目次


マイクロサービスとコンテナーを併用すべき理由

マイクロサービスとコンテナーを扱う場合に期待できること

Comments

マイクロサービスとコンテナーについて

そもそも、マイクロサービスとは何なのでしょう?これは、アプリケーションを複数のサービスに分割し、それぞれのサービスがアプリケーション全体の一部として細分化された役割を果たすようにするアーキテクチャーです。つまり、それぞれに異なる論理機能を処理するマイクロサービスから 1 つのアプリケーションが構成されることになります。アプリケーションのコンポーネントと関数のすべてが 1 つのインスタンス内にまとめられるモノリシック・アーキテクチャーと比べると、マイクロサービスはアプリケーション・アーキテクチャーにおける、より現代的な手法です。モノリシック・アーキテクチャーとマイクロサービス・アーキテクチャーの違いについては、この 2 つを比較した以下の図を参照してください。

モノリシックとマイクロサービスの違いを示す図
モノリシックとマイクロサービスの違いを示す図

マイクロサービスをどこに配置するのかと言うと、それはコンテナー内です。コンテナーとはソフトウェアのパッケージのことで、ここに、実行する必要のあるコード、依存関係、ライブラリー、バイナリーなどのすべてが収容されます。コンテナーを作成して実行するのによく使われている手段としては Docker が挙げられます。その一方で、エンタープライズ環境内で複数のコンテナーをオーケストレーションするために使用されている Kubernetes が事実上の業界標準として急速に普及しつつあります。仮想マシン (VM) の場合、OS カーネルの完全なコピーを持たせた複数の VM を単一のホスト内に作成しますが、コンテナーの場合はそれとは異なり、OS カーネルを複数のコンテナー間で共有します。マイクロサービスを複数の VM 内に組み込むことも可能ですが、通常は、マイクロサービスにはコンテナーが使用されます。それは、コンテナーは占有するスペースが少なく、起動にかかる時間も短いためです。

マイクロサービス・アーキテクチャーを使用する理由

マイクロサービス・アーキテクチャーは、モノリシックなアプリケーションに伴う問題に対処するために誕生しました。マイクロサービスはすでに広く使われており、大規模な Web サイトの中には、かつてのモノリシックなアプリをマイクロサービスに変換して使用しているものもあります。マイクロサービス・アーキテクチャーを採用することによってもたらされるメリットとしては、以下が挙げられます。

  • モノリシックなアプリに比べ、開発者が扱うコードベースのサイズが縮小されます。 アプリケーションのコンポーネントが疎結合されていれば、開発者はソース・コードを簡単に理解できるので、開発のスピードが低下することがありません。言うまでもなく、処理するコードの行数が少なければ IDE の動作が高速化します。さらに開発者は、モノリシックなアプリで見られるような関数の複雑さと依存関係に対処する必要がなくなります。
  • 開発者の責任がより明確に定義されます。 アプリのコンポーネントまたはマイクロサービスごとにチームを割り当てることができます。各チームがそれぞれに個別のコンポーネント/マイクロサービスを担当できることから、コード・レビューにかかる時間が短縮されるだけでなく、更新を行うのも簡単になります。また、モノリシックなアプリとは異なり、更新後にすべてのものをビルドしてデプロイする必要もありません。
  • アプリケーションのテクノロジー・スタックを、マイクロサービスごとに変えることができます。 そのため、アプリケーションが 1 つの言語またはライブラリーに依存する必要がなくなります。マイクロサービスでは、開発者の判断に応じて異なるプログラミング言語を利用できます。したがって、以下の図のような多言語マイクロサービスを利用することが可能になります。 多言語マイクロサービスを示す図
    多言語マイクロサービスを示す図
  • 継続的デリバリーが容易になります。 マイクロサービスの場合、モノリシックなアプリとは異なり、単純な変更だけのためにあらゆるものを再度デプロイする必要がなくなります。更新する必要があるマイクロサービスだけ再ビルドしてデプロイするという選択肢が与えられるため、頻繁な更新でも短時間で対処できます。
  • マイクロサービスごとに独立してスケーリングできます。 アプリケーションのコンポーネントごとに、リソースのニーズに応じてスケーリングするかどうかを決めることができます。モノリシックなアプリのように、あらゆるコンポーネントのインスタンスを複数作成する必要はありません。モノリシックなアプリをスケーリングする場合、アプリケーション全体のコピーが複数必要になりますが、それとは異なり、マイクロサービスのスケーリングでは利用可能なリソースが効率的に使用されることになります。 互いに独立したスケーリングを示す図
    互いに独立したスケーリングを示す図
  • Data can be decentralized. データを分散化できます。マイクロサービスごとに異なるデータベース/ストレージを使用できます。例えば、マイクロサービスにリレーショナル・データベースよりも NoSQL データベースのほうがふさわしいのであれば、NoSQL データベースを選択できます。また、Redis のようなシンプルな Key-Value 型ストアで事足りるマイクロサービスには、その選択肢もあります。例えば以下の図に示すように、Cloudant、MySQL、MongoDB を組み合わせて使用できます。つまり、データ型によって異なるデータベースを利用できるというわけです。 さまざまなデータベースの選択肢を示す図
    さまざまなデータベースの選択肢を示す図
  • 障害を切り分けることができます。 あるマイクロサービス内のエラーやバグによって、システム全体がダウンするという状況に追い込まれることはありません。コンポーネントが疎結合されていれば、アプリケーション内のあるマイクロサービスが停止したりエラーをスローしたりしても、他のマイクロサービスに影響が及ぶ可能性は低くなります。各マイクロサービスはそれぞれ独自のコンテナー内にあり、マイクロサービスが互いに完全に依存することはないからです。モノリシックなアプリの場合、バグやエラーが正しく捕捉されなければ、アプリケーションのプロセス全体が停止する可能性があります。

マイクロサービスの難点とは

マイクロサービスを利用することでモノリシックなアプリケーションに伴う問題のいくつかは解決されますが、マイクロサービスを使用する場合に固有の問題もいくつかあります。モノリシックなアプリケーションをマイクロサービスに分割しようと取り組む場合、最初に課題となるのは、その分割方法です。選択肢の 1 つとしては、例えば、あるマイクロサービスで配送を処理し、別のマイクロサービスで決済サービスを処理するといったように、ビジネス機能ごとに分割することが考えられます。最終的に、各コンポーネントで対処する機能または責任はわずかな数だけになる必要があります。

私の考えで言うと、マイクロサービス・アーキテクチャーには以下の問題があります。

  • 追跡の難しさ。マイクロサービスの数が増えると、マイクロサービスを漏れなく追跡するのが難しくなる場合があります。これらの複数のマイクロサービスによって増加する複雑さに対処しなければならないことから、最初に継続的統合と継続的デリバリーをセットアップするところからして困難になり得ます。
  • 複雑さ。. 複数のチームが関与する場合は尚更のこと、マイクロサービスでは調整の必要性が増してきます。また、マイクロサービス間でのやり取りが必要な場合、ネットワーク呼び出しの数も多くなります。これは、モノリシックなアプリには存在しない問題であり、アプリの 1 つのインスタンスをデプロイするというだけの単純なことでは終わりません。他にも考慮しなければならない点としては、マイクロサービス間の通信を処理する方法、他のマイクロサービスを中断せずにエラーを処理する方法、各コンポーネントでのテスト・ケースの追加などが挙げられます。
  • アプリケーション内でのバグ/エラーの検出と追跡。マイクロサービスに 1 つのルートしかなければバグやエラーを検出して追跡するのは簡単かもしれませんが、マイクロサービスが他のマイクロサービスと通信するとなると、エラーを見つけるだけでもかなりの時間がかかる場合があります。 リクエストの追跡を示す図
    リクエストの追跡を示す図
  • マイクロサービスのルーティング。マイクロサービスをルーティングするには、より多くの作業が必要になります。 マイクロサービスのフローを構成して制御する作業に時間をかける必要が出てくることでしょう。また、マイクロサービスのバージョンを追跡して、そのルーティングに対処する必要もあります。 マイクロサービスのルーティングを示す図
    マイクロサービスのルーティングを示す図
  • リソースの消費量。マイクロサービスは、モノリシックなアプリよりも多くのリソースを消費する可能性があります。 前述したように、スケーラビリティーとリソースの有効利用と使用効率はマイクロサービスの利点の 1 つですが、すべてのコンポーネントに固有のインスタンスとコンテナーが必要になることから、メモリー使用量と CPU 使用率の増加につながる可能性があります。

マイクロサービスで利用できるツール

Kubernetes

Kubernetes は、コンテナーのすべてをデプロイ、スケーリング、管理するために利用できるコンテナー・オーケストレーション・プラットフォームです。Kubernetes を使用すると、コンテナー化したマイクロサービスのデプロイを自動化することができるので、アプリケーションのコンポーネントとマイクロサービスのすべてを簡単に管理できるようになります。マイクロサービスをコンテナー化する方法としては、Docker を調べてください。IBM では、クラスターを自動的に管理する IBM Cloud Kubernetes Service で Docker を一般提供しています。

Istio

Istio では、マイクロサービスに伴う難題のいくつかに対処しています。Istio は、マイクロサービスの管理をさらに容易にするサービス・メッシュです。Kubernetes をベースに Istio をインストールすれば、Istio を利用してマイクロサービスを追跡およびモニタリングすることができます。さらに、アプリケーション内にエラーやバグがある場合、それを迅速に検出するのにも役立ちます。Istio では、フローを管理して制御するのと同じように、マイクロサービスのトラフィックを管理することもできます。ルートは簡単に構成できます。また、Istio は相互 TLS 認証や外部サービスへのアクセス制限などといったセキュリティーをマイクロサービス内で実装します。Istio は IBM Cloud Kubernetes Service にインストールすることもできます。

まとめ

私の経験から言うと、マイクロサービスを使用してアプリケーションを構築する場合、コンテナー・オーケストレーション・フレームワークを使用することが必須となります。コンテナー・オーケストレーション・フレームワークとして開発者の間でよく使用されているのは、Kubernetes です。Kubernetes ではアプリケーションを開発環境から本番環境へと迅速に移行できます。しかも、Kubernetes はオープンソースです!

開発者はアプリケーションの構築を開始するときに、モノリシック・アーキテクチャーではなくマイクロサービス・アーキテクチャーを使用することがメリットになるかどうかを判断しなければなりません。その判断を下す際に考慮しなければならないのは、アプリケーションの長期的な有用性とスケーラビリティーです。モノリシック・アーキテクチャーに従って開発を開始するのでも問題はありませんが、その場合、アプリケーションの規模が大きくなったときに、それをマイクロサービスに分解するのが難しくなるだけです。その点から言うと、開発の初期段階からマイクロサービスに移行すれば、得られるメリットは大きくなります。既存のモノリシックなアプリケーションについては、アプリケーション内のどのコンポーネントをどのように分離するかを考える必要があります。

いくつかの難点はあるとは言え、マイクロサービスはアプリケーションとそのユーザーの需要に対して大きなメリットをもたらすことから、開発者や企業の間で揺るぎない評判を維持しています。適切なレベルのマイクロサービスを配置してあれば、開発と企業はその柔軟性を利用して、アプリケーションの開発や更新を迅速化することができます。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, DevOps
ArticleID=1064621
ArticleTitle=マイクロサービスとコンテナーを併用すべき理由
publish-date=02072019