レジリエンスライフサイクルで進化する – ミッションクリティカル[勘定系] ワークロード（金融リファレンスアーキテクチャ日本版 2025）

はじめに

「AWS 金融リファレンスアーキテクチャ 日本版」は金融機関の厳格な要件に応えるためのリファレンス実装として 2022 年 10 月に初版をリリースして以来、継続的に進化を続けています。GitHub で公開されている本アーキテクチャは、金融機関が AWS 上でセキュアかつレジリエントなシステム構築を行うための実装例として活用いただいています。

図1：AWS 金融リファレンスアーキテクチャ日本版の概要図

勘定系ワークロードについて

金融システムの中でも特に勘定系システムは、預金、為替、融資などの中核業務を担う存在です。そのため、金融リファレンスアーキテクチャ日本版の勘定系ワークロードではミッションクリティカルなシステムに必要な高可用性を実現するためのアーキテクチャを提示しています。

この度、勘定系ワークロードに AWS のレジリエンスライフサイクルフレームワークに基づいた機能追加を行いました。リエンスライフサイクルフレームワークは、「目標設定」「設計と実装」「評価とテスト」「運用」「対応と学習」という5つのステージで構成される継続的なプロセスであり、アプリケーションの回復力を段階的に向上させるためのガイドラインです。

今回のアップデート（v1.6）では、このフレームワークに沿って勘定系ワークロードの可用性と回復力を高める以下の3つの機能を追加しました：

本ブログでは、これらの機能について詳しく解説します。

1. Amazon CloudWatch Synthetics Canary × AWS Step Functions で構築する、東京リージョンから大阪リージョンへの自動切替

従来の勘定系ワークロードのサンプルアプリケーションでは、災害発生時の東京リージョンから大阪リージョンへの切り替えは、人による判断後に手動オペレーションで実施する前提でした。今回のアップデートでは、より迅速なサービス復旧を優先するユースケースを想定し、外形監視の導入により人による判断を介さない自動フェイルオーバー機能を追加しました。

自動フェイルオーバーはアプリケーションに対して Synthetics Canary による外形監視でアプリケーションの正常性を判断しています。切り替えの自動化にあたっては、監視の誤検知による意図しないフェイルオーバーを防ぐため、2 つのリージョンから外形監視を行い、両リージョンの外形監視が同時に一定期間失敗した場合に、自動フェイルオーバーを実行する仕組みを採用しました。これにより特定のリージョン間の通信障害による意図しないフェイルオーバーの発生を回避しています。

具体的な処理フローは次のようになります。

図2：フェイルオーバーの処理フロー

サンプルアプリケーションでは仕組みのわかりやすさを優先し、短時間で自動フェイルオーバーする設定値を採用しました。自動フェイルオーバーの閾値はシステムに依存するものであり、要件に応じた適切な値の設計が必要です。運用要件によっては、自動フェイルオーバーは行わずに監視へ障害通知のみ行い、人による判断後に手動でのフェイルオーバーが現実的な設計となるでしょう。

2. 勘定元帳データベースとして Amazon Aurora を選択肢に追加

勘定系システムにおいてデータの整合性確保と迅速な災害復旧は最重要課題です。Amazon Aurora PostgreSQL の Global Database を使用すると、リージョン間の非同期レプリケーションにより、優れた RPO と数分程度でのリージョンフェイルオーバーを迅速に実現することができます。一方で、金融機関の中には「RPO をさらに短縮したい」「リージョン障害時のサービス復旧をより迅速に実現したい」「複数のリージョンを Active-Active 構成で運用したい」というニーズもあります。

今回の勘定系ワークロードのアップデートでは、2024 年に発表された Aurora DSQL を勘定系ワークロードの新たな選択肢として追加しました。Aurora DSQL は、マルチリージョンでの同期レプリケーションにより RPO をゼロにするとともに、リージョン障害時でも即座に他のリージョンでサービスを継続できます。従来の Aurora PostgreSQL は引き続き有力な選択肢ですが、お客様の要件によっては Aurora DSQL も新たな選択肢として検討いただくことができます。

なお、今回のアップデートはドキュメントのみの更新となります。Aurora DSQL に対応した CDK コードの実装は今後のリリースを予定しています。

図3：Aurora DSQL の場合のリファレンスアーキテクチャ

Aurora DSQL の最大の特徴は、マルチリージョンでの同期レプリケーションによる強力なデータ整合性です。Aurora PostgreSQL の Global Database では非同期レプリケーションのため若干の RPO が発生しますが、Aurora DSQL では同期レプリケーションにより RPO をゼロにすることができます。これは勘定系システムにおける重要なトランザクションデータの損失リスクを大幅に低減します。

また、Aurora DSQL は Active-Active 構成をサポートしており、複数のリージョンで同時に読み書き処理を実行できます。これにより、リージョン障害が発生した場合でも、他のリージョンで即座にサービスを継続することが可能です。従来のプライマリ・セカンダリ構成では、フェイルオーバー処理に数分を要していましたが、Aurora DSQL では障害発生時の切り替え時間を大幅に短縮できます。

Aurora DSQL の導入にあたっては、いくつかの設計上の考慮事項があります。特に Aurora DSQL は楽観的同時実行制御を採用しているため、高い同時実行性を持つアプリケーションでは、トランザクションのコミット時にシリアライゼーションエラーが発生する可能性があります。このため、アプリケーション側でのリトライ処理の実装が重要です。

より詳細な解説は GitHub リポジトリのドキュメントを参照してください。

3. Amazon CloudWatch Application Signals の導入によるマイクロサービスのオブザーバビリティ強化

勘定系ワークロードのサンプルアプリケーションは、Balance Service（口座残高管理）、Count Service（取引回数管理）、Transaction Service（取引処理）、Transaction Worker（非同期処理のオーケストレーション）といった複数のマイクロサービスで構成されています。これらのサービスが相互に連携する分散システムでは、データベースなど個々のインフラレベルの監視だけではサービス全体の稼働状況を把握することが困難です。これまでの勘定系ワークロードでは AWS Distro for OpenTelemetry (ADOT) による計測の仕組みは実装されており、マイクロサービスが稼働するコンテナからテレメトリ情報を送信することは出来ていたものの、その情報を使ってサービス間の依存関係や影響範囲を可視化するためにはメトリクスの関連付けやダッシュボードの設計・構築をゼロから自分で行う必要がありました。

そこで今回のアップデートでは Amazon CloudWatch Application Signals を導入することで、マイクロサービス全体の可観測性を向上させました。CloudWatch Application Signals は、ADOT からアプリケーションのメトリクスやトレースを自動収集し、「アプリケーションの可用性とパフォーマンスを自動で見える化する」機能です。言わば、ADOT は観測の“センサー”で、CloudWatch Application Signals はそのデータを使って“健康診断レポート”を作る仕組みです。最も重要な改善は、サービス間の依存関係が自動的に可視化されることです。例えば、Transaction Service が Balance Service を呼び出す際の応答時間やエラー率がサービスマップ上でリアルタイムに表示されます。これにより、障害発生時に「どのサービスが影響を受けているか」「根本原因はどこにあるか」を迅速に特定できるようになりました。以下は可視化の例（各マイクロサービスの Latency）となります。

図4：各マイクロサービスの Latency の可視化

さらに、CloudWatch Application Signals が提供する SLI (Service Level Indicator) と SLO (Service Level Objective) ベースのマネジメント機能、標準ダッシュボードにより、ビジネス観点での健全性を把握することも可能になりました。従来の CPU 使用率やメモリ使用率といったインフラメトリクスに加えて、「取引処理の成功率」「口座残高照会の応答時間」といったビジネス価値に直結する指標を中心とした監視が可能になりました。これは金融サービスにとって特に重要で、システムの技術的な正常性とビジネス的な正常性を統合して評価できます。

分散トレーシングの強化も大きなメリットです。一つの取引リクエストが複数のマイクロサービスを経由する際、そのリクエストの完全なライフサイクルを追跡できます。例えば、振込処理で Transaction Service → Balance Service → Count Service という流れで処理される場合、各サービスでの処理時間、待機時間、エラーの発生箇所を一つのトレースで確認できます。これにより、パフォーマンスのボトルネックや障害の根本原因を特定する時間が大幅に短縮されます。

実際に運用の現場でご利用いただく際には、追加でダッシュボードを制作し、一目で各サービス、サービス間、もしくはサービス全体の稼働状況がわかるようにすることも多いでしょう。これらは運用体制など個別の環境に合わせて用意する必要がありますが、その構築の参考となるよう、サンプルとして簡易なダッシュボードがデプロイされるようにしてあります。

実装詳細は GitHub リポジトリをご確認ください。

まとめ

今回ご紹介した勘定系ワークロードの 3 つの機能強化は、AWS のレジリエンスライフサイクルフレームワークに沿った継続的な改善の一環です。

金融リファレンスアーキテクチャはオープンプロジェクトとして GitHub で公開しています。GitHub にはサンプルアプリケーションや自動フェイルオーバー機能、監視設定などの実装コードやドキュメントがすべて含まれています。これらはそのままデプロイして即座に動作確認をしていただくことができるため、金融機関の皆様がシステムを構築する際の参考としてご活用いただくことが可能です。

このリファレンスアーキテクチャを活用し、より安全で回復力の高いシステム構築に取り組まれることを願っています。また、より良い金融リファレンスアーキテクチャの発展に向けて、皆様からのフィードバックもお待ちしております。

本ブログ記事は、AWS のソリューションアーキテクト 嶋田朱里、疋田洋一、小野卓人、深森広英 が執筆いたしました。