type
status
date
slug
summary
tags
category
icon
password
书籍
041-DAX
理論
DynamoDB Accelerator (DAX) は、Amazon DynamoDB用のフルマネージド型のインメモリキャッシュサービスです。DAXはDynamoDBのパフォーマンスを向上させるために設計されており、特に読み取り要求のレイテンシ（応答時間）を大幅に短縮することができます。
主な特徴
- インメモリキャッシュ
DAXはDynamoDBのデータをインメモリにキャッシュし、高速な読み取り操作を提供します。これにより、データベースにアクセスする際の遅延が大幅に削減され、アプリケーションのレスポンス速度が向上します。
- フルマネージド
DAXは完全に管理されているサービスであり、インフラストラクチャのセットアップや管理、スケーリング、パッチ適用などの運用作業をAWSが自動で処理します。これにより、運用負担が軽減されます。
- DynamoDBと完全に統合
DAXはDynamoDBとシームレスに統合されており、DynamoDBのAPIと互換性があります。アプリケーションコードの変更を最小限に抑えつつ、キャッシュ機能を追加することができます。
- キャッシュの効果的な利用
DAXは主に読み取り要求をキャッシュするため、読み取り負荷が高いワークロードに最適です。データベースの負荷を軽減し、スケーラビリティとパフォーマンスを向上させます。
使用例
- 頻繁にアクセスされるデータをキャッシュして、データベースの負荷を削減したい場合。
- レイテンシが極めて重要なアプリケーション（例：リアルタイム分析やゲームなど）の場合。
- 高頻度で読み取り要求が発生するが、書き込みは比較的少ないワークロードに対して。
DAXを使うと、DynamoDBテーブルに対する読み取り操作がキャッシュされ、繰り返し同じデータを読み取る際に高速にレスポンスを得ることができます。
実践
略
一問道場
問題 #41
ある企業が最近、AWSにアプリケーションを展開しました。このアプリケーションはAmazon DynamoDBを使用しています。企業はアプリケーションの負荷を測定し、DynamoDBテーブルのRCU（リードキャパシティユニット）とWCU（ライトキャパシティユニット）を予想されるピーク負荷に合わせて設定しました。ピーク負荷は毎週1回、4時間の期間で発生し、通常の負荷の2倍となります。それ以外の期間は、アプリケーションの負荷は平均負荷に近いです。アクセスパターンは、テーブルへの書き込みが読み込みよりも遥かに多いです。
ソリューションアーキテクトはテーブルのコストを最小化するソリューションを実装する必要があります。
どのソリューションがこの要件を満たすでしょうか？
- A. AWS Application Auto Scalingを使用してピーク期間中にキャパシティを増加させる。平均負荷に合わせてRCUとWCUを予約購入する。
- B. テーブルにオンデマンドキャパシティモードを設定する。
- C. DynamoDB Accelerator（DAX）をテーブルの前に設定し、テーブルの新しいピーク負荷に合わせてプロビジョニングされたリードキャパシティを減らす。
- D. DynamoDB Accelerator（DAX）をテーブルの前に設定し、テーブルにオンデマンドキャパシティモードを設定する。
解説
- A は、ピーク時にキャパシティを増加させ、通常時に予約購入でコストを抑えようとする方法です
- このソリューションは、ピーク時に容量を自動的に増加させるために Application Auto Scaling を使用することで、平均負荷の2倍に対応します。そして、平均負荷に見合う予約済みの RCU（読み込みキャパシティーユニット）および WCU（書き込みキャパシティーユニット）を購入することで、負荷が平均に近い週の残りの期間のテーブルコストを最小限に抑えます。
042-DAX
理論
1. AWSのスケーラブルなサービス利用
クラウドサービスを活用することで、オンプレミスの限界を超えたスケーラビリティを提供できます。AWSでは、トラフィックや負荷に応じてリソースを動的に増減させることが可能です。
- Amazon SQS (Simple Queue Service): メッセージングサービスで、分散アプリケーション間でメッセージを送受信できます。ファイル処理のような分散処理において、作業を効率よく並列処理するために活用できます。
- AWS Lambda: サーバーレスコンピューティングサービスで、コードを実行するためにサーバーの管理が不要です。これにより、処理を自動化でき、スケーラビリティも向上します。ファイル処理などの負荷に応じてLambdaを起動し、柔軟にリソースを使うことができます。
2. コスト最適化
AWSでは、リソースを使用する分だけ料金が発生します。したがって、ビジネスの負荷に合わせてリソースを動的に調整することが重要です。以下の方法でコストを最適化できます。
- オンデマンド：AWSの「オンデマンド」サービスは、リソースを必要なときに必要なだけ使えるため、特にピーク時間が予測できる場合に有効です。LambdaやSQSなど、必要なときにだけリソースを活用することで、無駄なコストを削減できます。
- EC2オートスケーリング：EC2インスタンスを使用する場合、オートスケーリングを利用して負荷が高い時だけインスタンスを増加させ、負荷が低い時に自動で減少させることで、コストを抑えることができます。
3. メッセージングと分散システムの活用
このケースのように、データの処理を並列化し、負荷に応じてリソースを効率的に使うためには、メッセージングシステムや分散処理が非常に重要です。AWSでは、メッセージキュー（Amazon SQSやAmazon MQ）を使って、非同期でタスクを処理し、スケーラブルなシステムを構築できます。
- Amazon SQS: 並列処理を簡単に実現できるため、負荷が増加する時間帯でも効率的にリソースを使い、コストを最適化できます。
- Amazon MQ: 高度なメッセージング機能を持つマネージドサービスで、特に大規模で信頼性が必要な場合に適しています。
4. サーバーレスアーキテクチャ
サーバーレスアーキテクチャは、サーバーの管理を必要とせず、処理能力を柔軟にスケールできます。AWS Lambdaなどを利用することで、サーバーの管理負担を軽減し、トラフィックの増減に応じて必要なリソースだけを使用することができます。
まとめ
この問題では、AWSのスケーラブルなサービス（Amazon SQS、AWS Lambda、Amazon EC2オートスケーリングなど）を駆使して、負荷に応じた動的なリソース管理を行い、コスト最適化を実現する方法を選択することが求められます。特に、処理待ちファイルの数が業務時間中に増減するという状況を考慮すると、リソースのスケールアップ・ダウンが自動で行えるAWSのサービスを活用するのが重要です。
以下に、Amazon SQS と Amazon MQ の主な違いを簡潔にまとめた表を作成しました：
特徴 | Amazon SQS | Amazon MQ |
サービスの種類 | マネージドなキューサービス | マネージドなメッセージブローカーサービス |
メッセージタイプ | 非同期メッセージ、データストレージが可能 | メッセージブローカーを使ったプロトコル対応 |
プロトコル | 標準的なAPI | AMQP, MQTT, STOMP など複数のプロトコル対応 |
使用例 | スケーラブルなメッセージキュー、簡単な非同期処理 | 複雑なメッセージングシステム、オンプレミスとの互換性 |
スケーラビリティ | 高スケーラブル、自動で拡張 | 手動でスケーリング、制限あり |
可用性 | 高可用性、冗長性が組み込まれている | 高可用性が提供されるが、SQSほど自動ではない |
管理の手軽さ | フルマネージドで非常に簡単に使える | 複雑な管理が必要、設定がやや手間 |
この表を使って、どちらのサービスが自分の用途に適しているかを簡単に比較できます。
実践
略
一問道場
問題 #42
トピック 1
企業は、オンプレミスのデータ処理アプリケーションをAWSクラウドに移行しようとしています。現在、ユーザーはウェブポータルを通じて入力ファイルをアップロードし、その後、ウェブサーバーがファイルをNASに保存し、メッセージキューを使って処理サーバーに通知します。各メディアファイルの処理には最大1時間かかります。業務時間中は処理待ちのファイル数が急増し、業務時間外には急激に減少します。
最もコスト効率の良い移行方法はどれですか？
- A. Amazon SQSを使用してキューを作成し、
既存のウェブサーバーを設定して、メッセージを新しいキューに送信します。
メッセージがあると、AWS Lambda関数が自動でリクエストを取り出して処理します。
処理後、ファイルはAmazon S3バケットに保存します。
- B. Amazon MQを使ってキューを作成し、
既存のウェブサーバーを設定して、メッセージを新しいキューに送信します。
メッセージがあると、新しいAmazon EC2インスタンスが自動でリクエストを取り出して処理します。
処理後、ファイルはAmazon EFSに保存され、タスク完了後にEC2インスタンスは停止します。
- C. Amazon MQを使ってキューを作成し、
既存のウェブサーバーを設定して、メッセージを新しいキューに送信します。
メッセージがあると、AWS Lambda関数が自動でリクエストを取り出して処理します。
処理後、ファイルはAmazon EFSに保存されます。
- D. Amazon SQSを使ってキューを作成し、
既存のウェブサーバーを設定して、メッセージを新しいキューに送信します。
EC2オートスケーリンググループを使用して、EC2インスタンスが自動でリクエストを取り出して処理します。
EC2インスタンスは、SQSキューの長さに基づいてスケールします。処理後、ファイルはAmazon S3バケットに保存されます。
この問題では、最もコスト効率が良い方法を選ぶ必要があります。
解説
選択肢A: AWS LambdaとSQS
- AWS Lambda は、サーバーレスのコンピューティングサービスで、リクエストが発生した際にコードを実行する仕組みですが、1回の実行に最大15分の制限があります。したがって、処理時間が最大1時間かかる場合、Lambdaは適していません。もしLambdaを使用すると、処理が途中でタイムアウトしてしまう可能性が高いです。
- Amazon SQS はメッセージキューとして、メッセージが来るたびに処理を開始できる仕組みですが、Lambdaとの組み合わせでは、長時間の処理が必要なシナリオに対応できません。
このため、選択肢A は、処理時間が1時間かかるという要件には適していません。
選択肢B: Amazon MQとEC2インスタンス
- Amazon MQ は、メッセージングサービスで、メッセージを受け取った際に EC2インスタンス を起動して処理を行う設計です。
- EC2インスタンス は、長時間実行することができ、1時間程度の処理時間を必要とするタスクには適しています。タスクが完了した後、インスタンスを停止することで、無駄なコストを削減できます。
- しかし、このアーキテクチャではEC2インスタンスを手動で起動・停止する必要があるため、管理の手間やコストが増加する可能性があります。また、インスタンスを適切にスケーリングする仕組みを別途用意しなければならないため、管理が煩雑になる場合があります。
選択肢B は長時間の処理には向いていますが、運用の効率を考えると他の選択肢の方が適している可能性があります。
選択肢C: Amazon MQとAWS Lambda
- Amazon MQ を使ってメッセージをキューに送り、AWS Lambda を使って処理する設計ですが、再度、Lambdaは最大15分の実行制限があるため、この選択肢も長時間の処理には適していません。
- したがって、処理時間が最大1時間かかる場合、選択肢C も不適切です。
選択肢D: Amazon SQSとEC2オートスケーリング
- Amazon SQS を使ってメッセージキューを作成し、処理のために EC2オートスケーリンググループ を使用する設計です。EC2インスタンスは、スケールアップ（インスタンスの増加）やスケールダウン（インスタンスの減少）に対応できます。
- EC2オートスケーリング は、トラフィックの増減に応じて自動的にインスタンスを増減させるため、業務時間中の急増したリクエストにも対応できます。処理が最大1時間かかるという要件にも十分対応できることが分かります。
- また、処理後のファイルは Amazon S3 に保存されるため、コスト効率が良く、スケーラブルで高可用性なストレージが確保されます。
選択肢D は、長時間の処理と急増するリクエストに対してスケーラブルで効率的な解決策を提供するため、最もコスト効率の良い方法となります。
結論
処理に最大1時間かかることを踏まえると、選択肢D が最適です。EC2インスタンスを使用し、オートスケーリングで負荷に応じてリソースを調整できるため、長時間の処理と変動するトラフィックに柔軟に対応できます。また、Amazon S3を使用したストレージもコスト効率が良いため、この構成が最も適切です。
043-Amazon OpenSearch Service
理論
1. データノード（Data Node）
- 役割：データの保存、シャードの管理、クエリや集計の処理。
- 構成の考慮要素：
- データ量：データが大量の場合、より多くのデータノードが必要。
- クエリ負荷：クエリが多い場合、データノードを増やして負荷を分散させる。
- ストレージ容量：データノードのストレージ容量が限られているため、データ量に応じてノードを増やす必要がある。
- バックアップコピー：高可用性のためにレプリカ（副本）を増やすと、データノードの数が増加する。
構成のアドバイス：
- データ量が多い場合、複数のデータノードを使用して処理能力を確保する。
- クエリが多い場合、データノードの数を増やしてパフォーマンスを向上させる。
2. マスターノード（Master Node）
- 役割：クラスタのメタデータ管理、ノードの健康管理、シャードの割り当て。
- 構成の考慮要素：
- クラスタの規模：クラスタが大きい場合、マスターノードを専用に設定することで安定性と効率性を保つ。
- クラスタの安定性：マスターノードはクラスタの「脳」として重要なので、冗長化を図り、故障に備える。
構成のアドバイス：
- 小規模クラスタ：1つのマスターノード（ただし、冗長化のために3つのマスターノードが推奨される）。
- 中規模から大規模クラスタ：3つのマスターノードを推奨。冗長性と可用性を確保。
3. コーディネーターノード（Coordinator Node）
- 役割：外部のリクエスト（例：クエリ）を受け付け、データノードに転送し、結果を統合してユーザーに返す。コーディネーターノード自体はデータを保存したりシャードを処理したりしない。
- 構成の考慮要素：
- クエリ負荷：クエリが大量の場合、複数のコーディネーターノードを配置して負荷を分散させる。
- スループットの要求：コーディネーターノードの数とパフォーマンスがクエリ性能に大きな影響を与える。
構成のアドバイス：
- 大量のクエリ負荷がある場合にコーディネーターノードを増やす。通常、データノードがコーディネーターノードの役割も担うことが多いが、負荷が高い場合は分離することも検討する。
4. UltraWarmノード（UltraWarm Node）
- 役割：アクセス頻度が低いデータを保存し、S3にデータを格納してコストを削減するが、クエリ性能は低くなる。
- 構成の考慮要素：
- データ保存の必要性：大量の歴史データを保存するが、アクセス頻度が低いデータの場合、UltraWarmノードが適している。
- コスト削減：UltraWarmノードはコストが低いため、大量のデータを安価に保存できる。
構成のアドバイス：
- 大量のデータを保存する必要がある場合、UltraWarmノードを利用してコストを削減できる。
- 低頻度アクセスのデータを長期保存する際に有効。
5. ホットノード（Hot Node）
- 役割：リアルタイムデータを保存し、高速なクエリをサポート。データやインデックスはメモリや高速なディスクに保存される。
- 構成の考慮要素：
- リアルタイムクエリの要求：高速なレスポンスが必要なクエリには、ホットノードが不可欠。
- リアルタイムデータの流れ：ログ分析や検索など、頻繁に更新されるデータに必要。
構成のアドバイス：
- リアルタイムデータを処理する場合、ホットノードの数をデータ量に合わせて設定する。
- クエリ性能が重要な場合は、ホットノードを増やす。
6. コールドノード（Cold Node）
- 役割：長期間アクセスされないデータを保存し、クエリ遅延は高くなるが、ストレージコストは非常に低い。
- 構成の考慮要素：
- アーカイブデータ：アクセス頻度が低く、長期保存が必要なデータを格納する。
- データのアーカイブ：歴史的な記録やアーカイブデータを保存するのに適している。
構成のアドバイス：
- 非常に低頻度のアクセスデータに対してコールドノードを使用し、ストレージコストを削減する。
クラスタノードの構成に関するアドバイス
- 小規模クラスタ：
- データノード：1〜3台。
- マスターノード：1台（冗長性のために3台以上推奨）。
- コーディネーターノード：データノードが担当。
- UltraWarmノード：必要なら1〜2台。
- ホットノード：データ量に応じて1〜3台。
- 中規模クラスタ：
- データノード：3〜5台。
- マスターノード：3台。
- コーディネーターノード：1〜2台。
- UltraWarmノード：必要なら3〜4台。
- ホットノード：3〜5台。
- 大規模クラスタ：
- データノード：10台以上（データ量とクエリ要求に応じて）。
- マスターノード：3台。
- コーディネーターノード：複数台。
- UltraWarmノード：大量の歴史データがある場合に増加。
- ホットノード：大量のリアルタイムデータがある場合に増加。
まとめ
クラスタノードの数量と種類の適切な構成は、ビジネスニーズや負荷に応じて調整する必要があります。それぞれのノードタイプは異なる役割を持ち、次のように使い分けます：
- データノード：データの保存と処理。
- マスターノード：クラスタ管理。
- コーディネーターノード：クエリ負荷の分散。
- UltraWarmノード：コスト削減のための歴史データ保存。
- ホットノード：リアルタイムデータの保存とクエリ処理。
適切なノード構成により、クラスタのパフォーマンスや可用性を最大化し、コストを最小化できます。
一問道場
質問 #43
ある企業がAmazon OpenSearch Serviceを使用してデータを分析しています。企業はAmazon S3バケットから、S3 Standardストレージを使用して10台のデータノードからなるOpenSearch Serviceクラスタにデータをロードします。このデータは1ヶ月間、読み取り専用の分析用にクラスタ内に保持されます。1ヶ月後、企業はクラスタからデータを含むインデックスを削除します。コンプライアンス上、企業はすべての入力データのコピーを保持する必要があります。企業は継続的なコストを懸念しており、ソリューションアーキテクトに新しいソリューションを推奨するよう依頼しています。
どのソリューションが最もコスト効率よく要件を満たしますか？
- A. すべてのデータノードをUltraWarmノードに置き換え、予想される容量を処理します。データをクラスタにロードする際、入力データをS3 StandardからS3 Glacier Deep Archiveに移行します。
- B. クラスタのデータノードの数を2に削減し、予想される容量を処理するためにUltraWarmノードを追加します。OpenSearch Serviceがデータを取り込む際、インデックスをUltraWarmに移行するように設定します。1ヶ月後、S3ライフサイクルポリシーを使用して入力データをS3 Glacier Deep Archiveに移行します。
- C. クラスタのデータノードの数を2に削減し、予想される容量を処理するためにUltraWarmノードを追加します。OpenSearch Serviceがデータを取り込む際、インデックスをUltraWarmに移行するように設定します。コールドストレージノードをクラスタに追加し、インデックスをUltraWarmからコールドストレージに移行します。1ヶ月後、S3ライフサイクルポリシーを使用してS3バケットから入力データを削除します。
- D. クラスタのデータノードの数を2に削減し、予想される容量を処理するためにインスタンスバックされたデータノードを追加します。データをクラスタにロードする際、入力データをS3 StandardからS3 Glacier Deep Archiveに移行します。
解説
問題の要点
会社がAmazon OpenSearch Serviceを使用してデータ分析を行っています。現在、データは1ヶ月間分析用に保存され、その後削除されます。会社は、入力データのコピーを保持する必要があり、コスト効率を最適化したいという要件があります。
オプションの分析
- A.
- 変更点: すべてのデータノードをUltraWarmノードに変更し、入力データをS3 Glacier Deep Archiveに移行する。
- 評価: UltraWarmノードは低コストのストレージを提供し、クエリ頻度が低いデータに適しています。しかし、データをS3 Glacier Deep Archiveに保存することで、データのアクセスには時間がかかり、リアルタイムアクセスが必要な場合には不便です。
- B.
- 変更点: データノードを2に削減し、UltraWarmノードを追加。データの保存後1ヶ月後にS3 Glacier Deep Archiveに移行するためにS3ライフサイクルポリシーを使用。
- 評価: UltraWarmノードは分析用に適しており、データの保存後にコスト効率よくS3 Glacier Deep Archiveに移行できる点で理にかなっています。
- C.
- 変更点: UltraWarmノードに加え、Cold Storageノードを追加。データをUltraWarmからCold Storageに移行。
- 評価: Cold Storageはさらにコスト効率の良い長期保存オプションですが、追加の構成が必要で、シンプルさとコスト効率の観点では少し複雑になります。
- D.
- 変更点: データノードを2に削減し、インスタンスバックデータノードを追加。データはS3 Glacier Deep Archiveに移行。
- 評価: インスタンスバックデータノードは、UltraWarmノードに比べて高コストになる可能性があります。このオプションは他の選択肢と比べてコスト効率が低いと考えられます。
最もコスト効率の良い解決策はB
- 理由:
- データノードを削減し、UltraWarmノードで低コストのストレージを使用。
- S3 Glacier Deep Archiveに移行するためにS3ライフサイクルポリシーを使用することで、1ヶ月後にコスト効率良くデータを保存できます。
- S3 Glacier Deep Archiveは長期保存に最適であり、コストを抑えることができます。
したがって、Bの選択肢が最もコスト効率が高いと評価されます。
044-AWS config
理論
AWS Organizationsの理解
AWS Organizations は、複数のAWSアカウントを一元的に管理するためのサービスです。大規模な企業や組織では、複数のAWSアカウントを使用して異なるプロジェクトや部門を分けることが一般的ですが、AWS Organizationsを使うことで、これらのアカウントをグループ化し、中央からポリシーを適用したり、請求を一元管理したりできます。
- Organizational Units (OUs) を使って、アカウントを論理的にグループ化し、各OUごとに異なる管理や制限を設定できます。これにより、セキュリティ、リソース管理、アクセス制御を効率的に行うことが可能です。
Amazon EventBridgeの活用
Amazon EventBridge は、AWSリソース間でリアルタイムのイベントを送信するためのサービスです。例えば、あるAWSリソースで特定のアクションが実行されたときに、EventBridgeを使ってそのイベントをトリガーし、他のAWSサービスや外部のシステムに通知を送ることができます。
- EventBridgeでは、ルール を設定して、特定の条件に合ったイベントをフィルタリングし、それに基づいてアクションを起こすことができます。これにより、運用管理を自動化したり、イベント駆動型のアーキテクチャを構築することが可能です。
種類：
機能 | 説明 | 具体例 |
EventBridge ルール | 受信イベントをルールで照合し、処理のためにターゲットに送信します。 | EC2 インスタンスが起動したイベントを検知し、SNS トピックに通知を送信する。 |
EventBridge パイプ | オプションのフィルタリングとエンリッチメントを使用してイベントソースをターゲットに接続します。 | Amazon DynamoDB ストリームからデータを取得し、一部の項目をフィルタリング後、AWS Lambda に送信する。 |
EventBridge スケジュール | ターゲットを一度だけ、または cron 式や rate 式で定義した間隔で定期的に呼び出します。 | 毎日午前9時に Lambda 関数を呼び出し、定期的に S3 バケットのデータを処理する。 |
EventBridge スキーマレジストリ | スキーマを収集し整理して、イベントデータの構造を明確化します。 | カスタムアプリケーションのイベントをスキーマレジストリに登録し、開発者がスキーマを参照してコードを生成する。
|
イベントバス (Event Bus) は、Amazon EventBridge のコアコンポーネントの一つで、イベントを受け取り、ルールによってターゲットにルーティングする仕組みです。イベントバスは、複数のイベントソース（AWSサービス、カスタムアプリケーション、SaaSアプリケーション）からイベントを受け取り、指定されたルールに従って処理します。
特徴
- イベントの集約ポイント 複数のソースからのイベントを一か所で受信。
- ルールによるルーティング ルールを設定することで、イベントを特定のターゲットに送信可能。
- デフォルトバスとカスタムバス AWSアカウントにはデフォルトのイベントバスがあり、必要に応じてカスタムイベントバスを作成可能。
具体例
- デフォルトイベントバスの使用
- ソース: AWS CloudTrail からの API 呼び出しイベント
- ルール: 特定の IAM ユーザーが S3 バケットにアクセスした場合のイベントを検知。
- ターゲット: SNS トピックに通知を送信。
- カスタムイベントバスの使用
- ソース: 独自アプリケーションから送信されたカスタムイベント。
- ルール: イベント内のデータに基づいて、重要度が「高」の場合のみ処理。
- ターゲット: AWS Lambda 関数を起動してイベントを処理。
- SaaS イベントの処理
- ソース: Zendesk や Shopify などの SaaS アプリケーションのイベント。
- ルール: 注文がキャンセルされたイベントを検知。
- ターゲット: カスタマーサポート用の通知を送信。
イベントバスとルールの関係
イベントバスはイベントを集約する場で、ルールがフィルターとなり、イベントの送信先を決定します。例えば、デフォルトイベントバスに届くすべてのイベントをそのまま送信することも、特定の条件でフィルタリングして処理することも可能です。
Amazon SNS (Simple Notification Service) の活用
Amazon SNS は、通知を送信するためのフルマネージドなメッセージングサービスです。SNSを使用することで、システムからのアラートやイベント通知を、異なるサブスクライバー（例えば、セキュリティチームや管理者）に送信することができます。
- SNSは、メールやSMS、他のAWSサービス、HTTPエンドポイントに通知を送信することができ、通知の配信方法を柔軟に選択できます。特に、セキュリティやシステム監視において、リアルタイムの通知を送信するためにSNSを活用することがよくあります。
AWS Configによる設定監視とコンプライアンス管理
AWS Config は、AWSリソースの設定を監視し、その変更履歴を追跡するサービスです。これにより、リソースが意図したとおりに設定されているかを確認したり、設定が変更された場合に通知を受けたりすることができます。
- AWS Config管理ルール を使用すると、特定の設定ポリシーに対してリソースが準拠しているかを評価できます。例えば、セキュリティグループの設定が適切かどうかを監視し、不正な設定が行われた場合にアラートを発生させることができます。
vpc-sg-open-only-to-authorized-portsは、AWS Config の管理されたルールで、VPC内のセキュリティグループが承認されたポートのみを開放しているかどうかを評価します。このルールは、セキュリティグループに不必要なポート（例えば、全てのIPアドレスに対してポート0.0.0.0/0を開放する設定）が含まれていないかを確認し、セキュリティリスクを減らすための警告を発します。
- AWS Lambda関数と統合して、AWS Configの違反が検出された際に自動的に修正を実行する仕組みを導入することもできます。
Service Control Policies (SCP)によるアクセス制御
Service Control Policies (SCPs) は、AWS Organizations内でアカウントやOUに対するアクセス制御を行うための機能です。SCPは、アカウント内でどのAWSサービスにアクセスできるか、どのアクションを実行できるかを制御することができます。
- SCPを利用することで、特定の操作やアクションを制限することができます。たとえば、あるOUに対してセキュリティグループ設定を変更するアクションを制限することができ、セキュリティリスクを低減させることができます。
セキュリティグループとインバウンドルールの管理
セキュリティグループ は、AWS EC2インスタンスのネットワークアクセスを制御するための仮想ファイアウォールです。セキュリティグループは、インスタンスへのインバウンドおよびアウトバウンドトラフィックを許可または拒否するルールを設定できます。
- インバウンドルール の設定には、IPアドレス（例えば
0.0.0.0/0）を指定することができますが、これを不適切に設定すると、インターネット全体からのアクセスを許可してしまい、セキュリティリスクが増大します。セキュリティグループの適切な管理が、AWS環境におけるセキュリティの要となります。
まとめ
これらのサービスや機能を組み合わせることで、AWS環境でのリソースの管理、セキュリティ、監視を効率的に行うことができます。特に、AWS Organizationsを使ったアカウント管理、Amazon EventBridgeとSNSを利用した通知システム、AWS Configによる設定監視、そしてSCPを利用したポリシー制御により、企業はセキュリティやコンプライアンスを強化し、運用負荷を減らすことができます。
実践
参照元：
AWS Configルールを使用してEC2インスタンスとS3バケットのタグを検証し、通知を送信する
概要:
このハンズオンでは、AWS Configルール「required-tags」を作成し、EC2インスタンスとS3バケットに「Name」と「Application」のタグが付与されているかを判定します。判定結果がNGの場合、Amazon EventBridgeを使って通知を検知し、Amazon SNSを通じてEメールで通知される仕組みを構築します。
1. 前提条件
以下のサービスを事前に設定しておく必要があります：
- AWSアカウントにサインイン
- IAMロールが必要な権限を持っていること
- SNSトピックを作成するための設定が整っていること
- EC2インスタンスとS3バケットが存在していること
2. AWS Configルールの作成
- AWS Configダッシュボードに移動:
- AWSマネジメントコンソールにログインし、
AWS Configを検索して選択します。
- 新規ルールの作成:
- 「Rules」メニューに移動し、「Add rule」をクリックします。
- ルールテンプレートで「
required-tags」を選択します。
- ルールの設定:
- リソースタイプで「EC2インスタンス」と「S3バケット」を選択します。
- 必要なタグとして「Name」と「Application」を指定します。
- ルールを有効にし、「Save」をクリックして設定を保存します。
これで、指定したタグが付与されていないEC2インスタンスとS3バケットが検出されるようになります。
3. Amazon EventBridgeの設定
- EventBridgeの作成:
- AWSマネジメントコンソールから
Amazon EventBridgeを検索し選択します。 - 「Create rule」をクリックし、新しいルールを作成します。
- ルールの設定:
- 「Event Pattern」で「AWS Config」を選択します。
- イベントパターンに「
ConfigRuleComplianceChange」を設定します。
- ターゲット設定:
- 「Select targets」で「SNS topic」を選択します。
- 先ほど作成したSNSトピックを選択します。
- ルールの保存:
- ルールを有効にして、「Create」をクリックします。
4. Amazon SNSの作成と設定
- SNSトピックの作成:
- AWSマネジメントコンソールから
Amazon SNSを検索して選択します。 - 「Create topic」をクリックし、「Standard」を選択します。
- トピック名を指定（例:
RequiredTagsNotification）し、「Create topic」をクリックします。
- サブスクリプションの作成:
- SNSトピックの詳細ページに移動し、「Create subscription」をクリックします。
- プロトコルとして「Email」を選択し、通知を受け取るメールアドレスを入力します。
- 送信された確認メールを承認します。
5. テストと確認
- タグの不正なEC2インスタンスとS3バケットの作成:
- タグ「Name」と「Application」が設定されていないEC2インスタンスまたはS3バケットを作成します。
- AWS Configルールが非準拠を検出:
- AWS Configがリソースを評価し、タグが不足している場合は、非準拠として検出されます。
- EventBridgeの通知確認:
- EventBridgeがAWS Configからの非準拠イベントを受信し、設定したSNSトピックに通知を送信します。
- メール通知が届いたことを確認します。
6. まとめ
このハンズオンでは、AWS Configルール「required-tags」を使用して、EC2インスタンスとS3バケットに必要なタグが付与されているかを確認し、非準拠の場合にAmazon EventBridgeを通じてAmazon SNSに通知を送信する仕組みを構築しました。これにより、タグの管理が効率的に行えるようになります。
この手順で設定を進めることで、タグ管理が強化され、EC2インスタンスやS3バケットが適切なタグを持っていない場合に自動で通知が届く仕組みが完成します。
一問道場
問題文
ある会社が AWS Organizations の組織に属する 10 のアカウントを持っています。
AWS Config は各アカウントで設定されています。すべてのアカウントは、Prod OU または NonProd OU のいずれかに属しています。
この会社では、Amazon EC2 のセキュリティグループにおいて、インバウンドルールでソースとして
0.0.0.0/0 が指定された場合、Amazon Simple Notification Service (Amazon SNS) トピックに通知を送信する Amazon EventBridge ルールを各 AWS アカウントで設定しています。セキュリティチームは、この SNS トピックを購読しています。
NonProd OU に属するすべてのアカウントについて、セキュリティチームは、
0.0.0.0/0 をソースとするセキュリティグループのインバウンドルールを作成する機能を削除する必要があります。要件
次のうち、最小限の運用負荷でこの要件を満たすソリューションはどれですか？
選択肢
A.
EventBridge ルールを修正して、AWS Lambda 関数を呼び出し、セキュリティグループのインバウンドルールを削除し、SNS トピックに通知を送信するように設定します。この更新されたルールを NonProd OU にデプロイします。
B.
vpc-sg-open-only-to-authorized-ports AWS Config のマネージドルールを NonProd OU に追加します。C.
Service Control Policy (SCP) を設定して、
aws:SourceIp 条件キーの値が 0.0.0.0/0 ではない場合に ec2:AuthorizeSecurityGroupIngress アクションを許可するようにします。この SCP を NonProd OU に適用します。D.
SCP を設定して、
aws:SourceIp 条件キーの値が 0.0.0.0/0 の場合に ec2:AuthorizeSecurityGroupIngress アクションを拒否するようにします。この SCP を NonProd OU に適用します。解説
A. EventBridge + Lambda:
セキュリティグループのルールをリアルタイムで削除する仕組みを作成するが、Lambda のデプロイや管理が必要で運用負荷が高い。
B. AWS Config のマネージドルール:
AWS Config のルールはルール違反を検出するのみで、制限を強制する機能はないため要件を満たさない。
C. SCP (許可ベース):
特定条件での許可を設定するが、条件を反転するため設定が複雑になり、ミスが起きやすい。
D. SCP (拒否ベース):
aws:SourceIp が 0.0.0.0/0 の場合のアクションを拒否するポリシーを設定。明確でシンプル、運用負荷が最も低い。正解: D
SCP を使った拒否ベースのアプローチが要件を最も効率的に満たします。
045-Webhook
理論
1. Gitリポジトリ
Gitリポジトリとは、ソフトウェアのコードやプロジェクトの履歴を管理するための場所です。Gitはバージョン管理ツールで、コードの変更履歴を追跡したり、チームでコードを共同作業する際に役立ちます。
簡単に言うと、Gitリポジトリは「コードの保管庫」や「コードの歴史を記録する場所」です。
2. Webhook
Webhookは、あるイベントが発生したときに、自動的に指定されたURLにHTTPリクエストを送信する仕組みです。これにより、異なるシステムやサービスがリアルタイムで連携できます。
例として、Gitリポジトリでコードを更新したときに、その情報を別のシステム（例えばデプロイ用のサーバーや通知サービス）に送信するためにWebhookが使われます。
具体的な流れは以下のようになります：
- Gitリポジトリでコードの変更があったとき
- Webhookがその情報を指定されたURL（例えば、APIエンドポイントやサーバー）に自動で送信
- 受け取ったサーバーはその情報を基に、例えば自動的にコードをデプロイしたり、通知を行ったりします
Webhookは、外部のシステムにイベントを通知するために利用され、リアルタイムでの連携を助けます。
Webhookロジックとは、Webhookが送信したリクエストを受け取って処理する一連の操作や機能のことを指します。具体的には、Webhookから送られてくるデータを元に何らかのアクションを実行する部分です。
Webhookロジックの流れ
- Webhookリクエストの受信
Gitなどの外部システムからWebhookがトリガーされ、指定されたURLにHTTPリクエストが送信されます。このリクエストには、変更された内容やその他の情報が含まれています。
- リクエストの処理
Webhookロジックは、リクエストを受け取って、その内容を解析します。例えば、Gitのリポジトリでコードが変更されたことを示す情報を処理し、必要な操作を実行します。
- アクションの実行
- コードのデプロイ
- 自動テストの実行
- チームへの通知
Webhookロジックは、受け取った情報に基づいて、次のアクションを実行します。例えば、次のようなことが考えられます：
- 結果の返却（必要に応じて）
Webhookロジックが処理を完了した後、結果を呼び出し元に返すこともあります。例えば、「成功した」とか「エラーが発生した」といったステータスを返すことがあります。
例
- GitのWebhookの場合、リポジトリにコードがプッシュされると、Webhookが呼び出され、そのリクエストに基づいてCI/CD（継続的インテグレーション／継続的デリバリー）のツールが自動的にコードをビルドしたり、テストを実行したりします。この処理がWebhookロジックです。
Webhookロジックは、主にWebhookを受けて実行する必要がある機能やアクションを含んでおり、他のシステムと自動で連携するために非常に重要な役割を果たします。
3.AWS App Runner
AWS App Runner は、開発者がコードを簡単にコンテナ化して、スケーラブルな Web アプリケーションや API を運用できるフルマネージドのサーバーレスサービスです。App Runner を使用することで、インフラの管理を意識せずにアプリケーションのデプロイとスケーリングが可能になります。
主な特徴
- サーバーレス運用: サーバーの管理を必要とせず、アプリケーションを自動的にスケールさせます。
- 簡単なデプロイ: GitHub や Amazon ECR からソースコードやコンテナイメージを直接デプロイできます。
- 自動スケーリング: トラフィックの需要に応じて、アプリケーションのインスタンス数が自動でスケールします。
- 簡単な設定: アプリケーションのデプロイや管理が簡単で、インフラ設定やオーケストレーションを気にする必要がありません。
使い方
- GitHub / GitLab などのリポジトリを連携して、コードを自動的にデプロイ。
- コンテナイメージ（例えば Amazon ECR から）を使用して、アプリケーションを直接デプロイ。
App Runner は、サーバーレスの利便性と簡易性を提供し、インフラ管理の負担を軽減するため、特に Web アプリケーションや API に向いています。
以下は ECS、EKS、AWS App Runner の簡単な比較です。
特徴 | Amazon ECS | Amazon EKS | AWS App Runner |
管理対象 | コンテナ管理サービス、EC2 または Fargate 上で動作 | Kubernetes クラスター管理 | サーバーレス、コンテナのデプロイを簡単に管理 |
柔軟性 | 高い柔軟性、カスタマイズ可能 | Kubernetes による非常に高い柔軟性 | シンプルで自動化された管理 |
利用シナリオ | 複雑なコンテナアプリケーション | 複雑でスケーラブルなマイクロサービス | シンプルなコンテナアプリケーションのデプロイ |
スケーリング | 手動で設定、オートスケーリング対応 | Kubernetes を使ったスケーリング | 自動スケーリング |
運用管理 | 自動化されていない部分も多い、管理が必要 | Kubernetes の運用管理に関する深い知識が必要 | インフラ管理不要、ほぼ全自動で管理 |
対象ユーザー | 高度なカスタマイズが必要なユーザー | Kubernetes に精通しているユーザー | 簡単なデプロイを希望する開発者 |
まとめ
- ECS はコンテナの柔軟な管理が可能ですが、設定や運用に関しては手動で行う部分が多く、よりカスタマイズされた運用が求められます。
- EKS は Kubernetes を使用した非常に高い柔軟性を提供しますが、運用や管理が難しく、Kubernetes の知識が必要です。
- AWS App Runner はサーバーレスで、インフラの管理やスケーリングを気にせずに簡単にアプリケーションをデプロイできるため、最小限の運用負荷で開発者が集中できる環境を提供します。
実践
アプリケーションの用意
- ディレクトリ作成:
- ファイル作成:
index.js:package.json:Dockerfile:
ECRのセットアップ
- リポジトリ作成:
- プライベートリポジトリ:
simple-express-repository
- イメージのプッシュ:
IAMロールの作成
- ポリシー (
AppRunnerECRAccessRole):
- 信頼関係ポリシー:
デプロイ
- App Runnerサービスの作成:
- リポジトリタイプ: コンテナレジストリ
- プロバイダー: Amazon ECR
- コンテナイメージURI:
ECRにプッシュしたイメージ - サービスロール:
AppRunnerECRAccessRole - ポート: 3000
- デプロイ確認:
- ステータスが
Runningになったら、デフォルトドメインにアクセスして確認。
自動デプロイ確認
index.jsの文字列を変更後、再度ECRにプッシュ。
- プッシュ後、App Runnerが自動で新しいバージョンをデプロイ。
まとめ
App Runnerを使って、数分でコンテナベースアプリケーションをデプロイ。AWSのベストプラクティスが組み込まれており、開発者がアプリケーション開発に集中できる素晴らしいサービス。
一問道場
質問 #45
ある会社がオンプレミスのデータセンターで Git リポジトリをホストしています。会社は Webhook を使用して、AWS クラウドで実行される機能を呼び出しています。
会社は、Webhook のロジックを AWS クラウド上で複数の Amazon EC2 インスタンスから構成される Auto Scaling グループにホストし、その EC2 インスタンスを Application Load Balancer (ALB) のターゲットとして設定しています。Git サーバーは ALB を呼び出して Webhook を実行します。
会社はこのソリューションをサーバーレスアーキテクチャに移行したいと考えています。
どのソリューションが最も運用負荷が少なく、この要件を満たしますか？
- A. 各 Webhook 用に AWS Lambda 関数 URL を作成して設定します。Git サーバーを更新し、個別の Lambda 関数 URL を呼び出すようにします。
- B. Amazon API Gateway HTTP API を作成します。各 Webhook ロジックを別々の AWS Lambda 関数として実装します。Git サーバーを更新し、API Gateway エンドポイントを呼び出すようにします。
- C. Webhook ロジックを AWS App Runner にデプロイします。ALB を作成し、ターゲットとして App Runner を設定します。Git サーバーを更新し、ALB エンドポイントを呼び出すようにします。
- D. Webhook ロジックをコンテナ化します。Amazon Elastic Container Service (Amazon ECS) クラスターを作成し、Webhook ロジックを AWS Fargate で実行します。Amazon API Gateway REST API を作成し、Fargate をターゲットとして設定します。Git サーバーを更新し、API Gateway エンドポイントを呼び出すようにします。
解説
この問題は、サーバーレスアーキテクチャへの移行に最適なソリューションを選ぶものです。
- A: Lambda 関数 URL を使用する方法は管理が煩雑で運用負荷が増えるため、最適ではありません。
- B: API Gateway と Lambda を使用する方法は、サーバーレスアーキテクチャに適しており、運用負荷が低く、拡張性も高いため、最適な選択肢です。
- C App Runnerは確かにサーバーレスですが、ALBを使用してApp Runnerにリクエストを送る必要があり、運用の負荷が増える可能性があります。
- D: Fargate を使用する方法はコンテナ化が必要で、サーバーレスより運用が複雑になります。
最適な選択肢は B です。
もし、サーバーレスでの処理を重視する場合、API Gateway + Lambdaの組み合わせがより適しています。
046-AWS Migration Hub
理論
1. AWS移行プロセスの全体像
(1) 移行準備
AWS移行の最初のステップは、既存のインフラストラクチャを把握し、移行計画を立てることです。この段階では、以下の情報が必要になります：
- サーバーの基本情報：CPU、RAM、ディスク容量
- 実行中のプロセス、ネットワーク構成
- オペレーティングシステムとソフトウェア依存関係
(2) データ収集
AWSは、オンプレミスのサーバーデータを収集するためのツールを提供しています。主な選択肢は以下の通りです：
- AWS Application Discovery Service: エージェントベース（個別サーバーにインストール）またはエージェントレス（VMware環境向け）でデータを収集可能。詳細なサーバーメトリクスやプロセス情報を取得できます。
- AWS Migration Hub: サーバーデータの統合管理と移行進捗の可視化が可能です。
(3) データ分析と計画
収集したデータを分析し、以下の点を考慮して移行計画を作成します：
- ワークロードの依存関係
- 移行先AWSサービスの選択（EC2、ECS、RDSなど）
- 移行順序（重要なシステムを最初に移行するか、段階的に移行するか）
(4) 移行の実行
実際の移行は以下の方法で行います：
- リフト＆シフト（Lift-and-Shift）: サーバーをそのままAWS上に移行。短期間での移行が可能。
- リファクタリング（Refactoring）: アプリケーションをクラウドネイティブなアーキテクチャに最適化。時間がかかるが、長期的な効率向上が期待されます。
2. AWS Application Discovery Serviceの役割
AWS Application Discovery Serviceは、移行前のサーバーデータ収集を自動化するための主要ツールです。
主な機能
- 詳細なサーバーデータの収集:
- CPU/RAM使用率
- 実行中のプロセス
- ネットワーク構成
- オペレーティングシステムとバージョン
- データのAWS Migration Hubへの統合: 収集したデータはMigration Hubに送信され、移行計画の管理に利用されます。
エージェントベース vs エージェントレス
- エージェントベース: サーバーにインストールして詳細なデータを収集（例: プロセス情報）。
- エージェントレス: VMware環境に対応し、仮想マシンのメタデータを収集。詳細データ収集には不向き。
3. 分析とクエリのツール
AWSで収集したデータを分析するには、以下のツールが役立ちます：
(1) Amazon S3
AWS Application Discovery Serviceが収集したデータはS3に保存されます。S3はデータの安全なストレージとスケーラブルなクエリの基盤を提供します。
(2) Amazon Athena
Athenaは、S3に保存されたデータに対してSQLクエリを実行するサーバーレスのクエリサービスです。主なメリットは以下の通り：
- 事前にスキーマを定義する必要がない: ログや収集データをそのまま分析可能。
- コスト効率が高い: クエリ実行に応じて課金されるため、初期コストを抑えられます。
(3) Amazon QuickSight
QuickSightはデータの可視化ツールであり、AthenaやS3と連携してレポートやダッシュボードを作成できます。移行後のシステムパフォーマンスの監視にも利用可能です。
4. 移行のベストプラクティス
- 依存関係の明確化: アプリケーション間の依存関係を把握し、移行中のダウンタイムを最小限に抑えます。
- 段階的移行: 一度に全てを移行するのではなく、小規模なシステムから段階的に進めることでリスクを軽減します。
- 移行後のテスト: AWS上でシステムの動作確認を行い、パフォーマンスや可用性を検証します。
5. まとめ
オンプレミスサーバーのAWS移行では、収集・分析ツールの選択と正確なデータ管理が成功の鍵です。
AWS Application Discovery Agent + Migration Hub + Amazon Athena の組み合わせは、移行前のデータ収集と分析の効率化に最適です。移行プロセスを段階的に進め、AWSのツール群を活用することで、安全かつ効果的な移行を実現できます。
実践
ハンズオン: AWS Application Discovery Service を使ったオンプレミスサーバー（Amazon Linux 2023）のデータ収集と分析
このハンズオンでは、オンプレミスのサーバー（Amazon Linux 2023）からAWSにデータを収集し、Amazon Athenaを使って分析するまでの手順を、初心者向けにわかりやすく解説します。
目次
- 準備と前提条件
- アーキテクチャ概要
- ハンズオン手順
- ステップ1: エージェントのインストールと設定
- ステップ2: AWS Migration Hub の設定
- ステップ3: データ収集と確認
- ステップ4: Amazon Athena でデータ分析
- まとめと今後のステップ
1. 準備と前提条件
前提条件
以下が必要です：
- オンプレミスサーバー:
- Amazon Linux 2023 を使用
- インターネット接続可能
- AWS アカウント:
- IAM 管理者権限を持つユーザー
- セットアップ済みの AWS サービス:
- AWS Migration Hub
- Amazon S3 バケット
- Amazon Athena
2. アーキテクチャ概要
以下の手順で進めます：
- オンプレミスサーバー（Amazon Linux 2023）に AWS Application Discovery Agent をインストール。
- データを収集し、AWS Cloud に転送。
- AWS Migration Hub と Amazon S3 にデータを保存。
- Amazon Athena でデータをクエリして分析。
3. ハンズオン手順
ステップ1: エージェントのインストールと設定
- AWS Application Discovery Agent のダウンロード
- AWSコンソールの Application Discovery Service にアクセス。
- 「エージェント」セクションからインストール用スクリプトのリンクを取得。
- エージェント用IAMユーザ作成
- 専用のIAMユーザを作成し、エージェントがデータをアップロードするための権限「AWSApplicationDiscoveryAgentAccess」を付与し、AccessKey/SecretKeyを発行する。このKeyをエージェントのインストール時に使用する。
- エージェントのインストール
- Amazon Linux 2023 のターミナルにログイン。
- 以下のコマンドを実行して、エージェントをダウンロードしてインストールします：
- エージェントを起動
- AWSアカウントをリンクするため、以下を実行：
- AWS Region（例:
us-west-2）を入力し、エージェントを起動：
- エージェントのステータス確認
- 正常に動作していることを確認：
ステップ2: AWS Migration Hub の設定
- AWSコンソールで Migration Hub を開きます。
- Oregon (us-west-2) Region を選択します。
- 登録済みのエージェントを確認し、サーバーが検出されていることを確認します。
ステップ3: データ収集と確認
- 収集されるデータ
- CPU、メモリ、OS情報、稼働中のプロセスが含まれます。
- AWS Application Discovery Service がデータを自動で収集し、Amazon S3 に保存します。
ステップ4: Amazon Athena でデータ分析
- Athena テーブルの作成
- Athena コンソールに移動。
- 「クエリエディタ」で以下を実行して、S3に保存されたデータを参照するテーブルを作成します：
- データクエリの実行
- サーバーの CPU 使用率が高いものを確認するクエリ：
- クエリ結果を確認し、各サーバーのパフォーマンスデータを分析します。
4. まとめと今後のステップ
まとめ
- エージェントを使用してオンプレミスの Amazon Linux 2023 サーバーのデータを収集し、AWSに保存しました。
- Amazon Athena を使い、収集データをクエリで分析しました。
次のステップ
- Amazon QuickSight を使用してデータを可視化。
- 移行プランの設計やアプリケーションの依存関係を分析。
これでハンズオンは完了です！お疲れさまでした 😊
一問道場
質問 #46
トピック 1
ある企業が、1,000台のオンプレミスサーバーをAWSに移行する計画を立てています。このサーバー群は、企業のデータセンター内の複数のVMwareクラスター上で稼働しています。
移行計画の一環として、以下のサーバーメトリクスを収集し、それをクエリおよび分析したいと考えています：
- CPUの詳細
- RAMの使用状況
- オペレーティングシステム情報
- 実行中のプロセス
この要件を満たすソリューションはどれですか？
選択肢
A.
- オンプレミスホストに AWS Agentless Discovery Connector 仮想アプライアンス をデプロイして設定します。
- AWS Migration Hub で Data Exploration を構成します。
- AWS Glue を使用してデータに対する ETL ジョブを実行します。
- Amazon S3 Select を使用してデータをクエリします。
B.
- オンプレミスホストから VMのパフォーマンス情報のみをエクスポート します。
- 必要なデータを直接 AWS Migration Hub にインポートします。
- Migration Hub で不足している情報を更新します。
- Amazon QuickSight を使用してデータをクエリします。
C.
- オンプレミスホストからサーバー情報を自動収集する スクリプト を作成します。
- AWS CLI を使用して
put-resource-attributesコマンドを実行し、詳細なサーバーデータを AWS Migration Hub に保存します。
- Migration Hub コンソールでデータを直接クエリします。
D.
- 各オンプレミスサーバーに AWS Application Discovery Agent をデプロイします。
- AWS Migration Hub で Data Exploration を構成します。
- Amazon S3 内のデータに対して Amazon Athena を使用して事前定義されたクエリを実行します。
解説
この質問では、1,000台のオンプレミスサーバーをAWSに移行する際に、サーバーメトリクスを収集し、データを分析する要件を満たす適切なソリューションを選ぶ必要があります。それぞれの選択肢を解説します。
A. AWS Agentless Discovery Connector + AWS Glue + Amazon S3 Select
解説:
- AWS Agentless Discovery Connector はVMware環境で動作し、エージェントレスで仮想マシンのメタデータを収集します。ただし、このソリューションはサーバーごとの詳細なメトリクス（CPU/RAM使用率やプロセス情報など）は収集できません。
- AWS Glue と S3 Select を使用した分析手法は有効ですが、そもそも必要なデータが収集できないため、この選択肢は不適切です。
結論: サーバーメトリクス収集の要件を満たさない。
B. VMのパフォーマンス情報のみをエクスポート + Migration Hub + Amazon QuickSight
解説:
- オンプレミスのVMパフォーマンス情報だけをエクスポートする方法では、必要な詳細メトリクス（CPU/RAM使用率、プロセス情報など）が不足します。
- Migration Hub は移行の進捗管理に適していますが、収集したデータを分析するための機能は限定的です。
- Amazon QuickSight はビジュアル分析ツールとして優れていますが、前提となるデータの収集が不十分なため、この選択肢も不適切です。
結論: サーバーメトリクス収集の要件を満たさない。
C. カスタムスクリプト + AWS CLI + Migration Hub
解説:
- スクリプトを使用してサーバー情報を収集し、AWS CLI を用いて Migration Hub にデータを保存する方法は、実装が可能です。ただし、この手法は以下の点で不十分です。
- Migration Hub は移行資産情報の追跡ツールであり、詳細なクエリ機能がありません。
- 手動でスクリプトを作成するには多大な労力がかかり、運用上の課題が多い。
結論: 効率的ではなく、要件を満たさない。
D. AWS Application Discovery Agent + Migration Hub + Amazon Athena
解説:
- AWS Application Discovery Agent は、オンプレミスサーバーごとにインストールし、詳細なメトリクス（CPU/RAM使用率、プロセス情報、OS情報など）を収集できます。
- Migration Hub を使用してデータを統合的に管理できます。
- データは Amazon S3 に保存され、Amazon Athena を用いることで柔軟にクエリを実行し、分析が可能です。
- このソリューションは、詳細なサーバーメトリクスの収集、クエリ、分析という要件をすべて満たします。
結論: この選択肢が最適。
正解: D. AWS Application Discovery Agent + Migration Hub + Amazon Athena
理由:
- AWS Application Discovery Agent により、必要なサーバーメトリクスを詳細に収集できる。
- Migration Hub で移行プロセスを一元管理できる。
- Amazon Athena により、データに対して高度なクエリを実行可能。
このソリューションは、要件を効率的かつ包括的に満たす唯一の選択肢です。
047-VPC Lambda
理論
AWS LambdaとVPC内のインターネットアクセスに関する基本知識
AWS Lambda関数がVPC内で外部リソースにアクセスするには、特定のネットワーク構成が必要です。この構成に関連する重要な知識を以下にまとめます。
1. VPCとサブネットの基本
- VPC（Virtual Private Cloud）: AWS上で仮想的に隔離されたネットワーク環境を提供。
- サブネット:
- パブリックサブネット: インターネットゲートウェイを介して直接インターネットにアクセス可能。
- プライベートサブネット: NATゲートウェイを経由してインターネットにアクセス。
2. AWS LambdaとVPC
- Lambda関数がVPC内にデプロイされる場合、特定のサブネットとセキュリティグループに関連付けられる。
- プライベートサブネットに配置されたLambda関数が外部インターネットリソースにアクセスするには、出口トラフィック用の設定が必要。
3. NATゲートウェイの役割
- NATゲートウェイ: プライベートサブネット内のリソースがインターネットにアクセスするためのサービス。
- Elastic IP: NATゲートウェイに割り当てる固定パブリックIPアドレス。
- ルートテーブル設定:
- プライベートサブネットのルートテーブルでデフォルトルート（0.0.0.0/0）をNATゲートウェイに向ける必要がある。
4. Elastic IPの利用
- Elastic IPは固定のパブリックIPアドレスを提供し、外部リソースに対して一貫したIPアドレスを使用する場合に便利。
- 許可リスト（allow list）を使用する外部サービスとの連携に適している。
5. セキュリティの考慮
- Lambda関数が外部リソースにアクセスする際、セキュリティグループを正しく設定して通信を制限。
- NATゲートウェイを使用することで、インバウンドトラフィックを防ぎつつ、アウトバウンドトラフィックのみを許可。
6. IPv6の特別なケース
- Egress-onlyインターネットゲートウェイは、IPv6トラフィックの出口専用。
- IPv4トラフィックには使用不可。
まとめ
AWS LambdaがVPC内で外部リソースと通信するには、プライベートサブネットにNATゲートウェイを設定し、Elastic IPを使用して固定パブリックIPアドレスを提供することが必要です。これにより、外部サービスとのセキュアかつ安定した通信が可能になります。
実践
目的
- VPC 内にある Lambda 関数にインターネットアクセスを提供する。
- 完成構成では、プライベートサブネットに配置した Lambda 関数が NAT ゲートウェイを経由してインターネットに接続します。
構築手順
- VPC 作成
- サブネット作成
- プライベートサブネット:
10.0.2.0/24
- インターネットゲートウェイ作成 & アタッチ
- NAT ゲートウェイ作成
- パブリックサブネットに配置
- Elastic IP 割り当て
- ルートテーブル設定
- パブリック:
0.0.0.0/0→ インターネットゲートウェイ - プライベート:
0.0.0.0/0→ NAT ゲートウェイ
6. IAM ロールの作成
- 必要なポリシー:
- AWS 管理ポリシー
AWSLambdaVPCAccessExecutionRole
- ロール名:
- 任意の名前 (例:
lambda_vpc_basic_execution)
7. Lambda 関数の作成
- VPC に配置する際に、作成した IAM ロールを設定。
- 動作確認には、
https://checkip.amazonaws.com/を使用するコードを記述。
コードの全体像
以下のコードは、外部API（
https://checkip.amazonaws.com/）にアクセスし、レスポンスを取得するLambda関数の例です。動作確認
- 作成した Lambda 関数をテスト実行し、インターネットに接続できることを確認。
考慮点
- 冗長化: 本番環境では、高可用性を確保するため NAT ゲートウェイやサブネットの冗長化を検討。
- コスト: NAT ゲートウェイや Elastic IP はコストが発生するため、利用状況に応じた設計が必要。
この記事を基に設定を進めれば、VPC Lambda のインターネットアクセスを安全に確保できます。
一問道場
質問 #47
ある会社が、VPCに接続されたAWS Lambda関数上で実行されるサーバーレスアプリケーションを構築しています。この会社は、新しい外部プロバイダーのサービスとアプリケーションを統合する必要があります。外部プロバイダーは、許可リストに載っているパブリックIPv4アドレスからのリクエストのみをサポートしています。
アプリケーションが新しいサービスを使用できるようにするために、会社は外部プロバイダーに対して単一のパブリックIPアドレスを提供する必要があります。
どのソリューションがアプリケーションに新しいサービスへのアクセスを提供しますか？
A.
NATゲートウェイをデプロイし、Elastic IPアドレスをNATゲートウェイに関連付け、VPCをNATゲートウェイを使用するように設定します。
B.
egress-onlyインターネットゲートウェイをデプロイし、Elastic IPアドレスをそのインターネットゲートウェイに関連付け、Lambda関数のElasticネットワークインターフェイスをeferess-onlyインターネットゲートウェイを使用するように設定します。
C.
インターネットゲートウェイをデプロイし、Elastic IPアドレスをそのインターネットゲートウェイに関連付け、Lambda関数をインターネットゲートウェイを使用するように設定します。
D.
インターネットゲートウェイをデプロイし、Elastic IPアドレスをそのインターネットゲートウェイに関連付け、パブリックVPCのルートテーブルのデフォルトルートをインターネットゲートウェイを使用するように設定します。
解説
この問題では、AWS Lambda関数がVPC内でインターネットにアクセスする方法を尋ねています。外部サービスは、許可リストに登録されたパブリックIPアドレスからのリクエストのみを受け入れるため、Lambda関数が使用するIPアドレスを提供する必要があります。
- A. NATゲートウェイを使用する: 正解です。NATゲートウェイを使ってLambda関数がインターネットにアクセスし、Elastic IPを提供することで、外部サービスに必要な単一のIPアドレスを提供できます。
- B. Egress-onlyインターネットゲートウェイ: 不正解。IPv6専用で、IPv4には適用できません。
- C. インターネットゲートウェイを使用する: 不正解。Lambdaがプライベートサブネットにある場合、インターネットゲートウェイは直接使用できません。
- D. インターネットゲートウェイとVPCルートテーブルの設定: 不正解。Lambda関数がプライベートサブネットにある場合、NATゲートウェイを使用する必要があります。
結論として、A. NATゲートウェイを使用するが正しい解答です。
048-RDS Proxy
理論
Amazon Aurora
以下は、Amazon Auroraで使用できるエンドポイントの種類とその詳細を示した表です：
エンドポイントの種類 | 用途 | 説明 |
クラスターエンドポイント | 書き込み操作用（プライマリインスタンス） | Auroraクラスター内のプライマリインスタンスに接続します。すべての書き込み操作（INSERT、UPDATEなど）はこのエンドポイントを通じて行います。 |
リーダーエンドポイント | 読み取り操作用（読み取りレプリカ） | Auroraクラスター内の読み取りレプリカに接続します。主にSELECTクエリなど、読み取り操作に使用されます。複数の読み取りレプリカに負荷分散を行います。 |
カスタムエンドポイント | 特定の使用ケースに合わせたエンドポイント | ユーザーが定義した特定のインスタンスに接続するエンドポイントです。複数のインスタンスを対象にする場合や、特定の用途に合わせて設定します。 |
インスタンスエンドポイント | 特定のインスタンスへの接続 | Auroraクラスター内の個別のインスタンスに接続します。通常、単一のインスタンス（書き込みインスタンスまたは読み取りインスタンス）に接続する際に使用します。 |
このように、Auroraにはそれぞれ異なる種類のエンドポイントがあり、用途に応じて適切なエンドポイントを選択することが重要です。
+
まとめ
クラスターエンドポイント
DBクラスターの現在のプライマリインスタンスに接続する。書き込みオペレーションを実行できる唯一のエンドポイント
リーダーエンドポイント
DBクラスターへの読み込み専用接続を負荷分散する。最大15個のレプリカを作成でき、レプリカから読み込む
カスタムエンドポイント
特定のDBインスタンスのグループに接続する。グループ内のいずれかのインスタンスを選択し接続処理を行う
インスタンスエンドポイント
クラスター内の特定のDBインスタンスに接続する。
参照元：
RDS Proxyとは
RDS Proxy は、Amazon Web Services (AWS) が提供する、データベース接続を効率的に管理するためのサービスです。主に以下の目的で使用されます：
- 接続のプール管理: Lambda や EC2 インスタンスなどからデータベースへの接続をプールし、効率的に再利用します。これにより、接続数の増加やオーバーヘッドを防ぎ、アプリケーションのパフォーマンスを向上させます。
- スケーラビリティ: 高トラフィック時でもデータベース接続を適切に管理し、接続数を制限することでデータベースの負荷を軽減します。
- 高可用性: 複数の RDS インスタンスや Aurora クラスターをサポートし、接続の可用性を向上させます。
簡単に言うと、RDS Proxy はデータベースへの接続を効率的に管理し、アプリケーションのパフォーマンスと可用性を向上させるためのサービスです。
一問道場
質問 #48
ソリューションアーキテクトは、Amazon API Gateway のリージョナルエンドポイントと AWS Lambda 関数を使用するウェブアプリケーションを開発しました。ウェブアプリケーションの消費者はすべて、アプリケーションがデプロイされる AWS リージョンに近い場所にいます。Lambda 関数は、Amazon Aurora MySQL データベースをクエリするのみです。ソリューションアーキテクトは、データベースに 3 つの読み取りレプリカを設定しています。テスト中、アプリケーションはパフォーマンス要件を満たしていません。高負荷時に、アプリケーションは大量のデータベース接続を開きます。ソリューションアーキテクトは、アプリケーションのパフォーマンスを改善する必要があります。
どのアクションを取るべきですか？（2つ選んでください。）
A. Aurora データベースのクラスターエンドポイントを使用する
B. RDS Proxy を使用して、Aurora データベースのリーダーエンドポイントに接続プールを設定する
C. Lambda のプロビジョニング済み同時実行数機能を使用する
D. Lambda 関数内でデータベース接続を開くコードをイベントハンドラーの外に移動する
E. API Gateway エンドポイントをエッジ最適化エンドポイントに変更する
解説
この問題では、ウェブアプリケーションのパフォーマンス改善が求められており、アプリケーションが高負荷時に大量のデータベース接続を開いていることが問題となっています。パフォーマンス改善のために取るべきアクションを選ぶ必要があります。
各選択肢を分析します。
- A. Aurora データベースのクラスターエンドポイントを使用する
- Auroraのクラスターエンドポイントは、主にデータベースクラスター全体に対する接続を管理するために使用されます。これを使用することで、アプリケーションは読み取り専用ではなく書き込みが可能なプライマリインスタンスに接続することになりますが、パフォーマンス改善という観点では必ずしも効果的ではありません。この選択肢は問題を解決しません。
- B. RDS Proxy を使用して、Aurora データベースのリーダーエンドポイントに接続プールを設定する
- RDS Proxyは、データベース接続のプールを管理することで、Lambda関数からデータベースへの接続のオーバーヘッドを軽減し、接続の効率を向上させます。これにより、高負荷時に大量の接続が開かれる問題を解決できます。これは非常に効果的な解決策です。
- C. Lambda のプロビジョニング済み同時実行数機能を使用する
- Lambda関数のプロビジョニング済み同時実行数機能は、Lambda関数の同時実行数を事前に確保することができ、関数のスケーリングの問題を軽減します。しかし、これはデータベース接続の問題とは直接的に関係しません。接続の問題を解決するものではないため、パフォーマンスの改善には不適切です。
- D. Lambda 関数内でデータベース接続を開くコードをイベントハンドラーの外に移動する
- Lambda関数内でデータベース接続を開くコードをイベントハンドラーの外に移動することで、接続のオープン・クローズの回数を減らし、パフォーマンスを改善することができます。しかし、これは根本的な接続管理の問題を解決するものではないため、効果的な解決策としては限界があります。
- E. API Gateway エンドポイントをエッジ最適化エンドポイントに変更する
- API Gatewayのエッジ最適化エンドポイントは、消費者がAWSリージョンに近い場合に効果がありますが、これはアプリケーションのパフォーマンス向上には直接的な影響を与えません。データベース接続やLambdaのスケーリングに関する問題には関係ありません。
正解：
B. RDS Proxy を使用して、Aurora データベースのリーダーエンドポイントに接続プールを設定する
D. Lambda 関数内でデータベース接続を開くコードをイベントハンドラーの外に移動する
理由：
- Bは、データベース接続の効率を改善し、高負荷時に大量の接続を開く問題を解決します。
- Dは、データベース接続を効率的に管理するために役立ち、接続のオープン・クローズの回数を減らし、パフォーマンスを改善します。
Lambda 関数内でデータベース接続を開くコードをイベントハンドラーの外に移動する方法について、実際のコード例を説明します。
Lambda 関数内でデータベース接続を開くコードをイベントハンドラーの外に移動することで、Lambda 関数が複数回実行されても接続の再利用が可能になり、データベース接続のオーバーヘッドを減らすことができます。Lambda 関数が繰り返し呼ばれる場合、接続を再利用することが非常に重要です。
Lambda 関数でのデータベース接続を最適化する例
ここでは、Node.js の Lambda 関数を例に、データベース接続コードをどのようにイベントハンドラーの外に移動するかを示します。
1. 最適化前（接続をイベントハンドラー内で毎回開く）
このコードでは、Lambda 関数が毎回呼び出されるたびに、新しいデータベース接続を開いています。接続を開くたびにオーバーヘッドが発生し、高負荷時には問題になります。
2. 最適化後（接続をイベントハンドラーの外で再利用）
解説
- 接続を関数の外で作成:
Lambda 関数の外で
mysql.createConnectionを実行することで、Lambda が呼ばれるたびに新しい接続を開くことなく、以前の接続を再利用することができます。
- 接続の管理: Lambda 関数が最初に実行されるときに接続が開かれ、その後の実行では接続が再利用されます。Lambda のランタイムが保持する接続オブジェクトを再利用するため、接続オーバーヘッドが削減され、パフォーマンスが向上します。
- 接続を閉じない:
Lambda の
connection.end()を呼び出さないことで、関数が再実行されるたびに新しい接続を開く必要がなくなります。Lambda 関数が実行されるたびに再利用されます。
注意点
- Lambda の実行環境はリサイクルされる場合があるため、永続的に接続が生き続けるわけではありません。Lambda の環境が再利用されない場合（例えば、インスタンスがシャットダウンされた場合）、再度接続を作成する必要があります。
- 高トラフィック環境では、RDS Proxy を使用して接続プールを管理することも有効です。これにより、接続プールの管理が効率化され、接続のオーバーヘッドがさらに削減されます。
このように、接続をLambda関数の外に移動することで、データベース接続の再利用が可能となり、パフォーマンスが向上します。
049-443 443
理論
1. SSL/TLS証明書と通信の暗号化
- *SSL（Secure Sockets Layer）とTLS（Transport Layer Security）**は、インターネット上でデータを安全に転送するためのプロトコルです。SSLはTLSの前身であり、現在はほとんどのシステムでTLSが使用されています。
- クライアントとサーバー間の通信を暗号化するためには、SSL/TLS証明書が必要です。これにより、通信が盗聴や改竄から保護されます。
- *AWS証明書マネージャー（ACM）**は、AWS上でSSL/TLS証明書を簡単に管理できるサービスです。これを使用すると、証明書の発行や更新を自動化できます。
2. AWSのロードバランサー
- *Application Load Balancer（ALB）**は、HTTP/HTTPSトラフィックをターゲットインスタンスに転送する際に使用されるロードバランサーです。ALBはレイヤー7（アプリケーション層）で動作し、URLパスやホストヘッダーに基づいてトラフィックをルーティングすることができます。
- *Network Load Balancer（NLB）**は、TCPトラフィックを高速で処理するために使用されるロードバランサーで、レイヤー4（トランスポート層）で動作します。NLBは、高速な通信が求められるケースや、静的IPアドレスを必要とするシナリオに適しています。
3. エンドツーエンド暗号化
- エンドツーエンド暗号化は、データが送信元から受信先に到達するまでの全経路で暗号化されることを意味します。これにより、途中でデータが傍受されても解読できません。
- クライアントからウェブサーバーまでの通信を暗号化するために、SSL/TLS証明書をALBに設定して、ALBがクライアントとの接続を暗号化し、その後の通信をEC2インスタンスに暗号化された状態で転送することが一般的です。
4. SSL/TLS証明書の配置場所
- ALBにSSL証明書を設定する場合、ALBがクライアントとの暗号化通信を担当し、その後の通信（ALBとEC2インスタンス間）はオプションで暗号化するか、平文で転送することも可能です。
- EC2インスタンスにSSL証明書を設定する場合、ALBがSSLの終端処理を行わず、インスタンス間でもSSL通信を行う必要があります。これを「エンドツーエンド暗号化」と呼びます。
5. CloudFrontとターゲットグループ
- Amazon CloudFrontは、AWSのCDN（コンテンツ配信ネットワーク）サービスで、グローバルなキャッシュを使用してウェブコンテンツを高速に配信します。CloudFrontを使ってSSL証明書を設定し、オリジンサーバー（ターゲットグループ）との接続を暗号化することができます。
- ターゲットグループは、ロードバランサーの背後に配置されるリソースの集合で、ALBやNLBがどのインスタンスにトラフィックを転送するかを決定します。
これらの知識を理解することで、AWS環境でのセキュアなアプリケーションホスティングやトラフィックのロードバランシングに関する適切な選択ができるようになります。
一問道場
質問 #49
ある企業がAWSでウェブアプリケーションをホストし、トラフィックを複数のAmazon EC2インスタンスにロードバランスすることを計画しています。セキュリティ要件の1つは、クライアントとウェブサーバー間での通信のエンドツーエンド暗号化を有効にすることです。
どのソリューションがこの要件を満たしますか？
- A.
EC2インスタンスをアプリケーションロードバランサー（ALB）の背後に配置します。
AWS証明書マネージャー（ACM）を使用してSSL証明書をプロビジョニングし、その証明書をALBに関連付けます。
SSL証明書をエクスポートして各EC2インスタンスにインストールします。
ALBをポート443でリッスンし、インスタンスのポート443にトラフィックを転送するように構成します。
- B.
EC2インスタンスをターゲットグループに関連付けます。
AWS証明書マネージャー（ACM）を使用してSSL証明書をプロビジョニングします。
Amazon CloudFrontディストリビューションを作成し、SSL証明書を使用するように設定します。
CloudFrontをターゲットグループをオリジンサーバーとして使用するように設定します。
- C.
EC2インスタンスをアプリケーションロードバランサー（ALB）の背後に配置します。
AWS証明書マネージャー（ACM）を使用してSSL証明書をプロビジョニングし、その証明書をALBに関連付けます。
サードパーティ製のSSL証明書をプロビジョニングし、それを各EC2インスタンスにインストールします。
ALBをポート443でリッスンし、インスタンスのポート443にトラフィックを転送するように構成します。
- D.
EC2インスタンスをネットワークロードバランサー（NLB）の背後に配置します。
サードパーティ製のSSL証明書をプロビジョニングし、それをNLBおよび各EC2インスタンスにインストールします。
NLBをポート443でリッスンし、インスタンスのポート443にトラフィックを転送するように構成します。
解説
この質問は、「クライアントからEC2インスタンスまでの通信をエンドツーエンドで暗号化するために、どのソリューションが適切か」を問うています。選択肢を詳しく検討し、正しい解答を導きます。
要件のポイント
- エンドツーエンド暗号化: クライアントからロードバランサー（ALBまたはNLB）を経由し、EC2インスタンスに至るまで通信が暗号化される必要があります。
- HTTPS通信: クライアントからロードバランサー、およびロードバランサーからEC2インスタンス間でHTTPS通信を確立。
- SSL証明書の適切な配置: 通信の暗号化を担保するため、ロードバランサーとEC2インスタンスの両方にSSL証明書が必要です。
選択肢の分析
A.
- 構成:
- ALBでAWS証明書マネージャー（ACM）の証明書を使用し、ALBとクライアント間を暗号化。
- ACM証明書をエクスポートしてEC2インスタンスにインストールし、ALBとEC2間も暗号化。
- ALBがポート443でリッスンし、EC2インスタンスのポート443にトラフィックを転送。
- 評価:
ACM証明書を直接エクスポートしてEC2インスタンスにインストールすることはできません。そのため、この構成は実現不可能です。
- 結論: 不正解。
B.
- 構成:
- CloudFrontでACM証明書を使用し、クライアントとCloudFront間を暗号化。
- CloudFrontからターゲットグループ（EC2インスタンス）への通信をHTTPSで行う。
- 評価:
CloudFrontは一般的にキャッシュ分散のために使用され、ロードバランサーとしての機能を補うものではありません。また、CloudFrontとEC2インスタンス間の暗号化要件を満たすための設定が曖昧です。
- 結論: 不正解。
C.
- 構成:
- ALBでACM証明書を使用し、クライアントとALB間を暗号化。
- サードパーティ製のSSL証明書を使用してEC2インスタンスにインストールし、ALBとEC2間も暗号化。
- ALBがポート443でリッスンし、インスタンスのポート443にトラフィックを転送。
- 評価:
サードパーティ製SSL証明書をEC2インスタンスにインストールすることで、ALBとEC2インスタンス間の通信も暗号化され、要件を完全に満たします。
- 結論: 正解。
D.
- 構成:
- NLBを使用し、サードパーティ製のSSL証明書をNLBとEC2インスタンスの両方にインストール。
- NLBがポート443でリッスンし、インスタンスのポート443に転送。
- 評価:
NLBは通常、レイヤー4（TCP/UDP）での動作を目的としており、HTTPSのプロトコルレベルの処理は行いません。そのため、NLBを用いてエンドツーエンド暗号化を設定するのは非効率的です。
- 結論: 不正解。
解答: C
エンドツーエンドの暗号化を実現するには、ロードバランサーとEC2インスタンスの両方にSSL証明書を配置し、ALBとサードパーティ製証明書の組み合わせが最も適切です。
050-Aurora Replica
理論
AWS移行
- データベース移行の基本的なステップ
- 移行計画の立案: 現状のデータベースの構成、利用状況、依存関係を分析し、移行後のアーキテクチャを設計します。
- ツール選定: AWS Database Migration Service（DMS）やSnowballなど、移行要件に合ったツールを選択します。
- レプリケーション: オンプレミス環境とクラウド環境でデータをリアルタイムで同期し、移行中のダウンタイムを最小限に抑えます。
- Aurora MySQLの特徴
- スケーラビリティ: Auroraは高性能で自動スケーリングが可能。レプリカを作成することで、読み取り負荷を分散できます。
- マルチAZ構成: 高可用性を実現し、障害が発生しても迅速に復旧します。
- RDS Proxyの活用: アプリケーションの接続管理を最適化し、大量の接続を効率的に処理できます。
- データロードと集計ジョブの負荷分散
- 負荷分散の原則: 書き込みと読み取りを分けることで、リソース競合を回避します。
- レプリカの利用: 書き込みはプライマリインスタンスに集中させ、集計や分析処理はリードレプリカで行います。
- 継続的データレプリケーション
- AWS DMSの利点: 既存データのフルロードと、変更データキャプチャ（CDC）によるリアルタイム同期が可能。
- 移行後の切り替え: レプリケーションが完了したら、DNSの変更やアプリケーション設定の更新で、新しい環境に移行します。
- 移行中断を防ぐ設計
- Blue/Greenデプロイメント: 新旧システムを並行稼働させ、テスト後に切り替える手法。
- ロードバランサー: Application Load Balancer（ALB）やNetwork Load Balancer（NLB）を使用してトラフィックを分散。
- ステージング環境: 本番環境に影響を与えないよう、移行作業はまずステージング環境で検証します。
- クラウドネイティブ設計の考慮
- サーバーレス: AWS Lambdaを活用し、動的スケーリングとコスト効率を向上。
- イベント駆動アーキテクチャ: KinesisやSQSでデータ収集や処理を非同期化。
これらの知識は、AWS移行プロジェクトにおいて効率的かつ中断を防ぐ設計を実現するための基本となります。
一問道場
質問 #50
トピック 1
ある企業がデータ分析環境をオンプレミスからAWSへ移行しようとしています。この環境には次の2つのNode.jsアプリケーションがあります：
- センサーデータ収集アプリケーション
- センサーデータを収集し、MySQLデータベースにデータをロードする。
- データ集計アプリケーション
- データを集計してレポートを作成する。
ただし、集計ジョブが実行される際に、一部のデータロードジョブが失敗する問題が発生しています。
要件
- データロードの問題を解決する。
- 移行作業は顧客に影響を与えず中断を発生させない。
ソリューションアーキテクトとして、この要件を満たすにはどの選択肢を採用すべきですか？
選択肢
A.
- Amazon Aurora MySQLデータベースをオンプレミスのデータベースのレプリケーションターゲットとして設定する。
- Aurora Replicaを作成し、集計ジョブをAurora Replicaで実行するように移行する。
- 収集エンドポイントをNetwork Load Balancer（NLB）の背後にあるAWS Lambda関数として設定し、Amazon RDS Proxyを使用してAurora MySQLデータベースに書き込む。
- データベースが同期されたら、レプリケーションジョブを無効化し、Aurora Replicaをプライマリインスタンスとして再起動する。
- コレクタのDNSレコードをNLBに向ける。
B.
- Amazon Aurora MySQLデータベースを設定する。
- AWS Database Migration Service（AWS DMS）を使用して、オンプレミスデータベースからAuroraへの継続的なデータレプリケーションを実行する。
- 集計ジョブをAurora MySQLデータベースで実行するように移行する。
- 収集エンドポイントをApplication Load Balancer（ALB）の背後にあるAuto Scalingグループ内のAmazon EC2インスタンスとして設定する。
- データベースが同期されたら、コレクタのDNSレコードをALBに向ける。
- オンプレミスからAWSへの移行後、AWS DMSの同期タスクを無効化する。
C.
- Amazon Aurora MySQLデータベースを設定する。
- AWS Database Migration Service（AWS DMS）を使用して、オンプレミスデータベースからAuroraへの継続的なデータレプリケーションを実行する。
- Aurora Replicaを作成し、集計ジョブをAurora Replicaで実行するように移行する。
- 収集エンドポイントをApplication Load Balancer（ALB）の背後にあるAWS Lambda関数として設定し、Amazon RDS Proxyを使用してAurora MySQLデータベースに書き込む。
- データベースが同期されたら、コレクタのDNSレコードをALBに向ける。
- オンプレミスからAWSへの移行後、AWS DMSの同期タスクを無効化する。
D.
- Amazon Aurora MySQLデータベースを設定する。
- Aurora Replicaを作成し、集計ジョブをAurora Replicaで実行するように移行する。
- 収集エンドポイントをAmazon Kinesisデータストリームとして設定する。
- Amazon Kinesis Data Firehoseを使用してデータをAurora MySQLデータベースにレプリケートする。
- データベースが同期されたら、レプリケーションジョブを無効化し、Aurora Replicaをプライマリインスタンスとして再起動する。
- コレクタのDNSレコードをKinesisデータストリームに向ける。
解説
正解: C
理由:
- 要件1: データロードの問題を解決
- 集計ジョブの実行によりデータロードが失敗する問題は、読み取りと書き込みの負荷分散が必要です。選択肢Cでは、Aurora Replicaを使用し、集計ジョブをAurora Replicaで実行することで、プライマリデータベースへの書き込み負荷を軽減します。
- 要件2: 中断を発生させない移行
- AWS DMSを使用した継続的なデータレプリケーションにより、オンプレミスデータベースからAurora MySQLへの移行がリアルタイムで進行し、顧客への影響を最小限に抑えます。
- 収集エンドポイントをALBの背後にあるLambda関数に設定し、Amazon RDS Proxyを活用することで、スケーラビリティと接続管理が最適化され、サービスの中断を防ぎます。
- 選択肢A, B, Dとの比較
- A: NLBとLambdaの組み合わせや手動でのAurora Replicaの昇格が複雑で、移行中断リスクが高い。
- B: Aurora Replicaを使用せず、負荷分散が考慮されていない。集計ジョブの影響でデータロードが失敗する問題が解決できない。
- D: Kinesisを用いたソリューションは、データ収集ワークロードには適しているが、MySQLデータベースとの統合が複雑で要件の範囲を超える。
したがって、選択肢Cが要件を最も適切に満たします。
- 作者:みなみ
- 链接:https://www.minami.ac.cn//%E8%B3%87%E6%A0%BC%E5%8B%89%E5%BC%B7/166d7ae8-88e2-801e-a828-d3e053c49fed
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
