Kubernetesの「複雑さ」を制御する2つの作戦術

ツール導入前の課題

ココナラは、複数のサービスを有機的に連携させて新たな価値を生み出す「コンパウンド戦略」を推進しています。

この戦略を成功させるには、新しいサービスや機能をこれまで以上のスピードで市場投入し、事業成長に合わせて柔軟にスケールできる技術基盤が不可欠でした。

しかし、当時のAWS ECSを中心としたインフラでは、主に以下の3つの技術的制約が顕在化していました。

• スピードの低下
  • 中央集権的なインフラ管理が一部でボトルネックとなり、開発リードタイムが増大
• 信頼性実現の困難さ
  • カナリアリリースやサービスメッシュといった高度な信頼性パターンを、スケーラブルに実現することが困難
• 開発者体験の悪化
  • 限定的なデプロイ手法や非効率な開発環境が、開発者の生産性や心理的安全性を阻害

どのような状態を目指していたか

これらの課題を解決するため、「プラットフォーム型ゴールデンパス」の実現を目指しました。

これは、開発者がインフラの複雑さを意識することなく、安全かつ効率的にアプリケーションを本番環境へ届けられる、プラットフォームが推奨する「舗装された道」です。

この道を通れば、セキュリティも、可観測性も、安全なデプロイも、すべてが「当たり前」のように提供される世界です。

• Amazon Elastic Container Service（ECS）
• Google Kubernetes Engine（GKE）

コンテナオーケストレーションツールを選定するにあたり、特に以下の点を重要視しました。

• プラットフォームとしての拡張性
  • ゴールデンパスを実現するために、サービスメッシュやプログレッシブデリバリーといった高度な機能を導入できること
• エコシステムの成熟度
  • 業界標準として、サードパーティ製ツールが豊富に存在し、参考にできる知見や事例が多いこと
• 既存クラウド資産との親和性
  • 既存のAWS中心のインフラ環境とシームレスに連携し、既存の知識や資産を最大限に活用できること
• 運用負荷の低減
  • 運用負荷が高いレイヤーを可能な限りマネージドサービスに任せられること

最終的にAWS EKSを選定した決め手は、以下の3点です。

Kubernetesの表現力と広大なエコシステム

まず、「ゴールデンパス」という戦略を実現するためには、ECSよりも柔軟で拡張性の高いKubernetesが最適であると判断しました。

我々が目指すプラットフォームを実現するには、Istio、ArgoCD、Karpenterといった豊富なエコシステムの活用が必要不可欠でした。

AWSへの集約による運用効率

Kubernetes採用を前提とした上で、GKEではなくEKSを選定しました。

最大の理由は、既存のAWS環境との親和性です。

ALB、VPC、IAMといったサービスとネイティブに連携できるEKSは、我々のチームが持つAWSの知見をそのまま活かすことができ、マルチクラウド管理の複雑さを回避できる最も合理的な選択肢でした。

EKSの成熟

以前は、EKSはGKEと比べてマネージドで提供されている範囲が狭く、運用負荷が非常に高いサービスでした。

最近は少しずつマネージドに任せられる範囲が拡大しており、以前に比べて運用負荷を抑えられるようになっています。

改善したかった課題はどれくらい解決されたか

まだまだ道半ばですが、課題に挙げた内容のいくつかは解決することができました。

どのような成果が得られたか

セルフサービス化によるインフラ構築のリードタイム短縮や、プログレッシブデリバリーによる安全なデプロイなどが実現できました。

導入時に最も悩んだのは、特定の技術的な問題というよりも、Kubernetesが本質的に持つ「複雑さ」そのものでした。

例えば、「GitOpsが流行っているからArgoCDを導入する」といった局所的な戦術に飛びつくと、管理するマニフェストが爆発的に増え、かえって運用が複雑化してチームが疲弊してしまいます。 このような「戦術的な成功が、戦略的な敗北を招く」という罠に陥る危険性を感じていました。

この根源的な課題に向き合うため、私たちは技術選定の前に、戦略と戦術のギャップを埋める「作戦術」という意思決定フレームワークを採用しました。 これにより、全ての技術的な判断が常に大きな目的に沿っていることを保証し、複雑さを制御下に置くことを目指しました。

EKSやKubernetesは、導入すれば全ての問題が解決する「銀の弾丸」ではありません。

サービスや組織の規模、運用体制によっては、ただただ運用負荷が増すだけになります。

まず、「なぜKubernetesを導入するのか？」という問いに明確に答えてみてください。

その結果、今はKubernetesは不要となるかもしれません。

そのうえで、Kubernetesが必要であれば、その複雑さをどうやって制御下に置くのか検討してみてください。

その際には、以下の弊社の取り組み内容の記事が参考になるかもしれません。

https://zenn.dev/coconala/articles/kubernetes-operational-art

このプラットフォームはまだ完成形ではありません。

今後は、Backstageによる開発者ポータルの整備を進め、テンプレートによるセルフサービス化を推進していく予定です。

また、テスト戦略をさらに拡充し、カオスエンジニアリングのような「より高度な取り組み」にも挑戦することで、「開発者体験」と「持続可能性」をさらに高いレベルで両立させていきたいと考えています。