2025年6月に開催されたプラットフォームエンジニアリングに関する国際カンファレンス「PlatformCon 2025」のセッション「8 years of Kubernetes platform evolution: Do’s and don’ts」では、ロサ氏が同社の内部システム進化の軌跡と実践的なノウハウを共有した。

　クラスタのアップグレード手法は、運用チームにとって積年の課題だ。Aurelia Netherlands Targetは当初、新しいバージョンのクラスタを別途構築し、徐々にトラフィックを移行させる「ブルーグリーンデプロイメント」（新旧のシステム構成を並行稼働させて安全に切り替える手法）を採用していた。この手法はロールバックが容易である半面、エンドユーザーとの日程調整にかかる手間が大きく、インフラ担当チームの運用負荷を増大させる要因となっていた。

　そこでAurelia Netherlands Targetは、Kubernetesのマネージドサービス「Amazon Elastic Kubernetes Service」（Amazon EKS）への移行を契機に、稼働中のクラスタを直接更新する「インプレースアップグレード」へと方針を転換した。後戻りできないというリスクを軽減するため、同社はAPIの破壊的変更（後方互換性がなくなる変更）の影響を受けるオブジェクトを事前に検出するダッシュボードを独自に開発した。これによってエンドユーザーへの影響を最小限に抑えつつ、インフラ担当チームの運用負荷を大幅に削減することに成功している。

教訓2．適切な抽象化レベルを設定する

　開発者の認知的負荷を下げるためには、開発システムの抽象化が不可欠だ。しかし、そのレベル設定には細心の注意が必要だ。ロサ氏は2つの両極端な事例を挙げて警告する。

　1つ目は、抽象度が高過ぎるケースだ。Aurelia Netherlands Targetは、デプロイを簡易化するオープンソースのKubernetesオペレーター「FiaaS」を推奨インタフェースとして導入した。しかし、ネットワークプロキシなどの目的でサイドカー（メインコンテナの機能を補助する副コンテナ）を追加したいというユーザー要件に対し、FiaaSの仕様にその項目が存在しなかったため、機能の追加や処理が困難になった。エスケープハッチ（例外処理の仕組み）がない高過ぎる抽象化は、エンドユーザーの多様なニーズへの適応を困難にする。

　2つ目は、抽象度が低過ぎるケースだ。Aurelia Netherlands Targetは外部トラフィックの制御機構「Ingress」のコントローラーとして、Webサーバソフトウェア「nginx」を採用し、エンドユーザーが独自の設定を追加できる特別なアノテーション（追加のメタデータ設定）の使用を許可した。その結果、2025年6月時点では34％のIngressオブジェクトがnginx固有のアノテーションに依存しており、他のコントローラーへの移行が極めて困難な状態に陥っている。「後でいつでも変更できる」という安易な妥協は、技術的負債になり得る。

教訓3．KPIの定期的な運用レビューを実施する

　開発システムの健全性を維持するためには、適切な指標の設定と定期的なレビューが欠かせない。Aurelia Netherlands Targetは、KubernetesのAPI、Ingress、DNS（ドメインネームシステム）などのSLO（サービスレベル目標）に加え、オンコール（緊急呼び出し）のアラート発生件数、問い合わせリクエストの量、クラウド費用、クラスタ効率などをKPI（重要業績評価指標）として設定している。

　特筆すべきは、オンコールのアラートに対するアプローチだ。アラートが急増した際には、その根本原因を分析し、ページング（呼び出し通知）を減らすためのアクションを講じている。定期的なレビューを通じて改善サイクルを回すことで、オンコール運用の健全化とシステムの安定稼働を実現している。

今後の展望

　大規模なKubernetesシステムを持続的に運用するためには、技術力の向上だけでなく、組織間の調整やインタフェースの設計といった戦略的な視点が求められる。ロサ氏が共有した知見は、変化の激しいビジネス情勢において、臨機応変なシステムの構築に取り組む企業にとって、長期的な持続可能性をもたらす道しるべになる。

本稿は、Platform Engineeringが2025年6月26日に公開した動画「8 years of Kubernetes platform evolution: Do’s and don’ts - Fabian Selles Rosa | PlatformCon 2025」を基に作成しました。