アリババ ASK クラスタ

はじめに

最近チームのコンテナ化方針を検討する中で、避けて通れない問いがありました。K8S クラスタは自前で構築するのか、マネージドを買うのか、それともいっそノードすら持たないのか。ASK のような Serverless 形態のクラスタはちょうど最後の選択肢に当たるため、個別に記録しておく価値があります。

小さなチームにとって、自前 K8S の隠れたコストはしばしば過小評価されます。コントロールプレーンの高可用化、etcd のバックアップ、バージョンアップグレード、ノードへのパッチ適用。これらの作業はビジネス価値を生まないのに、どれも省くことができません。クラウドベンダーのマネージドサービスはまさにここを狙ったもので、ASK はさらに一歩進んで、ノードというレイヤーまでユーザーの視界から取り除いてしまいました。

アリババクラウド ASK（Alibaba Cloud ACK）クラスタは、アリババクラウドが提供するマネージド Kubernetes サービスです。オープンソースの Kubernetes プロジェクトをベースに、使いやすく、弾力的にスケールし、高可用で安全かつ信頼性の高いコンテナデプロイ・管理プラットフォームをユーザーに提供する、いわばサーバーレス Kubernetes コンテナサービスです。ノードを購入することなくコンテナアプリケーションを直接デプロイでき、クラスタのノードメンテナンスやキャパシティプランニングも不要で、アプリケーションに設定した CPU とメモリのリソース量に応じた従量課金となります。ASK クラスタは充実した Kubernetes 互換性を提供しつつ、Kubernetes の利用ハードルを下げ、下層のインフラ管理ではなくアプリケーションそのものに集中できるようにしてくれます。

ASK の SK は Serverless Kubernetes を指し、公式ドキュメントでは現在 ACK Serverless とも呼ばれています。通常のマネージド版 ACK との核心的な違いは次のとおりです。マネージド版はコントロールプレーンを管理してくれますが、Worker ノードは依然として自分の ECS です。一方 ASK には Worker ノードという概念自体がなく、向き合う最小リソース単位が直接 Pod になります。

什么是容器服务 Serverless 版ACK Serverless_容器服务 Kubernetes 版 ACK-阿里云帮助中心

ASK クラスタ内の Pod は、アリババクラウドの Elastic Container Instance（ECI）をベースに、セキュリティ隔離されたコンテナ実行環境で動作します。各 Pod コンテナインスタンスは、下層で軽量仮想化のセキュアサンドボックス技術により完全に強く隔離され、コンテナインスタンス同士は互いに影響しません。

この仕組みをもう少し掘り下げてみます。従来の K8S では、複数の Pod が同一ホストマシンのカーネルを共有し、隔離は namespace と cgroup に頼るソフトな隔離でした。コンテナエスケープ系の脆弱性が出れば、同じノード上の他の Pod も影響を受ける可能性があります。ECI のやり方は、各 Pod に軽量仮想マシンのサンドボックスを一枚かぶせるというもので、Pod 間でカーネルを共有せず、隔離レベルは仮想マシンに近い一方、起動速度とリソースオーバーヘッドは従来の仮想マシンよりずっと小さくて済みます。ユーザーにとってこのサンドボックス層は透過的です。提出するのは標準的な Deployment や Service といった K8S リソースのままで、スケジューリング層が Pod を ECI 上に載せて実行してくれます。

そして、Pod が宣言した CPU とメモリで課金されるからこそ、リソースの requests/limits の設定は ASK においてもはや単なるスケジューリングパラメータではなく、請求額の数字を直接決めるものになります。この点は自前クラスタの考え方とは大きく異なります。

ASK クラスタのメリット

1. 使いやすさ：ASK クラスタは直感的で分かりやすい GUI と CLI ツールを提供し、Kubernetes クラスタの作成・デプロイ・管理を簡単に行えます。
2. 弾力的なスケーリング：ASK クラスタは実際の需要に応じた自動的な拡張・縮小をサポートし、アプリケーションが常に良好なパフォーマンスを保ち、トラフィックの変動に柔軟に対応できるようにします。
3. 高可用性：ASK クラスタはマルチアベイラビリティゾーン構成を採用し、自動フォールトトレランスと自動復旧の機能を提供することで、障害発生時もアプリケーションの可用性を維持し、業務中断時間を最小限に抑えます。
4. 安全性と信頼性：ASK クラスタはネットワーク隔離、アクセス制御、データ暗号化など多層のセキュリティメカニズムを提供し、アプリケーションとデータの安全を守ります。
5. エコシステムとの統合：ASK クラスタはコンテナイメージサービス、ログサービス、クラウドモニタリングなど、アリババクラウドの他の製品・サービスとシームレスに統合され、包括的なソリューションを提供します。

この中で私が最も実用的だと感じるのは弾力的なスケーリングです。自前クラスタでオートスケーリングを実現するには、Pod を増やす前にまずスケジュール可能なノードがあることを保証しなければならず、ノードのスケールアウト自体に数分はかかるうえ、cluster-autoscaler のパラメータ調整も必要です。ASK はノードのレイヤーを抽象化して取り除いたことで、スケールアウトは「Pod を立ち上げる」という一点だけになり、スケーリングの経路がずっと短くなりました。トラフィックにはっきりしたピークとオフピークがある業務では、この差が応答速度とコストに直接反映されます。

いくつかのデメリット

1. 価格が比較的高い：ASK クラスタの利用には一定のサービス料金がかかり、予算が限られたユーザーにとっては検討要素になり得ます。年額・月額課金の ACK クラスタと比べると、従量課金はリソース配分が不均一な場合に追加費用が発生します。
2. 学習曲線がやや急：Kubernetes を使ったことのないユーザーにとっては、ASK クラスタの概念や操作方法の学習と適応に時間がかかります。
3. クラウドベンダーへの依存：ASK クラスタを使うことはアプリケーションをアリババクラウドのプラットフォームにデプロイすることを意味し、特定のクラウドベンダーに関わる制約や依存に直面する可能性があります。

価格についてもう一言。従量課金の単価は通常、年額・月額の ECS より高いため、ASK が割に合う前提は、ワークロードに本当に弾力性があることです。常駐して 7x24 フル稼働するサービスは、予約リソースに載せたほうがむしろ安くなります。選定時には、自分のワークロードの「常駐部分」と「弾力部分」がそれぞれどれくらいを占めるか、先に見積もっておく価値があります。

ハマりどころと注意点

1）リソース仕様は真面目に設定すること。ASK は Pod が宣言したリソースで課金されるため、requests を適当に大きく書けば請求額もそれに従って増え、小さすぎれば OOM になる可能性があります。リリース前に負荷試験の結果に基づいて、実際の使用量に近い設定を出しておくのがベストです。

2）標準 K8S との挙動の違いに注意すること。実ノードが存在しないということは、DaemonSet、hostPath、hostNetwork といったノードに依存する機能の使い方が通常のクラスタと異なるということです。既存アプリケーションを移行する前に項目ごとに確認し、具体的なサポート状況は公式ドキュメントを正としてください。

3）コールドスタートはゼロコストではないこと。ECI で Pod を立ち上げるのは、既存ノード上でスケジュールするよりインスタンス作成の時間が余分にかかります。レイテンシに敏感なバーストトラフィックのシナリオでは、事前のウォームアップや一定数の常駐レプリカの確保を検討するとよいでしょう。

ヒント

Serverless K8S の使い勝手を体験してみたいだけなら、まず最小スペックの Pod でテストアプリケーションを動かし、しばらく請求額を観察してからコア業務を移行するかどうか決めるとよいでしょう。

まとめ

K8S クラスタを自前で構築して維持することに比べると、投入時間が多く、メンテナンスコストが大きく、長期の保守に時間がかかり、イテレーションやアップグレードが煩雑で、パッチや脆弱性のセキュリティも自分で保証しなければならず、設定も煩雑で、チームの運用能力に一定の要求があります。ASK クラスタを直接使えばこうした悩みから解放され、より多くのエネルギーをプロダクト開発に投入できます。さらにその後トラフィックが伸びたときも、Pod のレプリカをスケールアウトするだけでよく、下層の Node リソースの物理的制約を管理する必要がありません。

私の見解はこうです。チームの規模が大きくなく、専任の運用担当もいない状況では、ASK のような Serverless クラスタは現実的な出発点です。業務規模が大きくなり、コストへの感度が高まってから、マネージド版や自前構築への移行を再評価しても、決して遅くはありません。