前編：知ってるようで知らないマイクロサービス、マイクロサービス化すべきタイミングやバックグラウンドの考察
2019年5月10日にCTO meet up「知ってるようで知らないマイクロサービス〜様々な意思決定のロジック～」が開催されました。
今回のテーマは、トレンドトピックスであるマイクロサービスです。スタートアップから大手企業まで、規模感の異なる各社がどのようなプロセスでマイクロサービス化を推進しているのか。タイミングや手法、成功させるコツなどを各社CTO、ディレクター、マネージャーにじっくり語っていただきました。
また、今回のCTO meetupでは、イベント参加者との相互のやりとりの時間を増やし、質疑応答の時間をいつもより多めに確保。 マイクロサービスに関する気になるエンジニアやCTOからの質問にもたっぷり答えていただいています。
マイクロサービスを検討している方、基本から知りたい方は必見のイベントレポートです。
登壇者のご紹介
エンジニア数十名から数千人規模まで、マイクロサービス化を進行中の4社
長沢：株式会社LIFULLでCTOを務めています、長沢と申します。よろしくお願いします。CTOになったのは2017年頃なので、キャリアは2年ほど。フロントからバックエンドまで幅広く手がけています。 会社規模は1000人ほどで、エンジニアはプロパーが約150名ほどです。ベトナムに開発子会社があり、そちらにも約50名のエンジニアがおります。LIFULLは「あらゆるLIFEを、FULLに。」というコーポレートメッセージを掲げ、不動産・住宅情報の総合サイトLIFULL HOME’Sを運営しているほか、子会社でもさまざまなサービスを展開しています。 マイクロサービスという考えを導入し始めたのは2014年頃。そのころ事業系サービスをオンプレミスの環境からAWSに移行するというプロジェクトを進めていてそれと同時期です。
【モデレータ：株式会社LIFULL CTO 長沢 翼さん】
2008年株式会社ネクスト（現 株式会社LIFULL）入社。 フロント、サーバーサイド、ネイティブアプリなどアプリケーション開発に従事した後、バックエンド・インフラ系を担当し、API基盤の刷新、事業系システムのAWSへの移行チームを責任者として牽引。 2017年4月からCTO就任。 情報システム部門の責任者、ベトナムの開発系子会社の委任代表なども務める。
生内：クラウドファンディングサイトの運営を行なっている株式会社マクアケのCTO、生内です。CTOになったのは去年の頭頃で、就任から1年半ほどになります。僕が参入した時点ではエンジニア8名程度の小さな組織だったのですが、事業拡大のために去年から一気にメンバーも増員し、現在は28名のエンジニアが在籍しています。 一般的には開発規模が拡大した際に取る手法のひとつだと思いますが、今回も同様です。まだまだ発展途上ですが、マイクロサービス化を進めています。
佐藤：LINE株式会社の佐藤です。サーバーサイドの開発チームでマネージャーを担当しています。CTOではないのですが、社内ではマイクロサービスの共通基盤の開発にチームとしてコミットしていることと、イベントなどにおいて情報発信を担当しているということで、今回お声がけいただきました。 主な担当はLINEスタンプやLINE着せかえなど、LINEのコンテンツの一部で、社内では通称LINE Shopチームと呼んでいます。最近はLINEウォレットやLINE Payが絡んでいる部分も担当しています。 LINEはコンテンツごとに個別のグループ会社がある場合もあり、全体像が複雑なのですが、エンジニアはトータルで2000人以上在籍しています。現在は3000人規模を目指すため採用活動中です。今日はどうぞよろしくお願いします。
白石：株式会社メルカリのディレクターをやっております白石です。メルカリ全体は現在1800人ほどの規模の会社です。 私自身は以前ソフトバンクやレコチョクに務めており、ドリコムではCTOの役回りも担っていました。現職と並行して自社の運営や複数社の技術顧問も行なっています。マイクロサービス化はメルカリでも進めていますが、他社で検討することも多いです。メルカリにおいてはマイクロサービスの技術的な部分にはほとんどタッチしておらず、テストと育成や採用などの組織マネジメントの役割を担っています。マイクロサービス化を進めるといろいろな周辺課題が出てくるので、今日はそういった切り口でお話しさせていただければと思います。
マイクロサービスの捉え方と導入経緯
機能ベースによって分割されるのがマイクロサービスの主なケース
長沢：一口にマイクロサービスと言っても、会社ごとに捉え方が違うはずです。そこでまずみなさんの会社がマイクロサービスについてどのような捉え方をしているのか、実際にどのような単位で分割しているのかお伺いしたいと思います。
白石：メルカリはノーティフィケーション、認証など、機能単位で分割しています。
佐藤：LINEはLINE○○というさまざまなサービスがありますので、まずはその単位で大きく分かれています。そこからメルカリさんのように、特殊な役割を持っている、あるいは技術を利用できるような機能があれば、そこにマイクロサービスを当てはめるといった形にしています。ビジネスで欲している機能と、実装に必要な技術として中心に据えたいものがあると、それがマイクロサービスになるという感じですね。
生内：マクアケではサービスの分割とマイクロサービス化は概念として分かれています。サービスは業務内容やサービスへの思いが強い人、サービスを使う人の思考を考慮して分割するわけですが、マイクロサービスはエンジニアリング都合で設計しています。リソースの消費傾向やセキュリティレベルなどのシステムのある部分に求められる性能傾向の偏りは分割を判断するのによくトリガーになります。
【ご登壇者：株式会社マクアケ 執行役員 CTO 生内 洋平さん】
1979年生まれ、弘前大学理工学部卒業。大学在学中から通算7年のインディーズミュージシャン・デザイナー・エンジニアの３足のわらじ生活を経て独立創業。以後、国内外、大手・スタートアップ問わずプロダクトチームへの参加を経て株式会社Socketを創業、CTOとしてWEB接客ツールFlipdeskの立ち上げ〜グロースまでを指揮。2015年にKDDIグループSyn.HDに参加し、Supership株式会社CTO室での業務を経て、2017年にSupership株式会社を退社。2017年12月、株式会社マクアケ執行役員CTOに就任。
組織の拡大、ビジネスの成長に伴って求められるマイクロサービス化
長沢：ではマイクロサービスを導入しようとした際の課題や実際の導入経緯について、佐藤さんいかがでしょうか？
佐藤：私が所属している部署で言うと、ジョインした2013年当時はモノリシックなサーバーの見通しが悪く、機能を追加するにもどこを触ればいいのか全くわからないような状態でした。その頃からマイクロサービス化が必要だと社内で話し合っていた印象です。2013～2014年頃はLINEのサービスのラインアップが増えてきた時期なので、その影響もあります。ビジネス上の要件について、複数人からそれぞれ別の要望を受けるような現状があり、サービス側としても自分たちのKPIややりたいことに向かって進むにはマイクロサービス化が必要だと感じていたのです。 また、拠点も東京、福岡、京都、韓国、台湾など急速に増えたことで、異なる場所のメンバーがある程度独自の判断で動ける体制が必要になったことも理由でした。
生内：当社は先程述べたようにまず事業と組織の拡大時期にきていたのがトリガーでした。システムと組織の業務体制が絡まりあったモノリスが形成されており、一枚岩として強い部分もあったのですが、効率化・仕組み化の妨げになっていたり、開発を必要以上に複雑化している状況があったんです。 そこで僕たちの場合は、マクアケはサービスとしてどんな機能を有していているのかを洗い出し、ドメイン設計からやり直しました。そこに応じてシステムを変えていこうと考えたんです。組織の拡大をチャンスと捉え、組織の変更に寄り添う形でシステムを変更していこうという組織的判断をしたわけです。 比較的丁寧にマイクロサービス化を進めているのではないでしょうか。
長沢：ちなみに、エンジニア人数はどれくらいの規模のタイミングだったんですか？
生内：この思想自体を打ち出したのは12名くらいの頃ですね。だいぶ早い段階だったとは思いますが、思想を形にすることで日常的に将来を考えたデータ構造を意識して開発を進めることになるので、大事なことだったと思います。 そこは、僕たちが考えているマイクロサービス化に向けてのステップが関係しています。まずはビジネスストラクチャーの構造をよく観察し、それに対してデータをモデリングしていくというプロセスを何度もトライアルする。そこからようやくデータストアを分割します。トライアル期間をできるだけたっぷり確保して、未来の形を組織の中に先行して落とし込んでおくのです。
長沢：どのタイミングからマイクロサービス化するべきなのかという視点で言えば、メルカリさんもかなり早いタイミングからマイクロサービス化を推進してきたイメージがありますが、何を見据えていたのでしょうか？
白石：メルカリがマイクロサービス化に踏み切ったのも、ビジネスが急激に加速していき、エンジニアの人数も一気に増えたタイミングです。もともとプロジェクトをはバイヤーやセラーなどKPI単位で分けて運用していたのですが、バックエンドシステムはモノリスでした。そんな状態でエンジニアの人数が増えると、開発速度が遅くなってしまいます。そのうち手としてバックエンドのチームをドメインで分けつつ、ある程度担当を分けてそれぞれで進められるようにしていくという判断がありました。 急成長するというタイミングで判断しないと、ビジネスが拡大してからではどんどん難しくなっていきなっていきますのでその前に踏み切るという判断でした。
【ご登壇者：株式会社メルカリ Director 白石 久彦さん】
大学卒業後、さまざまな業務システム、インターネットサービスの開発プロジェクトにエンジニアとして携わる。ソフトバンクグループ、株式会社レコチョクなどを経て2014年よりドリコムの技術担当役員に就任。ゲーム事業を中心に技術組織の強化に取り組む。2018年より株式会社メルカリに参画、技術組織のDirectorに就任。並行して株式会社Slicetoneを創業。技術顧問としてスタートアップから上場企業まで幅広く課題解決の支援を行なっている。
マイクロサービス化をスムーズにするには？
必然性があって初めてマイクロサービスは成立する
長沢：経営判断という面で言えば、マイクロサービス化のためにモノリスを切り分けたとしても、切り分けている最中はもちろん、切り分けた後も結局何の利益も生み出さない可能性もゼロではありません。マイクロサービスにすることで果たして新しい価値が生まれるのかどうか、議論はあったのでしょうか。
生内：その点については意識していました。「事業的に新しくしたい部分」は率先して切り分けの対象にしようという前提があり、チャンスだからマイクロサービス化しようといった形で、順番立てて話を進めていきました。もちろん技術的に無理をしすぎず、負債もたまりすぎない範囲ですが。
長沢：なにかビジネス的な機会があるたびにそこを切り出すんですね。佐藤さんはいかがでしょうか。
佐藤：当社でもビジネス側と議論してお互い納得の上で進めましたし、その方がいいと思います。単に「バグを直したいからしばらく開発を止める」と言っても通用しませんが、「こういう技術があるからこう改善できる」といったバックグラウンドをきちんとコミュニケーションして説明できれば、成功しやすいはずです。
長沢：そういう意味だとマイクロサービス化するタイミングも難しいと思うのですが、たとえばみなさんが自分で今から新しいサービスを立ち上げるとしたら、最初からマイクロサービスにするのか、それともモノリスファーストで進めるのか、どうされますか？
白石：何社か技術顧問をやらせていただいている観点からすると、まだマイクロサービス化するタイミングではない会社は結構あります。今は「マイクロサービス」というキーワード自体が注目されているのでエンジニアとしても気になりますし、導入した方がいいのか検討すると思うのですが、実際に導入するのは事業が軌道に乗っていく少し手前、あるいはシステムをスケールアウトする手前の状態がいいのではと思います。
佐藤：会社やビジネスが健全な状態で成長すればユーザー規模も一緒に大きくなっていくと思いますが、そういう状況の場合、実際にエンジニアが「モノリスでは開発しにくい」と思った段階でスタートするのがいい気がしますね。
【ご登壇者：LINE株式会社 開発1センター LINE開発1室 P Partチーム マネージャー 佐藤 春旗さん】
大手インターネットサービス企業からLINEへ転職し、2013年９月より『LINE』のサーバーサイドを担当。『スタンプショップ』『LINE STORE』『LINE Pay』などの開発に携わっている。
既存のモノリスを切り分けるために必要な判断やプロセス
長沢：マイクロサービス化するタイミングについてはみなさん共通して、大きなモノリスに対してこのまま使い続けるのが難しそう、組織が拡大しそう、ビジネスが軌道に乗ってきているといったタイミングで、将来を見据えて分割していったという感じですね。 ただ、分割できそうなところから徐々にやっていくと、いつかは既存の大きくて古いモノリスにも手を入れなければいけないと思うのですが、それは積極的に動かれているんですか？
佐藤：LINEにおいて、もともとのモノリスを解体する作業は進行中です。担当者が何をしているかと言えば、まずは具体的にモノリスの問題を見つけて、どうしたら分解できるのかある程度見通しを立てています。そこからその部分を渡すチームを新たに作り、マイクロサービス化に着手します。完成したら切り替えるというやり方ですね。終わりはまだ見えませんが、地道に続けています。
長沢：なるほど。切り分けるための設計をしてマイクロサービスを作りはじめると、既存のシステムに機能が追加されて終わらない…という事態もあると思うのですが、その点はどう対処していますか？
佐藤：ケースバイケースで古い方に追加しなければならない場合はマイクロサービス側も準備したり、移行できるようなやり方を検討する必要がありますね。実際、古いサーバーにとりあえずAPIを追加して、後日改善の一環としてマイクロサービス側にAPIをまるごと移行したこともあります。
長沢：そういった微妙な判断が必要な部分はコミュニケーションで解消するということですね。
佐藤：それがベストだと思います。
会場へご来場いただきました方からの質問に、直接答えていただきました。
質疑応答
既存のサービスからマイクロサービス化を進めるコツは？
長沢：先程モノリスの分割の仕方についてはお話しいただいたかと思いますが、それ以外にありますか？
生内：MVCを取り巻く流れで言うと、いかに優れたデータモデリングができるかが一つコツになると思います。 あとはビジネスの奥行きを見ること。「これは本当に分割する意味があるのかどうか」という判断ですね。分割した後もそのサービスが目的に併せて成長していく見込みが充分あるのなら、分割すべきだと思います。
白石：生内さんがおっしゃるように、伸びない部分を切り分けて広げても意味はありません。スタートアップの人たちが分割したいと言う場合でも、必要なのは本当にマイクロサービスなのか、それともシステム単位の分割なのかという判断がありますよね。マイクロサービスかというと、実はそうではないなというものも多かったりしますよね。
佐藤：個人的には、既存の良いとされるデザインパターンはどのレイヤーにも使えると思っています。MVCでもそうでなくても、なんらかのモデルをしている時は良いモデル化をすること。あとはドメインドリブン的な考え方で、どのドメインがどこに属するのか、自分たちで分けられるようになっておくとマイクロサービス化はやりやすい気がします。
サービスを分割する際は同時に組織も分割していくのか？
長沢：マクアケさんでは28名のエンジニアがいて、たとえばログインサービスは3名といったようにマイクロサービスごとに担当を決めているのでしょうか？
生内：基本的にはそうですが、サービス間でメンバー移動はありますね。リーダーの移動やサービスの兼任はできるだけしない方がいいというスタンスですが、少人数なのでやむを得ない場合は行います。
長沢：ありがとうございます。メルカリさんはどんな感じでしょうか。
白石：先々は組織も分割することを考えて動いています。そしてその組織単位で自由に技術選定などもできるようになるのが理想ではあるのですが、現状はまだ遠いですね。今で言うと組織ではなくチームでは分かれているのですが、各チームが独自性を発揮するのはこれからという感じでしょうか。
佐藤：当社も基本的にマイクロサービスと組織は紐付けされているのですが、LINE Shopチームはあえて物理的に東京と福岡に分散しています。分散しない方がいいと言われることもあるのですが、これは実証実験の意味合いもあるんです。各マイクロサービスの共通部分があるわけですが、それを東京と福岡両方で使えるものにすれば、仮に３つ目のチームができてもそれを利用できるのではと考えています。共通部分というのは、例えばデプロイのシステムやキャッシュの仕組みなどですね。しっかりデザインすれば、どのサービスでもある程度同じようなインターフェースを利用できるはずですから。
マイクロサービス、サービス間のやりとりはHTTP？
生内：HTTPだけにはあまりこだわっていませんね。一般的なところでは、RPC系のプロトコルも標準の範疇です。ある程度標準として採用するプロトコルとして定めてはいるものの、サービス移管の過渡期であるという認識を前提に、一時的に直にSQLを叩くケースもゼロではありません。
佐藤：LINEの場合はApache ThriftやProtocol Buffersを使っています。 ただ、マイクロサービスの利点の一つはAPIとして抽象化されていて、そのサービスが何をするものなのかわかりやすく言語化できる点です。APIを定義できて、それをメンバーが共有できる仕組みさえあれば、HTTPなのかgRPCなのかというレベルのプロトコルは本質的には何でもいいんじゃないでしょうか。
長沢：白石さんはいかがですか？
白石：状況や目的によりますね。別にHTTPでやっても全然いいと思っています。
長沢：ちなみにインターフェースを選んだ基準はあったりしますか？
佐藤：Apache Thriftに関しては、2011年当時の選定だったのですが、クライアント側、サーバー側、マイクロサービス側すべてにおいて同じものを使えないかという視点で検討したようです。ちょっと珍しいタイプの判断だったかもしれませんね。
生内：前述の補足ですが、僕たちの規模感ならではかもしれませんが、gRPCを使う箇所が多すぎるとエンジニアの採用ハードルが上がってしまうので、メインはhttpを採用しています。
分割した後の共通部分の管理はどうしている？
長沢：共通部分というのは、たとえばログの取得やAPIのインターフェースの部分かもしれませんが、いかがでしょうか？
白石：メルカリの場合は「マイクロサービスプラットフォーム」というチームがあり、共通している仕様を管理しています。
佐藤：いくつか切り口となる考え方があると思いますが、LINEの場合はインフラ寄りの部分はインフラチームが管理しています。 似通ったサービスの共用部分という意味合いであれば、リポジトリを共有していますね。うちのチームは比較的複数のマイクロサービスから成り立っていますが、シングルリポジトリです。共通化しているものに関しては１つのリポジトリの中にあるコードをいじればまとめて変更できるという仕組みを採用しています。
長沢：分割しているサービスの言語もすべて共通しているんですか？
佐藤：うちのチームに関しては基本的にJavaとKotlinですね。マイクロサービス単位であえて複数の言語を使うケースはあまり見たことがありませんし、アクロバティックな感じがします。
長沢：なるほど。生内さんはいかがですか？
生内：当社はさほど規模も大きくありませんし、プロダクト的に共通処理が起きにくいですね。ただうちはSREを置いていて、リファレンスサービスという概念も設けています。デプロイフローなどは邪魔にならない程度に共通化させていますね。
後編に続きます>> 後編は、更に深くマイクロサービス化に必要な要件についてディスカッションをしました。
