マイクロサービスのメリット/デメリットは？
こんにちは。Build サービス推進チームで Solution Architect をしている t_maru です。
今回はマイクロサービスについて考えてみたいと思います。
マイクロサービスとは？
マイクロサービスは、小さな独立した複数のサービスでソフトウェアを構成する、ソフトウェア開発に対するアーキテクチャ的、組織的アプローチです。各サービスは、正確に定義された API を通じてやり取りします。これらのサービスは、小規模の自己完結できるチームが所有します。
マイクロサービスアーキテクチャはアプリケーションのスケーリングを容易にし、開発期間を短縮するため、イノベーションの実現と新機能の市場投入の加速につながります。
上記は、AWS のマイクロサービスの概要の引用です。ここに記載されているようにマイクロサービスとは、小さなサービスの集合としてシステムやアプリケーションを構成する、ソフトウェア開発の技法の一つです。各サービスは疎結合な状態に保たれ、サービス間の通信は API call により行われるのが一般的です。
マイクロサービスのメリットはなにか？
マイクロサービスでよく挙げられるメリットとしては以下のようなものがあると思います。
サービス間が疎結合なので・・・
ビルド、テスト、デプロイ、ロールバックがサービス単位で可能となり開発が柔軟になる
サービスごとにリソースをスケールできるようになる
障害時のリスクを局所化できる
サービスは特定の機能に特化したものとなるのでサービス自体はシンプルになる
サービス毎に独立して開発を行えるので、用途に適した技術や言語を選択できる
マイクロサービスのサービス単体に焦点をあてると上記のように、疎結合だからこそ得られるメリットとして開発の柔軟性が高くなり、動作するリソースの量すらサービス単位で適切な容量を選択できるようになります。先程のマイクロサービスの概要にも記載のあったように、サービス単位でチームをアサインすることができれば、管理・開発はチームで完結することができるため (サービス間連携のため他のサービスの開発しているチームとの連携は必要になりますが)、そのサービスを実現するに当たり本当に必要な技術だけを選んで実装することができる可能性が生まれると思います。
デメリットは存在しないのか？
次にデメリットになりえるものはないのか考えてみようと思います。
分割されたサービス毎に管理・監視が必要となるため、運用負荷が増す
マイクロサービスの集合として構成されるシステム全体としては設計は難しくなる可能性がある
データの一貫性を保つための仕組みが必要になる
サービス毎にチームがアサインできない場合、あまりにも違う技術の組み合わせを使ってしまうと開発効率が低下する恐れがある
上記にデメリットになりえる事項を挙げてみましたが、先程のメリットがサービス単体について焦点をあてているのに対して、デメリットについてはシステム全体を見たときに生じる事項が多い印象ではないでしょうか。
上記のうちの `データの一貫性を保つための仕組みが必要` という項目に関しては、マイクロサービスにだけに起こる問題ではなく、システム外の API を呼び出す必要が出た場合に起こる問題であり、設計・開発する際に考慮する必要があります。この点関しては、このまま続きで記載すると記事が長くなってしまうため、今後の別記事で紹介したいと思います。
まとめ
今回はマイクロサービスのメリットとデメリットについて考えてみました。
個人的な見解ではありますが、スモールスタートでアイデアを具現化していくという過程では、最初からマイクロサービスを導入するのはやりすぎではないかなと考えています。ただ、一度サービスインしてしまったシステムを後から改変していくことは大変な労力がかかることは身を持って体感しているため、スケールすることがある程度見通せるものについては予めマイクロサービスで作っておくということも良い選択であると思います。
マイクロサービスにすることによるメリットは確かに存在していますが銀の弾丸ではないので、システムの規模や開発体制も含めて利用するかどうかを決定することがより良い選択になるのではないでしょうか。