マーチン・ファウラー氏による「マイクロサービスの前提条件」

2014年9月26日

「マイクロサービス」という新しいアーキテクチャスタイルが話題になっています。ごく簡単に言えば、1つのシステムを複数の小さなサービスを組み合わせて実現することです。マーチン・ファウラー氏とJames Lewis氏が今年の5月に公開した記事「Microservices」で注目が集まりはじめました。

参考："Microservices"を読んだ | SOTA
参考：クックパッドとマイクロサービス - クックパッド開発者ブログ
参考：マイクロサービスとSOA - InfoQ

このマイクロサービスを実現する上で、組織が備えていなければならない能力について、マーチン・ファウラー氏が先月、「MicroservicePrerequisites（マイクロサービスの前提条件）」という記事を公開しています。同氏のWebサイトの記事は翻訳が許可されているので、ここで翻訳を紹介したいと思います。

MicroservicePrerequisites

マイクロサービスの前提条件（MicroservicePrerequisites）

私がみなさんにマイクロサービスアーキテクチャスタイルの話をし、多くの好意的な反応をいただいた。デベロッパーは小さな組織で働くことを楽しんでいて、またモノリシックなものよりも小さなユニットとよりよいモジュール化に期待を寄せているようだ。

しかしあらゆるアーキテクチャがそうであるように、トレードオフは存在する。とりわけマイクロサービスには、よく練られた単一のモノリシックなものではなく小さなサービスのエコシステムを扱わなければならないという点で、運用に関しては深刻なものがある。従って、ここで挙げる適性に合わないのであれば、マイクロサービススタイルを採用すべきではない。

迅速なプロビジョニング（Rapid provisioning）
新しいサーバをせめて数時間で立ち上げられるようでなければならない。当然ながらクラウドコンピューティングはこれに合致するが、クラウドでなくとも実現できるだろう。迅速なプロビジョニングを実現するには、多くの自動化も必要とされるはずだ。最初から全部を自動化しなくてもいいかもしれないが、後からマイクロサービスを真剣に採用することになれば、やはり必要となってくるだろう。

基本的なモニタリング（Basic Monitoring）
本番環境で多くの疎結合なサービスが連係するなると、テスト環境では分からなかったような問題が発生することもある。だからこそ、モニタリングの体制は深刻な問題をより早く検出するために重要になる。少なくとも技術的な問題について（エラーの発生回数、サービスの可用性など）は検出できるようにするべきで、同時にビジネス上の問題（発注処理の失敗など）をモニタリングすることも重要だろう。もしも突然問題が発生したら、ロールバックできるかどうかを確認する必要もあるだろうし。

アプリケーションの迅速なデプロイ（Rapid application deployment）
多くのサービスをマネージするためには、それらをテスト環境にも本番環境にも迅速にデプロイできるようでなければならない。一般にこれは数時間以内に実行されるようなデプロイメントパイプラインに関わることである。当初は多少の手作業があってもいいが、いずれは完全自動化を目指すことになるだろう。

こうした能力を備えることは、組織的な変化～デベロッパーとオペレーターの緊密な協力：DevOpsカルチャー～にとって重要だ。この協力はプロビジョニングとデプロイメントの迅速化を確実なものにするために必要であるし、モニタリングによってなにか問題を発見したときの迅速な対応にとっても重要だ。

この準備が済んではじめて、最初のマイクロサービスを扱う準備が整ったということになる。そしてシステムをデプロイしてそれを本番で扱うことにより、状態を正常に保ち、DevOpsの協力体制を健全にすることから多くを学ぶことが期待できるだろう。サービスを増やしていく前に、この業務にできるだけ時間を割り当てて多くを学び、能力を向上させることをしていくべきだ。

もしまだこうした能力を現在備えていないのであれば、マイクロサービスのシステムを本番投入する前に、その能力を確かなものにしておくべきだ。こうした能力というのはモノリシックなシステムでも実は求められるのである。こうしたことはソフトウェアの組織において広く見られるわけではなく、限られた組織だけであるし、優先度も低くなってしまっている。

さらに多くのサービスが求められるようになると、包括的な継続的デリバリによってプロビジョニングやデプロイメントを自動化したうえに、ビジネストランザクションの追跡が必要となってくるだろう。再び組織をシフトさせて「プロダクト中心のチーム（product centerd teams）」にする必要が出てくる。デベロッパーが容易に複数のリポジトリやライブラリ、言語と言ったものを切り替えられるように開発環境を整えなくてはならなくなるだろう。何人かの知人はより多くのマイクロサービスを実装する組織のために「成熟モデル（maturityModel）」が役に立つのではないかと調べている。私たちはこれから数年、この分野でさらに議論を積み重ねていくことになろう。