マイクロサービスは銀の弾丸か(1) - 実適用のポイントと「9つの特徴」1～4

マイクロサービスを深く正しく理解するには以下のJames Lewis氏・Martin Fowler氏が名付けた「9つの特徴」 をおさえる必要があります。

その内容はこれまでの連載でも触れてきましたが、今回からは、それぞれの「位置付け」や必ずしもメリットとは言えない部分も含め、改めて一つ一つ筆者の見解を交えながら振り返っていきます。

「9つの特徴」を読むのはハードルが高い、あるいは読んだけれどもよくわからなかった、という方への一助となれば幸いです。

表 : マイクロサービスの「9つの特徴」と本連載における紹介回次

No	特徴名(英語)	特徴名(筆者による日本語訳)	紹介回次
1	Componentization via Services	サービスを通じたコンポーネント化	1、2
2	Organized around Business Capabilities	ビジネス遂行能力に基づいた組織整理	3、4
3	Products not Projects	プロジェクトではなくプロダクト	3、4
4	Smart endpoints and dumb pipes	スマートエンドポイントとシンプルな土管	2、7
5	Decentralized Governance	分散統治	2
6	Decentralized Data Management	分散データ管理	未説明※
7	Infrastructure Automation	インフラの自動化	4、5、6
8	Design for failure	障害発生を前提とした設計	3※
9	Evolutionary Design	進化的な設計	5
※は必ずしもメリットとは言えない特徴

まず、それぞれの特徴における位置付けは、以下の通りです。

• マイクロサービスをどういった契機および粒度で切り出すか(特徴No1、9)
• マイクロサービス間の連携(特徴No4)
• データの配置(特徴No6)
• 開発チームをどう分割して統治していくか(特徴No2、5)

• 開発サイクル(設計～運用・監視)における技法・ツールや設計手法(特徴No3、7、8)

以下、順に説明していきましょう。

1. Componentization via Services :
　サービスを通じたコンポーネント化

マイクロサービスではアプリケーションをサービスに分けて構築し、サービスの単位でコンポーネント化を実現します。では、ここでいうコンポーネントとはどういったものを指すのでしょうか。デプロイの観点でサービスの対極に位置づけられるライブラリとの比較により説明します。

それぞれの用語の定義は以下の通りです。

• 「コンポーネント」: 独立して交換やアップグレード可能なソフトウェアの単位
• 「ライブラリ」: プログラム内にてリンクされ、インメモリの関数呼び出しされるコンポーネント
• 「サービス」: プロセス境界を超えてWebサービスやリモートプロシージャコールにて呼び出しされるコンポーネント

ライブラリとサービスの決定的な違いはプロセス境界をまたぐかどうかという点です。これにより、デプロイの単位をサービスの単位で独立させることができます。

単一プロセス内に複数ライブラリを用いてモノシリックなアプリケーションを構築した場合、特定のライブラリの修正がアプリケーション全体の再デプロイにつながります。もちろん、一つのサービスの再デプロイが他のサービスの再デプロイにつながることはあります。

良いマイクロサービスを作る際のポイントとしては、サービス境界を利用し、こういった影響範囲を局所化することにあります。

2. Organized around Business Capabilities :
　ビジネス遂行能力に基づいた組織整理

巨大なアプリケーションを開発する際、プロジェクトによっては、UI・業務ロジック・基盤・DBAといった単位でチームを分割するケースがあります。これはこれで良い面もありますが、単純な仕様変更や機能追加であっても、チーム横断のプロジェクトとなり、時間がかかったり、予算承認が困難になったりします。コンウェイの法則が示すように、組織構造とソフトウェアの構造には密接な関係があります。

マイクロサービスを適用した開発プロジェクトでは、ビジネス遂行能力に基づいて整理されたサービスの単位にチームを分割します。具体的には、UI・業務ロジック・基盤・DBAなどの必要なスキルを全て含むクロスファンクショナル型と呼ばれます。勘の良い方は気づかれたかもしれませんが、これはアジャイルの一つであるSCRUMの文脈でも語られる内容になります。

こういったクロスファンクショナル型は、Monolithアプリケーションでも実現可能ですが、マイクロサービスは組織間をサービスで疎結合にすることができるため、より実現しやすいと言えます。

3. Products not Projects :
　プロジェクトではなくプロダクト

開発チームがシステム開発プロジェクトを担い、リリースしたら運用に引き渡す。そう言ったスタイルをとっているケースは多いのではないでしょうか。これは、いわゆるDevOpsの文脈で語られる内容となります。

マイクロサービスでは、プロジェクトが終わったら、開発チームは解散という考えではなく、プロダクトのライフサイクル全体に渡って、サポートしていくべきだという考えがあります。

Amazonにおいて「you build it, you run it」という言葉があり、類似の思想です。運用やサポートに部分的にでも関わることで、開発者がソフトウェア製品の振る舞いに日々接し、ユーザとの接点を増やすことができます。これにより、単にソフトウェアの完成のみに注力するのではなく、ユーザのビジネスに貢献することにも注力しやすくなります。

4. Smart endpoints and dumb pipes :
　スマートエンドポイントとシンプルな土管

プロセス間通信を行う際、通信機構にスマートさを与えるプロダクトやアプローチが多く存在します。ESB(Enterprise Service Bus)がその好例で、洗練されたメッセージルーティングやビジネスルール等の機構を持ちます。

一方、マイクロサービスは「スマートエンドポイントとシンプルな土管」のアプローチを提供します。通信機構にスマートさを与えるのではなく、サービス(エンドポイント)にスマートさを与え、通信機構をシンプル(土管)にします。

具体的にはREST APIのようなシンプルなプロトコルを用い、通常WS-ChoreographyやBPEL(Business Process Execution Language)やESBを使ったプロトコルは利用しません。

*　　*　　*

今回は、前回までに説明した内容とマイクロサービスの「9つの特徴」との紐付けや特徴同士の関係性を整理したうで、「9つの特徴」のうち4つを説明しました。次回は残りの5つをご紹介します。