モーテムを手の届かないところに投稿Quay.io

約transl。：8月の初めに、Red Hatは、Quay.ioサービス（同社がCoreOSの購入で取得したコンテナイメージのレジストリに基づいています）のユーザーの間で前月に発生したアクセシビリティの問題の解決について公に話しました。このサービス自体への関心に関係なく、事故の原因を診断して排除するために会社のSREエンジニアがたどった道は有益です。







5月19日（EDT）の早朝、quay.ioがクラッシュしました。この災害は、quay.ioをソフトウェアの構築と配布のプラットフォームとして使用するquay.ioの消費者とオープンソースプロジェクトの両方に影響を及ぼしました。レッドハットは両方の信頼を大切にしています。



SREエンジニアのチームはすぐに参加し、できるだけ早くQuayサービスを安定させようとしました。ただし、これを行っている間、クライアントは新しいイメージをプッシュできなくなり、既存のイメージをプルできるのはたまにしかありませんでした。なんらかの理由で、サービスが最大容量にスケールアップされた後、quay.ioデータベースがロックされました。



「何が変わったの？「-これは、そのような場合に通常尋ねられる最初の質問です。問題が発生する少し前に、OpenShift Dedicatedクラスター（quay.ioが実行されている）がバージョン4.3.19への更新を開始したことに気付きました。quay.ioはRedHat OpenShift Dedicated（OSD）を利用しているため、定期的な更新は一般的であり、問​​題を引き起こすことはありませんでした。さらに、過去6か月間に、サービスを中断することなく、Quayクラスターを数回アップグレードしました。



サービスを復元しようとしているときに、他のエンジニアが、必要に応じてすべてをデプロイするために、以前のバージョンのソフトウェアを使用して新しいOSDクラスターを準備し始めました。

根本原因分析

クラッシュの主な症状は、MySQLインスタンスを事実上使用できなくする、何万ものデータベース接続のなだれでした。これにより、問題の診断が困難になりました。 SREチームが問題を評価できるように、顧客からの接続の最大数に制限を設定しました。データベースへの異常なトラフィックは確認されませんでした。実際、ほとんどのリクエストは読み取り用であり、書き込み用のリクエストはごくわずかでした。



また、この雪崩を引き起こす可能性のあるデータベーストラフィックのパターンを特定しようとしました。ただし、ログにパターンを見つけることはできませんでした。 OSD 4.3.18の新しいクラスターの準備が整うのを待っている間、quay.ioポッドの起動を試み続けました。クラスターがフルキャパシティーになるたびに、データベースがフリーズしていました。これは、すべてのquay.ioポッドに加えてRDSインスタンスを再起動する必要があることを意味しました。



夕方までに、サービスを読み取り専用モードで安定させ、データベースの負荷を軽減するために、必須ではない機能（たとえば、名前名のガベージコレクション）の最大数を無効にしました。フリーズは止まりましたが、理由は見つかりませんでした。新しいOSDクラスターの準備が整い、サービスを移行し、トラフィックを接続し、監視を継続しました。



Quay.ioは新しいOSDクラスターで安定して実行されたため、データベースログに戻りましたが、ロックを説明する相関関係が見つかりませんでした。OpenShiftのエンジニアは、Red Hat OpenShift4.3.19での変更がQuayの問題を引き起こした可能性があるかどうかを確認するために私たちと協力しました。しかし、何も見つからず、実験室で問題を再現することはできませんでした。

2番目の失敗

5月28日、正午EDTの直前に、quay.ioが同じ症状で再びクラッシュしました。データベースがブロックされました。もう一度、私たちはすべての力を調査に投入しました。まず、サービスを復旧する必要がありました。ただし、今回はRDSを再起動してquay.ioポッドを再起動しても、何も発生しませんでした。接続の別のなだれがベースを一掃しました。しかし、なぜ？



QuayはPythonで記述されており、各ポッドは単一のモノリシックコンテナとして動作します。多くの並列タスクは、コンテナーランタイムで同時に実行されます。gevent下のライブラリを使用していますgunicornWebリクエストを処理します。リクエストがQuayに到着すると（独自のAPIまたはDocker APIを介して）、geventワーカーが割り当てられます。通常、このワーカーはデータベースと通信する必要があります。最初の失敗の後、geventワーカーがデフォルト設定を使用してデータベースに接続していることがわかりました。



多数のQuayポッドと1秒あたり数千の着信要求を考えると、理論的には、多数のデータベース接続がMySQLインスタンスに過負荷をかける可能性があります。監視のおかげで、Quayは1秒あたり平均5000件のリクエストを処理することがわかっていました。データベースへの接続数はほぼ同じでした。マージンのある5000の接続は、RDSインスタンスの機能に適合します（これは約数万とは言えません）。何らかの理由で、接続数に予期しないスパイクが発生しましたが、着信要求との相関関係は見られませんでした。



今回は、再起動するだけでなく、問題の原因を見つけて修正することにしました。各geventワーカーのデータベース接続の数を制限するために、 Quayコードベースに変更が加えられました。この数は構成のパラメーターになりました。新しいコンテナーイメージを作成せずに「オンザフライ」で変更できるようになりました。実際に処理する接続の数を確認するために、さまざまな値を使用していくつかのステージングテストを実行し、これが負荷テストシナリオにどのように影響するかを確認しました。その結果、接続数が10Kを超えると、Quayは502エラーをスローし始めます。



すぐにこの新しいバージョンを本番環境にデプロイし、データベース接続スケジュールの監視を開始しました。過去には、基地は約20分後にブロックされました。トラブルのない30分後、私たちは希望を持ち、1時間後には自信を持っていました。サイトの投稿へのトラフィックを復元し、事後分析を開始しました。



ブロッキングにつながる問題を回避することができましたが、その真の原因はわかりませんでした。以前はQuayで問題なく動作していたバージョン4.3.18でも同じことが起こったため、OpenShift4.3.19の変更とは関係がないことが確認されました。



クラスターには明らかに何か他のものが潜んでいた。

詳細な調査

Quay.ioは、デフォルト設定を使用して6年間、問題なくデータベースに接続しています。何が変わったの？ quay.ioへのトラフィックが常に着実に増加していることは明らかです。私たちの場合、すべてが特定のしきい値に達したように見え、それが接続のなだれのトリガーとして機能しました。 2回目のクラッシュ後もデータベースログの調査を続けましたが、パターンや明らかな関係は見つかりませんでした。



その間、SREチームは、Quayのクエリの可観測性と全体的なサービスの状態の改善に取り組んでいます。Quayのどの部分が顧客から最も需要があるかを示す、新しいメトリックとダッシュボードが展開されました。



Quay.ioは6月9日まで正常に機能しました。午前中（EDT経由）に、データベース接続の数が大幅に増加するのを再び目撃しました。今回は、新しいパラメーターによって数が制限され、MySQL帯域幅を超えることができなかったため、ダウンタイムは発生しませんでした。しかし、約30分の間、多くのユーザーはquay.ioが遅いことに気づきました。追加された監視ツールを使用して、考えられるすべてのデータをすばやく収集しました。パターンが突然現れました。



接続が急増する直前に、多数のリクエストがApp RegistryAPIに送信されました..。 App Registryは、quay.ioのあまり知られていない機能です。ヘルムチャートやメタデータが豊富なコンテナなどを保存できます。ほとんどのquay.ioユーザーはこの機能を使用していませんが、Red HatOpenShiftは積極的に使用しています。 OpenShift内のOperatorHubは、すべてのオペレーターをAppRegistryに格納します。これらのキャリアは、OpenShiftワークロードエコシステムとパートナー中心の運用モデル（2日目の運用）の基盤を形成します。



各OpenShift4クラスターは、組み込みのOperatorHubのオペレーターを使用して、インストール可能なオペレーターのカタログを公開し、既にインストールされているオペレーターの更新を提供します。 OpenShift 4の人気が高まるにつれ、世界中でクラスターの数が増えています。これらの各クラスターは、quay.io内のApp Registryをバックエンドとして使用して、オペレーターコンテンツをロードして組み込みのOperatorHubを実行します。問題の原因を探すと、OpenShiftの人気が徐々に高まるにつれて、めったに使用されないquay.io関数の1つに負荷がかかるという事実を見逃しました。



App Registryリクエストトラフィックの分析を行い、レジストリコードを調べました。すぐに欠陥が明らかになり、データベースへのクエリが最適に形成されなかったためです。軽負荷では問題ありませんでしたが、増加すると問題の原因になりました。App Registryには、負荷の増加にうまく反応しなかった2つの問題のあるエンドポイントがあることが判明しました。1つ目はリポジトリ内のすべてのパッケージのリストを提供し、2つ目はパッケージのすべてのblobを返しました。

原因の排除

来週、私たちはAppRegistry自体とその環境のコードを最適化してきました。明らかに非効率的なSQLクエリが作り直され、コマンドへの不要な呼び出しが排除されtar（blobがフェッチされるたびに実行されました）、可能な限りキャッシュが追加されました。次に、広範なパフォーマンステストを実施し、変更前後のAppRegistryのパフォーマンスを比較しました。



以前は最大30分かかっていたAPIリクエストが、ミリ秒単位で完了するようになりました。来週、生産への変更を展開し、quay.ioはそれ以来安定しています。この間、App Registryエンドポイントでトラフィックが急増しましたが、改善によりデータベースの停止が防止されました。

私たちは何を学びましたか？

どのサービスもダウンタイムを回避しようとしていることは明らかです。私たちの場合、最近のクラッシュがquay.ioの改善に役立ったと信じています。私たち自身のために、私たちが共有したいいくつかの主要なレッスンを取りました：

1. 誰があなたのサービスをどのように使用しているかに関するデータは不要ではありません。Quayは「機能した」ため、トラフィックの最適化と負荷の管理に時間を費やす必要はありませんでした。これらすべてが、サービスが無期限に拡張される可能性があるという誤った安心感を生み出しました。
2. , — . Quay , . , — , .
3. 各サービス機能の影響を評価します。顧客がAppRegistryを使用することはめったになかったため、私たちのチームにとって優先事項ではありませんでした。製品の一部の機能がほとんど使用されていない場合、それらのバグがポップアップすることはめったになく、開発者はコードの監視を停止します。これが本来あるべき姿であるという妄想の餌食になるのは簡単です-突然この機能が大規模な事件の中心になるまで。

次は何ですか？

サービスの安定性を確保するための作業は止まることなく、常に改善しています。quay.ioのトラフィック量は増え続けており、お客様の信頼に応えるために最善を尽くす必要があることを認識しています。したがって、現在、次のタスクに取り組んでいます。

1. , RDS.
2. RDS. . , ( ); .
3. . , .
4. firewall’ - (WAF), , quay.io.
5. , Red Hat OpenShift App Registry (Operator Catalogs), , quay.io.
6. Open Container Initiative（OCI）アーティファクト仕様のサポートは、AppRegistryの長期的な代替となる可能性があります。現在、ネイティブのQuay機能として実装されており、仕様自体が完成したときにユーザーが利用できるようになります。

上記のすべては、小さなスタートアップのようなチームからSREによって駆動される成熟したプラットフォームに移行する際の、quay.ioへのRedHatの継続的な投資の一部です。多くのお客様が日常業務（Red Hatを含む）をquay.ioに依存していることを認識しており、最近の混乱や継続的な改善努力について可能な限りオープンに努めています。

翻訳者からのPS

私たちのブログも読んでください：

• " RedHatがCoreOSからコンテナイメージのレジストリコードを開く-Quay ";
• « SRE-. 2»;
• « pod' Kubernetes Grafana Labs».