class: title, smokescreen, shelf, no-footer # クラウドコンピューティング<br><small>第12回 ロードバランサー</small> <div class=footnote> <small><small> 3年、秋学期、選択; 旧「オペレーティングシステム」; ;脚注はELや定期試験の範囲ではありません </small></small> </div> --- class: compact,img-right # <small>【復習】ショッピングシステムの全体像</small> <div class=footnote> <small><small> (脚注) もっとも1万台も起動したら裏側の書きこみ部分が保つのか？は、別途、検討が必要です </small></small> </div>  <small> - Web APIサーバ = 本科目ではwww.pyのこと <br> (図中央のサーバ群に相当する) - 一式EC2の上にコンテンツとwww.pyを構築して、EC2をコピーすれば何台でも起動できます - 100台だろうが1万台だろうがドンとこい - <B>どのサーバに誘導するのか？が今回のテーマ</B> - 「ロードバランサー」が、その担当 </small> --- class: compact,img-right # <small>ショッピングシステムの階層構造</small> <div class=footnote> <small><small> (脚注) 同じ「階層」という用語ですが、 ファイルシステムとは考えていることが異なります。 ビルの1階2階のように階層として表現できるところだけは同じですが ... (a)"ファイルシステム"は<B>階層分類</B>を表現していました。 あの<B>木構造は「分類の大小関係」という暗黙の概念を含んでいます</B>。 そして同じ階層で横に並ぶモノは、 (大小関係では同レベルですが)分類は異なるモノです。 <br> (b)本スライドは単なる階層で、大小関係はありません。 同じ階層には同じモノが並んでいて数量が増減します </small></small> </div>  <small> - 階層モデルとして考えられます (左->右: 1->3) - 第1階層「ロードバランサー」はネットワークの担当です。 トラフィック(通信)を第2階層のどこか(Web APIサーバの一つ)に振り分けます - 第2階層「Web APIサーバ」が処理の本体、ビジネスロジックの実装部分。 スケールできるようにステートレスなアプリを作ります - 第3階層はデータを確実に読み書きする担当 </small> --- class: compact,img-right # <small>【復習、一年分】HTTPアクセスの全体像</small> <div class=footnote> <small><small> (脚注1) コンピュータネットワークの第9回「DNS」の復習です。 (脚注2) いわゆるサーバクライアントモデル。 サーバとはサービスを提供する側のことなので、 この図では、給仕さんがサーバ(この図はHTTPの説明なので「WWWサーバ」)に相当します </small></small> </div>  <small> ブラウザにURLを与えクリックした時の動作 - (0) DNSに問い合わせて、URLのサーバ名のIPアドレスを調べる - (1) サーバのIPアドレスへTCPコネクションを貼り、 HTTPプロトコルを使い、コンテンツを要求 - (2) 複雑な処理が必要な場合は、裏側で別のサーバに処理を依頼する (これがWeb APIサーバ) - (3) コンテンツのダウンロードを行う - (4) ブラウザは、ダウンロードしたコンテンツをレンダリングし、画面上に表示する </small> --- class: compact,img-right # <small>ロードバランサーの動作</small> <div class=footnote> <small><small> (脚注1) だからELBの設定をしたら 「ELBのコンソールでDNS名を調べて申請してください」ということになるわけです <br> (脚注2) ロードバランサーの返すIPアドレスが1個だったり複数個だったりしますが、 そのへんのネットワーク実装の詳細は省略 </small></small> </div>  <small> - URLのサーバ名はロードバランサーに設定 - 例: www.google.co.jp - 例: lb.b2902900.cloud.fml.org - ブラウザは(、DNSを引き)、ロードバランサー(のIPアドレス)に対してHTTPアクセス - ロードバランサー(第1階層)が、 Web APIサーバ群(第2階層)のどれかにHTTPを振り分けます </small> --- class: compact,img-right # <small>AWS ELBの特徴、ELBで出来ること</small> <div class=footnote> <small><small> (脚注1) その他の特徴については公式を参照 -> <A HREF="https://aws.amazon.com/jp/elasticloadbalancing/"> https://aws.amazon.com/jp/elasticloadbalancing/ </A> <br> ロードバランサーも製品によって出来ることが異なるので、 あくまでもAWS ELBの例です <br> (脚注2) ちなみにELBも、実体はELBイメージを動かすEC2群のはずで、このEC2群が増減しています </small></small> </div>  <small> - 高可用性 - ロードバランサーが障害を起こしたら全システムがダウンするので、 <B>複数のサーバ群が協調して動作しています(分散システム)</B> - ネットワーク障害に備えて、 デフォルトが<B>マルチAZ構成(異なるAZ上にサーバ群を構築)</B> - モニタリング - 振り分け先の負荷や障害を監視します - 自動スケーリング - 負荷に応じて自動的にELBのサーバ群も増減 - ELBとAWS Auto Scalingが連動することで、 負荷を見ながらWeb APIサーバを増減可 <br> (振り分け先も増減するEC2に自動追従) </small>