Ruby on Rails on Kubernetesってどうなの?

Ruby on Rails on Kubernetes ってどうなの？ 2024/12/12 (Thu.) 小林悟史(noel) ブルーモ証券株式会社 Omotesando.rb#104 & Roppongi.rb#25

■ 小林 悟史（小林 ノエル） @free_world21 ■ 本業：ブルーモ証券株式会社 取締役CTO – 米国株・米国ETF専業の長期資産形成特化 型の投資アプリを作ってるFintechスター トアップ https://bloomo.co.jp/ ■ 10年+ ほどフリーランスエンジニア – 途中事業会社の中の人もやった ■ 2022〜：ブルーモ証券株式会社を創業 THE FARM@NY ■ 趣味：旅行・世界のコワーキングスペースめぐ り（ワーケーション的な何か） CARR WORKPLACE@Chicago

• https://bloomo.co.jp/

■ 小林 悟史（小林 ノエル） @free_world21 ■ 本業：ブルーモ証券株式会社 取締役CTO ー メ イ の た 1 2 っ d l ら r o も w ̲ て が e っ e ク fr 作 ー を パ 像 マ 画 ー ジ テ の 😂 謎 誕 ら 爆 THE FARM@NY – 米国株・米国ETF専業の長期資産形成特化 型の投資アプリを作ってるFintechスター トアップ https://bloomo.co.jp/ ■ 10年+ ほどフリーランスエンジニア – 途中事業会社の中の人もやった ■ 2022〜：ブルーモ証券株式会社を創業 ■ 趣味：旅行・世界のコワーキングスペースめぐ り（ワーケーション的な何か） CARR WORKPLACE@Chicago

• https://bloomo.co.jp/

『Ruby on RailsをKubernetesクラスタで運用する のってどうなの？』に主観的な観点でお答えします ■ ブルーモ証券でのテックスタック構成でのお話 – Flutter/Ruby on Rails/Golang/GKE(Google Kubernetes Engine) ■ まとまった一般論やメリット・デメリットの紹介というより、やってみての感想や『こんな観 点を持ちながら使ってる』というレベルのお話として聞いて下さい

前提1： コンテナベースのインフラとして構築する際の選択肢 0. VMインスタンスを用意して、コンテナ化せずcapistranoでコードを直接デプロイ – 2010年代前半くらいまではこの形が主流だった 1. VMインスタンス用意してその中でdocker composeでがんばる – 🟢 構成がシンプルでバックエンド書ける人なら大体さわれる – ❌ オートスケールや自動復旧、ロードバランサとか自分で作成・設定しないといけ ない 2. Managed系コンテナサービス（＝ECS） – 🟢 ↑のデメリットが概ねmanagedになる – ❌ ロックオン。ロードバランサとかは引き続き自分で作成・設定する必要あり 3. Kubernetes – 🟢 ポータビリティ。「k8s使ってます！」って言えるとなんかｶｯｺｲｲ（個人の感想 です）。ロードバランサまで含めてすべてKubernetesの管理対象 – ❌ 学習コスト

前提2：KubernetesはGolangで作るマイクロサービスアー キテクチャとの相性が良い on – – – – 1つの巨大モノリス、もしくはそこそこ大きい複数のモノリスを組み合わせた構成とかが多い 立ち上がるコンテナ（＝プロセス）の数も限定的 1つ1つのコンテナに大きめのリソース（CPU、メモリ）を割り当てる必要がある Rails界隈ではあまり採用されていないイメージ on – マイクロフレームワークが多いので1つ1つのサービス（＝プロセス）は大きくせずに、複 数の細かいサービスを組み合わせて巨大サービスを実現する構成が多い（マイクロサービ スアーキテクチャ） – 1つ1つのコンテナに必要なリソース（CPU、メモリ）は少なくて済む – 各サービスごとに複数のコンテナを立ち上げるので最終的なコンテナ数がどんどん増える – Golangでサービス作る場合はまず第一の選択肢としてあがる

観点1：1つの最終系の形を最初から見据えて開発できる ■ Railsコンテナは数個のモノリス、Golang側は複数の（マイク ロ？）サービス ■ それらを一括で管理したいならなんだかんだ最終的には Kubernetesに行き着く気がする ■ たとえば将来的にこんなこともできる – （必要に応じて）PRごとに動作確認環境が自動でできあがる – ちょっとした検証環境ならDBやクラウドストレージも Kubernetesの中に構築できる ■ RDSやS3をk8s内に構築できると思ってもらってOK 最終形？

観点2：アプリケーションエンジニアとインフラエンジニア の垣根をなるべくなくせる ■ Kubernetesに乗せられるもの（ミニAWSみたいなもの） – EC2 – Auto Scaling + Auto Healing – 内部向け(Internal)＆外部向け(External) Load Balancer – Networking – 環境変数管理（ConfigMap） – Secret Manager – Job Scheduler ■ これらを宣言的なコード（yamlファイル）として記述可能 ■ 誰がどこまでやるかは会社やチームの状況次第だが、アプリケー ションエンジニアがk8sのyamlまで染み出して書くケースも多い

観点3：ポータビリティー ■ AWSでもなんだかんだ大規模障害とかおきる – 落ちないサービスはない ■ 突然の大規模障害、突然のサービス終了、突然の大幅規制 （利用制限）、突然の大幅値上げなどなど、何が起こるかわ からない ■ いざというときは『他のクラウドに移れるようにしておこ う』という視点は持っているに越したことはない – 実際にできるかどうかは別として ■ 前述の観点2がKubernetes管理対象なので他のクラウドに 移った際に（だいたい）同じyamlファイルで（だいたい）同 じ構成が作れる

観点4：イメージ（どのように見られたいか） ■ Kubernetes＝大規模サービスや大企業サービスとかで使わ れてる ■ それを使ってる＝大規模サービスっぽそう、大規模サービス を目指してる、将来的にスケールしそう、などなど… ■ 大規模サービスの構築・運用経験のあるエンジニアの転職候 補先として候補にのる（かもしれない） ＝

おわりに Ruby on Rails on Kubernetes やってみたくなった方！ We are Hiring！ https://careers.bloomo.co.jp/

• https://careers.bloomo.co.jp/