AWSサーバーレス・マルチリージョン構成事例｜連載「IBM Services for AWS Cloud」

記事をシェアする:

IBM Consulting Hybrid Cloud Service AWS Strategic Partnershipの大西です。

「IBM Services for AWS Cloud」の第3回として、筆者がシステム構築案件で経験したAWSサーバーレスのマルチリージョン対応システムの構築事例をご紹介します。特にマルチリージョン採用時のアーキテクチャー上の検討要素を中心に記載します。

事例の背景

本事例のお客様は金融機関であり、顧客接点のひとつとしてスマートフォン・アプリケーションケーションを展開していました。
スマートフォン・アプリケーションは今後のDX戦略の中核をなす顧客チャネルであり、さまざまな機能拡張が予定されていました。一方、バックエンド・システムをオンプレミス・システムと共用しており、今後予定される機能拡張をスピーディーに実現できない恐れがありました。
そこで、スマートフォン・アプリケーション専用のバックエンド・システムをAWS上に構築することになりました。
 

システム・アーキテクチャー

アーキテクチャー策定にあたり、お客様から３点の要件が提示されました。

要件：

1. OSパッチ適用などのシステム運用コストを削減するために可能な限り仮想サーバーを利用しない
2. リージョン障害による顧客影響を最小化する
3. 目標復旧時間（RTO）・目標復旧時点（RPO）を可能な限り短くする

1点目の要件からAWSのサーバーレス・サービスを活用したシステム構成としました。
2点目の要件から災害時リカバリー戦略として東京・大阪リージョンを利用したマルチサイト方式を採用しました。
3点目の要件からDNSによる短時間でのフェイルオーバーおよびリージョン間でリアルタイムデータ同期を可能にしました。

システム・アーキテクチャー

APIを構成するサービスは、Amazon API Gateway（API Gateway）・AWS Lambda（Lambda）といったAWSで実績のあるサーバーレス・サービスです。中核となるサービスはサーバーレス・コンピューティングを提供するLambdaです。Lambdaの最大のメリットはソースコードとかんたんな設定で動作しインフラストラクチャー管理が容易なことです。
他の選択肢としては、Amazon ECS（ECS）とAWS Fargate（Fargate）を組み合わせたサーバーレスなコンテナ・サービスが挙げられます。ですが、Lambdaと比較しコンテナ構築・メンテナンスなどの作業負荷が高くなることが想定されたため、アプリケーションの機能拡張やデプロイをスピーディーに行えるようにすることを優先し、Lambdaを採用しました。

DBにはNoSQLサービスであるAmazon DynamoDB（DynamoDB）を採用しました。本システムでは数百件/秒のアクセスが見込まれていました。オートスケール可能で高スループットに対応できる本サービスは最適な選択肢でした。また、RPOを可能な限り短くする必要があるため、グローバルテーブルを利用したリージョン間リアルタイム・データ同期が可能なことも採用ポイントでした。DynamoDB グローバルテーブルは、マルチリージョンにマルチアクティブ・データベースをデプロイするための完全マネージド型のソリューションです。
他の選択肢としては、Global Database機能でリージョン間データ同期が可能なAmazon Aurora（Aurora）も候補になります。しかし、Aurora採用時はLambdaとAurora間にRDS Proxyを配置する必要がありシステムの複雑性が増すこと、および複雑なトランザクション制御などRDBでなければ実現不可能な機能要件がなくRDBを積極的に採用する理由がなかったため、DynamoDBを採用しました。

バッチはAWS Batch（Batch）とFargateを組み合わせたサーバーレスなコンテナ・アーキテクチャーとしました。ジョブ実行・ジョブ・フロー制御はAmazon EventBridge（EventBridge）およびAWS Step Functions（Step Functions）で制御します。
利用するサービスの種類を絞ってシンプルな構成にすることを理想としていたため、BatchでなくLambdaを採用しAPIとサービスを統一することがベストな選択でした。しかし、Lambdaには実行時間制限（15分）があり、同時間内にバッチが終了する確証がなかったため、Batchを採用しました。

マルチサイト方式

マルチサイトには2つの方式があります。「アクティブ-アクティブ構成」もしくは「アクティブ-パッシブ構成」です。最終的に「アクティブ-パッシブ構成」を採用しました。

「アクティブ-パッシブ構成」を採用した最大の理由は、DynamoDBのリージョン間レプリケーション遅延の懸念でした。DynamoDBのリージョン間レプリケーションでは、他リージョンへ更新が伝達されるまでに若干の遅延が発生します。
一方、リージョン間のルーティング方式はAmazon Route 53（Route 53）のルーティングポリシーに依存します。「アクティブ-アクティブ構成」をサポートするポリシーではリージョンの切り替わりが発生する可能性があります。
DynamoDBのデータ更新直後のリクエストでリージョン切り替えとレプリケーション遅延が同時発生した場合、アプリケーションがレプリケーション前の古いデータにアクセスする可能性があります。対処方法としては、両リージョンから特定リージョンのDynamoDBへアクセスするなどが挙げられます。しかし障害発生時の切り替え制御が必要となるなどシステムの複雑性が高まります。

「アクティブ-パッシブ構成」を採用した場合のデメリットも検討しました。主なデメリットとしては下記が挙げられます。

• 「アクティブ-アクティブ構成」と比較し、主系リージョン障害時の影響ユーザー数が多くなる
• フェイルオーバー時にLambdaインスタンスのスケーリングが多発し、レスポンスが一時的に低下する（スケーリング時に初期化処理を伴うため）
• 副系リージョンは常時稼働していないため、システムの正常稼働が担保されない

前述の「アクティブ-パッシブ構成」のデメリットは、裏を返せば「アクティブ-アクティブ構成」のメリットであり、お客さま要件である「リージョン障害による顧客影響を最小化する」観点において「アクティブ-アクティブ構成」が優位です。
一方、「アクティブ-アクティブ構成」のデメリットであるDBレプリケーション遅延対応に伴うシステムの複雑性に関する課題は、将来の機能拡張やシステム運用時の工数増に継続的に直結し、お客さまの本来の目的であるスピーディーな機能拡張の実現にマイナス要素となります。将来コストの側面は「アクティブ-パッシブ構成」が優位という判断になり、これを重視したため、最終的に「アクティブ-パッシブ構成」を選択することになりました。

フェイルオーバーに要する時間

本システムでは、障害発生時のフェイルオーバーに要する時間もお客さまの関心ごとでした。

障害発生時のフェイルオーバー時間に関係する要素としては以下の2点が挙げられます。

• Route 53ヘルスチェックによる障害検知時間
• Route 53 DNSレコードのTime To Live（TTL）

Route 53ヘルスチェックによる障害検知時間は、Route 53のヘルスチェック間隔としきい値（エラーの連続回数）が影響します。ヘルスチェック間隔は30秒もしくは10秒が選択できます。より早く障害検知する場合は10秒が推奨されます。今回はヘルスチェック間隔に10秒を選択し、しきい値は一般的な3回を採用しました。

DNSレコードのTTLは、Route 53で0秒から最大2日まで設定可能です。このTTLはDNSリゾルバーのキャッシュ保持時間となります。フェイルオーバーをより早く行いたい場合は短い値が推奨されます（AWSの推奨は60秒以下）。ただし、短いほどRoute 53へDNSクエリを行う回数が増加するため、以下のデメリットが発生します。

• レスポンスの遅延頻度の増加が増加する（DNSリゾルバがRoute 53へクエリする時間分が増加）
• Route 53の利用料が増加する（ただし、Route 53へのクエリ料金は非常に安価なので誤差の範囲）

本システムでは、最終的に20秒を採用しました。

本システムのフェイルオーバー最大所要時間は以下の合算となり、50秒となります。

• Route 53ヘルスチェックによる障害検知時間：10秒（ヘルスチェック間隔） × 3回(しきい値) = 30秒 ^※1
• Route 53のDNSレコードのTTL：20秒 ^※2

この値は最大値であり、ほとんどのケースでは上記より短くなります。

^※1Route 53は複数のヘルスチェッカーが動作します。正常判断を行なったチェッカー数が18%以下となった場合に異常と判断します。障害検知時間は前述のような単純計算にはなりませんが、大きく前後するとは考えづらいため近似値として有用であるとは判断できます。
^※2DNSキャッシュはクライアント（ブラウザなど）やOSにも保持される場合があります。これらはAWSの設定で制御できないため、この要素は除外しています。

最後に

この記事ではAWSのサーバーレスを活用したマルチリージョン構成事例とアーキテクチャーの上の検討要素について記載しました。

IBMではAWSを利用した複雑なアーキテクチャーのシステム構築支援が可能です。さらなるAWSの活用に向けて、ぜひIBMにコンタクトください。

このブログに関するお問い合わせやご相談はこちら

関連情報

IBM Services for AWS Cloud の詳細はこちら

連載「IBM Services for AWS Cloud」

第1回 日本IBMでのAWSビジネスへの取り組み
第2回 グローバルなAWS活用での特権ID管理ソリューション導入事例