クラウドネイティブトレンドにおける移行と災害復旧

傾向

1. クラウドネイティブ開発のトレンド

クラウドネイティブは近年非常にホットな話題となっています。中国情報通信研究院が2020年7月に発表した「クラウドネイティブ発展白書（2020年）」は、クラウドコンピューティングの転換点が到来し、クラウドネイティブがビジネス成長を牽引する重要な原動力となっていることを明確に指摘した。クラウド ネイティブが IT 業界に再編をもたらしたことは容易に想像できます。アプリケーション開発プロセスから IT 実務者の技術的能力に至るまで、これは破壊的な革命です。これを基に、クラウド ネイティブ プラットフォームに基づくオープン アプリケーション モデル定義が登場し、クラウド ネイティブ プラットフォームがさらに抽象化され、インフラストラクチャよりもアプリケーションに重点が置かれるようになりました。同時に、ますます多くのパブリック クラウドがサーバーレス サービスをサポートし始めており、これは、アプリケーション中心とシステム構築における軽量インフラストラクチャ層の役割という将来の開発トレンドをさらに示しています。しかし、どのように変化しても、IT の全体的な開発方向は、迅速なビジネスの反復とビジネス ニーズへの対応につながる方向に進化する必要があります。

2020年9月、Snowflakeは1株あたり120ドルで株式を公開し、今年最大のIPO、そして史上最大のソフトウェアIPOとなりました。 Snowflake はクラウドネイティブ アプローチを使用してデータ ウェアハウスを再構築し、業界の競争環境を覆すことに成功しました。これは、市場によるクラウドネイティブの開発動向の最良の認識です。では、クラウド ネイティブによって次に破壊される分野は、従来の災害復旧分野になるのでしょうか?

2. クラウド上で新たな移行と災害復旧が必要なのはなぜですか?

1) 従来のソリューションの限界

このような一般的な傾向により、従来の移行と災害復旧は依然としてデータ転送のレベルにとどまり、クラウド指向の機能やユーザービジネスの再考と構築は無視されています。クラウド コンピューティングのビジョンは、水や電気のようにクラウド リソースをオンデマンドで利用できるようにすることです。そのため、クラウドベースの移行と災害復旧もこの歴史的傾向に従う必要があります。 Snowflake は、このようなビジネス モデルの革新を通じて、古い競争環境を打破することにも成功しました。

従来の災害復旧方法ではクラウド ネイティブのニーズを満たせないのはなぜでしょうか?簡単に言えば、この 2 つは異なるコアに重点を置いています。従来の災害復旧では、多くの場合、ストレージに重点が置かれ、ストレージに対する最高の制御が行われます。さらに、物理時代では、コンピューティング、ストレージ、ネットワークなどのインフラストラクチャ層に効果的なスケジューリング方法がなく、高度に自動化されたオーケストレーションを実現することは不可能でした。クラウド ネイティブに基づいて構築されたアプリケーションの場合、コアはクラウド ネイティブ サービス自体になります。ユーザーのビジネス システムが完全にクラウドに移行されると、ユーザーは基盤となるストレージを完全に制御できなくなるため、従来の災害復旧方法は効果的ではなくなります。

クラウドネイティブな災害復旧ソリューションを構築する際には、ビジネスを核とした構築方法を考え、クラウドネイティブサービスのオーケストレーション機能を活用してビジネスシステムの継続性を実現すべきだと考えています。

2) データセキュリティ

AWS CTO の Werner Vogels 氏はかつてこう言っています。「あらゆることは常に失敗する」。 AWS の責任共有モデルを通じて、クラウドプロバイダーが基盤となるインフラストラクチャの責任を負い、ユーザーが引き続き自身のデータセキュリティとビジネス継続性の責任を負っていることが容易にわかります。

クラウドネイティブのトレンドの下では、ユーザーの最も直接的な要求はデータセキュリティ、つまりバックアップから来ていると私は考えています。そして、移行、リカバリ、高信頼性などはすべてバックアップに基づいたビジネス形態です。バックアップ機能はクラウドネイティブ機能またはサードパーティ機能によって提供される場合がありますが、ビジネス フォームの最終的な実現はオーケストレーションによって生成されます。

クラウドに移行しても、ユーザーが安心してリラックスできるわけではありません。逆に、ユーザーはビジネスの継続性を最大限に確保するために、クラウドを開く正しい方法を学ぶ必要があります。クラウドの基盤となる設計は信頼性が高いですが、光ケーブルの引き抜き、停電、人為的ミスによりクラウド プラットフォームの可用性ゾーンが使用できなくなるなど、外部要因の影響は避けられません。そのため、「Lanxiang が中国のクラウド コンピューティングの安定性を決定する」といったジョークが生まれています。ユーザーがビジネスをクラウドに移行することを決定した瞬間から、バックアップ、移行、リカバリ、高い信頼性は継続的なプロセスになると考えています。クラウドネイティブ サービスの特性を合理的に活用して、コストを最適化し、総所有コスト (TCO) を削減しながらビジネス継続性を実現する方法。

3) ベンダーロックインを防ぐ

ある意味、クラウド ネイティブの方向性は、過去に人気があった IOE アーキテクチャと同様に、ベンダー ロックインの新たなラウンドです。ただし、現在はクラウド ベンダーがアプリケーションを実行するための基盤として使用されている点が異なります。 IOE 時代では、ユーザーが完全な代替品を見つけるのは困難でしたが、クラウド時代ではその違いはそれほど明白ではありません。そのため、ほとんどの顧客は通常、クラウド構築戦略としてハイブリッド クラウドを選択します。アプリケーションを異なるクラウド間でスムーズに移動できるようにするには、災害復旧テクノロジを使用した移行が通常の要件として存在する必要があります。 Gartnar は、マルチクラウド管理プラットフォームの定義に移行と DR を別々の機能として含めています。これは、マルチクラウド環境における移行と災害復旧の標準化の傾向を完全に示しています。

クラウド移行とクラウド災害復旧の関係

1. クラウド移行の必要性

従来の環境では、移行の必要性はそれほど顕著ではありません。移行は、コンピュータ ルームが再配置されるか、ハードウェアがアップグレードされる場合にのみ考慮されます。ただし、ここでの移行は鉄を動かすようなものであり、移行ツールと自動化の必要性は明らかではありません。 VMware の登場により、物理環境から仮想化への移行の需要が拡大しましたが、単一の仮想化プラットフォームであったため、基本的には仮想化ベンダー独自のツールで十分に需要を満たすことができました。仮想化プラットフォーム上では、これまで手動でしか操作できなかった物理環境が一気に軽量化されることに誰もが気づきました。簡単に言えば、従来のサーバーは鉄の山からファイルに変わり、このファイルは移動したりコピーしたりできるようになりました。その後、クラウド時代に入り、さまざまなクラウドプラットフォームが隆盛を極め、国内のクラウドコンピューティング市場にはさまざまな学派が競合し、クラウドコンピューティングは固定的な需要となりました。時間が経つにつれて、コストやベンダー ロックインなどの要因により、異なるクラウド間の移行が標準的な要求になるでしょう。

2. 一貫した基盤技術

ここで言及されているクラウド移行と災害復旧は、大勢の人が提供する移行サービスではなく、高度に自動化された手段を重視しています。目標は、移行プロセス中のビジネス継続性を確保し、ダウンタイムを短縮し、さらにはダウンタイムをなくすことです。ここでは、災害復旧ストレージ レベルの同期テクノロジを使用して、異機種環境での「ホット マイグレーション」を実装します。既存のソリューションには、従来の物理マシン再配置時代の移行ソフトウェアと、クラウド ネイティブに基づいて開発されたツールの両方が含まれます。しかし、どのような形をとろうとも、クラウド コンピューティングに対するユーザーの基本的な要求はさまざまな程度に解決されています。最も大きな違いは労働効率比にあり、これはあなたの利益に直接関係します。

別の観点から見ると、いわゆる移行が、実際には正式な切り替えの前の災害復旧の中間プロセスであることに気づくのは難しくありません。同時に、業務システムをクラウド プラットフォームに移行した後は、従来のバックアップや災害復旧だけでなく、クラウド上の高信頼性の概念も含めた災害復旧が継続的なアクションとなります。このように、業務システムをクラウドに移行することで、ユーザーは従来のインフラストラクチャの負担から解放され、「運用・保守ゼロ」を実現し、クラウドがもたらすメリットを真に享受できるようになります。したがって、クラウドネイティブの状態では、クラウド移行、クラウド災害復旧、クラウドバックアップは本質的にビジネス形式であり、基礎となる技術手段は完全に一貫性を保つことができると考えています。

3. 開発の方向性

上記の問題点と傾向を踏まえると、データ セキュリティとビジネス継続性の問題を解決するために顧客を支援する新しいプラットフォームが必然的に登場します。本日は、この観点から、クラウドネイティブのトレンドの下でアプリケーションシステムの移行と災害復旧ソリューションを構築する方法を分析します。

クラウド移行のトレンド

1. クラウド移行方法

移行はコンサルティング業務が中心となります。インターネット上のすべてのクラウドベンダーと MSP には独自の方法論があります。実際のところ、違いはそれほど大きくありません。関連するトピックについては以前から多くの人が共有しているので、この記事では詳細には触れません。ここでは、実際の実装プロセスでどのツールを使用すべきか、どの方法が最も効率的かについて説明することに焦点を当てます。いわゆるクラウド移行ツールは、ソース エンドをターゲット エンドに移行して、ソース エンドがターゲット エンドで正しく実行されるようにします。一般的な方法には、物理​​マシンから仮想化、仮想化から仮想化、物理マシンからクラウド プラットフォーム、仮想化からクラウド プラットフォームなどがあります。

これは、典型的な 6R 移行理論です (現在は 7R にアップグレードされ、VMware が加わって混乱が生じています)。この図では、実際の移行に関連するのは、再ホスティング、再プラットフォーム化、再購入、およびリファクタリングのみです。しかし、これら 4R のうち、リファクタリングは明らかに、ユーザーとソフトウェア開発者の共同参加を必要とする長期にわたる反復的なプロセスです。再購入は基本的に手動による再展開とあまり変わりません。したがって、ユーザーまたは MSP が短期的に実際に完了できるのは、再ホスティングと再プラットフォーム化だけです。

上記の従来の移行理論と比較して、私は、従来のアプリケーションがクラウド ネイティブに成長するプロセス全体をより適切に反映する次の図を好みます。上記の結論と同様に、クラウドを真に導入する場合、基本的に上記の 3 つの道が考えられます。

• リフト アンド シフトは、再ホスト メソッドの別名です。この方法は最も広い道路を持ち、この道路がクラウドへの最短経路であることを意味します。アプリケーションは変更せずにクラウド上で直接使用できます。
• Evolve と Go Native はどちらもパスが狭いため、Rehost 方式と比較すると、これら 2 つのパスは時間がかかり、より困難です。

図の右端では、3 つの形式が相互に変換され、最終的に完全にクラウド ネイティブな状態に進化します。つまり、移行は一夜にして達成できるものではなく、段階的に完了する必要があるということです。

2. 再ホスト

一般的に使用される再ホスティング方法は、コールド移行とホット移行です。コールド移行では、複雑な手順を踏むことが多く、多くの人手が必要となり、エラーが発生しやすく、効率も低くなります。事業継続性に大きな影響を与えるため、本番システムの移行には適していません。ホット マイグレーション ソリューションは基本的に商用ソリューションであり、ブロック レベルとファイル レベルに分かれており、さらに従来のソリューションとクラウド ネイティブ ソリューションに分かれています。

1) コールドマイグレーション

まず、コールド移行の手動ソリューションを見てみましょう。 VMware から OpenStack を例にとると、最も簡単な方法は、qemu-img ツールを使用して VMware 仮想マシン ファイル (VMDK) を QCOW2 または RAW 形式に変換し、それを OpenStack Glance サービスにアップロードしてから、クラウド プラットフォームで再起動することです。もちろん、ここでは virtio ドライバーの注入が必要です。そうしないと、クラウド プラットフォーム上でホストを正常に起動できません。このプロセスで最も時間のかかる部分は、おそらく仮想マシン ファイルを OpenStack Glance サービスにアップロードすることです。私たちの初期の実践では、ホストの移行には起動の開始から完了まで 24 時間かかりました。同時に、移行期間中に増分データが生成されます。ソース側をシャットダウンして移行が完了するまで待たない限り、上記の手順を繰り返す必要があります。したがって、この方法は、ビジネス継続性を備えた実稼働システムの移行には適していません。

では、物理マシンのコールド移行ソリューションの場合はどうすればよいでしょうか?ベストプラクティスに基づいて、中国語名が Regeneration Dragon である古いバックアップ ツール CloneZilla をお勧めします。これは非常に古いバックアップ ソフトウェアであり、マシン全体のバックアップと復元によく使用され、その原理は一般的な Norton Ghost と非常によく似ています。 CloneZilla は、基礎となるブロック レベルからコピーし、ディスク全体をバックアップでき、複数のターゲット エンドをサポートします。たとえば、ディスクをモバイル ハード ディスクに保存する場合、実際の形式は RAW になります。移行を完了するには、上記の解決策を繰り返すだけです。ただし、CloneZilla を使用する場合は、起動に Live CD を使用する必要があり、これも長期的な業務システムの中断を引き起こします。これが、前述のようにコールド移行が本番環境の移行には適していない理由です。

2) 従来のホットマイグレーションソリューション

従来のホット マイグレーション ソリューションは、基本的にブロック レベルとファイル レベルに分かれています。両者の類似点は、差分同期テクノロジ、つまり完全かつ増分的な相互同期を使用して実装されていることです。

ファイルレベルのホット移行ソリューションには、多くの場合大きな制限があり、ソース側とまったく同じオペレーティング システムを事前に準備する必要があり、マシン全体を再配置できないため、真の ReHost 方法とは見なされません。操作がより複雑になり、移行の安定性は高くありません。 Linux でよく使用される rsync は、実際にはファイルレベルのホットマイグレーションのソリューションとして使用できます。

ホット マイグレーションを真に実装できるソリューションでは、ブロック レベルの同期も使用して、基盤となるオペレーティング システムへの依存を減らし、マシン全体を再配置する効果を実現する必要があります。従来のブロック レベルのホット マイグレーション ソリューションは、基本的に、メモリ オペレーティング システム WIN PE またはその他の Live CD を使用して実装される従来の災害復旧ソリューションのバリエーションです。基本的な原理とプロセスを下の図に示します。このプロセスから、この方法は移行目標をある程度達成したものの、将来のハイブリッド クラウド正規化移行のニーズに対してはまだ次の欠点があることが容易にわかります。

• 従来のホット マイグレーション ソリューションは物理環境に基づいて構築されているため、プロセス全体で多くの人間の介入が必要となり、ユーザーに高いスキルが求められることがわかりました。
• クラウドネイティブ時代のマルチテナントとセルフサービスのニーズに対応できない
• プロキシのインストールはユーザーにとって常に問題となる
• 1対1の同期はコストの観点から経済的ではない

移行を確認する最良の方法は、クラウド内のビジネス システム クラスターを完全に復元することです。ただし、手動で検証すると、移行の人件費が再び増加します。

3) クラウドネイティブのホットマイグレーションソリューション

まさに従来の移行ソリューションの欠点のために、クラウド ネイティブのホット移行ソリューションが登場しました。この点で代表的なメーカーは、2019年にAWSがGoogle Cloudに勝つ代わりに2億5000万ドルで買収したイスラエルのクラウドネイティブな災害復旧および移行メーカーであるCloudEndureです。

クラウドネイティブのホットマイグレーションソリューションとは、ブロックレベルの差分同期テクノロジーとクラウドネイティブの API インターフェースおよびリソースを組み合わせて使用​​することで、高度に自動化された移行効果を実現するとともに、マルチテナントおよび API インターフェースを提供してハイブリッドクラウドテナントのセルフサービスニーズを満たすことを指します。まず、従来のソリューションと比較して、クラウド ネイティブ アプローチが高度な自動化とユーザー セルフサービスのユーザー エクスペリエンスを実現できる理由を原理的な観点から分析してみましょう。 2 つのソリューションを比較すると、クラウド ネイティブ アプローチの利点がいくつかあることがわかります。

• クラウドネイティブの API インターフェースとリソースを使用することで、操作が簡単になり、従来のソリューションの面倒な手動操作が完全に置き換えられ、ユーザーの技術要件が軽減され、学習の難易度が大幅に軽減されます。
• 操作が簡単なため、移行効率が向上し、移行実施の労働効率が効果的に向上します。
• 1 対多の同期により、検証と最終的な切り替え時にのみ使用されるコンピューティング リソースの使用量が大幅に削減されます。
• マルチテナントとセルフサービス要件を満たすことができる
• ソース側はエージェントレスモードもサポートし、ユーザーの懸念を払拭し、大規模なバッチ移行に適しています。
• 高度に自動化された検証とは、移行スイッチを完了する前に繰り返し検証できることを意味します。

これは CloudEndure のアーキテクチャ図です。もちろん、CloudEndure を使用してリージョン間の災害復旧を実現することもできます。

残念ながら、AWS による買収により、CloudEndure は現在 AWS への移行のみをサポートしており、国内のさまざまなクラウド移行ニーズを満たすことはできません。そこで、ここでは純粋に国内の移行プラットフォームである Wanbo Zhiyun の HyperMotion をお勧めします。これは原理的には CloudEndure と非常に似ており、VMware と OpenStack のエージェントレス移行をサポートしています。さらに重要なのは、中国における主流のパブリック クラウド、プロプライエタリ クラウド、プライベート クラウドの移行をカバーしていることです。

3. リプラットフォーム

クラウド ネイティブが提供するサービスが増えるにつれて、アプリケーション アーキテクチャの複雑さが軽減され、企業は自社のビジネスの開発にさらに集中できるようになります。しかし、R&D 側の作業負荷が軽減されるということは、その分のコストが導入や運用保守のリンクに転嫁されるということであり、DevOps はクラウドネイティブ アプリケーションにおいて欠かせない救済手段となり、企業が複雑なビジネスの変化に俊敏に対応できるようにもなります。

前述のように、ユーザーはわずかな変更を加えるだけで、一部のクラウドネイティブ サービスを優先的に使用できるようになります。この移行方法をリプラットフォームと呼びます。現在、再プラットフォーム化を選択する移行は、主にユーザーデータに関連するサービスに基づいています。一般的なサービスとしては、データベースサービス RDS、オブジェクトストレージサービス、メッセージキューサービス、コンテナサービスなどがあります。これらのクラウドネイティブサービスの導入により、ユーザーの運用・保守コストが削減されます。ただし、クラウドネイティブ サービスは厳密にカプセル化されており、基盤となるインフラストラクチャ層はユーザーからはまったく見えないため、移行には上記の再ホスティング方法を使用することはできず、他の補助手段を使用する必要があります。

リレーショナルデータベースを例にとると、AWS DMS、Alibaba Cloud の DTS、Tencent Cloud のデータ転送サービス DTS など、ほぼすべてのクラウドが移行ツールを提供しています。これらのクラウドネイティブ ツールは、MySQL、MariaDB、PostgreSQL、Redis、MongoDB などの複数のリレーショナル データベースと NoSQL データベースの移行をサポートできます。MySQL を例にとると、これらのサービスはすべて、binlog レプリケーションを巧みに使用して、データベースのオンライン移行を実現します。

オブジェクト ストレージを例にとると、ほぼすべてのクラウドが、Alibaba Cloud の ossimport や Tencent Cloud COS Migration ツールなど、ローカル オブジェクト ストレージからクラウド オブジェクト ストレージへの段階的な移行を実現できる独自の移行ツールを提供しています。ただし、実際の移行時にはコストの問題も考慮する必要があります。パブリック クラウド オブジェクト ストレージは、データを保存するには比較的安価ですが、データを読み取る場合は、ネットワーク トラフィックとリクエスト数に基づいて課金されます。このため、移行計画を設計する際にはコスト要因を十分に考慮する必要があります。データ量が多すぎる場合は、AWS の Snowball や Alibaba Cloud の Lightning Cube などのオフラインデバイスの使用も検討できます。この部分については詳しく説明しませんので、機会があれば別途ご紹介します。

クラウドに移行するためにプラットフォームを再構築することを選択した場合は、必要なアプリケーションの変更に加えて、データがスムーズにクラウドに移行できるように、適切な移行ツールを選択する必要もあります。上記のリホスト移行方法と組み合わせることで、業務システム全体のクラウド移行効果を実現できます。関係するサービスが多数あるため、参考として移行ツールの表を示します。

クラウドネイティブにおける災害復旧の開発動向

これまでのところ、クラウド ネイティブ状態で統合された災害復旧要件を完全に満たすことができるプラットフォームは存在しません。次のシナリオを使用して、クラウド ネイティブのニーズを満たす統合災害復旧プラットフォームを構築する方法を分析します。

1. 伝統的な建築

シンプルな WordPress + MySQL 環境を例に挙げてみましょう。従来のデプロイメント環境は、一般的に次のように構成されます。

このアプリケーション アーキテクチャの災害復旧ソリューションを設計する場合は、次の方法を使用できます。

1) 負荷分散ノードの災害復旧

負荷分散はハードウェア レベルとソフトウェア レベルに分かれています。ハードウェア負荷分散の高い信頼性と災害復旧は、多くの場合、独自のソリューションを通じて実現されます。ソフトウェア負荷分散の場合は、基本オペレーティング システムにインストールする必要があることがよくあります。同じ都市での災害復旧は信頼性の高いソフトウェアを使用して実現できますが、異なる場所での災害復旧は、事前にピア ノードを確立するか、災害復旧ソフトウェアのブロック レベルまたはファイル レベルの災害復旧を使用するだけで実現されることがよくあります。災害復旧スイッチ（フェイルオーバー）の非常に重要な部分です。

2) Webサーバーの災害復旧

Wordpressの動作環境はApache + PHPのみです。ユーザーのアップロードを保存するために使用されるファイル システムが分離されているため、ノードはほぼステートレスです。ノードを拡張することで高い信頼性を実現でき、異なる場所での災害復旧も比較的簡単です。従来のブロック レベルとファイル レベルの両方で、災害復旧のニーズを満たすことができます。

3) 共有ファイルシステムの災害復旧

図では Gluster ファイル システムが使用されています。分散システムの一貫性は通常、内部的に維持されるため、ブロック レベルのみを使用してノードの一貫性を確保することは困難であり、ここではファイル レベルの災害復旧を使用する方が正確です。

4) データベースの災害復旧

ストレージ層だけに頼ってデータベースのデータ損失をゼロにすることは不可能なので、通常はデータベース レベルで実装されます。もちろん、コストを削減するために、データベースを定期的にダンプするだけで、データベースの災害復旧を簡単に実現できます。もちろん、信頼性の要件が高い場合は、CDP も使用できます。

上記の事例分析から、従来のインフラストラクチャにおける災害復旧は、ディスクアレイのストレージミラーリングであれ、I/Oデータブロックやバイトレベルに基づくキャプチャ技術であれ、ストレージを中心に行われることが多く、ネットワーク、データベース、クラスタのアプリケーションレベルの技術と組み合わせて、高信頼性の災害復旧システムの構築を完了していることは容易に理解できます。災害復旧プロセス全体に関与するのは主に、ホスト、ストレージ、ネットワーク、アプリケーション ソフトウェアであり、これは比較的単純です。したがって、従来の災害復旧ソリューションでは、ストレージ災害復旧をどのように正しく解決するかが、問題を解決する鍵となります。

2. ハイブリッドクラウド災害復旧

これは現在最も一般的なハイブリッド クラウド ソリューションであり、主要な災害復旧ベンダーが推進している方法でもあります。ここでは、クラウド プラットフォームを仮想化プラットフォームとして扱い、その機能をほとんど活用していません。復旧プロセスでは、ビジネス システムを使用可能な状態に復元するために、多くの人的介入が必要になります。このアーキテクチャはクラウドのベスト プラクティスに準拠していませんが、多くのビジネス システムをクラウドにバックアップまたは移行する状況を忠実に反映しています。

この種のアーキテクチャは確かに災害復旧の問題を解決できますが、非常にコストがかかります。では、別のアプローチを試してみましょう。最適化のためにオブジェクト ストレージとデータベースを活用しました。オリジナルのストレージサービスをオブジェクトストレージに保存し、リアルタイムのデータベースレプリケーションにはデータ転送サービスを使用します。クラウド ホストは、同期に従来のブロック レベルを引き続き使用します。障害が発生すると、事前に設定した計画に従って、バックアップを復元し、可能な限り短時間で災害復旧を完了するための自動オーケストレーション機能が必要になります。

3. クラウドベースのローカル災害復旧アーキテクチャ

上記のバックアップ方法は、実際にはプラットフォーム再構築による移行です。移行を使用してバックアップが実行されているため、アーキテクチャを次のように変換して、同じ都市で災害復旧アーキテクチャを形成できます。クラウド プラットフォームのベスト プラクティスに基づいて、アーキテクチャを次のように調整しました。

このアーキテクチャは、アプリケーション レベルで高い信頼性を実現するだけでなく、一定レベルの高い同時実行性もサポートします。ユーザーは、最小限の変更コストで、同じ都市でアクティブ/アクティブ デュアル サーバー効果を実現できます。クラウド上で使用されているクラウドネイティブ サービスの数を分析してみましょう。

• ドメイン名解決サービス
• VPC サービス
• 負荷分散サービス
• 自動スケーリングサービス
• クラウドホスティングサービス
• オブジェクトストレージサービス
• リレーショナルデータベース RDS サービス

クラウド ホストを除き、他のサービスは当然、可用性ゾーン全体にわたる高可用性をサポートします。クラウド ホストの場合、ミラーリング サービスを作成でき、自動スケーリング サービスがインスタンスのステータスを管理します。クラウドアベイラビリティゾーンは同一市内での災害復旧という概念なので、ここでは同一市内の業務システムの災害復旧を実装しました。

調整されたアーキテクチャは、ビジネス継続性の要件をある程度満たしていますが、データセキュリティの保証はまだ不十分です。近年、ランサムウェアが猛威を振るい、多くの企業が甚大な被害に遭っているため、クラウド移行後にはデータのバックアップを実施する必要があります。クラウドネイティブ サービス自体は、クラウド ホストの定期的なスナップショットなどのバックアップ ソリューションを提供しますが、サービスは分散していることが多く、統一された方法で管理することが困難です。同時に、リカバリ中は各サービスのみを復元できます。業務システムの規模が大きい場合、復旧コストは大幅に増加します。クラウド ネイティブ サービスは独自のバックアップ問題を解決しますが、バックアップをアプリケーションに再編成するには、自動オーケストレーション機能を使用する必要があります。

4. 同じクラウドと異なる場所における災害復旧アーキテクチャ

ほとんどのクラウドネイティブ サービスは可用性ゾーン内にあり、高い信頼性を提供しますが、クロスリージョン サービスでは通常、バックアップ機能のみが提供されます。たとえば、クラウド ホストをミラーに変換し、そのミラーを他のリージョンにコピーすることができます。リレーショナル データベースとオブジェクト ストレージにも、クロスドメイン バックアップ機能があります。これらのコンポーネントのバックアップ機能とクラウド独自のリソース オーケストレーション機能を活用することで、災害復旧可用性ドメインでシステムを利用可能な状態に復元できます。では、スイッチをどうやって起動するのでしょうか?

ここでは、業務システムの特性に基づいてクラウドネイティブ監視のアラームをカスタマイズし、アラームプラットフォームのトリガー機能を使用して機能コンピューティングをトリガーし、業務システムのクロスドメイン切り替えを完了し、リモート災害復旧を実現します。

5. クロスクラウド災害復旧

ただし、クロスクラウドの災害復旧は、同一クラウドの災害復旧とは異なります。少なくとも、異なる可用性ゾーン間でサービスは一貫しています。この場合、同じクラウド上で使用される方法は基本的に効果がなく、対象のクラウド プラットフォームの機能または中立的なサードパーティ ソリューションが絶対に必要になります。データのバックアップに加えて、ここでのもう 1 つのポイントは、サービス構成の一致です。そうすることで初めて、クロスクラウド災害復旧のニーズを完全に満たすことができます。考慮すべきもう一つの点はコストです。オブジェクトストレージを例にとると、「クラウドに行くのは簡単だが、クラウドから離れるのは難しい」という典型的なケースです。したがって、クラウドネイティブ リソースの特性をどのように活用して災害復旧ソリューションを合理的に設計するかが、コストの大きな試練となります。

要約する

クラウドネイティブの災害復旧はまだ初期段階にあります。現在、上記のシナリオの災害復旧要件をサポートできる完全なプラットフォームは存在しません。それは継続して調査する価値のあるテーマです。クラウドネイティブの災害復旧は、バックアップを中核とし、移行、復旧、高信頼性をビジネスシナリオとして採用し、複数のクラウド間の自由な流れを可能にして、最終的にユーザーのビジネスニーズを満たします。

そのため、クラウドネイティブの災害復旧プラットフォームとしては、以下の 3 つの機能を解決する必要があります。

• データを中核にすることで、複数のクラウド間でデータを流すことができます。データはユーザーにとって中核的な価値であるため、基盤となるインフラストラクチャがどのように変化しても、データのバックアップはユーザーが最初に意識する要求となるはずです。さまざまなクラウドネイティブ サービスのデータ バックアップの問題をどのように解決するかは、データ フローの必要な基礎です。
• クラウドネイティブのオーケストレーション機能を活用して、高度な自動化を実現し、データに基づいてビジネス シナリオを構築します。自動化されたオーケストレーション機能を活用して、より多くのデータ層ベースのアプリケーションを実装し、ユーザーがより多くのビジネス革新を実現できるようにします。
• クラウドネイティブ リソースの特性を柔軟に活用して、総所有コストを削減します。これにより、従来の災害復旧に対する巨額の投資の問題が解決され、ユーザーは水や電気と同じようにオンデマンドで支払うことができます。