Amazon Web Services ブログ
保険会社がどのように 3 層アプリケーションのディザスタリカバリを実装するか
優れたレジリエンス戦略には、高可用性での運用とビジネス継続性の計画が不可欠です。また、地震や洪水などの自然災害、停電やネットワーク接続の障害などの技術的な障害の発生の考慮も必要です。AWS は、高可用性にはマルチ AZ 戦略を、ディザスタリカバリにはマルチリージョン戦略を推奨しています。このブログでは、米国を拠点とする保険会社であるお客様の事例を通じて、クラウドネイティブサービスを使用して 3 層アプリケーションのディザスタリカバリを実装する方法を説明します。
この保険会社では、かなりの数の重要なアプリケーションが 3 層構造の Java または .Net アプリケーションです。これらのアプリケーションは、Amazon EC2 インスタンス上で動作する IBM Db2、Oracle、または Microsoft SQLServer データベースへのアクセスを必要とします。要件は、パイロットライトまたはウォームスタンバイシナリオを実装するディザスタリカバリ戦略を作成することでした。この設計はコストを最小限に抑え、障害検知とリソースの手動フェイルオーバーを可能にする必要があります。さらに、目標復旧時間 (RTO) と目標復旧時点 (RPO) を 15 分以内に抑える必要があります。最後に、このソリューションではインターネット上のリソースを利用できず、すべてプライベートネットワーク内に構築する必要がありました。
ソリューション
Amazon Application Recovery Controller は、複数の AWS リージョンやオンプレミス環境にまたがるアプリケーションのフェイルオーバーとリカバリの管理とオーケストレーションを支援します。これは主にフェイルオーバーとリカバリ操作中の DNS ルーティングとトラフィック管理に焦点を当てていますが、一部のお客様はアプリケーション復旧のために独自の戦略を実装しています。このブログでは、ある金融サービスのお客様がどのように実装しているかを見ていきます。
Well-Architected フレームワークでは、優れたディザスタリカバリ計画には構成ドリフトを管理する必要があると説明しています。両方のリージョンにデリバリーパイプラインを使用してデプロイし、定期的にリカバリパターンをテストすることがベストプラクティスです。さらに一歩進んで、一定期間セカンダリリージョンで運用することを選択するお客様もいます。
当社の大手保険会社のお客様が選択したソリューションには、フェイルオーバーとフェイルバックという 2 つの異なるシナリオが含まれています。フェイルオーバーシナリオでは、プライマリリージョンからセカンダリリージョンへアプリケーションをフェイルオーバーするための一連のステップを網羅しています。フェイルバックプロセスは、運用をプライマリリージョンへ戻す処理です。
フェイルオーバー
お客様はパイロットライトシナリオのテストを実施することを決定しました。このシナリオでは、プライマリリージョンとセカンダリリージョンの両方にアプリケーションとデータベースをデプロイすることを前提としています。 15 分の RPO を達成するための要件として、プライマリリージョンにデプロイされたアプリケーションは、セカンダリリージョンにデータをレプリケーションする必要があります。この非同期レプリケーションは、データベース固有のツールを使用して、企業の各データベースエンジン (Db2、SQLServer、Oracle) に実装されています。各データベース独自のツールの活用は以前から行っていたやり方であり、これを採用することで運用上の影響を最小限に抑えることができます。
障害検出とフェイルオーバーの仕組みがセカンダリリージョンに作成されることは重要なポイントです。これにより、プライマリリージョンが利用できなくなった場合でも、これらのコンポーネントは利用可能な状態を維持できます。もう 1 つの重要な点は、2 つのネットワーク間の接続を確立することです。これは、データベースのレプリケーションを可能にするために必要です。
図 1. アプリケーションサーバーとデータベースを 2 つのリージョンにデプロイした 3 層アプリケーションのパイロットライトシナリオ
障害検出とフェイルオーバーは、以下の手順で実行されます。
- Amazon EventBridge スケジューラーが 60 秒ごとに AWS Lambda 関数を実行します。
- Lambda 関数はアプリケーションのエンドポイントをテストし、Amazon CloudWatch にカスタムメトリクスを追加します。アプリケーションが利用できない場合、CloudWatch アラームがフェイルオーバーを開始する Lambda 関数を起動します。
- Lambda 関数は Jenkins パイプラインを起動してフェイルオーバーを開始します。このパイプラインは、アプリケーションとデータベースをセカンダリリージョンにフェイルオーバーします。Jenkins パイプラインは手動承認ステップから開始され、フェイルオーバープロセスが自動的に開始されないようにします。
- 承認者がフェイルオーバーの必要性を確認した後、ワークフローを承認し、パイプラインは次のステージに進みます。
- パイプラインはデータベースをフェイルオーバーし、セカンダリリージョンのデータベースをプライマリ状態に昇格させ、書き込み操作を有効にします。
- 次に、EC2 インスタンスまたはコンテナで実行されているアプリケーションサーバーを起動またはスケールアウトします。これは、フェイルオーバー完了後にセカンダリリージョンで増加した負荷に対応できるようにするために重要です。
- この時点で、データベースとアプリケーションサーバーは負荷を受け入れる準備ができています。次に、Application Load Balancer (ALB) をセカンダリリージョンにフェイルオーバーする必要があります。Route 53 フェイルオーバールーティングポリシーは自動的にリージョン間でフェイルオーバーしますが、このお客様はヘルスチェックを使用してこのステップを手動で制御したいと考えていました。ALB の手動フェイルオーバーを実装するために、パイプラインは指定の S3 バケットにファイルを作成します。Lambda 関数は定期的にこのファイルが所定の場所に存在するかを確認します。ファイルが存在する場合、CloudWatch アラームをトリガーし、Route 53 ヘルスチェックが失敗します。この時点で、Route 53 はトラフィックをセカンダリリージョンの ALB にリダイレクトし、これが新しいアクティブエンドポイントとなります。
フェイルバック
フェイルバックシナリオは、プライマリリージョンで必要なすべてのサービスがオンラインになったときに開始されます。サービスの状態を確認するには、AWS Personal Health Dashboard を使用することをお勧めします。図 2 は、フェイルバックプロセスの詳細を示しています。フェイルバック手順の開始から最終的な DNS の切り替えまでの詳細な手順を示し、各段階で重要な構成要素とその連携を強調しています。この視覚的な表現により、プライマリリージョンへの運用復帰という複雑なプロセスが明確になります。
図 2. フェイルバックプロセスの図
フェイルバック手順は、以下の 6 つのステップで実装されます。
- クラウドオペレーターまたは Site Reliability Engineer (SRE) が HTML ページのフォームを送信することでフェイルバック手順を開始します。Lambda 関数が Jenkins パイプラインを起動します。
- パイプラインはデータベースの差分同期レプリケーションを開始します。これにより、セカンダリリージョンで行われたデータ変更がプライマリリージョンにレプリケートされます。
- 次のステージは、プライマリリージョンへの復旧のための手動承認ステージとなり、SRE はデータベースが同期されていること、および必要なすべてのサービスがプライマリリージョンでオンラインになっていることを確認します。
- 承認後、パイプラインはプライマリリージョンでアプリケーションサーバーを起動します。
- 次に、プライマリリージョンのデータベースが書き込み操作のために昇格されます。セカンダリリージョンのデータベースエンドポイントが、プライマリリージョンのデータベースを指すように更新されます。
- フェイルオーバーセクションで説明したように、DNS の切り替えは S3 に存在するファイルに依存します。このファイルはフェイルオーバーイベントのために作成されたため、パイプラインはここでこのファイルを削除します。Lambda 関数が変更を検知して CloudWatch アラームの状態を更新し、Route 53 ヘルスチェックが状態を変更します。この時点で、プライマリリージョンの ALB がアクティブになり、フェイルバックが正常に完了します。
利点
このお客様は、この設計を実装することで以下の利点を見出しました。
- 会社の内部プロセス、運用モデル、使用中の技術に合わせてカスタマイズ可能なソリューション
- データベース、EC2 上で実行される Windows および Linux アプリケーションなど、異なる技術を使用するアプリケーションに対して、組織全体で適用可能な標準化されたパターン
- 15 分未満の目標復旧時点 (RPO) と目標復旧時間 (RTO)
- 障害検知とフェイルオーバーシナリオを実装するためにクラウドネイティブサービスを使用したコスト最適化ソリューション
まとめ
3 層アプリケーションのディザスタリカバリソリューションは、この金融サービス企業のビジネス継続性とレジリエンスに対する取り組みを示しています。このアーキテクチャ設計は、企業が特定の要件に合わせてアーキテクチャをカスタマイズできることを示しています。重要なアプリケーションの RPO と RTO を 15 分未満に抑えることは、素晴らしい成果です。これにより、リージョン障害時のビジネスオペレーションの中断を最小限に抑えることができます。
さらに、このソリューションは企業内の既存の技術とプロセスを活用しており、組織全体でシームレスな統合と導入を可能にします。様々な技術を使用するアプリケーションに対してこのパターンを標準化できることで、運用の効率化と負担軽減に役立ちます。
もしあなたが重要なアプリケーションの回復性を向上させたいとお考えの場合、当社のお客様によるディザスタリカバリソリューションは参考になる事例です。AWS でのディザスタリカバリ戦略とベストプラクティスについて、さらに詳しく知りたい場合は、以下のリソースをご覧ください。
- Disaster Recovery of Workloads on AWS: Recovery in the Cloud: AWS におけるディザスタリカバリの概念と戦略について包括的な概要を提供します。
- Creating a Multi-Region Application with AWS Services: 3 部構成のブログ記事で、耐障害性を向上させるために複数の AWS リージョンにまたがるアプリケーションの設計に関する洞察を提供します。
- AWS Well-Architected Framework – Reliability Pillar: AWS 上で信頼性が高く耐障害性の高いシステムを構築するためのベストプラクティスについて説明します。
- Disaster Recovery Architectures on AWS: さまざまなディザスタリカバリシナリオのリファレンスアーキテクチャを集めた 4 部構成のブログ記事です。