最新のアプリケーション プラットフォームの計画
クラウド導入フレームワークの計画方法論を使用して、クラウド導入計画全体を作成し、クラウドベースのデジタル変革に関わるプログラムとチームをガイドできます。 このガイダンスでは、バックログを作成するためのテンプレートと、チーム全体で必要なスキルを構築するための計画を、クラウドで実行しようとしている内容に基づいて提供します。
計画方法論の適用では、デジタル資産の合理化の 5 R に焦点を当てます。 クラウドへの最も一般的なパスでは、移行と最新化のプロセスのスピード、効率性、再現性に重点が置かれます。 通常、計画では 5 つの R から、リホスト オプションが優先され、再設計と再構築のオプションに対する並列サポートは限定的です。
デジタル資産
デジタル資産を計画するときは、インベントリ データを収集し、資産を合理化することを考えます。 コンテナー導入計画では、VM、データ、アプリケーションなどのすべての資産が、サポートするワークロード別にグループ化されていることが重要です。 グループ化と基本的な合理化が完了したら、これらのワークロードを評価して、パッケージとリホストまたは再構築のオプションを決定できます。
標準的なクラウド導入計画テンプレートでは、一般的なクラウド導入処理に必要な作業の種類が考慮されています。 しかしながら将来的には、ワークロードをコンテナーにパッケージ化し、コンテナーのプロビジョニングをオーケストレーションするタスクを計画に追加する必要があるでしょう。
注意事項
この記事では、読者が Azure DevOps でのクラウド導入計画の構築に関する記事シリーズで説明されているベスト プラクティスに既に従っていることを前提としています。 スプレッドシートまたは他のプロジェクト追跡ツールでクラウド導入計画を追跡している場合でも、以降のセクションを適用できますが、計画にデータを追加する実践の手順は調整する必要があります。
警告
最新のアプリケーション プラットフォーム戦略を標準の移行プロセス (または移行ファクトリ) に組み込むには、移行前のワークロード アーキテクチャの設計に関連するタスクの成熟した実装が必要です。 これらのタスクなしでこの戦略を進めると、移行作業が遅れ、デプロイされるコンテナー ホストとサポート ワークロードに対して適切なアーキテクチャ上の決定を下せなくなる可能性があります。
候補となるワークロードを特定する
最新のアプリケーション プラットフォーム シナリオでは、より効率的な移行プロセスよりも、より多くの先行投資を必要とする長期的なリターンが優先されます。 長期的な投資は、特定のワークロード グループに対するイノベーションの有効化と運用の合理化への取り組みの強化という形で、計画の特定の部分で表されます。
戦略と計画の調整を開始するには、クラウド導入戦略に最新のアプリケーション プラットフォームを追加することで影響を受ける可能性があるワークロードを特定します。 これらの前提条件は、技術的な変更を実装する前に検証されます。 潜在的な候補を特定するには、ワークロードのポートフォリオ内で次の条件を探します。
- アクティブな開発または DevOps 投資: 実稼働ワークロードの一定の割合は、アクティブな開発の対象となります。 一部は、継続的な DevOps プラクティスで管理される場合もあります。
- ワークロードの移植性: 一部のワークロードは、コンプライアンス、データ保護、または運用上の制約の影響を受け、プライベート クラウド、エッジ、または複数のパブリック クラウド プロバイダー間の移植性が必要な場合があります。
- ワークロードの統合: 多くのワークロード (特に使用率の低いワークロード) は、コンテナー ホストの統合の候補になる可能性があります。その結果、サーバーまたは VM の数が減り、運用コストが削減されます。
- レガシ ワークロード: レガシ ワークロードが、オペレーティング システムの更新を妨げ、さらにはクラウドへの移行を妨げる可能性があります。 Azure の機能と互換性がないレガシ ワークロードは、コンテナー ホストでの移行の候補になる可能性があります。
候補となるワークロードを文書化する
Note
次の考慮事項の一覧は、上の条件で特定された移行候補についてのみ文書化する必要があります。
クラウド導入計画を策定する際に、ワークロードの定義と優先順位付けのガイダンスに従って、各ワークロードを文書化します。 最新のアプリケーション プラットフォーム シナリオの候補であるワークロードには、プランの実行をガイドする追加情報が必要となります。 この記事では、ワークロードを定義するためにビジネスと技術的な入力を文書化することの重要性について説明しています。 最新のアプリケーション プラットフォームの候補について、次のデータ ポイントをワークロードの定義に追加する必要があります。
業務的な入力
最新のアプリケーション プラットフォーム戦略にワークロードを含めるという決定に影響する可能性があるビジネス関連のデータ ポイントを次に示します。
- コンプライアンス要因: プライベート クラウドでこのワークロードをホストする際の考慮事項の要因となっている具体的なコンプライアンス基準は何ですか?
- データ保護要因: プライベート クラウドでこのワークロードをホストする際の考慮事項の要因となっているデータ保護対策は何ですか?
- 運用上の制約: プライベート クラウドでこのワークロードをホストする際に考慮すべき運用上の制約は何ですか?
- 最新アプリケーション プラットフォームの成果: このワークロードをコンテナー候補として評価する背後にある要因は、次のどれですか? DevOps、移植性、統合、レガシ、またはこれらの複数の要因。
- 運用モデル: このワークロードは(中央 IT/CCoE によって) 集中管理されるか、(ワークロード チームによって) 個別に管理されるか、またはエンタープライズ運用 (中央サポートとワークロード固有の運用) で管理されるか。
技術的な入力
最新のアプリケーション プラットフォーム戦略にワークロードを含めるという決定に影響する可能性がある、テクノロジ チームからのデータ ポイントを次に示します。
場所の考慮事項:
ワークロードがホスティングされる場所に関連する考慮事項。
- パブリック クラウドのホスティング要件: パブリック クラウドの要件に関連する具体的な技術的制約はありますか?
- プライベート クラウドのホスティング要件: プライベート クラウドの要件に関連する具体的な技術的制約はありますか?
- エッジのホスティング要件: エッジの要件に関連する具体的な技術的制約はありますか?
- 移植性の要件: クラウドの移植性の要件に関連する具体的な技術的制約はありますか?
運用の考慮事項:
プラットフォーム、ホスト、ワークロードの運用に関連する考慮事項。
- プライマリ クラウド プラットフォーム: 組織は、運用管理ツールを提供するプライマリ クラウド プラットフォームを定義する必要があります。 組織によっては、さまざまな種類の運用を管理するためのプライマリ クラウド プラットフォームが複数ある場合があります。 このワークロードを運用するプライマリ クラウド プラットフォームは何ですか?
- 追加の運用プラットフォーム: このワークロードは、追加の運用プラットフォームでも管理されますか?
- クラウドのホスティング要件: このワークロードには、特定のクラウド ホスティング戦略が必要ですか? パブリック クラウド、プライベート クラウド、またはクラウドの移植性
- 標準化されたオーケストレーション プラットフォーム: 会社にコンテナー オーケストレーションの標準ソリューションがある場合は、考慮対象となる標準化されたプラットフォームの名前を含めます。 例: Azure Kubernetes Service (AKS)、AKS エンジン、Kubernetes。
- カスタム オーケストレーションに関する考慮事項: 非標準のコンテナー オーケストレーション プラットフォームの要件はありますか? ある場合は、その要件について説明します。
- 標準化されたホスト運用: ワークロードは非敵対的であり、標準化されたホスト運用でサポートされている共有コンテナーでホスティングできることが想定されています。 このワークロードは、このアプローチと互換性がありますか?
- カスタマイズされたホスト運用に関する考慮事項: ワークロードが標準化された運用と互換性がない場合、このワークロードのホスト運用手順を確立するときに考慮する必要がある具体的な要件は何ですか?
アプリケーションの考慮事項:
アプリケーションの開発方法と今後の開発方法に固有の考慮事項。
- サービスとしてのプラットフォーム (PaaS) ランタイム: パブリック クラウド プロバイダーは、サービスとしてのプラットフォーム (PaaS) オファリングと呼ばれる、一貫性のあるアプリケーション ランタイムを生成します。 Azure では、PaaS は Azure App Service により提供されます。 このアプリケーションは PaaS ランタイムで運用できますか? 互換性が最も高いのはどのランタイムですか?
- 標準化されたランタイム: アプリケーションが PaaS ランタイムと互換性がない場合、組織によって提供される標準化されたランタイムがありますか? このワークロードは、どのランタイムで構築されますか?
- カスタム ランタイムに関する考慮事項: このワークロードに対してカスタマイズされたランタイムが必要な具体的な考慮事項は何ですか?
- ランタイムの制約: 選択したランタイムによってアプリケーションに課される制約はありますか?
- アプリケーションの依存関係: このワークロードは、特定の場所 (パブリックやプライベートなど) に存在する既存のシステムに依存していますか? たとえば、特定のソリューションで実行されている SAP などの ERP システムがあります。
- データの重力: このワークロードは、特定の場所 (パブリックやプライベートなど) に存在するデータ ソースに依存していますか? たとえば、SAP のデータや他の一元化されたデータ ソースへの依存関係が含まれます。
- 承認済みリストに関する考慮事項: カスタム運用に関する考慮事項は、クラウド プラットフォーム内での使用が承認されていますか? デプロイに含める必要がある承認済みのサービスは何ですか?
初期コンテナーに関する考慮事項
ワークロードをコンテナーにパッケージ化することが、スケジュールして作業する必要がある 1 番目の作業です。 2 番目は、これらのコンテナーのホスティングを計画します。
標準化されたランタイム、オーケストレーション、運用のための PaaS ソリューション
ワークロードの中には、自己完結性が高く、Kubernetes のような大規模なプラットフォームに付属する高度な制御やインフラストラクチャの要件の恩恵を必ずしも受けられないものもあります。 ワークロードがコンテナー化されているからといって、Kubernetes にデプロイしなければならないというわけではありません。 Azure には、ポートフォリオ内でワークロードを実行できるように、AKS で必要な管理とインフラストラクチャのレベルを必要としないさまざまなソリューションが用意されています。 次のソリューションではそれぞれ、このアプローチに従って計画を立てます。
複雑性の増加が予想されず、上記のソリューションの目的と制限に沿っているワークロードについては、より軽量のソリューションをコンテナーに使用することを検討してください。
パブリック クラウドでのカスタムのランタイムと運用を使用した標準化されたオーケストレーション
これらのワークロードが、フル マネージドの PaaS プラットフォームで実行できずインフラストラクチャレベルの制御で中継する必要がある、コンテナー オーケストレーターにより提供されるような高度なデプロイ機能を使用したい、またはモジュールの複雑化が予想される場合は、Azure Kubernetes Service (AKS) を利用します。 AKS により、両方のコンテナー ホスティングが解決されるだけでなく、広範なアーキテクチャ、SRE、セキュリティ、デプロイ、監視、インフラストラクチャのオプションも提供されます。
プラットフォームの機能セットには、クラスター オペレーター レベルとワークロード レベルの両方でプラットフォームを学習する要件があります。 運用チーム、アーキテクチャ チーム、ワークロード エンジニアリング チームの教育を移行タイムラインに組み込みます。 また、AKS はプラットフォームであるため、ワークロード チームが、このプラットフォーム内の責任の分離と、現在のホスティング配置について確実に理解するようにします。 これはいくつかの点では似ているかもしれませんが、他の点では新しいものになるでしょう。
パブリック クラウドでのカスタマイズされたオーケストレーション、ランタイム、運用
非常に特殊なワークロードまたは特定の組織要件について、Azure には、コンテナーのオーケストレーション領域に他の主要なプラットフォームが 2 つ用意されています。
- Azure Red Hat OpenShift
- Azure Service Fabric
代替案を検討すべき理由がある場合は、すべてのプラットフォーム オプションの利点とトレードオフを理解するための時間を確保してください。 Azure の既定のソリューションは AKS です。このドキュメントでは、AKS テクノロジを選択していることを前提としています。
クラウド プラットフォーム間での運用の標準化
多くの場合、お客様は、プライベート クラウド、エッジ、パブリック クラウドの環境にさまざまなコンテナー オーケストレーターをデプロイします。 これらの異なるクラウド プラットフォーム全体で運用を標準化するために、顧客はクラウド運用ツールを複数のクラウド プラットフォームに拡張することで、統合された運用アプローチを組み込むことができます。
Azure では、さまざまなコンテナー ホストを Azure Arc for Kubernetes にオンボードすることによって、複数のオーケストレーター間の運用を標準化できます。 このツールにより、各コンテナー ホストで一貫した監視、運用、ガバナンスを行うことができます。
プライベート クラウドとエッジ環境でのアプリケーション ランタイム
ワークロードをプライベート クラウドまたはエッジ環境で実行する必要があるが、ワークロードのサポートに最も適しているのが PaaS ランタイムである場合には、Azure App Service を使用して、一貫性のある PaaS ランタイム上で開発者が構築できるようにするツールがいくつかあります。
- Azure Stack HCI: Azure Stack にネイティブで Azure App Service をホスティングし、Azure Stack オペレーターによって管理することができます。
- Azure Stack HCI for AKS: Azure Stack 内の AKS で実行されるカスタム ランタイムをホスティングし、他の Kubernetes ソリューションへの移植性を確保するために Azure Stack および AKS のオペレーターによって管理することができます。
- Azure Arc を使用した Kubernetes 上の Azure App Service: 任意の Kubernetes ホストで Azure にアプリケーション サービスを提供できるようにします。 すべてのホストが Azure App Service の小さなインスタンスになります。 各ホストは Azure Arc にもオンボードされるため、これらのホストは、一貫性のあるクラウド ベースのホスト運用によって管理することもできます。
最新のアプリケーション プラットフォームの準備計画
クラウド導入のスキルアップ計画に加えて、クラウド導入チームは、計画を実行する前に、コンテナーと Kubernetes に関連するスキル開発が必要になる場合があります。
ワークロード チームが移行計画を文書化およびドライランするための時間を確実に割り当てます。 既存のアプリケーションまたは外部システム (このワークロードに依存する依存関係とシステムの両方) を変更し、移行作業をサポートするために柔軟性を高める必要がある場合があります。 これは、運用前環境と運用環境の両方に当てはまります。
次のステップ: 環境または Azure ランディング ゾーンを確認する
次の一連の記事には、クラウド導入作業において、クラウド導入シナリオの成功に役立つ特定のポイントについて説明されています。