Quay.io が利用できない場合の事後分析

ノート。 翻訳。: XNUMX 月初旬、Red Hat は、サービスのユーザーが過去数か月間遭遇したアクセシビリティの問題の解決について公に話しました。 キーアイオ (これは、同社が CoreOS の購入とともに受け取ったコンテナ イメージのレジストリに基づいています)。 このサービス自体に興味があるかどうかに関係なく、同社の SRE エンジニアが事故の原因を診断して排除するためにたどった道は有益です。

19 月 XNUMX 日の早朝 (東部夏時間、EDT)、quay.io サービスがクラッシュしました。 この事故は、quay.io の利用者と、ソフトウェアを構築および配布するためのプラットフォームとして quay.io を使用するオープンソース プロジェクトの両方に影響を与えました。 Red Hat は両方の信頼を大切にしています。

SRE エンジニアのチームがすぐに参加し、できるだけ早く Quay サービスを安定化させることに努めました。 ただし、これを行っている間、クライアントは新しいイメージをプッシュできなくなり、既存のイメージをプルできるのはごくまれでした。 何らかの理由で、サービスをフルキャパシティに拡張した後、quay.io データベースがブロックされました。

«何が変わったの？「 - これは、そのような場合に通常尋ねられる最初の質問です。 この問題が発生する直前に、OpenShift D dedicated クラスター (quay.io を実行する) がバージョン 4.3.19 への更新を開始したことに気づきました。 quay.io は Red Hat OpenShift D dedicated (OSD) 上で実行されるため、定期的な更新は日常的であり、問​​題が発生することはありませんでした。 さらに、過去 XNUMX か月間、サービスを中断することなく Quay クラスターを数回アップグレードしてきました。

私たちがサービスを復元しようとしている間、他のエンジニアは、何かが起こった場合にすべてをその上に展開できるように、以前のバージョンのソフトウェアを使用して新しい OSD クラスターの準備を始めました。

根本原因分析

この障害の主な症状は、何万ものデータベース接続が雪崩のように発生し、MySQL インスタンスが事実上動作不能になったことです。 これにより、問題の診断が困難になりました。 SRE チームが問題を評価しやすくするために、クライアントからの最大接続数に制限を設定しました。 データベースへの異常なトラフィックには気づきませんでした。実際、ほとんどのリクエストは読み取りであり、書き込みリクエストはわずかでした。

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

夕方までに、サービスを読み取り専用モードで安定させ、データベースの負荷を軽減するために、できるだけ多くの重要でない機能 (名前空間のガベージ コレクションなど) を無効にしました。 フリーズは止まった しかし、その理由は決して見つかりませんでした。 新しい OSD クラスターの準備ができたので、サービスを移行し、トラフィックを接続し、監視を継続しました。

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

二度目の失敗

28 月 XNUMX 日、東部標準時正午の少し前に、quay.io が再びクラッシュし、同じ症状が発生しました。データベースがブロックされました。 そして私たちは再び全力を尽くして調査に取り組みました。 まず第一に、サービスを復元する必要がありました。 しかし 今回は、RDS を再起動して quay.io ポッドを再起動しても何も起こりませんでした: 新たな接続の雪崩が基地を圧倒しました。 しかし、なぜ？

Quay は Python で書かれており、各ポッドは単一のモノリシック コンテナーとして動作します。 コンテナー ランタイムは、多くの並列タスクを同時に実行します。 私たちは図書館を利用します gevent 下 gunicorn Web リクエストを処理します。 リクエストが (独自の API または Docker の API 経由で) Quay に届くと、gevent ワーカーが割り当てられます。 通常、このワーカーはデータベースに接続する必要があります。 最初の失敗の後、gevent ワーカーがデフォルト設定を使用してデータベースに接続していることがわかりました。

かなりの数の Quay ポッドと 5 秒あたり数千の受信リクエストを考慮すると、理論的には多数のデータベース接続が MySQL インスタンスに負荷を与える可能性があります。 モニタリングのおかげで、Quay は 5 秒あたり平均 XNUMX 件のリクエストを処理していることがわかっています。 データベースへの接続数はほぼ同じでした。 XNUMX の接続は、RDS インスタンスの能力の範囲内でした (数万とは言えません)。 何らかの理由で接続数が予期せず急増しましたただし、受信リクエストとの相関関係は見つかりませんでした。

今回は、再起動に限定するのではなく、問題の原因を見つけて排除することにしました。 Quay コードベースへ 各ワーカーのデータベースへの接続数を制限するための変更が行われました。 ゲベント。 この数値は構成内のパラメーターになり、新しいコンテナー イメージを構築せずに、その場で数値を変更できるようになりました。 現実的に処理できる接続数を調べるために、さまざまな値を設定してステージング環境でいくつかのテストを実行し、これが負荷テスト シナリオにどのような影響を与えるかを確認しました。 その結果、次のことが判明した。 接続数が 502 を超えると、Quay は 10 エラーをスローし始めます。

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

ブロックにつながる問題を回避できたので、 その本当の理由はまだわかっていません。 以前は Quay で問題なく動作していたバージョン 4.3.19 でも同じことが発生したため、OpenShift 4.3.18 の変更とは関係がないことが確認されました。

クラスターには明らかに別の何かが潜んでいました。

詳細な調査

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

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

Quay.io は 9 月 XNUMX 日まで正常に動作していました。 今朝 (EDT)、データベース接続数の大幅な増加が再び確認されました。 今回はダウンタイムはありませんでした新しいパラメータによってその数が制限され、MySQL スループットを超えることができなくなったためです。 しかし、約 XNUMX 分間、多くのユーザーが quay.io のパフォーマンスが遅いと指摘しました。 追加された監視ツールを使用して、考えられるすべてのデータを迅速に収集しました。 突然パターンが現れました。

接続が急増する直前に、App Registry API に対して大量のリクエストが行われました。。 App Registry は、quay.io のあまり知られていない機能です。 Helm チャートやコンテナーなどを豊富なメタデータとともに保存できます。 ほとんどの quay.io ユーザーはこの機能を使用しませんが、Red Hat OpenShift は積極的にこの機能を使用します。 OpenShift の一部としての OperatorHub は、すべてのオペレーターを App Registry に保存します。 これらのオペレーターは、OpenShift ワークロード エコシステムとパートナー中心の運用モデル (Day 2 運用) の基礎を形成します。

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

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

原因の除去

次の XNUMX 週間にわたって、私たちは App Registry 自体のコードとその環境の最適化に費やしました。 明らかに効果のない SQL クエリが再加工され、不要なコマンド呼び出しが削除されました tar (BLOB が取得されるたびに実行されました)、可能な限りキャッシュが追加されました。 次に、広範なパフォーマンス テストを実施し、変更前後のアプリ レジストリの速度を比較しました。

以前は最大 XNUMX 分かかっていた API リクエストが数ミリ秒で完了するようになりました。 翌週、変更を運用環境にデプロイしました。それ以来、quay.io は安定して動作しています。 この間、App Registry エンドポイントでトラフィックの急激な急増が数回ありましたが、改善によりデータベースの停止は回避されました。

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

どのサービスもダウンタイムを回避しようとしているのは明らかです。 私たちの場合、最近の機能停止が quay.io の改善に役立ったと考えています。 私たちはいくつかの重要な教訓を学びましたので、それを共有したいと思います。

1. サービスを誰がどのように利用するかに関するデータは決して不要ではありません。 Quay は「機能するだけ」だったので、トラフィックの最適化や負荷の管理に時間を費やす必要はありませんでした。 これらすべてが、サービスが無制限に拡張できるという誤った安心感を生み出しました。
2. サービスがダウンすると、 復旧して稼働させることが最優先事項です。。 最初の停止中も Quay はデータベースのロックに悩まされ続けたため、標準手順では意図した効果が得られず、その手順を使用してサービスを復元できませんでした。 このため、機能の復元に全力を注ぐのではなく、根本原因を見つけるためにデータの分析と収集に時間を費やさなければならない状況が生じました。
3. 各サービス機能の影響を評価する。 クライアントが App Registry を使用することはほとんどなかったため、私たちのチームにとっては優先事項ではありませんでした。 一部の製品機能がほとんど使用されていない場合、そのバグはめったに現れず、開発者はコードの監視を停止します。 これが本来あるべき姿であるという誤解に陥りがちですが、突然、その部門が重大な事件の中心に置かれることになります。

次は何ですか？

サービスの安定性を確保するための取り組みは決して止まらず、常に改善を行っています。 quay.io の交通量は増加し続けるため、私たちはお客様の信頼に応えるためにできる限りのことを行う責任があると認識しています。 したがって、現在、次のタスクに取り組んでいます。

1. 読み取り専用データベースのレプリカをデプロイして、プライマリ RDS インスタンスに問題が発生した場合にサービスが適切なトラフィックを処理できるようにします。
2. RDS インスタンスを更新しています。 現在のバージョン自体には問題はありません。 むしろ、私たちは単に偽の痕跡 (失敗中にたどったもの) を削除したいだけです。 ソフトウェアを最新の状態に保つことで、将来の機能停止が発生した場合の別の要因を排除できます。
3. クラスター全体にわたる追加のキャッシュ。 私たちは、キャッシュによってデータベースの負荷を軽減できる領域を探し続けます。
4. Web アプリケーション ファイアウォール (WAF) を追加して、誰が quay.io に接続しているのか、またその理由を確認します。
5. 次のリリースから、Red Hat OpenShift クラスターは App Registry を廃止し、quay.io で入手可能なコンテナー イメージに基づく Operator Catalog を使用します。
6. App Registry の長期的な代替手段は、Open Container Initiative (OCI) アーティファクト仕様のサポートになる可能性があります。 現在、ネイティブ Quay 機能として実装されており、仕様自体が完成するとユーザーが利用できるようになる予定です。

上記のすべては、Red Hat が小規模な「スタートアップスタイル」チームから成熟した SRE 主導のプラットフォームに移行する際の quay.io への継続的な投資の一部です。 私たちは、多くのお客様が日々の業務で quay.io に依存していることを認識しており (Red Hat を含む!)、最近の機能停止と継続的な改善努力について可能な限り透明性を保つよう努めています。

翻訳者からの追伸

私たちのブログもお読みください:

• «CoreOS コンテナイメージ用の Red Hat オープンソースレジストリコード - Quay";
• «SRE の日常生活から得た実践的なストーリー。 パート2";
• «Kubernetes のポッドの優先順位が Grafana Labs でダウンタイムを引き起こした仕組み'。

出所： habr.com