<style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style>

Circle CIをPerformance Planに移行したらテスト時間が半分になって最高だった

みんなのウェディングのインフラエンジニア横山です。 今回は、Circle CIをPerformance Planに移行したところ、テスト時間が半減して最高だった件について書きます。

みんなのウェディングのCI/CD環境について

Performance Planへの移行前は、みんなのウェディングのCI/CD環境は以下のような構成でした。

ポイントはマスターマージの際にAWS Codeシリーズを利用して、テスト&ステージング環境へのデプロイを行っている点です。
以前は、マスターマージ後のテスト&ステージングデプロイもCircle CIで行っていました。
しかし、Circle CIではトピックブランチのテストも行われているので、マスターマージ後のテスト&ステージングデプロイがそちらと同じCI待ち行列に入ってしまうという問題がありました。
これによりトピックブランチのテストが多いとステージングデプロイに時間がかかり、延いては、本番反映にも時間がかかることがありました。
このような状況を回避するために、マスターマージ後のテスト&ステージングデプロイの実行をCircle CIからAWS Codeシリーズに分離していました。

Performance Planについて

Circle CIのPerformance Planについては以下のブログで知りました。
Circle CIのPerformance Planが控え目に言って最高という話

Perforamce Planでは通常のプランと異なり、コンテナの「利用数」ではなく「利用時間」「アクティブユーザ数」に対して課金されるようになります。
つまり、コンテナは何個でも使い放題!ということです。

こちらのブログを見た後、早速Circle CIのサポートに連絡しました。 やりとりしていく中で、サポートの方には以下のような対応をしていただけました。

  • トライアルとして2週間、200コンテナを付与して擬似的なPerformance Planの体験をさせてくれた。
  • 前月の利用状況からコスト試算してくれた

トライアルとコスト試算から見えてきた、弊社における導入の「メリット」「デメリット」について以下に書きます。

Performance Planのメリット

並列コンテナ数が無制限

コンテナ使い放題なので、並列実行するコンテナ数をいくらでも増やせます。
弊社の場合は、4並列 -> 12 並列にすることで、テスト時間を6分 -> 3分に半減させることができました。
並列コンテナ数が3倍ですがテスト時間が3分の1ではないのは、テスト用コンテナイメージのダウンロードなどにかかる時間は並列度を上げても短縮できないためです。

CI待ち行列が発生しない

コンテナ使い放題なので、トピックブランチのテストが増えてもCI待ち行列が発生しません。
CI待ち行列が発生しないので、前述した、マスターマージ後のテスト&ステージングデプロイのAWS Codeシリーズでの実行をやめて、全てをCircle CIで行うようにしました。

Performance Planのデメリット

若干のコストアップ

弊社の従来の契約では8コンテナ($400)を購入していました。利用している状況に対して、試算していただいた金額は$650となっており、約$250ほどのコストアップとなりました。
現在の利用状況にもよりますが、多くのケースではプラン変更と共にコストアップするのではないでしょうか。 利用の際はサポートの方にコスト試算をお願いし、許容できる範囲か確認することをお勧めします。

みんなのウェディングのCI/CD環境について(移行後)

トライアルを経た後、弊社では、デメリットよりメリットの方が大きいと考え移行することにしました。
移行後のみんなのウェディングのCI/CD環境は、以下のような構成になりました。

ポイントは以下の2点です。

  • マスターマージ後のテストをCodeBuild -> Circle CIに変更
  • SQS+Lambdaを使うことでマスターマージ後のテストとステージング環境へのデプロイを分離

2つめのポイントである、SQS+Lambdaを導入した理由は、Circle CIから直接CodeDeployを実行すると、マージのタイミングが近い場合に以下のような問題が発生するためです。

  • CodeDeployの実行が重なってしまう。
  • マージ順にテストが終わらず、新しいソースをデプロイした後に古いソースがデプロイされて上書きされてしまう恐れがある。

これらの対策として、SQS+Lambdaを使ってテストとステージング環境へのデプロイを分離しています。
Lambdaは10分に1回実行されるようになっており、SQSに溜まっているコミットIDとGitHubから取得したコミットIDを比較し、最も新しいソースをCodeDeployでステージング環境にデプロイするようにしています。
これにより上述した問題を極力回避できるようにしています。

まとめ

Circle CIのPerformance Planに移行することで快適なCI/CD環境を得ることができました。
すでにCircle CIを利用されている方はサポートに問い合わせをして、トライアル利用・コスト試算だけでもしてみることをお勧めします。