こんにちは、編集長の白石です。

この記事は、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な話で盛り上がりました）

HTML5Experts.jp名物、いろんな会社におじゃまして開発環境や開発体制とかを根掘り葉掘り聞く企画、今回はIoT通信プラットフォームとして大変な注目を集めるソラコムさんに伺ってきました。

インタビューに答えてくれたのは、執行役員プリンシパルソフトウェアエンジニアの片山暁雄さん、シニアソフトウェアエンジニアの清水雄太さん、同じくシニアソフトウェアエンジニアの小熊崇さんです。
今回は副編集長の仲さんがインタビュアーを務めます。

まずは自己紹介から！

仲 本企画は、イケてるサービスを作っている会社を訪問して、どう開発しているのかなどを根掘り葉掘り聞く企画です。まずは、自己紹介からお願いできますか？

片山 イケてるっていう前提がハードル高いですね(笑) 。

私は現職ではソフトウェアエンジニアで、課金の周りやSIMを管理する仕組みなどを開発しています。どちらかというとバックエンド寄りですね。もともとはJavaのプログラマーを10数年やっていて、以前は金融業界にいたので、ずっとBigDecimalとかを扱うプログラムを書いていました。結局今も同じようなことをやっていますけど(笑)。

前職はAWSでサービスの普及に務めていたのですが、だいぶ普及も進んだのでプログラマーに戻ろうかなと思い、転職して今ここにいるというかんじです。

▲株式会社ソラコム 執行役員 プリンシパルソフトウェアエンジニア 片山暁雄さん

小熊 私はソラコムに入社した当初は、Webの管理コンソールを開発していました。

今はAPIのゲートウェイになる部分を作っています。ソラコムのバックエンドは、実際にはいくつものマイクロサービスに分かれているのですが、それを外から見た時に単一のAPI群に見えるようなゲートウェイを作っています。

あとは、コマンドラインインターフェースやSDKなど、開発者の皆様に使っていただく部分を開発しています。

▲株式会社ソラコム シニアソフトウェアエンジニア 小熊崇さん

清水 私はフロントエンドを中心に担当しています。例えば、先ほどの小熊が以前開発していたWebの管理コンソールは、現在私が開発を引き継いでいます。

前職でRuby on Railsを使ってフロントエンド・バックエンドの開発を行っていましたので、ここでもそういう役割が多いですね。

ほかにも、普段の開発作業で行うスタンドアップ・ミーティングやSlackなど、開発体制の整備も行っています。このオフィスを作るにあたってのディレクションなど、開発から少し外れた部分も担当しています。

▲株式会社ソラコム シニアソフトウェアエンジニア 清水雄太さん

ソラコムって…なに？

仲 では、ソラコムさんのサービスの概要を教えていただけますか？

片山 はい、私たちのサービスを一言で言うならIoT向けの通信プラットフォームです。IoTのサービスを実際に展開しようとした際に発生する、技術的な課題やビジネス上の課題解決を支援するためのプラットフォームです。

具体的には、3GやLTEといったモバイル通信を使った通信サービス、そしてそれらをうまくクラウドにつなぐためのサービスです。 SIMカード「SORACOM Air」は、Amazon.co.jpで1枚から通販で購入可能です。また、世界の120の国と地域で通信を行えるようになります。

SIMカードを提供するとだけでは従来の通信事業者さんと変わらないのですが、私たちの特徴はIoTに特化しているというところです。

まず私たちの特徴の一つとしては、通信事業者であれば通常必要とされるようなパケット交換機や顧客管理といった通信用のハードウェアを一切持っていません。専用のハードウェアを用意する代わりに、それらを実現するソフトウェアコンポーネントを用意して、AWS上ですべてを実現しています。

通信に必要な基地局などは、MVNOとして通信キャリアから借りて、クラウド上ですべてを処理できる仕組みを持っています。

仲 なるほど、IoTに特化した、クラウドネイティブなMVNOというかんじですね。

片山 こうしたサービスをAPIの形で公開している、というのも大きな特徴と言えるでしょう。

IoTをやろうと考えるお客様は、数万から数十万の回線を扱うことも、特別なことではありません。例えばビーコンに通信機器を入れて全国にばらまく、といったことをする場合は相当な回線数になるので、人手では管理しにくい。

そこをAPIで管理できるようにしているので、通信量のモニタリングや、異常があったら通信を止めたりということを自動化していただくことができる。こうしたあたりが、私たちが「IoT向け」と謳っている強みになります。

また、3G網からAWSに専用線でつなぐこともできるので、Internet of Thingsといえども「インターネットを使わない」という環境を作ることもできます。

例えば自社システムがAWSの中だけにあったりする場合に、SIMカードを持っている人しか閉域に入れないような仕組みも簡単に作ることができる。そういった、セキュリティが重視されるIoTのシステムなんかも作ることが可能です。

また最近のアップデートとしては、「LoRaWAN」という通信量は限られているのですが、非常に省電力で広域まで届く通信プロトコルにも対応します。 そうなってくると、さらに多くのお客様に使っていただけるんじゃないかと思っています。

白石 私のようなWebエンジニアが、ソラコムさんのサービスを使って、何かしらIoTを試してみたい…ということもできるんでしょうか。

片山 はい、最近だとRasberry Piのような汎用的なデバイスもありますし、簡単に試せると思います。SIMのソケットを持つIoTデバイスを用意して、ほんとに簡単なロジックを書くだけで、クラウドまでデータが届きます。

例えばcurlコマンドでHTTP POSTするだけとかでもいい。JSON形式のデータでクラウドまで届きますので、後はご自由にどうぞというかんじです。

ソラコムの開発はどのような体制で行われている？

仲 ソラコムさんはWebのフロントエンドから通信キャリア的なバックエンドまで幅広く開発をされていますね。開発チームの体制などについて伺ってもよろしいでしょうか？

片山 あまり、チームに分かれて開発…というっかんじではないかもしれません。私たちは2週間のイテレーションをベースとして開発しており、2週間に1回インテグレートしてリリース、というのを繰り返しています。

なので、イテレーションを開始する際に次に実現する機能のプランニングや担当を割り振って、あとは個々人がそれぞれ進めていきます。

仲 なるほど。

片山 ただ、担当の割り振りについては、決まったものがあるわけではありません。エンジニアの平均年齢は30代中盤、ぼくらは各分野で経験を積んできたメンバーが集った、言ってみれば「おっさんベンチャー」なので(笑)、「これしかできません」っていう人はあんまりいない。

足りないところがあったら「代わりにやりますね」という雰囲気です。

仲 皆さん、一番得意なスキルはあれども、その他のこともこなせるというかんじなんですね。

清水 開発者としては実際に10名ちょっとなので、基本的に1チームで開発を進めている雰囲気です。

片山 弊社は、ベースが開発者っぽい人が多いんです。例えば、ビジネス開発をしているメンバーも、実はデバイスにものすごく詳しかったりして、コマンドラインで作業したり、ハードウェアの調査をしたりというのを普通にやったりするので…。だから、そういうところからも開発リソースを調達したりしています(笑)。

雨だから人が来ていない(笑)

仲 グローバル展開されているので、海外にも開発者がいるわけですよね。海外メンバーとのコミュニケーションはどのように取っていらっしゃいますか？

片山 基本的にはSlackとかGoogle Hangoutとかですね。ビデオ会議システムについては、いろいろ紆余曲折がある(笑)。

清水 例えばSlack Callsはまだリリースされたばかりで、機能も不足しています。スクリーン共有ができなかったり。なのでappear.inとかGoogle HangoutとかSkype for Businessとか、いろいろ試しましたね。まだここについては決定版がないという状態です。

白石 リモートワークが可能な体制になっているわけですね。そういえばこのオフィスも、他にほとんど人がいない状態ですが、皆さん別の場所で仕事してらっしゃるんでしょうか？

片山 はい、今日人が少ないのは雨だからだと思います(笑)。生産性を高く保てる環境で仕事をしているはずです。

清水 もちろんオフィスにいないと困る職種の人もいるので、そういう人は基本的に出社していますね。

マイクロサービス・アーキテクチャが実現する「開発者の自由」

仲 では実際の開発をどのように進めているかも教えてください。具体的にはどのようなプログラミング言語を使って開発していますか？

小熊 基本的には、先ほども申し上げたように、ソラコムの内側はマイクロサービスとして分かれているので、それぞれのサービスを開発者が選んだ言語で開発しています。

片山 例えば「使いたいライブラリがその言語にあるから」という理由で言語を採用することもありますね。ぼくらはスタートアップなので、一番早く実装できる方法を選択したいというのがその理由です。

今のところ、使っている言語としてはGo、Java、Node.js、C…。あと、AWS Lambdaの開発は、実はPythonが一番やりやすかったりもするので、Pythonを使ったりということもしていますね。

仲 その技術を採用する前に、誰かに相談したりはしないんですか？

片山 CTOに相談したり、といったことは多少ありますけど、基本的には開発者の自由ですね。

仲 なるほど、マイクロサービスに分けているからこそ、様々な言語を混在させることも可能なわけですね。興味本位で伺いますが、そこまで自由だと今後エンジニアが増えていったときとかに、「既存のコンポーネントを自分の好きな言語で書き直したい」なんて要望も出てきたりしないのかな…なんて。

小熊 書き直す正当な理由があるなら、それも許されるとは思います。REST APIの定義さえ変わらなければ、あるコンポーネントの中身がごっそり置き換わっても他の部分には影響ないですし。

片山 あとマイクロサービスのいいところは、オーナーシップがわかりやすいことですね。サービスごとに開発した人が大体分かれているので、担当者が自然と定まってくる。もし今後開発者が増えていって、100人とかになった時に、今と同じことができるかはわからないです。

そうなったら、ある程度統一しようという話も出てくるのかもしれませんが、とりあえず現在の段階では、マイクロサービスを開発者それぞれが開発するという体制でスケールアウトを目指したほうが素早くサービスを拡張できると考えています。

仲 マイクロサービスによる開発には、開発そのものをスケールアウトできるというメリットもあるわけですね。

白石 しかしそれだけ多様で自由に開発しているとなると、コードレビューなどが難しくなったりはしないのでしょうか？

片山 コードそのものよりも、仕組みやアーキテクチャ、APIのほうを重点的にレビューするようにしていますね。

小熊 開発をしていると、呼び出す相手のコンポーネントについて APIの挙動がよく分からなかったり、バグっぽかったりしても、相手に聞いたりする前にまずコンポーネントのコード読んじゃって、「あ、なるほど、こうやってこのAPI呼び出すのか」とかって自己解決しちゃったりすることもあります。

その際に、そのコードが難解すぎて読めないとか、何をするためのコードなのか理解できないとかいったようなことはこれまで経験していません。事前にアーキテクチャなどをレビューしているからということもありますし、各コンポーネントを担当しているエンジニアのスキルが一定以上の水準だからだと思います。

清水 私の担当しているユーザーコンソールなどは複数人で開発しているので、少しレビューを綿密にやっていたりはしますね。

（筆者補足: ソラコムさんは「理想的なリーダーシップ」について書かれた15の項目「リーダーシップ・ステートメント」をメンバー内で共有し、定期的に議論、各自が実践することで、自由なワークスタイル、自由な開発体制、そして各自が責任を持って仕事をすることを同時に実現しているのだそう。見習いたい！）

DevOpsではなくOpsDev

仲 サービスの運用などについても聞いてみたいです。DevOpsのあたりとかは、どのように運用を自動化しているのでしょうか？

小熊 そこは、弊社だとOpsDevと呼んでいるんです。Opsをメインでやっている人間が強いこだわりを持っていまして(笑)。開発したものを運用するんじゃなくて、運用のためにこそ開発がある、と。

仲 運用をメインで行うチームがあるというわけではないんですか。

小熊 まず、そもそも開発メンバー自体が、日々の運用やサポートにも直接参加しています。いわゆるDevOpsです。さらに弊社では、運用の自動化にメインで取り組むエンジニアが一人いて、彼を中心に様々な自動化や監視を行っています。

片山 メインはZabbixによる監視と、Ansibleによる自動化をしています。何か問題があったら、次はどうそれを自動化するかとか、次に問題をどうやって起こさなくするかとかを決めて、あとはそれを担当のOpsDevエンジニア中心にやる、という運用になっていますね。

白石 御社だと、運用そのものがビジネスかもしれませんよね。

片山 はい、そうなんです。通信コア部分を安定的に、そしてスケーラブルにAWS上で動かすというのが我々のビジネスの根源と言えば根源なので、そこは一番力を入れています。

なのでそれ以外の、例えば私が書いているバックエンドの部分などは、AWSのBeanstalkなどにを使えばそれなりにスケールアウトするし、それに頼って作っているという部分はありますね。

仲 先ほど「スケーラブル」という単語が出てきましたが、スケーラビリティを担保するためにどのようなアーキテクチャになっていますか？

片山 一言で言うのは難しいですが、例えば一番ネックになるデータベース部分はDynamo DBをメインで使っています。メインとなる通信サービスで、RDB使ってるところはほとんどないんじゃないかな。

ただDynamo DBだと、アプリケーション側で頑張らなきゃいけない部分が出てくるので、そこは頑張るといった感じですね(笑)。

白石 マイクロサービスだし、DBも分けてらっしゃるんですよね？

片山 はい、そうです。ただ、使っているDBはみなDynamo DBですね。

白石 決済の部分とかは、トランザクション処理が必要だと思いますが、そこはどうしてるんでしょう？

片山 そこもDynamo DBで頑張っています。Dynamo DBはトランザクションがあるにはあるのですが、2レコードをアトミックに更新できないので、極力1レコードに寄せるようにしたりとか。あと公式のトランザクションライブラリもありますし。

仲 ほかには、ログの管理などはどうしてらっしゃいますか？

片山 Logglyというサービスを使っていますね。ライブラリを使ってログを送ると、よしなにインデックスしてくれるようなサービスです。

仲 Elastic Searchを自前で運用したりはしていないのですね。

片山 はい。弊社のサービスは、ログの分析などがビジネスの源泉になるものではないので。ビジネスの源泉になる部分は自社開発にこだわっていますが、それ以外の部分は積極的に外部のサービスを使用するようにしています。

ソラコムの課題・改善点

仲 では、ソラコムの開発において、課題だと感じていることや今後改善していきたい点などはありますか？

片山 個人的に継続的に追求していきたい課題としては、いかにチームを小さく保っていられるかというところですね。

人が増えるといろんなロスが発生してくるじゃないですか。機動性を確保しておくために、人をなるべく増やさない。そのために必要なのは生産性を上げることなのか、一人が何役もできるようにすることなのか、ということですが、そこを追求していきたいと思っています。

清水 私も、今の片山の話ともリンクしていると思いますが、作るものをいかに小さく保っておけるかが大事だと考えています。大きなものを作ろうと思うと、沢山の人が必要になるし、メンテナンスも必要になってくる。

なので、同じ価値を少ない機能やコンポーネントで実現するということにはこだわっていきたいですね。今はまだぼくらは、機能やツールを追加していくフェーズではありますが、ある程度、一通り揃ったタイミングで、いかにそれらを減らしていけるか、シンプルにしていけるかは考えていきたいと思います。

小熊 ぼくは…課題とか不満とか、あんまりないですねえ(笑)。すごく自由だし、生産性も高いし、今のところ申し分ありません。

あらゆるものが「目」を獲得し進化する

白石 では最後になりますが、まだIoTに取り組んだことのないエンジニアに対して、IoTにどう取り組むべきかを教えてください。

清水 私はもともとWebエンジニアなんですけれども、IoTをやると、様々な業種の人々と接することになるのが楽しかったりします。

例えばWeb系の勉強会だったら、Webのトピックがやっぱり一番熱いので、Webの話が中心になる。それはそれで楽しいのですけど、ソラコムのユーザーグループだったり、メイカーズ・ムーブメントだったりに顔を出していくと、自分と同じくらいのスキルセットを持った人がぜんぜん違うことをやっていたりするわけです。

サーバーサイドもできるんだけど、Arduinoで何かやっていたりもする。そういう人たちに接すると、IoTに取り組むモチベーションも上がったりするんじゃないかなと思います。

小熊 私はもともと組み込み系の出身なんです。組み込みの業界のエンジニアは、「Webやクラウドについてはまだわからない」という人も多いですが、エンジニアリングの基礎がしっかりしているので、吸収も速いと感じています。

なので、組み込みの方々がIoTに取り組むのはすごく向いているので、ぜひトライしてみるといいと思います。

片山 個人的には、IoTでワクワクすることの一つは、あらゆるものに「手足」や「目」ができることだと思っています。どんなものにもセンサーが付き、デジタルデータ化できる可能性がある。

例えばぼくは、部屋のあらゆるものの最終アクセス日時が分かったら、片付けとかにすごく便利じゃないかと考えているんですよね。

白石 確かに(笑)。

片山 センサーだけじゃなくて、Amazon Goみたいに画像解析によるアプローチもあるし、そういうアイデアが実現可能な時代はもう来ている。これが進んで、身の回りのものがデジタルデータになることで、世界はもっと面白く、便利になるんじゃないかと思っています。

生物はカンブリア紀に目を獲得したことで、大幅に進化が進んだと言われているのですよね。それと同じことが、今まさに起ころうとしているんじゃないかなと。現在、そういう進化の途上なのだと考えると、IoTの波に乗っかってみるのも悪くはないと思えるんじゃないでしょうか。

巨大化・複雑化したモノリシックなアプリケーション開発から、サービスを小さい単位に分割し、開発のスピードを上げようとするマイクロサービスが注目されています。アプリ開発のアーキテクチャとして関心はあるのものの、実際にはどのようなメリット・デメリットがあるのかは気になるところ。

そこで、マイクロサービスアーキテクチャを採用して新サービスをリリースしたという株式会社ビズリーチ・CTO室チーフアーキテクトの竹添直樹さんに、お話を伺ってきました。
聞き手は、HTML5 Experts.jp編集部・岩瀬義昌（@iwashi86）さん、HTML5 Experts.jp編集長・白石俊平さんです。

そもそもマイクロサービスって何ですか？

岩瀬：そもそもマイクロサービスとは、どのようなアーキテクチャなのでしょうか。

竹添：システムをがちっとした一枚岩で作るのでなく、コンポーネントに分割して、小さなサービスの集合体として構築するという考え方がマイクロサービスです。各サービス間は疎結合で、HTTPやMessagingなどでつなぎ、通信し合えるように設計します。

　▲ビズリーチの新サービスをScalaで作ってみた～マイクロサービスの裏側 #jissenscala

岩瀬：一般的に、これがマイクロサービスだという代表例はありますか？

竹添：外側から見ているとわかりにくいですが、Amazonさんのシステムがそうですね。チームがそれぞれ独立してサービスを作っていて、裏側はそれぞれマイクロサービスになっているというのは有名です。

　▲株式会社ビズリーチ CTO室 チーフアーキテクト　竹添直樹さん

岩瀬：モノリシックのほうはどうでしょう。

竹添：小さくてまだ立ち上げたばかりのサービスは、モノリシックが多いと思います。そうしたサービスが大きくなるにつれて機動力が落ち、メンテナンスコストも増大するにつれ、マイクロサービス化するという流れが多いのかなと。

岩瀬：ちなみに例えばWordPressは、がっつり一枚岩で作られている印象があるのですが、モノリシックですか？

竹添：マイクロサービスの粒度をどう考えるかによりますね。ブログという一つのサービスと見ることもできるし、アーキテクチャとしてはがっちり一枚岩だと思います(笑)。

岩瀬：確かに、人によって解釈が違うから定義は難しいですね。

　▲HTML5 Experts.jp編集部　NTTコミュニケーションズ 技術開発部所属 岩瀬 義昌さん

竹添：たとえば、決済サービスは呼ぶ側からすれば、マイクロサービスと言えるかと。

岩瀬：たしかに！では、Web制作で最近よく見るシングルページ・アプリケーションはいかがでしょうか？

竹添：フロントエンドがどうあれ、裏側にあるサーバーサイドのシステムが一枚岩かどうかが、マイクロサービスとモノリシックの違いになります。例えば管理者向けの機能とコンシューマ向け機能がそれぞれが独立されたサービスになっていて、APIで必要なデータだけをやりとりする…といった作りがマイクロサービス。フロントエンドとバックエンドのやりとりが、APIでシンプルになっているからといって、マイクロサービスというわけでもないんです。

マイクロサービスのメリットとデメリット

岩瀬：マイクロサービスのメリットって、どんなところだとお考えですか？

竹添：そもそも弊社がマイクロサービスを採用したのは、それぞれのサービスが独立して開発やメンテナンスができるからなんです。全サービスのシステムへの影響を考えなくていいのが、最大のメリットと言えるでしょう。どんなシステムも、運用をずっと続けていくとアーキテクチャが古びてしまうことは避けられません。そのときに全部新しいものに載せ換えるのは、全サービスの停止を伴うことが多いので、リスクも高いしコストもかかる。部分的にメンテナンスしたり、稼働できるというのはいいですね。

運用面やバッチ処理、アップデートも、そのサービスごとに単位で入れ替えたりできる。古いアーキテクチャを差し替えるときや、新しいサービスを立ち上げるときも既存システムを止めずに開発できるので、トライアルもしやすいです。また、SEOが重要なサービスと、業務寄りのサービスとでは目指す方向も、適している技術も違います。サービスごとに技術の選択ができるのは大きいですね。

開発者の問題もあって、全部同じ技術でできるかというとそうでもない。エンジニアによって得手不得手があるので、チームとしてもプロジェクトとしてもスケールしやすい面があるなと。

岩瀬：スケーラビリティはキーワードですね。バックエンドの言語を好きに選べるというのは、生産性も上がるし、組織的なメリットがあると思います。

岩瀬：では、マイクロサービスのデメリットはいかがでしょうか？

竹添：デメリットの部分ももちろんあります。サービスごとに冗長性を考えなくてはいけないので、コストも手間もその分かかります。モノリシックならロードバランサ一つでサービス全体を冗長化できますが、マイクロサービスだとそうもいかないので、オーバーヘッドとかインフラとか運用のコストがかかるのが悩みどころです。

また、実際に開発をやってみるとデバッグが難しいですね。いろんなサービスがつながっているので、どこで落ちたのかがわかりにくい。プログラミング的にも、今まで単純にトランザクションスクリプトで書いていたのがいろんなサービスに分割されていくので、単純にシリアルで呼び出していくとその分遅くなってしまう。

サーバサイドでも、並列に投げられるところはパラレルに取りに行ったりする並列プログラミングや、非同期的な処理を扱うクライアントサイドの知識が求められるようになってきました。慣れていないとキツイかもしれませんね。アプリケーションプログラマに求められるスキルは上がっていると思います。

岩瀬：これまで同期的なコードを書いてきたプログラマが、マイクロサービスでNode.jsなどの非同期な並列プログラミングをしようとしても、前の癖で同期的に書いてしまって、全然パフォーマンスが出ないというのもあり得るわけですね。

ちなみに先ほどデバッグの話が出ましたが、モノリシックに比べて、時間がかかって大変だったということはありますか？

竹添：作っているときはそうでもないんですが、動かしてトラブルがあったときが大変ですよね。結合させてテストしているときや、プロダクションで何か起きたときのトラッキングとか。セッションIDを全部のログに含めるようにするなど、エラーをトラッキングできる仕組みを最初から作っておけばなんとかなるんですけど、それでも難しい時は難しいですね。

岩瀬：設計の段階でわかっていればいいけど、結構大変だってことですね。コツがわかってくるといいのかもしれませんが。

では、サービスの監視についてはいかがでしょうか？
以前、マイクロサービスとして各パーツを構築してみたのですが、クラウド上でサービスを作成・破棄することが多く、監視するサービスが増えて大変でした。もちろん、自動化して監視すればいいと思うんですが、その辺は具体的にどうされてましたか？

竹添：自動で監視できるようにテンプレート化してますね。監視系の運用は、New Relic、Mackerel、SasS、ほかにも使えるものは何でも使ってます(笑)。サーバーの種類に応じて、Webサーバー用やデータベース用などを作ってます。

岩瀬：いろいろ試されているんですね！

マイクロサービスの実践例

岩瀬：ビズリーチでのマイクロサービス実践例について、聞かせてください。

竹添：『スタンバイ』というインターネット上から求人情報をクローリングしてくる求人検索エンジンがそうです。

　　▲求人検索エンジン スタンバイ

垂直方向のアーキテクチャなのですが、コンシューマを向いている部分や、出稿企業に向いている部分、管理的なものや内部のAPIと接続したりといった、マイクロサービスになっています。

バックエンドのいわゆるAPIサーバーなどは、機能別にいろいろあるんですが、フロントも二層に分かれていて、直接HTMLからWebサーバーにアクセスするのではなく、間にAPIをはさんでいます。バックエンドは基本プリミティブに作っていて、フロントのAPIがHTMLを生成して直接返しているところもあります。

岩瀬：共通する処理とかも結構あるんですか？

竹添：認証とかがそうですね。例えばスマホのものであれば、同じようなAPIを共用できます…と言いたいところですが、やはりいろいろ予期せぬことが起こりましたね(笑)。

一応、もともとの思惑としてはチームをスケールさせたいという意図がありました。バックエンドとフロントエンドをきっちり分けて、フロントエンドだけでアプリをメンテできるようにしたかったという意図があったんです。

　▲ビズリーチの新サービスをScalaで作ってみた～マイクロサービスの裏側 #jissenscala

岩瀬：バックエンドはScalaで書かれているんですよね？フロントエンドの人も頑張ってScalaを書かなくちゃならないようなことにはならなかったんでしょうか？

竹添：全員ががっちり（Scalaを）書かなくちゃならない、ということにならないよう、役割分担を決めて、なるべくフロントエンドで修正が完結するようにしています。とはいえどうしても、サーバーサイドのプログラミングが必要になることもあるので、各チーム一人サーバサイドのサポートをできる人を配置したりはしています。その人が作ったパーツを使って、フロントエンドの人がテンプレートを作ったり。

フロントエンドのほうで全部できるのが理想的なんですけどね。開発のライフサイクルが全然違うので。フロントだけデプロイとか、もっと短いスパンでやっていけるといいなと。ちょっと画面を変えるだけなのに、サーバーサイドも落とさなくてはいけないのは避けたいので、将来的はフロントエンドだけで回せるようにしたいと思っています。まだまだ試行錯誤しているところです。

岩瀬：フロントとサーバーサイドのライフサイクルの長さの違いって、重要ですね。最近のフロントエンドでも、AngularやReactとかいろいろ流行があるから、必要に応じて対応していかなくてはいけない部分もありますよね。

竹添：とはいっても、現実的には厳しいところもあります。フロントで完結できずに、サーバーサイドのエンジニアがサポートしなくてはいけない部分はどうしても出てきます。サーバサイドをサポートするエンジニアが少なくてボトルネックになってしまったり、PCとスマホで同じようなAPIを共有できると思っていたら、画面に引きずられて、結局画面のAPIが増えて再利用できなかったりすることもありました。パフォーマンスとか工数面で考えると、レイヤーが増えていくのでいい結果が出なかったり、JSONの処理にCPUを使うなどの性能面の課題もありましたね。

結局、時間的にチューニングしている余裕もないし、直接データベースをいじってしまうこともありました（苦笑）。工数的にも、想定よりかかってしまいましたね。

岩瀬：その辺の開発はホント大変ですよね…。アーキテクチャは毎回試行錯誤されているのだと思いますが、次に設計するときはもっとうまくいきそうですか？

竹添：実は、ここに来るまで何度かチャレンジはしているんです。最初はモノリシックに作って、それをバラしたり。この『スタンバイ』というサービス自体も、最初から大規模で開発することがわかっていました。工数の都合で密結合となっている部分もありますが、最終的には落ち着くんじゃないかと思っています。次からは、あらかじめ手を打って切り離せるところもあるんじゃないかと。

岩瀬：サービスのどの部分が、マイクロサービスに変えていきやすかったといったことはありますか？

竹添：今作っているサービスは、（モノリシックなサービスを）部分的に切り離してマイクロサービス化していったのではなく、一回捨ててマイクロサービスで構築し直したんですよね。既存の安定したサービスの隣や上とかに、新たなマイクロサービスを乗っけていくのであればまだやりやすいのですが、仕様もゆるい状態で全てのサービス開発が並列で進んでいくのが難しいところでした。最初はこの機能とこの機能だけとか縛りを設けて、少しづつ拡張していくとか、一個ずつサービスを作っていくことができればやりやすいと思います。

マイクロサービス導入の選定ポイントは？

竹添：こないだ海外のScalaのカンファレンスに行ってきたときに聞いたのですが、「HootSuite」というSNSのクライアントツールを作っている会社が、PHPのモノリシックなアプリケーションからScalaのマイクロサービスにリプレイスしているという話がありました。

それによると、まず最初に手をつけたのが、認証系だったそうです。なぜかというと一番難しいところだから。最も難しいところから一番最初にやれば、ほかのところもできるでしょうという考え方なんですよね。我々は経験値があまりないので、簡単なところからやろうとするけど、強いチームで「頑張ってやるんだ」という覚悟があれば、あとはできるだろうと。

岩瀬：難しいところからやるって度胸ありますね（笑）。

竹添：コードを静的解析して、どこが一番複雑かを分析してるんですね。リファクタリングと同じでダメなところからつぶしていく考え方じゃないかと。

岩瀬：マイクロサービスはパーツが多いので、モノリシックなサービスに比べて壊れやすいと思うのですが、何か設計のポイントはありますか？

竹添：ユーザー向けのサービスで、一個壊れると止まってしまうようなところは、必ず冗長化させるようにしています。ただ、全部冗長化させるとコストがかかるので、社内向けのシステムやバックエンドで動いているバッチ処理など、1日くらい止めてもいいサービスならゆるめにするとか、強弱をつけて冗長化しています。

岩瀬：クリティカルなところはかなり力を入れているんですね。

竹添：検索サービスは弊社のサービスとしてかなりメインになっていくので、スケールすることが前提です。コストをかけても実装しておくようにしていました。

岩瀬：マイクロサービスは冗長化しておくように、頑張って作らないといけない部分もありますよね。

竹添：弊社はAWSを使っているのと、冗長化についてはかなり学んでいるので、その辺はなんとかなっています。もちろん、エンタープライズのミッションクリティカルなものと比べると、やりきれていない部分もありますけどね。本当なら相乗りさせられるものはしたほうが運用も楽になるし、コストも下げられると思いますが、まだそこまでやりきれてない。

岩瀬：今回はマイクロサービスで作ったけど、次回はモノリシックで作ったほうがいいとか判断に悩むことがあると思うのですが、何か選定ポイントはありますか？

竹添：開発のときのオーバヘッドや、インフラコストで見ると、短期的にはデメリットのほうが大きいと思っています。どこかで損益分岐点はあると思うんですが。とりあえずスモール仕立てでやってみようとか、成功するかまったくわから状況なら、モノリシックで作って、後から大きくなったタイミングでマイクロサービスにしてもいいのではないでしょうか。

ただ、Webのサービスが大きくなるときはビジネスとして勝負時だし、攻めどきなので、 その事業が大きくなるタイミングでシステムを止めてコアアーキテクチャを変えるという判断は簡単にはできません。経営判断が必要になるかと。

もしリソースがあるなら、現状のモノはエンハンスを続けながら、マイクロサービスで作りなおすなど、体制を組むという選択肢もあるが難しいですね。特に企業向けのサービスをやっていると、機能的に変わってしまうとか、デグレードしてしまうのは、許されない面もあるので。最初からこれだけ大きなサービスにするというように決められたら、マイクロサービスで作るという判断もできると思います。

大きくなったタイミングで経営判断もあるが、あきらかにスケールすることが見えていればマイクロサービスにするほうがいい。ある程度大きくなってくると、プロダクトとしても、チームとしてもマイクロサービスでないとスケールできない。モノリシックだとレガシー化してしまうので、新しい技術も入れられないし、新陳代謝していかないと新しい人も入ってこない。両面的に健全ではないです。

岩瀬：例えば新しくチームメンバーが増えたとき、モノリシックなら全体像が見えるけど、マイクロサービスは全体像が見えにくくて困る…といったことはないのでしょうか？

竹添：それはもちろんありますね。ただ、ひとつひとつのサービスのインターフェイスが明確であれば、それほど問題はないはずです。サービス開発を立ち上げたばかりだと難しいところもありますが、なんとか頑張って、インターフェイスだけはちゃんとしようと思っています。まだそこまで到達していない過渡期ではありますが…。

岩瀬：インターフェイスは、ほぼJSONでやりとりしているようですね。JSONのスキーマはどのように定義しているのでしょうか？JSON Schemeを使ったりしているのでしょうか？

竹添：インターフェースは、内部ではScalaのオブジェクトで定義しています。JSONを直接さわることはほぼありませんね。ただそれだと、（Scalaを知らない）フロントエンジニアにとってはハードルが高いので、そこもカバーできるようなものがあるといいのですが。型定義の強いTypeScriptにトライしているチームもありますね。

白石：インターフェース定義がJSONを前提としていないということは、他のシリアライズ方法に切り替えることも難しくなさそうですね。先ほど、JSONのシリアライズ・デシリアライズ処理の負荷の話が少し出ましたが、例えばそれをJavaのシリアライゼーションやProtocol Bufferに置き換えたりすることで、処理負荷を軽減することもできるんでしょうか。

竹添：その辺も研究はしています。ただ扱っているデータがテキストが多いので、バイナリ形式にしてもあまり速くならないんですよね。MessagePackとかも試しましたが、あまり変わらなかったので、今は使いやすさでJSONを選んでいます。コンパクトな情報でやりとりしているところは、プロトコルを変えたりとか、今後検討の余地はありますが。

白石：マイクロサービスのAPI設計はどのように行うのですか？サービス同士が複雑な依存関係を持たないように設計するには？

竹添：マイクロサービスの設計を適切に行うのはなかなか難しいですが、あるまとまった処理を他の部分から独立させうるかどうか、複数のサービスから利用されうるかどうか、といったところがひとつの判断基準になると思います。その上で、データベース処理を必要とするかどうかによって、ライブラリとして実装するか、サービスとして実装するか判断する感じでしょうか。データベースアクセスを伴わないなら、ライブラリとして配布すればいい。データベースアクセスを伴うのであれば、マイクロサービスにすることを考えますね。

白石：データベースって、どうしているんでしょうか。マイクロサービスごとに別々のデータベースを持っているのか、それともひとつのデータベースを複数のマイクロサービスが共有しているイメージでしょうか？

竹添：いえ、マイクロサービスごとにデータベースは分けています。

白石：じゃあ、トランザクションはどうするんですか？

竹添：マイクロサービスごとに切ってますね。

白石：マイクロサービスをまたがるような処理を、ひとつのトランザクション内で行いたいという場合はありませんか？

竹添：それぞれのマイクロサービスを、適切な粒度で切っているので、基本的には大丈夫かと。もっと大きくなって出てこないとは言い切れないかもしれませんが、そうなったら外側の仕組みでなんとかするかんじですね。

白石：SOAPという選択肢はないですか？WS-Transactionとかあると思いますが。

竹添：ないですね。フロントがスマートフォンのアプリだったり、JavaScriptだったりするので、フロントエンドから使いやすいフォーマットということで。トランザクションが必要なところが切り出せているのと、参照系がほとんどなので現段階では問題として浮上していませんね。出てきたときには、大きな課題になるかもしれませんが。

白石：マイクロサービス・アーキテクチャと、アジャイル開発との相性はいかがでしょう？特に、複数の小さなチームが連携しなくてはならないとなると、それぞれのチームがアジャイルに独立して進めるのは難しいのでは…と思ったのですが。

竹添：私たちもスクラムで開発していますし、マイクロサービスとアジャイル開発の相性は良いと思っています。マイクロサービス間で、密に連携しなくてはならないという状況はそれほど多くないですし、そうした必要が生じた場合は、マイルストーンを置いて調整します。

白石：例えばサービスに一個の機能を追加するとき、チームを横断した変更が必要になったりしませんか？

竹添：チームとしてはマイクロサービスごとに（フロントエンドからデータベースまで）縦に分けているので、チーム内で完結しますね。そして、それぞれのチームの中でフロント・サーバーなどの役割分担があります。ひとつひとつのサービスの粒度も、小さいものから大きいものまであります。単機能のサービスもあれば、大きなWebアプリケーションだけど一つのマイクロサービスというものまであって、その中でスクラムを回すかんじですね。

白石・岩瀬：いろいろ試行錯誤やチャレンジをされているお話を伺い、マイクロサービス・アーキテクチャ実践のポイントが見えてきた気がします。本日は貴重なお話をありがとうございました！