テクノロジ・アーキテクチャ

クラウド導入のためのテクノロジー・アーキテクチャとは、クラウド・コンピューティング・リソースを活用するITインフラストラクチャ、システム、アプリケーション、サービスの設計と構造を指します。クラウド環境内の目標をサポートするために、様々なテクノロジの選択、統合および管理が網羅されています。

目標

クラウド導入のためのテクノロジ・アーキテクチャの主な目的は、クラウド・サービスを利用して、パフォーマンス、俊敏性、コスト効率およびイノベーションの向上を実現する、スケーラブルで柔軟かつ自己回復性の高いITランドスケープを作成することです。

役割

テクノロジ・アーキテクチャに責任を持つ役割は、通常、クラウド・ソリューション・アーキテクトまたはクラウド・アーキテクトです。この担当者は、クラウド環境内のテクノロジ・アーキテクチャ全体の設計、計画および実装を担当します。

テクノロジ・アーキテクチャには、次の役割が含まれます。

クラウド・アーキテクト

クラウド・アーキテクチャ全体の設計、適切なクラウド・サービスの選択、ビジネス目標との整合性の確保を担当します。

インフラ・エンジニア

基盤となるクラウド・インフラストラクチャ、ネットワーキングおよびストレージ・コンポーネントを実装および管理します。

アプリケーション開発者

クラウドネイティブまたはクラウド互換のアプリケーションおよびサービスを開発、デプロイおよび維持します。

セキュリティ・エキスパート

セキュリティ対策、暗号化、アクセス制御、規制への準拠を確立します。

DevOpsおよび自動化エンジニア

継続的インテグレーション(CI)および継続的デリバリ(CD)パイプライン、自動化およびオーケストレーションを実装して、効率的なデプロイメントと管理を実現します。

データ・アーキテクト

クラウド環境内のデータ・ストレージ、統合および処理ソリューションを設計します。

モニタリングおよびパフォーマンス・スペシャリスト

監視、ロギングおよびパフォーマンス最適化戦略を設定します。

実装

次の情報では、クラウド導入のためのテクノロジ・アーキテクチャを実装する際の機能および設計上の考慮事項について説明します。

戦略プランニングと評価

クラウド・テクノロジーの採用目標、目的、および理由を概説した明確な戦略を策定します。

クラウド戦略

クラウド導入のためのテクノロジ・アーキテクチャにおけるクラウド戦略とは、複数のクラウド・プロバイダまたはサービスを使用してビジネス・ニーズを満たし、これらの異なるクラウド環境間のコミュニケーションと統合を可能にすることです。プライベート・クラウドを選択するときめ細かな制御が可能で、マルチクラウドまたはハイブリッド・クラウドを使用すると、信頼性が向上します。

• 要件の定義: クラウド戦略のビジネス要件を定義します。これには、冗長性、ディザスタ・リカバリまたはワークロードの最適化の必要性を特定し、複数のクラウドがこれらのメリットをどのように提供できるかを判断することが含まれます。
• 互換性のあるクラウド・プロバイダの選択: 互換性のあるサービスとアプリケーション・プログラミング・インタフェース(API)を提供するクラウド・プロバイダを選択して、異なるクラウド環境間の通信と統合を有効にします。これには、コンピュート、ストレージ、ネットワーキングなどの様々なクラウド・サービスの互換性を評価し、互換性のあるサービスを提供するクラウド・プロバイダを選択することが含まれます。詳細は、Oracle Multicloud戦略およびクラウド・インターコネクト・オプションを参照してください。
• クラウド・サービスの標準化: クラウド・サービスの使用を標準化して、互換性の問題を最小限に抑え、複数のクラウド環境間で一貫した管理を実現します。これには、コンピュート、ストレージおよびネットワーキング・リソースの標準構成を定義し、複数のクラウド・プロバイダにわたってこれらの標準を適用することが関係する場合があります。
• ハイブリッド・クラウド・ソリューションの実装: パブリック・クラウドとプライベート・クラウド間のシームレスな統合を可能にするハイブリッド・クラウド・ソリューションを実装します。これには、仮想プライベート・ネットワーク(VPN)を使用したり、プライベート・クラウド環境をパブリック・クラウド・プロバイダに接続するための直接インターコネクトを使用することが含まれます。
• クラウド管理ツールの活用: 単一の画面を提供するクラウド管理ツールを活用して、複数のクラウド環境を管理します。これには、クラウド・リソースの使用状況を可視化するツールの使用、リソースのプロビジョニングの自動化、および複数のクラウド環境にわたるセキュリティとコンプライアンスのポリシーの適用が含まれる場合があります。
• パフォーマンスの監視と最適化: マルチクラウド、ハイブリッド・クラウド、クラウド間環境のパフォーマンスを監視して、最適なリソース使用率を確保し、コストを最小限に抑えます。これには、クラウド・リソースの使用状況に関するインサイトを提供する監視ツールの使用、パフォーマンスのボトルネックの特定、プロアクティブな容量計画の実現などが含まれます。

次の情報では、テクノロジ・アーキテクチャでマルチクラウドおよびハイブリッド・クラウド戦略を使用するいくつかの利点について説明します。

• 柔軟性の向上: マルチクラウド戦略により、組織はニーズに基づいてワークロードごとに異なるクラウド・プロバイダを使用できます。これにより、リソース割当てに関して柔軟性が高まり、パフォーマンスとコストのためにインフラストラクチャを最適化できます。
• 信頼性の向上: 複数のクラウド・プロバイダを活用することで、ダウンタイムやサービスの中断のリスクを軽減することで、クラウド・インフラストラクチャの信頼性を向上させることができます。あるクラウド・プロバイダで停止やサービスの中断が発生した場合、サービスの可用性を維持するためにワークロードを別のプロバイダに移行できます。
• セキュリティの強化: マルチクラウド戦略は、複数のクラウド・プロバイダにワークロードを分散させることで、セキュリティを向上させることもできます。これにより、単一障害点または単一の攻撃対象領域のリスクが軽減され、各クラウド・プロバイダに固有のセキュリティ制御を実装できます。
• パフォーマンスの向上: 複数のクラウド・プロバイダを使用することで、ワークロードを異なる地理的リージョンに分散し、各プロバイダ独自のインフラストラクチャとサービスを活用できます。これにより、エンド・ユーザーのパフォーマンスが向上し、レイテンシが削減される可能性があります。
• コストの最適化: 複数のクラウド・プロバイダを活用することで、ワークロードごとに最もコスト効率の高いプロバイダを選択することで、インフラストラクチャ・コストを最適化できます。これにより、時間の経過とともに大幅なコスト削減が実現します。
• ベンダーのロックインの回避: マルチクラウド戦略は、単一のクラウド・プロバイダーに縛られるのを防ぐことで、ベンダーのロックインを回避するのに役立ちます。これにより、ベンダーの選択に関して柔軟性が高まり、必要に応じてプロバイダを切り替えることができ、業務に大幅な中断はありません。

ツールとテクノロジーの在庫

ターゲット・ツールおよびテクノロジの在庫を作成するには、ターゲット・クラウド環境のツールおよびテクノロジを選択するためのマスター・リストおよび部品構成表(BOM)の作成が含まれます。これは、クラウドへの準拠に関する組織のポリシーおよび手順に適している各ツールおよびテクノロジを評価するための徹底的なプロセスです。

• ビジネス要件の特定: ツールやテクノロジーを選択する前に、ビジネス要件やビジネス目標を特定することが不可欠です。これを行うには、利害関係者と相談し、組織のニーズを理解します。
• テクノロジ要件の定義: ビジネス要件に基づいて、組織が目標を達成できるようにするテクノロジ要件を定義します。これには、スケーラビリティ、セキュリティ、信頼性、コスト効率などの要因が含まれます。
• 利用可能なツールとテクノロジの研究: テクノロジの要件を定義したら、これらの要件を満たすことができる利用可能なツールとテクノロジを調査します。これには、市場調査の実施、業界レポートの読解、テクノロジ・エキスパートとのコンサルティングが含まれます。
• ツールとテクノロジの評価: 各ツールまたはテクノロジの特徴、機能、および既存のシステムとの互換性に基づいて評価します。統合のしやすさ、ベンダーのサポート、スケーラビリティなどの要因を考慮します。
• ツールとテクノロジの選択: 評価に基づいて、テクノロジ要件を満たし、目標に沿った最適なツールとテクノロジを選択します。
• インベントリの作成: 名前、ベンダー、バージョン、目的などの詳細を含む、選択したツールおよびテクノロジのインベントリを作成します。このインベントリは、テクノロジ・アーキテクチャ開発プロセスの参照として機能し、クラウド・テクノロジの採用における一貫性と標準化の確保に役立ちます。
• 継続的な監視と更新: 選択したツールとテクノロジのパフォーマンスを継続的に監視し、必要に応じて在庫を更新して、ニーズと目標を満たし続けることが重要です。

ビジネス・アラインメントとレディネス

全体的なエンタープライズ・ビジョンとビジネス目標に沿ったアーキテクチャを設計し、スケーラビリティと柔軟性を確保します。

エンタープライズ・スケール・アーキテクチャ

クラウドのエンタープライズ・スケール・アーキテクチャは、通常、複数のコンポーネントで構成され、それぞれが大規模な組織のニーズをサポートするように設計されています。主要コンポーネントの一部を次に示します。

• クラウド・インフラストラクチャ: これには、サーバー、ストレージ、ネットワーキング、セキュリティなどのクラウド・コンピューティングをサポートするために必要な物理リソースと仮想リソースが含まれます。
• クラウド・プラットフォーム: これには、開発フレームワーク、ランタイム環境、自動化ツールなど、クラウドベースのアプリケーションを構築およびデプロイするために必要なソフトウェアとツールが含まれます。
• クラウド・サービス: これらは事前構築済みのクラウドベースのサービスで、認証、メッセージング、データ・ストレージなどの追加機能を提供するためにアプリケーションに統合できます。
• データと分析: これには、データウェアハウス、機械学習、ビジネス・インテリジェンス・ツールなど、クラウド内のデータを収集、保存、処理、分析するためのツールとサービスが含まれます。
• セキュリティとコンプライアンス: これには、アイデンティティおよびアクセス管理(IAM)、暗号化、コンプライアンス・レポートなど、クラウドベースのアプリケーションとデータのセキュリティとコンプライアンスを確保するために必要なポリシー、手順およびツールが含まれます。
• 統合とAPI管理: これには、クラウドベースのアプリケーションを他のアプリケーションやシステムと統合し、APIを管理および監視するために必要なツールやサービスが含まれます。
• DevOpsと自動化: これには、継続的インテグレーションとデリバリ、構成管理、Infrastructure as Codeなど、クラウドベースのアプリケーションのデプロイメントと管理を自動化するためのツールとサービスが含まれます。

能力とリソース評価

既存のIT機能、スキルおよびリソースを評価して、ギャップと必要なスキル開発を特定します。

IT機能とリソースの調整

IT機能とリソースをテクノロジ・アーキテクチャに連携させることで、スムーズかつクラウドへの移行が成功します。この連携には、既存のITインフラストラクチャの評価、ビジネス・ニーズの理解、クラウドへの移行の戦略的な計画による効率性と有効性の最適化が含まれます。

1. 現在のIT機能とリソースの評価: 最初のステップは、インフラストラクチャ、システム、アプリケーション、人事など、現在のIT機能とリソースを評価することです。この評価は、既存のIT環境の長所と短所を特定するのに役立ちます。
2. ビジネス要件の特定: 次に、クラウド導入のビジネス要件を特定します。これには、スケーラビリティ、セキュリティ、信頼性、コスト効率などの要因が含まれます。ビジネス要件が全体的な目標と一致するように、このプロセスに利害関係者を関与させることが重要です。
3. テクノロジ要件の決定: ビジネス要件に基づいて、組織が目標を達成できるようにするテクノロジ要件を決定します。これには、既存のシステムとの互換性、統合の容易さ、ベンダー・サポートなどの要因が含まれます。
4. スキル・ギャップの特定: クラウド導入をサポートするために対処する必要がある現在のIT従業員のスキル・ギャップを特定します。これには、新しいテクノロジに関するトレーニング、既存のスタッフの再スキル化、必要なスキルを持つ新しいスタッフの採用などが含まれます。
5. ロードマップの開発: ITの機能とリソースをクラウド導入のためのテクノロジ・アーキテクチャと連携させるためのロードマップを作成します。このロードマップには、タイムライン、マイルストーン、および測定可能な目標が含まれており、進捗を追跡し、ITの機能とリソースが目標と整合していることを確認する必要があります。
6. ロードマップの実装: リソースを割り当て、確立されたタイムラインと目標に基づいてタスクに優先順位を付けることで、ロードマップを実装します。これには、新しいテクノロジへの投資、既存のスタッフのトレーニングとサポートの提供、または必要なスキルを持つ新しいスタッフの採用が含まれる場合があります。
7. 継続的に監視および最適化: クラウド導入のためのテクノロジ・アーキテクチャによるIT機能およびリソースの調整を継続的に監視し、必要に応じてロードマップを最適化します。これには、定期的な評価の実施、パフォーマンス指標の確認、変化するビジネス・ニーズに基づくロードマップの調整などが含まれます。

Capacity Planningと需要評価

予想されるワークロードと使用パターンを分析して、リソース要件を正確に計画します。

容量計画

テクノロジ・アーキテクチャでのクラウド導入のキャパシティ・プランニングには、クラウド環境での組織のワークロードのサポートに必要なITリソースの見積りが含まれます。

1. ワークロードの理解: 容量計画の最初のステップは、クラウドに移行されるワークロードを理解することです。これには、処理されるデータの量、ユーザー数、ピーク使用時間、アプリケーション要件など、ワークロードの特性を分析することが含まれます。
2. 必要なリソースの特定: ワークロード分析に基づいて、クラウド環境でのワークロードのサポートに必要なITリソースを特定します。これには、処理能力、ストレージ、メモリー、ネットワーク帯域幅などの要因が含まれます。
3. リソース使用量の見積り: クラウド環境でのワークロードのリソース使用量の見積り。これには、ピーク使用時間や季節需要など、様々なシナリオでリソース使用量を見積るために、履歴データを使用したり、同様のワークロードに対するベンチマークを行ったりすることがあります。
4. クラウド・サービス・プロバイダの選択: 特定されたリソース要件を満たすことができるクラウド・サービス・プロバイダを選択します。クラウド・サービス・プロバイダを選択する際には、コスト、パフォーマンス、セキュリティ、可用性などの要因を考慮してください。詳細は、Oracle Cloud Infrastructure (OCI)のクラウド機能を参照してください。
5. クラウド・インスタンス・タイプの決定: リソース要件およびクラウド・サービス・プロバイダに基づいて、ワークロードのサポートに必要なクラウド・インスタンス・タイプを決定します。これには、ワークロード要件を満たす適切な仮想マシン・タイプ、ストレージ・タイプおよびネットワーク構成の選択が含まれる場合があります。
6. スケーラビリティの計画: 予想される成長と需要に基づいて将来のリソース・ニーズを見積もることで、スケーラビリティの計画を立てます。これには、自動スケーリングをサポートするアーキテクチャの設計、ロード・バランサを使用したトラフィックの分散、およびボトルネックの検出と必要に応じて容量の調整のためのリソース使用量の監視が含まれます。
7. 監視と最適化: クラウド環境のパフォーマンスを継続的に監視し、変化するビジネス・ニーズに基づいて容量計画を最適化します。これには、パフォーマンス・メトリックの確認、インスタンス・タイプまたは構成の調整、追加のスケーリング計画の実装などが含まれます。

予想される需要評価

ターゲット容量の予想される需要を評価するには、ITリソースに対する予想される需要を見積もり、その需要を満たすために必要な容量を決定する必要があります。

• 履歴データの分析: ワークロードの需要とリソース使用率に関する履歴データを分析して、パターンと傾向を特定します。これには、時間の経過に伴う使用状況、ピーク使用時間および季節的な需要に関するデータの分析が含まれます。
• ビジネスの成長の検討: 予想されるビジネスの成長と、それがITリソースの需要にどのように影響するかを考慮します。これには、ビジネス計画、市場動向および予想される顧客需要の分析が含まれます。
• クラウド導入の影響を評価する: クラウド導入がITリソースの予想される需要に与える影響を評価します。これには、既存のシステムのパフォーマンスの分析、ボトルネックや制限の特定、およびクラウドへの移行から予想される改善の見積りが含まれる場合があります。
• 将来の需要の見積り: 履歴データ、ビジネスの成長、クラウド導入の影響に基づいて、ITリソースの将来の需要を見積もります。これには、ワークロード需要やリソース使用パターンの変化を考慮して、将来の使用量と容量のニーズを予測することが含まれます。
• ターゲット容量の決定: 将来の推定需要に基づいて、その需要を満たすために必要なターゲット容量を決定します。これには、ワークロードのサポートに必要な処理能力、ストレージ、メモリーおよびネットワーク帯域幅の計算が含まれます。
• 適切なクラウド・インスタンス・タイプの選択: ターゲット容量に基づいて、容量のニーズを満たす適切なクラウド・インスタンス・タイプおよび構成を選択します。これには、ワークロード要件を満たす適切な仮想マシン・タイプ、ストレージ・タイプおよびネットワーク構成の選択が含まれる場合があります。
• スケーラビリティの計画: 自動スケーリングをサポートするアーキテクチャを設計し、ロード・バランサを使用してトラフィックを分散し、リソース使用率を監視してボトルネックを検出し、必要に応じて容量を調整することで、スケーラビリティの計画を立てます。
• 継続的に監視および最適化: クラウド環境のパフォーマンスを継続的に監視し、変化するビジネス・ニーズに基づいて容量計画を最適化します。これには、パフォーマンス・メトリックの確認、インスタンス・タイプまたは構成の調整、追加のスケーリング計画の実装などが含まれます。

ガバナンスと合意

サービス・レベル、期待値、パフォーマンス・メトリックを定義して、品質とアカウンタビリティを確保します。

サービス・レベル契約アセスメント

サービス・レベル合意(SLA)の需要に対する評価と検証を実行するには、ワークロードのクラウド環境におけるSLAを満たすために重要な技術的要因、属性およびパラメータを評価する必要があります。

• SLAの定義: アプリケーションの技術的なニーズに基づいてSLAを統合または定義します。たとえば、アプリケーションで低レイテンシが必要な場合は、許容可能なレスポンス時間の観点からSLAを定義します。
• 重要な要因の特定: ネットワーク帯域幅、ディスクI/O、CPU使用率、メモリー使用量など、SLAに影響を与える可能性のある技術的要因を特定します。監視ツールを使用して、これらの要因のパフォーマンスを追跡し、ボトルネックを特定します。
• 属性要件の決定: 各クリティカル・ファクタの特定の要件を決定します。たとえば、ネットワーク帯域幅が重要な要素である場合は、必要な帯域幅を決定し、許容可能な帯域幅使用量のSLAを設定します。
• パラメータしきい値の識別: SLA要件に基づいて、属性ごとにしきい値を設定します。監視ツールを使用して各属性のパフォーマンスを追跡し、しきい値を超えた場合にアラートを生成します。
• クラウド・サービス・プロバイダ機能の評価: SLA要件を満たすために、潜在的なクラウド・サービス・プロバイダ層の機能を評価します。これには、ネットワーク・レイテンシやスループットなど、クラウド・サービス・プロバイダのインフラストラクチャのパフォーマンス・メトリックを確認して、それらをSLA要件と比較することが含まれます。
• クラウド・インスタンス・タイプと構成の評価: SLA要件に基づいて、適切なクラウド・インスタンス・タイプおよび構成を選択します。インスタンス・タイプと構成を選択する際には、CPU、メモリー、ストレージ、ネットワーク帯域幅などの要因を考慮してください。
• スケーラビリティの計画: 需要の急増に対処するための自動スケーリングをサポートするアーキテクチャを設計します。ロード・バランサを使用して複数のインスタンスにトラフィックを分散し、監視ツールを使用してリソース使用率を追跡し、ボトルネックを検出します。
• テストおよび検証: シミュレートされた負荷でクラウド環境をテストして、それがSLA要件を満たしていることを検証します。負荷テスト・ツールを使用して、現実的なトラフィックを生成し、パフォーマンス・メトリックを監視して問題を特定します。

Risk Managementと最適化

現在と希望の状態のギャップを特定し、それに対処するための戦略を策定します。

ギャップ分析と緩和

テクノロジ・アーキテクチャでのクラウド導入のためのテクノロジ・ギャップ分析および軽減計画の実行には、現在のテクノロジ環境におけるギャップの特定、クラウド導入がこれらのギャップにどのように対処できるかの決定、およびクラウド導入に関連するリスクを軽減する計画の作成が含まれます。

• ビジネス要件の定義: 機能要件や非機能要件など、クラウド導入プロジェクトのビジネス要件を定義します。
• 現在のテクノロジの状況を評価: 現在のテクノロジの状況を評価して、ビジネス要件が完全に満たされないようにするテクノロジ・スタックのギャップを特定します。これには、現在のプロセスおよびワークフローの評価に加えて、既存のハードウェア、ソフトウェアおよびネットワーク・インフラストラクチャの確認が含まれます。
• クラウド導入のメリットを判断する: クラウド導入が、現在のテクノロジー環境における特定されたギャップにどのように対処できるかを判断します。これには、Infrastructure as a Service (IaaS)、Platform as a Service (PaaS)、Software as a Service (SaaS)など、必要な機能を提供する特定のクラウド・サービスの識別が含まれます。
• リスクと軽減戦略の特定: セキュリティ・リスクやパフォーマンス・リスクなど、クラウド導入に関連するリスクを特定し、これらのリスクに対処するための緩和戦略を策定します。これには、セキュリティ制御の実装、耐障害性とスケーラビリティの設計、およびパフォーマンスと可用性の監視が含まれます。
• クラウド導入計画の開発: クラウド・サービスの選択、クラウド環境の構成、データとアプリケーションの移行、クラウド環境のテストと検証を含む、クラウド導入の計画を策定します。計画には、前のステップで特定した緩和戦略も含まれている必要があります。クラウドで提供されるIaaS、PaaSおよびSaaSサービスについては、OCIを参照してください。
• クラウド導入計画の実装: クラウド導入と構成に関するベスト・プラクティスに従って、クラウド導入計画を実装します。これには、クラウド・サービス・プロバイダとの連携によるクラウド・リソースのプロビジョニングおよび構成、データとアプリケーションのクラウドへの移行、およびクラウド環境のパフォーマンスと可用性のテストが含まれます。
• クラウド環境の監視と最適化: 監視ツールを使用して、リソース使用率を追跡し、ボトルネックを特定し、必要に応じて構成を最適化して、クラウド環境のパフォーマンスと可用性を監視します。これには、需要に応じてリソースをスケール・アップまたはスケール・ダウンしたり、セキュリティ制御を調整して新しい脅威に対処したり、ソフトウェア・パッチおよび更新を適用してクラウド環境をセキュアかつ最新の状態に保つことが含まれます。

技術統合と互換性

クラウド・システムとオンプレミス・システム間のシームレスな通信と統合を実現します。

相互運用性

テクノロジの相互運用性は、様々なテクノロジがシームレスかつ効率的に連携できる機能です。クラウド導入のコンテキストでは、テクノロジの相互運用性とは、異なるクラウド・テクノロジが連携して、統一された一貫性のあるクラウド・インフラストラクチャを提供する能力のことです。次の情報では、テクノロジの主な相互運用性要件について説明します。

• クラウド・サービスの互換性: 異なるクラウド環境間の通信と統合を可能にするには、コンピュート、ストレージ、ネットワーキングなどのクラウド・サービスが相互に互換性がある必要があります。これには、様々なクラウド・サービスで使用されるAPI、データ形式およびプロトコルの標準化が必要です。
• アプリケーションとデータの移植性: シームレスな移行と相互運用性を実現するには、アプリケーションとデータを異なるクラウド環境間で移植できる必要があります。これには、異なるクラウド・プロバイダが使用するオペレーティング・システム、ミドルウェアおよびデータベースの互換性が必要です。
• 既存のインフラストラクチャとの統合: クラウド・テクノロジは、オンプレミスのデータ・センターやレガシー・アプリケーションを含む既存のITインフラストラクチャと統合する必要があります。これには、既存のITシステム、セキュリティ・フレームワークおよび管理ツールとの互換性が必要です。
• クラウド・プロバイダ間の相互運用性: 異なるクラウド・プロバイダがシームレスに連携して、マルチクラウドとクラウド間の導入を可能にする必要があります。これには、クラウド管理ツール、セキュリティ・フレームワーク、および異なるクラウド・プロバイダが使用するデータ形式の互換性が必要です。
• セキュリティとコンプライアンスの標準化: クラウド・プロバイダは、相互運用性を確保し、異なるクラウド環境間のシームレスな移行を可能にするために、標準的なセキュリティとコンプライアンスのフレームワークを遵守する必要があります。これには、ISO 27001、SOC 2、PCI DSSなどの業界標準への準拠が必要です。

リソース稼働率と効率性

効率的な割当て、スケーリングおよびロード・バランシングにより、リソース使用量を最適化します。

リソースの最適化

技術リソースの最適化とは、コンピューティング能力、ストレージ、ネットワーク帯域幅などの技術リソースの使用の最適化に重点を置いたクラウド導入のコンポーネントです。次の情報では、技術リソース最適化計画を作成するいくつかのステップについて説明します。

1. 技術リソースの特定: 技術リソース最適化計画を作成する最初のステップは、クラウド環境で使用される技術リソースを識別することです。これには、仮想マシンやコンテナなどのコンピューティング・リソース、ブロック・ストレージやオブジェクト・ストレージなどのストレージ・リソース、ロード・バランサやファイアウォールなどのネットワーク・リソースが含まれます。
2. 現在の使用状況の評価: 技術リソースが特定されたら、現在の使用状況を評価します。これには、コンピューティング、ストレージ、およびネットワークリソースの使用状況を監視して、それらがどのように使用されているか、および使用可能な容量を決定します。
3. リソース使用率の分析: 現在の使用状況の評価に基づいて、リソース使用率を分析し、過剰プロビジョニングまたは過少使用率の領域を特定します。これには、CPU使用率、メモリー使用量、ネットワーク帯域幅などのメトリックを分析して、リソース使用率の傾向とパターンを特定することが含まれます。
4. リソース割当ての最適化: リソース使用率の分析に基づいて、リソース割当てを最適化し、リソースが効率的に使用されるようにします。これには、仮想マシンのサイズの調整、自動スケーリング・ポリシーの構成、ワークロードの異なるリージョンまたは可用性ゾーンへの移動などが含まれます。
5. 自動化の実装: リソース使用率をさらに最適化するには、自動化を実装してリソースの割当てとスケーリングを管理することが重要です。これには、クラウド・オーケストレーション・プラットフォーム、自動スケーリング・グループ、ロード・バランシングなどのツールを使用して、ワークロードの需要に基づいてリソース割当てを自動的に調整することが含まれます。
6. 継続的に監視および最適化: リソース使用率を継続的に監視し、リソース割当てを継続的に最適化することが重要です。これには、アラートおよびモニタリング・ツールを設定して、問題をリアルタイムで特定し、必要に応じてリソース割当てを調整することが含まれます。

クラウドの成熟度と進歩

クラウド導入の進捗と成熟度レベルを評価するモデルを確立します。

クラウド成熟度モデルの定義

クラウド戦略を定義する際の重要なステップは、組織が達成しようとする成熟度レベルを評価して理解することです。

成熟レベルは、組織がクラウドベースのサービスに投資する方法をより深く理解するのに役立ちます。

一部のカテゴリがアクセスできない、またはビジネスに接続されていない可能性がある場合、目標は必ずしもすべてのカテゴリで高い成熟度レベルを達成することではありません。クラウド成熟度モデルは、テクノロジからビジネスまで、複数のレベルをカバーするように構造化する必要があります。レベルごとに、ターゲット、タイムライン、ステータスおよび使用可能な予算を定義します。

Oracle Cloud Infrastructure (OCI) Cloud Adoption Framework内で提案されるクラウド成熟度モデルの成熟度レベルは次のとおりです。

テクニカル・アーキテクチャ設計

コンポーネント、サービスおよび相互作用を考慮して、目的のアーキテクチャを設計します。

ターゲット・アーキテクチャ

ターゲット・アーキテクチャは、評価ステップ中に直面するすべての課題と懸念に対処することで、クラウドに効果的かつ効率的に移行するためのクラウド導入の重要なステップです。ターゲット・アーキテクチャは、最適化されたコストと効率、強化されたセキュリティ、透明性の高いガバナンスを備えたクラウドで実行されるワークロードの最終的なテクノロジ環境を表します。

次の情報では、ターゲット・アーキテクチャの準備のために考慮するステップについて説明します。

1. ビジネス要件の定義: 最初のステップは、クラウド導入のビジネス要件を定義することです。これには、クラウド移行の目標と目的、クラウドに移行されるアプリケーションおよびワークロード、およびクラウド導入のビジネス・ドライバの特定が含まれます。
2. 技術要件の特定: ビジネス要件に基づいて、クラウド導入の技術要件を特定します。これには、適切なクラウド・サービス・モデル(IaaS、PaaSまたはSaaS)、クラウド・プロバイダ、および必要な技術機能の選択が含まれます。
3. 技術アーキテクチャの定義: 技術要件が特定されたら、クラウド導入のための技術アーキテクチャを定義します。これには、クラウド環境のネットワーク・アーキテクチャ、ストレージ・アーキテクチャ、セキュリティ・アーキテクチャおよびアプリケーション・アーキテクチャの定義が含まれます。
4. 移行プランの作成: 技術的なアーキテクチャに基づいて、ワークロードをクラウドに移行するための移行プランを作成します。これには、移行のシーケンス、移行のタイムライン、ワークロードの移行に使用するツールとプロセスの特定が含まれます。
5. テストと検証の実行: ワークロードをクラウドに移行する前に、テストと検証を実行して、技術アーキテクチャが期待どおりに機能していることを確認することが重要です。これには、ロード・テスト、セキュリティー・テストおよびディザスタ・リカバリ・テストの実行が含まれます。
6. テクニカル・アーキテクチャの実装: テストと検証が完了したら、クラウド導入のためのテクニカル・アーキテクチャを実装します。これには、クラウドへのワークロードのデプロイ、ネットワークおよびセキュリティ・インフラストラクチャの構成、および既存のシステムおよびアプリケーションとの統合が含まれます。

自己回復性とビジネス継続性

高可用性(HA)とディザスタ・リカバリ(DR)を計画して、ダウンタイムとデータ損失を最小限に抑えます。

高可用性および障害リカバリ

HAおよびDRは、特にクラウド環境におけるITシステムの信頼性と耐障害性を確保するために重要な関連概念です。これらは、ビジネス継続性およびディザスタ・リカバリ(BCDR)およびビジネス継続性計画(BCP)という用語でよく使用されます。

高可用性とは、ハードウェアやソフトウェアの障害、ネットワーク停止、その他の混乱が発生しても、システムやアプリケーションが引き続き使用可能で運用可能であることを指します。つまり、高可用性システムは、ダウンタイムを最小限に抑え、重要なアプリケーションとサービスの継続的な可用性を維持するように設計されています。高可用性を実現するために、クラスタリング、ロード・バランシング、冗長ハードウェア、自動フェイルオーバー・メカニズムなどの様々な手法を使用できます。

ディザスタ・リカバリとは、自然災害、サイバー攻撃、人的エラーなどの致命的な出来事の後にITシステムおよびサービスをリストアするプロセスを指します。ディザスタ・リカバリの目的は、このようなイベントが業務に与える影響を最小限に抑え、重要なシステムとデータを迅速にリストアできるようにすることです。ディザスタ・リカバリには、通常、ディザスタ・リカバリ計画および手順の開発およびテストに加えて、データおよびシステムのバックアップおよびレプリカの作成が含まれます。

HAおよびDRは、予期しない障害時にシステムの可用性を維持するために独自に重要であり、ワークロード向けのテクノロジ・ランドスケープの設計に特別な考慮事項が必要です。OCIは、ワンクリックでフルスタックのディザスタ・リカバリも提供します。

段階的な移行と実装

計画されたフェーズでクラウド導入を実装して、リスクを管理し、スムーズな移行を確保します。

段階的な実装

クラウド導入のための段階的な移行計画は、アプリケーションとワークロードを経時的にクラウドに移行するためのステップバイステップのアプローチです。このアプローチにより、事業運営の中断を最小限に抑えながら、徐々にクラウドに移行し、クラウド・コンピューティングの利点を活用することができます。次の情報では、段階的な実装の一般的なアプローチについて説明します。

• 検出と評価: このフェーズでは、既存のITインフラストラクチャ、アプリケーションおよびワークロードの包括的な検出と評価を実行します。これにより、対処する必要がある潜在的な問題や課題に加えて、クラウドへの移行に適したアプリケーションおよびワークロードを特定できます。
• 概念実証(POC): POCフェーズでは、テスト・ケースとしてクラウドに移行するアプリケーションまたはワークロードの小さなセットを選択します。これにより、クラウド・アーキテクチャと移行計画を検証し、大規模な移行を進める前に対処する必要がある潜在的な問題や課題を特定できます。
• パイロット移行: パイロット移行フェーズでは、より大きなアプリケーションまたはワークロードのセットをクラウドに移行します。これにより、クラウド・アーキテクチャと移行計画をさらに検証し、クラウドでのアプリケーションの運用経験も得ることができます。
• 完全移行: 完全移行フェーズでは、残りのすべてのアプリケーションおよびワークロードをクラウドに移行します。このフェーズは段階的に実行され、アプリケーションとワークロードはビジネス上の重要度やその他の要因に基づいてグループで移行されます。
• 最適化とガバナンス: 最適化およびガバナンス・フェーズでは、パフォーマンス、コストおよびセキュリティのためにクラウド環境を最適化することに重点を置きます。これには、監視および管理ツールの実装、ワークロードの配置とサイズ調整、クラウド・ガバナンスのポリシーと手順の実装が含まれる場合があります。

決定フレームワーク

次の情報は、クラウド・コンピューティング・レイヤーのコンテキスト内でクラウド戦略の基盤を特定するのに役立つ質問のリストです。テクノロジ・インベントリおよび評価を実行して、これらの質問の多くに対する答えを見つけてください。

その他の考慮事項

• ベンダー・ロックイン: ベンダーのロックインを最小限に抑え、クラウド・プロバイダ間の移植性を維持するための戦略を検討します。
• バックアップおよびディザスタ・リカバリ: データのバックアップ、レプリケーションおよびディザスタ・リカバリのメカニズムを計画します。
• コスト管理: クラウド支出を制御するためのコスト監視および最適化プラクティスを実装します。
• コンプライアンスと規制上の懸念: テクノロジ・アーキテクチャが業界固有の規制および標準を満たしていることを確認します。

制約およびブロッカ

クラウドの導入は、さまざまな技術的な制約やブロッカに直面する可能性があるため、ITインフラストラクチャのクラウドへの移行が困難になる可能性があります。クラウドに移行する前に、すべての制約およびブロッカに対処し、軽減戦略を策定する必要があります。

次の情報は、クラウド導入時に発生する可能性のある技術的な制約やブロッカの例を示しています。

• レガシー・アプリケーション: レガシー・アプリケーションは、クラウド環境と互換性がない可能性があるため、クラウド導入の大きな技術的制約になる可能性があります。これらのアプリケーションは、クラウドで機能するために大幅な再設計または変更が必要になる場合があり、時間とコストがかかる場合があります。
• データのセキュリティとコンプライアンス: データ・セキュリティとコンプライアンスは、組織、特に規制対象業界の企業にとって重要な懸念事項です。コンプライアンス要件は地域や業界によって異なる場合があり、クラウド・プロバイダがこれらの要件を常に満たしているとは限らないため、クラウド導入を妨げる可能性があります。
• 技術的なスキルと専門知識: クラウドの導入には、特にクラウド・アーキテクチャ、セキュリティ、ネットワーキングなどの分野に特化した技術スキルと専門知識が必要です。組織はこのようなスキルを社内で持っていない可能性があり、クラウド導入の制約になる可能性があります。
• ネットワーク接続: クラウドの導入には、クラウドとオンプレミスのデータ・センターまたはエンドユーザー間の信頼性が高く高速なネットワーク接続が必要です。ネットワーク接続の低下やレイテンシの増加は、アプリケーションのパフォーマンスに影響を及ぼす可能性があり、クラウドの導入を妨げる可能性があります。
• ベンダー・ロックイン: ベンダー・ロックインは、クラウド・プロバイダを切り替えたり、ワークロードをオンプレミスのデータ・センターに戻す能力を制限できるため、組織にとって懸念事項です。これは、特にクラウド・プロバイダがオープン・スタンダードや相互運用性をサポートしていない場合、クラウド導入の技術的な制約になる可能性があります。
• コスト管理: クラウドの導入には、多大な先行コストと継続的な運用費用がかかり、予算が限られている組織にとって制約となる可能性があります。クラウドのコストを管理するには、専門的なツールと専門知識が必要であり、クラウドの導入を妨げる可能性があります。
• データ転送とレイテンシ: データをクラウドに移行する際のデータ転送時間と潜在的なレイテンシを考慮します。
• セキュリティとコンプライアンス: セキュリティとコンプライアンスの厳しい要件が、特定のクラウド導入の決定に影響を与える可能性があります。
• リソースの制限: コンピュート・インスタンスやストレージなどのクラウド・リソースの可用性は、スケーラビリティに影響する可能性があります。
• スキルとトレーニング: クラウド・テクノロジの専門知識が不足すると、実装が妨げられる可能性があります。

次のステップ

クラウド導入のセキュリティ・アーキテクチャの定義