突き合わせを1日ごとにすると、ずれは平均1.9件。30日ごとでは30.0件でした。
ところが直した総件数はほぼ同じです。変わるのは1回あたりの量だけでした。
突き合わせは明示的に走らせたときだけです。間隔で変わるのは1回あたりの量でした。
Pulumiでは、実際の状態を見に行くのは明示したときだけです。公式は突き合わせの操作は、明示的に走らせたときにだけ起きると述べています。
走らせない間、手で触られた分は積み上がります。どれだけ積むのか実際に数えてみました。
管理する対象 400件・90日ぶん。1日に平均 1.2件が手で触られる 宣言した状態に戻す作業を、決めた間隔で行う 直す間隔 ずれている件数（平均） 最大 直した回数 1回あたり直す件数 直さない 88.0件 206件 0.0回 0.0件 1日ごと 1.9件 8件 90.0回 1.9件 7日ごと 7.7件 25件 12.0回 13.5件 30日ごと 30.0件 75件 3.0回 58.2件
直さないと平均88.0件、最大で206件がずれたままです。400件のうち半分に迫ります。
1日ごとに直せば平均1.9件です。ずれている状態の量が46分の1になりました。
右端を見ると、1日ごとは1.9件×90回、30日ごとは58.2件×3回です。掛け算するとほぼ同じになります。
つまり間隔を短くしても、作業の総量は減りません。変わるのは、ずれたまま過ごす時間の長さです。
同じ形の話はGitOpsの記事でも扱っていて、自動で突き合わせる仕組みを入れるかどうかの判断になります。
間隔を短くすると、ずれたままの量が減る。作業の総量は変わらない。
The refresh operation only occurs when you explicitly run pulumi refresh原文Pulumi 公式ドキュメント「How Pulumi Works」 この内容の有効期限2027-02-18
必要な操作だけを計算します。ただしその数は、依存の形しだいで大きく変わります。
Pulumiは、必要な操作を計算します。公式は配置の動力部は、いまの状態を、書かれた目指す状態へ進めるために必要な操作の集合を計算する役目を負うと述べています。
その集合はどれくらいの大きさになるのか。実際に数えてみました。
書いた行数 20行。1行が何個の資源になるかで比べる 書き方 作られる資源 1行あたり 定義の行数（1資源10行として） 生の資源を1つずつ書く 20個 1.0個 200行 低い水準の部品を使う 60個 3.0個 600行 高い水準の部品を使う 240個 12.0個 2400行 作られた資源 240個。1つを変えたとき、作り直しの対象になる資源を数える やり方 対象の資源 全体に対する割合 中央値 8個 3.3% 平均 55個 22.9% 99%点 228個 95.0% 最大 240個 100.0%
半分の変更では8個、全体の3.3%です。差分だけを触る利点がそのまま出ています。
ところが99%点は228個で95.0%です。ほぼ全部の作り直しになります。
上の表を見ると、20行から240個の資源ができています。1行が12個です。
だから書いた量から影響の大きさは読めません。差分を出して確かめるしかありません。
同じ形はTerraformの記事でも扱っていて、部品を重ねるほど1行あたりの重さが増えます。
The deployment engine is responsible for computing the set of operations needed to drive the current state of your infrastructure into the desired state expressed by your program.原文Pulumi 公式ドキュメント「How Pulumi Works」 この内容の有効期限2027-02-18
並べて動かせる分は速く終わります。ただし入れ替えは、分けたほうが被害が小さくなります。
Pulumiは、できるところは並べて動かします。公式はPulumiは可能な限り、資源への操作を並列に実行すると述べています。
速く終わるのは利点です。ただし新しい版に問題があったら困ります。実際に流して数えました。
台数 20台・1秒あたり 400件の要求。1台の入れ替えに 30秒 新しい版に当たった要求の 8%が失敗する。気づいて止めるまで 90秒かかる やり方 組の数 全部終わるまで 失敗した要求 最初の1組で失敗した要求 一斉に入れ替える 1組 30秒 2,880件 960件 4台ずつ入れ替える 5組 150秒 1,152件 192件 1台ずつ入れ替える 20組 600秒 288件 48件
一斉なら30秒で終わりますが、失敗した要求は2,880件です。1台ずつなら288件でした。
10分の1になる代わりに、全部終わるまで600秒かかります。20倍の時間です。
4台ずつなら150秒で1,152件です。時間は5倍、失敗は2.5分の1という置き方になります。
右端の列が判断の助けになります。最初の1組で失敗する件数が960件から192件に下がり、気づく前の被害が減ります。
3つの計測はいずれも手元で書いた模型で、実際のPulumiを動かしたものではありません。手で触られる件数を1日1.2件、資源のつながりを式で作るなど、前提はすべて置いた値です。実際の依存はもっと偏るので、中央値と99%点の開きはさらに大きくなります。失敗率8%や気づくまで90秒も置いた値です。ここで見せているのは、突き合わせの間隔を変えても総件数は変わらないという点と、書いた行数から影響の大きさは読めないという点の2つです。
Pulumi executes resource operations in parallel whenever possible原文Pulumi 公式ドキュメント「How Pulumi Works」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る