このトピックでは、タグ設計の背景、原則、ベストプラクティス、および例について説明します。
背景情報
企業が保有するクラウドリソースが少数である場合、記憶や手作業の記録によって分類できます。 しかし、クラウドリソースの数が増加し、大企業では数千に達することもあるため、手作業による分類は信頼性が低くなり、プラットフォームベースのソリューションが必要になります。
Alibaba Cloud では、タグを使用してリソースをマークし、分類できます。 リソースを作成する際に、ビジネスや財務上の所有権などのプロパティをタグとして設定できます。 たとえば、作成者、リージョン、またはプロジェクト別にリソースにタグを付けることができます。 リソース作成時にタグを付けないと、後でリソースのプロパティを整理することが非常に困難になります。
タグ設計の原則
-
相互排他性の原則
相互排他性の原則により、同じリソース属性に対して複数のタグキーを使用することはできません。たとえば、タグキー owner を使用してリソースの所有者を識別する場合、own、belonger、または owner_cn などの類似したキーは使用しないでください。
-
網羅性の原則
網羅性の原則では、すべてのリソースに、計画されたタグキーとそれに対応するタグ値が付与されている必要があります。たとえば、ある企業に 3 つのゲームプロジェクト部門があり、タグキーとして プロジェクト を使用する場合、これらの部門を表すために、少なくとも 3 つのタグ値が必要になります。
包括的かつ網羅的なタグ付けの原則は、リソースの検索、コスト配分、自動化された O&M、アクセス制御など、タグディメンションに基づく操作の前提条件です。
-
限定値の原則
限定値の原則は、リソースのコアとなるタグ値のみを保持し、冗長なものを削除することです。 たとえば、ある会社に 5 つの部門がある場合、部門のタグキーに対応するタグ値は 5 つだけであるべきです。 これにより、管理が簡素化されます。
限定値の原則により、リソースの検索、コスト配分、自動化された O&M、およびアクセス制御が簡素化されます。
-
将来の変更を考慮する原則
タグを設計する際は、タグ値の追加や削除による影響を考慮して、将来の変更に備えて計画してください。ビジネス境界を明確に定義することで、タグの柔軟性が高まり、変更が容易になります。例えば、クラウドを初めて利用する企業は、事業運営が一元化されており、リソースの所有権、財務上の所有権、および自動化された O&M を管理するために、department のような単一のタグを使用する場合があります。企業が成長するにつれて、この単一のタグはビジネスロジックで過負荷になり、後で分離する際にコストがかかり困難になる可能性があります。したがって、クラウド導入の初期段階で、タグに対するビジネス要件を評価する必要があります。この例では、最初から department、costcenter、および ops タグを使用する方が適切です。
タグを変更すると、タグベースのアクセス制御、自動化された O&M、または関連する請求レポートに影響を与える可能性があります。 企業および個人の両方のユースケースで、技術、ビジネス、セキュリティのディメンションからリソースを管理するために、ビジネス関連のタグを作成する必要があります。 自動化された O&M を使用してリソースとサービスを管理する場合は、自動化タスクを支援するために、追加の専用タグを設計する必要があります。
-
簡略化された設計の原則
シンプルな設計の原則とは、ビジネスニーズに合わせて、シンプルなキーと値を持つ固定のタグセットを使用することです。たとえば、プロジェクト環境のタグを設計する場合、テスト環境には、test-environment のような一貫性のあるタグキーを使用します。pre-test-environment や formal-test-environment のように、類似したキーを複数使用しないでください。
この原則により、タグキーが多すぎることによる運用上のエラーを減らすことができます。
-
標準化された命名の原則
標準化された命名の原則は、タグに標準の命名形式を使用して、さまざまなオープンソースツールとの互換性を確保し、将来の API 統合を簡素化することです。 たとえば、タグ名に英単語が含まれる場合は、小文字のみを使用します。
タグ設計のベストプラクティス
あるインターネット企業には、ビジネス部門、マーケティング部門、O&M 部門の 3 つの部門があります。 各部門は 1 つ以上のプロジェクトを管理します。 各プロジェクトには、さまざまなライフサイクル段階に対応する本番環境、開発環境、テスト環境があります。 O&M チームは、会社のリソースをリアルタイムで監視し、各プロジェクトのコストを定期的に配分し、リソースへのアクセスを制御し、自動化された O&M を実装する必要があります。
これらの要件を満たすために、同社は次のようにタグを設計しました。
|
要件 |
タグ設計 |
説明 |
|
リソースの検索と管理 |
すべてのリソースに次の 3 つのレベルのタグを作成してアタッチします：
|
企業の組織階層が深い場合は、支社 (会社) のタグなど、より高いレベルのタグを追加することを検討してください。 |
|
コストとコスト配分の管理 |
すべてのリソースにコストセンタータグを作成してアタッチします：
|
なし |
|
リソースのアクセス制御 |
プロジェクトメンバー以外が ECS インスタンスなどのプロジェクトリソースにアクセスするのを制限します。 |
詳細については、「タグを使用してRAM ユーザーによる特定のECS インスタンスの管理を制限する」をご参照ください。 |
|
自動化された O&M |
日次リソース検査用に、キーが purpose の目的タグを作成します。値を autocheck-8am に設定して、毎日午前 8:00 の自動検査であることを示します。検査で異常が検出された場合は、リソース所有者タグ owner を使用して、担当者に対処するよう通知します。 |
なし |
タグ設計の例
次の表は、一般的なディメンションのタグ設計の例を示しています。
|
分類ディメンション |
タグキー |
タグ値 |
|
組織構造 |
|
関連する名前 |
|
ビジネスアーキテクチャ |
|
関連する名前 |
|
ロールアーキテクチャ |
|
|
|
目的 |
|
目的の値 |
|
プロジェクト |
|
正確な情報を提供していることを確認してください。 |
|
事業部門 (コスト配分およびビジネストラッキング用) |
|
実際の値 |
|
財務ディメンションの所有者 (リソースの所有者を識別するため) |
owner |
名前またはメールアドレス |
|
財務ディメンションの顧客 (リソースサービスの顧客を識別するため) |
customer |
顧客名 |
|
財務ディメンションのプロジェクト (リソースがサポートするプロジェクトを識別するため) |
project |
プロジェクト名 |
|
財務ディメンションの注文 |
order |
注文カテゴリ ID |