Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Canva's ECS to EKS Migration Strategy and freee...

Avatar for Tomoaki Nakagawa Tomoaki Nakagawa
July 31, 2025
180

Canva's ECS to EKS Migration Strategy and freee EKS Migration Practices

Avatar for Tomoaki Nakagawa

Tomoaki Nakagawa

July 31, 2025
Tweet

Transcript

  1. KubeConの感想を肴に語らう会 
 Canva に学ぶ ECS → EKS 移行戦略と フリー の

    EKS 移行実践事例 
 ~Recap: From ECS To Kubernetes (and Sometimes Back Again)~

  2.   2 Tomoaki Nakagawa
 中川 智瑛
 経歴
 • 2020/05 ~

    フリー 入社以降、ずっと SRE
 ◦ EC2 → EKS 移⾏祭り ◦ SRE プラクティスの浸透 ◦ プロダクト構築の効率化 ◦ GoldenPath 整備 X
 • https://twitter.com/tmnkgwa4
 
 GitHub
 • https://github.com/naka-gawa
 Platform Engineer → Embedded SRE

  3. 3 取り上げるセッション ※以降、セッションスライドを引⽤しつつ説明します。 From ECS to Kubernetes (and Sometimes Back

    Again) Canva という⼤規模サービスを「ユーザ影響の最⼩化‧シームレスな移⾏プロセス」がテーマのセッション。 ECS vs EKS という単純な技術⽐較ではなく、「すでに動いている巨⼤なサービスを、どうやって安全に、現実的に移 ⾏していくか」という、実践的な戦略に焦点を当てた内容。 セッション動画リンク
  4. 6 Canva の挑戦「2 つの壁 4つの教訓」 FY26Q1 LESSON 1 FY26Q1 LESSON

    2 FY26Q1 LESSON 3 FY26Q1 LESSON 4 セッションスライド 11,14,16,17,18,21 ページより引⽤ VILLAIN 1 VILLAIN 2
  5. 7 LESSON 1~2: 「戦略」「⾃信」 セッションスライド 11,14 ページより引⽤ Capabilities Analysis •

    個々の対象サービスが EKS 移⾏に耐えうるものであるかではなく、 サービスが基盤に要求する能⼒に焦点を当てるという考え⽅ • 全サービスが必要とする基盤能⼒をカタログ化、より多くのサービ スを移⾏できる基盤能⼒を優先的に開発した Gain (Real) Confidence • 影響範囲の少ないサービスを移⾏パイロット対象として選定 • ⼀度移⾏できれば基盤能⼒が証明されるので、並列度を上げて移⾏ することが可能になるという戦略 • コンシェルジュのような⼿厚い whiteglobe migration を通じて、プ ロダクトチームのリソースを削ることなく⽀援した
  6. 8 VILLAIN 1: SCALLING セッションスライド 16 ページより引⽤ 命令的から宣⾔的なスケーリングへ思考転換 • 命令的なスケーリング

    ◦ 「CPUが80%を5分超えたら、2インスタンス追加する」 • 宣⾔的なスケーリング ◦ 「平均CPU使⽤率が50%になるように維持する」
  7. 9 VILLAIN 1: SCALLING セッションスライド 16 ページより引⽤ イベント駆動型のオートスケーラー導⼊ • Kubernetes

    Event-driven Autoscaling → KEDA • SQS、RabbitMQ、Kafka など、HPA が標準では対応していな い多様なイベントソースをトリガーに、Podを 0 から N まで スケールさせることができる
  8. 10 VILLAIN 2: EVICTIONS セッションスライド 17 ページより引⽤ Pod Disruption Budgets

    • PDB は Eviction などに対して、アプリケーション Pod が最低 何台、あるいは最⼤何台まで利⽤不能になってよいかを定義 する仕組み
  9. 11 VILLAIN 2: EVICTIONS セッションスライド 17 ページより引⽤ Topology Spread Constraints

    • Pod を複数の Node や Availability Zone に分散配置させるた めの制約 • descheduler とこれを組み合わせることで、特定の Node に Pod が集中配置されるのを防ぎ、ある Node が終了対象と なった場合の影響を限定的できる
  10. 12 VILLAIN 2: EVICTIONS セッションスライド 17 ページより引⽤ Custom Readiness Gates

    • Readiness Probe ◦ アプリケーション⾃体が、リクエストを受け付けられる状 態になったかをチェックする役割 • Readiness Gates ◦ Pod がトラフィックを受け取るために必要な、外部の条件 が整ったかをチェックする 役割
  11. 13 LESSON 3~4: 「安全策」「移⾏実⾏」 セッションスライド 18,21 ページより引⽤ When Ready Migrate

    Quickly • 集団単位で、洗練されたパイプラインで⼀気に移⾏ • DNS の加重ルーティングにより、段階的にリクエスト切り替え • ⾮同期処理は worker ⽐率を操作することで段階的に切り替え Have A Way Back • リクエストを切り替える直前まで ECS と EKS 両⽅に同じイメージ をデプロイする • ECS と EKS の細かい基盤差分は環境変数などで差分をなくす
  12. 16 AWS Cloud Public subnet GAP 1: トラフィック移⾏戦略 フリー 構成

    想像する Canva 構成 Private subnet AWS Cloud Public subnet Private subnet
  13. 17 AWS Cloud Private subnet GAP 2: ヘルスチェック標準化 フリー 構成

    Public subnet • アプリケーションのプロセスが⽣存しているかどうか確認す るための path ◦ Kubernetes の Liveness Probe によってのみ利⽤されるエ ンドポイント ◦ このエンドポイントが叩かれたときには、アプリケーショ ンが http リクエストをさばけるプロセスが起動している かどうかだけを確認する ◦ もちろん、プロダクト内でしか使われないのでプロダクト の外からは利⽤されない https://developers.フリー.co.jp/entry/Health-Check-Standardization-in-Diverse-フリー-Products より抜粋
  14. 18 AWS Cloud Private subnet GAP 2: ヘルスチェック標準化 フリー 構成

    Public subnet • アプリケーションがリクエストを捌ける状態であるかを確認 するための path ◦ Kubernetes の Readiness Probe、 Envoy cluster health check、ALB からの health check によって利⽤される path ◦ このエンドポイントが叩かれたときには、アプリケーショ ンが http リクエストかどうか重要な各コンポーネントへ のアクセスなどを確認する ◦ プロダクト内でしか使われないのでプロダクトの外からは 利⽤されない https://developers.フリー.co.jp/entry/Health-Check-Standardization-in-Diverse-フリー-Products より抜粋
  15. 19 AWS Cloud Private subnet GAP 2: ヘルスチェック標準化 フリー 構成

    Public subnet • プロダクトが利⽤可能であるか、プロダクトの外から確認す るための path ◦ ⾃分のプロダクト外から来るアクセスが叩きに来たり、外 形監視などで利⽤されたりする path ◦ これは、プロダクト A が、依存するプロダクト B に対す る health check を実施したい場合などで利⽤するような イメージ ◦ 基本的にプロダクト外からのアクセス⽬的のため、プロダ クト内部でのチェックには使われない https://developers.フリー.co.jp/entry/Health-Check-Standardization-in-Diverse-フリー-Products より抜粋
  16. 20 GAP 3: スケーリング戦略 想像する Canva 構成 GetQueueAttributes scaleout フリー

    構成 SQS ElastiCache dogstatsd datadog agent SQS scaleout external metrics cloud integration  scaledObject
  17. 22 EKS 移⾏に「銀の弾丸」はない 
 Canva
 フリー
 戦略
 プラットフォーム構築
 標準プラットフォーム移行 


    トラフィック移行戦略
 DNS 加重ルーティング 
 ApplicationLoadBalancer ルーティング 
 ヘルスチェックパス
 不明
 標準定義
 スケーリング
 イベント駆動オートスケーリング 
 Datadog & External HPA
 ⼤事なのは、⾃分たちのコンテキストを分析‧理解し、最適な戦略を選ぶこと
  18. 23 Key Takeaway Start Small
 Have a Way Back
 Proceed

    with Confide nce
 CanvaのLesson 2のように 影響の少ないサービスから試して 技術的な⾃信と経験を積む ① ⼩さく始める (Start Small) CanvaのLesson 2のように 影響の少ないサービスから試して 技術的な⾃信と経験を積む ② 戻れる道を⽤意する (Have a Way Back) この2つがあれば⾃信が⽣まれる。 そうすれば、移⾏はチームを成⻑さ せる「プロジェクト」になる ③ ⾃信を持って進める (Proceed with Confidence)