Ruby 2.1へのアップグレードは必要か？本番環境で実証された15〜20%の高速化

その答えは、スクリーンショットを見ていただくのが一番早いでしょう。

{% img img-responsive /images/posts/ruby-2-1-improvement.png 645 259 大いに「イエス」と呼ぶべき結果 %}

私たちは約1週間前、本番環境でRuby 1.9から2.1へのアップグレードを実施しました。上のグラフがそのときの実際の様子です。下部のグレーの部分はガベージコレクション（GC）にかかる時間を示しており、ほぼゼロまで減少しています。全体として、サーバーのレスポンスタイムは15〜20%改善されました。しかも、追加のGCチューニングは一切行っていません。

さらに注目すべきは、アップグレードをリリースした後、GoogleとBingのクロール率が大きく向上したことです。検索エンジンからのトラフィックに大きく依存しているサイトにとって、これは非常に嬉しい副次的効果といえます。

では、アップグレードはどれほど大変だったのか？

依存gemが150近くある大規模なRailsアプリケーションでしたが、アップグレードに必要だったのは、わずか1つの小さなコミットと数日間のテストだけでした。すべてのサーバーでrvmを使用し、chefでプロビジョニングを行っているため、全サーバーを2.1にアップグレードする作業は、chefのロールファイル内のバージョン番号を変更するだけで完了しました。

どんな問題に遭遇したか？

私たちは依然として文字変換（トランスリタレーション）にiconvを使用していたため、2.x系から削除された組み込み機能を代替するiconv gemを追加する必要がありました。また、ruby-debugやdebugger gemは2.x系では動作させられなかったため、デバッグ環境をpryとpry-byebugへ切り替えました。その際、byebugの作者であるDeivid Rodriguez氏から「pry-byebugで発生した問題はおそらくbyebug自体が原因ではない」と指摘を受けました。実際にその通りで、真の原因はbyebugとpryの相互作用によるものでした。

また、1.9と2.1が混在する環境では、bundlerも1.5.1へアップグレードする必要があります。新しいバージョンのbundlerでは、Gemfile内でプラットフォーム要件として2.1を明示的に指定できるようになりました。

gem 'iconv', '~> 1.0.2', :platform => [:mri_20, :mri_21]

ちなみに、GitHubでも2.1への移行時に別の問題に遭遇したようです。Aman Gupta氏がこのgistでその詳細に言及しています：https://gist.github.com/tmm1/8393897。ただし、私たちの環境では現時点で問題は確認されていません。

さらにパフォーマンスを引き出したい場合は、リリース後にGCのチューニングを行うことをおすすめします。Aman氏による詳細な解説記事が非常に参考になります：https://tmm1.net/ruby21-rgengc/。彼のブログのRuby 2.1シリーズ全体は、低コストで簡単なアップグレードから最大限の効果を得たい開発者にとって必読の内容です。