GitLab.com、200TB超のデータとともにAzureからGCPへ移行完了。三度の計画停止による予行演習を繰り返し、移行手順も公開

ソースコード管理サービスを提供するGitLab.comは、GitHubの競合として見なされています。そのため、今年の6月にマイクロソフトがGitHubを買収するとの報道の際には、大手企業の傘下にない独立したGitサービスの提供元として突如として注目度が上昇していました。

参考：GitLabへのインポートが普段の10倍に急増、GitHubの買収報道で

その同じ6月、GitLab.comはこれまで同社のサービスを提供する基盤として利用してきたMicrosoft Azureから、Google Cloud Platformへ移行することを発表します。

I wrote a post about @gitlab's project to migrate our SAAS product from Azure to @GCPcloud https://t.co/xxh75NwKf5

— Andrew Newdigate (@suprememoocow) 2018年6月25日

GitHubがマイクロソフトに買収されるという発表とあまりに近いタイミングでこの移行計画が発表されたため、GitHubの買収によって競合となるマイクロソフトから距離を置くために移行するのではないかと邪推したくもなります。

しかし、GitLabは移行の理由をKubernetesとの統合を強化するためだと、次のようにブログで説明しています。

We believe Kubernetes is the future. It's a technology that makes reliability at massive scale possible. This is why earlier this year we shipped native integration with Google Kubernetes Engine (GKE) to give GitLab users a simple way to use Kubernetes. Similarly, we've chosen GCP as our cloud provider because of our desire to run GitLab on Kubernetes. Google invented Kubernetes, and GKE has the most robust and mature Kubernetes support. Migrating to GCP is the next step in our plan to make GitLab.com ready for your mission-critical workloads.

私たちはKubernetesこそ未来だと信じています。これは大規模環境で高信頼性を実現するものです。だからこそ、私たちはGitLabユーザーに対してGoogle Kubernetes Engineとのネイティブな統合機能をGitLabユーザーに提供し、Kubernetesを簡単に使えるようにしたのです。
同様に私たちがGCPをクラウド基盤として選択したのも、GitLabをKubernetesで実行しようとしたためです。GoogleはKubernetesの開発者であり、GKEはもっとも堅牢かつ成熟したKubernetesをサポートする基盤です。GCPへの移行はGitLabをミッションクリティカルなワークロードへ対応させる計画の次の一歩なのです。

ミラーリングツールを用いてGCPへ移行

GitLabは、SaaSとして提供しているGitLab.comをどうやってAzureからGCPへ移行するのか、その手順も詳細に説明しています。

基本的な移行ツールは、同社がオープンソースのGitLab向けに提供しているミラーリングツール「GitLab Geo」を用います。

Geoは、あるGitLabサイトを別のサイトへレプリケーションすることでスケーラビリティの向上を実現すると共に、プライマリサイトが落ちたときに自動的にフェイルオーバーによってセカンダリサイトへ切り替えるディザスタリカバリ機能も備えています。

基本的にはこれを用いてAzureからGCPへ移行するわけです。

ただしGitLab.comには200TBのGitデータと、PostgreSQLのデータベースに2TBのデータなどがあり、この膨大なデータを移行しなければならないために同社はデータの転送テストや、移行のリハーサルをなんども繰り返しています。

Once or twice a week, several teams, including Geo, Production, and Quality, get together to jump onto a video call and conduct a rehearsal of the failover in our staging environment.

週に1度か2度、Geoチーム、本番チーム、品質管理チームなどのいくつかがビデオ会議を行い、ステージング環境でのフェイルオーバーのリハーサルを試した。

これによってGeoのバグだしや手順の確認などを行ったそうです。

多くの読者がご記憶かもしれませんが、GitLabは昨年、2017年2月に本番データベースを喪失するという大規模な障害を起こしています。おそらく同社は、こうした問題を二度と起こさないように非常に慎重に手順を確認したのではないでしょうか。

参考：GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット

予行演習を繰り返す

当初の予定では7月28日が移行日でしたが、その後に移行日が8月11日に変更になりました。

実際の移行までに次のように3回ほどGitLabのサービスを計画停止し、リハーサルを行うこともあわせて発表しています。SaaSにおけるクラウド基盤の移行は実際にどう行われたのか、それに至る下記の計画は興味深いところです。

一度目の計画停止は7月21日に5分程度。予行演習（Dry Run）。

Maintenance window - Dry run - Saturday, July 21 at 13:00 UTC
As a further update to our testing, we are planning to take a short maintenance window this weekend on Saturday, July 21 at 13:00 UTC to do final readiness checks. This maintenance window should last one hour.

この予行演習の2日後の7月23日、いくつかの問題を修正するため移行計画が変更され、当初の移行日だった7月28日が8月11日に。

2018-07-23 UDPATE: Here are the finding from the maintenance window. We've decided to push our target date from July 28th to August 11th to comfortably address several issues. We will likely do a small maintenance window on Saturday, July 28th, and another full practice on Saturday, August 4th.

二度目の計画停止は7月28日。ここも約5分程度。修正された内容の確認と、Chefの実行確認など。

Maintenance window - Short test - Saturday, July 28 at 13:00 UTC
We will perform a short test of approximately 5 minutes. This will help us verify some of our fixes to make sure our Chef runs work correctly with GitLab.com inaccessible.

三度目の計画停止は8月4日。あらためて予行演習を行い、変更箇所の確認など。

Maintenance window - Dry run - Saturday, August 4 at 13:00 UTC
We will repeat the dry run exercise again to have a chance to verify our changes to the switchover plan.

そして8月11日に移行本番。予定では2時間で移行が完了予定。

Maintenance window - Actual switchover - Saturday, July 28 August 11 at 10:00 UTC
On the day of the migration, we are planning to start at 10:00 UTC. The time window for GitLab.com to be in maintenance is currently planned to be two hours. Should any times for this change, we will be updating on the channels listed below. When this window is completed GitLab.com will be running out of GCP.

移行本番の手順

移行本番の日。Twitterでは計画停止の予告がポストされます。

reminder - https://t.co/r11UmmDLDE will be undergoing 2 hours maintenance (https://t.co/tv9buxNJ1U) for our migration to GCP, from 2018-08-11 10:00 to 2018-08-11 12:00 UTC. Follow @gitlabstatus for more details. https://t.co/IePUoK3zp3

— GitLab.com Status (@gitlabstatus) 2018年8月11日

2018年8月11日19時1分（日本時間）。ついに移行が開始されました。以下、GitLabのツイートをもとに時系列で移行作業を追っていきましょう。

GCP Switchover maintenance is starting. Working doc: https://t.co/CCQTrowigB https://t.co/FRkUs3EQOU

— GitLab.com Status (@gitlabstatus) 2018年8月11日

ツイートのリンク先であるGoogle Docには、どこまで移行作業が進行しているのかがリアルタイムに書き込まれていきます。GitLabは、PostgreSQLの本番データを失ったときも復旧作業をYouTubeで公開していました。オープンさが徹底していますね。

19時20分。GitLabへのアクセスを停止。この時点までのデータをGCPへ同期。

19時41分。AzureからGCPへの同期を確認。GCP側のGitLabを起動するためのコンフィグレーションを実行。

20時02分。GCP側での内部QAをまもなく開始。

20時23分。コンフィグレーションがまもなく完了。

20時43分。内部QAが進行中。まもなく最終確認。計画停止が終わるまでさらに30分。

21時2分。内部QAの第一フェーズが終了。起動前のコンフィグレーションを完了中。最中確認中。

21時29分。GCPへの移行のための計画停止はほぼ完了。全システムの最終チェック中。

22時01分。計画停止が終了し、GCPへの移行が完了。継続して稼働状況をモニタリング。

Our maintenance window is complete. https://t.co/r11Ummmaf4 is running from GCP! We will continue to monitor systems over the weekend. https://t.co/FRkUs3EQOU

— GitLab.com Status (@gitlabstatus) 2018年8月11日

GitLabは万が一なにか問題があったときのために、GCPへの移行を中止してAzureへフェールバックする計画も用意していましたが、幸いなことに特に問題は発生せず、GitLabのAzureからGCPへの移行は無事に完了しています。