Kubernetesを使わない環境にもCloud Nativeなデプロイを実現する 〜クラウドネイティブ会議発表レポート〜

はじめに

2026年5月14-15日(木金)に名古屋の中日ホール&カンファレンスにてクラウドネイティブ会議が開催されました。本記事では同イベントで行われた発表の中から、さくらインターネット研究所の小田知央さん(@linyows)による「Kubernetesを使わない環境にもCloud Nativeなデプロイを実現する」の内容を紹介します。

「クラウドネイティブ＝Kubernetes」は本当か？

クラウドネイティブ会議で行われるさまざまな発表の内容を見ても、あるいは書店に並んでいるクラウドネイティブ関連の書籍を見ても、そこで取り扱っているシステムはKubernetesが前提になっています。CNCFのLandscapeでさえ、「クラウドネイティブ＝Kubernetes」に対する答えはYesという論調です。

しかし、CNCF Cloud Native Definition v1.1で示されているクラウドネイティブの定義は「セキュアで回復力が高く、運用管理性に優れ、持続・観測可能で、かつ相互連携可能な疎結合なシステム」です。Kubernetesを使えとは書かれていないので、実装手段は必ずしもKubernetesでなくてもよく、要件を満たせば他のツールで実装したものがあってもよいはずです。

Kubernetesが使えないケースもある

その一方で、現場ではKubernetesを採用できない、あるいは採用しないケースが見られます。その理由を大別すると以下の4つになります。

1. 主権や規制
   医療や公共、金融などの領域で求められる要件です。公共系の住民データや、金融におけるクレジットカードのデータなどです。このような分野では物理層に至るまで厳しい監査が入るので、クラウドを使うよりも物理サーバーを管理した方が運用が楽になるケースがあります。
2. コスト構造
   例えばワークロードが一定で変動しないなら、物理サーバを使う方がコストが安くなる場合があります。また、常時稼働させるサーバーが1台しかないような小規模な環境も、クラウドよりも物理サーバの方がコスト面で有利になることがあります。
3. 技術的制約
   GPUを占有したいとか、低いレイテンシを保証しなければならないようなシステムでは、クラウドよりも物理サーバーで実装した方が良いケースがあります。
4. 既存資産や組織
   例えばKubernetesを運用できる人材が社内にいないとか、既存システムとの互換性が求められるためにKubernetesを導入できないケースがあります。

物理サーバやVM環境におけるデプロイと問題点

このようなKubernetesを使わない(あるいは使えない)環境におけるデプロイはどのようにして行われているでしょうか。一番素朴な方法は、SSHでサーバに接続して手作業でデプロイするというものです。これを少し発展させると、Ansibleで構成を管理し、その延長でアプリのデプロイも実施するという手法になります。これをさらに発展させると、scpやgit cloneなどのコマンドが列挙されたシェルスクリプトを実行するといったものになります。さらにもっと発展すると、それらをCIツールを用いて自動化するといったことになります。

これらの手法を用いると運用効率は向上しますが、その一方でデプロイの経路は攻撃の対象になり得ますので、効率の向上と引き換えにセキュリティリスクが増大します。ここでクラウドネイティブの定義である「セキュアで回復力が高く、運用管理性に優れ、持続・観測可能で、かつ相互連携可能な疎結合なシステム」に立ち返ると、このようなKubernetesが利用できない環境にも、クラウドネイティブの原則に則ったデプロイの仕組みを導入したくなります。

Non-Kubernetes環境のためのデプロイツール「Dewy」

このような課題を解決するツールとして、小田さんが開発している「Dewy」(デューイ)があります。Dewyの動作を簡単に説明すると以下のようになります。

1. RegistryからGithub Releasesなどのバージョンリストを定期的に取得します。
2. 新しいバージョンを検知したら、Artifactから新バージョンのソースコードやバイナリを取得して展開し、自分の子プロセスとして起動します。

Dewyは、Registry、Artifact、Notifier、Cacheという4つの抽象化パッケージに分かれていて、要件に応じて組み合わせて使用します。例えばRegistryはGitHubの他にAmazon S3やGoogle Cloud Storageなどが対象で、ArtifactもRegistryと同様です。Cacheにはファイルシステムも利用可能です。NotifierはSlackやメールが使えます。

Dewyにはコントロールプレーンがありません。つまり中央集権的なものを持たない設計になっています。このような構造の利点は、故障点が減少し、運用負荷が軽減されることです。また、各ホストが自立した構造になっているので理解しやすく、段階的な導入も可能です。一方、このような設計のデメリットもあります。全体協調機能がないので、配置や協調といった仕組みは別途、AnsibleやTerraformなどで実装する必要があります。また、ホストの増減に関しても同様に外部ツールで管理することになります。

さくらのクラウドでのDewy利用事例

さくらインターネットが提供しているクラウドサービスであるさくらのクラウドでもDewyを使用しています。

背景事情としては、まず当社はクラウド基盤事業者として膨大な数の物理サーバーや配線を保有しています。また、そのクラウド基盤の上で動くアプリケーション実行基盤であるAppRunもあります。つまりコンテナが動く環境は保有しています。しかし、さくらのクラウドのコンポーネントをAppRun上で動かすと、AppRunに障害が起きたときにそのコンポーネントも連鎖的に障害になってしまって影響範囲が大きくなります。つまり、各コンポーネントは独立した構成にしておく必要があるという事業的な要件があります。かと言って、各コンポーネントごとにKubernetesのクラスタを用意するほどの規模にはまだ達していません。さらに、さくらのクラウドは政府情報システムのセキュリティ評価制度であるISMAPに登録されています。ISMAPに登録されるには厳しい評価基準を満たす必要があり、そのためにも各サービスを独立させることが重要でした。このようなことから、Dewyを用いたデプロイ環境を実装しました。

上図はさくらのクラウドにおけるDewyを使ったデプロイの流れです。Github Enterprise Serverが社内ネットワークにありますが、これは外部からアクセスできないのでDewyのRegistryとしては使えません。そこで、まずGitHub Actionsをトリガーにしてビルドを行い、生成されたものをオブジェクトストレージにアップロードします。そこに対して各インスタンスがアクセスし、新しいバージョンがあったらインスタンスにPullします。インスタンスの周辺はパケットフィルタを用いて外部からのアクセスを遮断しているのでインスタンスは攻撃を受けにくく、かなりセキュアな構造になっています。

Dewyはクラウドコンポーネントのデプロイだけでなく、データベースマイグレーションの自動化にも利用されています。当社ではDBスキーマを宣言的に管理するツールであるsqldefやatlasを使っていますが、このDBスキーマのファイルをデプロイするのにDewyを使っています。Dewyはデプロイの前と後に任意のコマンドを実行できるHooksという機構を持っているので、ここでsqldefコマンドを実行することでDBに対してマイグレーションを実行します。これもパケットフィルタで外部からのアクセスが遮断された安全な領域の中で実行されます。

もうひとつの利用例はDewyのcontainerコマンドを使ったランタイム抽象化です。Node.jsやPHPのようなインタープリタ言語の場合、アプリケーションに加えてランタイムも一緒に管理したいという要求があります。このような場合はコンテナを使う方が好都合です。ここでcontainerコマンドを使うと、DockerやPodmanを使ってコンテナを起動し、ローリングアップデートやBlueGreenデプロイメントの手法を用いてデプロイすることができます。起動するコンテナの数を指定することもできます。

まとめ

発表のまとめとして、物理サーバーやVMといった従来型インフラが使われるケースは今でも多々存在すること、そういった環境における従来型のデプロイ手法は攻撃対象の拡大につながり、セキュリティリスクが高まる点が指摘されました。そのような環境においてはDewyを使用することでクラウドネイティブなデプロイを実現するとともに、Kubernetesを使わなくても宣言的なデプロイやゼロダウンタイムによるシステム更新を行うことができます。小田さんからは「皆さんのお近くで物理サーバを見かけたら『Dewyが使えないかな』と思い出してくれるとうれしい」という言葉がありました。

Dewyを使ったデプロイの実演

発表の後、Dewyを使ったデプロイのデモも行われました。はじめにdewy serverコマンドでサーバを起動します。次にGitHubのリポジトリに新しいバージョンをpushします。するとGitHub Actionsが動いて新しいバージョンを検知し、サーバのバージョンアップを行います。ちなみにリポジトリからそのバージョンが消えると、それも検知されて自動的に前のバージョンにロールバックされるところも実演されました。

おわりに

小田さんによるとDewyはさくらインターネットに入る前から開発してきたものだそうですが、それが今ではさくらのクラウドという実サービスの運用においても使われていて、研究の成果が良い形で活かされていると思いました。クラウドネイティブな環境のデフォルトはまだまだKubernetesなのだと思いますが、今回の発表で示されたようにKubernetesが適さない状況も存在します。本記事でDewyに興味を持たれた方はぜひ使ってみてください。

• Dewy公式サイト
• GitHubリポジトリ