Kaltura が AWS CodeBuild ホステッドランナーを使用して CI/CD を加速した方法

本記事は 2025 年 12 月 18 日に公開された　「How Kaltura Accelerates CI/CD Using AWS CodeBuild-hosted Runners」　を翻訳したものです。

この投稿は、Kaltura のシニアプラットフォームエンジニアである Adi Ziv 氏が AWS との協力により寄稿しました。

AI ビデオエクスペリエンスクラウドおよび企業コミュニケーション技術の大手プロバイダーである Kaltura は、GitHub Actions 用の AWS CodeBuild ホステッドランナーに移行することで CI/CD インフラストラクチャを変革しました。この移行により、DevOps の運用オーバーヘッドが 90% 削減され、ビルドキュー時間が 66% 短縮され、インフラストラクチャコストが 60% 削減されました。最も重要なことは、この移行が Kaltura の規模 (1,000 以上のリポジトリ、100 以上の異なるワークフロータイプ、複数の開発チームにわたる 1 日あたり 1,300 のビルド) をサポートしながらこれらの結果を達成したことです。

組織がエンジニアリング業務を拡大するにつれて、効率的な CI/CD インフラストラクチャの維持がますます重要になります。GitHub Actions のようなツールはパイプラインの作成を簡素化しますが、基盤となるインフラストラクチャの管理は、特にセキュリティ要件やプライベートネットワークアクセスのニーズに対処する場合、エンジニアリングチームにとって大きな負担になる可能性があります。Kaltura にとって、この課題は、同社がエンジニアリングチームを急速に拡大し、毎週新しいマイクロサービスをオンボーディングするにつれて深刻になりました。

この投稿では、Kaltura がセルフマネージド Amazon Elastic Kubernetes Service (Amazon EKS) ランナーから CodeBuild ホステッドランナーに移行することで CI/CD インフラストラクチャを近代化し、パフォーマンスを劇的に向上させ、運用オーバーヘッドを削減しながら、強化されたセキュリティ機能を実装した方法を紹介します。

課題とソリューションの概要

セルフホステッドランナーの理解

GitHub ホステッドランナーは、運用オーバーヘッドがゼロで、自動スケーリングがあり、各ジョブに対してクリーンな状態を提供するため、多くの開発チームにとって優れた選択肢です。しかし、Kaltura のような特定のセキュリティおよび運用要件を持つ企業にとって、セルフホステッドランナーの方が適していました。GitHub ホステッドランナーは、安全ではあるものの、企業が機密性の高いワークロードに必要とする可能性のある、同じレベルの詳細な制御を提供しない共有環境で動作します。AWS 上のセルフホステッドランナーに移行することで、Kaltura は Amazon Virtual Private Cloud (Amazon VPC) の分離、AWS Identity and Access Management (IAM) ポリシー、きめ細かいアクセス管理などの堅牢なセキュリティ制御にアクセスできるようになりました。さらに、セルフホステッドランナーにより、Kaltura は特殊なニーズに合わせてハードウェア構成をカスタマイズし、特定の使用パターンに合わせてコストを最適化し、運用に不可欠なプライベートネットワークリソースへの直接アクセスを維持できるようになりました。

最初に実装されたセルフホステッドランナーは、Kaltura が必要とする制御を提供しました。Amazon VPC 内にランナーをデプロイすることで、Kaltura はエンタープライズ規模の運用に不可欠な機能を獲得しました。この実装により、IAM ロールを通じて詳細な権限を実装しながら、内部リソースへの直接アクセスが可能になりました。Amazon エンドポイントを使用することで、Kaltura はパブリック API リクエストを回避し、すべてのトラフィックが組織の安全なプライベートネットワーク内に留まることを保証しました。

Amazon EKS ベースの初期ソリューション

Kaltura の初期ソリューションは、ノードの自動スケーリングに Karpenter を使用して、Amazon EKS 上にセルフホステッド GitHub Actions ランナーをデプロイしました。Kaltura は、GitHub API をポーリングしてキューに入っているワークフローを確認し、必要なランナーを起動するカスタムコントローラーを実装しました。このソリューションは Kaltura が必要とするセキュリティと制御を提供しましたが、大きな運用上の課題をもたらしました。

問題の核心は、Kaltura のポーリングメカニズムに起因していました。ソリューションの規模が拡大するにつれて、Kaltura は頻繁に GitHub の API レート制限に達し、ポーリング頻度を 2 分間隔に減らすことを余儀なくされました。これらの状況は、運用上の問題の連鎖効果を生み出しました。DevOps チームは、ランナーイメージ、インフラストラクチャ、スケーリングメカニズムの維持にかなりの時間を費やしました。新しいリポジトリごとに手動での構成更新が必要となり、開発プロセスにボトルネックが生じました。パフォーマンス SLA を満たすために、Kaltura はウォームランナープールを維持し、インフラストラクチャコストを大幅に増加させました。

図 1：初期ソリューションは Amazon EKS と Karpenter が GitHub ランナーを起動する形式でした

開発チームへの影響は大きなものでした。すべてのワークフロー実行は、キューイングと実行の間に最低 2 分の遅延に直面しました。これらの遅延は 1 日を通じて蓄積され、開発者の生産性に深刻な影響を与えました。DevOps チームは、インフラストラクチャのメンテナンスタスクを処理するために、他のイニシアチブから常に引き離されることになりました。Kaltura が拡大を続けるにつれて、状況はますます維持できなくなりました。

Kaltura のソリューション – AWS CodeBuild ホステッドランナー

いくつかのオプションを評価した後、Kaltura は、セルフホステッドソリューションのセキュリティと制御の利点を維持しながら、インフラストラクチャの課題を解決するために CodeBuild ホステッドランナーを選択しました。この新しいアーキテクチャは、CI/CD ソリューションの動作方法を根本的に変更し、ポーリングベースのシステムから Webhook ベースのシステムに移行しました。

図 2：AWS CodeBuild ベースのソリューションはフルマネージドであり、Webhook ベースになっています

新しいアーキテクチャは、シンプルでありながら強力なフローを通じて動作します。開発者がコードを GitHub にプッシュすると、GitHub は AWS CodeConnections に即座に Webhook 通知を送信します。これにより CodeBuild がトリガーされ、Kaltura の Amazon VPC 内にランナーがプロビジョニングされます。その後、GitHub Actions ワークフローがこの CodeBuild ランナー上で実行され、最小権限の原則に従ったきめ細かい IAM ロールを活用して AWS サービスにアクセスします。

主要なアーキテクチャコンポーネント

Webhook ベースのアーキテクチャは、以前のポーリングの課題を完全に排除します。定期的なチェックを待つ代わりに、ワークフローはトリガーされるとすぐに実行を開始します。CodeBuild と CodeConnections は、リポジトリ、組織、またはエンタープライズレベルで構成可能な Webhook を持つ GitHub App を使用します。この統合により、真の CI/CD 自動検出が可能になり、以前の手動構成要件からの大きな進歩となります。

セキュリティは、新しいアーキテクチャの主要なコンポーネントの 1 つです。各ランナーは Amazon VPC 内で動作し、厳格なネットワークセキュリティ要件を維持します。Kaltura は IAM ロールを通じてきめ細かいアクセス制御を実装し、ランナーが AWS Systems Manager Parameter Store、Amazon CloudWatch、AWS Secrets Manager などの必要な特定の AWS サービスのみにアクセスできるようにしました。これにより、アクセス管理を簡素化しながらセキュリティ態勢が維持されます。

インフラストラクチャ管理

CodeBuild のサーバーレスな性質により、インフラストラクチャ管理のアプローチが変わりました。カスタムコントローラーとスケーリングロジックを備えた複雑な Amazon EKS クラスターを維持する代わりに、Kaltura は現在 AWS のマネージドサービスを活用しています。この移行により、ランナーイメージのパッチ適用、インフラストラクチャの維持、スケーリングメカニズムの最適化の必要性がなくなりました。

システムの柔軟性は、多様なワークフロー要件に対して特に価値があることが証明されました。CodeBuild は、標準インスタンスからマルチアーキテクチャビルド、特殊な ARM および GPU ランナーまで、さまざまなコンピューティング構成をサポートします。Kaltura は、異なるランナープールを管理したり、個別のインフラストラクチャスタックを維持したりすることなく、シンプルなラベル構成を通じてコンピューティングリソースをワークフローのニーズに簡単に合わせることができます。

Docker ワークフローの改善

Docker ビルドプロセスで予期しない利点が現れました。以前の Amazon EKS ベースのソリューションでは、コンテナビルドに複雑な Docker-in-Docker (DinD) 構成または Kaniko のような代替ツールが必要でした。CodeBuild のネイティブ Docker サポートにより、これらの複雑さが解消されました。このサービスは、Docker が直接実行できる分離されたビルド環境を提供し、ビルドパフォーマンスを大幅に向上させる組み込みのレイヤーキャッシング機能を備えています。

自動検出とセルフサービス

新しいアーキテクチャの主な利点は、そのセルフサービス機能です。開発チームが新しいリポジトリを作成したり、既存のリポジトリを変更したりする場合、手動での DevOps の介入は必要ありません。システムは、事前定義された構成とワークフローの runs-on ラベルに基づいて、適切なランナーを自動的にプロビジョニングします。このセルフサービスアプローチにより、Kaltura の運用オーバーヘッドが劇的に削減され、開発者の生産性が向上しました。

以下は、新しいアプローチを示す典型的なワークフロー構成です：

name: Hello World
on: [push]
jobs:
  Hello-World-Job:
    runs-on:
      - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
      - image:${{ matrix.os }}
      - instance-size:${{ matrix.size }}
      - fleet:myFleet
      - buildspec-override:true
    strategy:
      matrix:
        include:
          - os: arm-3.0
            size: small
          - os: linux-5.0
            size: large
    steps:
      - run: echo "Hello World!"

この構成は、Kaltura がシンプルで宣言的なワークフロー定義を維持しながら、CodeBuild の柔軟性をどのように活用しているかを示しています。チームはラベルを通じてコンピューティングニーズを指定でき、システムはすべての基盤となるプロビジョニングと管理を処理します。

移行アプローチ

CodeBuild ランナーへの移行には、ワークフローの変更を最小限に抑えたシームレスな移行が含まれていました。移行の成功の鍵はそのシンプルさでした – ほとんどのワークフローは runs-on ラベルへの 1 つの変更のみが必要でした：

runs-on: codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}

1 対 1 の互換性があるため、既存のワークフローはさらなる変更なしに機能し続けました。

結果

新しいアーキテクチャは、1,000 以上のリポジトリと 100 のワークフロータイプにわたって 1 日あたり 1,300 以上のビルドを正常に処理し、さまざまなセキュリティ要件を持つ複数の開発チームにサービスを提供しています。CodeBuild ホステッドランナーへの移行の結果は、すべての主要な指標で大幅な改善をもたらしました：

運用における効果：

DevOps運用オーバーヘッドを 90% 削減
ビルドキュー時間を 66% 短縮
インフラストラクチャコストを 60% 削減
開発者 1 人あたり 1 日 30 分の時間節約

最も重要なことは、より高速なビルド、運用負担の削減、一貫したパフォーマンスにより、開発者の満足度が向上したことです。システムのセルフサービスの性質により、オンボーディングのボトルネックが解消され、開発ライフサイクルが加速されました。

結論

CodeBuild ホステッドランナーを通じた Kaltura の CI/CD インフラストラクチャの変革は、最新のクラウドサービスが複雑なエンタープライズ規模の開発課題をどのように解決するかを示しています。Amazon EKS 上のセルフホステッドランナーの管理から AWS マネージドサービスの活用への移行は、エンタープライズグレードのセキュリティ要件を維持しながら、運用オーバーヘッドの 90% 削減、ビルドキューの 66% 高速化、60% のコスト削減を実現しました。

同様の道を検討している組織には、重要でないリポジトリを使用したパイロットプログラムから始めることをお勧めします。ワークフロー要件、セキュリティニーズ、パフォーマンスのボトルネックを理解して、効果的な移行戦略を形成することに焦点を当ててください。移行の影響を可視化し、ステークホルダーに ROI を示すために、コスト配分タグと監視を早期に実装してください。

追加リソース

翻訳はソリューションアーキテクトの紙谷が担当しました。原文はこちらです。

著者について

	Adi Ziv は Kaltura のシニアプラットフォームエンジニアで、スケーラブルで回復力があり最適化されたクラウドネイティブアプリケーションとインフラストラクチャの設計と構築において 10 年以上の経験を持っています。彼はサーバーレス、コンテナ化、およびイベント駆動アーキテクチャを専門としています。
	Michael Shapira は、機械学習と生成 AI ソリューションを専門とする AWS のシニアソリューションアーキテクトです。19 年間のソフトウェア開発経験を持つ彼は、最先端の AI 技術を活用して顧客のビジネス変革とクラウド導入の加速を支援することに情熱を注いでいます。Michael は AWS 機械学習コミュニティの積極的なメンバーでもあり、イノベーションと知識共有に貢献しながら、顧客がエンタープライズレベルで AI とクラウドインフラストラクチャを拡張できるよう支援しています。クラウドソリューションの設計に携わっていない時は、Michael は熱心な写真家として、カメラのレンズを通して世界を捉えることを楽しんでいます。
	Maya Morav Freiman は AWS のテクニカルアカウントマネージャーで、お客様が AWS サービスから最大限の価値を得て、運用および事業目標を達成できるよう支援しています。彼女は AWS サーバーレスコミュニティの一員であり、 DevOps エンジニアとして 10 年の経験を持っています。

この投稿の内容と意見は第三者の著者のものであり、AWS はこの投稿の内容または正確性について責任を負いません。

Amazon Web Services ブログ