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