次の方法で共有

eコマース ソリューションを Azure へ移行する

  • [アーティクル]

はじめに

企業にとって、既存の eコマース ソリューションをクラウドに移行することには多くのメリットがあります。これにより、スケーラビリティが実現され、24 時間 365 日のアクセシビリティを顧客に提供することができ、クラウド サービスの統合が容易になります。 しかし、eコマース ソリューションをクラウドに移行する作業は大掛かりなものとなり、コストについても意志決定者の理解を得る必要があります。 このドキュメントでは、オプションを提示することを目的に Azure の移行の範囲について説明します。 最初のフェーズは、IT 部門によるコンポーネントのクラウドへの移行から始まります。 Azure に移行した後は、eコマース チームが投資収益率 (ROI) を向上させ、クラウドを活用するために実行できる手順について説明します。

重大な決定を下すべきとき

グローバルな eコマース取引が小売売上高の総額に占める割合はごくわずかに過ぎませんが、その販売経路は年々着実に成長を続けています。 2024 年時点で、e コマースによる売上高は小売業全体の売上高の 5 分の 1 を占め、2016 年の 8.6% から増加しています ( 出典)。 クラウド コンピューティングの登場と共に、eコマースが成熟してくるにつれ、小売業者は岐路に立たされています。 選択しなければなりません。 進化し続けるテクノロジによってもたらされる新機能を用いたビジネス モデルを構想することも、既存システムのモダナイゼーションを計画することもできます。

カスタマー ジャーニーを向上させる

カスタマー ジャーニーに主に的を絞った eコマースには、さまざまな属性があります。 これらの属性は、発見、評価、購入、購入後という 4 つの主な領域に分類できます。

顧客の行動は、データとして取り込まれます。 ショッピング ファネルは、製品データ、トランザクション、インベントリ、配送、受注処理、顧客プロファイル、ショッピング カート、製品のおすすめなどを表示するために使用するアプリケーションへのコネクション ポイントをまとめたものです。

一般的なリテール ビジネスでは、顧客向けのアプリケーションから基盤となるアプリケーションまでソフトウェア ソリューションの大きなコレクションに依存します。 次の図は、一般的なリテール ビジネスに存在する機能を絵で表しています。

図は、外部から見える機能とコア機能を比較したものです。

クラウドは、組織がテクノロジを獲得し、使用し、管理する方法を一変させるチャンスを与えてくれます。 データ センターの維持にかかるコストの削減、信頼性やパフォーマンスの向上、サービスを後から追加できる柔軟性の実現など、その他にもメリットがあります。 このユース ケースでは、リテール ビジネスが既存のインフラストラクチャを Azure に移行するために選択できるフローに注目します。 また、リホスト、リファクター、リビルドといった段階的なアプローチを使用して、新しい環境を活用していきます。 多くの組織がこの一連のフローに従ってモダナイゼーションを行うかもしれませんが、ほとんどの場合、開始点としていずれかのフェーズに落ち着きます。 現在のアプリケーションを Azure にリホストすることを断念し、直接リファクターまたはリビルドから開始することを選択するかもしれません。 この決定は、組織のモダナイゼーションの必要を最適な形で満たすために、アプリケーション、そして組織によってそれぞれ異なったものとなります。

リホスト

"リフト アンド シフト" とも呼ばれますが、この段階では、物理サーバーと VM をクラウドにそのまま移行します。 現在のサーバー環境を IaaS に直接移行することによって、コスト削減、セキュリティや信頼性の向上といったメリットが得られます。 サイズを適切に設定した VM でワークロードを実行するといった手法によって、コストを削減できます。 今日、オンプレミスの VM や物理マシンの性能が、小売業者が通常の業務で必要とする性能を超えているということが多々見受けられます。 VM は、1 年に数回だけ発生する季節的なビジネス ピークに対応できるように備えておく必要があります。 その結果、オフピーク シーズン中には使用しない性能のためにも支払っていることになります。 Azure では、その時点のビジネス サイクルの需要に基づいて、適切なサイズの VM を選択します。

Azure にリホストするための 3 つのフェーズがあります。

  • 分析: アプリケーション、ワークロード、ネットワーク、セキュリティなどのオンプレミス リソースを識別し、一覧を作成します。 このフェーズの終わりには、既存システムの完全なドキュメントが作成されています。
  • 移行: 各サブシステムをオンプレミスから Azure に移行します。 この段階では、アプリケーションの通信を継続しながら、Azure をデータ センターの拡張機能として使用します。
  • 最適化: システムを Azure に移行する際、適切にサイズが設定されるようにします。 一部の VM に割り当てられているリソースが多過ぎることが判明した場合、VM のタイプを CPU、メモリ、ローカル ストレージが適切に組み合わされたものに変更します。

分析

次の手順を実行します。

  1. オンプレミスのサーバーとアプリケーションのリストを作成します。 このプロセスでは、エージェントまたは管理ツールを使用して、サーバー、そのサーバーで実行されているアプリケーション、現在のサーバー使用率、サーバーとアプリケーションの構成方法に関するメタデータを収集します。 結果として、環境内のすべてのサーバーとアプリケーションのレポートが生成されます。
  2. 依存関係を識別します。 ツールを使用して、相互に通信しているサーバーおよび相互に通信しているアプリケーションを識別します。 結果として、すべてのアプリケーションとワークロードのマップが生成されます。 これらのマップは、移行計画に送られ使用されます。
  3. 構成を分析します。 目標は、Azure で実行するのに必要な VM のタイプを把握することです。 結果として、Azure に移行できるすべてのアプリケーションのレポートが生成されます。 これらは、さらに以下のように分類できます。
    • 変更なし
    • 名前の変更など基本的な変更
    • わずかなコードの変更など小規模な変更
    • 移行に余分な作業を必要とする互換性のないワークロード
  4. 予算を作成します。 CPU やメモリなどをそれぞれ列挙したリストと各アプリケーションの要件は既に作成されています。 これらのワークロードを適切なサイズで設定された VM に配置します。 クラウド プラットフォームでは、使用量に基づいて費用が請求されます。 お客様のニーズを適切なサイズに設定された Azure VM にマップするツールがあります。 Windows VM または SQL Server を移行している場合、Azure での費用を削減する Azure ハイブリッド特典についても調べる必要があります。

Microsoft では、システムを分析し、カタログするための複数のツールを提供しています。 VMware を実行している場合、検出と評価をサポートする Azure Migrate を使用できます。 このツールは、Azure に移動できるマシンを識別し、実行する VM のタイプを提案し、ワークロードのコストを見積もります。 Hyper-V 環境では、Azure Site Recovery Deployment Planner を使用します。 数百以上の VM を移動する必要がある大規模な移行では、Azure 移行パートナーを利用できます。 これらのパートナーは、ワークロードを移行するための専門知識と経験を有しています。

Migrate

どのサービスをクラウドに移行するか、どのような順序で移行するかについて計画を開始します。 この段階でワークロードの移行も行うため、次の順序で実行します。

  1. ネットワークを構築する。
  2. ID システム (Microsoft Entra ID) を組み込みます。
  3. Azure でのストレージ部分をプロビジョニングする。

移行中、Azure 環境はオンプレミス ネットワークの拡張機能となります。 論理ネットワークと Azure Virtual Network を接続できます。 Azure ExpressRoute を使用することで、インターネットに接続したことのないプライベート接続で、ネットワークと Azure 間の通信を維持することもできます。 Azure VPN Gateway がオンプレミス VPN デバイスと通信するサイト間 VPN を使用することもできます。この方法では、すべてのトラフィックが Azure とネットワーク間の暗号化された通信を使用して安全に送信されます。 その接続を確立するには、ExpressRoute とサイト間の共存接続を構成するためのガイダンスに従ってください。

ネットワークを構成したら、ビジネス継続性について計画します。 オンプレミス データをクラウドに移行して、クラウドと既存のデータが同じであることを確認する、リアルタイム レプリケーションを使用することをお勧めします。 eコマース ストアを閉じることはありません。重複では、顧客に与える影響を最小限に留めながら、オンプレミスから Azure に切り替える機能を提供します。

データ、アプリケーション、および関連するサーバーの Azure への移行を開始します。 多くの企業では、Azure Site Recovery サービスを使用して Azure に移行します。 このサービスは、事業継続とディザスター リカバリー (BCDR) を目的としています。 これは、オンプレミスから Azure への移行に最適です。 実装チームの方は、「オンプレミスのマシンを Azure に移行する」を参照してください。

サブシステムを Azure に移行したら、テストを行い、すべて想定どおりに動作していることを確認します。 すべての問題が解決されたら、ワークロードを Azure に移動します。

最適化

この時点では、環境を監視し続け、環境の変化にワークロードが一致するように基盤となるコンピューティング オプションを変更します。 環境の正常性を監視する際は、必ず各リソースがどれほど使用されているかに注目する必要があります。 目標は、ほとんどの VM で使用率が 75 - 90% になるようにすることです。 極端に低い使用率で稼働する VM では、より多くのアプリケーションをその VM で実行するようにするか、適切なパフォーマンス レベルを保持する Azure 上の最もコストのかからない VM に移行することを検討します。

Azure には、環境を最適化するツールも用意されています。 Azure Advisor は、環境のコンポーネントを監視し、ベスト プラクティスに基づいてユーザーの環境に合わせた推奨事項を提示します。 この推奨事項は、アプリケーションを使用するリソースのパフォーマンス、セキュリティ、可用性の向上を図るのに役立ちます。 Azure portal では、アプリケーションの正常性に関する情報も把握できます。 ご使用の VM で、Linux および Windows 向けの Azure 仮想マシン拡張機能を活用してください。 これらの拡張機能では、デプロイ後の構成、ウイルス対策、アプリの監視といった機能を利用できます。 また、Network Watcher、Service Map、Application Insights、Log Analytics など、ネットワーク診断、サービスの使用状況、サービスを介したアラートに関するその他の Azure サービスも利用できます。

組織の一部のシステムが Azure で最適化されている中、開発チームは移行後のフェーズ、つまりリファクターを開始することができます。

リファクター

移行が完了したら、eコマース アプリケーションは、Azure で新しいホームのメリットを使い始めることができます。 リファクター フェーズは、環境全体が移行が完了するまで待つ必要はありません。 CMS チームの移行が完了したものの、ERP チームがまだ完了していないといった場合でも、問題ありません。 CMS チームは、リファクタリングの作業を開始できます。 この段階で追加の Azure サービスを使用して、アプリケーションをリファクタリングすることにより、コスト、信頼性、パフォーマンスを最適化します。 リフト アンド シフトでは、プロバイダーが管理するハードウェアと OS しか利用できませんでしたが、このモデルではクラウド サービスを利用してコストを削減することもできます。 アプリケーション コードや構成を少し変更するだけで、現在のアプリケーションのそのまま利用し、コンテナー、データベース、ID 管理システムなどの新しいインフラストラクチャ サービスにアプリケーションを接続します。

リファクタリング作業で変更するコードと構成はほんのわずかです。 ほとんどの場合、この段階で採用されるテクノロジはリソースを構築してデプロイするスクリプトに依存するため、つまりデプロイ手順はスクリプトで行うため、オートメーションにより専念することになります。

さまざまな Azure サービスを利用できますが、リファクター フェーズで使用する最も一般的なサービス、つまりコンテナー、アプリ サービス、データベース サービスに焦点を当てます。 なぜリファクタリングに注目するのでしょうか。 リファクタリングでは、無理のない範囲でコードの負債を保持することで、長期的なコストを削減する強力なコード基盤を提供します。

コンテナーは、アプリケーションをバンドルする方法を提供します。 コンテナーがオペレーティング システムを仮想化する手法のおかげで、1 つの VM に複数のコンテナーをまとめることができます。 まったくコードを変更せずに、またはいくつかコードを変更するだけで、アプリケーションをコンテナーに移動することができます。構成は変更しなければならない場合があります。 この作業は、アプリケーションをコンテナーにバンドルするスクリプトの記述につながります。 開発チームは、リファクタリング期間に、これらのスクリプトの記述とテストを行います。 Azure では、Azure Kubernetes Service (AKS) と、コンテナー イメージを管理するために使用できる関連する Azure Container Registry を介してコンテナー詰めをサポートします。

アプリ サービスでは、さまざまな Azure サービスを利用できます。 たとえば、RabbitMQ のようなキューにメッセージを配置することで、既存のインフラストラクチャで顧客の注文を処理できます。 (たとえば、1 つのメッセージで顧客に請求し、2 つ目のメッセージで注文の品を出荷します)。リホストするときは、別の VM に RabbitMQ を配置します。 リファクタリングの際には、Service Bus キューまたはトピックをソリューションに追加できます。 そのときに RabbitMQ コードを書き換えれば、キュー機能を提供していた VM の使用をやめることができます。 すべてのコードを一度に書き換えるのが現実的でない場合は、メッセージング ブリッジなどのパターンを採用してメッセージング キュー間をつなぐことができます。 そうすれば、エンドポイントを一度にすべて移行せず、1 つずつ移行することが可能になります。 どちらの方法でも、最終的にすべてのエンドポイントを Azure Service Bus に移行することで、一連の VM を常時オンのメッセージ キュー サービス 1 つに置き換え、コストを削減できます。 Azure portal には、その他のアプリ サービスもあります。

データベースについては、VM からサービスにデータベースを移行できます。 Azure では、Azure SQL Database および Azure SQL Managed Instance で SQL Server のワークロードをサポートします。 データ移行サービスはご使用のデータベースを評価し、移行前に行う必要のある処理について知らせ、それからデータベースを VM からサービスに移行します。 Azure では、MySQL、PostgreSQL、およびその他のデータベース エンジンのサービスもサポートしています。

[再構築]

ここまで、eコマース システムへの変更を最小限に留める努力をしてきました。稼働しているシステムはそのまま残してきました。 これから、クラウドのメリットを利用する方法について考慮します。 この段階では、PaaS または SaaS のサービスとアーキテクチャを積極的に採用することにより、既存のアプリケーションを変更します。 このプロセスでは、新機能を追加するか、クラウドのアプリケーションを再設計するため、大掛かりな変更が発生します。 マネージド API は、クラウド システムを活用する新しい概念です。 サービス間の通信用の API を作成して、システムを簡単に更新することができます。 2 つ目のメリットは、所有しているデータから分析情報を得られることです。 マイクロサービス プラス API アーキテクチャに移行し、機械学習とデータを分析するための他のツールを使用することによって、これを行います。

マイクロサービス プラス API

マイクロサービスは、外部と接続する API を介して通信します。 各サービスは自己完結型であり、1 つのビジネス機能を実装させる必要があります (たとえば、顧客に商品を提案する、ショッピング カートを維持するなど)。 アプリケーションをマイクロサービスに分解するには、時間と計画が必要です。 マイクロサービスを定義する明確なルールはありませんが、大抵一緒に変更するコンポーネントをまとめて、デプロイ可能なユニットを減らすようにするのが一般的です。 マイクロサービスを使用すると、全体的なアプリケーションのテスト負荷を削減しながら、必要な頻度で変更をデプロイできます。 一部のサービスは、非常に小さくなる可能性があります。 そのため、Azure Functions を使用してサーバーレスを進めると、使用していないときにリソースを消費しないようにしながら、呼び出し元の必要に応じてスケールアウトすることができるようになります。 その他のサービスは、製品の管理、顧客の注文の取り込みなど、ビジネス機能に基づいて分けられます。

サーバーレスのメカニズムには難点もあります。負荷が軽いときに、クラウド内のサーバーがコードを構成して実行するのに数秒かかるため、応答が遅くなる可能性があります。 顧客による商品の検索、注文、返品要求など、環境内の顧客によってよく使われる部分については、迅速かつ容易に対応できるようにしておきたいと思われるかもしれません。 パフォーマンスが低下してしまうと、ショッピング ファネルで顧客を失ってしまうリスクがあります。 迅速に対応する機能を既に備えていれば、Azure Kubernetes Service で個別にデプロイ可能なユニットとしてその機能をリビルドします。 大量のメモリ、複数の CPU、たくさんのローカル ストレージを組み合わせる必要があるサービスなどのケースでは、自社の VM でマイクロサービスをホストする方が良い場合もあります。

各サービスは、相互作用に API を使用します。 API へのアクセスでは、マイクロサービスに直接接続できますが、その場合、サービスと通信する側がアプリケーション トポロジを把握している必要があります。 API Management のようなサービスでは、API を発行する一元的な方法が提供されます。 すべてのアプリケーションは、API Management サービスに接続するだけで済みます。 開発者は使用可能な API を検出できます。 API Management サービスは、リテール環境のパフォーマンスを向上させる機能も提供します。 このサービスは、アプリケーションのさまざまな部分に分けて API へのアクセスを制限したり (ボトルネックを避けるため)、値の変更に時間のかかる応答をキャッシュしたり、JSON から XML に変換したりできます。 ポリシーの完全な一覧については、こちらをご覧ください。

データと Azure Marketplace を使用する

すべてのデータとシステムを Azure に配置しているため、ビジネスに他の SaaS ソリューションを簡単に組み込むことができます。 すぐに行えることがあります。 たとえば、Power BI を使用してさまざまなデータ ソースを 1 つにまとめることができます。これにより、視覚化を実現し、レポートを生成して、分析情報を得ることができます。

次に、Azure Marketplace で提供されるサービスに注目してください。これは、在庫の最適化、顧客の属性に基づいたキャンペーンの管理、好みや履歴に基づいた各顧客への適切なアイテムの表示などを実現するのに役立ちます。 Marketplace オファリングで機能するデータを構成するのに少し時間がかかります。

コンポーネント

リホスト中に以下が使用されます。

  • Azure Advisor は、ベスト プラクティスに従って Azure デプロイメントを最適化できるようにする、個人用に設定されたクラウド コンサルタントです。
  • Azure Migrate サービスは、Azure への移行についてオンプレミスのワークロードを評価します。
  • Azure Site Recovery では、Azure VM、オンプレミス VM、物理サーバーのディザスター リカバリーを調整および管理します。
  • Azure Virtual Network では、Azure Virtual Machines (VM) などのさまざまな種類の Azure リソースが、他の Azure リソース、インターネット、およびオンプレミスのネットワークと安全に通信することができます。
  • Azure ExpressRoute を利用すると、接続プロバイダーが提供するプライベート接続を介して、オンプレミスのネットワークを Microsoft クラウドに拡張できます。

リファクター中に以下が使用されます。

  • Azure Kubernetes Service を使用すると、ホストされている Kubernetes 環境を管理できます。これによって、コンテナー オーケストレーションの知識がなくてもコンテナー化されたアプリケーションを迅速かつ簡単にデプロイおよび管理できるようになります。
  • Azure SQL Database は、Microsoft Azure における汎用リレーショナル データベース管理サービスです。 これは、リレーショナル データ、JSON、空間、XML などの構造をサポートします。 SQL Database には、マネージド シングル SQL データベース、エラスティック プール内のマネージド SQL データベース、および SQL マネージド インスタンスが用意されています。

リビルド中に以下が使用されます。

  • Azure API Management が組織にもたらす利点は、外部のパートナーや社内の開発者に API を公開することによって、社内に眠っているデータやサービスの可能性を発掘できることです。
  • Azure Functions を使用すると、クラウドで小さなコードの集まりまたは "関数" を簡単に実行できます。
  • Power BI は、組織全体に分析情報を提供できるビジネス分析ツール スイートです。

まとめ

e コマース システムを Azure に移行するには、分析および計画と共に、明確に定められたアプローチが必要になります。 リホスト、リファクター、リビルドの 3 段階のアプローチについて考慮しました。 これらのアプローチでは、各ステップで生じる変更を最小限に抑えながら、作業中のフェーズから次のフェーズに移ることが可能になります。 小売業者は、リホストをスキップして、コンポーネントのリファクターまたはリビルドを行うこともできます。 多くの場合、これでモダナイゼーションへの明確な道筋が見えてきます。後はできるときに行うだけです。 Azure での経験を重ねるにつれ、新しい機能の追加、コストの削減、システム全体の改善といった機会が見えてくるでしょう。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

  • Scott Seely 氏 | ソフトウェア アーキテクト
  • Mariya Zorotovich | カスタマー エクスペリエンス、HLS、エマージング テクノロジー担当責任者

次のステップ

多くの開発チームは、技術的負債に対処し、より効率的にキャパシティを使用するために、リホストとリファクターを同時に実行しようと模索します。 次の手順に進む前に、リホストを行うことにはメリットがいくつかあります。 新しい環境にデプロイする際に生じる問題を診断して修正するのが簡単になります。 これにより、開発チームとサポート チームに、Azure を用いた新しい環境に慣れる時間を与えることができます。 システムのリファクーとリビルドを開始するときには、安定して稼働しているアプリケーションの上に構築していくことができます。 そして、加える変更をより小さく、的を絞ったものにし、更新の頻度を増やすことができます。

製品ドキュメント: