Rails: Kamalデプロイツールはゲームチェンジャーになるか？（翻訳）

Kamalデプロイツールはゲームチェンジャーになるか？（翻訳）

原文編集者注: 2024年に本記事の内容を見直しました。現時点の私たちは、状況を見守っているところです。

忙しい人向け: 私たちの分析結果を知りたい方、Kamalを採用または移行するメリットがあるのはどんなプロジェクトか、Kamalに乗り換えるべきか、そうでないかを知りたい方は、このパラグラフまでスキップしてください。それ以外の方はこのまま読み進めてください。

まずは簡単な調査と歴史を振り返ってみましょう。
Docker 1.0がリリースされてから2023年で10年目を迎えました。当初は、これによってアプリケーションのデプロイにおける多数の重要な問題（移植性、一貫性、分離）が解決されましたが、Dockerコンテナを大規模に管理するソリューションはまだありませんでした。そこで、そのための新しいツールがいくつも登場しました。Kubernetesが誕生すると、たちまち「惑星規模」のオープンソースソリューションにのし上がりました。
一方、メジャーなクラウドプロバイダもこぞって独自のサービスでユーザー獲得に励みました（Amazon ECSやGoogle Cloud Runなど）。また、Ansible、Chef、Puppetのコミュニティも、パブリックロールやレシピを多数公開して、複数サーバーにコンテナをデプロイ可能にしました（品質や複雑さはさまざまですが）。Nomadや Docker Swarmなどの他のツールは、ややニッチではあるものの、今も生き残って活躍している成熟したツールであることもわかってきました。

しかし、どのツールにも固有の限界があり（詳しくは後述）、夜空に新たな星が光り輝く余地は常にあるのです。それがKamalなのです。

🔗 Kamal登場

Kamalは、初心者がコンテナをできるだけシームレスに導入できるようにすることを目指しています。Kamalを支えている基本概念は、古き良きCapistranoに大きく依存しており、Kamalの作者であるDHHもその点を強調しています。

Kamalは、Capistranoのシンプルな手順と、最新のコンテナ化技術の良さが融合したものです。

David Heinemeier Hansson（Ruby on RailsとKamalの作者）
Introducing Kamalより

Kamalは命令的なツールとして特別に設計されており、背後に複雑なロジックを隠していません。すなわち、Kamalをゼロから導入する方が、ステート調整ロジックを隠し持っている既存の宣言的なコンテナオーケストレーションツールで頑張るよりも手軽に利用できます。このおかげで、Kamalで最初にアプリをデプロイするときに読まなければならないドキュメント量や記述すべきコンフィグ量も少なくて済みます。

しかしKamalのメリットを詳しく検討する前に、心にこんな疑問が浮かびます。
「別のデプロイツールが本当に必要なの？」
この疑問について調べるよい方法は、おそらく既存のソリューションに潜むいくつかのギャップを指摘することでしょう。

🔗 各種デプロイツールをざっくりチェック

その点を踏まえて、おそらく皆さんも既によくご存知のさまざまなデプロイツールやプラットフォームと、そこで遭遇する可能性のある状況を検討してみましょう。

• Heroku、Fly.io、Render

最初はHeroku、Fly.io、Renderです。
これらはいずれも快適な開発エクスペリエンスを提供する優秀なプラットフォームであり、実際私たちは最初にこれらをオプションとして検討することを推奨するのが常です。その理由は、プロジェクトを最初にリリースするときの時間や労力を大幅に削減できるからです（この状況は多くのスタートアップ企業にとって、おそらく今後何年もの間通用すると考えてよいでしょう）。
ただし、プロジェクトが成長するに連れてコストが急上昇したり、そのプラットフォームが技術要件や制約の進化についていけなくなる可能性があります。

• Kubernetes（K8s）

次はKubernetes（K8s）です。Evil MartiansのSREチームは、上述のソリューションに該当しない大規模プロジェクトではKubernetesを推奨しています。Kubernetesは巨大なコミュニティとエコシステムを備えている、優秀なコンテナオーケストレーションプラットフォームです。メジャーなクラウドプロバイダ（AWSやGoogle Cloudに加えてDigital Oceanなど他多数）が一通りマネージドKubernetesソリューションを提供していることも好材料です。
しかし、Kubernetesはやはりシステムとして相当複雑であり、一晩で習得するというわけにはいきません（Kamalはそれが可能なほどシンプルという強みがあります！）。

• Nomad

Nomadも、Kubernetes同様に経験豊富なチームに向いていますが、コミュニティが小さく、まだ少々複雑過ぎます。

• Mesos

MesosはKubernetesよりも学習曲線がかなり急角度であり、エコシステムも限定的です。

• Ansible、Chef、Puppet

これらは汎用のコンフィグ管理ツールとして設計されているため、コンテナのビルドやデプロイに特化していません。

• Docker Swarm

Docker Swarmは、複雑さという点では他のライバル製品よりもシンプルですが、本格的なコンテナオーケーストレーションが提供する柔軟な構成機能には遠く及びません。Docker Swarm自身も管理しなければならず、強力なコミュニティもなければパブリッククラウドで大規模に採用された事例もなく、つまるところニッチなソリューションであると言えます。

• Amazon ECS、Google Cloud Run

最後はAmazon ECSとGoogle Cloud Runですが、AmazonとGoogleがそれぞれ強力に推進しているだけあって、オプションとして高い人気があります。しかしどちらも厳密にベンダーロックされるため、必要な知識もベンダーロックされることになり、（複雑で高価な）ツールも追加しなければならず、値段もお手頃とは言えません。

🔗 Kamalのメリット

それではKamalとそのメリットについて再び考えてみましょう。

• シンプルかつ最小限

Kamalが魅力的である主な理由は、シンプルであることです。利用目的が1つに絞られているので、膨大な知識を必要としません。Kamalを使うには、何らかの仮想サーバー（Digital Ocean、AWS EC2、Linodeなど）と、愛用しているクラウドプロバイダが提供するロードバランサーさえあれば準備完了です。Kamalツールそのものを管理する必要はありません。
インフラ管理の初心者がコンテナ化デプロイを初めて手がけるための敷居をKamalが引き下げたことは、業界全体の進化にとって大きな意義があります。

• ベンダーロックがない

KamalはスタンドアロンのCLIツールであり、Dockerコンテナ内であろうとローカルコンピュータ上であろうと、CI/CDワークフローであろうと、どこでも手軽に実行できます。
Kamalには1つだけ厳密な要件があります。Kamalを使うためには、デプロイに利用するサーバーを私たちが提供しなければなりません。

• Ruby gemである

KamalはRubyで書かれているので、要件に応じて気軽にforkしてカスタマイズできる点が便利です。

• YAMLコンフィグのマージ機能でアプリケーションのコピーを手軽に作成できる

Kamalには、そのための"destination"（宛先）という概念があります。メインのYAMLコンフィグを1個のファイルで定義しておけば、メインのYAMLコンフィグとそれとの差分コンフィグのみを含む追加コンフィグをいくつでも手軽に作成できます。
この機能は、レビュー用の即席アプリや本格的なstaging環境を手早く立ち上げたい場合や、アプリを別の場所に移行したい場合、必要に応じて世界中のあちこちでアプリを追加インストールしたい場合などに非常に便利な方法です。

• アプリ起動前にヘルスチェックが行われる

これはシンプルかつ便利な機能です。アプリケーションがある日突然動かなくなるといった事態に遭遇せずに済みます（Kubernetesでも以前同様の機能のおかげで生活が変わったことが個人的に思い出されます）。

• 簡単なログgrepツールを提供している（ログ集約機能がまだない場合）

負荷の大きなproductionアプリケーションであれば確実に専用のログ集約サービスが必要ですが、小規模なセットアップであればこの機能が実に便利です。

• 高速かつお手軽なロールバック機能

一般的にコンテナは迅速にロールバック可能ですが、Kamalでも同様です。

• ENVファイルのテンプレート化

Kamalは、環境変数やsecretのテンプレート化にRailsの認証情報ツールをデフォルトで利用します。

• デプロイロックのメカニズムがある

他の誰かが同時にデプロイしていないことを確認したい場合や、メンテナンスウィンドウを開始するためにデプロイをフリーズしたい場合は、Kamalでできます。

• 実際のアプリ以外のコンテナを追加実行できる

通常のアプリケーションでは、キャッシュサーバーやデータベース、検索サービスやインデックス化サービスなどの追加サービスに依存する必要が生じることがあります。Kamalのコンフィグには"accessories"セクションがあり、これを用いてそれらの追加サービスもデプロイできます。追加サービスは指定のサーバーにデプロイされ、kamal deployを実行するたびに再起動されることはありません。

---

最後に、Kamalを利用することで、以下の4つの主要な管理タスクをアプリケーションで簡単に実行できます。

1. 全サーバーに対して同じコマンドを実行可能（例: パッケージの更新）
2. primaryサーバーのみに対してコマンドを実行することも可能
3. 対話型セッションで、独立したコンテナ内でコマンドを実行可能
   たとえば、バグで発生した問題を修正するためにRailsのカスタムタスクを実行できます（この場合は独立した環境を取得して、アプリのメインコンテナが再起動で影響を受けたり、アプリのプロセスに干渉したりしないようにするのがよいでしょう）。
4. 対話型セッションで、現在実行中のコンテナ内でコマンドを実行可能
   （ありそうな事例: QAをすり抜けた見つけにくいバグを、ユーザーに見咎められる前に発見する）

Kamalはここ数年活発に開発が進められています。独自のコミュニティも生まれて、開発や改良が熱心に行われています。当初のKamalには機能が制限される落とし穴がいくつもありましたが、こうして皆さんが本記事を読んでいる間も続々と解決されつつあります。

目につきやすい修正例を以下にリストアップします。

• Kamal 1.0.0: ゼロダウンタイムのデプロイプロセスの管理方法が改善されました。
• Kamal 1.1.0: データベースマイグレーションなどの1度しか実行しないタスクの実行方法が改善されました。
• Kamal 1.3.0: Traefikをセットアップしなくてもバックグラウンドジョブを完全に実行可能になりました。
• Kamal 1.4.0: ローカルビルドがクロスアーキテクチャになりました。

この調子でいくらでも続けられます。

🔗 Kamalを採用するうえで考慮すべき点

Kamalの人気が急速に高まっているのは間違いありません（実際、私たちEvil Martiansは、インフラストラクチャをKamalで強化したいというお客様からの依頼を既にいくつもいただいています）。Kamalには、検討の価値がある可能性やメリットがたくさんありますが、新しいツールの例に漏れず、Kamalにも事前準備が必要です。

37signalsとDHHは、Kamalをメインのコンテナデプロイツールとして用いることで、自社アプリケーションをパブリッククラウドから社内のベアメタルサーバー（物理サーバー）への移行を進めているところです。

特にこの移行作業で見込まれるコスト削減がどのぐらになるかを考えると、この話はだいぶ誇張されています。彼らはこの事実を自ら公表し、移行プロセスやそこで達成した成果を解説する記事（「デプロイ時間を従来の数分の1に短縮」「Chefをメインの管理ツールとして用いるというニーズに応えるため、カスタムの超高速VMプロビジョニングを実装」「インフラストラクチャの設定全般をシンプルにする機能」など）を多数共有しています。

37signalsが、これらすべてを達成するために並外れた努力を払ったことは間違いありません。

しかしKamalは、あくまで37signalsの技術スタックの一角を占めているにすぎません。インフラストラクチャは皆それぞれ異なっているのですから、自分たち独自のプロジェクトの文脈に応じた形でKamalを考える必要があります。37signals固有のプライベートインフラストラクチャや専門知識と、Kamal自身をまぜこぜにせず、分けて考えなければなりません。

この点について、Kamalを採用するか、それとも別のソリューションを用いるかという最終決定を下す前に、考慮すべきいくつかのポイントを簡単に確認しておきましょう。

第一に、新しいツールは初期トラブルがつきまといがちなので、常に慎重に扱うべきです。
第二に、Kamalは特定のタスクやシナリオを想定して設計されているので、自分たちのインフラストラクチャや要件、制約、エッジケースが想定に含まれていない可能性もあります。

「新しいツールのメリットとデメリットを綿密に調査し、十分な調査が行われてから、初めてそのツールを特定の状況に適合させること」は、優秀なSREエンジニアの責務のひとつであることが思い出されます。それでは、その通りにやってみましょう。

🔗 デプロイの処理時間

Kamalは、デプロイを高速化する魔法のツールではありません。Kamalは以下の2つの重要な約束を果たしているだけです。

• （仮想かベアメタルかを問わず）サーバーにデプロイすれば、必ずサーバーが実行されることが期待できる
• Kamalは裏方に徹することで迅速なデプロイプロセスが可能になる

Kamalの内部には、同じDocker Buildプロセスがあり、以下に依存しています。

• 実行されているサーバーの速度
• Dockerfile の構造（および品質）
• アプリのサイズ
• Dockerレイヤキャッシュ
• kamal deployを実行するコンピュータ間のネットワーク速度
• ビルドサーバー
• Docker レジストリ
• アプリノード自体の間のネットワーク速度
• アプリの起動速度

より高速なデプロイを達成するには、これら個別のステップにも注意を払う必要があります。そしてこれらは、想像可能なあらゆるインフラストラクチャのコンフィグに適用可能です。

繰り返しますが、Kamalはあくまで邪魔にならない裏方であり、毒になるか薬になるかは使い方次第です。

🔗 ベアメタルサーバーへの移行

Kamalを用いてクラウドからベアメタルサーバーへ移行することについて、多くの誇張がつきまとっています。

Kamalは、初期段階のアプリを任意のサーバー（AWS EC2インスタンス、Digital Oceanドロップレット、レンタルした専用ベアメタルサーバー、Raspberry Piなど何でも構いません）に手軽にデプロイするツールとしては非常に優秀です。

しかしKamalは、クラウドからベアメタルサーバーへの移行を楽にするためのツールではありません。ベアメタルサーバーの管理ツールやベアメタルサーバーの問題を解決するツールといったものは存在しません。プロジェクトでそうした点を解決するには、やはり専門家もしくは専門チームが必要になります。

次の考察に進みましょう。

🔗 背後のインフラを管理する

ずらりと並んだベアメタルサーバーをセットアップする作業は簡単ではありません。Kamal deployを実行する前に、さまざまな専門知識や下準備、計画立案、設定の管理に長い時間をかける必要があります。

話を簡単にするため、ベアメタルではなく仮想ノードを採用することにしたとしても、「ノードのプロビジョニング」「ネットワークルールの設定」「ロードバランサのセットアップ」といったクラウド周りの管理がやはり必要です。

しかも、プロジェクトは複数のコンポーネントで構成されているのが普通です。一般的に言って、「データベース」「バックアップシステム」「ロードバランサ」「アクセス管理システム」「監視およびログ集約サーバー（New Relicやその競合製品が対象外の場合）」「ビルドサーバー」「イメージレジストリサーバー（デプロイ時間を徹底的に短縮したい場合）」が必要になります。

要するに、これら一切合切を管理しようとすれば、どの項目についても十分な経験値が不可欠になります。

たとえば、Kamalコンフィグの"accessories"にPostgreSQLコンテナを追加することは、デモ用アプリやレビュー用アプリなら優れたソリューションになるかもしれませんが、production環境向けのコンフィグが不十分なままで同じことをするのは無茶です。

すなわち、これまで通り最新のクラウドが提供するマネージドデータベースサービスに依存する方が賢明かもしれないのです。

🔗 監視とログ集約

新しいインフラストラクチャを立ち上げたら、シンプルであろうと複雑であろうと、運用状況や安定性を継続的に担保しなければなりません。だからこそチームは、セットアップ全体を透過的に監視するソリューションと、アプリケーションの全インスタンスのログファイルを手軽に収集・表示できる方法を用意しておく必要があります。さもないと、重大な損害やダウンタイムが発生するまで問題が検出されず、生産性・収益・評判の損失という高い代償を支払うはめになる可能性があります。

Kamalは、気の利いたログgrepツールを提供しています（Capistranoを使っていた頃にこれがあったらどんなによかったでしょう！）。初期段階はおそらくこれで間に合いますが、いずれ独自の監視ソリューションが必要になります。

無料のNew Relicセットアップは、サーバー数が限られている小規模チーム向けの優れたオプションです。監視のニーズに対応可能なことに加えて、より優れたログ集約サービスも提供されます。ただし、無料プランを超えた瞬間に高額になる可能性があります。その場合、コストを節約するには、Prometheus+GrafanaやELK/Lokiなどの独自の監視ソリューションを検討する必要があるかもしれません。

🔗 ここ1年間に何らかの改善があったか？

残念ながら、Kamal実装の文脈では、上述のトピックに関する議論がまだ不足しています。

ここで個人的な意見を述べることをお許しください。
このことは、私たちが2024年に生きていること、インフラストラクチャが以前ほど複雑でなくなって管理がもっと自動化されることが求められている状況を表していると思います。言い換えれば、HerokuやDataDogなどのクラウドサービス、またはそれらを連想するようなツールが必要とされているということです。私見では、Kamalと Basecampの移行に関する誇張された話によって、そのことが余すことなく強調されたと思います。

🔗 Kamalのメリットが最も大きいのはどんなユーザーか

Kamalはシンプルで使いやすく、経験の浅いチームが特定サービスにロックインされることなく、コンテナベースのインフラストラクチャの世界に参入するときに役立つツールであると喧伝されています。しかしそれでも、初心者はここで気をつけておく必要があります。

逆に、上述した技術的な問題とタスクに十分対応可能な専門知識を有しているチームやプロジェクトであれば、慎重に検討を重ねたうえでKamalに移行するという決定を下すことも可能です。

自己診断: Kamalに乗り換えるべきかどうか？

「管理作業やデプロイに深入りしたくない」「今使っているHerokuやFly.ioやRenderで満足している」

今のソリューションをそのまま使い続けましょう。

「パブリッククラウドを使いたくない」「VPSやベアメタルでホスティングしたい」

Kamalを試してみましょう。

「既にK8sを導入していて快適に利用できている」または「既にセットアップが高度になっている」

しばらく現状のままにすることをおすすめします。

「アプリケーションの利用量が定期的に急増する」または「インフラストラクチャの手動または自動スケーリングが頻繁に必要になっている」

まだKubernetesを使っていなければ、Kubernetesを検討してみましょう。

「Kubernetesが好きになれない」または「Kubernetesが難しすぎる」

ぜひKamalを調べてみましょう。Kamalがぴったりはまる可能性があります。

Kamalは新しいツールであり、さらに大きく成長する可能性を秘めています。つまり、新しい機能によってKamalならではのニッチな用途を開拓し、独自のコンテナ化インフラストラクチャを「若い」プロジェクトが編成するのを支援することでコミュニティを前進させるということです。

Kamalの長所と短所について少しでもご理解いただければ幸いです。インフラストラクチャでお悩みの方は、Evil Martiansの専任SREチームが、さまざまなオプションの長所と短所を整理するお手伝いをいたします。

• 自社をベアメタルサーバーに移行する価値があるかどうか、あるならいつどのような形で移行するのがよいかについて相談に応じます。
• 弊社の経験豊富なKubernetesプロフェッショナルは、関連するあらゆる問題にいつでも対応・支援する準備ができています。
• Kamalがお客様のプロジェクトに最適な選択かどうかを詳細に検討するお手伝いもいたします。
• Kamalが最適な選択でしたら、弊社のSREスペシャリストが実現をお手伝いします。
• 私たちは、その他にもお客様のプロジェクトのあらゆるニーズにお力添えいたします！

地球外からのコンサルタントをお求めのお客様は、ぜひ私たちのフォームまでお気軽にお問い合わせください。

関連記事

Kamal README: 37signalsの多機能コンテナデプロイツール（翻訳）