5時間で800のマイクロサービスをクラウドに移行しました

9 月 16 日の夕方、FINN の運用環境をローカル データ センターから Google Cloud Platform (GCP) に移行しました。これは、800 を超えるアプリケーション、145 のデータベース、16 TB のデータで構成される複雑な分散システムによってサポートされている、トラフィック量の多い Web サイトを移行することを意味しました。夜間にはダウンタイムの時間枠が計画されていますが、この時間は短いほど良いです。どうやってやるんですか？ぜひこの記事を読み続けてください！

[[346046]]

FINN.no をデータ センターからクラウドに移行することについての社内議論は、何年も前に始まりました。それ以来、私たちはさまざまなクラウド テクノロジーとクラウド プロバイダーを試してきました。 2016 年に Kubernetes をプラットフォームとして選択したとき、私たちの指針は FINN をクラウドで実行することでした。

当社はシステムをクラウドに移行する心構えを長い間整えていましたが、実際にそれを実現するための戦略や計画を立てたことはありませんでした。当社の製品の一部は 1998 年から使用されていたため、移行は困難な作業でした。しかし、データ センターにかかる負担が増大し、より柔軟なソリューションが必要となり、昨年 Sybase を Solaris から Linux に移行した経験から、この計画を真剣に検討する大きな動機が生まれました。

当社は 2019 年 1 月にクラウド プロバイダーの評価を開始しました。候補リストには AWS、Google Cloud、IBM Cloud、Azure が含まれています。私たちは、数多くのワークショップ、会議、電話会議に参加し、サービスを自分たちで管理したり、他のクラウド プロバイダーでサービスをホストしたりするなど、さまざまなオプションを評価しました。そして最終的に、「マルチクラウド」アプローチを採用し、ほとんどのサービスで GCP を第一の選択肢として選択しました。この計画は最終的に2019年8月中旬にシブステッドによって承認されました。

1. 準備

移行は差し迫っていたため、FINN を稼働させながら、所有するすべてのものを GCP に移行する計画を立てる必要がありました。私たちは、開発者が時間をかけてサービスを移行できるように、段階的に移行することを決定しました。しかし、時間があっという間に過ぎてしまい、使える時間がどんどん少なくなっていることに気づきます。インフラストラクチャの劣化、既存データセンターの計画的なネットワーク改修、およびリソースの不足により、段階的な移行の成功を予測することは困難でした。世界的なパンデミックにより仕事も困難になった。私たちはいくつかの難しい決断を迫られました。

2020 年 6 月、私たちはより直接的なアプローチを取り、GCP への迅速な切り替えの日付を設定する必要があることに気付きました。私たちは 9 月 15 日を目標日として設定し、FINN 管理チームから FINN.no を一晩シャットダウンする承認を得ました。 7 月には、クラウド移行が FINN の最優先事項として設定されました。つまり、すべてのチームは、計画されている他のタスクに進む前に、担当するクラウド移行関連の作業をすべて完了する必要があるということです。 （リモート）ワークに行く時間です。

段階的な移行を断念し、迅速に切り替えようと決めたとき、私たちの目の前に困難な課題が浮かび上がり始めました。 800 を超えるアプリケーション、145 のデータベース、16 TB を超えるデータ、183 台の仮想マシンを一晩で移動できるプラットフォームを準備する必要がありました。 FINN のインフラストラクチャ チームは長い間クラウド移行の準備をしてきましたが、この決定により、取り組みを再び集中させることができました。今、私たちは優先順位をしっかりとつけ、必要に応じて時間をかけて技術を深​​く探求し、常に目標を明確に保つ必要があります。場合によっては、これは、かつて多くの時間を費やしたソリューションの一部を変更したり、放棄したりすることを意味します。

夏が終わった瞬間から、私たちはこれを成功させるために一生懸命働きました。私たちは、何に時間を費やす必要があるのか​​、何を待たなければならないのか、難しい選択をしなければなりません。しかし、私たちは近道をせず、コードとしてのインフラストラクチャなどの原則に忠実に従うようにしています。移行日が近づき、作業量が増えるにつれて、私たちの自信も高まりました。

このグラフは、切り替え日が近づくにつれて、FINN インフラストラクチャを維持するためのリポジトリの 1 つに対する変更の頻度が増加していることを示しています。

FINN.no への変更は通常、1 日に約 350 回行われます。切り替え前の最後の 24 時間に、「リリース フリーズ」を推奨することを決定しました。これは、ライブ プロダクションの問題やクラウド移行関連の問題に対処しない変更は翌日まで待つ必要があることを意味します。切り替えの前日に、変更頻度は約半分に減り、クラウド プラットフォームの切り替えが始まるわずか数分前に、最後の製品が元のオンプレミス インフラストラクチャにデプロイされました。

2. クラウドプラットフォームの切り替え

9 月 15 日 23:00 に、インフラストラクチャ チームが (オンラインで) 集まり、準備を整えて、カットオーバー前のチェックリストを確認しました。全員が地理的に異なる場所にいるため、詳細なランブックとビデオ会議を利用して共同作業を行っています。 FINN.no への変更は通常、ダウンタイムなしで展開され、サイトのダウンタイムは重大度 1 のインシデントです。しかし、これは普通の火曜日の夜ではありませんでした。深夜に、ユーザーを静的フォールバック ページにリダイレクトした後、FINN.no をシャットダウンしました。 30 分後、ローカル Kubernetes クラスター内のすべてのアプリケーションをシャットダウンしました。

移行中に FINN.no に表示される静的フォールバック ページ

これで、データを移行する準備が整いました。 Kafka は、マイクロサービス アーキテクチャの基盤の 1 つです。 1 日あたり約 20 億のメッセージ (1 秒あたり平均 30,000 件) が Kafka クラスターを通過するため、FINN が適切に機能するにはその安定性が重要です。 Kafka チームは、一時的に「ストレッチ クラスター」構成で実行していた Kafka クラスターを、オンプレミスのデータ センターとクラウド プラットフォームを単一のクラスターとして移行しました。私たちは数週間前にストレッチ クラスター構成を慎重に計画し、実装しました。 Kafka のトピックは切り替えの 1 週間前に GCP ブローカーに複製され、切り替え中は GCP ブローカーがプライマリ ブローカーになりました。

永続的なストレージを必要とするサービスでは、通常、25 個の PostgreSQL クラスターまたは Sybase クラスターのいずれかが使用されます。これらのデータベース クラスターを移行するには、事前に GCP にデータベース レプリカを設定し、切り替えプロセス中にすべてのアプリケーションを停止した後にプライマリ データベースを切り替えました。切り替え当日の午前 1 時 35 分には、Kafka とすべての PostgreSQL および Sybase データベースが GCP で実行されていました。

永続データを移動した後、すべてのアプリケーションを新しい Google Container Engine (GKE) クラスタにデプロイしました。 02:30 までに、800 個のアプリケーション (1500 個を超える Kubernetes ポッド) がすべて GKE にデプロイされました。この時点では、その夜にいくつかの小さな問題と遅延が発生しただけで、社内テストの準備が整っていました。

切り替え当日に向けて、私たちは移行のあらゆる領域の準備とテストを完璧に行い、深夜にテストが始まったときにゴーサインが出たのを見て、インフラストラクチャ チームは非常に安堵しました。プラットフォームのさまざまな部分に対する自己組織化されたテストは、私たちが考えていたよりもさらにうまく機能しました。

すべてのチームの良好なチームワークにより、いくつかのアプリケーションのデプロイメント、破損したデータベース テーブル、その他の小さな問題が修正され、クラウド プラットフォームの FINN は大きな障害もなく 04:43 に稼働を開始しました。

FINN.no がクラウド プラットフォームで 04:43 に有効化された後の、ロード バランサーを通過するリクエストのレート増加曲線

クラウドへの切り替えに成功したことを誇りに思います。

FINN Technology の優秀な人材がいなければ、移行は不可能だったでしょう。私たちは組織のあらゆる部分から賛同を得て、行動の呼びかけがあったときには、全員が飛び込んで自分の役割を果たしました。準備として、開発チームはファイアウォール、ネットワーク ルーティング、ロード バランサに懸命に取り組んでおり、新しい GCP インフラストラクチャの問題を発見し、インフラストラクチャ チームと協力して解決に取り組んでいます。切り替え日の数週間前には、勤務時間中に開発環境で切り替え訓練も実施しました。この「ドライ ラン」により、指定されたダウンタイム ウィンドウ内でカットオーバーを実行できるという自信が得られ、ツールの問題を特定して修正するのに役立ち、本番環境のカットオーバーのランブックを改良するのに非常に役立ちました。これら 2 つの方法は、リスクを許容できるレベルまで低減するのに役立ちます。

移行には厳しい期限があったため、リフト アンド シフト アプローチを使用して多くのシステムを移行する必要がありました。クラウドに少し慣れてきたら、インフラストラクチャのこれらの部分もさらにクラウドネイティブにしていきたいと考えています。