どちらかだけじゃもったいないかも？ ECSとEKSを適材適所で併用するメリット、運用課題とそれらの対応について

Slide 1

Slide 1 text

どちらかだけじゃもったいないかも？ ECSとEKSを適材適所で併用するメリット、運用課題とそれらの対応について primeNumber Inc. Hiroki Takatsuka (@tk3fftk) ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 1

Slide 2

Slide 2 text

1. はじめに 2. ECSとEKSの一般的な話 3. TROCCO®について 4. TROCCO® on ECS “and” EKS 5. まとめ 6. EKS Auto Mode 目次ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 2

Slide 3

Slide 3 text

髙塚広貴 (@tk3ﬀtk) 株式会社primeNumber プロダクト開発本部 Head of SRE ● ヤフー株式会社 (2016 ~ 2022) ○ CI/CDプラットフォーム Screwdriver.cd SREチームのスクラムマスターやEM ● 株式会社primeNumber (2022 ~ ) ○ TROCCO®/COMETA®のSRE, EM, たまにSecurity ● 猫🐈 ○ アルくん (アビシニアン ♂ 4歳) 自己紹介ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 3

Slide 4

Slide 4 text

ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 4 今日の発表で伝えたいこと ● ワークロードによってはECS “and” EKSの選択肢もありかも？ ○ 絶対良い、ではなくあくまで選択肢の提示🚀 ■ ECS “and” EKSでサービス提供しているTROCCO®の運用経験を通じて説明します ● ECS “and” EKSのアーキテクチャについて「アーキテクチャConference 2024」における弊社CTO室中根さんの発表の一部を深堀りする connecting the dots ○ PaaSとSaaSの境目で信頼性と開発速度を両立する〜TROCCO®のこれまでとこれから〜

Slide 5

Slide 5 text

ECSとEKSの一般的な話ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 5

Slide 6

Slide 6 text

● 単純な構成で動かすなら運用管理はかなりシンプル ● フルマネージド型のコンテナオーケストレーションサービス ○ コンテナの配置・スケジューリングをAWSが完全に管理 ○ ≒ 開発者はアプリケーション開発に集中できる ● 他AWSサービスとの統合が容易 ○ Elastic Load BalancingやCloudWatchと連携し、自動スケーリングや監視 ○ IAMによるきめ細かいアクセス制御やVPCとの統合でセキュリティを強化 ● 複数のデプロイ先オプション ○ Amazon EC2, AWS Fargate, ECS Anywhere [おさらい] Amazon Elastic Container Service (ECS) ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 6

Slide 7

Slide 7 text

● 拡張性が高くオープンソースのエコシステムも利用できるが、管理は複雑 ● マネージド Kubernetes (k8s) サービス ○ Control PlaneはAWSが完全管理 ○ インプレースアップデートに対応 ○ k8s主要コンポーネントやAWSサービスとの連携のためのコンポーネントは EKSアドオンとして提供され、管理が容易 ● 複数のデプロイ先オプション ○ Amazon EC2, AWS Fargate, Hybrid Node, EKS Anywhere, Auto Mode… ※ EKSのロゴはですがECS との差分がKだけなのでk8sのロゴを使います [おさらい] Amazon Elastic Kubernetes Service (EKS) ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 7

Slide 8

Slide 8 text

AWSの見解としては以下の通り ● ざっくり「シンプルだが拡張性が低いECS」vs「複雑だが拡張性が高いEKS」 ● どちらかが全面的に優れているわけではない ○ 「AWSでのコンテナサービスの選択は、二者択一である必要はありません」 ○ 「ワークロード特性や好みで使い分けて。コンテナ化されてたら一方通行じゃないし」 ref: Amazon ECS vs Amazon EKS: making sense of AWS container services (2020年の記事だからやや古いけど) ECS vs EKS ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 8

Slide 9

Slide 9 text

ものすごーく単純化して比較表にしてみるとこんな感じ ECS vs EKS ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 9 ECS EKS 拡張性低高 👍 学習コスト低 👍 高運用コスト低 👍 高

Slide 10

Slide 10 text

ワークロードによっては、併用することで EKSの高い拡張性を享受しつつ学習コストや運用コストをカバーできるのでは？ ECS ECS and EKS EKS 拡張性低高 👍 高 👍 学習コスト低 👍 中高運用コスト低 👍 中高 ECS “and” EKS は…？ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a10

Slide 11

Slide 11 text

TROCCO®についてハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a11

Slide 12

Slide 12 text

TROCCO® についてハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 点在するデータの「統合」を自動化「統合」を軸にデータ基盤の構築や運用を支援するSaaSプロダクトデータをビジネスに活用するまでのステップ 12

Slide 13

Slide 13 text

メインの機能であるデータ転送についてハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a13

Slide 14

Slide 14 text

UIで転送の設定を作成ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a14 TROCCO®のUIフォームデータ転送機能の概要

Slide 15

Slide 15 text

TROCCO®のUIフォーム転送実行時に、入力情報を元にEmbulkのYAMLを作成ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a15 Embulkのconﬁg.yml データ転送機能の概要

Slide 16

Slide 16 text

ジョブ実行の単位でコンテナが立ち上がり、終了時に破棄ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a16 データ転送機能の概要データ転送ジョブのフロー TROCCO®のジョブ画面 PaaSとSaaSの境目で信頼性と開発速度を両立する〜TROCCO®のこれまでとこれから〜

Slide 17

Slide 17 text

TROCCO®のジョブ基盤のワークロード特性ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a17 データ転送機能の概要 ● 一日あたり20万以上のデータ転送ジョブが実行される ● 毎時00分と30分にスパイク (スケジュール設定されやすいため) ● 1日の中では午前1時頃がピーク ● 24/365でジョブが動いているここが約1日

Slide 18

Slide 18 text

TROCCO®のアーキテクチャ概観とアーキテクチャ改善の歴史についてハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a18

Slide 19

Slide 19 text

● ユーザーがジョブの設定を行うAPI/UI ● データ転送ジョブを実行するジョブ基盤 TROCCO®は大きく2つのコンポーネントに分けられるハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a19 アーキテクチャ概観アーキテクチャ概観を抽象化したもの

Slide 20

Slide 20 text

● TROCCO®はAPI/UIのトラフィックは比較的少ないサービス ● 一方、ジョブ基盤は高い信頼性を求められる ○ 常に何かしらのジョブが動いている状態 ○ 指定した時間にジョブが動くことの保証 ○ 基盤起因でジョブが失敗しないこと ...などコアの価値提供したい(≒差別化したい)部分はジョブ基盤ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a20

Slide 21

Slide 21 text

体制や技術的背景により、サービスローンチ当初はECSを使っていたハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a21 PaaSとSaaSの境目で信頼性と開発速度を両立する〜TROCCO®のこれまでとこれから〜より

Slide 22

Slide 22 text

コアの価値提供したい部分をEKSに移行してスケーラビリティを高めるハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a22 PaaSとSaaSの境目で信頼性と開発速度を両立する〜TROCCO®のこれまでとこれから〜より抜粋スケールアウトスケールインデプロイ Before (ECS) After (EKS) ECS Task数 = 同時実行可能数 SQSへの流量を見てスケールアウトするなど試行錯誤起動に時間がかかる実行中のジョブがノード上に存在するとスケールインできない Lambdaを使ったりと原始的な手法で試行錯誤実行に長時間かかっているジョブがあると、そのECSタスクをローリングアップデートできずデプロイが一向に完了しない Cluster Autoscalerにより Jobを立ち上げるための Nodeリソースがないとスケールアウト Nodeが空いているとスケールイン実行中のJobがある場合にも完了を待つイメージタグを変えるだけでデプロイ可能に実行中のJobがある場合にも影響を受けない

Slide 23

Slide 23 text

流れとしては「EKSに統一」となりそうだけど… ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a23

Slide 24

Slide 24 text

EKSへの統一は見送りハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a24 PaaSとSaaSの境目で信頼性と開発速度を両立する〜TROCCO®のこれまでとこれから〜より

Slide 25

Slide 25 text

EKS統一を見送った結果どうなったかハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a25

Slide 26

Slide 26 text

● ECS “and” EKSに移行した話は、筆者目線だと入社前に行われた話 ● 筆者はオンプレk8sの世界から来たため入社時の感覚としては”EKSに統一したい”側 ● 先のスライドの通り積極的に統一するモチベーションはなく、リソースも限られているので優先度は上がらずそのままで運用 ● 運用を続けていくなかで「この構成意外とありかも…」となってきた💡 ECS “and” EKSってTROCCO®のワークロードにマッチしているのでは🤔 ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a26

Slide 27

Slide 27 text

TROCCO® on ECS “and” EKS ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a27

Slide 28

Slide 28 text

1. ジョブ基盤という単一の目的を持つEKSクラスタになる 2. ジョブ基盤の負荷がAPI/UIに直接的な影響を与えない (逆も同様) 3. inboundアクセスなしのPrivate Subnetに閉じているため信頼境界になる ECSとEKSを併用することで、EKSはコアの価値提供(ジョブ基盤)に特化できるハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a28

Slide 29

Slide 29 text

● EKS Version更新はジョブ基盤のことだけ考えればOK ○ EKSカナリアリリースの仕組みを作った際にもAPI/UIのことは考慮不要だった ● クラスタのスケーリングもジョブ基盤としてのリソースだけ見積もればよい ● 運用ツールやちょっと動かしたい系も載せちゃえ、とならない ○ 3. のネットワーク分離の話も関連 ECSとEKSを併用することで、EKSはコアの価値提供(ジョブ基盤)に特化できるハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a29 1. ジョブ基盤という単一の目的を持つEKSクラスタになる

Slide 30

Slide 30 text

● EKSに統一していた場合、ノイジーネイバーが発生する可能性 ○ 例: APIに高負荷がかかってスケールしたため、ジョブの起動が遅れる ○ 例: 大量にジョブが動いていたため、APIがスケールできずエラー/デグレ発生 ● ECS側にFargate Spotを入れてtaskが中断されても実行中のジョブは影響なし ECSとEKSを併用することで、EKSはコアの価値提供(ジョブ基盤)に特化できるハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a30 2. ジョブ基盤の負荷がAPI/UIに直接的な影響を与えない (逆も同様)

Slide 31

Slide 31 text

● 一時的にではあるが、ジョブ基盤はユーザーが転送したいデータを保持する ○ 外部からk8sリソースやNodeへアクセスできてしまうと情報漏洩リスク増 ○ TROCCO®のVPCからのアクセスを許可して利用してもらうケースもある ● ジョブ基盤に特化することでinboundアクセスを無くせている ○ ネットワークレベルでの分離になるので、セキュリティ上の考慮事項を大幅削減 ■ (セキュリティチェックシートもｺﾜｸﾅｲ) ECSとEKSを併用することで、EKSはコアの価値提供(ジョブ基盤)に特化できるハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a31 3. inboundアクセスなしのPrivate Subnetに閉じているため信頼境界になる

Slide 32

Slide 32 text

学習コスト・運用コストについてハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a32

Slide 33

Slide 33 text

● ECSがあることで、開発チームがクラウドインフラを触る敷居を下げられている ○ 全員がいきなりEKSを扱えるようになる必要はない ● EKSに関わる必要がある人を減らすことで、コスト増を抑えられている学習コスト増…？いいえ、必ずしもそうではありませんハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a33 全員がEKSをいきなり触るのは難しい ECSがあると段階を踏める

Slide 34

Slide 34 text

ECSはEKSと比較すると学習コストはかなり低い ● シンプルな構成かつすでに動いているものがあるならなおさら低い ○ TROCCO®ではecspressoを使っており、JSONを見ればある程度当たりがつく ● ⚠ ただし、複雑なことをやろうとするとECSも学習コストが高くなってくる ○ EKS(k8s)のほうがオープンソースのエコシステムが整っている ■ オートスケールやサービスメッシュなど ■ k8sであれば学習した内容の可搬性もあるハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a34

Slide 35

Slide 35 text

ECSは運用コストもかなり低いハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a35 ● Platform Versionのアップグレードも気づけば終わっているレベル ● おかね的にもEKSと比べると安いので、スケーリングは多少大味でも良い ○ TROCCO®ではリソース利用率ベースのオートスケールのみ ○ オートスケールを作り込むコスト < 常時task数を増やすが合理的な場合もある ● ⚠ ただし、複雑なことをやろうとするとECSも運用コストが高くなってくる

Slide 36

Slide 36 text

CI/CD (リリース) パイプラインについてハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a36

Slide 37

Slide 37 text

● ECSとEKSで動いているアプリのバージョンに差分があるタイミングで問題が発生することがある ○ EKSに統一していたとしても発生する可能性のある問題 ● ECSとEKSそれぞれにデプロイが必要なのでリリース/ロールバックに時間がかかる ○ ロジックも2重で必要 ECSとEKSで動いているコンポーネントの依存関係を意識する必要があるハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a37 リリースパイプライン(抜粋)

Slide 38

Slide 38 text

● TROCCO®ではSSM Parameter StoreをECSとEKSから参照している ● それぞれクレデンシャルの更新反映タイミングが違う ○ ECS: Update Service時に更新 ○ EKS: External Secrets OperatorでSecretsを定期更新、Pod再起動時に反映 👉 頻繁に更新するものではないため、ドキュメントを用意して運用でカバー ECSとEKS間のクレデンシャルの更新反映タイミングを意識する必要があるハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a38

Slide 39

Slide 39 text

CI/CDパイプラインはこれから改善したいポイントのひとつ🚀 ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a39

Slide 40

Slide 40 text

まとめハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a40

Slide 41

Slide 41 text

● TROCCO®はAPI/UIとジョブ基盤で構成されジョブ基盤に高い信頼性が要求される ● 状況に応じた技術選定を行った結果、ECS “and” EKSのアーキテクチャが生まれた ● ECSとEKSを併用することで、EKSはコアの価値提供(ジョブ基盤)に特化 ● ECSとEKSを併用することで、学習・運用コストは抑えられる ● ECSとEKSを併用する場合、CI/CDパイプラインは検討の余地ありワークロードによってはECS “and” EKSの選択肢もありかも？ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a41

Slide 42

Slide 42 text

こだわりや先入観を一度手放して、日々変化していくプロダクトや状況に合わせて技術選定を継続的に実施するのがよさそう💪 ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a42

Slide 43

Slide 43 text

EKS Auto Mode ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a43

Slide 44

Slide 44 text

● 2024年12月1日 (AWS re:Invent 2024) にリリースされたEKSの新機能 ● つらいインフラ管理のほとんどが自動化される ○ EKSバージョン更新、ノードスケーリング、EKSアドオン管理など ● Karpenterがデフォルトで含まれており、スケーリングはKarpenterベース ○ KarpenterではEC2 APIを直接実行するためインスタンスの起動が高速 ○ Karpenter自体もAuto Modeの管理対象なので管理不要 ■ ユーザーはKarpenter設定用のマニフェストを書いてapplyするだけ ○ ⚠ 何もPodが動いていなければ、0台までスケールインする ● ⚠ Auto Modeで起動されたEC2インスタンスに対して追加コスト(12%)が発生 ● ⚠ EC2インスタンスのAMI指定やSSH接続等はできない [おさらい] EKS Auto Mode ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a44

Slide 45

Slide 45 text

● すでにマネジメントコンソールからの作成だとデフォルトで選択されている ○ これから改善に注力されるであろうことは明らか [おさらい] EKS Auto Mode ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a45

Slide 46

Slide 46 text

EKS Auto Mode はTROCCO®的にはこれからに期待🚀 ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a46 TROCCO®のジョブ基盤には(まだ)不向き ● AMIが指定できない 👉 転送ジョブ用コンテナイメージを含むゴールデンAMIが指定不可 ● 自動でノードがアップデートされる 👉 転送ジョブは途中で止めてしまうと問題があるが、強制終了する可能性 ● 最低台数0台までスケールイン 👉 転送ジョブのリソース要求が始まる前にノードを用意しておきたい ■ 常にover provisioningしておけばいいが、認知負荷↑ ● 通常クラスタよりおねだんが高い💸 👉 ECS on Fargate部分を移行するにも too much

Slide 47

Slide 47 text

さいごにハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a47

Slide 48

Slide 48 text

48 We Are Hiring ! primeNumberではプロダクトづくりに携わるさまざまな職種を絶賛募集しております！まずは、お気軽にカジュアル面談からでも！ (ボドゲカジュ面もあるよ🎲) 募集職種・Product SRE ・Corporate SRE ・ソフトウェアエンジニア・QAエンジニア・エンジニアリングマネージャー・PdM/PMM ・テクニカルライター・デザイナー採用サイト