It is the top of the page

Link for moving within the page
To text (c)

このウェブサイトではサイトの利便性の向上のためにクッキーを利用します。サイトの閲覧を続行されるには、クッキーの使用にご同意いただきますようお願いします。
お客様のブラウザの設定によりクッキーの機能を無効にすることもできます。詳細はこちら

The main part starts here.

  1. ナレッジセンター
  2. Net One BLOG

サービスメッシュ入門

Net One BLOG
アーキテクチャ
クラウド
仮想化

写真:井上 碧

井上 碧

コンテナの利活用が広く進み、マイクロサービスアーキテクチャの採用を耳にすることが増えてきました。本記事ではマイクロサービスアーキテクチャや連携して使用される技術サービスメッシュをご紹介します。

マイクロサービスアーキテクチャ

サービスメッシュを説明する前に、クラウド、コンテナ環境のサービスを運用するアーキテクチャの1つ「マイクロサービスアーキテクチャ」を整理します。マイクロサービスアーキテクチャとは、端的に言うと1つのシステムに複数の小さなサービスを組み合わせて開発する手法のことです。James Lewis氏とMartin Fowler氏が2014年3月に公開した記事 “Microservices” が有名ですが、コンテナ型仮想技術が普及するにつれて注目が集まっています[1]。

マイクロサービスアーキテクチャの利点はいくつかありますが、本ブログでは次の3つを取り上げます。


サービスごとのスケールアウト

マイクロサービスでは、各サービスが単一プロセスとして動作するため必要なサービスのみスケールアウトすることが可能です。一部のマイクロサービスのみスケールアウトすれば良いため、システム全体で使用するリソースを最適化することができます。


独立したデプロイ

マイクロサービスは、疎結合で構成され、他のサービスに影響しないため、小さな修正であっても組織の調整を行わずに再デプロイすることが可能です。各サービスは、あらかじめ規定したAPIのエンドポイントに沿って開発を行います。よって、サービスの境界であるエンドポイントに変更を加えない限り、各チームで修正を加えてビルドやテストといった改善が行えます。


サービスごとのテクノロジーの採用

各マイクロサービスでは、それぞれが独立したサービスとなっているため、異なるテクノロジーを組み合わせて利用することが可能です。そのため、サービス全体で共通のテクノロジーを採用しなくてよく、サービスごとに合ったプログラミング言語やデータベースの使用を検討できます。

1. マイクロサービスの利点

一方で、マイクロサービスは以下のような課題が挙げられます。

  • パフォーマンス : APIコールは、ネットワークを介すためメモリ処理に比べると遅い
  • 分散システムのモニタリング : サービス間通信の可視化やログ収集が難しい
  • ネットワーク障害 : APIコール時のリトライ処理、スロットリング処理が必要
  • セキュリティ : サービス間の通信の暗号化や認証・認可の機能が必要
  • サービスの特定 : サービスの参照先がダイナミックに変更される環境下でサービスの特定(サービスディスカバリ)が難しい

このような課題を各開発チームで実装することは、明らかに困難です。そこで、この問題を従来のアプリケーションレイヤでなく、新しいネットワークレイヤで解決するのがサービスメッシュです。

サービスメッシュ

前置きが長くなりましたが、サービスメッシュは、マイクロサービスごとにプロキシを配置し、プロキシを経由して他のサービスと通信させることでサービスの依存関係やトラフィックを制御する仕組みです。サービスメッシュでは、IstioLinkerdが有名ですが、この他にもAWS App MeshConsulMaeshKumaといったプロダクトがあります[2]。本ブログでは、この中でIstioの機能について触れていきます。

Istio

Istioは、Lyft、IBM、Googleといった会社によって開発されたOSSです。Istioのアーキテクチャはデータプレーンとコントロールプレーンの2つに分かれています [3]

データプレーンでは、サービス間の通信をプロキシが担うことで通信制御を行います。Kubernetes環境では、Sidecarと呼ばれる方式でPod毎にプロキシ Envoyがコンテナとしてデプロイされ、Pod間の通信はすべて、このEnvoyを経由することで制御されます。

一方、コントロールプレーンは、プロキシのポリシーを管理します。コントロールプレーンの機能は、すべてIstiodという単一のバイナリに統合されています。Istiodの内部には、PilotGalleyCitadelと呼ばれるコンポーネントが存在し、それぞれ次の機能を持ちます。

  • Pilot : Envoyの制御を行う。主に、サービスディスカバリを担当する
  • Galley : Istioを管理するためのAPIを担当する
  • Citadel : CA(認証局)として鍵管理や証明書の発行を担当する

Istioのコントロールプレーンから、Envoyに対して一元管理を行うことで大きく分けて次の3つの機能を提供します。いずれも様々な設定が可能であり、多機能なものなので、詳細は公式ドキュメントを参照ください[4-6]

  • Traffic management : サービス間のトラフィックのフローやAPI呼び出しを制御、サーキットブレーカーやタイムアウトの設定、A / Bテストやカナリーリリースといった機能
  • Security : 通信トラフィックの暗号化、認証・認可といった機能
  • Observability : テレメトリの収集、分散トレース、アクセスログといった機能

出典: Istio / Architecture

これらのIstioの機能を上手く使用することで、分散システムのモニタリングやネットワーク障害、セキュリティ、サービスの特定などの課題を解決し、アプリケーション開発者がビジネスロジックの開発に専念できるようにします。

まとめ

本記事では、マイクロサービスからサービスメッシュの概要を紹介いたしました。各種メリットについて触れましたが、依然としてマイクロサービスは、開発・運用者双方に負荷が高いことが提言されています。マイクロサービスの採用は、本記事で取り上げた以上に数多くの課題があるため、それらを採用するには慎重な判断が必要です。自社のビジネスにおける目標と課題と照らし合わせて柔軟な判断をとることが必要となるでしょう。

参考文献

[1] Microservices,

<https://martinfowler.com/articles/microservices.html>

[2]servicemesh.es | Service Mesh Comparison,

<https://servicemesh.es/>

[3]Istio / Architecture,

<https://istio.io/latest/docs/ops/deployment/architecture/>

[4] Istio / Traffic Management,

<https://istio.io/latest/docs/concepts/traffic-management/>

[5] Istio / Security,

<https://istio.io/latest/docs/concepts/security/>

[6] Istio / Observability,

<https://istio.io/latest/docs/concepts/observability/>

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。

カテゴリ関連記事