ScalarDB Analytics での使用量メータリングのセットアップ
このページは英語版のページが機械翻訳されたものです。英語版との間に矛盾または不一致がある場合は、英語版を正としてください。
ScalarDB Analytics サーバーは、分析ワークロードが消費するコンピューティング量を計測し、その使用量データをライセンスや課金に利用できるように保存します。このガイドでは、ScalarDB Analytics が何を計測するのかを説明し、本番環境でサーバーがメータリングデータを確実に保存できるようにオブジェクトストレージバックエンドを設定する方法を示します。
ScalarDB Analytics を使用するには、ライセンスキー (試用ライセンスまたは商用ライセンス) が必要です。ライセンスキーをお持ちでない場合は、お問い合わせください。
メータリングの仕組み
ScalarDB Analytics は、ScalarDB Analytics カタログにアクセスするクエリを実行する際に Spark エグゼキューターが消費する CPU 時間を計測します。ScalarDB Analytics を使用しないクエリは計測されません。
メータリングデータは以下のコンポーネントを流れます:
- Spark アプリケーションに登録されたリスナーが、クエリの実行に伴って実行メトリクスを収集します。
- リスナーは、ScalarDB Analytics サーバー内で動作するメータリングサービスにメトリクスを送信します。
- サーバーはメトリクスを集計し、ストレージバックエンドに保存します。
本番環境では、サーバーの再起動後もメータリングデータが失われないように、ストレージバックエンドとしてオブジェクトストレージを使用してください。ScalarDB Analytics は Amazon S3、Google Cloud Storage、Azure Blob Storage をサポートしています。
ストレージバックエンドとしてローカルファイルシステムも利用できますが、これは開発およびテスト専用です。メータリングデータはサーバーのローカルディスクに書き込まれるため、サーバーのストレージが永続的でない場合は失われます。本番環境ではオブジェクトストレージを使用してください。
前提条件
開始する前に、以下を準備してください:
- ScalarDB Analytics 3.18.0 以降。それよ り前のバージョンは、このガイドで説明する権限要件とは異なる別のストレージ実装を使用します。
- ScalarDB Analytics サーバー。サーバーのセットアップ方法については、ScalarDB Analytics カタログの作成を参照してください。
- 分析クエリを実行するように設定された Spark 環境。手順については、ScalarDB Analytics を通じた分析クエリの実行を参照してください。
- サポートされているクラウドプロバイダー (AWS、Google Cloud、または Azure) のアカウント。バケットまたはコンテナを作成し、そのアクセスを管理する権限が必要です。
ステップ 1: メータリングデータ用のオブジェクトストレージをセットアップする
ScalarDB Analytics サーバーはバケットまたはコンテナを自動的に作成しないため、事前に作成し、サーバーに必要な権限を付与する必要があります。サーバーはメータリングオブジェクトの書き込み、読み取り、一覧表示のみを行います。オブジェクトを削除することはないため、削除 権限を付与する必要はありません。
使用するクラウドプロバイダーを選択し、対応する手順に従ってください。
- Amazon S3
- Google Cloud Storage
- Azure Blob Storage
- ScalarDB Analytics サーバーが動作するリージョンに S3 バケットを作成します。
aws s3 mb s3://<BUCKET_NAME> --region <REGION>
-
メータリングデータの保存に必要な最小権限をサーバーに付与します。権限は AWS マネジメントコンソールで付与するか、ポリシードキュメントをアタッチして付与できます。サーバーには以下の権限が必要です:
- バケット内のオブジェクト (
arn:aws:s3:::<BUCKET_NAME>/*) に対するs3:PutObjectとs3:GetObject(メータリングデータの書き込みと読み取り用)。 - バケット自体 (
arn:aws:s3:::<BUCKET_NAME>) に対するs3:ListBucket(メータリングデータの一覧表示用)。
以下のポリシードキュメントはこれらの権限を付与します:
- バケット内のオブジェクト (
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "MeteringObjectAccess",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": "arn:aws:s3:::<BUCKET_NAME>/*"
},
{
"Sid": "MeteringBucketList",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::<BUCKET_NAME>"
}
]
}
メータリングデータにプレフィックスを設定する場合は、オブジェクトのリソースに arn:aws:s3:::<BUCKET_NAME>/<PREFIX>/* を使用し、s3:ListBucket ステートメントに s3:prefix 条件を追加することで、スコープをさらに絞り込めます。
-
サーバーが S3 へのアクセスに使用する ID にポリシーを付与します。認証情報は以下のいずれかの方法で提供できます:
- IAM ロール (推奨): Amazon EC2 インスタンスプロファイル、Amazon EKS の IAM roles for service accounts (IRSA) ロール、Amazon ECS タスクロールなど、サーバーが実行時に使用する IAM ロールにポリシーをアタッチします。この場合、アクセスキーのプロパティは設定せず、サーバーはデフォルトの AWS 認証情報プロバイダーチェーンから認証情報を解決します。AWS リージョンが環境経由でサーバーから利用できるようにしてください (例:
AWS_REGION環境変数を設定する)。 - アクセスキー: IAM ユーザーにポリシーをアタッチし、そのアクセスキー ID とシークレットアクセスキーを、ステップ 2 で示すストレージプロパティを通じてサーバーに提供します。
- IAM ロール (推奨): Amazon EC2 インスタンスプロファイル、Amazon EKS の IAM roles for service accounts (IRSA) ロール、Amazon ECS タスクロールなど、サーバーが実行時に使用する IAM ロールにポリシーをアタッチします。この場合、アクセスキーのプロパティは設定せず、サーバーはデフォルトの AWS 認証情報プロバイダーチェーンから認証情報を解決します。AWS リージョンが環境経由でサーバーから利用できるようにしてください (例:
- ScalarDB Analytics サーバーが動作するロケーションに Cloud Storage バケットを作成します。
gcloud storage buckets create gs://<BUCKET_NAME> --location=<LOCATION>
- サーバーが使用するサービスアカウントにバケットへのアクセスを付与します。サーバーには
storage.objects.get、storage.objects.create、storage.objects.listの各権限が必要です。Google Cloud コンソールで Storage Object User という名前のroles/storage.objectUser事前定義ロールには、これらの権限が含まれて います。
gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
--member="serviceAccount:<SERVICE_ACCOUNT_EMAIL>" \
--role="roles/storage.objectUser"
roles/storage.objectUser には、サーバーが使用しない storage.objects.delete も含まれています。サーバーが必要とする権限のみを厳密に付与したい場合は、storage.objects.get、storage.objects.create、storage.objects.list だけを含むカスタムロールを作成し、そのロールを付与してください。
- サービスアカウントの認証情報をサーバーから利用できるようにします。Google Cloud Storage はアプリケーションのデフォルト認証情報 (ADC) を使用します。
GOOGLE_APPLICATION_CREDENTIALS環境変数にサービスアカウントキーファイルのパスを設定するか、Google Kubernetes Engine (GKE) 上で実行する場合は Workload Identity を使用します。アクセスキーのプロパティは Google Cloud Storage では使用されません。
- 既存のストレージアカウントに blob コンテナを作成します。
az storage container create \
--name <CONTAINER_NAME> \
--account-name <ACCOUNT_NAME>
- ストレージアカウントのアクセスキーを取得します。サーバーは、ストレージアカウント名とアカウントキーを使用して Azure Blob Storage に認証します。
az storage account keys list --account-name <ACCOUNT_NAME>
アカウントキーは、メータリングコンテナだけでなくストレージアカウント全体へのフルアクセスを許可します。影響範囲を限定するため、メータリングデータ専用のストレージアカウントを使用してください。
ステップ 2: メータリングサービスを設定する
ScalarDB Analytics サーバー設定ファイル (例: scalardb-analytics-server.properties)にメータリングストレージのプロパティを追加します。プロパティはクラウドプロバイダーによって異なります。
- Amazon S3
- Google Cloud Storage
- Azure Blob Storage
scalar.db.analytics.server.metering.storage.provider=aws-s3
scalar.db.analytics.server.metering.storage.containerName=<BUCKET_NAME>
# IAM ロールではなくアクセスキーを使用する場合のみ以下を設定します
scalar.db.analytics.server.metering.storage.accessKeyId=<ACCESS_KEY_ID>
scalar.db.analytics.server.metering.storage.secretAccessKey=<SECRET_ACCESS_KEY>
scalar.db.analytics.server.metering.storage.provider=google-cloud-storage
scalar.db.analytics.server.metering.storage.containerName=<BUCKET_NAME>
Google Cloud Storage はアプリケーションのデフォルト認証情報を通じて認証情報を解決するため、アクセスキーのプロパティは不要です。認証情報はステップ 1 で説明したように環境経由で提供してください。
Azure Blob Storage では、accessKeyId にストレージアカウント名を、secretAccessKey にアカウントキーを設定します。
scalar.db.analytics.server.metering.storage.provider=azureblob
scalar.db.analytics.server.metering.storage.containerName=<CONTAINER_NAME>
scalar.db.analytics.server.metering.storage.accessKeyId=<ACCOUNT_NAME>
scalar.db.analytics.server.metering.storage.secretAccessKey=<ACCOUNT_KEY>
必要に応じて scalar.db.analytics.server.metering.storage.prefix を設定すると、すべてのメータリングオブジェクトをバケットまたはコンテナ内の共通のプレフィックス配下に保存できます。
メータリングサービスは専用の gRPC ポートで待ち受けます。デフォルトから変更する必要がある場合は、他のサーバー設定と合わせて設定してください。
scalar.db.analytics.server.metering.port=11052 # デフォルト
メタデータデータベース、TLS、ライセンス設定を含むサーバープロパティの完全な一覧については、ScalarDB Analytics の設定を参照してください。設定を更新した後、新しいストレージ設定を反映させるために ScalarDB Analytics サーバーを再起動してください。
ステップ 3: Spark クライアントを設定する
サーバーがメータリングデータを受信するには、Spark アプリケーションがメータリングリスナーを登録し、メータリングサービスに接続する必要があります。Spark 設定ファイル (例: spark-defaults.conf) に以下の設定を追加します。
spark.extraListeners com.scalar.db.analytics.spark.metering.ScalarDbAnalyticsListener
spark.sql.catalog.<CATALOG_NAME>.server.host <SERVER_HOST>
spark.sql.catalog.<CATALOG_NAME>.server.metering.port 11052
<CATALOG_NAME> を ScalarDB Analytics サーバーで作成したカタログの名前に、<SERVER_HOST> をサーバーのホスト名に置き換えてください。サーバーで TLS が有効になっている場合は、カタログのクライアント側 TLS 設定も行ってください。Spark 設定の完全な一覧については、ScalarDB Analytics の設定を参照してください。
メータリングリスナーの登録は必須です。リスナーが登録されていない場合、または Spark アプリケーションがメータリングサービスに到達できない場合、カタログの初期化に失敗し、クエリを実行できません。
メータリングのセットアップを検証する
メータリングストレージバックエンドが正しく設定されていることを確認するには、Spark アプリケーションから ScalarDB Analytics カタログにアクセスする分析クエリを実行し、サーバーがメータリングデータを保存したことを確認します。
クエリの完了後、バケットまたはコンテナの内容を一覧表示します。ストレージバックエンドが正しく設定され、サーバーに必要な権限があれば、メータリングオブジェクトが確認できます。
- Amazon S3
- Google Cloud Storage
- Azure Blob Storage
aws s3 ls s3://<BUCKET_NAME>/ --recursive
gcloud storage ls --recursive gs://<BUCKET_NAME>/
az storage blob list --container-name <CONTAINER_NAME> --account-name <ACCOUNT_NAME> --output table
メータリングオブジェクトが表示されない場合は、ScalarDB Analytics サーバーのログで権限エラーや設定エラーなどのストレージ関連のエラーを確認し、ステップ 1 とステップ 2 のストレージ設定を修正してください。
次のステップ
以下の関連タスクに進んでください: