Google Cloud Platformへの移行（Google Cloud Platform-GCP）

[2/2]

[パート1/2]

どうやってやったの

アプリケーションのパフォーマンスを向上させるためにGCPに切り替えることを決定しました-規模を拡大しますが、大きなコストはかかりません。 プロセス全体に2か月以上かかりました。 この問題を解決するために、特別なエンジニアグループを編成しました。

この出版物では、選択されたアプローチとその実装、および主な目標をどのように達成したかについて話します。このプロセスを可能な限りスムーズに実装し、ユーザーサービスの品質を損なうことなくインフラストラクチャ全体をGoogle Cloud Platformに移行します。

計画中

1. 可能な各ステップを識別する詳細なチェックリストが用意されています。 シーケンスを説明するフローチャートが作成されました。
2. リセットプランが開発されており、これがあれば、使用できます。

いくつかのブレーンストーミングセッション-そして、アクティブ/アクティブスキームを実装するための最も理解しやすく最も簡単なアプローチを特定しました。 これは、少数のユーザーが1つのクラウドに配置され、残りのユーザーが別のクラウドに配置されるという事実に基づいています。 ただし、このアプローチは、特にクライアント側（DNS管理に関連する）で問題を引き起こし、データベース複製の遅延につながりました。 このため、安全に実装することはほとんど不可能でした。 明らかな方法では必要な解決策が得られなかったため、特別な戦略を開発する必要がありました。

依存関係図と運用上の安全要件に基づいて、インフラストラクチャサービスを9つのモジュールに分割しました。

（ホスティングインフラストラクチャを展開するための基本モジュール）

各インフラストラクチャグループは、共通の内部および外部サービスを管理しました。

⊹ インフラストラクチャメッセージングサービス ：MQTT、HTTP、Thrift、Gunicornサーバー、キューイングモジュール、非同期クライアント、Jettyサーバー、Kafkaクラスター。

⊹ データウェアハウスサービス ：分散クラスターMongoDB、Redis、Cassandra、Hbase、MySQL、およびMongoDB。

⊹ インフラストラクチャ分析サービス ：Kafkaクラスター、データウェアハウスクラスター（HDFS、HIVE）。

重要な日の準備：

✓各サービスのGCPに切り替えるための詳細な計画：シーケンス、データウェアハウス、リセットの計画。

✓GCPでのプロジェクト間のネットワークインタラクション（共有仮想プライベートクラウドVPC [XPN]）により、インフラストラクチャのさまざまな部分を分離し、管理を最適化し、セキュリティと接続性を改善します。

✓GCPと実行中の仮想プライベートクラウド（VPC）の間の複数のVPNトンネルにより、複製中のネットワーク上での大量データの転送を簡素化し、その後の並列システムの展開を可能にします。

✓Chefシステムを使用して、スタック全体のインストールと構成を自動化します。

✓展開、監視、ログ記録などのためのスクリプトと自動化ツール

✓システムストリームに必要なすべてのサブネットと管理されたファイアウォールルールを構成します。

✓すべてのストレージシステムの複数のデータセンター（マルチDC）でのレプリケーション。

✓ロードバランサー（GLB / ILB）およびマネージドインスタンスグループ（MIG）を構成します。

✓オブジェクトストレージコンテナーをチェックポイント付きのGCP Cloud Storageに転送するためのスクリプトとコード。

すぐに、必要な前提条件をすべて満たし、インフラストラクチャをGCPプラットフォームに移行するための要素のチェックリストを作成しました。 多数の議論を行い、サービスの数とその依存関係図を検討した後、3晩でクラウドインフラストラクチャをGCPに移行して、すべてのサーバー側およびデータストレージサービスをカバーすることにしました。

移行

ロードバランサーの転送戦略：

以前使用していたHAProxy管理クラスターをグローバルロードバランサーに置き換えて、毎日数千万のアクティブなユーザー接続を処理しました。

⊹ ステージ1：

• MIGは、すべてのトラフィックを既存のクラウドのMQTT IPアドレスに転送するためのパケット転送ルールで作成されています。
• サーバーパーツとしてMIGを使用してSSLおよびTCPプロキシバランサーが作成されました。
• MIGの場合、サーバーパーツとしてMQTTサーバーを使用してHAProxyが起動されます。
• DNSでは、重み付き重み付きルーティングポリシーにより、外部GLB IPアドレスが追加されました。

ユーザー接続は、パフォーマンスを追跡しながら徐々に展開されます。

⊹ ステップ2：マイルストーンの移行、GCPでのサービスの展開を開始します。

⊹ ステージ3：移行の最終ステージ。すべてのサービスがGCPに転送されます。

（ロードバランサーの転送の段階）

この段階では、すべてが期待どおりに機能しました。 すぐに、係数の重みを考慮して、ルーティングを使用してGCPにいくつかの内部HTTPサービスを展開するときがきました。 すべての指標に厳密に従いました。 計画された移行の前日にトラフィックが徐々に増加し始めたとき、VPNを介したVPC相互作用の遅延（40ミリ秒-100ミリ秒の遅延が記録されましたが、以前は10ミリ秒未満でした）が増加しました。

（2つのVPCが相互作用するときのネットワーク遅延をチェックするスナップショット）

監視により、VPNトンネルを使用する両方のクラウドベースのネットワークチャネルに問題があることが明らかになりました。 VPNトンネルのスループットでさえ、最適な水準に達しませんでした。 この状況は、一部のユーザーサービスに悪影響を及ぼし始めています。 以前に移行したすべてのHTTPサービスをすぐに元の状態に戻しました。 TAMおよびクラウドサービスのサポートチームに連絡し、必要な初期データを提供して、遅延が増大する理由を理解し始めました。 サポートスペシャリストは、2つのクラウドサービスプロバイダー間のクラウドチャネルで最大ネットワーク帯域幅が達成されたという結論に達しました。 したがって、内部システムの転送中のネットワーク遅延の成長。

このインシデントにより、クラウドへの移行が一時停止されました。 クラウドサービスプロバイダーは、帯域幅を十分に速く倍増できませんでした。 したがって、計画段階に戻り、戦略を修正しました。 クラウドインフラストラクチャのGCPへの移行を3泊ではなく1泊で実行することを決定し、サーバー部分とデータストレージのすべてのサービスを計画に含めました。 「X」という時間になると、すべてがスムーズに進みました。ユーザーに気付かれることなく、ワークロードが正常にGoogle Cloudに転送されました。

データベース移行戦略：

リレーショナルDBMS、メモリ内ストレージ、およびNoSQLと低遅延の分散およびスケーラブルなクラスターのために、50を超えるデータベースエンドポイントを転送する必要がありました。 すべてのデータベースのレプリカをGCPに配置しました。 これは、HBaseを除くすべての展開で行われました。

⊹ マスタースレーブレプリケーション： MySQL、Redis、MongoDB、およびMongoSクラスターに実装されています。

マルチマルチDCレプリケーション： Cassandraクラスターに実装されています。

⊹ デュアルクラスター：パラレルクラスターは、GCPでGbase用に構成されています。 既存のデータを移行し、両方のクラスターでデータの一貫性を維持する戦略に従って二重エントリを構成しました。

HBaseの場合、問題はAmbariで設定されていました。 複数のデータセンターにクラスターを配置するときに、たとえばDNS、ラック認識スクリプトなどの問題が発生したため、いくつかの問題が発生しました。

最後の手順（サーバーを移動した後）には、レプリカをメインサーバーに移動し、古いデータベースをシャットダウンすることが含まれていました。 計画どおり、データベース転送の優先度を決定するために、アプリケーションクラスターの必要な構成にZookeeperを使用しました。

アプリケーションサービスの移行戦略

アプリケーションサービスのワークロードを現在のホスティングからGCPクラウドに転送するために、リフトアンドシフトアプローチを使用しました。 アプリケーションサービスごとに、自動スケーリングを使用した管理対象インスタンス（MIG）のグループを作成しました。

詳細な計画に従って、データウェアハウスの順序と依存関係を考慮して、サービスをGCPに移行し始めました。 すべてのメッセージングスタックサービスは、ダウンタイムなしでGCPに移行されました。 はい、いくつかの小さな不具合がありましたが、すぐに対処しました。

午前中、ユーザーアクティビティが増加したため、すべてのダッシュボードとインジケーターを注意深く監視して、問題を迅速に特定しました。 いくつかの問題が実際に発生しましたが、すぐにそれらを排除することができました。 問題の1つは、内部ロードバランサー（ILB）の制限が原因でした。ILBは、最大20,000の同時接続を処理できます。 そして、さらに8倍が必要でした！ したがって、接続管理レイヤーにILBを追加しました。

移行後の最初のピーク負荷では、メッセージングスタックの負荷全体がGCPに転送されるため、すべてのパラメーターを特に慎重に制御しました。 いくつかの小さな不具合がありましたが、すぐに解決しました。 他のサービスを移行するときも、同じアプローチを取りました。

オブジェクトストレージの移行：

オブジェクトストレージサービスは、主に3つの方法で使用します。

personalパーソナルチャットまたはグループチャットに送信されたメディアファイルの保存。 保存期間は、ライフサイクル管理ポリシーによって決定されます。

userユーザープロファイルの画像とサムネイルの保存。

sectionsセクション「履歴」および「タイムライン」および対応するサムネイルからのメディアファイルの保存。

Googleのストレージ転送ツールを使用して、S3からGCSに古いオブジェクトをコピーしました。 また、カスタムのKafkaベースのMIGを使用して、特別なロジックが必要な場合にオブジェクトをS3からGCSに転送しました。

S3からGCSへの移行には、次の手順が含まれていました。

●オブジェクトストアの最初のユースケースでは、S3とGCSの両方に新しいデータの書き込みを開始し、有効期限が切れた後、アプリケーション側のロジックを使用してGCSからデータの読み取りを開始しました。 古いデータを転送するのは理にかなっておらず、このアプローチは費用対効果に優れています。

●2番目と3番目のユースケースでは、GCSに新しいオブジェクトの書き込みを開始し、データの読み取りパスを変更して、最初にGCSで検索が実行され、その後オブジェクトが見つからない場合のみS3で実行されるようにしました。

計画、コンセプトの正確性の確認、準備とプロトタイプの作成には数か月かかりましたが、その後、移行を決定し、非常に迅速に実装しました。 リスクを評価した結果、高速移行が望ましいことであり、ほとんど認識できないことがわかりました。

この大規模プロジェクトは、クラウドインフラストラクチャの管理に関する手動操作のほとんどが過去のものであるため、多くの分野で自信を持ってチームの生産性を向上させるのに役立ちました。

●ユーザーについては、最高のサービス品質を確保するために必要なすべてのものを受け取りました。 ダウンタイムはほとんどなくなり、新しい機能がより速く実装されています。

●当社のチームは、メンテナンスタスクに費やす時間を短縮し、自動化プロジェクトと新しいツールの作成に集中できます。

●ビッグデータを操作するための前例のないツールセットに加え、機械学習と分析のための既製の機能にアクセスできました。 詳細はこちらをご覧ください。

● Kubernetesオープンソースプロジェクトでの作業に対するGoogle Cloudのコミットメントは、今年の開発計画にも沿っています。