395-AWS SAP AWS 「理論・実践・一問道場」SAM

type

status

date

slug

summary

理論

1. AWSの災害復旧（DR）戦略

災害復旧（DR）戦略は、システムが予期せぬ障害に直面した際にサービスを迅速に回復させるための計画です。DR戦略では以下の要素が重要です：

RTO（Recovery Time Objective）: サービスが復旧するまでの最大許容時間。

RPO（Recovery Point Objective）: データ損失を許容する最大の時間幅。

災害復旧戦略を構築する際、以下の点に注意する必要があります：

自動フェイルオーバーを活用することで、手動での介入を最小限にし、復旧時間を短縮。

データの複製を活用して、障害発生時に最小限のデータ損失で済むようにする。

2. Aurora MySQLグローバルデータベース

Aurora MySQLグローバルデータベースは、複数リージョンにわたってデータをリアルタイムで同期し、障害発生時に迅速にプライマリリージョンを切り替えることができます。これにより、以下の利点が得られます：

低遅延のリージョン間データ複製: リージョン間でのデータの同期が迅速で、レプリカの整合性を保ちながら複数のリージョンにわたる高可用性を実現します。

フェイルオーバーの迅速化: 災害発生時に、システムは自動的にバックアップリージョンに切り替わり、復旧時間（RTO）を最小限に抑えることができます。

3. Aurora Serverless v1とグローバルデータベース

Aurora Serverless v1は、スケーラブルでコスト効率の良いデータベースサービスですが、複数リージョン間でのデータ同期や自動フェイルオーバーには制限があります。災害復旧においては、Aurora MySQLグローバルデータベースが推奨されます。

4. AWS SAM（Serverless Application Model）

AWS SAMは、サーバーレスアプリケーションを簡単にデプロイできるツールです。主にLambda関数やAPI Gatewayのデプロイに使用されますが、災害復旧の際には、手動でのランブック（手順書）を使用するよりも、自動化されたフェイルオーバーやリカバリ機能を活用する方が理想的です。

5. 自動化と手動介入

災害復旧戦略においては、できるだけ自動化を活用することが重要です。自動フェイルオーバー機能やバックアップシステムを活用することで、復旧時間を短縮し、人的エラーを防ぐことができます。

重要なポイント

RTOとRPOを理解し、それに応じたシステム設計を行う。

Aurora MySQLグローバルデータベースを使用して、複数リージョンでのデータ同期と自動フェイルオーバーを実現。

AWS SAMはデプロイメントの自動化に便利ですが、災害復旧時には自動化された復旧機能を優先することが理想的。

このような戦略を用いることで、災害発生時でも最小限のダウンタイムとデータ損失でサービスを復旧させることができます。

実践

略

一問道場

質問 #395

ある会社は、AWSでソフトウェア・アズ・ア・サービス（SaaS）ソリューションをホストしています。このソリューションには、HTTPSエンドポイントを提供するAmazon API Gateway APIがあります。このAPIは、計算処理のためにAWS Lambda関数を使用しています。Lambda関数は、Amazon Aurora Serverless v1データベースにデータを格納します。会社は、AWS Serverless Application Model（AWS SAM）を使用してソリューションをデプロイしました。ソリューションは複数のアベイラビリティゾーンにまたがっており、災害復旧（DR）計画はありません。

ソリューションアーキテクトは、別のAWSリージョンでソリューションを復旧できるDR戦略を設計しなければなりません。このソリューションには、5分のRTO（復旧時間目標）と1分のRPO（復旧時点目標）があります。

この要件を満たすためにソリューションアーキテクトは何をすべきですか？

選択肢

A. Aurora Serverless v1データベースのリードレプリカをターゲットリージョンに作成する。AWS SAMを使用してターゲットリージョンにソリューションをデプロイするためのランブックを作成する。災害時にはリードレプリカをプライマリに昇格させる。

B. Aurora Serverless v1データベースを、ソースリージョンとターゲットリージョンにまたがる標準のAurora MySQLグローバルデータベースに変更する。AWS SAMを使用してターゲットリージョンにソリューションをデプロイするためのランブックを作成する。

C. ターゲットリージョンに複数のライターインスタンスを持つAurora Serverless v1 DBクラスターを作成する。ターゲットリージョンでソリューションを起動する。2つのリージョンのソリューションをアクティブ-パッシブ構成で機能させるように設定する。

D. Aurora Serverless v1データベースを、ソースリージョンとターゲットリージョンにまたがる標準のAurora MySQLグローバルデータベースに変更する。ターゲットリージョンでソリューションを起動する。2つのリージョンのソリューションをアクティブ-パッシブ構成で機能させるように設定する。

解説

このシナリオでは、災害復旧（DR）戦略を設計するために、5分のRTO（復旧時間目標）と1分のRPO（復旧時点目標）を満たす必要があります。要件に基づいて、ソリューションアーキテクトは以下の選択肢から最適な戦略を選択する必要があります。

各選択肢の評価

選択肢A:

Aurora Serverless v1データベースのリードレプリカをターゲットリージョンに作成し、災害時にリードレプリカをプライマリに昇格させる方法です。
問題点: Aurora Serverless v1は、標準のAurora MySQLグローバルデータベースのように、複数リージョンにわたる高可用性をサポートしていません。リードレプリカは、常にプライマリでないため、復旧の際に昇格する時間がかかり、RTOを満たせない可能性があります。また、1分のRPOも達成しにくいでしょう。

選択肢B:

Aurora Serverless v1を、標準のAurora MySQLグローバルデータベースに変更する方法です。グローバルデータベースは、複数リージョンで同期的にデータを複製し、災害復旧時に迅速にプライマリリージョンを切り替えることができます。
AWS SAM（Serverless Application Model）は、サーバーレスアーキテクチャを構成しデプロイするためのツールです
良い点: Aurora MySQLグローバルデータベースは、高可用性と低い復旧時間を提供します。これにより、RTOとRPOを満たすことができるため、災害復旧戦略として適切です。

選択肢C:

ターゲットリージョンに複数のライターインスタンスを持つAurora Serverless v1 DBクラスターを作成し、アクティブ-パッシブ構成で機能させる方法です。
問題点: Aurora Serverless v1は、複数のライターインスタンスをサポートしていません。また、アクティブ-パッシブ構成は、このシナリオにおいて災害復旧要件に適合しません。Aurora Serverless v1は、スケーリングの方法に制限があるため、RTOやRPOを満たすことが難しいです。

選択肢D:

Aurora Serverless v1を、標準のAurora MySQLグローバルデータベースに変更し、アクティブ-パッシブ構成を作成する方法です。
良い点: Aurora MySQLグローバルデータベースは、複数リージョンでデータを同期的に複製し、迅速にプライマリリージョンを切り替えることができ、RTOとRPOの要件を満たします。これにより、災害復旧戦略において最適な選択肢です。

結論

選択肢 D が最も適切です。Aurora MySQLグローバルデータベースを使用することで、複数のリージョンにわたる高可用性を実現し、災害復旧時に5分のRTOと1分のRPOを達成することができます。