マイクロサービスとは

マイクロサービスとは

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つのシステムで構築するほうが安全です。