この記事の目的

「金融リファレンスアーキテクチャ日本版」の紹介
「金融リファレンスアーキテクチャ日本版」の勘定系ワークロードをローカル端末からデプロイ
AWS Fault Injection Service(AWS FIS)を利用したフェイルオーバーの検証

はじめに

初めまして NTT ドコモ第二プロダクトデザイン部の森田康平です。
普段の業務では d 払いをはじめとした金融系サービスのシステム基盤を担当しています。

最近、福島銀行が国内で初めて Amazon Web Services(AWS) のクラウド上で勘定系のシステムを稼働させたという記事を拝見しました。
aws.amazon.com

金融業界において、システムの安定稼働はお客様から信頼を得るために必要不可欠です。
特に勘定系システムのような基幹システムは、安定稼働のために高い可用性と耐障害性が求められます。

福島銀行の事例では、可用性と耐障害性を確保するために「金融リファレンスアーキテクチャ日本版」と 「AWS Fault Injection Service(AWS FIS)」を活用して、レジリエンシーの高度化を実現されたそうです。

本記事では、福島銀行の事例を参考に金融リファレンスアーキテクチャ日本版と AWS FIS を使って、金融システムに求められるレジリエンスを体験してみます。

「金融リファレンスアーキテクチャ日本版」とは

金融リファレンスアーキテクチャ日本版は AWS ソリューションアーキテクトが日本の金融業界の利用者に向けて開発したフレームワークで Github 上で公開されています。

github.com

金融リファレンスアーキテクチャ日本版では、金融システムのガイドラインであるFISC 安全対策基準に準拠するベストプラクティスが提供されており、金融グレードのセキュリティとレジリエンスを実現する事ができます。
また、以下 7 つのサンプルアプリケーションを例にベストプラクティスの実装方法とその IaC テンプレート(CDK テンプレート)が提供されており、利用者の環境で実際にデプロイして動作を確認する事ができます。

勘定系システム
顧客チャネル
オープン API
マーケットデータ
データ分析プラットフォーム
メインフレーム連携（CDK テンプレート提供なし）
ハイブリッド（CDK テンプレート提供なし）

今回は勘定系システムのサンプルアプリケーションをデプロイして、動作を確認します。

勘定系ワークロードのデプロイ

金融リファレンスアーキテクチャ日本版ではワークショップが提供されており、デプロイ方法が詳しく解説されています。
しかし、ワークショップは AWS Cloud9 の利用を前提とした手順であるため、本記事ではローカル端末からのデプロイ方法を記載します。

catalog.us-east-1.prod.workshops.aws

アーキテクチャの確認

今回デプロイする勘定系ワークロードのアーキテクチャ図は以下の通りです。
※ 構成がわかりやすいように詳細は省き、シンプルに記載しています。

開発環境(IDE)の準備

デプロイを開始する間にまずはローカル端末に開発環境(IDE)を準備します。

ランタイムのインストール

こちらを参考にランタイムをインストールします。

以下のランタイムを使用します。各 OS ごとの手順に従いインストールしてください。

Node.js (>= 18.17.1)

npm (>= 10.1.0)

Git

CDK(>= v2.144.0)

npm の最新バージョンは以下のようにしてインストールしてください。
npm install -g npm

Visual Studio Code のセットアップ

こちらを参考に Visual Studio Code をセットアップします。
※ "VSCode Extension のインストール" と "VSCode Extension の設定" はお好みで実施してください。

Visual Studio Code よりインストールしてください。

macOS の場合、 Running Visual Studio Code on macOS の手順に従い、 code コマンドがシェルから実行できるように設定してください。Windows では自動で設定されます。

Docker のインストール

マイクロサービスサンプルアプリケーションを利用するには、ローカル端末で docker デーモンが起動している必要があります。
ローカル端末で Docrker が使えるように Docker Desktop 等をインストールしてください。
www.docker.com

AWS CLI へのアクセス認証情報の設定

こちらを参考に AWS CLI へのアクセス認証情報を設定してください。
認証設定では"IAM"または"IAM Identity Center"による認証情報が必要になります。
ベストプラクティスでは "IAM Identity Center ユーザー"の利用が推奨されていますが、環境によっては IAM Identity Center が利用できない場合もあります。自身の環境や利用状況に合わせて適切な設定方法を選択してください。

リポジトリの準備

Github からリポジトリを clone

ローカル端末のターミナルで以下のコマンドを実行します。

git clone https://github.com/aws-samples/baseline-environment-on-aws-for-financial-services-institute.git
cd ./baseline-environment-on-aws-for-financial-services-institute

npm パッケージのインストール

ローカル端末のターミナルで以下のコマンドを実行します。

npm ci
cd usecases/guest-core-banking-sample

CDK パラメータファイルの設定

clone したリポジトリを開き、以下のパラメータファイルの変更を行います。
※ 変更後は必ず保存することを忘れずに！

CDK パラメータファイル：usecases/guest-core-banking-sample/bin/parameter.ts

デプロイ設定

54 行目の Dev 環境のパラメータを設定します。

設定する項目	入力する値	項目の説明
notifyEmail	自分のメールアドレス	Amazon SNS から通知が送られるメールアドレス

// Parameter for Dev - Anonymous account & region
export const DevParameter: StackParameter = {
  envName: "Development",
  account: process.env.CDK_DEFAULT_ACCOUNT,
  notifyEmail: "[email protected]",
  dbUser: "dbadmin",
  hostedZoneName: "example.com",
  primary: {
    region: "ap-northeast-1",
    regionCidr: "10.100.0.0/16",
    vpcCidr: "10.100.0.0/20",
    tgwAsn: 64512,
  },
  secondary: {
    region: "ap-northeast-3",
    regionCidr: "10.101.0.0/16",
    vpcCidr: "10.101.0.0/20",
    tgwAsn: 64513,
  },
};

アプリケーション設定

44 行目のマルチリージョンマイクロサービス・アプリケーションの設定を行います。

設定する項目	入力する値	項目の説明
deploy	true	マルチリージョンの動作確認を行う

//マルチリージョン マイクロサービス・アプリケーションの設定
export const SampleMultiRegionAppParameter = {
  //デプロイする場合は true に指定
  deploy: true,
  //実行確認用のクライアントを配置するVPCのCIDR
  appClientVpcCidr: "10.100.16.0/24",
};

CDK によるデプロイ

IDE の準備とパラメータの修正が完了したので、デプロイを行います。

CDK ブートストラップ

ローカル端末のターミナルで以下のコマンドを実行します。

npx cdk bootstrap

※ 既に東京と大阪とバージニア北部リージョンに CDK Toolkit が存在する場合は実行不要です。
※ AWS CLI の認証情報にデフォルト以外のプロファイルを使用している場合は --profile 自分のプロファイル名を付けて実行してください。

CDK デプロイ

ローカル端末のターミナルで以下のコマンドを実行します。

npx cdk deploy "*Dev" --require-approval never

※ AWS CLI の認証情報にデフォルト以外のプロファイルを使用している場合は --profile 自分のプロファイル名を付けて実行してください。

私の環境では初回デプロイ時に以下のエラーが発生しました。
Resource handler returned message: "Invalid request provided: CreateService error: Unable to assume the service linked role. Please verify that the ECS service linked role exists.
これは ECS の ServiceRole が存在しないことで発生するエラーで、AWS アカウントで ECS を初めて利用する際に必ず発生するエラーになります。( ECS 以外のサービスでも同様のエラーが発生する事があります。)
cdk destroy コマンドや CloudFormation ページからスタックを削除し、再度 CDK デプロイを実行することでエラーは解消できます。スタックの削除に時間が掛かるので、事前に ECS を利用して ServiceRole を作成しておくことを推奨します。

Transit Gateway の設定

こちらを参照し、Transit Gateway の設定を行います。 BLEAFSI-CoreBanking-secondary-Devのデプロイ完了後にコマンドが表示されるので、1 つずつコマンドを実行します。

Outputs:
BLEAFSI-CoreBanking-secondary-Dev.CLIforTGWpeeringacceptance = aws ec2 accept-transit-gateway-peering-attachment --region ap-northeast-1 --transit-gateway-attachment-id tgw-attach-008xxxx --profile ct-guest-sso
BLEAFSI-CoreBanking-secondary-Dev.CLIforaddingTGWrouteinprimaryregion = aws ec2 create-transit-gateway-route --region ap-northeast-1 --destination-cidr-block 10.101.0.0/16 --transit-gateway-route-table-id tgw-rtb-069xxx --transit-gateway-attachment-id tgw-attach-008xxx --profile ct-guest-sso
BLEAFSI-CoreBanking-secondary-Dev.CLIforaddingTGWrouteinsecondaryregion = aws ec2 create-transit-gateway-route --region ap-northeast-3 --destination-cidr-block 10.100.0.0/16 --transit-gateway-route-table-id tgw-rtb-094xxx --transit-gateway-attachment-id tgw-attach-008xxx --profile ct-guest-sso

Transit Gateway のピアリング承認

ローカル端末のターミナルで以下のコマンドを実行します。

aws ec2 accept-transit-gateway-peering-attachment ...

※ コマンドの内容は環境ごとに異なるため自身のターミナルに表示されたコマンドを参照してください。
※ 末尾の--profile ct-guest-ssoは自分のプロファイル名に変更して実行してください。
※ アクセプトが有効になるには少し時間がかかるため、2-3 分待ってから次のコマンドを実行してください。

主リージョンから副リージョンへのルート追加

ローカル端末のターミナルで以下のコマンドを実行します。

aws ec2 create-transit-gateway-route ...

※ コマンドの内容は環境ごとに異なるため自身のターミナルに表示されたコマンドを参照してください。
※ 末尾の--profile ct-guest-ssoは自分のプロファイル名に変更して実行してください。

副リージョンから主リージョンへのルート追加

ローカル端末のターミナルで以下のコマンドを実行します。

aws ec2 create-transit-gateway-route ...

アプリケーション用データベースのセットアップ

こちらを参照し、サンプルアプリケーションのセットアップを行います。 BLEAFSI-CoreBanking-primary-Devのデプロイ完了後に以下の情報が表示されます。

Outputs:
BLEAFSI-CoreBanking-primary-Dev.SampleAppClientInstanceBastionHostIdXxx = i-0XXXX
BLEAFSI-CoreBanking-primary-Dev.SampleMultiRegionAppBalanceMigrationCommand6ADC0CF6 = aws ecs run-task ...
BLEAFSI-CoreBanking-primary-Dev.SampleMultiRegionAppCountMigrationCommand03F10102 = aws ecs run-task ...
BLEAFSI-CoreBanking-primary-Dev.SampleMultiRegionAppParamTableNameXxx = BLEAFSI-CoreBanking-xxxx

Aurora にデータベースとテーブルを作成

情報に記載されているコマンドをローカル端末のターミナルで実行します。
※ 末尾の--profile ct-guest-ssoは自分のプロファイル名に変更して実行してください。

# BLEAFSI-CoreBanking-primary-Dev.SampleMultiRegionAppBalanceMigrationCommandxxx を実行
aws ecs run-task ...
# BLEAFSI-CoreBanking-primary-Dev.SampleMultiRegionAppCountMigrationCommand0xxx を実行
aws ecs run-task ...

DynamoDB テーブルのレコード作成

ローカル端末のターミナルで以下コマンドを実行します。
※ myTableName はそれぞれのリージョンに作成された DynamoDB のテーブル名BLEAFSI-CoreBanking-primary-Dev.SampleMultiRegionAppParamTableNameXxxの値に置き換えて下さい。
※ AWS CLI の認証情報にデフォルト以外のプロファイルを使用している場合は --profile 自分のプロファイル名を付けて実行してください。

#東京リージョン
aws dynamodb put-item --region ap-northeast-1 --table-name myTableName --item '{ "PK": { "S": "stopFlag" }, "value": { "S": "false" } }'
#大阪リージョン
aws dynamodb put-item --region ap-northeast-3 --table-name myTableName --item '{ "PK": { "S": "stopFlag" }, "value": { "S": "true" } }'

フェイルオーバーの検証

AWS CDK による勘定系ワークロードのデプロイが完了したので、フェイルオーバーの確認を行います。
Step Functions により、Route53 ARC のドメイン切り替えと Aurora Global Database の Writer の切り替えが行われることを確認します。
フェイルオーバーの詳細については、以下のデモ動画と記事を参照してください。

youtu.be
aws.amazon.com

サンプルアプリケーションにアクセス

こちらを参考にテストツールを用いてサンプルアプリケーションにアクセスしてみます。

手順通りに実行し、LOCUST からサンプルアプリケーションにアクセスする事ができました。

CloudWatch メトリクスからも東京リージョンの各リソースで処理が開始されている事が確認できます。

ALB
ECS Service
DynamoDB
Aurora

ついでに、X-ray によるトレースも確認できました。

AWS Fault Injection Simulator(FIS) で擬似障害を発生

こちらを参考に AWS FIS で擬似的な障害を発生させます。

AWS FIS で擬似障害を発生させ、 LOCUST でネットワーク接続が不安定になっていることを確認できました。

私の環境では SSM Run Command でInterface eth0 does not exist.のエラーが発生しました。
SSM セッションマネージャー経由で BastionHost にアクセスし、ip a lsコマンドを実行してプライベート IP が付与されたインターフェースを確認。
実験テンプレートの Document parameters に"Interface":"確認したインターフェース",を追加することで暫定的にエラーを解消しました。

大阪リージョンにフェイルオーバー

こちらを参考に大阪リージョンにフェイルオーバーを行います。

無事に Step Functions により Route53 ARC と Aurora Global Database のフェイルオーバーが行われました。
Step Functions の実行結果では 2 分程でフェイルオーバーが完了しているようです。

本当に 2 分程でフェイルオーバーが完了しているのか、 LOUCUST でも確認します。
フェイルオーバー中も http://api.example.com に対してリクエストを送り続けたところ、Step Functions の実行結果と同じく 2 分程で復旧したことを確認できました。

東京から大阪へのシステム切り替えが約 2 分で完了するのであれば、従来よりも高い目標の RTO を設定することが出来そうです。

まとめ

本記事では「金融リファレンスアーキテクチャ日本版」と「AWS FIS」を用いて、金融に求められるレジリエンスを体験しました。

記事内で紹介した通り金融リファレンスアーキテクチャ日本版は資料やワークショップが豊富のため AWS のセキュリティと可用性の実装を学ぶにはとても良い教材になると思います。是非、皆さんも金融リファレンスアーキテクチャ日本版でレジリエンスを体験してみてください。

NTTドコモでは、一緒にサービスを作り上げてくれる仲間を募集中です。
ご興味のある方は、以下のリンクからぜひご応募ください。
https://information.nttdocomo-fresh.jp/career/position/it/2PB011-2024/