ご招待ありがとうございました。

はい。初めてです。東京とかには寄らずにまっすぐ松江に来ました。

いいえ、松江だけです。日曜日に出雲に行く予定で、それからフランスに戻ります。

はい。私はジャン・ブッシエです。フランスに住んでいます。常駐スタッフエンジニアとして、Shopifyに勤めて9年になります。あらゆる仕事をしており、パフォーマンスや安定性などのSREもやりました。今は、RailsとRubyのインフラストラクチャ・チームで仕事をしています。そして、Railsのコアチームの一員であり、Rubyコミッターでもあります。あらゆるGemsをメンテナンスしていて、ブラックリストはありませんよ。

始めたのはかなり遅いです。というのも、私は全寮制の学校育ちのため、コンピューターへのアクセスは周りより遅かったです。コンピューターを持ったと思ったらインターネットがなかったとか…。高校で電子工学をやっていたこともあり、マイクロコントローラーのプログラミング・アセンブリをやり始めました。

そして、Intel8085のプログラミングを始めたんです。それは部品を半田づけするよりはずっとよく、こっちの方がずっと自分は好きだなと思い、その後コンピューター工学の学校に進学しました。

はい。大学です。そこで実際にプログラミングを学びました。とても気に入ったので、そのまま続けました。

いつRubyを使い始めたかということでしょうか。

私工学部には週2日行っていました。週3日はいろんな会社でインターンをしていました。当時は、ＰＨＰをやっていたのですが、ある時クラスメートから「Railsって知っている？」と言われ、調べたら、とても気に入りました。そこで、Railsのインターンシップを探したところ、2008年に見つけました。それ以来、他のものは使っていません。もう恋してしまったというか一貫していますね。私は一貫性が大好きなのです。いくつかの基本を理解すれば、すべてが理解できるようになっていて、そこから発展していったので、ただただ好きになりました。

しかし当時はオープンソースはあまりやっていませんでした。始めたのは、Shopifyに入ったときです。というのも、Shopifyはコードベースが膨大で、社内システムの一部をオープンソース化する機会が多く、改善点も見つける事ができるからです。

例えば、Bootsnapは、アプリケーションのサイズが大きすぎて、起動に時間が掛かる問題がありました。何ができるだろうかと考える機会があり、そのおかげでコミュニティーに貢献する機会がたくさん得られました。

ええそうです。Bootsnapは、私が以前作った「Bootscale」というgemを書き直したもので、ロードパスキャッシュを実現した最初のものした。私の同僚であるBurke Libbeyが、ある時点で書き直し、その後、私がBootsnapのメンテナンスを引き継ぎました。私が書いたのは正直不安定でした。

自然な流れだったかもしれませんね。

Shopifyでは常にRubyの更新が遅れていました。毎年クリスマスにあなたは私達に新しいRubyをくださいます。でも、そのプレゼントを開けずに半年も8ヶ月も放置しているような状態でした。だから、ちょっと腹が立ったんです。そこで、ruby-headのテストをたくさんするようになりました。Ruby-headに対するテストは、まずバグを発見して、上流に報告しさらに、言語の悪い使い方を修正するために行います。というのも、私たちは大規模なユーザーなので、自分の経験を提供することで、「こうすればうまくいくよ」「こうすればすごく助かるよ」「こうすれば多くのコードが壊れるよ」ということを伝えることが出来るのです。

そうですね。私が今力を入れているのは、私の最新のプロジェクトであるピッチフォークというRubyの新しいHTTPサーバーです。

「Rubyは遅い」とかいう話があるじゃないですが。でも、Rubyはみんなが考えてるよりずっと早いんです。ただ使い方が間違ってるんですね。というのも、pumaやsidekiqのようなスレッドを使うサーバーやジョブプロセッサーが多く使われるようになったんです。そして、Rubyコミュニティの常識は「すべてがIOだ。常にIOをやっている」というものでした。だから、GVLがあっても、5〜10スレッドを使えるし、その分スピードが出るんです。でも、みんなが思っているほど真実ではないと思います。本当にアプリケーション次第で、大きく変わりますが、多くのアプリケーションは50％のIOを行うかもしれません。それだと最大2スレッドしか作成されないし、50%のIOでスレッドが違うタイミングで実行してくれる保証もありません。そうすると片方のスレッドが待たされることになり、パフォーマンスを浪費することになります。そんなわけで、最近Ruby3.2に搭載される予定のGVL計測APIをRubyで実装してみました。これでスレッドがどれくらいの時間待機しているのか、例えば、実行中であってもGVLで待機しているのかを測定するためです。特に、New RelicやScoutのようなAPMサービスでは、これを表示することで、スレッドを使いすぎていると判断できるようにしたいんです。

二つ目に人々がスレッド使うのはメモリの使用量減らしたいからです。

以前はフォーキングサーバーを使っていました。

今、Unixには、Copy on Writeという魔法のようなものがあります。だから、フォークしても実際には２倍のメモリを使うことはなく、メモリを変更するまで共有されるのです。だから、私が夢中になっているのはRubyでCopy and Writeを十分に効率化し、プロセスを使ってもスレッドよりメモリが増えたり、ほとんど増えないようにすることです。プログラマーが「これで私のコードはすべてロードされた」といえるようにしたのです。だから、Rubyがメモリ領域への書き込みを少なくできるように、あらゆる最適化を行うことができるようになりました。そして、二つ目はPitchforkです。現在では、ワーカーをフォークしてリクエストの処理をしています。しかし、ワーカーに何度かリクエストを処理させた後、ローテーションから外し、再びフォークさせるとそれらのキャッシュはすべてウォームな状態になっています。そのため、次回からは書き込まれなくなります。だから基本的には、第一世代のワーカーでアプリワーケーションをあらかじめ温めてから、第二世代を作るわけですが、私はずっとプレウォームドを考えていて、いくつかテストしてみましたが、結果はかなり印象的でした。アプリケーションに依存するのでゴスペルみたいな数字は禁物ですが、メモリ使用量は半分くらいになります。

そういうこともいえるかもしれません。

２週間ほど前にリリースしました。Shopifyでプロダクションのテストを重ねていく予定です。でも、Ruby3.2のリリースが近づいてきたので、一旦停止することにしました。というのも、今は安定したリリースを実現するために、できるだけRubyのテストに全力を注いでいるんです。

そう、これも私たちが推し進めようとしていたことなんですが、あなたも会ったことがあるUfukを中心に、私たちには巨大なテストスイートを持つチャンスがあります。1週間前にもGCのバグでクラッシュが発生し、私たちがそれを検出し、GitHubもそれを検出しました。GitHubとはよく話をしていたため、ruby-headのテストも行うように説得しました。その結果、バグを発見することができるようになりました。また、数時間ごとにビルドのトリガーをかけているので、「このコミットに導入されたときに失敗した」ということも言えるようになりました。そのため、バグに気づき事前に修正することが非常に容易になりました。また、Rubyのコミュニティでは長い間、3.0.0などの.0リリースは基本的にベータ版やRC版として扱われてきました。コミュニティでは、「あぁ、アップグレードは.1や.2を待つことにしよう」というのが一般的だったんです。そして、あまり言いたくないのですが、3.1以降、多くのテストを行い、多くのバグを報告するようになったので、3.0までは、その通りだったと認めざるを得ません。ShopifyのRubyコミッターの多くは、11月に入ると未解決のバグがないことを確認し、ほかの何よりも先にそれを修正することが優先です。3.1.0では、それを実現することができたと思います。Shopifyだけでなく、Ruby-coreチームにもこの点を改善してほしいです。

えぇ、その通りです。Ufukがまとめた指標によると、Shopifyでの最新Rubyにアップグレードするまでの期間は、以前300日だったそうですが、3.1では7日でした。ただ、私が休暇を取っていたので休暇から戻ってからはアップグレートには、24時間かからずに済みました。そして、何の問題もありませんでした。

もう素晴らしいです。Shopifyで働き始めた時はモントリオールに住んでいました。

2016年にフランスに戻ることにしたのですが、とても気に入っています。静かなのは好きで、集中できる時間が持てるんです。オフィスでは、生産的な議論もできますが、リモートでは時間がたつのを忘れてしまうぐらい集中できます。

はい。

はい。もう2階に上がるだけ。通勤時間は数秒です（笑）

まだわかりません。ただCopy on Writeについてはまだまだしなければならないことがたくさんあるので、少なくともあと1年はこれにおそらくかかるでしょうね。

もう一つ挑戦してみたいのはPythonのHPyプロジェクトのようなものです。彼らはC言語の拡張機能のために安定したABIを作成しています。というのも、ruby-headでテストを行う際に問題になるのは、NokogiriやGRPCといった非常に大きなネイティブ
gemがたくさんあることです。そして、それらは通常プリコンパイルされたバイナリで出荷されます。しかし、ruby-headのテストを行う場合、プリンパイルされたバイナリはすでにリリースされたバージョンのRubyにしか使えません。なぜなら、ABIが新しいRubyには導入されていないからです。そこで、HPｙのように、毎回再コンパイルするような非常にシンプルなＣ言語拡張を作り、ほかのＣ言語拡張と安定したABIを公開して、ruby-head用にコンパイル済みのバイナリを用意できるようにしたいです。また、プリコンパイルされた拡張機能に関するワークフローも簡素化されます。

問題は、私はそこまで賢くないということです。ABIが何なのか、まったくわかりません。だから、私の仕事の大部分は、実際に何かをするのではなく、私のチームで、賢い人たちを探すことです。

私はどうかわかりませんが、ありがとうございます(笑)

こちらこそお招きいただきありがとうございます。

来る時は22時間でした。帰りは35時間かかります（笑）

ありがとうございました。