【CNDW2024】DeNAがECSを選択した理由と、GitHub Actionsセルフホストランナーの大規模運用

CloudNative Days Winter 2024において、DeNAの幸田優哉氏が「Kubernetesだけじゃない！ Amazon ECSで実現するクラウドネイティブなGitHub Actionsセルフホストランナー」と題し、全社向けのセルフホストランナーを構築・運用した事例を紹介した。なぜKubernetesではなくECSを選択したのか。その技術的背景や運用上のメリット、課題について、実際の事例を交えながら説明した。

GitHub Enterprise Serverとセルフホストランナー

DeNAは、社内でGitHub Enterprise Server（GHES）を運用しており、その制約上GitHub-hosted Runnerを利用できない。そのため「独自のセルフホストランナーを構築する必要があった」と幸田氏は振り返る。セルフホストランナーは、自社のインフラ上でGitHub Actionsのジョブを実行するための仕組み。GitHub公式の「actions/runner」というOSSが公開されており、物理マシン、仮想マシン、コンテナなど、多様な環境で実行可能となっている。

セルフホストランナーとは

セルフホストランナーにより、独自の環境設定やカスタムCI/CDの実行基盤を構築できるほか、特定のリソース要件に対応したチューニングも可能となる。幸田氏は「セルフホストランナーは単に動かすだけならとてもシンプルです。しかし大規模な環境で安定的に運用するためには、スケーリングや管理の工夫が必要になります」と語る。

要件の整理と実行環境の隔離

全社向けのGitHub Actionsランナーを構築するにあたって、まずは要件を明確に定めた。最も重要な要件は、ジョブごとの実行環境の完全な隔離である。というのも、DeNAの社内には秘匿性の高いプロジェクトが存在するためだ。異なるプロジェクト間で環境が共有されることは許容できない。例えばあるプロジェクトのディレクトリを操作した際に別のプロジェクトのソースコードが見えてしまう、認証情報が他のジョブに引き継がれる、「docker ps」コマンドで他のプロジェクトのコンテナが見えてしまう、ネットワーク越しに別のジョブへアクセスされる可能性などが懸念されていた。

また少人数での運用が可能であることも重要な要件だった。当時、DeNAのSWETチーム（SoftWare Engineer in Test）は3名しかおらず、セルフホストランナーの専任は1名に過ぎなかった。そのためKubernetesのような高い運用負担が求められる選択肢は難しく、より管理コストの低い方法を選ぶ必要があった。

GitHub ActionsのセルフホストランナーをスケールアウトするためのOSSとしては、「actions/actions-runner-controller（ARC）」と「philips-labs/terraform-aws-github-runner」の2つが存在する。ARCはKubernetesを基盤としたカスタムコントローラーであり、GitHub公式OSSとしてエンタープライズ環境でも利用可能である。一方terraform-aws-github-runnerは、AWSのサーバレスサービスを利用し、ランナーの管理を行う仕組みとなっている。セルフホストランナーに必要な機能がほぼ揃っており、サーバレス系のサービスでコントローラーが完結するメリットがあるものの、Enterprise Runnerには対応していない点が課題となる。

セルフホストランナーとOSS

2つのOSSを比較するとARCは概ね要件を満たしていたが、最終的にはどちらも採用しなかった。替わりにAmazon ECS（on EC2）、つまり自社のインフラに適した形でGitHub Actionsのランナーを運用する手法を選択することとした。その理由として、まずKubernetesの運用コストの高さが挙げられる。Kubernetesは4ヶ月ごとにバージョンアップが必要であり、そのたびに非推奨APIへの対応やアップグレード戦略の検討が求められる。加えて、Kubernetesのエコシステムを運用するには、ArgoCD、HPA、External Secrets Operatorなど多くのツールを管理する必要がある。これらの運用負担を考慮した結果、少人数のチームではKubernetesを選択するメリットが薄いと判断した。

こうしてECSを利用することで、Kubernetesに比べて管理の負担を大幅に軽減できる。またECS環境でもジョブの需要に応じたスケールアウトを実現するために、DeNA独自のコントローラーを開発し、必要なリソースのみを動的に確保できるようにした。

ECSランナーの継続的な改善と監視

ECSベースのセルフホストランナーの運用においては、いくつかの工夫が施されている。まず継続的なバージョン管理のためにRenovateを活用し、「actions/runner」のバージョンやDockerfileの更新を自動化した。Renovateは、依存関係の管理を自動化し、ソフトウェアのセキュリティと最新性を維持するためのツールで、リポジトリ内のライブラリやフレームワークの更新を定期的にチェックし、適切なアップデートを適用する役割を担っている。これにより、全体の8～9割の依存関係をオートマージし、最新の状態を保つことができている。

Renovateを活用した継続的なバージョンアップデート

またランナーのメトリクスを可視化するためにGrafanaを導入し、利用者向けのダッシュボードを提供している。このダッシュボードでは、混雑時間帯やリソースの使用状況を可視化し、利用者が最適なジョブ実行タイミングを選択できるようにしている。Grafanaは、オープンソースのデータ可視化ツールであり、さまざまなデータソースからメトリクスを収集し、直感的なダッシュボードを提供する。とくにリアルタイムモニタリングやアラート機能を活用することで、システムの運用監視を効率化できる点が特徴である。

さらにリソースの最適化のため、ジョブ待ち時間を監視し、SLO（Service Level Objective）に基づいた台数調整を実施している。これにより、リソースの無駄を抑えながら、必要な性能を確保することが可能となった。

そしてInternal Roadmapを作成し、社内向けにroadmapリポジトリを作成し、開発者がGitHub Actionsの機能改善リクエストを出せる仕組みを導入した。

リソース管理とコスト最適化の課題

運用が進む中で、いくつかの課題も浮上している。特定のリポジトリが過剰にリソースを消費し、他のジョブに影響を与える「Noisy Neighbor」問題が発生しており、リソース配分の改善が求められている。またGitHub Enterprise Serverへの負荷が増加し、ジョブの並列実行による負荷分散の最適化も課題となっている。

さらにコストの最適化も重要なテーマとなっている。ECSを利用することでクラスタ管理の負担は軽減されたが、インフラコストの増大に対する対応が求められている。特に、スポットインスタンスの活用によるコスト削減や、利用状況に応じた動的なリソーススケーリングの最適化が検討されている。これにより、パフォーマンスを維持しつつ、不要なコストを抑える戦略が進められている。

課題

今後の展望として、特権コンテナやKVM対応の検討、macOSランナーのサポート拡充、スポットインスタンスの活用によるコスト最適化が挙げられている。「ECSでの構築は概ね正解だったと思います。しかしさらなる最適化に向けて改善を続けていきます」と幸田氏は語り、セッションを締めくくった。