バイセル Tech Blog

バイセル Tech Blogは株式会社BuySellTechnologiesのエンジニア達が知見・発見を共有する技術ブログです。

RubyKaigi 2019を聴講しました

テクノロジー開発部の村上です。弊社のメイン言語がRubyということで、RubyKaigiを最初の2日間初聴講して来ました。 これまで私はScalaやPython、Javaを書くことが多かったので、Rubyはあまり詳しくはないです。
詳しくない人なりの目線で、面白かった発表を報告致します。
結論を先に言うと、Ruby熱がそこまで高くなくても勉強になり、とても良かったです。

f:id:nmu0:20190422214651j:plain

The Year of Concurrency

ご存知まつもとゆきひろさんのキーノートです。Ruby3の目玉機能の話です。
その中でも、Static Analysisと、タイトルにもあるようにConcurrencyの話が中心でした。
Ruby3では、言語とは別のコンポーネントでStatic Analysisを実現させるようです。
基本的には型定義をrbiファイルという別ファイルに記し、推論で自動生成することも出来るという形になります。
推論で生成したものは間違いもありうるので手動で修正でき、その型定義ファイルを使って厳密にチェックを実施します。
型アノテーションはDRYではない(同じ理由でテストもあまり好きではない)ので避けたい、ということでこのやり方になったようです。
ただ、個人的にはScalaでType Annotationに慣れているのでそこまで避けるものなのかなという感想を抱きました。
(昨今だとIDEが基本的にやってくれますし)

Concurrencyについては、マルチコアとIOの2軸があります。
マルチコアはGuild、IOはAuto fiberという新機構が導入されます(名前は共に最終決定ではないようです)
Guildについてはshared nothingがキーポイントで、オブジェクト空間はGuild間で分離され、
immutableなもの以外は、deeply fronzen objectという新しい概念を満たす場合Guild間で受け渡し出来るようです。
聞いている印象としては、Goのgoroutineに近いのかなという印象を受けました。
Auto fiberはスレッドの代わりに近いようです。

全体的には他の言語で良い・好評なものを、取り入れていっているという感想です。
まつもとゆきひろさんも、生き残るためには前進していかなければとおっしゃっていました。
ただ、闇雲にではなく賢くというのがポイントだそうです。(互換性も含めて)

Pathfinder - Building a Container Platform in Ruby Ecosystem

GO-JEK というインドネシアのスタートアップ企業の方の発表で、UberのようなサービスやPaymentのサービスなど幅広くサービス展開しているようです。
Kubernetesなどの既存のものを使わずに自社でコンテナオーケストレーションシステムを開発したので、その紹介とその中でGoで実装している部分をmrubyに置き換えるという話でした。
そもそもKubernetesなどを使わない理由は、LXCを使いたいからで、LXCを使いたいのはChefのcookbookでこれまでVMを管理していてその資産を活かしたいからです。
そのケース自体が面白いなと思ったのと、mrubyという組み込み系向けの軽量rubyについて知らなかったので興味深かったです。
mrubyでも今回の用途に必要なライブラリは存在していて、Goよりバイナリのサイズは小さくなったそうです(検証しないと確かではないそうですが)。

A Type-level Ruby Interpreter for Testing and Understanding

Ruby 3の機能である、型定義ファイルを自動で作成するinterpreterの中身の話でした。
それだけ聞くと単純そうですが、値を渡さないので分岐ではどうするか、処理をどうなるべく減らすか、状態爆発をどう防ぐかなど、色々と難しい問題があります。
分岐についてはどの分岐も実行し、その結果を統合しています。
また、処理を減らすために結果をなるべく再利用し、違う型を渡している場合のみ新たすに試すようにしています。
そして状態爆発ですが、call stackを持たないことで対処していて、そのためreturn文ではどこの呼び出しに戻るのかわからないので全部に戻すようにして判断しています。
そうした内部を知ると、正確にするためには手で修正が必要だということや、実際に呼び出している部分が存在するようにテストが必要だという説明がとても良くわかりました。

A Bundle of Joy: Rewriting for Performance

Bundlerの代替であるGelの紹介です。キャッシュや依存性解消の別アルゴリズム(PubGrub)を使うことなどで、かなり高速化しているようです。
まだどのライブラリでも対応しているわけではないようですが、今まで通りGemfileを使えるので発展すればかなり有効そうという印象です。
Gelの紹介もそうですが、既存のプログラムにもかなり改善の余地がある(Bundlerのように有名なものでも)という主張が発表のメインポイントでした。

All bug-fixes are incompatibilities

Rubyのstable versionのmaintainerのnagachikaさんのキーノートです。
stable versionのmaintainerの仕事は、masterにマージされたコミットの内、bugfixに関するものをstable versionのブランチにcherry-pickすることです。
(RubyはSVNで管理されているのですが、Git用語に置き換えて書きました)
bugfixに関するものとだけきくと単純に思えますが、実は判断が難しいものも多いということを、失敗例を挙げて説明なさっていました。
ここでいう失敗とは、別のバグを生み出してしまうことで、例えばSyntax Errorを直したために別のSyntax Errorを引き起こしてしまったというものです。
その可能性があるために、パフォーマンス改善や、ずっと残っているつまりエッジケースであるバグ改修は取り込まないことが重要だとのことでした。
そしてユーザーに安定したものを提供することが目的なので、多くのユーザーが困っているものが優先されます。
運用方法には多少違いはあると思いますが、他の言語でも同様なやり方をしていると思うので、
stable versionのアップデートのイメージが明確になってよかったです。

Benchmarking your code, inside and out

ElasticでRuby用のクライアントを作成している方の発表でした。
Elastic Search自体とElastic SearchのRuby Clientのベンチマークの話です。
そもそもベンチマークには3種類あり、

  1. Application
  2. Macro
  3. Micro

今回の発表はMacroについてです。Macroは、ベンチマーク対象となるシステムを実際に使われるような環境で測定するベンチマークとなります。
Elastic Searchのベンチマークで行っている内容を、発表者がいかにClientのベンチマークに落とし込んだかというのが発表の主題です。
Seven Tips for Better Elasticsearch Benchmarks というElasticのブログに書かれている、7つのTipsを用いることが重要です。
この内容は、簡単にいうと実際の現場に近く(データセットやインフラなど)、かつ毎回出来る限り同じ状況でベンチマークすることが重要ということです。
そのためにClientのベンチマークでもJenkinsで毎回環境を立てて、データセットも用意し、Warm upなども設定ファイルに定義した回数だけ実行されるようにしているとのことでした。
Tips自体は言われると当たり前のように感じてしまいますが、それを実際に落とし込むのが非常に難しいと思うので 非常に参考になりました。

RubyKaigiの雰囲気

国際会議自体には多く参加したことがあるのですが、それらと比較しても"おもてなし"という言葉が相応しいような素晴らしい運営でした。
色々な案内がわかりやすく表示やアナウンスされていますし、日本語の発表も英語翻訳の表示や同時通訳機の貸出がなされていました。
また、お昼や飲み物が提供されていて、懇親会も商店街貸し切りというすごいものでした。
そしてスポンサーの方々の各ブースもかなり熱心に開催されていました。
国際会議では毎回異なる開催地で開催地の大学が中心に運営するので、状況が違うとはいえ、
2日間参加して会議自体が非常に楽しめました。

f:id:nmu0:20190422153440j:plain
お昼の屋台(無料)

f:id:nmu0:20190422131942j:plain
ノベルティ

また、会場である福岡国際会議場も良い施設で、海がすぐそばなので休憩時間に気分転換も出来ました。

f:id:nmu0:20190422153851j:plain
福岡国際会議場近くの海

まとめ

JITなどの言語の細かい部分の発表を避けてたのもあるのですが、 普段プログラミングをしている人なら問題なく理解できる発表が多かったです。
特に今年はRuby3リリースに向けた準備が進んでいる状況だったせいか、
大きな粒度の話が多く楽しめました。
ということで、普段少しRailsを触っているという程度の方にもオススメです。