この記事は Measuring the accuracy of rule or ML-based matching in AWS Entity Resolution (記事公開日 : 2025 年 9 月 29 日) を翻訳したものです。 エンティティマッチングのルールセットやモデルが実際に十分な精度を持っているかどうか、どのように判断すればよいでしょうか？複数のアイデンティティプロバイダーを評価する場合でも、独自のマッチングルールを構築する場合でも、企業は達成したい明確な精度レベルの基準と、異なるアプローチを客観的に測定・比較するためのフレームワークを確立する必要があります。アイデンティティプロセスを客観的に測定しない企業は、実装期間を数週間、場合によっては数ヶ月も延長してしまい、手順を繰り返したり、精度測定の手法に高コストな変更を加えたりすることになります。 本記事では、 AWS Entity Resolution の既存機能である独自の機械学習 (ML) アルゴリズムを使用してモデルの精度をテストするアプローチについて説明し、実演します。AWS Entity Resolution は、複数のアプリケーション、チャネル、データストア間に保存された関連する顧客、製品、ビジネス、またはヘルスケア記録のマッチング、リンク、拡張を支援します。また、独自のデータまたは合成オープンソースデータセットを使用して結果を再現するために必要なすべてを提供します。 このフレームワークを使用することで、マッチングの精度を迅速に評価する方法を提供します。このプロセスは、ベンチマークを試みているあらゆるエンティティマッチングプロセスに適用できます。 精度が重要な理由 まず、精度とは何を意味するのでしょうか？本記事での精度とは、同一人物に属する記録を正しく識別し、かつ異なる人物の記録を誤ってマッチングしない頻度を指します。つまり、完全に正確なソリューションは、同一人物に属するすべての重複記録をマッチングし、断片を見逃すことなく、他の人物に属する記録に余分なデータをマッチングすることもありません。 これは直感的な概念ですが、一貫した測定は困難です。多くの企業が顧客データの重複排除・統合プロジェクトに着手する際、真陰性と真陽性を正確に測定する一貫した方法論や指標を持っていません。また、多くの企業は、顧客データで発生する複雑なエッジケースを捉える信頼できる個人情報データセットも不足しています。 100% クリーンなデータ、または十分に小さなサンプルセットで精度指標 100% を達成することは可能です。しかし、実世界のデータやより大きなデータボリュームでは、真の曖昧性を持つ無数のエッジケースが存在するため、100% の精度でマッチングすることは現実的ではありません。したがって、企業は不可能な目標を追い求める無限の実装サイクルに陥らないよう、精度について、測定可能な閾値を設定する必要があります。 今日、企業はこれまで以上に多くの断片化したデータを受け取っています。モバイルアプリのタップ、オンラインクリック、認証セッションのすべてが、企業が消費者行動を理解し、体験をパーソナライズし、運用を最適化するのに役立つデータを生成します。このデータを顧客の統一ビューにまとめることができる企業は、これらの洞察を使用してより良いパーソナライズされた体験を提供できます。また、より情報に基づいた製品、マーケティング、販売の意思決定を行うこともできます。 データからより多くの価値を引き出すことに焦点を当てている企業には、選択できるエンティティマッチングツールやサービスが幅広くあります。しかし、企業はしばしばソリューションの評価と実装で数ヶ月、場合によっては数年間停滞してしまいます。 最初の障害の一つは、アイデンティティマッチングフレームワークとアプローチを評価するための堅牢で一貫したフレームワークが不足していることです。どのアイデンティティマッチング手法が自社データに最も適しているか、企業はどう判断すればよいのでしょうか？精度に関する利害関係はますます高くなっています。顧客は、頻繁に利用するブランドや企業によりパーソナライズされた体験を期待しています。精度のベンチマークも、業界やユースケースに基づいて企業ごとに異なります。 アイデンティティ解決プロセスが特定のニーズに対応していることを企業が信頼するためには、本番データで実際に見られるエッジケースを含む信頼できるデータのベンチマークを作成し、顧客データを収集するあらゆるシステムから受け取る記録の種類に基づいて精度を定義する必要があります。 正解データセット (グラウンドトゥルース) マッチングプロセスの精度を評価する最も広く受け入れられている方法は、プロセスの結果を手動で注釈付けされた正解データセット (真実セットとも呼ばれる) と比較することです。AI における正解データセットとは、事実として知られているデータを指し、モデル化されているシステムの期待されるユースケースの結果を表します。 このユースケースでは、正解データセットは、人間が手動でレビューし、マッチングすべきかどうかを注釈付けした記録ペアの小さなサブセットです。正解データセットは大きくある必要はありませんが、データで頻繁に発生するユースケースの代表的なセットを含むのに十分な大きさである必要があります。 ただし、正解データセットには個人識別情報 (PII) が必要であるため、企業は概念実証でそれらを共有または使用することについて慎重である必要があります。また、必要なすべてのセキュリティプロトコルが整っていることを確認する必要があります。正解データセットは、他のベンチマークデータセットと比較して、より良い再現可能な結果を得ることができます。 アイデンティティ解決精度測定の課題 顧客の単一ビューの価値は、そのデータが表現しようとしている現実世界をどれだけ忠実に反映しているかにほぼ依存しています。しかし、個々の記録のみを見ている場合、精度の評価基準が一定せず、変動してしまう可能性があります。企業は、アイデンティティマッチングのルールを構築したりアルゴリズムを使用したりする際に、明確な精度の閾値を持つ必要があります。そうでなければ、修正と変更の無限のプロセスに陥ってしまいます。これらの閾値は顧客によって異なります。 例えば、同じ業界の 2 つの企業が、データを収集する場所のコンテキストに基づいて異なる精度の閾値を設定する必要がある場合を見てみましょう。2 つの異なる小売業者、企業 A と B を考えてみます。 企業 A は、取引イベントとロイヤルティプログラムから顧客データを収集する実店舗の食料品小売業者です。これらの取引は、現金が使用された場合はデータがないか、世帯内で共有されたり企業によって使用されたりする可能性のあるクレジットカードトークンを使用します。さらに、カードベースのロイヤルティプログラムを通じてロイヤルティデータを収集する場合、空白、不完全なデータ、または複数の異なる人々に関連付けられた多くの共有住所と固定電話データを持つカードがある可能性があります。新しいカードや共有されたカードを提示することでロイヤルティ特典を受けることができるため、顧客が正確なデータを共有するインセンティブはありません。 企業 A は、不完全な名前データ、クレジットカードトークン、高い割合で共有されるデータを含む記録ペアでマッチングをテストする必要があります。さらに、顧客がデータを共有する方法に基づいて企業 A が可能な最も正確な解決レベルであるため、グループ化のための世帯レベルのマッチングにのみ関心があります。 これを、ウェブサイトですべての取引を行うオンライン小売業者である企業 B と対比してみましょう。ほぼすべての顧客がメールアドレスで認証し、閲覧行動に関連付けられたプロファイルを持っています。顧客は実際に購入した商品を受け取るために、正確な住所、名前、メールアドレスの値を共有する必要があります。同じ世帯内の個人でも、個人のアカウントやメールアドレスを通じて領収書を受け取り、返品を開始する方が迅速であるため、自分の名前とメールアドレスで購入する可能性が高くなります。 実店舗小売業者である企業 A とは異なり、企業 B は個人レベルでユーザーをマッチングできます。配送先住所と電話番号が共有される可能性があるため、マッチングする前により高い割合の共有属性を要求することができます。しかし、他の多くの信頼できるデータが世帯のメンバーや重複するデータを持つユーザーを区別することができます。 両方の小売業者は、自社のデータに存在するシナリオを反映し、許容可能なマッチングの独自の閾値を持つ独自の正解データセットを作成すれば、最良の結果を得られるでしょう。このセットには、まとめるべき記録の断片 (真陽性) と、多くの特徴を共有するが分離しておく必要がある記録 (真陰性) の両方のテストケースを含める必要があります。マッチングに使用するために、これらのテストケースは、記録がマッチングすべきかどうかを示す正解データセットとして注釈付けされる必要があります。 データサイエンスコミュニティでは、精度を測定する最も標準的な方法は、F1 スコアと呼ばれる指標です。 F1 スコア は、正解データセットに対するモデルパフォーマンスの 2 つの主要な側面である精密度と再現率を平均化した指標です。 エンティティマッチングモデルのコンテキストでは、精密度は、正解データセットでマッチングされていない 2 つの記録を誤ってまとめてしまう偽陽性マッチをモデルがどの程度防げるかを指します。この文脈での再現率は、正解データセットでグループ化されている記録をモデルがどの程度正しくまとめることができるかを指します。したがって、正解データセットには、まとめるべき記録ペアと、類似性を共有するが一緒に属さない記録ペアの両方が含まれている必要があります (図 1 参照) 。 図 1 – 再現率と精密度を定義する表 F1 スコアは、精密度と再現率の調和平均として定義され、次のように計算されます : F1 スコア = 2 × [(精密度 × 再現率) / (精密度 + 再現率)] 精密度は、真陽性 (正しいマッチ) を、真陽性と偽陽性 (不正なマッチ) の合計で割った比率です。再現率は、真陽性を、真陽性および偽陰性 (見逃されたマッチ) の合計で割った比率です。F1 スコアは 0 から 1 の範囲で、値が高いほど精密度と再現率のバランスが良いことを示します。このバランスは、異なる業界が精密度または再現率を異なって優先するため重要です。例えば、ヘルスケア業界はしばしば偽陽性を最小化することを目指し (精密度を重視) 、広告業界は真陽性を最大化することに焦点を当てます (再現率を重視) 。 データ評価のウォークスルー 精度をテストするために顧客が使用できる公開データセットはそれほど多くありません。これらの分析でよく使用されるデータセットの一つが、オハイオ州有権者ファイルです。 オハイオ州有権者ファイル は、人物マッチングのためのよく知られた公開データセットです。オハイオ州の有権者情報から名前、住所、生年月日を含む 105,000 件の記録が含まれています。 オハイオ州有権者ファイルは、実際のデータを含むため、開発者による多くのエンティティマッチングソリューションで最も一般的に使用される正解データセットです。しかし、実際の顧客データの代理としての有用性を制限するいくつかの欠点があります。電話番号とメールフィールドが不足しており、正規化されていない郵便住所などのよくあるデータ品質問題がなく、記録が非常に完全である傾向があります。 これらのより複雑でデータ品質の低い例に対応するため、AWS Entity Resolution Data Science チームは、こうした困難なエンティティ解決シナリオをより忠実に再現する新しい合成データセットを開発し、オープンソース化しました。これは、 BPID: A Benchmark for Personal Identity Deduplication と呼ばれています。BPID は、名前、メール、電話、住所、生年月日フィールドにわたる複雑なパターンを持つ 2 万件の合成記録を含む、はるかに困難なデータセットです。BPID は、世界有数の自然言語処理会議の一つである Empirical Methods in Natural Language Processing (EMNLP) 2024 で発表されました。 以下の例では、AWS Entity Resolution の機能である機械学習ベースのマッチングモデルの精度を測定する手順を実演します。BPID からのオープンソースの正解データセットを使用します。 前提条件 AWS アカウント データマッチング概念の基本的理解 分析実行のための Jupyter Notebook または類似環境 Python とデータ処理ライブラリの知識 1. データのダウンロード まず、テストで使用するデータをダウンロードする必要があります。BPID データセットをダウンロードして解凍します。精度評価には matching_dataset.jsonl を使用します。以下は、BPID データセットからのペアの例です： {"profile1": {"fullname": "corrie arreola", "email": ["c_orrie@bizdev.org", "c0rri3@gov.us"], "phone": ["03 1284418523"], "addr": [], "dob": "1953 11 09"}, "profile2": {"fullname": "arreola corrie", "email": ["arreola_2023@gmail.com"], "phone": [], "addr": ["45434 11478 jenny road tx 75155 0411 falconer", "100209 57 summer drive hollywood"], "dob": "09 nov 1953"}, "match": "True"} {"profile1": {"fullname": "elroy warner", "email": ["e.l.roy@private-domain.info"], "phone": [], "addr": ["21480 miser road seal cove tx 75109 0784 united states of america"], "dob": "2007 09 26"}, "profile2": {"fullname": "charlee warner", "email": ["charlee.smith@biz-tech.com"], "phone": [], "addr": ["21480 miser rd j646 seal cove tx 75109"], "dob": "09 2007"}, "match": "False"} 2. テストと正解データセットの前処理 テストデータから 2 つのデータセットを準備します。1 つは入力用、もう 1 つはマッチング後の精度測定用の正解データセットです。 matching_dataset.jsonl をプロセッサに必要なスキーマに変換する必要があります。AWS Entity Resolution で使用するためにこのデータを準備するには、まずローカルまたは仮想環境にデータを読み込む必要があります。 import json import pandas as pd #BPIDデータセットは zenodo.org/records/13932202 を通じて公開されています raw_data_path = "./data_release/matching_dataset.jsonl" raw_data = [json.loads(line) for line in open(raw_data_path).readlines()] 次に、入力レコードをフラット化・変換して、AWS Entity Resolution で読み込める形式にします。ラベルは以下に概説されているように別のファイルに保存されます： max_length_mapping = {"email": 0, "phone": 0, "addr": 0} for data_i in raw_data: for field in max_length_mapping: max_length_mapping [field] = max( max_length_mapping[field], len(data_i["profile1"][field]), len(data_i["profile2"][field]) ) print(f"max_email_length={ max_length_mapping['email']}") print(f"max_phone_length={ max_length_mapping ['phone']}") print(f"max_addr_length={ max_length_mapping['addr']}") profile_list = [] name_list = [] dob_list = [] email_list = {f"email_{i+1}": [] for i in range(max_length_mapping["email"])} phone_list = {f"phone_{i+1}": [] for i in range(max_length_mapping["phone"])} addr_list = {f"addr{i+1}": [] for i in range(max_length_mapping["addr"])} 次に、以下のスクリプトを実行し、精度スコア計算用にラベルを分離・準備します： label_list = [] for i, data_i in enumerate(raw_data): p1, p2 = data_i["profile1"], data_i["profile2"] #ペアのラベルを保存 label_list.append({"profile_id_1":f"pair{i}_0", "profile_id_2":f"pair{i}_1", "label": data_i["match"]}) #プロファイルを追加 for p in [p1, p2]: p_json = {"profileid":f"pair{i}_0", "fullname":p["fullname"], "dob":p["dob"]} for attr in ["email", "phone", "addr"]: for j in range(1, max_length_mapping[attr]+1): p_json[f"{attr}_{j}"] = p[attr][j] if j<len(p[attr]) else "" profile_list.append(p_json) 次に、以下を使用して処理されたプロファイルとラベルを json ファイルとして保存します： # プロファイルを json ファイルに保存 f_out = open("./data_release/BPID_matching_profiles_processed.jsonl", "w") for p in profile_list: f_out.write(json.dumps(p)+ "\n") f_out.close() # ラベルを json ファイルに保存 f_out = open("./data_release/BPID_matching_label.jsonl", "w") for label_pair in label_list: f_out.write(json.dumps(label_pair)+ "\n") f_out.close() この前処理を実行した後、プロファイルデータ ( BPID_matching_profiles_processed.jsonl ) は以下のようになります： {"profileid": "pair0_0", "fullname": "corrie arreola", "dob": "1953 11 09", "email_1": "c0rri3@gov.us", "email_2": "", "email_3": "", "phone_1": "", "phone_2": "", "phone_3": "", "addr_1": "", "addr_2": "", "addr_3": "", "addr_4": "", "addr_5": ""} {"profileid": "pair0_1", "fullname": "arreola corrie", "dob": "09 nov 1953", "email_1": "", "email_2": "", "email_3": "", "phone_1": "", "phone_2": "", "phone_3": "", "addr_1": "100209 57 summer drive hollywood", "addr_2": "", "addr_3": "", "addr_4": "", "addr_5": ""} 付随するラベルファイル ( BPID_matching_label.jsonl ) は以下のようになります： {"profile_id_1": "pair0_0", "profile_id_2": "pair0_1", "label": "True"} {"profile_id_1": "pair1_0", "profile_id_2": "pair1_1", "label": "False"} 3. マッチングワークフローの実行 テストデータが変換されたら、評価予定のワークフローに対して マッチングワークフロー を実行します。 目標は、入力データセット内の任意の 2 つの記録が同一人物に属するかどうかを肯定的または否定的にマッチングできるマッチング結果を取得することです。この手順はサービスによって異なります。 最後に、AWS Entity Resolution マッチングワークフローを実行します。以下は、AWS Entity Resolution からの出力例です： InputSourceARN,ConfidenceLevel,addr1,addr2,addr3,addr4,addr5,dob,email1,email2,email3,fullname,phone1,phone2,phone3,profileid,RecordId,MatchID arn:aws:glue:us-west-2: :table/yefan-bpid-benchmark/input,0.75296247,cookson tx 75110,,,,,2003 7,,,,,26806124715,3236000026,,pair1622_1,pair1622_1,6d08ce607181460584e2436e66660b2300003566935683247 arn:aws:glue:us-west-2::table/yefan-bpid-benchmark/input,0.75296247,cookson tx 75110,,,,,2003 07 10,yong123@business-domain.co.uk,,,yong stearns,6807159172,6806124715,,pair1622_0,pair1622_0,6d08ce607181460584e2436e66660b2300003566935683247 4. F1 スコアの計算 マッチング結果を取得した後、生データのラベル情報とマッチング結果を使用して F1 スコア指標を計算できます。データセット matching_dataset.jsonl 内の各ペアには、マッチまたは非マッチのラベルがあります。各ペアについて、マッチング結果でラベルと一致するかどうかを確認します。その後、このペアを 4 つのカテゴリのいずれかに割り当てます： 真陽性 (TP) ：ラベルとマッチング結果の両方がマッチを示唆 偽陽性 (FP) ：ラベルは「非マッチ」だがマッチング結果はマッチ 真陰性 (TN) ：ラベルとマッチング結果の両方が非マッチを示唆 偽陰性 (FN) ：ラベルは「マッチ」だがマッチング結果は非マッチ これら 4 つのタイプの数を取得した後、以下を計算できます： 精密度 = TP / (TP + FP) 再現率 = TP / (TP + FN) F1 スコア = 2 × [(精密度 × 再現率) / (精密度 + 再現率)] 独自のベンチマークテストの実行 ベンチマークプロセスを実行することで、これらの結果を再現できます。以下は、機械学習ベースマッチングのための AWS Entity Resolution でこのプロセスを実行するために必要な手順とノートブックの概要です。手順とデータは、ルールベースマッチングワークフローまたは他のプロバイダーからのマッチングプロセスの精度を評価するために再利用することもできます。BPID データには実際の顧客 PII が含まれていないため、基礎となる参照グラフを使用するプロバイダーを評価するために使用できます。 アイデンティティ解決プロセスの改善を目指すチームには、以下をお勧めします： 独自の評価のための BPID データセットのダウンロード AWS Entity Resolution の機械学習ベースマッチング機能の探索 ベンダー評価における主要指標としての F1 スコアの検討 結論 企業が顧客データを統合するために使用するルールやアルゴリズムの精度を測定することは非常に困難です。ほとんどの企業は、ベンチマークとなる注釈付き正解データセットを持たず、測定のための一貫した方法論を欠いている可能性があります。 AWS Entity Resolution を使用したアイデンティティ解決サービスの包括的な精度評価の実施方法を実演しました。ベンチマーク手法、オープンソースデータセット、そして読者が精度評価を再現できるステップバイステップガイドを提供しました。 AWS の担当者 に連絡して、お客様のビジネスの加速をどのように支援できるかをご確認ください。 参考資料 AWS Entity Resolution の高度なルールベースファジーマッチングを使用して不完全なデータを解決する 顧客の統一ビューを構築する方法 AWS でのエンティティ解決のためのルール推奨生成に関するガイダンス Travis Barnes Travis は、AWS Entity Resolution のシニアプロダクトマネージャー (テクニカル) として、高度なアイデンティティ解決技術を通じて顧客がデータ価値を最大化できるよう支援しています。アイデンティティとアドテック分野で革新的な製品を構築してきた 10 年以上の経験を持ち、実際のビジネス成果につながる複雑なデータ課題の解決に情熱を注いでいます。 Yefan Tao Yefan は、大規模なエンティティ解決と情報検索システムを専門とするシニア応用科学者です。自然言語処理 (NLP) および関連分野において、堅牢で効果的な機械学習アルゴリズムを開発しています。研究と実用化の橋渡しにおける長年の経験を持ち、効率性と精度の両面で限界に挑戦する複雑なデータガバナンスとアイデンティティの課題解決に注力しています。 本稿の翻訳は、ソリューションアーキテクトの髙橋が担当しました。原文は こちら 。

こんにちは、技術戦略部のikkouです。2025年12月16日に「 AI Engineering Summit Tokyo 2025 」が開催されました。ZOZOはGoldスポンサーとして協賛し、スポンサーブースを出展しました。 AI Engineering Summit Tokyo 2025 会場エントランスのスポンサーパネル technote.zozo.com 本記事ではZOZOから登壇したセッションの紹介と、ZOZOの協賛ブースの様子をまとめてお伝えします！ セッションレポート ファッション×AI：「似合う」を届けるためのWEARのAI戦略 登壇中のブランドソリューション開発本部 本部長の増田 ブランドソリューション開発本部 本部長の増田が登壇し、ZOZOが「似合う」というテーマに取り組む背景から、それをWEARでどのように実現しているのかまでを紹介しました。 WEARにおけるAI活用の考え方や戦略について、具体的な事例を交えながら語られたセッションとなりました。登壇資料はSpeaker Deckで公開されています。 speakerdeck.com 見逃した方は、Findy Conferenceのアーカイブ動画もぜひご覧ください。 conference.findy-code.io セッション後のAsk the Speakerもとても盛り上がっていました。会場にお越しいただいた方、オンラインでご視聴いただいた方、ありがとうございました。 エンジニア組織として全社のAI活用をどうリードしていくのか パネルディスカッションに登壇中の執行役員 兼 CTOの瀬尾 続いて、執行役員 兼 CTOの瀬尾（ @sonots ）が「AI時代の開発組織の未来像 ― 5年後の姿をどう考えるか？」をテーマとしたパネルディスカッションに登壇しました。 本セッションは会場限定での実施となりましたが、アーカイブ動画が公開されています。このトピックに関心のある方は、ぜひご視聴ください。 conference.findy-code.io ZOZOブースレポート ZOZOの協賛ブースでは、当日登壇したセッション資料を含むAI関連の取り組み資料をスライドショー形式で紹介しました。 特に、瀬尾がパネルディスカッション内で言及していた「ZOZOグループで利用可能な代表的なAIツール」に関心を持たれる方が多く、ブースでも活発な交流が行われていました。 ZOZOグループで利用可能な代表的AIツール（2025年12月現在） ブース内では、「似合う」に関する取り組みを紹介するパネル展示も行いました。 ZOZOの独自性を生み出す「似合う4大要素」の開発サイクル 『ZOZOの独自性を生み出す「似合う4大要素」の開発サイクル』を解説する冨田 speakerdeck.com データサイエンス部 コーディネートサイエンスブロックの冨田が、ZOZOの独自性を支える「似合う4大要素」の開発サイクルについて解説しました。進行中のプロジェクトのため公開できる内容には限りがありましたが、プロジェクトに深く関わっている立場から、一人ひとりに丁寧な説明が行われました。 ファッションコーディネートアプリ「WEAR」におけるコーディネートレコメンドの動作インフラとその周辺技術 『ファッションコーディネートアプリ「WEAR」におけるコーディネートレコメンドの動作インフラとその周辺技術』を説明する岡本 ファッションコーディネートアプリ「WEAR」におけるコーディネートレコメンドの動作インフラとその周辺技術 もうひとつの展示では、ファッションコーディネートアプリ「WEAR」におけるコーディネートレコメンドの仕組みと、その周辺技術を紹介しました。データシステム部 MLOpsブロックの岡本が、関連するコーディネート情報を活用した推薦システムのアーキテクチャを、MLOpsの観点から解説しました。 前月に協賛してブースを出展したアーキテクチャConference 2025 でも感じたことですが、アーキテクチャやシステム構成に関心を持つ方は多く、こちらの展示も大きな盛り上がりを見せていました。 おわりに ZOZOから参加したメンバーの一部で記念撮影！ 今回の協賛・出展を通して、改めてAIの活用や開発に対する関心の高まりを強く感じました。ZOZOのAIに対する考え方や取り組みが、少しでも来場者の皆さまに伝わっていれば嬉しいです。 ZOZOでは、今回ご紹介したWEARのエンジニアをはじめ、さまざまな分野でエンジニアを募集しています。ご興味のある方は、ぜひ採用ページをご覧ください。 corp.zozo.com

本記事は 2026 年 1 月 15 日 に公開された「 Unlock granular resource control with queue-based QMR in Amazon Redshift Serverless 」を翻訳したものです。 Amazon Redshift Serverless は、データウェアハウス運用からインフラストラクチャ管理と手動スケーリングの要件を取り除きます。Amazon Redshift Serverless のキューベースクエリリソース管理は、クエリを専用キューに分離し、高負荷のクエリが他のユーザーに影響を与えることを防ぐ自動ルールを使用することで、重要なワークロードを保護し、コストを制御するのに役立ちます。さまざまなワークロードに対してカスタマイズされた監視ルールを持つ専用クエリキューを作成でき、リソース使用量をきめ細かく制御できます。キューを使用すると、メトリクスベースの述語と自動応答を定義でき、時間制限を超えたり過剰なリソースを消費したりするクエリを自動的に中止するなどの対応が可能です。 さまざまな分析ワークロードには、それぞれ異なる要件があります。マーケティングダッシュボードには、一貫した高速な応答時間が必要です。データサイエンスワークロードでは、複雑でリソース集約的なクエリを実行する場合があります。抽出、変換、ロード (ETL) プロセスでは、オフピーク時に長時間の変換を実行する場合があります。 組織がより多くのユーザー、チーム、ワークロードにわたって分析の使用を拡大するにつれて、共有環境で一貫したパフォーマンスとコスト管理を確保することがますます困難になっていきます。最適化が不十分な単一のクエリが過度のリソースを消費し、ビジネスクリティカルなダッシュボード、ETL ジョブ、経営層向けレポートのパフォーマンスを低下させる可能性があります。Amazon Redshift Serverless のキューベース Query Monitoring Rules (QMR) を使用すると、管理者はキューレベルでワークロードに応じたしきい値と自動アクションを定義できます。これは、以前のワークグループレベルの監視からの大幅な改善です。BI レポート、アドホック分析、データエンジニアリングなどの異なるワークロード用に専用キューを作成し、キュー固有のルールを適用して、実行時間またはリソース消費制限を超えるクエリを自動的に中止、ログ記録、または制限できます。ワークロードを分離し、ターゲットを絞った制御を実施することで、このアプローチはミッションクリティカルなクエリを保護し、パフォーマンスの予測可能性を向上させ、リソースの独占を防ぎます。これらすべてを、サーバーレスエクスペリエンスの柔軟性を維持しながら実現します。 この記事では、Redshift Serverless でクエリキューを使用してワークロードを実装する方法について説明します。 キューベース監視とワークグループレベル監視の比較 クエリキューが導入される前は、Redshift Serverless はワークグループレベルでのみクエリ監視ルール (QMR) を提供していました。これは、目的やユーザーに関係なく、すべてのクエリが同じ監視ルールの対象となることを意味していました。 キューベース監視は、大きな進化をしています。 きめ細かな制御 – さまざまなワークロードタイプ用に専用キューを作成できます ロールベースの割り当て – ユーザーロールとクエリグループに基づいて、クエリを特定のキューに振り向けることができます 独立した動作 – 各キューは独自の監視ルールを維持します ソリューション概要 以下のセクションでは、一般的な組織が Redshift Serverless でクエリキューを実装する方法を検討します。 アーキテクチャコンポーネント ワークグループ設定 クエリキューが定義される基本単位 キュー定義、ユーザーロールマッピング、監視ルールが含まれます キュー構造 単一のワークグループ内で動作する複数の独立したキュー 各キューには独自のリソース割り当てパラメータと監視ルールがあります ユーザー/ロールマッピング 以下に基づいて、クエリを適切なキューに振り向けます。 ユーザーロール (例: analyst、etl_role、admin) クエリグループ (例: reporting、group_etl_inbound) 柔軟なマッチングのためのクエリグループワイルドカード Query Monitoring Rules (QMR) 実行時間やリソース使用量などのメトリクスのしきい値を定義します しきい値を超えた場合の自動アクション (中止、ログ記録) を指定します 前提条件 Amazon Redshift Serverless でクエリキューを実装するには、以下の前提条件が必要です。 Redshift Serverless 環境 : アクティブな Amazon Redshift Serverless ワークグループ 関連付けられた名前空間 アクセス要件 : Redshift Serverless 権限を持つ AWS Management Console アクセス AWS CLI アクセス (コマンドライン実装の場合はオプション) ワークグループの管理データベース認証情報 必要な権限 : Redshift Serverless 操作の IAM 権限 (CreateWorkgroup、UpdateWorkgroup) データベースユーザーとロールを作成および管理する機能 ワークロードタイプの特定 まず、ワークロードを分類することから始めます。一般的なパターンには以下が含まれます。 インタラクティブ分析 – 高速な応答時間を必要とするダッシュボードとレポート データサイエンス – 複雑でリソース集約的な探索的分析 ETL/ELT – より長い実行時間を持つバッチ処理 管理 – 特別な権限を必要とするメンテナンス操作 キュー設定の定義 各ワークロードタイプに対して、適切なパラメータとルールを定義します。実用的な例として、3 つのキューを実装したいとします。 Dashboard キュー – analyst および viewer ユーザーロールによって使用され、60 秒を超えるクエリを停止する厳格なランタイム制限が設定されています ETL キュー – etl_role ユーザーロールによって使用され、データ処理操作中のリソース使用量を制御するために、ディスクスピル ( query_temp_blocks_to_disk ) に 100,000 ブロックの制限があります Admin キュー – admin ユーザーロールによって使用され、クエリ監視制限は適用されません AWS Management Console を使用してこれを実装するには、以下の手順を実行します。 Redshift Serverless コンソールで、ワークグループに移動します。 制限 タブの クエリキュー で、 キューを有効にする を選択します。 以下のスクリーンショットに示すように、適切なパラメータで各キューを設定します。 各キュー (dashboard、ETL、admin_queue) は特定のユーザーロールとクエリグループにマッピングされ、クエリルール間に明確な境界を作成します。クエリ監視ルールはリソース管理を自動化します。たとえば、dashboard キューは 60 秒を超えるクエリを自動的に停止し ( short_timeout )、ETL プロセスには異なるしきい値でより長い実行時間を許可します。この設定は、適切なガードレールを備えた個別の処理レーンを確立することでリソースの独占を防ぎ、重要なビジネスプロセスが必要な計算リソースを維持しながら、リソースを大量に消費する操作の影響を制限できるようにします。 または、 AWS Command Line Interface (AWS CLI) を使用してソリューションを実装することもできます。 以下の例では、 test-namespace という既存の名前空間内に test-workgroup という名前の 新しいワークグループを作成 します。これにより、以下のコマンドを使用して、キューを作成し、各キューに関連する監視ルールを確立できます。 aws redshift-serverless create-workgroup \ --workgroup-name test-workgroup \ --namespace-name test-namespace \ --config-parameters '[{"parameterKey": "wlm_json_configuration", "parameterValue": "[{\"name\":\"dashboard\",\"user_role\":[\"analyst\",\"viewer\"],\"query_group\":[\"reporting\"],\"query_group_wild_card\":1,\"rules\":[{\"rule_name\":\"short_timeout\",\"predicate\":[{\"metric_name\":\"query_execution_time\",\"operator\":\">\",\"value\":60}],\"action\":\"abort\"}]},{\"name\":\"ETL\",\"user_role\":[\"etl_role\"],\"query_group\":[\"group_etl_inbound\",\"group_etl_outbound\"],\"rules\":[{\"rule_name\":\"long_timeout\",\"predicate\":[{\"metric_name\":\"query_execution_time\",\"operator\":\">\",\"value\":3600}],\"action\":\"log\"},{\"rule_name\":\"memory_limit\",\"predicate\":[{\"metric_name\":\"query_temp_blocks_to_disk\",\"operator\":\">\",\"value\":100000}],\"action\":\"abort\"}]},{\"name\":\"admin_queue\",\"user_role\":[\"admin\"],\"query_group\":[\"admin\"]}]"}]' また、以下のコマンドを使用して、 update-workgroup で既存のワークグループを変更することもできます。 aws redshift-serverless update-workgroup \ --workgroup-name test-workgroup \ --config-parameters '[{"parameterKey": "wlm_json_configuration", "parameterValue": "[{\"name\":\"dashboard\",\"user_role\":[\"analyst\",\"viewer\"],\"query_group\":[\"reporting\"],\"query_group_wild_card\":1,\"rules\":[{\"rule_name\":\"short_timeout\",\"predicate\":[{\"metric_name\":\"query_execution_time\",\"operator\":\">\",\"value\":60}],\"action\":\"abort\"}]},{\"name\":\"ETL\",\"user_role\":[\"etl_role\"],\"query_group\":[\"group_etl_load\",\"group_etl_replication\"],\"rules\":[{\"rule_name\":\"long_timeout\",\"predicate\":[{\"metric_name\":\"query_execution_time\",\"operator\":\">\",\"value\":3600}],\"action\":\"log\"},{\"rule_name\":\"memory_limit\",\"predicate\":[{\"metric_name\":\"query_temp_blocks_to_disk\",\"operator\":\">\",\"value\":100000}],\"action\":\"abort\"}]},{\"name\":\"admin_queue\",\"user_role\":[\"admin\"],\"query_group\":[\"admin\"]}]"}]' キュー管理のベストプラクティス 以下のベストプラクティスを検討してください。 シンプルに始める – 最小限のキューとルールのセットから始めます ビジネスの優先順位に合わせる – 重要なビジネスプロセスを反映するようにキューを設定します 監視と調整 – キューのパフォーマンスを定期的に確認し、しきい値を調整します 本番環境の前にテスト – 本番環境に適用する前に、テスト環境でクエリメトリクスの動作を検証します クリーンアップ リソースをクリーンアップするには、Amazon Redshift Serverless ワークグループと名前空間を削除します。手順については、 ワークグループの削除 を参照してください。 まとめ Amazon Redshift Serverless のクエリキューは、さまざまな分析ワークロードに合わせたキュー固有の Query Monitoring Rules を有効にすることで、サーバーレスのシンプルさときめ細かなワークロード制御のギャップを埋めます。ワークロードを分離し、ターゲットを絞ったリソースしきい値を実施することで、ビジネスクリティカルなクエリを保護し、パフォーマンスの予測可能性を向上させ、高負荷のクエリを制限できます。これにより、予期しないリソース消費を最小限に抑え、コストをより適切に管理しながら、Redshift Serverless の自動スケーリングと運用のシンプルさの恩恵を受けることができます。 今すぐ Amazon Redshift Serverless を始めましょう 。 著者について Srini Ponnada Srini は、Amazon Web Services (AWS) のシニアデータアーキテクトです。20 年以上にわたり、お客様がスケーラブルなデータウェアハウスとビッグデータソリューションを構築するのを支援してきました。AWS で効率的なエンドツーエンドソリューションを設計および構築することを愛しています。 Niranjan Kulkarni Niranjan は、Amazon Redshift のソフトウェア開発エンジニアです。Amazon Redshift Serverless の採用と Amazon Redshift のセキュリティ関連機能に注力しています。仕事以外では、家族と時間を過ごし、質の高いテレビドラマを視聴することを楽しんでいます。 Ashish Agrawal Ashish は現在、Amazon Redshift のプリンシパルテクニカルプロダクトマネージャーであり、クラウドベースのデータウェアハウスと分析クラウドサービスソリューションを構築しています。Ashish は IT 分野で 24 年以上の経験があります。Ashish は、データウェアハウス、データレイク、Platform as a Service の専門知識を持っています。Ashish は世界中の技術カンファレンスで講演しています。 Davide Pagano Davide は、Amazon Redshift のソフトウェア開発マネージャーであり、自動ワークロード管理、多次元データレイアウト、Amazon Redshift Serverless の AI 駆動スケーリングと最適化などのスマートなクラウドベースのデータウェアハウスと分析クラウドサービスソリューションの構築を専門としています。データベースで 10 年以上の経験があり、そのうち 8 年は Amazon Redshift に特化しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Tatsuya Koyakumaru がレビューしました。