HTAPデータベースの選び方：完全ガイド

アプリケーションがウェアハウスにまだ存在しない回答を必要とする場合、チームはHTAPデータベースを探し始めます。オンライン トランザクション処理 (OLTP) データベースが注文を記録し、変更データキャプチャ (CDC) ジョブが数分後にそれをウェアハウスにコピーしますが、その間に、それを必要とする不正チェックや在庫予約は古い数値に基づいて実行されています。ハイブリッド トランザクション/分析処理 (HTAP) データベースは、直前に書き込まれた行とそれ以前の何年にもわたる履歴を含む同じライブ データに対してトランザクションと分析を実行するため、コピー手順が不要になります。このガイドでは、HTAP データベースとその機能について説明します。次に、HTAP データベースを選択する前に実行すべき 5 つのテストを示し、HTAP という名称を共有する製品がこれらのテストで異なるスコアを示す理由を説明します。

HTAPデータベースは、トランザクションと分析クエリを同一システム内で同じデータに対して実行するため、クエリは、書き込みを行ったトランザクションがコミットされるとすぐにその行を読み取ることができます。最適なデータベースを選択するには、コミット後のデータの鮮度、分析負荷時のトランザクションのレイテンシ、アドホッククエリの同時実行性、読み取りと書き込みが同時にコミットされるかどうか、履歴を含めた総コストの5つのテストを、ご自身のワークロードで実行してください。

既にHTAPまたは分散SQLデータベースを運用していて、置き換えを検討している場合、後半の2つのセクションでは、通常、置き換えの決定要因となる2つの質問、つまり、アプリケーションのどの程度を変更する必要があるか、そして、それを運用するベンダーのセキュリティをどのように評価するかについて解説しています。

HTAPデータベースとは何か？

ほとんどの企業は2種類のデータベース処理を行っています。OLTP（オンライン・トランザクション処理）は、注文、支払い、取引、ログインなど、発生したイベントをその都度記録します。一方、OLAP（オンライン分析処理）は、今四半期の地域別収益や顧客の過去3年間の支出など、多数のレコードにわたる質問に一度に回答します。数十年間、この2つは別々のシステムで運用されており、分析側は数分から1日前のトランザクションデータのコピーに基づいて処理を行っていました。

HTAPデータベースは、1つのシステムで、1つのデータコピーに対して両方の種類の処理を実行します。トランザクションがコミットされると、次の分析クエリにそのトランザクションが組み込まれ、パイプラインを介したり、同期を維持するための2つ目のコピーを作成したりする必要はありません。

コピーを廃止することで、分析を高速化するためだけに存在していたキャッシュ、リードレプリカ、CDCパイプラインをすべて削除できるため、コストが削減されます。より大きなメリットは、どちらのシステムも単独では実行できないワークロード、つまりライブデータと履歴を一緒に分析し、同じステップで結果を記録する意思決定です。カード発行会社は、カードの過去数分間のアクティビティとアカウントの履歴と照合した後、顧客が待っている間に支払いを承認または拒否します。小売業者は、ユニットがまだ在庫にあることを確認してからのみ在庫を確保します。SingleStore を使用している米国の大手銀行は、不正検出を夜間のバッチ処理からスワイプの瞬間に変更し、現在では 1 秒の承認期間内で 50 ミリ秒で約 70 のクエリを実行しています。

ビジネスデータに基づいて行動するエージェントにも、同様の要件があります。出荷ルートを変更したり、アカウントを保留したりするエージェントは、ビジネスの現在の状態を把握する必要があり、その行動によって次のエージェントと次の顧客のためにその状態が変更されます。企業がエージェントにどの程度まで自律的な行動を許容するかはまだ未解決の問題ですが、行動するエージェントは、今日の不正チェックに必要な情報と同じものを必要とするでしょう。

OLAPとOLTP：なぜこの2つのワークロードは分割されたのか

OLTPとOLAPでは、データのレイアウト方法が正反対です。OLTPワークロードは、一度に1レコードずつ書き込みまたは更新し、キーで1行ずつ読み取り、1秒間に数千回処理します。これは、各レコードのフィールドをまとめて保持する行ストアに適しています。OLAPワークロードは、数百万行にわたって少数の列を読み取ります。これは、クエリで指定された列のみを読み取り、それらを効率的に圧縮する列ストアに適しています。回転ディスクを備えたサーバーでは、1秒間に数百回のランダム読み取りしか行えず、大規模なレポートではトランザクションが必要とするページがキャッシュから押し出され、実行中は処理速度が低下しました。そのため、企業は2つを分離しました。OLTPデータベースは記録システムを保持し、抽出、変換、ロード（ETL）ジョブまたはCDCストリームは、変更を分析のためにデータウェアハウスにコピーしました。すべての分析結果は、最後のコピーが着地した時点でのビジネスの状態を記述していました。

その分割を支えるハードウェアは変化しました。メモリは2000年代初頭に比べてギガバイトあたりの価格が桁違いに安くなり、NVMeソリッドステートドライブは毎秒数十万回のランダム読み取りを処理できるようになりました。カラム型ストレージ、ベクトル化実行、クエリコンパイルにより、誰も想定していなかった分析クエリがアプリケーション内で実行できるほど高速になりました。データベースは、同じテーブルの行と列を保持し、データの1つのコピー上で両方のワークロードを実行できるようになり、これが上記のような決定を可能にしています。OLAP、OLTP (https://www.singlestore.com/blog/understanding-olap-vs-oltp-the-key-differences/)、HTAPデータベース (https://www.singlestore.com/blog/what-is-htap/)に関するガイドでは、これらの定義についてさらに詳しく解説しています。

ワークロードにHTAPデータベースが必要な兆候

ほとんどのチームは、既に実施している回避策の中からHTAPの候補を見つけます。その中でも、繰り返し出てくるのは次の4つです。

• キャッシュまたはリードレプリカは、速度向上のためだけに存在するものです。プライマリデータベースでは読み取りと書き込みを同時に処理できないため、誰かがデータベースの前にキャッシュを配置したり、ダッシュボードをレプリカに向けたりするのです。それぞれが、記録システムから乖離する可能性のある別のコピーです。
• 企業がその遅延を注視するパイプライン。CDCの配信が遅れた際にエンジニアに連絡が入る場合、企業はすでに古いデータにコストを課していることになります。
• 製品から分析機能が削除されたこと。顧客向けの利用状況レポートは、メインのシステムで実行するとチェックアウト処理が遅くなるため、削除されるか、または昨日のデータに限定されます。
• 2つのシステム間で意見の相違が生じたこと。ウェアハウスと注文システムで報告された在庫数が異なったり、リスクレポートと取引システムで示されたエクスポージャーが異なったりしたため、担当者が午後いっぱいかけてそれらを調整。

一部のチームはさらに進んで、 2011年にネイサン・マーズが提唱した (https://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html)ラムダアーキテクチャを構築しました。これは、すべてのデータに対して正確な結果を得るためのバッチ層と、最近のデータに対して概算結果を得るためのスピード層で構成されています。このアーキテクチャは、同じ指標を計算する2つのコードパスが存在するという代償を伴いますが、常に最新の結果を提供します。ただし、どちらかのパスにバグがあると、両者の結果が一致しなくなります。

これらのワークロードとストリームプロセッサがより適切に処理できるワークロードを区別する一つの重要な質問は、データが到着する前にアプリケーションが尋ねるすべての質問をリストアップできるか、そしてそのリストはイベントが通過するたびに各回答を計算できるほど短いか、という点です。過去 5 分間のアカウントごとのログイン失敗回数をカウントするテストは、このテストに合格するため、ストリームプロセッサはカウントを最新の状態に保つことができます。しかし、今日の配送業者の遅延の影響を受けた顧客の保留中の注文を、過去 3 年間の返品データと合わせて見つけるテストは、顧客、配送業者、および時間枠の組み合わせが多すぎて事前に計算できないため、通常は合格しません。このような質問には、ライブデータに対して任意のクエリを実行できるデータベースが必要です。

製品を比較する前に、データがどのような意思決定に役立っているか、そして古い回答がもたらすコストはどれくらいかを書き出してください。結果が変わるまでにデータはどのくらい古くなっても許容されますか？クエリには、履歴と結合された最新のレコードが必要ですか？一度に何人のユーザー、サービス、エージェントが問い合わせを行うでしょうか？これらの回答に基づいて、後続のテストの合格基準が設定されます。

HTAPデータベースを選択する際にテストすべき事項

このカテゴリーのすべてのベンダーは、製品ページにHTAPを掲載しています。機能一覧を見るよりも、実際のワークロードで5つの測定を行うことで、ベンダー間の差別化を図ることができます。以下の各テストでは、HTAPが重要な理由、実行方法、結果からわかること、SingleStoreがどのように処理するかを解説し、最後に記録すべき数値を示します。レイテンシの数値は、100件のリクエストのうち99件が完了するまでの時間である99パーセンタイル（p99）を使用します。平均値では、タイムアウトする低速なリクエストが隠れてしまうためです。

コミット後、分析クエリでその行を参照できるようになるまでどのくらいの時間がかかりますか？

なぜそれが重要なのでしょうか。鮮度とは、トランザクションがコミットされてから、その影響を読み取る分析クエリが実行されるまでの間の時間差であり、その時間差内に行われるあらゆる決定は、既に古くなっているデータに基づいて行われます。ダッシュボード上のリアルタイム分析では、数秒の遅延はほとんど問題になりません。しかし、支払いを承認またはブロックするチェックの場合、同じ数秒が、チェックが前回の支払いを認識したかどうかを左右します。

テスト方法：負荷がかかった状態でエンドツーエンドの測定を行います。ピーク時の本番書き込みレート（バーストを含む）を再現し、分析クエリからタイムスタンプ付きマーカー行をポーリングします。アイドル状態のシステムでは、ほぼすべてのアーキテクチャでギャップがゼロに近くなり、データベース自体の取り込みメトリックは正常に見えるものの、クエリは古いデータを参照している場合があります。

結果からわかること。行を別の列形式のコピーに複製する設計では、複製によってギャップが生じ、不正検出や在庫管理の判断が最も活発になる書き込みバースト時にそのギャップが拡大する傾向があります。レプリカが追いつくまでの間、分析読み取りは待機状態となり、レイテンシが増加するか、古いデータが返されます。製品がどちらの動作をするか、オペレーターは遅延をどのように認識するか、再起動後にどうなるかを確認してください。

SingleStoreでは、トランザクションと分析クエリは1つのエンジンで同じテーブルを読み取るため、トランザクションがコミットされた瞬間に、その行は分析クエリから参照可能になります。レプリカがないため、書き込み量が増えてもギャップは拡大しません。ただし、負荷がかかるとクエリのレイテンシは上昇し、テスト2と3でそれを測定します。

記録: p50 と p99、ピーク時、およびピークの 2 倍の時点でのコミットからクエリまでの遅延。

分析負荷はトランザクションの速度を低下させますか？

なぜこれが重要なのでしょうか。大規模なレポートによってチェックアウトや支払い承認が遅くなる場合、通常はレポートを制限することで解決しますが、その結果、分析機能が制限されてしまいます。HTAPデータベースは、そのような選択を強いられることなく、両方のワークロードを実行する必要があります。

テスト方法：トランザクションワークロードを単独で実行し、p99レイテンシとスループットを記録します。次に、分析ワークロードを並行して実行し、両方を再度記録します。アプリケーションとアナリストが本番環境で実行するクエリ（短い選択的ルックアップだけでなく、大規模な結合やスキャンも含む）を、本番環境のデータ量と偏りを考慮して使用します。小さな合成データセットを使用することで、本番環境で発生する競合を隠蔽できます。最後に、書き込みピーク時に意図的に負荷の高いクエリを実行します。

結果が示すこと。すべてのHTAP設計は、どこかで分離性を確保するためにコストを負担しています。レプリカはスキャンが別のマシンで実行されるため、優れた分離性を実現しますが、データの鮮度と2つ目のコピーというデメリットをもたらします。シングルエンジンはハードウェアを共有するため、結果はワークロード管理に依存します。つまり、データベースがトランザクションに影響が出る前に分析クエリの処理時間を制限できるかどうかです。高負荷なクエリの開始時にトランザクションp99がジャンプするということは、制限が設定されていないか、誤って設定されていることを意味します。

SingleStoreでは、両方のワークロードが単一のエンジンで実行されるため、分離性が設計上のトレードオフとなり、テストで注意すべき点となります。リソースプールは、クエリのクラスに利用可能なメモリ、CPU、および同時実行数を制限し、ワークロード管理はリソースが不足するとクエリをキューに格納します。テスト前にこれらを構成してください。高負荷クエリを実行すると、それらが十分かどうかを確認できます。

記録：トランザクションp99とスループット、単独の場合と分析ワークロード実行時の場合。

設定したレイテンシ目標において、同時に実行できる分析クエリの数はいくつですか？

なぜそれが重要なのでしょうか。分析クエリには2種類あります。事前設定クエリは、ダッシュボードの背後にあるクエリのように、事前に作成され、スケジュールに基づいて実行されるため、データベースはマテリアライズドビューやキャッシュを使用して回答を事前に計算できます。アドホッククエリは、回答が必要になった瞬間にアナリスト、アプリケーション、またはエージェントによって作成され、誰も質問内容を事前に把握していないため、事前計算は役に立ちません。アプリケーションまたはエージェントへの1つのリクエストが多数のアドホッククエリに発展する可能性があり、チームは同時に多数のエージェントを実行するようになっているため、今日のダッシュボードの負荷だけを考慮しても、おそらく過小評価されるでしょう。

テスト方法：ダッシュボードのプリセットクエリと、テスト中に本番テーブルに対して作成したアドホッククエリの両方を同時に実行します。同時実行クエリ数を段階的に増やし、レイテンシが上昇し始めるポイントを確認します。

結果が示すこと。事前設定されたクエリのレイテンシが維持される一方で、アドホッククエリの速度が低下する場合、データベースは以前に計算した回答を提供し、それ以外のすべての情報をスキャンしている状態です。アドホッククエリが目標値を超える同時実行数は、アプリケーションとエージェントに対するシステムの実際の処理能力を示します。

SingleStoreでは、新規書き込みは行としてメモリに書き込まれ、バックグラウンドで同じテーブルの圧縮されインデックス付きの列にマージされます。インデックスとセグメントごとの統計情報により、新しいクエリはテーブル全体をスキャンするのではなく、フィルタが選択したデータスライスのみを読み取ることができるため、同時実行数が増加しても各アドホッククエリのコストを低く抑えることができます。

記録：目標とする同時実行数におけるp99分析レイテンシを、プリセットクエリとアドホッククエリそれぞれについて個別に記録し、レイテンシが上昇し始める同時実行数も記録します。

読み取り操作と、それに伴う書き込み操作は、1つのトランザクション内でコミットできますか？

なぜそれが重要なのでしょうか。多くの意思決定は、読み取りとその後の書き込みによって行われます。例えば、在庫数を数えてから1単位を予約したり、トレーダーのエクスポージャーを確認してから取引を行ったりします。読み取りと書き込みが1つのトランザクションでデータの1つの状態に対してコミットされる場合、2人の買い手が両方とも最後の1単位を予約することはできず、2つの取引がそれぞれリスクチェックを通過して、それらが合わさって違反することもできません。ダッシュボードにはこのような保証は必要ありません。読み取りを行い、その読み取りに基づいてアクションを実行するワークロードはすべてそうであり、HTAPの比較ページでは、そのようなテストが行​​われることはほとんどありません。

テスト方法：ベンダーに、フェイルオーバー時にアプリケーションが認識する内容を含め、自社の操作に基づいて保証内容を説明してもらいます。次に、その保証内容を再現します。2つのセッションが同じ合計値を読み取り、それに基づいて書き込みを行う小規模な同時実行ワークロードを作成し、データベースが本来は片方しか成功しないはずの処理で、両方のセッションが成功してしまうことがあるかどうかを確認します。競合をブロックするためにアプリケーションがどのような処理を行ったか（例えば、分離レベルの選択や、読み取った行のロックなど）を記録しておきます。

結果が示すこと。共有ストレージ上で別々のエンジンを実行する設計では、データは共有されますが、分析エンジンとトランザクションエンジンは別々のトランザクションを実行します。テスト量が少ない場合は、競合はほとんど発生しません。本番環境では、過剰販売注文、制限超過、または毎朝実行される調整ジョブとして顕在化します。

SingleStoreでは、トランザクションと分析が単一のエンジンで実行されるため、分析結果とそれに基づく更新が、単一のデータ状態に対して同時にコミットされます。リスクの確認と取引の発注、在庫のカウントと引当は、すべて1つのステップで行われます。

競合する書き込みが防止されたかどうか、また、それを防止するためにアプリケーションがどのような処理を行ったかを記録します。

アーキテクチャ全体にかかる費用は、履歴データも含めていくらですか？

なぜそれが重要なのでしょうか。インメモリHTAPシステムに対する一般的な反対意見はコストです。データがメモリ上に保持される必要がある場合、数年分の履歴でもコストがかさみ、すべてをメモリ上に保持する設計に対する反対意見は妥当です。データベースはコストの一部にすぎません。今日のスタックには、CDCパイプライン、キャッシュとレプリカ、そしてコピーを同期させるために費やされるエンジニアリング時間のコストも含まれています。

テスト方法：先週のデータと1年前のデータに対して同じクエリを実行し、レイテンシを比較します。保持するテラバイトあたりのストレージ料金を計算します。次に、HTAPデータベースで無効化できるコピーとその年間コストを一覧表示し、テスト対象のワークロードでその数値を確認します。

結果からわかること。HTAPデータベースは一部のコピーを破棄し、残りは残すため、破棄するコピーのみをカウントしてください。1年前のデータがメモリ上に存在しているため高速な場合、履歴が増えるにつれてストレージコストは増加します。古いデータが安価でも低速な場合は、移行しようとしている意思決定にそのデータが必要かどうかを確認してください。

SingleStoreでは、データは3つの階層に自動的に分散されます。新しい変更はすべてメモリに取り込まれ、コミットされた瞬間に反映されます。最近使用されたデータは、高速な分析と検索のためにローカルのNVMeドライブに保存され、完全な履歴は低コストのオブジェクトストレージに保存されます。パイプラインやアーカイブジョブによって階層間でデータが移動されることはなく、クエリはどの階層にデータがあっても同じ結果を返します。変化するのは応答コストのみです。支出はデータ量ではなくアクティビティに応じて決まります。

記録すべき項目： 1年前のデータに対するクエリのレイテンシと、先週のデータに対する同じクエリのレイテンシ、保持する1テラバイトあたりのストレージコスト、および破棄する各コピーの年間コスト。

HTAPアーキテクチャの違い

HTAPとして、あるいはその代替品として販売されている製品は、少なくとも5つの設計を採用しており、5つのテストでそれぞれ異なるスコアを示します。ベンダーがどの設計を採用しているかにかかわらず、書き込み先と、分析クエリでどのように可視化されるかを必ず確認してください。以下の各設計は、一部のワークロードには適していますが、他のワークロードでは問題が生じます。

行と列のストレージが統合された単一のエンジン。書き込みは行としてメモリに格納され、バックグラウンドで同じテーブルの圧縮された列にマージされ、両方のワークロードが単一のデータ状態に対して単一のエンジンで実行されます。ライブデータを分析し、その結果に基づいて1つのステップでアクションを実行する意思決定に適しています。両方のワークロードは同じハードウェアを共有するため、分析負荷が制御されていない場合に問題が発生し、テスト2が注目すべきテストです。SingleStoreはこの設計を採用しており、行と列のストレージの統合とストレージとコンピューティングの分離に関する特許を保有しています。この設計の詳細については、「One Copy, One Engine, No Seams」 (https://www.singlestore.com/ja-jp/blog/one-copy-one-engine-no-seams/)で詳しく説明しています。

行ストアのプライマリと列指向レプリカ。トランザクションは行ストアノードで実行され、レプリケーションによって列指向コピーが別のノードに保持されるため、スキャンによってトランザクションが遅くなることはありません。分析クエリがレプリケーションの遅延を許容できる、またはレプリケーションを待つことができるワークロードに適しています。レプリカが遅れて分析読み取りが待機するか古いデータを返す書き込みバーストや、データが二重に保存されるためコストの面で問題があります。レプリカでの読み取りがプライマリでの書き込みとトランザクションを共有できるかどうかは製品によって異なるため、テスト4を実行してください。

インメモリ列指向キャッシュを備えた行ストアデータベース。既存のOLTPデータベースの中には、選択したテーブルの列指向コピーをメモリに保持できるものがあります。既にそのようなデータベースを使用しているアプリケーションにとっては、最も安価な選択肢ですが、3つの点で問題があります。キャッシュはプライマリのメモリに収まるテーブルのみをカバーするため、履歴にアクセスするクエリは行ストアの速度で実行されます。分析スキャンはトランザクションと同じCPUを使用するため、ピーク時の重いレポートはトランザクションのレイテンシに影響します。どちらのワークロードもプライマリの容量に制限されるため、書き込み量が容量を超えると、分析も同じ制限に達します。

共有ストレージ上の別々のエンジン。トランザクションエンジンは、最近のデータを行として保持するストレージレイヤーに書き込み、それをオープンフォーマットの列ファイルに変換し、分析エンジンが直接読み取ります。パイプラインを実行する必要はなく、各エンジンは独自にスケーリングし、複数の分析ツールが同じファイルを読み取ることができます。この方式には2つの問題点があります。分析エンジンは、エンジンが読み取るフォーマットで書き込みが利用可能になったときにのみ書き込みを認識するため、ピーク時にどれくらいの時間がかかるかを調べてテスト1を実行します。トランザクションエンジンと分析エンジンは別々のトランザクションを実行するため、分析してから書き込む決定はアトミックにコミットできません。現在、一部のベンダーはこの設計をHTAPの後継として提示しており、5つのテストは両者を比較する公平な方法です。

構成型スタック。OLTPデータベースはそのまま維持されます。CDC は変更内容を Apache Iceberg テーブルにストリーミングし、その上に高速な分析エンジンをインデックスとして配置します。この方式の支持者は、構成によって HTAP を実現すると主張しており、多くのワークロードではこの主張は妥当です。各部分は個別にスケーリングでき、履歴はオブジェクト ストレージで安価に取得できます。質問が事前にわかっており、鮮度目標にパイプラインのための余裕がある場合に最適です。CDC の遅延設定による鮮度の問題や、あるエンジンから読み取って別のエンジンに書き込む決定の問題で破綻します。各エンジンが独自のコピーを保持し、両者がアトミックにコミットできないためです。この設計については、「リアルタイムと AI が従来のデータ スタックを破綻させる理由」 (https://www.singlestore.com/blog/singlestore-vs-the-classic-data-stack-why-real-time-and-ai-break-patchwork-architectures/)でさらに詳しく解説しています。

この表は、各設計を5つのテストに対応付けたものです。同一設計内でも製品によって仕様が異なるため、この表はベンダーへの問い合わせの出発点としてご利用ください。

アプリケーションのどの部分を変更する必要があるのか？

既にHTAPまたは分散SQLデータベースを運用している場合、移行コストがベンチマークよりも最終的な候補を決定づける重要な要素となる可能性があります。変更コストが安い順から高い順に、5つのレイヤーを比較検討してください。

1. ドライバと接続。候補となるドライバが、アプリケーションで既に利用しているワイヤプロトコルに対応している場合、既存のドライバと接続プールは引き続き機能します。SingleStoreはMySQLワイヤプロトコルと互換性があるため、MySQLドライバに基づいて構築されたアプリケーションは、新しいクライアントライブラリを追加することなく接続できます。
2. SQL方言。ワイヤプロトコル互換性は、すべての関数とデータ型が同じように動作することを保証するものではありません。アプリケーションの実際のクエリログを1日分、候補となるシステムに対して再生し、失敗したクエリや異なる結果を返したクエリを数えてください。そのリストが移行の見積もりとなります。ベンダーの互換性ページは、あくまでも出発点に過ぎません。
3. データレイアウト。分散データベースはデータの配置方法が異なります。テーブルを自動的に範囲に分割するものもあれば、選択したシャードキーに基づいて各テーブルを分散し、どの結合を1つのノードで実行し、どの結合をネットワーク経由で実行するかを決定するものもあります。SingleStoreはシャードキーを使用するため、範囲分割機能を持つデータベースから移行する場合は、最大のテーブルと最も重要な結合の設計に十分な時間を確保してください。
4. トランザクションの動作。データベースによって分離レベルや再試行のセマンティクスが異なるため、ある動作に合わせて書かれたコードが別の動作では静かに動作しなくなる可能性があります。競合時に再試行するコードや、自身の書き込みを読み取るコードについては特に注意深く確認してください。
5. データ移行。初期ロードと現在のシステムからのCDCストリームを計画し、切り替え前に結果を検証しながら両方を並行して実行できるようにします。コネクタが再起動時やスキーマ変更時にどのように動作するかをテストし、切り替えが失敗した場合に備えて復旧手段を確保しておきます。

ドライバの互換性だけではクエリプランはほとんど分かりません。誰かがクエリを調整したり書き換えたりする前に、移行後のクエリに対してそのままのパフォーマンス テストを実行してください。そうしないと、概念実証が書き換え後の処理を測定することになってしまいます。また、各変更を担当するチームも明記してください。担当者がいない移行は、最初の書き換え段階で停滞する傾向があります。

あなたのチームはそれを運用し、安全に管理できるか？

あらゆるパフォーマンス テストに合格したデータベースでも、運用を担当するチームにとっては問題となる可能性があります。運用担当者がデータ取り込みの遅延をどのように認識し、障害をどのように診断するかを確認し、本番稼働前に復旧手順をリハーサルしてください。マネージド デプロイメントとセルフ マネージド デプロイメントでは、この作業の分担方法が異なるため、人員配置と必要な制御レベルに合わせて比較検討してください。SingleStore は、マネージド サービス SingleStore Helios として、またはお客様独自の環境でセルフ マネージドとして実行できます。

セキュリティも同様の評価項目に含まれます。マネージドデータベースはベンダーのインフラストラクチャとプロセスに基づいて稼働するため、ベンダーの運用慣行は貴社のリスクの一部となります。以下の質問に対する監査レポートやテスト結果などの証拠を求めてください。SingleStore Heliosが質問にどのように回答しているかについては、該当箇所へのリンクを掲載しています。

1. コンプライアンス レポートは何をカバーし、何を除外していますか?監査レポートは、特定の期間の特定のシステムを対象としています。どのシステムが対象だったのかを尋ねてください。SingleStore Helios:企業が常に最初に尋ねるコンプライアンスに関する質問 (https://www.singlestore.com/blog/cloud-database-compliance-certifications/)。
2. アクセスはIDプロバイダー経由で実行できますか？シングルサインオン（SSO）とSCIMプロビジョニングでは、ユーザーがディレクトリから離れるとデータベースへのアクセス権が失われます。多要素認証（MFA）も適用されているかどうかを確認してください。SingleStore Helios：エンタープライズIDを、お客様のニーズに合わせて (https://www.singlestore.com/blog/enterprise-database-sso-scim-identity-integration/)。
3. ネットワークアクセスはどのように制限されていますか？ベンダーのスタッフによるアクセスも含めて。プライベート接続について、またエンジニアの本番環境へのアクセスがどのように承認され、ログに記録されるかについて質問してください。SingleStore Helios:ゼロトラストはチェックボックスではありません (https://www.singlestore.com/blog/zero-trust-isnt-a-checkbox/)。
4. 暗号化キーは誰が管理するのでしょうか？自分でキーを管理できるかどうか、またキーを失効させた場合にデータとサービスに何が起こるのかを確認してください。SingleStore Helios:暗号化制御のスペクトル (https://www.singlestore.com/blog/customer-managed-encryption-keys-cloud-database-cmek/)。
5. ベンダーはデータベース以外に、あなたの情報をどのような形で保存しているのでしょうか？コンソール、サポートチケット、診断ログには、クエリテキスト、スキーマ名、接続の詳細などが保存されている可能性があり、管理APIキーからクラスターにアクセスできる場合もあります。保存されている情報とその保存期間、閲覧権限を持つユーザー、キーのスコープ設定とローテーションについて確認しましょう。
6. リカバリポイントとリカバリ時間の目標は何ですか？また、最後にテストされたのはいつですか？誰もテストしていない目標は、単なるターゲットにすぎません。SingleStore Helios:何かがうまくいかなかった場合、何が起こるか (https://www.singlestore.com/blog/cloud-database-disaster-recovery-rpo-rto/)。
7. どの責任があなたに残り、ベンダーはどのようにしてインシデントについてあなたに通知するのでしょうか？通知の約束を、期間を含めて書面で入手してください。SingleStore Helios:責任の共有がリスク移転にならない理由 (https://www.singlestore.com/blog/cloud-database-shared-responsibility-model/)。
8. ベンダーのリリースプロセスにセキュリティはどのように組み込まれていますか？依存関係がどのようにスキャンされ、既知の脆弱性がどれくらいの速さでパッチされるのかを尋ねてください。SingleStore Helios：セキュリティ機能だけでなく、セキュリティエンジニアリングも (https://www.singlestore.com/blog/cloud-database-security-engineering-sdlc/)。

認証はシステムの安全性を証明するものではありません。認証は、監査人がどの制御項目をどのくらいの期間にわたってテストしたかを示すものであり、残りの部分は上記の質問で網羅されます。

概念実証でこれらのテストを実行する方法

ベンダーベンチマークは、ベンダーのワークロードをベンダーのスキーマ上で実行します。概念実証は、最初のテスト実行前に合意された合格基準値に対して、ワークロードを最悪の状態で実行することで、より多くの情報を提供します。

1. 偏ったキーと最大のテーブルを含め、本番データの代表的な部分を読み込みます。
2. 本番書き込み速度をピーク時と、その2倍のピーク時にそれぞれ再現してください。
3. ダッシュボードのプリセットクエリとアドホッククエリを、目標とする同時実行数で同時に実行してください。
4. 上記のテスト結果から5つの数字を記録してください。
5. ピーク負荷時にノードを停止させ、データ取り込みコネクタを遮断します。復旧にかかる時間と、復旧中にデータの鮮度が維持されるかどうかを記録します。
6. バックアップを新しい環境に復元し、復旧目標時間と比較して所要時間を計測します。

既存のアーキテクチャに対しても同じテストを実行してください。調整済みの既存スタックが目標値を満たす場合もあり、概念実証でそれを証明できるはずです。各候補に必要な構成と調整内容を記録しておきましょう。調整に数週間を要した後にようやく結果が出た場合、そのコストが本番環境に持ち込まれることになるからです。

概念実証には数週間のエンジニアリング時間が必要となるため、最も重要な答えが得られる作業範囲に絞って実施すべきです。

HTAPデータベースが不適切な選択である場合

HTAPデータベースは、ある一つの問題をうまく解決します。それは、トランザクションが次々と到着する中で、ビジネスの現状を把握した上で、任意のクエリを実行する必要がある意思決定です。しかし、多くのワークロードには、そのような問題は存在しません。

ペタバイト規模の膨大な履歴データのスキャン。モデルのトレーニングや大規模なデータウェアハウス変換では、誰も変更していない大量のデータが読み込まれます。データウェアハウスやレイクハウスを使えば、もっと安価に処理できます。

質問は事前に分かっており、数分の許容範囲がある。データが到着する前にすべての質問をリストアップでき、5分間の遅延がコストにならない場合は、データウェアハウスまたはストリームプロセッサへのCDC（データセンター）処理がより簡単になります。

分析負荷のないOLTPデータベース。1つのデータベースでトランザクションを問題なく処理でき、ライブデータに対する分析が必要ない場合、2つ目のシステムを導入しても作業が増えるだけです。

共有オーナーがいない。通常、トランザクションデータベースは製品エンジニアリングチームが所有し、分析はデータチームが所有します。ワークロードをHTAPデータベースに移行するには、どちらのチームが運用するかについて合意する必要があり、その話し合いには技術的な評価よりも時間がかかる場合があります。

1つのワークロードにHTAPを選択した場合でも、アーキテクチャの残りの部分はそのまま維持されます。記録システムは帳簿を管理し、レイクハウスは長期履歴を保持し、HTAPデータベースはリアルタイムの応答を必要とするワークロードを処理します。

どこから始めればいいのか

遅延や矛盾した回答による損失が最も明確なワークロードから始めましょう。例えば、資金移動後に発覚する不正行為や、二重売買された株式などが挙げられます。これらの失敗が1件発生した場合のコストと発生頻度を書き留めてください。次に、そのワークロードに対して5つのテストを実行し、2つ目のテストに進む前に、得られた証拠に基づいて判断を下してください。既に運用しているデータベースを置き換える場合は、移行チェックとセキュリティに関する質問を同じ評価に含めてください。どちらか一方だけでも結果が確定する可能性があるためです。

SingleStoreが候補に入っている場合は、無料トライアルを開始する (https://portal.singlestore.com/intention/cloud#UA.utm_ref=%2Fblog%2Fhow-to-choose-an-htap-database-a-complete-guide%2F)か、概念実証の範囲設定について弊社にご相談ください。