従来のビジネスをパブリック クラウドに移行する際の落とし穴を回避するためのガイド

[[396459]]

この記事はWeChatの公開アカウント「New Titanium Cloud Service」から転載したもので、著者はQin Mingです。この記事を転載する場合は、Xintai Cloud Service公式アカウントまでご連絡ください。

現在、国内の多くの企業では既にパブリッククラウドを積極的に活用しています。これらの企業の多くは、事業が発展するにつれて、マルチクラウドのアクティブ/アクティブや災害復旧を検討し、クラウド製品の機能やコストに基づいてクラウド間を移行することになります。

当社は数か月前にパブリッククラウドビジネス移行プロジェクトに着手しました。プロジェクトでの経験を少しまとめました。以下は私の要約です。すべての運用・保守スタッフが同様の問題を迅速に解決するのに役立つことを願っています。

データベース同期の問題

データベースの同期は DTS ツールを使用して行われます。現在、すべての主流パブリック クラウドには独自の DTS ツールがあります。 DTS ツールの基本原理は、ソース データベースの binlog からデータを読み取り、それをターゲット データベースに挿入することです。ただし、さまざまな DTS ツールのフォールト トレランスは大きく異なります。次に、データベースの同期で遭遇する落とし穴について説明します。

1. データベースのテーブルフィールドはNULLを許可する必要がある

エラー 3140: 無効な JSON テキスト:「ドキュメントが空です。」 MySQL 同期中に列の値の位置 0 で発生します。

その理由は、ソースデータベースの検証が厳密ではないためです。データベース内のフィールドは NOT NULL である必要がありますが、データ内に NULL 値を持つデータが存在します。

ニーズに応じて 2 つのソリューションがあります。

（１）ソースデータベースのデータを修復し、すべてのNULL値を正しい値に修正します（これもビジネスロジックの要件を満たしています）。

（2）ターゲットデータベースのテーブルを変更し、フィールドがNULLを許可するように変更します。たとえば、テーブルはxxxxでフィールドは合計です

ALTER TABLE `xxxx` CHANGE `total` `total` JSON NULL;

2. データベースソースライブラリのバイナリログをより長期間保持する必要がある

データベースの同期を実行すると、問題が発生し、増分同期のために再起動が必要になる場合があります。ただし、この同期は夜間に実行されることもあり、朝に問題が発見されたときには、問題が発生してから数時間経過している場合があります。

この時点でソース データベースが binlog を 1 ～ 2 時間しか保持していない場合、ユーザーは朝に同期タスクを再開するときに対応する binlog ファイルを見つけることができず、再度完全同期を実行する必要があります。同期中は、ソース データベースのバイナリ ログを 2 ～ 3 日以上保持することをお勧めします。

3. ターゲットデータベースのディスク容量は、ソースデータベースの2倍にすることを推奨します。

データベースの同期を実行すると、大量の書き込みに加えて、ターゲット データベースにいくつかの一時テーブルとログが生成されます。 2 つのライブラリのディスク容量が同じ場合、ターゲット ライブラリのディスク容量が不足し、書き込みに失敗する可能性が高くなります。これに対処するには、間違いなく多くの時間を無駄にすることになります。

したがって、ターゲット データベースのディスク領域をソース データベース領域の 2 倍に適用することをお勧めします。コストの差がそれほど大きくない場合は、移転後にコストを減らさないでください。

4. データベース同期中にタスクをスケジュールすることはできません

データベースを同期しているときに、DTS が突然主キー ID エラーのログを報告し、同期が中断されました。調査の結果、ユーザー データベースでスケジュールされたタスクが実行されていることが判明しました。したがって、データベースを同期するときは、データベースのスケジュールされたタスクをオフにする必要があります。

ES 移行の問題

ES の移行自体に問題はありませんが、異なる ES バージョン間には大きな違いがあります。慎重にテストしないと、隠れた問題を発見できない場合があります。

お客様が遭遇した ES の問題は、以前 XX Cloud で ES の初期バージョンを使用しており、デフォルトのシャーディング設定が 5 であったことです。XX Cloud に切り替えると、ES 7 バージョンが使用され、デフォルトのシャーディングは 1 になります。

通常の顧客業務に使用する場合は、業務に合わせてシャード数を変更し、業務に適応させる必要があります。しかし、顧客はそうしなかったため、製造事故が発生しました。弊社がお客様のインデックス再構築とシャード数の調整をサポートした結果、問題は解決しました。

DNS の問題

移行には最終的にドメイン名の切り替えが伴います。国内および世界中でドメイン名を切り替えるのにかかる時間は不確実であり、地域によって一定の違いがあります。

顧客は特定のプロジェクトへのアクセスで問題が発生しました。私たちが行うことは、元のパブリック クラウドの入り口に nginx を展開し、元の nginx へのすべてのアクセスを新しいパブリック クラウドの入り口に proxy_pass することです。これにより、誰も古い環境にアクセスできなくなります。

結論: クラウド間のアプリケーションの移行は非常に簡単な作業のように見えますが、実際には未知の問題が山積しています。これらの問題は、パブリック クラウド製品またはビジネス コードによって発生する可能性があります。

しかし、理由が何であれ、プロのクラウド管理サービスプロバイダーとして、Xintai Cloud Service はこれらの問題をうまく処理し、移行プロセス中に顧客のために情報を整理し、アーキテクチャと運用および保守プロセスを最適化し、顧客のビジネスを保護することができます。