プロビジョニングキューの書き直し

5年間、ここでサーバーを購入するのにかかる時間は、決済ウェブフックから受信トレイに認証情報が届くまで、中央値で3分20秒でした。誰も文句を言いませんでした。これは業界の大半よりも速く、人間の承認を必要とするものよりはるかに速かったのです。

しかし、それは直列である必要のない4つの直列ステップでもあり、一度気づくと気になり始めます。書き直しは3月に出荷され、現在の中央値は47秒、95パーセンタイルは4分弱です。

旧システムの動作

4つのステップ、1つのグローバルワーカープール、そして同じサイト内のすべての注文が待機しなければならないアドレスプールのロック。静かな火曜日には問題ありませんでした。プロモーション中や、大規模な顧客が40台の作成をスクリプト化した後の1時間は、中央値が2倍になり、テールは12分を超えました。

変更した点

イメージはコピーではなく事前シードされます。 各ノードは、カタログ内のすべてのイメージのシンクローンベースを保持し、毎晩更新されます。ボリュームの作成は、現在ではネットワークプルではなく、ローカルのGen4 NVMeミラーに対するコピーオンライトクローンです。このステップは84秒から2秒未満になりました。

アドレスは事前に予約されます。 各サイトは、そのサイトの約6時間分の需要に合わせて、逆DNSがすでに書き込まれた割り当て済みアドレスのウォームプールを保持します。割り当ては現在、ロック、スキャン、DNS書き込みではなく、事前構築されたプールからのポップです。46秒が約400ミリ秒になりました。

キューはサイトごとにあります。 フランクフルトのラッシュがサンパウロの作成を遅延させることはなくなりました。これは当然のことのように聞こえますが、元の設計では4つのサイトと1人のエンジニアしかいなかったため、元の設計ではそうではありませんでした。

ワーカーは冪等で再開可能です。 すべてのステップにキーが付けられているため、ワーカーが途中で死んでも、中途半端なインスタンスとサポートチケットではなく、再開可能なジョブが残ります。失敗した作成に対する手動介入は、約400件に1件から9000件に1件に減少しました。

結果

途中で何が悪かったか

3月、11時間にわたって、シンクローンベースの夜間更新が4つのサイトで静かに失敗し、事前シードされたDebianイメージが9日古いポイントリリースを提供しました。約90のインスタンスがそれから構築されました。古いポイントリリースはパッケージ更新で最新版に追いつけるため、それらのいずれも興味深い方法で壊れていませんでしたが、サーバーを購入する人は誰もチェックする必要はないはずです。

私たちはリクエストに応じて影響を受けたインスタンスを再構築し、要求したかどうかに関係なく90すべてにメールを送り、ベースイメージのハッシュをカタログと比較するチェックを追加しました。これにより、どのノードも作成の提供を許可される前に確認されます。夜間ジョブの静かな失敗は最も退屈な原因であり、退屈だからこそ書き留める価値があります。

まだ遅いもの

• カスタムISOインストール。 まだ手動で、まだ数十分単位で、通常は1時間以内に完了します。ボトルネックは、イメージがアップローダーの言うことを実行することを確認する人です。
• Windows。 ライセンス認証には2〜3分かかり、当社の制御外です。
• ベアメタル。 同日対応であり、同分対応ではありません。物理マシンには物理的な再構築があり、勝てない時計をスタートさせるよりも正直に見積もりを提供したいと考えています。
• IPv6 /48委任。 ファブリック設定が古い3つのサイトでは手動です。ゆっくりと修正中です。

なぜここで止めたか

インスタンスを事前ブートし、支払い時に単に引き渡すことで、中央値を約20秒にすることができます。つまり、アイドル容量を保持し、誰も使用していないコアにお金を払い、新しい注文が11秒速く感じられるように全員にもう少し請求することを意味します。

47秒は、制約が私たちが行うことではなく、チェーンが支払いを確認することになるほど十分に短いです。顧客が気付くポイントを超えて最適化することは、趣味であり、エンジニアリングではありません。