CI/CD Conference 2023から、ゲーム配信ベンチャーがレガシーなテストと格闘するセッションを紹介

連載 [第1回] :

CI/CD Conference 2023レポート

2023年6月2日(金)

CICD Conferenc 2023から、ミラティブのエンジニアがレガシーなPerlコードの大規模テストに関する事例を解説したセッションを紹介する。

CloudNative Daysが開催したCI/CDに特化したカンファレンス、CI/CD Conference 2023（CICD2023）が2023年3月20日に開催された。今回の記事では、株式会社ミラティブのインフラエンジニアである近藤宇智朗氏のセッションを紹介する。ミラティブはスマートフォンから動画やゲームプレイをストリーミング配信するシステムを提供するベンチャーだ。タイトルは「大規模レガシーテストを倒すためのCI基盤の作り方」というものだ。

●動画：大規模レガシーテストを倒すためのCI基盤の作り方

Mirrativのシステムを支えるテクノロジースタック。GCPやGitHubなどで構成されている

タイトルにあるようにレガシーな大規模テストを実行するための継続的インテグレーション、継続的デプロイメントに関する経験談を解説する内容となっている。

システムの開発は2015年にスタート、当初はPerlをベースにした配信サービスだったが、後にGoを中心としたモダンなシステム開発に移行したという。だが実際にはPerlのコードはまだ生き残っており、今回はそのPerlの資産をテストしビルドするためのCI環境に関するユースケースを解説している。

アプリケーションのCI環境に関するトピックを整理

現時点ではGoで書かれたアプリケーションに対するテスト、システム全体のE2Eテスト、レガシーなPerlのコードで構成されたシステムに対するテストなどが定期実行されているという。

システム全体の近代化として、プラットフォームをGoogle Cloud Platform（GCP）に移行することについて統一を実行。その背景としてアカウントを一つのプラットフォームに寄せて管理を容易にすること、アカウントを集約することでコストを圧縮することなどがあったという。細かい話だが、アプリケーションが利用するコンテナレジストリを同じUSリージョンに配備すると、データ転送料が無料になるという事情もあったと解説した。

CIプラットフォームを統一する背景を説明

そこで採用したのがCloud Buildだ。Cloud BuildはGCPが提供するマネージドビルド環境で、外部のGitHub等のリポジトリとの連携が取れている点や、メッセージングサービスであるCloud Pub/Subとの連携がシンプルである点などが採用の背景であると説明した。

Cloud Buildを選んだ理由を説明

実行環境はマネージドサービスとしたかった、Cloud Build自体の高機能には期待せずに外部サービスとの連携によって機能を実装するという方針に加えて、従量課金を採用したかったというのが選択の理由だと説明。

その後、サービスで必要となるトークンの扱いには工夫が必要だったが、CI/CDをCloud Buildで実行した時に遭遇したトラブルについて解説を行った。

CIで「skip ci」というコメントがコミットにあるとビルドが実行されない

ここで近藤氏は「skip ci]というコメントが存在するコミットリクエストによってイメージビルドが実行されないという問題点について解説を行っているが、どうして「skip ci」というコメントが挿入されるのかというそもそもの状況については解説をせず、イメージを強制的にデプロイするための方法について解説を行った。

skip ciはイメージビルドを行わないための命令で各種CIツールでも同じ仕様だ

ここでの回避策はGitHubからのWebhookをCloud Pub/Subに送ってトリガーとするというものだ。

Cloud Pub/Subを使ってトリガーを実行

ここでもCloud Build自体の機能で回避策を実装するのではなく、GCPが用意するサービスを使って必要な実装が行われていることがわかる。

そして本題である大規模テストに関する課題について解説を行った。これはGoで開発が行われる前のPerlのコードに対する大量のテストを、Cloud Buildに移行する際のチューニングに関する内容となった。

大規模なPerl資産に対するテスト実行のユースケース

創業当初から存在するPerlのコードには大量のテストコードが存在しており、それを新しいプラットフォームで実行するというのがミッションである。単にそのまま実行しただけでは処理時間やコストの観点からベストではないというところから、テストの並列化によって処理時間を短縮するというのがここからの内容だ。

レガシーなPerlのテストを大量に実行するための戦略は

テストの並列化によってテストを同時実行できるようになり、Pub/Subを組み合わせて通知もシンプルにシステム化が可能になり、テストも細分化することで当初の目的であるテストをすべて実行することが可能になったという。しかしコストがかさみ過ぎるという問題が発生したというのがこの後のトピックだ。

テストは全部実行できるようにはなったが、コストという次の問題が発生

そのためにCloud Buildの内部で実行されているDockerの動作パラメータを変更することで、処理時間を短縮することができたと説明。ここではCPUを固定することとコンテナへのCPU割り当ての重みを変更することで、アプリケーションとともに実行されるMySQLなどの処理時間を短縮することが可能になったことを解説した。他にコンテナのネットワーク設定についても触れている。

CPUのピンニングとコンテナに対するCPU割り当てウェイトを変更

ここまでの進捗として、Perlのテストについてだけはまだチューニングの余地があるとしてそれ以外の項目はすでにCloud Buildの上で実装されていることを説明。最後にまとめとしてCloud BuildとともにGitHub AppとCloud Functionsを使ったこと、skip ciへの対処、Perlの大量なテストを回す仕組み、チューニングなどについて解説したと総括した。またCloud Buildはそれ単体で完結するサービスではなく、Cloud FunctionsやCloud Pub/Subなどと組み合わせることで必要な機能を実装できることを意識したほうが良いと説明した。

最後にテストの実行について、並列化すれば良いのではなく何がボトルネックなのかを把握するためには、既存のシステムの計測をちゃんとやっておく必要があること、その上で新しいシステムでの計測値との比較を行って勘ではなく科学的に原因を追及することの重要性を強調した。

skip ciについては、どうしてそれがMirrativにおいて発生したのか、ビルドを行わないという方法が各種CIツールで存在していることはそれなりの使い方があるということだろうが、そこの部分について説明も聞いてみたかったと感じた。またテスト実行のチューニングについてはCPU、ネットワークだけについても触れているが、他の要因についての考察があれば、より参考になったのではないだろうか。

ちなみにskip ciについてはAzure pipelineなどでも話題になっている。

●参考：Skip build if there's [skip ci] in the commit message.