00:00
というわくで、LayerX NOW! 今日もやっていきたいなと思います。
ちょっと僕が育休に入ってしまっていて、しばらくお休みしていたんですけども、
その間もマーサさんの方でいくつか公開されていたかなと思います。
LayerX NOW! まずいつもこの番組についての説明なんですが、
このポッドキャストは、LayerXの開発メンバーやその組織がどういうふうに運営されていたりするのかというところをですね、
セキュララに知ってもらうというところがテーマで始まったポッドキャストです。
我々の会社のことをですね、より深く知っていただきたいと思いましてやるんですが、
実は今日はですね、会社のことというよりは個人的にちょっとテックネタをしゃべりたいなと思い立ちまして、
弊社のEnabling Teamというチームが立ち上がりまして、
そちらのメンバーからですね、3人ほどお越しいただいてお話をしようと思っております。
というわけで皆さんよろしくお願いします。
よろしくお願いします。
お願いします。
1人ずつ自己紹介をお願いしようかなと思っておりまして、
まずはSuguruさんからお願いしてもいいですか?
はい。LayerXでEnabling TeamにいるSuguruと申します。よろしくお願いします。
引いているSuguruさんですね。よろしくお願いします。
よろしくお願いします。
次、Yoshikiさんお願いします。
はい。私もEnabling Teamの中川ヨシキと申します。
で、Podcast出るのLayerX Nowは2回目だと、多分2年、1、2年だいぶ前な昔な気がします。
今はEnabling Teamに入ってますという感じです。
今日よろしくお願いします。
お願いします。
じゃあ最後イズミンさんお願いします。
はい。どう?イズミンです。
インターネットではイズミン5210ってアカウントをだいたい使ってます。
LayerX Nowは今日が初めてです。よろしくお願いします。
よろしくお願いします。まだイズミンさん入って間もないという感じですね。
急に引っ張り出してしまいました。
今日はですね、Enabling Teamっていう多分他社にこの名前のチームがほぼないと思うんですけども、
このチームについてお話をしたいなと思っていて、
これ企画始めた時にですね、ちょうどいいネタが降ってきたんですよね。
今簡単にご説明しておくとEnabling TeamってLayerX Nowのアーキテクチャにおいて非常に広域な意思決定をやろうとしている中心のチームになっていて、
それにも関わるのでそのネタを持ってきました。
何かというとですね、GitHubのCTOのJaysonさん、
Jaysonさんがですね、モノリス、アプリケーションサービス、マイクロサービスって4つを並べながら、
みんな目を覚ませ、モノリスでやっておいた方が安全だぞみたいな話をTwitter上に長いスレッドで投げていただきましたと。
03:04
このスレッドを皆さん読んでますかね?
めっちゃ読みましたね。
今日読んできました、このタイミング。
社内でも結構話題になってたと思うんですけど、
人数少ないうちはモノリスにしておくのが安倍だというふうなことをいろいろな検知から述べられていて、
GitHubってものすごく大きなマイクロサービスの塊だと思うんですけど、
そこを率いる方がそんなことを言っていて、いろいろ界隈でも話題になっていたなと思ってるんですけども、
ちょっと曖昧な質問になっちゃうんですけど、
最初にSuguruさんからこのツイートを見た時の感想とか思ったこととか、
ここ違うぞみたいなポイントとかあったら聞いてみてもいいですか?
そうですね、難しいとこですけど、
でも大体そうだよねっていうか、そりゃそうだよねっていう話が書いてあるので、
たぶん納得する人も多いかなっていうところと、
マイクロサービス、揺り戻しがあるアーキテクチャーの流れだなと思っていて、
1回モノリスでいろいろ発展して、次マイクロサービスで発展して、
今度またモノリスに近いような別のモノリスに戻っていって、
また今度またマイクロサービスに戻っていってっていうのは、
たぶん行き来しながらアーキテクチャーが進化していくんだろうなっていうところがあるんで、
今たぶん世の中的にマイクロサービスに振ってるというか、
そっちにみんな寄っていって、こっちに行かなきゃみたいになってるのが、
少しずつとはいえマイクロサービスが良くないとかもいっぱいあるよねっていうのがみんな分かってきて、
今度1回分けるマイクロサービスっていう分割するところから、
もうちょっと違う形があるんじゃないかっていうのに、
揺り戻すタイミングが来てんだろうなっていうので、
そういうのもあるんだろうなっていうのを感じながら見ていて、
書いてることは、それはそうだよね、それはモノリスの方が早いよねとか、
どっちが早いかって言われたらモノリスだよねとか、
どっちが簡単かって言われたらモノリスだよねとか、
いろいろ言ってることはそうだよねっていうことを書いてるなっていうふうに見てて感じましたね。
なんでこれが今ツッコミが入ったのかみたいなちょっと気になってますね。
そしてちょっと吉木さんからチャットで補足があったんですが、元GitHub CTOですね。
現在はまた別なところのマネージングディレクターのようですが。
今日見てたRedPointっていうVCっぽいところなんですかね。
多分投資する観点でエンジニアの視点で投資してるのかなという推測ですかね。
06:01
VCに入った方いるってすごいですね。
すごいですよね、それはそれで。
こんだけ知見ある人がいるっていうのは確かにすごいですね。
多分GitHubだけで考えたことっていうか、経験したことではないんだろうな、
全部が全部GitHubで起きたことではないんだろうなっていうのは、
盛り上がりとは別の観点でちょっと感じたところだったりしました。
吉木さんはまさにレイヤーXのアーキテクチャーの生き地引きみたいな方じゃないですか。
ワンプロダクトから複数プロダクトになりつつ、
途中すごく塩梅のいいところは切り出したりとかを、
もさと二人三脚してきたと思っていて、
その吉木さんの観点からこのツイートみたいなのがどう思いました?
行くとまさに爆落はこの、何でしょうね、
モノリスアプリサービスマイクロサービスみたいな最初のスペクトラムみたいな話をしてくれてるんですけど、
その順を一応辿ってるのかなという気はしていて、
最初一つのプロダクトというか製品だったものが、
複数のプロダクト探検を作るようになったら、
それって多分アプリだと思うんですけど、
爆落っていうグローバルな1個のサービス群の中の1個のサービスっていうのが、
アップとかの切り出し方なのかなという気がしてて、
サービスの定義が具体があんまり思いつかなかったりはしたんですけど、
インフラがリードしていくものだっていうところでいくと、
サブシステムとかそういうものなのかなと思ったりはしていて、
自分の中では。
さらにもそのサービスをもっともっと小さい単位で、
本当に数百余のコードでマイクロサービスがあるって考えると、
今まさにこういうところに向かっていってるのかなっていう感じはしていて、
ただその向かい方っていうのが、
この一連のスレッドからは分からなかったりするんで、
みんなで考えながらやってる最中かなというのは気がしていますね。
何だか分ける瞬間っていうのは結構難しくないですか?
マイクロサービスに踏み出そうみたいなきっかけはどの辺にあるのかなが、
まさに今、エネーブリングチームと各アプリケーションのチームで、
けんけんガクガク議論してるところな気がしていて。
最初の動機はやっぱり重複したものを減らせる、
リプリケートしてるものを切り出せるといいよねっていうのはそうなんですけど、
確かにそんなに単純じゃないっていうのはやってみて思うところだったりもありますかね。
結局アプリケーションライフサイクルとかいろいろ考えたときに、
どこが一つの切れ目なんだろうとか難しいですよね。
そうですね。切り出す範囲も難しいですし。
最近出たソフトアクテクチャーハードパーツでしたっけ、
これイズミンさんが紹介してましたっけ、社内で。
そうですね。もう発表されてからずっと楽しみにしてたんで。
あの本なんか結構アプリケーション流度の定義みたいな、
09:01
割とカッチリした議論からスタートしてましたよね。
そうですね。結構このアーキテクチャーハードパーツの作者の方々が、
割とそういう話をずっとしてて、
何年か前の進化的アーキテクチャっていう本から始まって、
ソフトウェアアーキテクチャの起草、で今回のハードパーツみたいな感じで、
なんかその集大成じゃないけど、そこからの流れで結構細かく話してくれてますね。
この流度は結局アプリケーションの性質とかドメインにも結構寄る気がしていて、
難しさは感じるんですけど、なんかイズミンさん、
今初見で爆落というプロダクトを眺めてて、
このアーキテクチャー議論を見てみて、
難しさは感じてるポイント結構あるんじゃないかと思うんですけど、
今爆落でイズミンさん的にここムジイなと思ってるポイントとか何かあります?
そうですね。
まず根本的にドメインがめちゃめちゃ複雑というか難しいというか、
専門性が高いなっていうのが前提としてあって、
やっぱりこれはどこかでMOSAさんが言ってたんですけど、
業務サースは業務フローを再構築するみたいなことをどこかでするものだみたいなことをおっしゃってて、
そこを再構築、再定義する中で、
今までに自分たちが思った常識とは違うところで、
こことここを組み合わせるとすごくいい体験になるみたいなのが発生するんだろうなと思っていて、
そのプロダクト上の選択肢を狭めないようにしつつ、
適切にいろんなものを境界線を引いていくっていうのはすごい難しいというか、
ハードだなっていうのは感じましたね。
特にトランザクションの境界線難しいですよね。
いや、そうなんですよね。
分散しちゃった時点でトランザクション貼れなくなるけど、
そこ貼れなくなって本当に大丈夫だっけみたいなのを緊張感を持って、
やっとかないといけないですよね。
かつユーザー体験から見たスピード感とかありますしね。
複数サービスにまたがったトランザクションで果たして気持ちのいいユーザーインターフェイスが作れるのかみたいな話とか。
そうですよね。ちょっとUIの変更が遅れることがあるんですよねとか、
許されない場面と許される場面が両方あると思うし、難しいなって思いますね。
そんな中でこのチームで今新しいものを作っているわけじゃないですか。
Layer1というとあるリポジトリがSuguruさん入社後に爆誕しているんですけども、
今、イネーブリングチームで目指していることとか、
その中で取り組んでいるLayer1というプロジェクトについて、
ちょうどこのGitHubの議論の延長にもある話題だなと思っているので、
12:04
まずSuguruさんから今イネーブリングチームで何を考えていて、
どういうチームで何を考えているんですか?みたいなところから聞いてもいいですか。
そうですね。イネーブリングチーム入社後に作ったのは、
前職でも同じ似たような名前、似たというか同じ名前のチームでやってて、
その役割がすごくいいなと思って、今回RayXでも作ったんですけど、
名前の通りなんですけど、ソフトエンジニアに関わらず、
いろんな社内で働く人たちをイネーブリングするというか、
よく言ってるのは選択肢を増やすというか、できることを増やすというのと、
選択肢を増やすというのを目標に動いていて、
なので例えば、分かりやすいので言うと、
マシンラーニングのプラットフォームがあったときに、
マシンラーニングを簡単に使えると、
例えばマシンラーニングを詳しくないエンジニアとかも、
その機能を簡単に使えたとすると、
そういった機能の開発が、いろんなプロダクトの開発の局面において選択肢に入ってくるので、
それが結果としてそのプロダクトの強さにつながってきたりとか、
あと機能的なエンジニアが作る機能の品質とかクオリティに関わってくるので、
そういったところをイネーブリングしていくっていうのが目的で、
いわゆるDXと呼ばれている部分ですとか、
あとは無駄な時間とかプロダクティビティをどんどん上げていって、
もっとクリエイティブな時間を増やそうとか、
そういうところとかがイネーブリングチームの主な目的なので、
主に最終的にはお客様に向けてサービスを提供するんですけど、
直接的には社内の人たちっていうのが主なお客さんになるっていう形でいるチームになっていて、
今このイネーブリングチームがLayXというかBacklackとかの中で何をしようとしているかで言うと、
Backlackにいくつかプロダクトがあって、それがそれぞれ一つのプロダクトとして進化をしてきていて、
技術的にも比較的独立性の高い状態で、それぞれモノリスとしてプロダクトごとにモノリスで成長してきているんですけど、
今後そういったプロダクトをいろいろ作って発展していった結果、
事業的な更新をしているところもあるので、いろんな連携がプロダクト間で必要になったりですとか、
あとはそもそもプロダクトの作り方とか開発の仕方みたいなところとかも含めて、
もっとよくできるものがあるだろうみたいなところは、いろんなところでイメージがあって、
15:02
爆速開発って社内でよく呼んでるんですけど、開発速度が速いっていうのはLayXの大きな特徴だと思うんですけど、
もっと速くできるんじゃないかっていうのが一つアイデアとしてあるので、
そのもっと速い開発をするにはっていうところで、いろんなこういうことを、こういう環境を用意したらいいんじゃないかとか、
こういうふうにしたらいいんじゃないかみたいないろいろ考えながら作っているっていうのが現状ですかね。
なので、そのための新しい仕組み作りとか、枠組みとかをLayXで進めてるっていう感じですかね。
なんかこの仕組みが結構新しいっていうのは、自分もLayer 1リポジトリを眺めていていつも感じるんですよね。
なんかこのLayer 1っていうプロダクトって、そもそも何なんですかって雑な質問、ちょっとこれも菅谷さんに投げちゃっていいですかね。
そうですね。なんか最初入社して眺めた時に割とプロダクトごとにいろんな知見が散ってるというか、
各々が独立したスピード感を保っていて、独立することでスピード感を保っているっていう利点もあるんですけど、
一方で知見が散っているなというところと、それぞれそれぞれのやり方が進化してたりとかして、
結構このまま色々複雑になっていくと大変だろうなっていうのは思い描いていたので、
さっきのマイクロサービスの話じゃないんですけど、何でしょうね、もうちょっと知見を集約した方がいいなっていうふうには思ったっていうのがまず一つと、
あと今後いろんなプロダクトを連携していくにあたって、連携ポイントというか連結点みたいなところを作っていかなきゃいけないよなっていうふうには思っていて、
ただそこで全職とかでもやったらモノレポってすごくいいなっていうのを感じていて、
マイクロサービスで色々ガリガリ作っているときに、レポジトリ分けてマイクロサービス作ると本当マイクロサービスの沼みたいなハマって、
オーナーシップがないサービスが生まれたりとか、誰も新しくサービス作るのすごい大変だったりとか、レポジトリ作ってそこにコミットしてとか、
そもそも全部で何かあるかっていうカタログ管理とかもすごい大変だったり、デプロイとかそのルール、新しいルールの適用とかを全レポジトリに適用するとかすごい大変で、
結構マイクロサービス大変だなっていう印象はすごく強かったんですけど、モノレポにそのサービスを送っているのをやった時点でそのほとんどが解決されるというか、
18:02
結局その境界線上のサービスのインターフェースは存在するんですけど、いわゆるしっかりと境界線を切り分けられたサービスたちがいわゆるモノリスに存在するっていう、
クリーンアーキテクチャーとかじゃないんですけど、綺麗なアーキテクチャーを維持しないといけないという制約の中に生まれるモノレポみたいなのが生まれて、
これってマイクロサービスとしてすごい良い形だなっていうのを感じて、なのでプロダクト間連携とかいろいろ社内でコードを共有するときにモノレポっていう視界の広さみたいなのはすごく良いなと思ったんですよね。
で、そのLayer Xとか爆落もいずれプロダクト間でいろんな共有をしたりとか、プロダクト間で通信しあったりとかって増えてくると思うんで、
モノレポっていうフィールドにそういった知見とか行動を集約していた方が絶対良いよねっていうところがあったのと、
あとモノレポにするといろんなルールとかガイドラインが行き渡るというか、凛と一つ取っても行き渡るので、
今そのLayer 1でコードジェネレーターみたいなのでテンプレートを生成するとか、そういうのとすごく相性が良いので、
なんでしょうね、そういうのもあってエンジニアがいかに楽に作るかっていうのを考えたときに、
今後その爆落とかLayer Xにとって起点となるような場所みたいなのを作っていきたいなって思ったんですよね。
それが最初のレポジションが生まれた、最初のきっかけで、
最初はそんなにすごい共通コードまず置いていければいいかなぐらいの感じでスタートしたんですけど、
でも結果としていろんなサービスを置けるようにしてみたり、
プロダクト感をまたぐようなGraphQLを作ろうみたいな話になっていって、
そういうのを置いたりしてっていうのでちょっと発展していってるっていう話がだんだん広がりすぎちゃったんですけど、
そんな感じのレポジトリになってます。
あれですね、Layer 1っていうのは僕らが多分これからさっきのスペクトラムで、
モノリス、アプリケーション、サービス、マイクロサービスになる中のアップの次を作るためみたいな感じなのかなと思ったんですけど、
吉木さん各プロダクト、コード大体見てきてるじゃないですか、
そこと比べて、一応前提として聞いていらっしゃる方の前提として、
結構Layer Xのソフトウェア設計ってすごく堅実というか、
一般的な設計を徹底的にやってるような印象を僕は持っているんですけど、
21:02
その中でLayer 1って吉木さんから見てどうですか、モノレポで確かにこういったメリットがあるとか、
とはいえまだこの辺を解決しなきゃいけない未解決問題があるとか、そういった観点で感じる部分とかありますか?
そうですね、最初の時は自分にモノレポの経験がなかったんで、どれくらいうまくいくのかなっていうのを思ってたんですけど、
今は開発サイクル回ってくると、これがベストだよなっていう気はやっぱりしてきましたね、そこはあって。
菅谷さんがさっきのに補足すると、嬉しい観点で言うと、最近はCIサービスとかを使う前提にはなってると思ってて、
レポジトリとこのCIとCDみたいなのがある程度1対1とかで動かす必要があったりすると、
レポジトリ分かれてて、例えばGitHub Actionsのファイル管理とかを全レポジトリでやっていくのってちょっとコストがバカにならなかったりとか、
もしくはツールセット的に用意してあげて、それをクローンしてとか、そういうのをいちいち考えなくていいっていう煩わしさがないっていうのはめちゃくちゃ自分の中では嬉しかったポイントだったりはしましたね。
今のLayer 1での課題的なところでしたっけ?
ここら辺はとはいえ、まだ言うほど上手くいってないなとか悩んでるなとか。
そうですね、そこあんまり今パッと出てくるのはないんですけど、
結構このLinuxで開発2年ぐらいずっとしてきていて、それについてイズミさんとかツグルさんが新しく入ってきたときに、やっぱり2方が知見がある。
GRPCだったりとかGraphQLだったりとか、そこの知識差みたいなのは自分の中でちょっと感じている部分があったりしていて、
そこはここからちゃんと身につけないといけないというか、今からのメモもついていけるように身につけるべきところなのかなっていうのが、
レポジトリとは関係なくて、スキル面で思ってたりするところですからね。
2人とも知見がありすぎて、何でしょうね、クミネイティーに来たものがちゃんとあるから、それをアプライしてくれてるからっていうのはありつつ、
ある程度前提とかコンテキストみたいなのをちゃんとキャッチしていかないといけないなと思います。
すごいいい話だなと思ったんですけど、その観点でイズミさんに聞きたいんですけども、
過去もマイクロサービスの中でお仕事をしてきてるじゃないですか。
はい。
その中で今取り組んでるレイヤー1って、いわゆるこれまで取り組んできたマイクロサービスと違いだったりとか、この辺面白いなみたいな部分とかあったりするんですか?
そうですね。やっぱりモノレポであることって、いろんな前提が変わるなっていう感触を自分は持っていて、
マイクロサービスっていった時に、モチベーションっていろんなものがよく出てくるんですけど、
24:10
コードベースの認知負荷を下げるために1個1個のコードベースを小さく保ちたいであるとか、
もしくはインフラ的にちゃんと独立させることでみたいな文脈であるとか、
結構いろんなモチベーションが混ざって語られることが多いなって思ったんですけど、
モノレポにすると、割とそれを全部独立して考えることができるような気もするなと思っていて、
そもそもモノレポの上に複数のサービスを置く段階で、
各サービスというか、いろんなコードを論理的に独立した状態で書く方法っていうのは多分作るわけで、
そこの段階でもコードベースを小さく保ちたいみたいなのって達成されてるわけで、
そこまでの話とそこから先のインフラ的に最適にしたい、
例えばここは絶対落ちてほしくないから、
SLが高い部分は独立したアーキテクチャ漁師にしたいみたいな話とかを、
別の話として完全に議論できるようになるなと思っていて、
もはや今までのマイクロサービスとモノレポ、マイクロサービスはちょっと別のものなんじゃないかなっていうのは日々感じてますね。
これまでのマイクロサービスと違うものって感覚は、僕もそのレイヤー1のリポジトリ見ながら、
Suguruさんとワンワンしながらすごい感じるんですけど、
いまいちまだ上手い言語化ができてないんですよね。
難しくないですか、これ。
みんなにマイクロサービスにしますって言うと、多分伝わってないと思うんですよ、今やってることが。
何が違いとして生まれてるのかなっていうのを、
このポッドキャストで生で喋りながら言語化できるのかみたいな話はあるんですけど、
僕はすごい気になってるポイントですね。
開発で、いずみんさんの目線から見て、この辺のプロセスが変わるなとか、
具体的に日々の開発業務がこうなりますみたいな変化ってお話聞いたところとかあります?
そうですね。
変わっているところ、
特に本番に出てないところを開発してる時とかはより顕著なんですけど、
今まで以上にコードの再配置とか境界線の引き直しみたいなのは、
すごいカジュアルにできるようになってるなと感じていて、
圧倒的に試行錯誤がしやすいんですよね、今までより。
今までマイクロサービス作るぞってめっちゃちゃんと設計して、
リポストリを作りますみたいな感じになって、
リポストリ作った後、間違えたって思ったら戻すの超大変じゃないですか。
27:05
それがそんなに面倒くさくはあるが、今までほど不可ではないなと思ってて、
もちろんちゃんと設計しないと不思議なことになるの前提なんですけど、
とはいえ今までより試行錯誤しやすいのは1個大きいかなと思っていて、
より最適な形を模索しやすい環境なのかなっていう気はしてます。
ある種そのリファクタリングがしやすいみたいなアーキテクチャ全体を見渡しても。
うん、そんな気はしますね。
API定義も全部の定義がプロトバフって形で同じリポストリに載っているので、
まずプロトバフありきで設計をして、その後ろ実装して、
この辺はこういう口も必要だよねみたいなのがあったら、
また新しくRPCを作ってみたいな。
結果的にマイクロサービスこれぐらいの流、
こういう席もここまでの席も持つよねみたいなのがよりどんどん鮮明になっていくみたいな。
そうですねリファクターしやすい、試行錯誤しやすい。
結構今までと違う感じがしますね。
さっきイズミンさんが言ってたこのコードとインフラって言えばいいんですかね。
レイヤーが分離して議論できてるとか。
今の話聞いてると個人的にはコードサービスのトポロジーインフラのあり方みたいな3つを分けて適切な再配置がしやすい。
それが今やってるレイヤー1でやりやすいところなのかなみたいな感じを勝手に受けたんですけど、
Suguruさんそんな理解で良いですか?レイヤー1で狙っているところっていうのは。
エンジニアが考えることを減らしたいっていうのが何よりもレイヤー1で狙ってるところなので、
何でしょうね。これでテラフォームこうなるとかインフラこうなるとかを作るときにあんま考えなくていいようにしたいっていうのがあるんですよね。
なんとなくそのサービスの定義というか、いわゆるバウンダリーというか境界線みたいなのを極力綺麗にアーキテクチャとして最初に定義できるだけやって、
それで作っていってみて、おかしかったら定義を変えてみて、定義さえしてしまえば残りに必要なものは全部生成するんで、
ロジックだけ書いてくださいみたいな感じになってるのがいいなというか、そういうのを目指していきたいっていうのがあるので、
結構コードジェネレーターでいろいろベースのコードとか、何でしょうね、サービス定義を書けば基本ベースとなるコードは全部生成されて、
30:06
で、プロトコルバッファー書けばファンクションのスタブも生成されるんで、あともこの中身を書いてくれみたいな、
そしたらデプロイとかはあと全部自動で動くんでみたいな、なんかそういう世界観なんで、エンジニアがもう本当インフラのこととか実はあんまりよくわかってないとか、
知らないけどとりあえず作ってますみたいな状態を目指していけるといいなみたいなところはあるんで、
そうですね、なんで、そういうインフラのことを最初のタイミングで考えなきゃいけないとかっていうのはできるだけやりたくないっていうのはあるんで、
まさに目指してるところかなとは思いますね。
ドメインの設計だけきちんと向き合って良いコードを書いたら、あとはよしなにやってるよみたいな世界なんですね。
あとはインフラ側でもしここはもっとこうした方がいいなと思ったときに、もっとこうした方がしやすいような感じにちゃんとなってるみたいなコードに手を入れなくても、
っていうのが理想かなと思うので。
めちゃくちゃ具体な話でいくと、例えばですけど、プロトモの定義書いたらそこで、RPCで通信する部分はもちろん生成されるんですけど、
グラフ系の部分も生成するとかいずみさんが取り組んでたりしてて、あとはデジタルベースが結局複数あったりしてて、
マイグレーション自分でローカルで毎回やんなきゃいけないみたいなのを自動でマイグレーション、複数のDB、必要なDBでマイグレーションを走るようにしておくとか、
エンジニアがデプロイするまでに一個一個必要なステップみたいなのが、ある程度自動化されてきてるっていうのがめちゃくちゃでかいのかなっていうのは思ったりしますね。
マイクロサービスのデベロッパーエクスペリエンスみたいな話になってくると、環境セットアップめちゃくちゃややこしい問題になりますよね。
全てのサービス、依存サービスを立ち上げないと動かないとか、当然やってくるわけなので、そこら辺が結構解決されてきてるような、そんな感じなんですね。
そうですね。モノレポにすることでその辺りがかなり良くなっていて。
前までマイクロサービスって全部立ち上げないといけないって言ってたら、Docker Composeに全サービスの定義書いて、ガチガチ書いてたんですけど、
ちょっと待ってよみたいになって、せっかくモノレポなんだから全部一気に立ち上がるじゃんみたいなんで、
全部プロセスを、いわゆるデプロイとサービス実装って必ずしも一緒じゃなくていいよねっていうのがあったので、
じゃあもう全部まとめて一個に入ったやつでデプロイできるローカル用のコマンドとかあってもいいよねっていうので、
今マイクロサービス多分何個かあるんですけど、それがまとめて立ち上がるローカルサーバーとかがあったりしますね、一つのプロセスの中に。
33:09
確かにインフラのトポロジーというかあり方は別にローカルだったら全部ワンプロセスで1DBで動いていいじゃないかと。
サービス貫通心も別に自分自身を参照すればいいじゃないかみたいな。
そうなんですよ。
結構GRPCとか、あとConnect Goを使ってるんですけど、GRPCとかConnect Goっていわゆるサービスインターフェースがちゃんと生成されるので、
リモートなのかローカルなのかあんまり考えなくていいっていうコードにはなるんですよね。
だからローカルで動くんだったらもう全部別にローカルにあるやつでいいじゃんっていうような感じで。
なのでこれでもう多分マイクロサービスの100個とか200個になっても、ローカル開発はもう1個立ち上げれば全部立ち上がるっていうふうになるはずというか、
でかいものですみたいな感じですよね、本当に。
面白い。じゃあそこはもうローカルで開発する限りは、そもそもGRPCすらかまさない可能性があるみたいなコネクションが、通信ができてるんですか、サービス間って。
一応ですね、通してるんですけど、ローカルの。
ローカルのサーバーに自分で問い合わせるっていう。
自分で問い合わせる。
やってるんですけど、返さないっていうのも多分できると思います。
一応ちょっと通したほうがいいんじゃないかなと思っていて、あえて通してるんですけど。
なるほど。いやでも開発の考え方が確かに、インフラを考えないっていう仕組みにしていくとそのような開発者体験が実現できるということなんですね。
そうですね。
同じポイントを得てるサービス会員ゾーンのCI検証とかも楽になるし。
結構全体で適応したい、例えば最近だとサーバーのタイムゾーンを調整する変更とかもまとめて全部適応できるんで、いろいろ楽なんですよね。
シェアドライブラリーの作りやすさはいいですよね。
そうですね。あとトランクというかメインのヘッドが常に最新っていうのがあるので、モノレポの場合。
マルチレポだとそれぞれのレポジトリのどのコミットを見るかみたいなのがあるんですけど、
全部メインが最新だよねってなってるのはかなり大きい利点だと思いますね。
あんまり考えなくていいというか、とりあえずメインで動かせば最新が全部動くよねみたいな感じになってるんで、
そういう煩わしさはかなりないかなっていうところですかね。
36:01
そこら辺はCIレベルで変更したら検証されて、そもそも互換性壊したらすぐに修正がかけられるっていうのもモノレポやってるよく言われる良さですしね。
そうですね。
モノレポで複数のサービスを作るようになって感じたのは、今までのモノリスっていうのがなんでみんながきついなと思いながら、
いきついなって思うように感じたのかっていうと、多分めちゃくちゃ複雑になっていくというか、依存が見えなくなるとか、
もう1個でワンプロセスで動かしちゃったりしてると、それがもう見えなくなっちゃうとかっていうのがあったかなと思うんですけど、
今みたいにモノレポの中で複数のプロセス立ち上げる、ローカルは1個だけどみたいな形で、
こうなんでしょうね、いいとこどりができてる感じはすごいするなと思ってます。
ちゃんとプロセス、デプロイするとプロセス分かれてて、こうなんでしょうね、ちゃんと認知負荷みたいなのが抑えられてて、
バウンダリーがあるっていうのが1個よく言って、ただローカルだとそこは一般プロセスで動かして、でも通信はさせてるみたいな。
なんか個人的にはモノレポで認知負荷もそこまで高くならない部分かなっていうのが思いますね。
確かにサービスバウンダリーがきちんと適用されねばならない設計になっているからこそ、認知負荷が上がりにくいみたいなのはありますよね。
モノリストでやってると好き勝手、よそのサービスのテーブルを参照すらできますからね。
そうですね、もうやろうと思えばない時間にないというか、いろんな複雑性が生まれてくるなというのはありますよね。
なるほど、そんなこんな喋ってるとですね、あっという間に、もともと30分ぐらい喋ろうかなと思っていたらだいぶ時間が経ってはしまったんだけども、
いや本当にこれ二部作にすべきだったなというぐらい話は楽しいですね。
ちょっと今日はレイヤー1っていうこのプロジェクト、エネーブリングチームっていうところの中身をですね、
ある種社内にももっと伝えたいなと思ってこの会を組んでるんですけど、
最後に今後このプロジェクトで目指しているところとか、その中で自分はこういうことをやっていきたいなみたいなところを、
最初はすぐるさんからよしきさん、いずみんさんの順に聞いてみてもいいですか。
すぐるさん、このプロジェクトをこれからここまでやっていくからこういう人来てほしいなみたいなところとか伺ってもいいですか。
そうですね、結構アーキテクチャとしてはかなり面白い感じになってきているなというか、
DX的にも結構面白いなと思っていて、他の会社とかであんまりここまでこんなふうにやってるのは見たことないかもなと思ったりとかしてるんで、
なんかそうですね、なんでしょうね、モダンなっていうわけでもないんですけど、
そのDXっていうのにフォーカスしたアーキテクチャっていう意味ではすごい面白いものになってるし、
なんかもっとなんか良くなりそうだなっていうところはあって、今日々それをこう、ここをこうやったらもっとこうなるんじゃないかとかいろいろ考えながらやってるんですけど、
39:08
なので結構なんでしょうね、そういうエンジニアが使うようなツールとかサービスとかを作ったりとか、エンジニアに限らずですかね、
いろんな人が使って、それぞれパフォーマンスが上がるとか、そういうのを作るのが楽しいとか、そういう人にとっては結構面白い状態になってるんじゃないかなと思うので、
ぜひそういうこう、人のお役に立ちたいというか、なんか技術を使って面白く、なんでしょうね、それこそ技術を使って面白いものを作って、
それで人の生産性を上げたりとか、もしくは人が作るものをもっと良くしたりとか、そういう風になるのが楽しいみたいな人は、ぜひぜひ来ていただけたら、かなり楽しい世界が終わってるんじゃないかなと思います。
いやほんと新しすぎてね、いまだにこう僕も全容をきちんと理解して、なんかSuguruさんとかみんなの設計論を理解できてるのかみたいになるぐらい新しくて面白いので来てほしいですね。
吉木さんなんかあのお伝えしておきたいこととかありますか、最後。
そうですね、まあやっぱり一緒に働けるメンバーみたいなすごい毎日刺激的で、いい自分だなっていうのは毎回思うのと、
今のフェーズでって考えるとやっぱり爆落やっぱり今ちゃんと成長させていかなきゃいけないアプリとしてプロダクトとしてっていうのがあるので、
なんかシステム開発だけじゃなくてちゃんとこうアプリ開発というかサービス開発、プロダクト開発に入っていっているのでエネルギーチームとかっていうのは、
なんかそのフェーズをこう一緒に楽しめる人がまた入ってもらえるとすごい良いなあっていうのは思いますね。
本当に楽しそうなチームで羨ましい限りです。
あとは泉さん最後何か言い残していることとか、なんかこの辺伝えときたいなあみたいなことなんかあれば。
そうですね、言い残したいことも議論は無限にしたいところですけど。
それはちょっと飲み会で今度しましょう。ご飯でも食べながらやりましょう。
まあやっぱりそうですね、今爆落っていうプロダクトはすごい成長しているところで、その成長の速度は当然止めたらダメ、拡大の速度は止めたらダメ。
でもちゃんとクオリティーの高いものをみんなで作っていく必要があって、それを支援する基盤を今作っていけるのはすごい楽しいなと思ってて。
ここでこのレイヤー1のわけでみんなの生産性が数倍数十倍になりましたっていうと、
回り回ってお客さんに提供できる価値、世の中に与える価値はすごい飛躍して大きな価値を与えられると思うので、
それを自分の技術力で実現できるっていうのはすごい楽しいなと思うので、
やっぱりこういうDX、ディベロッパーエクスペリエンスっぽいこととか、そういうのが好きな人とかはぜひ今話を聞きに来てみてほしいなっていう思います。
42:10
ありがとうございます。
本当なんか作ってるものが新しすぎる考え方だなと思って日々眺めていて刺激的なので、
僕もぜひ興味ある方は今後のこのチームからの発信とかも見ていただけたらなと思っております。
正直ちょっと今日は話し足りないなという気持ちで終わっちゃうんですけど、
ぜひまた継続的にこういうテックな回を人を変え、話題を変え、やっていきましょう。
というわけで、皆さんありがとうございました。
ありがとうございました。
ありがとうございました。
