出張！Railsウォッチ
 in 銀座Rails#30
 森 雅智 / @morimorihoge 2021/02/26 1
 特集：～Railsインフラ環境Overview～
 
 


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を振り返る
 ○ 銀座Rails#29: Serverless Railsを試す
 4
 各回資料に興味がある方は以下URLからどうぞ 
 https://speakerdeck.com/morimorihoge 


Railsインフラ環境Overview
 5


今日の概要
 ● Railsが世の中に使われるようになって早十数年
 ● Railsサーバーを動かす環境も色々な選択肢が増えた
 ● @morimorihoge の分かる範囲の歴史を振り返りつつ、新 旧方式の整理を試みる
 ● 整理の観点
 ○ Rackアプリケーションサーバー 
 ○ Deploy先インフラ環境 
 ○ 他にも色々な要素はありますが、今日はこの二つ 
 6


Rackアプリケーションサーバー
 ● そもそもRailsはRackアプリケーションの一種
 ● Rackアプリケーションサーバーは、Rackアプリケーションを実行することのできる Webサーバー
 7
 出典： https://medium.com/quick-code/rack-middleware-vs-rack-application-vs-rack-the-gem-vs-rack-the-architecture-912cd583ed24


WEBrick
 言わずと知れたCRuby本体にbundleされたWebサーバー
 -> Rubyさえ入っていれば追加GemなしにWebサーバーを立てられる
 8
 Ruby 3.0からはbundled gemから外れたため要注意
 see: https://bugs.ruby-lang.org/issues/17303
 というのは過去の話で・・・


Unicorn
 ● 現在主流のPumaになる前に最も使われていた（と思われる）
 ○ 少し古めのRailsアプリケーションなら今も使われているのを見るかも知れない 
 ● シングルスレッド・マルチプロセス（master-slave）設計のため、Railsアプリケーションのマ ルチスレッド化の流れの中で使われなくなっていった
 ○ マルチスレッド化を考慮されていなかった昔のRailsアプリではスレッドセーフでない実装がされていることがま れにあった
 ■ グローバル変数的なSingletonクラスをクラスインスタンス変数で実装してしまうと死 😇
 ■ 現代ではAS::CurrentAttributesを使いましょう（これも賛否両論ありますが・・・） 
 ○ 静的ファイル配信にWorkerを使わせたくない ため、Nginx + Unicornという鉄板構成が使われるようになった 
 ● ちなみにGitHubはUnicornを使っている（RubyKaigiでも高速化の話題になることが多々）
 ● 今からunicornを使いたいならRainbows!というのもあるらしい（こちらはUnicornベースで マルチスレッド化などに対応しているらしい）
 9


Puma
 ● 現在のRailsにおけるデフォルトRackアプリケーションサーバー
 ● マルチプロセス・マルチスレッド設計で、より少ないリソース（主にメモリ）で同時に多 数のリクエストを捌けるようになった
 ○ 現代のRailsアプリは普通にマルチスレッド対応で書くはずなので、新規なら特に意識せずに実装し て良い
 ○ マルチスレッド非対応なGemを利用する場合には要注意 
 ■ 1リクエストの中でグローバル変数が欲しい場合は AS::CurrentAttributes を使いましょう
 ● SSL/TLS LISTENモードやControl URL機能なども備えており、大抵の用途に耐え られる
 10


Phusion Passenger
 ● 商用版（Enterprise）のあるアプリケーションサーバー
 ● Passenger自体はRack以外にもGolangやElixirをホストすることができる より高機能サーバーとなっている
 ● マルチスレッド対応したければEnterprise版を使う必要があるため、商 用サポートを受けたいなどの事情がなければ気軽に使うのはなかなか 難しい
 ○ が、選択肢の一つとして知っておくのは良さそう
 11


最近聞かなくなったRackアプリケーションサーバー
 ● Mongrel: Rails 2系の頃まで良く使われていた
 ○ 最終更新が2008年のため多分WebSocket対応しておらず今後新しく使うことはなさそう
 ○ 当時はNginxが今ほど使われておらず、Apache + Mongrelという構成が多かった記憶がある
 ● Thin: Ruby 1.8系時代に使われているのを見た
 ○ after Mongrel時代、のような扱いをされていた記憶がある
 ● Phusion Passenger（OSS版）: Ruby 1.8系黄金期を支えた
 ○ Apache / Nginxモジュールとして組み込みができ、高機能だったため広く使われていた
 ○ REE（Ruby Enterprise Edition）＋PassengerがRails3.0の頃は定番だった記憶
 ○ Passenger自体は今もActiveで、Enterprise版がある貴重なプロダクト
 12
 昔話感あります。懐かしい・・・ 
 ＃ 昔のRailsサーバーは定期的にkillerで再起動させたりしたなあ（遠い目 


Deploy先インフラ環境
 ● どこでRailsサーバーをどうやって動かすかという選択
 ● 組み合わせ次第で無数に選択肢があるが、ここでは代表的と思われるものから pickupします
 ● ここではCRubyを前提とします
 ○ JRubyは経験ないので有識者の方がいたら懇親会とかでぜひ聞いてみたい・・・ 
 13


Linuxサーバーの上でそのまま動かす
 ● オンプレ（実機）、VPS、VM問わず、Linuxサーバー上にRubyをインストールし、Rails サーバーを直接プロセスとして実行する方式
 ○ 何も考えずに普通に動かそうとすると多分これです。Deployはcapistranoを使ったりする 
 ○ Rails Tutorialの開発環境であるAWS Cloud9はこれです 
 ● 利点
 ○ 最もベーシックな方法なので、構築段階でトラブルに遭遇しにくい 
 ○ SSHしてトラブルシューティングなどができるため、一般的なLinuxシステム管理者にも馴染み易い 
 ○ 手元の余ってるノートPCで自宅サーバーを立てたりなど、雑用途としてお手軽 
 ● 欠点
 ○ Linuxサーバーレベルでシステムを管理しないといけないため、OS脆弱性やプロセス監視、自動起 動設定などを自前で管理する必要がある 
 ■ Ansible等で自動化は可能だが、それはそれで管理が必要 
 ○ SSH作業を許容すると、サーバー環境の再現性が低下しやすい（属人性が上がりがち 
 14


Dockerコンテナで動かす
 ● RailsアプリケーションをDockerコンテナイメージとしてビルドし、コンテナを実行環境 にDeployする
 ○ 動作環境はECSやFargate、k8s、素docker-compose、HerokuのDocker deployなど様々あるがここ ではとりあえずまとめる 
 ● 利点
 ○ コンテナ実行環境とアプリケーションコンテナが明示的に分かれるので、作業分担が比較的やりや すくなる（実行環境にManagedなものを使えば、アプリケーションに集中できる） 
 ○ ビルド環境やDeploy環境が一通り整備されればDockerやLinux環境にそこまで詳しくない人でも Deployできる
 ○ ローカル開発環境もコンテナ化しておくと、複雑な動作要件のシステムの新規セットアップの手間を 短縮できる
 ● 欠点
 ○ 様々なコンテナ実行環境によって具体的なdeploy方法や機能上の制限などが異なるため、コンテ ナ環境についての学習が必要 
 ○ 最初の環境構築セットアップの手間がやや大きく、チョロいプロトタイプアプリをとりあえず動かした いといった用途だとoverkill過ぎると感じることも 
 15


Heroku Git Deployで動かす
 ● PaaS（Platform as a Service）であるHerokuを使い、Gitリポジトリをgit push deploy する
 ○ Rails Tutorialの本番環境がこれです(git push heroku masterでdeployする) 
 ● 利点
 ○ Linuxやインフラ知識に自信がない人にとってはセットアップやdeployが 圧倒的に楽
 ○ Managedサービスであり、お任せ可能 
 ○ 昔に比べるとEnterprise機能などが充実 してきており、💰に目を瞑ってよければかなりのユース ケースをカバーできるようになった 
 ● 欠点
 ○ かなりheavyにHerokuにロックインされてしまう 
 ■ 金の弾丸で解決できない問題にぶつかったときのリスクが大きい 
 ○ ある程度以上の信頼性のあるサービスをproductionレベルで運用しようとするとかなりお高くなって しまいがち
 ■ ビジネスのコアとなるシステムを載せる場合には、将来どうなる可能性があるのかを注意深く 検討しておく必要がある 
 16


今回扱わなかったその他の要素
 ● NginxなどのWebサーバーを併用するか？
 ● CDNなどの利用はどうする？
 ● 他のサービスの併用の可能性（S3などのObject Storageなど）は？
 ● 対障害性や可用性をどう見積もるか？
 
 ● その他ツッコミどころが多数あると思いますが、そういったものを考慮に入れた場 合、自分ならどういう提案をできるかを考えてみると訓練になります
 17


今新しくRailsサービスを立てるとしたらどうする？
 ● 趣味で自分や身内用のサービスを立てるなら？
 ● 趣味でPublicなサービスを立てるなら？
 ● 事業・業務として無償のサービスを立てるなら？
 ● 事業・業務として有償のサービスを立てるなら？
 ● 1週間でフルスクラッチからサービス作ってくれと言われたら？
 ● etc.
 18
 この逆に、適当な組み合わせを想定し、その構成がより妥当に見えるにはどんな条件を加えると良い か検討してみる、というのも特訓になります 


まとめ
 ● Railsインフラ環境として、Rackアプリケーションサーバーとそれを動作させるインフ ラ環境について簡単にoverviewしてみました
 ● Railsサービスをリリースするというだけでも色々な選択肢があるので、それぞれの メリット・デメリットを自分なりに理解しておき、必要なときに引き出しから出せるよう にしておくと、より柔軟な対応ができるようになります :)
 19


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