42-AWS SAP「理論・実践・10問道場」

type

status

date

slug

summary

421-AWS SAP AWS 「理論・実践・一問道場」DynamoDB自動スケーリング

理論

1. DynamoDB自動スケーリング

DynamoDB自動スケーリングを使用することで、リクエストの増加に応じて自動的にスループットを調整でき、パフォーマンスの低下を防げます。特に、トラフィックが急増した場合、これが最も効果的です。

2. Lambda関数の同時実行制限

Lambda関数の同時実行制限がボトルネックとなる場合、制限を増やすことで改善が期待できます。ただし、スロットルが1%に過ぎない場合は他の要因（例：DynamoDB）が原因である可能性が高いです。

3. API Gatewayスロットル制限

API Gatewayのスロットル制限を変更しても、根本的な問題がLambdaやDynamoDBにある場合、効果は限定的です。

4. DynamoDBのパーティション設計

DynamoDBテーブルの再設計は、データ量やアクセスパターンに応じてパフォーマンスを向上させますが、まずは自動スケーリングを試みるべきです。

これらの知識を活かし、パフォーマンス問題をトラブルシューティングする際には、リソースのスケーリングと制限の適切な設定がカギとなります。

実践

略

一問道場

質問 #421

ある企業が、Amazon API Gateway、AWS Lambda、Amazon DynamoDBを使用したウェブアプリケーションを運用しています。最近のマーケティングキャンペーンにより需要が増加しました。監視ソフトウェアによると、多くのリクエストで応答時間がキャンペーン前と比べて著しく長くなっています。

ソリューションアーキテクトは、API GatewayのためにAmazon CloudWatch Logsを有効にし、リクエストの20%でエラーが発生していることに気付きました。CloudWatchでは、Lambda関数のスロットルメトリクスがリクエストの1%を示しており、エラーメトリクスはリクエストの10%を示しています。アプリケーションのログによると、エラーが発生する際、DynamoDBへの呼び出しが行われています。

ウェブアプリケーションの人気が高まるにつれて、現在の応答時間を改善するために、ソリューションアーキテクトが行うべき変更はどれですか？

選択肢

A. Lambda関数の同時実行制限を増加させる

B. DynamoDBテーブルに自動スケーリングを実装する

C. API Gatewayのスロットル制限を増加させる

D. DynamoDBテーブルを再作成し、より適切にパーティションされたプライマリインデックスを使用する

解説

この問題では、ウェブアプリケーションの応答時間が遅くなり、エラーが発生している原因を特定し、改善する方法を考えています。具体的には、API Gateway、Lambda、そしてDynamoDBの間で問題が発生しているようです。

問題の背景：

API Gateway でのエラー率が20%であり、その中で10%はLambdaのエラー、1%はLambdaのスロットル（制限）によるものです。

Lambda関数 がエラーを引き起こす際、DynamoDB に関連する呼び出しが行われていることがログで示されています。

この状況から、問題がLambda関数やDynamoDBに関連していることが分かります。したがって、以下の選択肢を考察します。

各選択肢の分析：

A. Lambda関数の同時実行制限を増加させる

Lambda関数の同時実行制限を増加させることは、スロットルが原因でLambda関数が制限される場合に有効ですが、今回の問題ではスロットルの影響は1%に過ぎず、エラーの主要な原因とは言えません。このため、これが主な改善策ではない可能性が高いです。

B. DynamoDBテーブルに自動スケーリングを実装する

DynamoDBの自動スケーリングを有効にすることで、リクエストの急増に対応でき、リソース不足によるレスポンス遅延を防げます。特に、アプリケーションのトラフィックが急増している場合、DynamoDBのスループットに問題が生じ、エラーが発生している可能性があります。自動スケーリングにより、スループットを動的に調整し、パフォーマンスを向上させることができます。

C. API Gatewayのスロットル制限を増加させる

API Gatewayのスロットル制限を増加させても、Lambdaのエラーの原因がDynamoDBである場合、API Gateway自体の制限変更は効果が薄いです。エラーの原因がLambdaの処理やDynamoDBのスループットであれば、API Gatewayのスロットル設定を調整することは解決策にはなりません。

D. DynamoDBテーブルを再作成し、より適切にパーティションされたプライマリインデックスを使用する

DynamoDBテーブルの再作成やインデックスの調整は、パフォーマンスに影響を与える可能性がありますが、これは一般的に設計や初期のデータモデルに関わる改善点であり、エラーがスループット不足に関連している場合、まずは自動スケーリングを試みる方が効果的です。

結論：

最も適切な解決策は B の「DynamoDBテーブルに自動スケーリングを実装する」です。これにより、急増するトラフィックに自動的に対応し、DynamoDBのパフォーマンスが向上し、エラーやレスポンス遅延の問題が改善されると考えられます。

422-AWS SAP AWS 「理論・実践・一問道場」移行

理論

1. AWS EC2 (Elastic Compute Cloud)

EC2インスタンスは、AWSの仮想マシンであり、アプリケーションを移行する際に最も直接的で馴染みのある方法です。EC2は、オンプレミスの仮想マシンや物理サーバーからAWSに移行する際の主要な選択肢となります。

2. Amazon EFS (Elastic File System)

EFSは、AWSで提供される完全マネージド型のファイルストレージサービスで、複数のEC2インスタンスから同時にアクセスすることができます。オンプレミスのファイルサーバーをAWSに移行する場合、EFSは最適な選択肢です。これにより、ファイルストレージの管理がシンプルで、可用性とスケーラビリティが確保されます。

3. Application Load Balancer (ALB)

ALBは、HTTPおよびHTTPSトラフィックの負荷分散を提供するサービスで、Webアプリケーションのトラフィックを複数のバックエンドインスタンスに分散することができます。ALBはアプリケーション層の負荷分散に特化しており、HTTPリクエストに基づいたルーティングやWebSocketのサポートが可能です。

4. 高可用性設計

AWSでのアーキテクチャを高可用性に設計するためには、複数のアベイラビリティゾーン (AZ) にリソースを分散させることが推奨されます。これにより、障害が発生した際に他のAZでリソースを利用することができ、サービスの継続性を確保できます。

5. 最小限の変更による移行

現行のアーキテクチャとできるだけ近い構成にAWSのサービスを使用することで、移行作業を最小限に抑えることができます。既存のアーキテクチャに大きな変更を加えず、AWSのマネージドサービスを活用することが、迅速かつ効率的な移行を実現します。

これらの知識を組み合わせて、オンプレミスからAWSへの移行をスムーズに行い、最小限の変更で高可用性を確保するアーキテクチャを実現することができます。

実践

略

一問道場

会社にはウェブフロントエンドがあるアプリケーションがあり、そのアプリケーションはオンプレミスのデータセンターで実行され、クリティカルなデータのファイルストレージへのアクセスを必要としています。アプリケーションは、冗長性のために3台のLinux仮想マシン（VM）で実行されています。このアーキテクチャには、HTTPリクエストベースのルーティングを行うロードバランサーが含まれています。

会社はできるだけ早くアプリケーションをAWSに移行する必要があり、AWS上のアーキテクチャは高可用性を備えている必要があります。

最も少ない変更でこれらの要件を満たすソリューションはどれですか？

A. アプリケーションをAmazon Elastic Container Service (Amazon ECS)コンテナに移行し、Fargateローンチタイプを使用して3つのアベイラビリティゾーンで実行します。Amazon S3を使用して、すべての3つのコンテナにファイルストレージを提供します。Network Load Balancerを使用してトラフィックをコンテナにルーティングします。

B. アプリケーションをAmazon EC2インスタンスに移行し、3つのアベイラビリティゾーンで実行します。Amazon Elastic File System(Amazon EFS)を使用してファイルストレージを提供します。ファイルストレージを3つのEC2インスタンスにマウントします。Application Load Balancerを使用してトラフィックをEC2インスタンスにルーティングします。

C. アプリケーションをAmazon Elastic Kubernetes Service (Amazon EKS)コンテナに移行し、Fargateローンチタイプを使用して3つのアベイラビリティゾーンで実行します。Amazon FSx for Lustreを使用して、すべての3つのコンテナにファイルストレージを提供します。Network Load Balancerを使用してトラフィックをコンテナにルーティングします。

D. アプリケーションをAmazon EC2インスタンスに移行し、3つのAWSリージョンで実行します。Amazon Elastic Block Store(Amazon EBS)を使用してファイルストレージを提供します。Cross-Region Replication (CRR)を有効にして、3つのEC2インスタンス間でレプリケーションを行います。Application Load Balancerを使用してトラフィックをEC2インスタンスにルーティングします。

解説

この問題では、オンプレミスで運用しているアプリケーションを、最小限の変更でAWSに移行する方法を求めています。アプリケーションは、ファイルストレージを使用し、冗長性を確保するために3台のLinux仮想マシン（VM）を利用しています。また、アーキテクチャにはHTTPリクエストベースのルーティングを行うロードバランサーが含まれています。

選択肢ごとの解説：

A. ECS (Amazon Elastic Container Service) + Fargate + S3 + Network Load Balancer

ECSはコンテナベースのサービスで、Fargateを使用するとサーバレスでコンテナを実行できます。しかし、現在のアーキテクチャではコンテナ化していないため、最小限の変更で移行するという要件には合致しません。また、S3はオブジェクトストレージであり、アプリケーションが求めているような「ファイルストレージ」とは異なります。したがって、この選択肢は不適切です。

B. EC2 + EFS + Application Load Balancer

EC2インスタンスは仮想マシンをAWS上で提供するサービスで、現在のアーキテクチャに最も近いものです。EFS（Elastic File System）は、複数のEC2インスタンスからアクセス可能なネットワークファイルシステムを提供し、ファイルストレージの要件に適しています。Application Load Balancerは、HTTP/HTTPSリクエストのルーティングを行うため、アプリケーションの要件にも合致します。この選択肢は最小限の変更で移行を実現するため、最も適切です。

C. EKS (Amazon Elastic Kubernetes Service) + Fargate + FSx for Lustre + Network Load Balancer

EKSはKubernetesを使ったコンテナ管理サービスで、Fargateと組み合わせて使うことができますが、これはアプリケーションをコンテナ化するため、最小限の変更という要件には合いません。FSx for Lustreは高パフォーマンスのファイルシステムですが、EFSの方がシンプルで、既存のアーキテクチャに適しているため、複雑すぎて不適切です。

D. EC2 + EBS + Cross-Region Replication (CRR) + Application Load Balancer

EC2インスタンスを使用する点では適切ですが、EBS（Elastic Block Store）は単一のEC2インスタンスにアタッチするブロックストレージであり、複数のEC2インスタンスで共有することができません。また、Cross-Region Replicationは異なるリージョン間のデータ同期であり、アーキテクチャの要件に合致しません。この選択肢は不適切です。

最適な解答：B

EC2インスタンス + EFS + Application Load Balancerが、最小限の変更でAWSに移行し、ファイルストレージの要件も満たすため、最適なソリューションです。

423-AWS SAP AWS 「理論・実践・一問道場」AWS Application Discovery Service

理論

AWS Application Discovery Service:

オンプレミスのサーバー、アプリケーション、およびネットワークの依存関係を収集。

移行計画のために、アプリケーション、サーバー、依存関係の詳細情報を取得するツール。

ネットワーク図や依存関係を視覚化し、移行の準備を整える。

AWS Migration Hub:

移行の全体像を管理するサービス。複数の移行ツールと統合し、アプリケーションの移行状況を追跡。

Network diagramsなどを通じて、移行プロジェクトを視覚的に把握。

エージェントとエージェントレスオプション:

Application Discovery Agent：オンプレミス環境にインストールして詳細なデータを収集するオプション。

エージェントレスコレクター：エージェントを使わずにネットワーク依存関係の情報を収集する軽量な方法。

これらのツールと機能を理解し、AWSに移行する前にネットワークの依存関係を正確に把握することが、移行の成功に繋がります。

実践

略

一問道場

問題 #423

ある企業がオンプレミスのデータセンターをAWSに移行する予定です。この企業は現在、LinuxベースのVMware仮想マシンでデータセンターをホストしています。

ソリューションアーキテクトは、仮想マシン間のネットワーク依存関係に関する情報を収集する必要があります。この情報は、ホストIPアドレス、ホスト名、およびネットワーク接続情報を詳細に示す図の形式で必要です。

どのソリューションがこれらの要件を満たすでしょうか？

A. AWS Application Discovery Serviceを使用します。AWS Migration HubのホームAWSリージョンを選択します。オンプレミスサーバーにAWS Application Discovery Agentをインストールしてデータ収集を行い、Application Discovery ServiceにMigration Hubのネットワーク図を使用するための権限を付与します。

B. AWS Application Discovery Serviceのエージェントレスコレクターを使用してサーバーデータを収集します。AWS Migration Hubからネットワーク図を.png形式でエクスポートします。

C. オンプレミスのサーバーにAWS Application Migration Serviceエージェントをインストールしてデータ収集を行い、AWS Migration HubのWorkload Discoveryを使用してネットワーク図を生成します。

D. オンプレミスのサーバーにAWS Application Migration Serviceエージェントをインストールしてデータ収集を行い、AWS Migration HubからCSV形式でデータをエクスポートし、Amazon CloudWatchダッシュボードでネットワーク図を生成します。

解説

この問題では、オンプレミスのデータセンターをAWSに移行する際に、仮想マシン間のネットワーク依存関係を収集し、その情報をネットワーク接続図の形式で取得する方法を求めています。以下は各選択肢の解説です。

A. AWS Application Discovery Serviceを使用する

正解: AWS Application Discovery Serviceは、オンプレミスのインフラとアプリケーションの詳細な情報を収集し、AWS移行計画のために使用できるネットワーク図を提供します。データ収集にはApplication Discovery Agentをサーバーにインストールする必要があり、その後、Migration Hub内でネットワーク図を生成できます。これにより、必要なネットワーク依存関係の情報が収集できます。

B. エージェントレスコレクターを使用してデータ収集し、ネットワーク図を.png形式でエクスポート

誤り: エージェントレスコレクターを使用すると、サーバーの依存関係に関する情報は収集できますが、ネットワーク接続情報（ホストIPやホスト名など）の詳細な図を自動的に作成することはできません。ネットワーク図を生成するためには、適切なデータ収集と図作成機能が必要です。

C. AWS Application Migration Serviceエージェントをインストールし、Workload Discoveryでネットワーク図を生成

誤り: AWS Application Migration Serviceは、物理または仮想サーバーの移行を支援するサービスであり、ネットワーク依存関係の収集や図を作成するための専用ツールではありません。これには、Application Discovery Serviceを使用するほうが適切です。

D. AWS Application Migration Serviceエージェントをインストールし、CSV形式でデータをエクスポートしてCloudWatchでネットワーク図を生成

誤り: Application Migration Serviceエージェントは移行用のツールであり、ネットワーク図を生成する機能はありません。CloudWatchダッシュボードにCSVデータをエクスポートする方法では、ネットワーク依存関係の視覚化や自動的なネットワーク図生成は難しいです。

結論:

Aが最適な選択肢です。AWS Application Discovery Serviceを使用すると、オンプレミス環境のネットワーク依存関係を収集し、必要な情報を視覚化したネットワーク図を生成できます。

424-AWS SAP AWS 「理論・実践・一問道場」Amazon RDS Proxy

理論

1. Amazon Aurora

Amazon Auroraは、高いスケーラビリティと可用性を提供するリレーショナルデータベースサービスです。

Auroraは、自動的にバックアップ、パッチ適用、スナップショット管理を行い、高い可用性を確保するためにMulti-AZ配置が可能です。

Auroraは、MySQLやPostgreSQLとの互換性があり、オンプレミスのデータベースよりも高性能です。

2. Aurora Replica

Aurora Replicaは、読み取り専用のレプリカで、データベースの読み取り負荷を分散し、パフォーマンスを向上させます。

アプリケーションは、読み取りリクエストを複数のレプリカに分散することができます。

3. Amazon RDS Proxy

RDS Proxyは、データベース接続プールを管理するサービスです。これにより、Lambda関数や他のアプリケーションがデータベースへの接続を効率的に行えるようになります。

特に、Lambdaなどのスケーラブルなアプリケーションが多数の短期間での接続を開く場合に有効です。

4. Lambda関数の接続プール

AWS Lambdaは、デフォルトでは各実行時に新しいデータベース接続を作成しますが、接続プールを使用すると接続のオーバーヘッドを削減し、パフォーマンスを向上させることができます。

接続プールは、同時に発生する多くのリクエストの効率的な処理を支援します。

5. データベースのスケーリング

データベースのスケーリングには、垂直スケーリング（インスタンスのサイズを増やす）と水平スケーリング（レプリカを追加する）があり、特に読み取り負荷の高いアプリケーションには、レプリカを追加することで効果的に対応できます。

まとめ

このシナリオにおいては、Amazon Auroraへの移行、Aurora Replicaの追加、Amazon RDS Proxyを使った接続プール管理が、スケーラビリティとパフォーマンス向上に最も効果的なアプローチとなります。

実践

略

一問道場

ある企業がAWSでソフトウェア・アズ・ア・サービス（SaaS）アプリケーションを運用しています。このアプリケーションはAWS Lambda関数とAmazon RDS for MySQLのMulti-AZデータベースで構成されています。市場イベント時には、通常よりも大きなワークロードが発生し、ユーザーはピーク時にデータベース接続が多いため、応答速度が遅くなることに気付きます。企業は、データベースのスケーラブルなパフォーマンスと可用性を改善する必要があります。

どのソリューションがこの要件を満たしますか？

A. リソース使用率がしきい値を超えたときに、Lambda関数をトリガーしてAmazon RDS for MySQLのリードレプリカを追加するAmazon CloudWatchアラームアクションを作成する。

B. データベースをAmazon Auroraに移行し、リードレプリカを追加する。Lambdaハンドラ関数外でデータベース接続プールを追加する。

C. データベースをAmazon Auroraに移行し、リードレプリカを追加する。Amazon Route 53の加重レコードを使用する。

D. データベースをAmazon Auroraに移行し、Aurora Replicaを追加する。Amazon RDS Proxyを使用してデータベース接続プールを管理する。

解説

この問題では、データベースのスケーラビリティと可用性を改善し、ピーク時のパフォーマンスを向上させる方法を選択することが求められています。

選択肢ごとの解説:

この方法は、リソース使用率に基づいて自動的にリードレプリカを追加しようとするものですが、Lambda関数を使用して手動でデータベースのスケーリングを行うのは実用的ではありません。データベース接続の問題に対処するには、接続プールやより効率的なスケーリングが必要です。

B. データベースをAmazon Auroraに移行し、リードレプリカを追加する。Lambdaハンドラ関数外でデータベース接続プールを追加する。

Auroraへの移行は、性能向上と可用性を提供しますが、単にリードレプリカを追加しただけでは、Lambda関数による接続の問題を解決するには不十分です。Lambda関数で接続プールを使用することは重要ですが、Auroraでの管理がさらに効果的です。

C. データベースをAmazon Auroraに移行し、リードレプリカを追加する。Amazon Route 53の加重レコードを使用する。

Route 53加重レコードはDNSのルーティング方法を変更するもので、データベースの接続の問題に対処するための根本的な解決にはなりません。接続プールやAurora Replicaの活用が重要です。

D. データベースをAmazon Auroraに移行し、Aurora Replicaを追加する。Amazon RDS Proxyを使用してデータベース接続プールを管理する。

最適解です。Amazon Auroraへの移行とAurora Replicaの追加により、データベースのスケーラビリティと可用性が向上します。また、Amazon RDS Proxyを使用してデータベース接続プールを管理することで、Lambda関数のデータベース接続を効率化し、スケーラビリティを向上させます。これにより、ピーク時のパフォーマンス問題を解決できます。

結論: 選択肢 D は、データベースのスケーラビリティ、接続管理、可用性の向上を実現し、最も適切な解決策です。

425-AWS SAP AWS 「理論・実践・一問道場」SMB経由

理論

クラウドストレージ移行の基本

クラウドへのデータ移行は、アプリケーションが現在使用しているプロトコルやシステムとの互換性を保ちながら、効率的に行うことが重要です。以下は移行時に注意すべき点です。

プロトコル互換性

アプリケーションが使用しているアクセスプロトコル（例：SMB、NFS）とクラウドサービスが提供するストレージオプション（例：Amazon S3、Amazon EFS）との互換性を確認します。

データ移行方法

AWS DataSync：オンプレミスとAWS間で大規模なデータを効率的に移行。ファイルシステム間の同期に便利。

AWS Storage Gateway：オンプレミス環境とクラウド間でファイルシステムの統合を行い、SMBやNFSプロトコルを維持しつつクラウドにデータを保存。

Amazon FSx：Windows向けのファイルシステムで、SMBやNFSをサポート。クラウド上で既存のファイルサーバーを代替する。

段階的移行

アプリケーションのコードを一度に全面的に移行するのではなく、段階的に移行し、必要に応じてSMBやNFSのような既存のアクセス方法を一時的に維持する方法を取ります。

結論

AWSにはさまざまな移行ツールとサービスがあり、移行するデータやプロトコルに応じて最適なツールを選択することが重要です。

実践

略

一問道場

ある企業がアプリケーションをオンプレミスからAWSクラウドに移行しようとしています。企業は移行を、アプリケーションの基盤となるデータストレージのAWSへの移行から始めます。アプリケーションデータはオンプレミスの共有ファイルシステムに格納されており、アプリケーションサーバーはSMBを通じてこの共有ファイルシステムに接続します。ソリューションアーキテクトは、Amazon S3バケットを共有ストレージとして使用するソリューションを実装する必要があります。アプリケーションが完全に移行され、コードがネイティブなAmazon S3 APIを使用するように書き換えられるまで、アプリケーションはSMB経由でデータにアクセスできる必要があります。ソリューションアーキテクトは、オンプレミスのアプリケーションがデータにアクセスできるようにしたまま、アプリケーションデータをAWSの新しい場所に移行する必要があります。

この要件を満たすソリューションはどれですか？

A. 新しいAmazon FSx for Windows File Serverファイルシステムを作成します。AWS DataSyncを使用して、オンプレミスのファイル共有と新しいAmazon FSxファイルシステムの2つの場所を設定します。新しいDataSyncタスクを作成して、オンプレミスのファイル共有からAmazon FSxファイルシステムにデータをコピーします。

B. アプリケーション用にS3バケットを作成します。オンプレミスのストレージからS3バケットにデータをコピーします。

C. AWS Server Migration Service（AWS SMS）VMをオンプレミス環境に展開します。AWS SMSを使用して、ファイルストレージサーバーをオンプレミスからAmazon EC2インスタンスに移行します。

D. アプリケーション用にS3バケットを作成します。新しいAWS Storage GatewayファイルゲートウェイをオンプレミスVMに展開します。新しいファイル共有を作成し、それをS3バケットに格納し、ファイルゲートウェイに関連付けます。オンプレミスのストレージから新しいファイルゲートウェイエンドポイントにデータをコピーします。

解説

このシナリオの要件は、アプリケーションのデータをAWSに移行し、移行が完了するまでアプリケーションがSMB経由でアクセスできることを確保することです。そのため、SMBを使ってデータにアクセスする必要があり、かつ、データの移行と保存をS3バケットに行う必要があります。

各オプションの解説

A. 新しいAmazon FSx for Windows File Serverファイルシステムを作成し、AWS DataSyncを使用して移行する

Amazon FSx for Windows File ServerはSMBプロトコルをサポートしています。これにより、アプリケーションはSMB経由でデータにアクセスできます。しかし、このオプションはS3バケットを使用しないため、最初の要件である「S3バケットを使用する」という点に適していません。

B. アプリケーション用にS3バケットを作成し、オンプレミスのストレージからS3バケットにデータをコピーする

この方法では、オンプレミスからS3にデータをコピーできますが、SMB経由でアクセスするという要件に合致していません。アプリケーションがS3 APIに書き換えられるまで、SMBを介したアクセスを維持する必要があるため、この方法では解決できません。

C. AWS Server Migration Service（AWS SMS）を使用して、ファイルストレージサーバーをAmazon EC2インスタンスに移行する

AWS SMSは仮想マシンを移行するためのツールであり、ファイルシステムの移行に適しているわけではありません。また、SMB経由でのアクセスが必要という要件にも対応していません。このオプションはこのケースには不適切です。

D. AWS Storage Gatewayファイルゲートウェイを使用する

このオプションは、オンプレミスの環境でSMBを介してデータにアクセスする必要がある要件を満たします。Storage Gatewayのファイルゲートウェイは、オンプレミスとAWSの間でSMB共有を提供し、データをAmazon S3に保存できます。これにより、アプリケーションがSMB経由でデータにアクセスしながら、最終的にS3バケットにデータを移行できます。このソリューションが最適です。

結論

最適な解決策は D です。

AWS Storage Gatewayファイルゲートウェイを使用することで、オンプレミスのアプリケーションがSMB経由でデータにアクセスでき、かつデータはS3に保存されるため、移行プロセスを順次進めることができます。

426-AWS SAP AWS 「理論・実践・一問道場」DynamoDB Global cloudfront

理論

グローバルアーキテクチャにおける低レイテンシーの実現

データベースのグローバル分散

Amazon DynamoDB Global TablesやAmazon Aurora Global Databaseは、複数のAWSリージョンでデータを同期し、低レイテンシーでグローバルなアクセスを実現。データは最寄りのリージョンから即座に取得され、レイテンシーが最小化される。

エッジコンピューティング

Lambda@EdgeやCloudFront Functionsを使用すると、リクエストが最寄りのAWSエッジロケーションで処理され、バックエンドAPIを通さずにロジックを実行できるため、レイテンシーが劇的に低減される。

トラフィックの最適化

AWS Global AcceleratorやAmazon Route 53を利用して、ユーザーのリクエストを最寄りのリージョンやエッジロケーションにルーティングし、アプリケーションのパフォーマンスを向上させる。

サーバーレスアーキテクチャ

Lambda@EdgeやCloudFront Functionsは、インフラの管理を最小限に抑え、スケーラビリティとコスト効率を高めるため、特にトラフィックの多いグローバルアプリケーションに適している。

これらの技術を組み合わせることで、グローバルアーキテクチャにおいて低レイテンシー、スケーラビリティ、効率的な運用が可能になります。

実践

略

一問道場

質問 #426

あるグローバル企業が、チケットのバーコードを表示するモバイルアプリを運営しています。顧客はアプリのチケットを使ってライブイベントに参加します。イベントのスキャナーはチケットのバーコードを読み取り、バックエンドAPIを呼び出して、データベースのデータとバーコードのデータを照合します。バーコードがスキャンされた後、バックエンドのロジックはデータベースの単一テーブルに書き込み、バーコードを使用済みとしてマークします。

この企業は、AWS上でアプリを展開し、DNS名を api.example.com として設定する必要があります。データベースは世界中の3つのAWSリージョンにホストされます。

どのソリューションが最も低いレイテンシーでこの要件を満たしますか？

A. データベースを Amazon Aurora Global Database クラスターにホストします。バックエンドは、データベースと同じリージョンにある3つの Amazon Elastic Container Service（Amazon ECS）クラスターにホストします。AWS Global Acceleratorでアクセラレータを作成し、リクエストを最寄りのECSクラスターにルーティングします。api.example.com をアクセラレータのエンドポイントにマッピングする Amazon Route 53 レコードを作成します。

B. データベースを Amazon Aurora Global Database クラスターにホストします。バックエンドは、データベースと同じリージョンにある3つの Amazon Elastic Kubernetes Service（Amazon EKS）クラスターにホストします。3つのクラスターをオリジンとして Amazon CloudFront ディストリビューションを作成します。リクエストを最寄りのEKSクラスターにルーティングします。api.example.com を CloudFront ディストリビューションにマッピングする Amazon Route 53 レコードを作成します。

C. データベースを Amazon DynamoDB Global Tables にホストします。Amazon CloudFront ディストリビューションを作成します。CloudFront ディストリビューションに、バーコードを検証するバックエンドロジックを含む CloudFront Function を関連付けます。api.example.com を CloudFront ディストリビューションにマッピングする Amazon Route 53 レコードを作成します。

D. データベースを Amazon DynamoDB Global Tables にホストします。Amazon CloudFront ディストリビューションを作成します。CloudFront ディストリビューションに、バーコードを検証するバックエンドロジックを含む Lambda@Edge 関数を関連付けます。api.example.com を CloudFront ディストリビューションにマッピングする Amazon Route 53 レコードを作成します。

解説

オプションDが正解である理由について、さらに詳細な解説を行います。

1. Amazon DynamoDB Global Tables

DynamoDB Global Tablesは、複数のリージョンにわたって自動的にデータを同期し、世界中どこからでもアクセスできるデータベースを提供します。これにより、ユーザーの最寄りのリージョンから迅速にデータを取得することができます。特に、グローバルな分散アプリケーションにおいて、データベースの可用性とレイテンシーを最適化するために非常に有効です。

2. Lambda@Edge

Lambda@Edgeは、CloudFrontのエッジロケーションでサーバーレスコードを実行できるAWSサービスです。ユーザーがリクエストを送信すると、そのリクエストは最寄りのエッジロケーションで処理されます。これにより、バックエンドサーバーにリクエストを送る前に、エッジで直接処理が行われるため、レスポンス時間が大幅に短縮され、低レイテンシーを実現できます。

このサービスは、APIリクエストに対して即座にロジックを実行することが可能で、バーコードの検証のようなリアルタイムのバックエンド処理を迅速に行えます。特に、データベースとの連携が重要な処理であっても、Lambda@Edgeはエッジでの処理をサポートします。

3. CloudFrontとの統合

Amazon CloudFrontは、グローバルなコンテンツ配信ネットワーク（CDN）であり、ユーザーに最寄りのエッジロケーションを通じてコンテンツを提供することで、パフォーマンスを向上させます。Lambda@Edgeは、CloudFrontのリクエスト処理に組み込まれて、リクエストが最寄りのエッジロケーションで処理されるときにコードを実行します。これにより、グローバルなパフォーマンスの向上が実現します。

4. 低レイテンシーと効率性

Lambda@Edgeを使用することで、バックエンドAPIやデータベースにアクセスせずに、エッジロケーションで即座に処理を完了させることが可能です。これにより、全体的なレイテンシーが最小限に抑えられ、ユーザーのリクエストに対するレスポンス時間が短縮されます。

DynamoDB Global Tablesとの組み合わせにより、データは全リージョンで即座に同期され、必要なデータがユーザーに最寄りのリージョンから迅速に取得されます。

5. スケーラビリティと管理の簡便さ

Lambda@Edgeはサーバーレスでスケーラブルなサービスであり、負荷が増加しても自動的にスケールします。インフラの管理を心配することなく、コードを変更するだけでスケーラビリティが確保できます。

DynamoDBも完全マネージド型であり、スケーラビリティを気にすることなく使用でき、特にトラフィックの多いグローバルアプリケーションに最適です。

6. 他の選択肢との比較

オプションAは、AWS Global Acceleratorを使用して最寄りのECSクラスターにリクエストをルーティングします。Global Acceleratorは低レイテンシーを提供しますが、ECSクラスターはコンテナオーケストレーションが必要で、設定や管理が少し複雑です。また、ECSはAPIリクエストの処理をバックエンドで行うため、Lambda@Edgeに比べてエッジでの直接処理という利点はありません。

オプションBは、EKSを使用し、CloudFrontディストリビューションを使ってリクエストをルーティングします。EKSは複雑で、クラスター管理が必要です。特に、Lambda@Edgeのようにエッジで直接バックエンドロジックを処理することができないため、オプションDのように低レイテンシーを実現するのには向いていません。

オプションCは、CloudFront Functionを使用していますが、CloudFront Functionは軽量な処理に特化しており、バーコードの検証など複雑なバックエンドロジックには向いていません。Lambda@Edgeの方が、より高度で柔軟なバックエンド処理を実行できるため、オプションDの方が優れています。

結論

オプションDは、DynamoDB Global Tables と Lambda@Edge を組み合わせることで、グローバルに分散されたデータベースとエッジでの迅速なロジック実行を実現し、最も低レイテンシーで効率的なソリューションを提供します。サーバーレスでスケーラビリティも確保でき、運用負荷も低く、最適な選択肢です。

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

理論

オリジンセキュリティ強化のためのアーキテクチャとベストプラクティス

以下は、クラウド環境でのオリジンセキュリティ強化に関連する汎用的な知識です。

1. AWS WAF（Web Application Firewall）を活用する

WAFは、特定のリクエストを検査して悪意のあるトラフィックをブロックするためのツールです。WAFでは、IP一致、文字列一致、クロスサイトスクリプティング（XSS）やSQLインジェクション攻撃の検出、Rate Limiting（リクエスト数制限）などのルールを設定できます。

Web ACL（Access Control List）を使用して、ALBやAPI Gateway、CloudFrontのようなサービスに適用できます。

カスタムヘッダー検証：AWS WAFを利用して、特定のHTTPヘッダー（例えば、ランダムな文字列を含むカスタムヘッダー）に対するルールを設定し、リクエストの正当性を確認することができます。

2. セキュリティ強化のためのランダム文字列

APIやサービスの認証のために、ランダムな文字列（例えば、シークレットキーやトークン）を使用することが一般的です。

これらのシークレットキーは、定期的にローテーションして管理することが重要です。AWSでは、Secrets ManagerやSystems Manager Parameter Storeを使ってシークレットの管理と自動ローテーションを行うことができます。

3. CloudFrontによるリクエストの検査とルーティング

CloudFrontは、コンテンツ配信ネットワーク（CDN）として機能するだけでなく、オリジンサーバー（この場合、ALB）のセキュリティ強化にも使用できます。

CloudFrontでリクエストにカスタムヘッダーを追加し、その内容をALBやバックエンドで検証する方法で、リクエストが正当なものであるかを確認できます。

4. AWS Lambda と自動化

AWS Lambdaを使用して、秘密情報の自動ローテーションや、リクエストが正しいかを検証するための処理を自動化することができます。Lambda関数をトリガーとして、指定した条件を満たさないリクエストをブロックするなどの操作を行えます。

5. DDoS防御としてのAWS Shield

AWS Shield Advancedは、分散型サービス拒否（DDoS）攻撃からの保護を提供します。これを利用することで、大規模なDDoS攻撃からリソースを守ることができますが、リクエストの内容や認証強化には、AWS WAFやカスタムヘッダーの検証が有効です。

まとめ

オリジンセキュリティの強化には、リクエストの正当性確認、IPフィルタリング、カスタムヘッダーの検証、DDoS対策を組み合わせることが重要です。AWSのサービス（CloudFront, WAF, Lambda, Secrets Managerなど）を活用して、セキュリティを一元的に管理・強化する方法が推奨されます。

実践

略

一問道場

質問 #427

ある医療企業が、いくつかのAmazon EC2インスタンスでREST APIを実行しています。EC2インスタンスはAuto Scalingグループ内で実行され、Application Load Balancer (ALB) の背後に配置されています。ALBは3つのパブリックサブネットに配置され、EC2インスタンスは3つのプライベートサブネットで実行されています。企業は、ALBを唯一のオリジンとして持つAmazon CloudFrontディストリビューションを展開しています。

オリジンのセキュリティを強化するために、ソリューションアーキテクトはどのような解決策を推奨すべきですか？

A. ランダムな文字列をAWS Secrets Managerに保存し、自動秘密管理のためのAWS Lambda関数を作成する。CloudFrontがオリジンリクエストにカスタムHTTPヘッダーとしてランダムな文字列を挿入するように設定する。AWS WAFでカスタムヘッダーに対する文字列一致ルールを含むWeb ACLルールを作成し、そのWeb ACLをALBに関連付ける。

B. AWS WAF Web ACLルールでCloudFrontサービスのIPアドレス範囲に対するIP一致条件を作成する。そのWeb ACLをALBに関連付け、ALBを3つのプライベートサブネットに移動する。

C. ランダムな文字列をAWS Systems Manager Parameter Storeに保存し、その文字列の自動ローテーションをParameter Storeで設定する。CloudFrontがオリジンリクエストにカスタムHTTPヘッダーとしてランダムな文字列を挿入するように設定する。ALBでカスタムHTTPヘッダーの値を検査し、アクセスをブロックする。

D. AWS Shield Advancedを設定し、CloudFrontサービスのIPアドレス範囲からの接続を許可するセキュリティグループポリシーを作成する。そのポリシーをAWS Shield Advancedに追加し、ALBにそのポリシーを適用する。

解説

この問題は、Amazon CloudFrontを使用したアーキテクチャのオリジンセキュリティ強化に関するものです。ALB（Application Load Balancer）へのアクセスを保護し、悪意のあるアクセスを防ぐためにどのような手法を使用するかを問うものです。

各選択肢の解説

解説：この解決策では、セキュリティの強化のためにランダムな文字列（秘密鍵のようなもの）を使います。CloudFrontがリクエストにこのカスタムヘッダーを追加し、その値をALBで検証する方法です。AWS WAFでカスタムヘッダーをチェックするルールを作成することで、不正なリクエストをフィルタリングすることができます。自動で秘密を管理・更新するため、セキュリティが向上します。

推奨される理由：この方法は、セキュリティを強化するための最も効果的なアプローチであり、認証情報やシークレットを動的に管理し、CloudFrontを経由してALBに到達するリクエストの検証を行う点で強力です。

解説：このアプローチは、CloudFrontサービスのIPアドレスからのリクエストを許可するIP一致条件をAWS WAFで設定するものです。これにより、CloudFront以外からの不正なリクエストをブロックすることができます。しかし、ALBをプライベートサブネットに移動することが必要ですが、この設定は必ずしも適切とは言えません。ALBをプライベートサブネットに移動すると、CloudFrontがALBにアクセスできなくなる可能性があるため、アーキテクチャ的に不適切です。

問題点：ALBをプライベートサブネットに移動すると、CloudFrontがALBにアクセスできない場合があり、実行できない可能性があります。

解説：この方法では、ランダムな文字列をAWS Systems Manager Parameter Storeに保存し、それをCloudFrontのリクエストに挿入して検証します。Parameter Storeで自動ローテーションを設定してシークレットを管理することは可能ですが、ALBでカスタムヘッダーの値を検査するロジックを実装する必要があり、少し複雑になります。AWS WAFを使ってWeb ACLを設定した方が簡単で効果的です。

問題点：ALB側でヘッダーの検査が手動で行われる必要があり、AWS WAFを利用する方が簡単かつ効率的です。

解説：AWS Shield AdvancedはDDoS（分散型サービス拒否攻撃）に対する保護を提供するサービスです。セキュリティグループでCloudFrontのIP範囲を許可する方法は、CloudFrontからのアクセスを制限するための一つの方法ですが、オリジンセキュリティを強化する方法としては不十分です。AWS Shieldは主にDDoS攻撃に対して有効ですが、オリジンセキュリティの強化には他の方法（例：WAFやカスタムヘッダー）がより効果的です。

問題点：Shield AdvancedはDDoS保護に特化しており、リクエストの認証や精緻なアクセス制御には不向きです。

正解：A

理由：

AWS WAFを使用したカスタムヘッダーによる認証と、秘密管理を自動化するためのLambda関数を組み合わせることで、セキュリティ強化が効率的に行えます。

CloudFrontでリクエストにカスタムヘッダーを追加し、ALBでそのヘッダーを検証することで、オリジンへの不正アクセスを防ぐことができます。

428-AWS SAP AWS 「理論・実践・一問道場」AWS Direct Connect Gateway

理論

AWS Direct Connectを使用したセキュアで高可用性のネットワーク設計

AWS環境でデータをセキュアかつ効率的に管理・アクセスするには、以下の知識が役立ちます：

1. AWS Direct Connect (DX)

概要: お客様のオンプレミス環境とAWSを専用線で接続するサービス。

利点:

パブリックインターネットを通過せず、セキュアで低レイテンシーの接続を提供。
帯域幅コストを削減可能（大容量データ転送に最適）。

2. Direct Connect Gateway

概要: 複数のAWSリージョンのVPCに接続できる中継ゲートウェイ。

利点:

各リージョンへの直接接続が不要で、コストを大幅に削減。
複数リージョンにまたがるトラフィックを簡単に管理可能。

3. 高可用性設計

プラクティス:

Direct Connect接続を2本（アクティブ/スタンバイ）用意することで冗長性を確保。
AWSが提供する他のネットワークサービス（例: Transit Gateway）と連携可能。

4. リージョン間接続の選択肢

Direct Connect Gateway: 最適解。高スケーラビリティかつ運用負担が少ない。

リージョン間VPCピアリング: 小規模ネットワークに適しているが、大規模環境には不向き。

結論

Direct ConnectとDirect Connect Gatewayを組み合わせることで、セキュリティ、コスト効率、高可用性をすべて満たすAWSネットワーク設計が可能です。

実践

略

一問道場

質問 #428

業界規制に従い、ソリューションアーキテクトは会社の重要なデータを複数のAWSリージョンに保存するソリューションを設計する必要があります。データは本社があるアメリカを含むリージョンに保存されます。また、AWSに保存されたデータへのアクセスを会社のグローバルWANネットワーク経由で提供する必要があります。セキュリティチームからは、このデータにアクセスするトラフィックがパブリックインターネットを通過しないようにするよう求められています。

ソリューションアーキテクトは、要件を満たしつつ費用対効果が高く、高可用性を備えたソリューションをどのように設計すればよいでしょうか？

A. 本社から使用するすべてのAWSリージョンに対してAWS Direct Connect接続を確立します。会社のWANを使ってトラフィックを本社経由で各Direct Connect接続に送信し、データにアクセスします。

B. 本社から1つのAWSリージョンにAWS Direct Connect接続を2本確立します。会社のWANを使ってトラフィックをDirect Connect経由で送信します。他のAWSリージョンのデータには、リージョン間VPCピアリングを利用してアクセスします。

C. 本社から1つのAWSリージョンにAWS Direct Connect接続を2本確立します。会社のWANを使ってトラフィックをDirect Connect経由で送信します。他のAWSリージョンのデータには、AWSトランジットVPCソリューションを利用してアクセスします。

D. 本社から1つのAWSリージョンにAWS Direct Connect接続を2本確立します。会社のWANを使ってトラフィックをDirect Connect経由で送信します。他のAWSリージョンのデータには、Direct Connect Gatewayを利用してアクセスします。

解説

この問題では、以下の要件を満たすソリューションを設計する必要があります：

データの保存: データは複数のAWSリージョン（アメリカを含む）に保存される。

セキュリティ: データアクセスのトラフィックがパブリックインターネットを通過しない。

コスト効率: 費用対効果が高いソリューションであること。

高可用性: ソリューションは高可用性を確保する必要がある。

各選択肢の解説

A. AWS Direct Connect接続をすべてのAWSリージョンに確立

本社から全AWSリージョンに個別のDirect Connect接続を確立する方法です。

長所: 全リージョンに専用接続があるため、トラフィックが完全にセキュアです。

短所: 各リージョンにDirect Connect接続を確立するコストが非常に高くなる。現実的ではありません。

結論: コスト効率の要件を満たさないため、不適切。

B. Direct Connectを1リージョンに確立 + リージョン間VPCピアリング

本社から1つのAWSリージョンにDirect Connect接続を2本設置し、そこからリージョン間VPCピアリングで他リージョンにアクセスする方法です。

長所: コスト効率はAより良い。Direct Connectを1リージョンに絞ることでコストを削減可能。

短所: リージョン間VPCピアリングはAWSリージョン間のトラフィックにコストがかかり、スケールしにくい。また、ピアリングはフルメッシュの設定が必要で管理が複雑になる可能性がある。

結論: コスト効率や運用の観点から最適とは言えない。

C. Direct Connectを1リージョンに確立 + AWSトランジットVPC

本社から1つのAWSリージョンにDirect Connect接続を2本設置し、AWSトランジットVPCソリューションを利用して他リージョンにアクセスする方法です。

長所: トランジットVPCを使用することで他リージョンへの接続を効率化できる。

短所: AWSトランジットVPCソリューションは既に非推奨となり、AWS Transit Gatewayなどの最新のサービスが推奨されている。非推奨の技術を使うのはリスクが高い。

結論: 現在のAWSのベストプラクティスに適合しないため不適切。

D. Direct Connectを1リージョンに確立 + Direct Connect Gateway

本社から1つのAWSリージョンにDirect Connect接続を2本設置し、Direct Connect Gatewayを使用して他リージョンのデータにアクセスする方法です。

長所: Direct Connect Gatewayは複数のAWSリージョンにまたがるVPC接続を効率的に管理でき、スケーラブルかつコスト効率が高い。また、トラフィックはDirect Connect経由で送信され、パブリックインターネットを通過しない。

短所: 特になし。この方法は現在のAWSベストプラクティスに適合している。

結論: 高可用性、セキュリティ、コスト効率すべての要件を満たすため最適解。

正解

D. AWS Direct Connect Gateway を使用

429-AWS SAP AWS 「理論・実践・一問道場」Disaster Recovery

理論

AWS Elastic Disaster Recovery は常にデータを同期しており、障害が発生した場合に迅速にクラウド環境での運用を再開するための重要なサービスです。

災害復旧（Disaster Recovery）におけるAWSのベストプラクティス

災害復旧（DR）は、システム障害や災害発生時にサービスを迅速に復旧させ、ビジネス継続を可能にするための戦略です。AWSは、多様なDRソリューションを提供しており、要件に応じた柔軟な構成が可能です。本記事では、AWSにおける主要なDRソリューションやその適用場面を解説します。

AWS災害復旧ソリューションの種類

1. AWS Elastic Disaster Recovery

特徴:

オンプレミスやAWS内のシステムをAWSリージョン間でレプリケート。
自動化されたリカバリプロセスで迅速な切り替えを実現。
低コストで運用可能（必要なときのみリソースを活用）。

適用例:

高速な復旧が求められる環境（RPO: 数分、RTO: 数分～数時間）。
オンプレミスからAWSへの一時的な移行。

2. AWS Storage Gateway

特徴:

オンプレミスデータをAmazon S3やAmazon EBSにバックアップ。
ハイブリッドクラウド環境でのデータ共有に適用可能。

適用例:

ファイルベースのデータをAWSに安全に保存。
復旧に時間をかけても問題ないシステム。

3. Amazon FSx for Windows File Server

特徴:

Windows環境向けの共有ファイルシステム。
ネイティブWindowsファイルシステムをサポートし、アクセスが容易。

適用例:

Windowsアプリケーションが必要な場合。
データ共有や一部業務プロセスのバックアップ。

4. AWS DataSync

特徴:

オンプレミスからAWSにデータを高速転送。
定期的なデータ同期や移行をサポート。

適用例:

定期的なデータバックアップ。
レプリケーションよりも単発のデータ移行が求められる場面。

災害復旧の4つのパターン

AWSでは、以下の4つのDRパターンが一般的に使用されます：

1. バックアップ＆リストア

概要: データをAWSにバックアップし、災害時に手動で復旧。

利点: コストが低い。

欠点: 復旧時間が長い（RTOが数時間～数日）。

2. パイロットライト

概要: 必要最低限のシステムをAWSに待機させ、災害時に本番環境を立ち上げる。

利点: RTOが短縮される（数十分～数時間）。

欠点: 初期構築と管理に時間がかかる。

3. ウォームスタンバイ

概要: AWS上に縮小版の本番環境を稼働させ、災害時に拡張して本番運用に移行。

利点: RTOがさらに短縮される（数分～数十分）。

欠点: 維持コストがやや高い。

4. マルチサイト（アクティブ-アクティブ）

概要: 本番環境を複数のAWSリージョンで同時稼働させる。

利点: ほぼゼロダウンタイム（RPOとRTOが数秒～数分）。

欠点: 高コスト。

災害復旧計画の設計時に考慮すべきポイント

復旧時点目標（RPO）

データ損失許容時間を示す指標。アプリケーションの重要性に応じて選択。

復旧時間目標（RTO）

システムが復旧するまでの許容時間。RTOが短いほどコストが増加。

運用負担

自動化を進めることで復旧時の人的負担を軽減。

コスト効率

必要な可用性に応じたコスト最適化を検討。

まとめ

AWSは、運用要件やビジネスニーズに応じた柔軟な災害復旧ソリューションを提供しています。特に、迅速な復旧が求められる場合には AWS Elastic Disaster Recovery が適切であり、低コストで高可用性を実現します。一方、ストレージ中心のソリューションや手動操作を含む構成も、ニーズに応じて適用可能です。

正しい戦略を選択することで、効率的な災害復旧とコスト削減を両立することができます。

実践

略

一問道場

質問 #429

ある企業がWindows Serverを使用したアプリケーションを開発し、VMware vSphereの仮想マシン（VM）でオンプレミス環境にホストしています。このアプリケーションのデータは独自フォーマットで保存されており、アプリケーションを介してのみ読み取ることが可能です。サーバーやアプリケーションのプロビジョニングは手動で行われています。

この企業では、災害復旧計画の一環として、オンプレミス環境が利用できなくなった場合にAWS上で一時的にアプリケーションをホストできるようにしたいと考えています。災害復旧後は、アプリケーションをオンプレミス環境に戻すことを希望しています。また、復旧時点目標（RPO）は5分以内である必要があります。

次の選択肢の中で、運用負担を最小限に抑えながら要件を満たすソリューションはどれでしょうか？

選択肢

A. AWS DataSync を構成し、データを Amazon Elastic Block Store (Amazon EBS) ボリュームに複製する。オンプレミス環境が利用できなくなった場合、AWS CloudFormation テンプレートを使用して Amazon EC2 インスタンスをプロビジョニングし、EBS ボリュームをアタッチする。

B. AWS Elastic Disaster Recovery を構成し、データを Amazon Elastic Block Store (Amazon EBS) ボリュームに接続されたレプリケーション用 Amazon EC2 インスタンスに複製する。オンプレミス環境が利用できなくなった場合、Elastic Disaster Recovery を使用してレプリケートされたボリュームを持つ EC2 インスタンスを起動する。

C. AWS Storage Gateway のファイルゲートウェイをプロビジョニングし、データを Amazon S3 バケットに複製する。オンプレミス環境が利用できなくなった場合、AWS Backup を使用してデータを Amazon Elastic Block Store (Amazon EBS) ボリュームに復元し、そのボリュームを使って Amazon EC2 インスタンスを起動する。

D. Amazon FSx for Windows File Server のファイルシステムを AWS 上にプロビジョニングし、データをそのファイルシステムに複製する。オンプレミス環境が利用できなくなった場合、AWS CloudFormation テンプレートを使用して Amazon EC2 インスタンスをプロビジョニングし、AWS::CloudFormation::Init コマンドを使用して Amazon FSx のファイル共有をマウントする。

解説

この問題では、災害復旧のために RPO（復旧時点目標）5分以内 を満たしつつ、オンプレミスとAWSの間でアプリケーションを柔軟に移行できる方法を選ぶ必要があります。また、運用負担を最小限に抑えることが求められています。以下は各選択肢の詳細な解説です。

A. AWS DataSync を構成し、データを Amazon Elastic Block Store (Amazon EBS) ボリュームに複製する

メリット: DataSync はデータの移行や同期を自動化でき、効率的にデータをAWSに送ることが可能。

デメリット: DataSync は主にデータ転送に特化しており、アプリケーション全体を災害復旧の形で再現するには手動でのセットアップが必要。そのため、RPO 5分を達成するには運用負担が大きい。

評価: 運用負担が大きいため不適切。

B. AWS Elastic Disaster Recovery を構成し、データを Amazon EBS ボリュームに接続されたレプリケーション用 Amazon EC2 インスタンスに複製する

メリット: Elastic Disaster Recovery はオンプレミス環境をAWS上にレプリケーションし、障害発生時にほぼリアルタイムでAWS上のEC2インスタンスを起動可能。運用が自動化されており、RPO 5分以内を容易に達成可能。

デメリット: 初期設定が必要だが、運用負担は他の選択肢に比べて低い。

評価: 自動化が進んでおり運用負担が最小。この選択肢が最適。

C. AWS Storage Gateway のファイルゲートウェイをプロビジョニングし、データを Amazon S3 に複製する

メリット: Storage Gateway はオンプレミスとAWS間のデータ複製に便利。S3にデータを保存するため、コスト面で有利。

デメリット: データ復元とEC2インスタンスの起動が手動となり、復旧プロセス全体の自動化が難しい。RPO 5分以内を達成するには不適切。

評価: 手動操作が必要なため、運用負担が大きい。

D. Amazon FSx for Windows File Server のファイルシステムを使用する

メリット: FSxはWindowsアプリケーション向けの共有ファイルストレージとして優れており、データの可用性を確保できる。

デメリット: データレプリケーションとインスタンス起動を別々に管理する必要があり、運用負担が大きい。RPO 5分以内を達成するのは難しい。

評価: 他の選択肢と比べて運用が煩雑で、最適ではない。

正解: B

AWS Elastic Disaster Recovery を使用することで、運用負担を最小限に抑えながら RPO 5分以内の災害復旧を実現できます。このサービスは自動化が進んでおり、オンプレミスの環境をAWSに迅速かつ効率的に移行することが可能です。

430-AWS SAP AWS 「理論・実践・一問道場」S3クロスリージョンレプリケーション

理論

S3のデータ転送とレプリケーションに関する知識

S3 Transfer Acceleration:

目的: S3 Transfer Accelerationは、特に遠隔地からのデータアップロードを加速する機能です。インターネット経由でデータを送るのではなく、Amazonのエッジロケーションを経由してデータをS3に転送します。これにより、転送時間が短縮され、遅延を減少させることができます。

S3 クロスリージョンレプリケーション (CRR):

目的: S3バケット間でデータを自動的に複製する機能です。これを使用すると、異なるリージョンにデータがレプリケートされ、データアクセスの遅延を減少させます。特にグローバルに分散したアプリケーションでのデータアクセス速度向上に役立ちます。

S3のデータアクセス最適化:

近接性: データがユーザーの地理的に近い場所に保存されると、アクセス時間が短縮されます。例えば、ユーザーがデータにアクセスする際、そのデータがローカルリージョンのS3バケットにあると、ネットワーク遅延を最小化できます。

冗長性と可用性: クロスリージョンレプリケーションは、データの冗長性を確保するだけでなく、災害復旧にも役立ちます。データが複数のリージョンにレプリケートされていれば、1つのリージョンで障害が発生しても、他のリージョンからデータを利用できます。

マルチパートアップロード:

用途: 非常に大きなファイルを複数のパーツに分けてアップロードする方法です。これにより、アップロードの効率が向上し、途中で転送が中断された場合でも再開できますが、遅延の改善には直接関係しません。

これらの機能を適切に組み合わせることで、S3バケットへのデータ転送を最適化し、遅延を減少させることができます。

実践

略

一問道場

ある企業が、Amazon EC2 を使用して eu-north-1 リージョンで高可用性のデータ収集アプリケーションを実行しています。このアプリケーションは、エンドユーザーのデバイスからデータを収集し、Amazon Kinesis Data Stream と一連の AWS Lambda 関数にレコードを書き込みます。企業はレコード処理の結果を Amazon S3 バケットに保存しており、このバケットのデータは Amazon Athena のデータソースとして使用されています。

企業はグローバルな展開を進めており、sa-east-1 と ap-northeast-1 リージョンにもデータ収集機能を展開する必要があります。ソリューションアーキテクトは、アプリケーション、Kinesisデータストリーム、Lambda関数を新しい2つのリージョンに展開しましたが、S3バケットはeu-north-1に残し、データ分析の集中化要件を満たします。

新しいセットアップのテスト中、ソリューションアーキテクトは、新しいリージョンからS3バケットへのデータ到着に遅延が発生していることに気付きました。

この遅延時間を最も改善する方法はどれですか？

A. 新しい2つのリージョンで、Lambda関数をVPC内で実行するように設定し、そのVPCにS3ゲートウェイエンドポイントを設定する。

B. S3バケットでS3 Transfer Acceleration を有効にし、アプリケーションがデータをS3バケットにアップロードする際に、新しいS3加速エンドポイントを使用するようにアプリケーションを変更する。

C. 新しい2つのリージョンにそれぞれS3バケットを作成し、各リージョンのアプリケーションがそのリージョンのS3バケットにデータをアップロードするように設定する。その後、S3クロスリージョンレプリケーション を設定し、データをeu-north-1のS3バケットにレプリケートする。

D. Lambda関数のメモリ要件を増やし、複数のコアを使用できるようにする。アプリケーションがLambdaからAmazon S3にデータをアップロードする際に、マルチパートアップロード 機能を使用する。

解説

この問題は、新しいリージョンから既存の中央S3バケットへのデータの遅延を解消するための最適な方法を選ぶものです。遅延が発生する原因としては、データ転送の距離や帯域幅、ネットワークの混雑などが考えられます。解決方法としては、転送速度の最適化やデータのレプリケーションがキーとなります。

各選択肢の解説

A. Lambda関数をVPC内で実行し、S3ゲートウェイエンドポイントを設定する

VPC内でLambda関数を実行し、S3ゲートウェイエンドポイントを設定すると、Lambda関数がVPC内で直接S3にアクセスできるようになります。これにより、インターネット経由でのアクセスを避け、通信の効率が上がる可能性があります。しかし、データ転送の遅延自体の改善にはつながりません。遅延の原因は主にリージョン間の距離や帯域幅の制限にあるため、この選択肢は最適ではありません。

B. S3 Transfer Accelerationを有効にし、アプリケーションに加速エンドポイントを使用させる

S3 Transfer Acceleration は、Amazon S3へのデータ転送を加速する機能で、特に 遠隔地からのアップロード に効果的です。この機能を有効にすると、データが最寄りのエッジロケーションを通じてS3に送信され、転送速度が改善されます。グローバルなデータ転送の遅延を最小化できるため、この選択肢は遅延改善に有効です。

C. 新しい2つのリージョンにS3バケットを作成し、S3クロスリージョンレプリケーションを設定する

S3クロスリージョンレプリケーション（CRR）は、異なるリージョン間でS3バケットのデータを自動的にレプリケートする機能です。これにより、各リージョンでデータがローカルに保存され、データの到着時間を短縮することができます。データが直接そのリージョン内のS3バケットに保存されるため、遅延が大幅に改善されます。しかし、この方法では中央のS3バケットが必要な要件に影響を与えず、最終的にデータはそのバケットに集約されることになります。データのレプリケーションにより、遅延が最も効果的に改善される方法です。

D. Lambda関数のメモリ要件を増やし、マルチパートアップロードを使用する

Lambda関数のメモリを増やすことは、計算能力や処理速度を向上させるかもしれませんが、データ転送の遅延を直接改善するわけではありません。また、マルチパートアップロードは、非常に大きなファイルを分割してアップロードする際に有効ですが、遅延改善にはあまり寄与しません。

最適な選択肢

C. S3クロスリージョンレプリケーションが最も効果的な選択肢です。この方法では、各リージョンにデータをレプリケートし、ローカルでデータを利用できるようにするため、データの到着時間を短縮できます。また、中央S3バケットの要件も満たしつつ、遅延を大きく改善することができます。