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