マイクロサービスとは
1つのシステムを受注、在庫、決済といった業務の単位で小さなサービスに分け、それぞれを独立して開発・リリースできるようにする設計の考え方です。サービス同士はネットワーク越しにAPI（Application Programming Interface）による呼び出しや、メッセージによる通知で連携します。対になるのはすべての機能を1つのシステムとしてまとめて構築する形で、モノリスと呼びます。
たとえるなら1つの大きな店舗を、テナントごとに鍵と営業時間を持つショッピングモールに作り替えるようなものです。各テナントは他の店を閉めずに改装できますが、モール全体の管理の手間は増えます。
なぜ必要か
システムが大規模になり、関わる開発者が増えると、1つのシステムを全員で変更することになります。ある機能の小さな修正でも他チームの変更と一緒にテストし、まとめてリリースしなければなりません。リリース日の調整やテスト待ちが増え、開発者を増やしても開発の速度が向上しなくなります。
マイクロサービスはこの状態を解消する考え方で、業務の単位でシステムを分割し、分割したサービスごとに担当チームを決めます。これにより各チームは他チームの作業の完了とは関係なくリリースできます。
システムの分け方はチームの分け方と対応させる必要があります。チームが1つしかない会社では分ける理由がほとんどありません。
効果
- チームごとに独立してリリースでき、リリースの頻度と速度を維持できる
- 1つのサービスの障害が作りによっては全体の停止にならない
- 負荷の高い機能だけを増強でき、インフラ費をかける対象を限定できる
- サービス単位で技術を入れ替えられ、全体をまとめて作り直さずに済む
- 担当範囲が明確になり、新規メンバーの把握すべき範囲が限定される
コストとリスク
- 監視、ログ収集、リリース自動化の仕組みが必須になり、初期構築と継続的な運用に人と費用がかかる
- 障害の原因がサービス間のどこにあるかを特定する調査が困難になる
- 複数サービスにまたがる機能の変更は1つのシステムより調整が増える
- サービスごとにデータを持つため、データの整合を取る設計が複雑になる。分析用にデータを収集する手間も増える
- サーバーやネットワークの費用は多くの場合1つのシステムより増える
- 複数のサービスにまたがる障害を調査して修正できる人材が必要で、採用と育成のコストがかかる
- 分け方を誤ると影響が大きくなる
- データベースの共有や呼び出しの連鎖のせいで、結局まとめてリリースしないと動作しなくなる。分散モノリスと呼ばれる状態で、運用の負担だけが増えた1つのシステムより悪い形になる
- 後から分け方を変えるのが1つのシステム内の整理よりはるかに手間がかかる
よくある誤解
マイクロサービスにすれば開発が速くなる
開発チームが2つまでの規模ではサービス間の連携や運用の手間が増えるぶん、むしろ遅くなることが多いです。
大量のアクセスを処理するにはマイクロサービスが必要
アクセス量への対応は1つのシステムのままでもサーバーを増やすことで多くの場合まかなえます。大規模なサービスでも1つのシステムのまま運用を続けている例はあります。EC（Electronic Commerce）プラットフォームのShopifyはマイクロサービスへ移行せず、1つのコードベースの中を業務単位で区切る構成を選択しました。その経緯を2019年に公表した記事で説明しています。
細かく分けるほど良い設計になる
サービスの数が増えるほど連携と運用の負担も増えます。サービスの数はチームの数に合わせて決定するもので、細かさそのものに価値はありません。どのサービスにも責任を持つチームが1つ決まっていることが前提になります。担当の決まらないサービスが出る分け方は、管理しきれないシステムの典型的な形です。
マイクロサービスは最新の考え方なので新規開発では採用すべき
新規開発はまず1つのシステムとして作り、規模が拡大してから分割する進め方が広く推奨されています。最初から分けるべきという反論もあります。事業の初期は業務の区切り自体が変化しやすく、早期に分割すると分け方の引き直しに多くの工数がかかります。新規開発はまず1つのシステムで構築するほうが安全です。
