クラウド移行について

弊社の CIO Lele が大変な事態に陥っています。同社がパブリック クラウド サービス プロバイダーの変更を決定した後、技術部門はクラウド移行に向けて慎重に準備を始めました。当社がクラウド移行を行うのは今回が初めてではなく、技術部門も十分な準備をしてきましたが、パブリッククラウドへの移行中にいくつかの問題が発生し、しばらくの間、リリースシステムさえも正常に使用できませんでした。なぜクラウドへの移行が必要だったのでしょうか?クラウド移行プロセス中に Lele はどのような問題に直面しましたか?以下で詳しく見ていきましょう。

クラウド移行前のシステム再構築

まず、移行前に Lele 氏とその同僚が何をしていたかを見てみましょう。

Lele: クラウドへの移行前に、技術部門はまず大きなことを行っていました。それは、Zhiding.com が 10 年以上使用してきたビジネス システム全体を再構築することでした。

再建の理由は非常に現実的です。 10 年以上にわたるアプリケーションの蓄積により、業務システムは非常に肥大化し、複雑化しています。長い間使われなくなった多くのアプリケーションやデータは、絡まった糸の山のようなものです。それらは役に立たないだけでなく、ウイルスやトロイの木馬の温床にもなっています。また、基盤となるシステムが古いためにセキュリティ上の脆弱性が数多く残っており、システムの信頼性の高い適用が脅かされることがよくあります。物事を修繕して間に合わせるよりも、取り壊して再構築する方がよいでしょう。より成熟度が高く、操作が簡単で、PC やモバイル端末上のマルチプラットフォームのビジネス アプリケーションに適した新しいシステムを再構築します。

技術部門の同僚全員による数か月にわたる懸命な努力の結果、安全なユーザー ログイン、更新された基盤システム アーキテクチャ、およびデータベースの大幅な削減を備えた新しいビジネス システムが、一定期間の試用運用を経て、古いビジネス システムに正式に置き換えられました。

新しいビジネス システムがリリースされた後、予想通り多くの否定的なレビューが寄せられました。結局のところ、誰もが新しいことに慣れ、適応するプロセスを必要としています。小規模な機能調整を何度か繰り返し、ようやく業務システムが安定して稼働できるようになりました。

システムの更新が完了したので、クラウドへの移行が正式に議題に上がりました。

より良いビジネス体験のために

UCloud を選んだ理由を尋ねられた Lele 氏は、「より良いビジネス エクスペリエンスのため」と答えました。

フォローアップの質問:「これは本当にそうなのでしょうか?」

レレ氏はこう答えた。「もちろん、使用コストも考慮しなければならない非常に重要な要素です。」

さらに質問：「罠にかかったんですね～～」（不吉）

レレ: 「はい…」

「もちろん、完全に罠に落ちたとは言えません。パブリック クラウドに移行するたびに、必ず何らかの異なる問題が生じ、問題を発見して解決するというプロセスが必然的に発生します。」その後、Lele 氏は、この移行プロセス中に発生した問題とその解決プロセスを紹介しました。

ZDNet は、中国で最も早くビジネスをパブリック クラウドに移行した IT メディアの 1 つです。 ZDNet の技術系の学生たちは、「生命が生きている限り、努力に終わりはない」という研究精神を常に持ち続けています (bing)。 「やってみなければ良いのか悪いのか分からない」という会社のトップの強い後押しもあり、今回で2度目のパブリッククラウドへの移行となります。パブリック クラウドに移行する前に、パブリック クラウドの評価アクティビティを 2 回実施しました。テスト結果から判断すると、UCloud は ZDNet のビジネス アプリケーションのニーズを完全に満たすことができ、調達コストの面でも大きな利点があります。そこで慎重に検討した結果、UClould への移行を選択しました。

1か月半の準備期間を経て、クラウド移行作業が正式に開始されました。なぜこれほど長い準備期間が必要なのかというと、一方では現在利用している業務システム全体を再構築する必要があること、他方で新しいパブリッククラウドのアーキテクチャに適応する必要があることなどが挙げられます。システムの再構築については前項で紹介しました。それでは、クラウド移行プロセス中に発生した問題について具体的に説明しましょう。

移行IP設定の問題

クラウド移行プロセス中に遭遇した困難について尋ねられたとき、Lele 氏は「IP 構成と負荷分散」と答えました。

クラウド サービスの通常のアプリケーションは、サポートのためにさまざまなクラウド ホストに依存する必要があり、アプリケーションは IP アドレスに依存してクラウド ホストを見つける必要があります。業務システム用に元のパブリック クラウドで定義されたシステム アーキテクチャを、新しいパブリック クラウドに移行する必要があります。内部システム アーキテクチャが変更されないことが最善です。しかし、依然として問題が発生します。 UCloud のクラウド ホスト IP は、システム アーキテクチャに自動的に適応できません。

ZDNet のクラウド上の業務システムの規模はそれほど大きくありませんが、運用・保守担当者に頼って、クラウド ホストごとにリージョン、構成、ミラー、その他多数のオプションを手動で設定するのは明らかに非現実的です。その結果、ビジネスがオンラインになると、クラウド ホストの IP がシステムで定義された IP と一致しなくなります。システムはクラウドホストを見つけることができず、当然ビジネスは適用できません。最終的に、この問題を解決するには、UCloud 技術チームと交渉して、バックグラウンドですべてのイントラネット IP を再定義し、システム IP と一致させる必要がありました。パブリッククラウドのホスト IP の一括定義と自動切り替え機能も、パブリッククラウドの選択プロセスで慎重に検討する必要がある重要な機能であると思われます。

負荷分散: 予期しない問題

ビジネス システムが展開された後、ユーザー要求をさまざまなサーバーに効果的に分散して実行する必要があり、そのためには負荷分散を使用する必要があります。 UCloud は、メッセージ転送とプロキシ モードに基づく負荷分散機能を提供できますが、両方のタイプの負荷分散をビジネス システムに適用すると、いくつかの欠点があります。プロキシモードでは、限られたポートを除き、他のポートにアクセスすると正確な外部 IP アドレスが取得できず、着信は 1 回のみとなります。メッセージ転送モードではこの問題は発生しませんが、仮想ネットワーク カードを再定義する必要があります。これらの問題は最終的にはすべて解決できますが、問題の問題点が特定されるまでは、盲人が暗闇の中で手探りで進むようなものです。

さらに、UCloud から技術サポートやヘルプ ドキュメントを探す際にも課題に直面しました。問題が発生すると、テクニカル サポートは単にヘルプ ドキュメントをいくつか送信しますが、これらのドキュメントは完全ではなく、ユーザーが問題を効果的に見つけるのに役立ちません。これも改善が必要な分野です。

不完全な技術サポート ドキュメントは、学習コストが高すぎるという潜在的な問題にもつながります。ユーザーがパブリッククラウドを使用する場合、スムーズに使い始める前にシステムに慣れるのにある程度の時間が必要です。しかし、予期しない問題が発生した場合、ユーザーがシステムに慣れる時間はありません。その結果、事業ライン全体に混乱が生じる可能性があります。

まとめ

Lele 氏は、今回のクラウド移行を振り返って、UCloud には確かに不完全な機能もあるが、ユーザーのビジネス要求に応えるという観点からは、UCloud はまだかなり満足できるものだと述べています。たとえば、当社の要件はユーザー リクエストに 0.5 秒以内に応答することですが、UCloud は 300 ミリ秒以内に応答できるため、期待を上回ります。さらに、ドメイン名の登録に関しては、UCloud はすべての操作をオンラインで実行し、情報を郵送する必要がないため、登録プロセス全体の所要時間が大幅に短縮されます。レビューサイクルは基本的に約12営業日で完了し、効率は以前に比べてほぼ2倍になり、市場投入までの時間が大幅に短縮されました。

実際、アプリケーション機能の欠陥はどのクラウドにも存在しますが、クラウドによってはユーザー数が多いため、より早く発見され、改善されることもあります。さらに、ユーザー数が多く機能が充実したパブリッククラウドを利用する場合、コストも高くなる可能性があります。これらすべてを総合的に考慮する必要があります。

Zhiding.com がパブリック クラウドへの移行中に遭遇した問題から、問題は主にクラウド ホスト上に構築されたシステムとさまざまなパブリック クラウド間の調整にあることがわかります。私が現在研究しているコンテナは、そのような問題をより適切に回避できます。どうやら、もう少し Lele を「だまして」、いつか戻ってきてパブリック クラウドからコンテナへの移行を完了するように頼む必要があるようです。

どうぞお楽しみに！