マイクロサービスとはすなわち分散システムである

マイクロサービスへの移行はすなわち分散システムへの移行であり，レイテンシや自動化，権限と認証，メッセージの不達といった事態に対処しなくてはならない — 独立系ソフトウェア開発者であるSander Hoogendoorn氏はこのように主張する。マイクロサービスによって大規模なシステムをより小さなコンポーネントに分割すれば，アーキテクチャ全体のコントロールを取り戻すことができる。マイクロサービスならば，単一あるいは一連のコンポーネントを拡張してデプロイすることで，小規模な変更や機能単位での追加が可能になるのだ。

アジャイル開発とソフトウェアクラフトマンシップに関するカンファレンスの第２回として，9月12日と13日にサウスウェールズで開催されるSwanseaCon 2016でHoogendoorn氏は，閉会の基調講演を行なう予定である。InfoQは氏にインタビューして，モノリシックソフトウェアの問題点，最小実行可能なプロダクト構築におけるマイクロサービスの利用，マイクロサービスのテスト，マイクロサービスと継続的デリバリの適合性，マイクロサービスのメリットとデメリットなどを聞くとともに，マイクロサービスの実装を望む組織へのアドバイスを求めた。

マイクロサービスの活用方法やテストの方法，分散システムの構築という面で捉えたマイクロサービスの複雑さについては，これまでにも何人かの人たちが記事を書き，組織におけるマイクロサービスの実装に関するアイデアを提供してくれている。

InfoQ: モノリシックなソフトウェアプロダクトを抱える組織にとって，最大の問題は何でしょうか？

Sander Hoogendoorn: モノリシックなシステムは，記述言語や実行プラットフォームの種類に関わらず，時間とともに肥大化する傾向があります。つまりは多くの人たちがそのシステムに関わり，それぞれが違うスタイルでコードを書いているということです。システムが年月を経て機能追加や変更，あるいは削除が実施されることによって，アーキテクチャの安定性が損なわれることは珍しくありません。さらにシステムは単独で実行されるよりも，より大きなシステムランドスケープ内に統合されている場合が少なくないため，結果的に外部インターフェースの数も増えることになります。

それによって多くの組織では，新機能の市場投入時間が増大したり，新機能を組み込むことができないなどといった問題に直面しています。イノベーションの速度は低下し，新技術の採用が困難に，さらには不可能になる場合さえあるのです。

InfoQ: そういった問題に対して，マイクロサービスはどのようなソリューションを提供してくれるのでしょう？

Hoogendoorn: マイクロサービスアーキテクチャの基本的な考え方は，大規模なシステムを小さなコンポーネントに分解することです。それによって，システムランドスケープ全体のアーキテクチャに対するコントロールを取り戻そうというのです。分解されたコンポーネントは，RESTやJSON over HTTPといった，取り扱い容易なプロトコルを通じてコミュニケーションします。“マイクロ”という前置詞は，ソースのライン数やサービスエンドポイントの数の上でのコンポーネントのサイズを連想させます。ですが私としては，ドメイン駆動の設計パラダイムによるコンテキスト境界(bounded context)パターンを使ってシステムをブレークダウンし，各コンポーネントがシステムドメイン内の独立した部分を処理することの方が重要だと思っています。

InfoQの記事 “microservices anti-patterns” ではVijay Alagarasan氏が，マイクロサービスとサービス指向アーキテクチャ(SOA)との関連性について論じている。

適切な人材と文化と投資なくしては，SOAがビジネスバリューを提供することはありません。マイクロサービスアーキテクチャとSOAに本質的な違いはありません。アプローチが多少洗練されてはいますが，目標と目的は同じです。マイクロサービスはSOAをスケーラブルにしたに過ぎない，と言ってもいいでしょう。

InfoQ: MVP(Minimum Viable Product)を構築する上で，マイクロサービスはどのように利用できるのでしょうか？

Hoogendoorn: MVPの思想は，価値を提供する最小限のバージョンを実装することによって，プロダクトへの価値の追加を重視するものです。マイクロサービスでは，単一あるいは一連のコンポーネントの拡張とシステムランドスケープへの(個別の)デプロイを継続的に行なうことで，個々の機能の追加を可能にします。継続的デリバリさえ適切にセットアップされてしまえば，変更されたコンポーネントの新バージョンの展開は例えば毎日であっても可能ですし，自動テストももちろん実現できます。これによって，小さな変更を継続的に実装することが可能になるのです。

InfoQ: マイクロサービスのテストには，どのような手法が利用できるのでしょうか？

Hoogendoorn: システムランドスケープを小さなコンポーネントに分割すると，さまざまなレベルでのテストが必要になります。まず第一に，コンポーネント内部のレベルでは，ユニットテストでコンポーネント内を一通りカバーできると思います。次に，サービスインターフェースでは，例えそれがJSONやPDFなど高レベルの出力やドキュメントを生成するものであっても，テストは必要になります。それに続くレベルである，コンポーネントの提供するサービスを利用する外部コンポーネントでは，これらのコンポーネントが正しいアウトプットを提供していることを確認する必要があります。マイクロサービスアーキテクチャのサービスは，通常はRESTやJSON over HTTPなどを使用して疎結合されているので，サービスインターフェースの変更が開発チーム全体にピックアップされることはありません。コンポーネントが変更された場合，自動的にテストが実行されるようにしておけば，互換性のない修正を可能な限り早く知ることができます。サービスが成長するにつれてコンポーネントの数が増え，それに連れてテストの数もすぐに増加しますので，すべてを自動的にビルドできる環境を構築しておくことをお勧めします。

マイクロサービスの開発とテストに関するインタビューの中でRedgate SoftwareのJose Lima氏は，マイクロサービスにおいてすべてのテストを自動化する必要はなく，テスタ以外の人が実行可能なテストもあることを示唆している。

テストの自動化も必要なスキルだと言う人がいますが，私はそうは思いません。そもそも私は自動テストを信用していませんし，自動チェックならばテスタでなくても，他のチームメンバでもできます。自動テストはなくても，確かに自動チェックは必要ですね — テストは単なるチェック以上のものだと思いますし，チェックプロセスならば自動化も可能でしょう。ただし，それが何をするのか，どんな意味があるのかを理解した後でなければ，必要な処理が行われているかどうかをチェックすることは(自動化の有無に関わらず)できません。

InfoQ: マイクロサービスは継続的デリバリに適しているのでしょうか？

Hoogendoorn: 継続的デリバリでは，すべての変更が潜在的なリリース候補です。マイクロサービスアーキテクチャにおいてこれは，ひとつないしふたつのコンポーネントの継続的な新バージョンがランドスケープにリリースされる可能性がある，ということです。これらコンポーネントが分散システムあるいは共同サービスにリリースされる場合，自動テストを統合して高度に設計されたデプロイメントパイプラインは，モノリスにおける継続的デリバリよりもさらに重要です。継続的デリバリとマイクロサービスは，理屈の上では整合性が高いと言えるかも知れませんが，私の経験からは，組織が抱える構成数が数個というのはまれで，非常に多数であることの方が多いのです。従って事はそう簡単には運びません。

マイクロサービスを始めたいのであれば継続的デリバリと自動テストは必須だ，とAlagarasan氏は主張する。

継続的デリバリは，もしもまだ実践していないのであれば，すべての企業にとって必須の投資であり，目標とすべき文化的変革なのです。少なくとも，自動テストとデプロイを行なう方法を持っていないのならば，マイクロサービスには手を出すべきではありません。マイクロサービスは，私たちが必要とする速度を備えたアジリティの推進を目的としています。自動化されたユニットテスト，機能テスト，セキュリティテスト，パフォーマンステストは，各サービスの品質保証上では不可欠なものです。

InfoQ: マイクロサービスのメリットとデメリットはどのようなものでしょう？

Hoogendoorn: マイクロサービスアーキテクチャに向かって進むことは，大規模システムの小コンポーネントへの分割を支援し，ひいては自らのシステムランドスケープの制御権を取り戻すということです。これら個々のコンポーネントによって，管理やリプレース，デプロイ，拡張，テストなどの実施が簡単にできるようになります。新たな言語やフレームワーク，データベースといった新テクノロジの導入も容易になります。初期段階からシステムランドスケープ全体に対して一度に展開する必要はなく，数個のコンポーネントから使用を始めることも可能です。その一方で，マイクロサービスへの移行自体による影響もあります。小コンポーネントに分割したことにより，コンポーネント間のコミュニケーションが非常に増加します。実際に組織でも，マイクロサービスへの移行は分散システムへの進行に他ならないことに気付き始めています。そこにはメリットだけでなく，レイテンシや自動化，認証といったシステムの構成や，不達メッセージの操作も規定しなくてはなりません。

InfoQの記事 “Microservices: Decomposing applications for deployability and scalability” ではChris Richardson氏が，マイクロサービスを実装するというのは，つまり分散システムを構築することである，と述べている。

マイクロサービスの開発者は，分散システムに構築による複雑性向上に対処しなくてはなりません。 プロセス間通信のメカニズムを実装する必要があります。複数のサービスにまたがるユースケースの実装は，分散トランザクションの利用なしでは困難です。IDEなどの開発ツールはモノリシックなアプリケーション構築を中心としており，分散アプリケーション開発を明示的にはサポートしていません。複数のサービスを対象とする自動テストの記述は困難です。このように，モノリシックアーキテクチャにはない，数多くの問題に対処しなくてはなりません。

InfoQ: マイクロサービスを実装しようとしている組織に対して，何かアドバイスすることはありますか？

Hoogendoorn: マイクロサービスへの移行を検討中なのであれば，それが現在最高の流行だからというのではなく，適切な理由によるものであるという確信が必要です。その論拠としては，現行のシステムがメンテナンス不能である，システムランドスケープに新たなテクノロジないしプラットフォームを導入する必要がある，新機能の市場投入時間を大幅に改善する必要がある，といったものが考えられます。それでもマイクロサービスに向かおうとする時には，考慮すべき点がたくさんあることには注意してください。ソフトウェアの設計や開発やテストの方法，デプロイメントパイプラインや権限認証のセットアップ方法，チームの運用やコラボレーションの方法 — 機能を構築するか，すでにコンポーネントが存在するのか? — さらには内外のステークホルダとの交渉術も変えていかなくてはなりません。何よりも必要なのは，分散システムを開発しているのだという認識です。これは簡単なことではありません。場合によっては，マイクロサービスで使うものと同じ設計テクニックを利用してモノリスを分解し，それらを再構築しモジュール化した上で再構築するという方法もあります。

Alagarasan氏はマイクロサービスの実装に必要な文化変革を実現するために，エグゼプティブやシニアリーダの協力を得ることを提案する。

マイクロサービスの目標は，主要な３つの共通的問題の解決にあります — すなわち，ユーザエクスペリエンスの改善，新たな要件に対する高度な機敏性，ビジネス機能をきめ細かなサービスとして提供することによるコスト削減です。これは銀の弾丸ではなく，高品質でアジャイル的なサービスを提供可能な，規律あるプラットフォームが必要です。(...) これはコンテナ化やクラウド採用を話題にできるようになるための，わずかな第１歩に過ぎません。(...) これらの大部分は，組織内の文化的変革を起こすためなのです。自分ひとりで実現できるものではなく，エグゼプティブやシニアリーダの力を借りなくてはなりません。