私は Kubernetes を必要としていなかったし、おそらくあなたも必要としていません

(benhouston3d.com)

19 ポイント投稿者 GN⁺ 2024-11-28 | 12件のコメント | WhatsAppで共有

Kubernetes を離れて Google Cloud Run を選んだ理由

Kubernetes 導入の背景

2013年にリリースしたオンライン3D編集プラットフォーム Clara.io では、ベアメタルサーバーを使ってインフラを最適化していたが、ハードウェア管理と監視に過大な作業が必要だった。
2018年の Threekit.com プロジェクトでは Kubernetes を選択。当時 Azure, AWS, Docker が Kubernetes を標準として採用し、主流になっていた。

Kubernetes の限界

コストの問題:
- 管理ノードやクラスターの冗長構成など、基本的なクラスター構築コストが大きい。
- オートスケーリングが遅く、サービスの過剰プロビジョニングが必要になり、未使用リソースのコストが発生する。
ワークロード管理の難しさ:
- ジョブスケジューリングが複雑で、組み込みスケジューラーや Argo も大量ジョブでは非効率。
複雑さの過負荷:
- 豊富な機能により、単純な作業まで複雑になる。
- Kubernetes の運用には専任の DevOps 人材が必要で、これはコスト増につながる。

Google Cloud Run への移行

Cloud Run は Kubernetes の複雑さに代わる、簡素でコスト効率の高い環境を提供する。

新しい構成

Docker コンテナベース のインフラ:
- 自動スケーリングサービス と 長時間実行ジョブ 向けコンテナを含む。
- Cloud Run はコンテナのデプロイ、スケーリング、停止管理、ジョブ実行を自動化する。

Cloud Run の利点

コスト効率:
- CPU とメモリの使用時間に応じて課金される。
- アイドル状態のサービスにはコストが発生しない。
- 例: Web3D Survey サイトは月 500,000回のトラフィック を処理しながら 月額$4 で運用可能。
高速で安定したオートスケーリング:
- Kubernetes より速く、数秒でスケールする。
- 需要急増にも迅速に対応できる。
Kubernetes 管理の負担がない:
- Cloud Run は Google の Borg を基盤としており、Kubernetes クラスターの管理が不要。
シンプルな非同期ジョブ:
- Cloud Run Tasks を使って、自動リトライや大量ジョブの実行を簡単に行える。

Kubernetes の潜在的な問題: クラスター・ロックイン

Kubernetes の機能に依存すると、クラスター外リソースとの統合や拡張が難しくなる。
特定インフラへの依存が強まり、拡張やマイグレーションが複雑になり、コストも増える。

Cloud Run 利用に関する一般的な質問

「GCP 依存は気にならないのか？」

Docker ベースの構成なので、AWS のような別クラウドへのマイグレーションもおよそ1週間で可能。
現実的には、政治的要因でもない限りクラウドプロバイダーを変更することはまれ。

「Cloud Run も結局 Managed Kubernetes では？」

Cloud Run は Knative インターフェースを使うが、Kubernetes ではなく Google の Borg 上で動作する。
Kubernetes の複雑さを取り除き、簡素化されたインターフェースを提供する。

現在のワークフローの欠点

サービス名管理の不便さ:
- ローカルとサーバーで一貫した構成管理を行うための抽象化レイヤーが必要。
- Kubernetes の名前管理機能がない。
Cloud Run Task エミュレーション不足:
- ローカルでジョブを開発する際、ログ出力のキャプチャや追跡を含む簡単なエミュレーション環境がない。

結論

Cloud Run はコスト、速度、拡張性、簡素化の面で最適なソリューション。
大企業 や複雑な要件がある場合には Kubernetes が有用なこともあるが、
簡素さと効率性 が重要なプロジェクトでは Cloud Run のほうがはるかに実用的。
PS: Kubernetes に特定の拡張を追加して問題を解決することもできるかもしれないが、それは複雑さを増すだけであり、単純な必要性を超えた Kubernetes 環境に依存したくはない。

12件のコメント

blurblah 2024-12-01

万能薬なんてあるわけがありません。状況に合わせてうまく使えばいいのでしょうね（笑）
トレンドだからと無批判に kubernetes を導入すると大変になることもありますが、それでもある程度規模の大きい環境では悪くないツールだと思っています。
導入したとしても、導入して終わりではきちんと使いこなせないはずです。
そして、どんなツールでも同じですが、開発者や利用者のニーズを100%満たすことはできないので、適切なレベルの自動化は必須だと思います。

bungker 2024-11-29

Kubernetesは一度構築してしまえばあとは楽勝だと思っていたのに…（泣）

riki3 2024-11-29

Kubernetesは自分の飯の種で、かつてはこれこそが正解だと信じていた時期もありましたが、
時間が経つほど多くの問題を経験し、時間を無駄にしている自分に気づくようになりました。

人にはk8sを勧めますが、自分のサービスでは使わないと思います。k8sもそうですが、単にコンテナにも疲れました。

joon14 2024-11-28

AWS を使っているなら、ECS と似たようなものだと考えればいいでしょうか？

tujuc 2024-11-29

ええ、そんな感じです。 :)

eclipsense 2024-11-28

Kubernetesを使えないことが問題なのであって、Kubernetesがいまひとつだと言うのはちょっと違うと思います。

tujuc 2024-11-28

私も筆者の考えと似ています。
まだ会社の規模がkubeを使うほどではありませんし。

すべての開発者がKubeを使って運用管理できるはずだというのは、私だけの考えでした。
会社の開発者の平均的なレベルでもインフラを構築し、問題を解決できるようにガイドするほうが、より良かったです...

doolayer 2024-11-28

???: 私にはAIは必要なかったし、たぶん皆さんにも必要ないでしょう。

ilbanin00 2024-11-28

どんな製品にも、トレードオフになる部分はあるでしょう

bbulbum 2024-11-28

マネージドサービスを使えば、特に運用管理の難しさは感じませんでしたし、、
どんなツールでもほどほどの範囲で使えば有用ですが、Kubernetes はとりわけ「複雑な設定ができること」が主な批判対象になっている気がしますね。