この記事は foodison advent calendar 2015 の21日目の記事です。

こんにちは。　エンジニアの市川です。　記事を出すのが３日遅れたのを正直に報告します。

はじめに

今回も前回に引き続き Microservices ( マイクロサービス ) についてです。
前回、Microservices ( マイクロサービス ) の概要や特徴について書かせていただきました。
今回は、どのような場合にマイクロサービスを適用すべきかについて書いていきます。

大半のシステムでは、マイクロサービスは必要ない

いきなり全否定かよ！という感じですが 汗
2014 年に James Lewis 氏とともに Microservices を発表した Martin Fowler 氏は、マイクロサービスへの過度な期待を戒めるかのように MicroservicePremium という記事を記しています。
記事中では以下のようなことが書かれています。

• 開発チームがマイクロサービスを熱心に受け入れるあまり、それ自体がシステムを複雑にしているコトに気付いていない。
  これにより、プロジェクトのコストやリスクが増加し、深刻なトラブルにもつながる。

• マイクロサービスを利用するかどうかは、システムの"複雑さ"。
  マイクロサービスは複雑なシステムを扱うことを目的としている。　そのため、アプローチ自体が複雑さを伴っている。
  利用のためには、自動デプロイ、モニタリング、障害対応、結果整合性などの分散システム導入に伴う仕事をしなくてはならない。
  

• モノリスのように管理することができないような、複雑なシステムを利用している場合を除き、Microservices を考慮する必要はない。
  ソフトウェアシステムの大部分は、単一のモノリシックなアプリケーションとして構築されるべき。
  

また、記事中では、システムの"複雑さ"が小さい段階でマイクロサービスを導入すると、モノリシックなアーキテクチャに比べ、"生産性"が落ちてしまうことがグラフ化されています。
グラフは縦軸が"生産性"で、横軸が"複雑さ"です。
マイクロサービスは、小さなシステムで最初から導入するような考え方ではなく、システムの"複雑さ"が高まってから検討すれば良いことが、グラフから読み取れます。

導入に至るまでの経緯 ( クックパッド )

ここでは、マイクロサービスの導入にいたるまでの経緯を、クックパッドさんの事例をもとに見て行こうと思います。

2014年9月にクックパッド開発者ブログで クックパッドとマイクロサービス という記事が発表されました。
記事中では、クックパッドがマイクロサービスへの転換を進めていることと、その背景が記されています。

クックパッドでは巨大なコードベースを持つ、モノリシックなアーキテクチャゆえ、以下の課題を抱えていたコトが語られています。

モデルが複数のコンテクストに所属しているため、全体像の理解が難しく、意図しないところの変更の影響をうけたり、処理の流れがつかみにくいコードになってしまっていました。

自動テストの実行時間が非常に長くなってしまうという問題もあります。クックパッドでは、現在17,000項目を超える自動テストが存在します。RRRspec という分散テスト実行システムによってテストを並列化することにより実行時間を10分前後にとどめていますが、これも少なくないコストをかけたうえで、ようやく実現できていることです。

デプロイしたいサブシステムのコードに問題がなくても、別のサブシステムが利用しているコードによってテストが失敗し、デプロイができないということが発生しうるのです。

リリースした機能は問題がなくても、他の部分に問題があったため、ロールバックをしなくてはならなくなったということもありました。

また、この記事を書いたクックパッドの高井さんは個人ブログの マイクロサービス（microservices）とは何か という記事の中で、以下のように言っています。

私個人としては、マイクロサービスという用語は、モノリシックなアーキテクチャを採用して成長してきたウェブ企業がその問題に対応していくなかで、自然と培ってきたテクニックやスタイルに名前がついたものとしてとらえています。

マイクロサービスは Web 開発で経験を積んできた企業や組織の中で、自然と生まれたアーキテクチャであるならば、その成否は、企業や組織の文化や開発のレベルと密接な関係にあるはずです。

マイクロサービスへの適性

マイクロサービスの導入にあたってのチェック項目を、Martin Fowler 氏が MicroservicePrerequisites という記事中で書いています。

下記に挙げた項目を満たしていないならば、時期尚早というコトで、企業や組織の文化づくりから始めるべきです。

迅速なプロビジョニング

• 新しいサーバを数時間で立ち上げられる
• ( 全てでは無くても ) インフラの自動化を進めている

基本的なモニタリング

• 技術的な問題 ( エラーの発生回数、サービスの可用性など ) がモニタリングできるようになっている
• ビジネス上の問題 ( 発注処理の失敗など ) もモニタリングできるようになっている
• 問題が発生した際にロールバックできるようになっている

アプリケーションの迅速なデプロイ

• デプロイが自動化されている ( 当初は多少の手作業があってもよい )

終わりに

大半のシステムでは、マイクロサービスは必要ない。　とはいえ、企業やサービスが成長するにつれ、システムはどんどん複雑化していき、個々の開発者では全体像が把握出来なくなり、モノリシックなアーキテクチャの弱点が、ビジネスの足をひっぱりはじめます。
その際に取れる選択肢の一つとして、マイクロサービスというアーキテクチャを覚えておいて損は無いかと思います。

この連載の次回 ( があるならば … ) は、Netflix やクックパッドでのマイクロサービス実装の事例を見ていけたらと思います。

ではまた次回。