Laravel Podcast - 2024年11月
Maru2024/11/15 Matt Stauffer x Taylor Otwell x Jess Archer
Laravel Podcast Episode 18
※ Laracon AU 2024で収録された特別編
Intro
Matt)
よし、みんなおかえり！
Laravel Podcastシーズン6にようこそ！
今回もまた、カンファレンスでの特別回ってことで、対面でやってるよ。
今日は友達と一緒に収録してるんだ。僕はホストのMatt Staufferです。
みんな、自己紹介してもらっていい？
Taylor)
みんな、どうも。
Laravelの生みの親、Taylor Otwellだよ。
Jess)
こんにちは、Jess Archerです。
Laravelで働いてるわ。
Matt)
で、僕たち今Jessの街にいるわけだけど、ここって君にとってどんな場所なの？
だって、今Laracon Australiaでブリスベンにいるわけだからさ。
君とブリスベンのつながりをちょっと教えてよ。
Jess)
もちろん！私は多分1歳か2歳くらいの頃からずっとブリスベンに住んでるの。
だから、ほぼ一生この街にいるんだよね。
家はここから車で24分くらいのところかな。
だから、Laraconがブリスベンで開催されるのは本当にワクワクしてる。
カンファレンスのトークの最初でも話したんだけど、すごく不思議な瞬間がたくさんあるの。
例えば、Taylorが普通に私がいつも歩いてる道を歩いてたりとか、
MarcelがTwitterにWoolloongabbaとか、普段よく目にする場所の写真を投稿してたり。
なんていうか、自分の日常と世界がぶつかる感じ？
本当に不思議な感覚だよね。
Matt)
でさ、僕たちが「ブリスベンに行くよ！」ってアメリカの人たちに話したとき、何人かブリスベン出身の人がいてさ。
そしたら「ブリスベンなんて気にしないでシドニーに行けよ」とか言われたんだよね（笑）。
でも実際に来てみたら、この街めっちゃ綺麗だし、ほんと最高じゃん！
こんなに素晴らしい場所だなんて知らなかったよ。
ほんと、ここで開催するって決めた君たちは正解だよね。
Laravel Nightwatch
Matt)
で、昨日、君たちがLaravel Nightwatchについて発表してたよね。
もうすぐリリースされる新しいプロダクトで、Laravel Cloudに続く大きな発表って感じかな。
まだ見てない人は、たぶんこのQ&Aを聞く前に発表動画を見た方がいいよ。
じゃないとあんまり話が分からないかもしれないからさ。
それで、発表動画の後って、いつも通りみんなからたくさんの質問が来るわけだけど、
TwitterとかBlue Sky、それからsuggest.ggで「質問まとめて送って」ってお願いしたんだよね。
だから今日はその質問をいくつか取り上げて、君たちに聞いてみようと思う。
で、「君たち」っていうのは、もちろんTaylor、Laravelの創設者でCEO、大ボスだよね（笑）。
それからJess、Nightwatchプロジェクトのプロダクトリード、いや、開発リードって言った方がいいのかな？
Jess)
そうだね、正式な肩書きだと「Engineering Team Lead」かな。
Matt)
なるほどね。
まあ、君たち二人ともいろんなレベルで関わってるよね。
だから今日はマイクをお互いに渡しながら進めていこうか。
Nightwatchの開発期間
Matt)
じゃあ早速始めよう。これは僕が考えた質問じゃないんだけど、
個人的に一番気になってることなんだよね。
Nightwatchの開発期間ってどのくらいだったの？
開発者の月単位の労力とか、要するにどのくらいの時間がかかったのかってこと。
だってさ、最初Twitterであの「悪役の絵文字」とかがちょっとずつ見え始めた[1]と思ったら、
いきなり完成した感じがしたんだよね。
こんなクオリティのものがこんな短期間で作れるなんて、信じられないくらいだよ。
実際どれくらいのスケジュールで作ったの？
Jess)
私たちはこの分野でLaravel Pulseの経験があって。
オブザーバビリティの分野で少しだけ先に進んでた感じかな。
たしか去年の12月くらいだったよね、Taylorが初めて私に「Pulse Proみたいなものを作れないかな？」って話をしてきたの。
「本格的に作るなら、もっと専門的なインフラを使ってみたらどうだろう？」みたいな感じで。
それで、色々と試し始めたのがその頃だったよね。
リポジトリをちょっと振り返ってみたら、最初はただのプレイグラウンド的なリポジトリがあったのよ。
そこではいろんなデータベースプロバイダーを使ってクエリを試したり、
プロトタイプをあれこれ作ってたんだけど、その最初のコミットが今年の4月18日だったね。
Matt)
え、本当に？
Jess)
私もびっくりしたんだけど、実際のダッシュボード、つまりデモで見せたあのリポジトリが作られたのは7月8日だったのよ。
Matt)
2024年の？
Jess)
そう、2024年の。それがいわゆる本番バージョンの開発を始めたときだね。
Matt)
じゃあ、開発期間は4ヶ月ってこと？
Jess)
うん、最初はクエリをいくつかコピペして試したりしてたんだけど、ダッシュボードは完全にBladeだけで作って、ビューの中に直接データベースクエリを書いてテストしてたの。
で、実際のプロダクトとしては7月から完全にゼロから作り始めた感じかな。
Matt)
それはすごいね。
Jess)
ほんとに驚きだよね。全部、うちの素晴らしいチームのおかげだよ。
Nightwatch開発チーム構成
Matt)
このプロジェクトに関わってるチームって、どれくらいの規模なの？
Laravel 開発チーム全体？それとも一部のメンバーだけ？
Jess)
主に「Australia Pacific team」って呼んでるチームが担当してるの。
ほとんどがオーストラリアだけど、日本からも一人参加してるよ[2]。
Matt)
全員が比較的同じタイムゾーンだから、チーム全体でやるよりもコラボしやすかったりする？
Jess)
うん、たいていプロジェクトはタイムゾーンごとに分けて進めることが多いんだよね。
Matt)
それはいいね！知らなかったよ。
Jess)
そうなの。
で、TaylorがNightwatchのプロジェクトマネージャーとかプロダクトマネージャー的な立場で全体を見てて、Australia Pacific teamが実際に作り上げてる感じかな。
NightwatchプロジェクトへのTaylorの関わり方
Matt)
じゃあTaylor、Laravel Cloudのときにも同じことを聞いたけど、今回も聞いてみたいんだ。
前はアイデアを思いついて、自分でそのアイデアを形にして、必要なときにプロジェクトの一部を他の人に任せるって感じだったよね。
今回、このプロジェクトについてはどうだった？
Laravel Cloudのときと何か違った点はある？
今回は君のアイデアがベースになってるけど、実際にはほとんどコードを書いてないんじゃないかと思うんだけど。
Taylor)
そうだね、実はPulseもNightwatchも、僕自身は1行もコードを書いてないんだ。
どっちも基本的には、アイデアの「核」となる部分を数段落くらい書いただけ。
例えば、「これ、面白そうなアイデアじゃない？試してみたいならやってみてよ」みたいな感じで。
「どんな結果になるか見てみよう」ってノリだった。
Pulseの結果はみんなも知ってると思うけど、GitHubで触ってみられるし、すごくクールに仕上がったと思う。
Nightwatchもほぼ同じ感じで、「このデータを深掘りすることができたらどうなるだろう？」とか、
「もう一段階下まで行けるかな？それってどんな感じになる？」みたいなことを考えてたんだ。
ありがたいことに、Laravelのチーム全体がすごく自立してて、アイデアを形にするのが得意なんだよね。
今年チームを拡大し始めたとき、特に最初の1回目、2回目の採用では、
割とシニア寄りの開発者を採ることに重点を置いてたんだ。
リモートチームだし、世界中に散らばってるからこそ、
基本的なガイダンスだけで自分たちで動ける人を採用するのがすごく重要だと思ったんだよね。
いちいち細かく指示したり、訓練しなくてもいい人たちをね。
もちろんこれから採用を続ける中で、もっとジュニア寄りの人も採用することになるかもしれないけど、
最初にこういったアイデアをしっかり形にするためには、主にシニアな人たちがいるのが大事だと思ったんだ。
そのおかげで、僕が基本的なアイデアを出して、あとは信頼して任せられるようになったんだよね。
結果として、すごく素晴らしいものが出来上がったと思う。
Matt)
それ、めっちゃ cool だね。
昨日、誰かに聞かれたんだよ。「Tightenでのシニアって、他の会社のシニアとは違うって聞いたことあるんだけど、それってどういう意味？」って。
それで、「技術力が重要？」って聞かれてさ。
確かにそれも一部あるけど、Laravelのスタック全体に精通してる必要はあるよね。
でも、それ以上に大きいのは自己指向性だと思うんだ。
だって、うちのチームは100人規模で「これやって」ってタスクリストを渡されるような環境じゃないからね。
2人チームとか、多くても4人チームくらいで、「これが大まかな方向性だから、あとは任せたよ」って信頼できる人が必要なんだ。
その人が共感力を持って状況を理解して、自分で進められるのがすごく重要だと思う。
だから、テクニカルなスキルの高さだけじゃなくて、独立性とか自己管理能力も重視してるって感じがするんだよね。
これって、君たちが目指してる方向性とも同じかな？
Taylor)
そうだね。問題を自分でしっかり考え抜く力も重要だよね。
それから、自分の担当するプロダクトにある程度責任を持つことができる力も。
例えば、全ての作業に対して線引きされたタスクチケットがあるわけじゃない場合もある。
Cloudを例にすると、データベースを削除するときに、チームの開発者は「このデータベースに関連するバックアップはどうする？」ってことまで自然に考えるわけだよ。
チケットとして「削除したデータベースのバックアップを消す作業」みたいな指示がなくてもね。
つまり、自分の仕事や担当するプロダクトの一部に対して責任を持ち、自分で方向性を決められる力。
これがシニアらしさの大きな違いだと思うんだ。
NightwatchとTelescope, Horizonとの相違点
Matt)
そうだね。君たちの答えの中でPulseに触れてる部分がいくつかあったよね。
それがちょっと気になったんだ。
つまり、Nightwatchはオブザーバビリティスタック全体の中でどこに位置づけられるの？ってこと。
Horizonも関連してる部分があるけど、特にTelescopeやPulseとはどう絡むのかな？
Nightwatchはそれらと連携するの？それとも置き換えるの？
それとも全部共存していく感じ？どうやって全体がまとまってるのか教えてくれる？
Taylor)
Nightwatchは確実にHorizonの代わりにはならないよ。
Horizonにはダッシュボードがあるから、「これはオブザーバビリティツールなんだな」って思う人もいるかもしれないけど、実際にはそれ以上の機能があるんだ。
Horizonはむしろキューの負荷分散ツールって感じかな。
待ち時間の長さに応じて、プロセスをキューに割り当てたりするんだよね。
例えば、あるキューが混んでると判断したら、プロセスをそのキューに多めに割り当てるとか、
他のキューが混んできたらそっちにも割り当てるとか、そういうことをしてる。
だから、ただのダッシュボード以上の機能を持ってるんだ。
NightwatchにはHorizonと似たような画面があって、
実行中のジョブや失敗したジョブなんかを確認できるけど、
それは純粋に観察するためのもので、キューの負荷分散はやらない。
だから、HorizonとNightwatchは一緒に使うことも全然可能だし、場合によってはその方が理にかなってることもあると思う。
それからTelescopeもNightwatchと似てるように見えるかもしれないけど、
Telescopeは最初からローカル開発用に作られてるんだ。
Nightwatchが提供するようなインサイトは得られないし、
逆にTelescopeの方がNightwatchよりも多くのデータを保存するケースもあるんだよね。
例えば、Telescopeはリクエストボディ全体やヘッダーなんかを、
アプリケーションに入ってくる全てのリクエストについて保存してる。
ローカルデバッグ用のツールだから、そういったデータを掘り下げて確認できるようになってるんだ。
でもNightwatchでは、すべてのリクエストのリクエストボディを保存するのは現実的じゃないし、
そもそも本番環境向けのツールとしてはあまり望ましくないと思う。
あと、Nightwatchみたいなツールを作るには、ローカル環境で簡単にセットアップできないような技術が必要になるんだ。
例えば、Nightwatchの裏側にはClickhouseのデータベースやKafka、Lambdaなんかが使われてるんだよね。
単純なLaravelアプリとはちょっと違うんだ。
Matt)
ローカル環境にそれを設定するわけじゃないよね。
Taylor)
そうだね、そうじゃない。
Matt)
なるほど、つまりこれはかなり簡略化した答えだけど、
Horizonはキューを管理するツールで、確かにダッシュボードはあるけど、あくまでキューマネージャーだと。
Telescopeはローカル開発には素晴らしいけど、本番環境向けではないということだよね。
で、次に来る予定だった質問を今聞いちゃおうと思うんだけど、
Nightwatchをローカル開発に使いたい場合、それって可能なの？
Nightwatchはローカル環境でも使えるのか
Taylor)
それは全然可能だよ。
ただ、一部の画面はローカル環境では意味がないと思う。
というのも、それらは大規模なマルチユーザーアプリケーションとか、
トラフィックが多い環境でのインサイトを提供することを想定して作られてるから。
でも、いくつかの画面はローカルでも使えるかもしれないし、
例えば例外の画面とかログの画面とかは、使いたいって思う人もいるかもね。
ただ繰り返しになるけど、Nightwatchはローカルツールとして作られたものじゃないんだ。
Matt)
それが目的ってわけじゃないんだね。
Taylor)
そう、目的じゃない。
やりたければできるけど、間違いなくそれを意図したものではないね。
NightwatchとPulseの相違点
Matt)
なるほど。
で、まだ触れてないのがPulseだね。
あと、関連する質問で「Nightwatchのカスタムダッシュボードを作れるの？」っていうのもあったよ。
Pulseに詳しくない人のために言うと、Pulseはプリセットのダッシュボードコンポーネントがいくつかあるけど、基本的には「ダッシュボードを作ったり、メトリクスを表示したりするためのツールキット」みたいな感じなんだよね。
一方で、Nightwatchはそういう方向性じゃないと思うんだけど、そのあたりについて説明してくれる？
PulseとNightwatchのカスタマイズの違いとか、それぞれの役割がどうフィットするのか教えてほしいな。
Jess)
Pulseでは、Livewireを使って「ビルド不要なカスタマイズステップ」を実現することにしたの。
Livewireを使うことで、ユーザーがダッシュボードに好きなものを載せられるようになるって分かってたからね。
だから、そういう機能を目指して作ったわけじゃないんだけど、「結果的にそれができるようになったから、まあいいじゃん！」って感じ。
主な目標は、自分が優先したいカードを選べるようにすることだったの。
例えば、オフィスで働いてる人が大きなモニターに表示して、リアルタイムで状況を確認できるみたいな使い方を想定してたんだよね。
その人たちが「このカードを上に置きたい」とか、「このカードを大きくしたい」とかできると便利かなって。
あと、別のメトリクスを収集して保存できる機能もいいなと思ってて、例えば売上に関するカードを作りたいとかね。
そういう感じで、ちょっとカスタマイズできる要素を盛り込んでるのがPulseなんだ。
一方でNightwatchは、パフォーマンスモニタリング、例外追跡、ログに特化してるの。
で、Nightwatchにはカスタム計測に関する面白いアイデアがあって、
例えばLaravelの外にある処理、メール送信とか外部リクエスト、クエリみたいなものではないけど、
時間がかかる処理があったとしたら、それを計測用のクロージャでラップして、
タイムラインに表示できるようにするってことが考案されているところ。
現時点ではダッシュボードのカスタマイズはないけど、
例えば「どのカードを優先的に表示するか」を選べるようになるかもしれない。
アプリケーションによっては、ユーザーがいないものもあるだろうし、そういう場合はユーザーカードを表示する意味がないよね。
あるいは、キューを使ってないなら、キュー関連のカードを一番上に表示するのもおかしいよね。
だから、将来的にはそういう機能を考えるかもしれないけど、今すぐではないかな。
Matt)
リリース時点では、たぶんそこまではないよね。
Jess)
リリースには含まれないね。
Nightwatchの画面設計の意図
Matt)
デモで見ててすごくいいなと思ったのが、君たちが「例外が発生した場合は、他のどこに表示されるよりも例外が重要だと思うから、例外を一番上に置くよ。だって、みんなはそれを気にすると思うから」って言ってたところなんだよね。
それを聞いて、ツールを作る上でしっかりした意図を持って「ここを重視すべき」って意見を反映させてるのがすごく伝わってきたんだ。
アプリケーションを作るときって、「ここは必ずこの位置に置かなきゃいけない」とか、「これはいつも表示しなきゃいけない」みたいな固定観念にとらわれがちじゃない？
「これが大事なときもあるけど、そじゃないときもあるのではないか」っていう質問を自分に投げかけても、それを動かすになかなか至らないことが多いんだよね。
でも、デモを見てて、「そうだよね、例外が起きたらそれが最優先だよな」って思えたし、その例外を掘り下げることができるって分かるのがすごくよかった。
で、こういう設計をするには、「どこを重要視するべきか」っていう意見を明確に持ってなきゃいけないと思うんだ。
君たちが言ってたように、Laravelの開発者として小規模から大規模のプロジェクトまで運用してきた経験から、「これが重要だ」「ここに注目すべきだ」っていう考えを反映させてるんだと思うんだよね。
もちろん他の部分もクリックしていろいろ見れるけど、「これはこうあるべき」っていう明確な意図があるのが伝わるし、それがカスタマイズ性を求める質問とか、オープンテレメトリーみたいなものを使いたいって話とは対照的だと思うんだ。
で、「これはこういうツールにするよ。信じて。きっと楽しめるから」って、
君たちははっきりと提案してる感じがするんだよね。
動画を見てて、「はい、確かにその通りです」って納得したよ（笑）。
これって本当のところどうなのかな？
君たちは、こういう明確な意図を持って設計してるんだよね？
Jess)
うん、私たちは明確に「こうしたい」って意図を持って動いてると思うよ。
最初は、とにかく大量のデータを集めるところから始めたの。
初期のプロトタイプでは、全画面に集めたデータを全部載せて、
「もしこれだけのデータがあったらどう見えるんだろう？」って試してみたんだよね。
それで次は、「必要な情報を必要なタイミングで表示する」っていう方向に絞り込む作業をした。
その過程で、デザイナーともすごく密に協力したんだ。
デザイナーが入ることで、私たち開発者が陥りがちな考え方から抜け出すことができたんだよね。
例えば、私が作った初期バージョンでは、成功したものは全部緑色にしてたの。
そうすると、赤とかオレンジの問題は見えるには見えるけど、画面全体がまるでクリスマスツリーみたいになっちゃって。
デザイナーからの最初の提案の一つが、「成功したものは目立たせなくていい」ってことだったの。
こういうアプリケーションでは、エラーとかパフォーマンスの問題を目立たせるべきだってね。
それに例外処理もそう。
未処理の例外があったら、それが最優先事項だから、一番目立つ位置に配置すべきだって。
でも、開発者としての感覚だと、「これはこのページのこの場所に置くべきだ」って思っちゃうわけ。
「例外をページの一番上に表示する」っていうのは、開発者脳からすると追加条件みたいに感じるし、
テストするべきケースも増えるから、なんか変な感じがしてたんだよね。
でも実際に試してみて、その動きを確認してみたら、「これが正しい」って感じられた。
開発者だけで作ったソフトウェアにデザインの視点を入れることで、
より考え抜かれたデザインになるんだなって思ったよ。
そういう細かい部分への配慮とか、深い考察がプロダクト全体に行き渡ってるのが分かると思う。
Matt)
うん、それはすごくよく分かるよ。
みんなが「見た目がすごくいい」って言ってるのは、もちろんデザインが美しいとか、
アニメーションが素晴らしいとか、そういうところもあるけど、
それ以上にユーザーエクスペリエンスが大きいと思うんだよね。
情報が「あるべき場所」にあるから、APM（アプリケーションパフォーマンス管理）やエラー、
ログについて考えるときに、どこを見ればいいのか教えてくれる。
僕は単に「欲しい情報をそのまま見せてくれる」だけじゃなくて、「そもそも君はここに注目すべきだよ」って教えてくれるツールが大好きなんだ。
そのツールのおかげで、自分のスキルも自然と向上する感じがするからね。
だから、これには本当にワクワクしてるよ。
Nightwatchの技術スタック
Matt)
さて、ちょっと切り替えて話題を進めよう。
美しいデザインの話が出たところで、技術スタックについて聞きたいんだ。
みんながよく聞くのが、主に2つの側面についてなんだよね。
1つはバックエンドの技術スタック。
この膨大なデータをどうやって処理してるのかとか、その仕組みについて。
もう1つはフロントエンドの技術スタック。
すごくレスポンシブだし、アニメーションも一般的に見るものとは違っててめちゃくちゃ滑らかだよね。
僕の友達のサム・サリコフなんか、UIにめっちゃこだわる人なんだけど、グラフのアニメーションがどうなってるかについて30件くらいメッセージを送ってきたんだよ（笑）。
だから、バックエンドとフロントエンド、それぞれの技術スタックについて教えてくれる？
Jess)
もちろん！
さっき話したように、PulseはLivewireで構築したんだけど、あのプロダクトにはすごく合ってたんだよね。
でも、NightwatchのUIやページ上にある大量のデータを扱うためにはクライアントサイドでフルにコントロールできる仕組みが必要だったから、今回はInertiaを採用したの。
フロントエンドにはReactを使うことにしたの。
Laravelの標準的なやり方からは少し外れるけどね。
CloudでReactを使ってるって話を聞いてたし、Reactが得意な新しいメンバーもいたから、
特に強い意見はなかったけど、「チームが使いやすいものを選ぼう」って感じで決めたよ。
だから、フロントエンドのスタックはInertiaとReactだね。
Reactではshadcnのコンポーネントを結構使ったよ。
もちろんデフォルトからかなりカスタマイズしてるけど、それでもかなり助けられたね。
例えばツールチップとかポップオーバーみたいな小さい要素も、
デフォルトでうまく動くし、ポータルを使ってZインデックスの問題とかも解決できるのはすごく便利だった。
あと、デザイナー兼フロントエンドエンジニアがチームにいるのもすごく助かったよ。
私たちはバックエンド中心の人間だから、とりあえずデータをページに載せてFigmaのデザインに近づけるところまで作るんだけど、その後で彼が細かい部分を仕上げてくれるの。
Figmaは静的なデザインしかないけど、彼が動きをつけたり、
アニメーションやトランジションを加えたりして、さらに完成度を高めてくれるの。
正直、CSSやJavaScriptアニメーションで今できることには全然追いつけてないから、そういうのを専門にやってくれる人がいるのは本当にありがたいよ。
私もデザインにもっと時間を割きたいけど、そうするとバックエンドの作業に集中できなくなるからね。
で、バックエンドの話に移るけど、バックエンドはもちろんLaravelがダッシュボード全体を動かしてるよ。
データベースはPostgresを使ってて、アプリケーションの基本的なデータは全部そこに入ってる。
でも、分析用の大量のデータはClickHouseを使ってるよ。
メトリクスやその他のデータはほぼ全部ClickHouseに保存してるの。
ClickHouseは本当に面白いよ。
Laracon USでClickHouseについてのトークもやったんだ。
Nightwatchを発表する前だったけど、裏側をちょっと紹介するような内容なの。
Matt)
そのトークのリンクは概要欄に載せておくから、興味がある人は見てみてね。
Jess)
そのトークでは分析用データベースのコンセプトを紹介したんだけど、
私自身もこれについては全然知らなくて、「OLAP」や「OLTP」って何？って感じだったの。
でも「OLAP」って単語を知ったおかげで、検索して自分に必要なデータベースの種類を見つけられるようになったんだ。
だから、そのトークの目的の一つは、こういう問題を抱えてる人に「OLAP」って言葉を教えて、
それを使って調べてみてもらうことだったんだよね。
もちろんClickHouseが万能なわけじゃない。
だからこそ、用途に応じて2種類のデータベースを使い分けてるんだよ。
それぞれのデータベースには得意な領域があるからね。
あと、データを取り込む仕組みとして、LambdaやKafkaを使ってるよ。
さまざまなアプリケーションからデータを収集してClickHouseに保存するためのパイプラインを構築してるの。
Matt)
これは細かい話なんだけど、最近「SQLiteとMySQLとPostgresの違い」について質問されることが結構あるんだ。
今回、Nightwatchの「膨大じゃない方のデータストア」としてPostgresを選んだ理由って何か特別なものがあるの？
Jess)
なんかすごい技術的な答えを期待されそうだけど、実際にはMySQLもPostgresもSQLiteも、どれも同じくらい使ってきた気がするんだよね。
だから、特に強い意見はないの。特定のユースケースがない限りね。
例えばGIS（地理情報システム）関連だったら、PostGISがあるからPostgresを選ぶかな。
でもNightwatchでは割と標準的な用途でトランザクションデータベースを使うから、正直どれを使っても問題ないと思う。
Matt)
なるほどね。
Jess)
実はPostgresを選んだ理由って、Laravel CloudでPostgresを使った面白いことをやってるって聞いたからなんだよね。
それで「どうせCloudに載せるならPostgresで作ったほうがいいかも」って思って決めたの。
まあ、EloquentとかQuery Builderを使ってるから、
もし別のデータベースに切り替えたとしても、特に影響はないと思うよ。
というのも、データベースに関して「複雑なこと」をやってるのはClickHouseのほうであって、
トランザクションデータベースではそんなにやってないからね。
NightwatchはLaravel Cloudで動いているか
Matt)
それって実は、次のちょっとした質問にぴったりの話題だね。
NightwatchってLaravel Cloud上で動いてるの？
Jess)
今のところは違うね。
主にローカル環境で動いてて、今はForge上にデモ環境を作ってるけど、それが一番手っ取り早かったからなの。
でも、ダッシュボードとか全体をCloud上に載せる計画は確実にあるよ。
そのほうがいろいろ理にかなってるしね。
デモが一段落したから、これからその「クールなこと」を始められると思うよ。
データが保存される地域を選択可能か
Matt)
なるほどね。じゃあちょっと一息ついてもらって、残りの質問を片付けよう。
残念ながら細かい質問ばっかりなんだけど、
その中の最初の質問が「コンプライアンスのためにデータが保存される地域を選べる？」ってことなんだ。
Taylor)
それは確実に検討してることだよ。
リリース時点で確実に提供できるかは分からないけど、こういう要望が多いのは十分理解してるから、
しっかり考えて取り組んでいくつもりだよ。
今のところはそんな感じかな。
Nightwatchのスケーリングのために取り組んだこと
Mat)
なるほど、分かった。
じゃあ次の質問ね。
Nightwatchを作る中で、スケールに関するバックエンドの課題でこれまで経験したことのない問題に直面したことはあった？
Jess)
ちょっと関連する話にはなるのかな。
Jack Ellisがさらに高度な分析とかを導入したとき[3]のことを思い出すんだよね。
彼の仕組みでは、顧客がリクエストを受けるたびに、彼のところにもリクエストが来る。
だから、例えば彼の顧客がDDoS攻撃を受けたら、それが彼にも影響するわけ。
しかも、それが他の顧客のデータ収集全体の中ではほんの一部に過ぎないんだよね。
その「大量のデータを収集する」っていう考え方自体が、当時の私には恐怖そのものだったの。「そんなの絶対やりたくない」ってね。
でも、Pulseを作ったときに、その手のアイデアに少しずつ慣れてきたの。
ただ、PulseではMySQLとPostgresを使ってたから、データの扱いには限界があることも分かってた。
最初のステップは、すべてのアイデアを試すプロトタイプ作りだったんだよね。
Tim[4]と一緒に、学術論文を読んで、
時間ごとのロールアップ集計をするアルゴリズムを学んだりもした。
どうやってこの膨大なデータを処理するかを模索してたの。
それで最終的に「分析用データベース」や「カラムストア」っていう概念に行き着いたの。
いろんなものを試したけど、最終的にはClickHouseを選んだよ。
ClickHouseはオープンソースだし、ほんとにすごいんだよね。
開発チームも素晴らしくて、めちゃくちゃ親切なんだ。
ちょっと面白い例えだけど、「データベース界のLaravel」って感じがするんだよね（笑）。
ドキュメントも素晴らしいし、コミュニティもすごく活発でクールなんだ。
一方で、他の大手のサービスはもう少し「企業っぽい」感じがあって、
それがちょっと距離を感じさせるんだよね。
Laravelチームメンバーが増えたことによる影響
Matt)
さて、テイラー、君が何度か「Laravelの新しい世界がこれまでできなかったことを可能にしてくれる」と話していたよね。
そしてJessが話している内容を聞いてると、JessもTimも本当に素晴らしい人たちだよね。
その二人が、あるプロダクトのほんの一部分のためだけに何週間も、時には何ヶ月も学術論文を深掘りしてるなんて。
でも、それって以前の君たちにはその時間を確保するのが難しかったんじゃないかと思うんだよね。
つまり、僕が思うに、これが「より大きなチームがいることでできるようになったこと」の一部なんじゃない？
僕の理解は合ってるかな？
Taylor)
そうだね、これはチームが大きくなったこと、そしてAccelからの財政的なサポートがあったからこそできることなんだよ。
そういったサポートがあったおかげで、より多くのスタッフを必要とするリスクの高い課題にも挑戦できるようになった。
もし僕一人で会社を動かしていたとしたら、こういったリスクを取ることはまずなかっただろうね。
だから、いろんな要素が組み合わさって、これまで以上に大きな課題に挑戦できるようになったんだ。
もちろんそれはリスクも高いし、関わる作業量も多いんだけど、その分、最終的にはユーザーにとってものすごくメリットがある。
CloudやNightwatchみたいなプロダクトは、これまで僕たちが作ったものよりもユーザーエクスペリエンスや仕上がりのクオリティが格段に上がってる。
そして、それが顧客に提供できる価値もずっと大きいものになってる。
だから、すごくエキサイティングなことなんだよね。
Matt)
本当にワクワクするよね。
これ、前に個別に話したことがあるけど、Keith Damianiが1年くらい前に僕のところに来て、「APM（アプリケーションパフォーマンス管理）とか何かそういうものを作るべきじゃない？」って言ったことがあったんだ。
それで少し調べてみたけど「これはすごい作業量だな」と思って、「クライアントワークから人を外してまでそれをTitanで作るクオリティに持っていくのは無理だろうな」って結論になったんだ。
完全に諦めたわけじゃないけど、「それは素晴らしいアイデアだけど、どうやるか分からない」って感じだった。
だから君たちがそれをやるって聞いたときは、まず最初に「素晴らしい！ぜひやってくれ！」って思ったし、でも同時にこれをどれだけ深いレベルまで、どれだけ高いクオリティでやり遂げられるのか、全然想像もつかなかった。
結果を見て、本当に驚かされたよ。
まず普通に驚きだったし、それに加えて当時少し調査しただけで「これがどれだけ野心的でどれだけ大きな作業になるか」を感じてたからこそ、その中で君たちがやり遂げたことに感動してる。
君たち二人に伝えたいのは、これって本当に信じられないくらい素晴らしい仕事だってこと。
しかもそれをたった4ヶ月でやり遂げたなんて、本当に驚異的だよ。
もし誰かが「Laravelの新しい方向性で、これまでできなかったものが生まれている」って証拠を探してるなら、これがその証拠だと思う。
本当にここに到達したんだって感じるよ。
Taylor)
そうだね。今年の初めの9人とか10人の小さなチームでやってたら、この規模のものは絶対に作れなかったと思うよ。
Nightwatchと他ツールとの連携機能
Matt)
なるほど。それじゃあ、あと2つ質問をしたら終わりにするね。
1つ目の質問だけど、NightwatchってGitHubのIssueやPRとか他のツールとの連携機能を持つ予定はあるの？
例えば例外追跡と連携してNightwatchが自動でIssueを作ったり、特定のステータスに応じてIssueを自動でクローズしたりとか。
こういう機能が将来的に追加される予定はある？
Jess)
それについてもいろいろ考えてるよ。
Nightwatchでは掘り下げられる領域が本当にたくさんあるんだけど、まずは優先的にフォーカスするいくつかの領域を選んで進めることにしたんだ。
今回はAPM（アプリケーションパフォーマンス管理）にかなり注力したけど、例外追跡やログも全体を結びつけるストーリーとして入れてあるよ。
ただ例外の部分は今後もう少し掘り下げてNightwatch内や外部ツールでIssueを作成できるような仕組みを検討するつもり。
他にもみんなが期待するものだけじゃなくて、ちょっと意外なアイデアなんかも考えてるよ。
Matt)
なるほどね。
ちなみに僕のトークではもし見てない人がいたらなんだけど、「すべての新しいLaravelアプリはバグ追跡をオンにするべき」って話をしたんだ。
ログもあると素晴らしいけど、そこまでは触れられなかった。
APMに関しては、いろんなツールを試して「99%のプロジェクトにはコスパが合わない」って結論に至ったことが何度もあってね。
そこに、Laravelの公式として「ベストプラクティスを提供するツール」でAPMやログが簡単に使えるようになるなんて、本当にワクワクしてるよ。
これをLaravelアプリに導入しようとして10年以上試行錯誤してきたけど、ずっと良い解決策が見つからなかったんだ。
さらに、例外追跡と統合されるっていうのが本当にすごいと思う。
Jessとも少し話したけど、例外とログをそれぞれ別のツールで管理しているとそれらを関連付けるのがほぼ不可能なんだよね。
例えばあるログが同じタイミングで発生した例外と関連している場合、それが同じリクエストやジョブに紐づいてるかを追跡するのはほとんど無理なんだ。
でも、Nightwatchではそれが一つのシステムで統合されてるだけじゃなくて、開発者として「リクエスト」「ユーザー」「ジョブ」みたいな流れでトラッキングしたいっていうニーズをちゃんと理解してくれてる。
例えばあるリクエストが特定のジョブを起動して、そのジョブがメールを送信する、みたいな一連の流れが、全部追跡されて繋がってるのをデモで見たときは、本当に感動したよ。
これを早く試してみたくて仕方ないんだ。
Jess)
それは私たちが最初に本当に注力したことの一つだったんだよね。
データをどのように全部つなげるか、っていう部分にね。
例えば「トレースID」みたいな概念をすべてに付与して、どんな観点からでもデータを追跡できるようにしたんだ。
初期のプロトタイプでは、このツリーを辿ることでどこからでも情報を追いかけられるようになってた。
例えば、カスタマーサポートの視点で「このユーザーが問題を抱えている」ってところから入ったり、
「ここに問題がある」と分かっているところから入ったり、あるいは「まだ問題があるかどうか分からないけど調べてみたい」っていう場合でもね。
リクエストの視点から掘り下げたり、ジョブやクエリの視点から見たり、どの方向からアプローチしても関連する他の情報の文脈を常に把握できるようにしたの
そこからさらにAPMの部分をしっかり作り込んでいったんだけど、この「すべてがつながる仕組み」は最初から組み込まれていたものなの
Matt)
そのためにフレームワークに何か変更を加える必要があった？
Jess)
いいえ、フレームワークに変更を加える必要はなかった。
ただ、データの一部を取得する方法については改善できる部分がいくつかあるとは思ってる。
でも、現時点では必要なことを達成するための方法を見つけてるから大丈夫だよ。
それに具体的なバージョン番号は言えないけど少し前のバージョンにも対応できるようにしたいと考えてるから、大きな変更は避けたいと思ってるの。
ただ、小さな変更でも改善できる部分はいくつかあるね。
例えば、現在は「マイクロタイム」を保存してるけど、「高精度タイム」を保存したほうが良いケースもあるかもしれないとか。これを変えることが実際に可能かどうかは分からないけどね。
Taylorも「何の話をしてるんだ？」って思ってるかもしれないけど。(笑)
今のところ、私たちがキャプチャしているメトリクスはすべてマイクロ秒単位で計測されてるの。
というのも、データベースクエリの多くは1ミリ秒未満で処理されることが多いからね。
もしミリ秒単位しか保存できなかったら、タイムラインの正確性を保つのが難しくなる。
例えば、実際には別々のタイミングで発生している処理が、同じタイミングで発生しているように見えてしまうことがあるの。
Matt)
それが実際には違うのに、ってことだね。
Jess)
そうそう。
だから、すべての計測はマイクロ秒単位にしてる。
でも場合によっては、高精度タイムのほうがより適してるケースもあると思うよ。
Nightwatch導入によるパフォーマンスコスト
Matt)
それじゃあ、最後の質問。
今、マイクロ秒やミリ秒単位の精度でこれだけ細かいことを追跡してるけど、Nightwatchをアプリケーションに追加することでそれ以前にはなかったパフォーマンスコストが発生するんじゃないかな？
Jess)
まあ、どんなモニタリングや観測ツールでも何らかの形でシステムにフックする必要がある以上、少しのオーバーヘッドは避けられないよね。
ただ、Nightwatchの統合ポイントはすごく軽量に設計されてるよ。
基本的にはアプリケーションをホストしているサービス上にローカルエージェントを実行するようになってる。
サーバーレスみたいな特殊なケースでは少し異なるシナリオも出てくるかもしれないけど、そこはうまく対応できるように設計してるよ。
一番重要なのは、リクエストのライフサイクル中にメトリクスを収集してそのリクエストが完了してレスポンスが送信された後で、そのメトリクスのペイロードをローカルエージェントに送る仕組みなの。
その通信はローカルのTCPソケットを使うから、外部のデータベースやHTTPリクエストを使う必要がない。
全部同じマシン内、いわば「内部のローカルホスト」で完結するの。
その後、ローカルエージェントがこれらのデータをバッチ処理して送信するようになってる。
Matt)
リクエストそのものには全く影響を与えない形で、ってことだね。
Jess)
そうだね。
もちろん、イベントをリッスンして、そのイベントのプロパティを読み取って、どこかに保存するコードを実行するために、ほんのわずかな時間は必要だけど、それは秒単位で言えばほんの「何千分の1秒」程度のことだよ。
Matt)
でも、それって既存の例外追跡サービスとかと比べても大きな影響はないってことだよね？
Jess)
その通りだね。むしろ、既存のサービスよりもパフォーマンスが良いかもしれないよ。
Matt)
というのも、Nightwatchは自分自身でHTTPリクエストを送らないからだよね。
他のサービスはエージェントを持ってないから、それをやらざるを得ないけど。
Jess)
そうだね。
Outro
Matt)
なるほど。
それじゃあ本当に最後の質問なんだけど、今日の話の中でカバーしきれなかったことが何かある？
Taylor、Twitterで質問を受けたこととか、Jessも含めて、「これだけはみんなに伝えたい」って思うことがあれば教えて。
Jess)
そうだね、今日話した内容は大体カバーできたと思うけど、
Taylorも話の中で言ってたように、今はNightwatchの土台を築いてる段階なんだよね。
どうすればこれをもっと良くできるか、アイデアが本当にたくさんあるんだ。
ただ、その「もっと先のアイデア」を今はまだ探求できないのが、ある意味ではちょっともどかしい部分でもあるよね。
だから、これからも探求したいことがたくさんあるし、今この段階で驚いてくれてる人たちは将来的にもっとすごいものを目にすることになると思うよ。
Matt)
僕が今どれだけ興奮してるか、きっと伝わってるよね（笑）。
本当に素晴らしい。いや、すごくクールだし、本当にワクワクしてる。
忙しい中、時間を取ってくれてありがとう。
今このカンファレンスでいろいろと大変なことがあるのは分かってるけど、君たちの全ての努力に感謝してるよ。
それから、僕も登録リストに入ってるんだ。
サインアップリストを見つけた瞬間、すぐに飛び込んだよ（笑）。
だから、早期アクセスがもらえることを楽しみにしてる。
今日は本当にありがとう。
Jess)
ありがとう、Matt。
Taylor)
ありがとう、みんな。またね。
Matt)
またね！
-
Hamasaki Ryuta氏。2024年6月にLaravelコアチームへJoinしている。 ↩︎
-
Laravel コアチームのメンバーの一人Tim MacDonald氏を指している ↩︎