クラウド移行のアンチパターン

多くの場合、お客様がクラウドを導入する際に、その移行フェーズでアンチパターンが発生します。 次の方法は、移行のアンチパターンを避けるのに役立ちます。

  • セキュリティとコンプライアンスのガードレールが配置されていることを確認する。
  • アプリケーションとサーバーの潜在的な依存関係について理解する。
  • 徹底的な評価に基づいてアーキテクチャを選択する。

アンチパターン: ガードレールを使用せずに移行、最新化、またはイノベーションを行う

お客様は、最初のワークロードをクラウドにデプロイするときに、革新的なソリューションをテストするためのプラットフォームとして考えます。 クラウド内で利用できる柔軟性が得られます。 しかし、これらのワークロードで生産性が向上するか、会社のデータを保持する必要があるか、あるいは会社のシステムにアクセスする必要がある場合は常に、コンプライアンス、規制、およびセキュリティ標準に従う必要があるため、進行が遅れます。

例: セキュリティ ガードレールを省略する

会社ではオンライン ショップを最新化し、ユーザー エクスペリエンスを向上させたいと考えています。 最新化は、オンライン ショップ Web サイトと基になる在庫データベースを Azure に移行することによって行う必要があります。 在庫データベースと会社の SAP システムの間に依存関係が存在するため、これらのシステムで通信を行う必要があります。 そのため、会社ではハイブリッド クラウドを構築する必要があります。

オンライン ショップ チームは革新的であるため、アプリケーションの最新化を開始しますが、ハイブリッド接続であるため、セキュリティ要件は考慮しません。 チームがアプリケーションをテストするときに、セキュリティとコンプライアンスの要件が満たされていないため、IT セキュリティ チームが Azure とオンプレミスのシステム内での通信を許可していないことがわかりました。

推奨される結果: セキュリティとコンプライアンスのガードレールを確立する

ワークロードをクラウドに移行する前に、セキュリティとコンプライアンスのガードレールを配置します。 これらのガードレールがあれば、ワークロードでセキュリティとコンプライアンスの要件に確実に従うようになります。 クラウド ガバナンスとクラウド セキュリティ チームが、Azure ランディング ゾーン内にガードレールを提供するようにします。 特にハイブリッド ワークロードの場合は、ガードレールについて IT チームに確認してください。 高速で一貫性のあるコンプライアンスに準拠した安全な方法で作業できるように、ワークロード チームをサポートするガードレールを定義するのに役立つ「クラウド導入フレームワークのエンタープライズ規模ランディング ゾーン アーキテクチャ」を参照してください。

アンチパターン: 評価せずに移行、最新化、またはイノベーションを行う

移行または最新化プロジェクトを検討している会社は、より正確な計画を実現するために、潜在的なアプリケーションとサーバーの依存関係を理解する必要があります。 アプリケーション イノベーション シナリオでは、会社は目的のないエンジニアリング作業ではなく、アーキテクチャ デザイン セッションと参照アーキテクチャを使用して、より多くの成功を体験できます。

例: 綿密に計画せずに移行することでダウンタイムが発生する

あるチーム メンバーはアプリケーションをクラウドに移行して、会社の二酸化炭素排出量を削らすことを計画しています。 移行する最初の資産を特定する移行プランは、構成管理データベース (CMDB) のエントリと 1 人のアプリケーション所有者のインタビューに基づいています。 そのチーム メンバーがアプリケーションのデータベース サーバーの 1 つを移行した後、他の複数のアプリケーション所有者は、彼らのアプリケーションが正常に動作していないと IT チームに不満を漏らしています。 CMDB に示されている依存関係が正確ではなくなったため、他のアプリケーションで予期しないダウンタイムが発生しています。

推奨される結果: 移行または最新化の前にインフラストラクチャを評価する

大規模な移行または最新化プロジェクトの場合は、移行を開始する前にインフラストラクチャの評価を行います。 この評価は、依存関係と互換性の問題を特定するのに役立ちます。 詳細については、Azure 移行ガイド移行のベスト プラクティスをご覧ください。

最新化プロジェクトでは、追加のアプリケーション評価を使用して、コードのアンチパターン、互換性の問題、および技術的負債を特定します。 最新化の側面の詳細については、「Azure へのアプリケーション移行例の概要」を参照してください。

イノベーション プロジェクトについては、「Azure の革新的なソリューションのガイドの概要」を参照してください。これは、革新的なクラウド ソリューションを計画および開発するのに適した方法を特定するのに役立ちます。

ミッション クリティカルなワークロードまたはアーキテクチャの変更が必要なワークロードの場合は、Azure Well-Architected フレームワークまたはアーキテクチャ デザイン セッション (ADS) を使用すると、企業内でスケーリングできる高品質で堅牢なアーキテクチャを設計、構築、デプロイするのに役立ちます。 ADS ホワイトボードを使用して、ソリューションの検出、構想、計画を行います。

アンチパターン: アーキテクチャを決定する

ある会社ではクラウドで開発する際に、マイクロサービス ファーストの戦略を追求することがあります。その場合、マイクロサービス アーキテクチャが常に従来のモノリシック アーキテクチャより高性能であると想定します。 その会社でアプリケーションについて適切なアプリケーション評価とデュー デリジェンスが行われないと、この戦略が失敗する可能性があります。 そのアプリケーションには他のアーキテクチャ アプローチがより適している場合があります。 すべての状況に対してマイクロサービス アーキテクチャまたはアーキテクチャを選択または決定すると、多くの場合、プロジェクトが失敗することになります。

例: すべてのアプリケーションに対してマイクロサービス アーキテクチャを使用する

ある会社の最高情報責任者 (CIO) は、クラウドで新しいアプリケーションをビルドするときに、マイクロサービス アーキテクチャを使用するポリシーを確立します。 その会社の開発者は、マイクロサービス アーキテクチャに携わったことがありません。 シンプルな Web アプリを開発する必要があります。 その開発者は、数か月間アプリケーションで作業した後、モノリシック アーキテクチャで作業を開始していた場合、開発が既に完了している可能性があったということに気付きます。 その会社では、数ある利点のうち、市場投入までの時間の短縮が実現していません。

推奨される結果: 評価に基づいてアーキテクチャを決定する

特定のアーキテクチャ スタイルにこだわらず、ユースケースまたはアーキテクチャの評価とデュー デリジェンスに基づいて、アーキテクチャを決定します。 自由に選択できるのがクラウドの主な利点の 1 つであるため、使用できるアーキテクチャを制限しないようにしてください。 流行っているからといってアーキテクチャを選ぶのは、避けるべきアンチパターンです。 詳細については、「Azure アプリケーション アーキテクチャ ガイド」と「クラウド設計パターン」を参照してください。

アンチパターン: 単一のサブスクリプションを使用する

会社では多くの場合、すべてのワークロードをホストするために 1 つのサブスクリプションのみを使用することを決定します。 通常、このような選択は、何よりも速さが求められる迅速な移行を実装する場合に行います。 この決定により、ランドスケープは管理と設計が十分でないものとなります。 これらの会社ではすぐにサブスクリプションの制限に達する可能性があります。つまり、アーキテクチャを設計し直す必要があります。

例: 1 つのサブスクリプションの下に移行する

ある複合企業では、そのホテル部門を別の会社にスピンオフすることにしました。 ホテル部門では、その IT 資産を新しい場所に移動または移行する必要があります。 新しいホテル会社では、クラウド ファーストのアプローチを選び、すべての IT 資産をクラウドに移行します。 時間の制約により、新しい会社ではすべてを 1 つのサブスクリプションに移行し、大規模な仮想ネットワークを使用します。この場合、職務とセキュリティ モデルを適切に分離する可能性がほとんどありません。 スピンオフが完了して 3 か月後に、ホテル会社はその資産が以前よりも安全ではなく、管理されておらず、サブスクリプションの制限に達することに気付きました。

推奨される結果: セグメント化戦略を使用する

Azure に移行する前に、さまざまな職務を分離し、異なる環境を計画します。 異なるステージを 1 つのサブスクリプションにまとめると、すぐにサブスクリプションの制限に達する可能性があります。 セグメント化戦略を確立し、より簡単にガバナンスとコンプライアンスを実装できるようにします。

次のステップ