type
status
date
slug
summary
tags
category
icon
password
151-AWS SAP AWS 「理論・実践・一問道場」フロントエンドの静的サイト化
理論
1. AWS EC2インスタンスの選定とサイズの最適化
- オンデマンドインスタンス：アプリケーションの要件に応じてインスタンスを購入でき、リソースをフルに活用する場合に最適です。ただし、トラフィックの少ない時間帯にフル負荷のインスタンスを維持することはコストの無駄です。
- スポットインスタンス：リソースが余っている時間帯に利用可能なインスタンスで、コストを大幅に削減できます。リスクとしては、インスタンスがAWSにより取り消される可能性があることです。短期間でリスクの少ないバックエンド処理や負荷が高い時間帯に利用するのが有効です。
- バースト可能なインスタンス（Tシリーズ）：一般的に低コストで、CPU使用率が低いときにコストが安く、リソースが必要になった時にバーストする能力があります。これはトラフィックが急増する昼食時に効率的に使えます。
2. アプリケーションのフロントエンド最適化
- 静的ウェブサイトのホスティング（Amazon S3）：フロントエンドのアプリケーションが静的なコンテンツを提供する場合、Amazon S3を利用した静的ウェブサイトホスティングが最もコスト効果が高い方法です。S3はスケーラブルで、トラフィックに応じて自動的にスケールします。また、S3は非常に低コストで、ほとんどのケースで運用コストを大幅に削減できます。
3. AWS Elastic Beanstalk
- Elastic Beanstalkは、アプリケーションのデプロイと管理を簡素化するためのマネージドサービスです。インフラ管理の手間を減らし、アプリケーションのスケーリングやモニタリングを簡単に行えるようにします。Elastic Beanstalkを使うと、アプリケーションが自動的にスケールし、需要に応じてリソースを調整することができますが、特に高可用性を必要とする場合に有効です。
4. アプリケーションロードバランサー（ALB）の使用
- ALBはトラフィックを複数のEC2インスタンスに分散するために使用されます。トラフィックのピーク時にスケーリングを行い、可用性を確保します。特にスケーラブルなアーキテクチャを実現するためには、ALBと適切なEC2インスタンスタイプの組み合わせが必要です。
最適化の方法
- 昼食時の高トラフィックに対応するためのスケーリング戦略：
- オートスケーリングを利用して、ピーク時のリソースを迅速にスケールアウトし、トラフィックが減少する時間帯にはリソースを縮小する。
- スポットインスタンスやバースト可能なインスタンスを使うことで、コストを抑えつつ、ピーク時のパフォーマンスを確保する。
- フロントエンドの最適化：
- S3に静的ウェブサイトをホスティングし、コストを削減しつつ、簡単にスケールできるようにする。
- コスト管理のベストプラクティス：
- リソースの使用状況を定期的にモニタリングし、過剰なインスタンスを削除する。
- AWS Trusted AdvisorやCost Explorerを使って、コストの最適化とリソースの無駄を削減する。
一問道場
会社はアプリケーションをオンプレミスからAWSに移行しました。アプリケーションのフロントエンドは、2台のAmazon EC2インスタンスがアプリケーションロードバランサー(ALB)の背後で動作する静的なウェブサイトです。アプリケーションのバックエンドは、Pythonアプリケーションが3台のEC2インスタンスで動作し、別のALBの背後にあります。EC2インスタンスは、オンプレミスのピーク使用時の仕様に合わせてサイズが設定された、大きな汎用のオンデマンドインスタンスです。
アプリケーションは月に数十万回のリクエストを受けますが、主に昼食時に使用され、それ以外の時間帯にはトラフィックがほとんどありません。
ソリューションアーキテクトは、アプリケーションの可用性に影響を与えることなく、インフラストラクチャコストを最適化する必要があります。
以下のステップの組み合わせで要件を満たすものはどれですか？（2つ選んでください。）
A. 既存のEC2インスタンスと同じコア数の計算最適化インスタンスに、すべてのEC2インスタンスを変更する。
B. アプリケーションのフロントエンドをAmazon S3でホストする静的ウェブサイトに移行する。
C. AWS Elastic Beanstalkを使用してアプリケーションのフロントエンドをデプロイし、ノードに同じインスタンスタイプを使用する。
D. バックエンドのEC2インスタンスをスポットインスタンスに変更する。
E. バックエンドのPythonアプリケーションを、既存のEC2インスタンスと同じコア数の汎用バースト可能なEC2インスタンスにデプロイする。
解説
この問題では、アプリケーションのコスト最適化と可用性の維持が求められています。アプリケーションは昼食時にピークのトラフィックを処理し、それ以外の時間帯にはトラフィックが少ないため、次の2つの解決策が適切です。
- フロントエンドの静的サイト化：アプリケーションのフロントエンドをAmazon S3でホスティングすることで、低コストで高可用性を実現できます。S3はスケーラブルでトラフィックの変動に対応できます。
- バックエンドのインスタンス変更：バックエンドにスポットインスタンスやバースト可能なインスタンス（Tシリーズ）を使用することで、コストを削減しつつ、ピーク時のパフォーマンスを維持できます。
これにより、必要なときにリソースをスケールし、トラフィックの少ない時間帯にはコストを最小限に抑えることができます。
BE
152-AWS SAP AWS 「理論・実践・一問道場」Amazon RDS リードレプリカ
理論
Amazon RDS for MySQL には 読み取りレプリカ（Read Replicas）があります。
読み取りレプリカは、Amazon RDSインスタンスのデータを非同期的にコピーして、読み取り専用のインスタンスとして別のサーバーに保持する仕組みです。これにより、読み取りの負荷を分散させることができ、パフォーマンスの向上や可用性の向上を実現できます。
主な特徴
- 読み取り専用: レプリカは書き込み操作をサポートせず、主に読み取り操作に使用されます。
- 負荷分散: 複数のレプリカを使用することで、読み取り操作の負荷を分散し、アプリケーションのパフォーマンスを向上させることができます。
- スケーラビリティ: 高トラフィックのアプリケーションで、データベースのスケーラビリティを向上させるために利用されます。
- 自動バックアップ: 主インスタンスと同様に、読み取りレプリカにも自動バックアップ機能があります。
使用例
- リード・ライト分離: 書き込み操作は主インスタンスで行い、読み取り操作は読み取りレプリカで行うことで、パフォーマンスを最適化することができます。
- 災害復旧: 主インスタンスに障害が発生した場合、読み取りレプリカを昇格させて主インスタンスとして使用することができます。
注意点
- 非同期コピー: データのコピーは非同期で行われるため、レプリカが必ずしもリアルタイムで最新のデータを反映するわけではありません。
- 書き込み不可: 読み取りレプリカでは書き込みができないため、アプリケーション側で適切にリード・ライトの分離を行う必要があります。
このように、Amazon RDS for MySQLの読み取りレプリカは、可用性やパフォーマンスの向上に役立つ重要な機能です。
実践
略
一問道場
問題 #152
ある企業は、AWS上でイベントチケットプラットフォームを運営しており、コスト効率を最適化したいと考えています。このプラットフォームは、Amazon Elastic Kubernetes Service (Amazon EKS) 上で Amazon EC2 を使用してデプロイされ、バックエンドは Amazon RDS for MySQL インスタンスに依存しています。さらに、新しいアプリケーション機能は AWS Fargate と Amazon EKS 上で実行される予定です。
このプラットフォームは、需要が高いピークをまれに経験しますが、ピークはイベントの日程に依存しています。
この状況に最適な、最もコスト効果の高いソリューションはどれですか？
A. EKS クラスター が使用する EC2 インスタンスに対して、標準のリザーブドインスタンス を購入し、ベースラインの負荷を処理します。ピーク時には、クラスターを Spot インスタンス でスケールします。データベースのピーク負荷に対応するため、1年間の全額前払いリザーブドインスタンス を購入します。
B. EKS クラスター の中程度の負荷に対して、コンピュートセービングプラン を購入します。ピーク時には、イベント日程に基づいてクラスターを オンデマンド容量予約 でスケールします。データベースのベース負荷に対応するため、1年間の前払いなしリザーブドインスタンス を購入します。ピーク時にはデータベースの読み取りレプリカを一時的にスケールアウトします。
C. EKS クラスター のベース負荷に対して、EC2 インスタンスセービングプラン を購入します。ピーク時には、クラスターを Spot インスタンス でスケールします。データベースのベース負荷に対応するため、1年間の全額前払いリザーブドインスタンス を購入します。ピーク時には、手動で DB インスタンス をスケールアップします。
D. EKS クラスター のベース負荷に対して、コンピュートセービングプラン を購入します。ピーク時には、クラスターを Spot インスタンス でスケールします。データベースのベース負荷に対応するため、1年間の全額前払いリザーブドインスタンス を購入します。ピーク時には、手動で DB インスタンス をスケールアップします。
解説
この問題では、AWS上でホストされているイベントチケットプラットフォームのコスト最適化について尋ねられています。プラットフォームは、Amazon EKS（Elastic Kubernetes Service）で運用されており、Amazon EC2 インスタンスと Amazon RDS for MySQL が使用されています。また、AWS Fargate を使用して新しいアプリケーション機能も実行する予定です。
問題の要点
- 需要のピーク：このプラットフォームは特定のイベント日程に依存する需要の急増があります。つまり、システムは昼食時間などにアクセスが集中する傾向がありますが、他の時間帯はほとんど使用されません。
- コスト最適化：企業は、コストを最適化しつつ、アプリケーションの可用性に影響を与えない方法を探しています。
重要な要素
- Amazon EKS：Kubernetesベースのサービス。EKS上で実行されるアプリケーションは、通常、需要の変動に応じてスケーリングが必要です。
- AWS Fargate：無サーバーのコンテナ実行サービス。Fargateはリソースを自動的に管理し、必要に応じてスケールします。
- Amazon RDS for MySQL：データベースサービスで、需要のピークに対応するために読み取りレプリカやスケーリングが必要です。
解答の説明
A:
- 標準リザーブドインスタンス：EC2のベース負荷に対応するために予約インスタンスを使用することはコストを削減できますが、ピーク需要にはSpotインスタンスを使用してスケールする方法は有効です。データベースには1年分のリザーブドインスタンスを購入して、ピーク時の負荷に対応します。
B:
- コンピュートセービングプラン：中程度の負荷に対してコンピュートセービングプランを購入し、ピーク時の負荷をオンデマンドキャパシティ予約を使用して対応する方法です。データベースはリザーブドインスタンスを使用し、ピーク時に読み取りレプリカをスケールアップする方法が示されています。
C:
- EC2インスタンスセービングプラン：ベースの負荷に対応するためのセービングプランを使用し、ピーク時にはSpotインスタンスでスケールアップします。データベースに対してリザーブドインスタンスを使用し、手動でインスタンスをスケールアップする方法です。
D:
- コンピュートセービングプランを使用して、EKSクラスタのベース負荷に対応し、ピーク時のスケーリングにSpotインスタンスを使用します。データベースのリザーブドインスタンスを使用し、手動でスケールアップする方法です。
最もコスト効果の高い選択
この場合、最もコスト効率の良い選択肢は Bです。理由は次の通りです：
- コンピュートセービングプランを使用して、予測される中程度の負荷に対応し、オンデマンドキャパシティ予約を使用してピーク時にスケールすることができます。
- データベースに1年のリザーブドインスタンスを購入し、ピーク時に読み取りレプリカをスケールすることで、コストの最適化とパフォーマンス向上を実現します。
この選択肢は、特にピーク時に高い需要が予測される場合に有効です。
153-AWS SAP AWS 「理論・実践・一問道場」S3にエラーページ
理論
- CloudFrontディストリビューション:
- CloudFrontは、AWSのコンテンツ配信ネットワーク（CDN）で、オリジンサーバーからコンテンツをキャッシュし、低レイテンシでエンドユーザーに提供します。
- 通常、CloudFrontディストリビューションは、静的コンテンツや動的コンテンツを配信するために、S3バケットやEC2インスタンスなどをオリジンとして設定します。
- オリジンアクセスアイデンティティ（OAI）:
- OAIは、CloudFrontがS3バケットからコンテンツを取得するためのセキュリティ設定です。OAIを使用すると、CloudFront以外のアクセスを制限できます。
- CloudFrontのキャッシュビヘイビア:
- CloudFrontでは、キャッシュビヘイビアを使って、特定のパスパターンに対して異なるオリジンを設定できます。
- メンテナンス中に、アプリケーションを一時的に停止し、代わりに情報メッセージを表示したい場合は、キャッシュビヘイビアを変更して、メンテナンス用のS3オリジンにルーティングすることができます。
- メンテナンス時のトラフィック管理:
- アプリケーションをメンテナンス中にオフラインにする際、ユーザーにはエラーページではなく、カスタムのインフォメーションページ（例えば、メンテナンス中の通知）を表示することが一般的です。
このように、CloudFrontとS3を活用し、キャッシュビヘイビアやオリジン設定を変更することで、アプリケーションの可用性を高めつつ、メンテナンス中のエラーメッセージを防ぐことができます。
実践
略
一問道場
問題 #153
トピック 1
ある企業がAWS Elastic Beanstalk上にアプリケーションをデプロイしました。アプリケーションは、データベース層としてAmazon Auroraを使用しています。Amazon CloudFrontディストリビューションがウェブリクエストを処理し、Elastic Beanstalkのドメイン名をオリジンサーバーとして設定しています。ディストリビューションには、訪問者がアプリケーションにアクセスする際に使用する別のドメイン名が設定されています。
毎週、企業は定期的なメンテナンスのためにアプリケーションをサービス停止状態にします。アプリケーションが利用できない期間中、企業は訪問者にCloudFrontのエラーメッセージではなく、情報メッセージを表示したいと考えています。
ソリューションアーキテクトは、プロセスの最初のステップとしてAmazon S3バケットを作成しました。
要件を満たすために、ソリューションアーキテクトが次に取るべきステップの組み合わせはどれですか？（3つ選んでください。）
A. S3バケットに静的な情報コンテンツをアップロードする。
B. 新しいCloudFrontディストリビューションを作成し、S3バケットをオリジンとして設定する。
C. S3バケットを元のCloudFrontディストリビューションの第二オリジンとして設定し、ディストリビューションとS3バケットがオリジンアクセスアイデンティティ（OAI）を使用するように構成する。
D. 毎週のメンテナンス中、デフォルトのキャッシュビヘイビアを編集して、S3オリジンを使用するようにする。メンテナンスが完了したら変更を元に戻す。
E. 毎週のメンテナンス中、新しいディストリビューションにS3オリジン用のキャッシュビヘイビアを作成する。パスパターンを設定し、優先度を0に設定する。メンテナンスが完了したらキャッシュビヘイビアを削除する。
F. 毎週のメンテナンス中、Elastic Beanstalkを設定して、S3バケットからトラフィックを提供するようにする。
解説
この問題では、Elastic Beanstalkアプリケーションがメンテナンス中にCloudFrontエラーページを表示せず、代わりに情報メッセージを表示したいという要件です。
解決策は以下のようになります：
- A: S3バケットに静的な情報コンテンツをアップロードして、メンテナンス中に表示させるメッセージを準備します。
- C: S3バケットを元のCloudFrontディストリビューションの第二オリジンとして設定し、オリジンアクセスアイデンティティ（OAI）を使ってアクセスを制御します。これにより、CloudFrontは情報メッセージを配信できます。
- D: メンテナンス中に、CloudFrontディストリビューションのデフォルトキャッシュビヘイビアを編集してS3オリジンを使用するようにします。これにより、CloudFrontはS3から情報メッセージを提供します。
他の選択肢は、無駄な操作や追加の設定を含んでいるため、最適ではありません。
154-AWS SAP AWS 「理論・実践・一問道場」Lambdaの別名
理論
Lambda関数の更新に伴う中断を避けるために、Lambdaの別名を使用する方法が有効です。具体的には、Lambda関数のバージョンを直接更新し、アプリケーションで新しいARNを使用する場合、アプリケーションコードもその都度変更する必要があります。このプロセスは、ユーザーにとって中断を引き起こします。
しかし、Lambdaの別名を使用すると、アプリケーションは常に同じ別名ARNを参照し、別名が指し示すLambda関数のバージョンを変更するだけで済みます。これにより、アプリケーションの変更なしにLambda関数のバージョンを切り替えることができ、ユーザーの中断を防げます。
別名の利点：
- アプリケーションの中断なしに、Lambda関数のバージョンを変更可能。
- アプリケーションは固定の別名ARNを使用し、バージョン更新のたびにコードを変更する必要がない。
- 運用の手間を減らし、ユーザー体験を改善。
これにより、運用の効率化とユーザーへの影響を最小化できます。
実践
略
一問道場
問題 #154
トピック 1
ある企業では、ユーザーがカスタムアプリケーションから画像をアップロードできる機能を提供しています。アップロードプロセスはAWS Lambda関数を呼び出し、そのLambda関数が画像を処理してAmazon S3バケットに保存します。アプリケーションは特定のLambda関数バージョンARNを使用してLambda関数を呼び出します。Lambda関数は、環境変数を使用して画像処理パラメータを受け取ります。企業は、最適な画像処理結果を得るためにLambda関数の環境変数を頻繁に調整しています。企業は異なるパラメータをテストし、結果を検証した後に、更新された環境変数を使用して新しい関数バージョンを公開します。この更新プロセスには、アプリケーションのカスタマイズが頻繁に必要で、新しい関数バージョンARNを呼び出すように変更する必要があり、これによりユーザーに中断が生じます。
ソリューションアーキテクトは、ユーザーへの中断を最小限に抑えつつ、このプロセスを簡素化する必要があります。
どのソリューションが最も運用オーバーヘッドが少なく、これらの要件を満たすことができますか？
A.公開されたLambda関数バージョンの環境変数を直接変更し、SLATESTバージョンを使用して画像処理パラメータをテストする。
B.画像処理パラメータを格納するAmazon DynamoDBテーブルを作成し、Lambda関数を修正してDynamoDBテーブルから画像処理パラメータを取得する。
C.画像処理パラメータをLambda関数内に直接コード化し、環境変数を削除する。パラメータを更新するたびに新しい関数バージョンを公開する。
D.Lambda関数エイリアスを作成し、クライアントアプリケーションを関数エイリアスARNを使用するように変更する。企業がテストを終了した後、Lambdaエイリアスを新しい関数バージョンを指すように再構成する。
解説
この問題の解説は以下の通りです：
現状の問題
- ユーザーが画像をアップロードするアプリケーションがあり、そのプロセスは AWS Lambda 関数を呼び出して、画像を処理して S3 バケットに保存します。
- Lambda 関数の実行は、特定のバージョン ARN（Amazon Resource Name）を使って呼び出されます。
- 画像処理の最適化のために、Lambda 関数の環境変数が頻繁に更新されます。新しいパラメータで画像処理をテストし、結果を検証した後に関数の新しいバージョンを公開します。この更新は、アプリケーションにも変更を加える必要があり、そのたびにユーザーに中断を引き起こしています。
解決策
解決策は「ユーザーの中断を最小限に抑え、運用の負担を減らす」ことです。
各選択肢の説明
- A. 直接、公開されたLambda関数の環境変数を変更し、SLATESTバージョンを使って画像処理パラメータをテストする。
- これは最もシンプルな方法ですが、Lambda の「最新」バージョンを使用することで管理が難しくなる可能性があり、運用における柔軟性が低下します。
- B. Amazon DynamoDB テーブルを作成して、画像処理パラメータを格納する。Lambda 関数を変更して、DynamoDB テーブルからパラメータを取得する。
- これは環境変数を動的に管理する方法ですが、実装とメンテナンスが複雑になり、Lambda と DynamoDB の連携に追加の管理が必要となります。
- C. 画像処理パラメータをLambda関数に直接コードとして組み込み、環境変数を取り除く。パラメータを更新するたびに新しいバージョンを公開する。
- これは頻繁に関数を更新する必要があり、柔軟性に欠けます。関数のコードにハードコーディングされたパラメータの変更は運用を煩雑にする可能性があります。
- D. Lambda 関数のエイリアスを作成し、クライアントアプリケーションがエイリアス ARN を使うように変更する。新しいバージョンをテストした後、エイリアスを新しいバージョンに指し直す。
- この方法が最も効果的です。エイリアスを使用することで、アプリケーションは常にエイリアスを呼び出し、関数の新しいバージョンをテストしても、アプリケーション側の変更を最小限に抑えることができます。新しいバージョンを公開する際に、エイリアスを変更するだけで済むため、運用の負担を大きく軽減できます。
結論
D が最も効果的な解決策です。Lambda エイリアスを使用することで、関数の新しいバージョンをアプリケーションに影響を与えずに管理でき、ユーザーへの中断も最小限に抑えられます。
155-AWS SAP AWS 「理論・実践・一問道場」AWS Global Accelerator
理論
以下の観点に注目してください：
- エイペックスドメインの扱い：
- 通常、エイペックスドメインはCNAMEレコードを使って他のドメインにポイントすることができません。そのため、静的IPを利用するか、特殊なサービス（例：Global Accelerator）を利用する必要があります。
- ジオロケーションルーティング：
- 地理的に異なるリージョンでアプリケーションを展開している場合、ユーザーの場所に基づいて最適なリージョンにトラフィックをルーティングする機能が必要です。これを実現するための方法を考慮しましょう。
これらを踏まえて、最も労力が少なく、効率的な方法を選択することが求められます。
AWS Global Acceleratorの仕組みについて、以下のポイントを整理しました。
1. 入口ノードの自動選択
Global Acceleratorでは、ユーザーの地理的な位置に基づいて、最も近い「入口ノード」が自動的に選ばれます。これにより、ユーザーは最寄りの地域からアプリケーションへ最適な経路でアクセスでき、低遅延を実現します。つまり、ユーザーは自分の位置に最も近いAWSの「入口ノード」を経由してアプリケーションにアクセスします。
2. 目標地域の設定
Global Acceleratorを設定する際には、アプリケーションがデプロイされている「ターゲット地域」を指定する必要があります。これが、実際にアプリケーションが稼働しているAWSのリージョン（例：東京、ニューヨークなど）です。複数のターゲット地域を設定することができ、Global Acceleratorは最も効率的な経路を選んで、リクエストを適切な地域にルーティングします。
3. ユーザーはどこを経由するか
ユーザーは、自分の地理的な位置に最も近い入口ノード（例：ヨーロッパのユーザーならロンドンやフランクフルト）を通じてアクセスします。その後、Global Acceleratorは、ターゲット地域（アプリケーションがデプロイされているリージョン）への最適なルートを選択して流量を転送します。
4. エンドユーザーへの影響
Global Acceleratorを利用すると、ユーザーはより短い距離でアクセスできるため、遅延が減少し、アプリケーションのパフォーマンスが向上します。特に、ユーザーが遠くのリージョンにアクセスする際に最適な経路を提供し、安定したアクセスを確保できます。
まとめ
- Global Acceleratorは、ユーザーの地理的な位置に最も近い入口ノードを自動的に選択して、最適な経路でアクセスします。
- ユーザーは自分の最寄りの入口ノードを経由し、ターゲット地域（アプリケーションがデプロイされているリージョン）に最適な方法でルーティングされます。
- ターゲット地域を指定することは必要ですが、入口ノードは自動的に選ばれるため、手動での指定は不要です。
このように、Global Acceleratorはユーザーの利便性を最大化し、ネットワークの遅延を最小化するために設計されています。
実践
略
一問道場
問題 #155
トピック 1
あるグローバルメディア企業は、アプリケーションの多地域展開を計画しています。展開は、ユーザー体験を一貫させるために Amazon DynamoDB グローバルテーブル を使用してバックエンドを構築します。各展開には公開用の Application Load Balancer (ALB) が設定されます。この企業は、公開DNSを自社で管理しています。企業は、エイペックスドメイン（ルートドメイン）を通じてアプリケーションを利用可能にしたいと考えています。
最小の労力でこの要件を満たすソリューションはどれですか？
A. 公開DNSを Amazon Route 53 に移行し、エイペックスドメインのために CNAME レコードを作成してALBを指すようにします。ユーザーの位置に基づいてトラフィックをルーティングするためにジオロケーションルーティングポリシーを使用します。
B. Network Load Balancer (NLB) をALBの前に配置し、公開DNSを Amazon Route 53 に移行します。エイペックスドメインのために CNAME レコードを作成し、NLBの静的IPアドレスを指すようにします。ユーザーの位置に基づいてトラフィックをルーティングするためにジオロケーションルーティングポリシーを使用します。
C. AWS Global Accelerator を作成し、適切なAWSリージョンのエンドポイントをターゲットにする複数のエンドポイントグループを設定します。Global Acceleratorの静的IPアドレスを使用して、公開DNSでエイペックスドメインのためにレコードを作成します。
D. 1つのAWSリージョンで Amazon API Gateway API を作成し、AWS Lambdaでバックエンドを設定します。Lambda関数を使用してラウンドロビン方式でアプリケーション展開にトラフィックをルーティングします。エイペックスドメインのために CNAME レコードを作成し、APIのURLを指すようにします。
解説
この問題では、グローバルメディア企業が複数のリージョンに展開するアプリケーションを構築し、そのユーザーエクスペリエンスを最適化するために、Amazon DynamoDBのグローバルテーブルを使用するというシナリオです。また、アプリケーションの公開にエイペックスドメイン（ルートドメイン）を使用したいという要求もあります。
要求に関して：
- アプリケーションは2大陸にまたがる地域で展開され、ユーザー体験の一貫性を維持する必要があります。
- 各デプロイメントには**Application Load Balancer (ALB)**が設定されています。
- 公開DNSは社内で管理されていますが、エイペックスドメインでアプリケーションにアクセスできるようにしたい。
選択肢の解説：
A. Route 53を利用し、CNAMEレコードを作成しジオロケーションルーティングを使用
- エイペックスドメインにはCNAMEを直接使用できないため、この選択肢は不適切です。
- CNAMEレコードは通常、サブドメインに使用され、エイペックスドメインには使用できません。
B. NLBを使用して、Route 53でCNAMEレコードを作成
- NLB（Network Load Balancer）は静的IPアドレスを持っているため、エイペックスドメインに適用できます。しかし、Route 53でジオロケーションルーティングを使用してトラフィックを地域別に分ける部分は正しいですが、NLB自体がALBの代替として適切な場合は限られます。
C. AWS Global Acceleratorを使用して、静的IPでDNSレコードを作成
- 最適な選択肢です。
- AWS Global Acceleratorは静的IPアドレスを提供し、これをエイペックスドメインに割り当てることができます。また、トラフィックをユーザーの地理的な位置に基づいて最適なリージョンにルーティングする機能を持っています。この方法は、要求された最小の労力で実現できます。
D. API GatewayとLambdaを使用してトラフィックをルーティング
- 過剰な解決策です。
- AWS API GatewayとLambdaを使用してトラフィックをラウンドロビンでルーティングする方法は、スケーラビリティやコスト面で不効率になる可能性があり、この問題に対する最適な選択ではありません。
結論：
- 最も効率的で簡単な方法は、AWS Global Acceleratorを使用して、静的IPアドレスをエイペックスドメインに関連付けることです。この方法は、要求されたトラフィックルーティングとユーザーエクスペリエンスの最適化を最小の労力で達成できます。
したがって、選択肢Cが最適です。
156-AWS SAP AWS 「理論・実践・一問道場」Lambda Docker イメージをデプロイメントパッケージ
理論
AWS Lambda 関連の問題に対処するには、Lambda のアーキテクチャ、コードのデプロイ方法、およびライブラリやカスタムクラスの再利用についての本質的な知識が重要です。
AWS Lambda のアーキテクチャとコードのデプロイ
1. AWS Lambda の基本構造
AWS Lambda は、イベント駆動型でサーバーレスのコンピューティングサービスです。Lambda 関数は以下のような要素で構成されます。
- コード: ビジネスロジックを含むスクリプトやアプリケーションコード。
- ランタイム: 関数を実行するための環境（例: Python、Node.js、Java）。
- 依存関係: ライブラリやモジュールなど、コードが必要とする外部パッケージ。
2. コードのデプロイ方法
Lambda 関数をデプロイする際の一般的な方法は次のとおりです。
- Zip パッケージ: 関数コードと依存関係をまとめて圧縮し、直接アップロード。
- コンテナイメージ: Docker を使用して関数コードと依存関係をまとめ、Amazon Elastic Container Registry（ECR）にアップロード。
Zip パッケージはシンプルですが、依存関係が多い場合はコンテナイメージの使用が推奨されます。
共有ライブラリとカスタムクラスの再利用
1. Lambda レイヤー
Lambda レイヤーは、共有ライブラリやカスタムクラスを複数の Lambda 関数で再利用するための仕組みです。
- 利点: コードの重複を減らし、関数のパッケージサイズを小さくできる。
- 作成方法: 共有ライブラリを Zip 圧縮してアップロードし、Lambda レイヤーとして登録。
- 制約: レイヤーのサイズ制限は 50 MB（Zip ファイル、未圧縮時は 250 MB）。
2. Docker イメージの活用
AWS Lambda は、50 MB を超える依存関係を持つ場合や、カスタムランタイムが必要な場合に Docker コンテナイメージをサポートしています。
- Docker イメージにすべてのコードと依存関係を含めることで、カスタム環境を作成。
- Amazon Elastic Container Registry（ECR）を使用してイメージを管理。
ケース別ソリューションの選択
1. Zip パッケージ vs. コンテナイメージ
- Zip パッケージ: 軽量で、依存関係が少ないプロジェクトに適している。
- コンテナイメージ: 依存関係が多い、または特殊なランタイムが必要な場合に有効。
2. Lambda レイヤーの使用シナリオ
- 複数の Lambda 関数で同じライブラリを再利用する場合に最適。
- 頻繁に更新される依存関係を分離して管理することで、デプロイの効率を向上。
実際のデプロイ戦略
A. 共有ライブラリが少ない場合
Zip パッケージとして依存関係をまとめ、必要に応じて Lambda レイヤーを作成。
B. 複雑な依存関係がある場合
Docker イメージを使用し、すべての依存関係をコンテナ内に統合。ECR に保存して関数に適用。
C. カスタムランタイムが必要な場合
Docker イメージを使用してランタイムをカスタマイズし、特定の要件を満たす。
実践
略
一問道場
質問 #156
トピック 1
ある企業が、Amazon API Gateway と AWS Lambda を使用して新しいサーバーレス API を開発しています。この企業は、Lambda 関数を API Gateway と統合し、複数の共有ライブラリとカスタムクラスを使用しています。
ソリューションアーキテクトは、このソリューションのデプロイを簡素化し、コードの再利用を最適化する必要があります。
この要件を満たすソリューションはどれですか？
A. 共有ライブラリとカスタムクラスを Docker イメージにデプロイします。このイメージを S3 バケットに保存します。Docker イメージをソースとする Lambda レイヤーを作成します。API の Lambda 関数を Zip パッケージとしてデプロイし、そのパッケージが Lambda レイヤーを使用するように設定します。
B. 共有ライブラリとカスタムクラスを Docker イメージにデプロイします。このイメージを Amazon Elastic Container Registry（Amazon ECR）にアップロードします。Docker イメージをソースとする Lambda レイヤーを作成します。API の Lambda 関数を Zip パッケージとしてデプロイし、そのパッケージが Lambda レイヤーを使用するように設定します。
C. 共有ライブラリとカスタムクラスを AWS Fargate 起動タイプを使用して Amazon Elastic Container Service（Amazon ECS）の Docker コンテナにデプロイします。API の Lambda 関数を Zip パッケージとしてデプロイし、そのパッケージがデプロイされたコンテナを Lambda レイヤーとして使用するように設定します。
D. 共有ライブラリ、カスタムクラス、および API の Lambda 関数のコードを Docker イメージにデプロイします。このイメージを Amazon Elastic Container Registry（Amazon ECR）にアップロードします。API の Lambda 関数がこの Docker イメージをデプロイメントパッケージとして使用するように設定します。
解説
問題のポイント
- コードの再利用性: 共有ライブラリやカスタムクラスを複数の Lambda 関数で効率的に再利用する方法が求められています。
- デプロイの簡素化: Lambda 関数とその依存関係を管理しやすくする仕組みが必要です。
- 最適なツールの選択: AWS Lambda の機能（Zip パッケージ、Lambda レイヤー、Docker イメージ）や関連サービス（ECR、S3、ECS）の適切な組み合わせが求められます。
選択肢の検討
選択肢 A:
「共有ライブラリとカスタムクラスを Docker イメージにデプロイし、S3 バケットに保存する」
- 評価:
- Lambda レイヤーとして Docker イメージを直接使用するのは現時点ではサポートされていません。
- S3 は Zip パッケージや Lambda レイヤーの保存場所として適していますが、Docker イメージの保存場所としては不適切です。
- 結論: 不正解。
選択肢 B:
「共有ライブラリとカスタムクラスを Docker イメージにデプロイし、ECR にアップロードする」
- 評価:
- Docker イメージを ECR に保存するのは一般的なアプローチですが、「Docker イメージを Lambda レイヤーとして使用する」という部分が現実的ではありません。Lambda レイヤーは Zip ファイルで管理されます。
- Docker イメージの直接利用を考慮する場合、この方法は冗長になります。
- 結論: 不正解。
選択肢 C:
「共有ライブラリとカスタムクラスを ECS のコンテナとしてデプロイし、Lambda レイヤーとして利用する」
- 評価:
- ECS コンテナを Lambda レイヤーとして使用するのはサポートされていません。
- ECS はマイクロサービスや長時間稼働するアプリケーション向けであり、Lambda 関数の依存関係管理には適していません。
- 結論: 不正解。
選択肢 D:
「共有ライブラリ、カスタムクラス、および Lambda 関数コードを Docker イメージにまとめ、ECR にアップロードする」
- 評価:
- AWS Lambda はコンテナイメージ形式（最大サイズ: 10GB）のデプロイをサポートしており、ECR から直接 Lambda 関数にイメージを適用できます。
- すべてのコードと依存関係を 1 つのイメージにまとめることで、デプロイが簡素化され、コードの再利用性が向上します。
- 結論: 正解。
正解: D
この選択肢は、Docker イメージと ECR を使用した最新の Lambda デプロイ方法を活用しており、コードの再利用とデプロイの簡素化を両立しています。
補足
この問題から学べるポイントは以下のとおりです：
- AWS Lambda の Zip パッケージとコンテナイメージの使い分け。
- Lambda レイヤーの制約と適用シナリオ。
- Docker イメージを活用した依存関係管理の利点。
これらを理解することで、サーバーレスアーキテクチャの設計力が向上します。
157-AWS SAP AWS 「理論・実践・一問道場」Amazon SageMaker
理論
工場向け機械学習モデルのローカルデプロイに関する基本知識
工場環境で機械学習（ML）モデルを効果的に利用するためには、ネットワークの制約やリアルタイム性などの特定の課題を解決する必要があります。この問題に関連する知識を以下にまとめます。
Amazon SageMaker は、AWS が提供する完全マネージド型の機械学習（ML）プラットフォームです。これを使用すると、データの準備からモデルのトレーニング、デプロイ、運用までのすべての機械学習ライフサイクルを効率的に管理できます。以下が主要な特徴です。
主な機能:
- データ準備:
- データのクリーニング、前処理、変換を支援するツール（例: SageMaker Data Wrangler）。
- データの保存と取得のための統合されたストレージ（S3との連携）。
- モデルのトレーニング:
- 様々なアルゴリズムを使用して、高度なトレーニングが可能。
- ハードウェアリソース（GPU、CPU）を簡単にスケーリングして、トレーニング速度を向上。
- 自動化された機械学習 (AutoML):
- SageMaker Autopilot は、ユーザーが最適なモデルを自動で生成できる機能。トレーニングデータを指定するだけで、最適なアルゴリズムとパラメータが選ばれます。
- モデルのデプロイ:
- SageMaker Endpoint を使用して、モデルをリアルタイム推論用にデプロイ。
- バッチ変換 を使用して、大量のデータを一括処理する推論を行える。
- モデル監視と管理:
- デプロイしたモデルのパフォーマンスをモニタリングし、必要に応じて再トレーニングするための機能が提供されます。
- インテグレーション:
- AWSの他のサービス（Lambda, S3, Redshiftなど）とシームレスに統合し、スムーズにデータをやり取りできます。
メリット:
- スケーラビリティ: 必要に応じて計算リソースをスケールアウトまたはスケールインできます。
- 簡易化: 複雑な機械学習のプロセスを管理・自動化するツールを提供し、開発者やデータサイエンティストが効率的に作業できます。
- コスト管理: 必要なリソースだけを使用するため、コストの最適化が可能です。
Amazon SageMakerは、特に大規模なデータセットを使ったトレーニングや、高度な機械学習タスクを実行する場合に非常に有用なサービスです。
1. ローカルデプロイの必要性
- インターネット接続の制約: 工場ではインターネット接続が不安定または利用できない場合があります。そのため、ローカルで推論を行う仕組みが必要です。
- リアルタイム性: 欠陥検出などのタスクでは、結果を即座に作業員に通知する必要があります。クラウド経由では遅延が発生する可能性があるため、ローカルでの処理が優先されます。
2. Amazon SageMaker を活用した ML モデル
- モデルのトレーニング: SageMaker はクラウドでモデルをトレーニングするための強力なプラットフォームです。工場で使用する欠陥検出モデルをトレーニングする場合、以下のステップを実施します:
- 工場のデータ（例: IPカメラ画像）を収集。
- データを SageMaker でトレーニングしてモデルを構築。
- 必要な精度が得られるまでモデルをチューニング。
- デプロイ方法:
- クラウドベースのエンドポイント。
- ローカルサーバーまたは IoT デバイス。
3. AWS IoT Greengrass
- 概要: Greengrass は AWS のエッジコンピューティングサービスで、クラウドで開発した機械学習モデルをローカルデバイスにデプロイできます。
- 特徴:
- ネットワーク接続なしでローカルで推論を実行可能。
- 各種センサーやカメラとの連携が容易。
- Lambda 関数やカスタムコンポーネントを実行可能。
- 利点:
- クラウドでトレーニングしたモデルをエッジに展開するためのスムーズなワークフロー。
- ローカルAPIと連携するためのカスタムコンポーネントを作成可能。
4. AWS Snowball
- 概要: Snowball は大量データの転送やエッジでのコンピューティング向けの物理デバイスです。
- 用途:
- ネットワークが利用できない環境でのデータ処理。
- ML モデルをデプロイし、オンプレミスで推論を実行。
- 制約:
- 一般的にはデータ転送や一時的な用途に適しており、長期間の利用にはコストや管理上の課題があります。
5. Amazon Monitron
- 概要: Amazon Monitron は機械の状態監視に特化したサービスで、振動や温度のデータをもとに機械の異常を検知します。
- 適用範囲の制限:
- Monitron は振動や温度監視に焦点を当てており、画像処理を伴う欠陥検出のユースケースには適していません。
6. デプロイメント戦略の比較
ソリューション | 特徴 | 適用性 |
IoT Greengrass | ローカルでの推論が可能。リアルタイム処理に最適。クラウドとの連携も容易。 | 欠陥検出ユースケースに最適 |
Snowball | オンプレミスで推論可能だが、一時的な利用が主目的。ネットワーク非依存。 | 長期利用には不向き |
Monitron | 機械状態の監視が得意。画像処理には不適。 | 不適 |
クラウド依存モデル (S3等) | ネットワーク依存で遅延が発生。リアルタイム性が求められる場合は不向き。 | インターネット接続が安定している場合 |
7. 本質的知識のまとめ
- ネットワークが不安定な環境では、ローカルでの処理を優先すべき。
- AWS IoT Greengrass は、エッジでの推論とローカルAPIとの統合において最適な選択肢。
- Snowball や Monitron は特定のユースケースに適しているが、欠陥検出の要件には適合しない場合が多い。
これらの知識を活用して、適切なデプロイ方法を選択できます。
実践
略
一問道場
以下は問題文の日本語訳です：
問題 #157
トピック 1
ある製造会社は、工場の検査ソリューションを構築しています。この会社は各組立ラインの端にIPカメラを設置しています。Amazon SageMaker を使用して、静止画像から一般的な欠陥を識別する機械学習（ML）モデルをトレーニングしました。
会社は、欠陥が検出された場合に工場の作業員にローカルでフィードバックを提供したいと考えています。また、工場のインターネット接続が切れている場合でも、このフィードバックを提供できる必要があります。同社は、ローカルフィードバックを作業員に提供するAPIをホストするローカルのLinuxサーバーを所有しています。
どのようにMLモデルをデプロイすれば、これらの要件を満たせるでしょうか？
選択肢
A.
各IPカメラからAWSにAmazon Kinesis Video Streamを設定する。EC2インスタンスを使用してストリームから静止画像を取得する。これらの画像をAmazon S3バケットにアップロードする。SageMakerエンドポイントにMLモデルをデプロイする。新しい画像がアップロードされたときに推論エンドポイントを呼び出すAWS Lambda関数を起動する。欠陥が検出された場合、このLambda関数を使用してローカルAPIを呼び出すように設定する。
B.
ローカルサーバーにAWS IoT Greengrassをデプロイする。MLモデルをGreengrassサーバーにデプロイする。Greengrassコンポーネントを作成し、カメラから静止画像を取得して推論を実行する。欠陥が検出された場合、ローカルAPIを呼び出すようにコンポーネントを設定する。
C.
AWS Snowballデバイスを注文する。SageMakerエンドポイントにMLモデルとAmazon EC2インスタンスをSnowballデバイス上にデプロイする。カメラから静止画像を取得する。EC2インスタンスから推論を実行する。欠陥が検出された場合、ローカルAPIを呼び出すようにインスタンスを設定する。
D.
各IPカメラにAmazon Monitronデバイスをデプロイする。オンプレミスにAmazon Monitron Gatewayをデプロイする。MLモデルをAmazon Monitronデバイスにデプロイする。Amazon Monitronのヘルスステートアラームを使用して、欠陥が検出された場合にAWS Lambda関数からローカルAPIを呼び出す。
解説
この問題では、工場内でMLモデルをローカルでデプロイし、欠陥検出を行う方法を問うています。ネットワークが不安定な場合でもローカルで動作するソリューションが必要です。
選択肢の解説:
- A: クラウド依存で、画像をS3にアップロードし、Lambdaで推論を行うため、インターネット接続が必須。ローカルでの処理には不向き。
- B: 適切な解答。AWS IoT Greengrassを使って、ローカルサーバーで推論を実行し、欠陥が検出された場合にAPIを呼び出す方法。ネットワークがなくてもローカルで動作するため、要件に合致します。
- C: Snowballは一時的なデータ転送やローカル推論に使えるが、長期的な運用には不向きで、欠陥検出の要件に最適ではない。
- D: Monitronは振動監視に特化しており、画像ベースの欠陥検出には適していません。
結論: B が最適な選択です。
158-AWS SAP AWS 「理論・実践・一問道場」Migration Evaluator
理論
ビジネスケースとは？
ビジネスケースは、特定のプロジェクトや投資が実行可能であり、企業にとって利益をもたらすことを示すために作成される文書やプレゼンテーションです。ビジネスケースは、以下のような要素を含むことが一般的です：
- 目的と目標: プロジェクトが解決しようとする問題や達成すべき目標。
- 分析と評価: 現在の状況や課題、プロジェクトを実施することによる利点やリスクの分析。
- コストと予算: プロジェクトに必要な予算やコストの詳細。
- 利益とリターン: プロジェクトを実行することで得られる財務的な利益やその他の価値（時間の節約、効率化など）。
- 実行計画: プロジェクトの実行方法やステップ、スケジュール。
- リスクと対応策: プロジェクト実行中に考えられるリスクと、それに対する対応策。
ビジネスケースの後は？
ビジネスケースが承認されると、その後に行うべきステップとして以下のようなことが含まれます：
- プロジェクト計画の策定:
- プロジェクトの詳細な実行計画を作成します。これには、タイムライン、リソース計画、責任分担、進捗管理方法などが含まれます。
- 実行と監視:
- プロジェクトを実際に実行し、進捗状況を定期的に確認します。目標の達成度やコスト、スケジュールに遅れがないかをチェックし、必要な修正を加えます。
- 成果物の提供:
- プロジェクトの成果物を作成し、関係者に提供します。この時点で、予定通りに成果を上げられるかを確認します。
- 評価とフィードバック:
- プロジェクト終了後に成果を評価し、成功した点や改善点についてフィードバックを集めます。この情報は、将来のプロジェクトに役立てます。
- 最終報告と承認:
- プロジェクトが完了したら、最終報告書を作成し、関係者に提出します。プロジェクトの結果が期待通りだったかどうかを評価します。
ビジネスケースはプロジェクトのスタート地点として非常に重要ですが、その後のプロジェクト実行と結果の追跡も同様に重要です。
AWSへのオンプレミスデータセンターの移行: 主要なツールとアプローチ
企業がオンプレミスのデータセンターからAWSクラウドへ移行する際には、コスト効果の高い方法で詳細な移行計画を立てることが重要です。CMDB（構成管理データベース）を使用した分析は、移行プロセスの一環として非常に重要です。以下に、関連するツールとアプローチを紹介します。
1. AWS Well-Architected Tool
AWS Well-Architected Toolは、AWSインフラの設計がAWSのベストプラクティスに従っているかを評価するためのツールです。このツールは、アーキテクチャの改善点や最適化に関する推奨事項を提供します、このツールは主にアーキテクチャのレビューと改善に焦点を当てています。
2. Migration Evaluator (旧TSO Logic)
Migration Evaluatorは、オンプレミスのインフラをAWSクラウドに移行するための詳細な評価を提供するツールです。このツールは、CMDBからエクスポートしたサーバー情報をインポートし、各サーバーの移行コストやAWS上での最適なサービスを分析します。特に、コスト予測や最適化を行うためのテンプレートが用意されており、クラウド移行の経済性を評価するのに役立ちます。これにより、どのリソースをAWSに移行すべきか、またそれにかかるコストはどれくらいかを詳細に把握することが可能です。
3. AWS Price List Bulk API
AWS Price List Bulk APIは、AWSの料金データを一括で取得するためのAPIです。これを使用して、AWSサービスの料金情報を効率的に照会することができますが、CMDBデータを移行計画に統合するためには他の手法と組み合わせる必要があります。このAPI単体で移行の最適化や推奨事項を提供するものではありません。
4. AWS Application Discovery Service
AWS Application Discovery Serviceは、オンプレミスの環境を詳細に分析し、AWSクラウドに移行するために最適な方法を提供するサービスです。このサービスは、オンプレミスのサーバーやアプリケーションの依存関係を収集し、移行に向けたデータとリソースを分析するのに役立ちます。CMDBからのデータインポートに対応しており、企業のインフラをAWSに移行するために非常に有用なツールです。
結論
オンプレミスのデータセンターをAWSに移行するためには、CMDBデータをうまく活用して、コストや移行の優先度を評価することが重要です。特に Migration Evaluator と AWS Application Discovery Service は、移行計画を立てるために最もコスト効果的で包括的なソリューションを提供します。
実践
略
一問道場
質問 #158
トピック 1
ソリューションアーキテクトは、企業のオンプレミスデータセンターをAWSクラウドに移行するためのビジネスケースを作成する必要があります。
ソリューションアーキテクトは、企業のサーバーに関する構成管理データベース（CMDB）のエクスポートデータを使用して、このケースを作成します。
どのソリューションが最もコスト効果的にこの要件を満たしますか？
- A: AWS Well-Architected Toolを使用してCMDBデータをインポートし、分析を行い、推奨事項を生成する。
- B: Migration Evaluatorを使用して分析を実行する。データインポートテンプレートを使用してCMDBエクスポートからデータをアップロードする。
- C: リソースマッチングルールを実装する。CMDBエクスポートとAWS Price List Bulk APIを使用して、AWSサービスに対してCMDBデータを一括で照会する。
- D: AWS Application Discovery Serviceを使用してCMDBデータをインポートし、分析を実行する。
解説
この問題の解説を行います。
問題の要点：
- 企業は、オンプレミスのデータセンターをAWSクラウドに移行するためのビジネスケースを作成する必要があります。
- ソリューションアーキテクトは、企業のサーバーに関する構成管理データベース（CMDB）からエクスポートしたデータを使用して、このケースを作成する必要があります。
- 最もコスト効果の高い方法を選択することが求められています。
各選択肢の評価：
- A: AWS Well-Architected Tool
- 説明: AWS Well-Architected Toolは、AWS環境のベストプラクティスに基づいてインフラの評価を行い、アーキテクチャの改善点を特定するツールです。
- 評価: CMDBデータのインポートを行い、移行のための詳細な分析を行うことには向いていません。主にアーキテクチャのレビュー用であり、コスト分析や移行計画作成には適していません。
- 結論: 不適切です。
- B: Migration Evaluator (旧TSO Logic)
- 説明: Migration Evaluatorは、オンプレミスのサーバーのデータを基に、AWSへの移行のコストや最適なリソースを評価するツールです。CMDBからデータをインポートし、詳細な分析を行う機能が提供されており、移行コストの見積もりを行う際に非常に有効です。
- 評価: このツールは、CMDBデータをインポートして移行に関する分析を行い、最適なAWSサービスを選定するために使われます。また、コスト効率を高めるための詳細なレポートを提供します。
- 結論: 最もコスト効果の高いソリューションであり、最適な選択肢です。
- C: リソースマッチングルールとAWS Price List Bulk API
- 説明: AWS Price List Bulk APIは、AWSサービスの料金情報を一括で取得するためのAPIです。リソースマッチングルールを使ってCMDBデータを照会することが提案されていますが、CMDBデータを移行分析に活用するには手動の作業が多く、効率的ではありません。
- 評価: この方法は一度に多くの料金情報を取得できるものの、CMDBデータとの照合や移行計画の作成に対して直接的な支援は提供されません。手動作業が多く、コスト分析の面では最適ではありません。
- 結論: 最適ではないです。
- D: AWS Application Discovery Service
- 説明: AWS Application Discovery Serviceは、オンプレミスのサーバーやアプリケーションの依存関係を収集し、AWSへの移行を支援するサービスです。CMDBデータのインポートに対応しており、移行を支援するための情報を提供しますが、主にアプリケーションの発見と依存関係の解析に特化しているため、ビジネスケース作成には必ずしも最適ではありません。
- 評価: CMDBデータのインポートやサーバーの依存関係の理解には役立ちますが、ビジネスケースの作成やコスト分析にはMigration Evaluatorの方が特化しています。
- 結論: 不適切です。
最も適切な選択肢：
B: Migration Evaluator が最もコスト効果が高く、ビジネスケース作成に最適なツールです。CMDBからエクスポートされたデータをインポートし、AWSへの移行に必要なコスト分析を詳細に行い、最適なサービスを選定するために利用できます。
159-AWS SAP AWS 「理論・実践・一問道場」
理論
アプリケーション層攻撃とは？
アプリケーション層攻撃（Layer 7攻撃）は、OSI参照モデルのアプリケーション層をターゲットにした攻撃です。これらの攻撃は、サーバーのリソースを消費させることを目的として、通常のユーザーからのリクエストと見分けがつかないように偽装されます。よくある例としては、HTTP Flood攻撃、SQLインジェクション、クロスサイトスクリプティング (XSS) などがあります。
これらの攻撃は、サーバーやアプリケーションのリソースを急激に消費させ、サービスを停止させる原因となることがあります。攻撃元のIPアドレスが異なる場合も多く、IPベースでの攻撃の検出と対応が難しくなることがあります。
AWSでアプリケーション層攻撃に対応する方法
AWSには、アプリケーション層攻撃に対応するためのいくつかのツールとサービスがあります。以下に、それぞれの方法を解説します。
1. AWS WAF（Web Application Firewall）
- AWS WAFは、アプリケーション層で発生する攻撃を防ぐためのサービスです。ウェブアプリケーションの前に配置することができ、悪意のあるトラフィック（SQLインジェクションやクロスサイトスクリプティングなど）を防止します。
- AWS WAFを使用すると、アクセス制御をIPアドレスやHTTPヘッダー、URIパス、クエリ文字列などでカスタマイズでき、アプリケーション層攻撃を検出してブロックするルールを作成できます。
- Web ACL（アクセスコントロールリスト）を使用して、ALB（アプリケーションロードバランサー）との統合で、特定のIPアドレスまたはパターンに基づいてトラフィックを拒否することができます。
2. AWS Shield
- AWS Shieldは、DDoS（分散型サービス拒否）攻撃からの保護を提供するマネージドサービスです。AWS Shield Advancedは、特に高度なDDoS攻撃に対する保護を提供し、アプリケーション層攻撃にも対応します。
- AWS Shield Advancedを利用すると、攻撃を検出した際に自動的に防御が行われ、ALBやEC2インスタンスを保護します。
3. Amazon CloudWatch と AWS Lambda
- Amazon CloudWatchは、リソースの監視サービスで、アクセスログをリアルタイムで監視することができます。CloudWatchアラームを設定して、特定のしきい値を超えるトラフィック（特定のIPアドレスからの異常なアクセス）を検出し、アクションをトリガーできます。
- AWS Lambdaを利用して、CloudWatchアラームのアクションとしてIPアドレスを自動的にWAFの拒否リストに追加するなど、さらに柔軟に対応できます。
4. Amazon Route 53とジオロケーションルーティング
- Amazon Route 53は、ドメイン名システム（DNS）サービスで、ジオロケーションルーティングポリシーを使用して、リクエスト元の国別に異なるルーティングを行うことができます。
- 攻撃が特定の国から発生している場合、その国からのトラフィックを拒否することで、攻撃の影響を軽減することができます。ただし、IPアドレスが動的に変わる可能性があり、特定の攻撃に対する対応としては制限があります。
実践
略
一問道場
問題 #159
トピック 1
ある企業が、Amazon EC2 インスタンス上で実行されているウェブサイトを持ち、これらのインスタンスはアプリケーションロードバランサー (ALB) の背後に配置されています。インスタンスはオートスケーリンググループに所属しています。ALB は AWS WAF Web ACL と関連付けられています。
ウェブサイトはアプリケーション層の攻撃にしばしば直面しており、攻撃によりアプリケーションサーバーに対するトラフィックが急激かつ大幅に増加します。アクセスログには、各攻撃が異なる IP アドレスから発生していることが示されています。
ソリューションアーキテクトは、これらの攻撃を軽減するためのソリューションを実装する必要があります。
どのソリューションが最も運用負荷を低減しながらこれらの要件を満たすでしょうか？
A. サーバーアクセスを監視する Amazon CloudWatch アラームを作成し、IP アドレス別のアクセスに基づいてしきい値を設定します。アラームアクションでその IP アドレスを Web ACL の拒否リストに追加するように設定します。
B. AWS Shield Advanced を AWS WAF に追加でデプロイし、ALB を保護対象リソースとして追加します。
C. ユーザーの IP アドレスを監視する Amazon CloudWatch アラームを作成し、IP アドレス別のアクセスに基づいてしきい値を設定します。アラームが発動すると、AWS Lambda 関数を呼び出して、攻撃を起こした IP アドレスをアプリケーションサーバーのサブネットルートテーブルに拒否ルールとして追加します。
D. アクセスログを調べて攻撃を行った IP アドレスのパターンを見つけ、Amazon Route 53 のジオロケーションルーティングポリシーを使用して、その IP アドレスがホストされている国からのトラフィックを拒否します。
解説
この問題では、アプリケーション層攻撃に対する効果的な防御策を問われています。攻撃は異なるIPアドレスから行われ、アクセスログに異常なトラフィックが現れるため、IPアドレスベースでのブロックが求められています。
最も適切で運用負荷が少ない解決策は、AWS WAF（Web Application Firewall）を使用して、異常なトラフィックをフィルタリングし、CloudWatchアラームを設定して、特定のIPアドレスに対して自動的に拒否ルールを追加する方法です。この方法は、トラフィックをリアルタイムで監視し、アラームをトリガーして自動的に攻撃を緩和します。
AWS Shield Advancedは高度なDDoS攻撃に対応しますが、運用負荷を最小化するためにはWAFとCloudWatchの組み合わせが最適です。
160-AWS SAP AWS 「理論・実践・一問道場」バックアップとレプリカ
理論
- 高可用性のためのデータベース設計 高可用性を確保するためには、データベースを複数のリージョンにまたがってレプリケートすることが基本です。これにより、あるリージョンが障害を受けても、別のリージョンで即座にデータにアクセスでき、業務が停止しないようにします。
- Amazon Aurora MySQL グローバルデータベースAurora MySQLのグローバルデータベース機能は、データベースを複数のリージョンにまたがってレプリケートするための最も効果的な方法です。この機能は、読み取り専用レプリカを作成するだけでなく、書き込みレプリカにも対応しており、グローバルに分散したアプリケーションのための高可用性を提供します。これにより、主リージョンがダウンした場合、セカンダリリージョンで書き込みが可能となり、RTOとRPOの要件を満たすことができます。
- Amazon DynamoDB グローバルテーブルDynamoDBは、AWSのフルマネージドNoSQLデータベースであり、グローバルテーブル機能を利用することで、複数リージョンにデータを自動的に同期できます。これにより、異なるリージョンにあるデータベース間でリアルタイムでデータが同期され、高可用性が確保されます。
- クロスリージョンバックアップ vs. リアルタイムレプリケーションクロスリージョンバックアップは、災害復旧戦略の一環として有効ですが、RTOとRPOの要件を満たすためには不十分です。バックアップは主にデータ損失を防ぐために使用されますが、リアルタイムでのデータ同期（レプリケーション）は、即時のデータ回復と高可用性に不可欠です。
具体的な要素：
- RTO (復旧時間目標) と RPO (復旧点目標) は、ビジネスにおける「ダウンタイム」や「データ損失」の許容範囲を示す指標です。RTOが数分以内ということは、システム障害時に数分以内でサービスを復旧させる必要があることを意味します。同様に、RPOが数分以内ということは、データ損失が数分分に制限されるべきであることを示します。
- Aurora MySQLのグローバルデータベースやDynamoDBグローバルテーブルは、データを複数リージョンで自動的に同期するため、これらを使うことが最もコスト効率が良く、運用負荷が少ないソリューションです。
実践
略
一問道場
問題 #160
トピック 1
ある会社が重要なアプリケーションを運用しており、データ層は単一のAWSリージョンに展開されています。データ層はAmazon DynamoDBテーブルとAmazon Aurora MySQL DBクラスターを使用しています。現在のAurora MySQLエンジンのバージョンはグローバルデータベースをサポートしています。アプリケーション層はすでに2つのリージョンに展開されています。
会社のポリシーでは、重要なアプリケーションはアプリケーション層とデータ層の両方を2つのリージョンに展開しなければならないとされています。RTOとRPOはそれぞれ数分以内である必要があります。ソリューションアーキテクトは、データ層を会社のポリシーに準拠させるためのソリューションを推奨する必要があります。
どの組み合わせのステップがこれらの要件を満たしますか？（2つ選択してください）
A. Aurora MySQL DBクラスターに別のリージョンを追加する
B. Aurora MySQL DBクラスターの各テーブルに別のリージョンを追加する
C. DynamoDBテーブルとAurora MySQL DBクラスターのためにスケジュールされたクロスリージョンバックアップを設定する
D. 既存のDynamoDBテーブルをグローバルテーブルに変換し、設定に別のリージョンを追加する
E. Amazon Route 53 Application Recovery Controllerを使用して、セカンダリーリージョンへのデータベースバックアップと復旧を自動化する
解説
この問題では、データ層の高可用性と災害復旧の要件に対して、AWSのサービスをどう活用するかが問われています。特に、アプリケーションのデータ層が複数のリージョンに展開され、**RTO（復旧時間目標）とRPO（復旧点目標）**が数分以内であることが求められています。この要件を満たすためには、リアルタイムのデータ同期と複数リージョンでのデータアクセスが重要です。
問題の要点:
- 会社のポリシーでは、データ層が2リージョンに展開されている必要がある。
- RTOとRPOは数分以内という厳しい要件。
- 現在のデータ層はAmazon Aurora MySQL DBクラスタとDynamoDBテーブルを使用。
必要な対応:
- 高可用性を確保するため、データベースを複数のリージョンに展開することが求められます。
- リアルタイムでのデータ同期を行い、データ損失を防ぎ、即時のデータ復旧を可能にする必要があります。
各選択肢の評価:
- A. Aurora MySQL DBクラスタに別のリージョンを追加
- 正解。Aurora MySQLのグローバルデータベースは、複数リージョンにまたがるデータベースの書き込みと読み取りを可能にします。この機能を利用すれば、2つのリージョンにまたがってデータを同期し、RTOとRPOの要件を満たすことができます。
- B. Aurora MySQL DBクラスタの各テーブルに別のリージョンを追加
- 不正解。Aurora MySQLでは、データベース全体をグローバルデータベースに設定するため、個別のテーブルごとにリージョンを追加することはできません。
- C. DynamoDBテーブルとAurora MySQL DBクラスタのクロスリージョンバックアップを設定
- 不正解。バックアップは災害復旧の一環として有効ですが、RTOとRPOが数分以内という要件には適していません。バックアップはリアルタイムの同期ではないため、即座のデータ回復を提供できません。
- D. DynamoDBテーブルをグローバルテーブルに変換
- 正解。DynamoDBのグローバルテーブルを使用すると、複数のリージョンにまたがってデータがリアルタイムで同期されます。これにより、データ層が2リージョンで利用可能となり、RTOとRPOの要件を満たすことができます。
5.選択肢 E である Amazon Route 53 Application Recovery Controller に関してですが、このサービスは主に アプリケーションレベルのフェイルオーバー に関するものであり、データベースのバックアップや復旧を自動化するための直接的な方法を提供するものではありません。
結論:
この問題では、データベースを複数リージョンに展開して、リアルタイムでデータを同期することが最も重要な要素です。これを実現するためには、Aurora MySQLのグローバルデータベースやDynamoDBのグローバルテーブルを使用することが推奨されます。
したがって、正解は選択肢 A と D です。
- Author:minami
- URL:http://preview.tangly1024.com/private-license/16fd7ae8-88e2-8000-8a8e-c9e1028273cb
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
