Kubernetes and Cloud Native Associate (KCNA) #5 Cloud Native Architecture (16%): オートスケーリング、サーバーレス、コミュニティ、オープンスタンダード
#4 では、コンテナランタイム・セキュリティ・ネットワーキング・ストレージ・Service Mesh まで、Kubernetes の下でコンテナを支える層を整理しました。今回の記事は視線を一段上へ引き上げます。Kubernetes というツールそのものではなく、Kubernetes が属するクラウドネイティブという設計思想と、その生態系全体を問うドメインです。
KCNA の Domain 3 Cloud Native Architecture は比重 16% で、試験の 6 分の 1 ほどを占めます。このドメインはコマンドやマニフェストではなく、なぜこう設計するのかを問います。なぜ負荷に応じて自動で増やし減らすのか、なぜインフラを自分で管理しないサーバーレスを使うのか、なぜ CNCF という財団とオープンスタンダードが重要なのか。この記事でその思想と語彙を整理します。
クラウドネイティブとは何か #
このドメインの出発点は クラウドネイティブ (cloud native) の定義です。CNCF (Cloud Native Computing Foundation) はクラウドネイティブを次のように定義します。パブリック・プライベート・ハイブリッドクラウドのような現代的で動的な環境で、スケーラブルなアプリケーションを構築し実行する方式です。その代表技術としてコンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラ、宣言型 API を挙げます。
試験ではこの定義を構成するキーワードそれぞれが何を意味するのかを分類できる必要があります。
| キーワード | 意味 |
|---|---|
| コンテナ (container) | アプリケーションと依存関係を一緒にパッケージングし、どこでも同じように実行する単位 |
| マイクロサービス (microservices) | 一つの巨大なアプリケーションの代わりに、小さく独立してデプロイ可能なサービスへ分割した構造 |
| 宣言型 API (declarative API) | 命令の手順ではなく望む状態を宣言すれば、システムがその状態へ収束させる方式 |
| イミュータブルインフラ (immutable infrastructure) | 実行中のサーバーを直して使うのではなく、新しいイメージで丸ごと入れ替える運用モデル |
| サービスメッシュ (service mesh) | サービス間の通信・観測・セキュリティをアプリケーションコードの外で担う層 |
この定義を支える運用特性がもう二つあります。
- 自己修復 (self-healing)。コンテナやノードが死ぬと、システムが自ら再生成して復旧します。Kubernetes のコントローラーが望む状態と現在の状態の差を埋め続ける reconciliation ループこそが、自己修復の実装です。
- 回復性 (resilience)。一部の構成要素が失敗しても、システム全体は動き続けるように設計します。レプリケーション (replication)、障害分離、リトライがその手段です。
ここに 12-factor app というクラウドネイティブアプリケーションの設計原則も一度は知っておくとよいでしょう。設定を環境変数へ分離する、アプリケーションをステートレス (stateless) なプロセスにする、ログをイベントストリームとして扱う、といった 12 個の指針で、クラウドの上で拡張とデプロイが容易なアプリケーションを作るための推奨案です。
オートスケーリング #
クラウドネイティブの中核的な約束は、負荷に合わせて資源を自動で増やし減らすことです。Kubernetes の生態系にはこの自動拡張を担うメカニズムが複数の層に分かれており、KCNA は それぞれが何を調整するのかを正確に区別できるかを問います。
HPA (Horizontal Pod Autoscaler) #
HPA は Pod の個数を水平に増やし減らします。CPU 使用率やメモリ、あるいはカスタムメトリクスが設定した目標値を超えると Pod のレプリカ数を増やし、負荷が減れば再び減らします。「トラフィックが集中すれば同じ Pod を複数立てる」が HPA の絵です。最もよく使われ、試験にも最も多く出るオートスケーラーです。
VPA (Vertical Pod Autoscaler) #
VPA は Pod 一つに割り当てられるリソース (CPU・メモリの requests/limits) を垂直に調整します。Pod の個数ではなく Pod 一つの大きさを増やしたり減らしたりする方式です。適正なリソース要求量を自動で推奨し適用して、過剰割り当てによる無駄や過少割り当てによる性能低下を減らします。HPA と同じメトリクス (CPU・メモリ) を同時に基準とすると衝突するため、通常は両方を同じワークロードに併用しません。
Cluster Autoscaler (CA) #
CA は ノード (node) の個数を調整します。Pod がスケジュールされる場所がなく Pending 状態のまま残ると、クラウドプロバイダーへノードを追加で要求し、ノードが空いていれば減らしてコストを削減します。HPA が Pod を増やしたのにその Pod を載せるノードが足りないとき、CA がノードを補うという形で、HPA と CA は異なる層で協力します。
KEDA (Kubernetes Event-Driven Autoscaling) #
KEDA は イベント駆動のオートスケーリングを担う CNCF プロジェクトです。CPU・メモリだけでなく、メッセージキューの滞留長、Kafka トピックの lag、データベースクエリの結果のような 外部イベントソースをトリガーに Pod の数を増減します。特に処理すべきイベントがないとき Pod を 0 個まで減らす scale-to-zero をサポートする点が核心です。HPA は基本的に最低 1 個を維持しますが、KEDA は 0 まで下がり、イベントが入ると再び立てます。
四つのオートスケーラーの比較 #
| メカニズム | 何を調整するか | 基準 | 特徴 |
|---|---|---|---|
| HPA | Pod の個数 (水平) | CPU・メモリ・カスタムメトリクス | 最も一般的。最低 1 個を維持 |
| VPA | Pod のリソースの大きさ (垂直) | CPU・メモリの使用パターン | HPA と同じメトリクスの同時使用は衝突 |
| Cluster Autoscaler | ノードの個数 | Pending Pod / ノードの遊休 | インフラコストに直接影響 |
| KEDA | Pod の個数 (イベント駆動) | キュー長・Kafka lag などの外部イベント | scale-to-zero をサポート |
試験のポイントは明確です。HPA は水平 (個数)、VPA は垂直 (大きさ)、CA はノード、KEDA はイベントと scale-to-zero です。この一行を取り違えなければ、この領域の設問はほとんど解けます。実務で自分で立ててみた流れは 実務トラック中級 #6 オートスケーリング にまとめておきました。
オートスケーリングが動作する原理 #
オートスケーリングが可能になるには、現在の負荷を測定するメトリクスの出どころが必要です。HPA と VPA はクラスターの metrics-server やカスタムメトリクス API から CPU・メモリ使用量を読み取り、目標値と現在値の比率を計算して望むレプリカ数を算出します。こう算出した値を Deployment のレプリカ数へ反映するのが HPA の一サイクルです。
ここで注意したい点は、オートスケーラーも宣言型モデルの上で動作するという事実です。HPA は「Pod を増やせ」という命令を一度下すのではなく、望むレプリカ数を計算し続けて現在の状態をその値へ収束させます。負荷が揺れるとき Pod 数が過度に振動しないように安定化区間 (stabilization window) を置くのも、このためです。自己修復と同様、オートスケーリングも reconciliation ループの一形態として理解すると、試験設問の文脈がつかみやすくなります。
サーバーレス #
サーバーレス (serverless) は インフラを自分で管理せずにコード (関数やコンテナ) を実行するモデルです。名前と違ってサーバーがないのではなく、サーバーのプロビジョニング・拡張・パッチのような運用をクラウドプロバイダーやプラットフォームが代わりに担い、開発者がサーバーを意識しないモデルという意味です。
サーバーレスの特性は次のとおりです。
- リクエストがなければ 0 まで減る (scale-to-zero)。遊休状態では資源を使わないため、コスト効率が高いです。
- 使った分だけ課金。実行時間と呼び出し回数を基準にコストが課されます。
- イベント駆動。HTTP リクエスト、メッセージの到着、ファイルのアップロードのようなイベントが関数の実行を引き起こします。
FaaS と Knative #
サーバーレスを実装する代表的な形態が FaaS (Function as a Service) です。関数単位でコードをデプロイすると、プラットフォームが呼び出しに合わせて実行し拡張します。パブリッククラウドのマネージド FaaS が広く使われますが、KCNA でより重要なのは Kubernetes の上でサーバーレスを実装するプロジェクトです。
- Knative。Kubernetes の上にサーバーレスワークロードを載せるための CNCF プラットフォームです。リクエストがなければ Pod を 0 個へ減らし、リクエストが入ると自動で再び立てる scale-to-zero、そしてイベントルーティング (Eventing) 機能を提供します。「Kubernetes の上のサーバーレス」を問う設問の正解はほぼ Knative です。
- OpenFaaS。Kubernetes の上で関数をコンテナとしてパッケージングして実行する、もう一つのサーバーレスフレームワークです。
サーバーレスはいつ適するか #
サーバーレスは トラフィックがばらつくか断続的なワークロード、イベントに反応する短い作業、すばやく作って立ててみるプロトタイプによく合います。逆に、常に一定の負荷が着実に入ってくる場合や、コールドスタート (cold start) の遅延を許容しにくい低遅延サービス、長時間実行される作業には向きにくいです。
| 状況 | サーバーレスの適合性 |
|---|---|
| 断続的・予測不能なトラフィック | 適合。遊休時に 0 まで減らしてコスト削減 |
| イベントトリガー処理 (アップロード・メッセージ) | 適合。イベント駆動の実行モデルと一致 |
| 常に高く一定の負荷 | 向きにくい。常時実行ならコストの利点が減る |
| 低遅延が重要なサービス | 注意。コールドスタートの遅延を見極める必要がある |
| 長時間バッチ作業 | 向きにくい。実行時間の制限にかかりやすい |
コールドスタートは、0 まで減っていたワークロードが最初のリクエストで再び立ち上がるまでにかかる遅延を指します。scale-to-zero がコストを節約する代わりに払う代償であり、サーバーレスの代表的なトレードオフとして試験に出やすい概念です。
コミュニティとガバナンス #
クラウドネイティブの生態系は、一社の製品ではなく CNCF というオープンガバナンス財団の下に数百個のプロジェクトが集まった共同体です。KCNA はこのコミュニティの構造を問います。
CNCF の役割 #
CNCF は Linux Foundation 傘下の非営利財団で、クラウドネイティブのオープンソースプロジェクトを 中立的に保有し育成する組織です。特定のベンダーがプロジェクトを独占できないように ベンダー中立 (vendor-neutral) のガバナンスを維持し、プロジェクトの成熟度を審査し、資格と教育プログラムを運営します。Kubernetes を最初に CNCF へ寄贈したのが Google だという事実も、たまに出題されます。
プロジェクト成熟度の段階 #
CNCF プロジェクトは成熟度に応じて三段階に分かれます。順序と意味を覚えておくことが、この領域の核心的な試験ポイントです。
| 段階 | 意味 |
|---|---|
| Sandbox | 初期・実験段階。参入障壁が低く、まだ検証中のプロジェクト |
| Incubating | 成長段階。実際のプロダクション採用事例と活発な貢献が実証されたプロジェクト |
| Graduated | 成熟段階。広範な採用と安定したガバナンスを備えた最上位の段階 |
流れは Sandbox → Incubating → Graduated です。段階が上がるほど、採用率・安定性・ガバナンス成熟度の基準が高くなります。Graduated 卒業プロジェクトの代表例は次のとおりです。
- Kubernetes。コンテナオーケストレーション。CNCF の最初の卒業プロジェクトです。
- Prometheus。メトリクス収集とモニタリング。二番目の卒業プロジェクトです。
- Envoy。高性能プロキシであり Service Mesh のデータプレーン。
- そのほか containerd、Helm、etcd、Fluentd、ArgoCD、OpenTelemetry などが卒業段階に上がっています。
オープンガバナンスと KubeCon #
CNCF プロジェクトは一社ではなく、複数の組織と貢献者が一緒に意思決定へ参加するオープンガバナンスモデルで運営されます。メンテナー、貢献者、コミュニティが公開された手続きでロードマップを決めます。このコミュニティが集まる代表的なイベントが KubeCon + CloudNativeCon です。CNCF が主催するクラウドネイティブ生態系の最大のカンファレンスで、プロジェクトの発表と事例の共有が行われます。
オープンスタンダード #
クラウドネイティブが特定のベンダーに閉じ込められない理由は、オープンスタンダード (open standard) のおかげです。標準インターフェースが定義されていれば、実装を自由に取り替えても上の層のシステムはそのまま動作します。これが ベンダーロックイン (vendor lock-in) を避け、相互運用性 (interoperability) を確保する方式です。
KCNA に出る主要な標準は次のとおりです。
| 標準 | 何を定義するか |
|---|---|
| OCI (Open Container Initiative) | コンテナの イメージフォーマットと ランタイムの規格。どのツールで作ったイメージでもどのランタイムでも実行 |
| CRI (Container Runtime Interface) | Kubernetes の kubelet とコンテナランタイムの間の標準。containerd・CRI-O を交換可能 |
| CNI (Container Network Interface) | コンテナネットワーキングのプラグイン標準。Calico・Cilium などを交換可能 |
| CSI (Container Storage Interface) | コンテナストレージのプラグイン標準。さまざまなストレージバックエンドを交換可能 |
| SMI (Service Mesh Interface) | Service Mesh を扱う標準インターフェース。実装に依存しないメッシュ設定 |
| OpenTelemetry (OTel) | メトリクス・ログ・トレースのテレメトリデータの収集・転送の標準 |
標準の本質は同じです。「上の層は標準インターフェースだけを知り、下の層の実装は自由に取り替える」です。たとえば Kubernetes は CRI というインターフェースだけ知ればよいので、その後ろに containerd があろうと CRI-O があろうと同じように動作します。CRI・CNI・CSI の境界は #4 で詳しく扱いました。OCI が イメージとランタイムを、CRI が Kubernetes とランタイムの接続を定義するという区分は混同しやすいので、分けておくほうが安全です。
ロールアウトとデプロイの概念 #
クラウドネイティブアーキテクチャは、サービスを止めずに新しいバージョンへ入れ替えるデプロイモデルを前提とします。Kubernetes の Deployment が基本で提供する方式が ローリングアップデート (rolling update) です。
- ローリングアップデート。既存の Pod を一斉に死なせず、新しいバージョンの Pod を一つずつ立てながら古いバージョンの Pod を一つずつ降ろします。この過程で常に一定数の Pod がトラフィックを受けるため、無停止 (zero-downtime) デプロイになります。問題が起きれば以前のバージョンへ戻す ロールバック (rollback) も宣言型で可能です。
- イミュータブルインフラ。実行中のコンテナを直接直さず、新しいイメージで作った新しい Pod で丸ごと入れ替えます。同じイメージから立てた Pod は常に同じ状態なので、環境差による問題を減らし、ロールバックを単純にします。
この二つの概念は、クラウドネイティブの 自己修復・宣言型モデルと一まとめです。望む状態 (バージョン v2 の Pod 3 個) を宣言すれば、Kubernetes が現在の状態をその方向へ無停止で収束させ、その過程で死んだ Pod は自動で再び立てます。
試験ポイントの整理 #
このドメインで最もよく点数を分ける比較を集めました。
- HPA vs VPA vs CA。HPA は Pod の個数 (水平)、VPA は Pod のリソースの大きさ (垂直)、CA はノードの個数です。KEDA はイベント駆動で scale-to-zero です。
- プロジェクト成熟度の段階の順序。Sandbox → Incubating → Graduated。段階が上がるほど採用率と安定性の基準が高いです。
- サーバーレスの定義。サーバーがないのではなく、サーバーの運用を意識しないモデル。Kubernetes 上のサーバーレスは Knative、scale-to-zero が核心です。
- オープンスタンダードの区分。OCI (イメージ・ランタイム)、CRI (ランタイム接続)、CNI (ネットワーク)、CSI (ストレージ)、OTel (テレメトリ)。標準の目的はベンダーロックイン回避と相互運用性です。
- CNCF の性格。Linux Foundation 傘下のベンダー中立ガバナンス。KubeCon が代表的なイベントです。
よく出会う落とし穴 #
- HPA と VPA を同じメトリクスで同時に掛ける。両方が CPU・メモリを基準とすると、片方が大きさを増やす間にもう片方が個数を減らす衝突が起きます。選択肢でこの組み合わせを正常な構成として提示すれば、落とし穴です。
- scale-to-zero を HPA の基本機能と勘違いする。基本の HPA は最低 1 個を維持します。0 まで減らすのは KEDA や Knative の特性です。
- 成熟度の段階の順序を逆にする。Sandbox が最も初期、Graduated が最も成熟です。Incubating を最も高い段階として選ぶ選択肢がよく混ざります。
- OCI と CRI を同じ標準として束ねる。OCI はイメージ・ランタイムのフォーマット規格であり、CRI は Kubernetes の kubelet とランタイムをつなぐインターフェースです。層が違います。
まとめ #
今回の記事でつかんだもの:
- クラウドネイティブ。コンテナ・マイクロサービス・宣言型 API・イミュータブルインフラ・サービスメッシュ。自己修復と回復性が運用特性
- オートスケーリング。HPA (Pod 水平)・VPA (Pod 垂直)・CA (ノード)・KEDA (イベント・scale-to-zero) の四層の区分
- サーバーレス。インフラを意識しない実行モデル。Knative と FaaS、scale-to-zero
- コミュニティ。CNCF のベンダー中立ガバナンス、Sandbox → Incubating → Graduated の成熟度段階、KubeCon
- オープンスタンダード。OCI・CRI・CNI・CSI・SMI・OpenTelemetry。ベンダーロックイン回避と相互運用性
- ロールアウト。ローリングアップデートで無停止デプロイ、イミュータブルインフラで丸ごと入れ替え
Kubernetes 入門が初めてなら、実務トラック #1 でクラスターを自分で立てる流れを先に身につけるほうが、これらの概念を体得する近道です。
次: Cloud Native Observability #
設計思想と生態系まで整理しました。これからその上で 運用中のシステムをどのように覗き込むかへ移ります。
#6 Cloud Native Observability (8%): テレメトリ、Prometheus、コスト管理 では、テレメトリの三本柱 (メトリクス・ログ・トレース)、Prometheus を通じたメトリクス収集、SLI・SLO・SLA、そしてコスト管理 (FinOps) の概念まで整理します。