Mixer アダプターモデル

Istio 0.2では、Mixerの柔軟性を向上させ、多様なインフラストラクチャバックエンドに対応することを目的とした新しいMixerアダプターモデルが導入されました。この投稿では、アダプターモデルをコンテキストに置き、その仕組みを説明します。

なぜアダプターが必要なのか？

インフラストラクチャバックエンドは、サービス構築に使用されるサポート機能を提供します。これには、アクセス制御システム、テレメトリキャプチャシステム、クォータ適用システム、課金システムなどが含まれます。従来、サービスはこれらのバックエンドシステムと直接統合されており、強い結合が生じ、特定のセマンティクスと使用オプションが組み込まれていました。

Mixerは、Istioとオープンエンドのインフラストラクチャバックエンドの集合との間の抽象化レイヤーとして機能します。メッシュ内で実行されるIstioコンポーネントとサービスは、バックエンドの特定のインターフェースに結合されることなく、これらのバックエンドと対話できます。

アプリケーションレベルのコードをインフラストラクチャバックエンドの詳細から隔離することに加えて、Mixerは、運用担当者がアプリケーションコードとバックエンドの間にポリシーを挿入および制御できる仲介モデルを提供します。運用担当者は、どのデータがどのバックエンドに報告されるか、承認のためにどのバックエンドを参照するかなどを制御できます。

個々のインフラストラクチャバックエンドにはそれぞれ異なるインターフェースと運用モデルがあるため、Mixerはそれぞれを処理するためのカスタムコードを必要とし、これらのカスタムコードのバンドルをアダプターと呼びます。

アダプターは、Mixerバイナリに直接リンクされるGoパッケージです。デフォルトのアダプターセットが特定のユースケースに不十分な場合、特殊なアダプターセットをリンクしたカスタムMixerバイナリを作成するのは比較的簡単です。

設計思想

Mixerは基本的に、属性処理とルーティングを行うマシンです。プロキシは、事前条件チェックとテレメトリレポートの実行の一部として、属性を送信し、Mixerはそれをアダプターへの一連の呼び出しに変換します。運用担当者は、受信属性をアダプターの入力にマッピングする方法を記述する構成を提供します。

構成は複雑な作業です。実際、証拠によると、サービスの中断の大部分は構成エラーによって引き起こされています。これに対処するために、Mixerの構成モデルは、エラーを回避するように設計された多くの制約を適用します。たとえば、構成モデルは厳密な型付けを使用して、特定のコンテキストで意味のある属性または属性式のみが使用されるようにします。

ハンドラー：アダプターの構成

Mixerが使用する各アダプターは、動作するために構成が必要です。通常、アダプターは、バックエンドへのURL、資格情報、キャッシングオプションなどを必要とします。各アダプターは、protobufメッセージを介して必要な正確な構成データを定義します。

各アダプターを構成するには、ハンドラーを作成します。ハンドラーは、使用準備が整った完全に構成されたアダプターを表す構成リソースです。単一のアダプターに対して複数のハンドラーが存在することができ、異なるシナリオでアダプターを再利用することが可能です。

テンプレート：アダプター入力スキーマ

Mixerは通常、メッシュサービスへの着信要求ごとに2回呼び出され、1回は事前条件チェック用、もう1回はテレメトリレポート用です。このような呼び出しごとに、Mixerは1つ以上のアダプターを呼び出します。異なるアダプターは、作業を行うために異なるデータを入力として必要とします。ロギングアダプターはログエントリを必要とし、メトリックアダプターはメトリックを必要とし、承認アダプターは資格情報を必要とするなどです。Mixerのテンプレートは、アダプターが要求時に消費する正確なデータを記述するために使用されます。

各テンプレートはprotobufメッセージとして指定されます。単一のテンプレートは、ランタイム時に1つ以上のアダプターに配信されるデータのバンドルを記述します。任意のアダプターは、任意の数のテンプレートをサポートするように設計できます。アダプターがサポートする特定のテンプレートは、アダプター開発者によって決定されます。

metricとlogentryは、Istioで使用される最も重要なテンプレートの2つです。これらは、それぞれ、適切なバックエンドに単一のメトリックと単一のログエントリを報告するペイロードを表します。

インスタンス：属性マッピング

個々のアダプターに配信されるデータを制御するには、インスタンスを作成します。インスタンスは、プロキシによって配信された属性を、異なるアダプターにルーティングできる個々のデータバンドルにMixerがどのように使用するのかを制御します。

インスタンスを作成するには、一般的に属性式を使用する必要があります。これらの式の目的は、任意の属性またはリテラル値を使用して、インスタンスのフィールドに割り当てることができる結果を生成することです。

すべてのインスタンスフィールドには、テンプレートで定義されている型があり、すべての属性には型があり、すべての属性式には型があります。型が互換性のある式のみを、任意のインスタンスフィールドに割り当てることができます。たとえば、整数式を文字列フィールドに割り当てることはできません。この種の厳密な型付けは、不正な構成を作成するリスクを最小限に抑えるように設計されています。

ルール：アダプターへのデータの配信

最後のピースは、どのインスタンスをどのハンドラーにいつ送信するかをMixerに指示することです。これは、ルールを作成することで行われます。各ルールは、特定のハンドラーと、そのハンドラーに送信するインスタンスのセットを識別します。Mixerが着信呼び出しを処理するたびに、指定されたハンドラーを呼び出し、処理のために特定のインスタンスのセットを提供します。

ルールには、一致する述語が含まれています。述語は、真/偽の値を返す属性式です。述語式がtrueを返す場合のみ、ルールが有効になります。そうでない場合は、ルールが存在しないのと同様に、指定されたハンドラーは呼び出されません。

将来

アダプターの使用と開発のエンドツーエンドエクスペリエンスを改善するために取り組んでいます。たとえば、テンプレートをより表現力豊かにするためのいくつかの新機能が計画されています。さらに、式言語は、より強力で包括的なものになるように大幅に強化されています。

長期的に見ると、メインのMixerバイナリに直接リンクされていないアダプターをサポートする方法を評価しています。これにより、展開と構成が簡素化されます。

結論

刷新されたMixerアダプターモデルは、オープンエンドのインフラストラクチャバックエンドの集合をサポートする柔軟なフレームワークを提供するように設計されています。

ハンドラーは個々のアダプターの構成データを提供し、テンプレートは異なるアダプターがランタイム時に消費したいデータの種類を正確に決定し、インスタンスは運用担当者がこのデータを準備し、ルールはデータを1つ以上のハンドラーに指示します。

Mixerの全体的なアーキテクチャの詳細についてはこちら、テンプレート、ハンドラー、ルールの詳細についてはこちらをご覧ください。BookinfoサンプルのMixer構成リソースの多くの例はこちらにあります。