国内銀行様の場合
はじめに
銀行のシステムでは、勘定系システムをはじめとする基幹系システムが中核となります。これらのシステムはオンプレミスで稼働していることが一般的です。一方で、帳票管理やリスク管理、管理会計といった周辺系システムはAmazon EC2に代表されるパブリッククラウドへの移行が加速しています。これらの周辺システムでは、他のシステムとの連携が一般的に行われるため、ファイルの連携やバッチジョブの自動化を目的としてHULFTおよびJP1/AJS3が頻繁に導入されます。
システム間の連携は業務に直結するミッションクリティカルな領域になるため、HULFTおよびJP1/AJS3を安心・安定して使うために高可用性構成を視野に入れる必要があります。
LifeKeeperは、グローバルで25年以上・8万ライセンス以上の導入実績のあるHAクラスター製品です。
HULFT・JP1/AJS3をはじめとした基幹系のアプリケーションの多くに対応しており、オプション製品のリカバリキットを使用することで、一般的なHAクラスター製品に必要な制御スクリプトの開発を行わずに、GUI上で直感的かつ迅速にHAクラスターを構築できる点が強みです。
構成について
銀行のシステムの概念図です。大きく分けて上半分が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をはじめとしたデータベースにも対応しています。詳しくはお気軽にお問い合わせ下さい。