某都市銀行での業務システムの高可用性ソリューション
システム構成
下に示したのは某都市銀行のシステムの概念図です。大きく分けて上半分がAmazon EC2への移行が完了したシステム、下半分が既存の基幹系システムとなります。
一般ユーザー向けのシステム（キャンペーンサイトなど）は、インターネット経由でのアクセスを想定してAmazon EC2上で稼働しています。
業務システムとしては、前述の帳票管理やリスク管理、管理会計といった銀行業務のシステムがAmazon EC2上で稼働しています。これらの業務システムには、他の周辺システムとの連携を目的として、HULFTやJP1/AJS3が運用されることが多くあります。これらのソフトウェアは、停止してしまうと社内外の業務を止めてしまう可能性があるため、高いレベルの障害対策が求められます。
代表的なソフトウェアの例として、HULFTおよびJP1などをAmazon EC2上で冗長化することで、業務を止めない高可用性を実現します。
Amazon EC2上でソフトウェアを冗長化する場合、LifeKeeperは下記の図のようにAZ（Availability Zone）を跨いだ構成を前提としています。AZを跨ぐことで、広域障害にも対応することができ、高い可用性を実現します。クライアントからは仮想IPに対して通信することで、現在Activeなクラスターノードとの通信が可能となります。
LifeKeeperの標準機能のRecovery Kit for EC2は、サブネット内のルートテーブルのターゲット（ENI）をクラスタの切り替えに合わせて書き換えます。
仮想IPはVPCのCIDRの外側を指定しておくことで、クライアントから仮想IPに向けられた通信はルートテーブルを経由して現在Activeな方のノードに到達します。
また、HAクラスターシステムでは、切り替わりが行われた場合にクラスターノード間でデータを引き継ぐ必要があります。オンプレミスであれば共有ディスクを使うことが一般的ですが、物理的な共有ディスクを持ち込めないAmazon EC2環境では、レプリケーション製品のDataKeeperがブロックレベルのリアルタイム同期により論理的な共有ディスクを作り出すことで対応します。
クラスターに通信してくるマシン（クライアント）がAWSの外部（オンプレミス）にあるケースは多くあります。データセンターとAWSの間が閉域網で構成されているケースでは、Transit Gatewayが使える環境であれば図のように仮想IPを用いた構成が多く使われています。
なお、Transit Gatewayが使えない環境においては、仮想IPの代わりにRoute53によるホスト名の名前解決による通信制御にも対応しています。クラスターの切り替わり時に、LifeKeeperからAWS CLIを介してAレコードを書き換えます。この場合は仮想IPではなく実IPが使われます。
今回はAmazon EC2上でのHULFTおよびJP1/AJS3を例としたユースケースをご紹介致しましたが、LifeKeeperはオンプレミス環境（VMwareや物理サーバー）とクラウド環境（Amazon EC2、Azureなど）に対応しています。冗長化対象のアプリケーションも、HULFTやJP1の他にOracleをはじめとしたデータベースにも対応しています。詳しくはお気軽にお問い合わせ下さい。