MixerとSPOF神話

可用性の向上とレイテンシの削減。

2017年12月7日 | Martin Taillefer

Mixerがリクエストパス上にあるため、それがシステム全体の可用性とレイテンシにどのように影響するか疑問に思うのは当然です。Istioのアーキテクチャ図を初めて見た人がよく言うのは、「これは単一障害点（SPOF）を導入しているだけではないか？」ということです。

この記事では、Mixerを支える設計原則と、Mixerが実際にはメッシュ全体の可用性を向上させ、平均リクエストレイテンシを削減するという驚くべき事実について詳しく説明します。

IstioでのMixerの使用は、システム全体の可用性とレイテンシに関して2つの主な利点があります。

以下で詳しく説明します。

これまでの経緯

長年にわたりGoogleでは、Googleが公開する多数のAPIを処理するために、内部APIおよびサービス管理システムを使用してきました。(Google Maps、YouTube、Gmailなど)世界最大のサービスを支え、ピーク時には数億QPSを維持しています。このシステムはGoogleにとって役立ってきましたが、Googleの急速な成長に追いつくことができず、運用コストの急増を抑えるために新しいアーキテクチャが必要であることが明らかになりました。

2014年、よりスケーラブルな代替アーキテクチャを作成するための取り組みを開始しました。その結果は非常に成功し、Google全体に徐々に展開され、その過程で月に数百万ドルの運用コストを削減しました。

旧システムは、すべての着信トラフィックが流れ込み、実際の作業が行われるサービスに転送される前に、かなり負荷の高い共有プロキシの集中型フリートを基盤として構築されていました。新しいアーキテクチャは共有プロキシ設計を廃止し、代わりにサービスインスタンスの横に配置された非常に軽量で効率的な分散サイドカープロキシと、シャーディングされた共有制御プレーン仲介者のフリートで構成されています。

Google System Topology
GoogleのAPIおよびサービス管理システム

見覚えがありますか？そうです、Istioと同じです！Istioは、この分散プロキシアーキテクチャの第2世代として考案されました。この内部システムから重要な教訓を学び、パートナーとの協力によって多くの概念を一般化し、Istioを作成しました。

アーキテクチャの概要

以下の図に示すように、Mixerはメッシュとそれをサポートするインフラストラクチャバックエンドの間に位置しています。

Istio Topology
Istioトポロジー

Envoyサイドカーは、事前条件チェックを実行するために各リクエストの前に論理的にMixerを呼び出し、テレメトリを報告するために各リクエストの後に呼び出します。サイドカーにはローカルキャッシングがあるため、比較的多くの事前条件チェックをキャッシュから実行できます。さらに、サイドカーは発信テレメトリをバッファリングするため、数千リクエストごとにMixerを実際に呼び出す必要があるだけです。事前条件チェックはリクエスト処理に対して同期処理ですが、テレメトリレポートはファイアアンドフォーゲットパターンで非同期処理されます。

高いレベルで、Mixerは以下を提供します。

しかし、これらの純粋に機能的な側面を超えて、Mixerにはシステムに追加の利点をもたらす他の特性もあります。

Mixer：SLOブースター

MixerはSPOFであり、メッシュの停止につながる可能性があると主張するのに反して、実際にはメッシュの有効な可用性を向上させると考えています。それはどのように可能なのでしょうか？3つの基本的な特性が作用しています。

メッシュ内の各サービスインスタンスの横に存在するサイドカープロキシは、メモリ消費量の点で必ず節約する必要があります。これは、ローカルキャッシングとバッファリングの可能性のある量を制限します。しかし、Mixerは独立して存在し、はるかに大きなキャッシュと出力バッファを使用できます。したがって、Mixerはサイドカーの高度にスケールされた、高可用性の第2レベルキャッシュとして機能します。

Mixerの予想される可用性は、ほとんどのインフラストラクチャバックエンド（多くの場合、可用性は99.9％程度です）よりもはるかに高くなります。そのローカルキャッシュとバッファは、バックエンドが応答しなくなった場合でも動作を継続できるため、インフラストラクチャバックエンドの障害を隠すのに役立ちます。

Mixer：レイテンシ削減

前述のように、Istioサイドカーは一般的にかなり効果的な第1レベルのキャッシングを持っています。それらは、キャッシュからトラフィックの大部分を処理できます。Mixerははるかに大きな共有第2レベルキャッシュを提供し、Mixerがリクエストあたりの平均レイテンシの低下に貢献するのに役立ちます。

レイテンシを削減している間、Mixerはメッシュがインフラストラクチャバックエンドへの呼び出し数を本質的に削減しています。これらのバックエンドの支払い方法によっては、バックエンドへの有効なQPSを削減することで、コスト削減につながる可能性があります。

今後の作業

システムをさまざまな方法で改善する機会があります。

構成カナリア

Mixerは高度にスケールされるため、個々のインスタンスの障害には一般的に耐性があります。しかし、Mixerは、すべてのMixerインスタンスがほぼ同時にクラッシュする有毒な構成が展開された場合（はい、それは最悪な日になります）、カスケード障害の影響を受けやすいままです。このような事態を防ぐために、構成の変更は少数のMixerインスタンスにカナリア展開してから、より広範囲に展開できます。

Mixerはまだ構成の変更をカナリア展開していませんが、Istioの信頼性の高い構成配布に関する継続的な作業の一部として、これがオンラインになることを期待しています。

キャッシュチューニング

サイドカーとMixerのキャッシュのサイズを微調整していません。この作業は、最小限のリソースを使用して可能な限り最高の性能を達成することに重点を置きます。

キャッシュ共有

現時点では、各Mixerインスタンスは他のすべてのインスタンスとは独立して動作します。1つのMixerインスタンスによって処理されたリクエストは、別のインスタンスにキャッシュされたデータを利用しません。最終的には、memcachedやRedisなどの分散キャッシュを試して、はるかに大きなメッシュ全体の共有キャッシュを提供し、インフラストラクチャバックエンドへの呼び出し数をさらに削減します。

シャーディング

非常に大きなメッシュでは、Mixerへの負荷が大きくなる可能性があります。多数のMixerインスタンスがあり、それぞれが着信トラフィックを満たすためにキャッシュを準備しようと苦労しています。最終的には、Mixerインスタンスが特定のデータストリームの処理に少し特化して、キャッシュヒットの可能性を高めるようなインテリジェントなシャーディングを導入する予定です。言い換えれば、シャーディングは、任意の利用可能なMixerインスタンスにランダムにディスパッチするのではなく、関連するトラフィックを時間とともに同じMixerインスタンスにルーティングすることで、キャッシュ効率を向上させるのに役立ちます。

結論

Googleでの実践的な経験から、スリムなサイドカープロキシと大規模な共有キャッシング制御プレーン仲介者のモデルは、優れた認識された可用性とレイテンシを提供する最適なポイントに達することがわかりました。そこで得られた教訓を活かし、Istioでより洗練された効果的なキャッシング、プリフェッチ、バッファリング戦略を適用しました。また、キャッシュミスが発生した場合のオーバーヘッドを削減するために、通信プロトコルを最適化しました。

Mixerはまだ若い技術です。Istio 0.3の時点では、Mixer自体では本格的なパフォーマンス作業を行っていません。つまり、リクエストがサイドカーキャッシュにヒットしなかった場合、リクエストに応答するためにMixerで想定以上に多くの時間を費やしています。今後数か月で、同期事前条件チェックの場合にMixerが与えるオーバーヘッドを削減するために、多くの作業を行っています。

この記事によって、MixerがIstioにもたらす固有のメリットを理解していただければ幸いです。istio-policies-and-telemetry@にコメントや質問を投稿することを遠慮なく行ってください。

この記事を共有する