11月28日、Ben Houston氏が「I Didn't Need Kubernetes, and You Probably Don't Either」と題したブログ記事を公開し、海外で話題を呼んでいる。この記事では、Kubernetesを実際に使用しての痛み、そしてGoogle Cloud Runへの移行について詳しく紹介されている。
以下に、その内容を紹介する。
Kubernetes導入の背景と課題
記事の冒頭では、Houston氏がKubernetesを導入した背景とその後直面した課題が述べられている。2013年にオンライン3Dエディタ「Clara.io」を立ち上げた際、同氏はコスト削減のためOVHのベアメタルサーバを利用していた。しかし、ベアメタル環境の管理負担やハードウェア障害のリスクが高かったため、2018年に企業向けの新プラットフォーム「Threekit.com」へ再構築する際、Kubernetesを採用したという。
Kubernetesを採用した理由
- 業界標準としての成熟度: 2018年時点でAzure、AWS、DockerがKubernetesを採用しており、選択肢として自然であった。
- ハードウェア管理の解放: ベアメタル環境の管理負担からの解放を目的としていた。
しかし、数年間の運用で次の課題が浮上した。
Kubernetesの主な課題
- コストの増大:
- クラスターの基本的な運用コストが高い。
- オートスケーリングの遅さにより、リソースの過剰プロビジョニングが必要だった。
- 管理の複雑さ:
- 大量のジョブを処理する際、スケジューラーやArgoによる制約が煩雑であった。
- シンプルなタスクでも多くのプロセスが必要だった。
- 専門性の高さ:
- Kubernetesの運用には専任のDevOpsエンジニアが必要で、技術的負担が増えた。
Google Cloud Runへの移行と利点
Houston氏はKubernetesの複雑さとコストを解消するため、Google Cloud Runに移行した。この選択により、運用の効率化とコスト削減を実現したと述べている。
Cloud Runのセットアップ
Cloud Runでは、Dockerコンテナを使用した以下の仕組みが導入されている。
- 自動スケーリングサービス
- 長時間実行のジョブをタスクとして管理
Cloud Runの利点
- コスト効率:
- 実際に使用したCPUとメモリに応じて課金される。
- サービスがアイドル状態の際にはコストが発生しない。
- 例: 月50万アクセスの個人プロジェクトがわずか**$4/月**で運用可能。
- 高速なオートスケーリング:
- 数秒でスケールアップ可能。
- Kubernetesの数分を要するスケーリングと比較して優位性がある。
- Kubernetes管理の不要性:
- Googleの「Borg」基盤上で稼働し、複雑なクラスター管理を回避。
- 簡潔な非同期タスク管理:
- タスクの実行、結果追跡、自動リトライが可能で、個別のジョブ管理が不要。
Kubernetes特有の課題からの解放
記事では、Kubernetesのクラスター特有のロックイン問題についても言及されている。Kubernetes特有の機能に依存すると、システムの拡張や移行が難しくなるという課題があった。
具体的なワークフローと開発環境
Houston氏のCloud Runに基づくワークフローでは、以下の技術が利用されている。
- CI/CD: GitHub Actionsを利用し、ビルドとテストが成功した場合のみデプロイを実行。
- ストレージ: 管理されたデータベースやCloud Storageを利用。
- サービス間通信: Pub/Subメッセージングとドメインネームでの接続。
- セキュリティ: JWTを活用したルートの保護。
残る課題と将来的な改善
Cloud Runを利用する中でも、Houston氏は以下の課題に直面している。
- サービス名管理の手間:
- ローカルとサーバー間で統一的なサービス名管理が必要。
- Cloud Run Tasksのローカルエミュレーションの欠如:
- ローカル環境でタスクを再現する仕組みがなく、デプロイ作業の簡略化が求められる。
結論
Cloud Runは、Kubernetesと比較してコスト、速度、スケーラビリティ、簡便さにおいて優れていると評価されている。特に、効率性と管理負担の軽減を重視するプロジェクトには最適なソリューションであると述べられている。
詳細はI Didn't Need Kubernetes, and You Probably Don't Eitherを参照していただきたい。
