Oracle Cloud Infrastructureドキュメント

計画アーキテクチャの定義

現在のアプリケーションのマトリックスをコア属性に基づいて作成した後、計画されたクラウド実装に対して同様の分析を実行します。

計画アーキテクチャのマトリックスは、現在のアーキテクチャのマトリックスを概念的に拡張したものです。また、計画アーキテクチャのマトリックスは、クラウド・イニシアチブの一部として検討している新しいアプリケーションを追加する場所でもあります。

評価プロセス

マトリックス内の各アプリケーションまたはアプリケーション・グループを評価し、クラウド実装のための1つ以上のオプションを識別します。

現在のステータスを改善することでビジネス目標に向かって前進できるため、現在のアーキテクチャを評価したときに検討した属性の多くについて検討してください。分析スコープの管理も重要です。特に、計画された実装について多くの潜在的な「what ifs」について考えるときには重要になります。計画されたリストは、まったく新しい個別の演習ではありません。

実行する全体的なプロセスは次のとおりです:

  1. ビジネス目標の観点から各アプリケーションを評価します。現在のアーキテクチャ・マトリックスを開始点として使用します。この分析を行うことで、どの領域に多くの時間を費やすかを優先順位付けし、可能な代替案をより徹底的に追求することができます。

  2. 目標に照らしてどのアプリケーションが最も重要か、優先順位を付けます。これを行うには、ビジネスの目標と優先順位を、各アプリケーションの戦略的機能属性と組み合せて考慮します。

  3. 目標に対するアラインメントが高い他のアプリケーションとの依存関係または統合のために優先する必要があるアプリケーションを識別します。これを行うには、各アプリケーションの共有機能領域属性を考慮します。

    持続するアプリケーションは、アプリケーションそのものがそれほど戦略的でなくても、データの収集、保持またはシンジケーションの中心となっているために、引き続き優先させる必要があることはよくあります。このようなアプリケーションについては、クラウド・ネイティブ開発を並行して行うことができるリプラットフォームまたはリホストのオプションを検討してください。また、重要な機能をリライトするが、すべての技術的負債への即時対処を行わないという同じ目標に向けて、制限付きのリファクタリングとリプラットフォームを行うことも検討してください。

評価する属性

マトリックス内の各アプリケーションまたはアプリケーション・グループを評価し、クラウド実装のための1つ以上のオプションを識別します。

この項の属性を使用して、計画されたワークロードおよびプラットフォーム・アーキテクチャのマトリックスが含まれるように現在のアプリケーションのマトリックスを拡張します。

Oracle Architecture Centerには、特定のワークロードおよびアプリケーションのパターン用の多数のサンプル・アーキテクチャが含まれています。属性マトリックスを作成するときは、自分のポートフォリオと一致する例をアーキテクチャ・センターで探すと、アーキテクチャの定義と属性の取得をたやすく始めることができます。

次に、考慮する追加の属性を示します。非機能要件を評価する際には、組織の優先順位と目標に重点を置く必要があります。

レガシーの互換性:

  • 仮想マシン。次に例を示します:

    • リホストの選択肢はありますか。

    • 古いオペレーティング・システムを実行しているVMをクラウドまたは仮想化プラットフォーム(VMwareなど)に移行できますか。Oracle Cloud VMwareソリューションを使用して、Oracle Cloud InfrastructureでVMware対応のソフトウェア定義データ・センター(SDDC)を作成および管理します。

  • アップグレード。たとえば、コア・サポート・テクノロジをアップグレードできますか。

オンプレミスの同等物:

  • 直接リホスト。たとえば、比較的新しいアーキテクチャの場合、同等のクラウド・サービスで直接、またはバージョン・アップグレードによってリホストする選択肢はありますか。

  • ハイブリッドのリホストとリプラットフォーム。次に例を示します:

    • 一部の層にはより簡単なリホストができるようにし、他の層にはリプラットフォームが必要になるように、アプリケーション層を分割できますか。

    • ロード・バランサ、アプリケーション・サーバーまたはデータベース層(あまりない)のみをリプラットフォームし、それ以外をリホストすることができますか。

  • サードパーティ・プロバイダ。次に例を示します:

    • サードパーティ・プロバイダは、Oracle Cloud Marketplaceで仮想アプライアンスまたはプラットフォーム・サービスを提供していますか。

    • Marketplaceのオファリングは機能面と非機能面の両方で期待に添っていますか。一部のMarketplaceオファリングは、オンプレミス・バージョンの直接的類似物です。機能のサブセットしか持たないオファリングもありますが、これらの機能でニーズが満たされれば、問題にはなりません。

ビジネス継続性:

  • オンデマンド・リソースとしてのインフラストラクチャへのアクセス権を持ち、複数のリージョンをサブスクライブすることで、どのようなビジネス継続性パターンが強化されますか。

  • 再構築自動化によりリモート・リージョン・スナップショットを格納して障害に対処しますか、それとも、リモート・リージョンを高可用性(HA)スイッチオーバー・スタンバイの一部になるように拡張しますか。

  • アプリケーションはポートフォリオにとってどの程度クリティカルですか。

  • アプリケーションをクラスタ化できない場合、同じリージョンで使用できると想定される予約されていないスタンバイ・コンピュータで再構築またはリカバリを自動化できますか。

  • 詳細は、高可用性およびディザスタ・リカバリを参照してください。また、Oracle Architecture Centerには、一般的な計画と、特定のアプリケーションのパターンの両方についての詳細な例もあります。

スケーリング。たとえば、コンピュート自動スケーリングまたはネットワーク・ロード・バランサを使用してどのようなスケール・アップまたはスケール・アウト・オプションが使用可能になりますか。

コスト管理。クラウド・ネイティブ機能を使用することで、どのような運用効率が得られますか。

新しいアプリケーションまたはリライトおよびリファクタリングのための新機能:

  • アプリケーションのリライトまたはリファクタリングの一環として、次のテクノロジに移行できますか。またはそれらを使用して新しいソリューションを作成できますか。

  • 他に、Oracle Cloud Infrastructureに直接デプロイできるフレームワークや、Marketplaceで入手可能なフレームワークもあります。Oracleはこだわりの強いツールを提供しており、同時にオープンの互換性もサポートしています。お客様が一部のドメインですでにリライトおよびリファクタリングのプロセスを開始している場合もあります。より直接的な移行のためにOracle Cloud Infrastructureでこれらのツールを使用する方法に関するガイダンスは、Oracle Cloud MarketplaceおよびOracle Architecture Centerを参照してください。

開発、運用および管理のための新しいプロセス:

移行ツール。ワークロードにどのような移行ツールを使用できますか。Oracle Architecture Centerには、様々なアプリケーションのガイダンスが用意されています。また、次のオプションについても考慮してください:

マルチクラウドおよびハイブリッドの接続:

  • 分析中に、いくつかのアプリケーションが他のクラウド・プロバイダのネイティブ・テクノロジとの方が相性がよいと気づく場合があります。マルチクラウド・アプローチは、効率性、互換性およびビジネス継続性についてはメリットがあるかもしれません。一部のリージョンでは、Oracle Cloud Infrastructureが他のクラウド・プロバイダに近い場所に配置されています。また、Oracle Cloud Infrastructureは、Oracle CloudとMicrosoft Azure Interconnectを使用したクロスクラウド実装も容易にします。

  • アプリケーションをビジネス属性別にグループ化する場合、必要に応じて分析を拡張して、他のクラウドにアプリケーションを含めます。特に、共有データまたは統合のユース・ケースが全体的なアーキテクチャと計画に影響を与える可能性がある場合などです。

新しいスキル・インベントリ。計画アーキテクチャには新しいスキルが必要ですか。

  • アプリケーションの戦略的重要性によっては、ワークフォース・レディネスがフェージングとタイミングに対する重要な制約になる可能性があります。また、トレーニング要件もアーキテクチャに関する決定に影響する可能性があります。全体としてのトレーニング労力を確認してください。オンザジョブ・トレーニングのみで構成される「労力の少ない」アプローチですら、多くの変更が必要になる場合があり、時間をかけて対処の計画を立てる予定があります。

  • 次のオプションおよび関連する時間とコストについて考慮してください:

    • セルフガイド学習およびオンザジョブ・トレーニング(新しいテクノロジが既存のアプローチと類似している場合)。

    • インストラクタ指導コースまたはオンライン・コース。通常、コストは高くなりますが、タイムラインを圧縮し、トピックをさらに深くカバーできます。

    • 戦略的採用(該当する場合)。ビジネス・プランでは戦略的採用をサポートしていますか。まったく新しいチームを採用する場合、新しいスタッフが参加したときにコンテキストを共有および維持する方法を持っていますか。

ビジネス目標:

  • ビジネス目標を計画アーキテクチャにマップするには、明示的なビジネス目標属性を作成し、それを計画アーキテクチャに割り当てます。これを行うと、詳細な分析に集中できます。また、技術的な問題の解決とビジネス上の問題の解決のコンテキストを切り替えるときに、ビジネス目標の優先順位を付けるための簡略表記となります。

  • ビジネス目標を特定の属性として捉えると、メリットを評価する際に客観性を保つことができます。たとえば、特定の計画アーキテクチャのメリットの1つが、新しい機能の開発である場合があります。ビジネス目標属性は、新しい機能もそのアプリケーションのビジネス目標と連携しているかどうかを評価するのに役立ちます。

  • ビジネス目標属性の一般的な例のいくつかを次に示します:

    • 新しい機能の開発。

    • コスト削減または「コスト節約」。例: データ・センターの閉鎖、または将来のハードウェア調達サイクルの廃止。

    • ソフトウェア開発ライフ・サイクル(SDLC)の反復速度の改善。例: 機能のアジリティを高めるための新しい12ファクタ・コンポーネント。継続的インテグレーションおよび継続的デリバリ(CI/CD)ツールまたはInfrastructure as Codeを導入します。

    • 運用効率の改善。例: モニタリングと自動化の改善、環境と運用のオンボーディングの迅速なプロビジョニング、異種混在のレガシー・アプリケーションやプラクティスの排除による統合型の運用。

    • ビジネス継続性の改善。例: 高速リカバリのためにリージョン内にオンデマンド容量を適用し、以前の「障害クラスの」インシデントを影響の小さいスイッチオーバー・イベントに縮小することで可用性を他のリージョンにまで拡張します。

次のステップ

計画アーキテクチャのマトリックスを、移動および進化する長期的なターゲットとして理解することがベストです。

アプリケーションとその属性それぞれについて評価プロセスを繰り返す際には、次の点を考慮してください:

  1. アプリケーションのグループ化のフェーズから始めて実装フェーズに入ります。段階的実装計画の作成を参照してください。

  2. 分析の結果を使用して現在のアーキテクチャを再評価し、計画アーキテクチャのスコープを調整します。

  3. 特に、選択したオプションの影響および組織が吸収できる内容について理解を深めるとき、何を優先するかにフォーカスします。

特定したソリューションやトレードオフに応じて、ビジネスの利害関係者が優先事項を改良する場合もあります。このため、ビジネスの検証とトレードオフの決定をサポートするために、分析の完全なサイクル(現在のアーキテクチャ、計画アーキテクチャおよび実装フェーズ)を早期かつ頻繁に繰り返すことが重要です。