大規模サービスで採用が増えているマイクロサービス
すべての機能を一枚岩（モノリス）のようにまとめて実装を行うモノリシックなアプリケーションは、実現したい機能が単純で、チームが小さい段階では実装が早くできるというメリットがある。その一方、機能の追加が続くと、コードベースが複雑になり、開発の生産性が下がり、リリースにともなうテストの負荷も大きくなるなど運用作業の負担が増加。変更の負担が増えることで、ビジネス成長にあわせたタイムリーな拡張が難しくなるというデメリットが発生することが多い。
そこで、Thoughtworks社のJames Lewis氏とMartin Fowler氏が2014年に提唱したのがマイクロサービスアーキテクチャだ。機能ごとにアプリケーションを分割し、サービス間を疎結合とし、 軽量なAPIなどでお互いが協調動作することにより一つのシステムを構成するというソフトウェアアーキテクチャ。これにより、各機能をより小さいコードベースで、それぞれ別のチームで独立して開発、リリース作業ができるようになり、大規模なアプリケーションでもビジネスのニーズに合わせた変更を簡単に行うことができるようになった。
また、前述の容易な機能追加に加えて、以下のようなメリットもマイクロサービスを採用すると享受することができ、近年BtoCの大規模なサービスなどで採用が増えている。
- スケールアウトが容易になる
- 可用性・耐障害性の向上
- 異なる技術を組み合わせることができる
コンテナが最適だと言える4つのポイント
前述のようにマイクロサービスを採用することで、様々なメリットを享受することが可能だが、これらのメリットを最大化するためにマイクロサービスのプラットフォームとしてはコンテナを採用されるケースが多い。その親和性について、それぞれのメリットとの関係を含めて、ポイントごとに解説する。
機能追加
マイクロサービスでは、コードベースを分割し、別々のチームで個別開発が可能になるが、裏返すとデプロイの頻度が多くなり、この作業負荷や作業ミスによる障害発生などが懸念となる。ここでアプリケーション基盤にコンテナを採用することで、デプロイ方法をすべてのサービスで「コンテナの入れ替え」にて統一、自動化することができる。これによりサービスごとにデプロイ方法が異なるという状況を回避でき、デプロイ作業が頻繁に発生しても作業負荷の高まりや手順ミスでの障害発生も防止できる。加えて、前回紹介した、CI/CDも合わせて採用することで、デプロイ作業を自動化し、これらの作業を人の手を介することなく実施できる。
スケールアウト
マイクロサービスを採用すると、より少ないリソースでシステムのスケールが可能となる。どういうことかと言うと、モノリシックなアプリケーションでは、アプリケーション全体でスケールしていたが、マイクロサービスでは分割されたマイクロサービス単位でスケールすることが可能だ。たとえば、ECサイトのマイクロサービスにおいては参照が増えた際に商品表示のAPIだけスケールでき、より少ないリソースで多くのトラフィックを捌ける。このように細かい単位でアプリケーションプロセスの稼働と、スケールのためのプロセスの増減が頻繁に発生するのがマイクロサービスであるが、基盤としてVMなど、オーバーヘッドの高いものを使うと、積み重なって無駄な大きなリソース消費となってしまうが、コンテナを利用することで無駄なコストを削減しつつ最大限のスケールを実現できる。
