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