皆さんこんにちは、西下です。本年もよろしくお願いいたします。
今回は2019年のクラウドをめぐる出来事を受けて浮かび上がった課題についてお話したいと思います。
2019のクラウドをめぐる出来事
2019年を振り返ると、AWS東京リージョンで広域障害が発生し多くのサービスが利用出来なくなったり、多数の自治体で証明書発行システムに障害が発生したりと、クラウドでのシステム障害がニュースになった年でもありました。
そういった背景もあり、クラウド環境での障害対策の必要性を感じた方が増え、当社にもお問い合わせが多く寄せられています。
最も多かったのは「基幹系システムをオンプレミスからAWS（Amazon EC2）に移行（リフト）するに伴い、オンプレと同等の可用性を確保したい」というお問い合わせです。
クラウド障害が起きてもシステムを止めないためには
ジョブ管理システムのJP1やファイル転送システムのHULFTに代表される基幹系システムは、文字通りビジネスの根幹をなすシステムですので、クラウドで障害が発生しても止まらない事が求められます。
システム停止を防ぐ対策として当社がおすすめするのはHAクラスターです。
AWSでは障害対策の手法として複数のAZに冗長化させることを推奨しています。
そこで必要になるのがHAクラスターです。
HAクラスターは障害発生時に待機系のEC2にフェイルオーバーさせシステムを止めない仕組みです。
当社では低工数でHAクラスターが構築できる「EC2™専用リカバリーキット」を製品の標準機能でご用意しています。これらは下記の構成対応しています。
EC2上のHAクラスター構成例
↓製品の標準機能で対応している構成の概念図（いずれもAZを跨いだ構成）
上記の表の中で実際に案件で多いのは、一番左の「ルートテーブルシナリオ」と左から3番目の「Route 53（DNSのサービス）による制御」になります。
この内Route 53による制御は、下記の点がネックになることがあります。
- クライアントがホスト名でアクセスできない要件の場合は使えない
- TTLなどDNSの設計を考慮する必要がある
- Route 53をAWS CLIで制御するには、インターネットに出られることが前提になる
AWS Transit Gatewayでシンプルな構成を実現
これらの課題を解決するのがAWSのTransit Gatewayサービスです。東京リージョンでも2019年9月からDirect Connect環境が使えるようになっています。
Transit Gatewayそのものは、VPCやオンプレミスを単一のゲートウェイで接続可能にするサービスです。当社のHAクラスターソリューションのLifeKeeper の観点では、Transit Gatewayのルーティング設定により、VPC外部からの通信であっても「ダミーの仮想IP」にアクセスできます。
これにより、上記概念図の「ルートテーブルシナリオ」であらゆる構成に対応でき、シンプルかつ効率的な構築作業が可能になります。
↓Transit Gatewayとルートテーブルシナリオを組み合わせた概念図
Transit GatewayはLifeKeeper for Linux v9.4.1とLifeKeeper for Windows 8.7で公式にサポートされています。AWS移行をお考えの方はぜひご検討ください。
また、当構成の動作検証にあたっては「AWS 専用線アクセス体験ラボ」に多大なご協力をいただきました。この場を借りてお礼申し上げます。
もっと詳しく知りたい方は、こちらの動画をご覧ください。
AWS Transit Gatewayを使ったHAクラスター構成についてご紹介しています。
アジェンダ
・AWS Transit Gatewayについて
・Transit Gatewayを使わないHAクラスター構成
・Transit Gatewayを使ったHAクラスター構成
お問合せ
今後もLifeKeeperは、多様な環境で障害対策を実現できるよう様々なアップデートを計画しています。新たにサポートを開始した環境を利用してみたい等のご相談がありましたら、お気軽にお問い合わせください。
