メドピア開発者ブログ

集合知により医療を再発明しようと邁進しているヘルステックカンパニーのエンジニアブログです。読者に有用な情報発信ができるよう心がけたいので応援のほどよろしくお願いします。

Vue.js 公式ドキュメントのモブ翻訳をやりました!

こんにちは!
週一のサウナは欠かさない、フロントエンドエンジニアの土屋です。

先日、Vue.js の公式ドキュメントがリニューアルされました。
Vue.js 日本ユーザーグループ主導で翻訳プロジェクトが立ち上がっているのはご存知でしょうか?

メドピアでは、普段お世話になっている Vue.js に貢献したいという思いから、数回に渡って、Vue.js 公式ドキュメントのモブ翻訳を行ないました。

モブ翻訳の方法

  • Google Meet でファシリテーターの画面を共有しながら、Vue.js 公式ドキュメントの翻訳を行う
    • OSS へのコントリビュートに慣れていない方は、ファシリテーターが共有した画面を見ながら一緒に作業する。
    • 不明点がある場合、適宜ボイスやテキストチャットで相談しながら行う。
  • OSS へのコントリビュートに慣れてる方は、自分のペースでもくもくと作業する。

モブ翻訳の流れ

ここからは実際のモブ翻訳の流れとともに、その様子を紹介します。

まず、リポジトリの READMEVue.js 公式サイト日本語翻訳ガイドを確認します。
翻訳の方法や注意点が記載されているので、必ず目を通しましょう。

その後、翻訳するページを決めます。
Vue.js ビギナーの参加者が多かったので、Tutorial を翻訳することにしました。 翻訳を通して、Vue.js の知識を獲得するのが狙いです。

GitHub Issues で翻訳タスクが管理されているので、翻訳するページが決まったら、Issue に翻訳する旨をコメントします。
Tutorial を翻訳するので、Tutorial 翻訳まとめという Issue にコメントしました。

f:id:doyahiro:20220330165158p:plain
弊社のメンバーがこぞってコメントする様子

その後、リポジトリをフォークしてローカル開発環境を構築します。
ローカルで立ち上げることに成功したら翻訳開始です!

f:id:doyahiro:20220330165401p:plain
モブ翻訳中の様子。Google Meet で画面を共有しながらワイワイ。テキストチャットも盛んです。モブ翻訳だと、ここはこう訳した方が良いなど、色々な人の意見を聞けるのがありがたいですね。

訳し方に迷ったら Wiki をチェックしましょう。よくあるNGが記載されています。
また、Vue2 の公式ドキュメントではどのように訳されているか確認するのも有用でした。

訳し方に自信が持てない箇所は DeepL を使いました。

f:id:doyahiro:20220330165552p:plain
DeepL は強力ですが、意訳になりすぎたり、文中、文末の : (コロン) が削除されることがあるので注意が必要です。頼りきりにならないようにしましょう。

翻訳が完了したら、フォークした自分のリポジトリにプッシュします。
その後、フォーク元のリポジトリに Pull Request を出します。

f:id:doyahiro:20220330165703p:plain

PRを出すと、メンテナーの方がレビューしてくれます。
修正箇所がある場合は修正して再度コミットします。

f:id:doyahiro:20220330165735p:plain

問題がなければメンテナーの方がマージしてくれます。

f:id:doyahiro:20220330165813p:plain
晴れてマージされました。やったね!

これで一つの翻訳タスクが完了です。

f:id:doyahiro:20220330165902p:plain
初めてのOSSへのコントリビュートに喜びを隠しきれない様子

この流れで数回モブ翻訳を行い、弊社の社員で Tutorial を全て翻訳することができました!

まとめ

OSSにコントリビュートするのが初めての参加者が多かったので、リポジトリをフォークしてPRを出すといった、一般的なOSSへのコントリビュートの流れを体験できたのは良い経験になったと思います。

OSSにコントリビュートしてみたいけど、本体のコードに手を入れるのはハードルが高いと感じている方は、まずドキュメントの翻訳からトライしてみるのはいかがでしょうか。

普段使っているOSSには、今後も積極的にコントリビュートしていきたいですね。


是非読者になってください


メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html

Google ドキュメントを会議メモとして使う

こんにちは。サーバーサイドエンジニアのティーチです。最近の趣味は生後半年の娘にウケる動作の探求です。直近だと背筋が手応えありました。髪の毛がふわふわするのが面白かったようです。

本記事について

f:id:taichisato:20220304134701p:plain

■書く

  • Google ドキュメントを会議メモとして使うときの設定
  • Google ドキュメントを会議メモとして使う提案をする方法例

■書かない

会議メモを作る意義に触れると本記事の趣旨(Google ドキュメントの具体的な設定の仕方、使用の提案の仕方)以外の部分が長くなるので以下は割愛します。

  • 会議においてアジェンダ、議事録を作る意義
  • Google ドキュメントって何?

対象

  • 会議でアジェンダ、議事録を使いたいなと思ってる方
  • よその会議の仕方知りたいなという方

Google ドキュメントの強み

私のプロジェクトではオンライン会議をするためのツールとしてGoogle Meetを用いています。
そして、会議を入れる時はGoogle カレンダーに予定を入れるようになっています。

Google カレンダーには会議メモという機能があり、予定からGoogle ドキュメントを作成することが容易です。
作成後は予定にGoogle ドキュメントへのリンクが作られるので会議参加者への共有も容易です。

作成前 作成後
f:id:taichisato:20220304132153p:plain f:id:taichisato:20220304132217p:plain

f:id:taichisato:20220304132235p:plain

※2022/3/3時点 生成場所がマイドライブ固定のようなので共有ドライブに移動させるか、「共有」から編集権限を付与する必要があります。

作成、紐付けが容易な上
機能的には画像の挿入、見出し、同時編集機能ができるので良きです。

具体的な使い方

ファイル > ページ設定 から「ページ分けなし」に設定します。(この機能を紹介するためにこの記事書きました!) f:id:taichisato:20220304132252p:plain

ページ設定分けなしにすることで、なんと!例のあの空白をなくすことができます!ステキ! f:id:taichisato:20220304132303p:plain

f:id:taichisato:20220304132317p:plain

そして、1. 左上の灰色の部分をクリックしてテキストの幅を幅広にします。

あとは会議の内容に応じて構成を作る

f:id:taichisato:20220304132329p:plain

見出しは「見出し3」推しです。(MacならCommand + option + 3)

Google ドキュメントを会議メモとして使う提案をする方法例

私はすでに登録してある会議に対して上記のような会議メモを作って例えば以下のように共有しています。

前提

私はスギサポdeliというプロジェクトに携わっており、メンバーは本サービスを「deli」と呼称しています。

最近具だくさん食べるスープのBセットが出ました。私もまだ食べてないのですが、AセットはかなりおいしかったのでBセットもぜひ!(宣伝)

deliでは GitHubのプロジェクトボード を画面共有して会議していました。

Slackで投稿した文(ポイントがわかりやすいように修正しています)

Taichi Sato(teach)

deliの週次定例は内容充実してて良いのですが、
事前準備やissue外のトピックについての話し合いがやりづらいので、  .. (1)
マイブームの会議メモを作りました。.. (2)

[会議メモのURL]

deli projectとの2画面を画面共有するのはやりにくい部分あるかもしれませんが、
とりあえずやってみたいです! ..(3)

ポイント

(1) 会議メモがあると良い理由を一行で書く。

長いと読みづらいため。提案する相手によって詳細度は変えても良いと思います。

(2) 提案する人が会議メモのたたき台を作る。

理想的には、会議を招集する人が会議メモ、アジェンダ、構成全部つくるのが一番早いと思います。
しかし、登録された会議に対して
「アジェンダ作ってもらっていいですか?」
よりも
「会議メモとアジェンダ作りました!XXとYYはわからないので追記お願いしたいです!」
といった一緒に会議スタイルを作り上げていく方が現実的には効率よいのではないかなと私は思います。

(3) とりあえず一回!

「習うより慣れよ」
実際に会議メモを使って会議してみて、よかったら継続、合わなかったらやめれば良い。 そのくらいライトに提案した方が、提案された側も「とりあえずなら..」ってなる気がします。

deliでは今後も継続してGoogle ドキュメントを使用して会議をすることになりました。

まとめ

ページ分けなし設定ステキなのでぜひ広めて欲しい..!
Google ドキュメントの使用の提案方法が参考になれば幸いです!


是非読者になってください


メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html

ECR拡張スキャンでRailsアプリを診断した際の脆弱性警告(偽陽性)への対策

皆様こんにちは、サーバーサイドエンジニアの草分です。 最近ポケモン最新作を買ってしまったのでひたすら野原でボールを投げ続ける日々を送っています。

さて本題に入りましょう。

Amazon ECRには、pushしたコンテナイメージへのイメージスキャン(脆弱性診断)機能があります。

Image scanning - Amazon ECR

メドピアではこれを利用して全社横断的にアプリの脆弱性の検知および可視化を行っています。

f:id:yuyakusawake:20220131191845p:plain
脆弱性が検知された場合の表示

この記事では、Railsアプリをイメージスキャンした際の【偽陽性】警告の問題と、その解決策について紹介いたします。

問題

ECRのイメージスキャンには「基本スキャン」「拡張スキャン」の2種類があり、この内の拡張スキャン(Enhanced scanning)では、Rubyのgemやnpmのパッケージなども診断の対象となります。
Gemfile.lockに脆弱性のあるライブラリの記載があった場合でも、拡張スキャンを使えば自動検知&一覧化することができます。

ただし現時点(2022/01)ではアプリが使用するGemfile.lockだけでなく、インストールしたgemのディレクトリまで無差別に診断してしまうようです。

f:id:yuyakusawake:20220130162016p:plain

Rubyのgemは.gemspecファイルの記載に従って動作するため、gemパッケージ内にGemfile.lockが含まれていても通常は使われることはありません。

しかしそんなことはお構いなしに脆弱性警告を発してくるため、使っているgemによっては身に覚えのない警告を大量に受け取ることになるでしょう。困りましたね。

Inspector側でなんとかして欲しいという思いもありますが、この問題に対して以下の対策を実施しました。

続きを読む

The Complete Guide to Rails Performance読書会をしました

こんにちは。メドピアのお手伝いをしています@willnetです。最近車を買いました。これまでペーパードライバーだったので自信を持って運転できるように運転の練習を頑張っています。

今日は社内読書分科会で読んだThe Complete Guide to Rails Performanceという本の話を書きたいと思います。社内読書分科会って何?という人はこちらのエントリを参考にしてください。

tech.medpeer.co.jp

The Complete Guide to Rails Performanceとは

タイトルの通り、Railsアプリケーションのパフォーマンスを向上させるための知識やテクニックについて書かれている書籍です。書いている人は Nate Berkopecさんで、パフォーマンスに関するコンサルやワークショップをしているようです。パフォーマンスに関するメールマガジン*1の発行もしています*2

目次

こちらのgistから引用します。

  • An Economist, A Physicist, and a Linguist Walk Into a Bar...
  • Little's Law (+ screencast)
  • The Business Case for Performance
  • Performance Testing (+ screencast)
  • Profiling (+ screencast)
  • Memory - How to Measure (+ screencast)
  • Rack Mini Profiler (+ screencast)
  • New Relic
  • Skylight
  • Optimizing the Front-end
  • Chrome Timeline (+ screencast)
  • The Optimal Head Tag (+ screencast)
  • Resource Hints (+ screencast)
  • Turbolinks and View-Over-The-Wire
  • Webfonts (+ screencast)
  • HTTP/2 (+ screencast)
  • JavaScript
  • HTTP Caching (+ screencast)
  • Memory Bloat (+ screencast)
  • Memory Leaks (+ screencast)
  • ActiveRecord
  • Background Jobs
  • Caching
  • Slimming Down Your Framework (+ screencast)
  • Exceptions as Flow Control
  • Webserver Choice
  • Idioms - writing faster Ruby
  • Streaming
  • ActionCable
  • CDNs (+ screencast)
  • Databases
  • JRuby
  • Memory Allocators
  • SSL (+ screencast)
  • Easy Mode Stack - "What stack should I choose?"
  • The Complete Checklist - a 75+ item checklist for Ruby/Rails apps.

良かったポイント

Railsでアプリケーションを開発するときに知っておくと良い知識や気をつけるべきポイントについて網羅的にまとめられています。特にRailsアプリケーションだけの話にとどまらず、フロントエンドやCDNなどのwebアプリケーションを構成する要素全体について記述されているのが良いところだと感じています。ユーザが感じるwebアプリケーションの速度はサーバサイドのレスポンス速度だけではなくレイテンシやフロントエンドも含めた総合的な体験であり、通常の構成のwebアプリケーションではアセット類を取得したりパース、実行する時間のほうがユーザが待つ時間の大きい比率を占めるのでまずそちらを見てボトルネックを見つけると良い、というのは言われるとそうですね、となるのですがRailsエンジニアとしてはまずスロークエリとかN+1とかに目がいってしまうのですよね…。

一定規模以上のRailsアプリケーションを運用していると、アプリケーションサーバやワーカのメモリが急に増える現象に遭遇することがあります。そうなったときになにが原因なのかよくわからないのでとりあえず再起動しよう、とpuma_worker_killersidekiq-worker-killerなどのツールを使ってお茶を濁すことも多いです。この本ではお茶を濁さずに、原因をメモリリークなのかメモリ肥大化なのかを切り分けるところから、具体的にどうやって調査、解決していったり良いのか方針を提示してくれています。

最近 メドピア内でjemallocを採用した記事が公開されましたが、この本ではjemallocとそれ以外のメモリアロケータ (tcmallocHoardについてベンチマークが取られておりjemalloc以外の選択肢について考えさせられました(とはいえ採用事例の多いjemalloc側に寄せておくのがいいのかな、というのが現時点での個人的な見解です)。

などなど。もちろんActiveRecordで効率的なクエリを書くのはどうしたらよいか、とかキャッシュの使い方など基本的なトピックも抑えています。洋書を事前に予習しておくというのがハードル高く大変でしたが、それを超えたメリットがある本です。

良くなかったポイント

良いことばかり書くと信憑性に欠けそうなので、良くなかったポイントについても書いておきます。

何度か改訂はされていますが初出が2016年なので、当時の状況と現在の状況を読み替えないといけない箇所があります。具体的にはHTTP/1.1が広く使わている前提になっていてjsを結合して配信しましょう、という文章があちこちにあります。2022年現在ではHTTP/2が広く使われており、jsを結合する必要は薄れているのでそこを意識しつつ読み進める必要があります。

あとはとても細かい点です。HTML, PDF, epub, mobi, txt など複数のフォーマットで本が読めるのは良いのですが、PDF, epub, mobiで読むと横に長いソースコードが全部掲載されていない(右側が切れてしまう)ことがあってtxtなどを参照しにいかないとソースコードを確認できなくてつらい、となりました。あとは編集ミスのような文章の構成(2章分の全然別のトピックが1章にまとめられてる)があるので注意が必要です。

まとめ

The Complete Guide to Rails Performanceの紹介でした。Railsエンジニアでパフォーマンスに興味のある人であれば広くおすすめできる本ですのでよければ読んでみてください!


メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html

*1: ここ から購読できます

*2:参考になる知見が多いので、僕はずっと購読しています

Ruby v3.1.0のSegmentation faultに遭遇した話

こんにちは。サーバーサイドエンジニアの三村です。

保険薬局と患者さまを繋ぐ「かかりつけ薬局」化支援アプリ kakariやその姉妹サービスである患者接点を資産化する診療予約システム かかりつけクリニック支援サービス kakari for Clinicの開発を担当しています。

目次

はじめに

kakariをRuby v3.1.0にアップグレードする作業をしていたところSegmentation faultに遭遇したので、bugs.ruby への報告や再現コード作成などの経緯をまとめました。

賢い方法では無い部分も多々ありますが、温かい目で見守ってください。

bugs.rubyのissueはこちらです。

bugs.ruby-lang.org

f:id:t_mimura:20220119185723p:plain
bugs.ruby issue

※ Ruby本体の実装の話は出てきません。

現象

kakariでRuby v3.1にアップデートをしたら、CircleCIで実行しているRSpecでたまにSegmentation faultが発生するようになりました。

f:id:t_mimura:20220119185413p:plain
CircleCIログ

以下のような状態でした。

  • ActiveDecoratorの内部処理で発生
  • 複数回発生
  • エラー箇所は1箇所ではない
  • 再実行すると直る

bugs.rubyに報告

何はともあれ、Segmentation faultはRubyのバグなので報告します。 が、原因分からず再現コードも全然整理出来ていなかったので報告を躊躇いました。 そんなときに便利なruby-jp Slack

f:id:t_mimura:20220117233548p:plain
ruby-jp Slackでの相談の様子

温かく受け入れてくれそうだったので、安心してissueを作成することが出来ました。https://bugs.ruby-lang.org/issues/18489

issue起票当時は再現コードを整理する余裕がなかったので少しでも情報量を多くしようと思い、遭遇したSegmentation faultのログを複数個添付しました。

原因究明までの道のり

環境依存の問題かどうかを切り分け

これまでCircleCIでのみ再現していたので別の環境でも発生するのかをまず切り分けました。

ローカル開発環境(Docker Desktop for Mac)で複数回RSpecを全件実行し、無事に?再現することが確認出来ました。 Docker Image( cimg/ruby:3.1.0-browsers を利用 )依存ならまだしもCircleCI環境依存だった場合は原因究明までの試行錯誤が恐ろしく大変だったので一安心。

エラー発生ファイルの特定

特定のrequest specで再現することがすぐに判明出来ました。 が、このrequest specを単体で何回も実行しても再現しないことからファイルの読み込み順依存の問題であることも同時に分かり悲しみ。(ファイルの読み込み順問題よくありますよね)

specの実行順をランダムから定義順に変更

specは config.order = :random が指定されランダム順に実行されるようになっていたので、これを defined に変更し読み込み順を定義順にしました。 この状態でも本問題が再現することが確認できたのはかなりラッキーでした。 「randomの場合でのみたまに遭遇」みたいな状態だったらseed固定などもう一工夫必要になり面倒で諦めていたかもしれません。

因果関係のあるテストを特定

ここからは地道な試行錯誤の繰り返しです。

以下のspec群から本問題に関係のあるものを特定していきます。

$ tree -L 1 spec/
spec/
├── controllers
├── decorators
├── helpers
├── lib
├── mailers
├── models
├── push_notifiers
├── requests
├── serializers
├── system
├── uploaders
├── validators
└── workers

まずは試行時間の短縮の為に重たいspecを除外を試みました。 特にテスト数の多いmodelsと一つ一つが重たいsystemsを除外しました。 幸いこれらを除外しても変わらずSegmentation faultは再現できたのもラッキー。

脱Docker Desktop for Mac

この後もひたすらspecを実行しまくることが想像できたので少しでもspec実行時間を短くするように先に工夫しました。

kakariではDocker Desktop for Macを利用してローカル開発環境を構築しています。 が、これは色々な要因で重いことが有名ですね(詳細は割愛)。

ということで、脱Docker Desktop for Macを試みました*1。 (恒例の)mysql2のbuildでエラーになるなどちょいハマりポイントはあったものの、すんなり対応出来ました。 真面目に計測したわけではないですが、1.5~2倍くらい早くなった気がします。(かなりうろ覚えなので気になる方はご自身でお確かめください。)

MySQL -> SQLiteに変更

次にMySQLからSQLiteに変更をしました。

本事象は十中八九データベースは無関係だろうと予想していました。 MySQLが重たいわけではないですがSQLiteにすることでインメモリーなデータベースを利用することができる ( database: ':memory:' こんなやつ ) のでspecの並列実行が容易になりました。

基本的にDBの差異はActiveRecordが吸収しているのでadapterを切り替えるだけで済みました。 一部、外部キー制約やindex周りの挙動の違いはあったものの取り上げるほどのものはありませんでした。 (というか本事象と無関係だろうと思い深く考えずコメントアウトしたりして対応していました。)

↓はイメージですが、こんな感じの頭の悪い方法でspecを並列実行することが出来ました。

f:id:t_mimura:20220117234303p:plain
spec並列実行の様子
※ iTerm2の画面分割と「Broadcast Input to All Panes in Current Tab」を利用

再現コードの特定

上記の工夫のおかげもあり、因果関係のあるファイルを数個に特定することができたのでミニマムな再現コードの調査に切り替えました。 特に「request specでのみ再現」という状況が色々と面倒だったので何とかシンプルなRubyスクリプトコードを書けないかを模索。

数行のRubyスクリプトコードで再現したりしなかったりする状態までたどり着いたものの、再現有無の条件が全く分かりませんでした。 が、唐突に「GCか?」と思いついたため試しに GC.start を差し込んでみたところめでたく再現しました。

ここから先は簡単で、ActiveDecoratorを利用して書かれた再現コードをplainなRubyコードに変換するだけです。 ActiveDecoratorのコードは予め目を通していたお陰でここは数分で出来ました。

その結果出来た再現コードがこちらです。

M = Module.new
Object.new.extend(M)
GC.start
M.include(Module.new)

二日くらい費やした結果、美しく短い再現コードを作れた時は若干の感動がありました。

再現コード報告

早速「再現コード作れたよ」と追加報告です。

「ActiveDecoratorでSegmentation fault発生」という状況から一気にシンプルな再現コードに飛躍してしまったので「ActiveDecoratorをこんな感じに使ったら再現するよ」というのを添えてコメントしたのは我ながら親切ポイントです。

そして、再現コードをコメントしてから僅か2時間足らずでn0kadaさんが修正PRを作成してくれました。(流石だ)

修正確認

その後、issue上で 「Does https://github.com/ruby/ruby/pull/5455 fix it?」と聞かれてしまったので確認するしかありません。

Rubyをcloneして自前でビルドするのは初めてだったので不安がありましたが、実際にはruby/rubyのREADME手順通りにコマンド打つだけで大きなハマりどころもなくすんなり出来ました。 強いて言えばopensslのパス設定が必要だったかな程度です。あまり覚えていないくらい些細な問題でした。

上記の「脱Docker Desktop for mac」をしておいたのも地味に良かったです。

ruby-jpで相談していたところ、 k0kubunさんのブログ を紹介してもらいとても参考になりました(ありがとうございます!!) ※ 特に「ビルドしたrubyをrbenvから使うには」の所は便利

というわけで、大した苦労もなく無事に修正確認できました。

work around

無事に修正PRもマージされたとは言え流石にheadなrubyコードを利用するわけにはいかないので別途回避する方法を模索します。

これに関しては再現コードの特定が既に出来ているため簡単な話で、以下のような(不適切な形で)ActiveDecoratorを利用している箇所の修正するだけで済みました。

let!(:user) do
-  build(:user).extend UserDecorator
+  ActiveDecorator::Decorator.instance.decorate(build(:user))
end

本事象が発生していたのはspecのみで、実際のプロダクトコードでは同様の事象はなさそうでした。

まとめ

  • Rubyを触り始めて6年近く経ちますが、初めて Ruby本体 にまともな貢献が出来たかなと実感できとても良い経験でした。
  • ruby-jp Slackで気軽に相談できたのがとても有り難かったです。感謝感謝です。
  • 自分のコミットではないにしろ、ほぼ同等のものが「テストコード」としてRubyに入ったの嬉しい。
  • 褒められたの嬉しい。
    f:id:t_mimura:20220117235023p:plain
    ruby-jp Slackで褒められた様子

おまけ

無事にkakariはRuby v3.1.0にアップグレードすることができました。 本件は色々とありましたが、それ以外に必要な対応は殆どなくRubyの後方互換性の高さに感謝です。

以上です。 もし「Segmentation faultに遭遇して困った」なんて時に本記事が参考になれば幸いです。


メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html

*1:今回の調査中だけの話です

Ruby × jemallocのすすめ

集合知プラットフォーム事業部・エンジニアの榎本です。コロナ禍の運動不足を解消すべく筋肉体操で筋トレを続けてますが、上腕三頭筋がいい感じに成長しており継続の大切さを身に沁みて実感しております。

目次

TL;DR(三行要約)

  • jemalloc でRubyアプリのメモリ効率改善
  • jemalloc でRubyアプリのパフォーマンス改善
  • jemalloc の導入も簡単

Rubyアプリケーションのメモリ肥大化問題

Ruby on RailsなどのRubyアプリケーションを運用する上で、メモリ使用量の肥大化に頭を悩ませた方は多くいらっしゃるのではないでしょうか。

下記は典型的なRailsアプリケーションのメモリ使用量のグラフです。メモリの使用量が対数関数のグラフのように時間とともに100%に近づいていく様子が見て取れます。

Railsアプリケーションのメモリの使用率の増加

この問題の素朴な対処法としては、しきい値を定義して定期的にworkerプロセスを再起動してやることです。実際にそれを実現するためのgemがいくつか存在します。

しかし puma_worker_killer の README 冒頭で注意喚起されているとおり、頻繁な再起動はCPUリソースを消費させパフォーマンス劣化の要因にもなることから、あくまで応急処置であるべきです。メモリ肥大化の根本的な原因となっているコードがあるのであれば、それをきちんと調査し修正・対応すべきでしょう。

jemalloc を使ってみる

こういったメモリの肥大化・断片化がなぜ起こるのか、それにどう対処すべきかについては書籍・『Complete Guide to Rails Performance』の中で詳しく解説されています1

追記: 本書の内容は下記の記事で紹介しております。

tech.medpeer.co.jp

細かい話は本を読んでいただくとして、本書の中ではRubyアプリケーションのメモリ使用を効率化する方法として、メモリアロケーターを jemalloc に切り替える方法が紹介されています。

前置きが少し長くなってしまいましたが、本記事では jemalloc を実際にプロダクション投入してみた結果とともに jemalloc について紹介したいと思います。

jemalloc とは?

jemalloc とは Meta(旧・Facebook)社が中心となって開発されているメモリアロケーターです2。その特徴として、メモリの断片化の回避とスケーラブルな並行性サポートを謳っています。

github.com

jemalloc で改善するのか?

気になるのは jemalloc 導入によって実際にメモリ使用率は改善するのか?というところです。

検索してみるとすぐに jemalloc 導入で実際にメモリの使用量が改善したという事例がいくつか見つかりました。

またこちらのベンチマークによると、メモリだけではなくパフォーマンスも10%程度 jemalloc によって向上することが示されています。

CRuby 2.5.0 jemalloc tcmalloc increase w/ tcmalloc increase w/ jemalloc
Median Throughput 175.13 req/sec 197.49 req/sec 183.33 req/sec 4.68% 12.77%

jemalloc の設定方法

Rubyはデフォルトのメモリアロケーターとして、 glibc malloc を使います。ではどのようにメモリアロケーターをデフォルトから jemalloc に切り替えることができるのでしょうか?

--with-jemalloc オプションをつけてRubyをコンパイルする方法もありますが、一番手軽な方法は 環境変数 LD_PRELOAD を設定することです。このLD_PRELOADに jemallocのsoファイルのパスを指定してやればOKです。

具体例を示しましょう。下記は alpineベースのRuby dockerイメージにおける jemalloc 設定方法になります(マルチステージビルドを使って jemalloc のインストールを行っていることに注意してください)。

FROM ruby:X.X.X-alpine as base
...
FROM base as jemalloc
RUN wget -O - https://github.com/jemalloc/jemalloc/releases/download/5.2.1/jemalloc-5.2.1.tar.bz2 | tar -xj && \
    cd jemalloc-5.2.1 && \
    ./configure && \
    make && \
    make install
...
COPY --from=jemalloc /usr/local/lib/libjemalloc.so.2 /usr/local/lib/
ENV LD_PRELOAD=/usr/local/lib/libjemalloc.so.2
...

jemalloc インストール後、ENV命令にてLD_PRELOADにsoファイルのパスを指定しています。この状態でRubyアプリケーションを起動すれば、Rubyのメモリアロケーターは jemalloc に切り替わります。

ただ、この環境変数はDockerイメージ全体のソフトウェアに影響するグローバルな設定なので、設定して問題ないかはきちんとステージング環境などで動作確認・検証しましょう。

jemalloc をプロダクション導入してみた結果

実際に本番環境で稼働するRailsアプリケーションに jemalloc を適用させてみました。その結果をご紹介します。

下記は sidekiq (v6.3)の jemalloc 導入前後一週間のメモリ使用率の比較です。青い線が導入後のメモリ使用率、点線が導入前のメモリ使用率となっております。

sidekiq jemalloc化 before(点線)/after(青線)

少しわかりにくいのですが、平均して5%程度メモリの使用率が改善したことが確認できました。しかし、先に紹介した改善事例のようにグラフにはっきりと改善が現れると期待していたので、正直なところ少し期待外れ感は否めませんでした。

パフォーマンスについてはどうでしょうか? 下記はRailsアプリケーション(Rails v6.1, Webサーバーはunicorn)のレイテンシーのグラフです。上から順に p99, p95, p90のレイテンシーとなっています。

Railsアプリケーションのjemalloc化 before/after

こちらはグラフにはっきりとした改善(10-20%程度のレイテンシーの改善)が現れました。Dockerfile を少しイジっただけでこれだけのパフォーマンスが改善したのは、期待以上の結果と言えます。

まとめ

Rubyのメモリアロケーターを jemalloc に切り替えることで、アプリケーションコードの変更なしにメモリ使用およびパフォーマンスを改善できました。

導入もさほど難しくないので、Rubyアプリケーションのメモリおよびパフォーマンスにお困りの方は一度試してみてはいかがでしょうか。

おまけ:jemalloc についてMatzに聞いてみた

弊社の技術アドバイザリーとしてMatzさんがおりますので、Matzさんにもjemalloc について見解を伺ってみました。

Q. jemalloc コアチーム的にどう考えている?

  • どのアロケーターでパフォーマンス向上するかは、アプリケーションの特性次第。一概にどれがいいとは言えないと思う
    • jemalloc に変える提案も来た3が、Rubyとして取り込む予定はない
    • LD_PRELOADでメモリアロケーターを変更できる口は用意してあるので、変更したい場合はそちらを使ってほしい
  • Ruby として jemalloc を推奨することはしないが、Railsアプリケーションでメモリがボトルネックになりやすいということは理解しているので、改善は進めている。すでに入れた変更だと下記のようなもの。
    • 世代別GC
    • インクリメンタルGC
    • Object Compaction
  • Rubyとして推奨はしないがコミュニティの中で jemalloc のほうが良さそうだといった知見が公開されるのは大歓迎である

メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html

RubyWorld Conference 2021 にプラチナスポンサーとして出展しました!(Matzの後日談つき)

サーバーサイドエンジニアのミナトです。 医師とMRをつなぐコミュニケーションツールとなるMedPeer Talk というサービスの担当をしています。

昨年の 12/16に開催された RubyWorld Conference(RWC) に、メドピアはプラチナスポンサーとして参加しました。

f:id:minato_nkmr:20220108062103p:plain
RWC2021スポンサーセッション(メドピア)

スポンサーセッションはこちらからご覧いただけます!

当日は、GALIMO を利用したオンライン会場でブース出展もいたしました。

f:id:minato_nkmr:20220108062207p:plain
RWC2021スポンサーブース

この記事では技術的な内容がほとんどないのですが、RWCを振り返ってみた内容をまとめてみました。

個人的にRWCは比較的ビジネス寄りの発表が多いイメージがありました。 ですが、今年の発表ではメソッドオブジェクトの理解を深めるような技術寄りの話からRubyコミュニティについての話まで幅広くあり、改めてRubyの多様な側面を見れました。

Rubyコミュニティという軸でみたRWC2021

プログラミング未経験者でも利用できるSmalrubyをベースとして作成されたツールのセッションがありました。このツールを利用する方の中でRubyそのものに深く入り込んでいくという人は少ないのかも知れません。ですが、こういったプログラミング自体の敷居を下げていくきっかけとしてRubyが利用されていくということで、社会にRubyが入り込んでいくことが増えてくるのではと思いました。

アフリカでのRubyエンジニア育成のセッションRailsチュートリアル×遠隔学習のセッションを聞き、未経験からRubyを利用したエンジニアとして成長していく過程でこういったエコシステムが存在することで、Rubyコミュニティが形成されていくのだとも感じました。

私が一番共感してしまったのは、リンカーズ株式会社さまの「Railsバージョンを倍にした」セッションでした。 なぜ技術的負債が溜まってしまったのかという考察から、どうやってリファクタリングを進めていったのかという具体的なお話の中で、

  • MVC全部遷宮
  • テストカバレッジ0→95%まで上げた
  • 3ヶ月の動作確認
  • 負債を溜めないための仕組み

などなど、聞いている中で大変だったんだな…すごくわかる…といった部分が随所にありました。 Rubyを利用しているからこそ共感できるこういったものが、松田さんの発表「Me and My Ruby Friends」にあったような「Rubyを利用していることで芽生える友情」に育っていくのかなとも思いました。

Matzさん後日談

弊社ではMatzさんを技術顧問として毎月1回オンラインMTGをさせていただいております(エンジニアにとっての福利厚生ですね!)。

そのMTGの中でMatzさんに、特に印象に残ったセッションはどれでしたか、とお聞きしたところ松田さんの「Me and My Ruby Friends」とのことでした。他にもいくつか挙げていただいていましたが、全部は書ききれないので省略しました。

このセッションの感想をお聞きする中で、

「純粋に技術だけの話をすると投資しているリソースのサイズによってしまう。例えばV8エンジンにはどうやっても勝てない。しかし、RubyはRWCのようなものだったり、RubyKaigiのような多様なコミュニティがある。良いコミュニティ作るという意味では Ruby はなかなか良いのではと思っている」

と仰っていました。 私自身はJava、PHP、Rubyと変遷してきた中でのRubyコミュニティの多様さを本当に感じます。

他にも、

  • 当日の朝にmrubyのバグレポートが来ていて、開会〜キーノートの間に準備をしていると見せかけてデバッグして 5min前にcommitしていたこと
  • オンラインカンファレンスは「オフラインでできてた廊下でちょっと話したりとかフラッとブースに立ち寄ったりが難しいよね。副音声とか面白いかもね」

といった面白いこぼれ話も聞けました。

まとめ

とりとめもなく書いてしまいましたが、今回のRWCではRubyコミュニティ、OSSとしてのあり方、ビジネスとしての可能性の広さを改めて感じることができた1日でした。

最後になりますが、今回のRWCを開催・運営してくださったスタッフの皆様ありがとうございました!


メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html