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

Kubernetesを使わない環境にもCloud Nativeなデプロイを実現する / Ena...

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on.

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

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

Avatar for linyows

linyows

May 14, 2026

More Decks by linyows

Other Decks in Programming

Transcript

  1. Tomohisa Oda @ クラウドネイティブ会議 May 1 4 , 2 0

    2 6 Kubernetesを使わない環境にも Cloud Nativeなデプロイを実現する
  2. 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
  3. 実際にはKubernetesを使えない場合がある 主権や規制 (医療、 行 政、 金 融、政府) コスト構造 (定常負荷、 小

    規模) 技術的制約 (GPU、低レイテンシー) 既存資産や組織 (レガシー、 人 材不 足 )
  4. • SSH越しの 手 作業 • 構成管理の延 長 でAnsible • 秘伝のShell

    によるデプロイ Script • CIによるデプロイの 自 動化 物理サーバやVM環境のデプロイはどうしているか bastion dev 1 dev n host 1 host 2 host n CI
  5. • SSH越しの 手 作業 • 構成管理の延 長 でAnsible • 秘伝のShell

    によるデプロイ Script • CIによるデプロイの 自 動化 運 効率の向上 物理サーバやVM環境のデプロイはどうしているか bastion dev 1 dev n host 1 host 2 host n CI
  6. • SSH越しの 手 作業 • Ansible, 独 自 Shell による

    デプロイ作業のScript化 • CIによるデプロイの 自 動化 デプロイの経路は攻撃の対象 となり、アタックサーフェス は拡 大 する 物理サーバやVM環境のデプロイはどうしているか dev 1 dev n host 1 host 2 host n CI Security Group bastion
  7. 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
  8. コントロールプレーン無しという中央集権がない設計 メリット デメリット • 故障点が減る • 依存、複雑性が減り運 用 負荷縮 小

    • ネットワークやホスト個別性に強い • 段階的導 入 ができる • 全体協調機能を持てない • 配置や協調は別で管理 • ホスト増減も別で管理
  9. 再掲:実際にはKubernetesを使えない場合がある 規制や主権 (医療、 行 政、 金 融、政府) コスト構造 (定常負荷、 小

    規模) 技術的制約 (GPU、低レイテンシー) 既存資産や組織 (レガシー、 人 材不 足 )
  10. なぜさくらのクラウドではDewyを選んだのか • クラウド基盤事業者( 大 量の物理サーバや配線を扱う)で、当然アプリケー ション実 行 基盤のApprunなど、コンテナ環境はある • クラウドコンポーネントが他のコンポーネントの依存すると、障害時の影響

    が広くなるため、コンポーネントの独 立 性は事業要件 • クラウドコンポーネントごとに完全分離されたKubernetesクラスタを 用 意す るフェーズでもない • ISMAP(政府情報システムのセキュリティ評価)を満たす必要がある
  11. bastion Pull型デプロイによるアタックサーフェス最 小 化 • Github Enterprise Serverを 内部ネットワークで使 用

    し ている • Actionsでビルドしバイナリ をさくらのオブジェクトス トレージに配置する • パケットフィルタで外部か らのアクセスはさせない Object Storage GHES Actions instance 1 instance 2 instance n パケットフィルタ
  12. HooksによるDBマイグレーションの 自 動化 • 宣 言 的にDBスキーマを管理する sqldefやatlasを使 用 し、最新の

    DBスキーマをデプロイするとい う使い 方 • Dewyはデプロイの前と後に任意 のコマンドを実 行 できるHooks 機構を使う • DBマイグレーションも 人 が介在 せず安全に 行 うことができる Object Storage GHES Actions migrator DB sqldef —apply < ./schema.sql パケットフィルタ
  13. Container Registry Container コマンドによるランタイム抽象化 • NodejsやPHPのようなインタープリタ 言 語の場 合、アプリケーションに加えランタイムも 一

    緒に 管理できたほうが都合が良い • Dewyのcontainerコマンドはdockerやpodman を使ってコンテナを起動させ、ローリングアップ デートやBlueGreenデプロイメントを選択できる • serverコマンドがsupervisor型だったのに対して containerコマンドはproxy型で指定した数のコン テナを起動することができる GHES Actions instance 2 instance 1 instance n
  14. まとめ • 今もなお物理サーバーやVMを使 用 しなければならないユースケースはある • 物理サーバやVM環境において、旧来のデプロイ 手 法によってアタックサーフ ェースが拡

    大 する • DewyはCloud Nativeなデプロイを提供し、Kubernetesなしでも、宣 言 的な デプロイとゼロダウンタイムをセキュアに実現する • 物理サーバやVM環境を 見 たらDewyを思い出してください!