RubyConf2018参加レポート

Ruby カンファレンス 参加レポート

f:id:vasilyjp:20181117070815j:plain

こんにちは、サーバーサイドエンジニアの竹若です。11/13 ~ 11/15にかけてロサンゼルスで開催されたRubyConf2018にZOZOテクノロジーズから竹若・高木(@rllllho)・田島(@katsuyan121)の3人が参加しました。

今年のRubyConfは講演数60、参加者数840の大規模なカンファレンスでした。この記事では私たちが興味を持った講演をいくつか紹介させていただきます。

Opening Keynote

f:id:vasilyjp:20181117073616j:plain

Opening Keynoteは、Rubyのパパであり弊社ZOZOテクノロジーズの技術顧問でもあるMatzさんの発表です。 コミュニティの力や、Rubyのこれからについて話されていました。

プログラミング言語は人間によって作られたものであり、C言語はOSを書くためHaskellは教育のためなどそれぞれの言語が作られた背景には明確な目的や意図があります。 RubyはMatzさんのアイデアを表現するために開発されたそうです。 Matzさんが自分のために作り始めたRubyが世界中で使われるようにまでなった理由として、Rubyコミュニティの力があるそうです。

OSSコミュニティは人の集まりではなくバーチャルなようなものです。 コミュニティは例えるなら台風で、目には見えないがとても巨大なものであるとおっしゃられていました。 またRubyコミュニティは誰か個人のものではなく、Matzさん自身もコミュニティの一部に過ぎないとおっしゃられていました。

OSSコミュニティは知的好奇心、コミュニケーション、責任の3つが大事で、Rubyはこれらを持ったとてもよいコミュニティであるとおっしゃられていました。

"Ruby is dead" という意見を聞くことがあります。 ハイプ・サイクルをもとに考えるとRubyは『Trough of Disillusionment(幻滅期)』のフェーズに位置しており、今こそRubyへ新しい投資ができるフェーズで積極的にRubyを使って欲しいとおっしゃっていました。 近年開発されたSwiftやGoなどのプログラミング言語は会社が開発したものですが、Rubyはコミュニティによって開発されています。 これからRubyが生き続けるために、

  • Never give up
  • Keep moving
  • Community
  • Be nice
  • Be happy

であることが大事であるとお話しされていました。

Rubyのこれからの改善については、2018年12月にRuby2.6がリリースされ2020年にRuby3、2025年ごろにはRuby4の開発もありうるかもしれないとお話しされていました。

発表を聞き改めてコミュニティの大事さと自分もRubyコミュニティに貢献していきたいと思いました。 RubyConfはとても初めての参加者が多く、このような間口の広さもRubyコミュニティのいいところだと思います。 Matzさんが2025年には60歳になるとのことで、Rubyの言語デザインについてはどのように引き継がれていくのかについて気になりました。MatzさんのAI化も本当にありうるかもしれません。 これからのRubyも楽しみです。

Sweat the Small Stuff

Aaron Harpoleさんによる、組織をスケールさせる際によく見られるアンチパターンとその対処法を紹介する講演でした。

「チームが小さかった頃は全員がプロダクトを熟知していて、ミーティングもなく、デプロイとフィードバックのサイクルを小さく収めることができていた。しかしチームが大きくなるに従い既存のやり方が通用しなくなりチームの歯車がうまく回らなくなっていった」

といった事態に陥らないためのTIPSが紹介されていました。 具体的には以下のような内容でした。

  • エンジニアが生産性を高めるための投資を惜しまない（CIサービス、マシンのスペック）
  • トライ＆エラーがしやすい開発環境を用意してデプロイを安全にする
  • ミーティング前に各々が論点を紙にまとめておいてミーティングの最初に読み合う
  • エンジニアの採用ではまず最初にエンジニアが採用候補にコンタクトする

またチームの既存文化を変えることの難しさを説き、リクルーティングは文化を構築する最大のチャンスであると述べていました。 私が所属しているチームもまだ編成されて日が浅いのですが、今回のAaronさんの講演は今後チームをスケールさせていく上で気を配っておくべきポイントを明確化するのに役立つと思いました。

参考 : https://icanthascheezburger.com/wordpress/?page_id=222

Being Good: An Introduction to Robo- and Machine Ethics

Eric Weinsteinさんによる、技術者が持つべき倫理と人工知能が持つべき倫理に関する講演でした。

技術者が持つべき倫理のお話ではソフトウェアのバグが原因で複数の死者を出した放射線療法機器「セラック25」やシステムの脆弱性をハックされ巨額のお金が不正送金されたブロックチェインを使ったプロジェクト「The DAO」を引き合いに出しながら以下のことを述べていました。

  • 医療と同じで技術も技術者が標準治療を遵守しなければ人命を危険にさらしてしまうこと
  • システムの要件を満たすのに十分に強力であると同時に必要以上に強力ではない、必要最低限の力を持ったプログラムを書くことが必要であること

人工知能が持つべき倫理のお話ではFace IDや自動運転技術を例に出して以下のことを述べていました。

  • 人工知能に「決定」や「認識」などの人間的な行いをさせるということは暗黙的に人工知能の行動に倫理的な重みを持たせているということ
  • 人工知能の行動に対する説明とその責任を取ること

今後技術が発展し今まで人間のやってきた仕事が機械に置き換えられていくに従い、機械の保つべき倫理の水準などの議論が更に増すはずです。 技術者の関心は何かと技術そのものだけに集中してしまう傾向にあります。しかしそれにまつわる倫理や付随する責任を考慮して初めて世に役立つものが生まれると思います。 今回のEricさんの講演の内容には今後技術と倫理に関する議論をするために必ず認識しておかなければならない重要な事実が詰まっていると感じました。

Empowering Early-Career Developers

Mercedes Bernardさんによる、自身の経験に基づいた経験の浅いエンジニアをベテランエンジニアにまで育てるためのアプローチを紹介する講演でした。 Mercedesさんのチームでは経験の浅いエンジニアを育てるためにキャリアの早い段階で色々な裁量を与えているそうです。 経験の浅いエンジニアがいきなりベテランエンジニアの仕事を振られて困らないように早めに経験を積ませてあげることが重要であるとおっしゃっていました。

Mercedesさんはコンサルタントのチームを率いているそうで、具体的な内容はエンジニアに当てはまるものではありませんでした。しかし経験の浅いエンジニアをベテランエンジニアにするためのアプローチは、フレームワークとしては有用な気がします。 個人的にはメンバーそれぞれが優秀で頼りあうことのできるチームが理想です。チームの他のメンバーをレベルアップするアプローチを紹介する今回のMercedesさんの講演は非常に興味深かったです。

参考 : http://downloads.ctfassets.net/kueynwv98jit/2Dmircv1tmgoSAkc6UKggO/2120031f5d7f810ab6a13edae3642fe5/EmpowerEarlyCareerDevs.pdf

Ethical Data Collection for Regular Developers

Colin Flemingさんによる、自身の経験を基にした機密性の極めて高いデータを扱う際の倫理についての講演でした。 昨今の巨大テックカンパニーのデータの扱いをみて、データの扱いにもACM Code of Ethicsのようなベストプラクティスが必要になっているとのことでした。 ACM Code of Ethicsとはコンピューターのプロフェッショナルが倫理的な決断を下すのを助けるためのガイドラインです。 ColinさんはこのACM Code of Ethicsをシンプルに3つのポイントに要約していました。

  • Everyone is a stakeholder in computing
  • Avoid harm and protect privacy
  • avoid yolo-driven development

あくまで倫理に関する講演だったのでデータの収集、セキュリティなどの技術的なお話はありませんでした。 今回のColinさんの講演は中絶に関するデータという非常に機密性の高いデータを扱っているところに興味を惹かれたので、この講演を1日目で一番楽しみにしていました。 機密性の高いデータをクライアントから集める時にもう一度聞き返したくなるような内容でとても勉強になりました。

The Ruby Developer's Command Line Toolkit

Brad Uraniさんによる、生産性を上げるツールの数々を紹介する講演でした。

  • dotfiles
  • zsh
  • tmux
  • fzf

のような多くの開発者の支持を得ている便利ツールが中心に紹介されていました。 他にはhomesickやgit/hooksでcommitの前に何かを仕込むTIPSであったり、gemrcやrailsrcを使って開発を少し便利にするTIPSの紹介もありました。 またQ&Aでは質問者が便利だと思うツールが挙がったりして、moshなどのツールが紹介されていました。

中心的に紹介されていたツールはどれも素晴らしく便利なものばかりで、開発を始めたばかりの人なら誰にでも聞く価値のある講演でした。 私も開発を始めた頃にこれらの便利ツールを知っていたら生産性が上がって幸せになっていただろうなぁと思います。 もし今回のBradさんの講演で紹介されていたツールの中に試したことのないツールがあればぜひ試して見ることをお勧めします。 使ったことのないツールが自分の作業効率にどれだけ貢献してくれるかは使ってみなければわからないので、すぐに試してみるのがよいと思います。 私もhomesickやfzfを試してみたいと思います。

参考 : https://docs.google.com/presentation/d/18LyKvXRYZZA1RuPsZ4MvwKlufMhXDhWIM15LmK3oQ8A/edit#slide=id.p

Pointers for Eliminating Heaps of Memory

MRI、RailsのコアコミッターであるAaron Pattersonさんによる、Rubyのメモリ消費量を削減する2つのパッチを紹介する講演でした。 1つ目のパッチはrequireのメモリ消費量を削減するものでした。 このパッチを理解するのに前提知識として必要なのがShared Stringという概念です。 これはRubyの文字列オブジェクト（RString）が同じ文字列を共有することなのですが、1つ注意点があります。 それはRubyの文字列オブジェクト（RString）が参照する文字列が最後の文字まで等しくないと、同じ文字列が共有されないということです。 例えば/a/b/c.rbと/b/c.rbの文字列オブジェクトは/a/b/c.rbという文字列を共有しますがa/b/c.rbとa/b/cの文字列オブジェクトは文字列を共有せず、それぞれa/b/c.rbとa/b/cという別の文字列を参照します。 require '/a/b/c.rbとするとloaded_fatures_indexというハッシュに以下のような8つの文字列がキャッシュされます。

'/a/b/c.rb',
'/a/b/c',
'a/b/c.rb',
'a/b/c',
'b/c.rb',
'b/c',
'c.rb',
'c'

接尾辞に.rbとつく文字列オブジェクトは/a/b/c.rbという文字列を共有するのですが、接尾辞に.rbがない文字列オブジェクトはそれぞれ別の文字列（/a/b/c, a/b/c, b/c, c）を参照するようになっています。 今回そこで接尾辞に.rbとつかない文字列オブジェクトが全て/a/b/cという文字列を参照するようにすることで同じ文字列を共有できるようにしたそうです。 結果シンプルなRailsアプリケーションの起動時のメモリ消費量を4.2％削減することに成功したそうです。

2つ目のパッチはISeqオブジェクトから文字列を直接参照することでメモリ消費量を削減するものでした。 ISeqオブジェクトとは、Rubyのコードをコンパイルすると生成されるオブジェクトです。 そしてこのISeqオブジェクトの中にバイトコードが格納されます。 ここで登場するのがmark arrayというオブジェクトがGCに消されないようにオブジェクトをマークするのに使われる配列です。 今まではISeqオブジェクトはこのmark arrayを通してオブジェクトを参照していました。 そこでこのパッチでISeqオブジェクトから直接オブジェクトを参照するようにしたようです。 結果Railsプロセスのメモリ消費量を6％削減することに成功したそうです。

今回のAaronさんの講演はRubyの内部をわかりやすく紹介する内容にもなっていてとても面白かったです。 またAaronさんはハンバーガーの帽子をかぶって登場し、GithubがMicrosoftに買収されたことにかけたダジャレを連発したりしてとてもユーモアがあって素敵でした。

Parallel programming in Ruby 3 with Guild

Koichi SasadaさんによるGuildを使った並列処理の講演でした。 GuildとはRuby 3で導入予定の新しい並列処理です。 1つのGuildは1つ以上のスレッドを含み以下のような構成になっているそうです。

  • 異なるGuildに入っているスレッドは並列処理できる
  • 同じGuildに入っているスレッドは並列処理できない

またGuild間では共有できるオブジェクトが決まっており、Guildを使うことでスレッドセーフな処理を簡単に書くことができるとのことでした。 Guild間で共有できるオブジェクトには以下が挙げられていました。

  • イミュータブルなオブジェクト（fronzeしたオブジェクトはそのオブジェクトに含まれるオブジェクトもすべてfrozenされている必要がある）
  • Class/Moduleオブジェクト
  • Isolated Proc

また、共有できるオブジェクトについては特別なプロトコルを設けたいとも話していました。 案としては紹介されていたものは、GuildからGuildへのオブジェクトの受け渡しです。 Guildから他のGuildへオブジェクトを渡し、元のGuild内からは渡したオブジェクトが参照できなくなると言ったアクターモデル。 または、Goのchannelのような特別なオブジェクトを利用したCSPモデルが案として紹介されていました。

またこのGuildという名前はまだ決定しておらず code name だそうです。 デモではフィボナッチ数列を40vCPUの上で40個のGuildを使って並列処理した結果とシリアル処理した結果の比較を見ることができました。 n = 30の時点で実行時間に約16.2倍の差が出ていました。

今回のSasadaさんの講演ではGuildの実装ステータスなどのお話もあり、Guildに関する色々な情報を知ることができてとても面白かったです。 Ruby 3でGuildを使った並列処理を書くのが楽しみで仕方がないです。

参考 : http://www.atdot.net/~ko1/activities/2018_rubyconf2018.pdf

Building Serverless Ruby Bots

NetflixのDamir SvrtanさんによるServerlessをRubyで実現するお話でした。 AWS Lambda上でRubyを動かす話が中心に行われました。 現在AWS LambdaはRubyに対応しておらず、直接RubyをLambda上で動かすことができません。 そこで、Traveling Ruby・mruby・jrubyの3つRuby処理系を利用しRubyをLambdaで実行可能にする方法が紹介されました。

Traveling Ruby、mrubyの場合はjsにコンパイルを行い、jrubyはjarにコンパイルしLambda上でRubyの実行を実現していました。

それぞれの処理系のコードサイズ、メモリ使用量、実行時間についての比較が行われていました。

処理系 コードサイズ メモリサイズ 処理時間 ウォームアップ後の処理時間
Traveling Ruby 6.7MB 25MB 3900ms 3300ms
mruby 945KB 40MB 3900ms 3300ms
jruby 23.2MB 150MB 25000ms 1200ms

やはりLambdaのコールドスタートの影響で、jvmの起動に時間がかかると示されました。 ただしウォームアップされた状態だとjrubyの処理時間がダントツで早くなったそうです。

AWS Lambda以外でのServerlessについてもお話され、IBMクラウドのサーバレスのシステムがRubyに対応していることが紹介されました。 また、Rubyに対応したServerlessフレームワークServerless/FaaStRubyが紹介されました。

AWSLambdaでRubyを利用するには、まだまだ必要であり早く公式対応をしないかなと思いました。 3つの処理系でのメトリクスの比較はウォームアップ後にjrubyでの実行が高速になることなど、Lambdaやjvmの特性に合わせて計測を行っており参考になるなと感じました。 また知らないクラウド技術やフレームワークが紹介されておりとても興味深かったです。

Runnning a Government Department on Ruby for over 13 Years

Jeremy Evans(@jeremyevans0)さんによるCalifornia State Auditorという政府組織のレガシーなシステムをRubyを利用してモダナイズしているというお話でした。 もともとのシステムはすごくレガシーな状態でRubyを利用してモダナイズしているそうです。 モダナイズにRubyを選んだ理由としては以下の4つ挙げていました。

  • 高速に開発が可能
  • 簡単にモダンなアプローチを採用できる
  • 容易に学習が可能
  • 楽しい

高速開発、並びにモダンなアプローチは様々なOSSを駆使することが可能で、Rubyには豊富なOSSライブラリが揃っています。 また、政府組織のシステムということもあって採用の問題があると語っていました。そのため、学習が容易であるRubyを利用することで、誰でも開発に参加できます。

また、スピーカーの方はRodaというルーティングライブラリ。SequelというDBライブラリを作成しており、California State Auditorのシステムで利用しています。 Railsを利用せずにCodaやSequleを開発している理由としては、モダナイズのプロジェクトを進めるにあたり、スタートは小さくシンプルにしたかったとのことでした。

利用している技術スタックがFreeBSD/PostgreSQL/nginx/Unicornと私達にとってすごく身近なものでした。 勝手な思い込みですが政府のシステムでRubyが使われているとは思っていなかったのですごく興味深かったです。

参考 : https://code.jeremyevans.net/presentations/rubyconf2018/index.html

It's Down! Simulating Incidents in Production

Kelsey PedersenさんによるStitch Fixで実際に行っているインシデント発生時のシミュレーションやカオスエンジニアリングについてのお話でした。 インシデント発生シミュレーションは9つのステージにそって行われます。Stich Fixではシミュレーションの当日をGameDayと呼んでいるそうです。

1.　Define simulation

まずはじめに、どのインシデントを対象にしたシミュレーションを行うのかを決定します。インシデントはデータベース障害・インスタンス障害・外部サービスの障害など様々な障害が原因で発生します。 発表ではサービス障害インシデントのシミュレーションを選択し、サービスが500エラーを返した場合についてシミュレーションされていました。

2.　Implementation

1で設定したインシデントが発生するように実装を行います。 今回のケースではHTTPクライアントライブラリのFaradayにシミュレーション用の実装をしていました。 まず、インシデントを発生させるためのユーザーを作成します。そして、対象ユーザーの場合のみFaradayが常に500を返すようにoverwriteしていました。

3.　Gather expectations

チーム内で、対象のインシデントがサービスにどのような影響が出るのか議論を行います。 実際に行なった議論では、動かなくなる部分は発生するがクリティカルな問題は発生しないという意見が7割であったそうです。

4.　Huddle as a team

テーム全員が集合します。インシデントを想定して各人がリモートでビデオチャットを利用し議論している様子が見られました。

5.　Talk through expectaion

インシデントに対してどのようなことが起こるのか議論し、洗い出しを行います。それを以下の2点の観点からまとめを行っていました。

  • bullet point list of expectations
  • list the set of instructions

6.　Run it!

以下のようなコマンドで、準備したインシデントを発生させます。

bundle exec rake gameday:start

そして、実際に何が起こるのかをサービスのページ・サービスのメトリクスを見て確認します。

最後に以下のコマンドで、GameDayを終了します。

bundle exec rake gameday:end

7.　Revisit expectation

事前に想定していたインシデントと比べ、実際におきたインシデントがどう違ったかを振り返ります。

8.　Write and edit runbooks

インシデントが起こった時にどのような対応を行ったかをゲーム実施前のドキュメントに追加します。

9.　Update dashboards

エラー監視ツールのダッシュボードなどにGameDayなどタグ付をし、エラーメトリクスがGameDayのものであることを判別できるようにします。

実際のインシデントに対してシミュレーションを行っておくことで、いざそのような状況が発生した場合に焦らず対応ができるようになるだろうなと思いました。 さらにインシデントが発生した場合に起こる問題を事前に対策できるなと考えました。 シミュレーションを行う環境を整えることは大変なことですが、安全で柔軟なシステム運用を行うにあたりとても大切なことであると実感しました。 弊社でもこの発表を参考にインシデントに対するシミュレーションを行なってみたいと思いました。

Yes, You Should Provide a Client Library For Your API

Daniel Azumaさんによる、APIのクライアントライブラリについての話でした。 Danielさんは、Google Cloud Platform(GCP)のRubyAPIクライアント開発者の方です。 Googleでは膨大な数のAPIとAPIのクライアントライブラリを提供しています。 それらをメンテナンスし続けるにあたり、APIクライアントライブラリを開発する際に気をつけるべき点についてお話しされていました。

具体的にはAPIクライアントライブラリ内で以下の4つのことを意識することが大事とのことでした。

  • 独自で処理をラップしたクラスなどを作らずRubyの記法をつかって開発を行う
  • エラーハンドリングを適切に行う
  • セキュリティを担保する
  • パフォーマンスを意識する

パフォーマンスを意識するという話の中で、ログの書き込み処理などについてはユーザーからのリクエストを同期的に処理せず、非同期にバルク処理を行うことでパフォーマンスを向上させていると話されておりとても参考になりました。

またOpenAPIのようなインタフェース記述言語を使用し、コードジェネレータを用いてAPI定義書からAPIクライアントライブラリのインタフェースを生成することを推奨されていました。 API定義書からコードジェネレータを用いることで、APIクライアントライブラリのインタフェース以外にも

  • リファレンスのドキュメント
  • サーバーのスケルトン
  • テスト

などを生成することもできるため、API開発と保守の双方の役に立つということでした。

この発表を聞き、REST APIの開発はSwaggerなどのAPI定義書からAPIのインタフェースやドキュメント、テストはコードジェネレータで生成するという開発の流れがよさそうだと思いました。

発表スライドがとてもわかりやすいので、興味のある方はぜひご参考ください。

弊社でも以前、SwaggerからAPIのシリアライザーを生成するgemを開発した記事を公開しているのでこちらも参考にしてください。

techblog.zozo.com

Unlearning: The Challenge of Change

RubyConfでは、女性の参加者・登壇者の多さがとても印象的でした。 カンファレンス自体とても初心者歓迎の空気を感じましたし、Rubyの話だけでなく開発手法やエンジニアとしての働き方などの話もあり女性の方も参加しやすいのかなと感じました。 また3日間の最初のKeynoteの登壇者が、Matzさん以外女性であったこともとても印象的でした。

3日目のKeynoteはJessie ShternshusさんのUnlearningについてのお話でした。 Unlearningとは今まで学んだ知識や自分が持っている価値観を意識的に捨て、新たに学び直すことを意味するそうです。 新しい知識やスキルを身につける際、既存の知識があると既存の知識や習慣に頼ってしまいがちです。 しかし未学習の場合は外部から様々な学習法を探し取り入れようとします。そのため組織やチームで、新しいことを身につけたり変化を起こそうとする時に、すでに知識を身につけていることが足枷になることがあります。 そのためunlearningnの重要性についてお話しされていました。

一度自分がもってしまった価値観を捨てることは難しいため、日常的に何をunlearningしたいのかを考え意識的に習慣や行動を変えることが必要とのことでした。 発表中にunlearningを体験するために、2人1組で相手が空中に書く数字を反対側からなぞるというペアワークを行なったり、自分がunlearningしたいものを書いて紙飛行機を飛ばしたりと体験が混ざった発表で楽しかったです。

まとめ

今回私にとって初めての海外カンファレンス参加でしたが、会場の雰囲気がとても暖かくオープンで世界中から集まったRubyist達と交流できた素晴らしい経験になりました。

ロサンゼルスは少し肌寒かったです。それなのに会場は冷房がかかっていて思わぬカルチャーショックでした。食べ物に関してはさすがアメリカの中でも特に人種的な多様性に富んだ州ということで、様々な国の食べ物を楽しむことができました。特にメキシコ料理が良かったです。

講演は全て英語だったわけですが、中には早口なスピーカーもそれなりにいて英語慣れしていない人には厳しいように感じました。個人的には会話中に声量がなさ過ぎて聞き返されることが多々あったので、少しうるさいと感じるくらいの声量を意識して会話をしていました。

また、今回のRubyConf参加に関する費用はすべて会社が負担してくれました。 来年のRubyConfはテネシー州ナッシュビルで開催予定です。一緒に行きたい！　という方がいましたら、ぜひ以下のリンクからご応募ください。お待ちしております。

www.wantedly.com

カテゴリー