■ 発表カテゴリ
募集要項(https://srekaigi.notion.site/SRE-Kaigi-2026-CfP-25a6f7392c108187a9e6e47c346396b2) にある6つの発表カテゴリからお選びください
・Tech: SREを支える具体的な技術や手法
・Practices: SREの実践例と得られた教訓
・Architecture: SREの視点からのシステム設計
■ 発表概要(400字程度)
TROCCO は1日25万個の Kubernetes Job を処理するクラウド ETL サービスです。
ある EKS upgrade 後、k8s Job の起動時間が通常1秒以下から平均2分以上に増加する EKS コントロールプレーンの API 遅延トラブルが発生しました。
このトラブルのポストモーテムをきっかけに「EKS カナリア upgrade」というアーキテクチャを実装しました。
新旧2つの EKS クラスタを並行運用し、k8s Job の起動先を1%→10%→100%と段階制御し、影響範囲を限定しながら upgrade 可能な仕組みです。
結果として、安全な upgrade の実現に加え、従来の計画メンテナンスが不要となり、ゼロダウンタイム upgrade を実現でき、システムの可用性と運用効率が大きく向上しました。
本セッションでは TROCCO の EKS カナリア upgrade アーキテクチャをご紹介します。
■ 発表の詳細(1000字程度)
○EKS upgrade によるトラブル
・クラウド ETL サービス TROCCO は、1日25万個の Kubernetes Job を処理するシステムで、多種多様な ETL パイプラインが100台近くの EKS ノード で動いています。
・EKS upgrade は十分な実績を積んでいましたが、1.24 -> 1.28 の upgrade を実行後、予期しない大規模遅延が発生し、通常1秒以下の k8s Job 起動時間が平均2分以上遅延し、ユーザー体験が著しく悪化しました。
・調査の結果 AWS の EKS コントロールプレーン側の API 遅延が原因でした。暫定対応で k8s Job 起動時間を正常化できましたが、この経験から従来の EKS upgrade 手法では限界があることを痛感しました。
○ポストモーテムが生んだアイデア
・primeNumber では小さなトラブルでも必ずポストモーテムを実施します。再発防止策の議論で、根本的解決となりうるアイデアが生まれました。それがカナリアリリースの概念を EKS upgrade および k8s Job 起動に応用した「EKS カナリア upgrade」です。
○EKS カナリア upgrade の仕組み
・EKS カナリア upgrade では、新旧2つの EKS クラスタを並行運用し、k8s Job 起動の要求を受け付ける SQS キューへの振り分け比率を制御することで、起動先を段階的に移行します。メンテナンス不要のまま、k8s Job の起動先を新しいクラスタ側 1%, 10%, 50%, 100%と段階的に実行可能にできる仕組みです。
○EKS カナリア upgrade で達成したこと
本セッションでは、この EKS カナリア upgrade のアーキテクチャ、管理画面、CI/CD、マニフェスト管理等を解説します。
■ 対象聴衆とその人たちが得られるもの
○こんな方にオススメ
・Kubernetes 運用に携わる人
・いろんなアーキテクチャの事例を引き出しに持っておきたい人
・カナリアリリースという単語を聞いたら振り向かずにはいられない人
○セッションで得られる具体的な価値
・実際に起きた EKS インシデントの共有および解決策の知見
・複数 EKS クラスタ間で k8s Job の起動先を制御するアーキテクチャの引き出し
・クラスタ共存時の危険な落とし穴の事例
■ なぜこのトピックについて話したいのか(モチベーション)
Kubernetes upgrade は SRE にとって大きな負担です。
TROCCO も Kubernetes upgrade のスケジュールに追われることが多く、大きな課題感がありました。
その中で実際に upgrade で発生したトラブル事例や、それを改善するアーキテクチャの共有は、みなさまの知見の1つになるはずです。
より安全で効率的な Kubernetes 運用を実現するためのヒントを提供できるかと思い、今回応募いたしました。