クラウド移行時に企業が備えるべき課題

クラウド コンピューティングの普及により、ビジネスはかつてないほどダイナミックになっています。今日、多くの企業がビジネスをクラウド コンピューティングに移行しています。クラウド プロバイダーを選択すると、ほとんどの場合、長期的なベンダー ロックインが保証されます。エンジニアがアプリケーション層を適切に抽象化して一般化することが困難であったり、アプリケーション データのサイズが移行を困難にしたりと、クラウドベースのシステムへの移行は非常に困難な作業です。オンプレミス データ センター上のセルフホスト システムからクラウドに移行する場合は、次の課題を考慮する必要があります。

[[211960]]

1. 不適切な抽象化

新しい環境での障害を抽象化することは、クラウドへの移行における最大の課題の 1 つです。通常、アプリケーションのアーキテクチャは、その下にあるローカリゼーション API に依存します。特定の問題は特定の規模でのみ確認できるため、これは大規模に動作するシステムでは特に一般的です。エンジニアリング チームは、システムを修正するためにハッカーのようなプログラムやパッチを使用することが多いですが、ハッカーはシステムの移行中に攻撃する可能性があります。定期的なコードレビューは、これらの問題をある程度軽減するのに役立ちます。

2. 導入プロセスの違い

最新の継続的インテグレーションと継続的デリバリー (CI/CD) プラットフォームはすべて複数のクラウド プロバイダーをサポートしていますが、それだけでは十分ではありません。セットアップと起動のプロセスが複雑なアプリケーションでは、展開に手動による介入が必要になることがよくあります。近年では、Puppet、Chef、Ansible などのツールを使用して、これが大部分自動化されるようになりました。しかし、この自動化は、サーバーのプロビジョニング、監視、および解体を必要とするベンダー固有の API に関連付けられていることがよくあります。ただし、エンジニアリング チームが時間をかけて独自に構築しない限り、これらの API は小規模なオンプレミス データ センターには適していません。

3. 再設計

最新のアプリケーションは、さまざまな地域の複数のデータセンターに分散されています。これは、クラウドベースの展開に移行する主な利点の 1 つです。企業は、モノリシックなアプリケーション基盤からマイクロサービス ベースのアプローチへと徐々に移行しています。ローカル データ センターからマルチサイト展開に移行するには、アプリケーションを適切に再設計する必要があります。つまり、エンジニアリング チームは、新しいバージョンの開発に加えて、既存のインストールにも配慮する必要があります。システムの重要な部分を移行するとダウンタイムが発生することが多く、新しい展開が最初の試行で成功する保証はまだありません。問題が発生した場合にエラーを防ぐために、元のデプロイメントをフェイルオーバーすることをお勧めします。大規模な移行は完了までに数か月かかる場合があり、完了するために追加のスタッフが必要になることもあります。

4. 大量のデータの転送

モバイル ソーシャル アプリ Instagram のビジネスを AWS クラウド プラットフォームから Microsoft Azure クラウド プラットフォームに移行しなければならないと想像してみてください。こうした膨大な量の画像を送信すること自体が困難な作業です。場合によっては、データをクラウド コンピューティング プロバイダーにアップロードするのではなく、物理的に発送することが最善策であると考えるのはおかしなことではありません。両方の戦略は長年にわたって分析されてきましたが、業界ではどちらが正しいアプローチであるかはまだ決定されていません。この問題は移行するシステムの種類に依存しないため、アーキテクチャを変更するだけでは軽減できません。企業によっては、ローカル データ センターをベースとした展開であっても、最初からクラウド ストレージを使用することを選択するところもあります。このアプローチは、データがあまりアクティブでない場合や、即時の処理を必要としない場合に特によく使用されます。 Amazon S3 ストレージは長年にわたり多くの企業にとって信頼性の高いストレージ ソリューションであり、この分野のリーダーであり続けています。

今日、多くの企業は市場ベースのスタートアップ企業を迅速に買収して売却することを好みます。クラウドへの移行や、あるプロバイダーから別のプロバイダーへの切り替えは、この種のビジネスでは非常に一般的なタスクです。多くの場合、新しく取得したアプリケーションを作成するには、現在のアプリケーション セットを使用する必要があります。場合によっては、新しい製品が新しいクラウド プロバイダーに移行したり、クラウドから自己ホスト型の設定に移行したりして、すでに購入した契約やハードウェアを活用することがあります。たとえば、Instagram が Facebook のデータ センターに移行し、実質的に Facebook のプライベート クラウド プラットフォームを形成したのがその一例です。

理由が何であれ、クラウドベースのシステムへの移行は多くの組織にとって必須です。数か月かかる可能性のある試練を短縮するには、適切な抽象化を導入してベンダー中立の方法でアプリケーションを作成する方が適切です。