AWS ソリューションアーキテクト アソシエイト 高性能な設計 問題

正解は Range ヘッダーで同じオブジェクトの別々のバイト範囲を指定し、並行して取得する方法です。S3 は GET に Range ヘッダーを付けると指定した範囲だけを返します。同じオブジェクトの別々の範囲を複数の接続で同時に取ると、1 本で丸ごと取るより合計のスループットを高められ、バケットもストレージクラスも変えずに済みます。Transfer Acceleration は、クライアントとバケットの間の長い距離による遅れを縮める機能なので、同じリージョンの EC2 からの読み込みには効かず要件に合いません。S3 Express One Zone へ移すのは、既存のバケットを変えないという要件に合いません。Intelligent-⁠Tiering はアクセスの頻度に応じて保管の費用を下げる仕組みで、ストレージクラスを変えることにもなるので要件に合いません。出典 https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-⁠performance-⁠guidelines.html

正解はブロック方式の永続ストレージの EBS です。AWS のストレージの選び方の手引きでは、ブロック方式はデータを同じ大きさのブロックに分けて速く読み書きできるように置く技術とされ、1 台の EC2 に付けて低遅延で使う耐久性のあるストレージとして、データベースなどの用途に EBS が挙げられています。EFS はファイル方式で、複数の EC2 から同時に読み書きする共有に向いたストレージなので、1 台のデータベースのディスクという用途に合いません。S3 はオブジェクト単位で API から読み書きする方式で、ブロック単位で細かく書き換えるディスクの代わりにならないので合いません。FSx for Windows File Server もファイル方式で、SMB で共有するファイルサーバーのためのものなので、ブロック単位で読み書きするディスクという用途に合いません。出典 https://docs.aws.amazon.com/decision-⁠guides/latest/storage-⁠on-⁠aws-⁠how-⁠to-⁠choose/choosing-⁠aws-⁠storage-⁠service.html

正解はインスタンスに付いたインスタンスストアのボリュームです。インスタンスストアは、ホストのコンピューターに物理的に付いたディスクで提供される一時的なブロックストレージで、バッファやキャッシュ、作業用の一時データのように頻繁に変わる情報に向いています。インスタンスを停止、休止、終了するとデータは残りませんが、作り直せる中間ファイルなら問題になりません。gp3 の EBS はネットワークでつながるボリュームなので、ネットワークを経由しないという要件に合いません。EFS はネットワーク越しの共有ファイルシステムで、同じ理由で合いません。S3 はネットワーク越しに API で読み書きするオブジェクトストレージで、ディスクの細かい読み書きの代わりにならないので合いません。出典 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html

正解はキーの先頭を分けて、書き込みを複数のプレフィックスへ分散する方法です。S3 は 1 つのプレフィックスあたり少なくとも毎秒 3,5⁠0⁠0 件の PUT、COPY、POST、DELETE と 5,5⁠0⁠0 件の GET、HEAD をさばけ、プレフィックスの数に上限はありません。キーの先頭をセンサーの区分などで分けて複数のプレフィックスへ散らせば、バケットを 1 つのまま、並列にさばける量が増えます。Transfer Acceleration は距離による遅れを縮める機能で、プレフィックスあたりの処理の量は増えないので合いません。バージョニングは古い版を残す機能で、リクエストをさばく量は変わらないので合いません。Standard-⁠IA は低頻度のアクセス向けの保管の区分で、プレフィックスあたりの処理の量は変わらないので合いません。出典 https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-⁠performance.html

正解はマルチパートアップロードで部分に分け、並列に送る方法です。マルチパートアップロードは 1 つのオブジェクトを部分に分けて送る仕組みで、部分は独立に、順不同で送れます。部分を並列に送ればスループットが上がり、ある部分の送信に失敗しても、その部分だけを送り直せば済みます。Transfer Acceleration は遠い場所からの転送の遅れを縮める機能で、同じリージョンからの送信では効き目が小さく、失敗した分だけを送り直す仕組みも持たないので合いません。バージョニングは上書き前の版を残す機能で、送信の速さにも送り直しにも関係しないので合いません。Glacier Flexible Retrieval は保管の費用を下げる区分で、送る時間は短くならないので合いません。出典 https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html

正解はスループットモードを Elastic にすることです。EFS の文書は、急増する負荷や予測できない負荷で性能の要件を見積もりにくいとき、または平均とピークの比が 5% 以下のときに、Elastic スループットを使うよう勧めています。Elastic は負荷に応じて自動でスループットが増減するので、値を前もって決める必要がありません。Provisioned は性能の要件が分かっているときに値を決めて使うモードなので、見積もらないという要件に合いません。Max I/O は前の世代のモードで、操作ごとの遅延が大きく、Elastic スループットとは組み合わせられないので合いません。One Zone はデータを 1 つの AZ に置く区分で、スループットの増え方は変わらないので合いません。出典 https://docs.aws.amazon.com/efs/latest/ug/performance.html

正解は院内に S3 File Gateway を置き、NFS で共有する構成です。S3 File Gateway は、NFS や SMB の標準のファイルのプロトコルで S3 にオブジェクトとして読み書きできるようにする仕組みで、ローカルのキャッシュによって低遅延でデータを読めます。機器は NFS の書き込み先を替えるだけで済み、ファイルは S3 に置かれるので分析に使えます。EFS をマウントする構成は、データが S3 ではなく EFS に置かれるので、S3 に置く方針に合いません。DataSync で写す構成は、今のストレージ機器を残すことになり、廃止する方針に合いません。Volume Gateway は iSCSI のブロックのボリュームとして見せる仕組みで、NFS で書き込む機器の設定を変えるだけでは使えないので合いません。出典 https://docs.aws.amazon.com/filegateway/latest/files3/what-⁠is-⁠file-⁠s3.html

正解は同じ AZ に作った S3 Express One Zone のディレクトリバケットです。S3 Express One Zone は、遅延に敏感な用途に向けて一貫した 1 桁ミリ秒のデータアクセスを出すように作られた高性能のストレージクラスで、AZ を選んでディレクトリバケットを作り、計算資源と同じ場所に置けます。データは 1 つの AZ の中だけで冗長に保存されますが、作り直せる学習データなら許容できます。CloudFront は利用者に近いエッジから配信してキャッシュする仕組みで、データは汎用バケットのまま AZ を選んで置けないので、EC2 と同じ AZ に置く要件に合いません。Standard-⁠IA は低頻度のアクセス向けの区分で、繰り返し読む学習データに向かないので合いません。One Zone-⁠IA も低頻度のアクセスの費用を下げるための区分で、一貫した 1 桁ミリ秒の遅延を目的にしていないので合いません。出典 https://docs.aws.amazon.com/AmazonS3/latest/userguide/directory-⁠bucket-⁠high-⁠performance.html

正解は関数のメモリの設定値を増やすことです。Lambda は設定したメモリの量に比例して CPU の能力を割り当てるので、メモリを増やすと CPU も増え、CPU を多く使う処理の実行時間が短くなります。メモリは 1⁠2⁠8 MB から 1⁠0,2⁠4⁠0 MB の間で設定でき、コードを変えずに済みます。タイムアウトを長くしても、途中で打ち切られにくくなるだけで実行は速くならないので合いません。予約済みの同時実行数は同時に動く数の確保と上限の設定で、1 回の実行の速さは変わらないので合いません。プロビジョニングされた同時実行は初期化済みの実行環境を用意してコールドスタートを減らす設定で、問題になっていない起動の遅れへの対策なので合いません。出典 https://docs.aws.amazon.com/lambda/latest/dg/configuration-⁠memory.html

正解はクラスタープレイスメントグループで 1 つの AZ に寄せることです。クラスタープレイスメントグループは 1 つの AZ の中のインスタンスの論理的なまとまりで、低いネットワーク遅延や高いネットワークスループットが要る用途、通信の大半がグループの中のインスタンスどうしで起きる用途に勧められています。スプレッドはインスタンスを別々のハードウェアに分けて同時の故障を避ける配置で、遅延を下げる目的ではないので合いません。パーティションは区画ごとにラックを分けて、大規模な分散処理で故障の影響を区切る配置なので、同じく合いません。複数の AZ に分ける構成は可用性は上がりますが、AZ をまたぐ通信が増え、遅延を最も低くする要件に合いません。出典 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-⁠strategies.html

正解は AWS Batch の配列ジョブで回し、まとめのジョブを依存ジョブにすることです。AWS Batch は、ジョブの量と規模に応じて計算資源を自動で用意し、ジョブの配分も受け持つフルマネージドのサービスです。配列ジョブは同じジョブ定義を共有する 2〜1⁠0,0⁠0⁠0 個の子ジョブを並列に動かす仕組みで、大量の独立した計算を回すのに最も効率のよい方法とされています。まとめのジョブを配列ジョブに依存させれば、全部が終わってから 1 回だけ動きます。Lambda は 1 回の実行が最大 9⁠0⁠0 秒 (1⁠5 分) なので、1〜3 時間の計算に合いません。EMR の Spark は分散したデータ処理の仕組みで、コンテナの計算を Spark に書き直す必要があり、クラスターの管理も残るので合いません。自作のジョブ管理は、待ち行列と実行の順番を自作で管理しない要件に合いません。出典 https://docs.aws.amazon.com/batch/latest/userguide/array_jobs.html

正解は DynamoDB のオンデマンドモードでテーブルを作ることです。DynamoDB はキーと値の読み書きに向いたサーバーレスの NoSQL のデータベースで、規模に関係なく一貫した 1 桁ミリ秒の性能を出せます。オンデマンドモードは容量の見積もりをせずに、負荷の増減に自動で応じます。RDS for MySQL で大きいインスタンスを選ぶ構成は、急増に合わせて前もってサイズを見積もる必要があり、要件に合いません。Aurora のリードレプリカは読み取りを分けるだけで、カートの書き込みの急増には効かず、台数の見積もりも要るので合いません。プロビジョニングモードで容量を固定する構成は、読み書きの容量を前もって決める必要があり、要件に合いません。出典 https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/on-⁠demand-⁠capacity-⁠mode.html

正解は Aurora レプリカを足し、集計の接続先をリーダーエンドポイントにすることです。リーダーエンドポイントは問い合わせ用の接続先で、Aurora がすべての Aurora レプリカの間で接続を自動で振り分けます。集計はレプリカで動くのでライターの負荷から切り離され、接続先も 1 つで済みます。ライターを大きくする構成は、集計がライターで動いたままなので、切り離す要件に合いません。RDS Proxy は接続をプールして使い回す仕組みで、問い合わせはライターで動いたままなので合いません。ElastiCache は同じ結果を繰り返し読む場合に効きますが、毎回条件の違う集計ではキャッシュが当たらないので合いません。出典 https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.Endpoints.html

正解は顧客 ID と注文日をキーにした GSI を作り、Query することです。グローバルセカンダリインデックス (GSI) を作ると、テーブルのキーとは別の属性をキーにして Query でき、結果はソートキーの順に並びます。顧客 ID をパーティションキー、注文日をソートキーにすれば、その顧客の注文だけを新しい順に読めて、読み取る量が減ります。元のテーブルは注文 ID のまま使えます。並列の Scan は速くはなりますが、テーブル全体を読む量は減らないので合いません。DAX で Scan の結果をキャッシュしても、キャッシュに無いときはテーブル全体を読むので、読み取る量そのものを減らす要件に合いません。元のテーブルを消す構成は、注文 ID での取り出しを続ける要件に合いません。出典 https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html

正解は DB に書くたびにキャッシュも更新するライトスルーにすることです。ライトスルーは、データベースに書き込むたびにキャッシュのデータも追加や更新する戦略で、キャッシュのデータが古くなりません。書き込みはキャッシュとデータベースの 2 回になって少し遅くなりますが、更新が 1 日に数回で遅れも許容されるので問題になりません。遅延読み込みは、キャッシュに無いときだけデータベースから読み込むため、データベースを変えてもキャッシュは更新されません。有効期限を長くすると、古い運賃が残る時間がかえって延びるので合いません。ノードを増やしても更新の仕組みは変わらないので合いません。リードレプリカから読む構成は、キャッシュから返すという要件に合いません。出典 https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Strategies.html

正解はメモリ最適化の R ファミリーです。EC2 のインスタンスの種類の文書では、メモリ最適化のインスタンスは、メモリの中で大きなデータを処理する負荷で速い性能を出すように作られていると説明されています。R ファミリーはこの区分に入り、数百 GB のデータをメモリに載せる分析に合います。コンピューティング最適化の C は、CPU を多く使う計算に向いた区分で、メモリの量が決め手のこの用途には合いません。ストレージ最適化の I は、ローカルのストレージへの大量の読み書きに向いた区分で、ディスクへの書き出しがほとんど無いこの用途には合いません。バースト可能な T は、普段は CPU 使用率が低く時々だけ上がる負荷に向き、営業時間中ずっと高い負荷で大きなデータを扱う用途には合いません。出典 https://docs.aws.amazon.com/ec2/latest/instancetypes/mo.html

正解は Transit Gateway を置き、各 VPC と VPN をつなぐ構成です。Transit Gateway は VPC とオンプレミスのネットワークを相互につなぐ中継の拠点で、各 VPC と本社への VPN を 1 か所に集められます。VPC を足すときも Transit Gateway につなぐだけで済みます。すべての組をピアリングでつなぐ構成は、VPC が増えるほど接続の数が急に増えるので、1 か所につなぐ要件に合いません。VPC ごとに VPN を張る構成は、VPC を足すたびに本社側の VPN の設定も増え、VPC どうしの通信も別に用意が要るので合いません。PrivateLink は特定のサービスを別の VPC へ公開する仕組みで、ネットワーク全体を相互につなぐ用途ではないので合いません。出典 https://docs.aws.amazon.com/vpc/latest/tgw/what-⁠is-⁠transit-⁠gateway.html

正解は ALB のリスナーにホストの条件のルールを書くことです。ALB のホストの条件は、リクエストのホストヘッダーにあるホスト名で振り分けるもので、ホストベースのルーティングと呼ばれます。1 台のロードバランサーで、複数のサブドメインや異なるドメインを扱えます。サブドメインごとに ALB を置く構成は、1 台にまとめる要件に合いません。パスの条件は URL のパスで振り分けるもので、3 つのアプリのパスが同じ形なので区別できず合いません。NLB はポートとプロトコルで振り分けるロードバランサーで、ホスト名を見て振り分けられず、同じポートに届く 3 つのサブドメインを分けられないので合いません。出典 https://docs.aws.amazon.com/elasticloadbalancing/latest/application/rule-⁠condition-⁠types.html

正解は Data Firehose のレコード形式の変換で Parquet にして S3 へ送る構成です。Amazon Data Firehose は、入ってきた JSON を Apache Parquet や Apache ORC に変換してから S3 に保存できます。Parquet と ORC は列指向の形式で、JSON のような行指向の形式より場所を取らず、クエリが速くなります。変換は Firehose の設定で行うので、サーバーも変換のコードも要りません。EC2 の自作の変換プログラムは、サーバーを持たずコードも書かない要件に合いません。SQS と Lambda で JSON のまま書き込む構成は、列指向にならず、Lambda のコードも要るので合いません。月に 1 回 EMR で変える構成は、数分以内に分析に使える要件に合いません。出典 https://docs.aws.amazon.com/firehose/latest/dev/record-⁠format-⁠conversion.html

正解は DataSync のタスクを作り、スケジュールで毎晩動かす方法です。DataSync は、NFS などのオンプレミスのストレージと、EFS や S3 などの AWS のストレージの間で、ネットワーク越しにデータを移す仕組みです。暗号化とデータの整合性の確かめを自動で行い、転送の管理と高速な転送のための基盤も DataSync が受け持つので、自作のスクリプトが要りません。rsync のスクリプトを cron で動かす方法は、自作のスクリプトをやめる要件に合いません。S3 File Gateway は S3 にファイルを置く仕組みで、写す先が EFS であることに合いません。EFS を直接マウントして書き込み先を変える構成は、アプリの書き込み先を変えないという前提に合いません。出典 https://docs.aws.amazon.com/datasync/latest/userguide/what-⁠is-⁠datasync.html

正解は year=、month=、day= の形の日付のパーティションに分けて置くことです。データをパーティションに分けると、WHERE 句でパーティションを指定したクエリはそのパーティションのデータだけを読むので、読むデータの量が減り、クエリが速くなります。Athena は year=2⁠0⁠2⁠1/month=0⁠1/day=2⁠6/ のような Hive の形のパスを扱え、時間で分けるのはよく使われるやり方です。1 つの大きなファイルにまとめても、日付で絞り込めず毎回すべてを読むので合いません。ワークグループはクエリの実行を利用者や用途ごとに分けて管理する仕組みで、1 本のクエリが読む量は減らないので合いません。Express One Zone へ移しても、クエリが読むデータの量そのものは変わらないので合いません。出典 https://docs.aws.amazon.com/athena/latest/ug/partitions.html

正解は 5 つのアプリを拡張ファンアウトのコンシューマーにすることです。拡張ファンアウトを使うコンシューマーは、シャードあたり毎秒最大 2 MB のスループットを専用で受け取り、ほかのコンシューマーと取り合いません。共有のコンシューマーは、シャードあたり合計 2 MB の読み取りを全員で分け合うため、数が増えるほど遅れが伸びます。拡張ファンアウトでは、届くまでの遅れはコンシューマーが 1 つでも 5 つでも通常は平均 7⁠0 ミリ秒ほどです。シャードを増やす対応は、シャードの数を変えない要件に合いません。Data Firehose は決まった送り先へ届ける仕組みで、5 つの独自のアプリが同じストリームを読む代わりにならないので合いません。SNS と SQS で配る構成は、送る側の仕組みを変えるので合いません。出典 https://docs.aws.amazon.com/streams/latest/dev/enhanced-⁠consumers.html

正解はその大都市の近くの Local Zone に EC2 を置くことです。Local Zones は、計算、ストレージ、データベースなどの一部の AWS の資源を、人口や産業の集まる場所の近くに置く仕組みで、利用者に低い遅延でアプリを使ってもらえます。リアルタイムのゲームやライブ配信、仮想ワークステーションのような遅延に敏感な用途が挙げられています。CloudFront でのキャッシュは、操作のたびに作られる画面には効かないので合いません。Global Accelerator は AWS のネットワークを通ってリージョンへ届ける仕組みで、計算はリージョンで行われたままなので合いません。インスタンスを大きくしても、利用者との距離による遅れは縮まらないので合いません。出典 https://docs.aws.amazon.com/local-⁠zones/latest/ug/what-⁠is-⁠aws-⁠local-⁠zones.html

正解は Glue のクローラーでカタログに登録し、ETL ジョブで変換する構成です。AWS Glue はサーバーレスのデータ統合のサービスで、管理する基盤がありません。クローラーがスキーマを自動で推定して Data Catalog に登録し、ETL ジョブは Apache Spark を使うサーバーレスの実行環境で変換を行います。カタログに登録した表は Athena からすぐに問い合わせられます。EMR のクラスターを常に動かす構成は、クラスターを管理しない要件に合いません。DataSync で写す構成は、データを移すだけで Parquet に変えないので合いません。EC2 のスクリプトを cron で動かす構成は、サーバーを管理しない要件に合いません。出典 https://docs.aws.amazon.com/glue/latest/dg/what-⁠is-⁠glue.html