アプリケーションをクラウドに移行する際に知っておくべきこと

現在、多くの企業がアプリケーションをクラウドに移行しています。アプリケーションをクラウドに移行するのは簡単ですが、既存のインフラストラクチャを移行する必要がある場合はどうでしょうか?クラウドでネットワークを再作成し、アーキテクチャを最新化し、AWS などのクラウド コンピューティング プロバイダーの多くの利点を活用できます。

[[424506]]

クラウド コンピューティングが便利なのはなぜでしょうか?

最も基本的な形態では、「クラウド」はサービスとしてのインフラストラクチャであり、企業はハードウェアをレンタルしてアプリケーションを実行できます。多くの企業は自社のオンプレミス サーバーを介してネットワークを運用していますが、サードパーティからサーバーをレンタルすると、柔軟性が向上し、必要に応じて拡張できるようになります。

ただし、AWS、Google Cloud Platform、Microsoft Azure などの主要なクラウド コンピューティング プロバイダーは、サーバー以上のものを提供しています。同社の事業は、運用効率を向上させ、アプリケーションの構築を容易にする使いやすいツールを開発者に提供することです。

たとえば、クラウドでサーバーを実行すると、企業は実際にコストを節約できます。専用サーバーは高価になりますが、AWS などのクラウド コンピューティング プロバイダーは高度な自動スケーリング システムを備えています。これにより、企業はサーバーのライフサイクル プロセスを完全に自動化し、需要の変動に応じて (多くの場合、1 日に複数回) サーバー リソースを作成およびシャットダウンできます。企業はオフ時間中に規模を縮小できるため、ピーク時の容量を支払うのではなく、全体的なコストを節約できます。

自動スケーリングを設定すると、負荷が高まったときに追加のサーバーを自動的に作成することもできます。これにより、ネットワークのスケーラビリティが高まり、トラフィックの増加によるダウンタイムがほとんど発生しなくなります。このスケーラブルな機能はすべてのサービスで利用できます。たとえば、AWS の Lambda 関数は、そのままでも無限に拡張できます。彼らのシステムは企業向けのコード処理と実行を行います。関数が 1 秒間に何回呼び出されても、ボトルネックが発生することはありません。

クラウド コンピューティングは、タスクを自動化することでコストも節約します。たとえば、AWS のリレーショナル データベース サービス (RDS) は、データベース管理のタスクの多くを自動化する、完全に管理された SQL サービスです。すでに独自のサーバーでこれらのタスクを完了している場合もあります。 AWS RDS を使用すると、より多くのデータベースを管理し、残りの時間をより効率的に使用できます。

最後に、クラウド コンピューティング インフラストラクチャは、オンプレミス ソリューションよりも耐久性が高いことがよくあります。これは主に、S3 バケットなどのサービスがデータ ストレージに対して非常に冗長性が高いという事実によるものですが、高可用性ネットワーク設計にも適しています。ハードウェア障害が発生した場合にバックアップ サーバーが引き継ぐことができるように、フェイルオーバー状況を簡単に設計できます。また、最悪の場合でも、サーバー ストレージを強化する EBS などのサービスが S3 ストレージ ファシリティに自動的にバックアップされるように構成できるため、ネットワーク内のすべてのものをバックアップするのは非常に簡単です。

たとえば、AWS の DNS サービスである Route 53 は、組織のハードウェアを監視し、サーバーが応答しなくなった場合に DNS レベルでトラフィックを自動的に切り替えるヘルスチェックをサポートしています。自動スケーリングはヘルスチェックもサポートしており、問題が発生した場合にはサーバーを完全に終了して置き換えることができます。

クラウド コンピューティング ソリューションでアーキテクチャを最新化

クラウドへの移行は大きな一歩であり、企業が利用できる追加ツールがあれば、アーキテクチャを見直して、設計変更によってどの部分が恩恵を受けられるかを把握することは十分に可能です。

たとえば、従来のアプリケーションの多くは、サーバー上で実行できる 1 つの大きなプログラムとしてパッケージ化された「モノリス」として設計されています。プログラムは、オンプレミスまたはリモート データベースと通信し、受信した Web 要求を処理し、クエリを実行し、情報を検索し、キューを処理し、ユース ケースに必要なその他のすべての処理を実行します。

これは、アプリケーションをすぐに起動して実行するには適していますが、最終的には問題を引き起こします。つまり、効率的ではないということです。多くの複雑なタスクを同時に処理しようとする限り、大規模なモノリシック アプリケーションの一部が、常にアプリケーションの残りの部分のボトルネックになります。通常、企業は規模を拡大し、より多くのサーバーをプロビジョニングし、より多くのインスタンスを実行することを余儀なくされます。プログラム内の他のコンポーネントにそれほど負荷がかからない場合、これは無駄につながる可能性があります。

そこで、多くのエンジニアが注目しているソリューションが「マイクロサービス」です。これらのサービスは別々であり、それぞれ明確に定められた目標を持っています。おそらく、Web アプリケーションの 1 つの要素がビデオを処理しており、ユーザーが大きなビデオをアップロードすると負荷が高くなります。企業はこの部分をマイクロサービスに移行し、外部で処理して、必要なときに呼び出すだけで済みます。現在、そのコンポーネントは完全に独自に拡張できます。企業では、ビデオ処理サービスを実行するサーバーが 3 台必要になる場合がありますが、アプリケーションの残りの部分を実行するサーバーは 2 台だけで済みます。これにより、企業のリソースをより効率的に使用でき、全体的にスケーラブルな設計になります。

企業が導入を検討すべきサービスは何でしょうか?

企業がマイクロサービス設計を選択するかどうかに関係なく、他のクラウド コンピューティング ソリューションは役立ちます。

AWS は、特に提供するサービスの数の点でクラウド コンピューティング業界のリーダーであるため、AWS が提供するサービスのいくつかを以下で説明します。ただし、ほとんどの大手クラウド サービス プロバイダーは同様の製品を提供しています。

（１）クラウドオブジェクトストレージ（S3）

ほとんどのオンプレミス ソリューションはブロック レベルのストレージを使用します。つまり、オブジェクトはディスク上にファイルとして保存され、ネットワーク経由で提供されます。ただし、AWS などのクラウド コンピューティング プロバイダーの規模により、Simple Storage Service (S3) に大量のファイルを保存できるようになります。

S3 は従来のフォルダーを使用しませんが、S3 と同様に動作するオブジェクト キーを持っています。 S3 は基盤となるドライブへの直接アクセスは提供せず、企業がクラウド プラットフォームに名前と場所を指定してファイルを保存することのみを許可します。以上ですが、このシンプルなデザイン パターンにより、多くの柔軟性が実現されます。

たとえば、エンタープライズ アプリケーションでユーザーがコンテンツをアップロードできるとします。画像を S3 に保存するのは良い選択肢であり、AWS の CloudFront コンテンツ配信ネットワークを使用してインターネット経由で画像を提供することもできます。

S3 ベースのストレージへの切り替えはプロセスですが、AWS の Storage Gateway などのハイブリッド ソリューションもあります。

（２）クラウド機能

Lambda のようなクラウド コンピューティング機能は、企業がサーバーを意識することなくクラウドでコードを実行できるため、非常に便利です。 AWS の API Gateway などの API から直接関数の実行をリクエストするだけで、関数はキューに入れられ、Lambda サーバー上で実行されます。

企業は、関数によって使用された CPU 秒数とメモリに対してのみ料金を支払います。関数が何回呼び出されても、それを処理できるようにスケールされます。

クラウド機能を使用すると、ネットワーク内の単純なタスクを簡単に自動化できます。いずれかのサーバーで cron ジョブ スクリプトを実行している場合は、Lambda に移行することを検討してください。もちろん、Lambda は単純なスクリプトに限定されません。これは非常に強力であり、強力なアプリケーション バックエンドを作成するために使用できます。

（３）ロードバランサとオートスケーリング

ロードバランサーは、サーバー間でトラフィックを分散するネットワークデバイスです。従来、組織は HAProxy などのプログラムを使用してサーバーをセットアップし、自分で構成する必要がありました。 AWS クラウド プラットフォームでは、これらはネットワークに組み込まれているため、オンにして料金を支払うだけで済みます。

自動スケーリングは、ロードバランサー上に構築されたもう 1 つの機能です。企業のサーバー リストは静的ではなく、トラフィックの需要に基づいています。必要に応じて、サーバーがリソース プールに追加され、リソース プールから削除されます。

これまで見てきたように、これには多くの利点がありますが、企業がネットワークを使用および更新する方法にも大きな影響を及ぼします。サーバーのインストール プロセスは自動化されているため、ブルー/グリーン コードのデプロイメントを実行できます。ブルー/グリーン コード デプロイメントでは、まったく新しいサーバーを作成し、サービスがオンラインになるのを待ってから、トラフィックをゆっくりと切り替えて問題を解決することでサーバーを更新します。

どちらかといえば、これは自動スケーリングであり、企業向けの頼りになる EC2 サービスです。

（4）自動化された継続的インテグレーション（CI）/継続的デリバリー（CD）パイプライン

継続的インテグレーション (CI)/継続的デリバリー (CD) は、ソース管理に変更が加えられるたびにサーバーにデプロイされるアプリケーションの自動ビルドを設定するプロセスです。

基本的に、コミットを Github にプッシュし (または別のリポジトリを使用し)、AWS CodePipeline などのサービスがビルド サーバーを起動します。このサーバーはアプリケーションをビルドしてテストし、成功した場合は、完了したビルドを企業のサーバーに送信して更新します。自動スケーリングが設定されている場合は、必要に応じて迅速かつ簡単にロールバックするオプションを備えたブルー/グリーン デプロイメントでこれを実現できます。

（５）コンテンツ配信ネットワーク（CDN）内蔵

ビジネスにコンテンツ配信ネットワーク (CDN) を導入すると、配信時間を大幅に短縮できます。 AWS は世界的なクラウド コンピューティングの大手企業であるため、そのコンテンツ配信ネットワーク (CDN) には世界中にエッジ ノードがあります。他の多くのクラウドプロバイダーも同様のソリューションを提供しています。 Google のコンテンツ配信ネットワーク (CDN) は、インターネットを構成するインフラストラクチャの大部分を同社が実際に管理しているため、最も高速で柔軟性の高い CDN の 1 つです。

ビジネスはダウンタイムなしで移行できますか?

移行は長くて複雑なプロセスになりますが、ダウンタイムが長くなる必要はありません。多少のダウンタイムは発生する可能性がありますが、プロセスはほぼシームレスです。

企業は次の 2 つの戦略のいずれかを採用できます。

最初のオプションは、すべてのサーバーを一度に移動してネットワーク全体を切り替えるか、エンタープライズ アプリケーションの一部をクラウドに移動し、新しいサービスを使用するようにアプリケーションを更新することです。

2 番目のオプションはハイブリッド アプローチを採用することです。これは、最も有用なものだけを移行する方がコスト効率が高いため、ほとんどの大企業が選択するものです。 AWS には、オンプレミスのハードウェアとクラウド プラットフォームを統合して機能するサービスが多数あります。

最初のオプションは小規模な導入では簡単で、AWS のアプリケーション移行などのサービスを使用するとさらに簡単になります。このサービスを使用すると、サーバーのグループを EC2 にすばやく移動できます。コードの更新と構成は引き続き必要になる場合がありますが、ネットワーク全体をテスト環境に移動し、すべてをセットアップして、準備ができたら切り替えを実行できます。

いずれにしても、クラウドへの移行はビジネスにとって大きな決断であり、十分な調査と明確な計画に基づいて行う必要があります。組織の具体的な設定は大きく異なるため、実行するアプリケーションの種類に応じたベスト プラクティスを調査する必要があります。