コンテナと運用モデルをまず区別する
小さなチームはPaaSを使い、会社が大きくなったらKubernetesへ移るべきだ、といった説明は実際の選択にはあまり役立ちません。人数が同じでも、Linux・Network・Incident Responseを自ら運用できるチームと、Application開発に集中するチームでは、担えるインフラ責任がまったく異なるからです。
Computeの選択で最初に問うべきことは「私たちにどれほど大きな技術が必要か」ではありません。「どの統制が必ず必要で、その統制を得るために生じる反復的な運用業務を誰が継続して担うのか」です。
VM、PaaS、Managed Container、Kubernetesは発展段階ではありません。同じ会社でも、古い業務システムはVMに、公開APIはManaged Containerに、他のプラットフォームワークロードはKubernetesに置くことができます。最も適したモデルは、必要な統制を満たす候補の中で、チームのComplexity Budgetに収まるモデルです。
Containerはアプリケーションをパッケージングして実行する方法であり、それ自体が一つの運用責任モデルではありません。PaaSがContainer Imageのデプロイを受け付けることもあり、KubernetesもContainerを実行します。逆に、VM一台でDockerを直接運用することもできます。そのため、本稿で比較する四つのモデルは以下の定義に従います。
Managed Containerの代表的な形態は、Cloud RunやAzure Container Appsのように、Containerをデプロイするが、Kubernetes Clusterを自ら運用しないサービスです。Cloud Runの現行ドキュメントも、別途Clusterを作成したりInfrastructureを管理したりせずに、Service・Job・Worker Poolを実行する構造を説明しています。Kubernetesは、Managed KubernetesでControl PlaneをProviderに委ねても、ApplicationとWorkload Policyまで自動的に消えるわけではありません。[2] つまり「Containerを使いたい」という理由だけでKubernetesが必要になるわけではありません。
- VM
- Guest OSから先の大部分をチームが直接管理するモデルです。
- PaaS
- SourceやApplication Artifactを載せれば、ProviderがOSとRuntimeを含むPlatform領域の大部分を管理するモデルです。
- Managed Container
- Container Imageの自由度は保ちつつ、ClusterとHostの運用をProviderに委ねるモデルです。Containerをデプロイするが、Kubernetes Clusterを自ら運用しない形態が代表的です。
- Kubernetes
- Container WorkloadのScheduling、Service Discovery、Resource Policy、Rollout、Networking、Storage IntegrationをKubernetes APIで制御する運用モデルです。
Computeの選択をComplexity Budgetに置き換える
Compute Operating Modelを決めるときは、三つのことを併せて見る必要があります。
一つ目はRequired Control、どの程度の統制が本当に必要かです。標準的なHTTP Routingといくつかの環境変数があれば済むアプリケーションと、特定のNetwork Topology・GPU Placement・Privileged Workload・細かなService-to-Service Policyが必要なプラットフォームは、同じ水準の統制を要求しません。プラットフォームが提供する抽象化のために実際の要件を実装できないなら、より低い水準の統制を手元に持つ必要があります。
二つ目はSustainable Operations、その統制を継続して運用できるかです。一度インストールできることと、Productionで継続して運用できることは異なります。OS Patch、Certificate、Image Update、Nodeの交換、Runtime Upgrade、Autoscaling、Network Policy、Logging、Alert、Backup、障害対応を今後も担うOwnerが必要です。[3] Ownerのいない運用責任は、チームのComplexity Budgetに含まれているとは言えません。
三つ目はAcceptable Exit Cost、抜け出せるかです。導入が容易であることは、常に離脱が容易であることを意味しません。Application Runtimeだけを移せば済むのか、Deployment設定・IAM・Network・Storage・Managed Database・Observability・CI/CDまで作り直す必要があるのかを、別に見なければなりません。
簡単に表現すると次のようになります。選択可能なOperating Model = 必要な統制を満たし + 反復的な運用責任がチームの能力を超えず + Exit Costが許容範囲にあるモデル。この条件を通過した候補が複数あるなら、最も「モダン」なものを選ぶ理由はありません。継続して運用すべき複雑さがより少ない側が基本の候補になります。
サービス構成から運用基準まで — ネットワークとサーバーを設計し、デプロイ経路、アクセス権限、バックアップ基準を整えます。
Compute Operating Model Decision Matrix
以下の表は、製品機能の優劣ではなく、運用責任を比較するためのMatrixです。
このMatrixで注目すべき点は、Kubernetes列の運用負担が一つの値ではないことです。Kubernetesの公式ドキュメント自体が、Production Clusterを自ら運用するのか、Providerにどこまで委ねるのかを先に決めるよう案内しています。[6] 現在はGKE AutopilotやEKS Auto Modeのように、Worker NodeとInfrastructure Operationの大部分までProviderが引き受ける形態もあります。
逆に、マネージドサービスだからといってApplicationの責任までなくなるわけでもありません。MicrosoftのShared Responsibility Modelでは、IaaSは顧客がVM・OS・Applicationを管理し、PaaSではOSの責任がProvider側へ移りますが、データ・Identity・ConfigurationとApplication水準の責任は引き続き顧客に残ります。[4]
判断軸 | VM | PaaS | Managed Container | Kubernetes |
|---|---|---|---|---|
| Number of Services | 少数または強く結合したサービスでも単純に運用できます。増えると、デプロイ・設定の標準化が別の課題になります | 標準的なWeb/API中心の複数Appをそれぞれ運用するのに向いています | 独立してデプロイされる複数のContainer Service・Jobによく合います | 複数のWorkloadに共通のScheduling・Policy・Platform APIが必要なとき、価値が大きくなります |
| Stateful / Stateless | Local Stateまで直接制御できますが、Backup・HA・Migrationの責任も大きくなります | 通常、永続状態は外部のManaged DB・Storageに分離します | Statelessな実行と外部Stateの組み合わせが単純です | Stateful Workloadも可能ですが、StorageClass・Backup・Upgradeの運用まで考慮する必要があります |
| Traffic Variability | CapacityとScalingの構造を自ら設計します | プラットフォーム内蔵のScalingを使います | Request・Eventベースの自動拡張に有利なサービスが多いです | PodとNodeのScalingを細かく設計できますが、設定と運用責任が伴います |
| Deployment Frequency | Pipeline・Artifact・Rollbackの体系を自ら構築します | プラットフォーム標準のDeployment経路を使いやすいです | Image RevisionベースのデプロイとTraffic Controlが一般的です | Rolling Update・GitOpsのような強力な標準化が可能ですが、Platformの運用面が広がります |
| Isolation | VM単位のOS境界を自ら構成します | Providerが提供する分離モデルの中で選択します | Container Instance・Environment単位のPlatform分離を使います | Namespace・Node・Clusterなど多様な境界を設計できますが、要求水準に合わせた別途のポリシーが必要です |
| Networking | OS・Firewall・Routeまで高い統制を持ちます | 最もOpinionatedです。標準のネットワーク経路に合う場合にのみ単純です | VPC Integration・Ingress・Egressなど中程度の統制です | CNI、NetworkPolicy、Ingress/Gateway、Service Meshなど、高い統制と広い運用面を併せ持ちます |
| Scaling | VMまたはProcessのScaleを自ら設計します | PlatformのScale機能が中心です | Instance/Request/Event ScalingをProviderに大きく委ねます | Pod・Node・Custom Metricベースで非常に細かく構成できます |
| Portability | OSとApplication自体は移しやすい場合がありますが、Network・Data・Managed Serviceは別問題です | Platform Runtime・Build・Configurationへの依存を確認する必要があります | Container Imageの移植性は高くなり得ますが、周辺のPlatform設定は別問題です | Kubernetes APIは共通基盤を提供しますが、Storage・Load Balancer・IAMなどProvider Integrationは別途です |
| Platform Operations | OS・Runtime・Patch・Agentなどをチームが管理します | 低い | 低い〜中程度 | 中程度〜高い。Managed/Auto Modeによって、Node運用の負担は大きく減り得ます |
| Observability | Agentと収集経路まで自ら設計します | 基本のPlatform Telemetryを活用します。Applicationの観測は引き続きチームの責任です | Platform Log・Metric Integrationを活用します。Application Trace・SLIは別途です | Applicationだけでなく、Cluster・Pod・Node・Control Surfaceまで観測範囲が広がります |
| Security Responsibility | Applicationに加えて、OS Patch・Host・Networkの責任が大きいです | OSの責任はProvider側へ移りますが、Code・Data・Identity・Configurationはチームの責任です | Image・Application・IAM・Secret・Configurationをチームが担います | Applicationの責任に、RBAC、Pod Security、Workload Identity、Network PolicyなどKubernetes運用の責任が加わることがあります |
| On-call Capability | HostとApplicationの両方の障害に対応できる能力が必要です | Platform障害はProviderへのEscalationが可能です。Application障害の責任は残ります | Container WorkloadとDependencyを中心に対応します | Cluster/Workload Layerまで対応する運用体制が必要です。Auto ModeでもApplicationの責任は残ります |
| Regulatory / Isolation | Dedicated VM・Networkなど細かな構造を設計しやすい一方、準拠の責任も自ら負います | Platformが要求される統制を提供するかを先に検証します | 該当ServiceのIsolation・Region・Network条件を検証します | 細かなポリシーを実装できますが、Kubernetesの使用自体が規制準拠を証明するわけではありません |
| Team Capability | Linux・Network・Patch・Automationの運用能力が重要です | Applicationの運用能力が中心です | Container・Image・Cloud Runtimeの理解が必要です | Kubernetes運用・Networking・Resource・Security・Upgrade・Incidentの能力が必要です |
| Exit Cost | OS/Appの移動に加えて、Data・Network・Automationの再構成コストを確認します | Runtime・Build・Platform APIへの依存を確認します | Imageに加えて、IAM・Scaling・Network・Managed Serviceへの依存を確認します | Manifestだけでなく、CSI・Load Balancer・IAM・Observability・Dataへの依存を確認します |
VMは「OSまで統制する」という選択である
VMの長所は単純です。何をインストールするか、どのProcessを実行するか、NetworkとFile Systemをどう構成するかを自ら決めます。古いApplication、特殊なSystem Package、特定のDaemon、従来型のStateful Service、OS水準の設定が重要なWorkloadであれば、この統制がむしろ最も単純な解になり得ます。
問題は、統制権とともに運用責任も戻ってくることです。OSのセキュリティ更新が滞ったとき誰が処理するのか、Runtimeをいつ上げるのか、Diskが満杯になったら誰が対応するのか、サーバー一台が落ちたときどう立て直すのかまで、チームの問題です。
したがって「トラフィックが小さいからVM」より良い問いはこれです。このWorkloadは本当にOSの統制を必要としているのか、そしてそのOSを継続して運用する人がいるのか。どちらか一つでも否なら、VMの自由度は長所ではなく、使われない責任になり得ます。
PaaSは責任を限定する契約に近い
PaaSの最大の長所は、Serverの数が少ないことにあるのではありません。チームが責任を持つLayerが減ることにあります。Azureの現行のShared Responsibilityドキュメントも、PaaSではProviderがOSとPlatform Serviceを管理し、利用者はApplication・Data・Identity・Configurationにより集中する構造を示しています。[4]
一般的なWeb Application、REST API、Background Processが、Platformが支援するRuntimeとDeployment Modelの中で十分に動作するなら、この制約は損ではないかもしれません。むしろ「OSに接続して何でもできるわけではない」ことが、運用の複雑さを防ぐGuardrailの役割を果たします。
逆に、特定のSystem Package、Runtime Extension、特殊なNetworking、長時間のProcess、サポートされないProtocolのように、Platform Contractの外側の要求が繰り返されるなら、PaaSを無理に回避するコストが大きくなります。そのとき必要なのはすぐにKubernetesではなく、もう一段多いApplication Runtimeの統制が必要かを確認することです。
Managed Containerは自由度と運用境界の折衷である
Managed Containerはこの中間領域を担います。チームは自ら作ったContainer ImageにRuntimeとSystem Dependencyを含めることができますが、どのVMに配置するか、Host OSをどうパッチするか、Cluster Control Planeをどう運用するかはProviderに委ねます。
現在のCloud Runは、HTTP Serviceだけでなく、Batch Jobと常時実行のWorker Poolまで支援しています。Serviceは負荷に応じてInstanceを自動的に増減でき、必要なら最小・最大InstanceやManual Scalingも構成できます。Azure Container Appsも、ServerやContainer Orchestration Infrastructureを自ら運用せずにContainer Applicationをデプロイし、HTTP・Event・CPU・Memoryの条件に応じて拡張するモデルを提供しています。
したがって、標準的なPaaS Runtimeより自由なImageが必要だがNodeには関心がなく、API・Worker・Jobを独立してデプロイしながらTrafficの変化はPlatformに委ねたい場合は、Managed Containerが有力な候補になります。
しかし、ここでもチームの責任は消えません。誤ったContainer Image、Secret、IAM、ApplicationのMemory Leak、DB Connectionの枯渇や誤って設定した最大Instance数は、Providerが代わりに解決してくれるものではありません。Platform Operationsを減らしたのであって、Application Operationsを取り除いたわけではありません。
Kubernetesが必要になるのは「トラフィックが増えたとき」ではない
Kubernetesを導入する最も弱い根拠の一つが「後で大きくなりそうだから」です。Trafficが急増するという理由だけでKubernetesが必要になるわけではありません。マネージドのContainer PlatformもTrafficやEventに応じてInstanceを拡張できます。
サービス数も単独の基準ではありません。十個のAPIがすべて同じデプロイ・Network・Securityのパターンを使うなら、Managed Containerで十分に運用できることもあります。逆に、サービス数が多くなくても、Workload Scheduling、特殊なHardware、細かなNetwork Policy、KubernetesエコシステムのOperatorやCRD、組織共通のDeployment Policyを直接統制する必要があるなら、Kubernetes APIが意味を持ち得ます。Kubernetesを検討する理由は、おおむね同じ運用課題を複数のWorkloadで繰り返し解決する必要があり、その課題をPlatform APIとPolicyで標準化する価値があるときに生まれます。
一方で、Production Kubernetesが追加する運用面を無視してはいけません。Kubernetesの公式ドキュメントは、Production環境ではControl Planeの可用性だけでなく、Worker Node、User Access、Resource Policyなどを別途扱う必要があると説明しています。[7] Managed Kubernetesはこのうち一部をProviderに委ねますが、GKEの現行のShared Responsibilityドキュメントでも、Application Code、Build File、Container Image、Data、IAM/RBAC、PodとWorkload、MonitoringとIncident Responseなど、相当な責任が利用者に残っています。
「Managed Kubernetesだから、Cluster運用を知らなくてもよい」も正確ではありません。EKS Auto ModeやGKE Autopilotのように、Node・Patch・Scalingをより多く委ねられるモデルは、確かに運用負担を下げます。しかし、Kubernetes APIを使うWorkloadのResource、Policy、Identity、Deployment、そして障害判断までProviderが代わりに所有するわけではありません。
人数ではなく、実際の運用能力を書き出す
「開発者五名だがKubernetesは可能か？」という問いだけでは判断できません。五名のうち一名がProduction KubernetesとNetwork、Incident Responseを継続して担当できるチームと、五名全員がProduct Feature開発を主業務とするチームは、まったく異なるComplexity Budgetを持ちます。
したがって、役割ごとに実際のOwnerがいるかをComplexity Budget Cardに書き出すほうがよいです。カードには、OS/Host Patch、Runtime/Base Image Upgrade、Deployment/Rollback、Network/Access Policy、Secret/Identity、Scalingポリシーの責任者を書きます。続いて、Application Observability、Platform Observability、Backup/Restore、Platform Upgradeの責任者と、Incident Commander、夜間・休日のEscalation、Provider Support Escalationの担当を書きます。最後に、各項目のRunbookの有無と、直近の実際の復旧または障害訓練の日付を書きます。
人の名前を埋めるだけでは十分ではありません。該当業務を遂行する時間と権限、観測手段、RunbookとEscalation経路まで揃っていてこそ、実際の運用能力とみなせます。[5] このため、三名のチームでもKubernetesが合理的な場合があり得ますし、開発者が数十名いる組織でもPlatform Ownershipがなければ、Kubernetesの運用は適さないことがあります。
依存関係を確認し、移行を検証 — 一緒に移すシステムを整理し、リハーサルと切戻し条件を整えてから本番移行を実施します。
Statefulという理由だけでKubernetesを選ばない
KubernetesはStatefulSetとPersistent VolumeでStateful Workloadを実行できます。だからといって、DatabaseをKubernetesの中に入れることが自動的により良い運用モデルになるわけではありません。Persistent Storageを運用すれば、Volume Provisioning、Availability Zone、Backup、Restore、UpgradeとFailure Recoveryを併せて扱う必要があります。
KubernetesのStorageClassも、実際のStorageを生成するprovisionerとProviderごとのParameterを使います。公式ドキュメントのAWS EBS、EFS、Azure、vSphereなどの例でも、同じKubernetes APIの背後に異なるStorage Integrationが付いています。[2]
小さなチームであれば、Application ComputeはPaaSやManaged Containerに置き、StateはManaged Databaseに委ねる組み合わせのほうが、より低いComplexity Budgetで済むこともあります。逆に、Data LocalityやStorage Controlのために自ら運用する必要があるなら、VMまたはKubernetesが候補になり得ます。Statefulという一語が答えを決めるわけではありません。
PortabilityはContainer Image一つで判断しない
Containerを使えば、Application Runtimeを一定のImageとしてパッケージングできるため、Computeの移動性には役立ちます。Kubernetesも共通APIを提供し、DeploymentやServiceのような一部の運用表現を複数の環境で再利用しやすくします。しかし、これを「Kubernetesを使えばVendor Lock-inが消える」へと拡大してはいけません。
たとえば、KubernetesのService type: LoadBalancerは外部Load Balancerという共通概念を提供しますが、実際の実装はCloud Providerが担い、ProviderごとのAnnotationと制約があり得ます。Storageも、CSI Provisioner、StorageClass Parameter、実際のStorage Backendによって異なります。[2]
実際のExit Costは次を併せて計算する必要があります。Exit Costは下記八項目の合計です。VMだからこのコストが0になるわけでも、PaaSだから必ず大きいわけでも、Kubernetesだから自動的に小さくなるわけでもありません。Compute PortabilityとSystem Exit Costは別の指標です。
- Exit Cost
- 下記八費用項目の合計です。
- Application変更
- 総費用へ合算します。
- Runtime / Deployment設定変更
- 総費用へ合算します。
- Network / Security再構成
- 総費用へ合算します。
- Data移動
- 総費用へ合算します。
- IAM / Secret再構成
- 総費用へ合算します。
- CI/CD変更
- 総費用へ合算します。
- Observability変更
- 総費用へ合算します。
- 運用手順・教育変更
- 総費用へ合算します。
規制と分離の要件はTechnologyの名前では解決しない
規制があるという理由で「PaaSは不可でKubernetesでなければならない」と結論づけることも、逆に「Managed Serviceだからセキュリティ責任はProviderにある」と結論づけることもできません。確認すべきは実際の要件です。
特定のRegionにDataを保管する必要があるか、Dedicated Hostが必要か、Network経路を統制する必要があるか、管理者アクセスを監査する必要があるか、Workload間の分離水準はどの程度かをまず確定する必要があります。その次に、各サービスが該当する統制を実際に提供するかを比較します。[8]
Kubernetesは多くの統制を実装できる道具ですが、Kubernetesという名前自体はCompliance Evidenceではありません。Managed Serviceも、ProviderがInfrastructureに責任を持つという理由だけで、顧客のData・Identity・Applicationの責任がなくなるわけではありません。
実際の選択はこの順序が最も単純である
先に読む記事でWorkload Placement Cardが作られていれば、次の順序で絞り込めます。その記事は、ワークロードと制約条件を先に確認し、Operating Modelを決めてからVendorを比較するよう境界を定めています。
一つ目に、Workloadが必ず要求する統制を書き出します。OSアクセス、特殊なRuntime、Network、Isolation、GPU、Deployment Policyのように、なければ候補から脱落する項目だけを残します。二つ目に、各モデルでチームに残る反復的な運用業務を書き出します。Patch、Upgrade、Scaling、Network、Observability、Backup、Incident ResponseのOwnerを確認します。三つ目に、必要な統制を提供できない候補を除外します。Platformの制約を無理に回避して候補を維持することはしません。
四つ目に、チームのComplexity Budgetを超える候補を除外します。「学べる」という計画と、現在Productionに責任を持てる能力を区別します。五つ目に、残った候補の中からExit Costと運用の複雑さが最も低いモデルを選びます。六つ目に、Vendorと商品は最後に比較します。同じOperating Modelの中でも、Region、Networking、Scaling、Supportと実際の責任境界が異なるからです。
この順序は、PaaSから始めてKubernetesまで順番に昇格せよという意味ではありません。最初からVMが合っていることもあり、PaaSに長く留まることが合理的なこともあり、Managed ContainerとKubernetesを同時に使うことも可能です。
Workloadを当てはめると違いがよく見える
以下の表は、いくつかの代表的な状況に四つのモデルを当てはめた結果です。この表でも、サービス数や会社の規模は直接の選択基準として登場しません。その数字は、運用の複雑さを生む多くの入力の一つにすぎません。
状況 | まず見る候補 | 理由 | 追加確認 |
|---|---|---|---|
| 公開Web API + Worker + 外部Managed DB、Traffic変動が大きい、標準HTTP | PaaS / Managed Container | OSやClusterよりApplicationのデプロイとAutoscalingが重要です | PaaS Runtimeの制約、Containerの必要性、Cold Start、DB Connection |
| 古い業務Application、特定のDaemon・System PackageとOS設定が必要 | VM | OSの統制が実際の要件です | Patch、Backup、Failover、Deployment自動化のOwner |
| 複数のAPI・Worker・Batchが独立してデプロイされるが、NetworkとSchedulingの要件は標準的 | Managed Container / PaaS | 独立したデプロイは必要ですが、Cluster Controlまでは必要ない可能性があります | Service別のScaling、IAM、Cost、Platform Limit |
| 複数のチームとWorkloadが共通Platformを使い、細かなScheduling・Policy・Network Controlが必要 | Kubernetes | 反復する運用課題を共通APIとPolicyにする価値があります | Platform Owner、Upgrade、RBAC、Network、Observability、On-call |
| 特定の規制により専用の分離・Network・Audit条件が存在 | 要件に応じてVM / Managed Platform / Kubernetesのいずれも可能 | Technologyの名前ではなく、実際の統制要件が候補を決めます | 規制の原文、Provider Architecture、Audit Scope |
最も高い抽象化が最も良いわけではない
最も低い抽象化が最も強いわけでも、最も高い抽象化が最も良いわけでもありません。VMは自由度が高いですが、その自由を維持するためにOSを運用しなければなりません。PaaSは多くの決定をPlatformに委ねますが、その代わりにPlatform Contractを受け入れる必要があります。Managed Containerは、Application Runtimeの自由度とPlatform運用の委任の間の中間的な選択を提供します。
KubernetesはScheduling、Policy、NetworkingとPlatform Extensionに高い統制力を提供しますが、そのAPIとWorkload運用に対する責任も併せて持ち込みます。[1] Managed Kubernetesの発展によってその負担を相当に減らすことはできても、責任境界が完全になくなるわけではありません。
小さな開発チームに必要な問いは「Kubernetesを使うほど大きくなったか？」ではありません。今のWorkloadが要求する統制の水準はどこまでで、その統制を得るために生じる反復的な運用責任を今後も担えるのか、です。その答えを先に書き出せば、VM、PaaS、Managed Container、Kubernetesは成熟度の順序ではなく、それぞれ異なる責任契約として見え始めます。そしてそのときから、Computeの選択はずっと単純になります。
