Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

20210226_出張!Railsウォッチ in 銀座Rails#30

Masato Mori
February 26, 2021

20210226_出張!Railsウォッチ in 銀座Rails#30

Masato Mori

February 26, 2021
Tweet

More Decks by Masato Mori

Other Decks in Programming

Transcript

  1. 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

  2. これまでの出張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 

  3. 今日の概要
 • Railsが世の中に使われるようになって早十数年
 • Railsサーバーを動かす環境も色々な選択肢が増えた
 • @morimorihoge の分かる範囲の歴史を振り返りつつ、新 旧方式の整理を試みる
 •

    整理の観点
 ◦ Rackアプリケーションサーバー 
 ◦ Deploy先インフラ環境 
 ◦ 他にも色々な要素はありますが、今日はこの二つ 
 6

  4. Unicorn
 • 現在主流のPumaになる前に最も使われていた(と思われる)
 ◦ 少し古めのRailsアプリケーションなら今も使われているのを見るかも知れない 
 • シングルスレッド・マルチプロセス(master-slave)設計のため、Railsアプリケーションのマ ルチスレッド化の流れの中で使われなくなっていった
 ◦

    マルチスレッド化を考慮されていなかった昔のRailsアプリではスレッドセーフでない実装がされていることがま れにあった
 ▪ グローバル変数的なSingletonクラスをクラスインスタンス変数で実装してしまうと死 😇
 ▪ 現代ではAS::CurrentAttributesを使いましょう(これも賛否両論ありますが・・・) 
 ◦ 静的ファイル配信にWorkerを使わせたくない ため、Nginx + Unicornという鉄板構成が使われるようになった 
 • ちなみにGitHubはUnicornを使っている(RubyKaigiでも高速化の話題になることが多々)
 • 今からunicornを使いたいならRainbows!というのもあるらしい(こちらはUnicornベースで マルチスレッド化などに対応しているらしい)
 9

  5. Puma
 • 現在のRailsにおけるデフォルトRackアプリケーションサーバー
 • マルチプロセス・マルチスレッド設計で、より少ないリソース(主にメモリ)で同時に多 数のリクエストを捌けるようになった
 ◦ 現代のRailsアプリは普通にマルチスレッド対応で書くはずなので、新規なら特に意識せずに実装し て良い
 ◦

    マルチスレッド非対応なGemを利用する場合には要注意 
 ▪ 1リクエストの中でグローバル変数が欲しい場合は AS::CurrentAttributes を使いましょう
 • SSL/TLS LISTENモードやControl URL機能なども備えており、大抵の用途に耐え られる
 10

  6. 最近聞かなくなった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で再起動させたりしたなあ(遠い目 

  7. Linuxサーバーの上でそのまま動かす
 • オンプレ(実機)、VPS、VM問わず、Linuxサーバー上にRubyをインストールし、Rails サーバーを直接プロセスとして実行する方式
 ◦ 何も考えずに普通に動かそうとすると多分これです。Deployはcapistranoを使ったりする 
 ◦ Rails Tutorialの開発環境であるAWS

    Cloud9はこれです 
 • 利点
 ◦ 最もベーシックな方法なので、構築段階でトラブルに遭遇しにくい 
 ◦ SSHしてトラブルシューティングなどができるため、一般的なLinuxシステム管理者にも馴染み易い 
 ◦ 手元の余ってるノートPCで自宅サーバーを立てたりなど、雑用途としてお手軽 
 • 欠点
 ◦ Linuxサーバーレベルでシステムを管理しないといけないため、OS脆弱性やプロセス監視、自動起 動設定などを自前で管理する必要がある 
 ▪ Ansible等で自動化は可能だが、それはそれで管理が必要 
 ◦ SSH作業を許容すると、サーバー環境の再現性が低下しやすい(属人性が上がりがち 
 14

  8. Dockerコンテナで動かす
 • RailsアプリケーションをDockerコンテナイメージとしてビルドし、コンテナを実行環境 にDeployする
 ◦ 動作環境はECSやFargate、k8s、素docker-compose、HerokuのDocker deployなど様々あるがここ ではとりあえずまとめる 
 •

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

  9. 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

  10. 今回扱わなかったその他の要素
 • NginxなどのWebサーバーを併用するか?
 • CDNなどの利用はどうする?
 • 他のサービスの併用の可能性(S3などのObject Storageなど)は?
 • 対障害性や可用性をどう見積もるか?


    
 • その他ツッコミどころが多数あると思いますが、そういったものを考慮に入れた場 合、自分ならどういう提案をできるかを考えてみると訓練になります
 17

  11. 今新しくRailsサービスを立てるとしたらどうする?
 • 趣味で自分や身内用のサービスを立てるなら?
 • 趣味でPublicなサービスを立てるなら?
 • 事業・業務として無償のサービスを立てるなら?
 • 事業・業務として有償のサービスを立てるなら?
 •

    1週間でフルスクラッチからサービス作ってくれと言われたら?
 • etc.
 18
 この逆に、適当な組み合わせを想定し、その構成がより妥当に見えるにはどんな条件を加えると良い か検討してみる、というのも特訓になります