ロードバランサー比較(AWS、Azure、GCP)


メンテナンスページ表示機能要件(詳細は後述参照)を満たせるかという視点で、各クラウド事業者(AWS、Azure、GCP)がサービスとして提供しているロードバランサーについて比較、検討してみました。

1.メンテナンスページ表示機能要件

現在、オンプレ構成(Apacheサーバ、もしくはLBアプライアンス製品)で以下の要件を実現している。

  • メンテナンス時間帯になったら自動的にメンテナンスページを表示したい
     例えば、AM1時00分になったら、自動的にメンテナンスページに切り替わるようにし、AM1時30分になったら、自動的に本番公開ページを表示するということがしたい

  • メンテナンスページには「メンテナンス時間帯」を記載したい
     ただし「メンテナンス時間帯」は毎回変わるので、都度編集が必須である

  • SEO対策のため、応答コードは「200」ではなく「503」としたい

  • 特定のIPアドレスだけからは、本番公開用ページを表示し続けたい

これらの要件をクラウド標準サービスで実現出来るのか、各社のサービス仕様を確認した。

2.AWSでの実現可否

2-1.メンテナンスページ表示の構成パターン

AWSでメンテナンスページを表示する方法として、以下の3点がある模様。いずれにしても、複数のサービスを組み合わせる形となる。

  • Route53 + S3
  • CloudFront + S3
  • Application Load Balancer(ALB)+α

2-2.実現可否

上記の3パターンのうち、要件を満たせそうなのは「Application Load Balancer(ALB)+α」となるが「+α」を何にするかで変わる。
事例としては、「+α」を「Lambda関数を呼び出してNode.jsで表示」にすれば出来そうな記事がヒットした。実際に試してないが、実現は出来そう。

2-3.参考:Application Load Balancer(ALB)

Application Load Balancer」はAWSロードバランサーのうち、もっとも高機能グレードのようだ。
ALB単独でもSorryPage(簡易なもの)の表示が可能のようだ。WAF機能、認証機能などがアドオン出来そうで、パスベースのルーティング、ロードバランサー振り分け先として、VPC 外のターゲット(IP アドレス指定)を登録できるようだ。
HTTP ヘッダーベースのルーティングもサポートしているようなので、ユーザーエージェント判別で、サイト振り分けも可能かと思われる。
執筆時点で、ALBの料金は、東京リージョンで以下の価格となっていた。

  • S/M/LとWAF有無により $18.0792/月 ~ $353.204/月
  • データ処理 0.008USD/時間

3.Azureでの実現可否

3-1.メンテナンスページ表示の構成パターン

Azureでメンテナンスページを表示する方法として、以下の2点がある模様。いずれにしても、複数のサービスを組み合わせる形となる。

  • Traffic Manager + Web Apps
  • Application Gateway + Blob Storage

3-2.実現可否

上記の2パターンともに要件が満たせそう。cronサーバやjobサーバで上記の設定変更をするように組み込む必要があるが、実現はできると思われる。

3-3.参考:Application Gateway

Application Gateway」は、AWS、Azure、GCPの3社の中では一番機能が豊富で柔軟性に使えそう
AWSと同じく、WAF機能がアドオン出来そうで、URI パスやホスト ヘッダーなど、HTTP 要求の追加属性に基づいてルーティングを決定出来る模様。
最大で 100 の Web サイト(ドメイン)を 1 つのアプリケーション ゲートウェイに追加でき、HTTP を HTTPS に自動的にリダイレクトされ、Cookie ベースのセッション アフィニティ機能もある。
カスタム エラー ページを作成、HTTP ヘッダーを書き換えまで出来るようだ。
執筆時点で、Application Gatewayの料金は、東京リージョンで以下の価格となっていた。

  • S/M/LとWAF有無により $19.71/月 ~ $353.204/月
  • データ処理 $0.008/GB ~ $0.0035/GB

4.GCPでの実現可否

4-1.メンテナンスページ表示の構成パターン

情報量が少なく、事例が見当たらない状況だが、GCPでメンテナンスページを表示する方法として、以下の1点のみと思われる。

  • HTTP(S) 負荷分散 | Google Cloud Load Balancing + α

4-2.実現可否

事例が少ないので、試行錯誤が必要と思われるが、要件は満たせそう。cronサーバやjobサーバで上記の設定変更をするように組み込む必要があるが、実現はできると思われる。

4-3.参考:HTTP(S) 負荷分散 | Google Cloud Load Balancing

HTTP(S) 負荷分散 | Google Cloud Load Balancing」は、他の2社(AWS、Azure)とは違い、物理的なリージョンには紐づかない、完全に論理的なソフトウェアデザインロードバランサーである。
1 つのエニーキャスト IP アドレスが、世界中のリージョンに分散されたすべてのバックエンド インスタンスのフロントエンドアドレスとして機能し、CDN機能がアドオン出来る。
ロードバランサー機能としては非常にシンプルかつ明瞭。

執筆時点で、Cloud Load Balancingの料金は、種類を問わずすべて同じ価格となっており、以下の価格となっていた。
他の2社(AWS、Azure)と同様、時間単価、データ処理量単価に基づいて料金が計算される

  • 時間単価
     最初の 5 つの転送ルール $0.025 1 時間あたり 月あたり18.6ドル
     追加の転送ルール 1 つあたり $0.010 1 時間あたり 月あたり7.44ドル

  • データ処理量単価
     ロードバランサで処理された上りデータ $0.008 GB 単位

5.まとめ

各社ともに共通して言えるのは、「メンテナンスページ表示機能」ではなく「Sorryページ表示機能」や「エラーページのカスタム表示機能」といったキーワードで検索すれば、調べたい記事がヒットした。
いずれも、1個のサービスのみでは実現が難しく、複数のサービスを柔軟に組み合わせて要件を達成する必要がある。
特に「メンテナンス時間帯」の指定については、スクリプトやバッチ等で作りこむことが前提となる。
「URLPATH」によるサーバ振り分け機能は、すべてのサービスで標準機能として実装されているが、「ユーザエージェント」によるサーバ振り分け機能は、ニーズが少ないのか、AWS、Azureで明言はされていないが出来そう。
なお、いずれのサービスにおいても、ストレージサービスをウェブサーバ代わりに使うことが可能だが、ステータスコードの処理については考慮が必要。


 Previous
SD-WANをOSSで実現できるのか? SD-WANをOSSで実現できるのか?
昨今、話題となっている「SD-WAN」が「どのような技術を組み合わせて実現しているのか」について興味が湧いたので、Google先生に聞いた結果をまとめてみました。ダディ伯爵は、WANで使われるダイナミックルーティングプロトコルである「BGP
2019年07月06日
Next 
クレカ不要でGCPを始めよう「Qwiklabs」が無料で使える♪ クレカ不要でGCPを始めよう「Qwiklabs」が無料で使える♪
一昔前から、クレジットカード登録さえすれば、1年間無料、1ヶ月無料といった無償サービスが主流でしたが、最近は、クレジットカード登録が不要で試せるようになっている無償サービスが出てきていますのでまとめてみました。 カテゴリ:GCP入門合わ
2019年06月24日
  TOC