エンジニアの市川です。記事を出すのが3日遅れたのを正直に報告します。概要や特徴について書かせていただきました。今回は、どのような場合にマイクロサービスを適用すべきかについて書いていきます。いう記事を記しています。記事中では以下のようなことが書かれています。開発チームがマイクロサービスを熱心に受け入れるあまり、それ自体がシステムを複雑にしているコトに気付いていない。これにより、プロジェクトのコストやリスクが増加し、深刻なトラブルにもつながる。マイクロサービスを利用するかどうかは、システムの"複雑さ"。マイクロサービスは複雑なシステムを扱うことを目的としている。そのため、アプローチ自体が複雑さを伴っている。分散システム導入に伴う仕事をしなくてはならない。ソフトウェアシステムの大部分は、単一のモノリシックなアプリケーションとして構築されるべき。記事中では、システムの"複雑さ"が小さい段階でマイクロサービスを導入すると、モノリシックなアーキテクチャに比べ、"生産性"が落ちてしまうことがグラフ化されています。グラフは縦軸が"生産性"で、横軸が"複雑さ"です。マイクロサービスは、小さなシステムで最初から導入するような考え方ではなく、システムの"複雑さ"が高まってから検討すれば良いことが、グラフから読み取れます。)ここでは、マイクロサービスの導入にいたるまでの経緯を、クックパッドさんの事例をもとに見て行こうと思います。いう記事が発表されました。記事中では、クックパッドがマイクロサービスへの転換を進めていることと、その背景が記されています。クックパッドでは巨大なコードベースを持つ、モノリシックなアーキテクチャゆえ、以下の課題を抱えていたコトが語られています。モデルが複数のコンテクストに所属しているため、全体像の理解が難しく、意図しないところの変更の影響をうけたり、処理の流れがつかみにくいコードになってしまっていました。自動テストの実行時間が非常に長くなってしまうという問題もあります。クックパッドでは、現在17,000項目を超える自動テストが存在します。いう分散テスト実行システムによってテストを並列化することにより実行時間を10分前後にとどめていますが、これも少なくないコストをかけたうえで、ようやく実現できていることです。デプロイしたいサブシステムのコードに問題がなくても、別のサブシステムが利用しているコードによってテストが失敗し、デプロイができないということが発生しうるのです。リリースした機能は問題がなくても、他の部分に問題があったため、ロールバックをしなくてはならなくなったということもありました。いう記事の中で、以下のように言っています。私個人としては、マイクロサービスという用語は、モノリシックなアーキテクチャを採用して成長してきたウェブ企業がその問題に対応していくなかで、自然と培ってきたテクニックやスタイルに名前がついたものとしてとらえています。開発で経験を積んできた企業や組織の中で、自然と生まれたアーキテクチャであるならば、その成否は、企業や組織の文化や開発のレベルと密接な関係にあるはずです。いう記事中で書いています。下記に挙げた項目を満たしていないならば、時期尚早というコトで、企業や組織の文化づくりから始めるべきです。)終わりに大半のシステムでは、マイクロサービスは必要ない。いえ、企業やサービスが成長するにつれ、システムはどんどん複雑化していき、個々の開発者では全体像が把握出来なくなり、モノリシックなアーキテクチャの弱点が、ビジネスの足をひっぱりはじめます。その際に取れる選択肢の一つとして、マイクロサービスというアーキテクチャを覚えておいて損は無いかと思います。クックパッドでのマイクロサービス実装の事例を見ていけたらと思います。