データコネクタサービス入門
注釈:本資料はAI技術を用いて翻訳されています。
このデータコネクタサービスは、AccelByte Intelligence Service(AIS)でのみ利用可能です。AGSバージョンを利用する場合は、Analytics Data Connector を参照してください。
概要
AccelByte Intelligence Serviceには、サービステレメトリまたはカスタムテレメトリを選択したデータウェアハウスにシームレスかつ効率的にデータ転送するために設計されたデータストリーミングソリューションである、データコネクタサービスが含まれています。
- Amazon S3: Amazon Web Servicesが提供するスケーラブルなオブジェクトストレージ。
- Amazon Redshift: Amazon Web Servicesのクラウドコンピューティングプラットフォームの一部を構成するデータウェアハウス製品。
- Snowflake: オンデマンドでデータウェアハウスを構築できるクラウドホスト型のリレーショナルデータベース。
このセクションでは、データコネクタサービスの主要な概念、サポートされている機能、制限事項、およびサービスを活用するためのベストプラクティスについて学習します。
共有クラウドマルチテナント環境の制限事項
共有クラウドマルチテナント環境でデータコネクタサービスを使用する場合、以下の制限が適用されます:
-
最大コネクタ数: ゲームネームスペースあたり2つのコネクタに制限されます。
-
フラッシュ設定: カスタムフラッシュ設定は利用できません。デフォルト設定は以下の通りです:
- フラッシュ間隔: 1分
- フラッシュサイズ: 300イベント
- フラッシュメモリ: 500 KB
-
S3パス形式: カスタムS3パス形式の設定は利用できません。デフォルト形式は以下の通りです:
{eventType}/realm/{realm}/namespaces/{namespace}/topics/{topic}/year={yyyy}/month={MM}/day={dd}/hour={hh}/minute={mm}/{topic}-{namespace}.json -
RedshiftとSnowflakeの制限: 単一テーブルモデルのみがサポートされ、カラムのフラット化は行われません。
上記の制限事項は、共有クラウドマルチテナント環境にのみ適用されます。
主要な概念
統合をできるだけシームレスにするために、このサービスの設計で使用されている主要な概念を理解することが重要です。
イベントタイプ
データウェアハウスにストリーミングできるイベントには2つのタイプがあります:
- サービステレメトリ: AccelByteサービスから生成されるシステムイベント。
- カスタムテレメトリ: ゲームクライアントから送信されるカスタムテレメトリイベント。
フラッシュ設定
- フラッシュ間隔: データウェアハウスにデータを定期的にストリーミングする最大時間間隔(分単位)。フラッシュ間隔の範囲は1分から5分です。
- フラッシュサイズ: データウェアハウスにストリーミングするイベントの最大数。フラッシュサイズの範囲は100から1000です。
- フラッシュメモリ: データウェアハウスにストリーミングされる前にデータを保存する最大メモリサイズ(KB単位)。フラッシュメモリの範囲は100から1000 KBです。
データは、フラッシュ間隔、フラッシュサイズ、またはフラッシュメモリのいずれかの条件が最初に達したときにストリーミングされます。
S3パス形式の設定
Amazon S3の宛先を設定する際、ストリーミングされたデータが保存されるS3パスを指定する必要があります。S3パスには、バケット名とバケット内のディレクトリ構造の両方が含まれます。
データコネクタサービスでは、タイムスタンプ、イベントタイプ、またはその他の変数などのプレースホルダーを使用したカスタマイズが可能です。
S3パスの設定に関する詳細な手順と例については、S3パス形式設定ガイドを参照してください。
RedshiftとSnowflakeのテーブルモデル
コネクタを使用してAccelByteサービスまたはゲームテレメトリサービスからRedshiftまたはSnowflakeへのデータストリーミングを設定する場合、単一テーブルモデルとマッピングテーブルモデルの2つのテーブルモデルから選択できます。
1. 単一テーブルモデル
単一テーブルモデルでは、すべてのイベントがイベントタイプに基づいて1つのテーブルに挿入されます。このアプローチは、分析とレポート作成を容易にするためにデータを1つのテーブルに統合したい場合に特に便利です。
トピックの例:
analytics_game_telemetry.dev.lightfantastic.gameStartedanalytics_game_telemetry.dev.lightfantastic.gameEnded
期待されるスキーマとテーブル:
public.game_telemetry_dev
2. マッピングテーブルモデル
マッピングテーブルモデルでは、イベントはトピックに基づいて複数のテーブルに挿入されます。これにより、各トピックに対して個別のテーブルを持つことができ、データをより細かく整理できます。
このアプローチは、異なるタイプのイベントに対して個別のテーブルを維持したい場合に適しています。
トピックの例:
analytics_game_telemetry.dev.lightfantastic.gameStartedanalytics_game_telemetry.dev.lightfantastic.gameEnded
期待されるスキーマとテーブル:
public.gameStartedpublic.gameEnded
RedshiftとSnowflakeのテーブル名形式
テーブル名形式は、マッピングテーブルモデルを使用する際にRedshiftとSnowflakeでテーブル名がどのように作成されるかを決定します。テーブル名形式には、トピック形式とイベント形式の2つのタイプがあります。
トピック形式の例:
analytics_game_telemetry_dev_lightfantastic_gameStarted
イベント形式の例:
gameStarted
RedshiftとSnowflakeのカラムフラット化
RedshiftまたはSnowflake用のコネクタを設定する際、カラムフラット化機能を有効または無効にするオプションがあります。この機能は、イベントの構造に基づいてデータベーステーブルにイベントがどのように挿入されるかを決定します。
カラムフラット化を無効にする
カラムフラット化機能が無効になっている場合、すべてのイベントプロパティはeventという名前の単一のカラムに挿入されます。イベントペイロード全体がこのカラム内にJSONオブジェクトとして保存されます。
イベントの例:
{
"EventNamespace": "lightfantastic",
"EventTimestamp": "2023-07-20T03:30:00.036483Z",
"EventId": "d110582c54804a29ab1d95650ca4c644",
"Payload": {
"winning": true,
"hero": "Captain America",
"kill": 9,
"network": 912.27,
"item": [
{
"name": "vibranium shield",
"defense": 10,
"attack": 1
},
{
"name": "mjolnir hammer",
"defense": 1,
"attack": 9
}
]
},
"EventName": "gameEnded"
}
期待されるカラム:
| event |
|---|
{"EventNamespace":"lightfantastic","EventTimestamp":"2023-07-20T03:30:00.036483Z","EventId":"d110582c54804a29ab1d95650ca4c644","Payload":{"winning":true,"hero":"Captain America","kill":9,"network":912.27,"item":[{"name":"vibranium shield","defense":10,"attack":1},{"name":"mjolnir hammer","defense":1,"attack":9}]},"EventName":"gameEnded"} |
カラムフラット化を有効にする
カラムフラット化機能を有効にすると、各イベントのプロパティがデータベーステーブルの個別のカラムに挿入されます。これにより、データのより細かく構造化された表現が提供されます。
提供されたイベントがカラムにどのように挿入されるかを以下に示します:
期待されるカラム:
| eventid | eventnamespace | eventtimestamp | eventname | payload |
|---|---|---|---|---|
| d110582c54804a29ab1d95650ca4c644 | lightfantastic | 2023-07-20T03:30:00.036483Z | gameEnded | {"winning":true,"hero":"Captain America","kill":9,"network":912.27,"item":[{"name":"vibranium shield","defense":10,"attack":1},{"name":"mjolnir hammer","defense":1,"attack":9}]} |
カラムフラット化機能は、単一テーブルモデルには適用できません。
フィルタリング
データコネクタサービスは、クライアントがデータを選択的にストリーミングできる高度なフィルタリング機能を提供します。クライアントは、サービステレメトリまたはカスタムテレメトリサービスからストリーミングしたい特定のネームスペースを指定できます。この機能により、関連するデータのみが選択したデータウェアハウスに転送され、ストレージが最適化され、不要なデータ転送が削減されます。
セキュリティ
S3バケットポリシー
セキュリティコンプライアンスを強化するために、データが保存される宛先バケットに適切なS3バケットポリシーを実装する必要があります。バケットポリシーは、承認されたユーザーとシステムのみにアクセスを制限する必要があります。
S3バケットポリシーの実装方法については、S3バケットポリシー設定ガイドを参照してください。
AWS Key Management Serviceを使用したサーバー側暗号化(SSE-KMS)
データコネクタサービスは、S3バケットへのストリーミング時のデータセキュリティを強化するために、AWS KMSキー(SSE-KMS)を使用したサーバー側暗号化をサポートしています。この機能は、保存データに対する追加の暗号化制御を提供します。
S3バケットのSSE-KMSを有効にする
-
AccelByteアカウントマネージャーに連絡し、KMSキーIDを提供します。
-
KMSキーポリシーが以下の権限を付与していることを確認します:
kms:Decryptkms:GenerateDataKey
-
AWS Management Consoleで、Key Management Service(KMS)キーポリシーを更新して、データコネクタIAMロールを含めます。
{
"Version":"2012-10-17",
"Id":"key-default-1",
"Statement":[
{
"Sid":"Enable IAM User Permissions",
"Effect":"Allow",
"Principal":{
"AWS":[
"arn:aws:iam::xxxxxxxxxxx:root",
"arn:aws:iam::xxxxxxxxxxx:role/irsa_analytics_connector"
]
},
"Action":"kms:*",
"Resource":"*"
}
]
}
Redshift IAMロール認証
Redshift IAMロール認証は、AWS IAMロールを使用してコネクタとAmazon Redshiftクラスター間の接続を確立する安全な方法を提供します。このアプローチにより、コネクタにRedshiftリソースで特定のアクションを実行するための一時的なアクセスを付与できます。
Redshift IAMロール認証の実装に関する詳細な手順については、Redshift IAMロール認証設定を参照してください。
Snowflakeキーペア認証とキーペアローテーション
コネクタを使用してSnowflakeをデータウェアハウスの宛先として設定する場合、セキュリティを強化するためにキーペア認証を使用するオプションがあります。この方法では、公開鍵と秘密鍵のペアを使用して、コネクタとSnowflake環境間の安全な接続を確立します。さらに、高いレベルのセキュリティを維持するためのベストプラクティスとして、定期的なキーペアローテーションを検討することが重要です。
キーペア認証
キーペア認証は、データストリーミング設定に追加のセキュリティレイヤーを導入します。この方法では、Snowflakeが公開鍵と秘密鍵のペアを生成します。
公開鍵はコネクタと共有され、秘密鍵はデータコネクタサービス内に安全に保存されます。
コネクタが接続を開始すると、公開鍵を使用してデータを暗号化し、秘密鍵を使用してデータを復号化します。
キーペアローテーション
堅牢なセキュリティ維持のために、定期的なキーペアローテーション戦略を実装することが重要です。これには、スケジュールされた間隔で新しい公開鍵と秘密鍵のペアを生成することが含まれます。認証に使用されるキーを定期的に更新することで、キーが侵害された場合の不正アクセスのリスクを大幅に削減できます。
制限事項
コネクタ設定の編集
コネクタ設定が正常に作成されると、イベントタイプ(ソース)とデータウェアハウス(宛先)の設定は編集できません。初期設定時に正しい設定を確実に行うことが重要です。
コネクタの一時停止
イベントは、Kafkaクラスター設定に応じて、Kafkaに1日から7日間一時的に保存されます。データ保持ポリシーよりも長い期間コネクタを一時停止すると、データ損失のリスクがあります。
データの重複
コネクタサービスはデータ配信を優先するため、ストレージシステム(S3、Snowflake、またはRedshift)で重複イベントが発生する場合があります。
各イベントは一意のidフィールドで識別され、重複イベントは同じidを持ちます。これらの重複は、ネットワークの問題やシステムの再起動により発生する可能性があります。
データの整合性を維持するために、これらの重複を自分で処理することが重要です。
ベストプラクティス
データコネクタサービスを使用する最適なシナリオは、AccelByteサービスまたはゲームテレメトリサービスからAmazon S3、Snowflake、Amazon Redshiftなどのデータウェアハウスにデータをシームレスにストリーミングしたい場合です。
これは、レポート、分析、ビジネスインテリジェンスの目的でデータを統合および分析する場合に特に有益です。