
直接対決:モノリスとマイクロサービス
今すぐご利用いただけます • オンデマンド
マイクロサービスはソフトウェアアーキテクチャの一種で、アプリケーションの機能を小さな要素に分割し、回復力と拡張性を高めたものです。分割後の要素は「サービス」と呼ばれます。各サービスはアプリケーションの単一の機能のみを担います。他のサービスとは分離されており、それぞれが独立したものになっています。そのため、様々なサービスに関する作業を各開発チームが別々に行うことができます。チーム間で複雑な調整を行う必要はありません。
サービス同士はAPIやWebサービス経由で通信します。
マイクロサービスアーキテクチャ
マイクロサービスの由来を知ると、マイクロサービスとは何か、なぜ幅広く利用されるようになったかがよくわかります。ここで、マイクロサービスの歴史を簡単に振り返りましょう。
マイクロサービスは、その前身である「サービス」の生まれ変わりのようなものです。20年前にアーキテクトが考案したサービスというアイデアが、今マイクロサービスとなって当初の期待に応えているのです。サービス指向アーキテクチャ(SOA)は、扱いにくいモノリシックアプリケーションに対応するための切り札としてIT業界の期待を集めていました。
スタートアップ企業が拡張性の高い製品を開発して市場シェアを伸ばしていたころ、企業はバックログや政策的論争に頭を悩ませていました。そこで、企業はコアビジネス機能を含む小さなモノリスを作成して、モノリスを分割しようと考えました。
小さなモノリス、いわば「ミニリス」は、アジャイルプラクティスを推進し、水平型チームにプロダクトの完全なオーナーシップを割り当て、必要とする誰もがサービスに簡単にアクセスできるようにするために作成されました。すばらしい発想です。結果はどうなったでしょうか。
いわゆる「最新の技術トレンド」は、ほぼ例外なく一時的な流行に終わります。なぜでしょう。それは、プロが何年も実践してきたことが突然流行になるからです。プロの成功に刺激されたアマチュアが真似しようと思っても、そううまくはいきません。一握りの有能な個人が手をかけてサービスを作成するのを、それ以外のIT業界関係者がうらやましそうに眺めるという構図です。
アジャイルの創始者の1人であるMartin Fowler氏は、大半の組織は本当の意味でSOAに移行したわけではなく、主にエンタープライズサービスバス(ESB)などに複雑さを転嫁しただけだと評しています。ESBはサービスとコンシューマとの間の通信を処理するミドルウェアの1つです。企業は、モノリシックな母体からビジネスプロセスを分離する際の複雑さを軽減するためにこのESBを利用しました。その結果、技術的には機能するものの、変更やテストが難しく管理が不可能なブラックボックスソリューションができあがってしまったのです。
その結果、技術的には機能するものの、変更やテストが難しく管理が不可能なブラックボックスソリューションができあがってしまったのです。この状況を見たFowler氏は、ESBは「Erroneous Spaghetti Boxes(エラーだらけのスパゲティボックス)」の略語としたほうがよいのではないかと考えたそうです。
何かを説明しているとき、話した内容とはかけ離れた、明らかに誤解のある内容を相手がオウム返しにしてきたことはないでしょうか。もしくは、会話の最中に相手のうなずきが明らかに過剰だったことはないでしょうか。そのときの気持ちを思い出してください。世界中の企業がサービス指向アーキテクチャをうまく理解できず、様々な問題を発生させているのを見て、考案者はまさにそれと同じ気持ちになりました。
こうした状況では、誤解を解きたくなるものです。そこで考案者は、最初のコンセプトを「マイクロサービス」という形で言い換えました。基本的に、マイクロサービスはサービスが本来もたらすはずだったメリットを実現します。一般的な決まりは次のとおりです。
Netflix、Amazon、Uberといったテクノロジー企業大手は、多くのメリットが期待されるマイクロサービスをすでに導入しています。マイクロサービスのメリットは以下のとおりです。
残念ながら、他の最新のトレンドと同様、マイクロサービスもすべてがバラ色というわけではありません。以下のような問題があります。
マイクロサービスのメリットとデメリットを理解した今であれば、この問いに答えることができるはずです。最後にひとつアドバイスです。マイクロサービスの開発に着手する前に、なぜマイクロサービスアーキテクチャを開発したいのか考えてください。答えが「大企業がこぞって導入しているから」である場合は、方向性を間違っているかもしれません。
この記事では、マイクロサービスに関するメリットをいくつか紹介してきました。なぜそうしたアーキテクチャが有用なのかは、もうおわかりのはずです。独立した継続的統合および継続的デリバリー(CI/CD)パイプラインを複数持ち、様々なスキル、ベンダー、テクノロジーを活用しているチームもあるでしょう。
ただし、大切なのは有効活用できそうなタイミングを見極めることです。ほとんどの企業は、世界トップクラスのエンジニアを擁し、1つのアプリケーションを専門的に管理する開発スタッフを多数抱えているNetflixとは違います。人材は不足がちであり、平均的な企業では確保が難しいことが多いものです。また、そうした企業では開発が小規模であり、1つの製品ではなくビジネスで利用するアプリケーションポートフォリオに重点を置く傾向にあります。適切に利用しないと、マイクロサービスは手に負えないものになってしまうおそれがあります。
各アプローチのメリットとデメリットを理解することは、アーキテクチャに関する意思決定を適切に行ううえで重要です。
様々なアプローチの詳細と開発プロジェクトに適したアーキテクチャの選び方については、以下のリソースが参考になります。