タグ付けを使用したコストデータの管理

Cost Management Service 1-latest

リソースの整理とタグを使用したコストの割り当て

Red Hat Customer Content Services

概要

Cost management におけるタグ付けの仕組みと、タグとラベルを使用してコストデータを管理するためのストラテジーについて学習します。Cost Management は、Red Hat Insights ポートフォリオサービスに含まれます。高度な分析ツールである Red Hat Insights スイートは、運用、セキュリティー、およびビジネスへの影響を特定して優先順位を付けるのに役立ちます。

第1章 タグ付けストラテジーの計画

1.1. タグの使用

タグ (OpenShift ではラベルと呼ばれています) は、リソースに割り当てることができるカスタムメタデータの文字列です。Cost management では、タグを使用すると、環境のさまざまな部分にコストを割り当て、コストデータをより正確に把握できます。

クラウドやクラスター内のプロジェクトなどの階層と組み合わせてタグを使用できます。クラウドプロバイダーは、リソースに関連付けることができるタグの数に制限を設けているため、Cost management のタグ付けストラテジーを計画する必要があります。

タグは、次の目標を達成するのにも役立ちます。

  • ビジネス概念をレポートにマッピングする
  • ビジネスコンセプト別にコストを表示する
  • ビジネスの自動化、運用プロファイル、アクセスおよびセキュリティー制御などの操作を定義する
  • タグに基づいてポリシーを適用する
  • プロジェクトやサブプロジェクトを使用できない場合は、リソースをより小さな単位に分割します。
  • 環境、コストセンター、またはチームが同じ複数のクラスターにおけるインテグレーションとグループアプリケーション間の関係を識別する
  • RDS データベースとそれを使用する OpenShift プロジェクトなどのリソース間に直接リンクがない場合に依存関係を識別する

1.2. タグのストラテジーの作成

タグのストラテジーを計画するときは、統合のコストをどのように整理して報告するかを検討する必要があります。組織の目標を達成するために必要と思われる最小限のタグ数から始めます。さらに必要な場合は、時間をかけてゆっくりと構築してください。

次のセクションでは、タグの作成を開始する前に考慮すべき重要な事項について説明します。

値の優先順位:

複数の値が特定のリソースの同じ値に関連付けられている場合に、Value precedence は、どの値が優先されるかを判断する基準を参照します。タグでグループ化するときにコストが重複しないようにするには、各タグまたはラベルキーがすべてのリソースに対して一意である必要があります。

値の優先順位を検討する方法の詳細は、「タグ値の優先順位の理解」 を参照してください。

ビジネスをレポートにマッピングする:

レポートするビジネスパースペクティブを定義します。たとえば、Cost Management の分類法では、次のさまざまな観点を考慮することができます。

+ .所有権と使用法: リソースの所有者およびユーザーの定義: たとえば、リソースを要求したユーザーの一意の ID、およびそのリソースを実際に消費しているユーザーの一意識別子。

+ .テナンシー: 環境が共有されている場合は、どのグループまたはビジネスユニットがリソースを要求しているかを理解することが有益な場合があります。ユーザーが異なるグループの一部である場合は、1 つのグループを選択する必要があります。コストレポートについては、コストセンターを使用して、多くのケースでこれを実現できます。ただし、部署、プロジェクト、またはパートナーも優れた候補です。

+ .ロケーション: グローバルにデプロイされた組織の場合、クラウドプロバイダーはリソースが実行しているリージョンを特定しますが、プライベートクラウドは異なる場合があります。

+ .環境またはステージ: リソースを作成または実行している環境に応じて異なるコスト決定を行うことができるように、開発と本番を区別することを推奨します。開発パイプラインに、開発、テスト、ステージング、実稼働前、実稼働などのステージがすでに含まれる場合、これは適切な候補となります。

+ .アプリケーション / プロジェクト / サービス / イベント: 使用している環境では、イベント用の一時的なリソースグループ (例: 顧客中心の年次会議) などのサービスが提供されている場合もあります。さらにアプリケーションバージョンを含めることもできます。

ラベルの標準化

一貫性は、タグ付けストラテジーの中で最も重要な要素で、正確で比較可能なコストレポート結果を提供します。

タグ付けする必要のあるリソース、必須のタグ、任意のタグを定義する明確なタグ付けポリシーを作成し、解釈の余地がないことを確認します。

リストの中から値を選択する必要がある場合は、それらの値が定義されていて、一貫性があり、簡単にアクセスできること、またはリストがユーザーに提示されていることを確認してください。たとえば、key ‘Development’ で開発を定義する場合は、Dev、DEV、R&D などのバリエーションを使用せず、Development としてリソースを特定します。

インテグレーション上のすべての要素にタグを付ける (手動または自動化を通じて)

タグ付けされていないリソースは、できるだけ多くの要素で報告できないため、人間によるエラーを防ぐために自動化を使用していることが理想的です。インテグレーションには、タグ付けに利用できるさまざまな自動化機能があります。

  • Azure では、Azure ポリシーを使用して、タグ付けのルールおよび規則を適用し、期待に従わないリソースがデプロイされないようにすることができます。プロビジョニング時に必要なタグを自動的に適用するポリシー、日付に事前定義された形式を適用するポリシー、または一部のリソースタイプに一部のタグを必須にするポリシーを作成できます。
  • AWS では、同じものに IAM ポリシーを使用できます。さらに、Ansible などの自動化ツールを使用して、プロビジョニング中に必要なタグを追加し、すべてのリソースが適切にタグ付けされていることを確認できます。
  • OpenShift Container Platform には、ラベルリングを自動化する方法がありません。
タグの頻繁な確認と改良 (必要に応じて)

タグを定義し、後でタグ付けスキームを調整する必要がある場合でも、Cost Management で可能な限り早くそれらを使用します。

結果のレポートをビジネスオーナーや利害関係者と早い段階で確認して、タグが目的のレポートの生成に役立っていることを確認し、タグ付けストラテジーを数週間ごとに確認して最適化します。

タグの用語の選択
  • メタデータにアクセスせずにリソースを識別できる名前をリソースに付けてから、メタデータを追加して続行します。クラウドの多くは、正しく行う方法についてのガイドがあります。リンクについては、5章関連情報 を参照してください。
  • リソースをキーと値にマップします。キーはパースペクティブにマップされますが、値は各キーで許可されるさまざまなオプションを定義します。場合によっては、値は Null になります。
注記

すべてのインテグレーションで同じ識別子が許可されるわけではなく、異なる制限があります。インテグレーションごとの制限については、「インテグレーションタイプ別のタグ仕様」 を参照してください。

1.3. タグ値の優先順位の理解

複数の値が特定のリソースの同じ値に関連付けられている場合に、Value precedence は、Cost management でどの値が優先されるかを判断する基準を参照します。タグでグループ化するときにコストが重複しないようにするには、各タグまたはラベルキーがすべてのリソースに対して一意である必要があります。

1.3.1. OpenShift の値の優先順位

OpenShift では、可能な限り最も具体的な値を維持する基準を作成します。

1.3.1.1. namespace、ノード、および Pod ラベル

各リソースに同じキーがある場合、Pod 値はノード値と名前空間値の両方をオーバーライドします。Cost management では、これらのレベルのラベルが内部で実行されているワークロードに特化しているため、Pod の値が優先されます。ノードラベルと namespace ラベルはより一般的であり、特性の概要を記述します。

namespace、ノード、および Pod ラベルには次の値が優先されます。

  1. Pod のラベル
  2. 名前空間ラベル
  3. ノードラベル

1.3.1.2. 永続ボリュームおよび永続ボリューム要求ラベル

永続ボリューム (PV) は、ノードまたは名前空間から独立して存在するクラスター内のリソースです。Pod は、利用可能な PV からそれらのリソースを要求するために、永続ボリューム要求 (PVC) を作成します。リクエストがこれらの PV のいずれかの基準に一致すると、Pod はこれらのクレームをボリュームとして使用します。

PV および PVC の値は、以下のようになります。

  1. 永続ボリューム要求のラベル
  2. 永続ボリュームラベル
  3. Pod のラベル
  4. 名前空間ラベル
  5. ノードラベル

1.3.1.3. Openshift によってフィルタリングされたクラウドデータ

OpenShift によって何かがフィルタリングされると、OpenShift クラスターの実行に関連するクラウドプロバイダーのコストが示されます。クラウドプロバイダーと OpenShift ソースのコストレポートに一致するタグまたはリソース ID がある場合、Cost management は 2 つのレポートを相関させます。この相関関係は、クラウドプロバイダーのコストのうち OpenShift の実行に関連するコストを計算します。

2 つのレポートのタグとラベルを 1 つに結合しますが、クラウドインスタンスがデータの元のソースであるため、Openshift ラベルではなくクラウドインスタンスのタグを優先します。

  1. クラウドインスタンスのタグ
  2. OpenShift ラベル

第2章 タグを使用したコストデータの管理

Cost management におけるタグの仕組みと、タグを使用してリソースを最適に整理および表示し、コストを管理する方法について学習します。

2.1. タグマッピングの有効化および作成

タグマッピングは、クラウド統合全体で複数のタグを組み合わせる場合です。タグマッピングを使用すると、1 つのタグキーで同様のタグをグループ化してフィルタリングできます。

タグをマップするには、まずタグを有効にする必要があります。Cost management では、有効にできるタグの数は 200 個に制限されています。以下の手順を実行します。

  1. Cost Management から Settings をクリックします。
  2. ヘッダータブ Tags and labels をクリックします。
  3. ドロップダウンメニューの Enable tags and labels をクリックします。
  4. 有効にするタグを選択します。タグをクリアするには、これを無効にします。
  5. 次に、Map tags and labels ドロップダウンメニュー、Create a tag mapping の順にクリックします。
  6. 開いたウィザードで、子タグを作成するタグを選択します。Next をクリックします。
  7. 親タグとして使用するタグを 1 つ選択します。このアクションにより、親タグは前のステップで選択した子タグにマッピングされます。Next をクリックします。
  8. 選択内容を確認し、Create tag mapping をクリックします。

2.1.1. 重複キーのトラブルシューティング

すべてのリソースについて、各タグキーは一意であり、値は 1 つだけである必要があります。ただし、タグをマップすると、このルールに違反するシナリオが意図せず作成され、複数の値が作成される可能性があります。

通常、値が複数あるとコストが重複します。ただし、重複を避けるために、Cost Management では 1 つのキーの値が優先されます。Cost management で値を優先し、それに応じて計画を立てる方法については、「タグ値の優先順位の理解」 を参照してください。

2.1.1.1. トラブルシューティングの例

AWS 上で EC2 インスタンスを実行している次の例を考えてみましょう。このインスタンスには次のキー > 値のペアでタグ付けしました。

  • app > cost-management
  • App > Insights

Cost Management では、appApp にマッピングしました。したがって、同じ EC2 インスタンスには次のキー > 値のペアが存在します。

  • App > cost-management
  • App > Insights

このような状況では、Cost management では、App のキー > Insights の既存の値が優先されます。Cost management では、コストの重複を防ぐために、app キーとその値 cost-management の関連付けを AWS リソースから削除します。App=cost-managementApp=insight コストに追加されます。

App は親キーとして設定されているため、Cost management ではタグマッピング内の app の値よりもその値が優先されます。したがって、親タグを設定する前に、タグマッピングストラテジーを検討する必要があります。

重複キーに関する問題をトラブルシューティングするには、タグキーが一意であり、値が 1 つだけであることを確認します。キーの優先順位を設定する方法は、「タグ値の優先順位の理解」 を参照してください。。

第3章 Cost Management でのタグおよびラベルの設定

Cost Management がタグを使用してコストデータを自動的に整理できるようにするには、各インテグレーションでタグを設定する必要があります。

Cost Management にインテグレーションを追加した後、以下を行います。

  1. 各インテグレーションでリソースにタグを付けるかラベルを付けます。「インテグレーションでのタグの設定」を参照してください。
  2. コストデータの表示を最適化するには、タグに絞り込み、追加します。「タグのストラテジーの作成」を参照してください。
注記

インテグレーションの設定手順の詳細は、Cost Management スタートガイド ガイドを参照してください。

3.1. Cost Management によるタグの関連付け方法

AWS と Microsoft Azure のタグと OpenShift のラベルは、キーと値のペアで構成されます。key:value ペアが一致すると、AWS/Azure および OpenShift コストは Cost Management によって自動的に関連付けられます。Cost Management でのタグ一致では、大文字と小文字が区別されません。たとえば、AWS リソースタグが付いた APP と OpenShift リソースタグが付けられた app は一致するとみなされます。

表3.1 例: 一致するタグ

ソースおよびリソースタイプキー

AWS リソース (RDS)

APP

Cost-Management

OpenShift Pod

app

cost-management

AWS リソースタグが複数の OpenShift プロジェクトに一致する場合、そのリソースのコストと使用状況は、一致したプロジェクト間で均等に分割されます。

これは、インスタンス ID とノードの関係によって一致する AWS コンピューティングリソースには当てはまりません。この場合、OpenShift クラスター内でのプロジェクトのリソース消費に関する情報を使用し、コストと使用状況は破損します。

デフォルトでは、Cost Management は、Amazon EC2 インスタンス ID または Microsoft Azure 仮想マシンインスタンス ID を、そのインスタンス上で実行されている OpenShift Container Platform ノードに関連付けることにより、AWS コンピュートの使用量とコストを追跡します。

3.1.1. Cost Management におけるタグのマッチング階層

AWS または Azure インスタンスで実行されている OpenShift リソースを識別するために、Cost Management は次の順序でインテグレーション間のタグを照合します。

  1. 直接リソースマッチング (AWS EC2 インスタンス ID または Azure 仮想マシンインスタンス ID)
  2. 特殊な OpenShift タグ
  3. カスタムタグ

3.1.2. Cost Management における OpenShift ラベルの継承

OpenShift ラベルは、クラスターからノード、プロジェクトから Pod への継承パターンに従います。クラスター内のすべての Pod にラベルを付けなくても、ノードまたはプロジェクトレベルでコストを関連付けることができます。

ノードとプロジェクトのラベルからのキーと値のペアは、Cost Management の Pod レベルで継承されます。クラスターとノードのラベルからのキーと値のペアは、各レベルの永続ボリューム要求 (PVC) によってプロジェクトレベルで継承されます。クラスター、ノード、またはプロジェクトのラベルごとにグループ化して、それらのワークロード内の関連する PVC を表示できます。

キーが Pod にすでに存在する場合、Pod 内のそのキーの値は残ります。Cost Management は、Pod の値をプロジェクトまたはノードの値で上書きしません。同様のプロセスがノードからプロジェクトまで発生します。

以下の例を参照してください。

例 1: ラベル app と値 costpod1 を Pod に割り当てます。この Pod のプロジェクトのラベルは、app ですが、値は、cost-project です。これらのリソースは、ラベル us-east-1 のノードで実行されています。ラベル app と値 costpod1 は Pod に関連付けられたままになります。

例 2: ラベルが app で値が cost-project のプロジェクトがあります。プロジェクトでは 3 つの Pod が実行していますが、それらにはラベルが付いていません。コスト管理は、ラベル app と値 cost-project をこれらの Pod に関連付けます。

3.1.3. 直接リソースマッチング (インスタンス ID)

インテグレーションでは、これらの識別子が自動的に適用されます。この形式のタグ付けにより、Microsoft Azure または AWS インスタンスと OpenShift ノードの間に直接リンクが提供されます。

AWS は、すべての EC2 インスタンスをリソース識別子 (i-01f44b3d90ef90055 など) に割り当てます。OpenShift ノードは、クラスターが AWS リソース識別子を使用して実行している AWS EC2 インスタンスに直接マッチします。Cost Management の OpenShift レポート (Prometheus データから生成) には、ノードのこの識別子が含まれています。同様に、Microsoft Azure では、Cost Management 用に各仮想マシンインスタンス ID が OpenShift レポートに含まれます。

3.1.4. 特殊な OpenShift タグ

コストを OpenShift に関連付けるために使用できる 3 つの特別な場合の AWS タグがあります。

  • openshift_cluster
  • openshift_node
  • openshift_project

これらのタグにはカスタムタグのマッチング優先順位があり、特に同じ AWS インスタンスで実行される異なる OpenShift クラスターのコストを区別するのに役立ちます。

このタグ付け方法を使用して OpenShift クラスターを識別するには、AWS インスタンスにキー openshift_cluster をタグ付けし、値として OpenShift インテグレーション名を指定します。次の例では、Cost Management アプリケーションの OpenShift インテグレーションの名前は dev-cluster です。

表3.2 例: OpenShift の特殊なタグ

ソースおよびリソースタイプキー

AWS リソース (RDS)

openshift_cluster

dev-cluster

OpenShift クラスター

タグは必要ありません。これは、Cost Management における OpenShift インテグレーションの名前が dev-cluster である場合に一致します。

タグは必要ありません。

3.1.5. カスタムタグ

任意の key:value の組み合わせをタグとして使用し、Cost Management は同一のタグキーと値を一緒に関連付けます。次に、タグキー、アカウント、サービス、リージョンなどでコストをグループ化し、そのタグのコストと料金を表示することもできます。

表3.3 例: カスタムタグ

ソースおよびリソースタイプキー

AWS リソース (RDS)

team

engineering

OpenShift Pod

team

engineering

3.2. インテグレーションでのタグの設定

Cost Management がインポートするタグを制御するには、各インテグレーションで表示するタグをアクティブ化または有効化します。

  • AWS タグをアクティブ化し、データエクスポートで選択して cost management にエクスポートする必要があります。手順については、Amazon Web Services (AWS) ソースの追加 ガイドの Cost Management のための AWS タグのアクティブ化 を参照してください。
  • Microsoft Azure タグは、Azure の日次データエクスポートスケジュールの設定 で設定されたコストエクスポートレポートの Cost Management にエクスポートされます。
  • OpenShift Container Platform のラベルは Cost Management Metrics Operator によってエクスポートされ、Cost Management が入力として使用するメトリクスレポートに含まれます。

3.2.1. AWS リソースへのタグの追加

Amazon は、EC2 インスタンスリソース識別子 (i-123456789 などの番号) などの特定の識別子を自動的に作成します。これは、Cost Management がタグと同様に使用します。

個別のリソースレベルで独自のタグを追加することもできます。これらのタグを Cost Management アプリケーションにエクスポートするには、コストおよび使用方法のレポートに対してアクティベートする必要があります。

以下の手順で、Cost Management の AWS タグを設定します。

手順

  1. AWS リソースにタグを作成し、これを適用します。

    注記

    互換性のあるサードパーティー Linux ディストリビューションから Red Hat Enterprise Linux (RHEL) に変換し、AWS でサードパーティー移行リスト用の RHEL を購入した場合は、RHEL システムの AWS Cost Allocation Tags タグをアクティブにします。コスト割り当てタグページで com_redhat_rhel タグを有効にします。RHEL のバージョンに一致するタグ値として、RHEL 7 ELSRHEL 8、または RHEL 8 ELS を入力します。

    AWS ドキュメントの手順については、User-Defined Cost Allocation Tags を参照してください。

  2. データのエクスポートを使用して、cost management アプリケーションで収集するタグをアクティブ化します。AWS Billing コンソールで、Cost Allocation Tags 領域からアクティブ化するタグを選択します。

    AWS ドキュメントの手順については、Activating the AWS-Generated Cost Allocation Tags を参照してください。

3.2.2. Microsoft Azure リソースへのタグの追加

Microsoft Azure インテグレーションを追加すると、仮想マシンインスタンスの識別子が自動的に作成され、Cost Management ではこれをタグと同様に使用して、Azure リソースを関連する OpenShift リソースに関連付けます。

Microsoft Azure に個別のリソースレベルで独自のタグを追加することもできます。

Microsoft Azure のドキュメント Use tags to organize your Azure resources and management hierarchy の手順に従って、Cost Management 用の Microsoft Azure タグを作成して適用します。

3.2.3. タグの Google Cloud リソースへの追加

カスタムラベルを、仮想マシンインスタンス、イメージ、永続ディスクなどの Google クラウドリソースに適用できます。これらのラベルは、BigQuery エクスポートに自動的に追加され、Cost Management に送信されます。

手順

  • ラベルを Google Cloud リソースを作成し、これに適用します。

    手順については Google Cloud ドキュメントの ラベルの作成および管理 を参照してください。

3.2.4. OpenShift namespace でのラベルの表示

OpenShift で AWS または Microsoft Azure タグに相当するのはラベルであり、これもキーと値のペアで構成されます。Cost Management Service は、Prometheus メトリクスと Cost Management Metrics Operator を使用して、ノード、Pod、永続ボリューム (または永続ボリューム要求) から OpenShift タグデータを収集します。

利用可能なタグを表示するには、OpenShift Web コンソールでリソースに移動します。割り当てられたラベルは Labels 見出しにリスト表示されます (例: openshift.io/cluster-monitoring=true)。

3.2.5. Cost Management でのタグの有効化と無効化

Cost Management では、デフォルトですべてのクラウドプロバイダーのタグが有効になっています。リソースタグが多すぎると、Cost Management のパフォーマンスに影響することがあります。有効なタグはアカウントごとに 200 に制限されています。また、タグをグループ化したり、キーと値のペアを一致させたりする場合に、不要なタグがあるとコスト管理が煩雑になります。これらの潜在的な問題を軽減するには、アクティブに使用していないタグを無効にします。

前提条件

  • Cost Management でこれらの設定を変更するには、組織管理者または Cost Price List 管理者の権限が必要である。ユーザーのロールとアクセスに関する詳細は、Cost Management スタートガイドCost Management リソースへのアクセス制限 を参照してください。

手順

  1. cost management から、Cost ManagementSettings をクリックします。
  2. Tags and labels タブをクリックします。
  3. 無効にするタグを選択します。
  4. Disable tags をクリックします。

    このタグは、Cost Management アプリケーションに対して非アクティブになりました。同じページで無効にしたタグを有効にするには、有効にするタグを選択して Enable tags をクリックします。

3.2.6. Cost Management での Amazon Web Services のコストカテゴリーの設定

Cost Management Service で Amazon Web Services (AWS) のコストカテゴリーを有効または無効にできます。AWS コストカテゴリーを使用すると、組織はタグに加えて意味のあるコストと使用状況の情報をグループ化できます。Cost Management でコストカテゴリーを使用するには、まず AWS コンソールでコストカテゴリーを設定する必要があります。次の手順では、Cost Management Service でコストカテゴリーを有効にする方法について説明します。

前提条件

  • Cost Management でこれらの設定を変更するには、組織管理者または Cost Price List 管理者の権限が必要である。ユーザーのロールとアクセスに関する詳細は、Cost Management スタートガイドCost Management リソースへのアクセス制限 を参照してください。
  • Amazon Web Services のインテグレーションが Cost Management に追加され、Amazon Web Services コンソールを通じてコストカテゴリーが有効化されている。

手順

  1. cost management から、Cost ManagementSettings をクリックします。
  2. Cost categories タブをクリックします。
  3. 有効にするコストカテゴリーを選択します。複数選択できます。
  4. Enable categories をクリックします。

    選択したコストカテゴリーが Cost Management アプリケーションに対して有効になりました。無効にするコストカテゴリーを選択し、Disable categories をクリックして、コストカテゴリーを無効にすることもできます。

第4章 コストデータの表示およびエクスポート

4.1. コストデータビューのフィルタリング

タグを使用すると、コストデータの表示をカスタマイズできます。リソースをタイプ (プロジェクト、ノード、クラスターなど) またはタグまたはラベル別に表示して、特定のリソースのコストが増加した理由、またはデータが異常に見えるタイミングを調べることができます。

この例は、クラスター内の各 OpenShift プロジェクトのコストを確認する方法を示しています。

前提条件

手順

  1. OpenShift details メニューから、フィルターボタンをクリックして Tag を選択します。
  2. Choose key ドロップダウンリストで、フィルター処理に使用するキーを選択します。たとえば、environment タグでクラスターを表示する 環境 を選択します。tag キーを選択すると、フィルタリングする値を選択する別のドロップダウンが表示されます。
  3. Choose value ドロップダウンリストで、フィルタリングする 1 つ以上の値を選択します。たとえば、qe および dev を選択して、これらのタグを持つ OpenShift プロジェクトのコストデータを表示します。
  4. 各プロジェクトの詳細情報を表示するには、以下を実行します。

    • 各リソースの矢印アイコンをクリックすると、リソースが属するクラスター、CPU とメモリーの使用量、制限、リクエストなどの詳細情報が表示されます。
    • More options More options icon をクリックして、さらに表示オプションを表示します。

      • View price list をクリックし、OpenShift メトリクスに適用されるレートを表示し、コストを計算します。
      • View historical data をクリックして、毎日の使用量比較ビューを開きます。このビューでは、月ごとに、対象リソースの 1 日当たりの使用率、要求、制限を比較します。
      • View all projects または View all tags をクリックして、関連リソースおよびメタデータを表示します。
  5. Clear all filters をクリックして OpenShift の詳細ビューをリセットします。

4.2. タグカテゴリー別のコストデータのグループ化

タグカテゴリー別にリソースをグループ化して、コストデータをさらに調べることができます。

グループ化とフィルタリングは、コストや問題の根本原因を見つけたり、コストセンターや特定の環境など、他の環境とは独立して機能する環境の一部を調査したりするのに役立ちます。

これにより、環境の残りの部分に関する情報を非表示にして、コストデータの結果が必要以上に複雑になるのを防ぎ、他のデータの中に隠れてしまいがちな必要な情報を見つけることができます。

この例は、OpenShift Container Platform でラボ環境を実行している教育コースプロバイダーがタググループ化を使用して、学生とコースごとにコスト情報をフィルタリングする方法を示しています。

前提条件

手順

  1. Group cost by: フィールドの OpenShift details ページから、コストをグループ化するタグキーを選択します。この場合は、Tag Key:user を選択して、学生ユーザー別にグループ化された結果を表示します。
  2. フィルターエリアで、Tag を選択します。
  3. Choose key リストで、タグキー user を選択します。
  4. Choose value ドロップダウンリストで、course_id および course_type の値をチェックして、コース X を受講した学生の数とそのコースの費用を特定します。
  5. 各リソースの詳細情報 (例: コース X のコスト) を表示するには、以下を実行します。

    • 各リソースの矢印アイコンをクリックすると、リソースが属するクラスター、CPU とメモリーの使用量、制限、リクエストなどの詳細情報が表示されます。
    • View Historical Data をクリックして、毎日の使用量比較ビューを開きます。このビューでは、月ごとに、対象リソースの 1 日当たりの使用率、要求、制限を比較します。
    • More options More options icon をクリックして、さらに表示オプションを表示します。

      • View historical data をクリックして、毎日の使用量比較ビューを開きます。このビューでは、月ごとに、対象リソースの 1 日当たりの使用率、要求、制限を比較します。
      • Export data をクリックして、レポート用の .CSV ファイルを作成します。日次または月額の集約を指定し、Generate and download をクリックします。
  6. Clear all filters をクリックして OpenShift の詳細ビューをリセットします。

4.3. レポートツールへのコストデータのエクスポート

タグを使用すると、コストデータの表示をカスタマイズできます。これは、特定のリソースがコストの増加を示している理由、またはデータが異常に見える理由をさらに調査する場合に役立ちます。

この例は、特定の OpenShift リソースのデータを表示し、データを必要なレポートツールにエクスポートする方法を示しています。

前提条件

手順

  1. OpenShift details メニューから、フィルターボタンをクリックして Tag を選択します。
  2. Choose key ドロップダウンリストで、フィルター処理に使用するキーを選択します。たとえば、version を選択します。tag キーを選択すると、フィルタリングする値を選択する別のドロップダウンが表示されます。
  3. Choose value ドロップダウンリストで、フィルタリングする 1 つ以上の値を選択します。たとえば、qe および dev を選択して、これらのタグを持つ OpenShift リソースのコストデータを表示します。
  4. リソースのデータをエクスポートするには、データをエクスポートする各リソースの横にあるチェックボックスを選択します。Export をクリックして、エクスポートオプションダイアログを開きます。
  5. 日次または月額の集約を指定し、Generate and download をクリックします。

CSV ファイルはローカルシステムにダウンロードされ、必要なレポートツールでこれを使用できます。

注記

リソースごとに、More options More options icon > Export data メニューからデータを .CSV ファイルとしてエクスポートすることもできます。

Clear all filters をクリックして OpenShift の詳細ビューをリセットします。

第5章 関連情報

5.1. インテグレーションタイプ別のタグ仕様

タグ付け標準はインテグレーションタイプによって異なります。インテグレーション間で同じタグ/ラベルを使用するには、さまざまなプロバイダー間ですべての制限の中で最も一般的なものを使用する必要があります。

以下の表は、AWS、Azure、および OpenShift Container Platform 4 間での基準のタグ付けとラベル付けについてまとめています。

表5.1 インテグレーションによるタグ付け仕様

基準AWSAzureGoogle CloudRed Hat OpenShift

名前

タグ

タグ

ラベル

ラベル

フォーマット

キー & 値

名前 & 値

キー & 値

キー & 値キー: [prefix/]name Prefix: は DNS サブドメインでなければなりません

空の値を許可する

はい

はい

はい

はい

キーごとの一意のラベル

はい

はい

はい

はい

大文字小文字が区別される

はい

いいえ

小文字のみ

はい

リソースごとの制限

50

50 (ストレージの場合は 15)

64

該当なし

キーの長さ

128

512 (ストレージの場合は 128)

63

253(prefix) / 63(name)

値の長さ

256

256

63

63

使用可能な文字

UTF-8 で表示可能な文字、数字、スペース、記号 (+ - = . _ : / @)

タグ名には <、>、%、&、\、?、/ の記号を含めることはできません。

小文字、数字、アンダースコア、ハイフンのみ。

名前のセグメントは必須であり、63 文字以下で、語頭および語尾は英数字 ([a-z0-9A-Z]) を使用し、それ以外はダッシュ (-)、アンダースコア (_)、ピリオド (.)、および英数字を使用する必要があります。

制約

接頭辞 aws: は予約されています。EC2 に適用されるタグは任意の文字を使用できます。すべてのリソースタイプがタグをサポートしているわけではありません。

すべてのリソースタイプがタグをサポートしているわけではありません。汎用仮想マシンでは、タグはサポートされません。リソースグループに適用されるタグはリソースによって継承されません。

キーは小文字または国際文字で始まる必要があります。

kubernetes.io/ と k8s.io/ の接頭辞は予約されています。すべてのリソースタイプがタグをサポートしているわけではありません。

備考

コストと使用量のファイルと請求レポートに含まれるタグキーを選択する必要があります。

JSON 文字列を使用してキーの制限を引き継ぐことができます。

プロジェクト内のすべてのリソースに適用できるラベルの数に制限はありません。

接頭辞を省略すると、ラベルキーはユーザー専用であると想定されます。

5.2. 関連資料

次のリンクでは、各インテグレーションタイプのタグ付けに関する詳細なガイダンスを提供します。

AWS:

openshift

Microsoft Azure

Google Cloud

Red Hat ドキュメントへのフィードバック (英語のみ)

エラーを見つけた場合、またはこのガイドを改善するための提案がある場合は、cost management Jira board で Issue を作成し、Documentation のラベルを追加してください。

フィードバックをお待ちしております。

法律上の通知

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.