Venkata Kondepati（PMP）は、Ascenttのデータアーキテクチャ＆エンジニアリングマネージャーで、クラウド、データ、AI、顧客IAM、GISを専門としている。
企業にとって顧客IAMソリューションは、オンボーディング、認証、セルフ登録、アクセス管理など、顧客を安全に管理するための不可欠かつ重要なシステムである。理想的なシステムでは、インフラやアプリケーションの課題に関わらず、プラットフォームは高可用性を維持すべきである。また、災害復旧（DR）、事業継続計画（BCP）、効果的なデプロイメントプロセスを備えている必要がある。
以下では、140万人のユーザー、80以上のアプリケーション、12億ドルの収益を生み出す業務をサポートするアクティブ-アクティブのマルチリージョンアーキテクチャの目標、課題、実装のハイライトについて説明する。このプラットフォームは、契約上のサービスレベル目標（SLO）とサービスレベル合意（SLA）に従って、RTO（目標復旧時間）とRPO（目標復旧時点）を1時間未満にすることが求められていた。プロダクトチームリーダーとして、私は2つのリージョンにまたがるアクティブ-アクティブのデプロイメントモデルを使用するようにシステムを再設計した。100万人以上のユーザーを支えるシステム構築から学んだこと：信頼性は単なる機能ではなく、あらゆる意思決定に組み込むべき約束なのである。
課題
以前のIAMソリューションは、3つのアベイラビリティゾーンを持つ単一のAWSリージョンにデプロイされていた。このリージョンで障害が発生すると、IAMソリューションも停止していた。従来の設定では、復旧に6時間以上かかり、金融機関、銀行、エネルギー、モビリティ顧客などの重要な顧客のピーク時間帯に大幅な時間損失が生じていた。
アクティブ-アクティブの高可用性アーキテクチャの設計と実装には、多くの課題があった：
データレプリケーション：プライマリリージョンとセカンダリリージョン間のデータ同期により、グローバルAWS Aurora RDSセットアップで整合性の問題が発生した。
ForgeRockデータストア：トランザクションのタイミングとノード同期の違いから生じる複雑さにより、データストアノード間で不整合なレプリケーションと調整が発生した。
リソースの制約：他の競合するプロジェクトの優先事項により、テストと検証に利用できるリソースが限られていた。
ワークフローとDevOpsの調整：クロスリージョンレプリケーションをサポートするために、CI-CDパイプライン、オーケストレーションスクリプト、モニタリングツールの変更に広範な反復が必要だった。
方法論
レプリケーションの問題を調査し、概念実証を開発し、アクティブ-アクティブの高可用性デプロイメントのための安定したアーキテクチャを設計するためのフォーカスグループが結成された。
データベース層
グローバルAWS RDSクラスターを構成して、セカンダリリージョンにリードレプリカを、プライマリリージョンにライターインスタンスをセットアップした。セカンダリリージョンでは、グローバルRDS構成のライトフォワード機能を使用して、すべての書き込みリクエストをプライマリリージョンに転送し、それをセカンダリリージョンに複製して、データの整合性を確保した。リージョンのAWS障害を検出するために、カスタムAWS Lambda関数が使用された。セカンダリリージョンへのフェイルオーバーが発生した場合、AWS Route 53ヘルスチェックを使用してトラフィックの再ルーティングが行われた。
アプリケーション層
ForgeRockデータストアのレプリケーションを再構成するために、マルチマスター同期が使用された。一時的な競合を処理し、ノードレベルの整合性を維持するために、グループはいくつかの調整戦略をテストした。このセットアップは、両方のリージョンにまたがる継続的な読み取りと書き込み操作中にユーザーセッションの整合性を維持する問題に対処するのに役立った。
デプロイメント戦略
リリース中のダウンタイムを回避するために、ブルー/グリーンデプロイメント戦略が使用された。これにより、本番トラフィックを処理する前に、ブルースタックで新しいリリースの変更を検証することができた。このアプローチにより、サービスの中断なしに様々な更新と構成変更を提供することが可能になった。
テストと検証
DR（災害復旧）テスト計画には、以下のシナリオが含まれていた：
• セカンダリリージョンの障害：すべてのユーザートラフィックをプライマリエリアにルーティングしながら、意図的にセカンダリリージョンに障害を発生させた。100、500、1000の同時ユーザーでパフォーマンステストを実行した。応答時間、認証成功率、スループットが測定された。
• プライマリリージョンの障害：プライマリリージョンに障害が発生し、セカンダリリージョンが新しいプライマリとして昇格された。トラフィックはセカンダリエリアに再ルーティングされ、同じユーザーセットに対して再度パフォーマンステストが行われた。
• 内部アプリケーション：内部向けアプリケーションは冗長性のために両方のリージョンにデプロイされたが、任意の時点で単一のアクティブリージョンから操作された。デプロイメントは同期され、リージョンの障害時にシームレスなフェイルオーバーが可能になった。JMeterを使用してロードテストが実行され、マルチリージョンセットアップの前後で結果がベンチマークされた。
学んだ教訓
私たちの経験に基づき、IAMプラットフォームを使用しているアプリケーションのリストを保持し、変更があるたびに更新することを強く推奨する。誰が何を使用していて、何のテストが必要かを追跡するのに多くの時間を費やした。重要なプラットフォーム変更に必要なインベントリと連絡先情報がなければ、この規模で変更を行うことは困難になる。
開発、検証、テストを迅速に進めるためには、専任のフォーカスグループを結成することが重要である。環境でDRとロードテストを実施することで、チームは本番デプロイメント前にボトルネックを特定し、パフォーマンスパラメータを微調整することができる。
80以上のアプリケーションチームとの連携が、それらのAWSアカウントとIAMシステム間の正確なネットワーク接続とルーティング構成のために必要だった。これらの各チームは、リージョンのフェイルオーバーテスト中にアプリケーションの動作を検証し、すべてのトラフィック条件下で認証が安定していることを確認する必要があった。
この構造化されたアプローチにより、IAMプラットフォームはリージョンの障害に対して完全な回復力を示した。障害、パッチ適用ウィンドウ、またはダウンタイムのないメンテナンスサイクル中も、システムはユーザーリクエストの処理を継続した。
結論
IAMアクティブ-アクティブアーキテクチャは、機能、負荷、災害復旧テストの複数のサイクルを経て、アイルランドとオレゴンの2つのAWSリージョンに本番環境として正常にデプロイされた。このソリューションは、シームレスなユーザーアクセスとセッションの継続性を維持しながら、1時間未満の目標RTOとRPOを提供した。
新しいアーキテクチャは、将来のスケーリングと地理的拡大のための強固な基盤を提供する。これは、クラウドネイティブな設計、自動化されたフェイルオーバー、規律あるオペレーショナルレディネスに基づいて構築された場合、複雑なIAMシステムが正確な高可用性を提供できることを証明した。私の経験から、効果的な計画、テスト、アプリケーションとインフラチームの連携が、エンタープライズグレードの耐障害性システムを構築するための鍵であることを強調したい。
