Zendeskは、DynamoDBからMySQLとS3を使用した階層型ストレージソリューションに移行することで、データストレージのコストを80%以上削減した。同社は様々なストレージ技術を検討したが、コストを抑えつつ、クエリ性とスケーラビリティのバランスを取るために、リレーショナルデータベースとオブジェクトストアを組み合わせることにした。
Zendeskは、ストレージにDynamoDBを使用して、イベントストリームデータの永続化ソリューションを作成した。初期の設計はうまくいっていたが、ソリューションの運用コストがどんどん高くなっていった。チームはプロビジョニング課金モデルに切り替え、コストを50％削減したが、顧客ベースの拡大と新しいクエリパターンをサポートするためのグローバルセカンダリインデックス（GSI）の必要性に伴い、アーキテクチャの運用コストは維持できなくなった。
DynamoDBを使用した初期のアーキテクチャ（出典：Zendesk Engineering Blog）
ZendeskはAWS上でプラットフォームを運用しているため、チームはコストを削減しながら機能的・技術的要件を満たせる代替ストレージソリューションを探していた。S3、Hudi（Zendeskで使用されているデータレイク）、ElasticSearch、MySQLを検討したが、Hudiはその複雑さと24時間の遅延が発生するため、ElasticSearchはDynamoDBを使用するのと同様のコストのため、採用を見送った。最終的にチームは、Apache Kafkaからのログのバッファリングとメタデータの保存にMySQLを使用し、1ファイルあたり10,000のバッチで生データを保存するためにS3の使用を決定した。
インジェストフローでは、Kafkaから消費されたログデータをMySQLのバッファテーブルに格納する。1時間ごとに、バックグラウンドジョブがバッファテーブルからS3に1ファイルあたり1万ログのバッチで新しいレコードをアップロードし、S3ファイルごとにメタデータレコードを挿入する。別の毎時ジョブは、バッファテーブルから4時間以上前のログを削除する。
MySQL（AuroraDB）とS3を使用した新しいアーキテクチャ（出典：Zendesk Engineering Blog）
クエリを処理するために、新しいソリューションでは、MySQLのメタデータテーブルをルックアップし、ルックアップによって返されたファイルに対してS3-Selectクエリを並行して実行する必要がある。データレイアウトは時系列検索に最適化されているため、チームはより複雑なクエリを実行する際に問題を経験した。
Zendeskの技術開発部門の責任者であるShane Hender氏は、新しいアーキテクチャにおける柔軟なクエリの課題についてこのように説明している。
一通り動作させた後、クライアントがタイムスタンプ以外のフィールドで結果をフィルタリングしたい場合、パフォーマンスの問題が発生しました。例えば、クライアントが特定のユーザーIDのログが欲しい時、最悪の場合、関連するログを見つけるために、時間範囲内の全てのS3データをスキャンしなければなりません。
エンジニアは、より多くのフィルタリング可能なフィールドを扱うために、S3でデータを複製することを検討したが、フィールドの組み合わせの数を考えると、このアプローチは実現不可能だった。最終的に、彼らはブルーム・フィルターに注目し、さらにCount-Min Sketchデータ構造と組み合わせることで、マルチフィールド・フィルタークエリーをサポートする効果的な方法を提供した。改善されたソリューションでは、クエリするS3ファイルを決定するために使用されるシリアライズされたデータ構造を格納する追加のテーブルが必要になった。
移行後、ZendeskはストレージコストをDynamoDBのプロビジョニングコストの20%未満に削減し、MySQL (AuroraDB)が90%以上、S3とS3-Selectが10%未満を占めるようになった。新しいソリューションのクエリレイテンシは約200-500ミリ秒だが、数秒に及ぶものもあり、チームはさらなる最適化を目指している。