判断: サーバーのサイジング

適切なサイジングはワークロードのプロファイル (OLTP、データウェアハウス、混合) から始まり、実際のボトルネック (CPU、I/O、RAM) を特定する必要がある。鉄則: 頻繁にアクセスされるデータセット (ワーキングセット) が RAM に収まること。まず測定し、次にスケールし、急な負荷に備えて余裕を残す。このツリーは、ワークロードを特定し、ボトルネックに基づいてリソースとスケーリングの方向 (垂直/水平) を選択するのに役立つ。

ワークロードのプロファイルは?

OLTP と分析の負荷ではまったく異なるリソースプロファイルが必要なため、サイジングはワークロードから始まる。システムの主な処理は何か: 多数の小さく高速なトランザクション (OLTP)、大規模なスキャンと集計を伴うレポート/分析 (DWH)、またはその両方の混合か? 確信がない場合は、まず測定する必要がある。

• OLTP — 多数の小さく短いトランザクション (Web/アプリケーション)
• 分析 / データウェアハウス (DWH) — 大規模なスキャンと集計
• 混合ワークロード、または確信がない
• ボトルネックは分かっている。垂直と水平のどちらでスケールすべきか?

ボトルネックはどこか: RAM、I/O、CPU?

OLTP では、やみくもにリソースを追加するのではなく、実際のボトルネックを特定する。メトリクスを確認する: 頻繁にアクセスされるデータが RAM に収まらずディスク読み取りが多い (RAM/I/O) のか、ディスクのレイテンシ/IOPS が不足している (I/O) のか、それともデータはすでにメモリ上にあるが CPU が飽和している (CPU) のか? 誤ったリソースをスケールすると、費用と時間を無駄にする。

• 頻繁にアクセスされるデータが RAM に収まらず、ディスク読み取りが多い
• データはメモリ上にあるが、ディスクのレイテンシ/IOPS が不足している (書き込み中心)
• データはメモリ上にあり、ディスクも問題ないが、CPU が常に飽和している

推奨: まず測定し、次にサイジングする

推測に基づいてハードウェアを購入すると、ほぼ必ず誤ったサイズになる。ワークロードのプロファイルとボトルネックは実際のメトリクスから明らかになる。サイジングは推測ではなく、測定に基づく反復作業。

推奨: RAM を追加する — ワーキングセットはメモリに収める必要がある

OLTP で最も重要なルール: 頻繁にアクセスされるデータとインデックス (ワーキングセット) がメモリ (バッファ/キャッシュ) に収まること。収まらなければ、すべてのクエリがディスクにアクセスし、レイテンシが急増し、I/O がボトルネックになる。通常、RAM は最も投資効果の高い対象。

推奨: I/O 層を強化する (IOPS/レイテンシ)

データがメモリ上にあっても、書き込み中心の負荷 (commit、WAL/redo/binlog、checkpoint) ではディスクの速度が決定的。ここでの問題は容量ではなく、IOPS とレイテンシ。誤ったディスククラスは、CPU/RAM が高速でもシステムを行き詰まらせる。

推奨: CPU のボトルネックを解消する (まずクエリ、次にコア)

データがメモリ上にありディスクも問題ないのに CPU が飽和している場合、根本原因は通常、非効率なクエリ (不適切な実行計画、不足しているインデックス、多数の小さなクエリ) または過剰な同時実行。コアを追加する前に負荷を減らすほうが、通常は安価で効果的。

推奨: 分析/DWH — スループット、並列処理、水平スケール

データウェアハウスのワークロードは、大きなテーブルをスキャンして集計する少数の重いクエリで構成される。ここでの優先事項は低レイテンシではなく、高いスキャンスループット、並列処理、そして通常は水平スケール可能なアーキテクチャ。

一般原則: 垂直 vs 水平 + 余裕 + まず測定

どのリソースをスケールするかと同じくらい、どのようにスケールするかが重要。垂直 (より大きなマシン) はシンプルだが上限と単一障害点がある。水平 (より多くのマシン) はスケールするが複雑さが増す。いずれの場合も、急な負荷に備えて余裕を残し、測定によって判断を検証する。