Kubernetes を使用してインフラストラクチャの回復性を実装する
インフラストラクチャ ベースの回復性を実装するには、"サービス メッシュ" を使用できます。 コードを変更せずに回復性を確保すること以外に、サービス メッシュでは、トラフィック管理、ポリシー、セキュリティ、強力な ID、監視が提供されます。 これらの運用機能は、アプリから切り離されて、インフラストラクチャ レイヤーに移動されます。 アーキテクチャ的には、サービス メッシュは、コントロール プレーンとデータ プレーンという 2 つのコンポーネントで構成されます。
"コントロール プレーン" コンポーネントには、サービス メッシュの管理をサポートする多くのコンポーネントがあります。 通常、コンポーネント インベントリには次のものが含まれます。
- 管理インターフェイス。UI または API です。
- サービス メッシュによる特定の機能の実装方法が定義されているルールとポリシーの定義。
- mTLS に対する強力な ID や証明書などのセキュリティ管理。
- アプリからメトリックとテレメトリを収集して集計するためのメトリックまたは監視。
"データ プレーン" コンポーネントは、各サービスと共に透過的に挿入されるプロキシで構成されます。これは、サイドカー パターンと呼ばれています。 各プロキシは、サービスが含まれるポッドを出入りするネットワーク トラフィックを制御するように構成されます。 この構成では、各プロキシを次のように構成できます。
- mTLS によりトラフィックをセキュリティで保護する。
- トラフィックを動的にルーティングする。
- トラフィックにポリシーを適用する。
- メトリックとトレース情報を収集する。
Kubernetes クラスター用の一般的なサービス メッシュ オプションには、Linkerd、Istio、Consul などがあります。 このモジュールでは、Linkerd に焦点を当てます。 次の図は、データ プレーンとコントロール プレーン内のコンポーネント間の相互作用を示したものです。
コード ベースのアプローチとの比較
Linkerd の主要なエラー処理戦略は、再試行とタイムアウトで構成されます。 Linkerd にはクラスター全体の体系的なビューがあるため、斬新な方法で回復性戦略を導入できます。 たとえば、ターゲット サービスに対して加わる負荷が最大 20% になるように再試行を設定できます。 Linkerd のメトリック ベースのビューを使用すると、リアルタイムでクラスターの状態に動的にそれを適応できます。 この方法では、クラスターの管理に別のディメンションが追加されますが、コードは追加されません。
Polly のようなコード ベースのアプローチでは次のようになります。
- どの再試行パラメーターとタイムアウト パラメーターが適切であるかを推測する必要があります。
- 特定の HTTP 要求に注目します。
アプリのコードでインフラストラクチャの障害に対応するための適切な方法はありません。 同時に処理される数百または数千の要求を考慮することになります。 指数バックオフ (掛ける要求数) による再試行でさえ、サービスが過負荷になる可能性があります。
これに対し、Linkerd のようなインフラストラクチャ ベースのアプローチでは、アプリの内部構造は認識されません。 たとえば、複雑なデータベース トランザクションは、Linkerd には見えません。 そのようなトランザクションは、Polly を使用して障害から保護できます。
以降のユニットでは、Polly と Linkerd を使って、クーポン サービスに復元性を実装します。