レースコンディションと不適切なデータ検証。

https://news.ycombinator.com/item?id=45681136 を見て。実際のDNS変異APIは、実質的にCASを行っている。彼らは論理的な制約や変更の順序なしに競争する複数の非同期ライターを持っていた。あまり考えずに、彼らはゾーンシリアルを更新するか、常にChangeRRSetsに影響を与えるラベル/ゾーンのために使われる別の「センチネルレコード」を通じて、ベクトルのようなものを実装できたかもしれない。例えば、シリアライズされた変更セット番号や古い状態と新しい状態の「チェックサム」を含むTXTレコードのように。おそらく「プラン」の側面はそれをスキップして、単に意図した状態を適用していたんだろう。最後の書き込みが勝ち、でもそれがうまくいかないこともある。

あと、見逃したのかもしれないけど、異常な遅延が再発した場合のアウトageを防ぐための対策は何も確立されてないの？

これは問題の全体像を説明するための公のメッセージだよ。事故後の分析ってわけじゃない。アクティブなインシデントが「解決」される前に、再発の可能性を評価するんだ。通常、再発に迅速に対応するための潜在的な緩和策や回復の手順も用意してる。すぐに解決されたと見なされる前に、開いているリスクを積極的に緩和する作業が行われるよ。それには、最適な緩和策がわかっているなら、24時間体制で開発チームが働くことも含まれる。次に、「再発のリスク」に対する可能性のある道筋は、開発チームの最優先事項になる（営業時間内）まで、アクションアイテムが完了してデプロイされるまで続く。これには、同じようなDIY DNS管理をしている他のチームや、影響が少ないキュー深度の問題を抱えていたチーム、または似たような「ニアミス」の発見が含まれるかもしれない。サービスチームの技術者やビジネスオーナー（PE、シニアPE、GM、VP）は、解決されるまで進捗を毎日追跡するよ。それから数週間後、組織やAWSレベルでの「オペレーションミーティング」では、インシデント、対応、根本的な問題などについて深く議論される予定だ。目標は組織の学びと、得られた教訓やアクションアイテム、ベストプラクティスの広範な普及だね。

「DNSプランナー」と「DNSエナクター」が分かれているのはなぜ？もし一つのものだったら、このレースコンディションは作業している人たちにとってもっと明確だったんじゃない？これは、マイクロサービスアーキテクチャの過剰使用による複雑さの爆発が原因なのかな？

俺の結論は、レースコンディションが根本的な原因だったってこと。あのバグを取り除けば、処理の遅延があっても、突然インシデントは起こらなくなる。

エポックの失敗？

私の推測では、PTが選ばれたのは、ほとんどの対応しているオペレーションの人たちにとって真夜中に起こったことを強調するためだと思う。（ここでは何も知らないけど、その選択がなぜなされたのかを考えてみた）

君は失敗ケースを誤解してると思う。ChangeResourceRecordSetはトランザクショナルだよ（私がそのサービスに関わっていたときはそうだった）。https://docs.aws.amazon.com/Route53/latest/APIReference/API_.... 問題は、異なる目標状態を持つ二つのクライアントがいたことだ。- 一つの（「古い」）DNSエナクターは、DNSエンドポイントのいくつかで更新を再試行する必要があって、異常に高い遅延を経験した。- DNSプランナーは動き続けて、新しいプランの世代をたくさん作り出した。[注：これが重要。望ましい状態の「プラン」を生成しているが、以前の状態や変化を含む完全なトランザクションではない。] - その後、別の（「新しい」）DNSエナクターが新しいプランの一つを適用し始めた。- そして（「新しい」）プランのクリーンアッププロセスを呼び出し、適用したプランよりもかなり古いプランを特定して削除する。[注：ここに重要なレースが暗示されている。「古い」エナクターは現在の状態を読み取っていて、それは「新しい」エナクターの出力で、望ましい「古い」状態を上に適用している。この不一致は、プランナーとエナクターがチェーンやベクトルクロック、シリアライズされた変更セット番号などを使っていないために起こっている。] - 同時に最初の（「古い」）エナクターが、地域のDDBエンドポイントにかなり古いプランを適用して、新しいプランを上書きした。[注：ここで「古い」エナクターが有効なChangeRRSets呼び出しを作成し、「新しい」を「古い」に置き換えている。] - プラン適用プロセスの最初に行われたチェックは、プランが以前に適用されたプランよりも新しいことを確認するもので、これがこの時点で古くなっていた。[注：おっと！] - 二番目のエナクターのクリーンアッププロセスは、この古いプランを削除した。なぜなら、それは適用したプランよりも何世代も古かったから。皮肉なことに、Route 53はAPI変更の強力なトランザクションを持っていて、シリアライズもされていて、すべてのデータプレーンホストで変更セットを検証するクローズドループオブザーバーもある。その他のAWSサービスもそうだし、こういったレプリケーションや変更セットチェーンを構築するための内部プリミティブもある。でも、これは面倒で、たくさんの作業が必要で、失敗するとグローバルデッドロックが発生して、DNS変更が反映されないことで顧客が本当に不満を持つことになる。

DNSベースのCDNって、実際にはこういうことだよね。システムの使用状況やパケットロス、レイテンシーなどのメトリクスをデータストアから集めて、視聴者ネットワークと優先PoPのテーブルを計算する。残念ながら、詳しいドキュメントを提供するのは難しいけど、これが俺が以前働いていたところのCDNの仕組みだった。他にも同じことをもっとおしゃれな言葉で説明しているCDNがあるよ。[1] https://bunny.net/network/smartedge/

AWSはそろそろカーテンを少し開けて、各AWSサービスの内部サービス依存関係のリストを示すJSONドキュメントを公開するべきだと思う。