AWS Solutions Architect — 高性能アーキテクチャの設計：練習問題75問

Step 1: 要件と制約の整理 — 問題はグローバルユーザーによるキャッシュミスがオリジン（EC2）での CPU スパイクを引き起こし、オリジンがボトルネックになっている点。目標は低レイテンシとオリジン保護、かつコスト効率良く解決すること。

Step 2: 各オプションの効果を評価 — Auto Scaling によるインスタンス増加は一時的な緩和にはなるが、グローバルユーザーが多数のエッジから同時にキャッシュミスを起こすとオリジンの負荷軽減効果は限定的で、スケールアウトやスケールインの反応遅延、追加コストが発生する。ElastiCache はアプリケーションレイヤでの高速キャッシュを提供するが、グローバルに分散されたエッジからのアクセス遅延を解決するにはリージョンごとにキャッシュを配置する必要があり、設置・同期コストやアプリ改修が発生する。API Gateway によるスロットリングはオリジン保護にはなるが、ユーザーへの低レイテンシ提供やキャッシュによるトラフィック削減という観点では不十分で、API Gateway のコストが高くなる可能性もある。CloudFront はエッジキャッシュとしてグローバルに分散し、静的・動的コンテンツのキャッシュと適切なキャッシュ制御（キャッシュキー、TTL）の設定によりオリジンへのリクエストを大幅に削減できる。

Step 3: 実装方針と運用 — CloudFront を導入し、キャッシュヒット率向上のために適切なキャッシュキーの設計（クエリ文字列・ヘッダの選別）、Cache-Control ヘッダの調整、必要に応じて Lambda@Edge による動的なレスポンス加工を行う。オリジン保護として、CloudFront のオリジンフェイルオーバーや WAF、オリジングループの設定も検討する。Trap: よくある誤解は「オリジンのスケールアウトだけで解決できる」「ElastiCache を置けばグローバル問題は解決する」という点。Auto Scaling は根本解決にならないことが多く、ElastiCache はリージョン境界を越えた遅延削減には使いにくい。なぜ他の選択肢が不正解か：EC2 の Auto Scaling を増やす選択は短期的にはオリジンの処理容量を増やしてスパイクを吸収するが、グローバルなキャッシュミス発生時には多数のリージョンから同時に流入し続けるためスケールの限界やコスト増が著しい。ElastiCache をオリジン前に置く設計はアプリケーションの改修（読み書きロジックの変更）やデータ一貫性管理が必要で、グローバルエッジからの遅延を解決するには各リージョンに配置する必要があり運用コストが増える。API Gateway に切り替えてスロットリングで保護するのはオリジンの保護には寄与するが、キャッシュでの遅延削減やユーザー体験改善という点で CloudFront に劣る。総括として、CloudFront はグローバルなエッジキャッシュを提供し、オリジンへのリクエストを減らして CPU スパイクを抑える最もコスト効果が高い第一候補であり、必要に応じて ElastiCache と組み合わせるハイブリッド戦略も検討できる。

Step 1: 静的ファイルの配信は原則として CDN（CloudFront）に任せるべきです。S3 をオリジンにして CloudFront を使えば、世界中のエッジロケーションでファイルをキャッシュでき、ユーザーに近い場所から高速に配信されます。Cache-Control ヘッダを適切に設定して長めの TTL とし、バージョニングされたオブジェクトで更新時のみキャッシュを無効化する設計にすれば、オリジンへの不必要なアクセスを劇的に削減できます。セキュリティ面では Origin Access Control（旧OAI）で S3 への直接アクセスを制限し、HTTPS/TLS を強制します。

Step 2: Origin Shield は CloudFront エッジの前段で“シングルポイント”として機能し、複数エッジロケーションからのオリジンリクエストを集約・キャッシュヒットを増やすことでオリジンへの egress と負荷を下げます。大量ダウンロード時のコストやオリジンのスパイク保護に寄与します。

Step 3: 効率の良い設計は S3 のライフサイクル・キャッシュポリシー・バージョニングと CloudFront のキャッシュポリシーを組み合わせ、必要に応じてリアルタイム計測でキャッシュヒット率を改善します。Trap: S3 Transfer Acceleration は主にアップロード（ユーザ→S3）の高速化を目的として設計されており、ダウンロードでの恩恵は限定的でコストがかさむことがある点に注意が必要です。なぜ各誤答が失敗するか: 選択肢2（S3 Transfer Acceleration）はダウンロード高速化の主目的には合致しない上、GB 当たりの追加料金が発生するためコスト効率が悪い場合があります。選択肢3（各リージョンに EC2 で配布）は運用・同期・コストの面で非効率で、可用性やセキュリティパッチ、帯域管理が複雑化します。選択肢1 と 4 の組み合わせは、エッジキャッシュでパフォーマンスを最大化し、Origin Shield でオリジン負荷と egress コストを抑えるという観点から、エンタープライズの大規模静的配信に最も現実的で費用対効果の高いアプローチです。

Step 1: 要件把握と目標 - 問題は「読み取りが圧倒的に多く、グローバルなユーザーに対してレイテンシを最小化したい」こと。重要なのは読み取りレイテンシ（ユーザー体感）と可用性、運用負荷、コストのバランスである。

Step 2: 提案される改善施策とそのAWS的妥当性 - 各リージョンにDAXを導入する（選択肢1）: DAXはDynamoDBのためのインメモリキャッシュで、読み取りレイテンシをミリ秒→マイクロ秒オーダーに削減できる。アプリケーションからDAXクラスターに接続するだけで整合性モデル（読み取り整合性は注意）を扱えるため、実装の負荷は比較的低い。 - Global Tables を使ってデータをユーザーに近いリージョンへ複製する（選択肢2）: Global Tablesはマルチマスターなリージョンサイドでの書き込み/読み取りを可能にし、ユーザーに近いリージョンからローカルに読み取ることでクロスリージョンネットワーク遅延を削減できる。読み取りトラフィックを各地域のリージョンに分散できるため、全体のレイテンシと可用性が向上する。 - これらを組み合わせて、各リージョンにGlobal Tablesによる複製＋そのリージョン内でDAXキャッシュを置く構成が、グローバル読み取りの遅延最小化と高可用性を両立する。

Step 3: 実装時の注意点とトレードオフ - DAXはキャッシュ整合性に制約（強整合読取りには向かない）やキャッシュのウォームアップがあるため、キャッシュミス時の挙動を設計する必要がある。 - Global Tablesはクロスリージョンの複製遅延と増分コスト（書き込みの複製やリージョンごとの課金）を伴う。アプリ設計で競合解決やマルチマスタの設計を考慮する必要がある。 - 運用負荷はGlobal Tables＋DAXで増えるが、ユーザー体感遅延と可用性改善のメリットが大きい。 Trap: よくある誤解 - 「オンデマンドにすれば遅延が小さくなる」は誤り。オンデマンドはスループットの運用面を簡素化するが、読み取りレイテンシそのものを改善する手段ではない。 - 「ElastiCacheを前段に置けば同等」も一見正しく見えるが、DAXはDynamoDB向けに最適化されており、キャッシュコヒーレンシや整合性モデル、開発の簡便さで優位。ElastiCacheはアプリ側でキャッシュ整合性を実装する必要があり、運用負荷が高くなる恐れがある。 Why each wrong answer fails (各選択肢の検討) 1) 各リージョンにDAXを導入して読み取りキャッシュを利用する — 正解。DAXはDynamoDB用のインメモリキャッシュで読み取りレイテンシを大幅に下げる。リージョンごとに設置すればローカルアクセスの高速化が可能。 2) Global Tables を使ってデータをユーザーに近いリージョンへ複製する — 正解。クロスリージョン遅延を避けてローカル読み取りを提供でき、可用性も向上する。 3) On-Demand キャパシティモードへ切り替えて自動的にスケールするようにする — 不正解。オンデマンドはスループットのスケーリング（運用の簡素化）を助けるが、個々の読み取りレイテンシ（ネットワークやディスクアクセス）を必ずしも低減しない。グローバルなレイテンシ問題の直接解決にはならない。 4) アプリケーションレイヤに ElastiCache Redis を置いてDynamoDBへの読み取りをオフロードする — 不正解（部分的に有効だが推奨度は低い）。ElastiCacheは強力な汎用キャッシュだが、DynamoDB向けに最適化されたDAXに比べると整合性維持やキャッシュヒット率管理・コールドスタートハンドリングなど、追加の実装・運用負荷が発生する。グローバル展開では各リージョンにキャッシュを設置し、整合性と同期を考慮する必要があり、Global Tables＋DAXの組合せの方が運用面で一貫性がある。 まとめ：グローバルな読み取りレイテンシの最小化には「リージョンローカルでのキャッシュ（DAX）」と「リージョンローカルで読み取れるデータ配置（Global Tables）」を組み合わせるのが有効で、オンデマンド化や汎用キャッシュだけでは目的を完全には達成しない。

Step 1: 要件分析 — シングルスレッド性能と安定したCPUクロックが重要で、ネットワークはそれほど重要でない。コスト効率も考慮する必要がある。これらは汎用タイプよりコンピューティング最適化インスタンスが向いており、最新世代は同世代の前インスタンスに比べて IPC（Instructions per cycle）とクロック効率が改善されている。

Step 2: インスタンスタイプ比較と選定理由 — C6i は Intel Xeon の最新世代（例: Xeon Scalable）をベースにしており、シングルスレッド性能が高く、バーストや共有CPUの影響を受けにくい専有vCPUリソースを提供する。C6iはC5世代と比較してアーキテクチャが改善されており、同コスト帯でより高い計算性能を発揮することが多い。ネットワーク最適化や大容量メモリが必要ないケースでは、よりコスト効率の良いC6iが最適選択となる。

Step 3: 実装上の注意点と運用トレードオフ — シングルスレッド性能を最大化するためにCPUオーバープロビジョニングを避け、適切なvCPU数とインスタンスサイズを選ぶ。CPUフレームワーク（例えばCPUパフォーマンスガバナー）やNUMA配置、JVMチューニング（Javaの場合）など、アプリケーションレイヤでの最適化も併せて行う。最新世代を利用することでコスト/性能比が良いが、アプリケーションが特殊な命令セット（AVX-512等）に依存している場合は世代間の互換性を確認すること。 Trap: よくある誤解は「C5n を選べば常に最速になる」という点。C5nはネットワーク性能が強化されており、RDMAや高スループットが必要な分散処理やネットワーク集約ワークロードには有利だが、シングルスレッド性能でC6iより有利とは限らない。また、T3 はバースト型であり、継続的な高負荷ではベースラインを超えたパフォーマンスを継続できない。 Why each wrong answer fails: - 選択肢1（T3）：T3 はバースト型でコスト効率は良いが、ベースラインを超えて長時間高負荷をかけるとパフォーマンスが制限される場合がある。安定した高いシングルスレッド性能を保証しないため要件に合わない。 - 選択肢2（M5）：M5 はバランス型で汎用性が高いが、同コスト帯でのシングルスレッド性能（特に最新世代最適化）ではC6iなどのコンピューティング最適化インスタンスに劣る可能性がある。計算集約でシングルスレッドが重要なら専用のコンピューティング最適化がより良い。 - 選択肢3（C5n）：C5nはネットワーク最適化が特徴で、分散処理やネットワークI/Oがボトルネックのワークロードには優れるが、ここではネットワーク要件は低く、シングルスレッド性能とコスト効率が最重点であるためオーバースペックになりがちでコスト効率が落ちる。 総括：シングルスレッド性能重視かつコスト効率を確保したい場合、最新世代のコンピューティング最適化インスタンス（C6i）が最も適しており、実運用ではアプリケーションチューニングとインスタンスサイズの吟味を行うことが重要である。

Step 1: 要件評価 — グローバル配信、静的アセットは既に S3、動的APIは ALB/EC2。目的は遅延低減とオリジン負荷軽減。CloudFront はエッジキャッシュで世界中のユーザーに低レイテンシを提供でき、ビヘイビアごとの挙動設定で静的と動的を分離できる。

Step 2: 技術的な選択肢の比較 — CloudFront を用いると静的は長めの TTL、動的は短めまたは Cache-Control に従う設定が可能。Lambda@Edge による加工やキャッシュキーの変更（ヘッダ、クッキー、クエリ文字列の制御）も行える。S3 の静的ウェブホスティングだけではグローバルなエッジキャッシュ効果が弱く、ALB への負荷軽減や動的APIのキャッシュ制御には不十分。ElastiCache をアプリ側で導入するとオリジン内での高速キャッシュは可能だが、グローバルなユーザーの遅延改善や CDN によるトラフィック削減効果は限定的で、アプリ改修が必要になる。ALB 自体にレスポンスキャッシュ機能はなく、ALB のリスナーで TTL を設定することはできない（誤り）。

Step 3: 運用とコスト考慮 — CloudFront の導入は設定の複雑さ（キャッシュキー、ビヘイビア、オリジン設定）を伴うが、一度設定すればグローバル配信でのレイテンシ改善とオリジン負荷削減の効果が大きい。キャッシュの無効化（Invalidation）やキャッシュヒット率の監視を導入し、動的コンテンツについてはキャッシュ制御ヘッダを適切に設計する。Trap: よくある誤解は「S3に置けばCDNは不要」「ALBでキャッシュできる」といった理解。S3の静的ウェブホスティングだけではエッジキャッシュの利点を活かせず、ALB にはキャッシュ機能がない。なぜ他の選択肢が不正解か：S3 の静的ウェブホスティングのみでは静的配信は可能だが、CloudFront のエッジキャッシュによるグローバルな遅延低減やオリジン負荷軽減が得られない。またクライアント側キャッシュのみに頼るとキャッシュヒットが不安定でコントロールが難しい。ElastiCache を API の前に置く設計はアプリケーションレイヤでのキャッシュ戦略として有効だが、グローバルなユーザーのレイテンシ低減や CDN による配信最適化の代替にはならず、アプリ側の改修とキャッシュ一貫性の管理が必要になる。ALB にキャッシュ機能を期待する選択肢は誤りで、ALB はロードバランシングと一部のリダイレクトやヘッダー操作は可能だがレスポンスのキャッシュやTTL設定機能は提供していない。追加アドバイスとして、動的APIを CloudFront でキャッシュする場合はキャッシュキーに注意し、認証トークンやユーザー固有のヘッダは除外してパブリック／プライベートの区別を明確にし、キャッシュ不整合時のオリジンフェイルオーバーやキャッシュバスティング方針を作ること。

Step 1: 要件整理 — 大規模データセット（数百 TB）を多数のコアが並列で読み込み、POSIX 準拠のファイルシステムが必要であること。また読み取りスループット（帯域）と低レイテンシが重要で、処理性能がストレージに依存する典型的な HPC/科学計算ワークロードです。

Step 2: AWS の選択肢評価 — Amazon S3 は耐久性とコスト面で優れますが、オブジェクトストレージであり POSIX インタフェースではないため、ランダムアクセスや POSIX アプリの互換性で制限を受けます。EBS st1 は順次スループットは良いがノードローカルで共有しにくく、HDFS のようなレイヤを組むと運用が複雑になります。EFS は POSIX 準拠ですが、非常に高い並列スループットが必要な場合にコストや性能面で最良とは限りません。FSx for Lustre は低レイテンシな POSIX 準拠の分散ファイルシステムで、S3 Data Repository Integration によって S3 上のデータをネイティブにマウントし、高速処理用にキャッシュ／インポートできるため、HPC ワークロードに適合します。

Step 3: 実行と運用上の判断 — FSx for Lustre を S3 と統合してジョブ前に必要データを読み込み（またはオンデマンドにストリーミング）、処理中は高スループットでアクセス、処理後に結果を S3 にエクスポートするパターンが推奨されます。FSx は並列 I/O と高帯域を提供し、並列コア数の増加に対してスケールする設計を立てられます。Trap: 試験で間違いやすいのは「S3 はスケールするからそのまま使えばよい」と考えることです。S3 は並列読み出しで非常に高いスループットを出せますが、POSIX インタフェースを期待するアプリやランダムアクセスが多いワークロードには直接は向きません。Why each wrong answer fails: 選択肢 1（S3 直接）はデータレイク用途には素晴らしいが、POSIX ファイルシステムを期待する既存 HPC アプリケーションに対する互換性と低レイテンシ読み出しの要件を満たすことが難しい。S3 にはレイテンシがあり、オブジェクト API を使うためアプリ改修が必要になる。選択肢 2（EBS st1 を HDFS 的に構成）は順次スループットは得られるが、ノード停止やスケールアウト時のデータ再配置、運用負荷、スループットの総合的な管理（複数ノードからの同時高並列読み取り）で複雑さと耐久リスクが増す。選択肢 3（EFS）は POSIX 準拠だが、超大規模の並列読み込みで必要な帯域・パフォーマンスを最小コストで実現する点で FSx for Lustre に劣ることがある。EFS は高スループットモードもあるが、HPC 向けの最適化や S3 統合の面で FSx が有利です。総括: POSIX 準拠かつ大幅な並列スループットを求める HPC ワークロードでは FSx for Lustre と S3 統合が最も適切な選択です。

Step 1: 要件分析では「複雑なデータ構造と原子的操作」「ミリ秒レイテンシ」「可用性優先」が重要です。Redisはハッシュ、リスト、セットなどのデータ構造とINCR、MULTI/EXECなどのトランザクション的操作をネイティブにサポートします。ElastiCache for Redisはマネージドで、レプリカや自動フェイルオーバー、クラスタモードによるスケーリングが可能です。

Step 2: 可用性と耐障害性を満たすためにCluster Mode enabledを採用し、各シャードに対して複数のレプリカを配置、Multi-AZ配置を行います。AOF（Append Only File）やスナップショットを組み合わせることで、再起動や障害後のデータ復元を短時間で行えるようになります。読み取りはレプリカで分散し、書き込みはプライマリで処理することでミリ秒レイテンシを維持できます。

Step 3: コストを抑えつつ可用性を確保するには、インスタンスタイプを適切に選び（メモリ最適化・ネットワーク性能重視）、レプリカ数とシャード数をワークロードに合わせて調整します。運用面では自動バックアップ、監視（CloudWatch）、パラメータグループでの最適化を行い、必要に応じて読み取り/書き込み分離やTTLでメモリ圧迫をコントロールします。 Trap: よくある誤解は「Memcachedはシンプルなので可用性とスケーリングが容易」という点です。Memcachedは水平シャーディングに優れますが、永続化や自動フェイルオーバー、複雑データ型はサポートしておらず、セッションの完全性や原子的操作が必要なケースには不適です。 Why the wrong answers fail: - ElastiCache for Memcached: Memcachedは永続化がなく、クラスタのノード障害時にデータが失われます。また原子的な複雑データ操作をサポートしていないため、要件に合いません。可用性を高めるために多くのレプリケーションやアプリ側の再構成ロジックが必要で運用負荷が増えます。 - DynamoDB + DAX: DynamoDBは可用性とスケーラビリティに優れ、DAXはキャッシュでレイテンシを下げますが、DynamoDBは基本的にキー/属性ストアでRedisのようなリッチなデータ構造や一部の原子的コマンドを直接は提供しません。トランザクションはありますが、Redisで可能な高速な集合演算やリスト操作を同等の低レイテンシで行うのは困難です。また、設計によってはコストが高くなることがあります。 - RDS（MySQL）: RDSは永続化とACIDを提供しますが、ディスクベースのためミリ秒（特にサブミリ秒）レスポンスが求められるセッションストアには一般的に遅く、スループットとレイテンシの面で不利です。またスケーリングは水平化が難しく、コストと運用面でRedisほど効率的ではありません。 結論として、要件（複雑データ構造、原子的操作、低レイテンシ、可用性）に最も合致するのはElastiCache for Redis（クラスタモード＋Multi-AZレプリカ）です。

Step 1: 要件整理 — オンプレミスのデータベースを残し、グローバルな読み取り負荷を軽減したい。最小限のアプリ変更で実装したいこと、セッションや厳密な強整合性は不要で多少の遅延は許容できる点が重要。

Step 2: ソリューション評価 — CloudFront は HTTP レスポンスのキャッシュに優れるが、データベースクエリの結果（構造化データ）を直接キャッシュする用途には適していない。DAX は DynamoDB 向けのインメモリキャッシュであり、オンプレミス DB には適用できない。ALB レイヤで Memcached を置くことは実際の構成として提供されておらず（ALB はリクエストの転送を行うがキャッシュサーバを挟む機能を意味する選択肢は誤解を含む）、また Memcached は管理上の注意点が多い。ElastiCache Redis ならば既存アプリに最小限の変更（読み取り時にまず Redis を参照し、ミスならオンプレへフェッチして書き戻す）で read-through キャッシュを実装でき、クラスターモードでスケールアウト、レプリカで耐障害性も確保できる。

Step 3: 運用上の検討 — ElastiCache Redis を導入する際はキャッシュの有効期限、キャッシュキー設計、キャッシュの一貫性戦略（書き込み時にインバリデーションを行うか TTL を短めにするか）を決める。グローバルアクセスが必要なら、リージョンごとにリードレプリカやキャッシュレイヤを設置してレイテンシを低減するか、アプリをリードレプリカのあるリージョンに配備してフェイルオーバー設計を行う。Trap: よくある誤解は「CloudFront はあらゆる読み取りキャッシュに使える」という考え。CloudFront は HTTP レスポンスの CDN であり、データベースクエリの結果を直接かつ安全にキャッシュする用途には適さない（特に動的でパーソナライズされたクエリ）。なぜ他の選択肢が不正解か：CloudFront は静的・一部動的コンテンツの配信に最適だが、オンプレ DB のクエリ結果を直接キャッシュするためにはアプリ側で HTTP API 化して CloudFront のキャッシュポリシーを細かく管理する必要があり、最小限の変更という要件を破る可能性がある。DAX は DynamoDB 専用のキャッシュでありオンプレDBには適用できない。ALB の前に Memcached を置くという選択は実務上の一般的パターンではなく、ALB は単なるロードバランサーでキャッシュの代替にはならないし、Memcached を運用する場合はセッションの分散や故障時の影響、スケーリングの問題を自前で管理する必要があり、ElastiCache Redis のマネージド運用メリットに劣る。補足として、グローバルな読み取りレイテンシをさらに低減したい場合は、リージョンごとにキャッシュクラスターを配置してデータ同期方針（非同期更新、TTLでの整合性緩和）を採ることで、オンプレDB への恒常的なトラフィックを抑制できる。

Step 1: 要件整理 — 必要なのは「大容量メモリ」「高スループット」「コスト効率」「可用性」。Redisはメモリ容量とネットワークIO、単一ノードあたりのメモリレイテンシが重要である。

Step 2: インスタンス特性の評価 — Rシリーズはメモリ最適化であり、R6gはGraviton（Arm）ベースの世代で、同等世代のx86インスタンスに比べて価格性能比が優れるケースが多い。Redisのような単一プロセスが多くのメモリを使うアプリケーションでは、より多くのメモリ/ドルを提供するR6gはコスト効率が高い。R6g導入にはRedisバイナリや依存ライブラリのArm対応確認が必要だが、互換性が確認できれば運用コストが下がる。高可用性はクラスタ設計（マスター/レプリカ、フェイルオーバー、スナップショットやAOFの永続化、Multi-AZ配置）で確保する。

Step 3: 実装上の考慮点 — Arm対応のRedisビルドを利用し、パフォーマンステストでレイテンシとスループットを検証。ネットワーク性能（ENI設定やEnhanced Networking）を確保し、必要に応じてインスタンスサイズを調整。バックアップとリカバリ戦略、監視（CloudWatch）とアラートを構築する。Trap: よくある誤解は「Gravitonは常に速くて安いから何でも置き換えればよい」という点。実際にはバイナリ互換性や特定のネイティブ拡張（モジュール等）の対応、ベンチマークの違いを確認する必要がある。Why each wrong answer fails: R5はx86ベースで互換性面では一切問題ないが、最新世代のR6gに比べて同じ金額で提供されるメモリ量やスループット効率が劣る（コスト効率が下がる）。C6gはコンピュート最適化でメモリ容量が少なく、Redisの大容量メモリ要件には向かない。M6gは汎用でバランスは良いが、メモリ最適化のR系列ほどメモリ密度/性能は高くないため、同一コストでより大きなメモリが必要なキャッシュ用途では不利である。以上を踏まえ、Arm互換性が確認できる場合はR6gを選択することでコストと性能の最適化が可能となる。

Step 1: 要件把握 - ワークロードは大容量（TB〜PB）、並列処理（多数のノードが同時にI/Oする）、シーケンシャルアクセスが主体。求めるのは高スループットとコスト効率、そしてEMRなどの分散処理フレームワークとの相性である。

Step 2: 候補技術の評価 - Amazon S3 をデータレイクとして使う（選択肢1）: S3はオブジェクトストレージでコスト効率が非常に高く、EMRやAWS GlueなどはS3から直接並列にデータを読み書きする設計になっている。多数のパーティション（prefix）でオブジェクトを分散しておけば、非常に高い総帯域（スループット）を得られる。耐久性・スケーラビリティの面でも優れている。 - Amazon FSx for Lustre をS3と連携させる（選択肢3）: FSx for LustreはHPC向けのPOSIXファイルシステムで、低レイテンシかつ高スループットで並列アクセスに優れる。S3と連携してデータをインポート/エクスポートできるため、S3に配置したデータを高速にアクセスする際のキャッシュ層／ワークスペースとして非常に有効。

Step 3: 実運用の設計とトレードオフ - 実務ではS3を“原本”のデータレイクに置き、ジョブ実行時にFSx for Lustreを一時ファイルシステムとしてマウントして高速I/Oを実現し、処理完了後に結果をS3へ戻すというパターンが多い。これによりコスト効率（S3）とパフォーマンス（FSx）を両立できる。 - EBS gp3を各ノードで使う方法は高性能だが、ノード数が多い並列クラスターでは容量・管理・コストの観点でスケールが難しい。EFSは共有ファイルシステムだが、スループットとレイテンシ特性がFSx for Lustreほど並列HPC向けではないため、EMRの大規模並列I/Oには最適でないことがある。 Trap: よくある誤解 - 「EBSをノードに割り当ててストライピングすれば大きなスループットが得られる」は一見有効だが、ノード障害時のデータ保全や管理負荷、コスト回帰が発生する。S3+FSxの組合せのほうが運用上の柔軟性が高い。 Why each wrong answer fails (各選択肢の評価) 1) Amazon S3 をデータレイクにして、EMRの分散I/Oでパーティション並列読み取りを行う — 正解。S3は大容量データの保存コストが低く、EMRなどでの並列読み取りに最適化されている。高い耐久性とスケーラビリティを備え、設計次第で非常に高い総スループットを発揮する。 2) EBS gp3 ボリュームを各ノードのローカルにストライピングして分散処理のストレージとする — 不正解（限定的に有効）。gp3は単一EC2インスタンスでの低レイテンシ高IOPSを提供するが、TB〜PB規模のデータを多数ノードで扱う場合、データの一元管理・耐久性・コスト効率で劣る。クラスタ全体での管理やノード障害時のリカバリが問題となる。 3) Amazon FSx for Lustre をS3と連携させ、POSIXインタフェースで高スループットアクセスを提供する — 正解。FSx for Lustreは並列処理向けに最適化されたファイルシステムで、S3と連携することでデータレイクとの組合せで高スループットを実現できる。 4) Amazon EFS Standard を使って全ノードで共有ファイルシステムを用いる — 不正解（ユースケース依存）。EFSは共有ファイルシステムとして便利だが、最大スループットやレイテンシの観点でFSx for Lustreほど並列HPCワークロードに最適化されていない。大量の小ファイルや非常に高いスループットを必要とするバッチ処理では性能上のボトルネックになる可能性がある。 まとめ：大規模並列バッチワークロードではS3をコスト効率の良いデータレイクに置き、必要に応じてFSx for Lustreを一時的に利用して低レイテンシ・高スループットを確保するのが現実的かつスケーラブルなアプローチである。

Step 1: 要件整理 — 読み取りリクエストが非常に多く、応答時間改善と DB オリジンへの負荷軽減が目的。アクセスパターンが多くのクライアントによる同じクエリやセッション・データ読み取りを含む場合、キャッシュによるスピードアップのメリットが大きい。

Step 2: 選択肢の技術的評価 — ElastiCache（Redis）はインメモリキャッシュとして非常に低レイテンシでスループットが高く、頻繁にアクセスされるデータや計算結果をキャッシュすることで RDS への読み取りを大幅に減らせます。キャッシュ失効（TTL）、一貫性モデル（読み取り整合性）、キャッシュ・ワーム対策など戦略を設計する必要があります。RDS Read Replica は読み取りのスケールアウトに寄与するが、レイテンシはディスク/ネットワーク経由であり、同一クエリを大量に受ける場合はリードレプリカ間でキャッシュ効果ほどの速度向上は得られないことがあります。スケールアップは瞬間的な処理能力を増やすが一時的かつコスト効率が悪く、根本的には繰り返し同じデータを読み続ける問題は解決しない。S3 へ移行は静的データに限る方法であり、動的な DB クエリやトランザクション性が必要なデータには適さない。

Step 3: 実装と運用上の考慮 — ElastiCache for Redis を導入する場合はクラスターモードの採用、マルチAZ の耐障害性、フェイルオーバー、メモリのプロビジョニング（データサイズ+余裕）、Eviction ポリシー、TTL 設計を検討します。キャッシュミス時の負荷増に備え、サーキットブレーカーやバックプレッシャーを実装します。またセキュリティは VPC 内に配置しサブネットグループやセキュリティグループでアクセス制御します。Trap: 試験でよくある誤解は「Read Replica を作ればすべて解決」というもの。Read Replica は確かに読み取りスケールに寄与するが、同一クエリの高頻度アクセスに対するレイテンシ改善や DB の I/O 削減という観点ではインメモリキャッシュほど効果的でないことがあります。Why each wrong answer fails: RDS Read Replica（選択肢2） — 読み取り分散は可能だが、レプリカ間でのキャッシュ効果はないため同一クエリが大量に来るケースでは RDS 側の I/O 負荷が依然高く、応答時間改善の効果は限定的。垂直スケーリング（選択肢3） — インスタンスサイズを上げることで一時的に処理能力は増すが、コスト効率が悪くスケールの上限がある。根本的に繰り返し同じデータを返す処理を減らさない限り恒常的な改善にならない。S3 へ移行（選択肢4） — S3 はオブジェクトストレージであり、RDS のトランザクション性やクエリ性能、動的データには適合しない。静的コンテンツには有効だが、一般的な DB 読み取り負荷軽減の汎用解とは言えない。以上より、低レイテンシで高スループット、かつ読み取り負荷を劇的に減らせる ElastiCache for Redis が最適解です。

Step 1: 要件整理 — 条件は「数TBのログ」「並列で順次読み込み」「大量のシーケンシャルスループット」「耐久性優先」「コスト抑制」。これはデータレイク／バッチ処理ワークロードの典型です。

Step 2: サービス比較と設計 — Amazon S3は11 9sの耐久性を提供するオブジェクトストアで、データ量が大きくても非常にコスト効率が良い。S3は並列GETやS3 Transfer Acceleration、マルチパートアップロード／ダウンロードを活用することで高い総スループットを確保でき、分析ジョブではEMRやAthena、フレームワークで並列読み込みを前提に設計される。加えて、S3はスケールの制約がほぼなく、耐久性と可用性が高いため長期保存とバッチ処理に最適である。

Step 3: 実装上の考慮点 — オブジェクトの大きさを適切に分割し、並列ダウンロード数やスレッド数をチューニングする。頻繁なアクセスが必要な小さなファイルが多数ある場合はファイルの統合を検討。S3の読み取りコスト（PUT/GETリクエストやデータ転送料金）を把握し、必要ならS3 Intelligent-Tieringやライフサイクルポリシーを設定する。Trap: よくある誤解は「スループット＝ローカルディスクが常に最速」というもの。確かにインスタンスストアやEBSは低レイテンシでスループット出るが、耐久性（再起動で消えるインスタンスストア）やスケール・コスト面でS3に劣る。Why each wrong answer fails: EBS st1はスループット最適化HDDで順次読み書きに向くが、EBSはボリューム当たりのスループットやインスタンスへのアタッチ制限があり、データ容量と耐久性の面でS3ほど適切ではない（またコストはケースにより変わる）。EFS（汎用SSD）はファイル共有ニーズには向くが、大量のシーケンシャルバッチ読み込みを最もコスト効率良くスケールさせるにはS3の方が有利。インスタンスストアはI/O性能は良いが耐久性がなく、インスタンス障害や停止でデータが失われるため本番での長期保存には不向き。総括すると、耐久性とコスト効率を重視し大規模なシーケンシャルスループットを出したい場合、S3と並列処理がベストプラクティスである。