使用量の種類

Resource Transparency レポートは Resource Management アプリで閲覧でき、プロジェクトとオントロジーが消費したコンピュートリソースとストレージリソースの内訳を確認できます。

Foundry コンピュート

Foundry は、データに対して計算処理を実行するプラットフォームです。この処理量は、Foundry の compute-seconds を使用して測定されます。コンピュート秒は、プラットフォーム内の計算処理量を表す単位で、バッチ（長時間実行）アプリケーションとインタラクティブ（アドホック）アプリケーションの両方で使用されます。コンピュート秒は、並列化されたコンピュートエグゼキューターの数、コンピュートエグゼキューターのサイズ、処理対象データのサイズ、計算ジョブの複雑さなど、さまざまな要因によって決まります。

Foundry の多くのコンピュートフレームワークは「並列」で動作します。つまり、複数のエグゼキューターが同じジョブを同時に処理します。並列化によってほとんどのジョブの実行が大幅に高速化されますが、単位時間あたりのコンピュート秒の使用量は増加します。

実経過時間

ここで定義しておくべき重要な用語が、実経過時間（wall-clock time） です。実経過時間とは、壁掛け時計やストップウォッチで測定した、プロセスの開始から測定時点までに実際に経過した時間です。言い換えると、実経過時間は、タスクの開始時刻と終了時刻の差（秒単位）です。実経過時間の1秒あたりに多数の Foundry コンピュート秒が使用されることがあり、ジョブの種類によって、設定に応じて異なるペースでコンピュート秒が使用されます。

実経過時間と Foundry コンピュート秒の関係を理解するには、人時の概念が役立ちます。2人がそれぞれ1日8時間働くと、実経過時間は8時間にすぎなくても、16人時分の作業が行われます。

並列化されたバッチコンピュート

並列化されたバッチコンピュートは、「バッチ」として実行されるクエリやジョブを指します。つまり、一定のスケジュール間隔またはアドホックにトリガーされ、バックグラウンドで実行されます。バッチコンピュートジョブは、実行されていないときにはコンピュートを消費しません。Foundry は、これらのジョブがトリガーされるとすぐに、計算リソースを自動的に割り当てます。コンピュート使用量は、リソースがプロビジョニングされた時点から、ジョブから解放されるまで計測されます。

プラットフォーム全体でコンピュートリソースがどのように使用されているかを把握できるように、ジョブごとに vCPU とメモリーの使用量を測定し、データセットおよびオブジェクト単位でレポートします。

現在、以下のバッチコンピュートジョブが監視されています。

• すべてのトランスフォームジョブ（Java、Python、SQL、Mesa、GPU）
• Pipeline Builder
• Contour から保存されたデータセットのビルド（Contour のプレビュー、分析、レポートは含みません）
• Code Workbooks
• オントロジーおよびインデックス化済みストレージへの同期（オブジェクトストレージや時系列同期など）
• Object Storage v1（Phonograph）のライトバックジョブ
• Data Health チェック

並列化されたインタラクティブコンピュート

インタラクティブコンピュートは、通常、インタラクティブなユーザーセッションの一部として、リアルタイムで評価されるクエリを指します。高速なレスポンスを提供するために、インタラクティブコンピュートシステムは、アイドル状態のコンピュートを常時稼働させています。そのため、インタラクティブクエリはバッチ評価よりもコストが高くなります。

インタラクティブ使用量はクエリごとにレポートされます。クエリは、スケジュールされたバックエンドアプリケーションのリソースを、そのクエリに相当する割合で消費します。この使用量は、バッチコンピュートと同様に、プロジェクト単位で集計されます。

現在、以下のアプリケーションからのクエリがインタラクティブコンピュート使用量に含まれます。

• Contour のダッシュボード、分析、プレビュー。
• オントロジークエリ
• 時系列クエリ
• Code Workspaces

並列化された継続的コンピュート

継続的コンピュートは、メッセージを受信して任意のロジックで処理できる状態を常時維持する、常時稼働の処理ジョブで使用されます。

継続的コンピュートは、ジョブがメッセージを受信して処理を実行できる状態にある時間の長さに応じて測定されます。

現在、以下のアプリケーションの使用量が継続的コンピュートに含まれます。

• ストリーミング
• Foundry Machine Learning

並列化されたコンピュートの測定単位

並列処理コンピュートでは、コア秒とメモリー対コア比率という2つのメトリクスを測定することで、コンピュート秒を算出します。

並列化されたコア秒

コア秒は、ジョブの実行時間にわたって使用された vCPU コアの数を反映します。たとえば、2コアを3秒間使用すると、6コア秒になります。ジョブの実行時間とは、ジョブの送信から完了報告までの時間です。これには、起動時間とジョブのクリーンアップ時間が含まれます。

ジョブが使用したコア数を特定するために、そのジョブのプロパティが確認されます。具体的には、エグゼキューターの数、エグゼキューターの vCPU コア数、およびドライバーが考慮されます。

このプラットフォームで一般的に使用される並列化されたコンピュートエンジンは Spark です。ユーザーによっては、あらかじめ定義された Spark 設定を「サイズ」として提供する Spark Configuration Service プロファイルのみを使用する場合もあります。通常、これらのプロパティはジョブの Spark プロファイルで指定されるか、システムのデフォルトに設定されます。

例：

spark.driver.cores = 3
spark.executor.cores = 2

この例では、合計コア秒を次のように計算できます。

core_seconds = (num_driver_cores + num_executor_cores * num_executors) * job_duration_in_seconds

メモリー対コア比率

稼働中の計算ホストではメモリー対コア比率が固定されているため、コアあたり何 GiB のメモリーが使用されるかを考慮する必要があります。4コアと32 GiB のメモリーを備えたホストを想定します。このホストでは、それぞれ1コアと8 GiB のメモリーを要求する4個のジョブをスケジュールできます。ただし、これらのジョブの1個がより多くのメモリー、つまり16 GiB を要求すると、メモリーが不足するため、ほかのジョブは残りのコアを活用できません。つまり、残りのジョブの1個には追加の容量が必要になります。このため、メモリー対コア比率はコンピュート秒の計算における重要な要素です。

Foundry では、デフォルトのメモリー対コア比率は 7.5 GiB per core です。

並列化されたコア秒からコンピュート秒への換算

Foundry コンピュート秒は、ジョブ用に予約された vCPU コア数とメモリー量の両方を反映します。コンピュート秒は、コア秒と予約されたメモリー量を組み合わせたものです。

まとめると、次の2つの要素の最大値を使用してコンピュート秒を計算します。

• タスクあたりの使用コア数
• タスクのエグゼキューターのメモリー対コア比率

これは、次の式で表せます: max(num_vpcu, gib_ram / 7.5)

次の特性を持つ例を考えます。

• 2個のエグゼキューターがそれぞれ1コアと12 GiB の RAM を持つ
• 合計の実経過計算時間は5秒

vcpu_per_executor = 1
ram_per_executor = 12
num_executors = 2
num_seconds = 5

default_memory_to_core_ratio = 7.5
job_memory_multiplier = 12 / 7.5 = 1.6

job_core_seconds = num_vcpu * num_excutors * num_seconds
job_core_seconds = 1 * 2 * 5 = 10

job_compute_seconds = max(num_vcpu, job_memory_multiplier) * num_executors * num_seconds
job_compute_seconds = max(1vcpu, 1.6mem-to-core) * 2executors * 5sec
job_compute_seconds = 16 compute-seconds

このジョブが使用したのは10コア秒のみですが、要求したメモリー量がコア数に対して大きいため、合計16コンピュート秒を使用したことがわかります。

クエリのコンピュート秒

Foundry には、オンデマンドでクエリできるさまざまなインデックス化済みストアがあります。これらのインデックス化済みストアは、それぞれクエリの実行時にコンピュート秒を使用します。クエリがコンピュート秒をどのように使用するかについては、次のドキュメントを参照してください。

• Foundry オントロジー
• Foundry 時系列

オントロジーボリューム

Foundry のオントロジーとインデックス化済みデータ形式は、組織を中心とした高速なクエリとアクションのためのツールを提供します。これらの基盤システムは、アドホックな業務および分析ユースケースに対して柔軟性が大幅に高い形式でデータを保存します。オントロジーボリュームは gigabyte-months で測定されます。

オントロジーボリュームの使用量は、次のシステムで追跡されます。

• オントロジーオブジェクト（v1 および v2）
• Postgate（Postgres インターフェース。一部の Foundry 設定では利用できません）
• Lime（オントロジーマッピングのないレガシードキュメントストア）

同期されたデータセットのサイズは、Foundry 内のサイズと異なる場合があります。これは、データを保存して提供するために、各システムが異なるレイアウトや圧縮方式を使用しているためです。

Foundry ストレージ

Foundry ストレージは、Foundry のオントロジー以外の変換レイヤーに保存されている汎用データを測定します。ディスク使用量は gigabyte-months で測定されます。

各データセットのストレージ使用量は個別に計算されます。データセットのブランチと過去のトランザクション（およびビュー）は、1個のデータセットが消費するディスク容量に影響します。DELETE トランザクションでビューからファイルを削除しても、基盤となるストレージからは削除されないため、ストレージコストは引き続き発生します。合計ディスク使用量は、次の2つのステップで計算されます。

• データセットでこれまでにコミットまたは中止されたすべてのトランザクションを確認し、追加された基盤ファイルのサイズを合計します。
• 保持機能を使用して削除されたすべてのトランザクション分を減算し、現在使用されているディスク容量を算出します。

サイズを削減する唯一の方法は、保持を使用して不要なトランザクションをクリーンアップすることです。DELETE トランザクションのコミットやブランチの更新では、ストレージ使用量は削減されません。

オントロジーボリュームの使用量の帰属

オントロジーボリュームの使用量は、主に各オブジェクトの入力データソースのプロジェクトに帰属します。以下に示すように、任意のプロジェクトの詳細な使用量を表示すると、Foundry リソースとオブジェクトが左右配置で表示されます。

注記：埋め込みモジュールを含む Workshop アプリケーションに使用量が帰属する場合、その埋め込みモジュールで発生するすべての使用量も含まれます。

一部のオブジェクトは、単一のプロジェクトに帰属させることができません。たとえば、オブジェクトに複数のプロジェクトにまたがる複数の入力データソースがある場合です。この場合、以下のように、使用量はオントロジー自体に帰属します。

一般に、オブジェクトには次の種類の使用量が発生します。

• Foundry コンピューティングは、データセットをオブジェクトタイプにインデックス化するために使用されるコンピューティング、つまりオントロジーを同期するコストを記録します。
• オントロジーボリュームは、すべてのオブジェクトタイプのインデックスのサイズを記録します。
• オブジェクトの Foundryストレージは空です。

ジョブの帰属

Resource Management アプリケーションのすべての使用量は、タイムスタンプ、日付範囲、使用量の集計を含め、厳密に UTC で記録および表示されます。

ジョブは終了時刻に基づいて帰属します。ジョブが完了すると、その使用量は終了した UTC 日付に割り当てられます。複数の日にまたがるジョブの場合、すべての使用量は開始日ではなく、終了日に帰属します。これは、バッチ、インタラクティブ、連続コンピューティングを含む、すべてのコンピューティング処理に適用されます。

使用量の単位

コンピュート秒

すべての Foundry 製品が実行するすべての計算処理は、compute-seconds で表されます。Foundry プラットフォームでは、compute-second は時間の尺度ではなく、プラットフォームが実行する処理量の単位です。compute-second はプラットフォームにおける処理量の最小単位であり、Foundry でコンピューティングを測定する際の最小粒度を意味します。Foundry の各製品の種類がコンピュート秒をどのように使用するかについては、以下のテーブルを参照してください。

ギガバイト月

すべての Foundry 製品のすべてのストレージ使用量は、gigabyte-months で表されます。これは、時間の経過に伴う割り当て済みストレージの量を測定する単位です。1 GB のデータファイルは、1か月あたり 1 GB-month の使用量を消費します。

ストレージ容量は1時間ごとに計算され、gigabyte-months の値は、その月の期間内における1時間ごとの測定値の合計から計算されます。たとえば、30日ある月の場合は次のようになります。

Days 0-3      - 0GB volume
Day 4, 06:00  - 3GB volume (3GB added)
Days 5-10     - 3GB volume (no change from day 3)
Day 11, 00:00 - 6GB volume (3GB added)
Days 11-20    - 6GB volume (no change)
Day 21, 00:00 - 3GB volume (3GB deleted)
Days 21-30    - 3GB volume (no change)

Total:
(0GB * 4 days + 3GB * (18hrs/24) days + 3GB * 6 days + 6GB * 10 days + 3GB * 10 days) / 30 days
   = 3.675 gigabyte-months of usage

月の日数は異なるため、同じストレージ容量で1日あたりに発生する gigabyte-months は月ごとに変わります。たとえば、次のようになります。

90GB stored for 1 day in a month with 30 days will consume:
(90GB * 1 day) / 30 days = 3 gigabyte-months

90GB stored for 1 day in a month with 31 days will consume:
(90GB * 1 day) / 31 days = 2.90 gigabyte-months

つまり、サイズが変わらないデータセットのストレージ使用量を表示する場合、1日または1週間あたりに消費される gigabyte-months には多少の変動がありますが、1か月全体で消費される gigabyte-months は変動しません。

Foundry アプリケーションと関連する使用量の一覧

データ変換

分析

モデルと AI の統合

オントロジーとアプリケーションの構築

注記：

Yes (writeback) は、ユーザーによる編集内容またはユーザーが作成したオブジェクトを Foundry のオブジェクトセットに保存する処理を指します。

Yes (export) は、ユーザーによる編集内容を Foundry の指定されたライトバックデータセットに保存する処理を指します。

Yes (from other applications) は、Notepad ドキュメントに埋め込まれた Contour ボードなど、ほかの埋め込み Foundry アプリケーションによって発生する使用量を指します。