1. はじめに
本稿では、オンプレミスからAWSへの移行で頻繁に課題となるアプリケーションの設計思想の間にあるギャップの1つ、VRRP（Virtual Router Redundancy Protocol）による冗長構成を前提にしたアプリケーションのAWS移行について考察していきます。
（オンプレミスからのAWS移行は、現在でも多くの案件で検討されています）
2.オンプレミスにおけるVRRP冗長構成の概要
オンプレミス環境では、高可用性を実現するために、ロードバランサー製品にVRRPを用いた冗長構成が広く採用されています。VRRPは、複数のネットワーク機器が1つの仮想IPアドレス（以下、VIP）を共有し、クライアントからの通信を常にそのVIPに向けて行うことで、冗長性を確保する仕組みです。
2.1. VRRPの動作原理とフェイルオーバー
VRRPは、以下のような構成がよくある構成になります。
この構成では、1台のロードバランサーがマスターとしてVIPを保持し、他の機器はバックアップとして待機します。マスターが正常に稼働している間は、すべてのトラフィックがマスターを経由します。マスターがダウンした場合、VRRPプロトコルに従ってバックアップ機が自動的にVIPを引き継ぎ、即座にマスターとして昇格します。これにより、クライアント側からはIPアドレスの変更を意識することなく、サービスが継続される形態です。
2.2. オンプレミスにおけるVRRPのメリットとアプリケーションへの影響
商用のロードバランサー製品では、このVRRPによる冗長化が組み込まれており、L3/L4レベルでの高速なフェイルオーバーが可能です。さらに、様々なプロトコルに対応していたり、Active/Active構成やActive/Standby構成を選択できたりと、オンプレミスで柔軟かつ堅牢な冗長構成を実現できます。
VRRPベースの設計思想に基づいたアプリケーションでは、上記の図の構成を暗黙の了解としているケースがあります。その場合、アプリケーション側のコードに、単一のIPアドレスに接続するコードが含まれていることがあります。企業間のネットワーク間での接続など、複数のシステム間で接続している場合、単一のIPアドレスでの接続を規約としていて、規約の変更、構成変更が困難というケースもあります。
3. AWSの設計思想：冗長性と拡張性の確保
一方、AWSでは、単一のIPアドレスを使用する形態で、かつ冗長性を高めたい場合は、選択可能な構成が絞られてきます。
というのも、AWSでは、オンプレミスでのVRRPの設計思想と異なり、固定IPアドレスから脱却し、接続を固定のFQDNにすることで、冗長性と拡張性を高める設計思想になっているためです。
3.1. AWSにおける冗長性設計の基本：Everything Fails All the Time
AWSの冗長性を高める考え方をまず振り返ってみましょう。
AWSの冗長性設計を理解するうえで、まず押さえておきたいのが、Amazon CTO Werner Vogels氏の有名な言葉「Everything Fails All the Time（すべてのものは常に故障する）」です。この言葉は、AWSのインフラ設計思想を象徴するものであり、クラウド環境では障害は避けられない前提で設計すべきだという強いメッセージを含んでいます。オンプレミスでは「壊れないように守る」設計が主流でしたが、AWSでは「壊れても耐えられる」構成が基本です。
3.2. マルチAZによる可用性の向上
この思想に基づいて、AWSの各リージョンは複数のAZ（Availability Zone）で構成されています。AZはそれぞれ独立した電源・ネットワーク・冷却設備を持つ物理的なデータセンター群であり、AZ単位での障害に備えた冗長構成が可能です。つまり、AZの障害に備えて、単一のAZに依存する構成ではなく、複数AZにまたがってリソースを配置することで、可用性を高める設計が推奨されます。
AZ障害が発生しても問題なく稼働できる構成を推奨する資料は多数ありますが、ここでは、その中の一例をご紹介します。
3.3. オンプレミスデータセンターの可用性レベルとの比較
オンプレミスでも機器を冗長に構成することは当然行われています。ただ、データセンターの単位では、単一のデータセンター内で機器を冗長に構成する形態が多いと思います。AWSのマルチAZは、オンプレミスでの感覚だとDR構成相当の構成を最初から組みましょうと言われているのと同じ感覚かもしれません。
ちなみにオンプレミスの考え方では、データセンターは、単一のデータセンターでも十分な可用性を担保できるよう、品質を高めていこうという考え方です。本稿の趣旨と外れますが、概要程度でご紹介します。
データセンターの可用性は、グローバルではUptime Institute、日本国内ではデータセンターファシリティスタンダードという品質基準があります。日本の基準は、Uptime Instituteの基準をもとに、日本国内の電源事情・地震リスク・建築基準法などが考慮されています。Uptime Instituteもデータセンターファシリティスタンダードも「Tier/ティア」と呼ばれる基準があり、ティア1からティア4まであります。
| ティア | 特徴 | 稼働率 | 年間稼働率 の目安 |
|---|---|---|---|
| ティアI | 最低限のインフラ、冗長性なし | 99.671% | 約28.8時間 |
| ティアII | 一部冗長構成（UPSや冷却） | 99.741% | 約22時間 |
| ティアIII | 同時保守性あり ※保守や障害時に1台分の余裕を持たせることで、 サービスを継続可能にするN+1設計 |
99.982% | 約1.6時間 |
| ティアIV | フォールトトレランスあり ※どちらか一方が完全に故障しても、 もう一方でサービスを維持できる、 同じ構成を丸ごともう1セット用意する 完全冗長構成の2N設計 |
99.995% | 約26分 |
AWSのデータセンターは、以下に記載がありますが、目安としてはティアIII相当、でもティアにとらわれない設計をしている、とのことです。
Uptime Institute Tiers
https://aws.amazon.com/jp/compliance/uptimeinstitute/
How does AWS apply the Uptime Institute guidelines?
The AWS Global Cloud Infrastructure is the most secure, extensive, and reliable cloud platform. AWS data centers are generally designed to meet the requirements of concurrent maintainability, which is at the core of the Uptime Institute Tier standards. However, AWS has chosen not to have a certified Uptime Institute-based tiering level so that we have more flexibility to expand and improve performance. AWS' approach to infrastructure ensures the highest level of performance and availability for our customers. Specifically, AWS infrastructure within our Availability Zones exceeds concurrent maintainability standards by also focusing on metrics not tracked by those standards.
3.4. AWSにおける拡張性設計の基本：FQDNとスケーリング
次に、AWSで拡張性を高める考え方も振り返ってみましょう。
AWSでは、先ほどのマルチAZの考え方で、ロードバランサー（ALB/NLB）やAuto Scaling Groupを活用し、複数AZにインスタンスを分散配置することで、AZ障害時にもサービスを継続できる構成が基本です。
AWSのマネージドサービスは、ほとんどのサービスでFQDNを使って接続します。このFQDNを使うことの意義として、FQDNで示されるIPアドレスが増減しても対応可能である、という意義があります。
具体的な例として、ALB（Application Load Balancer）を見ていきましょう。
ALBは、ポンチ絵としては上図のようにAZの間にアイコンが置かれる例が多いです。しかしながら実態としては、以下の図のように、VPCの中でALB用のサブネットの中に、ALBのインターフェース（ENI）が作成される形態です。
この図では、VPCの中で、パブリックサブネットの中に、ALB用のENI（Elastic Network Interface、プライベートIPアドレス等のネットワーク属性を持つ仮想インターフェース）があります。このENIは、固定ではなく、ALBのアクセス量が増えたり減ったりする都度、それに合わせてENIも増えたり減ったりします。
ちなみに、ALBのユーザーガイドでは、1つのサブネットにつき最大8個のIPアドレスを使うことが記されています。
ロードバランサーが正しくスケールできるように、ロードバランサーのアベイラビリティーゾーンサブネットごとに CIDR ブロックを最低でも /27 ビットマスク (例: 10.0.0.0/27) にし、少なくとも各サブネットにつき 8 個の空き IP アドレスを用意してください。これらの 8 個の IP アドレスは、ロードバランサーが必要に応じてスケールアウトできるようにするために必要です。
上記から、AWSの多くのマネージドサービスでは、以下の特徴を有していると言えます。
- FQDNが固定で、アプリケーションはこのFQDNにアクセスする
- そのFQDNが示すサービスでは、アクセス量によってスケールアウト等のスケール処理が行われる
- スケール処理では、IPアドレスが増えたり減ったりするが、そのIPアドレス群を示すFQDNは固定なので、アプリケーションからの接続には影響しない
このような考え方で、AWSでは拡張性を高めることが可能になっています。
4. オンプレミスVRRPアプリケーションのAWS移行の一般的な課題
ここまで、AWSでは、マルチAZと、FQDNでの接続（IPアドレスにはとらわれない）という、冗長性、拡張性を高める設計思想について触れてきました。
ここで改めてオンプレミスのVRRPを前提としたアプリケーションでの一般的な課題を振り返ります。
オンプレミスのアプリケーションでは、単一のIPアドレスに接続することを前提としたコードが組み込まれていることがあります。
これが、AWSの冗長性や拡張性の設計思想と適合しません。
AWSでは、IPアドレスにとらわれずに冗長性や拡張性を確保できる設計思想です。VPCの中にはサブネットがありますが、このサブネットは、AZ単位で閉じています。1つのサブネットは必ず特定のAZに属しています。そのため、AZを跨いで、1つのリージョンで同一のIPアドレスを共有する構成は、AWSの設計思想と整合しない、ということになります。
それでは、オンプレミスのアプリケーションをAWSに移行する時には、アプリケーションを修正すればよいかというと、その修正に対するコストが課題となってしまいます。
5. AWSにおける単一IPアドレス（VRRPによる仮想IP接続）代替の選択肢と特徴
この章では、AWSで選択可能な、IPアドレスを固定化する方式について、その方式と特徴を見ていきます。AWSの設計思想とは適合しないとはいえ、いくつかの選択肢があります。
以下に、AWSで「固定の単一IPアドレスによる接続」を実現する代表的な構成と、それぞれの特徴を整理します。
5.1 AWS Global Accelerator
AWS Global Acceleratorは、グローバルに固定されたパブリックIPアドレスを提供し、TCPやUDPといった特定のプロトコルに限定されない幅広い通信をサポートします。このサービスは、複数のAWSリージョンにエンドポイントを配置できるため、障害発生時には自動的に健全なリージョンへルーティングすることで、高い冗長性を実現します。特に、マルチリージョン対応のアプリケーションや、クライアント側でIPアドレスの固定が厳しく求められる場合に有効な選択肢です。
5.2 Network Load Balancer（NLB）
Network Load Balancer (NLB) も固定IPアドレスの利用を可能にします。NLBは各アベイラビリティゾーン（AZ）内で固定のパブリックIPアドレスまたはプライベートIPアドレスを提供し、TCP/UDPやTLSといったL4レベルのトラフィックを処理します。
ただし、NLB自体がリージョン全体で単一のIPアドレスを共有するわけではなく、AZごとに異なるIPアドレスが割り当てられます。AZ単位でのIPアドレスの固定化です。NLBで高い可用性を求める場合には、マルチAZでの構成が必要となります。
5.3 Elastic VMware Service
オンプレミスのVRRPベースの設計を大きく変更せずにクラウドへ移行したい場合には、Elastic VMware Service が有力な選択肢となります。このサービスは、オンプレミスで運用していたVMware環境をAWS上に展開できるため、仮想IPアドレス（VIP）やL2ネットワーク構成なども再現可能です。VMwareのHA機能がそのまま利用できることに加え、AWSのインフラ上で動作することで高可用性も担保されます。
ただし高コストとなるため、既存のオンプレミス環境がVMwareで、そのまま移行したい場合のみ、この構成を採用となるかと考えられます。
5.4 パブリックIPアドレスの付け替え
特定のEC2インスタンスへの直接接続が必要な場合には、パブリックIPアドレスの付け替えが検討できます。具体的には、Elastic IP (EIP) を利用することで、固定のパブリックIPアドレスをEC2インスタンスに割り当てることが可能です。
ただし、EIPは一度に1つのリソースにしか割り当てられないため、冗長性を確保するためには、インスタンス障害時にEIPを別のインスタンスに付け替える仕組み（例えば、スクリプトによる自動フェイルオーバー）が必要となります。
5.5 プライベートIPアドレスの付け替え
VPC内部での冗長化を実現するアプローチとして、プライベートIPアドレスの付け替えがあります。これは、EC2インスタンスに割り当てられているプライマリプライベートIPアドレスとは別に、セカンダリプライベートIPアドレスを柔軟に付け替えできる機能を利用するものです。例えば、あるEC2インスタンスに障害が発生した場合でも、そのセカンダリプライベートIPアドレスを別の健全なインスタンスに付け替えることで、サービスを継続させることが可能です。
この方法も、EIPの付け替えと同様に、アプリケーションやカスタムスクリプトによる制御が必要となります。
5.6 VPC外のIPをルーティングテーブルに設定する方式
VPC外のIPアドレスをルーティングテーブルに設定する方式は、VPCのルートテーブルに、VPCのCIDRの範囲外のプライベートIPアドレスを静的に設定し、ルーティング上で特定のEC2インスタンスへトラフィックを誘導する方式です。
VPCのCIDRを10.0.0.0/16、VPCの範囲外のプライベートIPアドレスを192.168.0.10/32とします。EC2は、以下で配備されているとします。
-
EC2①
ap-northeast-1aのAZ上の10.0.1.0/24のサブネットに、
10.0.1.15というプライベートIPアドレスで配備 -
EC2②
ap-northeast-1cのAZ上の10.0.2.0/24のサブネットに、
10.0.1.30というプライベートIPアドレスで配備
ここで、VPCの範囲外のプライベートIPアドレス192.168.0.10/32へのアクセスを、EC2①の10.0.1.15にルーティングする設定とします。EC2①は、192.168.0.10/32へのアクセスを、自分自身へのアクセスとして処理します。EC2①に障害があった時に、192.168.0.10/32へのアクセスを、EC2②の10.0.2.30にルーティング変更します。
このようなルーティングのアプローチによって、リージョン内で同一のプライベートIPアドレスを使用することが可能になります。
この方式は、EC2でのクラスター構成をAWSで構築するミドルウェアで採用されています。
まとめ
このようにAWSでは、オンプレミスのVRRPでの仮想IPを使う接続方式の代替としていくつかの選択肢があります。アプリケーションの要件（IP固定の要否、プロトコル、冗長性、拡張性、移行コスト）を考慮して、最適な構成を選択することが重要です。
さて、次の投稿では、ここでご紹介した構成を、具体的なアーキテクチャ図とともに紹介していくことを考えています。
この投稿が皆様のご参考になれば幸いです。