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

https://event.cloudnativedays.jp/cndw2024/talks/2405

Transcript

1. © DeNA Co., Ltd. 1 Kubernetes だけじゃない！ Amazon ECS で実現するクラウドネイティブな GitHub Actions セルフホストランナー 幸田優哉 IT 本部品質管理部 SWET 第二グループ 株式会社ディー・エヌ・エー
2. © DeNA Co., Ltd. 2 Yuya Koda DeNA の SWET (SoftWare Engineer in Test) チーム所属 お仕事は全社向けに提供している GitHub Actions セルフホストランナーをいい感じにすることです。 最近のマイブームは立ち飲み屋さん巡り DeNA IT 本部品質管理部 SWET 第二グループ ponkio_o © DeNA Co., Ltd. 自己紹介 koday.me
3. © DeNA Co., Ltd. 3 今日話すこと、話さないこと 話すこと • [前半] 全社用ランナーの概要と設計及び技術選定 • [後半] 全社用ランナーの運用について 話さないこと • GitHub Actions のワークフローについて • Amazon ECS / Kubernetes の詳しい話 • セルフホストランナーの技術的な話 (多少は出てきますが)
4. © DeNA Co., Ltd. 4 セルフホストランナーについて
5. © DeNA Co., Ltd. 5 セルフホストランナーとは • セルフホストランナーは GitHub Actions の Job を自前のインフラ上で実行する ための仕組み ◦ actions/runner というリポジトリでソースコードが公開されている • 物理マシン、仮想マシン、コンテナなど様々な場所で実行可能
6. © DeNA Co., Ltd. 6 なぜセルフホストランナー？ 大きく２つ理由がある • GitHub Enterprise Server (GHES) は、GitHub-hosted Runner に対応していないため ◦ つまり runs-on: ubuntu-latest できない • セキュリティ的な事情で、開発時に自前のインフラ上での Job の実行が要求されるケー スがある → DeNA では GHES の利用がメインであるため GitHub Actions を利用するためにはセルフ ホストランナーの運用が必須となる
7. © DeNA Co., Ltd. 7 セルフホストランナーの実行方法
8. © DeNA Co., Ltd. 8 セルフホストランナーの実行 セルフホストランナーは単に動かすだけならとてもシンプル
9. © DeNA Co., Ltd. 9 大規模ランナーの設計と技術選定
10. © DeNA Co., Ltd. 10 全社用ランナーの設計から構築まで 次のような流れで進めた 1. 要件の洗い出し 2. OSS の比較検討 3. 構築・実装
11. © DeNA Co., Ltd. 11 要件の洗い出し
12. © DeNA Co., Ltd. 12 全社用ランナーで定めた要件 簡単に構築できるランナーも、「全社向け」に提供するとなると考慮事項がたくさん出てくる 構築や OSS を検討する前に、まずは次のような要件を定めた 1. 実行環境をジョブごとに確実に隔離可能であること 2. Enterprise Runner として構成可能であること 3. 少人数で運用し続けられること
13. © DeNA Co., Ltd. 13 実行環境をジョブごとに確実に隔離可能であること 社内には秘匿性の高いプロジェクトも存在するため、他のプロジェクトの実行環境と ファイルやネットワークが確実に隔離されることは必須要件 例えば、次のようなことは絶対に起きないように設計する必要があった • ディレクトリを移動すると他のプロジェクトのソースコードが見えてしまう • 各サービスの認証情報が残ってしまう • docker ps した時に他のプロジェクトのコンテナが見えてしまう • ネットワーク越しに他のジョブにアクセスできてしまう 1
14. © DeNA Co., Ltd. 14 Enterprise Runner として構成可能であること セルフホストランナーはいくつかのスコープでランナーを登録することができるが、 リソースの最適化のために Enterprise Runner を利用したかった Enterprise Organization Repository Repository Enterprise Runner (全 Organization / Repository で利用可能) Organization Runner (特定 Organization 内で利用可能) Repository Runner (特定 Repository でのみ利用可能) 2 Organization
15. © DeNA Co., Ltd. 15 少人数で運用し続けられること 「動かし続ける」ために運用コストも外せない要件の１つ • 当時の SWET メンバーは３人 ◦ セルフホストランナーの専任は１人 (自分) のみ • 当時想定されていた主なタスク ◦ ランナーが動く何らかの実行基盤 (ECS, k8s…etc) の保守・運用 ◦ ランナー本体のアップデート ◦ ランナーを動かすコンテナのアップデート ◦ その他、障害発生時の調査など 3
16. © DeNA Co., Ltd. 16 OSS の比較検討
17. © DeNA Co., Ltd. 17 セルフホストランナーと OSS ランナーをいい感じにやってくれる OSS がいくつか存在するが、代表的なのは次の２つ • actions/actions-runner-controller • philips-labs/terraform-aws-github-runner
18. © DeNA Co., Ltd. 18 actions/actions-runner-controller Kubernetes のカスタムコントローラーで、カスタムリソースとしてランナーを管理できる (現在は) GitHub 公式の OSS で、ランナー部分はコンテナ (Pod) で動作する • セルフホストランナーに必要な機能がほぼ入っている • GitHub 公式サポート • Enterprise ランナー対応 1 アーキテクチャ図 (公式ドキュメントより)
19. © DeNA Co., Ltd. 19 philips-labs/terraform-aws-github-runner AWS のサーバレス系のサービスを利用して、ランナーをスケールさせるコントローラーを 構築するための Terraform Module で、ランナー部分は VM (EC2) で動作する • セルフホストランナーに必要な機能がほぼ入っている • サーバレス系サービスでコントローラーが完結する • Enterprise Runner 非対応 2 アーキテクチャ図 (README より)
20. © DeNA Co., Ltd. 20 Container vs VM
21. © DeNA Co., Ltd. 21 Container vs VM 最初に紹介した通り、actions/runner は任意の場所で実行可能だが、次のような理由から VM よりも優位であると判断しコンテナを利用して動かすことにした • 実行環境を隔離しつつ１つの VM (EC2) で複数台のランナーが動かせる ◦ １ジョブにつき１プロセス使用するので、いかに効率よく並列数を稼ぐかが大事 • クリーンな実行環境を作りやすい • デプロイなどを自動化しやすい • プリインストールツールなどの保守が楽
22. © DeNA Co., Ltd. 22 OSS の比較検討 ２つの OSS を比較すると ARC は概ね要件を満たしていたが、最終的に採用しなかった actions-runner-controller (ARC) terraform-aws-github-runner ジョブの実行環境隔離 ◯ ◯ コンテナで動作可能 ◯ X Enterprise Runner の対応 ◯ X 運用・保守 △ ◯
23. © DeNA Co., Ltd. 23 なぜ Kubernetes を採用しなかったか？
24. © DeNA Co., Ltd. 24 前提 当時の状況は次のとおり • チームで既に運用されている Kubernetes クラスタが存在しなかった (※1) ◦ 今回のために新しくクラスタを構築する必要があった • (自分含め) メンバーは Kubernetes を触った経験はあるが、深い知見があるわけではない ◦ また新規メンバーのキャッチアップにも時間がかかると感じた • セルフホストランナー専任のメンバーは自分だけで、他のメンバーは兼任 • 既に ECS で作られた PoC が存在していた ◦ ECS でも概ね実現可能であることは見えていた ※1) 厳密には存在するがまともにメンテできていない 😇
25. © DeNA Co., Ltd. 25 選定時のポイント
26. © DeNA Co., Ltd. 26 1 クラスタアップデートの運用コスト Kubernetes は４ヶ月に一度のアップデートが存在し、継続的にこれらのバージョンアップ に付き合っていく必要があり、マネージド Kubernetes であってもそこそこ大変 • コントロールプレーンのアップデート ◦ これ単体で言えばマネージドの場合にはほぼ気にしなくても良い • 非推奨 API への対応 • アップグレード戦略 ポイント マネージド Kubernetes の場合１クリックでコントロールプレーンの更新が完結するが、果たして それだけなのか？また限られた人員で継続することは可能か？
27. © DeNA Co., Ltd. 27 2 エコシステムの保守 Kubernetes はそれ単体で使うことは少なく、何かしらのエコシステムと共に使われること が多い。必須ではないものの、導入した場合にはそれらの設計も別途必要になる • デプロイとマニフェスト管理 ◦ ArgoCD / Flux • オートスケーリング ◦ VPA / HPA / CA • シークレット管理 ◦ ESO (External Secrets Operator) ポイント 追加でどのようなコンポーネントが必要になるか？またそれらの保守は続けられるか？
28. © DeNA Co., Ltd. 28 3 Platform としての Kubernetes Kubernetes はコンテナオーケストレーションツールの枠組みを超えて、プラットフォーム 的な側面を持っていると考えており、今回の用途ではそこまで活用しきれないと判断 • 少なくとも設計段階では「ARC を動かす」以外の用途でクラスタが使われるイメージ が湧かなかった • もちろん ARC の存在は大きかったが、これだけなら自分たちで作ったほうがトータル の運用コストを抑えられそうだと感じた ポイント 単に運用コストのかかるコンテナオーケストレーションツールにならないか？ (比較的高い) 運用コストに見合う使い方ができるか、またそのリターンは期待できるか？
29. © DeNA Co., Ltd. 29 まとめ • クラスタ運用 (主にバージョンアップデート) にかかるコストが大きいと判断 ◦ マネージドサービスならコントロールプレーンの管理は気にしなくても OK • Kubernetes の場合、直接的にランナーに関係しないエコシステムの保守が大変そう ◦ バージョンアップ起因でバグったりすることはそこそこある ◦ それによる考慮事項も増えそうだった • 払う運用コストに見合うリターンが期待できなかった ◦ 悪い言い方をすると運用コストのかかる「ランナー動かす君」になりそうだった
30. © DeNA Co., Ltd. 30 最終的に
31. © DeNA Co., Ltd. 31 最終的に 最終的に下記のような方針で、ランナーの基盤を構築することにした • Amazon ECS (on EC2) をベースに構築する ◦ Fargate は技術的な制約で利用できなかった ▪ 主に docker in docker を実現するのが難しかった • ジョブの需要に応じてスケールアウトするためのコントローラーは自作する • マネージドサービスで代替可能なものはマネージドサービスを利用する ◦ オートスケーリング、シークレット管理、メトリクス
32. © DeNA Co., Ltd. 32 ECS で構築してどうだったか？
33. © DeNA Co., Ltd. 33 概ね正解だった気がする (まだ１年ちょっとですが)
34. © DeNA Co., Ltd. 34 1 クラスタ管理がほぼ不要 やはりクラスタの面倒をほとんど見なくてもいいのは大きい • コントロールプレーンは一切管理不要 ◦ さらに利用に伴う追加料金もなし • ECS の API や ECS Agent に対する破壊的変更が入ることはほぼない • ECS インスタンスは基本的に ECS Optimized AMI を使っておけば OK
35. © 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 が利用可能
36. © DeNA Co., Ltd. 36 ほんとうに…？
37. © DeNA Co., Ltd. 37 少し微妙かも？と思っているポイント ECS ならではの大変さもあり、もちろん Kubernetes や ARC が羨ましくなる時もある • 車輪の再発明 (主にランナーのオートスケール部分) ◦ 自分たちで作ることを決めた以上これは仕方ないですが… ▪ 基本的には AWS の API を呼ぶだけなので実装はシンプルになることが多い • Kubernetes に比べると否めない機能不足感 ◦ 特にスケジューリングやスケーリング周りに機能不足を感じる ◦ 実際に ECS 標準だとクラスタのスケールアウト速度が遅かったので独自の cluster-autoscaler を作ることになった
38. © DeNA Co., Ltd. 38 Appendix 具体的なシステム構成や cluster-autoscaler を作ることになった話については 『GitHub Actions Meetup Tokyo #4』で話しました https://speakerdeck.com/ponkio_o/github-actions-meetup-tokyo-number-4
39. © DeNA Co., Ltd. 39 運用の取り組み
40. © DeNA Co., Ltd. 40 運用の取り組み 低コストでより良いランナーが提供できるように下記のような取り組みを行っている • Renovate を活用した継続的なバージョンアップデート • Grafana を活用したランナーに関するメトリクスの可視化 • 待ち時間を SLO とした台数の調整 • Internal roadmap による機能改善
41. © DeNA Co., Ltd. 41 Renovate を活用した継続的な バージョンアップデート
42. © DeNA Co., Ltd. 42 1 Renovate を活用した継続的なバージョンアップデート 独自で開発したコンポーネントや、Dockerfile など全ての依存関係は Renovate を利用して バージョンの更新を行っている。専用の Shareable Config を作成して８〜９割はオート マージされており、ほぼ常に最新の状態に保たれている。 • actions/runner のバージョン • 各種 Dockerfile のベースイメージのバージョン • 自作のコントローラー (Golang) の各種ライブラリ • CI/CD で利用している各種ツール
43. © DeNA Co., Ltd. 43 Appendix セルフホスト Renovate や automerge の設定の設定方針、プリセットに関する話は 『令和最新版 他人に自慢したいヤバい CI/CD LT 会 @ yabaibuki.dev #2』で話しました https://speakerdeck.com/ponkio_o/yabaibuki-dev-number-2
44. © DeNA Co., Ltd. 44 Grafana を活用したランナーに関する メトリクスの可視化
45. © DeNA Co., Ltd. 45 2 Grafana を活用したランナーの可視化 ランナーの利用状況や混雑時間帯が分かるようにダッシュボードを作成して社内に提供して おり、利用者は cron の実行タイミングやデプロイのタイミングの調整に活用している。 管理者視点ではランナーの台数最適化や社内の費用按分のデータとして活用 • 時間 x 曜日の混雑状況ヒートマップ • ランナー別の実行回数や実行時間 • Organization / Repo ごとの利用状況
46. © DeNA Co., Ltd. 46 利用者向けダッシュボード
47. © DeNA Co., Ltd. 47 管理者向けダッシュボード
48. © DeNA Co., Ltd. 48 ランナー種別の利用状況ダッシュボード
49. © DeNA Co., Ltd. 49 待ち時間を SLO とした台数の調整
50. © DeNA Co., Ltd. 50 3 待ち時間を SLO とした台数の調整 ランナーを無限台数を待機させておけば理屈上待ち時間は無くなるが、現実的ではないため、 平日の業務時間帯の待ち時間 (p90) を SLO 的に扱って台数の調整を行っている。 厳密に守るというよりは「台数を増やす、増やさない」の判断材料として使っていて、コスト と相談しつつ見直すゆるめな運用
51. © DeNA Co., Ltd. 51 Internal roadmap による機能改善
52. © DeNA Co., Ltd. 52 4 Internal roadmap による機能改善 社内向けに roadmap リポジトリを作成し、機能リクエストや改善リクエストを出せるように している
53. © DeNA Co., Ltd. 53 課題と今後の展望
54. © DeNA Co., Ltd. 54 課題 利用者増加に伴い、様々な課題も • 特定リポジトリからの過剰なジョブリクエストによる Noisy Neighbor 問題 ◦ 大量のリクエストによって Enterprise Runner のリソースが食いつぶされる • GitHub Enterprise Server への負荷 ◦ Matrix などを利用したジョブによる Git LFS の並列利用 ◦ コントローラーによる API 呼び出し回数の増加 • コスト最適化
55. © DeNA Co., Ltd. 55 今後の展望 より良い開発者体験を得られるようにしていきたい • 早く、安く使えるランナーの提供 • SLO の見直し ◦ 今だと特定のワークフローの影響を大きく受けてしまう • 未対応ワークロードへの対応 ◦ 特権コンテナの利用 ◦ KVM の利用 ◦ macOS ランナー
56. © DeNA Co., Ltd. 56