はじめに
本記事は「モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド」を読了した上で、自分が学んだことをまとめたものになります。そもそもマイクロサービスとはどんなものか、どういったときに採用すべきものか、代替となる技術はないのか、どのように進めるのか、ということを検討されている方のご助力となれば幸いです。
マイクロサービスとは
webアプリケーションの設計方法のひとつです
ビジネス要件を区切り線として、プログラム、DB、サーバーを分離するアプローチを取ります。
比較されるその他の代表的な設計方針として、モノリス、モジュラモノリスが上げられます。
いくつかのSaaSプロダクトは、単一のサービスのみを提供するにとどまらず、代替する仕事の周辺の仕事を巻き込んで、オールインワンで解決できるようプロダクトを拡大させていく戦略を取ります。
例えば、倉庫管理サービスを提供しているプロダクトに、新たに配送管理の機能を追加する場合、モノリスな組み方では以下のような構成となります。
よくある構成ですよね。
このプロダクトに、受発注、契約、配車、採算、、など様々な機能が追加されるにつれ、継続的に従来の開発スピードを維持するのが日に日に難しくなっていくことは、エンジニアの皆様は体感されていることと思います。
- 自担当の開発を進めた結果、他の機能に悪影響を与えてしまった
- 他の機能を変更しないと、自担当の開発ができない
- 同時期に他の開発者と同じ箇所を触り、修正作業が多発、不具合も多発
こうした出来事は、各サービスが分離されていれば解決されるかもしれません。
マイクロサービスは、各サービスが独立して開発を進めることのできる環境を提供してくれます。
メリット
独立させることで、どんないいことがあるのでしょうか。
- 好きなように設計できる
好きな言語、好きなフレームワーク、好きなデータベース、提供するサービス内容や開発者にとって都合の良い技術選定をすることがしやすくなります。 - 好きなように開発できる
他の開発チームとの連携、合意形成の手間が少なくなります。問題解決の方法も、独自に決定することができます。
デメリット
「独立」がメリットである、というのはまさに言いえて妙だなと感じるのですが、集団から独立をするということは、集団では享受できていた恩恵を手放すということでもあります。
例えば
- 自由が利く故、判断や悩みの回数が増えてしまう。結果として開発速度が落ちることもあり得る。
何か話せと言われるより、昨日の晩飯について話せ、と言われる方がしゃべりやすいですよね。 - 独立したサービス間の連携に難が生じる
サーバー間の通信が発生することでアプリの速度が低下したり、データベース間の整合性を保ちにくくなったり、工程が増えることでミスが発生しやすくなったり
以上をまとめ、上述の本の中では「マイクロサービスは選択肢を買い与える」という表現が使用されていました。つまり、今より良い状態になるために対価が必要になるということです。対価を支払うことになるのであれば、その結果手に入るものが、本当に自分が欲しかったものなのか、吟味する必要があります。
代替案はないのか
悩みによっては、マイクロサービスを採用することもなく解決ができることが、いくつか例示されます。
- 責任範囲を明確にして、チームの自律性を高めたい
<- アーキテクチャの変更は必須ではなく、プログラムやスキーマ単位で明確に振り分けることもできる。 - 開発スピードを高めたい
<- 本当にスピードを落としているのは、並列に開発を進めていることが原因なのか、考えてみた方が良い。単純に解決策を組み上げるのに時間がかかっているだけかもしれない。 - 各サービスの耐久性をコスパよく調整したい
<- サーバーを分離せずとも、性能を上げたり、複数台並べたりする方法もある。この対策で消費されるコストはがいくらなのかを見つめてからでも遅くはない。 - 開発者を増やしたい（=> 開発スピードを高めたい）
<- 前述の通り、必要なことは線を引くことで、サービスを分離することではない。
自分の抱えている悩みに対して、もっとシンプルに解決する方法はないか、精査することが推奨されます。
怪しげなサイン
それでも、マイクロサービスをやりたい場合、以下のような状況でないか、立ち止まって考えてみましょう。
- そもそも、境界線の決め方がよく分からない
サービスの開発初期段階で、何をしていくかの土台が固まっていない、自信が持てない場合は、着手をしてもサービスを分割することができない、もしくは不都合な分割をしてしまう可能性があります。従って、創業初期のスタートアップなどには一般に不向きと言えるでしょう。サービスを分けるのも大変ですが、再度合体させるのも大変で、不可逆な意思決定になりかねません。
それでも必要であれば
やはり、選択肢を買い与える、ですから、できるだけ少ない金額で買って、効果があるか試してみるのが定石でしょう。一気に全てを分割するのではなく、段階的に一番優先度の高いサービスから分離していくことが推奨されます。分離をさせるためには、境界線を引くことが必要です。この境界がプログラム単位でうまく分かれていると、次のサーバーへの載せ替えもスムーズそうです。
モジュラーモノリス
DBやサーバーは統一、だけどプログラムは責任範囲に応じて明確に分けておく、というアプローチにはモジュラーモノリスという名前が付けられています。
こうなっていれば、各サービスを独立させるのは簡単そうですね。感覚的にはいわゆるドメイン駆動設計がきちんとできているか、どうか、ということと同義だと考えています。
プログラムは分離されたにしても、DBの分離にはまたさらに苦労がかかりそうです。この辺りはスキーマで興味のある物事をわけておくとよさそうです。
ほとんどの会社にとって、困りごとは様々あれど、最も優先されることは「開発の質と量を高めたい」に尽きると思います。本記事の冒頭で上げた、作業がぶつかることによる品質、開発速度の低下は、責任範囲を明確にし、できるならそれがきれいに反映された、自分の作業が他者に影響を与えないような構造のプログラムおよびDBの構造を持っている、という状況に変われば、ほとんど解決してしまうかもしれません。
もしマイクロサービスへの移行が必要になったら、まずはモジュラモノリスの形状を目指してみて、実は当初の目的が達成されていないか、振り返るのが良さそうです。
おわりに
マイクロサービスについて、ご紹介しました。今回拝読した「モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド」ですが、著者様なのか訳者様なのか、とても文章表現が分かりやすく、また人柄が伝わってくるような内容で、ぜひ様々なエンジニアの方にご一読いただきたいと思い、とりあげさせて頂きました。内容的には軽い気持ちでマイクロサービスに手を出そうとする人へ警鐘を鳴らすような内容になっており、「止めておきながら、ではどうしたらいいんですかという問いには、安易には答えられません。ごめんなさい」という表現が随所に出てくるのがとても魅力的でした。しかしずいぶん様々なケースを網羅されており、各ケースに合わせた提言を十分に提示して頂いている内容のように感じました。
株式会社LOKIARでは、物流コンサルティング、システム開発業務を承っております。ぜひお気軽にお問合せくださいませ。物流について相談する
また、弊社では開発にご助力いただける方を募集しています。
まずはカジュアルに情報交換させて頂ければと思いますので、
ぜひこちらからお問い合わせください。