Docker Hub インシデント レビュー – 2020 年 7 月 5 日

バックグラウンド

Docker がインシデント レポートを公開するのはこれが初めてです。 インシデントの詳細な事後分析は常に社内で行ってきましたが、Docker の文化の変化の一環として、外部でもよりオープンになりたいと考えています。 たとえば、今年は ロードマップ を公開し、ユーザーに意見を求め始めました。 最も重要なインシデントのレポートを引き続き公開することを期待してください。

これらのレポートを公開するにあたり、私たちが直面した問題とその対処方法から他の人が学ぶことを願っています。 私たちのサービスとチームへの信頼を築くことを願っています。 また、これは、複数のサービスと利害関係者の間の複雑な相互作用のために非常に興味深いと思います。

インシデントの概要

いくつかのリージョンの Amazon Linux ユーザーは、およそ 7 月 5 日 19:00 UTC から 7 月 6 日 06:30 UTC の間に、Docker Hub レジストリからの Docker イメージの断続的なハングダウンロードに遭遇しました。 この問題は、CDNプロバイダーのCloudflareが展開したボットネット対策メカニズムに起因していました。 Docker、Cloudflare、AWSのチームが協力して問題を特定し、問題のメカニズムが無効になり、完全なサービス復元につながりました。

どうされました

7 月 6 日月曜日の 01:45 UTC (太平洋時間の日曜日の夕方) 頃、Docker Hub からのイメージプルが多くのサービスとユーザーで失敗することについて、Docker から AWS から連絡を受けました。 Docker Hub チームとインフラストラクチャ チームの両方がすぐに問題の調査を開始しました。

もちろん、最初のトラブルシューティング手順は、ローカルマシンからイメージプルを実行することでした。 これらはすべて機能し、問題がないことを示す監視とアラートと組み合わせることで、レジストリに関するサービス全体の問題を除外しました。 

次に、AWSで実行されている独自のインフラストラクチャのプルを確認しました。 私たち自身の監視にアラームがないことから予想されるように、これは機能しました。 これは、問題が「すべてのAWSインフラストラクチャ」よりも具体的であり、リージョンまたは失敗したサービス自体のメカニズムに関連していることを示しています。

この問題がAmazon Linuxを使用するシステム(Fargateなどの高レベルのサービスを含む)に影響を与えるというAWSエンジニアからの初期のフィードバックに基づいて、Dockerチームは複数のAWSリージョンでAmazon Linuxと別のOSを使用してインスタンスのスピンアップを開始しました。 ここでの結果は、AWSリージョンus-east-1の両方のオペレーティングシステムが正常に機能し、他の一部のリージョンでは、Amazon Linuxが他のOSが正常に機能するイメージを正常にプルできなかったという2つのことを示しました。

us-east-1が両方のオペレーティングシステムで機能したという事実は、問題がCDNであるCloudflareに関連していることを示しています。 これは、Docker Hub イメージデータが us-east-1 の S3 バケットに保存されるため、そのリージョンからのリクエストが S3 から直接提供されるためです。 問題が発生した他のリージョンは、CDNを介して提供されていました。 Dockerは、02:35 UTCにCloudflareでインシデントを開始しました。

私たちはAmazon Linuxでのみこの問題を観察したため、3社すべてのエンジニアが問題を掘り下げて、そのOSとCloudflareの間の相互作用が何であるかを理解し始めました。 いくつかの手段が検討されました–Amazon LinuxはカスタムDocker/containerdパッケージを使用していましたか? いいえ。Dockerエンジンではなくcurlを使用してプルを複製する場合、問題はまだ存在していましたか? はい。 問題はある種の低レベルのネットワーク実装の詳細であることが今ではかなり明らかであり、すべてのチームがこれに焦点を合わせ始めています。

05:00 UTC 頃、Amazon Linux と他のオペレーティングシステム間のネットワークの違いを調べる AWS のエンジニアは、他のシステムに一致するようにネットワークパケット属性を変更すると問題が解決しないことを発見しました。 この情報はCloudflareと共有されます。

Cloudflareはこの新しい情報に基づいて調査し、ボットネット対策システムが原因でDocker Hubへのトラフィックの一部がドロップされていることを発見しました。 このシステムには最近、特定の属性を持つパケットに攻撃の一部である可能性があるというフラグを立てる新しい検出シグネチャが追加されました。

Amazon Linux からのパケットがこのシグネチャと一致したという事実と、Docker Hub への大規模なトラフィックが相まって、いくつかのリージョンでこのメカニズムがアクティブになりました。 Cloudflareはこの変更を有効にする前にしばらく監視していましたが、メカニズムが監視からアクティブに切り替わるまで、この相互作用は明らかにされていませんでした。 

その後、CloudflareはDocker Hubトラフィックに対してこのメカニズムを無効にし、すべての関係者が06:30 UTC頃に完全な解決を確認しました。

結論

それで、私たちは何を学びましたか?

まず、CDNダウンロードのエンドユーザーエクスペリエンスに対する可視性が限られていることを知りました。 独自の監視では、206の応答コードの増加を追跡して、そのような問題が発生している可能性があることを示すことができることを確認しました。ダウンロードがハングすると、クライアントは多くの場合、以前に受信しなかった部分的なコンテンツを再接続してダウンロードしようとします。 この監視は現在実施されており、この情報は将来のそのようなインシデントではるかに迅速な解決につながります。

さらに、Cloudflareと協力して、Docker Hubのトラフィックに積極的に影響を与えている緩和策の可視性を高めます。

最後に、これはインターネットが複雑な場所であることを再確認しました。 この問題には、低レベルのネットワーク実装から、そのようなものを抽象化する高次サービスまでの詳細が含まれていました。 スタックのすべてのレイヤーの影響と、他のパーティへの依存関係を過小評価しないでください。

CloudflareとAWSのパートナーが問題の診断に取り組んでくれたことに感謝します。 共同ユーザーのためにこの問題を解決するために、3者すべてが協力する必要がありました。 開発者とオペレーターは、システムを強化するためにさまざまなプロバイダーに依存しており、緊密に連携すればするほど、お客様をより適切にサポートできます。