Upgrade to Pro — share decks privately, control downloads, hide ads and more …

デプロイの先まで全部面倒を見る ― Kamal を社内 PaaS に育てた話

Avatar for dkan75 dkan75
October 19, 2026

デプロイの先まで全部面倒を見る ― Kamal を社内 PaaS に育てた話

Avatar for dkan75

dkan75

October 19, 2026

More Decks by dkan75

Other Decks in Technology

Transcript

  1. Kaigi on Rails 2026 デプロイの先まで全部面倒を見る ― Kamal を社内 PaaS に育てた話

    神田 博之 @dkan75 株式会社ソニックガーデン / インフラプログラマ から数分でサービス公開。 その裏側は、Kamal をラップした Rails アプリ。 rails new
  2. 自己紹介と、今日の流れ 神田 博之 ソニックガーデン インフラプログラマ AWS を中心に、IT インフラに約15年 Rails 歴は1年ちょっと(Ruby

    は10年以上) 趣味はテニス、ニャンズの遊び場 DIY 今日の流れ 1. なぜ作ったのか 2. 何を作ったのか 3. Kamal をどのようにラップし、うまく活用したか 4. 持ち帰ってほしいこと 「インフラの管理って、Rails と相性がいいのでは?」 ― 作ってみて、そう感じました 高所好きなニャンズ 2
  3. なぜ作ったのか ― 作ったアプリの「置き場」がなかった 「すぐ畳むかもしれないし、環境作成は頼みづらい…」 ― アプリ開発者 「外の PaaS や SaaS

    に散らばると、管理しきれない…」 ↓ ― インフラチーム 社内に、いつでも、すぐに使える場所があれば…? 3
  4. 作ったもの ― Kamal をラップした Kamaly(カマリー) Kamal + Rails 8 標準の

    デプロイツール ボタンひとつで動く インフラを知らなくて良い y 1文字だけ (typo ではありません) Kamal に任せる 作るのは「その外側」だけ = Kamaly 今日お話しする 社内 PaaS リソースを上手に共有 サーバーも DB も、みんなで 4
  5. 使う前に、何をすればいい? 書く必要がある 書かなくて良い Dockerfile deploy.yml Solid Queue などの設定 DB の接続設定

    AI が書く AI が書く Kamaly が生成 Secret(環境変数)で渡る credentials への登録も不要 書く必要があるものも、AI 向けのプロンプトの定型文を用意。リポジトリ上で AI に言うだけ 6
  6. 操作の流れで見る、守備範囲 利⽤者 アプリ追加 デプロイ Kamaly Kamal EC2 AWS ALB 初期化(DB‧S3

    を作成) deploy.yml を⽣成 ルーティング設定 docker build docker run 守備範囲をはっきり分けたから、Kamaly は「その外側」の設計に集中できた 7
  7. 裏側の構成 ― リソースを、アプリ同士で上手に共有する ユーザー / インターネット ALB(全アプリで共有) server-1(共有) app-A 2GB

    app-B 1GB server-2(共有) app-C 2GB Aurora PostgreSQL(共有) S3(アプリごとに専⽤) ポイント 上手に共有 サーバーも DB も、みんなで あえて シンプルに K8s ほど大掛かりにしない クラウドベンダ依存を低く 8
  8. 「上手に共有」は、言うほど簡単じゃなかった ユーザー / インターネット ALB(全アプリで共有) A どう届ける? + 新しいアプリ app-D

    1GB server-1 ! app-A 2GB app-B 1GB server-2 app-C 2GB Kamal = Kamal が⾯倒を⾒る範囲 Kamal server-3 (追加?) アプリは複数のサーバーに散らばり、 置き場所も変わる B どこに置く? アプリは増え続ける。 置き場所は、⼈に決めさせたくない C サーバーが変わったら? 追加‧⼊れ替え‧故障。 ここは Kamal が関与しない Kamal の外側は、案外広い 9
  9. A. 行き先は Kamaly が決め、Kamal が届ける app-a.example.jp 階層1 Kamaly 管轄 ALB

    app-c.example.jp Kamaly が決めた転送先の server へ流す TG-b(2台) TG-a server-1 kamal-proxy 階層2 Kamal 管轄 app-b.example.jp app-a TG-c server-2 kamal-proxy app-b 使う人は、台数を決めるだけ 置き場所も届け方も、Kamaly と Kamal におまかせ app-b app-c 10
  10. B. 置き場所は、Kamaly が良い感じに選ぶ ① 必須 AZ 分散で、候補を絞る 冗⻑化設定のアプリは、必ず2つの AZ へ

    az-1 app app az-1 az-2 別々の AZ app app az-2 AZ 冗⻑化できていない ② 優先 「余裕」のあるサーバーを選ぶ 何を「余裕」とみなすかに、基盤の色が出る。 たとえば ― → メモリ あふれたら、どうなる? CPU 取り合ったら、どうなる? 11
  11. B. メモリの「余裕」は、きっちり見る 8GB 空き app-B 3GB app-A 2GB 0GB 8GB

    OS 予約 server app-A が 膨らむと app-B 3GB OOM 停⽌ app-A 5GB 0GB OS 予約 server メモリ不足はサービス障害に直結 上限は Kamal がアプリごとに守り、空きは Kamaly が見て置き場所を選ぶ 12
  12. B. CPU の「余裕」は、ゆるく見る A A B server C app-A が

    暴れると 遅くなる B C server CPU の取り合いは遅くなるだけ。だからオーバーコミットを許容する 何を大事にするかで、共有の仕方は変わる。Kamaly は、そのロジックを組むだけ 13
  13. B. デプロイのたびに、勝手に平準化される before 8GB after 空き 空き 空き 空き 空き

    3.5GB 4.5GB 空き 4.5GB 4.5GB 4.5GB app-X を 5.5GB 再デプロイ app-X 1GB 他 0GB server-1 app-X 1GB 他 他 他 server-2 server-3 server-1 app-X 1GB app-X 1GB ← 移動 他 他 server-2 server-3 デプロイのたびに、偏りが自然に整っていく。使う人は、いつも通りデプロイするだけ 14
  14. C. サーバーの入れ替えは、管理画面から3ステップ ① サーバー追加 → ② 配置停⽌ → ③ アプリを退避

    server-1 が不調。同じ az-1 に server-3 を追加 server-1 server-2 app-B app-C app-A app-B (az-1) ⚠ 不調 (az-2) server-3 (az-1) 新規 (空) ALB からは⾃動で切り離し済み 15
  15. C. サーバーの入れ替えは、管理画面から3ステップ ① サーバー追加 server-1 配置停⽌中 → ② 配置停⽌ →

    server-1 を配置停⽌に設定 server-2 (az-2) app-B app-C app-A app-B ③ アプリを退避 server-3 (az-1) (空) 新規の配置候補から外れる 16
  16. C. サーバーの入れ替えは、管理画面から3ステップ ① サーバー追加 → ② 配置停⽌ → ③ アプリを退避

    アプリを退避。server-1 が空になり、削除できる server-1 削除可能 server-2 server-3 app-C app-B app-B app-A (空) (az-2) (az-1) ③ の退避は、稼働中のバージョンで再デプロイするだけ kamal deploy -P --version={稼働中のバージョン} あとは B の配置ルールが再配置。運用者は管理画面だけ、使う人は何もしなくて良い 17
  17. 結果 ― 大掛かりでなくても、自社に合った PaaS が作れた 大掛かりな基盤なら クラスタの設計・構築 専任の運用チーム Kamaly は

    ↓ Rails アプリ 1つ + Kamal シンプルなインフラ 本業の合間に作れた 結果 30+ 自然と増える アプリが載っている 管理された PaaS の上で 散らばらない 手間いらず 全部ここにある 一つひとつ把握しない 18
  18. 持ち帰ってほしいこと ― Kamal + Rails で、PaaS は作れる 1 作るのは、外側だけ Kamal

    に任せられる ところは、任せる 2 → 仕組みは、単純 2階層で届ける 再デプロイで平準化 3 → 道具は、手元にある ActiveRecord ActiveJob Solid Queue Turbo … インフラも、Rails で書こう 19
  19. 裏話 ― はじまりは、電車の中 2025年 9月 現地に向かう電車の中で、 「これを作ろう」と決めた その後 本業の合間に、Rails を学びながら

    2026年 2月 Kamaly 本番始動 https://www.sonicgarden.jp/join_us/blog_articles/hyogo_hackation202510 2026年 8月 アプリが 30個を超えた ハッケーション = ハッカソン × バケーション(ソニックガーデンの造語) 20