GitLabがKubernetesをさまざまな課題に直面しながら1年間運用して学んだこと

コンテナオーケストレーションシステムのKubernetesは、2014年にリリースされてからさまざまなウェブサービスのインフラとして活用されてきました。GitリポジトリマネージャーのGitLabもアプリケーションのデプロイやスケーリングの観点から、2019年より自社のウェブサービス「GitLab.com」のインフラをKubernetesへと移行するプロジェクトを進めており、その移行過程で学んだことをブログで公開しています。

What we learned after a year of GitLab.com on Kubernetes | GitLab
https://about.gitlab.com/blog/2020/09/16/year-of-kubernetes/

GitLabのウェブサービス「GitLab.com」はその立ち上げ当初から、クラウドの仮想マシン(VM)上で構成管理ツールのChefとGitLab自身が提供しているセルフマネージド向けLinuxパッケージを用いて運用されていたとのこと。GitLabを自分でホスティングするユーザーの不便や喜びを知るために、GitLab.comのバージョンアップはCIパイプラインによって各サーバーに展開するといった、一般のユーザーと同じような方法を採用していました。しかし、サービスが成長するにつれて、スケーリングおよびデプロイに対する要求を満たせなくなったため、GitLabはKubernetesへの移行を決めたそうです。

記事作成時点では、GitLab.comは単一リージョン内のGKCクラスタ上で動作しているとのこと。移行に際して障害となっていたNFSへの高い依存度を解決した上で、サービスへのトラフィックを「ウェブサイト」「API」「SSH／HTTPSによるgitのリモートリポジトリ」「レジストリ」といった機能別にルーティングし、デプロイにはGitLabが提供しているHelm chartを利用しています。GitLab.com自体の管理はGitLab.com上では行っていませんが、「gitlab-com」「gitlab-helmfiles」「gitlab-com-infrastructure」の3つのリポジトリにコードがミラーリングされています。

GitLabがKubernetesを1年間運用して学んだことは主に以下の5つであるとのこと。

◆1：ゾーン間通信にるコスト増
GCPの各リージョンはいくつかのデータセンターの集合である「アベイラビリティーゾーン(AZ)」で構成されており、AZ間の通信は課金対象となっています。従来の構成ではVMのローカルホスト内で行われていた課金対象でない通信が、Kubernetesを利用すると複数のAZで起動しているPod間で行われるため、課金対象となることがあるとのこと。特にGitLabではGitリポジトリだけで下りのトラフィック量が100TBに及ぶため、どのトラフィックが課金対象となるかは重要な要素です。Podが複数のAZで生成されるリージョンクラスタは複数のゾーンを利用するため可用性に優れていますが、GitLabではコスト削減のため、リージョンクラスタから単一ゾーンクラスタに移行することを検討しているそうです。

◆2：Podのrequestsとlimitsの調整
GitLabがKubernetes移行時に経験した最初の課題は、ノードのメモリ制約によって大量のPodが別ノードに追い出されてしまうことでした。時間経過とともにメモリ使用量が増加するアプリケーションでは、requestsの値を低く、limitsの値を高く設定していると、Pod生成段階では十分なリソースを確保できていても、時間が経過するにつれてノードのメモリ不足に陥ることがあります。これを避けるためには、requests値を高く、limits値を低く設定し、Podに割り当てるリソースに余裕を持たせる必要があるとのこと。なお、requestsとlimitsについては、以下の記事を読むとよくわかります。

KubernetesのCPU limits設定時における「不要なスロットリング」を回避する方法とは？ - GIGAZINE

◆3：メトリクス収集とロギング
Kubernetesを運用した1年間で起こったインフラ部門の大きな変化は、サービスレベル目標(SLO)の監視と管理方法の改善でした。Kubernetesへの移行はVMによる従来インフラでのサービス提供も行いながら並行して実行されたため、VMによるインフラとKubernetesによるインフラで同じリクエストを管理し、同じダッシュボードとログ収集システムで一貫性を維持することが重要だったとのこと。

◆4：新インフラへのトラフィック切り替え
GitLabには「Canary」と呼ばれる開発段階があり、新機能や変更点などが最初に製品としてデプロイされる段階です。Canary段階のGitLabは主にGitLab内部のプロジェクトによって利用され、SLOを満たしているかどうかの確認が行われます。Kubernetesへのインフラ移行においても、まずは内部プロジェクトからのトラフィックのみKubernetesクラスタへと切り替え、動作を確認した上で徐々に他のトラフィックも切り替えていったとのこと。新旧のインフラ間でトラフィックを移動させた場合、最初の数日間は容易に環境をロールバックできるようにしておくことが大切だと語られています。

◆5：起動に時間がかかるPod
ジョブを迅速に処理し、迅速にスケーリングする必要がある処理をKubernetesに移行し始めたとき、ジョブスケジューラのSidekiqサービスのPod起動時間が2分もかかることが課題になっていました。KubernetesにはPodの負荷に応じてPod数をスケーリングする「Horizontal Pod Autoscaler(HPA)」という機能が存在していますが、このHPAはトラフィック増に対してはうまく機能する一方、特に必要とするリソースが均等でないPodの場合は、スケーリングする前にCPUリソースを消費し尽くしてしまうことがあるとのこと。現在はPod数に余裕を持たせ、SLOに注意しつつ後からスケールダウンを行うことで、SidekiqサービスのPod起動時間は平均約40秒まで改善されたそうです。

GitLabではKubernetesへの移行後、アプリケーションのデプロイやスケーリング、リソース割り当ての面で多くの恩恵を受けているとのこと。公式のHelm chartの改善を通して、自分でGitLabをホスティングしている一般ユーザーにも利益をもたらせると語っています。