Docker Hub のインシデント レビューの公開を継続するという 昨年の約束 に沿って、4 月から 2 つについて話し合います。 多くのユーザーは影響を受けませんでしたが、コミュニティに対して透明性を保つことが重要であり、それが有益で有益なものになることを願っています。
2021年4月3日
07:30 UTC 頃から、Docker Hub に対するレジストリ要求のごく一部 (3% 未満) が失敗し始めました。 最初の調査では、内部DNSサービスの過負荷や、複数のユーザーとIPからの重大で異常な負荷など、いくつかの原因が指摘されました。 これらすべて(スケーリング、ブロッキングなど)に対処するための変更が行われ、問題は一度に数時間解決したように見えましたが、再発し続けました。
この問題は翌日まで断続的に再発し、その時点で実際の根本原因は、アプリケーションのサービス検出とルーティングを行うロードバランサーのスケール不足であると判断されました。
以前は、負荷分散システムのボトルネックはノード上のネットワーク帯域幅であり、自動スケーリングルールは帯域幅メトリクスに関連付けられていました。 時間の経過とともに、このシステムに対するいくつかの重要な変更を経て、負荷分散アプリケーションはCPUをより集中的に使用するようになったため、現在の自動スケーリングセットアップは特定のシナリオを処理するための設備が不十分でした。 週末のトラフィックが少なかったため、システムのスケーリングが低すぎて、帯域幅が問題ないにもかかわらずCPUが過負荷になりました。 実際、CPU負荷が高いと、これらのノードからのメトリックレポートにギャップが生じ、理論がさらに確認されました。
これを認識した後、デプロイは手動でスケーリングされ、インシデントは 4 月 4 日の 20:50 UTC 頃に解決されました。
2021年4月15日
17:46 UTC に、レジストリ サービスに変更が加えられ、新しいバージョンがスケールアップされ、古いバージョンがスケールダウンされました。 この新しいバージョンを認識するために、サービス検出システムの構成を更新する必要がありましたが、変更が間違った順序でデプロイされました。 そのため、ロード バランサーは Docker Hub レジストリ トラフィックを処理する有効なバックエンドを認識しておらず、レジストリ要求は 503 エラー応答で満たされました。
デプロイのエラーはすぐに認識され、サービス検出の構成変更がすぐにプッシュされました。 エラーは18:06 UTCまでに解決されました。
学習と改善
どちらのインシデントでも、レジストリのプル要求フローに対して、より詳細で応答性の高い監視が必要であることがわかりました。 これらのシナリオをより迅速に把握するために、すでに内部監視を強化しています。 さらに、ハブ エンドポイントは外部で監視されますが、レジストリ API が有効な応答を返すことを確認するなど、主に分離して監視されます。 複数のサービスへの複数のAPI呼び出しを含む「ドッカープル」フロー全体をより徹底的にテストするための作業が進行中であり、これらのタイプの問題をより迅速に検出する複数の外部バンタージから。
以前のインシデントでは、負荷分散のデプロイにも大きな変更を加えました。 自動スケール ルールは、現在のボトルネック (CPU) を反映するように変更され、インスタンスタイプが変更され、最小インスタンス数が高く設定されました。 メトリックとアラートが更新され、メトリックのギャップを探すなど、問題をより迅速に検出できるようになりました。 将来的には、大規模な変更のロード テストでは、すべてのメトリックを調べて、"ボトルネック" 属性が変更されたかどうかを判断します。
いつものように、私たちはDocker Hubの可用性を非常に真剣に受け止めています。 何百万人もの開発者が Hub を利用して作業を完了し、運用ワークロードにイメージを提供していることを認識しているため、過去数年間、Hub の信頼性に多額の投資を行ってきました。 たとえば、後者のインシデントは、昨年構築されたより優れた展開自動化のおかげで、非常に簡単かつ迅速に解決されました。 これらのインシデントについてお詫びし、二度と起こらないように措置を講じました。