Kubernetesを使わない環境にもCloud Nativeなデプロイを実現する / Enabling Cloud Native deployments without the complexity of Kubernetes

クラウドネイティブ会議での資料

Transcript

1. Tomohisa Oda @ クラウドネイティブ会議 May 1 4 , 2 0 2 6 Kubernetesを使わない環境にも Cloud Nativeなデプロイを実現する
2. Tomohisa Oda さくらインターネット株式会社 • 研究員 ／ ソフトウェアエンジニア • 福岡在住でFukuoka.go主催の1 人 • 筋トレとテニスが趣味 @linyows
3. クラウドネイティブ＝Kubernetes、 本当にそうでしょうか？
4. CNCFのLandscapeを 見 ると答えは Yes • 多くのエコシステムはKubernetes上で動く • 本屋にならんだ書籍をみても • カンファレンスのセッションの 一 覧をみても • SREやプラットフォームエンジニアの求 人 をみても どれもKubernetesが前提
5. Cloud Nativeの特徴とは？ • セキュアで回復 力 が 高 く、運 用 管理 性に優れ、持続 ・ 観測可能で、かつ 相互連携可能な疎結合なシステム （ 長 い）。 • KubernetesはCloud Nativeの1実装 であり、これらを満たす他の実装が あっても良いはず。 “It is characterized by loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable.” via CNCF Cloud Native De fi nition v 1 . 1
6. 実際にはKubernetesを使えない場合がある 主権や規制 （医療、 行 政、 金 融、政府） コスト構造 （定常負荷、 小 規模） 技術的制約 （GPU、低レイテンシー） 既存資産や組織 （レガシー、 人 材不 足 ）
7. 物理サーバやVMは残っていませんか
8. それらの環境におけるデプロイの課題
9. • SSH越しの 手 作業 • 構成管理の延 長 でAnsible • 秘伝のShell によるデプロイ Script • CIによるデプロイの 自 動化 物理サーバやVM環境のデプロイはどうしているか bastion dev 1 dev n host 1 host 2 host n CI
10. • SSH越しの 手 作業 • 構成管理の延 長 でAnsible • 秘伝のShell によるデプロイ Script • CIによるデプロイの 自 動化 運 効率の向上 物理サーバやVM環境のデプロイはどうしているか bastion dev 1 dev n host 1 host 2 host n CI
11. • SSH越しの 手 作業 • Ansible, 独 自 Shell による デプロイ作業のScript化 • CIによるデプロイの 自 動化 デプロイの経路は攻撃の対象 となり、アタックサーフェス は拡 大 する 物理サーバやVM環境のデプロイはどうしているか dev 1 dev n host 1 host 2 host n CI Security Group bastion
12. そこで、物理サーバやVM環境にも Cloud Nativeの原則を持ち込む
14. Non-Kubernetes環境のためのデプロイツール • Dewyは 自 分で 自 分を更新し続け るソフトウェア • 中央のレジストリから繰り返しバ ージョンリストを取得し、新しい バージョンを 見 つけるとダウンロ ードし展開し、起動させる • 主に4つの抽象化パッケージに分 かれており、要件に合わせ組み合 わせて使 用 する App, Files or Containers v1.2.2 App, Files or Containers v1.2.3 Artifact Registry Notifier Cache ɾGithub Releases ɾAWS S3 ɾGoogle Cloud Storage ɾContainer Registry ɾGRPC Server 1. Polling 5. Reporting 6. Send 2. Download 3. Storage 4. Deployment ɾFile system ɾAWS S3 ɾGoogle Cloud Storage ɾSlack ɾMail Dewy
15. コントロールプレーン無しという中央集権がない設計 メリット デメリット • 故障点が減る • 依存、複雑性が減り運 用 負荷縮 小 • ネットワークやホスト個別性に強い • 段階的導 入 ができる • 全体協調機能を持てない • 配置や協調は別で管理 • ホスト増減も別で管理
16. さくらのクラウドでの事例
17. 再掲：実際にはKubernetesを使えない場合がある 規制や主権 （医療、 行 政、 金 融、政府） コスト構造 （定常負荷、 小 規模） 技術的制約 （GPU、低レイテンシー） 既存資産や組織 （レガシー、 人 材不 足 ）
18. 使えないではなく、使わない選択
19. なぜさくらのクラウドではDewyを選んだのか • クラウド基盤事業者（ 大 量の物理サーバや配線を扱う）で、当然アプリケー ション実 行 基盤のApprunなど、コンテナ環境はある • クラウドコンポーネントが他のコンポーネントの依存すると、障害時の影響 が広くなるため、コンポーネントの独 立 性は事業要件 • クラウドコンポーネントごとに完全分離されたKubernetesクラスタを 用 意す るフェーズでもない • ISMAP（政府情報システムのセキュリティ評価）を満たす必要がある
20. bastion Pull型デプロイによるアタックサーフェス最 小 化 • Github Enterprise Serverを 内部ネットワークで使 用 し ている • Actionsでビルドしバイナリ をさくらのオブジェクトス トレージに配置する • パケットフィルタで外部か らのアクセスはさせない Object Storage GHES Actions instance 1 instance 2 instance n パケットフィルタ
21. HooksによるDBマイグレーションの 自 動化 • 宣 言 的にDBスキーマを管理する sqldefやatlasを使 用 し、最新の DBスキーマをデプロイするとい う使い 方 • Dewyはデプロイの前と後に任意 のコマンドを実 行 できるHooks 機構を使う • DBマイグレーションも 人 が介在 せず安全に 行 うことができる Object Storage GHES Actions migrator DB sqldef —apply < ./schema.sql パケットフィルタ
22. Container Registry Container コマンドによるランタイム抽象化 • NodejsやPHPのようなインタープリタ 言 語の場 合、アプリケーションに加えランタイムも 一 緒に 管理できたほうが都合が良い • Dewyのcontainerコマンドはdockerやpodman を使ってコンテナを起動させ、ローリングアップ デートやBlueGreenデプロイメントを選択できる • serverコマンドがsupervisor型だったのに対して containerコマンドはproxy型で指定した数のコン テナを起動することができる GHES Actions instance 2 instance 1 instance n
23. 時間があれば簡単なデモ
24. まとめ • 今もなお物理サーバーやVMを使 用 しなければならないユースケースはある • 物理サーバやVM環境において、旧来のデプロイ 手 法によってアタックサーフ ェースが拡 大 する • DewyはCloud Nativeなデプロイを提供し、Kubernetesなしでも、宣 言 的な デプロイとゼロダウンタイムをセキュアに実現する • 物理サーバやVM環境を 見 たらDewyを思い出してください！