高パフォーマンスなアーキテクチャの設計 #1
リクエストレートの単位となる S3 のプレフィックス
Amazon S3 の性能を考えるときは、リクエストレートがどの単位で割り当てられるかを押さえます。
・割り当ての単位はパーティション分割されたプレフィックスで、1 つあたり少なくとも毎秒 3,500 件の PUT / COPY / POST / DELETE、または 5,500 件の GET / HEAD を処理できます。
・1 つのバケットに作れるプレフィックスの数に上限はありません。10 個のプレフィックスを作れば読み取りは毎秒 55,000 件まで伸ばせます。
・拡大は段階的で即時ではありません。急に負荷を上げると 503 (Slow Down) が返ります。
「503 (Slow Down) が出る」なら、まずキーの設計を疑います。バケットを分けるのは過剰で、キーの先頭を分けるだけで同じ効果が得られます。割り当てはリクエスト元ではなく宛先の側に付いているため、送信元の台数を増やしても増えません。
ファイル数の増加が効いてくるファイル操作の処理能力
共有ファイルストレージが遅いときは「どの軸が足りないか」で切り分けます。
・スループット不足 — 大きなファイルの読み書きに時間がかかる。ディスク側の帯域やクライアント側の並列度が効きます。
・ファイル操作の処理能力の不足 — 作成・削除・一覧取得が遅い。データ量ではなくファイルの数が桁違いに増えたときに現れます。
Amazon FSx for Lustre はファイルの中身と、ファイル名やディレクトリの情報を別々の場所で管理する構造で、この 2 つの軸が独立しています。
後者を担うのがメタデータ IOPSで、Persistent 2 では自動モードからユーザープロビジョニングモードへ切り替えて引き上げられます。ただしメタデータ構成を指定して作成したファイルシステムに限られ、値は上げる方向にしか変えられません。
『データの総量はほとんど増えていないのにファイル数だけ桁違いに増えた』が合図です。
推奨の質は材料の指標と分析の期間で決まる
AWS Compute Optimizer の推奨の質は、どの指標が届いているかとどれだけの期間を見たかの 2 つで決まります。
指標の側でつまずくのがメモリの使用率です。EC2 の標準のメトリクスにメモリは含まれないため、CloudWatch エージェントを導入するか対応する製品から取り込まない限り、メモリを根拠にした推奨は出ません。
「CPU には余裕があるのに重い」状況でも、標準のメトリクスだけではメモリの逼迫が推奨に表れません。メモリの指標が無いとき、Compute Optimizer はメモリを減らす推奨を避けようとするだけで、メモリが足りないことは判定できません。
期間の側はデフォルトでは直近の 14 日しか見ません。月末や四半期末にだけ現れる山は、直近 14 日に入っている間しか反映されません。
分析の期間は 14 日・32 日・93 日から選べますが、93 日を選ぶには拡張インフラストラクチャメトリクスの有効化が必要で、四半期の周期を確実に含められるのはこの 93 日だけです。
Route 53 のルーティングポリシーは「何を基準に選ぶか」で覚える
Route 53 のルーティングポリシーは、行き先を決める基準で整理すると迷いません。
・シンプル — 常に同じレコードを返す。
・フェイルオーバー — ヘルスチェックの結果で切り替える。
・加重 — 指定した比率で返す。段階的な移行や A/B テストに使う。
・レイテンシー — 利用者に対してレイテンシーが最も小さいリージョンを返す。地理的に最も近いリージョンになるとは限らない。
・位置情報 — 問い合わせの発信元の場所（大陸・国・米国の州）で返す。規制やコンテンツの出し分けはこれ。
・地理的近接性 — リソースの所在地との距離で返す。
・IP ベース — 自分で登録した CIDR ブロックのロケーションで返す。
・複数値回答 — 正常なレコードを最大 8 件返す。
法規制・データの所在・国ごとの出し分けなら位置情報ルーティングで、デフォルトのレコードを必ず用意します。場所を判定できない問い合わせには「回答なし」が返るためです。
OpenSearch の保管階層は書き込みの終了と検索の頻度で切る
UltraWarm を使う構成では、Amazon OpenSearch Service のストレージは 3 段です。
・ホット（データノード） — 書き込みと頻繁な検索を受け持つ層。
・UltraWarm — 書き込みが終わったデータ向けの、安価で大容量の層。検索はそのままできます。
・コールドストレージ — さらにまれにしか読まないデータを置く層。そのままでは検索できず、読むときは UltraWarm へ戻します。
移す条件は 2 つです。下の 2 段は書き込みが終わったデータ向けなので、書き込みが続いているインデックスは移せません。そのうえで頻繁に検索する期間の分はホットに残し、書き込みが終わって検索も減ったものから順に下の層へ送ります。ログは日付ごとにインデックスをローテーションしておくと、この 2 つの条件で切り分けられます。
なおゾーン間の転送も、階層と S3 の間の転送も課金されません。転送料を理由に可用性の構成を縮めるのは、耐性だけを失う判断です。
また OpenSearch 3.3 以降では、OpenSearch Optimized Instances (OI2) のウォーム層に書き込みもできる別の構成（多層ストレージ）も選べますが、この構成にはコールド層がありません。