GitLab.comは先頃、AzureからGoogle Cloud Platform(GCP)に移行し、最低のエラー率と最高の可用性を必要とするミッションクリティカルなワークロードにより適したものになった。大きなダウンタイムを起こさずにこれを実現する上で、中核となったアイデアは、GitLabをミラーリングすることだった。
GitLabがGCPへの移行を決定した理由のひとつは、パフォーマンスと一貫性の向上にあった。加えて、GCPがKubernetesをサポートしていたことも、もうひとつの説得力のある理由だった、とGitLabのChrissie Buchanan氏は記している。ただし、GitLabを完全にKubernetes上で動作させるプロジェクトは、移行の完了後に延期されている。
GitLabチームがすぐに気付いたのは、GitLab.comをシャットダウンして、AzureからGCPにすべてのデータをコピーし、新しいサーバを示すようにDNSを変更し、サービスを再開する、という単純なアプローチが実行不可能であることだ。事実、約0.5ペタバイトのデータをコピーした上で、すべてのデータが正しく転送されたことを確認するには、膨大な停止時間が必要なことは明らかだ。
そのため、GitLabのエンジニアたちは、別の方法を採用した。GitLabに新たな機能を追加して、複数の自己同期型GitLabインスタンス間でのミラーリングを可能にする、といものだ。一般的にミラーリングは、クラウド全体にデータを分散する場合に、パフォーマンスと信頼性を向上させる目的で使用される。今回はそれを、Azureベースのサービスをフェールオーバーして、GCPで運用するサービスに置き換えるために使用したのだ。
新機能はGeoと呼ばれ、GitLabのすべてのデータを、メインサービスを停止することなく移行可能にした。すべてのデータが転送されると、GitLabのエンジニアたちは、AzureからGCP環境にフェールオーバして、後者を新たなプライマリにする、という手順を開始した。この手順は非常に微妙で、正しく実行するには、修正と試行の繰り返しによる長いプロセスが必要だった。
同社のアライアンス担当副社長のBrandon Jung氏と、インフラストラクチャ担当スタッフエンジニアであるAndrew Newdigate氏に話を聞いた。
あなた方の説明によれば、今回の移行プロセスは、ミラーリングの利用が鍵である点に気付いた後は、最後のフェールオーバステップを除けば非常に簡単だった、ということですが、その中で発見した困難な点と、それをどのように解決していったのか、説明して頂けますか？
Andrew: ひとつの例です。小さな問題なのですが、長く見逃されていました。
GitLabでは、ほぼすべてのワークフローにGitLab.comを使用しています。フェールオーバプロセスも同じく、GitLab.com上で、イシューテンプレートとして、マークダウンで実装されていました。
私たちはステージングインスタンスに対してフェイルオーバを実施していましたが、ワークフローが私たちのプロダクションインスタンスであるGitLab.comで実行されていたので、ステージングフェイルオーバ時には必ず利用可能でした。
実際にフェイルオーバが発生した時にはGitLab.comはダウンしているので、ワークフローに使用することはできないはずだ、と誰かが指摘したのは、移行プロセスの終盤でした。
後から考えれば、極めて当然の問題だったのですが、どういうわけか私たちは、それを見逃していました、おそらくは、自分たちのプロダクトを使うことに慣れ過ぎていたのでしょう。
解決策は簡単でした。GitLabのプッシュミラーリング機能を使用して、マイグレーションプロジェクトのレプリカを別の、社内的なGitLabインスタンスで管理するようにしたのです。GitLab.comに加えられた変更は、すべてミラーに複製されます。フェイルオーバ中は運用版ではなく、そちらのインスタンスを使用するのです。
GitLab.comは、日々のエラー率と全体的なサービス可用性の両面で、大幅な改善のあったことを報告しています。GCPへの移行がそのような改善を実現したという事実を、どのように説明しますか？
Brandon: GCPの一貫性のあるネットワーキングが、APIエンドポイントのパフォーマンスを向上させる重要な部分でした。
Andrew: Brandonが今、ネットワーキングについて話しましたが、これがおもな要因のひとつです。改善が実現した他の理由についても、こちらのブログ記事で説明しています。記事では5つの要因を取り上げていますが、技術的なものばかりではありません。
Geoを使用したことが改善に貢献している、という可能性はありますか？
Andrew: Geoはレプリケーションとオフサイトミラーリングのソリューションです。障害復旧の選択肢としても適していますが、それだけでGitLab.comの可用性向上に役立つものではありません。
実際にフェールオーバの完了時、GitLab.comでは一旦はGeoを無効にしたのですが、数ヶ月前に、オフサイトバックアップソリューションとして改めて有効にしました。データセンタ全体の大規模な機能停止が発生した場合もフェイルオーバしますが、本番トラフィックを直接受信することはありません。
移行プロセスは、簡単に実施できるものではありません。GCPへの移行から、GitLabチームとしては、どのようなことを学びましたか？
Brandon: Microsoft AzureからGoogle Cloudへの移行が成功したのは、当社の持つ開発指向の文化と、オープンソースへの注力によるものです。
Brandon: Google Cloud Platformに移行して、Kubernetesを簡単に導入する手段をユーザに提供することで、GitLabのパフォーマンス、可用性、カスタマーサービスが向上しました。
Andrew: GCP移行プロジェクトは、GitLabがこれまでに実施した最大級のエンジニアリングプロジェクトでした。エンジニアリング(Geo、CI、計画)、QAチーム、インフラストラクチャ、マーケティング、サポートなど、組織全体にわたる複数のチーム間の調整が必要でした。複数の作業ストリームを調整しながら、デリバリを行う必要があったのです。GitLabには、私たちのリモートオンリーの文化に非常に適した、明確で成熟したエンジニアリング・デリバリプロセスがありましたが、これらのプロセスを適応させ、拡張することで、全社規模のプロジェクトをタイムリーかつ安全に実現する必要がありました。プロジェクトの展開には(プロダクトの)GitLabを自社利用していたので、大規模なマルチチームプロジェクトで運用するために改善の可能性がある分野については、フィードバックとして製品マネージャに提供することができました。当社のプロダクト管理チームは非常に応答が早く、現在のフィードバックの多くは現在製品に組み込まれています。
GitLabによるGCPへの移行に関して、詳細を知りたい場合は、上記のブログ投稿チェックをしてほしい。