出張！Railsウォッチ
 in 銀座Rails#29
 森 雅智 / @morimorihoge 1
 特集：～Serverless Railsを試す～
 
 


About Me
 ● 森 雅智： @morimorihoge
 ● BPS株式会社でRailsの受託開発チームをやってたり、週1大学非常勤で Web開発を教えてたりします
 ● Ruby/Rails歴は11年くらい。Web開発は17年くらい
 ● 銀座Ralis #10でActiveRecordでVIEWを使おうという話をしました
 ● 銀座Rails #27でアプリケーションコンフィグの話をしました
 About BPS & TechRacho
 ● Web受託開発や電子書籍製品開発をやっている会社です
 ● TechRachoという自社技術Blogを運営しています
 ○ 3年半ほど前から平日毎日更新してます
 ○ https://techracho.bpsinc.jp/ ● お仕事相談、転職相談、TechRachoへのご意見など気軽にどうぞ
 ○ https://www.bpsinc.jp/ 2


Railsウォッチとは？
 技術ブログTechRachoで毎週連載しているRails / Ruby界隈を中 心とした雑多な情報を提供する技術雑談マガジン
 3


これまでの出張Railsウォッチのピックアップテーマ
 ● Rails6新機能特集
 ○ 銀座Rails#12: 複数DB対応
 ○ 銀座Rails#13: ActionText、Trix
 ○ 銀座Rails#14: ActionMailbox
 ● Railsアプリケーション開発に関する雑多なテーマ
 ○ 銀座Rails#15: production、development、staging環境について
 ○ 銀座Rails#16: 機能開発の設計レビューについて
 ○ 銀座Rails#17: リソース管理スコープについて
 ● 開発一般な話
 ○ 銀座Rails#19: 開発チームの冗長化について
 ○ 銀座Rails#20: Excelと仲良くしよう
 ○ 銀座Rails#21: 標準仕様を読むためのABNF
 ○ 銀座Rails#22: CLIプログラムにOptionParserを使う
 ○ 銀座Rails#23: ActiveRecordのSELECTベンチマーク
 ○ 銀座Rails#24: 令和Devise事情
 ○ 銀座Rails#28: 2020年の銀座Railsを振り返る
 4
 各回資料に興味がある方は以下URLからどうぞ 
 https://speakerdeck.com/morimorihoge 


～Serverless Railsを試す～
 5


今日の概要
 ● RailsとServerless環境の相性の悪さ・難しさについて
 ● 巷のServerless Rails系ライブラリを取り上げ
 ○ Jets: https://rubyonjets.com/
 ○ Lamby: https://lamby.custominktech.com/
 6
 ※Serverlessという言葉がややバズワード気味だが、ここではいわゆるFaaS（Function as a Service）上で動作させるWebサービスのこととします
 また、今回紹介するGemは両方ともAWS前提です


Serverless「でない」アプリケーションの例
 いわゆるアプリケーションサーバープロセス（に相当するもの）が事前に起動しており、リ クエストに応答する方式
 7
 例）Railsにおけるpumaやunicornサーバー
 例）PHPにおけるphp-fpmサーバー
 例）JavaにおけるTomcatサーバー
 特徴
 アプリケーションサーバープロセスは初回起動に時間がかかっても良いが、起動後のリ クエストの応答は即座に返す必要がある
 ※Workerプロセス/スレッドはリクエスト処理後、終了せずに次のリクエストを待ち受ける （サーバー上に残り続ける）


Serverlessアプリケーションの例
 FaaS（Function as a Service）プラットフォームに関数が登録されており、URLなどの条件 によって登録された関数を呼び出してレスポンスを返す
 8
 例）AWS Lambda + API Gateway
 例）Google Cloud Functions
 特徴
 FaaSプラットフォーム側で動かす関数は都度プロセスとして呼び出され、事前にWorker を立ち上げて待ち受けるようなことは（概念上は）しない。
 そのため、起動～レスポンスを返すまでが高速である必要がある
 ※サーバー上のメモリは都度解放されてしまうため、preloadコストが重い


Railsの特徴とServerlessの相性
 Railsは実行サイズが大きくアプリケーションの起動（初期化～リクエストを受け付けるま で）にかかる時間が大きいため、リクエストの都度プロセスを実行するようなアーキテク チャと相性が悪い
 ※ファイルキャッシュなどを駆使して速度を上げることはできなくはないが、限界がある
 とはいえ世の中ではServerlessアーキテクチャが流行っているので、RailsでServerless 的なことをやってみようという試みがある
 ● Railsサーバーの管理をしたくない
 ● DeployをManagedなサービスに乗せたい
 などなど（今ではServerlessじゃなくてもk8sなりFargateなりを使って↑に近いことを実現 する方法があるので、Serverlessにしないとできないわけではない）
 9


Serverless Railsなプロジェクト
 Ruby on Jets
 ● https://github.com/boltops-tools/jets
 ● Railsライクなインターフェースを持つ
 フルスタックなAWS Serverlessフレームワーク
 Lamby
 ● https://github.com/customink/lamby
 ● AWS Lambda FunctionとしてRailsのコードを動かすライブラリ
 10


Ruby on Jets
 ● Railsライクにコードが書けるフレームワーク
 ● Railsのコードそのものが動くわけではないが、概ねRailsと同じようなコードを書けば 動作する
 ● Deploy先はAWS Lambda ＋ API Gatewayで、actionごとのRubyコードに分解した Lambda Functionとして登録される
 RubyKaigi 2019でも発表がありました
 ● https://rubykaigi.org/2019/presentations/tongueroo.html
 11


Jetsを使ってみる
 ローカルサーバーモードがあり、すんなり動かすことが出来る
 AWSアカウントも不要なので、やってみるのがわかりやすいです
 12
 https://rubyonjets.com/quick-start/

Jetsのdeploy
 AWSアカウント設定をした上で `jets deploy`を実行することで、AWS CloudFormation経 由で必要なリソースが自動的に作られていく
 ● webpack compile
 ● ソースコードのZIPアーカイブ
 ● ZIPアーカイブのS3アップロード
 ● Controller Actionに対応するLambda Functionの登録
 ● API Gatewayの設定
 ● IAM Roleなどの設定
 ● その他諸々
 環境変数JETS_ENVでproduction / development切り替えも可能
 ※この発表向けに最新のJetsを落としてきて動かしてみたのですが、どうも直近deploy がこける（ShowLambdaFunctionが作成失敗する）ようです


Jetsを本番で使ってみてハマったところ
 ● デフォルトだとAWSの公式Ruby Lambda Layerを使うため、Rubyのマイナーバージョ ンがAWS都合で更新されることがある
 ○ Ruby本体のbundled gemがGemfile.lockに記述されていると、ある日突然エラーを吐くようになる （CVE-2020-10663の対応時にドハマりした・・・ ）
 ○ 自作のLambda Layerを使うなどで対策可能 
 ● Hyper-V上のLinuxを使っていてPC本体のsleepが原因でdeployを実行するLinux側 の時刻が実時間と大幅にずれていると、AWS APIが失敗してdeployできない
 ○ これはAWS API一般？の問題だが、知らないとハマる 
 ● nativeライブラリをリンクするGemを利用する場合、利用するLambda Layerにインス トールされていないものは動かない
 ○ BoltOps（Jets開発元）がServerless Gemsという有償Gem配信サービス？を使うとcompiledなGemを 使えるようだ（が、どれくらいActiveなサービスなのかは不明 
 ■ https://www.serverlessgems.com/ ○ これもCustom Lambda Layerを作れば解決できるはず 14


Jetsの良いところと悪いところ
 ● 良いところ
 ○ 書き慣れたRails的コードで書けるのは良い 
 ■ Pure Rubyで書くには複雑だけどRails環境作ってまではしたくない・・・みたいな 単機能API サーバーなどに良い
 ○ 生成されるコードが1 action 1 lambda functionになるため、AWS X-Rayなどでトラッキングしたり、 CloudWatch Logsのストリームが追いやすい 
 ○ 1つ1つのLambda Functionの呼び出しはそれなりに高速 
 ○ Lambda側コンテナのpreheating機能などがビルトインされているため、そこまでLambda自体に詳し くなくてもそこそこにJets wayに乗れる 
 ● 悪いところ
 ○ Railsのコードそのものが動くわけではない ので、Jetsのドキュメントを見つつどういう書き方がサ ポートされているかを確認しながら実装する必要がある 
 ○ DBはRDS Lambda Proxyを使うなり、DynamoDBを使うなどの工夫が必要 
 ■ ドキュメントを読む限りではConnectionはlambda execution contextに維持しているので、 Lambda呼び出しの度にDB接続するようなことはないらしい（未確認） 
 15
 複数のURLを持ち、リクエスト数が大幅に増減するような小さなAPIサーバーなどには向 いている


Lamby
 LambdaからRackを呼び出してRails のコードそのものを動かしちゃおう ぜというライブラリ
 Deploy先はAWS Lambda + API Gatewayだが、Lambdaは Rails&Lambyをまるっとバンドルした Lambda Containerを実行する（全て のリクエストを1つのLambdaで受け る）
 16


Lambyを使ってみる
 Docker-Composeがあればすんなり動作するのでやってみると良いです
 https://lamby.custominktech.com/docs/quick_start
 17
 ※見せられる時間があれば動いているコンテナ＆LambdaのCloudWatchメトリクスを demoる


Lamby触ってみた所感
 まだちゃんと触り切れてはいないが、Railsのコードが普通に動いていることに驚く
 Cold Start時は起動に7-8秒かかるが、preheat時はただのテキストを返すだけであれば 5-80ms位なので、思ったほど遅くない印象
 ドキュメントを読みつつRDS-Proxy接続を試そうとしてみたのだが、まだ成功できず。発 展途上中のプロジェクトという印象
 実際に本番運用を考えるとしても、URL別のメトリクスをAPI GatewayやLambdaから取れ ないため、FaaSの持つ監視・計測機能が効果的に使えないなど課題もある
 とはいえ限定的な用途であれば非常に安いRailsサーバーとして利用できなくもなさそう なのと、構造上Google Cloud Functionなどにも応用が利きそうなので、面白いかもしれ ない
 18


まとめ
 ● RailsをそのままServeless環境で動かすことの難しさを解説した
 ● Serverless Rails実現のアプローチとしてJetsとLambyの2つを紹介
 ○ JetsはRails風のServerlessフレームワーク。FaaSのアーキテクチャに合わせたdeployがさ れるため、Serverlessの良さを享受できるがRailsそのものではない 
 ○ LambyはLambdaハンドラからRailsを無理矢理動かすアダプタ。Railsそのものが動くので 既存Railsのノウハウが利用できる一方、FaaSの思想に乗らない分管理面では課題もあり そう
 ● どちらも既存のRailsサーバー環境を置き換えるような利用方法には向いてなさそうだが、うまく 使えるケースがあれば追いかけてみると面白いかもしれない 
 19


次回以降もブラッシュアップしていきます
 感想・リクエストなどあればTwitter
 #ginzarails
 @morimorihoge
 @hachi8833
 までお声かけください
 20