GitlabがAzureからGCPへ移行した際のノウハウ

オンプレからクラウドに移行したり、逆にクラウドからオンプレに戻す話は聞くが、なかなか別のクラウドに移行する話を聞く機会は少ない。

GitLab’s journey from Azure to GCP

Our SaaS infrastructure for GitLab.com was not ready for mission-critical workloads, error rates were just too high, and availability was too low. To address these challenges, we decided to migrate from Azure to Google Cloud Platform (GCP) and document the journey publicly, end to end. A lot has happened since we first talked about moving to GCP, and we’re excited to share the results.

インフラがミッション・クリティカルでなくエラー率も高すぎ、可用性も低すぎるからAzureからGCPに移行した。ここまで書いちゃっていいのか心配になる。

It became apparent there were problems with this approach as we went along:
- The changes we needed to make to the application to allow it to become fully cloud native were extensive and required major work.
- The timeframes of the GCP migration and cloud native projects wouldn’t allow us to carry them out simultaneously.
We ultimately decided it would be better to postpone the move to Kubernetes until after migration to GCP.

Kubernetesへの移行とGCPの移行が同時に走っていて、最終的にはGCPに移行してからKubernetesに移行することに決めたようだ。

We went to the next iteration and decided to use Omnibus to provision the new environment. We also migrated all file artifacts, including CI Artifacts, Traces (CI log files), file attachments, LFS objects and other file uploads to Google Cloud Storage (GCS), moving about 200TB of data off our Azure-based file servers into GCS.

OmnibusというのはGitlab自身が作ったパッケージ・インストール用のツール。これを今回のプロジェクトでも使っている。ざっと200TBのファイルをAzureからGCPに移行した。思ったより小さいかもしれない。

The merge requests were thoroughly reviewed before being approved by the team and through this very tight, iterative feedback loop, the checklist grew to cover every possible scenario we experienced. In the beginning, things almost never went according to plan, but with each iteration, we got better. In the end, there were over 140 changes in that document before we felt confident enough to move forward with the failover.

作業は徹底的にレビューされ、厳格に遂行され、最初は計画通りにいかなかったが繰り返すたびによくなった。ドキュメントには140もの変更が加えられた。なんか数字だけ聞くと、ものすごく大規模という感じはしないが、会社の屋台骨を支える作業だけに緊張感も高かったのだろう。

This Pingdom graph shows the number of errors we saw per day, first in Azure and then in GCP. The average for the pre-migration period was 8.2 errors per day, while post-migration it’s down to just one error a day.

前に取り上げたこともあるPingdomのデータによるとエラー率が大幅に下がっていることがわかる。別の表でもavailabilityが99.61%から99.88%に改善された。さらにRedditで安定性が増したというスレッドが立った。

個人的には、監視が適切に設計されていて、土台となるIaaSが変わっても全く同じ指標でモニタリングできているのは素晴らしいと思った。クラウドの影に隠れがちかもしれないが、モニタリングも大きな技術革新だろう。