ロードバランサー Azure Load Blancer/Application Gateway/Traffice Manager

シェアする

  • このエントリーをはてなブックマークに追加

Azure Load Blancer/Application Gateway/Traffice Managerとは?

Elastic Load Blancing(以下、ELB)は、AWSのロードバンランサーです。ELBには、

  • Classic Load Blancer(CLB)  :旧型
  • Application Load Blancer(ALB):2016年8月にWEB特化
  • Network Load Blancer(NLB) :2017年9月に大量トラフィック向け

の3つのロードバランサーがあります。

3つのロードバランサの仕様比較

項目 CLB(Classic) ALB(Application) NLB(Network)
概要説明  旧型の汎用型  HTTP/HTTPS専用 TCP専用
レイヤー  L4/L7 L7 L4
プロトコル TCP、SSL、HTTP、HTTPS HTTP、HTTPS TCP
ヘルスチェック  可
バランシング方式  ラウンドロビン パスベース、ホストベース ハッシュベース
タイムアウト設定  可(1~3600秒) 可(1~3600秒)  不可
SSLオフロード  可 不可
スティッキーセッション  可 不可
セキュリティグループ  可  可 不可
固定アドレス  なし なし あり
ログ記録先  S3  S3 CloudWatch
料金(※参考) 0.027ドル/時間

0.008ドル/GB

 0.024ドル/時間

0.008ドル/LCU時間

0.024ドル/時間

0.006ドル/LCU時間

※LCU(Loadbalancer Capacity Unit)時間:アクセス数、トラフィック量、振り分け先ルール利用数のいずれかが多いほど課金額が上がる課金体系

ELB構成パターン

ELBの構成パターン例を紹介します。ELBは他のサービスと指向をかえ構成パターンではなく、リクエスト増・トラフィック増というシュチュエーションを想定し、ALBとNLBの性能評価を行っています。CLBは旧型ということで検証対象から除外してます。

サービス 構成パターン システム概要
Elastic Load Blancing ELBのリクエスト処理性能評価 ALBとNLBのリクエスト処理性能を検証
ELBのトラフィック処理性能評価 ALBとNLBのトラフィック処理性能を検証

ロードバランサの性能は不可に応じて自動スケールアウト・インします。マネージドサービスなのでロードバランサ性能は指定できませんが、キャンペーンなどで突発的な負荷増が明らかな場合は暖気申請できます。暖気申請によって事前にELBの性能を強化しておくことが可能となります。但し、今回は暖気申請はせず、通常状態での性能検証を行っています。

ELB機能別解説

ELBについて「エンドポイント提供」「AZを横断した振り分け」「ヘルスチェックとルーティング判断」という機能ごとに説明します。CLB、ALB、NLBの機能はほぼ同じです。

機能 説明
エンドポイント提供 ロードバランサをAWSで作成するとelb.amazonaws.comのドメインをもつエンドポイントが作成されます。クライアントはエンドポイントにアクセスすれば、配下の仮想マシンにELBが振り分けを行います。

例えば、test.elb.amazonaws.comのエンドポイントを持つ、WEBサイトにアクセスする場合は、クライアントはELBのtest.elb.amazonaws.comだけを意識すれば、配下のWEBサーバを意識せずにアクセスが可能となります。

 AZを横断した振り分け ELBの配下リソースは同じリージョンに配置します。同じリージョン内なら複数のAZ(アベイラビリティゾーン)に分散してもかまいません。

例えば、東京リージョンの場合だとAZ-AからCまでそれぞれEC2インスタンスをたてELBに登録することで、AZを横断した構成が可能になり、可用性向上につながります。

ヘルスチェックとルーティング判断  AWSのロードバランサはすべて配下リソースに対するヘルスチェック機能をもっています。この機能により、正常でないリソースを振り分け先から除外し正常なリソースにルーティングします。

勿論インターネット経由での外部アクセスだけでなく、VPCに閉じた内部ロードバランサーとして利用することもできます。

ELB利用時のポイント

ELBについてみてきたが、3つのELBにつてはやはり適材適所という判断になると思います。特にALBとNLBについては他のAWSサービスと連携するという思考で作られているので、連携を視野に入れた選択なども必要になってくるでしょう。例えば、コンテナ管理のECSと連携させると動的ポートマッピングがアプリケーション通信制御が可能になったり、beanstalkと連携すればパスベースルーティングが可能になります。

その他にもALBではHTTPステータスコードなどL7のCloudWatchメトリクスを取得できたり、NLBでも処理バイトなどの情報が取得できたりするので、監視や管理面でも有効活用していくべきだと思います。

そのうえで最適なネットワーク設計をするためには、リソースIDや名前ベースのAWS的なネットワーク設計オンプレミス環境のIPアドレス設計とは異なることを理解し、ハイブリット環境を意識したVPCセカンダリーCIDRなどを活用することが重要となってくる。NLBに関してはハイブリット環境がだいぶ意識されており、DirectConnectやVPNルーティングに対応し振り分け先にIPアドレスが選択できるようになっています。

スポンサーリンク
スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする