Kubernetesでの分散システムの進化

原文(投稿日：2021/03/24)へのリンク

3月のQConで、Kubernetesを使用した分散システムの進化について講演しました。まず、マイクロサービスの後に何が来るのかという質問から始めたいと思います。きっと皆さんもその答えを持っていると思いますし、私もそうです。最後に、私がそれがどうなると思うかがわかります。そこにたどり着くには、分散システムのニーズを調べることを勧めします。そして、Kubernetesへのモノリシックアプリケーションから始まり、Dapr、Istio、Knativeなどのより最近のプロジェクトまで、これらのニーズが何年にもわたってどのように進化してきたか、そして分散システムの方法をどのように変えているか。将来についていくつかの予測を試みます。

最新の分散アプリケーション

この話にもう少しコンテキストを設定するために、私が分散システムと言うとき、念頭に置いているのは、複数のコンポーネント、数百のコンポーネントで構成されるシステムです。これらのコンポーネントは、ステートフル、ステートレス、またはサーバレスにできます。さらに、これらのコンポーネントは、ハイブリッド環境とオープンソーステクノロジーで開発され、オープンスタンダード、および相互運用性で実行されるさまざまな言語で作成できます。クローズドソースソフトウェアを使用してこのようなシステムを作成することや、AWSやその他の場所で作成することもできると確信しています。特に、Kubernetesエコシステムと、Kubernetesプラットフォームでそのようなシステムを作成する方法について講演します。

分散システムのニーズから始めましょう。私が念頭に置いているのは、アプリケーションまたはサービスを作成し、ビジネスロジックを記述したいということです。分散システムを構築するために、プラットフォームにランタイムの他に何が必要でしょうか? 基礎として、最初はいくつかのライフサイクル機能が必要です。アプリケーションを任意の言語で作成する場合、そのアプリケーションを確実にパッケージ化してデプロイし、ロールバックやヘルスチェックを実行できるようにする必要があります。また、アプリケーションをさまざまなノードに配置し、リソースの分離、スケーリング、構成管理などを行うことができるようにする必要があります。これらは、分散アプリケーションを作成するために最初に必要なものです。

2本目の柱はネットワーキングに関するものです。アプリケーションを作成したら、クラスタ内であろうと外部であろうと、他のサービスに確実に接続できるようにします。サービス検出、負荷分散などの機能が必要です。リリース戦略が異なる場合でも、その他の理由がある場合でも、トラフィックシフトを実行したいと考えています。次に、もちろん、再試行、タイムアウト、サーキットブレーカを介して、他のシステムと回復力のある通信を行う機能が必要です。適切な監視、トレース、可観測性などを取得してセキュリティを確保します。

ネットワークの次は、さまざまなAPIやエンドポイント、つまり、リソースバインディング - 他のプロトコルやさまざまなデータ形式と通信できるようにします。おそらく、あるデータ形式から別のデータ形式に変換することも必要でしょう。ここには、ろ光器 (light filtering) なども含めます。つまり、トピックをサブスクライブするときに、特定のイベントにのみ関心があるかもしれません。

最後のカテゴリーは何だと思いますか? それは状態です。私が状態とステートフル抽象化と言うときは、データベースの機能やファイルシステムなど、実際の状態管理については話していません。私は開発者が状態に依存している舞台裏の抽象化についてもっと話しています。おそらく、ワークフロー管理を行う能力が必要です。実行時間の長いプロセスを管理したり、一時的なスケジューリングやcronジョブを実行して、サービスを定期的に実行したい場合があります。おそらく、分散キャッシングを実行したり、べき等性を持たせたり、ロールバックを実行したりすることもできます。これらはすべて開発者レベルではプリミティブですが、舞台裏では、何らかの状態を持つことに依存しています。サウンド分散システムを作成するために、これらの抽象化を使いやすくする必要があります。

この分散システムプリミティブのフレームワークを使用して、Kubernetesやその他のプロジェクトでこれらがどのように変化しているかを評価します。

モノリシックアーキテクチャ - 従来のミドルウェアの機能

モノリシックアーキテクチャから始めて、それらの機能をどのように取得するかを考えてみましょう。その場合、私が最初にモノリスと言うとき、分散アプリケーションのコンテキストで念頭に置いているのはESBです。ESBは非常に強力であり、ニーズのリストを確認すると、ESBはすべてのステートフル抽象化に対して優れたサポートを提供していたと言えます。

ESBを使用すると、実行時間の長いプロセスのオーケストレーション、分散トランザクション、ロールバック、およびべき等を実行できます。さらに、ESBは優れたリソースバインディング機能も提供し、数百のコネクタを備え、変換、オーケストレーションをサポートし、さらにネットワーク機能も備えています。そして最後に、ESBはサービス検出と負荷分散を行うことさえもできます。

再試行できるなど、ネットワーク接続の復元力に関するすべてのものがあります。おそらく、ESBは本質的にあまり分散されていないため、非常に高度なネットワークやリリース機能は必要とされません。ESBに欠けているのは、主にライフサイクル管理です。これは単一のランタイムであるため、ひとつめは、単一の言語の使用に制限されていることです。これは通常、実際のランタイムが作成される言語、Java、.NET、またはその他のものです。次に、これは単一のランタイムであるため、宣言型デプロイメントを簡単に実行したり、自動配置を実行したりすることはできません。デプロイメントはかなり大きく、かなり重いため、通常は人との対話が必要です。そして、このようなモノリシックアーキテクチャのもう1つの問題は、スケーリングです。「個々のコンポーネントをスケーリングすることはできません。」

大事なことを言い忘れましたが、それがリソースの分離であろうと障害の分離であろうと、分離についてです。これらはいずれも、モノリシックアーキテクチャでは実行できません。私たちのニーズのフレームワークの観点から、ESBのモノリシックアーキテクチャは適格ではありません。

クラウドネイティブアーキテクチャ - マイクロサービスとKubernetes

次に、クラウドネイティブアーキテクチャと、それらのニーズがどのように変化しているかを確認することを勧めます。これらのアーキテクチャがどのように変化しているかを俯瞰すると、クラウドネイティブはおそらくマイクロサービスムーブメントから始まりました。マイクロサービスを使用すると、モノリシックアプリケーションをビジネスドメインごとに分割できます。コンテナとKubernetesは、実際にはこれらのマイクロサービスを管理するための優れたプラットフォームであることが判明しました。Kubernetesがマイクロサービスにとって特に魅力的になる具体的な機能と能力のいくつかを見てみましょう。

当初、ヘルスプローブを実行できることが、Kubernetesを人気のあるものにしました。実際には、コンテナをポッドにデプロイすると、Kubernetesがプロセスの状態をチェックします。通常、そのプロセスモデルは十分ではありません。まだ稼働中のプロセスがあるかもしれませんが、それは健全ではありません。そのため、準備 (readiness) チェックと活性 (liveness) チェックを使用するオプションもあります。Kubernetesは準備チェックを実行して、アプリケーションが起動時にトラフィックを受け入れる準備ができているかどうかを判断します。サービスの状態を継続的にチェックするために、活性チェックを実行します。Kubernetes以前は、これはあまり一般的ではありませんでしたが、今日では、ほとんどすべての言語、すべてのフレームワーク、すべてのランタイムに、エンドポイントをすばやく起動できるヘルスチェック機能があります。

Kubernetesが次に導入したのは、アプリケーションの管理されたライフサイクルに関するものです。つまり、サービスをいつ開始し、いつシャットダウンするかを制御できなくなったということです。それらの実行についてはプラットフォームを信頼します。Kubernetesはアプリケーションを起動できます。シャットダウンしたり、別のノードに移動することができます。これを機能させるには、起動時とシャットダウン時にプラットフォームから通知されるイベントを適切に実装する必要があります。

Kubernetesが人気を博したもう1つの点は、デプロイメントとその宣言型に関することです。つまり、サービスを開始する必要がなくなります。開始したかどうかログを確認してください。インスタンスを手動でアップグレードする必要はありません。宣言型デプロイメントを使用するKubernetesでアップグレードできます。選択した戦略に応じて、古いインスタンスを停止し、新しいインスタンスを開始できます。さらに、問題が発生した場合、ロールバックすることができます。

もう1つは、リソースの需要を宣言することです。サービスを作成するときは、それをコンテナ化します。サービスに必要なCPUとメモリの量をプラットフォームに通知することはよいプラクティスです。Kubernetesはその知識を使用して、ワークロードに最適なノードを見つけます。Kubernetes以前は、基準に基づいてインスタンスをノードに手動で配置する必要がありました。これで、Kubernetesを好みに合わせ最善の決定が下されるようにガイドできるようになります。

現在、Kubernetesでは、多言語構成管理を行うことができます。アプリケーションランタイムでは、構成ルックアップを行うために何も必要ありません。Kubernetesは、構成がワークロードと同じノードに配置されることを確認します。構成は、アプリケーションで使用できるようにボリュームまたは環境変数としてマップされます。

私が今話した特定の機能も関連していることがわかりました。たとえば、自動配置を行う場合は、サービスのリソース要件をKubernetesに通知する必要があります。次に、使用するデプロイメント戦略を指示しなければなりません。戦略が正しく機能するためには、アプリケーションは環境からのイベントを実装する必要があります。ヘルスチェックを実装する必要があります。これらのベストプラクティスをすべて導入し、これらの機能をすべて使用すると、アプリケーションは優れたクラウドネイティブ市民になり、Kubernetesで自動化する準備が整います (これは、Kubernetesでワークロードを実行するための基本的なパターンを表しています) 。そして最後に、ポッド内のコンテナの構造化、構成管理、および動作に関しては他のパターンがあります。

次のトピックとして、ワークロードに関して簡単に説明したいと思います。ライフサイクルの観点から、さまざまなワークロードを実行できるようにしたいと考えています。Kubernetesでも同じことができます。Twelve-Factor Appsとステートレスマイクロサービスの実行は非常に簡単です。Kubernetesはそれを行うことができます。持っているものは、それだけが唯一のワークロードではありません。おそらく、ステートフルワークロードもあり、ステートフルセットを使用してKubernetesで行うことができます。

あるかもしれないもう一つのワークロードはシングルトンです。アプリのインスタンスをクラスタ全体でアプリの唯一のインスタンスにしたい場合があります。- 信頼性の高いシングルトンにしたい場合があります。失敗した場合は、再起動する必要があります。したがって、ニーズと、シングルトンに少なくとも1つまたは多くても1つのセマンティクスを持たせるかどうかに応じて、ステートフルセットとレプリカセットのどちらかを選択できます。もう1つのワークロードは、ジョブとcronジョブに関するものです。Kubernetesを使用すると、それらも実行できます。

これらすべてのKubernetes機能をニーズにマッピングすると、Kubernetesはライフサイクルのニーズを満たします。私が通常作成する要件のリストは、主にKubernetesが今日提供しているものに基づいています。これらはどのプラットフォームからも期待される機能であり、Kubernetesがデプロイに対して実行できるのは、構成管理、リソース分離、および障害の分離です。さらに、サーバレスそのものを除いて、さまざまなワークロードをサポートします。

それでは、Kubernetesが開発者に提供するのがそれだけだとしたら、Kubernetesをどのように拡張するのでしょうか? そして、どうすればより多くの機能を提供できるようになるのでしょうか? したがって、今日使用されている2つの一般的な方法について説明したいと思います。

アウトオブプロセス拡張メカニズム

まず、ポッドの概念です。これは、ノードにコンテナをデプロイするために使用される抽象化です。さらに、ポッドは2セットの保証を提供します:

• 最初のセットはデプロイメント保証です。ポッド内のすべてのコンテナは常に同じノードに配置されます。つまり、ローカルホストを介して、またはファイルシステムを使用して非同期に、または他のIPCメカニズムを介して相互に通信できます。
• ポッドが提供するもう1つの保証は、ライフサイクルに関するものです。ポッド内のすべてのコンテナが同じというわけではありません。

initコンテナとアプリケーションコンテナのどちらを使用しているかによって、異なる保証が得られます。たとえば、initコンテナが最初に実行されると、ポッドが起動して、次々と順番に実行されます。これらは、前のコンテナが正常に完了した場合にのみ実行されます。これらは、コンテナによって駆動されるワークフローのようなロジックの実装に役立ちます。

一方、アプリケーションコンテナは並行して実行されます。それらはポッドのライフサイクル全体で実行され、これがサイドカーパターンの基盤です。サイドカーは、ユーザに協力して共同で価値を提供する複数のコンテナを実行できます。これは、Kubernetesを追加機能で拡張するために現在見られる主要なメカニズムの1つです。

次の機能を説明するために、Kubernetesが内部でどのように機能するかを簡単に説明する必要があります。これは、調整ループに基づいています。調整ループの考え方は、目的の状態を実際の状態にドライブすることです。Kubernetes内では、多くのビットがそれに依存しています。たとえば、2つのポッドインスタンスが必要だと言う場合、これがシステムに求める状態です。ポッドのインスタンスが2つあるかどうかを継続的に実行し、チェックする制御ループがあります。2つのインスタンスが存在しない場合、1つまたは2つ以上ある場合は、差が計算されます。2つのインスタンスがあるようにします。

これには多くの例があります。一部はレプリカセットまたはステートフルセットです。リソース定義はコントローラが何かにマップされ、リソース定義ごとにコントローラがあります。このコントローラは、現実の世界が目的の世界と一致することを確認するように、独自のカスタムコントローラを作成することもできます。

ポッドでアプリケーションを実行していて、実行時に構成ファイルの変更をロードできない場合があります。しかし、構成マップの変更を検出するカスタムコントローラを作成し、ポッドとアプリケーションを再起動して、構成の変更を取得させることができます。

Kubernetesには優れたリソースのコレクションがありますが、さまざまなニーズすべてに対応するには不十分であることがわかりました。Kubernetesは、カスタムリソース定義の概念を導入しました。つまり、要件をモデル化して、Kubernetes内に存在するAPIを定義できます。それは他のKubernetesネイティブリソースの隣にあります。モデルを理解できる任意の言語で独自のコントローラを作成できます。以前に説明したことを記述するJavaで実装されたConfigWatcherを設計できます。これがオペレーターパターンであり、カスタムリソース定義を操作するコントローラです。今日、多くのオペレーターが登場しています。これは、追加機能でKubernetesを拡張するための2番目の方法です。

次は、Kubernetes上に構築されたいくつかのプラットフォームについて簡単に説明します。これらのプラットフォームは、サイドカーとオペレーターを多用して開発者に追加機能を提供します。

Service Meshとは何か?

サービスメッシュから始めましょう。サービスメッシュとは何でしょうか?

2つのサービスがあります。どの言語でもよいですが、サービスBを呼び出したいサービスAがあります。これがアプリケーションのワークロードであると考えてください。サービスメッシュはサイドカーコントローラを使用し、サービスの隣にプロキシを挿入します。ポッド内に2つのコンテナができあがります。プロキシは透過的なものであり、アプリケーションはプロキシが存在することを完全に認識していません。プロキシはすべての着信トラフィックと発信トラフィックをインターセプトしています。さらに、プロキシはデータファイアウォールとしても機能します。

これらのサービスプロキシのコレクションはデータプレーンを表し、小さくてステートレスです。すべての状態と構成を取得するには、コントロールプレーンに依存します。コントロールプレーンは、すべての構成を保持し、メトリックを収集し、決定を下し、データプレーンと対話するステートフルな部品です。さらに、これらはさまざまなコントロールプレーンやデータプレーンに適しています。そして、結局のところ、もう1つのコンポーネント、つまりデータをクラスタに取り込むためのAPIゲートウェイが必要です。一部のサービスメッシュには独自のAPIゲートウェイがあり、一部はサードパーティを使用しています。これらのコンポーネントはすべてそれらの中を調べて必要な機能を提供します。

APIゲートウェイは、主にサービスの実装を抽象化することに重点を置いています。詳細を非表示にし、境界機能を提供します。サービスメッシュはその逆です。ある意味で、サービス内の可視性と信頼性を向上させます。合わせて、APIゲートウェイとサービスメッシュがすべてのネットワーキングニーズを提供すると言えます。Kubernetesの上にネットワーク機能を追加するには、サービスだけを使用するだけでは不十分です。「サービスメッシュが必要です。」

Knativeとは何か?

私が話したい次のトピックはKnativeです - プロジェクトは、数年前にGoogleによって開始されました。これは、サーバレス機能を提供するKubernetesの上のレイヤであり、2つの主要なモジュールがあります:

• Knative Serving - 要求と応答の相互作用に焦点を当て、
• Knative Eventing - よりイベント駆動型の相互作用に。

あなたにイメージを与えましょう、Knative Servingとは何でしょうか? Knative Servingを使用してサービスを定義しますが、それはKubernetesサービスとは異なります。これはKnativeのサービスです。Knativeサービスを使用してワークロードを定義すると、サーバレスの特性を備えたデプロイメントが得られます。インスタンスを稼働させる必要はありません。リクエストが到着すると、ゼロから開始できます。サーバレス機能を利用できます。急速にスケールアップしたり、ゼロまでスケールダウンできます。

Knative Eventingは、完全に宣言型のイベント管理システムを提供します。統合したい外部システム、外部イベントプロデューサがあるとしましょう。下部には、HTTPエンドポイントを持つコンテナー内のアプリケーションがあります。Knative Eventingを使用すると、ブローカを開始できます。ブローカは、Kafkaがマップするブローカをトリガすることも、メモリまたはクラウドサービスに配置することもできます。さらに、外部システムに接続してブローカにイベントをインポートするインポータを開始することもできます。これらのインポータは、たとえば、数百のコネクターを持つApache Camelをベースにすることができます。

イベントをブローカに送信し、宣言的なYAMLファイルを使用して、コンテナをそれらのイベントにサブスクライブできます。コンテナには、Kafkaクライアントなどのメッセージングクライアントは必要ありません。コンテナは、クラウドイベントを使用してHTTP POSTを介してイベントを取得します。これは、完全にプラットフォーム管理されたメッセージングインフラストラクチャです。開発者は、ビジネスコードをコンテナに記述する必要があり、メッセージングロジックを処理する必要はありません。

私たちのニーズの観点から、Knativeはそれらのいくつかを満たしています。ライフサイクルの観点からは、ワークロードにサーバレス機能を提供するため、ゼロにスケーリングし、ゼロからアクティブ化して上昇することができます。ネットワークの観点から、サービスメッシュとの重複がある場合、Knativeはトラフィックシフトも実行できます。バインディングの観点からは、Knativeインポータを使用したバインディングをかなりサポートしています。これは私たちにPub/Sub、またはポイントツーポイントの相互作用、あるいはいくつかの順序付けを与えることができます。これはいくつかのカテゴリーのニーズを満たします。

Daprとは何か?

サイドカーとオペレーターを使用する別のプロジェクトのDaprは、ほんの数か月前にMicrosoftによって開始され、急速に人気が高まっています。さらに、バージョン 1.0はプロダクションレディと見なされます。これはサイドカーとしての分散システムツールキットです。Daprのすべてがサイドカーとして提供され、ビルディングブロックと呼ばれるもののセットまたは機能のセットがあります。

機能には何があるのでしょうか? 機能の最初のセットはネットワーキングに関するものです。Daprは、サービス検出とサービス間のポイントツーポイント統合を行うことができます。同様に、トレース、信頼性の高い通信、再試行、およびサービスメッシュへのリカバリも実行できます。機能の2番目のセットは、リソースバインディングに関するものです:

• クラウドAPI、さまざまなシステム等への多くのコネクタがあり
• publish/subscribeメッセージングやその他のロジックも実行できる。

興味深いことに、Daprは状態管理の概念も導入しています。Knativeとサービスメッシュが提供するものに加えて、Daprはステートストアの上に抽象化も持っています。さらに、ストレージメカニズムに裏打ちされたDaprとのKey-Valueベースの対話を行うことができます。

大まかには、このアーキテクチャはどの言語かに関わらずアプリケーションを最上位に配置することです。Daprが提供するクライアントライブラリを使用できますが、使用する必要はありません。言語機能を使用して、サイドカーと呼ばれるHTTPおよびgRPCを実行できます。サービスメッシュとの違いは、ここではDaprサイドカーが透過プロキシではないことです。これは、アプリケーションから呼び出してHTTPまたはgRPCを介して対話する必要がある明示的なプロキシです。必要な機能に応じて、Daprはクラウドサービスなどの他のシステムと通信できます。

Kubernetesでは、Daprはサイドカーとしてデプロイされ、Kubernetesの外部で動作できます (それは、Kubernetesだけではありません) 。さらに、それにはオペレーターもあり、サイドカーとオペレーターが主要な拡張メカニズムです。他のいくつかのコンポーネントは、証明書を管理し、アクターベースのモデリングを処理し、サイドカーを注入します。ワークロードはサイドカーと相互作用し、他のサービスと通信するためのすべての魔法を実行して、さまざまなクラウドプロバイダとの相互運用性を提供します。また、追加の分散システム機能も提供します。

これらのプロジェクトが提供していることを要約すると、ESBは、集中型のコントロールプレーンとデータプレーンを備えた分散システムの初期の化身であると言えますが、拡張性は十分ではありませんでした。クラウドネイティブの集中型コントロールプレーンはまだありますが、データプレーンは分散型であり、遮音機能を備え高度にスケーラブルです。

優れたライフサイクル管理を行うには、常にKubernetesが必要です。さらに、1つ以上のアドオンが必要になる可能性があります。高度なネットワーキングを行うには、Istioが必要になる場合があります。Knativeを使用してサーバレスワークロードを実行するか、Daprを使用して統合を実行できます。これらのフレームワークは、IstioおよびEnvoyとうまく連携します。DaprとKnativeの観点からは、おそらく1つを選択する必要があります。合わせて、それらはクラウドネイティブな方法でESBが持っていたものを提供しています。

未来のクラウドネイティブトレンド - ライフサイクルトレンド

次のパートでは、これらの分野でエキサイティングな開発が行われていると思ういくつかのプロジェクトの意見リストを作成しました。

ライフサイクルから始めたいと思います。Kubernetesを使用すると、アプリケーションの有用なライフサイクルを実行できますが、より複雑なライフサイクル管理には不十分な場合があります。たとえば、より複雑なステートフルアプリケーションがある場合、Kubernetesのデプロイメントプリミティブではアプリケーションに十分ではないシナリオが存在する可能性があります。

これらのシナリオでは、オペレーターパターンを使用できます。デプロイメントとアップグレードを行うオペレーターを使用して、サービスのストレージをS3にバックアップすることもできます。さらに、Kubernetesの実際のヘルスチェックメカニズムが十分ではないことに気付くかもしれません。活性チェックと準備チェックが十分ではないとします。その場合、オペレーターを使用して、アプリケーションのよりインテリジェントな活性と準備状況のチェックを実行し、それに基づいてリカバリーを実行できます。

3番目の領域は、自動スケーリングと調整です。オペレーターにアプリケーションをよりよく理解してもらい、プラットフォームで自動調整を行うことができます。現在、オペレーターを作成するためのフレームワークは主に2つあります。Kubernetes Special InterestグループのKubebuilderと、RedHatによって作成されたオペレーターフレームワークの一部であるOperator SDKです。それにはいくつかのものがあります:

Operator SDKを使用すると、オペレーターのライフサイクルの管理に関するオペレーター (Operator Lifecycle Manager) と、オペレーターを公開できるOperatorHubを作成できます。現在、そこに行けば、100を超えるオペレーターがデータベース、メッセージキュー、および監視ツールを管理していることがわかります。ライフサイクル空間から見ると、おそらくオペレーターは、Kubernetesエコシステムで最も活発な開発が行われている領域です。

ネットワーキングトレンド - Envoy

私が選んだもう1つのプロジェクトはEnvoyです。サービスメッシュインターフェイス仕様の導入により、さまざまなサービスメッシュ実装の切り替えが容易になります。デプロイメントでは、Istioアーキテクチャがある程度統合されています。コントロールプレーンに7つのポッドを配置する必要はありません。これで、一度だけデプロイできます。さらに興味深いのは、Envoyプロジェクトのデータプレーンで何が起こっているかです。Envoyに追加されるレイヤー7プロトコルがますます増えていることがわかります。

サービスメッシュは、MongoDB、ZooKeeper、MySQL、Redisなどのより多くのプロトコルのサポートを追加し、最新のものはKafkaです。Kafkaコミュニティは現在、プロトコルをさらに改善して、サービスメッシュに適したものにしているようです。より緊密な統合、より多くの機能が期待できます。ほとんどの場合、いくつかのブリッジ機能があります。サービス内のアプリケーションからローカルでHTTP呼び出しを行うことができ、プロキシはバックグラウンドでKafkaを使用します。Kafkaプロトコルのサイドカーで、アプリケーションの外部で変換と暗号化を行うことができます。

もう1つのエキサイティングな開発は、HTTPキャッシングの導入です。これで、EnvoyはHTTPキャッシングを実行できます。アプリケーション内でキャッシュクライアントを使用する必要はありません。それはすべてサイドカーで透過的に行われます。タップフィルターがあるので、トラフィックをタップしてトラフィックのコピーを取得できます。最近では、WebAssemblyの導入により、Envoyのカスタムフィルタを作成する場合、C++ で作成してEnvoyランタイム全体をコンパイルする必要がなくなりました。フィルタをWebAssemblyで記述し、実行時にデプロイできます。これらのほとんどはまだ進行中です。それらはそこになく、データプレーンとサービスメッシュを停止する意図はありません、HTTPとgRPCをサポートするだけであることを示しています。それらは、より多くのユースケースを有効にするために、より多くのアプリケーションレイヤプロトコルをサポートして、より多くを提供することに関心を持っています。ほとんどの場合、WebAssemblyの導入により、サイドカーでカスタムロジックを記述できるようになりました。そこにビジネスロジックを配置しない限り、問題ありません。

バインディングトレンド - Apache Camel

Apache Camelは統合を行うためのプロジェクトであり、エンタープライズ統合パターンを使用したさまざまなシステムへの多数のコネクターがあります。たとえば、Camel version 3は、Kubernetesに深く統合されており、オペレーターなど、これまでに説明したものと同じプリミティブを使用します。

統合ロジックは、Java、JavaScript、YAMLなどの言語でCamelで記述できます。最新バージョンでは、Kubernetesで実行され、統合を理解するCamelオペレーターが導入されています。Camelアプリケーションを作成し、それをカスタムリソースにデプロイすると、オペレーターはコンテナを構築する方法や依存関係を見つける方法を知ることができます。プラットフォームの機能に応じて、それがKubernetesのみであるかどうか、Knativeを使うKubernetesであるかどうかに応じて、使用するサービスと統合を実現する方法を決定できます。ランタイムの外に出て行くインテリジェンスはかなりたくさんあります、オペレーターにもありますが、そのすべてが非常に高速に行われます。なぜそれがバインディングトレンドだと言えるのでしょうか? それは、主に、Apache Camelが提供するすべてのコネクタを備えた機能のためです。ここで興味深い点は、Kubernetesとどのように深く統合されているかです。

ステートトレンド - Cloudstate

私が話したいもう1つのプロジェクトは、Cloudstateとステート関連のトレンドに関するものです。また、CloudstateはLightbendによるプロジェクトであり、主にサーバレスで関数駆動の開発に重点を置いています。最新のリリースでは、サイドカーとオペレーターを使用してKubernetesと緊密に統合されています。

関数を作成するとき、関数が行う必要があるのは、gRPCを使用して状態を取得し、状態と対話することだけです。状態管理全体は、他のサイドカーとクラスタ化されたサイドカーで行われます。これにより、イベントソーシング、CQRS、Key-Valueルックアップ、メッセージングを実行できます。

アプリケーションの観点からは、これらすべての複雑さに気付いているわけではありません。あなたがすることはローカルのサイドカーを呼び出すことだけで、サイドカーが複雑さを処理します。舞台裏では、2つの異なるデータソースを使用できます。そして、それは開発者として必要とするであろうすべてのステートフルな抽象化を持っています。

これまで、クラウドネイティブエコシステムの最新技術と、現在も進行中の最近の開発のいくつかを見てきました。そのすべてをどのように理解したでしょうか?

マルチランタイムマイクロサービスがここにある

マイクロサービスがKubernetesでどのように表されるかを見ると、いくつかのプラットフォーム機能を使用する必要があります。さらに、主にライフサイクル管理にKubernetesの機能を使用する必要があります。そして、ほとんどの場合、透過的に、サービスはEnvoyなどのサービスメッシュを使用して、トラフィックルーティング、復元力、強化されたセキュリティ、または監視目的であっても、強化されたネットワーク機能を取得します。さらに、ユースケースに応じて、ワークロードによってはDaprまたはKnativeが必要になる場合があります。これらはすべて、アウトオブプロセスの追加機能を表しています。あなたに残されているのは、ビジネスロジックをトップではなく、別のランタイムとして書くことです。おそらく、未来のマイクロサービスは、複数のコンテナで構成されるこのマルチランタイムになるでしょう。それらのいくつかは透過的であり、それらのいくつかは非常に明示的に使用します。

スマートなサイドカーと間抜けなパイプ

もう少し深く見てみると、それがどのように見えるか、あなたはビジネスロジックを高級言語で書いています。それが何であるかは関係ありません。他の言語を使用してカスタムロジックを社内で開発できるため、Javaだけである必要はありません。

ビジネスロジックと外部世界とのすべての相互作用は、プラットフォームと統合されたサイドカーを介して行われ、ライフサイクル管理を行います。外部システムのネットワーク抽象化を行い、高度なバインディング機能と状態抽象化を提供します。サイドカーはあなたが開発したものではありません。既製のものです。少しのYAMLまたはJSONで構成し、それを使用します。つまり、サイドカーはランタイムに組み込まれなくなったため、簡単に更新できます。パッチの適用、更新が簡単になります。これにより、ビジネスロジックのポリグロットランタイムが可能になります。

マイクロサービスの後に何が来るのでしょうか?

私に最初の質問をもたらします、マイクロサービスの後に何が来るのでしょうか?

アーキテクチャがどのように進化しているかを見ると、大きく俯瞰してモノリシックアプリケーションのアプリケーションアーキテクチャから始まりました。それでも、マイクロサービスは、モノリシックアプリケーションを個別のビジネスドメインに分割する方法に関する指針を提供します。その後、サーバレスとFunction-as-a-Service (FaaS) が登場しました。ここでは、各操作を個別にスケーリングできるため、操作ごとにさらに分割できるため、極端なスケーリングが可能であると述べました。

関数は、同じデータセットと対話する必要があるときに複数の操作を一緒に配置する必要がある合理的に複雑なサービスを実装するための最適なモデルではないため、FaaSが最適なモデルではない可能性があります。おそらく、マルチランタイム、私はそれをMechaアーキテクチャと呼んでいますが、ここでは、ビジネスロジックが1つのコンテナにあり、インフラストラクチャに関連するすべての関心事が別のコンテナにあります。これらは共同で、マルチランタイムマイクロサービスを表します。それはより良い特性を持っているので、多分それがより適切なモデルです。

マイクロサービスのすべてのメリットを享受できます。あなたはまだすべてのドメイン、すべての境界づけられたコンテキスト (bounded context) を1か所に持っています。すべてのインフラストラクチャと分散アプリケーションのニーズが別々のコンテナにあり、実行時にそれらを組み合わせます。おそらく、今それに近づいている最も近いものはDaprです。それらはこのモデルに従っています。ネットワークの側面からのみ関心がある場合は、おそらくEnvoyの使用もこのモデルに近づいています。

著者について

Bilgin Ibryam氏は、Red Hatのプロダクトマネージャであり、元アーキテクトであり、コミッタであり、Apache Software Foundationのメンバです。彼はオープンソースのエバンジェリストであり、レギュラーのブロガであり、スピーカであり、Kubernetes PatternsとCamel Design Patterns本の著者です。Bilgin Ibryam氏の現在の仕事は、分散システム、イベント駆動型アーキテクチャ、および反復可能なクラウドネイティブアプリケーション開発のパターンと実践にフォーカスしています。同様のトピックに関する今後の更新については、@bibryam をフォローしてください。