317-AWS SAP AWS 「理論・実践・一問道場」Secrets Manager KMS

type

status

date

slug

summary

理論

複数リージョンでのAPI展開とアーキテクチャ設計

現代のクラウドアーキテクチャでは、アプリケーションの可用性やスケーラビリティを高めるために、複数のリージョンにまたがる展開が一般的です。特に、グローバルに分散したシステムでは、アクティブ-アクティブ構成を採用し、トラフィックの分散や障害耐性を向上させることが重要です。このようなアーキテクチャ設計において、特に API Gateway や AWS Lambda、DynamoDB Global Tables を使ったシステムがどのように機能するかについての汎用的な知識を紹介します。

1. アクティブ-アクティブ構成のメリット

アクティブ-アクティブ構成は、複数のリージョンでシステムを同時に稼働させることで、以下のようなメリットを提供します：

高可用性：1つのリージョンがダウンしても、他のリージョンでシステムが稼働しているため、サービスの中断を最小化できます。

低レイテンシー：ユーザーが最寄りのリージョンにリクエストを送信することで、低遅延でのアクセスが可能になります。

耐障害性：リージョン間でトラフィックが自動的に切り替わり、システム全体の耐障害性が向上します。

2. 複数リージョンにおけるAPI Gatewayの使用

API Gatewayは、クラウドベースのアプリケーションのエンドポイントとして機能します。複数リージョンにまたがるAPIを設計する際には、次のようなポイントが重要です：

Regional APIエンドポイント：API Gatewayは、各リージョンで独立して設定する必要があります。これにより、ユーザーのリクエストが最寄りのリージョンにルーティングされ、遅延が最小限に抑えられます。

Route 53によるトラフィックの分散：AWSのDNSサービスであるRoute 53を利用して、各リージョンのAPIエンドポイントへのトラフィックを分散させます。これにより、ヘルスチェックを基に健全なリージョンにリクエストを振り分けることが可能になります。

カスタムドメイン名：複数リージョンにまたがるAPIを管理するために、Route 53を使ってカスタムドメイン名を設定し、グローバルにアクセス可能なAPIを提供できます。

3. AWS Lambdaの多地域展開

AWS Lambdaは、サーバーレスでコードを実行できるサービスですが、リージョン固有で動作します。そのため、複数リージョンに対応するためには、各リージョンに同じLambda関数をデプロイする必要があります。

Lambdaの手動デプロイ：各リージョンにLambda関数を手動でデプロイする方法。これには少し手間がかかりますが、小規模なシステムでは十分に機能します。

CI/CDパイプラインの活用：より効率的に複数リージョンにデプロイするためには、AWS CodePipelineやTerraformなどのインフラ管理ツールを使って、Lambda関数を複数リージョンに自動デプロイする方法が一般的です。

Lambda関数の役割：API Gatewayからのリクエストを受けて、外部APIからのデータ取得やDynamoDBへのデータ書き込み・取得を担当します。Lambda関数は、API Gatewayからリクエストを受けて、ビジネスロジックを実行します。

4. DynamoDB Global Tables

DynamoDB Global Tablesは、複数のAWSリージョンでデータを同期させるための機能です。これにより、複数リージョンにまたがるデータの読み書きが可能になります。

自動データ同期：DynamoDB Global Tablesは、データの変更を各リージョンに自動的に反映させます。これにより、複数のリージョンで一貫性のあるデータを保持できます。

高可用性の確保：Global Tablesを使うことで、どのリージョンでもデータが利用でき、障害発生時にも他のリージョンからデータにアクセスできます。

5. Secrets Managerの複数リージョンでの管理

Secrets Managerは、機密情報を安全に管理するためのサービスです。複数リージョンでシステムを運用する場合、次のような構成が考えられます：

Secretsの複製：機密情報（APIキーなど）は、各リージョンに複製しておくことが一般的です。これにより、リージョン間で同期を取り、システムがダウンしないようにします。

KMSキーの管理：Secrets Managerでは、**KMS（Key Management Service）**を使って機密情報を暗号化します。複数リージョンで使用する場合、マルチリージョンKMSキーを使用することで、異なるリージョンでも同じキーで暗号化・復号化を行えます。

6. 運用上の考慮点

複数リージョン構成では、以下の運用上のポイントも重要です：

監視とアラート：AWS CloudWatchを使って、複数リージョンのシステムを監視し、問題が発生した際には即座にアラートを受け取ることが重要です。

障害対応計画：障害発生時にどのリージョンでトラフィックを受け入れるか、どのようにデータの整合性を保つかなど、障害対応の計画を事前に立てておく必要があります。

まとめ

複数リージョンでのシステム展開は、高可用性と低遅延を実現するために不可欠なアーキテクチャの1つです。API Gateway、AWS Lambda、DynamoDB Global Tables、Secrets Managerなどのサービスを組み合わせて、アクティブ-アクティブ構成を作成することで、システム全体の信頼性とスケーラビリティを大幅に向上させることができます。

実践

略

一問道場

Question #317

ある企業が新しいAPIをAWSにデプロイしています。このAPIは、Regional APIエンドポイントを持つAmazon API GatewayとAWS Lambda関数を使用しています。APIは外部ベンダーのAPIからデータを取得し、Amazon DynamoDBグローバルテーブルにデータを保存し、そのテーブルからデータを取得します。ベンダーAPIのAPIキーはAWS Secrets Managerに保存されており、AWS Key Management Service（AWS KMS）のカスタマーマネージドキーで暗号化されています。企業は自社のAPIを単一のAWSリージョンにデプロイしています。

ソリューションアーキテクトは、APIコンポーネントを変更して、複数リージョンでアクティブ-アクティブ構成で実行できるようにする必要があります。

運用負荷を最小限に抑えながら、この要件を満たすためにどの変更の組み合わせを行うべきでしょうか？（3つ選択してください）

選択肢:

A. APIを複数のリージョンにデプロイします。Amazon Route 53にカスタムドメイン名を設定し、各Regional APIエンドポイントにトラフィックをルーティングします。Route 53のマルチバリューアンサールーティングポリシーを実装します。

B. 新しいKMSマルチリージョンカスタマーマネージドキーを作成します。対象となる各リージョンに新しいKMSカスタマーマネージドレプリカキーを作成します。

C. 既存のSecrets Managerシークレットを他のリージョンにレプリケートします。対象となる各リージョンのレプリケートされたシークレットに適切なKMSキーを選択します。

D. 各対象リージョンに新しいAWSマネージドKMSキーを作成します。既存のキーをマルチリージョンキーに変換します。他のリージョンでマルチリージョンキーを使用します。

E. 各対象リージョンに新しいSecrets Managerシークレットを作成します。既存のリージョンからシークレット値をコピーして、各対象リージョンの新しいシークレットに入力します。

F. Lambda関数のデプロイプロセスを変更し、対象となる各リージョンにデプロイを繰り返します。既存のAPIのマルチリージョンオプションをオンにします。各リージョンにデプロイされたLambda関数を、マルチリージョンAPIのバックエンドとして選択します。

解説

この質問は、企業のAPIを複数のリージョンでアクティブ-アクティブ構成にするための方法を問うものです。解決策としては、AWSサービスを活用して運用負荷を最小限に抑えながら、リージョン間での冗長性と可用性を確保することが求められています。

必要な変更のポイント:

API Gatewayのデプロイ: 複数のリージョンでAPIを提供するために、APIを他のリージョンにもデプロイする必要があります。

Secrets ManagerとKMSキーの管理: 複数リージョンでAPIが利用できるように、Secrets Managerに保存されているAPIキーを複数のリージョンにレプリケートし、KMSキーもマルチリージョンに対応させる必要があります。

Lambda関数のデプロイ: APIが複数のリージョンで動作するためには、Lambda関数も複数のリージョンにデプロイする必要があります。

各選択肢の解説:

A. APIを複数のリージョンにデプロイし、Route 53でトラフィックをルーティングする

理由: API Gatewayを複数のリージョンにデプロイすることで、アクティブ-アクティブ構成を実現できます。Route 53でカスタムドメイン名を設定し、マルチバリューアンサールーティングポリシーを使用することで、トラフィックを各リージョンに均等に分散させることができます。この構成により、高可用性とスケーラビリティが確保されます。

適切な理由: この設定により、APIが複数のリージョンで同時に稼働し、リージョン間での冗長性が確保されます。

B. 新しいKMSマルチリージョンカスタマーマネージドキーを作成し、各リージョンにレプリケートキーを作成

理由: KMSのキーは、複数リージョンで使用するために「マルチリージョンキー」を作成する必要があります。これにより、複数のリージョンで同じKMSキーを使ってデータを暗号化および復号化できます。マルチリージョンキーを使うことで、運用管理が容易になります。

適切な理由: KMSのマルチリージョンキーを使用することで、シークレットの暗号化と復号化の一貫性が確保され、リージョン間でのキー管理が簡素化されます。

C. Secrets Managerシークレットを他のリージョンにレプリケートし、適切なKMSキーを選択

理由: Secrets Managerのシークレットは複数のリージョンにレプリケートできます。これにより、各リージョンで同じAPIキーが利用でき、リージョン間での可用性が向上します。また、適切なKMSキーを選択することで、セキュリティも確保できます。

適切な理由: シークレットのレプリケーションによって、リージョン間でAPIキーを共有でき、マルチリージョンで一貫性を持たせることができます。

D. 新しいAWSマネージドKMSキーを作成し、マルチリージョンキーに変換

理由: 新しいKMSキーを作成し、それをマルチリージョンキーに変換する方法もありますが、これよりも「マルチリージョンカスタマーマネージドキー」の作成の方が運用負荷が低く、AWSによる管理が容易です。

不適切な理由: AWSマネージドキーを使用することは推奨されません。セキュリティと管理の柔軟性が低く、カスタマーマネージドキーの方が適切です。

E. 各リージョンに新しいSecrets Managerシークレットを作成し、既存のリージョンからコピー

理由: シークレットを手動でコピーする方法は、運用の効率性が低く、複数リージョンでの管理が煩雑になります。また、この方法ではシークレットの整合性を保つのが難しく、運用負荷が高くなります。

不適切な理由: 手動でシークレットをコピーするのは、管理が面倒でエラーが発生しやすい方法です。

F. Lambda関数のデプロイプロセスを変更し、マルチリージョンオプションをオンにする

理由: Lambda関数のデプロイを複数のリージョンに展開することで、各リージョンにデプロイされたLambda関数をAPIのバックエンドとして使用できます。これにより、APIとLambda関数がリージョン間で冗長化され、可用性が向上します。

適切な理由: Lambda関数を複数のリージョンにデプロイすることで、マルチリージョン構成が実現できます。

結論:

運用負荷を最小限に抑えながら、APIを複数のリージョンでアクティブ-アクティブ構成にするためには、以下の選択肢が最適です：

A: APIを複数のリージョンにデプロイし、Route 53を利用してトラフィックを分散

B: KMSのマルチリージョンカスタマーマネージドキーを使用

C: Secrets Managerシークレットをレプリケートし、各リージョンで適切なKMSキーを選択

これらを組み合わせることで、運用負荷が最小限で済み、APIと関連リソースが高可用性とスケーラビリティを確保できます。