TOPSoftware > マイクロサービスの普及とともに存在感を増すサービスメッシュ(...

Software

マイクロサービスの普及とともに存在感を増すサービスメッシュ(下)

2019/08/09

Josh Fruhlinger InfoWorld

 IT界で、デジタルトランスフォーメーションの旗印のもとに起きている変化の1つが、モノリシックアプリケーションからマイクロサービスへという転換だ。大規模な一枚岩的アプリケーションを、個別の機能を提供するサービスに細分化し、それぞれ別のコンテナで動かす。コードや依存関係をサービス単位で切り分けることができ、別のサーバーへの移動も簡単だ。

前回から続く)

サービスメッシュのアーキテクチャー

Credit: geralt

 サービスメッシュの概念ができてからまだ数年の現時点では、マイクロサービスの通信を管理する方法にはいくつかの種類がある。米Aspen MeshのAndrew Jenkins最高技術責任者(CTO)は、サービスメッシュの通信レイヤーの実装形態としては、次の3つの手法を挙げている。

  • ライブラリ:それぞれのマイクロサービスがライブラリをインポートして使う。
  • ノードエージェント:各ノードで稼働するエージェントが、同じノードのすべてのコンテナに対してサービスを提供する。
  • サイドカー:アプリケーションのコンテナと対になる形でサイドカーのコンテナが稼働する。

 サイドカーを使う手法は、サービスメッシュのパターンとして最も一般的で、広く使われている。そこで、サイドカーについてもう少し詳しく見てみよう。

サービスメッシュのサイドカーとは

 アプリケーションのコンテナと対になる形でサイドカーのコンテナが稼働する、と先ほど述べたが、これはどういうことか。Red Hatの説明にもあるとおり、サイドカーを使うタイプのサービスメッシュでは、マイクロサービスのそれぞれのコンテナと対になるようにプロキシのコンテナを配置する。サービス間の通信に必要なロジックはすべて、抽象化された形でマイクロサービスの外にくくり出され、サイドカーに実装されている。

 この構成では、アプリケーションで使うコンテナの数が実質的に倍になり、複雑に思えるかもしれない。だがこれは、分散型のアプリケーションをシンプルにするうえで鍵となるデザインパターンに沿っている。ネットワーキングや通信に関するコードを別のコンテナに切り出してインフラの一部とすることで、開発者はそうしたコードをアプリケーションの中に実装する必要がない。

 つまり、個々のマイクロサービスは、ビジネスロジックのみに焦点を絞れる。世の中の多種多様なサービスや、複雑な稼働環境の数々と通信する方法について、各サービスが知っている必要はない。サイドカーとの通信の方法さえ分かっていれば、あとはサイドカーが面倒を見てくれる。

↑ページ先頭へ