Resource Management:リソースグループを設計するためのベストプラクティス

背景情報

企業のクラウドリソースの数が増加するにつれて、リソース管理の効率を向上させ、O&Mリスクを軽減し、不要なコストを削減するために、最も早い機会にカテゴリ別にクラウドリソースを管理する必要があります。

リソースグループを使用すると、Alibaba cloudアカウント内のクラウドリソースをカテゴリ別に管理できます。 各リソースはリソースグループに属する必要があり、1つのリソースグループにのみ属することができます。 リソースグループは、リソース管理に次の利点を提供します。

• 管理効率の向上: リソースをさまざまなリソースグループに分類した後、リソースのデプロイ、リソースのモニタリング、およびリソースグループごとのリソースに対する権限の管理を行うことができます。 たとえば、プロジェクトグループのメンバーに特定のプロジェクトグループのリソースに対してのみ権限を付与する場合は、プロジェクトグループのリソースグループを作成し、プロジェクトグループのリソースをリソースグループに転送してから、メンバーにリソースグループに対する権限を付与できます。 これにより、メンバーは、関連するアカウントのすべてのリソースに対する権限ではなく、リソースグループ内のリソースに対する権限のみを持ちます。 リソースグループのリソースが変更された場合、メンバーの権限設定を変更する必要はありません。 これにより、権限設定のメンテナンスコストを削減できます。

• Reduce O&M risk: リソースをリソースグループに分類する場合、各リソースはリソースグループに属している必要があり、1つのリソースグループにのみ属することができます。 したがって、異なるリソースグループで同じリソースを管理することによって発生する可能性のあるリスクを心配する必要はありません。 たとえば、リソースグループごとに一度に複数のリソースの名前を変更するO&M操作を実行する場合、同じリソースで実行される異なるO&M操作によって発生する可能性のある競合について心配する必要はありません。

リソースグループを設計するための原則

リソースグループを設計するときは、リソースグループの計画、標準実行、確認と評価の手順を実行することを推奨します。 設計中の各ステップの原則に従わなければなりません。

• 相互排他性: リソースグループを計画するときは、分類ディメンションが相互排他的であることを確認する必要があります。 たとえば、部門、プロジェクト、機能、およびリソース配置環境ごとにリソースを分類できます。 これにより、リソースがビジネスの観点から1つのリソースグループのみに属することを保証できます。 たとえば、生産環境におけるプロジェクトAとプロジェクトAの分類ディメンションは、相互排他性の原則に準拠していません。 リソースを複数のビジネスシステムで使用する必要がある場合は、共有の原則に従ってリソースグループを設計できます。

• 包括性: リソースグループを計画するときは、すべてのリソースを適切なリソースグループに分類できることを確認する必要があります。 また、その後のビジネスの発展と変化を考慮する必要があります。 これにより、不適切な分類ディメンションによるリソースグループの調整に起因するリスクや追加コストを防ぐことができます。 リソースをデフォルトのリソースグループに分類しないことを強くお勧めします。 デフォルトのリソースグループはシステムによって生成され、削除できません。 分類されていないAlibaba Cloudアカウントのリソースは、デフォルトリソースグループに追加されます。 カスタムリソースグループを使用してリソースを分類することを推奨します。

• 共有: 一部のリソースを複数のプロジェクトまたはビジネスシステムで共有する必要がある場合は、これらのリソースを格納する専用リソースグループを作成し、他のリソースグループの名前と区別できるリソースグループ名を指定できます。 たとえば、企業には2つのビジネスシステムがあり、それらのビジネスシステムは同じ仮想プライベートクラウド (VPC) を使用しています。 企業のプロジェクトごとにリソースグループを作成し、共有リソースを格納する専用のリソースグループを作成する必要があります。 これにより、VPCを専用リソースグループに分類できます。

• 最小権限の原則: リソースグループによる権限付与を実行する場合は、最小権限の原則に従う必要があります。 たとえば、企業には複数のビジネスシステムがあり、各ビジネスシステムは複数の環境に展開されます。 企業は、デプロイ環境ではなく業務システム別にリソースグループを計画し、リソースグループ別に認可を行う。 その結果、開発環境のリソースを使用するRAMユーザーが本番環境のリソースに対する権限を持つ可能性があり、本番環境のビジネスシステムのセキュリティと安定性の問題が発生する可能性があります。

• 標準命名: リソースグループの名前は単純で、特定の標準に準拠し、ビジネスに関連している必要があります。 これにより、リソースグループを簡単に識別および管理できます。 たとえば、本番環境のリソースグループ名Project Aは、標準の命名原則に準拠しています。 リソースグループ名の本番環境は、明確なビジネスシステムの意味を持たないため、標準の命名原則に準拠していません。

• タイムリーな調整: リソースグループの既存の分類ディメンションがビジネス開発の要件を満たすことができない場合、ビジネス開発から発生する可能性のあるリスクと追加コストを防ぐために、できるだけ早い機会に分類ディメンションを調整する必要があります。 たとえば、企業のリソースを部門ごとに異なるリソースグループに分類します。 ビジネスが発展するにつれて、企業の各部門には複数のビジネスシステムがあります。 その結果、部門による分類は、権限分離の要件を満たすことができません。 この問題を解決するには、企業のリソースをビジネスシステムごとに分類する必要があります。 できるだけ早い機会に分類ディメンションを調整することを推奨します。

• タイムリーなクリア: 特定のリソースグループが不要になった場合、管理コストを削減するために、リソースグループをできるだけ早く削除する必要があります。 不要になったリソースグループをマークするために、DeprecatedやDeletedなどの識別子を使用しないことを推奨します。 リソースグループを削除することを推奨します。 たとえば、企業のリソースをプロジェクトごとに異なるリソースグループに分類し、プロジェクトAやプロジェクトBなどのリソースグループを作成します。プロジェクトAが不要になった場合は、プロジェクトAのリソースを別のリソースグループに転送するか、プロジェクトAのリソースをリリースしてプロジェクトAを削除する必要があります。

ベストプラクティス

インターネット企業には2つのオンラインビジネスシステムがあり、テスト環境と本番環境にオンラインビジネスシステムを展開して、サービス機能の継続的な反復と開発の要件を満たします。 2つのビジネスシステムは、環境内で複数のタイプのクラウドリソースを使用します。 ビジネス部門に加えて、企業には財務、O&M、およびコンプライアンス監査部門もあります。 これらの部門では、クラウドリソース管理の要件が異なります。 以下に詳細を説明します。

• ビジネス部門: ビジネスシステムのメンバーだけがビジネスシステムのリソースにアクセスできることを期待しています。 また、各業務システムで使用されているリソースを効率的に特定し、各業務システムで使用されているリソースを個別に監視・管理したいと考えています。

• 財務部門: 企業全体のリソース料金と各ビジネスシステムのリソース料金を理解したいと考えています。

• O&M部門: リソースに対して効率的なO&Mを実行することを望んでいます。 O&M部門は、2つのビジネスシステムが使用するリソースに対して、異なる標準に基づいてO&M操作を実行する必要があります。 たとえば、O&M部門は、毎朝02:00にビジネスシステムAが使用するリソースに対して例外検査を実行して、最も早い機会にO&Mを必要とするリソースを特定する必要があります。

• コンプライアンス監査部門: 企業のすべてのクラウドリソースのコンプライアンスを監査し、すべてのリソースが法律や規制、業界標準、および企業のコンプライアンス要件に準拠していることを要求します。 ただし、ビジネスシステムで使用されるリソースのコンプライアンス基準が異なるため、コンプライアンス監査部門は差別化されたコンプライアンス監査を実装することを望んでいます。

上記の要件を満たすために、企業は、ビジネスシステムおよび環境ディメンションからリソースグループを同時に設計し、次のリソースグループを作成します。開発環境のビジネスシステムA、生産環境のビジネスシステムA、開発環境のビジネスシステムB、および生産環境のビジネスシステムB。 さらに、企業はリソースグループに対する権限を関連する機能担当者に付与します。

企業がすべてのリソースをリソースグループに分類した後、リソース管理に関するさまざまな機能担当者の要件が満たされます。