後編:知ってるようで知らないマイクロサービス〜様々な意思決定のロジック~マイクロサービス化に必要な要件

CTO meet up「知ってるようで知らないマイクロサービス〜様々な意思決定のロジック~」イベントレポートの後編です。

「前編:知ってるようで知らないマイクロサービス、マイクロサービス化すべきタイミングやバックグラウンドの考察」は、こちらからご覧ください。

マイクロサービスを検討している方、基本から知りたい方は必見の内容です。

【ご登壇者】
・株式会社LIFULL CTO 長沢 翼 氏 (モデレーター)
・株式会社マクアケ 執行役員 CTO 生内 洋平 氏
・株式会社メルカリ Director 白石 久彦 氏
・LINE株式会社 開発1センター LINE開発1室 P Partチーム マネージャー 佐藤 春旗 氏

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

メリットの裏側はデメリットになる、マイクロサービスの特質を理解する

【モデレータ:株式会社LIFULL CTO 長沢 翼さん】
2008年株式会社ネクスト(現 株式会社LIFULL)入社。 フロント、サーバーサイド、ネイティブアプリなどアプリケーション開発に従事した後、バックエンド・インフラ系を担当し、API基盤の刷新、事業系システムのAWSへの移行チームを責任者として牽引。 2017年4月からCTO就任。 情報システム部門の責任者、ベトナムの開発系子会社の委任代表なども務める。

長沢:では第2部をスタートします。大きなテーマはマイクロサービスのメリット・デメリットということで、これも組織ごとにいろいろあると思いますから、まずはざっくりみなさんが思うところから教えていただければと思います。

佐藤:マイクロサービスのメリット・デメリットについて日々感じている箇条書きにまとめました。

・一般論としての、分業制のメリット・デメリットに近いものも多くある
・メリットとデメリットは表裏一体
・むやみに分割すればいいというものでもなく、メリットを享受できるように分割するべき
・弊チームの新しいメンバー向けの紹介でも ”well-shared and well-separated micro services.” が大事、と紹介している

最後の”well-shared and well-separated micro services.”というのは、どこを共通化してどこを分けるべきかを気にするべきだということです。どちらか一方に偏ればいいというものではありません。
その上でメリットとして挙げられるのは、まず自分たちの担当範囲の改善がすばやく行えるということです。さらに技術的、開発側の理論や都合でいけば、そのサービスにとって最適な選択もしやすくなりますね。同じように、エンジニアも適した技術を持ったメンバーを集中して採用できます。
細かい技術的観点で言えば、モニタリングがやりやすいですね。モノリスの場合はプロセスやマシンは1つなのですが、モニタリングのために使用するツールややり方が複雑になりがちです。一方でAPIのモニタリングは現在ツールがかなりしっかりしているので、かなり楽に行えます。

デメリットは自分の担当から遠い部分の変更に時間がかかったり、コミュニケーションが発生する手間がかかることですね。ただこれはメリットの裏側なので、一概にだからダメというものではありません。マイクロサービスはそうなるものだと認識して進めたいところです。
また、これもメリットと裏返しのデメリットですが、サービスそのものの要素が増えるため、ソフトウェアエンジニアリングの観点では複雑系になりやすいです。そうなると、なにか一つエラーが発生した際に、どこに何が起こるのか一見してわからない可能性もあります。

LINE株式会社 開発1センター LINE開発1室 P Partチーム マネージャー 佐藤 春旗 【ご登壇者:LINE株式会社 開発1センター LINE開発1室 P Partチーム マネージャー 佐藤 春旗さん】
大手インターネットサービス企業からLINEへ転職し、2013年9月より『LINE』のサーバーサイドを担当。『スタンプショップ』『LINE STORE』『LINE Pay』などの開発に携わっている。

生内:先にデメリットから言及すると、慎重に設計をしてもミスをする可能性はゼロにできません。そして工程が進んでいればいるほどリカバリーがつらい。ですから、前編で紹介したCuddled Microserviceの表のようにデータモデリングの段階から慎重にやっていくことが大事だと思います。
また、僕が作っているのはクラウドファンディングというまだまだ新しい概念のサービスで、市場における「システムはこうあるべき」という姿が180度変わることもあります。そういった危険性のある部分をがちがちに分割していくと痛い目を見るかもしれません。
メリットは、マイクロサービスを自由自在に扱えるようになってくるとスケーラビリティといった性能を置きたいところに置けることですね。インフラを巻き込んでアプリケーションアーキテクチャの一部として取り扱える。このようなエンジニアリング(アプリケーションエンジニアリングとインフラエンジニアリングがシームレスになった状態のエンジニアリング)のことを我々はサービス・エンジニアリングと呼んでいますが、こういった思考に昇華されていくメンバーがぼちぼち現れている。これは強力なメリットです。
当社はゴールデンタイムの番組などに紹介されることも多くて、そうなるといきなり2000倍3000倍といったアクセスによる負荷がかかるので、そういったケースで「サービス切出さなくちゃ」という意思決定が下されることもありますね。

株式会社マクアケ 執行役員 CTO 生内 洋平さん 【ご登壇者:株式会社マクアケ 執行役員 CTO 生内 洋平さん】
1979年生まれ、弘前大学理工学部卒業。大学在学中から通算7年のインディーズミュージシャン・デザイナー・エンジニアの3足のわらじ生活を経て独立創業。以後、国内外、大手・スタートアップ問わずプロダクトチームへの参加を経て株式会社Socketを創業、CTOとしてWEB接客ツールFlipdeskの立ち上げ〜グロースまでを指揮。2015年にKDDIグループSyn.HDに参加し、Supership株式会社CTO室での業務を経て、2017年にSupership株式会社を退社。2017年12月、株式会社マクアケ執行役員CTOに就任。


白石:やはり分業してパラレルに物事を進められるのがメリットですね。人間が覚えられる細かい仕様というのは、範囲に限界があるような気がしているんです。スピーディにタスクをさばいている人たちが見るべき範囲がきちんと区分されているのは利点があると思います。
デメリットはみなさんがおっしゃるようにメリットの裏返しですが、並行して物事を進めるために作業する人も分かれていますから、モノリスよりも人員が必要になる気がしています。そして人が増えれば統制を取る必要がありますから、このへんはデメリットになり得るかもしれません。

株式会社メルカリ Director 白石 久彦さん 【ご登壇者:株式会社メルカリ Director 白石 久彦さん】
大学卒業後、さまざまな業務システム、インターネットサービスの開発プロジェクトにエンジニアとして携わる。ソフトバンクグループ、株式会社レコチョクなどを経て2014年よりドリコムの技術担当役員に就任。ゲーム事業を中心に技術組織の強化に取り組む。2018年より株式会社メルカリに参画、技術組織のDirectorに就任。並行して株式会社Slicetoneを創業。技術顧問としてスタートアップから上場企業まで幅広く課題解決の支援を行なっている。


長沢:私からもLIFULLで実施して感じたメリット・デメリットをお伝えしたいと思います。LIFULL HOME’Sというサービス自体のメイン部分はもう7年ほど続いていて、モノリスな部分が多いサービスです。

その中で感じているマイクロサービスを実施した部分のメリットは、切り分けたサービスの開発効率が良かったことです。プロダクトに関わる数字、たとえば、コードの複雑度や開発やテストにかかっている時間、障害率などの数字をいろいろと取得して、モノリスなサービスとマイクロサービス間で比較した結果、特にテストやレビューなど「品質」にかけるコストが、切り分けたサービスのほうが良かったんですよね。当然なんですが、可視化すればより明確になるというか。ただ、モノリスなサービスはだんだんと品質にかけるコストが増えている一方で、障害率はほぼ変わってませんでした。このことから仮説を立てると、コードなどが複雑化したモノリスで障害率をおさえられているのは、テストやレビューにかなりの時間をかけているからだということになります。つまりマイクロサービス化によってこれらの時間を削減し、代わりに実装に割ける時間が増えたということなので、これは大きなメリットと捉えることができました。

一方でデメリットは、マイクロサービス化したものの、戦略上の問題でチームがなくなってしまったり、別のチームに吸収・統合されるといった動きがあり、誰がマイクロサービスを管理するのかわからなくなってしまうといった問題が起きたことです。 あとは分割を進めることを優先して、共通部分を無視してあえてマイクロサービス化した部分があるのですが、開発が進むと共通部分に関わるオーバーヘッドが段々無視できないレベルになってきてしまいました。ログの取得やインターフェースの部分です。効率的ではなくなってしまったので、現在は全体の共通基盤を作ろうとしているところです。

影響範囲を切り分けられるメリットがある一方、マイクロサービスの複雑性には対応が必要

長沢:では気になった部分をいくつか深掘りしたいと思います。白石さんがおっしゃったメリットで、分業でパラレルに開発を進められるということがありましたが、これはある意味モノリシックな状態でもできなくはないという発想もあると思います。この点はいかがでしょうか?

白石:たとえばリグレッションテストなどがオートメーション化できている場合、単体でデプロイしてもリグレッションが回って通っていれば問題ないんですよね。ただ、おっしゃったようにモノリシックで分業しようとすると、すべて同じタイミングでテストしないといけない。そこはスケールしていくときのボトルネックになると思います。何か問題が起きたときの影響範囲の切り分けという意味でも、マイクロサービスはメリットがありますね。

長沢:一つだと一部分だけ戻すということができませんからね。
あとは佐藤さんがおっしゃっていたデメリットで、エラーが起きたときに何がどこで起きているか、影響が見えにくくなる問題ですが、これに対してカオスエンジニアリング的にわざと障害を起こして影響度を見るといったテストなどは行っていますか?

佐藤:チーム内でもその点は勉強していて、やりたいと考えています。本格的なカオスエンジニアリングとは違いますが、ベータ環境においては一定の割合でエラーを返すような仕組みが入っていて、その状態でちゃんとフォールバックするかは日々確認している例もあります。LINEの場合は何かキャンペーンを開始したときに障害が起きるというのが典型的なパターンなので、最近は定期的にハイトラフィックを一台にぶつけてみて、止まったらどうなるのかを見るようにもしています。

マイクロサービスがエンジニア組織のモチベーションアップに寄与する事例の紹介

長沢:マイクロサービスにたいして誰が責任を持つのかわからない、といったように宙に浮いてしまったということはありますか?

生内:僕はあります。チームで運営していたサービスが、そのチームが解散した際にを誰も引き取ってくれなかったケースです。アドテクに近いサービスの一部を切り出すプロジェクトだったのですが、作りがレガシーであることに加えてビジネス的な貢献度もわかりづらいものでした。やりがいのない単位で分割してしまうとまずいかもしれません。失敗談ですね。

白石:やりがい問題はありますよね。たとえば主要なKPIがちゃんとマイクロサービス化しても意識できるとか、OKRを担当チームで持てるといったことは非常に重要です。個人的にはマイクロサービスの半分くらいは組織論なのではないでしょうか。

長沢:では、逆にマイクロサービスにしたことによってメンバーのモチベーションが上がったといったことはありますか?

白石:メルカリでは、システムを分けることで各エンジニアがオーナーシップを持ってほしいという点があります。その範囲に対してオーナーシップを持つ人間が出て意思決定をする人が増えるくるということは、チャンスも増えます。それを良いことだと捉えてやっていきたいなと思っています。

長沢:適切にオーナーシップを持つのは非常に大切ですね。そのサービスを任されているオーナー的な人がいて、その人の判断でサービスを良くするための機能が追加できるとなればメンバーのモチベーションも上がりますし、そのサービスを良くするためにはどうしたらいいのか考える癖がつきます。
逆に言われたものをただ作ってるだけのマイクロサービスになってしまうと進歩がありませんし、モチベーションも上がらないと思います。佐藤さんいかがですか?

佐藤:今のお話を聞いて思い出したのは、新卒のメンバーが入社したときのことですね。新しいサービスを立ち上げてもらう形で、マイクロサービスをゼロから作ってもらいました。
ビジネス規模自体が大きいと、新しくビジネスを立ち上げてサービスをゼロから作るという機会はほとんど無いと思います。それがマイクロサービスにしたことで、定期的にゼロからサービスを作った経験をメンバーに与えられるのは、教育や組織論の観点で良いやり方だなと思いました。

CTO ご登壇者の皆さんに、イベント会場に参加いただいた方が疑問に思っていることを直接答えていただきました。

会場から出たマイクロサービスに関する質問


<質問>
1. マイクロサービスにおけるアンチパターンの実体験について
2. ドメイン設計後、モジュール分割に留めずマイクロサービス化に舵を切った理由は?
3. マイクロサービス化された部分はモノリスよりも外注に出しやすい?
4. マイクロサービス化をした後でビジネス範囲が変わってしまうことはあるのか?

マイクロサービスにおけるアンチパターンの実体験について

長沢:では第2部の質問タイムに移りたいと思います。アンチパターンの実体験について。マイクロサービスにしたせいで、かえって変更がつらくなったといったことでしょうか。佐藤さんいかがですか?

佐藤:分けたこと自体は判断として間違っていなかったので、つらい経験というわけではないのですが、分けてからどうしてもビジネス的に一緒に見せたいというタイミングはありましたね。改めて分割したデータを混ぜて表示しなければいけなかったケースです。もっと前からそれがわかっていればいろいろとやり方があったのかなと思います。ただ未来に何が起きるのか見通すのも難しいので、むしろそういったことが起こり得るという覚悟が必要なのではないでしょうか。

生内:アーキテクチャの変更そのものにチームが慣れていくということも視点としてあるかもしれないですね。分割したりマージしたりということはあるものだと捉えるんです。いや、そこはばっちり設計すべきだという考えの方はいますか?

白石:未来を考えて設計をすべて完璧に作り上げいくとしたら、それが制約になってしまうことも多いんじゃないでしょうか。とりあえず現状向いている方向に進んだ方が発展的な気がします。

生内:アーキテクチャ自体、一生懸命作っても保って3~5年程度ですしね。

白石:想像できる範囲は限られていますから、どこまでスコープに入れて設計するかという世界を追求するよりも、変化を前提とした設計をした方がいいのかもしれないですよね。

ドメイン設計後、モジュール分割に留めずマイクロサービス化に舵を切った理由は?

生内:マイクロサービスはDevOpsとも言われていて、その中でもインフラのコード化という文脈とセットになっていると捉えています。つまり、アプリケーションエンジニアがインフラやデータストアのステージングなども含めて考えてくれるようになる。そういったエンジニアが増えること自体がマイクロサービス化のものすごく大きなメリットですね。言語の共通化ができるので、問題意識や焦点の当て方も全く変わってきます。
そういう意味で、理論上はモジュール分割でも良い部分が確かにありましたが、組織づくりという点でエンジニアがベーシックに取り扱えるものの幅が広がるという利点を取った形です。

佐藤:あくまで一般論ではありますが、ロールバックが容易になるといったことも含めて、マイクロサービス化する方がモジュール分割よりも自由度が高まりますよね。何か問題が起きたときに対策手段が増えるというのは気が楽ですし。

白石:組織論で言えば、フィードバックを受けてそれに対して責任を持つというのはオーナーシップの根源だと思いますが、それがマイクロサービスによって強化されて、さらにサービスを良くできるというのは素晴らしいと思います。

マイクロサービス化された部分はモノリスよりも外注に出しやすい?

佐藤:たとえばきちんとAPIを定義してあげるとか、再利用可能なインターフェースを考えるといったマイクロサービス化するために使えるテクニックそのものが、外注に出す部分を決める際に役立つ気がしています。
外注だとやはり働く場所や時間が違いますから、リポジトリも完全に共通化するわけにはいきません。そこでマイクロサービス化で培ったやり方がそのまま使えますし、使うべきだというところですね。

長沢:サービスがモノリスのときは、割と外注に出しにくいんですよね。リポジトリも1つですし、既存のリソースに接続しなければならないデータベースや検索エンジンがある中で、そこにネットワークに穴を空けて外部とつなげられるようにして良いかというと、会社のセキュリティ的に難しいことがあります。
ですからマイクロサービスでネットワークも分離できた方が外注には非常に出しやすい、むしろそういうサービスしか外注には出せません。リモートや開発子会社に出す場合も同じで、切り分けられた環境が好ましいです。

マイクロサービス化をした後でビジネス範囲が変わってしまうことはあるのか?

長沢:では最後の質問です。ビジネス範囲が変わってしまわないようにしたいからこそ、ある程度ビジネスが軌道に乗ってからマイクロサービス化すべきかどうかという点も含めて、いかがでしょうか。一定規模にまで成長した組織にも当てはまる部分だと思いますが。

生内:今の段階で当社がマイクロサービスに舵を切っているのは、僕がCTOという立場で経営陣に入っているからです。そういう人がいるなら、ビジネスがまだ軌道に乗っていない段階でもマイクロサービス化に踏み切れるかもしれません。
というのも、マイクロサービス化は経営練度を気にしながら進めなければならないという実感があるんです。このビジネスがどこに行くのか、行きたい方向に進むためにはどうするのかという問題ですね。マイクロサービスの中心に立つ人物が経営陣の中にいないとやりきれないと思います。

白石:社外CTOとしてコミットしている会社に、とにかく多くのサービスを作るビジネスモデルの会社があります。この場合、サービスを横断した共通パーツとして抽象化できるものと、サービス単位で作っていくものがあまり交わらないんです。たとえばSaaSのサービスを作っても当たらなければすぐにサービスを閉じるという環境では、オーナーシップを継続的に持たせるのは難しいですし、マイクロサービス化は厳しいと思います。メルカリは全く逆で、一つのサービスを継続していくことが前提なのでやりやすい。その部分の差があるのは感じています。

CTO イベントの最後に、flexyのfのポーズをしていただきました!

編集部記

ご登壇者の皆さま、ありがとうございました!

【6月のCTO meet upについて】
flexy主催、6月のCTO meet upは「Edtech」です。
教育とテクノロジーという観点でディスカッションを行いました。Edtechイベントレポートは、7月に本メディアに掲載予定です。


この記事を書いた人
flexy編集部
flexy編集部
ハイスキルIT人材への案件紹介サービス
サーキュレーションが運営するフリーランスのエンジニアを中心としたIT人材の案件紹介サービスflexy。エンジニアに役立つコンテンツも提供しています。【flexyのサービス詳細】★求人を募集している法人様向けお仕事をしたいご登録希望の個人様向け

週1日~/リモートの案件に興味はありませんか?

週1日~/リモートの関わり方で、「開発案件」や「企業のIT化や設計のアドバザリーなどの技術顧問案件」を受けてみませんか?副業をしたい、独立して個人で仕事を受けたエンジニア・デザイナー・PM・技術顧問の皆様のお仕事探し支援サービスがあります。

flexyでご案内できる業務委託案件

業務委託契約・開発案件(JavaScriptメイン)

テーマ flexy登録画面から案件詳細の確認と直接応募が可能です
勤務日数 2-3日/週
報酬 4万円/日
必要スキル JavaScript・React
勤務地 東京都内/リモート含む
リモート

外部CTO、技術顧問

テーマ 技術アドバイザリーとして知見と経験を生かす
勤務日数 1日/週
報酬 10万円/日
必要スキル エンジニア組織立ち上げや統括のご経験、コードレビュー経験、技術的なアドバイスが出来る方
勤務地 東京
リモート 相談可

業務委託契約・インフラエンジニア

テーマ flexy登録画面から案件詳細の確認と直接応募が可能です
勤務日数 2-3日/週
報酬 5万円/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート 相談可

業務委託・フロントエンドエンジニア

テーマ flexy登録画面から案件詳細の確認と直接応募が可能です
勤務日数 週1日〜
報酬 5万/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート リモートと常駐のMIXなど

人材紹介のCTO案件(非公開求人)

テーマ CTO、技術顧問案件はflexyに登録後、案件をコンサルタントからご紹介します
勤務日数 業務委託から人材紹介への移行
報酬 年収800万以上
必要スキル CTOとして活躍可能な方、エンジニア組織のマネージメント経験
勤務地 東京
リモート 最初は業務委託契約で週3日などご要望に合わせます

業務委託契約・サーバサイドエンジニア

テーマ flexy登録画面から案件詳細の確認と直接応募が可能です
勤務日数 週2-3日
報酬 案件により異なります
必要スキル 案件により異なります
勤務地 東京都内
リモート 相談可能
個人登録

お仕事をお探しの方(無料登録)
法人の方(IT課題の相談)