現在のワークロードおよびアーキテクチャのインベントリ作成
現在のワークロードおよびプラットフォーム・アーキテクチャを調べて、クラウド導入の目標に最も関連の強い属性を特定します。
評価プロセス
属性マトリックスを組織的に作成することをお薦めします。小さいものから始めて、反復します。可能な場合は、最初に、考慮するアプリケーションのスコープを限定します。
実行する全体的なプロセスは次のとおりです:
これらのアプリケーションのコア属性に基づいて、アプリケーションのマトリックスを作成します。複数のアプリケーションが同じアーキテクチャ・スイートに属している場合は、それらをグループとして評価できます。次に、各属性の有限の値リストを特定します。
アプリケーション、属性および属性値のマトリックスを反復します。
反復する中で、新しい属性を特定したり、属性を結合したり、属性の値を変更することがあります。また、アプリケーションのリストや、それらをグループ化する方法を調整することもあります。たとえば、最初にレイテンシ属性を高レイテンシ、中レイテンシまたは低レイテンシの値として定義するとします。さらに評価した後、コロケートとリモート・トレラントのどちらでレイテンシの要件がより適切に定義されているかを判断します。
マトリックスは、アーキテクチャと移行に関する意思決定に役立つのに十分な記述を含める必要がありますが、認知決定空間に収まる大きさにする必要があります。評価のスコープが組織のITポートフォリオ全体にわたる場合は、統合された高位レベルのマトリックスを作成することを検討してください。
評価するアプリケーションの初期スコープを定義します。
最終的には、移行する予定のすべてのワークロードを評価する必要があります。ただし、最初の数回の反復では、評価するワークロードのサブセットを優先する必要があります。ビジネス目標で特定のアプリケーションまたはターゲット目標が特定されていると、どのアプリケーションを優先するかを決定するのに役立つため、理想的です。
アプリケーションの完全なセットを調査します。
移行する予定の完全なアプリケーション・セットのコンテキストで、既存の属性を再評価します。追加の考慮を必要とする重要な情報を特定した場合は、それをマトリックスに追加します。たとえば、レイテンシまたは統合の詳細が初期スコープに含まれていなかったために、データの依存関係が見つかる場合があります。他の例として、廃止または移行の計画のための労力を投入する必要がある主要なレガシー・テクノロジを特定したために、さらに詳細な評価が必要になる場合もあります。
評価する属性
この項に示す属性は、既存のワークロードおよびプラットフォーム・アーキテクチャを評価するための開始点として使用してください。
ビジネス目標および移行予定のアプリケーションによっては、属性間で関連の強さに差がある場合があります。用語は、自身の組織内で使われている用語に読み替えることをお薦めします。既存の制約およびビジネス目標の多くが、これらの属性に反映されます。
戦略的機能を評価します:
たとえば、Geoffrey Mooreのコア/コンテキスト・モデルのバージョンをITポートフォリオに適用します。機能をミッション・クリティカルおよび非ミッション・クリティカルとしてラベル付けします。機能を差別化または運用として識別する2番目のラベルを適用します。
ビジネス目標でイノベーションが重視されている場合、初期アーキテクチャでは、まだクリティカルになっていないアプリケーションではなく差別化にフォーカスを置く必要があります。
ビジネス目標で運用効率が重視されている場合、アーキテクチャではミッションクリティカルな運用アプリケーションにフォーカスを置く必要があります。
サードパーティ・アプリケーションのロードマップを理解します:
ネットワーキング、コンピュート、ストレージなど、現在のスタック内の各サードパーティ・テクノロジのベンダー・ロードマップについて理解していますか。
サードパーティ・アプリケーションのサポートは終了していますか。
アップグレードによりサードパーティ・アプリケーションを引き続き使用できますか。
将来のアーキテクチャを深く掘り下げることなく、Oracle Cloud Infrastructureはクラウド・バージョンを提供しますか。サードパーティ・ベンダーはOracle Cloud Marketplaceからクラウド・バージョンを提供していますか。
主要な非機能ディメンションにおけるテクノロジ、デプロイメントおよび操作に関連する固有の機能を特定します:
セキュリティ。たとえば、組込みのデータ・マスキング機能はありますか。
コンプライアンス。たとえば、クレジット・カード業界(PCI)の要件に対するサポートが組み込まれていますか。
自己回復性。次に例を示します:
アプリケーション層はクラスタ化できますか。
ストレージは自動的に冗長化されますか。
ビジネス継続性をサポートするためにライブ移行に頼りますか。
ガバナンスと運用。たとえば、外部ソフトウェア開発ライフサイクル(SDLC)ツールまたはモニタリング・フックへの直接統合はありますか。
効率性。次に例を示します:
スタック内にVMwareなどの仮想化プラットフォームはありますか。
他のコンピュート、ストレージまたはデータベースの共有は設定されていますか。複数のアプリケーションを実行している共有データベース・サーバーがある場合、属性値は共有データベース・デプロイメントになります。
自動化。次に例を示します:
ビルド/デプロイ/運用モデルはどの程度自動化されていますか。
どのようなツールを使用しますか。
共有機能領域、共有データおよびその他の共通コンポーネントを特定し、アプリケーションでどのように統合がサポートされるかを理解します:
アプリケーションでは複数の事業部門、ユーザー・ロールまたはビジネス・プロセスがサポートされていますか。
どのようなデータ・ソースが共有されていますか。共有されているインフラストラクチャはありますか。次に例を示します:
運用効率やビン・パッキング以外の理由でアプリケーションは共有ホスト上で実行されますか。
ネットワーク・コンポーネントはどのように共有されますか。たとえば、ネットワーク・セグメントがクロスサイト・ビジネス継続性を考慮する場合、ネットワーキング詳細が関連属性である可能性があります。
アイデンティティ管理にはどのようなシステムを使用しますか。組織で複数のアイデンティティ管理システムまたはソースを使用する場合は、アイデンティティ・システムが関連属性である可能性があります。
共有のファンクション、データおよびコンポーネントはどのように統合されますか。次に例を示します:
同期統合か非同期統合か。
大量か少量か。
統合の方法は何ですか。たとえば、受信リンクと送信リンク、ミドルウェア・コンポーネントなどです。
その他の非機能アーキテクチャまたは設計の特性を評価します。デプロイメントおよびアーキテクチャの選択によって、プラットフォームや技術的な機能ではなくコンポーネントが提供される領域を考慮します。
データ変更のボリュームと同時実行性。次に例を示します:
システムがほぼ1つの操作または別の操作を行う場合、純新規データと既存のデータに対する更新が関連する可能性があります。たとえば、データ・レイクで大量の新しいデータが追加されている一方で、現在のGPSロケーションのキャッシュで大量のデータが更新されている場合などです。
アプリケーションの同時実行性およびクライアント数。
アプリケーションに応じて、トランザクション・データ、参照データおよび分析データを考慮します。
スケーリング。次に例を示します:
定期的な需要サイクルまたは不測の需要ピークに基づいて現在のアーキテクチャをスケール・アップおよびスケール・ダウンしますか。
スケーリングのメカニズムは何ですか。
データの機密性または特別なコンプライアンスの問題。次に例を示します:
PCIまたは医療保険の相互運用性と説明責任に関する法律(HIPAA)の規制の対象となるデータがワークロードに含まれていますか。
格納または処理されるデータは、一般データ保護規則(GDPR)などのデータ・レジデンシ要件に準拠していますか。
自己回復性を備えた運用プラクティス。次に例を示します:
特定のインシデントに対応して一部のワークロードは別の場所にフェイルオーバーしますが、他のワークロードは単に停止状態に入りますか。一部のアプリケーション層またはデータベース層では、フェイルオーバー・クラスタが使用されます。自動フェイルオーバーがない一部のアプリケーションでは、再構築が完全に自動化されている場合もあります。他のアプリケーションでは、リカバリ・プロセスを完全に手動で行う場合もあります。
アプリケーションの特定の障害モードに関連する、限られた数のパターンを特定します。
運用コスト。コスト層は、正確な数値ではなく概算である可能性があります。考慮する領域の例:
固有のアプライアンスは必要ですか。
人件費はいくらですか。労務は割り当てられることが多いため、正確な数の取得は困難ですが、集計または要約マトリックスの見積りを考慮してください。
テクノロジ・スタックにプレミアムなサードパーティ・ライセンスまたはサポートは含まれていますか。その場合、そのサードパーティ・ライセンスまたはサポートは移植可能ですか。
強調することが重要な共有効率はありますか。たとえば、サーバーを共有するVMwareやコンテナベース・アプリケーションなどの仮想化テクノロジについて考慮します。
考慮が必要な追加の属性を特定することもあります。手に負えなくならないように、分析のスコープを管理することをお薦めします。
反復する中で、既存のテクノロジの状況、ビジネス目標およびクラウド導入計画(現在のアーキテクチャと計画アーキテクチャとのマッピングを含む)を理解し、それに基づいて現在のアプリケーション、属性および属性値のマトリックスを調整します。