この記事を参照することで、マイクロサービス アーキテクチャとそれをいつ使用するかについて、より良いアイデアを得ることができます。なお、本記事は以下の内容で構成されています。

◼記事の略称

◼はじめに

◼ マイクロサービスエコシステム

◼ モノリス アーキテクチャとマイクロサービス アーキテクチャ

◼ マイクロサービスの課題

◼ マイクロサービスをいつ使用するか

略語

• API : アプリケーション プログラミング インターフェイス
• MS : マイクロサービス
• NoSQL : SQLだけではない
• RTE : ランタイム環境

マイクロサービスアーキテクチャは、大規模なアプリケーションが一連のモジュラー サービスとして構築されるアプリケーション開発へのアプローチです(つまり、マイクロサービスは、アプリケーションがサービスのコレクションとして開発されるアプリケーション アーキテクチャの一種です)。各モジュールは、特定のビジネス目標をサポートし、明確に定義された単純なインターフェイスを使用して他のサービス セットと通信します。さらに、Java、Python などのさまざまなプログラミング言語で記述され、マイクロサービス アーキテクチャでリレーショナルや NoSQL などのさまざまなデータ ストレージ テクノロジを使用する可能性のある、最小限の集中管理サービスがあります。

マイクロサービスの主な機能/特徴は次のとおりです。

• 保守性とテスト性が高い
• 疎結合 (インターフェースを介して通信)
• 独立して展開可能
• ビジネス機能を中心に編成
• 少人数のチーム (クロスファンクショナル チーム) が所有

一般に、マイクロサービス システムには、次のエンティティが含まれます。これらのエンティティの一部は標準ソフトウェア開発のフェーズであり、一部は効率的なマイクロサービス システムのバックボーンを提供するマイクロサービス固有のプロセスです。

ロードバランサー

ロード バランサーの主な役割は、受信負荷を多数のマイクロサービス インスタンスに分散することです。主に、クライアント検出 (クライアント側ロード バランサー) とサーバー検出 (サーバー側ロード バランサー) と呼ばれる 2 種類のロード バランサーがあります。クライアント検出では、クライアントはサービス レジストリと通信し、負荷分散を行います。そのため、クライアントはサービス レジストリを認識する必要があります。サーバー検出では、クライアントはロード バランサーと通信し、ロード バランサーはサービス レジストリと通信します。したがって、クライアント サービスはサービス レジストリを認識する必要はありません。次の図を見ると、これら 2 種類のロード バランサーについて理解を深めることができます。

サービス検出サーバー

サービス検出機能により、マイクロサービスは、現在デプロイされているマイクロサービスと必要なホストとポートを手動で追跡する代わりに、起動時に自己登録できます。したがって、MS1 が MS2 と対話したい場合、まず、MS1 はランドスケープに属するレジストリ サービスから詳細を取得してから、MS2 と対話します。さらに、MS3 と呼ばれる別の MS が同じランドスケープ内で稼働または停止している場合、レジストリ サービスは自動的に更新されます。

API ゲートウェイ

API ゲートウェイはサーバーです。これは、システムへの単一のエントリ ポイントです。API Gateway は、内部システム アーキテクチャをカプセル化します。各クライアントに合わせた API を提供します。また、認証、モニタリング、ロード バランシング、キャッシング、リクエストのシェーピングと管理、静的なレスポンスの処理なども担当します。API ゲートウェイは、リクエストのルーティング、構成、プロトコル変換も担当します。クライアントからのすべてのリクエストは、API ゲートウェイを通過します。その後、API ゲートウェイはリクエストを適切なマイクロサービスにルーティングします。

API Gateway は、次の 2 つの方法のいずれかでリクエストを処理します。

• リクエストを適切なサービスにルーティングまたはプロキシしました。
• リクエストを複数のサービスにファンアウト (分散) します。

これで、同じエコシステム内のさまざまなノードで実行されている多数のマイクロサービスがあることがわかりました。したがって、単一のシステムでそれらをまとめて監視する必要があります。Hystrix ダッシュボードと Spring Boot 管理ダッシュボードは、監視ツールの例です。マイクロサービスの監視には、次の 5 つの原則があります。

• コンテナとその中身を監視します。
• サービスのパフォーマンスに関するアラート。
• 柔軟で複数の場所にあるサービスを監視します。
• API を監視します。
• 組織構造を監視する

マイクロサービスを実装する場合、マイクロサービスの実装はさまざまなテクノロジを使用して実行できるため、JRE や Node.js などのさまざまな RTE で実行されます。また、これらのマイクロサービスがポリグロット方式でデプロイされていることもわかっています。したがって、ノードはデプロイされたマイクロサービスの RTE を認識しないため、各ノードに手動でインストールする必要があります。しかし、コンテナ化に関しては、RTE をマイクロサービスにパッケージ化します。したがって、RTE を考慮せずにどこでもマイクロサービスを実行でき、これらのサービスを簡単に管理および更新できます。

サーキットブレーカー

これは、マイクロサービスのエコシステムにおいて非常に重要なエンティティです。ほとんどの場合、これはパターンとして定義されます。理解のために言うと、これは家庭のサーキット ブレーカーとほとんど同じです。災害からあなたを守り、発生した問題の伝播を止めます。マイクロサービスに関して、ここ (MS のサーキット ブレーカー) で同じシナリオが発生しています。クライアントがサプライヤ マイクロサービスにリクエストを送信し、レスポンスが送信されている間に接続の問題が発生したとします。そのため、クライアントは応答を長時間待ち、他のサービスにも影響を与える可能性があります。サーキット ブレーカー アーキテクチャ以降、問題のあるチャネルは破棄され、以前の待機の問題は解決されます。さらに、クローズドと呼ばれるサーキット ブレーカーの 3 つの異なる状態があります。、オープンとハーフオープン。

モノリス アーキテクチャとマイクロサービス アーキテクチャ

価格

• モノリシック : プロジェクトが拡大すると、より高くなります
• マイクロサービス : 最初の開発段階で高い

• モノリシック : 製品全体の統合されたコードベースとデータベース
• マイクロサービス : 複数のコード ファイル。各サービスはベースとデータ ストレージを処理します

• モノリシック : コード ベース全体をデプロイする必要があります
• マイクロサービス : 各マイクロサービスは個別にデプロイされます

• モノリシック: 同じコード スタック
• Microservice : さまざまなスタック (言語、ランタイム環境など)

マイクロサービスを扱う場合、次のようないくつかの課題があります。

• プロセス間通信（ネットワーク経由）
• 分散トランザクション
• 多数のサービス
• さらに自動化が必要

これで、マイクロサービスとその課題についてよく理解できました。マイクロサービスに適したシナリオを見てみましょう。

• 同社は、クリーンで読み取り可能なコードをすぐに構築し、技術的負債を回避したいと考えています
• 同社にはマイクロサービス開発のための人材がいる
• 会社は短期的な利益よりも長期的な利益を優先します
• 開発者のチームは、さまざまな技術スタックとツールを使用しています
• プラットフォームは高度にスケーラブルで、さまざまな市場に拡張する必要があります