Kubernetes だけじゃない！Amazon ECS で実現するクラウドネイティブな GitHub Actions セルフホストランナー / CNDW2024

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© DeNA Co., Ltd. 2 Yuya Koda DeNA の SWET (SoftWare Engineer in Test) チーム所属お仕事は全社向けに提供している GitHub Actions セルフホストランナーをいい感じにすることです。最近のマイブームは立ち飲み屋さん巡り DeNA IT 本部品質管理部 SWET 第二グループ ponkio_o © DeNA Co., Ltd. 自己紹介 koday.me

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© DeNA Co., Ltd. 6 なぜセルフホストランナー？大きく２つ理由がある ● GitHub Enterprise Server (GHES) は、GitHub-hosted Runner に対応していないため ○ つまり runs-on: ubuntu-latest できない ● セキュリティ的な事情で、開発時に自前のインフラ上での Job の実行が要求されるケースがある → DeNA では GHES の利用がメインであるため GitHub Actions を利用するためにはセルフホストランナーの運用が必須となる

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© DeNA Co., Ltd. 13 実行環境をジョブごとに確実に隔離可能であること社内には秘匿性の高いプロジェクトも存在するため、他のプロジェクトの実行環境とファイルやネットワークが確実に隔離されることは必須要件例えば、次のようなことは絶対に起きないように設計する必要があった ● ディレクトリを移動すると他のプロジェクトのソースコードが見えてしまう ● 各サービスの認証情報が残ってしまう ● docker ps した時に他のプロジェクトのコンテナが見えてしまう ● ネットワーク越しに他のジョブにアクセスできてしまう 1

Slide 14

Slide 14 text

© DeNA Co., Ltd. 14 Enterprise Runner として構成可能であることセルフホストランナーはいくつかのスコープでランナーを登録することができるが、リソースの最適化のために Enterprise Runner を利用したかった Enterprise Organization Repository Repository Enterprise Runner (全 Organization / Repository で利用可能) Organization Runner (特定 Organization 内で利用可能) Repository Runner (特定 Repository でのみ利用可能) 2 Organization

Slide 15

Slide 15 text

© DeNA Co., Ltd. 15 少人数で運用し続けられること「動かし続ける」ために運用コストも外せない要件の１つ ● 当時の SWET メンバーは３人 ○ セルフホストランナーの専任は１人 (自分) のみ ● 当時想定されていた主なタスク ○ ランナーが動く何らかの実行基盤 (ECS, k8s…etc) の保守・運用 ○ ランナー本体のアップデート ○ ランナーを動かすコンテナのアップデート ○ その他、障害発生時の調査など 3

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© DeNA Co., Ltd. 18 actions/actions-runner-controller Kubernetes のカスタムコントローラーで、カスタムリソースとしてランナーを管理できる (現在は) GitHub 公式の OSS で、ランナー部分はコンテナ (Pod) で動作する ● セルフホストランナーに必要な機能がほぼ入っている ● GitHub 公式サポート ● Enterprise ランナー対応 1 アーキテクチャ図 (公式ドキュメントより)

Slide 19

Slide 19 text

© DeNA Co., Ltd. 19 philips-labs/terraform-aws-github-runner AWS のサーバレス系のサービスを利用して、ランナーをスケールさせるコントローラーを構築するための Terraform Module で、ランナー部分は VM (EC2) で動作する ● セルフホストランナーに必要な機能がほぼ入っている ● サーバレス系サービスでコントローラーが完結する ● Enterprise Runner 非対応 2 アーキテクチャ図 (README より)

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© DeNA Co., Ltd. 21 Container vs VM 最初に紹介した通り、actions/runner は任意の場所で実行可能だが、次のような理由から VM よりも優位であると判断しコンテナを利用して動かすことにした ● 実行環境を隔離しつつ１つの VM (EC2) で複数台のランナーが動かせる ○ １ジョブにつき１プロセス使用するので、いかに効率よく並列数を稼ぐかが大事 ● クリーンな実行環境を作りやすい ● デプロイなどを自動化しやすい ● プリインストールツールなどの保守が楽

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© DeNA Co., Ltd. 24 前提当時の状況は次のとおり ● チームで既に運用されている Kubernetes クラスタが存在しなかった (※1) ○ 今回のために新しくクラスタを構築する必要があった ● (自分含め) メンバーは Kubernetes を触った経験はあるが、深い知見があるわけではない ○ また新規メンバーのキャッチアップにも時間がかかると感じた ● セルフホストランナー専任のメンバーは自分だけで、他のメンバーは兼任 ● 既に ECS で作られた PoC が存在していた ○ ECS でも概ね実現可能であることは見えていた ※1) 厳密には存在するがまともにメンテできていない 😇

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© DeNA Co., Ltd. 26 1 クラスタアップデートの運用コスト Kubernetes は４ヶ月に一度のアップデートが存在し、継続的にこれらのバージョンアップに付き合っていく必要があり、マネージド Kubernetes であってもそこそこ大変 ● コントロールプレーンのアップデート ○ これ単体で言えばマネージドの場合にはほぼ気にしなくても良い ● 非推奨 API への対応 ● アップグレード戦略ポイントマネージド Kubernetes の場合１クリックでコントロールプレーンの更新が完結するが、果たしてそれだけなのか？また限られた人員で継続することは可能か？

Slide 27

Slide 27 text

© DeNA Co., Ltd. 27 2 エコシステムの保守 Kubernetes はそれ単体で使うことは少なく、何かしらのエコシステムと共に使われることが多い。必須ではないものの、導入した場合にはそれらの設計も別途必要になる ● デプロイとマニフェスト管理 ○ ArgoCD / Flux ● オートスケーリング ○ VPA / HPA / CA ● シークレット管理 ○ ESO (External Secrets Operator) ポイント追加でどのようなコンポーネントが必要になるか？またそれらの保守は続けられるか？

Slide 28

Slide 28 text

© DeNA Co., Ltd. 28 3 Platform としての Kubernetes Kubernetes はコンテナオーケストレーションツールの枠組みを超えて、プラットフォーム的な側面を持っていると考えており、今回の用途ではそこまで活用しきれないと判断 ● 少なくとも設計段階では「ARC を動かす」以外の用途でクラスタが使われるイメージが湧かなかった ● もちろん ARC の存在は大きかったが、これだけなら自分たちで作ったほうがトータルの運用コストを抑えられそうだと感じたポイント単に運用コストのかかるコンテナオーケストレーションツールにならないか？ (比較的高い) 運用コストに見合う使い方ができるか、またそのリターンは期待できるか？

Slide 29

Slide 29 text

© DeNA Co., Ltd. 29 まとめ ● クラスタ運用 (主にバージョンアップデート) にかかるコストが大きいと判断 ○ マネージドサービスならコントロールプレーンの管理は気にしなくても OK ● Kubernetes の場合、直接的にランナーに関係しないエコシステムの保守が大変そう ○ バージョンアップ起因でバグったりすることはそこそこある ○ それによる考慮事項も増えそうだった ● 払う運用コストに見合うリターンが期待できなかった ○ 悪い言い方をすると運用コストのかかる「ランナー動かす君」になりそうだった

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© DeNA Co., Ltd. 31 最終的に最終的に下記のような方針で、ランナーの基盤を構築することにした ● Amazon ECS (on EC2) をベースに構築する ○ Fargate は技術的な制約で利用できなかった ■ 主に docker in docker を実現するのが難しかった ● ジョブの需要に応じてスケールアウトするためのコントローラーは自作する ● マネージドサービスで代替可能なものはマネージドサービスを利用する ○ オートスケーリング、シークレット管理、メトリクス

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

© DeNA Co., Ltd. 35 2 他の AWS サービスと連携しやすい当然ですが、他の AWS サービスとネイティブに連携できるため考慮事項が少なく、関連したエコシステムの保守も必要ない ● シークレット管理は Secrets Manager / Systems Manager Parameter Store ● 権限管理は Identity and Access Management (IAM) で完結 ● メトリクスは主要なものは CloudWatch に勝手に吐かれる ● スケーリングも Cluster Autoscaler (Capacity Provider) や Application Autoscaling が利用可能

Slide 36

Slide 36 text

Slide 37

Slide 37 text

© DeNA Co., Ltd. 37 少し微妙かも？と思っているポイント ECS ならではの大変さもあり、もちろん Kubernetes や ARC が羨ましくなる時もある ● 車輪の再発明 (主にランナーのオートスケール部分) ○ 自分たちで作ることを決めた以上これは仕方ないですが… ■ 基本的には AWS の API を呼ぶだけなので実装はシンプルになることが多い ● Kubernetes に比べると否めない機能不足感 ○ 特にスケジューリングやスケーリング周りに機能不足を感じる ○ 実際に ECS 標準だとクラスタのスケールアウト速度が遅かったので独自の cluster-autoscaler を作ることになった

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

© DeNA Co., Ltd. 42 1 Renovate を活用した継続的なバージョンアップデート独自で開発したコンポーネントや、Dockerfile など全ての依存関係は Renovate を利用してバージョンの更新を行っている。専用の Shareable Config を作成して８〜９割はオートマージされており、ほぼ常に最新の状態に保たれている。 ● actions/runner のバージョン ● 各種 Dockerfile のベースイメージのバージョン ● 自作のコントローラー (Golang) の各種ライブラリ ● CI/CD で利用している各種ツール

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

© DeNA Co., Ltd. 45 2 Grafana を活用したランナーの可視化ランナーの利用状況や混雑時間帯が分かるようにダッシュボードを作成して社内に提供しており、利用者は cron の実行タイミングやデプロイのタイミングの調整に活用している。管理者視点ではランナーの台数最適化や社内の費用按分のデータとして活用 ● 時間 x 曜日の混雑状況ヒートマップ ● ランナー別の実行回数や実行時間 ● Organization / Repo ごとの利用状況

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

© DeNA Co., Ltd. 54 課題利用者増加に伴い、様々な課題も ● 特定リポジトリからの過剰なジョブリクエストによる Noisy Neighbor 問題 ○ 大量のリクエストによって Enterprise Runner のリソースが食いつぶされる ● GitHub Enterprise Server への負荷 ○ Matrix などを利用したジョブによる Git LFS の並列利用 ○ コントローラーによる API 呼び出し回数の増加 ● コスト最適化

Slide 55

Slide 55 text

Slide 56

Slide 56 text