Kompox ストーリー¶

このページでは、作者が Kompox プロジェクトを始めた経緯、Kompox が目指しているゴール、中長期的なビジョンなどを紹介します。

出発点: Linux VM + Docker Compose によるサービス運用¶

作者が長年提供していたサービスインフラは、クラウド上の多数の仮想マシン (VM) 上で Docker Compose を使って多数のコンテナを動かす構成で、Traefik リバースプロキシをフロントに置いてバックエンドのサービスコンテナに接続するというものです。

この構成は非常に安定して動作した実績があります。しかし、VM の OS 更新やセキュリティパッチ適用、インスタンスタイプの変更といったメンテナンスは避けられず、台数が増えるほど運用負荷もかさんでいきます。

そこでKubernetes をはじめとするクラウドネイティブな仕組みを使って、この状況から脱却したいと考えたことが、このプロジェクトの始まりでした。ゴールは、これまで VM 上で稼働していた多数の社内向け Web サービスのワークロードをコンテナ化・クラウドネイティブ化することで、API によるオペレーションの自動化を可能にして、運用負荷を大幅に削減することです。

ステートフルワークロードという難所¶

Kubernetes とステートレス前提の設計¶

Kubernetes はコンテナのクラウドネイティブなオーケストレーション基盤として広く普及し、多くのマネージドサービスが提供されています。しかしながら Kubernetes の設計が前提としているのは ステートレスなワークロード、すなわち個々のコンテナインスタンスがローカルに永続データを持たないワークロードです。

ステートレスとステートフル¶

ステートレスワークロード とは、各インスタンスが自身のローカルディスクに永続的なデータを保持しないアプリケーションです。インスタンスが終了しても失われるデータはなく、別のインスタンスが即座に代替できます。すべての永続データは外部（マネージド DB やオブジェクトストレージなど）に委譲されています。

• Web フロントエンドサーバ (HTML/CSS/JS の配信)
• 外部 DB にすべての状態を委譲する REST API サーバ
• リバースプロキシ、ロードバランサ
• キューからジョブを受け取り結果を外部に書き出すワーカー

ステートフルワークロード とは、各インスタンスがローカルディスク上に永続データを保持し、そのデータが Pod の再起動やリスケジュールをまたいで維持されなければならないアプリケーションです。

• リレーショナルデータベース (PostgreSQL, MySQL) — データファイルをローカルディスクに格納
• Git ホスティングサーバ (Gitea, GitLab, GHES) — リポジトリをローカルファイルシステムに格納
• Wiki / ドキュメント管理システム — アップロードファイルや DB をローカルに保持
• 組み込みデータベースやローカルファイル依存を持つレガシーアプリ

ステートフルワークロードの一部はマネージドサービスへ移行できます（例: 自前の PostgreSQL をマネージド PostgreSQL に置き換える）。しかし Git ホスティングサーバ、独自のファイルストレージに依存するアプリ、改修不能なレガシーアプリなどはマネージドサービスに逃がすことができず、アプリ自身がローカルディスク上にデータを持って動くしかありません。

RWO 永続ボリュームの制約¶

こうしたローカルディスクに依存するステートフルワークロードは、性能要件から ReadWriteOnce (RWO) の永続ボリューム (PV) を必要とすることが多いです。

RWO PV とは、仮想マシンに直結するブロックデバイス (Azure Managed Disks, Amazon EBS, Google Persistent Disks, OCI Block Volume など) の抽象であり、非常に高い I/O 性能を発揮しますが、その代わりに同時にひとつのノードにしか接続できないという大きな制約があります。

RWO PV と対比される ReadWriteMany (RWX) の PV は、NFS/SMB などのネットワークファイルサーバ (Azure Files, Amazon EFS, Google Filestore, OCI File Storage など) の抽象であり、複数ノードから同時接続できますが、性能はほどほどに留まります。

クラウド各社の簡便なマネージドコンテナサービス (Azure Container Apps, AWS Fargate, Google Cloud Run, OCI Container Instances など) は RWX PV にしか対応しておらず、RWO PV を必要とするワークロードには使えません。結果として、マネージドサービスに逃がせないローカルディスク依存のワークロードは、Kubernetes で直接 RWO PV を使って扱うしかないというのが現状です。これがステートフルアプリをクラウドネイティブ化する上での最大の難所と言えます。

Kompox のアプローチ: compose.yml をクラウドへ¶

Docker Compose で書いた compose.yml によるローカル開発体験はシンプルで強力です。Web サーバーやデータベースなどのコンテナと永続化データボリュームのマウントを自由に組み合わせ、docker compose up -d の一発でアプリが立ち上がり、手元で動作確認できます。この体験をクラウドの Kubernetes クラスタで動く本番サービスでもそのまま再現したい、というのが Kompox の基本的な発想です。

Kompox に先行するプロジェクトとして Kompose があります。Kompose は Docker Compose ファイルを Kubernetes マニフェストに変換するツールですが、変換以上のことはできず、本番サービス運用のツールとしては不十分です。

Kompox は Kompose のアイディアを大きく拡張し、compose.yml の変換にとどまらず、クラウド各社のマネージド Kubernetes クラスタ・RWO PV・ディスクスナップショットといったクラウドネイティブリソースの運用にまで踏み込むことで、本番サービス運用に耐えるツールを目指しています。

下の図は、Kompox が実現する構成の全体像を示したものです。複数のアベイラビリティゾーン (AZ) にまたがる Kubernetes クラスタ上に、compose.yml で定義したコンテナ群が Pod として配置されます。各 Pod の永続データは AZ ごとの RWO ディスクに格納され、スナップショットを通じたバックアップや AZ 間マイグレーションが可能です。図中の「Kubernetes-managed」は Kubernetes 自身が担う領域（Pod のスケジューリングやサービスルーティングなど）、「Kompox-managed」は Kompox が担う領域（RWO ディスクやスナップショットのライフサイクル管理）を示しています。

Kompox が目指すもの¶

Kompox は RWO PV を前提とするステートフルなコンテナ Web アプリの DevOps を省力化するオーケストレーションツールです。その目標は次の点に集約されます。

compose.yml ベースのワークフローでローカルからクラウドまでシームレスに動かす: compose.yml はローカルの docker compose でもそのまま使えますし、kompoxops CLI を通じてクラウド各社の Kubernetes クラスタ上にもデプロイできます。開発者は compose.yml と KOM (Kompox Ops Manifest) 設定ファイルを用意するだけで、ステートフルアプリの本番運用に適した Kubernetes リソース構成を自動生成し、デプロイできます。

クラウド間の差異を吸収する: Provider Driver というアーキテクチャ層により、AKS (Azure)・OKE (OCI)・EKS (AWS)・GKE (Google)・K3s (Self-hosted) における RWO PV やスナップショット機能の差異を吸収します。一度書いた定義ファイルをマルチクラウドで活用できます。

ディスクとスナップショットのライフサイクルを管理する: RWO 永続ボリュームの作成からバックアップ・リストア、障害発生時のアベイラビリティゾーン (AZ) 間・リージョン間・クラウド間へのマイグレーションまで、クラウドネイティブなスナップショット機能を活用して自動管理します。Pod・ディスク・スナップショットは AZ を意識して配置・管理されます。

ノードプールとスケジューリングを最適化する: クラウド側のキャパシティ・クオータ制約と折り合いながら、スペックや優先度の異なる複数のノードプールを構成し、Pod の適切なスケジューリングとコスト最適化・耐障害性を実現します。

PaaS として整備する 将来的には、組織内のコンテナアプリホスティングプラットフォームとして整備し、RBAC やビリングの仕組みも備えた PaaS として提供することを目指します。

Kompox が想定する可用性目標¶

Kubernetes の能力をあえて使わない¶

Kubernetes を使うからには水平オートスケーリング、マルチレプリカによる高可用性、ローリングアップデートによるゼロダウンタイムデプロイといった機能を活用するのが一般的です。しかし Kompox はこれらの能力をいずれも前提にしていません。

Kubernetes のエコシステムは「Cattle, not Pets」（個体を使い捨て可能な家畜として扱い、ペットとして大切にしない）という哲学を前提に発展してきました。Kompox はその逆で、各ワークロードを固有のデータを持つ「Pet」として扱いながら、Kubernetes のインフラ層としての能力――宣言的な構成管理、ヘルスチェックと自動再起動、API による運用自動化――だけを活用します。言い換えれば、Kubernetes をプログラマブルな VM マネージャーとして使うというのが Kompox の立場です。

シングルレプリカ前提の可用性¶

Kompox が対象とするのは Docker Compose で記述・運用されていた Web アプリのような、永続データの全てを内包するステートフルワークロードであり、各ワークロードはシングルレプリカでの運用を基本とします。データベースなどもマネージドサービスには逃がさず、RWO ストレージの性能を活かしてコンテナ上で動かします。

この前提のもとで、次の可用性目標を設定しています。

RWO の「単一ノード専用」という制約に起因する停止時間をいかに短縮するか、そのための仕組みを Kompox が引き受けます。

ゾーン冗長ストレージによる RPO=0 の達成¶

前述の表では AZ 障害時の RPO をスナップショット時点としていますが、一部のクラウドプロバイダはブロックストレージの ゾーン冗長 (Zone-Redundant) 構成を提供しており、これを利用すれば AZ 障害時にも RPO=0 を達成できます。

ゾーン冗長ストレージはコストが高く（通常のブロックストレージの約 2 倍）、利用可能なリージョンにも制限がありますが、RPO=0 が求められるワークロードには有効な選択肢です。Kompox はゾーン冗長ストレージの利用をサポートしており、Provider Driver がプロバイダごとの差異を吸収します。

Kompox の開発ロードマップ¶

Kompox は次のような開発ロードマップを描いています。

• v1 (Kompox CLI)
  • 基本的な kompoxops CLI と Provider Driver を実装し、AKS 上で RWO PV を伴うシンプルな Compose アプリのデプロイとスナップショット管理を可能にする。
  • Kompox Ops Manifest (KOM) フォーマットを定義・実装し、Workspace・Provider・Cluster・App の各レイヤーで構成を管理できるようにする。
  • OKE・EKS・GKE・K3s など他のクラウドプロバイダへの対応を追加し、マルチクラウドで同一の定義ファイルを使えるようにする。
  • AZ 障害など大規模インシデントからの自動復旧機能を実装し、RTO を大幅に短縮する。
• v2 (Kompox PaaS)
  • Kompox CLI 実装をベースに Kubernetes をターゲットとして次の実装を行う。
    • Kompox CRD: Kubernetes ネイティブなリソースとして Compose アプリの定義と管理を可能にする。
    • Kompox Operator: Kubernetes コントローラとしてアプリのライフサイクル管理を行う。
  • マルチテナント PaaS 機能を実装して組織内のコンテナアプリホスティングプラットフォームを実現する。
    • ひとつの Kompox インスタンス上で複数のチーム・プロジェクトが独立してアプリをホストできるようにする。
    • クラウドリソースの使用量に基づくビリング機能を実装し、コスト管理を支援する。