CNDT 2022、ArgoCDとGitHub Actionsの導入でリリース時間を1/4に削減した事例を紹介

CNDT 2022から、Chatwork株式会社のSREである坂本諒氏によるEKS上のCI/CD環境においてリリース時間を削減した事例に関するセッションを紹介する。

●動画：ArgoCDとGitHub Actions Self Hosted Runnerを使ってリリース時間を1/4にした話

プレゼンテーションを行う坂本氏

まずChatworkのKubernetesの利用について概要を説明。2016年末から新規のアプリケーションに限定してKubernetes上の実装が始まり、2020年にはモノリシックなアプリケーションについてもAWSが提供するマネージドKubernetesサービスのEKS上への移行が終わったと語った。2021年にはほとんどのアプリケーションがEKS上に移行されている。規模感は利用しているノード数が約160、Pod数が600から2500くらいというところだ。odの約90％はAWSのSpot Instanceを使ってコスト削減を図っていると説明した。今回の話はこのうち200くらいPodに関連する内容であるという。

2021年にほぼ移行が終わったKubernetes上のChatworkのアプリケーション

ここからChatworkがリリースに使うパッケージマネージャーのHelmとHelmfileについて簡単な説明を行い、具体的にHelmfileで記述する例なども示しながら環境ごとに定義ファイルを生成する仕組みなどについて説明を行った。CIについてはCircleCI、CDについては以前から利用していたという理由でJenkinsを使っていたと解説した。

HelmとHelmfileの説明。CIはCircleCI、CDはJenkinsを利用していた

ただいくつかのアプリケーションについてはすでにArgo CDを使っていたと説明したが、EKSに移行した後もJenkinsについては開発チームの新しいツールに慣れるという負担を減らすという意味で継続して利用していたという。

アプリケーションのデプロイにはJenkins、移行後はArgo CD

2021年にはほぼすべてのアプリケーションがEKSに移行しており、この時点でJenkinsを使い続ける理由はなくなったと説明した。

Jenkins利用のイメージ。アプリケーションのリポジトリとKubernetesの設定ファイルのリポジトリが存在している

しかしながらJenkinsについてはアップデートを行うと壊れるという事例が発生したこと、スクリプトの修正でバグが発生しがちだったことなどからいわゆる「秘伝のタレ」問題を起こしていたことがうかがえる。

すでにArgo CDを導入していたことなどから、JenkinsからArgo CDへの移行について移行時の混乱を避けること、開発チームに「Jenkinsのほうが良かった」と思わせないこと、JenkinsでもArgo CDでも並列して実行できるようにすることなどを注意点として移行作業が行われたと説明した。

JenkinsからArgo CDに移行した際の注意点

当初のCI/CDの概要を説明したスライドでは、アプリケーションのリポジトリ、Kubernetes構成のリポジトリ、Helmチャートのためのリポジトリなどを用いてGitOpsを目指して構成されていることがわかる。

当時のCI/CD構成。アプリの変更からGitHub Actionsが起動されパイプラインを実行

このフロー自体はごく常識的な構成だが、JenkinsからArgo CDに移行した効果は大きかったようで、メリットとして並列実行できるようになったことでリリース時間が削減されたこと、GUIでCI/CDの結果が確認できることなどを挙げた。それまではJenkinsのターミナルのログを見るしかなく、SREにとっても開発チームにとっても負荷が高かったという。

実際の移行については、講習会やリリースを実演する実演会などを開催して社内啓蒙を行ったと説明。結果的にJenkinsに戻ったアプリケーションはなかったということで、SREチームが思ったように進行したという。

ここからテスト環境においてCDを実行するSelf Hosted Runnerに関する説明に移った。

「素晴らしい仕組み」と絶賛するSelf Hosted Runnerを導入した背景を説明

SaaSで提供されるGitHub ActionsからEKS上のKubernetesに直接アクセスさせたくなかったことが理由であると説明し、任意の場所でGitHub Actionsのジョブを実行可能にするSelf Hosted Runnerを発見したことが大きな転機となったと説明。

またSelf Hosted RunnerをKubernetes上で実行するための仕組みであるActions Runner Controllerについても簡単に解説を行った。

Actions Runner Controllerの説明

最終的なCI/CDのフローは次のスライドで説明されているが、Kubernetesクラスター上で実行されるSelf Hosted RunnerがArgo CDを起動してCDパイプラインが実行されることなどを解説した。

Self Hosted Runnerを使ったCI/CDパイプラインの進化

リリースの改善点として、テスト環境においては手順を省くことでより高速化が行われたこと、ソースコード修正のプルリクエストとコメントの併用によりデプロイまで一気にできるようになったことなどを挙げた。

テスト環境のリリースフローの改善点

ここまでで開発チームにとってみれば、大きな改善が行われたとして100％満足していること、具体的には、手間が減った、画面がJenkinsの場合よりも見やすい、リリースが安定した、時間が短縮されデプロイ回数が増えたことなどを挙げて説明した。

最後にまとめとして、最大30分かかっていたリリース作業が8分程度まで短縮したこと、高い安定性、品質の向上、テスト環境のリリース改善などを挙げた。しかしながらGitHub ActionsがKubernetesクラスターにパッチを当てることで環境を変更する方法では、GitOpsとしての設計からは外れてしまうこと、Kubernetesの構成ファイルのリポジトリへの同期はマニュアルで行われていることなどを挙げて改善の余地はまだあると説明し、これからもSREとしての仕事が続くことをコメントしてセッションを終えた。

なおGitHub ActionsのSelf Hosted Runnerについては以下の公式ドキュメントを参考にされたい。

●参考：セルフホステッド ランナーの概要