Kubernetesなしでも宣言的デプロイを実現、Dewyが示す運用分離の考え方

編集: グリットアーツ編集部

公開日：2026年11月2日

3行解説

ニュースの概要

2026年5月14〜15日に名古屋で開かれたクラウドネイティブ会議で、さくらインターネット研究所の小田知央さんが「Kubernetesを使わない環境にもCloud Nativeなデプロイを実現する」と題して発表しました。記事はその内容をまとめたもので、Kubernetesを前提にしないデプロイの考え方と、ツール「Dewy」の仕組みを紹介しています。あわせて、さくらのクラウドでの利用例や、データベースマイグレーションへの応用も説明されています。

何が新しいのか

新しい点は、クラウドネイティブを「Kubernetesありき」で捉えず、物理サーバーやVMでも同じ原則を満たすデプロイを目指していることです。Dewyは、Registry、Artifact、Notifier、Cacheという4つの抽象化を持ち、GitHub、Amazon S3、Google Cloud Storage、Slack、メール、ファイルシステムなどを組み合わせられます。さらに、コントロールプレーンを持たず、各ホストが自立して更新を受ける設計です。

さくらのクラウドの事例では、GitHub Enterprise Serverが社内ネットワーク内にあるため、そのままRegistryに使えませんでした。そこでGitHub Actionsでビルドし、成果物をオブジェクトストレージに置き、各インスタンスがPullする構成にしています。更新経路を外に開かず、パケットフィルタで外部アクセスを遮断している点も、実運用を意識した変更です。

グリットアーツ編集部の分析

この発表で重要なのは、Dewyが「中央集権の管理基盤を持たない」ことです。更新の入口を限定し、各ホストが自分で取りに行く形にすると、攻撃面を小さくしやすくなります。一方で、配置やホスト増減はAnsibleやTerraformなど別の仕組みで補う必要があり、運用を完全に単純化できるわけではありません。つまり、Kubernetesの代替というより、規模や制約に応じて責任分界を組み替える選択肢と見るのが妥当です。

日本の現場で考えると

日本では、公共、医療、金融のように監査や規制が厳しい現場で、Kubernetesを前提にしない構成が選ばれることがあります。今回の事例でも、ISMAP対応のために各サービスを独立させる必要がありました。こうした現場では、更新経路が社内ネットワーク内に閉じているか、外部からの到達面をどこまで減らせるかが重要です。

また、一定負荷で動く物理サーバーや、低レイテンシが必要な処理、GPUを占有したい環境では、コンテナ基盤よりも単純なホスト運用の方が合う場合があります。逆に、ホスト数が増えたときの配置管理や、障害時の切り分けをどう標準化するかは慎重に見るべきです。Dewyはゼロダウンタイム更新やロールバックの考え方を持ち込みやすい一方、全体協調は外部ツールに依存します。

導入・検討時に確認したいこと

• 既存の配布元がRegistryとして使えるか。GitHub、S3、GCSなどのどれを使うか。
• 通知先をSlackやメールに合わせられるか。運用標準のアラート経路と合うか。
• ホスト増減や配置を、AnsibleやTerraformなど既存の構成管理で補えるか。
• DBマイグレーションのような前後処理をHooksで安全に実行できるか。
• 外部からのアクセス遮断やパケットフィルタ設計を、更新方式と両立できるか。

現時点で分かっていないこと

記事だけでは、Dewyの対応OSや詳細な運用条件、障害時の復旧手順の細部は分かりません。また、どの規模まで段階的導入しやすいか、既存の構成管理とどう役割分担するのが最適かも、現場ごとに確認が必要です。

Kubernetes前提ではない環境でも、更新経路や保守の設計次第で運用のしやすさは大きく変わります。既存の物理サーバーやVMをどう安全に更新するかでお悩みなら、構成整理の観点からご相談ください。

出典: さくらのナレッジ