ウェアハウスのサイズ設計 ── 上げるべき時と、分けるべき時

ここで重要なのが、消費が増えても総額が増えるとは限らないという点です。この回はサイズと分割の判断を扱います。

課金はサイズ × 起動時間で決まります。したがって、サイズを2倍にして処理時間が半分になれば、総額は変わりません。

2行目なら費用そのままで待ち時間が半分になります。これは明確に得です。しかし4行目のように縮まらない場合、費用だけがほぼ倍になります。

つまり判断は単純で、上げてみて、時間が比例して縮むかを測る。縮むなら上げる価値があり、縮まないなら戻す。これが最も確実な方法です。理屈で予測しようとすると、読み取り量・並び順・同時実行など変数が多すぎて当たりません。1回試すほうが、議論するより速く確実です。

サイズを上げても縮まないなら、計算能力が ボトルネック（Bottleneck） ではないということです。原因は概ね次のどれかです。

2行目が最も多い原因です。読む量が減らない限り、計算資源を増やしても限界があります。この場合はサイズではなく、読み飛ばしを効かせる方向（EP.5）が正しい打ち手になります。これは パフォーマンスチューニング実践 EP.02 で扱った「計算しているのか、待っているのか」という切り分けと同じ構造です。計算資源が ボトルネック でないなら、そこを増やしても全体は動きません。

逆に、サイズを上げるべき明確な兆候もあります。スピル（Spill） の発生です。処理中のデータがメモリに収まらずディスクへ書き出されている状態で、これが起きると急激に遅くなります。

リモートへの書き出しが出ていたら、明確にサイズ不足です。ここはサイズを上げれば直り、しかも所要時間が大きく縮むため、費用も下がることが多い。サイズを上げて安くなる数少ないケースです。

混同しやすいのがここです。サイズは1件の処理を速くするもの、数は同時に捌ける量を増やすものです。症状が違えば打ち手も違います。

2行目に対してサイズを上げても、あまり効きません。1件あたりは速くなりますが、同時に走れる数は増えないためです。待ち行列の長さは、捌ける数を増やすことでしか解消しません。

待ち時間が実行時間に対して無視できないなら、数を増やす対象です。待ちがほぼゼロなのに遅いなら、サイズか処理内容の問題になります。この2つを取り違えると、費用だけ増えて改善しません。

全員が1つのウェアハウスを共有していると、設計そのものができなくなります。止めてよい時間帯も、求める応答速度も、用途ごとに違うためです。

4行目には注意が必要です。調査用途は、費用が想定外に膨らむ最大の要因になります。大きなサイズを与えると、うっかり全件走査したときの費用が跳ねます。小さめにして、必要なときだけ上げる運用にしておくと事故が減ります。小さいウェアハウスで重い処理を流せば、遅くて気づくという副次的な効果もあります。気づけること自体が安全装置として働くわけです。

サイズと分割の方針は、根拠を残さないと必ず崩れます。誰かが「遅いから」と上げ、誰も戻さない、という形で。

1. 1そのサイズにした根拠 — 測って比較した結果
2. 2分けた理由 — どの用途と干渉させたくないのか
3. 3止め方の設定と、その根拠 — EP.4 で扱う
4. 4見直す条件 — 「待ち時間が○秒を超えたら」

4番目があると、上げっぱなしを防げます。条件を書いておけば、それが満たされたときに動けばよく、常時気にする必要がなくなります。逆にこれが無いと、一度上げたサイズは誰も下げる根拠を持てないまま残り続けます。上げるのは簡単で、下げるには勇気が要るためです。