Kubernetesの「複雑さ」をいかに制御するか？ - 2つの作戦術で持続可能なプラットフォームを実現する
Kubernetesの「複雑さ」をいかに制御し、持続可能なプラットフォームを実現するか？
ココナラでは、サービスと組織の継続的な成長を支える基盤として、Kubernetes (Amazon EKS) の導入を進め、2025年2月に本番運用を開始しました。
その中で、日々この問いに向き合い続けてきました。
はじめに
こんにちは。
株式会社ココナラ在籍のKです。
本記事では、ココナラがKubernetesを導入した背景と、持続可能なプラットフォームを実現するために実践している2つの作戦術をご紹介します。
TL;DR
- 事業上の必要性と「スピード」「信頼性」「開発者体験」などの技術課題の解決の両面から、Kubernetesの導入を決断した
- 開発者が価値提供に集中できるプラットフォーム型ゴールデンパスを実現する
- Kubernetesの複雑さを制御するため、互いにバランスを取り合う「開発者体験の最大化」と「プラットフォーム自体の持続可能性」の2つの作戦術を実践している
対象読者
- Kubernetes（特にEKS）を用いたプラットフォーム構築に興味がある方
- Kubernetesの運用負荷の高さに悩まれている方
- 開発者体験（Developer Experience）や運用負荷の改善に課題を持つ方
- ココナラの技術スタックや開発文化に興味がある方
戦略：なぜKubernetesを使うのか
なぜ私たちは、数ある選択肢の中からKubernetesの導入を決断したのか。
私たちの決定の背景には、事業上の必要性と、避けては通れない技術的課題の両面がありました。
事業上の必要性
ココナラは、複数のサービスを有機的に連携させて新たな価値を生み出す「コンパウンド戦略」を推進しています。
この事業戦略を成功させるには、新しいサービスや機能をこれまで以上のスピードで市場に投入し、事業の成長に合わせて柔軟にスケールできる技術基盤が不可欠でした。
しかしながら、私たちの既存インフラは、この要求に応えきれなくなりつつありました。
技術的な制約
こうした事業上の必要性がある一方で、従来のAWS ECS中心のインフラでは、主に以下の3つの技術的制約が顕在化していました。
- スピード：中央集権的なインフラ管理が一部でボトルネックとなり、開発リードタイムが増大
- 信頼性：カナリーリリースやサービスメッシュといった高度な信頼性パターンを、スケーラブルに実現することが困難
- 開発者体験：限定的なデプロイ手法や非効率な開発環境が、開発者の効率性、心理的安全性を阻害
これらの制約は、技術的な問題にとどまりません。
本質的には、「開発者の習得すべき知識の多さ」や「デプロイ作業に対する恐怖」といった人間の認知負荷や心理的障壁の問題でもあると考えています。
そこで私たちが目指したのが、プラットフォーム型ゴールデンパスです。
プラットフォーム型ゴールデンパスとは？
ものすごく簡単に言うと、開発者がインフラの複雑さを意識することなく、安全かつ効率的にアプリケーションを本番環境に届けられる、プラットフォームが推奨する「舗装された道」のことです。
開発者が自然に歩みたくなる、舗装された快適な道。
その道を通れば、セキュリティも、可観測性も、安全なデプロイも、すべてが「当たり前」のように提供される世界です。
さらに詳しく知りたい方には、以下の記事が参考になると思います。
壁：立ちはだかるKubernetesの複雑さ
前のセクションで述べた通り、私たちの戦略は「プラットフォーム型ゴールデンパス」の実現です。
しかしながら、その実現手段であるKubernetesは強力な反面、非常に複雑であり、無計画に導入すれば運用負荷の増大という深刻な問題を引き起こしかねません。
そこで私たちは、この複雑さを制御下に置き、戦略を持続可能な形で達成するため、中心的な考え方として戦略と戦術の間に2つの作戦術を定義しました。
作戦術（Operational Art）とは何か
私たちが、戦略と戦術の間にあえて「作戦術」という階層を設けている理由。
それは、Kubernetes運用に潜む「戦術的な成功が、戦略的な敗北を招く」という深刻な罠を回避するためです。
少し歴史を紐解いてみます。
ベトナム戦争において、米軍は個々の局所的な戦闘（戦術）では勝利を重ねました。
しかしながら、戦争全体（戦略）としては、最終的に勝利したとは言えませんでした。
戦術レベルの成功の積み重ねが、必ずしも戦略目標の達成に結びつかなかったのです。
この教訓から、米軍は戦略と戦術のギャップを埋める思考法として作戦術を公式のドクトリン（教義）に組み込みました。
この歴史からの教訓は、Kubernetesの運用にも当てはまるのではないかと考えています。
例えば、「GitOpsを導入する」という戦術に個別最適で飛びついた結果、管理するマニフェストが爆発的に増え、かえって運用が複雑化してチームが疲弊する、というケースがありがちです。
このようなトラップを避けるために、私たちは戦略と戦術をつなぐ作戦術を定義し、その思想をDesign Docとして落とし込みました。
持続可能性のReconciliation Loop
私たちの作戦術は、互いに補完し合い、健全な緊張関係を保つ2つの基本方針から成り立っています。
-
作戦術1：開発者体験の最大化
- 開発者が快適に歩める「舗装された道」を整備し、拡張し続ける（進化させる力）
-
作戦術2：プラットフォーム自体の持続可能性
- 無秩序な変更や複雑化に歯止めをかけ、長期的な運用を可能にする（安定させる力）
この2つの力はトレードオフです。
進化に偏ればプラットフォームは複雑化して崩壊し、逆に安定ばかりを求めれば改善は停滞します。
進化と安定の健全な緊張関係を保ち、常にバランスを調整し続ける。
この姿勢は、KubernetesのReconciliation Loop（制御ループ）の思想と少し似ているかもしれません。
戦略、作戦術、戦術の3階層フレームワーク
この作戦術の考え方に基づき、私たちのプラットフォームに関する全ての意思決定は、以下の3つの階層で整理されます。
これにより、日々の小さな技術選定や判断が、常に大きな目的に沿っていることを保証します。
-
戦略 (Strategy)
- プラットフォーム型ゴールデンパスの実現
-
作戦術 (Operational Art)
- 開発者体験の最大化
- プラットフォーム自体の持続可能性
-
戦術 (Tactics)
- ArgoCDによるGitOps、Karpenterによるノード管理など
（各ツールの選定は、必ず作戦術に照らして判断）
- ArgoCDによるGitOps、Karpenterによるノード管理など
このフレームワークは、技術選定の「なぜ」に明確な根拠を与えてくれます。
例えば、「なぜArgoCDを使うのか？」という問いに対する答えが次のように変わります。
「トレンドだから」ではなく、「『開発者体験の最大化』（作戦術1）と『プラットフォームの持続可能性』（作戦術2）という我々の作戦に合致するからです」と、自信を持って説明できるようになります。
作戦術と戦術
それでは、この2つの作戦術が、私たちの現場でどのように具体的な戦術として形になっているのか、詳しく見ていきましょう。
作戦術1：開発者体験の最大化
作戦術の1つ目は、開発者体験の最大化です。
ここでは、実践している戦術の中からいくつか抜粋してご紹介します。
| # | フェーズ | 戦術 |
|---|---|---|
| 1 | 開発：Inner Loop | 📜 認知負荷を考慮したインターフェース設計 📜 動的なPRプレビュー環境 |
| 2 | リリース：Outer Loop | 📜 GitOpsによる宣言的なワークフロー 📜 プログレッシブデリバリーによる心理的安全性 📜 宣言的なワークフロー実行基盤 📜 Gateway APIによる責務の分離 |
| 3 | 運用：Day2 Operation | 📜 サービスメッシュによる信頼性の標準化 📜 ベースラインオブザーバビリティの自動提供 |
| 4 | 文化：ゴールデンパスの実現 | 📜 1. ペアプロによる実践知の共有 📜 2. ドキュメントやBackstageによる形式知化 📜 3. テンプレートによるセルフサービス化 |
開発：Inner Loop
-
認知負荷を考慮したインターフェース設計
-
内容：開発者には
kubectlを原則開放せず、ArgoファミリーのGUIやAWSマネジメントコンソールなどの使い慣れたインターフェースを提供する - 効果：Kubernetesの難解な作法を学ぶ学習コストを削減し、開発者が本来の価値創造に集中できるよう促す
-
内容：開発者には
-
動的なPRプレビュー環境
- 内容：ArgoCD ApplicationSetを活用し、Pull Requestごとに動作確認が可能なプレビュー環境を自動でデプロイする
- 効果：手戻りを削減してフィードバックループを高速化し、開発者が自信を持って変更をマージできるようにする
リリース：Outer Loop
-
GitOpsによる宣言的なワークフロー
- 内容：ArgoCD、Argo Image Updater、Argo Workflowsを使用し、Gitリポジトリを唯一の信頼できる情報源とする
- 効果：Pull Requestのマージだけで安全にAPIやバッチをリリースできるようにする
-
プログレッシブデリバリーによる心理的安全性
- 内容：Argo Rolloutsによるカナリーリリースを標準のデプロイ戦略として組み込み、ユーザー影響を最小限に抑える
- 効果：リリースへの恐怖心を取り除き、品質と心理的安全性を確保することで、高速な開発サイクルを後押しする
-
Gateway APIによる責務の分離
-
内容：次世代標準であるGateway APIを採用し、インフラ（
Gateway）とアプリ（HTTPRoute）の責務を明確に分離する - 効果：開発者自身が安全にルーティングを定義できる柔軟性を実現する
-
内容：次世代標準であるGateway APIを採用し、インフラ（
運用：Day2 Operation
-
サービスメッシュによる信頼性の標準化
- 内容：Istio (Ambient mode) を導入し、JWT認証やリトライ、タイムアウトといった横断的な機能をプラットフォーム層で提供する
- 効果：アプリケーションコードから非機能要件を分離し、開発者がビジネスロジックの実装に専念できる環境を整える
-
ベースラインオブザーバビリティの自動提供
- 内容：全てのアプリケーションに対し、ログ、トレース、メトリクスの収集と可視化をプラットフォーム側で自動的に行う（ただし、トレースを伝播させるにはアプリケーション側の実装が必要）
- 効果：監視設定の手間から開発者を解放し、デプロイするだけで平均修復時間（MTTR）の短縮に繋がる可観測性を確保する
文化：ゴールデンパスの実現
いきなり理想の形を追求するのは現実的ではありません。
そこで私たちは、以下の3つのフェーズに分けて、段階的にアプローチしています。
-
1. ペアプロによる実践知の共有
- 内容：ペアプロを通して、KubernetesのYAMLの役割やトラブルシューティングといった生きた実践知を共有する
- 効果：Kubernetesのキャッチアップコストを最小化する
-
2. ドキュメントによる形式知化
- 内容：共有された実践知をドキュメントに落とし込み、誰もが参照できる形式知へと変換する
- 効果：知識の属人化を防ぎ、組織が拡大してもノウハウが失われない、スケーラブルな知識基盤を構築する
-
3. テンプレートによるセルフサービス化
- 内容：形式知化されたベストプラクティスをBackstageのSoftware Templatesに組み込み、定型作業を自動化する
- 効果：開発者が数クリックで「最適なやり方」が適用されたコンポーネントを作成でき、探すコストすらかからないセルフサービスを実現する
作戦術2：プラットフォーム自体の持続可能性
作戦術の2つ目は、プラットフォーム自体の運用負荷を下げ、長期的に維持可能にすることです。
実践している戦術をいくつか抜粋してご紹介します。
| # | 持続可能項目 | 戦術 |
|---|---|---|
| 1 | アップグレード・変更の負担軽減 | 📜 ライフサイクルの分離 📜 Blue/Green方式による安全なアップグレード 📜 マネージドサービスの活用と責務分離 📜 徹底した自動テスト |
| 2 | 手作業による運用・保守コストの削減 | 📜 Karpenterによるプロアクティブなノード管理 📜 監視・アラートの自動設定 📜 CIによるレビュープロセスの効率化 |
| 3 | 開発・設計における認知負荷の解消 | 📜 文脈に応じたIaCツールの選択 📜 設計・意思決定プロセスの記録と共有 📜 モブプロによる知識の伝承 |
アップグレード・変更の負担軽減
-
ライフサイクルの分離
- 内容：永続データなどライフサイクルの長いリソースをクラスター外部で管理し、クラスター自体を「ステートレスな計算リソース」として設計する
- 効果：データ損失リスクを排除し、プラットフォームの安全なアップグレードや再構築を実現する
-
Blue/Green方式による安全なアップグレード
- 内容：ALBの加重ターゲットグループを活用して新旧クラスターへ段階的にトラフィックを移行する
- 効果：アップグレードに伴うリスクや切り戻しの困難さをなくし、サービス無停止での安全な更新と柔軟な段階的移行を実現する
-
マネージドサービスの活用と責務分離
- 内容：Amazon Managed Service for Prometheus (AMP) 等のマネージドサービスを積極的に活用し、ALB本体など共有リソースはクラスター外部で管理する
- 効果：「作らないもの」を決めて自前運用コストを削減、クラスター内で管理するものを最小限にして安定性と管理性を向上させる
-
徹底した自動テスト
- 内容：クラスター全体の振る舞いを保証するE2Eテストを整備する
- 効果：バージョンアップや変更時の手動テストの負担と障害リスクを軽減し、変更に対する心理的安全性を担保する
手作業による運用・保守コストの削減
-
Karpenterによるプロアクティブなノード管理
- 内容：高速かつ多機能なKarpenterを採用する
- 効果：ワークロードに応じた最適なインスタンスを自律的に選択・起動、スポットインスタンス活用によるコスト最適化と手動調整から解放する
-
監視・アラートの自動設定
- 内容：新規アプリケーションのデプロイ時に、基本的な監視設定やアラートルールを自動で適用する
- 効果：監視設定漏れによる「サイレント障害」を防ぎ、手作業の負担をなくしてスケーラブルな監視体制を実現する
-
CIによるレビュープロセスの効率化
-
内容：
cdk diffの結果と、ArgoCDがKustomizeやApplicationSetを通して生成する最終的なYAMLの差分をArgo CD Diff Previewにより、PRコメントとして自動挿入する - 効果：コードから生成結果を想像するのではなく、差分として見える状態にすることで、レビュー担当者の認知負荷を軽減し、意図しない変更のリスクを大幅に低減する
-
内容：
開発・設計における認知負荷の解消
-
文脈に応じたIaCツールの選択
- 内容：ココナラではTerraformをメインに使用しているが、EKSについてはEKS Blueprints for CDK（TypeScript）で管理する
- 効果：HCLによる表現の複雑化や可読性の低下を回避し、CDKの型システムや条件分岐、ループなどを使うことで、複雑なKubernetesの構成を柔軟かつ宣言的に管理する
-
設計・意思決定プロセスの記録と共有
- 内容：Design DocやADRによって意思決定の背景を記録し、知識を共有する
- 効果：将来のメンバーが文脈を正確に理解して一貫性のある判断を下せるようにする
-
モブプロによる知識の伝承
- 内容：Kubernetesは覚えることが膨大にあるため、モブプロを通して各自の知識や経験を効率的に伝承する
- 効果：属人化を徹底的に排除し、プラットフォームチーム自体の持続可能性を向上させる
主要技術スタック
上記の戦術群を支える技術スタックがこちらです。
これらはすべて、「開発者体験の最大化」と「持続可能性」のバランスを取るという思想の下に選択、構成されています。
| カテゴリ | 使用しているもの |
|---|---|
| Container Orchestration |  |
| Development |  |
| GitOps Progressive Delivery Workflow |
 |
| Service Mesh |  |
| Node Auto Scaling |  |
| Traffic Routing |  |
| Observability |  |
| Secret Management |  |
| Cost Management |  |
| Performance Testing |  |
| Developer Portal |  |
たどり着いた現在地
これまでの取り組みを通じ、私たちのプラットフォームは事業の安定性に貢献できることを証明しつつあります。
2025年2月に本番運用を開始して以来、新しいサービスの環境構築にかかるリードタイムが大きく短縮され、現在までプラットフォームに起因する障害ゼロを継続しています。
また、最大の懸念であったKubernetesのバージョンアップにも追従できています。
もちろん、計画通りに行ったことばかりではない（それだとやっていて面白くもない）ですが、それはまたの機会にご紹介できればと思います。
今後の展望
このプラットフォームは完成形ではなく、継続的に進化しています。
現在は、Backstageによる開発者ポータルの整備、テストの拡充、既存サービス群の移行などを進めています。
今後、より大きな挑戦、例えばカオスエンジニアリングの導入による開発者体験と持続可能性のさらなる向上などに取り組んでいければと考えています。
まとめ
Kubernetesの「複雑さ」をいかに制御し、持続可能なプラットフォームを実現するか？
私たちの答えは、2つの作戦術による動的な均衡でした。
開発者体験を追求する力と、持続可能性を保つ力。
この2つが、Reconciliation Loopのように継続的に調整し合いながら、システム全体をあるべき状態へと導き続けています。
この記事を読んで、ココナラの技術や文化に少しでも興味を持っていただけたら幸いです。
ココナラでは積極的にエンジニアを採用しています。
私たちと一緒に、複雑さと向き合い、それを制御する喜びを味わってみませんか？
採用情報はこちら。
カジュアル面談希望の方はこちら。
まずはココナラの魅力やキャリアパスについて、お気軽にお話ししませんか？
Discussion