🥇「Kubernetes によりレイテンシが 10 倍増加した」: この責任は誰にあるのでしょうか?

ノート。翻訳。: この記事は、ヨーロッパ企業 Adevinta で主任ソフトウェアエンジニアの職にある Galo Navarro によって書かれたもので、インフラストラクチャ運用の分野における魅力的で有益な「調査」です。原題は、著者が最初に説明する理由により、翻訳においてわずかに拡張されました。

著者からのメモ: この投稿のようです惹かれる予想をはるかに上回る注目度。記事のタイトルが誤解を招き、一部の読者を悲しませているという怒りのコメントが今でも寄せられます。何が起こっているのか理由は理解しています。したがって、陰謀全体を台無しにする危険にもかかわらず、この記事が何についてであるかをすぐに説明したいと思います。チームが Kubernetes に移行するときに私が見た奇妙なことは、問題が発生するたびに (移行後のレイテンシの増加など)、最初に非難されるのは Kubernetes ですが、その後、オーケストレーターが実際には非難されていないことが判明するということです。非難。この記事では、そのような事例の XNUMX つについて説明します。その名前は、開発者の XNUMX 人の感嘆符を繰り返したものです (後で、Kubernetes がそれとは何の関係もないことがわかります)。ここでは Kubernetes に関する驚くべき事実は見つかりませんが、複雑なシステムについていくつかの良い教訓が得られると期待できます。

数週間前、私のチームは単一のマイクロサービスを、CI/CD、Kubernetes ベースのランタイム、メトリクス、その他の機能を含むコアプラットフォームに移行していました。この移行は試験的なものでした。私たちはこれを基礎として、今後数か月間でさらに約 150 のサービスを移行する予定でした。彼らは全員、スペイン最大のオンラインプラットフォーム (Infojobs、Fotocasa など) の運営を担当しています。

アプリケーションを Kubernetes にデプロイし、一部のトラフィックをそこにリダイレクトした後、驚くべき驚きが私たちを待っていました。遅れ （待ち時間） Kubernetes でのリクエストは EC10 の 2 倍でした。一般に、この問題の解決策を見つけるか、マイクロサービス (場合によってはプロジェクト全体) の移行を放棄する必要がありました。

Kubernetes のレイテンシが EC2 よりもはるかに高いのはなぜですか?

ボトルネックを見つけるために、リクエストパス全体に沿ってメトリクスを収集しました。私たちのアーキテクチャはシンプルです。API ゲートウェイ (Zuul) が EC2 または Kubernetes のマイクロサービスインスタンスにリクエストをプロキシします。 Kubernetes では NGINX Ingress Controller を使用し、バックエンドは次のような通常のオブジェクトです。展開 Spring プラットフォーム上の JVM アプリケーションを使用します。

                                  EC2
                            +---------------+
                            |  +---------+  |
                            |  |         |  |
                       +-------> BACKEND |  |
                       |    |  |         |  |
                       |    |  +---------+  |                   
                       |    +---------------+
             +------+  |
Public       |      |  |
      -------> ZUUL +--+
traffic      |      |  |              Kubernetes
             +------+  |    +-----------------------------+
                       |    |  +-------+      +---------+ |
                       |    |  |       |  xx  |         | |
                       +-------> NGINX +------> BACKEND | |
                            |  |       |  xx  |         | |
                            |  +-------+      +---------+ |
                            +-----------------------------+

この問題はバックエンドの初期レイテンシーに関連しているようです (グラフ上で問題のある領域を「xx」としてマークしました)。 EC2 では、アプリケーションの応答に約 20 ミリ秒かかりました。 Kubernetes では、レイテンシが 100 ～ 200 ミリ秒に増加しました。

私たちは、ランタイムの変更に関連する可能性のある容疑者をすぐに却下しました。 JVM のバージョンは変わりません。コンテナ化の問題もこれとは何の関係もありませんでした。アプリケーションはすでに EC2 上のコンテナ内で正常に実行されていました。読み込み中? しかし、1 秒あたり XNUMX リクエストでも高いレイテンシが観察されました。ガベージコレクションの一時停止も無視される可能性があります。

Kubernetes 管理者の XNUMX 人は、DNS クエリによって過去に同様の問題が発生したため、アプリケーションに外部依存関係があるのではないかと疑問に思いました。

仮説 1: DNS 名前解決

リクエストごとに、アプリケーションは次のようなドメイン内の AWS Elasticsearch インスタンスに XNUMX ～ XNUMX 回アクセスします。 elastic.spain.adevinta.com。コンテナの内部貝殻がある, これにより、ドメインの検索に実際に時間がかかるかどうかを確認できます。

コンテナからの DNS クエリ:

[root@be-851c76f696-alf8z /]# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 22 msec
;; Query time: 22 msec
;; Query time: 29 msec
;; Query time: 21 msec
;; Query time: 28 msec
;; Query time: 43 msec
;; Query time: 39 msec

アプリケーションが実行されている EC2 インスタンスの XNUMX つからの同様のリクエスト:

bash-4.4# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 77 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec

ルックアップに約 30 ミリ秒かかったことを考慮すると、Elasticsearch にアクセスするときの DNS 解決が実際にレイテンシの増加に寄与していることが明らかになりました。

しかし、これは次の XNUMX つの理由から奇妙でした。

私たちはすでに、高いレイテンシーに悩まされることなく AWS リソースと通信する Kubernetes アプリケーションを大量に持っています。理由が何であれ、それは特にこの事件に関連しています。
JVM がメモリ内 DNS キャッシュを実行することがわかっています。私たちの画像では、TTL 値は次のように書かれています。 $JAVA_HOME/jre/lib/security/java.security そして 10 秒に設定します。 networkaddress.cache.ttl = 10。つまり、JVM はすべての DNS クエリを 10 秒間キャッシュする必要があります。

最初の仮説を確認するために、DNS への呼び出しをしばらく停止し、問題が解消されるかどうかを確認することにしました。まず、ドメイン名ではなく IP アドレスによって Elasticsearch と直接通信するようにアプリケーションを再構成することにしました。これにはコードの変更と新しいデプロイメントが必要となるため、単にドメインをその IP アドレスにマップしました。 /etc/hosts:

34.55.5.111 elastic.spain.adevinta.com

これで、コンテナはほぼ即座に IP を受け取りました。これにより、ある程度の改善は得られましたが、予想されるレイテンシレベルにわずかに近づくだけでした。 DNS 解決には長い時間がかかりましたが、本当の理由はまだわかりません。

ネットワーク経由の診断

を使用してコンテナからのトラフィックを分析することにしました。 tcpdumpネットワーク上で何が起こっているかを正確に確認するには:

[root@be-851c76f696-alf8z /]# tcpdump -leni any -w capture.pcap

次に、いくつかのリクエストを送信し、そのキャプチャをダウンロードしました (kubectl cp my-service:/capture.pcap capture.pcap）さらなる分析のために Wiresharkの.

DNS クエリには何も疑わしいものはありませんでした (後で説明する XNUMX つの小さな点を除いて)。しかし、私たちのサービスが各リクエストを処理する方法には、特定の奇妙な点がありました。以下は、応答が開始される前にリクエストが受け入れられたことを示すキャプチャのスクリーンショットです。

パッケージ番号は最初の列に表示されます。わかりやすくするために、さまざまな TCP フローを色分けしました。

パケット 328 で始まる緑色のストリームは、クライアント (172.17.22.150) がコンテナ (172.17.36.147) への TCP 接続を確立する方法を示しています。最初のハンドシェイク (328-330) の後、パッケージ 331 が持ち込まれました HTTP GET /v1/.. — 当社のサービスへの受信リクエスト。プロセス全体に 1 ミリ秒かかりました。

灰色のストリーム (パケット 339 から) は、サービスが Elasticsearch インスタンスに HTTP リクエストを送信したことを示しています (既存の接続を使用しているため、TCP ハンドシェイクはありません)。これには 18 ミリ秒かかりました。

ここまではすべて問題なく、時間は予想される遅延 (クライアントから測定した場合は 20 ～ 30 ミリ秒) にほぼ一致しています。

ただし、青色のセクションには 86 ミリ秒かかります。その中で何が起こっているのでしょうか？パケット 333 で、サービスは HTTP GET リクエストを次の宛先に送信しました。 /latest/meta-data/iam/security-credentials、その直後に、同じ TCP 接続を介して、別の GET リクエストが /latest/meta-data/iam/security-credentials/arn:...

トレース全体を通じて、すべてのリクエストでこれが繰り返されることがわかりました。確かに、コンテナーでは DNS 解決が少し遅くなります (この現象の説明は非常に興味深いですが、別の記事に取っておきます)。長い遅延の原因は、各リクエストでの AWS インスタンスメタデータサービスの呼び出しであることが判明しました。

仮説 2: AWS への不要な呼び出し

両方のエンドポイントが属しています AWS インスタンスメタデータ API。私たちのマイクロサービスは、Elasticsearch の実行中にこのサービスを使用します。どちらの呼び出しも基本的な認証プロセスの一部です。最初のリクエストでアクセスされるエンドポイントは、インスタンスに関連付けられた IAM ロールを発行します。

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
arn:aws:iam::<account_id>:role/some_role

XNUMX 番目のリクエストは、XNUMX 番目のエンドポイントにこのインスタンスの一時的なアクセス許可を要求します。

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/arn:aws:iam::<account_id>:role/some_role`
{
    "Code" : "Success",
    "LastUpdated" : "2012-04-26T16:39:16Z",
    "Type" : "AWS-HMAC",
    "AccessKeyId" : "ASIAIOSFODNN7EXAMPLE",
    "SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "Token" : "token",
    "Expiration" : "2017-05-17T15:09:54Z"
}

クライアントはそれらを短期間使用でき、定期的に新しい証明書を取得する必要があります (証明書が有効になる前に)。 Expiration）。モデルは単純です。AWS はセキュリティ上の理由から一時キーを頻繁にローテーションしますが、クライアントはそれらを数分間キャッシュして、新しい証明書の取得に伴うパフォーマンスの低下を補うことができます。

AWS Java SDK がこのプロセスを組織する責任を引き継ぐ必要がありますが、何らかの理由でこれが行われません。

GitHub で問題を検索したところ、問題が見つかりました #1921。彼女は、私たちがさらに「掘り下げる」方向を決定するのを手伝ってくれました。

AWS SDK は、次のいずれかの状況が発生した場合に証明書を更新します。

有効期限（Expiration）に落ちる EXPIRATION_THRESHOLD、15分にハードコーディングされています。
最後に証明書を更新してから、次の時間よりも長い時間が経過しました。 REFRESH_THRESHOLD、60分間ハードコーディングされています。

受け取った証明書の実際の有効期限を確認するために、コンテナと EC2 インスタンスの両方から上記の cURL コマンドを実行しました。コンテナから受け取った証明書の有効期間は、はるかに短く、ちょうど 15 分であることが判明しました。

これですべてが明らかになりました。最初のリクエストで、サービスは一時証明書を受け取りました。これらは 15 分を超えて有効ではなかったため、AWS SDK は後続のリクエストでそれらを更新することを決定します。そして、これはすべてのリクエストで起こりました。

証明書の有効期限が短くなったのはなぜですか?

AWS インスタンスメタデータは、Kubernetes ではなく EC2 インスタンスで動作するように設計されています。一方で、アプリケーションのインターフェースは変更したくありませんでした。このために使用したのはキアム - 各 Kubernetes ノード上のエージェントを使用して、ユーザー (アプリケーションをクラスターにデプロイするエンジニア) が EC2 インスタンスであるかのように IAM ロールをポッド内のコンテナに割り当てることができるツール。 KIAM は、AWS インスタンスメタデータサービスへの呼び出しをインターセプトし、事前に AWS から受信した呼び出しをそのキャッシュから処理します。アプリケーションの観点からは何も変わりません。

KIAM はポッドに短期証明書を提供します。ポッドの平均寿命が EC2 インスタンスの平均寿命より短いことを考慮すると、これは当然のことです。証明書のデフォルトの有効期間同じ15分に等しい.

その結果、両方のデフォルト値を重ね合わせると問題が発生します。アプリケーションに提供された各証明書は 15 分後に期限切れになります。ただし、AWS Java SDK は、有効期限まで残り 15 分を切った証明書は強制的に更新します。

その結果、一時証明書はリクエストごとに強制的に更新されることになり、AWS API への呼び出しが数回必要となり、レイテンシーが大幅に増加します。 AWS Java SDK で次のことがわかりました。機能リクエスト、同様の問題について言及しています。

解決策は簡単であることがわかりました。より長い有効期間の証明書を要求するように KIAM を再構成しただけです。これが発生すると、AWS メタデータサービスの参加なしでリクエストが流れるようになり、レイテンシは EC2 よりもさらに低いレベルに低下しました。

所見

移行に関する私たちの経験に基づくと、最も一般的な問題の原因の XNUMX つは、Kubernetes やプラットフォームのその他の要素のバグではありません。また、移植しているマイクロサービスの根本的な欠陥にも対処していません。 さまざまな要素を組み合わせるというだけの理由で問題が発生することがよくあります。

私たちは、これまで相互作用したことのない複雑なシステムを混ぜ合わせて、それらが単一のより大きなシステムを形成することを期待しています。悲しいことに、要素が増えれば増えるほど、エラーの余地が増え、エントロピーが高くなります。

私たちの場合、高いレイテンシーは、Kubernetes、KIAM、AWS Java SDK、またはマイクロサービスのバグや間違った決定の結果ではありませんでした。これは、KIAM と AWS Java SDK の XNUMX つの独立したデフォルト設定を組み合わせた結果です。個別に考えると、AWS Java SDK のアクティブな証明書更新ポリシーと KAIM の証明書の短い有効期間という両方のパラメータが意味を持ちます。しかし、それらを組み合わせると、結果は予測不可能になります。 XNUMX つの独立した論理的なソリューションを組み合わせても意味をなす必要はありません。

翻訳者からの追伸

AWS IAM を Kubernetes と統合するための KIAM ユーティリティのアーキテクチャについて詳しくは、次の Web サイトをご覧ください。この記事クリエイターから。

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

出所： habr.com

「Kubernetes によりレイテンシが 10 倍増加した」: この責任は誰にあるのでしょうか?