SAA-C03 · LESSON 3
高パフォーマンスなアーキテクチャの設計24% · 5項目
高性能・スケーラブルなストレージ、コンピューティング、データベース、ネットワーク、データの取り込みと変換の設計を学びます。
3.1高性能でスケーラブルなストレージを選ぶ
3.1 Determine high-performing and/or scalable storage solutions.
概念
EBS のボリュームタイプは、汎用 SSD（gp3：IOPS とスループットを容量と別に設定可）、プロビジョンド IOPS SSD（io2：高い IOPS と耐久性）、スループット最適化 HDD（st1：大きな連続の読み書き）、Cold HDD（sc1）です。共有ファイルは EFS（Linux）や FSx（Windows・Lustre の HPC）、S3 はプレフィックスごとに高いリクエストの性能を持ち、マルチパートアップロードや Transfer Acceleration で速くできます。
仕組み・手順
- アクセスのパターン（ランダムか連続か、IOPS かスループットか）を確認する
- 一般的な用途は gp3、高い IOPS の DB は io2 を選ぶ
- 複数のインスタンスで共有するなら EFS、HPC は FSx for Lustre
- 大きなファイルの S3 へのアップロードはマルチパート、遠隔地からは Transfer Acceleration
- インスタンスストアは高速だが一時的なデータだけに使う
業務での例
ログの大量の連続書き込みには st1、取引 DB には io2、機械学習の学習データの高速な共有には S3 と連携した FSx for Lustre を使う。
紛らわしい点・試験の注意
- gp2 は容量に比例して IOPS が決まり、gp3 は独立に設定できる
- インスタンスストアは停止・終了でデータが消える
- EFS は複数 AZ から同時にマウントできる。EBS は基本的に 1 つの AZ
ミニクイズ
Q1. gp2 の EBS ボリュームで、容量は足りているが IOPS が不足している。費用を抑えて性能を上げる方法として最も適切なものはどれか。
- ボリュームを gp3 に変更し、必要な IOPS を容量とは別に設定する
- IOPS を得るためだけに、必要以上に容量を大きくした gp2 を使い続ける
- ボリュームを sc1 に変更して、費用を下げる
- EBS をやめて、すべてのデータをインスタンスストアに置く
答えと解説を見る
正解：A ボリュームを gp3 に変更し、必要な IOPS を容量とは別に設定する
gp2 は容量に比例して IOPS が決まる。gp3 なら容量と別に IOPS とスループットを設定でき、多くの場合費用も下がる。Elastic Volumes で稼働中に変更できる。
Q2. EC2 上のアプリが遅い。CloudWatch で確認すると、CPU 使用率は低いが、EBS ボリュームの読み書きが上限に張り付いている。次に行うべきこととして最も適切なものはどれか。
- Auto Scaling の最大台数を増やす
- CloudWatch のアラームを削除する
- EBS のボリュームタイプや IOPS・スループットの設定を見直し、必要に応じて変更する
- インスタンスの CPU を増やすため、より大きなインスタンスタイプに変更して様子を見る
答えと解説を見る
正解：C EBS のボリュームタイプや IOPS・スループットの設定を見直し、必要に応じて変更する
ボトルネックはストレージの I/O なので、CPU を増やしても改善しない。ボリュームの性能（gp3 の IOPS 設定や io2 への変更）とインスタンスの EBS 帯域を見直す。
参考リンク
3.2高性能で弾力的なコンピューティングを設計する
3.2 Design high-performing and elastic compute solutions.
概念
性能のためには、ワークロードに合うインスタンスファミリー（C：計算、R：メモリ、I：ストレージ、G・P：GPU、Graviton の高い価格性能）を選び、Auto Scaling で弾力的に増減します。スケーリングのポリシーには、ターゲット追跡（CPU 50% を維持など）、ステップ、スケジュール、予測スケーリングがあります。低遅延の HPC はクラスタープレイスメントグループを使います。
仕組み・手順
- ボトルネック（CPU・メモリ・I/O・ネットワーク）を CloudWatch で確認する
- 適するインスタンスファミリーを選ぶ（Compute Optimizer の推奨も参考に）
- ターゲット追跡のスケーリングを基本にし、予測できるピークにはスケジュールを加える
- 起動に時間がかかる場合はウォームプールを使う
- イベント駆動の短い処理は Lambda、コンテナは Fargate も検討する
業務での例
毎朝 9 時にアクセスが集中する社内システムで、8 時 45 分にスケジュールで台数を増やし、日中はターゲット追跡で CPU 60% を維持する。
紛らわしい点・試験の注意
- クラスタープレイスメントグループは 1 つの AZ 内で低遅延、分散プレイスメントグループは障害の分離
- Lambda の同時実行の上限やコールドスタートに注意（プロビジョンド同時実行で軽減）
- 垂直スケーリング（大きいインスタンス）には停止が伴うことが多い
ミニクイズ
Q1. バッチ処理の性能を上げるため、処理を多数の小さなジョブに分けて並列に実行したい。インフラの管理を最小限にする方法として最も適切なものはどれか。
- EMR のクラスターを常時起動し、ジョブを投入する
- AWS Batch や Step Functions の分散マップで、ジョブを並列に実行する
- EC2 の Auto Scaling グループを作り、ジョブをスクリプトで配る
- Lambda で 1 つの関数の中にすべてのジョブを並列のスレッドで書く
答えと解説を見る
正解：B AWS Batch や Step Functions の分散マップで、ジョブを並列に実行する
マネージドなバッチ実行や分散処理の仕組みを使うと、並列度に応じて計算資源を自動で用意できる。 【他の選択肢】Auto Scaling とスクリプトは管理の負担が大きい。常時起動の EMR は管理と費用がかかる。1 つの関数の中では時間とメモリの上限に当たる。
Q2. Lambda 関数の処理時間が長く、メモリの使用量には余裕がある。処理を速くする方法として最も適切なものはどれか。
- 関数を別のリージョンに作り直す
- タイムアウトを短くして、処理を早めに打ち切り、残りは次回に回す
- 同時実行数を 1 に制限する
- 関数のメモリを増やす（CPU も比例して増える）
答えと解説を見る
正解：D 関数のメモリを増やす（CPU も比例して増える）
Lambda はメモリの設定に比例して CPU が割り当てられる。CPU が律速の処理は、メモリを増やすと速くなり、実行時間の短縮で費用が下がることもある。
参考リンク
3.3高性能なデータベースのソリューションを決める
3.3 Determine high-performing database solutions.
概念
読み取りの拡張は RDS・Aurora のリードレプリカ（Aurora は最大 15）、頻繁な読み取りのキャッシュは ElastiCache（Redis・Memcached）、DynamoDB のマイクロ秒の読み取りは DAX です。接続数の急増には RDS Proxy、予測できない負荷には Aurora Serverless v2、大規模なキーバリューは DynamoDB のパーティションキーの設計が性能を左右します。
仕組み・手順
- 読み取りと書き込みの比率、レイテンシの要件を確認する
- 読み取りが多いならリードレプリカかキャッシュを使う
- Lambda からの大量の接続は RDS Proxy でプールする
- DynamoDB はアクセスが偏らないパーティションキーを選び、必要なら DAX を加える
- グローバルな低遅延の読み取りは Aurora Global Database や DynamoDB グローバルテーブル
業務での例
商品の詳細ページの読み取りが DB の負荷の 9 割を占めるため、ElastiCache に結果をキャッシュし、在庫の更新はプライマリへ書き込む。
紛らわしい点・試験の注意
- リードレプリカは非同期なので、わずかな遅れがある
- DAX は DynamoDB 専用のキャッシュ（ElastiCache とは別）
- RDS Proxy は接続の管理で、クエリ自体を速くするものではない
ミニクイズ
Q1. RDS for PostgreSQL の読み取りの負荷が高く、応答が遅い。書き込みは少ない。アプリの変更を抑えて性能を上げる方法として最も適切なものはどれか。
- リードレプリカを追加し、読み取り専用のクエリをレプリカに向ける
- DB インスタンスを一度停止して、割り当てたストレージの容量を減らす
- マルチ AZ のスタンバイに読み取りのクエリを送る
- データベースのバックアップの保持期間を短くする
答えと解説を見る
正解：A リードレプリカを追加し、読み取り専用のクエリをレプリカに向ける
リードレプリカで読み取りを分散できる。マルチ AZ（インスタンス配置）のスタンバイは読み取りに使えない。
Q2. 利用が少ない時間帯と急増する時間帯の差が大きいリレーショナル DB で、容量の調整を自動化したい。最も適切なものはどれか。
- Aurora のリードレプリカの Auto Scaling で、レプリカの数を増減する
- Aurora Serverless v2 を使い、負荷に応じて容量を自動で増減する
- RDS のストレージの自動スケーリングを有効にする
- RDS Proxy を置き、接続をプールして負荷を下げる
答えと解説を見る
正解：B Aurora Serverless v2 を使い、負荷に応じて容量を自動で増減する
Aurora Serverless v2 は、負荷に応じてキャパシティ（ACU）を細かく自動で調整する。 【他の選択肢】レプリカの Auto Scaling は読み取りだけで、書き込みの容量は増えない。ストレージの自動の拡張は計算の容量を調整しない。RDS Proxy は接続の管理で、容量を変えない。
参考リンク
3.4高性能でスケーラブルなネットワークを決める
3.4 Determine high-performing and/or scalable network architectures.
概念
CloudFront はエッジでのキャッシュで静的・動的なコンテンツの配信を速くし、Global Accelerator は固定の Anycast IP と AWS のネットワークで TCP/UDP の通信を速くします。多数の VPC の接続は Transit Gateway（ハブ）、少数なら VPC ピアリング、オンプレミスとの大容量で安定した接続は Direct Connect です。ロードバランサーは HTTP は ALB、超低遅延・固定 IP・TCP/UDP は NLB を使います。
仕組み・手順
- 利用者の場所と通信の種類（HTTP・TCP・UDP）を確認する
- Web のコンテンツは CloudFront でキャッシュする
- 非 HTTP や固定 IP が必要なグローバルなアプリは Global Accelerator を使う
- 多数の VPC やオンプレミスとの接続は Transit Gateway に集約する
- ロードバランサーを ALB・NLB から選ぶ
業務での例
世界中のプレイヤーが UDP で接続するゲームのサーバーに Global Accelerator を使い、100 個の VPC は Transit Gateway で接続する。
紛らわしい点・試験の注意
- VPC ピアリングは推移的にルーティングしない（A-B、B-C があっても A-C は通らない）
- CloudFront はキャッシュ、Global Accelerator はキャッシュしない
- パスベースのルーティングは ALB、固定 IP は NLB
ミニクイズ
Q1. S3 の1つのプレフィックスへのリクエストが非常に多く、性能の上限に近づいている。設計の改善として最も適切なものはどれか。
- バケットを S3 Express One Zone に移し、同じプレフィックスのまま使う
- CloudFront を前に置き、書き込みのリクエストもキャッシュさせる
- S3 Transfer Acceleration を有効にする
- オブジェクトのキーを複数のプレフィックスに分散し、並列にリクエストする
答えと解説を見る
正解：D オブジェクトのキーを複数のプレフィックスに分散し、並列にリクエストする
S3 はプレフィックスごとに高いリクエストレートを処理できる。プレフィックスを分けて並列化すると全体の処理能力を高められる。 【他の選択肢】Transfer Acceleration は遠隔地からの転送を速くするもので、プレフィックスの上限は変わらない。Express One Zone はディレクトリバケットで、設計の見直しが要る。CloudFront は書き込みをキャッシュしない。
Q2. 本社と東京リージョンの間で、大量のデータを毎日安定した帯域で転送したい。インターネットの混雑の影響を受けたくない。最も適切なものはどれか。
- S3 Transfer Acceleration
- Amazon CloudFront
- AWS Direct Connect
- AWS Site-to-Site VPN（インターネット経由）
答えと解説を見る
正解：C AWS Direct Connect
Direct Connect は専用線で、インターネットより安定した帯域と遅延を得られる。VPN はインターネット経由のため変動しやすい。
参考リンク
3.5高性能なデータの取り込みと変換を決める
3.5 Determine high-performing data ingestion and transformation solutions.
概念
ストリーミングの取り込みは Kinesis Data Streams（リアルタイムの独自処理、シャードで拡張）か Amazon Data Firehose（S3・Redshift・OpenSearch へのほぼリアルタイムの配信、変換付き、運用不要）、Kafka なら Amazon MSK。バッチの変換は AWS Glue（サーバーレスの ETL・データカタログ）、大規模な処理は EMR、S3 のデータの分析は Athena、データレイクの権限は Lake Formation です。転送には DataSync や Snowball を使います。
仕組み・手順
- データの量・速度・遅延の要件（リアルタイムか、数分か、日次か）を確認する
- ミリ秒〜秒の独自処理は Kinesis Data Streams、S3 への配信なら Firehose
- Glue でカタログを作り、Parquet などの列指向形式に変換する
- Athena で S3 を検索し、パーティションで読み込む量を減らす
- オンプレミスからの継続的な転送は DataSync
業務での例
IoT センサーのデータを Firehose で 1 分ごとに S3 に Parquet で配信し、Glue のカタログを使って Athena で分析する。
紛らわしい点・試験の注意
- Firehose はバッファリングするのでミリ秒のリアルタイム処理には向かない
- 列指向形式（Parquet・ORC）と圧縮で Athena のコストと時間が下がる
- Kinesis Data Streams はシャード数で容量を決める（オンデマンドモードもある）
ミニクイズ
Q1. Kinesis Data Streams の処理が追いつかず、データの取り込みでスロットリングが発生している。最も適切な対策はどれか。
- データの保持期間を短くする
- プロデューサーの数を減らして、送信を止める
- ストリームを削除して、すべてのプロデューサーから S3 に直接書き込ませる
- シャード数を増やす（またはオンデマンドモードを使う）
答えと解説を見る
正解：D シャード数を増やす（またはオンデマンドモードを使う）
プロビジョンドモードではシャード数で処理能力が決まる。シャードを増やすか、オンデマンドモードで自動的に容量を調整する。
Q2. 分析基盤の部品を比べている。Amazon Athena の説明として誤っているものはどれか。
- データを専用のストレージに読み込まないとクエリできない
- クエリでスキャンしたデータ量に応じて課金される
- S3 のデータに標準 SQL でクエリできる
- サーバーの管理が不要である
答えと解説を見る
正解：A データを専用のストレージに読み込まないとクエリできない
Athena は S3 上のデータに直接クエリする。列指向形式（Parquet など）や圧縮・パーティション分割で、スキャン量を減らせる。
参考リンク
レッスンは当サイトがAWS 認定の公式ページと公式試験ガイドをもとに独自に作成したもので、試験の内容を保証するものではありません。製品の仕様は変わることがあるため、参考リンク先の最新情報を確認してください。
ご利用上の注意（非公式・独自問題・合格保証なし）
- 本サイトの問題は、公式に公開されているスキル概要・試験ガイドをもとに当サイトが独自に作成した練習問題であり、実際の試験問題ではありません。
- Amazon Web Services、AWS、および関連するマークは、米国その他の国における Amazon.com, Inc. またはその関連会社の商標です。本サイトは AWS（Amazon Web Services）と提携しておらず、AWS による承認・推奨を受けたものではありません。
- 本コンテンツは学習の補助であり、合格を保証するものではありません。試験の内容・形式・前提条件は予告なく変更されます。受験前に必ず公式ページで最新情報を確認してください。
- 本模擬試験の正答率は、公式試験の換算（スケール）スコア（合格 720）とは換算できず、合否を予測するものではありません。
- 未ログイン時の進捗はこのブラウザ内（localStorage）に保存します。Google でログインすると学習記録をアカウントに同期します。端末内の記録とサーバー上の記録は別に削除します。詳しくは保存・同期の説明とCookie・保存設定をご確認ください。