Kubernetes/Docker上の従来のマイクロサービスモデルには、管理が過度に複雑でリソース消費が多いという欠点があります。この記事では、layline.ioがコンテナとコンテナオーケストレーション技術をどのように取り入れ、上述の課題をより良いアプローチで解決するのかを説明します。
クイック解説: Kubernetes (K8S) & Docker
コンテナ
Kubernetes上で動作するプログラムはコンテナにパッケージ化されます。ソフトウェアと依存関係が一緒にパッケージ化されるという利点があります。これにより、コンテナの独立性が保証され、心配事が一つ減ります。DockerHubなどのポータルから、あらゆる種類のソフトウェアをパッケージ化した既製のコンテナをダウンロードできます。
理論的には、一つのコンテナに多くのプログラムを詰め込むことができますが、推奨される業界標準は「1コンテナ = 1プロセス」です。これにより、すべてがより細かくなり、個々のコンテナ（したがってプロセス）をより簡単に置き換えることができます。
ポッド
コンテナは単独では動作せず、別の「コンテナ」にパッケージ化されます。この場合、それはポッドと呼ばれます。ポッドは、コンテナ内で動作する仮想リソース（ネットワーク、メモリ、CPUなど）を管理します。
重要なのは、CPUパワーをコンテナに割り当てるのではなく、ポッドに割り当てるということです。したがって、同じポッドで複数のコンテナを実行する場合、ポッドに利用可能なリソースをすべて共有する必要があります。同じ理由で、1つのコンテナに複数のプログラムを入れるべきではないように、1つのポッドに複数のコンテナを入れるべきではありません。複数のコンテナがマイクロサービスの目的を果たすために必要でない限り。
Kubernetesでのスケーリング時のリソース問題
Kubernetesでは、スケーラビリティの通貨はポッドです。より多くの処理能力を得るためには、より多くのポッドを起動します。これをレプリケーションと呼びます。
この設計を見てみると、ポッド自体は実際には非常に静的です。最大限の柔軟性を保ち、あるプログラムを別のプログラムに置き換えることができるようにするには、ポッドには1つのコンテナが含まれ、そのコンテナには1つのプログラムが含まれ、1つのプロセスとして実行されます。
コンテナに必要な実際のリソースはポッドレベルで構成されていることを考慮すると、画像は次のようになります：
「スラック」としてマークされたスペースを確認してください。コンテナのリソースをサイズ設定するときには、CPUとメモリに多少の余裕を持たせる必要があります。しかし、1つのプログラムに必要なリソースを正確に決定することはほぼ不可能であるため、各ポッドにいくらかの予備が生じます。これを100個実行すると、スラックが100倍になります。ポッド間でのリソース共有はありません。さらに、クラスターに追加される各ポッドとノードにはいくらかのオーバーヘッドがあります。したがって、K8Sのコンセプトは全体的に素晴らしいですが、全体的にかなりのリソースオーバーヘッドも追加されます。
Kubernetesクラスター内でのコンテナの分散
ポッドは、Kubernetesクラスター内で機能を分散するための最小単位でもあります。例えば、マイクロサービスA、B、Cがあり、それらをクラスター内で不均等に分散させたい場合、A、B、Cのいずれかを含む個々のポッドを持つか、A、B、Cのコンテナを含むポッドのすべての組み合わせを作成するためのポッドの数を持たなければなりません（例：AとBを含むポッド、AとCを含むポッドなど）。管理するポッドが多くなり、すぐに圧倒され非効率的になります。
ポッドの分散は、Kubernetesおよび/または選択したCI/CDツール内での主要な構成の課題となります。これに加えて、ノード間の自動スケーリングと負荷分散の管理が加わり、大規模なセットアップと監視の頭痛の種になります。
Kubernetesクラスターにおけるlayline.ioのスケーラビリティ、リソース、および分散の取り扱い
Reactive Engine
layline.ioはReactive Engineを導入します。このエンジンは、Reactive Engine内で実行するように構成できるWorkflowsの実行コンテキストとして機能します。Workflowsは、特定のデータ処理タスクを実行する点でマイクロサービスに似ており、インジェスト、分析、強化、クエリ要求への応答などを行います。Workflowsは、WebベースのConfiguration Centerを使用して構成されます：
複数のReactive Engineが独自のReactive Clusterを形成します。Kubernetesのようなクラスター環境でlayline.ioを設定する場合、実際にはコンテナにカプセル化されたReactive Engineを実行するノードの数を設定します：
すべてのReactive Engineは平等に作成されます。彼らはWorkflowsの実行コンテキストとして機能します。簡単に言えば、Workflowsはマイクロサービスと同等と見なすことができます。違いは、Workflowsが構成されているため、典型的なマイクロサービスのようなプログラムされたオブジェクトコードではなく、構成であるということです。
各Reactive Engineは異なるWorkflows（上記のA、B、C）を実行できます。各Workflowは動的に複数回インスタンス化できます。インスタンスの数は、単一のWorkflowインスタンスが消費するリソースの量と、Reactive Engine自体が実行される実行コンテキストに利用可能で割り当てられたリソースの量によって制限されます。Kubernetesクラスターでは、これは対応するポッドのイメージになります：
任意のReactive Engineは任意のWorkflowを実行できます。Workflowsは、Configuration Centerを介して直接、または選択したCI/CDツール（例：Bambooなど）を介してデプロイされます。
これにより、次のようなセットアップが可能になります：
弾力的スケーリング
各Workflowのインスタンスの数は、Config Centerまたはコマンドラインからの手動介入、またはデータ圧力に基づいて自動的に動的にスケーリングアップおよびダウンできます。
追加のポッドを起動することでスケールするという標準のKubernetesの方法は有効ですが、ポッド内で追加のWorkflowインスタンスを単に起動することができます。この例では、各ポッドにスケールするための十分な余裕があるため、追加のポッドはアクティブ化されません。このプロセスはすべてReactive Engine内でスケールされるため、非常に迅速かつ効率的であり、インスタンスごとに必要な追加リソースは少なく、Kubernetesレベルでの介入は不要です。
リソースの利点
30のポッドを3つのノードに同じマイクロサービスで分散するか、3つのReactive Engineを3つのノードにそれぞれ同じWorkflowの10インスタンスで分散するかに関係なく、相応のCPUパワーとRAMが必要になると考えるのは理にかなっています。しかし、それはそうではありません。
Workflowに置き換えられるマイクロサービスの特性に応じて、通常、マイクロサービスを従来の方法でデプロイするのに比べて、25〜50％のリソースを節約できます。ただし、1つのWorkflowインスタンスのみを実行するReactive Engineは、1回だけ実行されるカスタムマイクロサービスよりも多くのリソースを必要とすることも事実です。
柔軟性とリソース要件の間のトレードオフであり、処理シナリオの規模が大きくなるにつれてlayline.ioモデルの方が有利になります。
セットアップの利点
Kubernetes/Dockerクラスターにlayline.ioを設定することは、すべてのノードに同じコンテナをデプロイすることを意味します。各コンテナはReactive Engineを実行し、異なるコンテンツを持つ他のコンテナタイプはありません。1つだけです。
Reactive EngineがどのWorkflowsを実行するかを知るためには、実行時に構成が注入されます。すべてのReactive Engineが独自のReactive Clusterを形成するため、1つのReactive Engineに構成を注入するだけで十分です。それはクラスター内の他のすべてのエンジンに自動的に分配されます。これもすべて手動で、またはCI/CDツールを通じて自動的にトリガーできます。
したがって、純粋なKubernetes/Dockerのコンセプトとは異なり、変更ごとに再構築され、デプロイメントの観点から管理される必要がある異なるコンテナを含む異なるポッドの手間はありません。Kubernetesとは異なり、事前にどのポッド/コンテナをどこで実行するかを考える必要はなく、再配置したい場合にポッドをどのように移動するかを考える必要もありません。layline.ioでは、1つまたは複数のReactive Engineで事前にロードされたWorkflowを単にアクティブ化するか、クラスターに新しいWorkflow構成をデプロイしてこのWorkflowをオンラインにすることができます。
まとめ
| アスペクト | Kubernetes/Docker | layline.io |
|---|---|---|
| スケーリング | ポッドを介してスケール | ポッド内でWorkflowインスタンスを介してスケール |
| スケーリング反応時間 | 中程度 | 速い |
| リソース消費 | 小規模シナリオに優れる | 中規模から大規模シナリオに優れる |
| セットアップ | 多くの異なるポッドとコンテナ | Reactive Engineに注入された構成 |
Kubernetesは素晴らしいです。しかし、複雑さと運用において欠点があります。
layline.ioは、サービスを作成および管理するだけでなく、クラスター環境でそれらを管理および分散するためのはるかに優れた、スリムな方法を提供します。中規模から大規模のシナリオでは、リソース管理と消費に関しても大きな利点があります。
layline.ioを無料でダウンロードして使用できます こちら。layline.ioについて質問がある場合は、こちらからお気軽にお問い合わせください！
リソース
- layline.ioをダウンロード
- マイクロサービスの問題を修正する
- layline.ioについてもっと読む こちら。
- hello@layline.io でお問い合わせください。
