統合に関する推奨事項
この Azure Well-Architected Framework のコスト最適化チェックリストの推奨事項に適用されます:
| CO:14 | リソースと責任を統合します。 ワークロード内で、リソースを統合して密度を高める方法を決定します。 ワークロード外では、既存の一元化されたリソースとサービスを使用して、ワークロードの責任を統合できます。 |
|---|
このガイドでは、ワークロード コストを最適化するためにリソースと責任を統合するための推奨事項について説明します。 リソースの統合は、単に無駄を排除することとは異なる微妙なタスクです。 統合には、サーバー、データベース、アプリケーション、責任などのワークロードのコンポーネントを組み合わせることが含まれます。
統合により、冗長なリソースとライセンスを削減し、密度を高めることができます。 ワークロードの責任を統合する機会を探します。 一元化されたリソースまたはチームを使用してコストを最適化します。 共有リソースを使用し、スケール メリットを最適化してリソースと責任を統合しないと、コスト削減の機会を逃す可能性があります。
定義
| 相談 | 定義 |
|---|---|
| 一元化されたリソース | 各コンポーネントが独自の専用リソースを持つのではなく、複数のコンポーネントが使用する共有リソース。 |
| 変更管理 | 変更を管理および実装するための構造化された手法。 |
| Consolidate | ワークロードの要件を最適に満たすためにコンポーネントを組み合わせる行為。 |
| リソース密度 | リソース内の論理的な分離の尺度。 密度の増加は、通常、さまざまなコンポーネント、コンシューマー、または環境の併置による使用率の向上につながります。 |
主要な設計戦略
統合の主な目的は、削減ではなく最適化です。 統合には、コスト効率を最大化するためにワークロード、リソース、チームの役割を再構築することが含まれます。 コンポーネント コストの最適化とは異なり、統合は慎重な検討を必要とするプロセスです。
ほぼすべての統合作業にはトレードオフと潜在的なリスクがありますが、コストを大幅に削減できます。 潜在的利益とそれに伴うトレードオフを分析することが重要です。 すべての統合戦略は、次の手順に従います。
"評価": 徹底的な評価を実行して、統合が有利になる可能性のある領域を特定します。
"識別と評価": 潜在的な統合対象を特定して評価し、潜在的な費用便益とトレードオフが統合の取り組みを正当化するかどうかを判断します。
"コミュニケーションと実装": 統合が有益であると判断した場合は、差し迫った変更を発表して適用します。
リソースを統合する
リソースの統合には、ワークロード内のリソースの結合が含まれます。 機能またはコンシューマーを併置できます。 たとえば、3 つの Web サーバーを 1 つのサーバーに統合したり、3 つのデータベースを 1 つのデータベース サーバーに統合したりできます。 複数のファイアウォールを複数の環境をサポートする 1 つのファイアウォールに統合することもあります。
目的は、リソース密度を高めて、各リソースのコスト効率を最大化することです。 リソースの使用を拡大し、リソースの冗長性を最小限に抑えます。
統合できるサービスの一般的な種類には、アプリケーション プラットフォーム、データベース、ネットワーク アプライアンス、ゲートウェイ、分散型サービス拒否 (DDoS) 保護などがあります。 ワークロード内のリソースを統合するには、次の推奨事項を検討してください。
ワークロード リソースを評価します。 既存のワークロードとそのリソース使用率を評価します。 CPU 使用率、メモリ使用量、ストレージ容量、ネットワーク帯域幅などの要因を分析します。 統合が有益な領域を特定します。 統合には、リソースの割り当ての最適化、冗長または十分に活用されていないリソースの排除、ワークロードをより効率的に実行するための再構成が含まれる場合があります。 ワークロードの依存関係、パフォーマンス要件、スケーラビリティなどの要因を考慮してください。
統合ターゲットを特定します。 統合するリソースを選びます。 既存のリソースでも、ワークロード内で作成された新しいリソースでも構いません。 統合に使用できる既存のリソースを特定します。 たとえば、ワークロード コンポーネントの一部に対応できるサーバーがある場合があります。 統合要件を満たしている既存のリソースがない場合、または新しいリソースを統合する方が有益な場合は、新しいリソースの作成を検討してください。
統合の実行可能性を評価します。 CPU、メモリ、拡張などの機能と技術面の要件が統合をサポートしていることを確認します。 パフォーマンス、信頼性、セキュリティなどの要件を妥協しないでください。 たとえば、望ましくないリージョン間の依存関係を作成したり、運用前環境と運用環境間でリソースを統合したりしないでください。
コストを見積もります。 統合の労力と潜在的な複雑さを判断します。 リソース、ライセンス、運用費などのコストを計算する必要があります。 統合によるリソース監視における潜在的な課題など、影響を考慮してください。
チームとコミュニケーションを取り、調整します。 すべての関係者に、今後の変更と必要なアクションについて確実に通知します。 競合を回避し、円滑な実装を確保するためにチームと連携します。
リスク: ノイジー ネイバー、スケール ユニット効果、冗長性の低下など、リソース密度の影響を考慮してください。 ミッションクリティカルおよびビジネスクリティカルなワークロード フローにとって、リソースの統合はリスクが大きすぎることがよくあります。
トレードオフ:
リソースの統合により分離性が低下し、ワークロードにノイジー ネイバー シナリオが発生する可能性があります。 ホスティング環境の論理分離と容量の増加を実装する他の方法を見つけます。 たとえば、ファイアウォールで複数のワークロードがサポートされている場合は、その容量を増やします。
統合によりセグメント化が排除され、攻撃者が水平方向に移動しやすくなり、セキュリティ リスクが高まる可能性があります。 また、一部のコンプライアンス基準を達成するのが難しくなります。 統合よりもコンプライアンスを優先してください。
リソースの統合により、冗長性が低下します。 ワークロードで適切な信頼性を確保するために慎重に計画してください。
責任を統合する
ワークロードの責任を統合する目的は、ワークロード チームの責任を軽減することです。 これは、組織の認識とワークロード チーム外のコラボレーションを必要とする戦略的なコスト最適化の取り組みです。
ワークロード チームの責任を統合するには、主に 2 つの方法があります。 外部の共有または一元化されたリソースを使用して、そのリソースをワークロード環境で実行しないようにすることができます。 また、ワークロードの責任を組織内の他のチームに委譲して、チームがそれらのタスクや人員の直接的な責任を負わないようにすることもできます。
外部の一元化されたリソースを使用する
外部の一元化されたリソースとは、ワークロード環境外の共有リソースを指します。 たとえば、企業は複数のワークロードをサポートする一元管理されたゲートウェイを持つことがあります。 外部の一元化されたリソースの目的は、重複とオーバーヘッドを最小限に抑えることです。 ワークロード専用のリソースを用意する代わりに、共有リソースを使用してコストを最適化できます。 次のレコメンデーションを検討してください:
ワークロード リソースを評価します。 ワークロードの現在の状態を評価し、統合が有益である可能性のある領域を特定します。
外部の機会を見つけます。 組織内の既存の一元化されたリソースを調査します。 これらのリソースが、ワークロードに対する潜在的な解決策となる可能性があります。 たとえば、独立した SIEM ツールを設定する代わりに、セキュリティ情報イベント管理 (SIEM) を使用できます。
変更管理を検討します。 一元化されたリソースに対する変更を管理するプロセスについて理解します。 承認ワークフロー、テスト プロトコル、デプロイ方法を検討します。 リソース変更の制御を減らした場合は、潜在的な課題を分析します。
コストを見積もります。 一元化されたリソースを実装する前に、移行に関連するコストに対して予想される節約額を明確に定量化します。 コスト削減のメリットとリスクを比較検討し、情報に基づいた意思決定を行います。
チームとコミュニケーションを取り、調整します。 懸念事項に対処し、コラボレーションを改善し、プロセスを改善するために、チーム間で継続的なフィードバックを行うメカニズムを確立します。
変更を文書化して追跡します。 承認されたすべての変更について、その範囲、実装手順、関連するリスクや問題など、詳細なドキュメントを保持します。 一元化されたシステムまたは変更管理ツールを使用して、ライフサイクル全体にわたって変更の状態を追跡および監視します。
外部チームに責任を委譲する
ワークロードの責任を外部チームに委譲することは、セキュリティ オペレーション チームなどの特殊なサービスを実行する専門家の集中型チームを使用することを指します。 既存のチームに責任を委譲すると、コストを最適化し、特定の機能の専門知識を委任することができます。
チーム スキルを評価します。 チームの現在のスキル セットを評価します。 スキルのギャップや、集中型チームがコストを最適化できる領域を特定します。
利用可能な機会を見つけます。 セキュリティ オペレーション チームのサービスなど、組織で利用可能なサービスを調べます。 集中型チームが品質を損なうことなく、追加の責任に対応できることを確認します。
変更管理を検討します。 承認ワークフロー、テスト プロトコル、デプロイ戦略など、集中型チームが変更を処理する方法を理解します。 これらの機能を直接制御できない場合に発生する可能性のある潜在的な課題を特定します。
チームとコミュニケーションを取り、調整します。 チームが互いのプロセス、ツール、期待を十分に理解していることを確認します。 移行を円滑にし、潜在的な課題を早期に特定するために、段階的な移行またはパイロット期間を検討します。
変更を文書化して追跡します。 承認されたすべての変更について、その範囲、実装手順、関連するリスクや問題など、詳細なドキュメントを保持します。 一元化されたシステムまたは変更管理ツールを使用して、ライフサイクル全体にわたって変更の状態を追跡および監視します。
Azure ファシリテーション
密度のサポート: 多くの Azure サービスでは、リソース密度の向上がサポートされています。 次の表は、これらのサービスの例を示しています。
| Azure サービス | セグメント化制御 |
|---|---|
| Azure Front Door | 顧客のドメインと URL パス |
| Azure Firewall | ネットワークとアプリケーション ルール |
| Azure Application Gateway | リスナー、URL パスベースのルーティング |
| API Management | API ポリシー |
| Azure Kubernetes Service (AKS) | 名前空間、ノード プール |
| Azure App Service | App Service プラン上の複数の Web アプリと API |
| Azure SQL データベース | サーバー上の複数のデータベース |
リソースの可観測性: Azure Monitor により、Azure リソースのパフォーマンスと正常性を監視および管理するための一元化されたプラットフォームが提供されます。 利用統計情報の収集と分析、アラートの設定、リソース使用率と統合の機会に関する分析情報を得ることができます。
Log Analytics により、一元的なログ管理と分析が提供されます。 さまざまな Azure リソースからログ データを収集、分析、視覚化できるため、問題の特定、問題のトラブルシューティング、運用上の分析情報の取得に役立ちます。
関連リンク
コスト最適化チェックリスト
レコメンデーションの完全なセットを参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示