Slide 1

Slide 1 text

KubeConの感想を肴に語らう会 
 Canva に学ぶ ECS → EKS 移行戦略と フリー の EKS 移行実践事例 
 ~Recap: From ECS To Kubernetes (and Sometimes Back Again)~


Slide 2

Slide 2 text

  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


Slide 3

Slide 3 text

3 取り上げるセッション ※以降、セッションスライドを引⽤しつつ説明します。 From ECS to Kubernetes (and Sometimes Back Again) Canva という⼤規模サービスを「ユーザ影響の最⼩化‧シームレスな移⾏プロセス」がテーマのセッション。 ECS vs EKS という単純な技術⽐較ではなく、「すでに動いている巨⼤なサービスを、どうやって安全に、現実的に移 ⾏していくか」という、実践的な戦略に焦点を当てた内容。 セッション動画リンク

Slide 4

Slide 4 text

01 Session Recap
 02 フリー の移行戦略との技術的なギャップ 
 03 まとめ
 CONTENTS


Slide 5

Slide 5 text

01 Session Recap
 02 フリー の移行戦略との技術的なギャップ 
 03 まとめ
 CONTENTS


Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

7 LESSON 1~2: 「戦略」「⾃信」 セッションスライド 11,14 ページより引⽤ Capabilities Analysis ● 個々の対象サービスが EKS 移⾏に耐えうるものであるかではなく、 サービスが基盤に要求する能⼒に焦点を当てるという考え⽅ ● 全サービスが必要とする基盤能⼒をカタログ化、より多くのサービ スを移⾏できる基盤能⼒を優先的に開発した Gain (Real) Confidence ● 影響範囲の少ないサービスを移⾏パイロット対象として選定 ● ⼀度移⾏できれば基盤能⼒が証明されるので、並列度を上げて移⾏ することが可能になるという戦略 ● コンシェルジュのような⼿厚い whiteglobe migration を通じて、プ ロダクトチームのリソースを削ることなく⽀援した

Slide 8

Slide 8 text

8 VILLAIN 1: SCALLING セッションスライド 16 ページより引⽤ 命令的から宣⾔的なスケーリングへ思考転換 ● 命令的なスケーリング ○ 「CPUが80%を5分超えたら、2インスタンス追加する」 ● 宣⾔的なスケーリング ○ 「平均CPU使⽤率が50%になるように維持する」

Slide 9

Slide 9 text

9 VILLAIN 1: SCALLING セッションスライド 16 ページより引⽤ イベント駆動型のオートスケーラー導⼊ ● Kubernetes Event-driven Autoscaling → KEDA ● SQS、RabbitMQ、Kafka など、HPA が標準では対応していな い多様なイベントソースをトリガーに、Podを 0 から N まで スケールさせることができる

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

12 VILLAIN 2: EVICTIONS セッションスライド 17 ページより引⽤ Custom Readiness Gates ● Readiness Probe ○ アプリケーション⾃体が、リクエストを受け付けられる状 態になったかをチェックする役割 ● Readiness Gates ○ Pod がトラフィックを受け取るために必要な、外部の条件 が整ったかをチェックする 役割

Slide 13

Slide 13 text

13 LESSON 3~4: 「安全策」「移⾏実⾏」 セッションスライド 18,21 ページより引⽤ When Ready Migrate Quickly ● 集団単位で、洗練されたパイプラインで⼀気に移⾏ ● DNS の加重ルーティングにより、段階的にリクエスト切り替え ● ⾮同期処理は worker ⽐率を操作することで段階的に切り替え Have A Way Back ● リクエストを切り替える直前まで ECS と EKS 両⽅に同じイメージ をデプロイする ● ECS と EKS の細かい基盤差分は環境変数などで差分をなくす

Slide 14

Slide 14 text

01 Session Recap
 02 フリー の移行戦略との技術的なギャップ 
 03 まとめ
 CONTENTS


Slide 15

Slide 15 text

15 では、フリー の EKS 移⾏実践事例とのギャップは?

Slide 16

Slide 16 text

16 AWS Cloud Public subnet GAP 1: トラフィック移⾏戦略 フリー 構成 想像する Canva 構成 Private subnet AWS Cloud Public subnet Private subnet

Slide 17

Slide 17 text

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 より抜粋

Slide 18

Slide 18 text

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 より抜粋

Slide 19

Slide 19 text

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 より抜粋

Slide 20

Slide 20 text

20 GAP 3: スケーリング戦略 想像する Canva 構成 GetQueueAttributes scaleout フリー 構成 SQS ElastiCache dogstatsd datadog agent SQS scaleout external metrics cloud integration  scaledObject

Slide 21

Slide 21 text

01 Session Recap
 02 フリー の移行戦略との技術的なギャップ 
 03 まとめ
 CONTENTS


Slide 22

Slide 22 text

22 EKS 移⾏に「銀の弾丸」はない 
 Canva
 フリー
 戦略
 プラットフォーム構築
 標準プラットフォーム移行 
 トラフィック移行戦略
 DNS 加重ルーティング 
 ApplicationLoadBalancer ルーティング 
 ヘルスチェックパス
 不明
 標準定義
 スケーリング
 イベント駆動オートスケーリング 
 Datadog & External HPA
 ⼤事なのは、⾃分たちのコンテキストを分析‧理解し、最適な戦略を選ぶこと

Slide 23

Slide 23 text

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)

Slide 24

Slide 24 text

スモールビジネスを、世界の主役に。