Ruby Kaigi Takeout 2021 速報記事 Day1 午後

2021年9月9日公開 2021年9月10日更新

始めに

こんにちは、enzaプラットフォーム事業本部でSREチームのエンジニアをやっている橘田です。
こちらは、RubyKaigiTakeout2021 の1日目の午後の速報記事です。
1日目の午前の速報記事はこちらをご確認ください。

Optimizing Partial Backtraces in Ruby 3

Rubyで記載されたプログラムをデバッグするためのツールのBacktraces
Ruby3以前では、Backtracesの生成に関してコールスタックが深くなると生成コストが高くなるっという問題がありました。

その問題に関しては、Rubyのissueに上がっています。

この問題をいかにして解決して、そしてBacktracesの内部がどのように動作しているのかが説明されました。
Backtracesの開始ポイントからいかにしてトレースを行っていき、最適化していったか
そして最適化した内容が実際にはフレームが欠落してしまう問題があり、それをいかにして対応していったかをソースコードを交えつつ説明が行われました
ちなみに、Backtracesを直している際に出た問題のIssueはこちらのようですね。

このように深い部分への解析はなかなか行うものでもないので良い勉強へとなりました。

The Art of Execution Control for Ruby’s Debugger

Ruby 用の最速デバッガ debug.gem の紹介とその作り方に関しての解説でした。
debug.gem は、TracePoint という機能を使って実行を管理しているようです。

既存のデバッガもありましたが性能に課題があると感じており、デバッガ用にRuby自体にAPIを追加していたが、それを使い新規に debug.gem を作成したようです。
debug.gem は step実行ができ、さらに step実行中にRubyのコードをirbのように実行することができるようです。
またVSCodeとの連携も完備しているようで、使用している動画が流れました。
さらにリモートデバッグにも対応しており、別のコンソールのプログラムへの接続を待って接続してきてからデバッグを進めるなど機能が用意されています。
既存のデバッグツールでは、ブレイクポイントなどをつけると遅くなっていたが、debug.gem では何もしていなければ速度が変わらないようにすることを目的としていて、それが達成できているようです。
後半からはdebug.gemを作成するにあたってTracePointをいかにして使っていったかなど、とても良い参考になる話だったのではないでしょうか

Variable Width Allocation: Optimizing Ruby’s Memory Layout

Rubyのメモリモデルに関して、現状はすべてのオブジェクトが固定サイズのスロットに格納されていると想定してメモリを確保していますが、実際に動作させた場合にはデータは多くの場所に散らばっている可能性があり、キャッシュ効率を低下させるなどの問題が発生しえます。
Variable Width Allocation として、どのようにしてメモリのレイアウトを制御していくかのお話でした。

まずはRuby自体のメモリ構成に関して説明があり、見ながらRubyソースコード完全解説の内容を思い出していました。
続いてガーベージコレクションがどのように行われているかが説明されていきます。
この辺りはRubyKaigiらしい発表だったのではないかと試聴していました。
実際に今回説明されたメモリモデルはインストール時のオプションで有効化することができるようです。
ただしテストも十分ではないため本番環境などでは使わないようにっという説明がありました。

Parallel testing with Ractors: putting CPUs to work

Rectorを使用してのパラレルでのテストフレームワークが作れるか、そしてRector自体の紹介とどのように通信をしているかの話が行われました。

Rubyは3.0以前では並列実行をサポートしていなかったのでプロセスを立ち上げてやりとりをしていたが、Ruby3.0からはRactorが入ったので並列実行で動かせるようになった。
実際に作成されたものは Loupe というテストフレームワークでデモも実行されてRactors と Processes を使った場合の比較が行われていました
テストケースが少ない場合にはRuby のプロセスをフォークする必要がないため，Ractors の方が速くなるようです。
テストフレームワークがどのような流れで実行フローを流れていくかが整理されていて勉強になりました。

Story of Rucy – How to “compile” a BPF binary from Ruby

Berkeley Packet Filter(BPF)という特定のコンピューターのオペレーティングシステム上で特にネットワークトラフィックの解析に必要なプログラムですが、BPFのバイナリを用意するにはC言語を使う必要がある中、BPFバイナリをすべてRubyで作るプロダクトとしてのRucyに関しての説明とコンパイル方法に関する説明でした

Demystifying DSLs for better analysis and understanding

DSL(Domain Specific Language)はRubyではメタプログラミングを使って実現しているわけだけれども、初心者の頃には全く何が起きているかがわからない。
Rubyで言うとGemfile, Rakefile, RSpecなどで使用されていて、RailsなどはDSLの塊である。
そのようなDSLが氾濫している状態にてDSLにてソースコードを交えつつ上から順に流れの説明が行われました。

またDSLの変更に追従してRuby interfaceを書かなくても良いようにTapioca gemというものが作成されたようです。
上記に合わせてRailsでのRBSをジェネレートするためのライブラリである rbs_rails にも言及されました。
keynoteの型解析の話に合わせて、型注釈とかドキュメントを自動で出せる形の話があり、私が聞いたセッションでは初めから終わりが型の話でしめくられました