重要なマルチリージョン、アクティブ/アクティブ金融システムのアーキテクト

Pulisher : Strategic Tech Center ソ・ソンス
Description：マルチリージョンアプリケーションアーキテクチャーとマルチリージョンActive-Activeアーキテクチャーの改善方法について紹介したChalktalkのセッション

はじめに

アプリケーションの近代化において、ミッションクリティカルなシステムが障害が発生した場合に、どのように回復力と高可用性を維持するかを保証する方法について話すセッションなので、興味があったので申し込みました。

セッションの概要紹介

このチョークトークでは、単一リージョンでよく構成された近代化されたアプリケーションをリージョン障害に対応するためのマルチリージョンアプリケーションアーキテクチャとは何か、マルチリージョンActive-Activeアーキテクチャに改善していく方法についてホワイトボードを利用して説明しました。

クラウドプロバイダ(CSP)が提供するサービスは、リージョン全体の障害が発生する可能性があり、実際に頻繁に発生するわけではありませんが、このような障害が発生し、データ損失やサービス対応ができない場合、企業は法的責任やコンプライアンス違反、深刻な金銭的損害を被る可能性があります。このような避けられないリスクを軽減するためには、マルチリジョンアーキテクチャーが必要です。

レジリエンスを理解するには、レジリエンスの3つの側面とそれらがどのように関連しているかを理解することが重要です。高可用性は、アプリケーション本番環境で直面する障害に対して回復力があること、災害復旧は、自然災害、主要な技術的問題、データやリソースの削除(主にヒューマンエラー)に対する回復力、そして継続的改善は、継続的な回復力を持つために失敗を予測・監視・対応し、失敗から継続的に学習することです。

災害復旧には様々なパターンがあり、RTO/RPOを考慮してActive/Passiveで構成することもできますし、ミッションクリティカルなサービスの復元力と高可用性を維持するためにActive-Activeで構成することもできます。

このアーキテクチャは、シングルリージョン・アプリケーション・アーキテクチャとしてAmazon API Gateway、Amazon DynamoDB、AWS Lambdaを使用するアーキテクチャで、そのアーキテクチャを全体的なレジリエンス状態を改善し、RTOとRPOを下げるマルチリージョンActive-Activeマイクロサービスベースのパターンに変更します。

上の写真はシングルリージョンのアプリケーションアーキテクチャを表示した図で、下はマルチリージョン(US-EAST-1, US-WEST-2)アプリケーションに変更したアーキテクチャです。Route53のHealth Checkと地理ベースのルーティングを使用し、リージョン間のデータ複製も利用しますが、APIリクエストの応答にリージョンIDをメタデータの一部として提供してくれるので、他のリージョンで復旧が必要なときに備えることができます。

セッションを終えて

シングルリージョンに構成されたアプリケーションアーキテクチャをマルチリージョンに弾力的に構成することで、直面している様々な問題をどのように解決するのかについてホワイトボードを継続的に改善しましたが、思ったより考えなければならない部分も多く、難しいと感じ、もう少し勉強が必要だと感じたセッションでした。