優れた特徴により、複雑なアプリの構築にマイクロサービスが広く利用されています。この開発手法にはいくつかのアプローチがあり、特にオーケストレーションとコレオグラフィーが人気です。
それぞれに独自の特徴があり、メリットとデメリットが存在します。戦略を選ぶ前に、各要素を十分に理解することが重要です。
簡単に言えば、複数のサービスを組み合わせ、内部でデータのやり取りを可能にする論理的なサービス管理の仕組みです。
その基礎はオーケストラ理論にあります。
この仕組みは、複数のマイクロサービスが連携し、アプリを構築する点で、即時に演奏するオーケストラが傑作を生み出す様子に例えられます。
各マイクロサービスは、優れた音楽が生まれるよう、個々のミュージシャンが協力するイメージです。
また、指揮者の役割も重要です。音楽オーケストラでは、指揮者が各演奏者の演奏を確認し、楽譜に沿って演奏できるよう管理します。
ここでの指揮者は、すべてのミュージシャンが正しい順序で演奏するよう見守ります。
「マイクロサービスオーケストレーション」において、指揮者はリクエストを処理する親サービスとして機能し、連携する各サービスがリクエストを確認し、必要なデータを取得できるようにします。
親サービスは各サービスからのレスポンスを集約し、主要なオーケストレーターに送ります。また、顧客側のアプリへ情報を伝達するとともに、APIリクエスト処理に必要な各サービスと継続して通信する役割を担います。
メリット
オーケストレーションフレームワークは各サービスを活用し、全体のアプリを監視する代わりに、アプリ作成に関わる個々のプロセスを確認します。特定のプロセスから定期的にデータを集め、検証できるようにしているため、開発者はワークフローを部分ごとに把握しやすくなります。
上記の通り、オーケストレーションではワークフローの改善が容易で、開発のニーズに合わせてすべてを同期させることができます。
基盤レベルからすべてのプロセスを把握できるため、スケールアウトも迅速かつ容易に実現できます。各マイクロサービス周辺で発生する様々な取引を円滑に全体のアプリと連携させることが可能です。
オーケストレーションでは、ワークフロー内のエラー箇所を容易に特定できます。単にバグを見つけるだけでなく、その原因やデバッグ方法も明らかにできます。
これらのメリットは魅力的ですが、同時に多くの制約も存在します。例えば、非常に時間がかかる点です。1つのアプリ開発には数千のサービスが関与する場合があり、その同期には多大な時間が必要となります。
デメリット
時間がかかる点に加え、マイクロサービスオーケストレーションは依存性が高い手法です。オーケストレーターはすべてのマイクロサービスと連携し、データにアクセスできるようにしなければなりません。データがなければ機能しません。
また、すべてのマイクロサービスが連携しているため、1つのサービスの障害が全体に影響を及ぼします。
この手法を採用する際は、実装を容易にする優れたマイクロサービスオーケストレーションツールについて学ぶ必要があります。最も知られているツールはKubernetesで、幅広い機能を持ち、ほぼすべての開発シナリオで利用されています。オーケストレーターとして活用されます。
もしKubernetesの代替を検討する場合は、Docker SwarmやMesosも候補になります。どちらも同様に機能し、実用的です。
CrossplaneはCNCF管理のオーケストレーションプラットフォームで、現在試験段階にあります。さらに、Karmada、Fluid、Volcano、wasmCloud、Open Cluster Managementなど、5種類のオーケストレーターが間もなく利用可能になる予定です。
マイクロサービスにおけるコレオグラフィーは、ここでのオーケストレーションの正反対を意味します。完全に分散化された手法で、各サービスの段取りを担当します。この概念は、踊り手が自ら踊らずに振付師がパフォーマンスを演出するダンス集団に例えられます。
ダンスグループの踊り手が各自の役割を果たすように、コレオグラフィー方式のマイクロサービスも自らのワークフローを担います。
また、Kubernetesのようなミドルウェアとしてのオーケストレーターの概念も存在しますが、ここでは不要な要素となっています。すべての軽量なサービスは自律的に動作し、第三者の介入なしで機能します。
マイクロサービスは疎結合であり、開発の柔軟性を大いに高めます。疎結合であるため、1つのサービスの動作が他に影響しにくく、アプリ開発の複雑さをやや軽減します。また、個別のプログラミングや管理のためのコントローラーは必要ありません。
この方式には単一のノードが存在しないため、疑問が生じます:
ミドルウェアが存在しない場合、どのように通信が行われるのでしょうか?
この方式の鍵となるのは、メッセージブローカーとも呼ばれるイベントブローカーです。各マイクロサービスは、関連サービスから受信したメッセージに基づいて自動的に自らの役割を果たします。
この仕組みにより、通信は非同期で行われ、各サービスはイベントブローカーを監視しながら動作します。
また、疎結合のロジックにより、関係するマイクロサービスは必要に応じて変更可能ですが、基盤となるロジックはそのまま保たれます。
メリット
コレオグラフィーパターンのマイクロサービスには、顕著なメリットとデメリットが存在し、両面を十分に理解していることが理想です。
まずメリットからご説明します。この方式は、最小限の労力でメッセージ交換の自動化を実現するのに最適です。効果的かつ分散化された制御ロジックにより、メッセージの自動化が容易に行えます。
オーケストレーションとは異なり、依存性が低いため、各マイクロサービスは独自の立場とプロセスを持ち、単一障害点が存在しません。エラーやバグは各アーキテクチャ内に留まり、スケーラビリティにおいてもコレオグラフィーはオーケストレーションより有利です。
また、パフォーマンスに影響を与えることなくスケールアウトが容易に実現できる点も魅力です。さらに、プロセスを変更してもアプリの主要なロジックに影響を与えないため、本来の効果を維持できます。
デメリット
まず、この方式はすべての人に適しているわけではなく、利用前に考え方を変える必要がある点をご理解いただきたいです。全く異なる仕組みで動作するため、マインドセットの転換が不可欠です。
次に、ビジネスプロセスが各マイクロサービスに分散しているため、管理がやや困難です。各サービスが独立して大きな自律性を持つため、運用の維持が非常に大変となります。疎結合の性質が複雑さを増す要因にもなっています。
さらに、扱う複雑さはオーケストレーションと比べて格段に高いです。関与する各マイクロサービスは固有のロジックで制御され、同じソースからのAPIメッセージに対しても異なる反応を示すため、リソースが異なると非常に複雑になります。その結果、障害のリスクが増大します。
また、この方式ではイベントブローカーに加え、サービスメッシュやランタイムDAPRなど、複数のツールが必要となるため、導入が難しい場合があります。3種類のツールを調達・維持するのは、すべての企業にとって現実的でないのに対し、オーケストレーションは1種類のツール(オーケストレーター)のみで済むため、利用範囲が広がります。
この方式を自動的に適用し、円滑に運用するためには、Kafka、Amazon SQS、RabbitMQなどのコレオグラフィーツールが有効です。いずれもイベントブローカーとして主要な役割を果たします。また、IstioのようなサービスメッシュやDAPRといったランタイムシステムも利用されます。
前述のオーケストレーション方式とコレオグラフィー方式にはそれぞれ欠点があるため、両方式のメリットを最大限に活かし、制約を最小限に抑える中間的な手法が求められます。
幸いにも、ハイブリッドアプローチという手法があります。この方式は非同期と同期の両方の要素を持ち、オーケストレーションの概念に基づく完全な一元管理コンポーネントを備えています。これにより、コレオグラフィー方式では得られない主要ワークフローの広範な可視化が可能となります。
しかし、この方式にも欠点は存在します。オーケストレーション同様、ハイブリッド方式はオーケストレーターに大きく依存しており、エラーが発生すれば全体に深刻な影響を及ぼします。また、ロジックの変更も非常に手間がかかります。
この詳細な分析から、どちらの方式も一長一短であると結論付けられます。メリットと制約の両面があるため、どちらを選ぶかはプロジェクトの要求次第です。
結局のところ、プロジェクトに求める内容によります。プロジェクトの実装方法、具体的な要件、最終目標、そして利用可能な資源を十分に検討する必要があります。
極めて高いスケーラビリティと複雑な処理への対応が求められる場合は、マイクロサービスのコレオグラフィーが推奨されます。
一方、アプリの各側面をしっかり管理し、安定した実装を目指す場合は、開発の状況が明確になるオーケストレーションを採用するのが適しています。
サービスベースの開発手法に関心のある方は、オーケストレーションとコレオグラフィーの詳細な比較検討を行う必要があります。どちらもマイクロサービスアーキテクチャの実装に広く用いられており、それぞれ独自の働きを持っています。
オーケストレーションは結合性が高く、実装が容易である一方、コレオグラフィーは疎結合で複雑です。どちらを採用するかは、様々な要素を考慮する必要があります。
本記事は、オーケストレーションとコレオグラフィーの主要な違いを明確にすることを目的としています。マイクロサービスアーキテクチャは優れた手法ですが、その本質を十分に理解することが欠かせません。Wallarmでは、マイクロサービスに関する記事を多数掲載しておりますので、ぜひご覧いただければ幸いです。
最新情報を購読