type
status
date
slug
summary
tags
category
icon
password
171-AWS SAP AWS 「理論・実践・一問道場」AWS CodeCommit
理論
AWS CodeCommitは、完全に管理されたGitリポジトリサービスで、ソースコードを安全に保存・管理できます。AWSインフラに基づいてスケーラブルで、高可用性とセキュリティを提供します。Git互換のため、既存のツールやワークフローを利用できます。AWSの他のサービス(CodePipelineやCodeBuild)と統合可能で、CI/CDパイプラインを自動化するのに便利です。
AWS CodeCommit リポジトリのバックアップ
AWS CodeCommitは、AWSの管理されたGitリポジトリサービスで、開発者がソースコードを安全に管理するために使います。しかし、CodeCommitはリージョン間でのデータ冗長性やバックアップを自動で行っていません。そのため、異なるリージョンにバックアップを保存するには、追加のアーキテクチャやサービスを使用する必要があります。
重要な考慮事項
- バックアップの頻度と復旧の要件: バックアップの目的に応じて、復旧時間目標(RTO)や復旧点目標(RPO)が決まります。例えば、企業によってはCodeCommitのデータを24時間に1回バックアップしたい場合もありますし、より頻繁にバックアップを行いたい場合もあります。バックアップが必要なタイミングとその内容を適切に設計することが重要です。
- リージョン間のデータ同期: CodeCommitはデフォルトでリージョン間の自動同期を行いません。したがって、別リージョンにバックアップを保存するためには、手動でリポジトリをコピーする必要があります。
実現方法
- バックアップの方法:
- EventBridge と CodeBuild: CodeCommitのイベントをAmazon EventBridgeでトリガーし、変更がある度にAWS CodeBuildを使ってリポジトリのクローンを作成する方法です。これにより、リポジトリのバックアップを定期的に別リージョンに保存できます。AWS CodeBuildを使うことで、リポジトリのデータをプログラム的にバックアップすることができます。
- 手動または自動スクリプト: 変更の度に、Gitクローンコマンドやスクリプトを使ってリポジトリの内容を圧縮して別リージョンのS3にコピーする方法です。この方法は、管理が容易で、コストを最小限に抑えながら実現可能です。
- バックアップ戦略: バックアップをどのタイミングで実行するか、またどれくらいの期間データを保持するかの方針を決めることが大切です。CodeCommitに対するバックアップ戦略は、リポジトリの更新頻度や企業のニーズに基づいて、設計する必要があります。
おすすめアーキテクチャ
- 自動化されたバックアッププロセス: Amazon EventBridgeを利用して、CodeCommitのイベント(例えばコードのプッシュ)をトリガーし、AWS CodeBuildでクローンと圧縮を行い、S3バケットに保存する流れを作ることが最適です。この方法は、バックアップの手間を減らし、頻繁な変更に対してもリアルタイムで対応できます。
- コスト管理: バックアップにかかるコストやS3ストレージのコストを管理し、適切なストレージクラス(例えば、S3 Glacierなど)を選択することでコストを最適化することも考慮する必要があります。
結論
AWS CodeCommitのバックアップは、別リージョンに保存するためには、手動でGitリポジトリをクローンするか、Amazon EventBridgeとCodeBuildを使用して自動化する方法が考えられます。手動バックアップと自動化されたバックアップにはそれぞれの利点があり、企業のニーズや要件に応じて選択することが重要です。
実践
略
一問道場
問題 #171
トピック
ある企業がAWS CodeCommitリポジトリを使用しています。企業は、リポジトリ内のデータを別のAWSリージョンにバックアップコピーとして保存する必要があります。
どのソリューションがこの要件を満たしますか?
A. AWS Elastic Disaster Recoveryを使用して、CodeCommitリポジトリデータを第二リージョンに複製する。
B. AWS Backupを使用して、CodeCommitリポジトリを毎時バックアップし、第二リージョンにクロスリージョンコピーを作成する。
C. Amazon EventBridgeルールを作成し、企業がリポジトリにコードをプッシュするとAWS CodeBuildを呼び出す。CodeBuildを使用してリポジトリをクローンし、コンテンツの.zipファイルを作成する。そのファイルを第二リージョンのS3バケットにコピーする。
D. AWS Step Functionsワークフローを毎時スケジュールで作成し、CodeCommitリポジトリのスナップショットを取得する。ワークフローを構成して、そのスナップショットを第二リージョンのS3バケットにコピーする。
解説
問題では、AWS CodeCommitリポジトリのデータを別のAWSリージョンにバックアップする方法を尋ねています。解答の選択肢は以下のようになっています。
選択肢の解説:
- A. AWS Elastic Disaster RecoveryでCodeCommitリポジトリデータを別のリージョンに複製する
不適切: AWS Elastic Disaster Recoveryは主にEC2インスタンスやオンプレミスの仮想マシンなどの復旧用に使用されます。CodeCommitリポジトリに適用するものではありません。
- B. AWS BackupでCodeCommitリポジトリをバックアップし、別のリージョンにクロスリージョンコピーを作成する
不適切: AWS Backupは主にRDSやEC2などのリソースのバックアップに使用されますが、CodeCommitリポジトリのバックアップには対応していません。
- C. Amazon EventBridgeルールを作成し、CodeCommitにコードがプッシュされるたびにAWS CodeBuildを起動してリポジトリをクローンし、ZIPファイルにしてS3バケットにコピーする
適切: この方法は、CodeCommitリポジトリにコードがプッシュされるたびにイベントをトリガーして、CodeBuildでリポジトリをクローンし、S3バケットにバックアップを保存する方法です。Cross-Regionでバックアップを管理するために適切な手段となります。
- D. AWS Step Functionsワークフローを作成し、CodeCommitリポジトリのスナップショットを毎時間取得し、S3バケットにコピーする
不適切: Step Functionsは複雑なワークフローを構築するためのサービスですが、CodeCommitリポジトリのスナップショットの取得はサポートされていません。
正解:
C. Amazon EventBridgeルールを作成し、CodeCommitにコードがプッシュされるたびにAWS CodeBuildを起動してリポジトリをクローンし、ZIPファイルにしてS3バケットにコピーする
この選択肢は、CodeCommitリポジトリのバックアップを別リージョンに作成するための最も実践的な方法です。EventBridgeでコードのプッシュイベントをキャッチし、CodeBuildを使ってリポジトリをクローンし、バックアップをS3に保存します。
172-AWS SAP AWS 「理論・実践・一問道場」
理論

1. VPC間接続とCIDR範囲の重複
- CIDR範囲が重複しているVPC同士の接続: CIDR範囲が重複するVPC間で直接的なIP通信を行うことはできません。VPCピアリングやVPN接続などの手法を使用しても、CIDRが重複しているとルーティングが衝突します。この問題を回避するためには、重複しないCIDRを使用するか、VPCピアリングの代わりに他の方法(例:AWS PrivateLink)を使用する必要があります。
2. AWS PrivateLink
- AWS PrivateLink: このサービスは、異なるVPC間でプライベートIPアドレスを使って、安全にサービスを共有するためのものです。PrivateLinkは、セキュリティ、スケーラビリティ、運用管理の効率性を高めるために最適化されており、VPC間の接続における最適解です。重複するCIDR範囲の問題を回避できるため、異なるAWSアカウント間で簡単にサービスを共有することができます。
3. Network Load Balancer (NLB) と API Gateway
- *NLB (Network Load Balancer)**は、非常に高いスループットと低遅延でトラフィックを処理できる負荷分散サービスです。API Gatewayと組み合わせて使用する場合、エンドポイントを公開して、異なるアカウントやVPCからのアクセスを管理できます。ただし、このアプローチでは、IAM認証やAPI Gatewayの設定が必要となり、AWS PrivateLinkに比べて少し複雑な運用が求められます。
4. 運用オーバーヘッドと簡素化
- 最小限の運用オーバーヘッド: 運用オーバーヘッドを最小化するためには、インフラの管理が簡単で、各VPCやアカウントにまたがるアクセスの設定が一元化できる方法を選択することが重要です。AWS PrivateLinkは、アクセス管理を効率化し、リソースの複雑さを減らすことができるため、運用の簡素化に貢献します。
5. セキュリティとプライベートアクセス
- セキュアなアクセス: インターネット経由でアクセスするのではなく、プライベートIPアドレスを使用してアクセスすることで、セキュリティリスクを低減します。PrivateLinkは、VPC間でインターネットを介さず、セキュアな接続を提供するため、プライベートアクセスの要件に適しています。
実践
略
一問道場
問題 #172
トピック
ある企業には、各事業部が別々のAWSアカウントを持っており、それぞれの事業部が複数のVPCを管理しています。それぞれのVPCのCIDR範囲は重複しています。企業のマーケティングチームは新しい内部アプリケーションを作成し、他のすべての事業部からアプリケーションへのアクセスを希望しています。ソリューションはプライベートIPアドレスのみを使用する必要があります。
最小限の運用オーバーヘッドでこれらの要件を満たすソリューションはどれですか?
A. 各事業部にVPCに一意なセカンダリCIDR範囲を追加するよう指示します。VPCをピアリングし、セカンダリ範囲内にプライベートNATゲートウェイを使用してマーケティングチームへのトラフィックをルーティングします。
B. マーケティングアカウントのVPCに仮想アプライアンスとしてAmazon EC2インスタンスを作成します。マーケティングチームと各事業部のVPC間でAWS Site-to-Site VPN接続を作成し、必要に応じてNATを実行します。
C. AWS PrivateLinkエンドポイントサービスを作成し、マーケティングアプリケーションを共有します。特定のAWSアカウントに接続権限を付与し、他のアカウントでインターフェイスVPCエンドポイントを作成して、プライベートIPアドレスを使用してアプリケーションにアクセスします。
D. マーケティングアプリケーションの前にNetwork Load Balancer(NLB)を作成し、プライベートサブネット内に配置します。API Gateway APIを作成し、Amazon API Gatewayプライベートインテグレーションを使用してAPIをNLBに接続します。APIにIAM認証を有効にし、他の事業部のアカウントにアクセス権を付与します。
解説
この問題では、異なるAWSアカウントに所属する複数のビジネスユニットが管理するVPC(仮想プライベートクラウド)間で、マーケティングチームの内部アプリケーションにプライベートIPアドレスを使ってアクセスする方法を問われています。CIDR(Classless Inter-Domain Routing)範囲が重複しているため、VPCピアリングやVPN接続を使うだけでは問題があります。解決策は、異なるアカウントやVPC間でのアクセスを効率的かつセキュアに行える方法を選ぶことです。
解決策の選択肢:
- A. VPCピアリングとNATゲートウェイの使用
- 各ビジネスユニットのVPCに一意のセカンダリCIDR範囲を追加して、VPCをピアリングし、NATゲートウェイを使用してマーケティングチームのアプリケーションにアクセスする方法です。この方法は、CIDR範囲の重複に対応するための手段を提供しますが、VPC間の接続の管理や運用オーバーヘッドが増加します。また、VPC間での複雑なルーティング設定が必要です。
- B. EC2インスタンスを使用してVPN接続を行う方法
- マーケティングチームのVPCに仮想アプライアンスを作成し、各ビジネスユニットのVPCに対してSite-to-Site VPN接続を確立する方法です。NATも必要となる可能性があり、複雑な設定が必要です。また、運用がやや手間がかかります。
- C. AWS PrivateLinkを使用する方法(正解)
- AWS PrivateLinkを使用して、マーケティングチームのアプリケーションを共有する方法です。特定のAWSアカウントにアクセス権を付与し、他のアカウントでインターフェイスVPCエンドポイントを作成してプライベートIPアドレスを使ってアクセスします。PrivateLinkは、VPC間でインターネットを使わずに安全に接続するため、CIDR範囲の重複を気にせずにシンプルかつ効率的にサービスを共有できます。これにより、運用オーバーヘッドが最小限に抑えられます。
- D. NLBとAPI Gatewayを使用する方法
- Network Load Balancer(NLB)を前面に配置し、API Gatewayを使ってアプリケーションを公開する方法です。API Gatewayのプライベート統合を使用してNLBに接続し、IAM認証を有効にしてアクセス管理を行います。この方法もプライベートアクセスを提供しますが、API GatewayやIAM認証の設定が必要なため、PrivateLinkに比べて運用が少し複雑になります。
正解の理由:
C. AWS PrivateLinkを使用する方法が最適です。理由は以下の通りです:
- CIDR範囲の重複問題を回避:PrivateLinkはインターネットを介さず、プライベートIPアドレスでVPC間接続を提供します。このため、CIDR範囲が重複していても問題なく機能します。
- 運用オーバーヘッドの最小化:PrivateLinkは、インターフェイスVPCエンドポイントを作成して簡単に設定できるため、運用の手間を減らすことができます。これにより、VPC間での接続管理が簡素化されます。
- セキュアな接続:VPC間の通信がプライベートIPアドレスで行われ、インターネットを経由しないため、安全性が高いです。
他のオプションは、VPCピアリングやVPN接続、NLB + API Gatewayなど、追加の設定や運用管理が必要になるため、より複雑で運用負荷が増加します。
結論:
最も簡単かつ効率的な解決策は、AWS PrivateLinkを使用する方法です。
173-AWS SAP AWS 「理論・実践・一問道場」
理論
IAM Access Analyzer と EventBridge の基本
- IAM Access Analyzer: AWS リソースのポリシーを分析し、意図しない公開を検出します。
- 特長: S3バケットの公開状態を含むアクセスリスクをリアルタイムで通知。
- 適用例: バケットが公開された場合に特定のアクションを実行する自動化。
- Amazon EventBridge: AWS サービス間でイベントを統合するサービス。
- 特長: IAM Access Analyzer のイベントをトリガーとして、通知やアクションを設定可能。
- 設定例: "isPublic:true" イベントをSNSトピックに通知するルールを作成。
これにより、組織のセキュリティ監視を効率的に強化できます。
実践
一問道場
企業は新たに取得したAWSアカウントのセキュリティ姿勢を監査する必要があります。企業のデータセキュリティチームは、Amazon S3バケットが公開される場合のみ通知を受け取ることを要求しています。企業はすでにデータセキュリティチームのメールアドレスが登録されたAmazon Simple Notification Service(Amazon SNS)トピックを確立しています。
どのソリューションがこの要件を満たしますか?
A
すべてのS3バケットに対してisPublicイベントのS3イベント通知を作成します。SNSトピックをイベント通知のターゲットとして選択します。
B
AWS Identity and Access Management(IAM)Access Analyzerでアナライザーを作成します。「Access Analyzer Finding」イベントタイプのAmazon EventBridgeルールを作成し、「isPublic:true」のフィルターを設定します。SNSトピックをEventBridgeルールのターゲットとして選択します。
C
「Bucket-Level API Call via CloudTrail」イベントタイプのAmazon EventBridgeルールを作成し、「PutBucketPolicy」のフィルターを設定します。SNSトピックをEventBridgeルールのターゲットとして選択します。
D
AWS Configを有効にし、cloudtrail-s3-dataevents-enabledルールを追加します。「Config Rules Re-evaluation Status」イベントタイプのAmazon EventBridgeルールを作成し、「NON_COMPLIANT」のフィルターを設定します。SNSトピックをEventBridgeルールのターゲットとして選択します。
解説
この問題の目的は、Amazon S3バケットが公開されるときに通知を受け取る方法を提供することです。要件に従って、正しいソリューションを選ぶために、それぞれのオプションを分析していきます。
オプションの分析
A. S3イベント通知を作成
- 解説: S3イベント通知は、S3バケットに対して特定のアクション(例えば、
isPublic
イベント)を監視する方法ですが、Amazon S3自体には「isPublic」という標準的なイベントが存在しません。そのため、このオプションは適切ではありません。
B. IAM Access AnalyzerとEventBridgeルールの作成
- 解説: IAM Access Analyzerは、アクセス制御ポリシーを分析し、リソースの公開状態を評価します。
isPublic:true
というフィルターを使って、バケットが公開されるイベントを監視することができます。この方法は、要件に合致しており、SNSトピックに通知を送信するため、正しい選択肢です。
C. CloudTrailを使ったAPIコールの監視
- 解説: CloudTrailの
PutBucketPolicy
イベントは、S3バケットポリシーが変更された際に発生しますが、公開設定が行われたかどうかを確認するためには、ポリシー自体の内容を解析する必要があります。直接的に「公開された」かどうかを検出するわけではないため、このオプションは不適切です。
D. AWS ConfigとEventBridgeルールの作成
- 解説: AWS Configはリソースの設定を監視し、変更があった場合に通知を送信します。しかし、「NON_COMPLIANT」の状態はリソースがAWS Configのルールに違反したときに通知されるもので、公開されたS3バケットを特定するための専用のルールが必要です。したがって、このオプションも適切ではありません。
結論
最も適切な解決策は B です。AWS IAM Access Analyzerを使用して、バケットが公開されているかどうかを検出し、EventBridgeを使って通知を送信できます。このアプローチは、公開状態に関する要件を満たす最も効率的な方法です。
174-AWS SAP AWS 「理論・実践・一問道場」AWS Migration Hub
理論
「ポートフォリオ」とは、ITの文脈では、企業が保有する全てのアプリケーション、サービス、データベース、インフラストラクチャの一覧や集合体を指します。
- 目的: すべての資産を可視化し、管理、最適化、移行の計画を立てるため。
- 例: ある会社が複数の業務アプリ、データベース、オンプレミスサーバーを持っている場合、それら全てがポートフォリオの一部となります。
AWS移行の場合、ポートフォリオを評価することで、移行対象を把握し、計画が立てやすくなります。
オンプレミスからAWSへの移行
オンプレミス環境からAWSへの移行を計画する際、ポートフォリオの評価は重要なステップです。ここでは、関連するサービスとベストプラクティスを簡潔に説明します。
1. AWS Migration Hub
- 概要: 複数のAWS移行サービスを一元管理するためのハブ。
- 役割: アプリケーションとサーバーの移行状況を可視化し、進捗を追跡可能。
- 利用場面: 複数の移行プロジェクトを同時に管理する場合。
2. Migration Evaluator
- 概要: オンプレミスのサーバーインフラの評価を支援するツール。
- 役割: サーバー構成、使用状況、コストデータを収集し、AWS移行のビジネスケースを構築。
- 利用場面: 移行計画を立てる前に、全体的なインフラを把握したい場合。
3. AWS Application Discovery Service
- 概要: オンプレミス環境の詳細なデータ収集と依存関係のマッピングを行うサービス。
- 役割: アプリケーション間の依存関係を特定し、移行の影響範囲を分析。
- 利用場面: アプリケーションの依存関係を理解する必要がある場合。
4. 移行のステップ
- 評価:
- Migration Evaluatorでインフラを評価。
- Application Discovery Serviceで依存関係を分析。
- 計画:
- Migration Hubで移行計画を統合。
- 適切なAWSサービスを選定。
- 実行:
- AWS Server Migration Service (AWS SMS)やDatabase Migration Service (AWS DMS)を利用して移行。
- 検証:
- 移行後の環境をテストし、最適化。
5. 関連ツールの使い分け
- Migration Evaluator: コスト面での移行メリットを分析。
- Application Discovery Service: アプリケーション依存関係の詳細を把握。
- Migration Hub: 移行プロジェクト全体の進捗を管理。
6. 移行における課題と解決策
- 課題: オンプレミス環境のドキュメントが不十分である場合。
- 解決策: Application Discovery Serviceを使用してデータを自動収集。
- 課題: バッチ処理などの特定のワークロードの特性を理解。
- 解決策: Migration Evaluatorでピーク時の使用状況を評価。
AWSの移行ツールを適切に組み合わせることで、移行プロセスを効率化し、コストを最適化できます。このステップに従うことで、安全かつ確実な移行を実現可能です。
実践
略
一問道場
質問 #174
トピック 1
ソリューションアーキテクトは、新しく買収した企業のアプリケーションとデータベースのポートフォリオを評価する必要があります。このソリューションアーキテクトは、ポートフォリオをAWSに移行するためのビジネスケースを作成する必要があります。新しく買収した企業はオンプレミスのデータセンターでアプリケーションを実行していますが、このデータセンターは十分に文書化されていません。そのため、アプリケーションやデータベースの数を即座に特定することができません。アプリケーションのトラフィックは変動があり、一部のアプリケーションは毎月末に実行されるバッチ処理です。
ソリューションアーキテクトは、AWSへの移行を開始する前に、ポートフォリオについてより深く理解する必要があります。
この要件を満たすソリューションはどれですか?
A. AWS Server Migration Service (AWS SMS)とAWS Database Migration Service (AWS DMS)を使用して移行を評価します。AWS Service Catalogを使用してアプリケーションとデータベースの依存関係を理解します。
B. AWS Application Migration Serviceを使用します。オンプレミスのインフラストラクチャにエージェントを実行し、AWS Migration Hubでエージェントを管理します。AWS Storage Gatewayを使用してローカルストレージのニーズとデータベースの依存関係を評価します。
C. Migration Evaluatorを使用してサーバーのリストを生成します。ビジネスケース用のレポートを作成します。AWS Migration Hubを使用してポートフォリオを表示します。AWS Application Discovery Serviceを使用してアプリケーションの依存関係を理解します。
D. 移行先アカウントでAWS Control Towerを使用してアプリケーションポートフォリオを生成します。AWS Server Migration Service (AWS SMS)を使用して詳細なレポートとビジネスケースを生成します。コアアカウントとリソースのためにランディングゾーンを使用します。
解説
問題概要:
新たに買収した会社のオンプレミスデータセンターのアプリケーションやデータベースをAWSに移行するためのビジネスケースを作成したい。しかし、データセンターは十分に文書化されておらず、アプリケーションやデータベースの数も不明である。変動するトラフィックや月末のバッチ処理を考慮しつつ、ポートフォリオを理解する必要がある。
各選択肢の評価
A: AWS SMS、AWS DMS、AWS Service Catalog を使用
- メリット: AWS SMSとAWS DMSは移行に役立つツール。
- 問題点: AWS Service Catalogはアプリケーションやデータベースの依存関係を直接評価するツールではない。初期評価には不適切。
- 評価: 不適切
B: AWS Application Migration Service、AWS Migration Hub、AWS Storage Gateway を使用
- メリット: AWS Application Migration ServiceとMigration Hubでオンプレミスのインフラを可視化できる。
- 問題点: Storage Gatewayはローカルストレージのニーズ評価には役立つが、アプリケーション依存関係の評価には不向き。
- 評価: 部分的に適切だが不足
C: Migration Evaluator、AWS Migration Hub、AWS Application Discovery Service を使用
- メリット:
- Migration Evaluator: サーバーリストを生成し、移行のためのコスト分析を実施。
- Migration Hub: ポートフォリオ全体を一元管理。
- Application Discovery Service: アプリケーションの依存関係を理解。
- 問題点: なし。この方法は問題の要件を完全に満たす。
- 評価: 最適な選択肢
D: AWS Control Tower、AWS SMS、ランディングゾーンを使用
- メリット: AWS Control Towerはマルチアカウント管理に便利。
- 問題点: アプリケーションポートフォリオの生成には不適切。SMSは深いレポート生成に限られる。
- 評価: 不適切
正解: C
理由: Migration Evaluator、Migration Hub、Application Discovery Serviceを組み合わせることで、ポートフォリオ全体を可視化し、依存関係を含めた詳細な分析が可能になる。問題の要件を最も効率的かつ包括的に満たすソリューションです。
175-AWS SAP AWS 「理論・実践・一問道場」AWS Backup
理論
分散システムにおけるストレージ選択のポイント
- ストレージタイプの特徴
- Amazon EFS: 複数インスタンスから同時アクセス可能な共有ストレージ。高可用性とスケーラビリティが特徴。
- Amazon EBS: 高速ブロックストレージ。Multi-Attachで共有可能だが、主に単一ポッド向け。
- Amazon S3: オブジェクトストレージ。大容量データ保存やアーカイブに最適。
- ローカルストレージ: 一時的なデータ保存用で高速だが、永続性はなし。
- バックアップ戦略
- AWS Backup: EFSやEBSなどの自動バックアップ管理。
- S3バージョニング: データ変更の保護とライフサイクル管理。
- クラウドネイティブツール: Kubernetes全体のバックアップにVeleroなどを使用。
- Kubernetes統合
- Persistent Volume (PV)とClaim (PVC): ストレージ利用の抽象化。
- CSIプラグイン: ストレージ管理を簡略化。
- 耐障害性とパフォーマンス
- アベイラビリティゾーン間でデータを共有(EFS, S3)。
- アクセス頻度とデータサイズに基づいたストレージ選択(EBS: 高速、EFS: 共有、S3: 大容量)。
実践
略
一問道場
Question #175
トピック 1
ある企業では、Amazon Elastic Kubernetes Service(Amazon EKS)クラスター内で複数のポッドのReplicaSetとしてアプリケーションを実行しています。このEKSクラスターには、複数のアベイラビリティゾーンにノードがあります。アプリケーションは多くの小さなファイルを生成し、これらのファイルはアプリケーションのすべての実行インスタンスでアクセス可能である必要があります。さらに、これらのファイルを1年間バックアップして保持する必要があります。
要件を満たしながら、最速のストレージパフォーマンスを提供するソリューションはどれですか?
A: Amazon Elastic File System(Amazon EFS)ファイルシステムを作成し、EKSクラスター内のノードを含む各サブネットにマウントターゲットを設定します。ReplicaSetをファイルシステムをマウントするよう構成し、アプリケーションにファイルをそのファイルシステムに保存するよう指示します。AWS Backupを構成してデータをバックアップし、1年間保持します。
B: Amazon Elastic Block Store(Amazon EBS)ボリュームを作成します。EBS Multi-Attach機能を有効にし、ReplicaSetをEBSボリュームをマウントするよう構成します。アプリケーションにファイルをEBSボリュームに保存するよう指示します。AWS Backupを構成してデータをバックアップし、1年間保持します。
C: Amazon S3バケットを作成します。ReplicaSetをS3バケットをマウントするよう構成し、アプリケーションにファイルをS3バケットに保存するよう指示します。S3バージョニングを構成してデータのコピーを保持し、S3ライフサイクルポリシーを構成して1年後にオブジェクトを削除します。
D: ReplicaSetを、実行中の各アプリケーションポッドで利用可能なストレージを使用してローカルにファイルを保存するよう構成します。サードパーティツールを使用して、EKSクラスターを1年間バックアップします。
解説
解説: EKSクラスタでのストレージ選択
この問題は、EKS(Elastic Kubernetes Service)クラスタ上で動作するアプリケーションに最適なストレージとバックアップ戦略を選ぶことを問われています。以下に選択肢の分析を示します。
選択肢の分析
A: Amazon EFSを使用する(正解)
- 理由:
- 共有ストレージ: EFSは複数のポッドから同時にアクセス可能で、アプリケーション間でデータを簡単に共有できます。
- バックアップ: AWS Backupを利用して自動的にデータを1年間保持できます。
- パフォーマンス: EFSはNFS(Network File System)ベースのサービスで、高スループットが求められる用途に最適。
- 結論: 要件(高速性、共有性、バックアップ)をすべて満たします。
B: Amazon EBSを使用する
- 問題点:
- 制限的な共有性: EBSのMulti-Attachを利用しても、複数ノードでの使用には制約があり、EKSのReplicaSetの全ポッドでの同時使用は難しい。
- 運用の複雑性: 各ポッドに対して個別にEBSをアタッチする必要があるため、運用負荷が高い。
C: Amazon S3を使用する
- 問題点:
- ファイルシステムではない: S3はオブジェクトストレージであり、ファイルシステムとしての利用には適さない。
- パフォーマンスの問題: S3はデータの書き込みや読み取りに時間がかかる場合があり、リアルタイムアクセスが必要なシナリオには不向き。
D: ローカルストレージを使用する
- 問題点:
- データの永続性が不足: 各ポッドのローカルストレージに依存するため、ポッド再作成時にデータが失われる可能性が高い。
- バックアップの管理が難しい: サードパーティツールを用いたバックアップは管理が複雑になる。
結論: Aが最適
- Amazon EFSを使用する選択肢は、アプリケーションの特性(小さいファイルの共有、高速性)と要件(1年間のバックアップ保持)に完全に適合します。AWS Backupで簡単に管理でき、複数アベイラビリティゾーン間での共有も可能です。
176-AWS SAP AWS 「理論・実践・一問道場」Amazon Pinpoint
理論
1. Amazon Connect
- 用途: Amazon Connectは、クラウドベースのコンタクトセンターサービスで、インバウンドおよびアウトバウンドの通話を管理するためのソリューションを提供します。従来のオンプレミスの電話システムの代替として使用され、迅速にスケーラブルで柔軟な環境を提供します。
- メリット: オンプレミスのシステムに比べて、設備の管理やメンテナンスが不要で、ダウンタイムのリスクが低減します。また、AIを活用した自動応答システムやインタラクティブボイスレスポンス(IVR)機能を簡単に統合できます。
2. Amazon Pinpoint
- 用途: Amazon Pinpointは、ターゲットを絞ったマーケティングキャンペーン、通知、アンケートなどを通じて顧客と連絡を取るためのサービスです。多くの場合、モバイルアプリやSMS(テキストメッセージ)を通じて顧客との双方向のやりとりを行うために使用されます。
- メリット: 顧客へのメッセージ配信のために、高いスケーラビリティを持つプラットフォームを提供します。また、ユーザーの応答や行動に基づいてカスタマイズされたメッセージを送信することができ、効果的な顧客エンゲージメントを実現します。
3. Amazon SNS (Simple Notification Service)
- 用途: SNSは、メッセージングサービスで、プッシュ通知やSMSメッセージを高スケーラビリティで送信するために使用されます。主にサーバーレスで動作し、個別またはグループへのメッセージ配信が可能です。
- メリット: SNSは、他のAWSサービス(Lambda、SQSなど)と簡単に統合でき、メッセージの配信に関する設定や運用負担を軽減します。
4. 運用の最小化
- AWSを活用することで、オンプレミスのインフラストラクチャ管理から解放され、運用負担が大幅に軽減されます。特に、Amazon ConnectやPinpointは、設定が簡単で、スケーラブルで柔軟性があり、運用管理の負担を最小限に抑えるため、企業はインフラ管理に費やすリソースを削減できます。
実践
略
一問道場
Question #176
Topic 1
ある企業が、顧客サービスセンターを運営しています。このセンターでは、電話を受け付けた後、すべての顧客に対して管理されたインタラクティブな双方向アンケートをテキストメッセージで送信しています。
企業の顧客サービスセンターを支えるアプリケーションは、オンプレミスのデータセンター内でホストされているマシン上で稼働しています。しかし、使用しているハードウェアが古く、システムのダウンタイムが発生しています。このため、企業はシステムをAWSに移行し、信頼性を向上させたいと考えています。
どのソリューションが、最小限の運用オーバーヘッドでこれらの要件を満たしますか?
選択肢
A: Amazon Connectを使用して古いコールセンターハードウェアを置き換えます。Amazon Pinpointを使用して顧客にアンケートのテキストメッセージを送信します。
B: Amazon Connectを使用して古いコールセンターハードウェアを置き換えます。Amazon Simple Notification Service(Amazon SNS)を使用して顧客にアンケートのテキストメッセージを送信します。
C: コールセンターソフトウェアをAuto Scalingグループ内のAmazon EC2インスタンスに移行します。これらのEC2インスタンスを使用して顧客にアンケートのテキストメッセージを送信します。
D: Amazon Pinpointを使用して古いコールセンターハードウェアを置き換え、顧客にアンケートのテキストメッセージを送信します。
解説
この問題に関連する本質的な知識は、AWSで提供される顧客サービス向けのサービスと、それに伴う管理や運用の効率化です。特に、コールセンターのハードウェア置き換えや、顧客へのアンケート送信などの機能に関して、AWSがどのように運用負荷を軽減し、信頼性を高めるかについて理解することが重要です。
本質的な知識
1. Amazon Connect
- 用途: Amazon Connectは、クラウドベースのコンタクトセンターサービスで、インバウンドおよびアウトバウンドの通話を管理するためのソリューションを提供します。従来のオンプレミスの電話システムの代替として使用され、迅速にスケーラブルで柔軟な環境を提供します。
- メリット: オンプレミスのシステムに比べて、設備の管理やメンテナンスが不要で、ダウンタイムのリスクが低減します。また、AIを活用した自動応答システムやインタラクティブボイスレスポンス(IVR)機能を簡単に統合できます。
2. Amazon Pinpoint
- 用途: Amazon Pinpointは、ターゲットを絞ったマーケティングキャンペーン、通知、アンケートなどを通じて顧客と連絡を取るためのサービスです。多くの場合、モバイルアプリやSMS(テキストメッセージ)を通じて顧客との双方向のやりとりを行うために使用されます。
- メリット: 顧客へのメッセージ配信のために、高いスケーラビリティを持つプラットフォームを提供します。また、ユーザーの応答や行動に基づいてカスタマイズされたメッセージを送信することができ、効果的な顧客エンゲージメントを実現します。
3. Amazon SNS (Simple Notification Service)
- 用途: SNSは、メッセージングサービスで、プッシュ通知やSMSメッセージを高スケーラビリティで送信するために使用されます。主にサーバーレスで動作し、個別またはグループへのメッセージ配信が可能です。
- メリット: SNSは、他のAWSサービス(Lambda、SQSなど)と簡単に統合でき、メッセージの配信に関する設定や運用負担を軽減します。
4. 運用の最小化
- AWSを活用することで、オンプレミスのインフラストラクチャ管理から解放され、運用負担が大幅に軽減されます。特に、Amazon ConnectやPinpointは、設定が簡単で、スケーラブルで柔軟性があり、運用管理の負担を最小限に抑えるため、企業はインフラ管理に費やすリソースを削減できます。
解説
この問題で求められている要件は、コールセンターシステムの信頼性を向上させることと、顧客へのテキストメッセージによるアンケートを効率的に送信することです。最小の運用負荷を実現するためには、従来のオンプレミスシステムの置き換えにおいて、完全なクラウドソリューションを選択するのが最適です。
- Amazon Connectを使用することで、コールセンターの機能を完全にクラウド上で実現し、柔軟でスケーラブルなサービスを提供できます。
- Amazon Pinpointは、テキストメッセージによるアンケート配信に特化しており、大量のメッセージを迅速に送信するために最適なサービスです。これにより、運用負荷を最小化しながら、顧客エンゲージメントを高めることができます。
したがって、Aの選択肢(Amazon ConnectとAmazon Pinpointを組み合わせたソリューション)が、要件に最も適しています。
177-AWS SAP AWS 「理論・実践・一問道場」コールセンター
理論
コンタクトセンターの災害復旧(DR)戦略
災害復旧(Disaster Recovery, DR)は、システムが故障したり、障害が発生した際に迅速に復旧し、業務を継続するための手段です。Amazon Connectは、クラウドベースのコンタクトセンターサービスで、災害復旧を考慮した設計が可能です。企業がAmazon Connectを使用してコールセンターを運営している場合、その可用性と事業継続性を確保するためにDR戦略を策定することが重要です。
1. AWSリージョン間の冗長性
災害復旧の基本的なアプローチは、複数のAWSリージョンにサービスを冗長化して配置することです。Amazon Connectを異なるリージョンに展開することで、1つのリージョンが障害に見舞われた場合でも、他のリージョンでサービスを継続できます。
2. Amazon Connectの災害復旧戦略
災害復旧に関する戦略は、以下の要素を含みます:
- 自動化と監視: AWS Lambdaを使用してAmazon Connectのインスタンスの可用性を監視し、問題が発生した場合には自動的に通知や復旧作業をトリガーする仕組みを作成します。
- CloudFormationによるテンプレート化: 災害復旧時に迅速にリソースをプロビジョニングするために、AWS CloudFormationを使用してコンタクトフローやユーザーなどの設定をテンプレート化します。
- Route 53とCloudWatchの活用: Amazon Route 53を使用してインスタンスのヘルスチェックを行い、問題が発生した場合にAmazon CloudWatchアラームを発火させて対応します。
3. 最速の復旧時間目標(RTO)の実現
復旧時間目標(RTO)は、システムが障害から回復するまでの目標時間を指します。最速のRTOを実現するためには、以下のアプローチが有効です:
- 事前の冗長化: 複数のリージョンに事前にAmazon Connectインスタンスをプロビジョニングしておき、障害が発生した際には即座に別のリージョンでサービスを再開できるようにします。
- Lambdaによる自動復旧: 障害が発生した際には、Lambda関数を使って自動的にインスタンスのプロビジョニングや設定を行うことができます。
- AWS CloudFormationテンプレートの使用: すべての設定(ユーザー、コンタクトフロー、電話番号など)をCloudFormationテンプレートで管理することで、手動の作業なしに迅速にリソースを復旧できます。
これらを組み合わせることで、最も迅速な復旧を実現できます。
実践
略
一問道場
問題 #177
トピック 1
ある企業がAmazon Connectを使用してコールセンターを構築しています。企業の運用チームは、AWSリージョン間での災害復旧(DR)戦略を定義しています。コールセンターには多数のコンタクトフロー、数百人のユーザー、および数十の取得済みの電話番号があります。
どのソリューションが最も低い復旧時間目標(RTO)で災害復旧を提供しますか?
A. AWS Lambda関数を作成し、Amazon Connectインスタンスの可用性を確認し、利用できない場合は運用チームに通知します。Amazon EventBridgeルールを作成し、Lambda関数を5分ごとに呼び出します。通知後、運用チームに指示して、AWS Management Consoleを使用して別のリージョンに新しいAmazon Connectインスタンスをプロビジョニングします。AWS CloudFormationテンプレートを使用して、コンタクトフロー、ユーザー、取得済み電話番号をデプロイします。
B. 別のリージョンに既存のユーザーを含む新しいAmazon Connectインスタンスをプロビジョニングします。AWS Lambda関数を作成して、Amazon Connectインスタンスの可用性を確認します。Amazon EventBridgeルールを作成して、Lambda関数を5分ごとに呼び出します。問題が発生した場合、Lambda関数を構成して、AWS CloudFormationテンプレートを展開し、別のリージョンでコンタクトフローと取得済みの電話番号をプロビジョニングします。
C. 別のリージョンに既存のコンタクトフローと取得済みの電話番号を含む新しいAmazon Connectインスタンスをプロビジョニングします。Amazon Route 53でAmazon ConnectインスタンスのURLのヘルスチェックを作成します。失敗したヘルスチェックのためのAmazon CloudWatchアラームを作成します。AWS Lambda関数を作成し、AWS CloudFormationテンプレートを展開してすべてのユーザーをプロビジョニングします。アラームがLambda関数を呼び出すように構成します。
D. 別のリージョンに既存のユーザーとコンタクトフローを含む新しいAmazon Connectインスタンスをプロビジョニングします。Amazon Route 53でAmazon ConnectインスタンスのURLのヘルスチェックを作成します。失敗したヘルスチェックのためのAmazon CloudWatchアラームを作成します。AWS Lambda関数を作成し、AWS CloudFormationテンプレートを展開して取得済みの電話番号をプロビジョニングします。アラームがLambda関数を呼び出すように構成します。
解説
この問題では、Amazon Connectを利用したコールセンターにおける災害復旧(DR)戦略について問われています。具体的には、障害が発生した場合に最も迅速にサービスを復旧できる方法を選択する問題です。以下にそれぞれの選択肢について解説します。
各選択肢の解説
A. Lambda関数と手動プロビジョニング
- 内容: AWS Lambda関数でAmazon Connectの可用性をチェックし、障害時に通知を送信する仕組みを作ります。通知後、オペレーションチームがAWS Management Consoleから手動で新しいAmazon Connectインスタンスを立ち上げ、CloudFormationテンプレートを用いて設定を展開します。
- 評価: この方法は手動での復旧作業が必要であり、復旧までの時間(RTO)が長くなります。したがって、最も迅速な復旧を実現する方法とは言えません。
B. Lambda関数で自動化されたプロビジョニング
- 内容: 既存のAmazon Connectインスタンスの可用性をLambdaで監視し、問題が発生した場合にはCloudFormationテンプレートを使用して自動的に復旧します。
- 評価: この方法は自動化されており、Lambda関数で自動的に復旧手続きを行うため、手動作業が少なく、復旧時間(RTO)が短縮されます。しかし、完璧に素早い復旧を実現するにはさらに効率的な方法があるかもしれません。
C. Route 53とCloudWatchで自動復旧
- 内容: Route 53のヘルスチェックとCloudWatchアラームを使ってAmazon Connectインスタンスの可用性を監視し、問題があった場合にはLambda関数で自動的にCloudFormationテンプレートを使用して復旧します。
- 評価: この方法は可用性の監視と復旧の両方を自動化しており、障害発生後に迅速にインスタンスを立ち上げることができます。RTOの短縮に寄与しますが、最も迅速な復旧にはさらなる工夫が必要です。
D. Route 53とCloudWatchによる復旧(Claimed Phone Numbersも含む)
- 内容: Amazon Connectインスタンスの復旧時に、Claimed Phone NumbersもCloudFormationテンプレートを使って自動的に復旧する仕組みです。
- 評価: こちらもCと同様に自動復旧のプロセスが含まれており、電話番号の復旧も含むため、より完全な復旧を実現できます。このアプローチが最も迅速な復旧(RTO)を実現するための方法となります。
- D では、電話番号を含むすべての設定(ユーザー、コンタクトフロー、電話番号)の復旧が自動化されています。
正解:D
選択肢Dが最も適切な理由は、災害復旧において必要な要素(可用性の監視、復旧、設定の再展開、電話番号の管理など)がすべて自動化されており、最も迅速に復旧できるためです。CloudWatchやRoute 53を利用してリアルタイムで監視し、問題発生時にLambdaで自動的にインスタンスの設定を復旧させるため、最短の復旧時間(RTO)を達成できます。
結論
最も迅速な復旧時間を提供するためには、復旧プロセスを自動化し、すべてのリソース(ユーザー、コンタクトフロー、電話番号)の設定も合わせて自動で復旧させる必要があります。選択肢Dがその要件を満たしており、最も効率的な解決策となります。
178-AWS SAP AWS 「理論・実践・一問道場」AWS Data Exchange のデータシェア
理論


AWS Data Exchangeは、データを安全かつ効率的に共有するためのAWSのサービスです。このサービスは、企業が外部の顧客やパートナーに対してデータを提供したり、他社のデータを取得したりするための基盤を提供します。データ交換のプロセスを簡素化し、アクセス管理、認証、ライセンス管理、そしてデータの共有の各機能を統合しています。
本質的な知識:
- データ製品の作成と共有:
- データ製品: 企業が提供する一連のデータ、API、またはバンドルされたリソースをデータ製品としてAWS Data Exchangeに登録できます。顧客はこれらの製品を購読し、指定されたアクセス方法でデータを受け取ります。
- サブスクリプション管理: 顧客がデータ製品を購読することによって、データ提供者は誰がそのデータにアクセスしているかを追跡できます。また、アクセスが必要な顧客の認証を事前に行い、アクセスを制御することが可能です。
- サブスクリプション確認(Subscription Verification):
- 顧客確認: データ提供者は、顧客がそのデータを受け取る前に確認を行うことができます。これにより、適切な顧客だけがアクセスできるようにし、セキュリティとコンプライアンスを保護できます。
- データの更新とアクセス:
- データ提供者は、データが更新されるたびに顧客に通知し、最新のデータにアクセスできるようにすることができます。AWS Data Exchangeを通じて、APIやS3などさまざまな方法でデータを配信できます。
- データのセキュリティとアクセス制御:
- IAMポリシーと認証: IAM(Identity and Access Management)を使って、特定のAWSリソースへのアクセスを管理できます。RedshiftやS3バケットへのアクセス制御を強化するために、リソースベースのポリシーを使用することができます。
- 自動化と最小化された運用負荷:
- AWS Data Exchangeは、データの配信と管理のプロセスを自動化し、データ提供者が手動で行う作業を最小限に抑えることができます。サブスクリプション確認、アクセス設定、データ配信などがすべてサービス内で簡単に実行できるようになっており、運用負荷が低減します。
具体的な手順:
- データ共有を作成:
- AWS Data Exchange は、データ提供者が他の企業や顧客とデータを安全に共有できるサービスです。まず、データ提供者の AWS アカウント内で「データ共有」(data share)を作成します。これにより、どのデータが顧客と共有されるかが決まります。
- AWS Data Exchange を Redshift クラスターに接続:
- Amazon Redshift は、大規模なデータを保存し、分析するためのデータウェアハウスサービスです。もしデータ提供者がデータを Amazon Redshift に保存している場合、AWS Data Exchange を使ってそのデータを顧客と共有することができます。そのため、AWS Data Exchange を Redshift クラスター に接続する必要があります。これにより、AWS Data Exchange 経由で Redshift に保存されたデータを提供できるようになります。
- サブスクリプション確認を設定:
- 顧客がデータを受け取る前に、データ提供者はサブスクリプション確認を設定する必要があります。これは、顧客が合法的にデータにアクセスできることを確認するプロセスです。サブスクリプション確認は、顧客がデータ使用の契約に同意するなど、さまざまな確認手続きが含まれます。
- 顧客にデータ製品へのサブスクリプションを求める:
- 顧客は AWS Data Exchange を通じてデータ製品にサブスクリプションする必要があります。サブスクリプションが完了すると、顧客はデータ提供者が Amazon Redshift に保存した最新のデータにアクセスできるようになります。
重要な点:
- AWS Data Exchange を利用して、データ提供者(企業)は Redshift に保存されたデータを顧客と共有できます。
- サブスクリプション確認 を設定することで、データ提供者は合法的な顧客にのみデータを提供することができます。
- 顧客は データ製品にサブスクリプションすることで、提供された最新のデータにアクセスすることができます。
この方法により、データ管理が簡素化され、AWS Data Exchange の機能を活用してデータのセキュリティとアクセス制御が効率的に行えます。
結論:
AWS Data Exchangeを使用することで、データの配信に伴う複雑さや運用の負荷を減らし、企業は効率的にデータ製品を提供できます。また、サブスクリプション管理やアクセス制御、セキュリティ管理など、複雑な要件にも対応できます。
実践
略
一問道場
問題 #178
トピック 1
ある企業が AWS 上でアプリケーションを運用しています。この企業は複数の異なるソースからデータを収集し、独自のアルゴリズムを使用してデータ変換と集計を行っています。ETL プロセスを実行した後、結果を Amazon Redshift のテーブルに格納します。この企業はこのデータを他の企業に販売しています。企業はデータを Amazon Redshift テーブルからファイルとしてダウンロードし、FTP を使ってデータ顧客にファイルを送信しています。データ顧客の数が大幅に増加し、データ顧客の管理が困難になっています。
この企業は AWS Data Exchange を使用してデータ製品を作成し、顧客とデータを共有することを考えています。データを共有する前に顧客の身元を確認したいと考えており、顧客は企業がデータを公開した際に最新のデータにアクセスする必要があります。
最小限の運用負荷でこれらの要件を満たす解決策はどれですか?
A. AWS Data Exchange for APIs を使用して、顧客とデータを共有します。サブスクリプション確認を設定します。データを生成する企業の AWS アカウントで、Amazon Redshift と統合された Amazon API Gateway Data API サービスを作成します。データ顧客にデータ製品へのサブスクリプションを求めます。
B. データを生成する企業の AWS アカウントで、AWS Data Exchange のデータシェアを作成し、AWS Data Exchange を Redshift クラスターに接続します。サブスクリプション確認を設定します。データ顧客にデータ製品へのサブスクリプションを求めます。
C. 定期的に Amazon Redshift テーブルからデータを Amazon S3 バケットにダウンロードします。AWS Data Exchange for S3 を使用して、顧客とデータを共有します。サブスクリプション確認を設定します。データ顧客にデータ製品へのサブスクリプションを求めます。
D. Amazon Redshift のデータを AWS Data Exchange の Open Data として公開します。顧客に AWS Data Exchange でデータ製品へのサブスクリプションを求めます。データを生成する企業の AWS アカウントで、Amazon Redshift テーブルに IAM リソースベースのポリシーをアタッチして、確認された AWS アカウントのみにアクセスを許可します。
解説
この問題では、AWS Data Exchangeを使用してデータを顧客と共有する方法を選択する必要があります。問題のポイントは、データ提供者が顧客の確認を行い、最新のデータを顧客に提供しつつ、最小限の運用負荷でデータを共有する方法を選ぶことです。
解説:
- 選択肢A:
- AWS Data Exchange for APIs: APIを利用してデータを提供する方法です。データ提供者はAPIを利用してRedshiftと連携し、データを顧客に提供できます。サブスクリプション確認を利用し、顧客の認証を行うことが可能ですが、APIの設定や運用が煩雑になる可能性があり、最小限の運用負荷という点では少し手間がかかります。
- 選択肢B:
- AWS Data Exchangeでデータシェア: これもRedshiftを使ってデータを顧客にシェアする方法ですが、AWS Data Exchangeのシンプルな機能を使用して、サブスクリプションの確認とデータの提供が行われます。この方法は最小限の運用負荷でデータ提供ができるため、最も適切な選択肢です。
- 選択肢C:
- S3を使用したデータ共有: データを定期的にS3バケットに保存し、AWS Data Exchange for S3を使って顧客にデータを提供する方法です。この方法では、顧客がS3にアクセスすることで最新のデータを取得できますが、S3にデータをダウンロードする手順やデータのバージョン管理、ライフサイクル管理などが追加されるため、運用負荷が増加します。
- 選択肢D:
- Open Dataとして公開: RedshiftのデータをAWS Data ExchangeのOpen Dataとして公開する方法ですが、これではデータが公開状態となり、特定の顧客にアクセスを制限するためには追加のIAMポリシーや管理が必要です。また、この選択肢ではデータの更新が即座に反映されない可能性があるため、最小限の運用負荷という要件には適していません。
最適解:
- 選択肢B: AWS Data Exchangeを利用して、Redshiftクラスターのデータを共有し、サブスクリプション確認を行う方法が最適です。この方法では、顧客確認、最新のデータの提供、最小限の運用負荷を満たすことができ、シンプルかつ効率的に運用できます。
179-AWS SAP AWS 「理論・実践・一問道場」エラーハンドリング SQS
理論
1. イベント駆動型アーキテクチャ
イベント駆動型アーキテクチャでは、システムは「イベント」に反応して動作します。イベントは例えばユーザーのアクションや外部システムからの通知などです。これにより、システムは非同期で動作し、イベントが発生するたびに適切な処理が行われます。
- SNS (Simple Notification Service) は、イベントを発行するためのメッセージングサービスです。SNS は、複数のサブスクライバー(例えば Lambda 関数)にメッセージを一斉に通知します。
- Lambda はサーバーレスコンピューティングで、SNS からのイベントを受けて自動的に処理を行います。
2. 自動スケーリング
システムは、受信するリクエストやイベントの量に基づいてリソースを自動的に増減させる能力を持つべきです。これにより、システムは効率的にリソースを使用し、過負荷になることを防ぎます。
- Lambda は、イベントの量に応じて処理能力を自動的にスケールイン・スケールアウトできます。これにより、大量のイベントが来ても自動で処理能力が増えます。
- EC2 Auto Scaling は、EC2 インスタンスを動的にスケールするための機能で、リソースの需要に応じてインスタンス数を増減させます。
3. エラーハンドリング
エラーハンドリングは、処理中のイベントが失敗した場合に重要です。失敗したイベントは、後でレビューや再処理できるように、別のキューに移動する必要があります。
- SQS (Simple Queue Service) は、メッセージを保存し、失敗したメッセージをデッドレターキューに移動させることでエラーハンドリングを行います。
まとめ
この問題は、SNS や Lambda を使用したイベント駆動型アーキテクチャの設計に関連しており、自動スケーリングやエラーハンドリングがどのように実装されるかに焦点を当てています。
実践
略
一問道場
問題 #179
トピック 1
ソリューションアーキテクトがイベントを処理するソリューションを設計しています。このソリューションは、受信するイベントの数に基づいてスケールインおよびスケールアウトする能力を持つ必要があります。処理エラーが発生した場合、イベントはレビューのために別のキューに移動する必要があります。
どのソリューションがこれらの要件を満たしますか?
A. イベントの詳細を Amazon Simple Notification Service (Amazon SNS) トピックに送信します。AWS Lambda 関数を SNS トピックのサブスクライバーとして設定し、イベントを処理します。関数に失敗時の宛先を追加します。Amazon Simple Queue Service (Amazon SQS) キューをターゲットとして設定します。
B. イベントを Amazon Simple Queue Service (Amazon SQS) キューに公開します。Amazon EC2 Auto Scaling グループを作成します。Auto Scaling グループを設定し、キューの ApproximateAgeOfOldestMessage メトリックに基づいてスケールインおよびスケールアウトを行います。アプリケーションを設定して、失敗したメッセージをデッドレターキューに書き込みます。
C. イベントを Amazon DynamoDB テーブルに書き込みます。テーブルに対して DynamoDB ストリームを設定します。ストリームを設定して AWS Lambda 関数を呼び出し、Lambda 関数でイベントを処理します。
D. イベントを Amazon EventBridge イベントバスに公開します。Amazon EC2 インスタンス上でアプリケーションを作成し、Auto Scaling グループで実行します。アプリケーションロードバランサー (ALB) の背後に配置します。ALB をイベントバスのターゲットとして設定します。イベントバスを設定してイベントをリトライします。アプリケーションがメッセージを処理できない場合、デッドレターキューにメッセージを書き込みます。
解説
この問題は、イベントを処理するための 自動スケーリング と エラーハンドリング の要件を満たすソリューションを選択する内容です。解説を以下にまとめます。
問題の要件
- スケールインおよびスケールアウト: システムは受信するイベント数に基づいて自動的に処理能力を増減させる必要があります。
- エラーハンドリング: 処理中にエラーが発生した場合、イベントは別のキューに移動してレビューする必要があります。
各選択肢の解説
A. SNS + Lambda + SQS
- SNS (Simple Notification Service): SNSは、イベントを発行するサービスで、イベントが発生すると、SNSにサブスクライブしている Lambda 関数 に通知されます。
- Lambda: Lambdaは、SNSから受け取ったイベントを自動的に処理します。Lambdaは並列実行により自動的にスケールし、イベント数の増加に対応できます。例えば、イベント数が増えればLambdaのインスタンス数が増加します。
- SQS (Simple Queue Service): もしLambdaでイベント処理が失敗した場合、Lambdaは失敗時に指定されたSQSキューにエラーイベントを移動できます。これにより、失敗したイベントは後で確認でき、処理漏れを防げます。
この選択肢は、イベント数のスケーリングに関して非常に効果的で、エラーハンドリングの仕組みも適切です。
B. SQS + EC2 Auto Scaling
- SQS: イベントが SQS キュー に送られ、キューにメッセージが蓄積されます。処理能力が不足している場合は EC2 Auto Scaling を使ってEC2インスタンスを増加させます。
- EC2 Auto Scaling: メッセージ数に基づき、EC2インスタンスの数が増減します。負荷が高ければインスタンス数を増やし、低ければ減らします。
- デッドレターキュー: 処理に失敗したメッセージは、SQSのデッドレターキュー(DLQ)に送られ、後で確認できるようになります。
この選択肢は、イベント処理のスケーリングにおいて EC2 Auto Scaling を使用しており、柔軟ですが、EC2インスタンスの管理 が必要で、他の選択肢よりも運用がやや複雑になります。
C. DynamoDB + Lambda
- DynamoDB: イベントをDynamoDBに書き込むと、DynamoDB Streamsを使って変更をトリガーできます。
- Lambda: DynamoDB StreamsからLambda関数がトリガーされ、Lambdaがイベントを処理します。
このアーキテクチャでは、自動スケーリングに関しては Lambda による処理のスケーリングはありますが、DynamoDB自体にはイベント数に基づくスケーリングの仕組みがないため、スケールイン・スケールアウトが必ずしも最適に行われるわけではありません。また、エラーハンドリングの詳細が不足しており、失敗したメッセージの処理が不明確です。
D. EventBridge + EC2 Auto Scaling
- EventBridge: イベントを EventBridge イベントバスに公開します。EventBridgeはイベントを集約し、適切なターゲット(例えばEC2)に転送します。
- EC2 Auto Scaling: EC2インスタンスは Auto Scaling を使って増減します。
- エラーハンドリング: イベントの処理に失敗した場合は、デッドレターキューに移動します。
EventBridgeとEC2 Auto Scalingはスケーリング能力を提供しますが、EC2インスタンスの管理が必要となるため、手間がかかります。また、EventBridgeのイベント処理やEC2上でのアプリケーションの動作を正しく設定する必要があり、少し複雑です。
最適な選択肢
最も適切な選択肢は A です。
- SNS + Lambda は、イベントが到着したときに自動でスケーリングし、Lambdaでの処理に失敗した場合は SQS を使ってエラーメッセージを移動できます。
- さらに、AWSの サーバーレス アーキテクチャに基づくため、管理が簡単で、コスト効率も良いです。
B も良い選択肢ですが、EC2 の管理が必要となり、運用の複雑さが増すため、手軽さと効率を重視するなら A の方が優れています。
180-AWS SAP AWS 「理論・実践・一問道場」データ損失は不許容API構成
理論
1. トラフィックの急増に対する「弾力性」
トラフィックの急増を処理するためには、「弾力性(Elasticity)」が欠かせません。弾力性とは、システムが需要に応じてリソースを自動的に増減させる能力です。急激にトラフィックが増加したとき、リソースが不足してしまうとデータ損失が発生したり、サービスが停止したりするリスクがあります。AWSは、Auto Scalingやサーバーレスなど、システムが動的にスケールする仕組みを提供しています。この弾力性が、急増するトラフィックに対する最も重要な対応策です。
- *サーバーレス(Lambda)**は、リソースを事前に決めることなく、リクエストに応じてリソースを自動的にスケールさせることができるため、弾力性が非常に高いです。
- *コンテナ化(ECS/Fargate)**では、コンテナの数やリソースを事前に設定しておき、トラフィック増加に応じて新たなコンテナを自動的に立ち上げることができます。
2. 非同期処理とバッファリング
デバイスが一度に送信するデータの量が予測不可能な場合、すべてのリクエストを瞬時に処理するのは不可能です。この問題を解決するために、非同期処理を採用します。非同期処理の基本的な考え方は、リクエストをその場で即時処理するのではなく、一時的にバッファしておき、処理可能なタイミングで順次処理するというものです。これにより、リクエストの急増時にもデータを失うことなく、順次処理を行うことができます。
- SQSは、リクエストを一時的に保存する「キュー」として機能し、処理能力に応じてデータを順次取り出して処理します。これにより、大量のリクエストを適切に管理することができます。
- LambdaやFargateがこれを処理する役割を果たし、非同期でスケールしながら処理を実行します。
3. データ損失の防止(Durability)
データ損失の防止は、システム設計において最も根本的で重要な要素です。データ損失を許容しない場合、システムの可用性や信頼性が保証されません。メッセージングシステム(例:SQS)は、メッセージの耐久性(Durability)を保つために、冗長性を確保した設計が必要です。SQSではメッセージが一時的に保存され、バックエンドで処理されるまで失われることがありません。
- SQSは、分散システムにおいて、メッセージが消失するリスクを最小化するため、メッセージの重複を避け、確実に処理されることを保証します。
4. シンプルさと管理の効率性
システム全体を管理する負荷が高いと、問題発生時の対応が遅れる可能性があります。システムをできるだけシンプルに設計し、管理の効率性を保つことが重要です。サーバーレスアーキテクチャや完全に管理されたサービスを利用することで、インフラの管理負担を減らし、運用の効率を高めることができます。
- Lambdaのようなサーバーレス技術では、インフラの管理を完全にAWSに任せることができ、システム運営に必要なリソースのみを意識すれば良いため、システム設計がシンプルになります。
5. 適切なツールとサービスの選定
最後に、システムに適したツールやサービスを選定することが本質的です。例えば、デバイスからのデータ送信において、高いリクエスト数やスケーラビリティの要件がある場合、API Gatewayが非常に適しています。もしリクエストを非同期で効率的に処理する必要があれば、SQS + Lambdaの組み合わせが理想的です。大量のデータをリアルタイムでストリーミングする場合には、Kinesisなどを選択することが最適です。
結論
本質的には、システムの設計は以下の要素に基づいています:
- 弾力性:リソースを自動的にスケールし、急激なトラフィック増加にも耐える能力。
- 非同期処理:リクエストを瞬時に処理せず、バッファリングして順次処理。
- データ損失防止:冗長性を確保し、データの耐久性を保つ。
- シンプルさと管理効率:システムの管理負担を最小化し、運用の効率を高める。
これらの原則に基づいて、**選択肢B(API Gateway + SQS + Lambda)**が最も適した解決策であるといえます。このアーキテクチャは、スケーラビリティ、非同期処理、データ損失防止を十分に実現し、運用管理を簡素化できます。
実践
略
一問道場
問題 #180
トピック 1
ある会社がAWSクラウドで処理エンジンを運用しています。このエンジンは、物流センターからの環境データを処理して、持続可能性指数を計算します。会社は、ヨーロッパ全体に分散した数百万のデバイスを物流センターで運用しており、これらのデバイスはRESTful APIを通じて情報を処理エンジンに送信します。
このAPIは予測不可能なトラフィックの急増が発生します。会社は、デバイスが処理エンジンに送信するすべてのデータを処理するソリューションを実装する必要があります。データ損失は許容できません。
どのソリューションがこれらの要件を満たしますか?
A. RESTful API用にアプリケーションロードバランサー(ALB)を作成します。Amazon Simple Queue Service (Amazon SQS)キューを作成します。ALBにリスナーとターゲットグループを作成し、ターゲットとしてSQSキューを追加します。Amazon Elastic Container Service (Amazon ECS)でFargate起動タイプを使用して、キュー内のメッセージを処理するコンテナを実行します。
B. RESTful APIを実装するAmazon API Gateway HTTP APIを作成します。Amazon Simple Queue Service (Amazon SQS)キューを作成します。API Gatewayサービス統合でSQSキューを設定します。AWS Lambda関数を作成して、SQSキュー内のメッセージを処理します。
C. RESTful APIを実装するAmazon API Gateway REST APIを作成します。Auto Scalingグループ内にAmazon EC2インスタンスのフリートを作成します。API GatewayのAuto Scalingグループプロキシ統合を設定します。EC2インスタンスで受信データを処理します。
D. RESTful API用にAmazon CloudFrontディストリビューションを作成します。Amazon Kinesis Data Streamsでデータストリームを作成します。データストリームをディストリビューションのオリジンとして設定します。AWS Lambda関数を作成して、データストリーム内のデータを消費して処理します。
解説
この問題の解説は以下の通りです:
要件:
- トラフィックの急増に対応する必要がある。
- データ損失を許容しない。
- すべてのデータを確実に処理する必要がある。
選択肢Bが最適な理由:
- API GatewayとSQSを使い、非同期処理を行い、トラフィック増加に対応。
- Lambdaを使用して、SQSのメッセージを処理し、スケーラブルで管理が簡単。
- SQSはデータの耐久性(データ損失なし)を保証。
他の選択肢(A, C, D)は複雑で、非同期処理やスケーラビリティ、データ損失防止の観点で効果的ではありません。
- Author:minami
- URL:http://preview.tangly1024.com/private-license/170d7ae8-88e2-80cd-b047-d989502db1c4
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts