こんにちは、編集長の白石です。
この記事は、9月24日に開催されるHTML5 Conference 2017に登壇するエキスパートに、予定しているセッションのトピックを中心に、様々な技術的なお話を伺おうというものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。
今回お話を伺ったのは、合同会社 Starlight & Storm 代表社員の長谷川裕一さんです。
▲合同会社 Starlight & Storm 代表社員 長谷川 裕一さん
長谷川さんのセッションは「Microservices入門」（ルームB 11:20-12:00）です。 （現在HTML5 Conferenceは定員オーバーの状態ですが、無料イベントということもあってキャンセルも多めに出るらしいので、あきらめずにキャンセル待ちすることをお勧めします！）
マイクロサービスとは？
白石: 長谷川さん、まずは簡単に自己紹介をお願いします。
長谷川: 私は日本Springユーザー会というコミュニティを運営していて、業務としてもSpring Framework関係のコンサルティングを行う企業を経営しています。業務アプリケーションのアーキテクチャ周りを相談されることが多いですね。ほかには、オブジェクト指向そのものに関する教育なども行っています。
※Spring Framework…Javaの世界で著名なフレームワーク。Dependency Injection （依存性注入）というコンセプトを世の中に広めたプロダクトとして名高く、Javaアプリケーションを作る際には、必ずと言っていいほど採用が検討される存在。
白石: Spring…ぼく昔、どっぷりJavaエンジニアでしたので、Javaのお話を思いっきりさせていただきたい衝動が沸き起こっておりますが…ここは我慢して(笑)。本題に入らせていただきますと、マイクロサービスとは簡潔に言うと何なのでしょうか？
長谷川: ソフトウェアを部品化しようという流れの中で生まれた、新しい部品だと思います。大きなシステムを構築する際にも、その部品を組み合わせて作りたいと考えているんです。 部品化はこれまでもたくさん考えられてきました。コンポーネントというのも部品ですし、Javaの世界ではEJB (Enterprise Java Beans)というテクノロジーもありました。SOA (Service Oriented Archetecture:サービス指向アーキテクチャ)が流行したこともあります。
その試行錯誤が続いている中で、現在たどり着いたのがマイクロサービスだと思っています。
粒度で言うと、EJBやSOAの1つのサービスよりは大きく、かと言って基幹システムに含まれる「販売」と「物流」みたいなサブシステムのように大きな単位ではありません。決まった粒度はないのですが、人によっては2週間でリリースできる程度の大きさとも言えますね。
白石: なるほど、システムを部品化する一つの方法であり、単位であるということですね。
長谷川: はい。また、マイクロサービスはそれぞれが個別にデータベースを持つように設計するのも特徴です。 これはサービスごとに「状態」を持つということで、いわばオブジェクト指向的とも言えるでしょう。
白石: どうして今、マイクロサービスはこれほど取り沙汰されているんでしょう？
長谷川: 流行している、と言ってもいいと思うのですが、どこで流行っているかというと、スタートアップ系とエンタープライズ系ですね。
スタートアップで流行っているのは、基本的にスタートアップでは新しいものを作るわけですが、その際にできるだけ早くリリースして、必要があればサービスを増やしてゆくことができるので、マイクロサービスアーキテクチャを取り込みやすいということだと思います。あと、馴染みのある技術で始めて育てていけるのもいいんんじゃないでしょうか。 RESTfulなWeb APIなど、普段から使っている技術を使ってサービスを作れる。
エンタープライズ系で流行っているのは、ビジネスの変化に素早く追従するためにはどうしたら良いか、とか、既存の古いシステムをどう移行していけばいいか、とか、常に悩ましく思っているという事情があるんじゃないかと思います。
だから、そうした悩みに答えられそうな新しいソリューションがあると、まずはチャレンジしてみようということになる。そうしたソリューションの中で、マイクロサービスが今はかなり魅力的に映っている…という風に、私は個人的には見ていますね。
マイクロサービスは万能薬ではない
白石: では、マイクロサービスの具体的なところを伺っていきたいと思います。マイクロサービスでシステムを構築するには、まずはどういう設計が必要なのでしょうか？
長谷川: 先程も申し上げましたが、マイクロサービスはデータと振る舞いを持つ「オブジェクト指向的」なものです。
だから、それぞれのサービスは小さく、自己完結した形でデータを保持している必要があります。つまり、データベースがそれぞれ分かれているのが普通です。複数のマイクロサービスが一つのデータベースを参照するような設計は、あまり良くありません。
白石: それぞれのサービスが独立するように設計する必要があるということですね。
長谷川: そうです。そういう前提のもと、マイクロサービスは万能薬ではないということを認識しておく必要があると思います。例えば、既存の巨大なシステムをマイクロサービスに分割したいというご相談はすごく多いのですが、実はそういう案件は難易度が高い。
白石: 私も以前エンタープライズ系で働いていましたので、巨大な業務アプリを「分割してスッキリさせたい」という要望が生じるのも分かる気がします。
長谷川: 一枚岩で作られた古くて巨大なシステムというのはたいてい、データもこんがらがってスパゲッティ状態になっているものです。で、マイクロサービスはそれぞれデータベースを分けるという前提に立つならば、そのこんがらがったデータとコードを慎重に解きほぐしていくという工程が必要になるんです。
ただ、古い巨大なシステムで、それができるかというとかなり難しいですよね。 全体像を把握することなくシステムを切り出すことはできませんが、全体像を把握するだけでも、凄まじいコストと能力が必要になります。マイクロサービスなどの技術以前の問題です。だからこそ、独立した粒度の小さいマイクロサービスが、古い巨大なシステムを持っている企業からすると魅力的に見えるのだと思いますが。
白石: なるほど…言われてみればその通りです。
長谷川: なので、マイクロサービスの導入が最もやりやすいのは、新規のサービスを開発する時ですね。既存の資産と連携しつつ、新しいお客様向けに新しいサービスを開発をする場合などは、既存のシステムへの機能追加という形ではなく、マイクロサービスとして構築するのがベストだと思います。
白石: だから、スタートアップ系では採用しやすいんですね。基本的に新規が多いから。
長谷川: ついでに言うと、ビューの部分がStrutsで書かれた業務システムを、Angularなどを使ってSPA (Single Page Application)化したいというご要望もかなり多いです。
「業務アプリを刷新するなら、マイクロサービスもSPAもやっておこう」みたいなノリですね(笑)。
白石: なんかそのノリわかる気がします(笑)。
長谷川: ただ、Struts (※)で書かれたものをSPAに…ってのも、実はすごく難しいんですよね。ビューがちゃんと層として分かれているシステムなら楽ですが、そうなっていないシステムも多いので。
白石: エンタープライズ・アプリケーション・アーキテクチャ・パターンに沿っているようなシステムならいいけど、そんなのはごく少数だと。
長谷川: そうそう。ひどいのになると、JSP (※)の中に思い切りSQL書いてあったりしますから(笑)。そういうシステムをSPA化するとなると、結局全面的に作り直しが必要になっちゃいますよね。合わせてマイクロサービスも…なんてやってたら、途方もないコストが必要になっちゃう。
※Struts…2000年代初頭に登場し、一世を風靡したJavaのWebアプリケーションフレームワーク
※JSP…Java Server Pagesの略。サーバサイドJavaで使われる標準的なテンプレート機能
マイクロサービスを設計するには
白石: では、マイクロサービスで具体的にシステムを設計していくには、どうしたらいいんでしょう？
長谷川: マイクロサービスは、それぞれが小さなシステムであるということを意識して、その内部もしっかりとレイヤーに分けて設計していくべきです。
白石: プレゼンテーション層、ビジネスロジック層、データアクセス層に分けていくという考え方ですね。
長谷川: そうです。そこは今までと変わりません。そして、それぞれのサービスがHTTPやキューを使って連携していきます。 小さなサービスがネットワークを介して繋がり合うので、サービスそれぞれに耐障害性を持たせたり、スケーラビリティを確保する必要はあります。
ただ、こうした耐障害性やスケーラビリティの知識って、今までも十分に議論されてきた分野なんですよね。だから、セオリーは確立されていると言ってもいい。今までの知識がそのまま使えますし、マイクロサービスだからといって特別なことはないんです。
それに、私はJavaでシステム開発を行いますが、Javaにはそういう事を行うための部品がすでに数多く揃っているんです。 だから実はそれらをうまく組み合わせるだけです。
白石: ただ、ぼくも昔Javaでアーキテクトをやっていた時期がありますが、いろんなフレームワークやライブラリを組み合わせて開発基盤を作るのって、すごく骨が折れますよね。
長谷川: Spring Bootというプロダクトを使うと、そこら辺の手間がほとんどいらないんです。 これはセッションでも紹介しようと思ってるんですが、Spring Bootは、様々なコンポーネントを組み合わせてセットアップする手間をほとんどゼロにしてしまう。
白石: それは興味深い…！（Java屋だった血が騒いでいる）
スタートアップやるならマイクロサービス？
白石: 実はぼくもTechFeedというサービスを作っているスタートアップなのですが、マイクロサービスを採用した方がいいのかな…？なんて思いつつ、たくさんのサービスに分割して管理する手間を考えて、結局モノリシック（一枚岩）に作ってしまっているんです。もし長谷川さんがスタートアップを始めるとしたら、やはりマイクロサービスで始めますか？
長谷川: そうです…と答えたいところですが、実際には場合によります。無理に分割するのも得策ではありませんし。
ただ、ビジネスの観点から考えていくと、「分けるほうが自然」というところが見えてくるんじゃないでしょうか。例えば、B2B2Cのビジネスがあったとして、B2C部分とB2B部分を別のサービスにするといった具合です。
白石: なるほどー。具体例を挙げてお話していただくとすると…、どんな感じでしょう？
長谷川: そうですねえ、例えば全国展開しているお弁当屋さんがあったとして ―― どんなお弁当屋さんか、私もよくわかりませんが ―― そのお弁当屋さんが、ネットで注文できたとするじゃないですか。一方で、注文から発送までを行うためのサプライチェーンのシステムがあったとします。
そしたら、一般ユーザー向けのサービスと、サプライチェーンのシステムは分けて作ったほうがよさそうですよね。
白石: 確かに、そこはシステムは分かれていたほうが自然に聞こえますね。なるほど、そういう単位でサービスを分けていくんですね。
長谷川: これは一例ですし、人によっても違うと思うんですけどね。システムを分割して管理していくのは、やはりそれに伴うコストもかかりますから、ビジネス上の視点が重要なのは間違いないと思います。
分割に伴うコストと、分割によるメリットの、損益分岐点みたいなものがきっとあるはず。それを意識して設計していくのが、ビジネスを含めて一貫性のあるアーキテクチャに繋がるのではないでしょうか。
白石: よくわかりました。本日は貴重なお話どうもありがとうございました。個人的には、久しぶりにエンタープライズなお話ができて楽しかったです😊
（この後、Javaな話で盛り上がりました）