type
status
date
slug
summary
tags
category
icon
password
书籍
071-S3 Transfer Acceleration
理論
S3 Transfer Acceleration
S3 Transfer Acceleration（S3転送加速）は、AWSのS3バケットへのデータ転送を高速化するサービスです。AWSのエッジロケーションとネットワークプロトコルを最適化することで、特に海外リージョンなどから遠く離れたS3へのデータ転送を高速に行うことができます。
S3のフォルダ構造とプレフィックス
一問道場
問題 #71
ある動画ストリーミング会社は、最近動画共有用のモバイルアプリを公開しました。このアプリは、さまざまなファイルを us-east-1 リージョン の Amazon S3 バケット にアップロードします。ファイルのサイズは 1 GB から 10 GB までさまざまです。
オーストラリアからアプリにアクセスしているユーザーは、アップロードに時間がかかることを経験しており、時にはファイルのアップロードが完了しないこともあります。
ソリューションアーキテクトは、これらのアップロードのパフォーマンスを改善する必要があります。
どのソリューションがこの要件を満たしますか？（2つ選んでください）
- A. S3 バケットで S3 Transfer Acceleration を有効にし、アプリがアップロードに Transfer Acceleration エンドポイント を使用するように構成する。
- B. 各リージョンに S3 バケット を構成し、S3 クロスリージョンレプリケーション を使用してファイルを配信用 S3 バケットにコピーする。
- C. Amazon Route 53 で レイテンシベースのルーティング を設定し、アップロードを最寄りの S3 バケットリージョンにルーティングする。
- D. アプリを構成して、動画ファイルをチャンクに分割し、マルチパートアップロード を使用してファイルを Amazon S3 に転送する。
- E. アプリを修正して、アップロード前にファイルに ランダムなプレフィックス を追加する。
解説
この問題の正解は A と D です。
解説:
- A. S3 Transfer Acceleration を有効にする
S3 Transfer Acceleration は、グローバルに分散したエッジロケーションを利用して、ユーザーがどこからでも高速に S3 バケットにデータをアップロードできるようにする機能です。オーストラリアからのアップロード速度が遅い場合、Transfer Acceleration を使用するとパフォーマンスが向上する可能性があります。
- D. マルチパートアップロードを使用する
大きなファイル（1GB〜10GB）をアップロードする際に マルチパートアップロード を使用することで、ファイルを複数の小さな部分に分けて並列でアップロードすることができ、ネットワークの問題があった場合にも再送信できるため、失敗しにくくなります。また、アップロードのパフォーマンス向上にも寄与します。
他の選択肢の理由:
- B. S3 クロスリージョンレプリケーションを使用する
これはファイルを異なるリージョンの S3 バケットにレプリケートする方法ですが、アップロード自体の速度改善には直接関係しません。クロスリージョンレプリケーションは、データのバックアップや地理的分散には有効ですが、アップロードのパフォーマンス向上には役立ちません。
- C. Amazon Route 53 のレイテンシベースのルーティング
S3 は、最寄りのリージョンを使用して自動的にアップロードを処理するため、Route 53 のレイテンシベースのルーティングを設定することは、アップロードパフォーマンスを改善する直接的な方法ではありません。
- E. ランダムなプレフィックスを使用する
プレフィックスをランダムにすることは、S3 のパフォーマンス改善に役立つ場合がありますが、これはアップロード速度にはあまり影響しません。主に S3 のパフォーマンスチューニングに関するベストプラクティスですが、ここでの主な問題である「アップロードの遅さ」には直接関連しません。
したがって、A と D が最適な解決策です。
072-RDSプロキシ
理論
RDSプロキシとは
RDSプロキシ
RDSが保持する情報
情報の種類 | 説明 |
接続プール | RDSプロキシはデータベース接続のプールを管理し、接続の再利用を行います。これにより、接続のオーバーヘッドを削減します。 |
接続の状態 | データベースインスタンスの接続状態を監視し、フェイルオーバーが発生した場合でも接続を切り替えます。 |
データベースエンドポイント情報 | アプリケーションに提供するデータベースインスタンスまたはクラスタのエンドポイント情報を保持します。フェイルオーバー後でも新しいエンドポイントを提供します。 |
認証情報 | アプリケーションが接続するための認証情報（ユーザー名、パスワード）を保持し、自動的に提供します。 |
フェイルオーバーテスト後に、再確立できなかった理由
主要な理由:
- 静的な接続エンドポイントの使用:
- RDSのエンドポイントは通常、データベースインスタンスがフェイルオーバー時に変更されませんが、フェイルオーバー後に新しいプライマリインスタンスに接続するためには、新しいIPアドレスを使用する必要があります。アプリケーションが古いエンドポイント（フェイルオーバー前のもの）を参照し続けていた場合、接続が失われます。
- 接続の再試行:
- フェイルオーバー後、アプリケーションは接続の再試行を行わない場合があり、これにより接続が自動的に再確立されないことがあります。通常、接続プールの構成が不足しているか、接続再試行の設定が適切でない場合があります。
- 接続プールとタイムアウト設定の問題:
- アプリケーションがデータベースへの接続プールを使用している場合、フェイルオーバー後の新しいインスタンスへの切り替えが適切に行われないことがあります。また、接続タイムアウト設定が短すぎる場合、再接続の試行が早期に終了してしまい、接続が確立できないことがあります。
解決策:
- RDSプロキシの導入:
- RDSプロキシは、フェイルオーバー後でも接続を維持し、アプリケーションが新しいインスタンスに接続するために必要な設定を隠蔽します。これにより、接続が途切れることなく、フェイルオーバー後も自動的に接続が再確立されるようになります。
- アプリケーションの接続設定の改善:
- アプリケーションが接続の再試行や接続プールを適切に設定し、フェイルオーバー後に新しいインスタンスへ自動的に切り替えられるようにする必要があります。特に、アプリケーションで動的に接続先を変更する機能を追加することが推奨されます。
このように、フェイルオーバー後に接続を再確立できなかった原因は、主に接続先のエンドポイントや再試行のロジックに関する設定ミスに起因しています。
一問道場
質問 #72
アプリケーションは、us-east-1リージョンでAmazon RDS for MySQLのマルチAZ DBインスタンスを使用しています。フェイルオーバーテスト後、アプリケーションはデータベースへの接続を失い、接続を再確立できませんでした。アプリケーションを再起動した後、接続が再確立されました。
ソリューションアーキテクトは、アプリケーションが再起動せずにデータベースへの接続を再確立できるようにするソリューションを実装する必要があります。
どのソリューションがこの要件を満たすでしょうか？
- A.
Amazon Aurora MySQL Serverless v1 DBインスタンスを作成し、RDS DBインスタンスをAurora Serverless v1 DBインスタンスに移行します。アプリケーションの接続設定をAuroraリーダーエンドポイントを指すように更新します。
- B.
RDSプロキシを作成し、既存のRDSエンドポイントをターゲットとして設定します。アプリケーションの接続設定をRDSプロキシエンドポイントを指すように更新します。
- C.
2ノードのAmazon Aurora MySQL DBクラスターを作成し、RDS DBインスタンスをAurora DBクラスターに移行します。RDSプロキシを作成し、既存のRDSエンドポイントをターゲットとして設定します。アプリケーションの接続設定をRDSプロキシエンドポイントを指すように更新します。
- D.
Amazon S3バケットを作成し、AWS Database Migration Service (AWS DMS)を使用してデータベースをAmazon S3にエクスポートします。Amazon Athenaを使用してS3バケットをデータストアとして設定します。アプリケーションに最新のOpen Database Connectivity (ODBC)ドライバーをインストールし、アプリケーションの接続設定をAthenaエンドポイントを指すように更新します。
解説
この質問では、RDSフェイルオーバー時にアプリケーションが再起動せずにデータベース接続を再確立できるようにするための最適なソリューションを選ぶ必要があります。
問題点の詳細
- フェイルオーバーが発生すると、RDSはスタンバイインスタンスをプライマリインスタンスとして昇格します。
- RDSのエンドポイントはフェイルオーバー後も同じですが、アプリケーションが接続を維持し続けることができない場合があります。理由としては、データベースドライバーや接続の再試行の欠如などが考えられます。
- アプリケーションを再起動せずに接続を再確立できるようにする必要があります。
選択肢の分析
A.
- 内容:
- RDS DBインスタンスをAurora Serverless v1 DBインスタンスに移行。
- アプリケーションの接続設定をAuroraリーダーエンドポイントに更新。
- 評価:
- 利点:
- Aurora Serverlessはスケーラブルであり、リーダーエンドポイントを使用すると複数のリーダーインスタンス間での接続が可能。
- 欠点:
- フェイルオーバー問題の解決とは直接関係がない。
- Aurora Serverless v1は高可用性の課題があり、AuroraマルチAZやプロキシほど適していない。
- 結論: 不適切（フェイルオーバー時の接続問題を解決できない）。
B.
- 内容:
- RDSプロキシを作成し、既存のRDSエンドポイントをターゲットとして設定。
- アプリケーションの接続設定をRDSプロキシエンドポイントに変更。
- 評価:
- 利点:
- RDSプロキシは、接続プールを管理し、フェイルオーバー時に接続を維持するための再試行を自動で行う。
- アプリケーションコードや設定に大きな変更を加える必要がない。
- 欠点:
- RDSプロキシを使用するための追加コストが発生する。
- 結論: 適切（フェイルオーバー時に接続を維持可能）。
C.
- 内容:
- 2ノードのAurora MySQL DBクラスターを作成し、RDSインスタンスをAuroraに移行。
- RDSプロキシを設定してアプリケーションの接続をプロキシ経由に変更。
- 評価:
- 利点:
- Auroraは高可用性を提供し、クラスター内でのフェイルオーバーは非常に迅速。
- RDSプロキシが接続の再試行を管理。
- 欠点:
- Auroraへの移行は大規模な変更を伴い、移行中のダウンタイムが発生する可能性がある。
- 現在の要件でAurora移行が必須ではない。
- 結論: 過剰（Aurora移行が不要であるため、コスト・時間が増加）。
D.
- 内容:
- Amazon S3にデータベースをエクスポート。
- Amazon Athenaを使用してデータにアクセス。
- 評価:
- 利点:
- データ分析用途には適している。
- 欠点:
- S3とAthenaはRDSの代替にならない。
- アプリケーションがリアルタイムでデータベースと連携する構成には不適切。
- 結論: 不適切（設問の要件を満たしていない）。
正解: B
RDSプロキシを使用することで、接続プールの管理とフェイルオーバー時の接続再試行を自動化できます。これにより、アプリケーションは再起動せずにデータベース接続を維持でき、ダウンタイムが最小化されます。
補足
- RDSプロキシは、高スループット環境やフェイルオーバーが頻繁に発生するケースに最適なソリューションです。
- RDSプロキシを利用するには、プロキシを作成し、ターゲットグループに既存のRDSインスタンスを追加した後、アプリケーションを新しいプロキシエンドポイントに接続する必要があります。
073-AWS IoT Core
理論
MQTプロトコル (Message Queuing Telemetry Transport)
- 概要: MQTTは、軽量でオープンなメッセージングプロトコルで、特にリソースが限られたデバイスやネットワーク環境でも効率よく動作します。
- 使用ケース: IoTデバイス間のリアルタイム通信に使用されることが多く、デバイスがメッセージをパブリッシュし、他のデバイスがそれをサブスクライブします。
- 特徴:
- 小さな帯域幅で効率的に動作。
- 必要な帯域幅が少ないため、ネットワーク負荷を減少。
- QoS (Quality of Service) レベルに応じて、信頼性のあるメッセージ配信が可能。
X.509証明書
- 概要: X.509証明書は、公開鍵インフラストラクチャ（PKI）で使用される証明書の標準です。特にセキュリティ通信で使われます。
- 用途: デバイスやサーバーの認証やデータ暗号化に使用される。
- 特徴:
- 鍵ペア（公開鍵と秘密鍵）を使用して、通信を暗号化したり、デバイスを認証したりする。
- ユーザーやデバイスのIDを証明書によって確認し、安全な通信を実現。
Amazon MQ
- 概要: Amazon MQは、AWSが提供するフルマネージドのメッセージブローカーサービスです。メッセージングアプリケーションやデバイス間での通信を簡素化するために使用されます。
- 対応プロトコル: 主要なメッセージングプロトコル（AMQP、MQTT、OpenWire、JMS）に対応しており、既存のアプリケーションとの統合が容易です。
- 用途:
- アプリケーション間での非同期メッセージ通信を行う場合。
- スケーラブルで高可用性のメッセージングソリューションを必要とする場合。
- 特徴:
- フルマネージド: インフラストラクチャ管理が不要で、スケーリング、パッチ適用、バックアップなどの管理はAWSが行います。
- 可用性: 高可用性を提供するために複数のアベイラビリティゾーン（AZ）で実行される。
- 互換性: 既存のメッセージブローカー（Apache ActiveMQやRabbitMQ）を使用している場合、これらと互換性があるため、移行が簡単。
使用例:
- IoTデバイスからのデータ送信と受信の中継。
- サービス間の非同期メッセージング。
- スケーラブルな通知システムやイベント処理システムの構築。
- 既存でMQを使用していてAWSにそのまま乗せたい → Amazon MQ 新規でサービスを立ち上げる → Amazon SQS
AWS IoT Thing
- 概要: AWS IoT Thingは、AWS IoT Core内で管理される物理的なデバイスや仮想的なエンティティのことを指します。IoT Thingは、デバイスの識別、設定、管理、セキュリティの面で重要な役割を果たします。
- 役割:
- 各デバイス（センサー、アクチュエーター、ゲートウェイなど）をAWS IoT Coreと連携させるための基本的な単位として機能します。
- デバイスのメタデータや設定、証明書、状態などを管理するために使用されます。
- 主な機能:
- デバイス識別: IoT Thingを使って、各デバイスを一意に識別し、管理できます。
- セキュリティ: 各Thingには、セキュアな接続のための証明書（X.509証明書）が関連付けられており、安全にデバイスを接続できます。
- 管理: デバイスに関連するメタデータ（名前、タイプ、状態、プロパティなど）を管理でき、デバイスの設定を効率的に更新できます。
- デバイスデータ: Thingが送受信するデータ（例えば、センサーデータ）をAWS IoT Coreで処理、分析するために使用します。
- 使用例:
- スマートホームデバイスの管理
- IoTセンサーによるデータ収集
- 機械の稼働状態を監視するためのデバイスの設定と状態の管理
- AWS IoT Thingの構成要素:
- Thingタイプ: 同じ種類のデバイスをまとめるためのテンプレート（例：温度センサー、スマートライトなど）。
- 証明書: 各デバイスに固有のX.509証明書を関連付けて、安全な通信を実現。
- ポリシー: デバイスが実行できる操作（データの送信、受信、管理）を制限するためのアクセス権限を設定。
まとめ:
AWS IoT Thingは、IoTデバイスのデジタル表現であり、これを管理することで、デバイスとAWS IoT Coreの間で安全かつスケーラブルな接続を提供します。
一問道場
質問 #73
ある企業がAWSクラウドでソリューションを構築しています。数千台のデバイスがこのソリューションに接続し、データを送信します。各デバイスは、リアルタイムでデータを送受信するためにMOTTプロトコルを使用する必要があります。各デバイスは、ユニークなX.509証明書を使用して認証する必要があります。
最も運用上の負担が少ない方法はどれですか？
選択肢：
A:
- AWS IoT Coreを設定し、各デバイスに対応するAmazon MQキューを作成し、証明書を発行します。
- 各デバイスをAmazon MQに接続します。
B:
- ネットワークロードバランサー(NLB)を作成し、AWS Lambda認証機能を設定します。
- Amazon EC2インスタンスにAuto Scalingグループを設定し、そこにMQTTブローカーを実行します。
- Auto ScalingグループをNLBのターゲットとして設定します。
- 各デバイスをNLBに接続します。
C:
- AWS IoT Coreを設定し、各デバイスに対応するAWS IoT Thingを作成し、証明書を発行します。
- 各デバイスをAWS IoT Coreに接続します。
D:
- Amazon API Gateway HTTP APIとネットワークロードバランサー(NLB)を設定します。
- API GatewayとNLBの統合を作成します。
- HTTP APIに相互TLS証明書認証機能を設定します。
- MQTTブローカーをAmazon EC2インスタンスで実行し、NLBターゲットとして設定します。
- 各デバイスをNLBに接続します。
解説
問題の解説
要件:
- 多数のデバイスがリアルタイムでデータを送受信する。
- 各デバイスは、ユニークなX.509証明書で認証される。
- 最小限の運用負荷で解決する必要がある。
選択肢の分析:
- A (AWS IoT Core + Amazon MQ):
- 問題: Amazon MQはメッセージブローカーサービスであり、MQTTに特化していないため、運用が複雑になりがち。
- 不適切: IoTデバイスの接続にはIoT Coreを使う方が適している。
- B (NLB + Lambda Authorizer + EC2でMQTT Broker):
- 問題: NLB + EC2の組み合わせは手動でスケーリングを管理する必要があり、運用負荷が増える。EC2インスタンスの管理が必要。
- 不適切: 管理が煩雑で、スケーリングや負荷分散に手動対応が必要。
- C (AWS IoT Core + IoT Thing):
- 正解: AWS IoT Coreは、デバイス認証（X.509証明書）とリアルタイム通信（MQTT）をサポート。IoT Thingでデバイスを管理し、低運用負荷で拡張可能。
- 適切: AWS IoT Coreが直接的な解決策を提供し、運用負荷が低い。
- D (API Gateway + NLB + EC2 MQTT Broker):
- 問題: API GatewayとNLBを組み合わせてMQTTブローカーをEC2で運用するのは、複雑で運用負荷が大きくなる。
- 不適切: IoTデバイス管理の目的にはIoT Coreを使用する方が効率的。
結論:
- 最小の運用負荷で要件を満たすには、C (AWS IoT Core + IoT Thing) が最適な選択肢です。
074-AWS CloudFormation権限
理論
AWS CloudFormation権限
AWS CloudFormationのデフォルトでは、実行者権限でリソースを作成。安全ではない？
CloudFormationのサービスロールに関する要点は以下の通りです：
- サービスロールの目的:
- 実行者の権限を分離：CloudFormationスタックの作成時に、実行者のIAMユーザー権限ではなく、指定されたサービスロールの権限で操作を行う。これにより、スタック作成に必要な権限を特定のロールに委譲する。
- 問題点：
- IAM権限の管理の煩雑さ：開発環境で複数のユーザーがスタックを管理する場合、各ユーザーに適切なIAMポリシーを割り当てる必要があり、これが不統一になると権限エラーや管理の乱れが発生する。
- 過剰権限の付与：開発者にスタック作成に必要な権限を付与すると、CloudFormationを通じてのみリソース操作を制限したい場合でも、コンソールやCLIを通じてリソースの変更・削除が可能になり、意図しない操作が行われるリスクがある。
- 解決策：
- サービスロールを使用：スタック作成時に専用のIAMサービスロールを指定し、リソース作成や変更をそのロールに委譲することで、実行者の権限を限定し、過剰な権限を与えないようにする。
- 本番環境での重要性：
- 権限の制限：特に本番環境では、CloudFormationを通じてのみリソースを操作できるようにし、他の手段（コンソールやCLIなど）で不適切に操作されないようにすることが重要。
一問道場
問題 #74
ある企業が単一のAWSアカウントでいくつかのワークロードを実行しています。新しい企業ポリシーにより、エンジニアは承認されたリソースのみをプロビジョニングでき、またエンジニアはAWS CloudFormationを使用してこれらのリソースをプロビジョニングする必要があります。ソリューションアーキテクトは、この新しい制限をエンジニアが使用するIAMロールに強制するソリューションを作成する必要があります。
ソリューションアーキテクトは、どのようにこの制限を強制すべきですか？
選択肢：
A.
承認されたリソースを含むAWS CloudFormationテンプレートをAmazon S3バケットにアップロードする。
エンジニアのIAMロールのIAMポリシーを更新して、Amazon S3とAWS CloudFormationへのアクセスのみを許可する。
AWS CloudFormationテンプレートを使用してリソースをプロビジョニングする。
解説
IAMポリシーを使って、エンジニアがアクセスできるサービスを制限します。これにより、エンジニアはAWS CloudFormationを使用してリソースをプロビジョニングできますが、S3バケットに格納されたテンプレートに基づいてのみリソースを作成できます。
B.
エンジニアのIAMロールのIAMポリシーを更新して、承認されたリソースとAWS CloudFormationのみをプロビジョニングできるようにする。
AWS CloudFormationテンプレートを使用して、承認されたリソースでスタックを作成する。
解説
IAMポリシーの更新で、承認されたリソースのプロビジョニングのみを許可するということですが、この方法だけでは他の手段（例えば直接AWSコンソールやCLIなど）を使って承認されたリソースを作成できる可能性があります。つまり、CloudFormationを通さずに承認されたリソースを作成できてしまうため、この選択肢は要件を完全に満たしません。
C.
エンジニアのIAMロールのIAMポリシーを更新して、AWS CloudFormationのアクションのみを許可する。
承認されたリソースをプロビジョニングするための権限を持つ新しいIAMポリシーを作成し、そのポリシーを新しいIAMサービスロールに割り当てる。
AWS CloudFormationのスタック作成時にこのIAMサービスロールを割り当てる。
解説
正解
D.
AWS CloudFormationスタックでリソースをプロビジョニングする。
エンジニアのIAMロールのIAMポリシーを更新して、エンジニア自身のAWS CloudFormationスタックへのアクセスのみを許可する。
075-DynamoDB TTL
理論
高頻度データ取り込みと効率的なストレージ管理
現代のシステムでは、さまざまなデバイスやサービスから高頻度で小さなデータを収集し、それを効率的に保存・管理することが重要です。このようなシナリオにおいて考慮すべき主要なポイントを以下にまとめます。
1. データ取り込みの特徴
- スモールデータ: 各レコードが小さいサイズ（例: 数KB以下）。
- 取り込み頻度: 毎秒数万件以上のデータを継続的に受信する場合が多い。
- 短期間保存: 一定期間（例: 120日）を過ぎたデータは削除可能なケースが一般的。
2. ストレージソリューションの要件
- スケーラビリティ: データ量が急増しても対応可能なインフラ。
- 耐久性と可用性: データを安全に保存し、必要に応じてすぐにアクセス可能。
- 低レイテンシー: 高速なデータ取り出しを実現。
- コスト効率: 必要な機能を最小限のコストで提供する仕組み。
3. データ削除とライフサイクル管理
- 自動削除機能: データの保存期限を設定し、手動操作を不要にする仕組み。
- 例: TTL（Time to Live）機能やライフサイクルポリシー。
- 運用の効率化: 管理負荷を減らし、不要なデータがストレージを占有するのを防ぐ。
4. 代表的なソリューション
- Amazon S3:
- バッチ処理されたデータや大容量データの長期保存に最適。
- ライフサイクルポリシーで古いデータを自動削除。
- Amazon DynamoDB:
- 高頻度かつ小規模なデータ取り込みに対応。
- TTL機能でデータの保存期限を管理。
- Amazon RDS:
- 構造化データを扱うリレーショナルデータベース。
- 定期的な手動クエリでデータを削除可能だが、自動化が制限的。
5. 設計のベストプラクティス
- 要件に応じたツール選択: 小規模データにはDynamoDB、大規模バッチデータにはS3が適する。
- コスト最適化: ストレージコストと読み書きコストのバランスを考慮。
- 拡張性と管理性の両立: ユーザー管理やアクセス権限も一貫性を持たせる。
このようなポイントを押さえ、最適なストレージ設計を行うことで、スムーズなデータ管理とコスト削減が可能になります。
一問道場
質問 #75
ソリューションアーキテクトが、新しいアプリケーションのデータ保存および取得アーキテクチャを設計しています。このアプリケーションは、世界中のデバイスから毎分数百万件の小さなレコードを取り込むように設計されています。各レコードのサイズは4KB未満であり、耐久性のある場所に保存され、低レイテンシーで取得できる必要があります。このデータは一時的なものであり、120日間のみ保存が必要で、その後は削除可能です。
ソリューションアーキテクトは、1年間でのストレージ要件が約10～15TBになると見積もっています。
この設計要件を満たし、最も費用対効果の高いストレージ戦略はどれですか？
選択肢
A. アプリケーションを設計し、各入力レコードを単一の.csvファイルとしてAmazon S3バケットに保存し、インデックス付きで取得できるようにします。ライフサイクルポリシーを設定して120日以上経過したデータを削除します。
B. アプリケーションを設計し、各入力レコードをAmazon DynamoDBテーブルに保存します。このテーブルはスケールに適した設定がなされています。DynamoDBのTime to Live（TTL）機能を設定して120日以上経過したレコードを削除します。
C. アプリケーションを設計し、各入力レコードをAmazon RDS MySQLデータベースの単一のテーブルに保存します。ナイトリーのcronジョブを実行し、120日以上経過したレコードを削除するクエリを実行します。
D. アプリケーションを設計し、入力レコードをバッチ処理してからAmazon S3バケットに書き込みます。オブジェクトのメタデータを更新して、バッチ内のレコードのリストを含めます。Amazon S3のメタデータ検索機能を使用してデータを取得します。ライフサイクルポリシーを設定して120日後にデータを削除します。
解説
設計要件のポイント
- データ特性
- データは1レコードあたり4KB未満と非常に小さい。
- データは「120日間のみ」保存が必要であり、その後は削除可能。
- 年間で10～15TB程度の容量が見込まれる。
- 低レイテンシーでのデータアクセスが求められる。
- 最適なストレージ戦略の条件
- 高スループット: デバイスからのデータを効率的に処理できること。
- 耐久性と低レイテンシー: 安全な保存と高速なデータ取得。
- コスト効率: データ寿命が短いため、コストを最小化する必要がある。
- ライフサイクル管理: 保存期間終了後にデータを自動削除。
選択肢の評価
A. Amazon S3 に各レコードを単一の .csv ファイルとして保存し、ライフサイクルポリシーを設定する
- 長所: S3はスケーラブルで耐久性が高く、ライフサイクルポリシーで自動削除可能。
- 短所: 小さなレコードごとに個別ファイルを保存すると、管理やアクセス効率が低下する。小さいファイルが大量にあるとS3のオペレーションコストも増加。
- 評価: 不適切。高頻度データ取り込みには不向き。
B. Amazon DynamoDB に各レコードを保存し、TTL 機能で120日後に自動削除する
- 長所: DynamoDBは高スループットと低レイテンシーを提供。TTLでデータの自動削除が可能。データが小さいためコスト効率が良い。
- 短所: 大量のデータに対する長期保存コストはS3に比べ高めだが、120日の保存であれば問題にならない。
- 評価: 最適解。要件をすべて満たす。
C. Amazon RDS MySQL に保存し、夜間クエリで120日以上のデータを削除する
- 長所: SQLでデータ操作が簡単。
- 短所: 高頻度で大量のデータをRDSに取り込むとパフォーマンスが低下する。手動クエリでの削除管理は運用コストが高く非効率。
- 評価: 不適切。運用とパフォーマンスの観点で劣る。
D. バッチ処理したデータを Amazon S3 に保存し、メタデータ検索とライフサイクルポリシーを活用する
- 長所: S3のスケーラビリティを活用可能。バッチ処理でファイル数を削減し、オペレーションコストを最小化。
- 短所: メタデータ検索の柔軟性はDynamoDBほど高くない。リアルタイム性や低レイテンシー要件には適合しない。
- 評価: 適切ではない。リアルタイム処理に不向き。
結論
最適解はB: Amazon DynamoDB を使用し、TTL 機能でデータを管理です。
この選択肢は、データ取り込みのスケール、高速なアクセス、ライフサイクル管理のすべてを効率的に実現します。
076-RDS 昇格
理論
高可用性を実現するためのAmazon RDSの設計ポイント
AWSでデータベースの高可用性を確保するには、設計段階から適切な戦略を選択することが重要です。以下に、主要な方法と関連する概念を簡潔に解説します。
1. マルチAZ配置
Amazon RDSのマルチAZ配置は、障害時に自動フェイルオーバーを提供します。プライマリインスタンスとスタンバイインスタンスを異なるアベイラビリティーゾーン(AZ)に配置することで、地域内の冗長性を確保します。これにより、以下の利点があります：
- 自動フェイルオーバーによりダウンタイムを最小化
- パッチ適用やメンテナンス中も高い可用性を提供
2. リードレプリカ
リードレプリカは、読み取り専用のデータベースインスタンスで、負荷分散とデータ冗長性を提供します。特に以下のケースに有効です：
- 大量の読み取り要求を処理する場合
- クロスリージョンでデータをレプリケートし、地理的な分散を実現する場合
リードレプリカは、手動で昇格してプライマリインスタンスとして機能させることも可能です。
3. バックアップと復元
Amazon RDSは自動バックアップ機能を提供しており、指定した保持期間内にスナップショットを保存します。バックアップは、以下のシナリオで役立ちます：
- データ損失時にデータを迅速に復元する
- 新しいDBインスタンスの作成に利用する
- 自動バックアップ（Automated Backups） そのものは、昇格できません。しかし、自動バックアップからの復元を行うことができます。
4. クロスリージョンレプリケーション
クロスリージョンリードレプリカを使用すると、異なるAWSリージョンにデータベースのコピーを作成できます。これにより、次のような利点が得られます：
- 災害復旧(DR)の向上
- 地域ごとの低レイテンシーアクセスを実現
障害時には、クロスリージョンリードレプリカを昇格してスタンドアロンインスタンスとして使用できます。
5. フェイルオーバー戦略
障害発生時にシステムを迅速に復旧するには、フェイルオーバー戦略が重要です。以下を考慮する必要があります：
- 自動フェイルオーバー(Multi-AZ)
- 手動昇格(リードレプリカ)
- アプリケーション側でのエンドポイント切り替え
6. 権限管理とセキュリティ
高可用性のデータベースでは、アクセス権限とセキュリティ設定も重要です：
- AWS IAMロールを使用してアクセスを制御
- 最小権限の原則を適用し、不要な操作を制限
- データ暗号化やネットワークセキュリティも考慮
これらの戦略を組み合わせることで、AWS上で堅牢で高可用性なデータベースアーキテクチャを構築できます。設計時には、アプリケーションの特性やビジネス要件に応じた最適な構成を選択することが鍵となります。
一問道場
質問 #76
小売企業が複数のAWSリージョンにまたがるAWS上でeコマースウェブサイトをホストしています。この企業は、オンライン購入のためにウェブサイトが常時稼働可能であることを望んでいます。ウェブサイトは、データをAmazon RDS for MySQL DBインスタンスに保存しています。
データベースの最高の可用性を提供するソリューションはどれですか？
選択肢:
A.
Amazon RDSの自動バックアップを構成します。障害が発生した場合、自動バックアップをスタンドアロンDBインスタンスとして昇格させます。データベーストラフィックを昇格されたDBインスタンスにリダイレクトします。昇格されたDBインスタンスをソースとする新しいリードレプリカを作成します。
B.
Amazon RDSでグローバルテーブルとリードレプリカを構成します。クロスリージョンスコープを有効化します。障害が発生した場合、AWS Lambdaを使用して1つのリージョンから別のリージョンにリードレプリカをコピーします。
C.
Amazon RDSでグローバルテーブルと自動バックアップを構成します。障害が発生した場合、AWS Lambdaを使用して1つのリージョンから別のリージョンにリードレプリカをコピーします。
D.
Amazon RDSでリードレプリカを構成します。障害が発生した場合、クロスリージョンのリードレプリカをスタンドアロンDBインスタンスとして昇格させます。データベーストラフィックを昇格されたDBインスタンスにリダイレクトします。昇格されたDBインスタンスをソースとする新しいリードレプリカを作成します。
解説
選択肢の検討
- A:
- 自動バックアップを利用してデータを復元し、スタンドアロンDBインスタンスに昇格する方法を提案しています。
- 問題点: 自動バックアップはデータの復旧には役立ちますが、リアルタイムの高可用性や迅速な切り替えは保証されません。ダウンタイムが長くなる可能性があります。
- B:
- グローバルテーブルとリードレプリカを使い、クロスリージョンのスコープを有効化する方法を提案しています。
- 問題点: Amazon RDSには「グローバルテーブル」という機能はありません。リードレプリカの操作もAWS Lambdaで行うことは非効率的で現実的ではありません。
- C:
- グローバルテーブルと自動バックアップを組み合わせ、AWS Lambdaを使用してレプリカをコピーする方法です。
- 問題点: Bと同様に、RDSでグローバルテーブルの概念はなく、AWS Lambdaを用いたレプリカ管理も実用的ではありません。
- D:
- クロスリージョンのリードレプリカを用い、障害発生時にはリードレプリカをスタンドアロンインスタンスに昇格する方法です。
- メリット: クロスリージョンリードレプリカは地理的な冗長性を提供し、昇格後はプライマリとして機能させられます。昇格後に新たなリードレプリカを作成することで、引き続き高可用性を維持できます。
解答: D
Dが最適な選択肢です。このアプローチは以下の理由で他の選択肢より優れています：
- 高可用性: 障害時に迅速に昇格し、ダウンタイムを最小限に抑えることが可能です。
- 地理的冗長性: クロスリージョンリードレプリカを活用することで、災害時にも対応できます。
- コスト効率: 自動バックアップやスタック操作よりも効率的なフェイルオーバーを提供します。
補足: AWS RDS高可用性のベストプラクティス
- Multi-AZ配置: 地域内での冗長性と自動フェイルオーバーを提供します。
- リードレプリカ: 読み取り負荷の分散とクロスリージョン冗長性を実現します。
- バックアップ: 定期的なスナップショットを活用してデータ損失リスクを軽減します。
- フェイルオーバー手順: 昇格操作を事前にテストし、運用の準備を整えておくことが重要です。
このような設計を採用することで、AWS環境での高可用性が確保され、ビジネス要件を満たす運用が可能になります。
077-Site-to-Site→VGT→TGW
理論
1. BGP伝播とVPCピアリング
- BGP (Border Gateway Protocol) は、主に VPN接続 や 複数のネットワーク間でのルート情報の交換 に使われます。例えば、AWS の Site-to-Site VPN で利用されます。
- VPCピアリング は、異なるVPC同士を直接接続する方法です。しかし、VPCピアリングでは BGP伝播 は使われません。ルートの追加は手動で行う必要があります。
VPCピアリングとは？
- VPCピアリング は、異なるVPC間で 直接通信 を可能にする接続方法です。
- これにより、例えば 異なるAWSアカウント や 異なるAWSリージョン にあるVPC同士が、インターネットを介さずに、安全に通信できるようになります。
制限
- VPCピアリングは 一対一の接続 です。つまり、ピアリングしたVPC同士だけが直接通信できます。
- たくさんのVPCを接続したい場合、それぞれのVPC間で個別にピアリングを設定する必要があります。
- トランジットゲートウェイ を使うことで、複数のVPCを効率的に接続することができますが、ピアリングはあくまで1対1の接続です。
Site-to-Site VPN
実践
一問道場
問題 #77
Example Corp. はオンプレミスのデータセンターと、Example Corp. の AWS アカウント内にある VPC A を持っています。オンプレミスのネットワークは、AWS Site-to-Site VPN を介して VPC A と接続されています。オンプレミスのサーバーは VPC A に正常にアクセスできます。Example Corp. は AnyCompany を買収し、その会社の VPC B を持っています。これらのネットワーク間で IP アドレスの重複はありません。Example Corp. は VPC A と VPC B をピアリングしました。Example Corp. はオンプレミスのサーバーから VPC B に接続したいと考えています。Example Corp. はネットワーク ACL とセキュリティグループを適切に設定しています。最小限の運用努力でこの要件を満たす解決策はどれですか？
A. トランジットゲートウェイを作成し、Site-to-Site VPN の VPC A と VPC B をトランジットゲートウェイに接続します。トランジットゲートウェイのルートテーブルを更新して、すべてのネットワーク間の IP 範囲のルートを追加します。
B. トランジットゲートウェイを作成し、オンプレミスネットワークと VPC B の間に Site-to-Site VPN 接続を作成して、その VPN 接続をトランジットゲートウェイに接続します。ルートを追加してトラフィックをピアリングされた VPC に向け、認証ルールを追加してクライアントに VPC A と VPC B へのアクセスを許可します。
C. Site-to-Site VPN と両方の VPC のルートテーブルを更新し、すべてのネットワークのために BGP 伝播を構成します。BGP 伝播が完了するまで最大 5 分待ちます。
D. Site-to-Site VPN の仮想プライベートゲートウェイの定義を変更して、VPC A と VPC B を含めます。仮想プライベートゲートウェイの 2 つのルーターを VPC 間で分割します。
解説
問題の背景
- オンプレミスにあるデータセンターとAWSのVPC Aを、AWS Site-to-Site VPNで接続しています。
- 新たに、AnyCompanyがVPC Bを持っていて、Example CorpはこのVPC AとVPC BをVPCピアリングで接続しました。
- オンプレミスからVPC Bへのアクセスを実現したいという要求があります。
- 要件は、できるだけ少ない運用作業で接続を実現する方法を選ぶことです。
解説
この状況を解決するための方法は、どの方法が最も効率的で運用負担が少ないかを問う問題です。
選択肢を確認
- A. トランジットゲートウェイを作成し、Site-to-Site VPN VPC AとVPC Bを接続してルートテーブルを更新
- トランジットゲートウェイは複数のVPCやVPN接続を効率的に管理するためのサービスです。
- VPC A、VPC B、オンプレミスのVPNをトランジットゲートウェイに接続し、トラフィックを適切にルーティングするためにルートテーブルを設定する方法です。この方法は、複数のネットワーク間を効率的に接続するため、運用負担を軽減し、スケーラビリティを提供します。
最適な解決策として、最小の運用作業で必要な接続を提供できます。
- B. トランジットゲートウェイを作成し、Site-to-Site VPN接続をVPC Bに接続し、ルートを追加してアクセスを許可
- この方法では、VPC Bとの接続を新たにVPN接続を通してトランジットゲートウェイ経由で行います。
- ルートを追加し、クライアントが両VPCにアクセスできるようにしますが、この方法はVPC間の接続を効率的に管理する点で最適とは言えません。
- C. すべてのネットワークでBGP（Border Gateway Protocol）伝播を設定してルートを自動的に調整
- BGPはダイナミックルーティングのプロトコルで、通常は大規模なネットワークで使用されます。
- この方法では、VPN接続とVPC間でルートの調整を行うことでネットワーク間の接続を最適化できますが、運用面では少し手間がかかります。
- D. Site-to-Site VPNの仮想プライベートゲートウェイを変更してVPC AとVPC Bを接続
- この方法では、仮想プライベートゲートウェイの設定を変更してVPC間接続を行いますが、通常、トランジットゲートウェイを使用する方が効率的でスケーラブルです。
- この方法は、VPC AとVPC Bのピアリングの後にさらにVPN設定を変更する必要があり、運用負担が増えます。
最適な選択肢はA
- A. トランジットゲートウェイを作成し、Site-to-Site VPN VPC AとVPC Bを接続して、ルートテーブルを更新する方法が最も運用負担が少なく、スケーラブルで効率的です。
- トランジットゲートウェイは、複数のVPCとオンプレミス接続を効率的に管理でき、今後の拡張にも対応できます。
078-SES
理論
Amazon Simple Email Service (Amazon SES) は、SMTP プロトコルだけでなく、他にもいくつかの方法でメールを送信することができます。以下に、SES の主要な送信方法を紹介します。
1. SES API（AWS SDK）を使用した送信
SES は、SMTP の代わりに Amazon SES API を使用して、プログラムから直接メールを送信することもできます。これには、AWS SDK（ソフトウェア開発キット）を使って、SES サービスに対してリクエストを送信します。API を使用することで、SMTP に比べてより細かな制御やエラーハンドリングが可能です。
- AWS SDKの使用: SES API は、AWS SDK を通じて簡単に呼び出せます。これにより、SES に対して、メールの送信、テンプレートの使用、バウンスや苦情の管理などが可能になります。
- HTTP リクエスト: SES API は HTTPS リクエストを通じて直接通信を行うため、SMTP よりもパフォーマンスが高い場合があります。
メリット:
- 高い柔軟性
- より多くの機能（バウンスや苦情の処理、テンプレート使用など）
- パフォーマンスの向上
2. Amazon SES SMTP インターフェース
前述の通り、SES は SMTP プロトコルをサポートしていますが、STARTTLS を使ってセキュアに接続できます。SMTP 経由でメールを送信する場合、アプリケーションは SMTP 認証情報を使って SES に接続します。
メリット:
- 既存の SMTP サーバーを利用して簡単に統合可能
- よく知られたプロトコルのため、設定が簡単
TLSラッパーの役割
- SMTP接続の暗号化: 通常のSMTP接続をTLSでラップして、セキュアな通信を提供します。これにより、メールの内容や送信者、受信者情報などが盗聴されるリスクを低減します。
- 古いSMTPサーバーとの互換性: 古いシステムでは、直接TLSをサポートしていない場合があります。その場合、TLSラッパーを使うことで、非暗号化のSMTP接続に後から暗号化を追加することができます。
実際の使用例
例えば、もし既存のSMTPサーバーがTLSに対応していない場合、TLSラッパーを使ってそのサーバーを保護することができます。こうした技術を使うことで、暗号化が必要な場合でもシステムの変更を最小限に抑えつつ、通信のセキュリティを強化することができます。
STARTTLSとの違い
- STARTTLS: SMTP接続が初めに平文で行われ、その後通信中にTLS暗号化が開始される拡張です。多くの現代的なメールサーバーはこの方法を使用しています。
- TLSラッパー: 最初からTLS接続で暗号化されたSMTP通信を確立する方法で、通信が完全にセキュアな状態で開始されます。
3. Amazon SES コンソールを使った手動送信
SES には、コンソールから直接メールを送信する方法もあります。これにより、簡単なテストや少量のメール送信を行いたい場合に便利です。
メリット:
- インターフェースが直感的
- 少量のテストや手動でのメール送信に最適
4. Amazon SES でのメールテンプレート利用
SES では、メールテンプレートを使って、同じ形式のメールを何度も送信することができます。テンプレートを利用することで、個別のメールを動的に生成し、より効率的に大量のメールを送信することができます。
メリット:
- メールの一貫性を保ちながら、効率的に大量送信できる
- 変数を使用して個別対応が可能
5. Amazon SES の送信結果やレポートの取得
SES には、送信したメールの バウンス や 苦情 を追跡するための機能があります。また、CloudWatch と統合して、メール配信のパフォーマンスやエラーをモニタリングできます。これにより、配信の成功率を分析したり、問題が発生した際に迅速に対応することができます。
メリット:
- メール送信後の結果をリアルタイムで監視
- 配信のパフォーマンスを向上させるためのデータを収集
6. Amazon SES と Lambda の統合
AWS Lambda を使って、特定のイベントに基づいてメールを自動的に送信することもできます。例えば、ユーザーがフォームを送信したときや、特定の条件を満たしたときにメールをトリガーすることができます。
メリット:
- イベント駆動型の自動化
- システム全体の柔軟な統合が可能
SES を利用するメリットと選択肢
SES は、単に SMTP 経由でメールを送信するだけではなく、API、Lambda 連携、バウンスや苦情の管理など、強力な機能を提供します。これにより、シンプルな通知メールから、大量のカスタマイズされたメール配信まで幅広く対応可能です。
選択肢の選定基準:
- SMTP 使用: 既存のアプリケーションが SMTP を使用している場合、最も簡単で手軽な方法。
- SES API 使用: より柔軟で、エラーハンドリングやパフォーマンスの向上を望む場合。
- Lambda 使用: イベント駆動型の自動化が必要な場合。
これらの方法を活用することで、より効率的で効果的なメール配信を実現できます。
一問道場
問題 #78
ある企業は、再プラットフォーム戦略を使用して、オンプレミスのデータセンターからAWSクラウドへの移行を完了しました。移行されたサーバーの1つが、重要なアプリケーションが依存しているレガシーなSimple Mail Transfer Protocol (SMTP) サービスを実行しています。このアプリケーションは、企業の顧客に対して外向きのメールメッセージを送信します。レガシーSMTPサーバーはTLS暗号化をサポートしておらず、TCPポート25を使用しています。アプリケーションはSMTPのみを使用できます。
企業は、Amazon Simple Email Service (Amazon SES) を使用し、レガシーSMTPサーバーを廃止することに決めました。企業はSESドメインを作成し、検証しました。また、SESの制限も解除されています。
アプリケーションがAmazon SESからメールメッセージを送信できるようにするために、企業は何をすべきですか？
選択肢
A. アプリケーションをTLSラッパーを使ってAmazon SESに接続するように設定します。
ses:SendEmail と ses:SendRawEmail の権限を持つIAMロールを作成し、そのロールをAmazon EC2インスタンスにアタッチします。B. アプリケーションをSTARTTLSを使ってAmazon SESに接続するように設定します。Amazon SESのSMTP認証情報を取得し、その認証情報を使ってAmazon SESに認証します。
D. アプリケーションをAWS SDKを使用してメールメッセージを送信するように設定します。Amazon SES用のIAMユーザーを作成し、APIアクセスキーを生成して、そのアクセスキーを使ってAmazon SESに認証します。
解説
A. TLSラッパーを使ってAmazon SESに接続するように設定する
- 解説: TLSラッパーを使用してAmazon SESに接続する方法は、一般的にセキュリティが強化される手段ですが、この場合、アプリケーションがレガシーなSMTPのみをサポートしているため、SESのSMTP認証を使用するためにSTARTTLSが必要です。
- 理由: TLSラッパーは、SMTPの暗号化を強化する方法ですが、SESは直接SMTP通信を行う場合、STARTTLSを使って暗号化を開始する必要があり、これはこの選択肢の説明には当てはまりません。
B. STARTTLSを使ってAmazon SESに接続するように設定し、SMTP認証情報を使用する
- 解説: Amazon SESでは、SMTPプロトコルを使用してメールを送信するために、STARTTLSを使って暗号化を開始することができます。さらに、SESのSMTP認証情報を使用して、アプリケーションを認証します。
- 理由: このアプローチは、アプリケーションがレガシーSMTPを使用しており、TLS暗号化がサポートされていないため、SESが提供するSMTP認証（STARTTLS）を使用する最も適切な方法です。
- 正解: この選択肢は、最も適切で効果的な方法です。
C. SES APIを使用してメールメッセージを送信するように設定し、IAMロールをサービスロールとして使用する
- 解説: SES APIを使用すると、Amazon SESを直接呼び出してメールを送信することができます。この方法は、プログラム的にSESを利用する方法としては有効ですが、問題文には「アプリケーションがSMTPのみを使用する」と記載されており、この選択肢はSMTPプロトコルを使用するという要件を満たしていません。
- 理由: SES APIはAPIを介してメール送信を行うもので、SMTPを使用するというアプリケーション要件には合いません。
D. AWS SDKを使ってメールメッセージを送信し、IAMユーザーのアクセスキーを使用して認証
- 解説: AWS SDKを使用すると、SESをプログラム的に操作することができますが、これもAPI呼び出しを行う方法です。問題文においてアプリケーションはSMTPのみを使用すると記載されており、SDKやAPIを使用するアプローチは要件に合致しません。
- 理由: この方法もSES APIを使ったアプローチであり、SMTPでの接続が必要な要件を満たしていません。
最適解：B
アプリケーションがレガシーSMTPを使用しているため、Amazon SESのSMTP認証（STARTTLS）を利用する方法が最も適切です。この方法で、アプリケーションがSMTPを通じてメールを送信できるようになります。また、SESのSMTP認証情報を使うことで、認証も簡単に行うことができます。
079-CUR
理論
AWSにおけるコスト管理とレポート作成の本質的な知識は以下の通りです：
1. AWS Cost and Usage Report (CUR):
- 概要: AWSのリソース利用状況とコストの詳細なレポートを提供するサービス。利用する全アカウント、サービス、リソースタイプごとの費用情報を精密に把握できます。
- 利用方法: AWSアカウントで生成されたレポートはCSV、Parquetなどの形式で保存され、これをもとに分析を行います。
2. タグとコストカテゴリー:
- タグ: AWSリソースに追加できるメタデータ。これを使うことで、リソースのコストをプロジェクト別、チーム別、または部門別に分けてレポートすることができます。
- コストカテゴリー: 特定の費用を分類するための設定。リソースタグとは異なり、コストの集計単位で分類できるため、さらに柔軟なコスト分析が可能です。
3. Amazon Athena:
- 概要: AWS上に保存されたデータに対してSQLクエリを実行するインタラクティブな分析サービス。CURデータをAthenaでクエリすることで、詳細なコスト分析が可能になります。
- 利用方法: Athenaを使って、AWS Cost and Usage Reportを格納したS3バケットに保存されたデータをクエリし、財務レポートを作成できます。
4. Amazon QuickSight:
- 概要: ビジネスインテリジェンス（BI）サービスで、データを視覚的に分析・可視化できます。AWS環境と直接統合され、AthenaやRedshiftなどのデータソースからデータを取得してダッシュボードを作成します。
- 利用方法: Athenaで抽出したデータをQuickSightで視覚化し、レポートやダッシュボードを作成。これにより、ユーザーは簡単にコストや利用状況を追跡できます。
5. 自己管理型アプリケーション:
- 概要: ユーザーがレポートやダッシュボードを自分で管理・カスタマイズできるシステム。AWSのツールを組み合わせることで、財務チームなどがレポート作成や分析を自分のペースで行えるようになります。
6. AWS Cost Explorer:
- 概要: AWSのリソース利用にかかる費用を可視化するツール。利用状況を日別、月別で表示したり、予算を設定してコストの変動を追跡したりできます。
- 利用方法: AWS Cost and Usage Reportを元に、Cost Explorerを利用して、期間ごとのコスト分析や予算管理を行います。
これらのツールを活用することで、複数アカウントや大規模なAWS環境におけるコストの効率的な管理とレポート作成が可能となり、企業の財務チームは柔軟かつ自己管理型でコストを把握できます。
一問道場
問題 #79
ある企業が最近、いくつかの他の企業を買収しました。各企業は別々のAWSアカウントを持ち、異なる請求および報告方法を採用しています。買収した企業は、すべてのアカウントをAWS Organizationsで1つの組織に統合しました。しかし、買収した企業は、すべてのチームにとって意味のあるコストレポートを生成するのが難しいと感じています。企業の財務チームは、すべての企業のコストを自己管理型アプリケーションでレポートする方法を求めています。
どのソリューションがこれらの要件を満たしますか？
A. 組織用のAWSコストおよび使用状況レポートを作成する。レポートでタグとコストカテゴリを定義する。Amazon Athenaにテーブルを作成する。Athenaテーブルに基づいたAmazon QuickSightデータセットを作成する。データセットを財務チームと共有する。
B. 組織用のAWSコストおよび使用状況レポートを作成する。レポートでタグとコストカテゴリを定義する。財務部門がレポートを作成するための専用テンプレートをAWSコストエクスプローラーで作成する。
C. AWS価格リストクエリAPIから支出情報を受け取るAmazon QuickSightデータセットを作成する。データセットを財務チームと共有する。
D. AWS価格リストクエリAPIを使用してアカウントの支出情報を収集する。財務部門がレポートを作成するための専用テンプレートをAWSコストエクスプローラーで作成する。
解説
この問題は、複数のAWSアカウントを統合した企業が、全アカウントのコストを簡単にレポートする方法を探している状況に関するものです。財務チームは、自己管理型のアプリケーションを使ってコストレポートを作成したいと考えています。
解説:
最適な解決策は、AWSのCost and Usage Reportを使い、Amazon AthenaとAmazon QuickSightを組み合わせてレポートを生成する方法です。
- Aが最適な選択肢です。
- AWS Cost and Usage Reportを作成し、タグやコストカテゴリーを定義して、レポートを詳細にカスタマイズ。
- Athenaを使ってレポートデータをクエリし、QuickSightで視覚的に分析できるようにします。
- QuickSightのデータセットを財務チームと共有し、レポート作成を自己管理できるようにします。
この方法により、財務チームはAWSのツールを使用して自分たちでコストレポートを生成し、分析できるようになります。
080-Kinesis+Lambda+DynamoDB
理論
1. スケーラビリティの確保
- スケーラブルなアーキテクチャの構築は、負荷が増加した場合にも安定してシステムを運用するための重要な要素です。AWSでは、Amazon KinesisやAmazon DynamoDBなどのサービスが高いスケーラビリティを提供し、システムの成長に伴うデータ処理能力を効率的に拡張できます。
- Kinesis Data Streamsはリアルタイムで大量のデータをストリーム形式で処理するため、IoTプラットフォームのように継続的にデータが流入するシステムに適しています。
- Amazon DynamoDBは、特に大量のデータを扱う場合に最適なNoSQLデータベースです。スケーラビリティが高く、運用面での負荷が少ないため、トランザクション型のRDS MySQLに比べて、可用性と拡張性に優れています。
2. サーバーレスアーキテクチャ
- AWS Lambdaなどのサーバーレス技術を活用することで、インフラの管理を最小限に抑え、必要なときにだけリソースを自動的にスケールさせることができます。これにより、コストの最適化が図れ、システムの負荷に応じて柔軟にリソースを調整できます。
- AWS Lambdaは、イベント駆動型で処理を実行するため、Kinesisのデータストリームからイベントを受け取り、リアルタイムでデータ処理を行うことが可能です。
3. データ処理とストレージ
- データベース選定がシステムの性能やスケーラビリティに直接影響を与えるため、ユースケースに合ったデータストレージと処理方法を選ぶことが重要です。
- Amazon RDS MySQLなどのリレーショナルデータベースは、トランザクション管理や複雑なクエリに強みがありますが、スケールが求められる場合にはパフォーマンスに限界があります。
- Amazon DynamoDBは、NoSQLデータベースとして、フラットなデータ構造や大量のデータを高速に読み書きできるため、大量データを効率よく処理する場合に最適です。
4. コスト効率と運用負荷の最適化
- サーバーレスアーキテクチャやオートスケーリング機能（例えば、Kinesis、Lambda）は、リソースの使用量に応じて自動でスケールアップ・ダウンが可能なため、必要なときにのみリソースを消費し、コストを抑えることができます。
- 自動スケーリングや**コンテナサービス（Amazon ECS、EKS）**の活用は、インフラの運用負荷を削減し、コスト効率を高める手段です。
これらの知識を基に、IoTプラットフォームのようなデータ量の急激な増加に対応するためには、スケーラビリティと柔軟なデータ処理を可能にするアーキテクチャの選定が鍵となります。
この図は、Amazon Kinesis Data Analytics Studio を中心としたリアルタイムデータ分析の仕組みを表しています。以下に、主要な要素とデータの流れを説明します：
1. Amazon Kinesis Data Analytics Studio
- データをリアルタイムで分析するためのプラットフォーム。
- ユーザーは SQL、Python、Scala を使ってデータを分析可能。
- Webクライアント からノートブック形式で操作し、結果を確認します。
2. データの流れ
データの入力元（Streaming Sources）
- Amazon Kinesis Data Streams: ストリームデータをリアルタイムで送信。
- Amazon Managed Streaming for Apache Kafka: Kafkaを利用したデータソース。
データの分析
- データは Amazon Kinesis Data Analytics に送られ、リアルタイム分析が行われます。
- AWS Glue Data Catalog を利用してデータスキーマ（データ構造）を管理し、分析を容易にします。
データの出力先（Streaming Destinations）
- 分析結果は再び Amazon Kinesis Data Streams または Amazon Managed Streaming for Apache Kafka に送られます。
- このデータは、次のアプリケーションやシステムで利用されます。
3. 目的
この仕組みは、リアルタイムデータの処理や分析を効率化し、即座に価値のある洞察を得るために設計されています。例えば、IoTデバイスのデータ処理、ログ解析、フィナンシャルデータのリアルタイム分析などに活用されます。
まとめ
図の全体像を簡単に言うと、リアルタイムデータを収集（データストリーム）、分析（Kinesis Data Analytics）、活用（出力先）する一連のプロセスを示しています。
Kinesis
以下の表に、Amazon Kinesis Data Streams と Amazon Kinesis Data Firehose の違いを整理しました。
項目 | Amazon Kinesis Data Streams | Amazon Kinesis Data Firehose |
主な用途 | リアルタイムデータ処理やストリーミングアプリケーション向け | バッチ処理やデータ配信向け |
リアルタイム性 | 高い（低遅延でデータを処理） | 比較的低い（バッファリング後に配信） |
データ保持期間 | 最長 7日間（デフォルトは24時間） | データ保持なし、処理後すぐに送信 |
ターゲット（送信先） | 任意のコンシューマーアプリケーション、Kinesis Data Analyticsなど | S3、Redshift、Elasticsearch、Splunkなど、あらかじめ定義された宛先 |
データ処理 | アプリケーションでカスタム処理可能 | 簡単な事前処理（Lambdaによる変換、圧縮）が可能 |
バッファリング | なし（データが即時処理される） | データを一定間隔またはサイズでバッファリングして送信 |
ユースケース例 | ログ解析、IoTデータ処理、リアルタイムモニタリング | データウェアハウスへのロード、アーカイブデータの保存 |
ポイントまとめ
- Kinesis Data Streams はリアルタイム性と柔軟なデータ処理が求められる場合に最適。
- Kinesis Data Firehose はシンプルなデータ配信やバッチ処理を求める場合に最適。
どちらを使用するかは、リアルタイム性の要件や送信先の形式によって選ぶと良いです！
一問道場
ある企業がAWS上でIoTプラットフォームを運用しています。さまざまな場所に設置されたIoTセンサーが、同社のNode.js APIサーバー（Amazon EC2インスタンスで、Application Load Balancerの背後に配置）にデータを送信し、そのデータはAmazon RDS MySQL DBインスタンス（4TBのGeneral Purpose SSDボリュームを使用）に保存されています。センサーの数は増加しており、今後も大幅に増加する見込みです。APIサーバーは常にオーバーロードしており、RDSのメトリクスは高い書き込みレイテンシーを示しています。
次のうち、プラットフォームを効率的にコスト管理しながら成長させ、新たなセンサーが導入されても問題を永続的に解決できる手段として適切なものはどれですか？（2つ選んでください。）
A. MySQLのGeneral Purpose SSDストレージを6TBにサイズ変更して、ボリュームのIOPSを改善する。
B. データベース層をRDS MySQL DBインスタンスからAmazon Auroraに変更し、リードレプリカを追加する。
C. Amazon Kinesis Data StreamsとAWS Lambdaを活用して、生データの取り込みと処理を行う。
D. AWS X-Rayを使用してアプリケーションの問題を分析・デバッグし、負荷に対応するためにAPIサーバーを追加する。
E. データベース層をRDS MySQL DBインスタンスからAmazon DynamoDBに変更する。
解説
選択肢 C と E の組み合わせを正解と考える理由について
C. Amazon Kinesis Data StreamsとAWS Lambdaを活用して、生データの取り込みと処理を行う。
- 理由: Amazon Kinesis Data Streamsは、リアルタイムで大量のデータを取り込むために使用され、AWS Lambdaを組み合わせることで、データ処理をサーバーレスで行うことができます。これにより、IoTセンサーから送られる膨大なデータの取り込みと処理を効率的にスケールさせることができ、APIサーバーやデータベースの負荷を軽減できます。特に、データ処理のスピードやスケーラビリティを向上させることができるため、成長するセンサー数にも対応可能です。
E. データベース層をAmazon DynamoDBに変更し、RDS MySQL DBインスタンスを置き換える。
- 理由: RDS MySQLは、トランザクション型のデータベースには限界がありますが、Amazon DynamoDBはNoSQL型のデータベースであり、非常に高いスケーラビリティを提供します。これにより、センサーから送られる大量のデータを効率的に扱うことができ、スケールの問題が解決されます。特に、IoTデータのようにアクセスパターンが予測できない場合には、DynamoDBは優れた選択肢です。
これらの選択肢は、以下の理由から適切です。
- Kinesis と Lambda を活用することで、データのリアルタイム処理が可能となり、システム全体のパフォーマンスを最適化できます。
- DynamoDB を利用することで、NoSQLの特性を活かし、スケーラビリティを確保し、RDS MySQLのスケーリング制限を回避できます。
まとめ：
- C と E の組み合わせが、プラットフォームを効率的にスケールさせ、成長に合わせて柔軟に対応できるため、正しい選択肢と言えます。
- 作者:みなみ
- 链接:https://www.minami.ac.cn//%E8%B3%87%E6%A0%BC%E5%8B%89%E5%BC%B7/16bd7ae8-88e2-802d-923e-d9c68b83ee80
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
