【イベントレポート】Ruby on Railsフレームワークについての最新情報を学ぼう！
皆さん、こんにちは！
ぶっちゃけ系エージェントROSCA広報のSahoです。
本日のイベントレポートはRuby on Railsフレームワークについての最新情報を学ぼう！です！ROSCAFE初のフレームワークに関するイベントでした！
Ruby on Railsを活用する、3社の企業さまにご協力いただきました。ありがとうございました！
このnoteでわかること
・WEBサービス企業のエンジニア3名が今注目しているRuby on Railsの活用方法
今回の登壇企業
・スマートキャンプ株式会社
・SHE株式会社
・株式会社Asobica
登壇者のご紹介
スマートキャンプ株式会社 BALES CLOUDカンパニー 開発本部 副本部長 井上 翔太朗
2012年：新卒でSier会社に入社。セールスから開発までの業務を経験。その後：ソフトウェアエンジニアとして、サービス開発を経験。2018年：スマートキャンプに入社。新規事業の開発リーダーとして、複数のプロジェクトを率いる。2020年以降：インサイドセールスに特化した管理ツール「BALES CLOUD」事業に移行。開発責任者として、開発を主導し、チームの育成とマネージメントを担当。
SHE株式会社 ソフトウェアエンジニア 錦織滉司
学生時代よりソフトウェアエンジニアとして自社プロダクト開発に携わる。前職では PdM も務めたものの、退職を機に改めてソフトウェアエンジニアへ復帰し、 2023年2月よりRuby on Railsを用いたSHEの開発に携わる。現在はテックリードとして開発チームを主導している。初めて触った Rails のバージョンは 3.2。
株式会社Asobica プロダクト開発部 Webアプリグループ 西岡慎司
総合職として中堅メーカーに入社。主にバックオフィスとしてキャリアを築いていたが、直接プロダクトを作りたいという思いが芽生え、エンジニアへキャリアチェンジ。エンジニアとしては2社で経験を積み、介護事業者向け業務支援サービス、CtoCマッチングサービスの開発に従事。2023年3月にAsobicaにジョイン。Asobicaでは開発業務のほか、採用業務にも従事し、共にプロダクトを育てる仲間を探している。
LT1:スマートキャンプ株式会社 BALES CLOUDカンパニー 開発本部 副本部長 井上 翔太朗
井上翔太朗と言います。to B向けのセールス系のサービスを開発する企業でエンジニアをやっております。八王子在住でコーヒーやヒップホップが好きだったりします。今日はよろしくお願いします。
BALES CLOUDというサービスには特定のセールス業務というのがあるのですが、成果を最大化するためにそのコミュニケーション最大化みたいなところをやっていこうというところでサービスを開発しているというところになっております。
今回、RailsでPostgreSQLというものがサポートされるのですが、そこで使える基本的な機能についてや、最近の話題ということでRails7などでサポートされてどのような恩恵があるのかについて話していきたいと思います。
PostgreSQLとは
ご存知の方もいらっしゃるかと思いますが、まずPostgreSQLは最近結構使われることが多くなってきたのかなと思うのですが元々カリフォルニア大学のバークレー校のコンピュータサイエンス学部で開発されて、Postgres95という名前からPostgreSQLになっていったという経緯があるようです。
オブジェクトリレーションデータベース管理システムとして皆さんに知られる形になっているのかなと思っています。そんなPostgreSQLはリリースでは標準でサポートされていて、Railsガイドでも手厚く説明がされています。これは結構珍しい気もしますが、ActiveReportsとPostgreSQLと、という形で、PostgreSQLのデータ型の利用方法だったり、どのような拡張機能を入れないと使えないよいうところなど、かなり細かく書いてありサポートの手厚さが伺えます。
SaaSにおけるPostgreSQLの利用
PostgreSQL自体の利用が促進されている背景みたいなところはいくつかありますが、今回はSaaSにおける部分で話していこうかなと思っています。Row Level Securityは皆さんご存知かもしれないですが、2016年のバージョン9.5で導入されたことにより、これを使うところが出てきたっていう部分もあるのかなと思っています。
機能としては一つ一つのテーブルのレコードの行レベルでテナントと言えば、企業ごとにデータの取得、追加、削除、更新を保護してくれて、そこの許可というところがあるのですが、許可がなければ操作拒否されるというものになっています。
これがマルチテナントという複数企業が一つのシステムを共有するという形を作るために培われたものになっています。シングルテナントだと、一つ一つデータベースやサーバーを作ったりなど、初期のスタートアップにとってはコスト的にかなりつらいものがあります。
その中でうまく運用するためにはどうすればいいのかというところで出てきた技術がRow Level Securityなのかなと思っています。Row Level Securityがありなしだと同じSQLを実行をしたとしても、結果が変わってきていて、tenant_idいうもので1のデータしか見れないように設定すると、同じselect*fromUsersでも、tenant_idが1のものしか見れない状態にデータベースレイヤーで制御できます。
Row Level Securityがない状態だとコードで制限しない限りは全てのデータが見えるという状況だったので、こういう形でデータベースレイヤーで制限することが可能になりマルチテナントのセキュリティをデータベースレイヤーでも守ることができるのがSaaSにおけるPostgreSQLが使われてきた理由なのかなと思ってます。
RailsのPostgreSQLサポート
ようやくになりますが、Railsのサポートにちょっと入っていこうと思います。PostgreSQLのサポートの大きなところでいうと「型の多さ」みたいなところがあるかなと思っています。非構造のデータ型は結構よく知られてるとは思うのですが、配列のデータ型や、hstoreやUUIDなど拡張機能をONにしなければ使えないものがあったり、日付の範囲型などもあります。
日付の範囲型などは使えるケースも特にありえるかなと思いますが、開始と終了を二つのカラムを使ったりとかすることもあると思うのですが、それをあの範囲型とで定義できたりもします。
さらに最新の話についてですが、RailsだとPostgreSQLのサポートはマイグレーションが書きやすく管理がしやすくなるというのがあります。あとはPostgreSQL12や15などPostgreSQLがバージョンが上がったことによって使える機能というところもどんどんサポートされるという形になっていってます。
実際にサポートのイメージで言うと、元々PostgreSQLの機能は使えるは使えるので、無理やり頑張ろうと思えばSQLを直接実行すれば機能は使うことができます。ただ、migrationなどのコードとして見やすく書けるかというサポートが主になってきます。
サポートされる以前はのSQLで書いていたところをを、DSLで書けるようになったりと、はPostgreSQL12で追加された生成列(generated column)も、DSLで書けたりします。生成列はラストネーム、ファーストネームなど名前が分かれているときにそれを結合しフルネームとして扱うときにRailsのメソッドでやるという方法もありますが、データベースレイヤーでやる、ということが可能になります。
実際にそのフルネームを定義すると、ファーストネーム、ラストネームというように追加するだけで、自動的にフルネームを使うとこのように「山田太郎」と出るような、そんな機能になっています。この辺りのデータベースレイヤーでできるというところは、一つの技術的な選択肢が増えるいいことだと思っています。
Rails内でのテストの追加というところもしっかりされていて、このような自動生成のカラムというところも、Rails内でどのようなテストがされてるかというところは説明が細かくされています。
機能が追加されていく、ということはもちろんあって、SQLで実行する際も乗っていくとこのようなテストがしっかりとされていて、それを使うことができるという恩恵を得られるかなっと思っています。PostgreSQL15、16が直近そろそろ出てきたのかなという感じですが、15でいうとNULLS NOT DISTINCTというものがあります。メッセージが同じでもタグがNULLであれば、複数のレコードが利用できるというのが今までの書き方でしたが、NULLS NOT DISTINCTを使うと、NULLというのが個別のデータとして扱われない、というような状況になります。
実際はこのようにメッセージのタグでユニークにしたとしても、NULLは個別のデータとして扱われ、データが登録されてしまうのですが、NULL NOT DISTINCTにするとNULLは、それぞれ個別のデータとして制限ができます。
まとめに入っていこうと思います。Railsを最新にすることで、データベースの新機能というところも結構柔軟に使っていけるかなというところがあります。
一見、書きやすくなったというところがあるかもしれないですが、裏ではRails自体がしっかりテストだったり、サポートをしっかりしてくれていたりとか、自分たちでなかなか情報を追っていかないと気づけないというところもテストでカバーしてくれています。
PostgreSQLについては、カラムの生成はじめ様々な機能があります。PostgreSQL自体も最新を追っていく中で、実際の開発の状況にもよりますが選択肢が広がること自体は良いことだと思っています。このように、最新情報を追っていくということはエンジニアとしてとても大切だと考えています。
以上で、今日の発表を終わります。
ありがとうございました。
LT2:SHE株式会社 ソフトウェアエンジニア 錦織滉司
錦織と申します。SHE株式会社の開発ユニットでエンジニアをやっていまして、大体働き始めて半年ちょっとぐらいになり、Rails歴は9年ぐらいと、そんなところです。よろしくお願いします。
事業説明から入らせていただきます。SHE株式会社は2017年に創業した7期目のスタートアップで、キャリアの入口、社会の不均衡の是正を図いるということでいろいろやっていました。
Webのサービスをやっていまして、メインのサービスがWebデザインやWebマーケティングをPC1台でどこでも働けるスキルを学べる女性向けのキャリアのスクールを運営しております。
最近はこれまでのスクール事業に合わせて、そのスキルだったり価値観だったり、パーソナルなデータを軸に学ぶところと、その先でスキルを生かして働く「循環キャリアプラットフォーム構想」を掲げていまして、その学びの支援と働く支援が統合されたようなプラットフォームを目指して日々開発をしています。
技術的にどんなものを使っているのというところですが、ざっくりではありますがこちらの表になります。
画像のアップロード方法
今日は画像のアップロード方法についてお話したいと思いますが、皆さんがどれくらいやられているかわからないので、一旦紹介させてください。
以前PaperclipやCarrierWave、Shrineなどそういったライブラリを使って画像アップロードというものを作っていました。
Paperclipの仕入れもまだ使われて残っていたりするんですが、フォークされたkt-paperclipというものを使っています。それぞれ色々な設定の方法がライブラリごとに少しずつ違いますが、例えばAWSや、BCPだとクラウドストレージにアップロードしてそこへの参照の情報DBを持たせるという構成は多分どれも一緒かなと思っています。
Paperclipだと、ユーザーテーブルに四つぐらいカラムが入るかと思いますが、CarrierWaveだと多分JSONのカラムが1個入るぐらいと、違いはあるものの大体似たような構成かなと思います。
僕はRails5.1を最近だと思っていたのですが、めっちゃ前でした（笑）ActiveStorageというものが本体にバンドルされるようになりまして、PaperclipとかCarrierWaveでやっていた機能の主要なユースケースというものは、大体このActiveStorageがラップして提供してくれるようになりました。
アップロードされたファイルへの参照の情報をDBに持たせるという構造は、ここも大体一緒です。テーブルの構成がActiveStorageの場合、ファイルごとのテーブルを持たせます。ユーザーテーブルとの関連は、その接続用のポリモーフィック関連のテーブルがあり、そこで持つようになります。構成としてはアップロード先のストレージへの参照情報だけを持つという点はここでも同じになります。知ってる方も多いとは思うのですが、ファイルアップロードというとこんなものが使えますよねという改めての紹介でした。
リサイズ
リサイズの話をしたいと思います。画像アップロードされたものをリサイズする場合ですが、この図では300×300ピクセルをmediunと定義しています。100×100ピクセルはサムネイル用画像として定義しています。このようなことはCarrierWaveでもできますし、PaperclipもできてActiveStorageでもできます。一応そういうのがあるんですけど、これらってRMagikやMiniMagicというgemに依存しているんですよね。
そのgemは、またImageMagickという個別のコマンドラインツールに依存しています。なので、その前準備としてこれらをインストールしなきゃいけないということになります。アプリケーション内でリサイズをするのが結構つらいなというのは経験がある方も結構いらっしゃる気がします。コマンドラインツールのバージョンに依存したり、何か古いバージョンを入れなくてはいけないなど、画像処理なのでサーバーのリソース使いますよね。
小さいコンテナの割り当てとかにしていると落ちてしまうとか「MiniMagic使うと省エネだよ」ということもMiniMagickのREADME に書いてあるのですが、ActiveRecord Modelに各サイズの定義をしなきゃいけないということは結構ハードル高いシーンがあるかなと思っていて、普通の会社さんは結構困るシーンが多いんじゃないかなと思っています。
View側でサイズを渡すこともできるのですが、ActiveStorageのドキュメントを見ると、個別にキャッシュさせるためになるべくモデルに定義した方がいいよ、ということが書いてあります。Rails的にはモデルに色々なロジックを寄せようという思想だと思うので、そういったコンフリクトがあると思っています。。
一方、最近の CDN にはリサイズの機能を含んだものが出てきています。例えばimgixはクエリパラメータで幅や高さを出すと、そのサイズにして返却してくれるというものです。というのをいろいろ考えて前にいたチームではこうしました。アップロードは普通にActiveStorageで行いますが、クライアント側にはRailsのプロキシー URLではなくCDN のURLを直接返却し、クライアント側は受け取ったURLに任意のサイズでパラメータをつけてCDN にリクエストし、返却されてきた画像を表示するというものになります。このときはフロントはReactでレンダリングしていました。
このやり方であればReactの世界の中だけで完結しますし、リサイズにかかるコンピューティングリソースは外部化できて、依存しているライブラリの機能はるべく使わないで済むことになります。
サービスが大きくなっていくと、CDNを入れないと、ということになってくると思うので、そこにリサイズの機能を載せたら、結構楽な感じにできましたよという話でした。他社の事例も知りたいと思っているので、コメントをもらえたら嬉しいなと思っています。今日はありがとうございました。
LT3:株式会社Asobica プロダクト開発部 Webアプリグループ 西岡慎司
Asobicaの西岡です。本日はよろしくお願いいたします。Asobicaは東京の会社なのですが、私は兵庫県からフルリモートでお仕事させていただいています。役割としましてはWebアプリ開発エンジニアとして業務に従事していまして、経歴としては地元企業の介護事業者向け支援サービスの開発を行っていて、その後はベビーシッターのマッチングサービスの開発を経験した後にAsobicaへ今年の3月に入社いたしました。3社とも、RubyとRailsを使って開発をしています。家族は妻と6歳の長男と4歳の次男がおります。
弊社は五反田にある会社で事業内容としましてはロイヤル顧客プラットフォームの開発提供を行っております。我々の会社のミッションは遊びのような熱狂で世界を彩るというものを掲げております。
会社名であるAsobicaという名前にあります通り、遊び心であったりとか、熱中する・熱狂するということが働く上の心情であったり、プロダクトで世の中を変えていきたいなといったことが含まれています。
我々が提供するcoorum（コーラム）は、コミュニティ運営からロイヤル顧客のデータ分析をワンストップで行いまして、LTVの最大化と新規顧客獲得の効率化を行うサービスとなっております。
事業領域としましてはカスタマーサクセスといったような領域になっています。coorumでできることは4つありまして、ノーコードで簡単にオンラインコミュニティを開始できる点、顧客ロイヤリティを高めるための機能が標準装備されている点、PDCAを高速で回すユーザー分析機能、成果最大化に向けた手厚い支援、このようになっております。
CEMI
今日はCEMI（セミ）というものについてお話をしようと思っています。そもそもセミってなんやねん、という話になりますが、CSV Excel Macro Injectionと呼ばれる脆弱性のことでして、なぜ今日この話をするのかと言いますと私は3社経験しておりながらもCEMIについて知らず、もしかしたら同じように知らない方もいるのではと考えました。
実際CEMIと聞いて、Googleで検索をしても脆弱性的な話は全然出でこないのですが、CSVをセットで紐付けると少しだけ欲しい情報が出でくるかなといった感じです。
CEMIの仕組みについてお話したいと思います。個人的にクロスサイトスクリプティングと似たような感じなのかな、と思っております。例えば自己紹介の入力フォームがあったとして、悪意を持ったユーザーが、プロフィールのところに=1+1で入力をするとします。その後、こちらはエンドユーザーというわけになりますが、サービス管理者がユーザーデータをCSVでエクスポートするような機能があったとします。
CSV自体はただのカンマ区切りのテキストですので、開くこと自体に影響はないのですが、これを例えばエクセルなどにインポートした際、例えばさっきの1+1みたいな入力だった場合、1+1ですから2になる、というような仕組みになって、関数やマクロが実行されてしまいます。
これぐらいだと全然大したことはないのですが、ではこれの何が怖いのかというところと、その脆弱性についてです。Windowsはこういった=cmd ◯◯というようなコマンドを打つと、電卓が実行できるようになっています。
電卓だと全然かわいいものですが、例えば変なファイルをダウンロードしてきてインストールさせるだとか、そういったプログラムが実行できたりということもできてしまいます。そして、関数を使って悪意あるサーバーにアクセスさせることができるリンクを生成できたりして、攻撃をしたりパラメータを付与して同じCSV内にあるデータを情報を漏洩させるようなリスクがあります。
対策
対策についてですが、CSVを作成するときに、この三つの点で対応すればいいのではないかと考えています。
今日はRuby on RailsがテーマということなのでRubyを用いた対策についてご紹介しようと思うのですが、サンプルコードをご用意しました。まず最初に、ダブルクォートで囲むという対応ですね。CSVで出力するにあたってGenerateメソッドを活用する方法です。force_quotes:trueによって各セルがダブルクォートで囲まれるという仕組みです。
シングルクォートについて対応する際、古典的な方法にはなってしまうのですが、例えば先程の場合、自己紹介のところで何かが実行されそうでしたので、こちらの方にシングルクォートをつけてあげるといったような対応になります。文字列のダブルクォートですが、こちらは勝手に自動エスケープしてくれますので特に対応する必要はないかなと思っています。
発表は以上となります。日々、お取り引き先もありがたいことに増えていまして、Asobicaの事業にご興味のある方はぜひお声掛けいただけたら嬉しいです。
3社全てのLTが終わり、質疑応答タイムに移行しました。
下記は実際にいただいた質問に対しての回答となります。
Q1.サービスのスケーラビリティを考慮した際に直面する課題や対策はありますか？Railsでのスケーラビリティの向上方法について教えてください。
RailsでいうとRspecなどでテストが書きやすい点があるのでテストをしっかりやりつつ、スケールに適応させていく構造にリファクタリングしていくのが良いかと思っている。重い処理については、非同期処理などについてもSisekiqなどがサポートがされているのでそういった部分にうまく逃がすというのもひとつの手法。（井上さん）
自分たちの場合はDatadogを活用していてここで時間がかかっているというのを細かく把握することができているので計測をしっかり行った上でひとつずつ潰していくというのが一番早い方法（錦織さん）
セキュリティ・パフォーマンス・インシデントPJというものを週１度開催し、webアプリエンジニア、インフラエンジニアメンバー一丸となって意見を共有したりアイデアを出し合いながら対策を行っている。（西岡さん）
Q2.Railsの最新のアップデートや新機能については、常に追いついていますか？アップデートの際に注意すべきポイントはありますか？
Railsだけではなく、他のgemにも関連してくるので、そのgemが長く付き合えるものかというところ、gem自体もgem依存をしていたりするので、その依存先は長く保てるもなのかというところは結構注意をした上で選定をしている。（井上さん）
Rails自体のアップデートは、最近はそこまで破壊的な変更は入ってきていないので、gemの相性やなるべく変なgamを入れないように心がけることなど、アップデートのときのつらみを少なくするように普段から開発していくことに意識を向けている。（錦織さん）
リリースノートを確認するなど、破壊的な変更がないかを確認しながら安全に周りを固めてからRailsのアップデートを行うように注意している。（西岡さん）
Q3.Railsエンジニアのキャリアパスやスキルアップにおすすめの学習リソースはありますか？エンジニアリングコミュニティへの参加やオープンソースプロジェクトへの貢献方法についても教えてください。
今日のようなイベントに参加していくと実際使ってみたときの生の知見なども聞けて、本では学べないところもあり有意義かなと感じている。オープンソースの貢献については、gemなどで業務で問題に引っかかったり、Railsの最新を使ってバグに遭遇した場合、ISSUEを立ててみたりとか、修正のPRや報告を歓迎をしてくれてる優しいコミュニティだと思うのでそういうところで勇気を出してやってみることがとて良いと思っている。（井上さん）
Railsは良くも悪くも味付けが濃いというか、思想が強いと感じていて、他のフレームワークを触ってみて「Railsとの違いがこういうところにあるんだ」と理解してみることは結構いいんじゃないかなと思う。コミュニティへの参加については定期開催されてたりする会がいっぱいあると思いますし、Rubyだとすぐgemを作れると思うので、まず作ってみるのもいいのでは（錦織さん）
疑問に思ったり行き詰まったことをドキュメントを見たりUdemyを使ったり、技術書籍を読んだりなどしてひとつずつ潰していくというのがよくあるやり方ではあるものの、良い方法。コミュニティについてはRuby以外でも地域のエンジニアコミュニティがあり、実際に顔を合わせたりSlackやDiscordなどでのやり取りから自分がキャッチアップできなかったやり取りを取りに行くということをしている。（西岡さん）
今回は初めての技術的なイベントということで、どのような会になるか私もとても楽しみだったのですが、それぞれ3社異なる視点からのLTで、参加者の方にとっても学びも多い会になったのではないかと思っています
直近はオフラインのイベントが続いていましたが、今後はさまざまなテーマでオンラインの会も開催予定です。情報は随時私SahoのXやこちらのnoteで発信予定ですので、ぜひぜひチェックしてくださいね。
いかがでしたでしょうか？
今回も、最後までお読みいただきありがとうございました！
また次回の記事でお会いしましょう！
ROSCAでは、エンジニアに最適なキャリアを選択してほしいという思いから知識を持ったキャリアアドバイザーが毎日厳選したクライアントのみに絞ってお仕事のご支援をさせていただいております。
少しでも関心をお持ちいただけましたら、ぜひお問合せください。
今回も最後までお読みいただきありがとうございました！
また次回の記事でお会いしましょう！
ROSCAの話を詳しく聞きたい！興味があるという方はこちらの募集からどうぞ！
この記事が気に入ったらサポートをしてみませんか？