マイクロサービスの問題を修正する

ここ数年、マイクロサービスとサービス指向アーキテクチャが大流行しています。その後すぐにコンテナ化が進み、OSや依存ライブラリを実際のアプリケーションと一緒にパッケージ化することで、インストールされたプラットフォームからデプロイされたプラットフォームを抽象化するのに役立ちました。

しかし、光があれば影もあります。マイクロサービスを使用することには独自の課題が伴います。非常に包括的なリストをこちらで見つけました。主な利点と欠点を見てみましょう。

マイクロサービスの開発、デプロイメント、運用の主な課題

良い点

1. 原子性: 自律型サービスは、開発と実行の観点から個別に扱うことができます（インターフェースを除く）。
2. 回復力: 個々のサービスは通常、他のサービスの障害に影響されず、より良い回復力を発揮します。
3. スケーラビリティ: 個々のサービスは、必要に応じて弾力的にスケールできます。

悪い点

1. 疎結合: マイクロサービスは通常、お互いのことや広範な実行コンテキストを知りません。それらは本質的に原子的です。間の通信にはオーバーヘッドがあり、標準化されていません。
2. モニタリング: 多様なマイクロサービスの包括的なモニタリングは非常に困難で、ほぼ不可能です。異なるサービス間での個々の問題を明確に明らかにすることは、さまざまな種類のログが散在しているため、サービス間の不明瞭な依存関係やトランザクションの広がりなどのために非常に困難です。
3. デバッグ: 複雑な分散マイクロサービスアーキテクチャで発生するエラーは、追跡するのに非常に時間がかかり、費用がかかることがあります。包括的なモニタリングシステムはなく、個々のログやスタックトレースを調査して、エラーの原因を安全に結論付ける必要があります。
4. セキュリティ: マイクロサービスの本質的な特徴はそのインターフェース/APIです。特に分散環境では、セキュリティに関して特別な注意が必要です。このような複雑なフレームワーク環境では、監視と制御を失うのは簡単です。
5. 回復力: 異なるチームによって開発された多くの異なるタイプのマイクロサービスがある場合、適切なフェイルオーバーメカニズムを確保することが指数関数的に困難になります。これにより、1つまたは複数のマイクロサービスが失敗したときに、システム全体が適切に動作することができます。
6. デプロイメント: 複雑なセットアップでの個々のマイクロサービスのデプロイメントは、ダウンタイムなしでオーケストレーションするのが難しく、すべてを再起動せずに達成することは時には不可能です。
7. 通信: マイクロサービス間の通信の標準化が必要です。シリアル化、セキュリティ、リクエストオプション、エラーハンドリング、期待される応答のリストなどに関して、何らかのトップレベルの設計オーケストレーションが非常に必要です。そうでなければ、通信の失敗やレイテンシーの問題が発生します。

これらは課題の一部に過ぎません。メンテナンス、ネットワーキング、チーム管理など、他にも多くの課題があります。

解決策: マイクロサービスではなくマイクロコンフィグレーション

マイクロサービスのアイデアは素晴らしいですが、非常に速く厄介になることがあります。自然に、マイクロサービスの良い部分を保持し、悪い部分を避ける方法があるかどうかという疑問が生じます。

マイクロコンフィグレーションがここで役立つかもしれません。マイクロコンフィグレーション（またはMicroConfig）を、実際のサービスロジック（コンフィグレーション）とサービス実行（エンジン）の分離として定義します。

このコンテキストでのコンフィグレーションは、ビジネスロジック、つまりデータに対して何をするか、どのアクションをトリガーするかなどに限定されます。

実行は、コンフィグレーションの実行を可能にするすべてのものです：

• ロジック（コンフィグレーション）の実行、
• 活動と問題の集中化および標準化されたログ記録、
• サービス間の実行のオーケストレーション
• モニタリングのためのメトリクス報告
• デバッグサポート
• サービス境界を越えた標準化された通信
• その他多くのこと。

これは技術の世界では新しい概念ではありません。

例: 典型的なデータベースは、データベース構造（テーブル、インデックス、制約など）とデータベースエンジン（解釈、保存、提供）を区別します。エンジンはすべてのユーザーにとって同じですが、構造はユニークです。それでも、テーブルをエンジンに直接ハードコードするという考えを抱く人はいません。コンフィグとエンジンの分離が、データベースを最初に汎用的にするものであり、それぞれが特別な目的と力を持っています。

layline.ioは、サービスがいわゆるワークフローコンフィグレーションとして実装されており、モノリシックな実行可能ファイルとしてではない点で似ています。無制限の数の異なるワークフローを定義できます。ワークフローはリアクティブエンジンによって実行され、これがノード上で実行されます。たとえば、Kubernetes PodやRaspberry Piがノードになります。2つ以上のエンジンが論理的なリアクティブクラスターを形成します。セットアップは完全に要件と環境に依存します。理論的には無期限の数のエンジン（ノード上）が生成され、地理的に分散された論理クラスターで実行されることができます。エッジコンピューティングはここでの興味深いユースケースの1つです。すべてが同じタイプのリアクティブエンジン上で実行されるため、物理レベルで何をデプロイするかを考える必要はありません。

ワークフローコンフィグレーションのデプロイメントは、コンフィグレーションがリアクティブクラスター内のノードに公開され、クラスターがその後自動的にクラスター全体にコンフィグレーションを伝播することで自動的に行われます。これにより、マイクロサービスをPodや実際の物理ノードに低レベルで物理的にデプロイすることを心配する必要がなくなります。クラスターに新しいノードが追加されると、コンフィグレーションデータを自動的に受け取り、すぐに処理を開始できます。

layline.ioには、回復力、スケーラビリティ、フェイルオーバーが組み込まれています。クラスターの継続的なモニタリングにより、ワークフローインスタンスの設定されたスケールの遵守が保証され、ノード障害が発生した場合にワークフローのワークロードが自動的に再バランスされます。

中央のモニタリングとログ記録により、リアクティブクラスター内の問題が即座に発見されます。物理レベルに干渉することなく、UIを通じて一般的に対策が提供されます。

layline.ioプラットフォーム内のすべては、実行レベルで標準化されていますが、コンフィグレーションレベルではオープンです。これにより、インフラストラクチャが実際にどのように動作するかについての難しい部分を心配することなく、必要なものを設定できます。

フレームワークの概念は、ハードコアな「低レベルのみ」の開発者が受け入れたがらないかもしれませんが、技術的にもビジネス的にも非常に理にかなっています。自分でデータベースをプログラムすることはないでしょう、そうではありませんか？

リソース

• 分散システム管理のためのマイクロサービス使用のトップ10の課題
• マイクロサービスがサービスメッシュ異常検出を切実に必要とする理由
• layline.ioについてもっと読むにはこちら。
• hello@layline.ioでお問い合わせください。