OSSとの関わり
趣味でOSSをやっている者だ。引き続き、goccyさんをゲストにお話ししていこうと思います。
前半、GoYamlの話とか、Yamlの話をしてきたんですけど、それに続いて、OSS開発とか、そういったものへのスタンスみたいなところをいろいろ持ってきてくださってますので、その辺の話をしたいかなと思います。
なんかこの辺で最近、ちょっと書いてきてくださったことをお話しいただいていいですか?
はい。自分のOSSとの関わり方なんですけど、Mixiに入社した当時から、オープンソースとして自分の成果物を世に出してフィードバックをもらったりとか、
こいつこういうことを考えてコードを書いてるんだ、みたいなのがコードを通して伝わるみたいな世界がすごい好きで、
で、OSSがそもそもソフトウェアを作って同行っていうのが好きなのもあって、オープンソースを今までずっとやってきたんですけど、
その十数年やってると作ってるものも結構多くなってきて、ありがたいことにスターもそれなりに多くもらうプロダクトが多くなってきて、
で、結構自分珍しいかなとは思ってるんですけど、それなりにスター数があるプロダクトをいくつも持ってて、それをメンテナンスしているっていう状態が結構珍しいかなと思ってて、
逆に自分はそうだから、OSSのコントリビューションのタイプとしては、有名なOSSにガンガン積極的にプールリークを送るみたいなことはあんまりしなくて、
仕事で必要になったやつとかだけだったりするんですけど、そういう人とはちょっと違うかなと思うのが、自分に判断の権限が全部あるっていうのがあって、
何を取り込むか、この一周に対してどう答えるかとか、レビューをいつまでにするかとか、何でもいいんですけど、そういうメンテナンスに関わるあらゆることが全部基本的には自分で判断しないといけないっていう、
それが毎日GitHubからメールが届く日々なんですけど、本当に朝起きると必ず何かしらのリポジトリから、一周でもプールリクエストでもいいんですけどメールが来てて、
それを見て、これは放置するとか、これは対応してあげるとか、色々考えながらやることが多くて、どうしてもやっぱり最近子供が生まれたっていうのもあって、
忙しくて、以前ほど、独身だったときほどやっぱりOSSに使う時間が多くなくなってきて、そのメールを見て、このプロジェクトに対して一周が来てるけど、
今はこのプロジェクト自分としてはやってないから、仕事でも使ってないし、ちょっと放置しちゃおうかなみたいなのが結構多くなってきて、
そうなると、ちょっと自分としても気持ちはありがたいんですけど、答えられないっていうのがちょっとずつ心の中に積み上がっていって、
負担ではないですけど、申し訳ない気持ちっていうのが結構あるっていう、そういうのも結構珍しいタイプの開発者かなと思ってます。
GoModRankの紹介
で、いろんな、逆に自分が積極的に開発してるやつが採用されることになって、ありがたいっていう思うこともたくさんあって、それはもう本当にトレードオフではあるんですけど、
ただちょっと課題感というか、ずっとやってきて、もうちょっとどうにかならないのかなと思ってるのは、
オープンソースの評価する指標って、今のところGitHubのスターの数ぐらいしかなくて、
皆さん多分、何か、Go、Space、やめるでもいいんですけど、検索して一番上に来るキスタースの多いライブラリをまず使いたくなるみたいな。
ただでも、本質的には、スタースでは重要なソフトウェアが何なのか、自分にとって何なのかっていうのが見えてこないと思ってて、
今のずっとやめるの話もしてたのもそうですけど、やっぱりGoogleで検索しただけだとわかんないみたいなところがあるかなとは思ってます。
実際、オープンソースってものにはソフトウェアなんで絶対依存関係が基本的にあって、
AっていうソフトウェアがBに依存してるんだったら、基本的にはAよりも大事なのはBだよねって思うわけですよ。
多分、この話をしたら100人が100人、ちゃんとBの方が大切だって思ってくれると思うんですよね。
BがなければAっていうものは存在しないので、それはそうだと思うんですけど、ただ、GitHubのスターをつける人たちっていうのは、
検索キーワードにもよりますけど、欲しいソフトウェアを検索して、それでヒットした結果に対してスターを付与するっていうのがほとんどだと思うんで、
基本的には一番フロントに来ている、自分の要望に一番層、一番手前にあるソフトウェアとして、
ソフトウェアツリーの一番手前にあるソフトウェアに対してスターを付与する機会が多いかなと思ってて、
わかりやすいのがフロントエンド系のUIライブラリとかがまさにそうだと思うんですけど、
自分の欲しい見た目を提供してくれるライブラリにスターをつけるけど、
そのライブラリが裏で使っている、重要ないいくつかのライブラリには別に関心を寄せないと。
そういうことが結構多くて、GitHubスターではこの課題を解決することができないんで、
どうにかできないかなと思ったので作ったのが、最近一番最新で公開したOSSがGo-ModRankっていうソフトウェアがあるんですけど、
これは今までは課題の中で、とりあえずGoに絞って、Goの依存関係みたいなものをGo-Modから一応算出することができるので、
その依存関係のうち、依存されてる方、ソフトウェアがどんどん重要度という内部的なスコアみたいなものを付与してて、
そのスコアがどんどん高くなっていくようにして、いろんなライブラリからめちゃくちゃ依存されてるライブラリが一番重要っていうような指標になるような形のランキング付けをしてくれるっていうソフトウェアなんですけど、
これをまさに今、会社では自分たちのオーガナイゼーションで使ってる全部のリポジトリを調べて、そのリポジトリにあるGo-Modを全部このソフトウェアで集計対象にして調べて、
そのオーガニゼーション全部の中で一番重要なソフトウェアっていうのが何なのかっていうのをランキング形式で網羅して出すような仕組みを作りました。
これで自分たちの会社でどのOSSが一番大事なのかみたいなのが一目でわかるようになったのがいいかなと思ってて、
自分たちの会社だけじゃなくて、今後他とかでも自分のソフトウェアを使う使わないが別として、こういう指標でソフトウェアが評価されるようになっていろんな重要なソフトウェアを使っているエコシステムを使っている人たちが日の目を見るというか、
ちゃんとした評価をされるようになってエコシステム自体がうまく回っていくといいなというふうに思ってたりします。
OSSの依存関係の重要性
なるほど。ありがとうございます。このGoModRankってやつがそのソフトウェアですね。そうですよね。そういう日の目を見るっていう表現がまさしくその通りだなっていうふうに思っていて、
多分多くの開発者とかが直接は使ってないけど推移的にめちゃくちゃ使ってるライブラリーみたいなのはあって、
そういうのをちゃんとなんというか日の目が当たるようにすることとかはすごい大事なことだよなっていうのは思いますね。
ただなんか結構、そういうプリミティブなライブラリーともっとそういうのを組み合わせて作ったアプリケーション、どっちにも価値があるんじゃないかなとは僕は思う部分もあって、
すごい小粒で誰でも使っているソフトウェアみたいなのも超大事だし、それも含めて結構でかいライブラリーみたいなのもそれはそれですごく大事だとは思うから、
ただ、だからそうKubernetesとかそういうのもそうだけど、ただちっちゃいライブラリーでみんな使ってるけどあんまり知られてないものがたくさんあるみたいなのはわかります。
それこそJSONとかYAMLとか多分みんな直接使うこともあるから多分スターもたくさん付くと思うんですけど、
多分そのアンジカラーのライブラリーとかそういうのみんな使ってるけど多分なんかどういうものが使われてるのかあんまり知らないとか、なんかそういうのはたくさんありそうですよね。
そうですね。今大室さんがおっしゃってたアップに近いものの方を内側ショーンしてるっていうのは自分もそういう意図ではなくて、
そっちも大事だと思うんですけど、比較して正当な評価を受けやすいと思うんですよね。やっぱりスターがそっちが足りなくて需要に対して悲しい思いをしてるかっていうと、
その小粒のライブラリーに対してはそんなことはないだろうなっていう感覚は自分の中にあって、そっちを救ってあげたいっていうようなモチベーションですかね。
まあそういうのありますよね。
よく積み木みたいな図があって、一番崩れやすそうなところが一番大事みたいな、あるじゃないですか。
だから、まだやってないですけど、このモードランクみたいな仕組みの中で、このソフトウェアがどういう人にメンテナンスされてるか、何人によってメンテナンスされてるかみたいなものを同時に計測して可視化してやれば、
自分たちにとってのこの積み木の一番まずい、危ういポイントが何かっていうのも見えてくるかもしれなくて、そういうのは結構面白いかなとは思います。
それはありますね。どれぐらいアクティブかとか。それこそ今回やっぱりヤムルがアーカイブされたのもそういう象徴的な出来事で、
スターはたくさんついてたけど、やっぱりあんまり手数が足りないからアーカイブせざるを得なくなったみたいなところとか、
Unix、Linuxの世界でもそういうのはよくありますもんね。OpenSSLとか、すごい主要なソフトウェアがめちゃくちゃ少人数で頑張りすぎてるみたいなのがあるから、
ちゃんとそういう正当に評価されたりとか、正当にリソースが投資されるべきところを見えるようにするっていうのは大事な話ですね。
なるほど。そうですよね。でも、ゴッシーさんがやってるようなものってすごく複雑なものを扱ってるみたいなところが多いから、余計難しいですよね。
それこそ、YAMLとかの複雑な話は前半でもしたし、JSONとかもそうだし、ビッグクエリーエミュレーターとか、どこから終わりのない開発を続けるものみたいなのがあるから、何を言うねんってやるな。
案外完結してそうで完結してないものじゃないですか。割とちっちゃい小粒なライブラリーだったら、もうある程度一回バーンと作って、あとはメンテナンスすればいいみたいな感じだけど、ゴッシーさんが作られてるものって実はそういう仕様が明確なものかと思いきや、実は終わりのないものだったりするっていうのが大変そうだなっていうのを思いました。
いや、本当にそうですね。その中で言うと比較的JSONってものは、仕様はシンプルなんですけど、自分があまりにも複雑な実装を選択しすぎたせいで、メンテナンスが大変になってますね。
そう、JSONはね、やっぱりその仕様が明確なのはいいとこですよね。みんないろいろ言うけど、そのケツかんまがないことも、そのクオートが厳密なのも、コメントがないのも、実はそういうパーザビリティにすごく一役かかっているっていうのはありますね。YAMLの地獄みたいなのを見ると。
はい、まさに。
なんかそう、GitHubから毎日メールが届くみたいなの、僕も多少そのレベルは違うとはいえ、結構来るんですけど、その辺ってどういうふうに管理してるんですか?メール見てるんですか?それとも、ノーティフィケーションをちゃんとメンテナンスしてるのかとか、その辺ってどうされてるんですか?
自分はメールですね。もうメールを見る習慣があるんで、そのGitHubから来てたら、そのメール上で一応その内容を読んだりとかして、プルリクエストは、そうですね、例えば今だったら、GoYAMLに対する一周とかプルリクエストだったら、しっかり読んで、読むぐらいなんですけど、
まあ返信するとかまであんまりいかないですけど、ここまでやって、ビッグクエリエミュレーターに関する一周とかだったら、なるほどって思って閉じちゃうみたいなのが多いですね。で、基本的にはまあその脳内スタックというか、まあそういうところに積まれてって、で、思い出した時にやってるっていうのが現状ですかね。
なるほど、そういう感じでやってるのか。まあ僕も結構近い感じなんですけど、僕もなんか意がついた時にやるみたいな感じで、あとまあたまに一周とかを検索したり見たりして、なんか気づいてないやつを見たりとか、そういうのはあるんですけど、まあやっぱりやっぱメールとかでやってて、
あとまあその、まあなんか反応ないと結構プッシュしてくれる人も多いから、てかむしろOSSってプッシュした方がいいと思うんですけど、そのなんか反応ないときって多分、プッシュの仕方にもよるけど、まあプッシュしてもらって構わないじゃないですか。なんか普通に見落としてることがめっちゃ多いから。
で、ちゃんとプッシュが来たら気づいた時に反応して、ああ確かにこれは必要そうみたいな、そういう感じで反応するみたいな感じでやってますね。
わかります。プッシュ大事ですよね。
OSSのメンテナンスの現状
うん、うん、そう。まあでも結構、昔そのJasperとか使ったりとかもしてたし、けど実はGitHubの公式のノーティフィケーションズをメンテナンスしたら結構いいんじゃないかっていう気持ちに最近なったんだけど、あんまりこう散らかったままになってるっていう感じです。
うん、違いますね。
まあだからなんかこんな、なんかたくさんリポジトリ管理したりしててる人みたいな人があんまり、てかまあそれなりにいるけど、でも全体からの割合からするとレアケースだから、なんかそういう人に対するこう、なんていうか、最適な体験みたいなのをどうするかみたいなのをみんな迷ってる感じがしますね。
なんか、Aquaの作者の方とかは、鈴木さん?あれ、同僚?元同僚でしたっけ?
そうですね。
うんうん。なんかすごい結構丁寧にやられてるみたいなのどっかで見た気がする。
確かに。そうですね。まあ自分はあんまり、会社にいるとき、彼はメルカリ側にいらっしゃってて、そんなにお話する機会があったわけではないんですけど、すごいOSSに対して丁寧に活動されてるなっていうので、すごい尊敬してますね。
で、実際そのソフトウェアもどんどんどんどん育ってるのを見てるし、Aquaに関してはどんどん採用、事例も増えてって、はい。すごい。
すごい、すごいですよね。Aquaなんか、僕のツールとかもすごい取り込んでくれてるんだけど、いいのかなみたいに思うこともあるんだよな。いいのかなって。
いいじゃないですか。それはもう最初に取り込むべきでしょ。
結構僕のマイナーなやつとかも取り込んでくれてるので、まあありがたいっちゃありがたいんですけどっていうのはあります。
ですね。
まあでも、なんかちゃんとこのOSSによって自分たちが支えられてるのがわかるようにする、どういうOSSに支えられてるのかわかるようにするっていうのは面白い試みだし、
なんかその、スター数が少ない割にはすごい依存してたみたいなもののギャップのランキングみたいなのがあっても面白そうだなっていうのを思いました。
貢献を可視化する取り組み
いやあ、そうですよね。自分もそういう方が見たいなと思ってて。
でまあ、こういうのをやったその、もう一つのモチベーションとしてその、なんだろう、会社で作ってるOSSっていうのがあるわけなんですけど、
まあそれをそのすごい少人数で開発してて、まあ自分がリードしているものも含めて、まあその大きなソフトウェアなのに
その会社の有志の人がボランティアで開発しているみたいな体制とか、一応そのメンテナンスオーナーチームはいつつも
そのソフトウェアに対してコントリビュートする時間がそんなにない、忙しくてないっていうような課題が結構会社的にもあって
で、まあその余剰リソース、まあ余剰ではないかもしれないですけど、その会社の他の人たちがまあその自分たちの会社でホストしているOSSにもっと積極的にコントリビューションしたくなるきっかけってなんだろうっていうふうに思ってて
で、このゴーモドランクっていうのでその重要なOSSっていうもののリストが、まあ会社にとって重要なものがそのランキングされた後に
まあその個人の日々のGitHub上のプルリクエストとかのトラックっていうのも同時に行って
で、そのAさんがその有名なこのOSSに実はプルリクエスト出してくれてて、マージされてましたみたいになったら
そのリポジトリに割り当てられているスコアをその人に付与するみたいな形で、その特定の期間で誰がどこにコントリビュートしたかっていうのを全部その
スコアにマップして計上していけば、その個人の貢献具合っていうのを定量的に評価できるなと思ってて
それを自分がオーナーシップを持ってないソフトウェアに対して積極的にやってるっていうのはまさにそのエコシステムに対する
ボランティアというかその貢献精神であるとすると、そのオーナーしてる、自分がそのオーナーになっているリポジトリそのスコアの中から引いてあげれば
本当にその関係ないものに対して自主的にやってた貢献具合っていうのが可視化されるんで
それを反旗とか旧ごととかひと月ごととかに個人を称賛するような制度に使えないかなっていうので
今そういう仕組みもちょうど作ってるところではあるんですけど、そういうのでどんどんどんどんオープンソースの開発がいい感じにドライブしていけばいいなと個人的には思ってます
OSSの開発環境の課題
それはめっちゃいいですね。あとそれこそなんか僕ら普段の開発とかそのツールチェーンとかそういったものに対してもコントリビュートすることあると思うんですけど
なんか最近Go、多分そのツール周りもGoモードに入れられるようになったから、結構そういうのをやっぱ積極的に会社のリポジトリでも入れていくようにすると
なんかそういうなんていうか社員の貢献状況みたいなのをより可視化できるようになるのかなっていうのを今思いました
まさにそういうこと考えてます
まあでもなんかねこういうのスコアリングするの難しいんだよなぁ難しいというかなんかその
まあでもなんかやってみるのはすごく良いかな面白いなって思います
いやなんかたまにすごいコントリビュートしやすいリポジトリみたいなのが実はいくつかあって
なんかまあまあまあそれはいいんですけど
いやなんか例えばホームブリューコアとかって、ホームブリューとかって実はなんかめちゃくちゃ貢献しやすいんですよねっていうのがあるんですよ
なんかご存知ですか
え、あの、わかんないかもです
ホームブリューってそのライブラリとかなんかツールのバージョンアップすると
バージョンアップした時ってあれって多分まだそのプルリクエストを誰かがプルリクエストを送ってマージされることによってバージョンが上がるんですよ
なので例えばGoとかがそのマイナーバージョンパッチバージョンが上がった時もそういうプルリクエストがこう誰でも送ることができて結構早いもの勝ちみたいなのがあるんですけど
なんかそのそこすごい手動なんですよねなんかあとホームブリューに取り組まれてる結構マイナーなツールのバージョンアップを素早く察知して
プルリクエストを送るとなんかこうコントリビュートできるみたいなのがあるんですよね
いやでもそれすごいありがたい話でそのOSS作者としてはありがたい話なので
その僕がメンテナンスしてるGHQとかそういったのも僕がバージョンアップすると誰かがホームブリューの方にプルリクエスト上げてくれて結構すぐ上げてくれて
ホームブリューの方のバージョンも上がってるみたいになってるので
まあその何だろうあんまりそういうスコア稼ぎみたいなのじゃなくて善意で成り立ってる話だと思うんですけど
まあなんかそういうなんかこう貢献しやすい大きいリポジトリもあるみたいなそういうお話でした
そうですねなんかまあハックできちゃうみたいな感じだと良くないんで
まあそこはそうですねやって結果を見つつちょっと調整していこうかなと思ってます
まあそういう過程もなんか面白そうですよね誰もまだここに対する答えを持ってないと思うんで
それがわかるだけでも面白いかなと思ってます
そうっすよねまあそういうなかなかまあでも社内でやる分にはすごくちゃんと明確なのかなっていうのは思いました
その会社の中でやっぱすごい大事なライブラリーとかそういったものもあると思うし
まあ何ならちゃんと必要だったらメンテナンスをね引き取るだったりとかなんか
まああのスポンサーするとかそういったのこともやれればいいと思うので
なんかルーカリさんとかそういうなんかOSSにGitHubスポンサーするみたいなことってされてましたっけされてたような
まあやってますねやってるんですけどでも本当にごく一部というのはありますね
なのでなんかそういうのの選定材料にもなるとめっちゃいいですね今回の取り組みが
まあでもそうっすよね
いやー書かれてる他の話としてはそうOSSのメンテナンスは基本的には自分が使わない機能に関しての話題が80%くらい
って書いてますけどいやーこれはね難しい問題ですよねでも僕はそうならないようにしてるんですけど
たぶんゴッシーさんはもうそうならざるを得ないようなものを開発してるっていう認識でいます
そうなのかもしれないですねだからもう自分で使う分にはもう一切困らないんですけど
あのまあ困ってる人が世界にたくさんいてまああれをしてくれこれをしてくれっていうわけなんですけど
まあだからバグとか全然いいんですよねその単純に自分の実装不備なんでそれを直すことには
一切迷いはないんですけど機能追加ですよねこの機能自分は使わないけどみんなのためになるかどうか
自分がこれを追加した後メンテナンスを続けられるかどうかっていうのを考えて入れる入れない決めないといけないんで
そこに脳のリソースを使うこと自体がオックになることもあるし まあ難しいところですねかなり
まあそれも決断ですしねまずそういうやるかやらないかって決断もしないといけないし やらない時は脳を言うみたいなのも必要だから
それも結構負担ですよね でもまあOSSやっぱちゃんとこう
なんか やらないことを
決めるの大事だけどとはいえなんか確かに必要そうだしなぁみたいな の思うこともあるし
まあでも結局あんまそうメンテナンスしたくないから 入れないっていうのはそれはそれで大事だと思うんですよね大事だしなんかちゃんと
その要望する方もなんかそこ踏まえて考えてほしいっていうのはありますよね
確かにでそういえばそのやってと思うのが なんかこういうオプションを足してほしいっていう要望があるんですけど
でもそのオプションって既存の機能のこの組み合わせで実現できたりとか この既存の機能にこういう実装を追加で自分ですれば同じことになるよっていうのを
まあ自分だったらすぐ分かってでそれをこう一周で教えてあげる時があるんですけど それが似たような質問がまた来たりとかすると
あーこれってそのなんだろう その既存の実装でも表現できるものだけどその機能
オプションという機能として切り出した方が本当は良かったのかもしれない まあもしくはそのエグザンプルとして
こういうことをしたい時はこうしろっていうのはそのFFQじゃないですけどそういう 動線があれば良かったのかもしれないっていう思う時があって
ただでもまあその動線を用意するのもコストなんで その毎回その何が正解なのかなって思ったりはしますね
そうそうですよねそれはあるし あんまりそう
太らせたくないなっていうのはありますよね そうですね
なんかそう結構例えばそのまあ設定ファイルとか多分 そういうところでいろいろ多分意見もらうことはいろいろ僕もたまにあって
その まあなんか設定ファイルのフォーマット増やしてほしいみたいなこともあるんだけど
いやそれはやりませんみたいな話だったりとか あと.env的なものを読み込む機能をつけてほしいみたいな時に
いやそれは多分そのツールの責務ではないし そのツールが呼び出す前にちゃんと環境変数が一通りセットされた状態でツールが起動するっていう状態にしたいから
そこは別のライブラリの責務としてやってほしいみたいな そういうふうに僕は考えるんですけど
まあ結構人によってはちゃんとその利用 まあいろんなフォーマットサポートしてあげたりとか
まあなんか.envとか読めたほうが便利っていうふうに取り込んだりみたいな まあことをしている人もいるから結構それはそれぞれの考え方だなっていうのは思いますね
いやでもなんかゴッシーさんのプロダクトって やっぱりかなりそのゴッシーさんしか書けないコードみたいなところがベースになっているから
ゴッシーさんの思想みたいなものが結構出てるから まあ別にそのコード自体は読みやすいし プルリクエストとか全然送りやすいし僕も送ったことあるんですけど
まあなんかなかなかそういうこうソフトウェアをなんかチーム開発に持っていくみたいなのが難しそうだなっていうのとか
またゴッシーさん自体がそれを望んでいるかどうかみたいなのもあるのかなっていうのはちょっとこう
なんていうか思ったりしているところはあります。なんかそなったりってなんかその結構OSSってそういう結構リーダーシップ型のものだったり
あと結構そのガバナンス型みたいななんかそういうある程度ちゃんとチームでやるの動きになってるものに結構分かれてるなって思うんですけど
その辺なんかゴッシーさん的に考えられてることとかってあるんですか
そうですねもう完全にソームさんが今おっしゃってたような話 まさにだなっていうのがその自分のオーガナイゼーション
ゴッシーホストでやってるソフトウェアっていうのは基本的には自分の思想というかその
アートのようなプログラミング
豪商な言い方するとアートみたいな行動には自分のその成果物でありその自分の脳内にある
なんかそのこれがいいと思ったものをなるべくそのままこうアウトプットした成果物みたいなところがあって
自分はこういうの頭の中でこんなことを考えてるんだよっていうのを行動にして人に見てもらったり使ってもらったりって
すること自体が好きだっていうところが一番あるのでまあそれを大事にしてるんですよね
だから基本的に自分のそのホストでやってるやつはその複数人で開発していくとかメンテナンスしていくっていうのを
まあそういうコードにしようとかえっとそういうその設計思想実装にしようみたいなのはあんまり考えてないですね実際には
もちろんその作る上で読みやすさとかその何だろうっていうようなそういうその綺麗な設計とかそういうのはもちろん
大前提としてあるんですけどそことは別な観点でそういう思想で動いているっていうのはありますよね
だからGo.JSONとかもそのアンセーフな機能とかをガンガン使うけどそれでもこうやって頑張ってメンテナンスすれば
その最新のGoでもちゃんと動くしかつその早い実装にちゃんとなるよっていうそういう実装ができるっていうこととかをこう示したかったみたいなところもあって
でまあそれがこういうなんか複雑に見えるその実装で動いているっていうのを示すこと自体にもなんか面白さを感じたみたいなのはあるんですけど
一方でなんかその会社、例えばメルカリオーガナイゼーションに出しているGRBCフェデレーションというソフトウェアは自分がそのリードして作ったっていうのはありつつも
そっちはそのチームで開発することがもう決まっているものですし
自分がこの先退職してもそれをずっとメンテナンスし続けていかないといけないと思っているんで
それができるような品質だったり、なんでしょうね、コード上にあるそのコメント一つとってもそうですけど
そういうその読み手からしてわかりやすいコードとか、とはいえでも難しいコードだなと自分でも思っちゃうので
そういうところに関してはなんか別途そのドキュメントだったりとかチームに別にそのコードリーディングをする回を設けてなんか説明したりとか
そうやってこううまくそのコードを共有していくっていうのをやりつつ進めてますね
なるほど、じゃあやっぱどこに置くかによって結構スタンスも変わってくるみたいなのもあるっていうところですかね
まあでもわかります、そういうやっぱアート性があるみたいなところは僕やっぱすごいゴッシーさんの良さだと思っているし
GRPCフェデレーションの概要
そういうゴッシーさんにしか書けないコードみたいなのがあってあるみたいなところはやっぱすごくなんかその好ましく思ってるところですね
なのでなんか今打ち引けてよかったなーって思います、まあそれこそ多分あの
多分林家のモールドを作ってるルイさんとかもやっぱそういう感じで、なんかもうあの人しか書けないコードが逆に強みになってるみたいなのがあると思うから
やっぱなんかそういう人はいますよね、いるしまあでもそういうまあなんかそういうコードを書ける強力な
プログラマーであるゴッシーさんが、今は結構そういうメルカリの中で、ちゃんとチームとしてOSSをどう運用していくかみたいなのを今やられてるっていうのは
なるほど、なんかこう面白いなって思いました
ありがとうございます、そうですね
そのGRPCフェデレーションっていうのが最近結構メインの仕事だっていうふうに書かれてるんですけど、これはなんか今もお話しいただきましたが、なんかどういったことをやられてるんですか
そうですね、簡単に言うとGRPCのサーバーのレスポンスとかをアグリゲーションする、いわゆるBFFって呼ばれてるようなソフトウェアを自動で作って
そのBFFのメンテナンスコストっていうのを極限まで低くしようっていうような思想であると思うんですよ
代表的なものだと、グラフQLフェデレーションっていうものが出てて、アポロフェデレーションって実装ですかね
だからそのグラフQLサーバーっていうのが複数あった時に、それらを束ねてどうクライアントに対してレスポンスを返すかっていう層を別途自分たちで一から作るんじゃなくて
スキーマみたいなものにうまくこれとこれとこれに依存してるよみたいなのを表現すれば、自動でサーバーなりを作ってくれてホストしてくれると
なので、そのBFFっていう層をそんなに注力してメンテナンスしなくてもいいよっていうメンテコストの話がありますと
実際そのうちの会社でも巨大なBFFっていうのがあって、これは過去にもテックフェスみたいなところでも触れてるんですけど
メルペイAPIみたいなジェネリックな名前の巨大なBFFがあって、大量の後ろのマイクロサービスの結果をそいつがクライアントのレスポンスに整形して返してあげるということをしてたんですね
でもこのいろんなチームが、それぞれのマイクロサービスにオーナーシップがメンテナンスするチームが存在してて
ただそのメルペイAPIっていうものをメンテするチームっていうのは一つのチームしかないですと
で、みんないろんなチームの人がメルペイAPIに行動をコミットしてるけど、あとはすっと去っていって
なんかオブソースに似てますけどね、でそのメンテナンスするメインのチームの人たちが頑張ってそれを運用していくと
でもどんどんコードベースも巨大になっていくし、実際巨大なモノリスになってて、一チームでメンテナンスするの大変になってたと
で、これをどうやってそのメンテコストっていうのを下げていきつつ、そのメルペイAPIみたいなBFFの層をどんどん開発していけるかっていうふうに考えたときに
うちの会社ではこの巨大なモノリスを分割するという方向に舵を切ってて、それぞれのグラフQLフェデレーションみたいなアプローチももちろんあると思うんですけど
うちとしてはGRPCで開発してるし、同じようなアプローチは取れないと思って
それぞれのマイクロサービスのオーナーになったチームがメルペイAPIから切り出したBFFのメンテナンスもすると
メンテナンスできるぐらいの責務をBFFとしてメルペイAPIから何APIか切り出して、ここは自分たちのファンカスだからメンテナンスしていくと
そういう形でどんどんどんどんBFFを細かく切り離していって、それぞれで頑張るみたいなふうになったんですけど
そうなるといろんなチームでBFFを作らないといけなくて、そのコストって馬鹿にならないので
これが一から作り始めたら逆に開発の生産性みたいなのが長下がりしちゃうっていう課題感もあって
じゃあこれをどう作るかっていうところで考え出したのがこのGRPCフェデレーションっていうもので
そのプロトコル、うちはそのプロトコルバッファーに全部そのスキーマが存在してるんで、そのスキーマ上にこのサービスとこのサービスのこのメソッドを呼び出して
その結果をコアグリゲーションしてこのフィールドにその結果をバインドしますみたいなのをプロト上に書くことができて
そうするとそのプロト上の定義からプロトCでそのプラグインを加わせると
GoのGRPCサーバーを起動するための必要なコードが全部生成されると
なのでそのプロト上で最低限の記述をすれば
なんかそのGRPCサーバーを作るためのGoのあらゆるコードを書く作業がなくなるよみたいなのが売りのソフトウェアですね
なるほどなるほど それってその
こうGRPCサーバーを作る
マイクロサービス側も作れるしマイクロサービス側でうまくそういうアノテーションというか的な
スキーマ的なものをやっておけばBFF側も結構いい感じにそれを解釈してくれるみたいになってるっていう感じなんですか
それはですねどっちかというとソウムさんの今の思想はグラフQLフェデレーションの思想に近くて
わりかしその各グラフQLのサーバー側でこういうスキーマで定義しておけば強調動作してそのBFFがこう動けますよって感じなんですけど
自分のアプローチはどっちかというと中央集権的な感じでそれぞれのハイカーのマイクロサービスのプロットは今まで通りスキーに書くことができて
特にアノテーションとかも存在しませんと BFFとして新しく作るサービスのそのプロットの定義上に
そのプロットのアノテーションとしてAサービスのこのFooメソッドとBサービスのFaaメソッドを呼び出すというような技術をオプション上で表現する
でそれをどうアグリゲーションするかみたいなのもそのオプション上に全部書いていくんで
BFFの上に全てのそのBFFを作るBFFのプロット上にその構築するための全てのロジックというかその必要な定義が集まるっていうような構成ですね
なるほどねBFF側にちゃんと手を入れる形にはなってるけどそれをやりやすくしてるっていう感じなのか
そういうBFFに勝手にいろんな人がジョインしてくるってよりかはBFF側でちゃんとそういう定義を書いて参加させやすくするっていう感じになっているっていうことか
そっちのほうが現実的な感じはしますね だからこそちゃんと分割して分割統治できるように各チームでBFFを構築してもらうようにしたっていう感じか
そうですそうです GraphQL フェデレーションの場合は確かにそのBFFってものをそもそもメンテする必要がないっていうのが強力なメリットだったんですけど
自分のアプローチは結局それはBFFってものをどう作るかっていうのを書く必要は結局あって
それ自体はコストとしてあるんですけど うちの会社でとってのアプローチはそのプロット上に書いてもらったら
その後のサーバーをどう生成して あとはその生成した後の行動をまずどうやってバイナリにしてデプロイして
どういうふうに動かすかみたいなところは全部自分たちのチーム 自分が所属しているエンジニアリングプロダクティビティっていうチームがあるんですけど
そのチームが全部その責務を負ってるので なんかこうそれぞれのBFFの開発者っていう人たちは
新しいアーキテクチャの構築
最初のコース的にはそのプロット上でちょちょっと書けば あともうそのデプロイのいろんなものは全部こっちでやってあげるっていうような
ふうにその作業を切り分けて BFFの開発のコースをこうラックにしてるっていうのが
弊社のアプローチですね
なるほどね それってなんかBFFはじゃあ階層化されてるみたいな感じになってるんですか
実際にはメルペAPIって100あったAPIを10個ずつに例えば分割してるだけなんですけど
だけなのでその10個のAPIを面倒見てて その先にはそのゲートウェイがそのままいてっていう構成なので
多段になったりとかしないんですけど 構成上は別にでもそのBFFっていうものが多段になってもいいと思うので
そういうのも全然作れるとは思ってますね
なるほど 分割しただけで多段になってるわけではないっていうことか 今のところは なるほどね
で 今それって新しくインターフェースを速そうってなると じゃあBFFのほうから定義を書いて
それである程度目的な目的化そういうのができるから それから裏側のマイクロサービスを新たに作ったり
既存のものに手を加えたりみたいな感じでやるっていう感じになるんですか
そういう意味だと 今回そういう要件的には裏側のマイクロサービスというものは既にあって
で メルペAPIって今話した話だと 既にあるものを新しいアーキテクチャに乗せ替えていくっていうアプローチなんで
裏側にあるものは全部そのままで BFFの層だけ新しく切り出して作り直してやるっていう
クライアントも特に変えないし その配下のマイクロサービスも変えずに
そのBFFのレイヤーだけ変えるっていうような構成なので 新しくマイクロサービス作るとかは
裏側のマイクロサービス作るとかはないですかね
なるほど なるほど 今後はでも出てくる可能性はありますよね
ありますあります そういうメルペAPIっていう例だけじゃなくて
普通にサードパーティーの別なものと協力して 仮メルペのAPIを提供したいみたいな時ってあると思うんですよ
そういう時は全く新規にそのBFFっていうレイヤーを作ることになりますし 実際そういう例もあって
そういう時はもう1から作るし その後ろのマイクロサービスも1から作るっていうような構成になってて
ここでなんか面白いなと思ったのは そのプロト上にその後ろのサービスのスキーマとBFFのスキーマっていうのがあるわけなんですけど
BFFからその後ろのサービスのスキーマをこう使いますっていう時に
そのプルリクエスト上でGRPCフェデレーションのプロトのコンパイルが全部動く CIで動くようになるんですけど
OSSのアート性とプロトコルの比較
その定義されてないメソッドとかを呼び出そうとしたら ちゃんとそのプルリク上でエラーになってくれるんで
プロト上のサービス間のリファレンスとかが 全部プルリクエスト上で完全に解決されてコンパイルできる状態になるっていう
世界が作れるっていうのが結構面白いなっていうのは最近思ってます
それはめちゃくちゃいいことですね すごい当たり前のことでなんでできてないのかっていう感じはあるけど
それこそリモートプロシジャーコールっていう感じがしますよね
ちゃんとそれで普通に1個のコードベースだったら当たり前のようにコンパイル落ちたり
引数の型が合ってませんみたいになるところを ちゃんとそういうRPCでもそういうのがCIでわかるというのはすげえいいですね
なるほど なんかそうですね いろいろ面白そうなこと書いてくれてるけど
さっきグラフQLフェデレーションの話もあり 結構思想の違いアーキテクチャの違いみたいなのもあるというふうに
うかがったんですが そのあたりでグラフQLフェデレーションみたいなものと
どう差別化していくかみたいなところって考えてることってあるんですか
そうですね 差別化はそもそものアーキテクチャがだいぶ違うっていうのもあって難しいんですけど
結局グラフQLのフェデレーションのアプローチが分散型であるのに対して
自分たちのアプローチは中央集権になってて それをどっちが良しと取るかっていうところにも
判断の軸がありそうですよね 分散の方がアーキテクチャとしては美しい気もするんですけど
実際に運用するってなると 協調動作するためのあらゆる制約っていうものがそれぞれのサービス開発に生じていて
そういうのをどうやって制約というか 協調動作するための設定だったりなんだりっていうのを制御するのか
っていうのを同時に考えないといけないので 難しいなって思う反面
モノレポとリポジトリの管理もそうですけど モノレポの方とバラバラに管理するポリレポとどっちが良いかみたいな
議論にもなるかもしれないですけど モノレポとかモノリシックでやることの良さ
中央集権でやることの良さみたいなのもあって 自分たちはそっちのシンプルさというかわかりやすさみたいなのを
重視したいっていうのもありますね さっき言ったコンパイルで全部プロト上で必要な
モノがコンパイルできるっていうのは このGRPCフェデレーションならではの中央集権的なやり方の良さかなぁとも思いますし
あとそういえば最近あった面白い話で GraphQLのGoでGraphQL使う時にGQLgenっていうのをみんな使うと思うんですけど
このGQLgenのメインのメンテナーさんからダイレクトメールが来て ちょっと何だろうって思って話聞いてたら
彼自身はそのGraphQLの今後を意外と不安視していて そのGraphQLから個人的にはGRPCに乗り換えたいんだよねっていう話をしてたのでびっくりしました
で彼はその会社でもそのGraphQLフェデレーションとかを使ってて でそうするとだいぶそのGRPCにしていくっていうのが大変だから
なんとかこのGraphQLフェデレーションからGRPCフェデレーションに移行するための そのアプローチとかツールっていうのを一緒に考えられないかみたいなそういう話で
おーなるほどと思いましたね
この話自体はまだ今進展はないんですけど 面白いなと思ってます
グラフQLどうなんですかね でもなんかだいぶ定着した感はあるなぁと思ってるんですけど
勢い的にはなんかGRPCよりもグラフQLの方が最近採用率が高いイメージがあるんですけど
なんかどういったところが今不安要素としてあるんですかね
どうなんですかね まあその具体的な何がっていうのは聞かなかったんですけど
実際自分もそのグラフQLのサーバーを書いたりとかもしてて まあやっぱGRPCに比べてそのやらないといけないことが多くて難しいなっていうのはありますね
その単純にその簡単難しいかで言ったらGRPCよりもやっぱり難しくて
その型というか ここで言ってる型っていうかそのプログラミング言語の型ではなくて
どういうその型で表現するかとそのグラフQLサーバーを構築していくかみたいなのがなんかやっぱりGRPCよりも
カチッと決まってないというか難しさが個人的には感じるところが多くて
まあ何だろうよっぽどグラフQLが良いケースじゃなかったら自分は使わなくてもいいかなっていう気にはなりますね
なるほどそのなんか難しいサーバーが難しいっていうのはつまりそのミドルウェアとしてのサーバー実装を作るのが難しいみたいな話ですか
まあでも普通のそのバックエンド作る上でもそのどうリゾルブするかというかその
Nたす1をどう解決するかとかそのデータローダーの話とかもありましたけどああいうのをその自分たちなりにどういうデザインが一番
その開発効率も損なわずにできるかっていうのを考えてやっていかないといけなくて
でそういうそのデータローダー使うにしてもそのなんかコード内でこういうルールを設けましょうとかやっぱり
そのバックエンドのサーバー自体にそういうルールが必要だったりとかすることもあってまあちょっと
難しいなって思いますそのなんかちゃんと作ればもちろん良いものはできると思うんですけどちゃんと作るっていうコストが
まあ結構高いなっていう それはね思いますねそうまあ便利ではあるんですけどねし使われてるとこも増えては
きてると思うしフロントとかから見るとすごい柔軟でやりやすいと思うんですけど
まあ結局そのまあ独自の構文でこう クエリを投げてるみたいなところもあるからやっぱり結構複雑だし
パフォーマンスのオーバーヘッドが出やすい部分っていうのはすごくあるようなっていう のは思うところではありますねそういう意味でまぁ jrpc は
もう プロトバフだからすごいシンプルだしパフォーマンス的にもまあそんなにそこでボトルネック
になることは少ないみたいなのがあるんだなっていうのは思いますね
まあとはいえなんか僕は最近所属してきた会社もなんか jrpc に寄せてっている会社の方が jrpc じゃないや
graphql に寄せてっている会社の方が多いですね
なるほどそうなんですね アプリケーションとか使うとなると書くってかまあ複雑なフロントエンドアプリケーションとか
になってくると結構やっぱグラフql便利だなっていうのは思うところでは ありますかねー
それってそのグラフqlの サーバーって今言ったようなそのマイクロサービスみたいな形
まあぼこぼこいろんな種類のものが立ち上がってる感じですかそれともでっかい一つが できてるようなことが多いんですかね
でっかい一つがあるっていう感じですかね まあなんか bff が多分今関わってるヘンリーとかだとノードの bff があって
そいつが返してるみたいなのだけど一部最近はポトリンからも直接 グラフql を喋れるようにしようみたいな感じでやってはいるっていう感じではありますけど
なるほど まあでもなんかgrpc フェデレーションこれはなんかすごい頑張って
エコシステムを作ろうとしている感じなので楽しみだなって思いました はい
ありがとうございます 社外での採用事例が増えればいいんですけど
まあそこがもっと課題ですかね 確かにまあこれぐらいのものがね必要になる規模みたいなのもありそうな気はするから
まあ じゃあ
だいぶ話してるけど最後の話も軽く話しますか ちょっとクソ
プロトバフとwebアセンブリーとセル?セルね コモンエクスプレッションラングイージと仲良くなった
ああそうですね まあこのgrpc フェデレーションを通してまあこれらの要素技術をまあここ数年 1,2年ぐらいだいぶずっと使い倒してきてて
まあそれぞれ面白いんですけどここではじゃあ web アセンブリーの話をちょっとしようかなと思ってて
その web アセンブリーをプロダクションで使うみたいなものって実は自分は2017年ぐらいから結構やってはいたんですけど
その時はその c++で書いたものをそのエンスクリプテンっていうツールで web アセンブリーにして
でそっちをブラウザーで動かして でその c++ で作ったロジックを c 号経由で号をホストとして呼び出すみたいな
そういうアプローチでまあそのシングルソースを2種類のサーバーとクライアントを両方で 同じものを動かしてなんか
ゲーム作ってたんでそのバリデーションに使ったりとかまあそういうことをしてたんですけど
今回のGRPCフェデレーションというのは web アセンブリーをプラグインとして
GRPCフェデレーションの機能を拡張するためのアプローチとして採用していて
このプラグインのアプローチって自分もその昔から何がいいんだろうって考えながら色々試してきたんですけど
例えばまあ号本体にあるプラグインの機能 ビルドモードを配布
iCallプラグインみたいな機能でシェアドオブジェクトを作って読み込むみたいな
昔ながらのシンボルのローディングの仕組みとかなり似ている仕組みとか
あとはハシコープが作ってるプラグインの仕組みで サーバーが分かれている状態で
その共通の定義しているプロトコルでもってRPCしてプラグインとやり取りするみたいな
あって でも個人的には今回のwebアセンブリーでのプラグインというアプローチが一番いいなと思ってて
その前挙げた2つには個人的な問題点っていうのがあると気がしてて 最初の一つはやったことがある人ならわかると思うんですけど
かなりバギーだし その号の実装自体が結構バギーだし
そもそもシェアドオブジェクトっていう性質上 ターゲットのアーキテクチャー用にプラグインをビルドしないといけなくて
そのポータビリティが下がるという まあ
プラグインだけどそのなんだろう そのプラグインをちゃんとそのターゲットアーキテクチャー用にビルドしとかないと
プラグインできないみたいな そういう制約があるのもなんか微妙だし
号の思想的にはやっぱりシングルバイナリで動くっていうのが大事にしているのに そのシングルバイナリでせっかく
動くそのイメージに1個しかバイナリが入ってないのに そのシェアドオブジェクトを追加でビルドして入れ込まないといけないみたいな
そういう世界になるのがなんかうーんって思うところもありますし そのハッシュコープのアプローチはそういう意味だと
アーキテクチャーを制限してないって意味でいいですし それともそのプラグイン自体がサンドボックス的に別プロセスで動くので
そっちのパニックに引きずられてコストが落ちることもないし いろんな制約をかけられるって意味でいいアプローチではあると思うんですけど
そもそもそのプロセスが分かれてるっていうアプローチ自体がいいのかっていう疑問もあって 例えば今のそのコンテナモデルの話で言うと
基本的には今のコンテナでのアーキテクチャっていうのはPID1で動く そのシングルプロセスがその1個のコンテナの上で動くっていうのが前提となってるのけど
このプラグインアーキテクチャを採用する場合はもう一つのプロセスが同じコンテナ上で動くように作るか
もしくはそのそういうリナクションのドメインソケットとか使って通信するのを前提としなければ別なサイドカーとして
サイドカーコンテナでプラグイン用のコンテナを立ち上げてやり取りしないといけないみたいな
そうすると例えばKubernetesだったらサイドカー用のマニフェストを別にプラグイン用のものとして書かないといけないし
そういう要はプラグインってものを提供するために 提供側としては例えばKubernetesのマニフェストのサイドカーにこういう設定を入れてくれないと
動きませんみたいなことってあんまり美しくなくて これをやるためにこのアーキテクチャを採用しているあなたはこういう設定を入れないといけないですっていうのを
次々そのアーキテクチャを採用している数分だけ提供しないといけないっていうのは あんま美しくないと思ってるので
そういう意味でそのプロセスが分かれているっていうモデルもいまいちかなと思ってましたと
Webアセンブリーのアプローチ
そんな中でそのWasmっていうアプローチは そのどこでも動くっていうその
Wasmに1回してあげればどのホストでビルドしたものであっても どのターゲットアーキテクチャでもその
Wasmを動かせるバーチャルマシン そのランタイムが存在すれば動くっていうのがあって
幸いそのランタイムっていうのはGoの場合はPureGoで実装されているWaseroっていうものが存在しますと
なのでそのGoの場合はWaseroってものをそのホスト側に組み込んでやれば どんなウェブアセンブリもその同じそのプロセス上で動かすことができる
で かつまあエンベッド機能もうのエンベッド機能とかを使ってWasmをそのシングルバイナリーに埋め込んであげれば
別にWasmを別なアセットとしてコンテナにイメージに入れ込む必要もなくて シングルバイナリーを配布するというポータビリティも損なわないみたいなところがあって
Wasm自体が持っているそのサンドボックス機能も あるのでHashCorpが提供したプラグインのそのサンドボックス性みたいなものを同時に満たせるっていう
まあところがあるので基本的にはこのWasmを使ったアーキテクチャがやっぱりまあいいなと個人的に思ってますと
ちょっと長くなっちゃったんですけど で それでそのJRPG FederationではそのプラグインでそのWasmっていうのをサポートしてて
Goだとその1.21のバージョンからそのウェブアセンブリのその
WASI Webアセンブリシステムインターフェースっていうやつのプレビューワンっていうプロトコルがあるんですけど
そいつをそのサポートした実装が入ってて それを使うとそのWASIを使った
ブラウザとかを前提としてないPOSIX寄りのアプリケーションとかを
普通にGoのアプリケーションをそのウェブアセンブリにして使うことができるようになりましたと
なのでまあ1.21基本的には前提としていいのでそれを使ってプラグインを提供しているっていうのはこのJRPG Federationのアプローチになってまして
でまあそこでいろいろ問題が起こったんで どうこう解決したっていうのをいろいろ書いてここにそのメモに書いてるんですけど
まぁちょっと長くなっちゃったんでとりあえずここまでにしておきましょうかね そうっすねはい
いやそうじゃ結構ちゃんとWASM動くようになってるんだな なんか結構やっぱりそのメモリモデルの違いとか
GC周りが結構ネックだからかなりこう実用になるのが難しいみたいな話はなんか昔の感じだけど結構進化してるんだなっていうのを今聞いてて思ったのと
結構プラグインをね確かにゴーエンベッドで埋め込めるっていうのは熱い熱いですね 昔できなかったことだけど今そういうのができるからいいなーっていうのは思いました
コンファレンスの準備
でその辺の話は今度のコンファレンスで話せればいいなって書いてありますがプロポーザル出しましたか
まだです ちょうどは今日か明日か書こうかなと思っております そうっすねそう来週までですよねそうこの話をしている時点では僕も何か出せればいいなと思って自分の
to doにこうまだ残っていますまだ僕も書けていません まあでもこのたぶん話がリリースされる頃にはもうこのエピソードがリリースされる頃にはもう
締め切っちゃってると思うんですけど まあはい
合間はですねはいまあでもまた何にせよお会いできるといいかなというふうに思いました はい本当ですねはい
よし後半が反応上長くなってしまったけどまあでもだいぶいろいろ話せてよかった はい
はいじゃあ今日はそんなところかな はいということで趣味でOSSをやっているものだは今回ゴシーさんをゲストに迎えていろいろお話をしました
ありがとうございました ありがとうございました
