Amazon Web Services ブログ
金融リファレンスアーキテクチャ日本版 v1.3アップデートのお知らせ
「金融リファレンスアーキテクチャ日本版」は、金融で求められるセキュリティと可用性に関するベストプラクティスを提供するフレームワークとして 2022 年 10 月に正式版として発表し、多くのお客様にご利用いただいております。 この度、皆様からいただいたご意見を踏まえ、レジリエンス関連の機能強化を行ったv1.3を公開しました。変更点の概要は以下の通りです。
[v1.3での主な変更点]
これらのアップデートについて解説していきます。
1. マルチリージョンアプリケーションのレジリエンス強化
1-1. Step Functionsによるリージョンの自動フェールオーバー
金融リファレンスアーキテクチャ勘定系ワークロードでのマルチリージョンの構成
金融リファレンスアーキテクチャの勘定系ワークロードは、銀行の各種業務とその元帳のDBを管理する勘定系業務に対するリファレンスアーキテクチャーです。このアーキテクチャにあわせたオンライントランザクション処理のサンプルアプリケーションが含まれています。銀行勘定系をターゲットとしていますが、汎用的なトランザクション処理に向けたものとなりますので、他の同様なワークロードにも適用可能です。
このアーキテクチャではアプリケーションをマルチAZ構成にすることで通常故障から保護しています。さらに、東京と大阪のマルチリージョンで Active – Standby 構成としています。東京リージョン全体が影響を受けるような何等かの障害が発生しても、大阪リージョンへフェイルオーバーすることで、サービスを提供し続けることが出来るようになっています。
このワークロードの上で稼働するアプリケーションとしては、トランザクション管理、アトミック性、排他制御などが求められるため、メイン DB としてRDBMSであるAurora Global Database、アプリケーションのステート管理用 DB として DynamoDB を使用しています。また、アプリケーションはECS上で東京、大阪の両リージョンで常時起動しており、Route 53 ARCを利用して利用リージョンのアプリケーションへトラフィック制御を行っています。
リージョン切り替えのフローと自動化
東京リージョンの障害を想定してのフェイルオーバーと収束後の切り戻しを想定したフェイルバック、2つの切り替えフローを準備しています。
フェイルオーバーの流れを示したのが以下の図です。元帳にあたるAuroraDBのデータ不整合を避けるため、まずStep1として東京リージョンのアプリケーションを閉塞しデータベースの更新を停止します。これはDynamDB Global Tablesに持つ閉塞フラグを利用します。その後Step2としてクライアントのリクエストをDNSにより大阪リージョンへルーティングします。これはTTLを加味してAurora Global Databaseの切り替え中に東京へのルーティング情報が残らない状態にするため、また障害によるエラーではなく大阪リージョンで稼動するアプリケーションにルーティングすることで適切に閉塞のステータスを返却するためです。その後Step3としてAurora Global Databaseを使ってレプリケーションされている大阪リージョンのBDに切り替えます。切り替えが完了したのち、最後にStep4として大阪リージョンのアプリケーション閉塞を解除します。この一連のフェイルオーバーは約5分間で完了します。
フェイルオーバとフェイルバックのフローはStep Functionsを使って以下のようなステートマシンのフローで自動化しています。自動化においては各々のStepの間に、適切な切り替えのための待ち時間や確認処理を入れることが重要です。詳細は以下の図で示しています。
1-2. Synthetics Canaryによるアプリケーションの外形監視
ミッションクリティカルなアプリケーションにおいて、外形監視はユーザー体験を直接反映し、システム全体の健全性を把握するために重要です。システム視点での内部監視では検出が難しい複雑な障害やネットワーク遅延を早期に発見し、迅速な対応を可能にします。また、サービスレベル契約(SLA)の遵守確認や、ビジネスインパクトの最小化にも寄与します。
今回のアップデートでは、AWS CloudWatch Synthetics Canaryを活用して、アプリケーションの外形監視のサンプル実装を提供します。このアプリケーションは残高照会、入金処理、出金処理のAPIを通じてトランザクションを処理します。大阪リージョンに設定したCanaryを用いて東京リージョンで稼働するアプリケーションに対して継続的に疑似トランザクションを実行させて、APIの応答メッセージの正常性と応答遅延を継続的にチェックしています。このサンプルによって、問題が発生した際に迅速に対応でき、サービスの信頼性を高めることができます。
1-3. OpenTelemetryの導入 (AWS X-Ray)
サンプルアプリケーションの外形監視に加え、AWS X-Rayを利用して、マイクロサービス間の遅延やエラー、失敗をトレースする仕組みを導入しました。このアプリケーションは残高照会、入金処理、出金処理のAPIを提供し、それぞれがマイクロサービスで構成されています。X-Rayを用いることで、各リクエストのフローを詳細に可視化し、特定のサービスでのパフォーマンス低下やエラー箇所を迅速に特定可能です。このトレース機能により、問題発生時の迅速なトラブルシューティングと、サービス全体の信頼性向上が実現されます。
2. ランサムウェア対策の追加
ランサムウェアとは
ランサムウェアとは「身代金(ransom、ランサム)を支払わないと被害者のデータを公開したり、ビジネスに不可欠な情報へのアクセスを遮断するマルウェアの一種のこと」です。ランサムウェアによる被害は、IPA (情報セキュリティ推進機構) が公表している 情報セキュリティ10大脅威 2024 の組織向け脅威の1位として挙げられており、組織にとって重大なセキュリティ上の脅威となっています。
ランサムウェアによる被害を防ぐには、マルウェアの侵入防止や攻撃者によるデータへのアクセス防止、データアクセスの失敗を攻撃の予兆として検知するなどの対策が考えられますが、ここでは実際に被害を受けてしまった場合の復旧に備えたバックアップ取得に関する対策についてご紹介します。
金融リファレンスアーキテクチャ勘定系ワークロードでの対策
勘定系ワークロードは永続化データに、メイン DB として Aurora Global Database、アプリケーションのステート管理用 DB として DynamoDB を使用しており、これらのデータベースを対象にランサムウェア攻撃を受けた際に復旧可能なようにAWS Backupでバックアップを取得します。
AWS Backupは、取得したバックアップをバックアップボールトとして管理します。バックアップボールトには、取得したバックアップを保護するためにボールトロックをオプションで指定することができ、2種類のロックモードを提供しています。ガバナンスモードでは、ボールトに格納されたリカバリポイントは特定の IAM 権限でのみ削除可能なロックモードとなっており、コンプライアンスモードはデータ保持期間が終了するまでボールトとリカバリポイントをルートユーザー(アカウント所有者)や AWS を含めていかなるユーザーも変更、削除することができなくなります。詳しくはこちらをご覧ください。
ボールトロックはこのようにリカバリポイントを保護する機能を提供するため、ランサムウェア対策として利用することができます。金融リファレンスアーキテクチャ勘定系ワークロードでは、Aurora Global Database と DynamoDB テーブルを対象に AWS Backup でバックアップを取得し、ボールトロックを指定したバックアップボールトへと保管しています。ただしサンプルアプリケーションであることから、十分な IAM 権限を持つユーザーであればデータ削除が可能であるガバナンスモードでの実装としています。コンプライアンスモードに変更することで、バックアップボールトに格納されたリカバリポイントを一定期間、特権ユーザーでも削除できない状態とすることが可能です。
まとめ
金融リファレンスアーキテクチャ日本版の全てのコンテンツとコードは、パブリックの GitHub リポジトリ から参照でき、Git リポジトリとしてローカル環境にクローンすることもできます。フィードバックや質問については Issue として GitHub サイト上に登録いただけます。また、執筆者に直接ご連絡頂いても構いません。ご利用される皆様からのニーズや意見に基づいて今後の改善方針を決めていきたいと考えておりますので、ご質問やフィードバックをお待ちしております。
金融リファレンスアーキテクチャ日本版v1.3での変更点の詳細についてはこちらを参照下さい。
なお、本ブログ記事は AWSのソリューションアーキテクトである根本裕規、疋田洋一、深森広英で執筆いたしました。
謝辞
アマゾン ウェブ サービス ジャパン合同会社 金融グループ/グローバルフィナンシャルサービス/プロトタイピングチームの下記メンバーで今回の開発を行いました。
根本裕規、疋田洋一、吉澤稔、深森広英、友岡雅志