トップ > Amazon EC2 > ALBでの負荷分散・冗長化をマルチリージョンで行う

ALBでの負荷分散・冗長化をマルチリージョンで行う

Amazon EC2 コスト削減
記事タイトルとURLをコピーする

こんにちは、クラウドインテグレーション2部 技術1課 宮形 です。

AWS の Application Load Balancer (以下ALB) では、ALBの配置先とルーティング先のEC2インスタンスは単一VPCとする構成が一般的ですが、実はALBとEC2インスタンスが異なるリージョン・異なるVPCという構成も可能になっています。ALBでの負荷分散・冗長化をマルチリージョンで行うことができます。

本BLOGでは設定方法をご紹介させていただきます。

構成図と概要

構成図としては下記のようになります。

VPC間の接続に Transit Gateway を利用しました。ALB から EC2 へ疎通できればよいので、VPCピアリング、Site-to-Site VPN でも可能です。ALBとEC2を配置する東京リージョンを「メインリージョン」、EC2のみ配置するバージニア北部を「サブリージョン」としました。

実はもともと AWS Global Accelerator の利用を検討していたのですが、調査するとインターネット接続が必須とわかりました。プライベート接続(インターネット非公開)を行いたケースがあることと、すでに Transit Gateway が構築済であったことから、ALB で実現することにしました。

メリット

下記メリットがあると考えています。

  • EC2利用料が安価なサブリージョンを選択することでのコスト削減
  • EC2にスポットインスタンスを利用した際のインスタンス中断対策（マルチリージョンとすることで全台が同時に停止するリスクを避ける）

注意しなくてはならないのは、コスト削減が主な目的であり、メインリージョン全体障害時のディザスタリカバリ(DR)としては適切ではないことです。ALBがメインリージョンのみの単一障害点であるためです。メインリージョン全体障害対策の場合は、サブリージョンにも ALB を配置し Route 53 フェイルオーバールーティングを組み合わせる等が適切です。

設定方法

VPC、EC2、Transit Gateway、ALB の設定方法については、すでに弊社ブログや一般サイトに多々情報があると思うので、割愛いたします。

各 EC2インスタンス の Security Group 設定

各EC2インスタンスは、ALBからのルーティングが行えるよう Security Group インバウンドルールは適宜開放しておきます。 サブリージョン側はVPCが異なるのでインバウンドルールのソースを Security Group が選択できません。メインリージョン側のCIDRブロックで設定します。

ターゲットグループとALBの設定

設定作業はメインリージョン側のAWSマネージメントコンソールから行います。本例では東京リージョンとなります。

VPCコンソールより、「ターゲットグループ」-「ターゲットグループの作成」を選択します。

最初の画面の「ターゲットタイプの選択」では「IPアドレス」を選択します。

最初の画面の残りの設定は、通常の ALB 設定時と同じです。「VPC」は ALB を配置するメインリージョンのVPC-IDとします。

ヘルスチェックも 通常の ALB 設定時と同じです。「次へ」を選択します。

次の画面「IPアドレス」では、ステップ1のネットワークに ALB を配置するメインリージョンのVPC-IDを選択します。 ステップ2の IPv4アドレスにメインリージョンに配置するEC2インスタンスのプライベートIPアドレスを指定し、「保留中として以下を含める」を選択します。

続けて同じ画面でステップ1のネットワークに「その他のプライベートIPアドレス」を選択します。 ステップ2の IPv4アドレスにサブリージョンに配置するEC2インスタンスのプライベートIPアドレスを指定し、「保留中として以下を含める」を選択します。

画面を下へスクロールして「ターゲットを確認」へ進めます。本例ではターゲット一覧にメインリージョンのEC2インスタンス2台(ゾーン=ap-northeast-1)、サブリージョンのEC2インスタンス2台(ゾーン=すべて)の計4台が表示されていることを確認します。「ターゲットグループの作成」を選択して、設定を完了します。

続けて「ロードバランサー」の画面より、今ほど設定したターゲットグループをALBのルーティング先として割り当てします。

ターゲットグループの「ターゲット」タブの画面より、すべてのEC2インスタンスのヘルスチェックが healthy になっていることを確認します。

以上でターゲットグループとALBの設定作業は完了です。

動作確認

WebブラウザよりALBへアクセスします。無事Webサイトが表示されます。各リージョンのどのEC2インスタンスに接続しているかわかるようWebページを配置しておくと、F5キー等で画面更新にあわせてラウンドロビンで順番に異なるリージョンのEC2へルーティングされていることがわかります。

メインリージョンのEC2インスタンス2台をすべて停止しましたが、Webサイトはサブリージョンのみで表示できていることがわかります。

逆にサブリージョンのEC2インスタンス2台をすべて停止しました。Webサイトはメインリージョンのみで表示できていることがわかります。

無事、期待する動作となることが確認できました。

注意点

異なるリージョン間接続のデータ転送料金

本例では 異なるリージョン間のVPC接続に Transit Gateway を利用しており、データ転送料金がかかります。クライアントサーバー間の通信データ量が多いシステムでは、この点がコスト増にならないよう注視する必要があります。

スポットインスタンス中断時の対応

EC2にスポットインスタンスを利用している場合、中断した時のデフォルト動作が「インスタンス終了」となっています。 その後にEC2の起動(＝再作成)を行うと殆どの場合プライベートIPアドレスが変わってしまうので、ターゲットグループの設定対応が必要です。

設定によりスポットインスタンス中断時の動作を「休止」に変えておくとプライベートIPアドレスが保持されるので、検討するとよいでしょう。

参考： 中断した スポットインスタンス の休止 - Amazon Elastic Compute Cloud

まとめ

ALB のターゲットグループをインスタンスではなくIPアドレスとすることで、ALBでのEC2の負荷分散・冗長化をマルチリージョンで行うことが出来ました。コストを抑えながらサービスの可用性を高めたい場合に検討できる構成ではないでしょうか。

本BLOGが皆様のお役にたてば幸いです。

宮形純平(執筆記事の一覧)

エンタープライズクラウド部 ソリューションアーキテクト1課

好きなお酒は缶チューハイと本格焼酎

"; doc.innerHTML = entry_notice + doc.innerHTML; }
' } }) e.innerHTML = codeBlock; });