InfoQ eMAG: Microservicesを少し読んだまとめと感想

August 20, 2014 - architecture

なんだか、世間的にMicroservicesが次の注目対象になりそうな感じです。

DockerConでも複数のセッションで言及があったり、はてブにもたまに関連記事があがってきたりしてます。

実態はどんなものかイメージしにくかったのですが、最近InfoQで公開されたeMAGが情報としてまとまっている気がしたので、これを読み進めています。

本に含まれている内容

この本は、過去のInfoQ記事や各ブログを再構成したもので、以下の記事タイトルがまとめられています。

  • Microservices: Decomposing Applications for Deployability and Scalability
  • Microservices and SOA
  • Adrian Cockcroft on Microservices and DevOps
  • Microservices? What about Nanoservices?
  • Building Products at SoundCloud
  • The Strengths and Weaknesses of Microservices
  • GOTO Berlin: Microservices as an Alternative to Monoliths

そのうち、以下を読んだので、まとめと雑感を書きます。

  • Microservices: Decomposing Applications for Deployability and Scalability
  • Building Products at SoundCloud

本の主題はMicroservices Architectureですが、それに伴うソフトウェアの設計手法などの参照もたくさん含まれているので、いろんな情報への入口としても勉強になると思います。

Microservices: Decomposing Applications for Deployability and Scalability

  • ドメイン単位で複数に分割されたもの小さなサービスのの集合体をMicroservices Architectureと呼ぶ
  • 既存フレームワークとかでservice層として定義していた単位が別々のプロセスに切りだされているイメージ
  • 一方、既存のシステムはMonolithic Architectureと呼ばれる
  • システム設計における単一責任原則の適用ともいえる
  • 現実に則したSOAの焼き直しである

メリット

  • 個々にデプロイ可能である
  • 個々のMicroserviceが独立しているため、サービス全体の可用性向上を期待できる
  • 開発チームを小さい単位に分割しやすい
  • 言語やフレームワークの移行が容易になる。変更が小規模なので仮に失敗しても取り戻しやすい。

デメリット

  • 個々にはシンプルでも全体の複雑性は増す
  • サービス間のIPCメカニズムが必要
  • サービス間をまたいだテストがやりにくい
  • 他サービスに影響する変更のデプロイは手順を十分に検討する必要がある
  • 運用が大変。ハイレベルな自動化が要求される

Building Products at SoundCloud

SoundCloudのMicroservices移行話は「Building Products at SoundCLoud」という三回分のブログ記事を再構成してまとめた内容になっています。

MonolithicなRailsアプリからMicroservicesに移行するまでの手順や失敗が紹介されていて、これから移行を進めるチームにとって有益になるでしょう。

彼らは既存アプリの機能をいきなり別言語で切り出すのではなく、

分析→リファクタリング→Service分割→新技術の採用

という手順を踏んでいます。この移行における重要な点は、どのような新技術を採用するかではなく、DDDをベースとしたドメイン分析を行うことにあると思います。分割の単位を誤ったなら個々のサービスの依存性を排除しきれなくなり全体の複雑性は確実に高くなります。

ドメイン分割の一例として、Bounded Contextを利用した例が紹介されています。

また、依存性の低い個々のMicroserviceにできることで、それぞれに独立したチームを配置することも可能になります。 ただ、それぞれのチームが無秩序に技術選定を行うことでスキルや情報の局所性(Bus Factorの低下)を招くことになるため、一定のルールを決めることも重要になるようです。結果として彼らはJVMベースのScala,ClojureJRubyを中心としたシステムを作ることを決定しています。(同時にGoとRubyもサポート)

雑感

Microservicesへ移行するにはサービス規模・システム規模・開発チーム規模が大きいことが前提であり、そうでない限りはMonolithicなシステムで頑張るほうが良いかな、というのが個人的な意見です。また、DDDのような適切なドメイン分析ができるアーキテクトが存在しない場合にもMicroservicesはあまり良い選択肢とはいえないと思います。それらの前提をクリアできるのであれば、長いプロダクトのライフスパンにおいて、システムそのものだけでなく開発チームも含めて良い影響をもらたすことになるのではないでしょうか。

ということで「Microservicesの本質はドメイン分析であり、デプロイ単位や技術選定などのメリットは副次的なものである」というのがこのeMAGを読んで得たとりあえずの結論です。

参考リンク

Martin Fowler氏の記事だけでなく、DockerConでのYelpのスライドやInfoQのbitlyの記事も参考になります。