【AWS×LifeKeeper】高可用性をかなえるための主要パターン集

近年、クラウドサービスの選択肢はますます多様化しており、さまざまなクラウドが活用されています。
世界のクラウドプロバイダーのシェア上位3社を見ると、AWSが29%、Microsoft Azureが20%、Google Cloudが13%となっており※、
Microsoft AzureやGoogle Cloud Platformも成長を続けていますが、依然としてAWSがトップの座を維持しています。
(※2025年第3四半期データ　Cloud Market Growth Rate Rises Again in Q3; Biggest Ever Sequential Increase | Synergy Research Group)

実際、当チームでもクラウド案件の多くは引き続きAWSが中心です。
そこで本記事では、LifeKeeperによる可用性対応の観点から、AWSでよく採用される代表的な構成パターンについて紹介します。
AWS環境で高可用性設計を検討されている方の参考になれば幸いです。

AWS OSごとの基本構成

Amazon EC2で冗長化構成をとる場合のOSごとの基本構成は以下の通りです。(稼働系、待機系ノード間でデータ共有を行う場合を想定。)
基本的に他のクラウドやオンプレミスの仮想環境と大きく変わりません。
Windows環境の場合はWindows標準機能のWSFCを使用することでコストを抑えた高可用性を確保することができます。

Linux	Windows
LifeKeeper+DataKeeperの組み合わせ	LifeKeeper+DataKeeperの組み合わせ	WSFC+DataKeeperの組み合わせ

※DataKeeperによるデータレプリケーションは必須ではなく、LifeKeeperのみの構成も可能です。
※図では省略しておりますが、可用性の観点から、各クラスターノードを別々のアベイラビリティゾーン（AZ）に配置することで、物理的な障害発生時にもシステム停止リスクを最小限に抑えることが可能です。

ルートテーブルシナリオ(仮想IPとルートテーブルによる制御)

この構成はクラスターを同じVPC内のクライアントから接続される際によく用いられます。
クライアント（クラスタノードと通信するマシン）は仮想IPに向けて通信することでActiveノードに到達できます。
AWS環境でAZを跨ぐとサブネットも跨いでしまうので、オンプレミスのように仮想IPだけではクライアントは正しくActiveノードへ到達できません。
そこで、VPCのCIDR外の仮想IPをルートテーブルに登録し、転送先のActive/StandbyノードのENIをクラスターの切り替え時にLifeKeeperからAWS CLIを介して書き換えることで、クライアントは常にActiveノードに到達できます。

＜概要図＞
   

この構成で利用必須となるRecovery Kit： Recovery Kit for EC2、Recovery Kit for IP Address

※注意：AWSの仕様上、クライアントはクラスタと同じVPCに存在している必要があります。
仮想IPはVPCのCIDR外で割り当てる必要があります。

ルートテーブルシナリオにAWS Transit Gatewayを組み合わせた制御

ルートテーブルシナリオにAWS Transit Gatewayを組み合わせることで、VPC外（オンプレミスや別VPC）からもクライアント通信に対応できます。
例えば、JP1等の統合運用管理ツール、HULFTなどのファイル転送ソフトでクライアントがVPC外にいる場合、この構成が有効です。

＜概要図＞

この構成で利用必須となるRecovery Kit： Recovery Kit for EC2、Recovery Kit for IP Address

※注意：Transit Gateway向きのルートテーブル設定を行っておく必要があります。

Route53のAレコード書き換えによる制御

Transit Gatewayが使えない場合などに、DNSサービスのRoute53での名前解決を利用する構成です。
クライアントはRoute53により名前解決された実IPに向けて通信することで、Activeノードへ到達できます。

＜概要図＞

この構成で利用必須となるRecovery Kit： Recovery Kit for Amazon Route 53™、Recovery Kit for IP Address

※注意：クライアントはホスト名(FQDN)でアクセスできることが前提になります。
LifeKeeper(Recovery Kit for Amazon Route 53™)に登録するホストゾーン名がパブリックホストゾーン、プライベートホストゾーンで複数存在している場合、Recovery Kit for Amazon Route 53™によるリソース作成は現状不可となりますのでご注意ください。
(参考：同名のホストゾーンは使えない！？ Amazon Route 53リソース作成時の注意点 – TechHarmony)
⇒上記問題発覚後、サイオステクノロジー社に改善提案を出したところ、今後改善予定で動いているとのこと。(2025年12月時点リリース時期未定)

NLBのヘルスチェックによる制御

NLB（Network Load Balancer）のヘルスチェックを利用した構成です。
セキュリティ要件により、前述のようなAWS CLIによる構成変更が実施できない、インターネットに接続していない環境でクライアントからDNS名でアクセスしたい場合にはこの構成をご検討下さい。
クライアントからはNLBのDNS名でアクセスし (AWS内部のRoute 53経由で解決）、NLBのヘルスチェックとLB Health Check Kitを組み合わせて、ヘルスプローブを受け取ったノードにトラフィックを転送することで接続先の切り替えを実現します。

＜概要図＞

さいごに

今回は代表的な構成についてご紹介しましたが、
その他にもクロスリージョン構成やAWS Outpostsで共有ディスクを冗長化させるなど様々な構成にも対応しています。

この記事で紹介されていない構成につきましては弊社やサイオステクノロジー社にお問い合わせ頂くことを推奨いたします
本記事がAWS環境における冗長化の参考になりましたら幸いです！