この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、コンサル部の鈴木(純)です。
AWS Summit tokyo 2023の「金融機関に求められるレジリエンスの AWS 環境での実装手法」のセッションに参加してきましたのでレポートします。
セッション概要
【スピーカー】 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックソリューション部 ソリューションアーキテクト
畑 大作
金融業界全体でセキュリティと同時に信頼性やレジリエンスの重要性が高まっています。より多くの金融アプリケーションを安心してAWS上で稼働していただくためにAWSは常に改善に取り組んでいます。その上で、信頼性の高い金融サービスを提供するにはレジリエントなアーキテクチャー設計が必要になります。本セッションでは、AWS環境においてレジリエンスを高める設計方法や事例をご紹介します。
オンデマンド配信
AWS Summit Tokyo 2023のセッションの多くは下記期間でオンデマンド配信されています。見逃してしまった方は是非この期間にご視聴ください。
2023年5月22日12:00 〜 2023年6月23日19:00
オンデマンド配信をご視聴するためには下記ページよりご登録していただく必要があります。
登録済みの方は、本セッションのオンデマンド配信を下記URLにてご覧いただけます。
https://jpsummit.awsevents.com/public/session/view/568
セッションレポート
本セッションについて
- 内容
- 金融機関など高いレジリエンスが求められるシステムに関しての実装方法を事例を併せて紹介
- 対象
- 高いレジリエンスに関心があるアーキテクト、エンジニアの方
- 目的
- レジリエンスを高める方法の1つとしてマルチリージョンアーキテクチャを整理し、取り組み例として事例を示す
### アジェンダ
- レジリエンスの概要とクラウドにおけるレジリエンス
- レジリエンスを高めるAWSアーキテクチャ
- お客様の取り組み事例から見るレジリエンスを高める実装方法
- まとめ
1. レジリエンスの概要とクラウドにおけるレジリエンス
- レジリエンスとは
- 障害から回復する能力のこと
- 高可用性
- ディザスタリカバリ
- クラウドにおけるレジリエンス
- クラウド上のレジリエンス
- お客様の責任範囲
- クラウドそのもののレジリエンス
- AWSの責任範囲
- レジリエンスのAWS責任共有モデル
- 数多くの要素があるため、本セッションではアーキテクチャのに関するものにフォーカスを当てて解説
2. レジリエンスを高めるAWSアーキテクチャ
- マルチAZとマルチリージョン
- マルチAZによる高可用性
- EC2に障害が発生した場合、片方のAZに通信が割り振られ多くの障害を回避できる
- ネットワーク
- ホスト障害等
- これだけで全てを回避できるわけではない
- 対応できないもの
- オペレーションミス
- リージョン障害等
- クラウドにおける業務中断シナリオ
- マルチAZでは対応できない障害
- システムに対し重大な影響がある場合、マルチリージョン構成が必要
- マルチリージョンアーキテクチャのパターン
- 様々なパターンがあるため、ここで整理
- Active/passive
- 障害が起きた際にフェイルオーバーする
- ユースケース
- DRのためのリージョンフェイルオーバー/フェイルバック
- 規制上の要求
- 設計上の考慮点
- 可観測性
- ルーティング戦略
- フェイルオーバー・フェイルバック手順
- Active/active
- ユースケース
- 非常に高い可用性
- パフォーマンスは遅延に敏感
- 低いRTO/RPO
- 重要な設計上の考慮点
- 可観測性とリージョン切り替え戦略
- ルーティング戦略
- データストアの同期方式
- Active/activeはさらに4つのパターンに細分化
-
- リージョン分割
- クライアントごとに担当リージョンを完全に分離
- Route53でリージョンごとにトラフィックを国や地域で振り分ける
- 海外拠点の拡大などで検討
- 高い可用性は求められないケースで有用
-
- Single witer/Multiple readers
- ユースケース
- 遅延に影響を受けやすいワークロード
- 結果整合性
- Read-heavyなワークロード
-
- Dual writes
- ユースケース
- Read-heavyなワークロード
- マーケットデータ配信などには向いている
- 設計上の考慮点
- 冪等性
- クライアントサイドでのデータ原子性を管理
-
- Multi writers/Multiple readers
- ユースケース
- 遅延に影響を受けやすいワークロード
- 結果整合性
- Read/write-heavyなワークロード
- 設計上の考慮点
- コンフリクトの解決
- 書き込み後の読み取り一貫性
-
- マルチリージョンアーキテクチャの整理
- 実際にマルチリージョン構成を実装する際は、どのパターンが適切か比較する
- ルーティング方式
- Amazon Route53
- 名前解決方式
- AWS Global Accelerator
- 名前解決方式
- クライアントは常に名前解決経てリージョンのアクセス
- 考慮点
- キャッシュの保持する期間でユーザーに影響が出るケースもある
- リージョン障害でフェイルオーバーでリージョンを切り替えた時
- クライアント側はキャッシュが残っている場合、元のリージョンにアクセスしてしまう可能性がある
- クライアント側に依存してしまう部分もあるので考慮が必要
- Anycast IP方式
- クライアントは2つの固定Public IPで認識しリージョンにアクセス
- Traffic Dialの設定によって振り分け
- 名前解決とは違いキャッシュに左右されない
- 全てのクライアントは静的IPに対してアクセス
- DNSキャッシュに左右されずにフェイルオーバーが可能
- 設計段階でAWS Global Acceleratorを採用するか検討
3. お客様の取り組み事例から見るレジリエンスを高める実装手法
- 取り組みの背景 原稿構成と課題
- CARDNET様
- サービス概要
- インターネットでのクレジットカード決済を行う加盟店向けに、データを変換してカード会社へ電文を仲介する
- 一時的なピーク対応のためAWSを採用
- As Is：シングルリージョンマルチAZ
- AZ単位の障害には対応可能
- 元々RPO/RTOが長めに設定されていた
- バックアップリストア
- 課題
- リージョナルサービスの障害で、マルチAZでは対応できないイベントが発生
- スモールスタートから加盟店獲得のために可用性向上が求められてきた
- DRが求められてきた
- 解決へのアプローチ
- システム特性
- データ変換するGateway機能に特化
- 中継のみを行うためデータストアを持たない
- トランザクション履歴のみを保持
- SQSでステートレスに処理
- マルチリージョンアーキテクチャパターンの選定
- マルチリージョンパターン Active/active(Dual write)を採用
- ルーティングはAnycast IP方式を採用
- To Be マルチリージョンAct-Act
- 東京リージョンと大阪リージョンで同じ構成を実装
- トランザクションを50:50で振り分け
- リージョン間は完全に独立して処理
- リージョン障害
- ヘルスチェック機能で自動で切り離し
- 正常なリージョンで処理を継続
- データ同期
- トランザクション履歴データのみバックアップを相互に取得
- Auroraでクロスリージョンレプリケーション
- 暗号・複合化の暗号鍵
- DynamoDBのグローバルテーブルに配置
- クロスリージョンレプリケーション
- オンプレミスとの接続
- DXによる接続
- DXロケーションをリージョンで分割
- キャリアも分けている
- DX接続通信の異常時はリージョン障害として扱いトランザクションの振り分けを変更
- 監視と切り替え
- ALBによる中継サーバーのヘルスチェック
- API Gatewayで業務トランザクションの5xxエラー数をカウント
- 閾値に達した場合にリージョンの切り離しを自動化
- 障害時のみではなく、保守による業務停止にも対応可能
- 設計ポイントのまとめ1
- マルチリージョンタイプ
- 業務としてデータストア不要
- ルーティング方式
- 加盟店の名前解決キャッシュ設定の考慮が不要であるAnycast IP方式
- データ同期
- 業務データ以外のデータストア同期
- Aurora Global Database、DynamoDB Global Tablesによる同期
- 設計ポイントのまとめ2
- オンプレミスとのネットワーク接続
- 回線、DXロケーション、NWキャリアの冗長化
- 監視と切り替え
- AWSサービスのヘルスチェック
- アプリケーション、外形監視によるエンドツーエンドの複数地点の監視
- 閾値に達した場合のリージョン切り離しの自動化
- これによって高いレベルでのRPO/RTOを実現できた
4. まとめ
- 業務の回復力を高めるレジリエンスは非常に重要視されている
- 金融機関などマルチAZアーキテクチャよりさらに高いレジリエンシーが求められる場合は、マルチリージョンアーキテクチャは有効な選択肢
- マルチリージョンアーキテクチャは大きく2つのアーキテクチャに整理できる
- Active/activeの採用も進んでいる
- 決済ワークロード以外での実装例をさらに知りたい方
- 金融リファレンスアーキテクチャ日本版を参照
- FSIブース(B2-44,B2-45)も会場内にあるのできてね
感想
マルチリージョン構成のアーキテクチャパターンを掘り下げて説明頂きましたが、とてもボリュームがあり聞き応えのあるセッションでした。 特にActive/activeのパターンでは４パターンあり、システムの特性に合わせて採用するパターンを検討する部分についてはしっかりと理解しておきたい内容です。
CARDNET様の事例説明ではマルチリージョンアーキテクチャの検討から、そのほかネットワークやデータ同期方法・監視のポイントまで解説がありました。Active/activeでマルチリージョンを検討する場合は絶対に参考にしたい内容盛りだくさんです。
特にDX部分はロケーションとNWキャリアまで冗長化しており、異常時には自動で切り替えられるように構築している部分は勉強になりました。
金融機関におけるマルチリージョンのアーキテクチャ事例はあまり数がなく学びが多いセッションだと思いますので、是非興味のある方は動画公開後に視聴してみてください。 最後に説明があった金融リファレンスアーキテクチャ 日本版も合わせて読んでみてくださいね。
37
