クエリパフォーマンスの最適化につながる Amazon Timestream の顧客定義パーティションキー機能

Amazon Timestream はインフラストラクチャの可観測性、ユーザの行動分析、IoT のワークロード等に適したフルマネージドでスケーラブルな時系列データベースです。1 日に何兆ものイベントを処理可能で、ニーズに合わせて水平方向に拡張できるように設計されています。Timestream はマルチメジャーレコードやスケジュールドクエリ等の機能を持ち合わせており、時系列データの分析を通じて、価値のある洞察ををコスト効率よく得る事が出来ます。

例えば、多数のパフォーマンス指標を追跡したり、顧客の行動をリアルタイムで分析するような場合等、様々なニーズに Timestream は対応出来ます。今回、顧客定義のパーティションキーを設定する事が可能になり、特定のニーズに合わせてクエリの最適化が行われる事により、以前よりもより高速に時系列データにアクセスできるようになりました。

顧客定義のパーティションキーの必要性

多くのお客様や我々の内部の開発チーム (Alexa Voice Service : AVS) では、拡張性の高い取り込みと低レイテンシーでのクエリ実行が必要となるようなユースケースで Timesream を利用しています。AVS チームの経験として、Timestream では時間の経過とともにデータが増大したとしても、既存のパーティショニング方法で拡張は可能ですが、ユースケースによっては特定のクエリに最適化されるような柔軟なオプションを提供する必要がある事が分かりました。

そういった点を念頭においた上で、Timestream の新機能である顧客定義のパーティションキーがリリースを発表できる事を嬉しく思います。この機能はクエリを高速化し、特定の時系列関連のニーズに基づいて、より効率的に洞察を得る為に必要な柔軟性を提供します。パーティショニングは複数の物理ストレージユニットにデータを分散する為に利用される技術で、より高速かつ効率的なデータ取得を可能にします。顧客定義のパーティションキー機能を利用すると、クエリパターンやユースケースに合わせたパーティションスキーマを作成する事が出来ます。

Timestream ではレコードは時系列内の単一のデータポイントです。各レコードには以下の 3 つの要素が含まれます。

• タイムスタンプ：通常、与えられたデータがいつ生成されたのかを示す
• ディメンジョン：エンティティを一意に示すメタデータ
• メジャー：時系列で追跡される実際の値

Timestream の主要な概念の詳細については、ドキュメントを参照して下さい。

データを分割する特定のディメンジョンを選択する事で、Timestream はクエリ実行でスキャンされるデータ量を削減し、パーティショニングスキーマに一致するアクセスパターンを持つクエリのレイテンシーを改善します。例えば、顧客 ID, デバイス ID, 場所によるフィルタリングは多くのお客様が使用するアクセスパターンですが、そういったディメンジョンの一つをパーティションに設定する事で、クエリを最適化し、時系列データを最大限に活用できます。

パーティショニングキーを柔軟に設定出来るようになった事で、お客様の特定のワークロードにより適用できるようになり、データからより多くの価値を引き出す事ができるようになります。以下の例で確認していきましょう。

顧客定義のパーティションキーの仕組み

新しいテーブルを作成する際、一般的なアクセスパターンに基づいて特定のパーティションキーを選択しますが、通常は顧客 ID や、デバイス ID 等のクエリのフィルタリング条件によく利用されるものを使います。適切なディメンジョンをパーティションキーに選択する事で、最良のパフォーマンスを得る事が出来ます。

また、オプションでパーティションキーを示す項目に対して Null 値を許容しないように Timestream のテーブルを設定する事も出来ます。そうする事で、パーティション分割がさらに最適化され、最良のパフォーマンスが得られます。

パーティションキーを選択する際、独自のディメンジョンを設定したい場合は必ず Dimension を選んで下さい。もしも Measure name を選択した場合には、Timestream はデフォルトのパーティショニングスキーマを採用する為、特定メジャーの時間の経過に伴うフリート全体の変動を分析するのに適しています。

一般的なアクセスパターンについて話す時は、時系列データに対してクエリ実行する際のフィルターや述語の種類を指します。これらのフィルターには、特定の顧客 ID, デバイス ID, 又はお客様のビジネスに取って重要な高いカーディナリティのディメンジョン等が含まれる場合があります。パーティショニングキーが DeviceModel である仮定の使用例では次のようなコードとなります。

Select 
 DeviceModel, segment, Event_name, count(event_name) as occurrences 
from
 events
where 
 event_type = ‘voice chrome latency’ and 
 DeviceModel in (‘xxx-xxx-xx’ , ‘yyy-yyy-yy’, ‘zzz-zzz-zz’, ‘%-012’) and 
 time >= ago(1h) 
group by 1, 2,3
order by occurrences

例えば、Timestream にスマートデバイスや IoT アプリケーションからのデータを保存している場合には、デバイスモデルに基づいてデータを分割したいかも知れません。デバイスモデルをパーティショニングキーに設定する事で、テーブル内の全てのデータをスキャンする事無く、特定のデバイスセットの値を迅速に取得する事が出来ます。同じように、例えば顧客とのやり取りに関するデータを保存している場合は、顧客 ID にパーティションキーを設定する事で、特定の顧客の全てのやり取りを迅速に取る事を検討すべきでしょう。そうする事で、顧客に関連するすべてのデバイスの可視性も提供される事になります。

同じデータから派生する複数の異なるアクセスパターンがあるような場合には、異なるユースケースに最適化された別のパーティションキーを使ったスケジュールドクエリーを利用する事も出来ます。例えば、一つはデバイスモデルの動作を理解する為のもの、もう一つは特定の顧客に関連する問題の原因分析と言った具合です。

最も一般的なアクセスパターンを把握する事で、パーティションキーに最もふさわしいディメンジョンを選択出来ます。これにより、Timestream は特定のアクセスパターンに対するクエリパフォーマンスを最適化し、時系列データ分析をより高速かつ効率的に実施する事が出来ます。

顧客定義によるパーティションキーを作成すると、Timestream は取り込まれたデータを自動的にパーティショニングし、クエリのパフォーマンスが最適化される事になります。テーブルが一旦パーティション化されると変更出来ない為、クエリパターンを慎重に検討し、パーティションキーとして最適なディメンジョンを選択する事が重要です。

データの正確性を確保し、クエリ効率を最大限高める為、スキーマ強制という新機能についてもリリースされています。この機能を使う事で、パーティションキーとして利用されているディメンジョンを含まない書き込みを拒否する事が出来ます。これにより、データが適切にパーティショニングされ、クエリパフォーマンスが高まり、より迅速に洞察を得る事が出来ます。パーティショニングの利点を最大限に活用できるように、強制レベルを REQUIRED とする事を推奨します。但し、少量のデータには対象となるディメンジョン値が存在しないようなユースケースもある事は理解しており、その場合は、強制レベルを OPTIONAL とすると対象ディメンジョンが無くとも書き込みを行う事が可能であり、全て同じ場所に格納される形となります。尚、強制レベルについては、テーブル作成後でも変更する事が可能です。

顧客定義のパーティションキーのケーススタディ

それでは、社内の AVS 監視チームが顧客定義のパーティションキーを利用して、数百万ものデバイスのパフォーマンスを監視した例を見てみましょう。AVS 監視チームはデバイスメトリクス、システム健全性メトリクス、クラウドメトリクス等、接続されている数百万のデバイスからデータを毎日取り込んでいます。目標は全てのデバイスでの顧客体験の改善ですが、大量のデータが存在する為、エンティティレベルでデータを効率的に分析する方法が重要となります。この特定のユースケースでは、エンティティは個別デバイスか、特定のセグメントにまとまったすべてのデバイスとなります。デバイス監視システムは、デバイスとクラウド側のメトリクスをほぼリアルタイムで分析を行い、異常を検出し、問題を軽減して顧客体験の改善につなげる必要があります。

次の図は上記のユースケース用に実装されたアーキテクチャを示しています。

考えられるデータモデルの一つは地域、デバイスタイプ、ヘルスメトリクス等のデータを含んでいると考えられます。例えば、device_type にパーティションキーを設定すると、デバイスタイプを条件に含むクエリのスキャン量が削減される事でレイテンシーが改善され、この特定の属性に基づいた問題の検知や、その原因分析がやりやすくなります。

データモデルの例を見てみましょう。

このデータモデルでは、カーディナリティが数百万に達するディメンジョンはあまり含まれていませんが、デバイスモニタリングチームはその中から device_type を顧客定義のパーティションキーとして選びました。データが app_name, device_type, device_model によってパーティション化されている場合にパフォーマンスが向上する例をいくつか見てみましょう (尚、Timestream はテーブル毎に複数のパーティションキーを割り当てる事が出来ません) 。このスキーマを使って次のような非常に貴重な洞察を得る事が出来ます。

• 特定のアプリケーションで使用されている全てのデバイスを使用時間でランク付する必要がある場合、理想的なパーティションキーは app_name です。
• 特定のセグメントのイベントの成功／失敗を全て検索し、平均レイテンシーやデバイスタイプ毎の結果を計算する必要がある場合、理想的なパーティションキーは segment です。
• 全てのドメインでの成功したイベントのレイテンシーを確認する必要がある場合、理想的なパーティションキーは domain です。
• 失敗したイベントの中から最も問題のあるデバイスタイプを示すダッシュボードを作成する事が目標の場合、理想的なパーティションキーは device_type となります。

顧客定義のパーティションキー機能を、スケジュールドクエリ等の他の機能と併せて利用する事で、よりクエリパフォーマンスが改善し、コストが最適化される事を確認しました。スケジュールドクエリの詳細についてはドキュメントを参照して下さい。

あなたのクエリを最適化しましょう！

顧客定義のパーティションキー機能は、エンティティレベルの分析でクエリのパフォーマンスを最適化する為の強力なツールとなります。最も一般的なアクセスパターンを理解し、ほとんどのデータアクセスニーズに合致する高いカーディナリティのディメンジョンを選択する事で、クエリパフォーマンスの改善につなげる事が出来ます。デバイス監視の上述の例では、特定のディメンジョンレベルの分析用にクエリを最適化する事で、デバイスのパフォーマンスをより深く理解し、サービス改善につなげる事が出来ました。また、スキーマ強制の機能により、パーティションキーとして利用されるディメンジョンを含まない書き込みリクエストを拒否する事も出来ます。30 日間のトライアルを利用して Amazon Timestream を無料でご利用開始して頂き、お客様の時系列ワークロードの探索を始めては如何でしょう？

翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文はこちらをご覧下さい。