「Kubernetesを導入すればDevOpsが加速する」。その幻想を信じて導入し、開発速度が半分以下に落ちた企業がある。SREチームリーダーとして導入を主導した筆者の、偽りなき反省記。
「みんな使ってるから」で始まった導入
エンジニア30人規模のBtoB SaaS。月間リクエスト数は100万程度。Docker Composeで十分に運用できていたインフラを、「スケーラビリティのため」にKubernetesへ移行する判断をした。本当の理由は「Kubernetesを運用した経験」が採用で有利になると思ったからだ。技術選定の動機として最悪だった。
学習コストの見積もりが甘すぎた
Pod、Service、Ingress、ConfigMap、Secret、PV、PVC、StatefulSet、DaemonSet、CronJob、HPA、NetworkPolicy、RBAC——これらの概念を理解し、YAML地獄をくぐり抜けるまでに、チーム全体で約4ヶ月を費やした。その間、新機能開発はほぼ停止。「学習期間は1ヶ月」という当初の見積もりは、楽観的すぎた。
障害対応の複雑化
以前は「サーバーにSSHしてログを見る」で解決していた障害が、kubectl、Prometheus、Grafana、Jaegerを駆使した調査が必要になった。平均障害復旧時間（MTTR）は導入前の15分から45分に悪化。「抽象化レイヤーが増えるほど、問題の特定が難しくなる」という基本原則を忘れていた。
本当にK8sが必要な規模感
筆者の経験則では、Kubernetesが投資に見合うのはエンジニア100人以上、マイクロサービス20以上、月間リクエスト1億以上の規模から。それ以下なら、ECS/Fargate、Cloud Run、あるいはDocker Compose + CI/CDで十分。「シンプルに保つ」ことの価値を過小評価してはいけない。
# comment