こんにちは、情報システム部・エンジニアの大河原です！
このブログ最初の記事で、技術顧問：まつもとゆきひろ氏との勉強会（通称：Matz会）について書きました。
今回は、12月度のMatz会についてレポートします。
「Matz会てなに？」という方は、上記の11月度の記事をご覧くださいね。
今回も、「メンバーがLTを行い、それに対してコメントをいただく」という形式でした。2人のメンバーが発表したトピックは、以下の通り。
- 力はPower! 速さはSpeed!
- RUBYGEMS 入門
タイトルだけ見ると何の発表だか分からないものもありますね。
詳しいレポートは「続きを読む」からどうぞ。
力はPower! 速さはSpeed!
Rubyで単純なループ処理を高速化できないか？というテーマで様々に検証をした、という発表でした。
ベンチマーク対象はRailsに定義したUserモデルを1万個作成する時間で、愚直に実行すると実時間(real)29秒かかるものです。
これを以下の3つのアプローチで高速化してみます。
- transactionで囲う
- activerecord-importを導入する
- parallelを導入する
transactionで囲う
データの格納処理が1回だけで済むため、そのぶん高速化します。
2倍以上の速さの実時間11秒弱になりました。
activerecord-importを導入
複数のモデルをDBに格納する際、1レコードごとではなくまとめてINSERTするようにSQLを生成してくれます（bulk insert）。
実行するSQL文が1文で済むため、減ったオーバヘッドの分だけ高速化します。
10倍以上速くなり、2秒強になりました。
parallelを導入する
Rubyの一部の機能を並列実行してくれます。
デフォルトでは並列化をプロセス並列で行い、並列数はCPUのコア数と同じになります。実行に使ったMacbook Pro(2017)は4コアなので、4並列。
しかし、こちらの実行時間もactiverecord-importを使ったのとほぼ同じ2秒強。
なぜ遅いんでしょう？
調べてみると、Parallelのインスタンス生成の時間がボトルネックになっているようでした。
ので、このベンチマーク対象ではあまり効果がないようです。
というわけで、Userに関連するArticleというモデルを新たに作成し、1万のユーザそれぞれに対して100記事生成して保存するベンチマークを新たに行うことに。
1ユーザに付き100記事で1万ユーザいるので、100万のモデルを生成することになります。
activerecord-importでこの処理を実行してみると、モデル生成に25秒・データ保存に218秒かかりました。
単純にデータ量が多いだけでなく、全レコードについてuser_idのバリデーションがかかるために非常に時間のかかる処理になっています。
そこで、
- parallelの導入
- バリデーションを実行しない
という施策を打つことで、モデル生成に7秒・データ保存に125秒と大幅なスピードアップを果たしました。
まとめ
parallelは、
- 単純に処理回数が非常に多い場合
- 1回の処理が重い場合
- つまり、Parallelインスタンス生成の時間が相対的に短くなる場合
に有効であるようです。特にバッチ処理に効きそうですね。
そもそも、RailsではどうしたってDBがボトルネックになるので、Sidekiq等で非同期に実行するなどボトルネックにならない工夫がまず必要、という話も出ました。
RUBYGEMS 入門
こちらは、技術顧問の前島真一（@netwillnet）さんからの発表で、ご本人がスライドを公開されています。
gemの作り方を詳しく解説してくださいました。
自社でホスティングしているGitLabにあるgemは1件のみです。もっと機能をgemに切り出す文化を根付かせていきたいですね。
まつもとさんへは「ライブラリ管理方法は色々遷移したが、Ruby開発者としてのコミットはあるか？」との質問。
回答は、「自然に任せていたら良い感じにしてくれた」つまり、RubyGemsにまつもとさん自身はあまり関わっていないようです。
最初期はまつもとさんご自身が作ったRAA(Ruby Application Archives, RubyCGIで作成)で管理されていましたが、第1回RubyConfでRubyForgeが発足し、それが徐々にRubyGemsに移り変わった、という形だそうです。
ライブラリの配布方式も、ディスクの価格低下により参照型からコピー型に移っていきました。
質疑応答
今回は質疑応答の時間があまり取れなかったのですが、
AWS LambdaでRubyだけでなくCOBOLもサポートされたことが話題になったが、狙いはなんだと思うか？
これに対しては、「話題作りでは？」というご回答をいただきました。
- そもそも、COBOLに注力したわけでなく「あらゆる言語に対応」したことが今回の発表
- COBOLはGNU COBOLとしてOSS化されているので動くのは当然
- 案の定バズったので、狙いとしては当たりだったのでは
- COBOLの技術者や資産は結構多い、主に医療系システムなど
- 「帳票界のRails」として、ある種のDSLと捉えると良いのではないか
とのことでした。
COBOLについては勤労統計問題や情報技術者試験に関連して立て続けに話題になっていますが、すぐになくなることはないのでしょうね。
Fortranが科学技術計算用の言語として生き残っているように、用途を限定して使われ続けるレガシー技術は確かにあるようです。
「誰も読めないコード資産がある」というのはCOBOLが生き残っているのとは別の、組織の問題だということでしょう。
まとめ
大変遅くなってしまいましたが、12月分Matz会のレポートでした。
「並列化」と「gem自作」に関して、いずれも今日から使えるテクニックだったのではないでしょうか。
1月分についてもほとんど書き上がっていますので、近いうちにアップします。
