Resource Management:リソースグループ設計のベストプラクティス

背景情報

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

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

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

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

リソースグループ設計の原則

リソースグループを設計する際には、リソースグループの計画、標準実行、およびチェックと評価の手順を実行することをお勧めします。設計中は、各ステップの原則に従う必要があります。

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

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

• 共有: 一部のリソースを複数のプロジェクトまたは業務システムで共有する必要がある場合は、これらのリソースを格納するための専用のリソースグループを作成し、他のリソースグループの名前と区別できるリソースグループ名を指定できます。たとえば、企業に2つの業務システムがあり、業務システムが同じVPC（Virtual Private Cloud）を使用しているとします。企業の各プロジェクトのリソースグループを作成し、共有リソースを格納するための専用のリソースグループを作成する必要があります。このようにして、VPC を専用のリソースグループに分類できます。

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

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

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

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

ベストプラクティス

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

• 事業部門: 業務システムのメンバーのみが業務システムのリソースにアクセスできるようにしたいと考えています。また、各業務システムで使用されているリソースを効率的に識別し、各業務システムで使用されているリソースを個別に監視および管理したいと考えています。

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

• O&M部門: リソースに対して効率的な O&M を実行したいと考えています。O&M部門は、異なる基準に基づいて 2 つの業務システムで使用されるリソースに対して O&M操作を実行する必要があります。たとえば、O&M部門は、できるだけ早く O&M を必要とするリソースを特定するために、毎朝午前 2 時に業務システム A で使用されるリソースに対して例外検査を実行する必要があります。

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

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

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