マイクロサービス

マイクロサービスとは

マイクロサービスは、アプリケーション構築のアーキテクチャ・スタイルです。マイクロサービス・アーキテクチャが従来のモノリシックなアプローチと異なるのは、アプリケーションをコア機能ごとに細分化するという点です。各機能はサービスと呼ばれ、独立して構築およびデプロイすることができます。つまり、個々のサービスが正常に機能してもしなくても、他のサービスに悪影響を及ぼすことはありません。

オンラインのショッピングサイトに最近アクセスしたときの状況を思い出してみてください。サイトの検索バーを使用して商品をブラウズしたのではないでしょうか。この検索がサービスです。また、お勧めの関連商品が表示されたかもしれません。こうしたお勧め商品は、買い物客の好みが蓄積されたデータベースをもとに表示されます。これもまた、サービスです。商品を購入しようとオンラインカートに追加しましたか?もちろん、これもサービスです。

つまり、1 つのマイクロサービスはアプリケーションの 1 つのコア機能であり、他のサービスとは独立して動作します。とはいえ、マイクロサービス・アーキテクチャは、アプリケーションのコア機能の単なる疎結合というわけではありません。不可避の障害や、今後のスケーラビリティ、新たな機能統合に備え、開発チームとサービス間のコミュニケーションを再構築することでもあります。

これを実現するには、マイクロサービスをデプロイできるように、サービス指向アーキテクチャ (SOA) の基本を適応させる必要があります。


従来の手法との違い

アプリケーションをコア機能に細分化し、モノリスのリスクを回避するという手法に聞き覚えがあるとしたら、それは、マイクロサービスのアーキテクチャ・スタイルが、すでに確立されたソフトウェア設計スタイルであるサービス指向アーキテクチャ (SOA) と似ているからです。

当初アプリケーション開発では、既存のアプリケーションに最小限の変更を加えるだけでも、独自の品質保証 (QA) サイクルで大規模なアップデートが必要となり、多くのサブチームの作業が滞ってしまう場合がありました。このアプローチは、アプリケーション全体のソースコードが 1 つのデプロイメントユニット (.war または .ear など) に組み込まれていたことから、多くの場合「モノリシック」と呼ばれます。アプリケーションの一部のアップデートが原因でエラーが発生した場合は、全体をオフラインにして、規模を縮小し、修正する必要がありました。このアプローチは小規模なアプリケーションには引き続き有効ですが、成長する企業にはダウンタイムを生じさせる余裕はありません。

そこで、サービス指向アーキテクチャが注目されるようになります。これは、エンタープライズ・サービス・バス (ESB) を介してやり取りする、個別の再利用可能なサービスの集合としてアプリケーションを構築する手法です。このアーキテクチャでは、特定のビジネスプロセスを中心に編成された個々のサービスが、SOAPActiveMQApache Thrift などの通信プロトコルに準拠し、ESB を介して共有されます。つまり、ESB を介して統合されるこの一連のサービスが、アプリケーションを構成するのです。

これによりサービスの構築、テスト、調整を同時に行うことができるため、モノリシックな開発サイクルに頼ることはなくなります。しかし、ESB はシステム全体の単一障害点となるため、モノリスを排除する努力が新たなモノリスを生み出しただけという見方もあります。ESB は、組織全体のボトルネックとなる可能性があります。


SOA とマイクロサービスの違い

マイクロサービスは、通常はステートレスに相互通信できるため、この手法で構築されたアプリケーションはフォールトトレラント性が高まり、単一の ESB への依存度は低くなります。これにより、マイクロサービスは言語に依存しないアプリケーション・プログラミング・インタフェース (API) を介して通信できるため、開発チームは独自のツールを使用することができます。

SOA が利用されてきたため、マイクロサービスは実際には、まったく新しい考え方とは言えません。しかし、コンテナ化テクノロジーの進歩に伴い、マイクロサービスの実用性は高まってきています。Linux コンテナでは、同じハードウェア上でアプリケーションの複数の部分を個別に実行し、各部分やライフサイクルをより詳細に制御できるようになりました。

どんな新しいアーキテクチャも、初めて利用する時が最も困難です。アプリケーションを新規作成したいですか?それとも既存のアプリケーションを変更したいですか?いずれにしても、マイクロサービスを構築するメリットと課題について考える必要があります。


マイクロサービス・アーキテクチャのメリット

マイクロサービスは、分散開発によりチームの作業やルーチン化を後押しします。複数のマイクロサービスを同時に開発することもできます。つまり、同じアプリケーションを同時に開発する開発者の数を増やすことができ、開発期間が短縮されます。

市場投入期間の短縮

マイクロサービス・アーキテクチャでは開発サイクルが短縮されるため、より俊敏なデプロイメントと更新が可能になります。

優れたスケーラビリティ

ニーズの高い特定のサービスは、複数のサーバーやインフラストラクチャにわたってデプロイできるため、ニーズに対応することができます。

耐障害性

これらの独立したサービスは、適切に構築されていれば、相互に影響しません。つまり、モノリシックなアプリケーション・モデルとは異なり、ある部分に傷害が生じてもアプリケーション全体がダウンすることはありません。

容易なデプロイ

マイクロサービスベースのアプリケーションは、従来のモノリシックなアプリケーションと異なり小さくモジュール化されるため、デプロイメントに伴う心配がありません。これにはいくらかの調整が必要ですが、大きなメリットにつながります。

アクセス可能

大規模なアプリケーションを小さなパーツに分割できるため、開発者は各部をより簡単に理解、更新、強化することができ、特にアジャイル開発手法と組み合わせることによって、開発サイクルが短縮されます。

オープン性の向上

多言語 API を使用するため、開発者は、必要な機能に最適な言語とテクノロジーを自由に選択することができます。


マイクロサービスの課題

組織でマイクロサービス・アーキテクチャへの移行を考えている場合は、アプリケーションだけでなく、従業員の働き方も変化することを想定しておく必要があります。各チームがデプロイメントを実施する頻度はそれぞれ異なり、独自の顧客層に対する固有のサービスを担当するため、組織的な変更と文化的な変更は、ある意味で課題となります。これは開発者が見落としがちな点ですが、マイクロサービス・アーキテクチャを成功させるために不可欠な要素です。

マイクロサービス・ベースのアーキテクチャにおいて、文化やプロセスよりもさらに大きな課題となるのは、複雑さと効率性です。Red Hat Mobile のプラットフォーム・アーキテクト、John Frizelle は、2017 年の Red Hat Summit での講演で、次の 8 つの課題カテゴリを提示しました。

  1. 構築: 時間をかけてサービス間の依存関係を特定する必要があります。1 つの構築を完了すると、依存関係により、他の構築も必要になる可能性があります。また、マイクロサービスがデータに及ぼす影響についても考慮する必要があります。
  2. テスト: 統合テストとエンドツーエンド・テストは、これまで以上に複雑かつ重要になります。アーキテクチャの一部で障害が起きると、サービス間のサポートをどのように構築したかに応じて、少し離れた部分が失敗することもあります。
  3. バージョン管理: 新しいバージョンに更新すると、下位互換性が失われる可能性があります。下位互換性に対応する条件付きロジックを使用して構築することもできますが、扱いが困難になります。あるいは、各クライアント向けに複数のライブバージョンを立ち上げることもできますが、メンテナンスや管理が複雑化するおそれがあります。
  4. デプロイメント: これもまた、少なくとも初期設定では課題となります。マイクロサービスの複雑さから、手動でのデプロイメントは困難であるため、デプロイメントを容易にするために、まずは多くの自動化に投資しなければなりません。サービスを導入する方法と順序を考える必要があります。
  5. ロギング: 分散システムでは、すべてのログを一元化する必要があります。これがなければ、スケーリングを管理することができません。
  6. 監視: 問題の原因を突き止めるために、システムを一元的に把握することが重要です。
  7. デバッグ: リモートデバッグを行うことはできず、数十、数百のサービスに対しては機能しません。残念ながら、現時点ではデバッグ方法はありません。
  8. 接続性: 一元型または統合型を問わず、サービスの検出を検討する必要があります。

マイクロサービスについてさらに詳しく知る