はじめに
こんにちは。マイクロアドでサーバサイドエンジニアをしているカマタです。主に MicroAd COMPASS*1 の開発をしています。
この記事では、レポートデータの整合性を保つために COMPASS レポートシステムで行われた改善について説明します。
改善前
広告のインプレッション数、クリック数、リクエスト数などに関するレポートは COMPASS 管理画面のレポート画面で表示されるだけではなく、仕様に従ってこれらのレポートをメディアおよび DSP パートナーごとの仕様に合わせて共有されています。このレポートデータはアプリケーションからサーバーに出力されたデータから集計されています。
データはサーバーから CDH*2 に転送されていきます。ただし、転送中にミドルウェアの問題が発生してデータが失われることがあります。データ欠損の起こる主な要因は以下になりますが、これらに限定されるものではありません。
- データ取り込みツールの不具合または利用者の操作ミスや誤解
- アプリケーションサーバーが追加される
- メモリ不調でサーバーが自動再起動される
データ欠損障害は可能な限りタイムリーに対応されますが、データ欠損の有無に関わらず、CDH のデータを集計する後続バッチがあります。
データ欠損している状態でバッチが処理されると、乖離があるレポートデータとなります。この問題は、レポートをできるだけ早く管理画面に表示したいという要望と、発生頻度、開発リソース不足のため、これまで対処されてきませんでした。
2022年6月末までは、COMPASS レポートシステムはおおよそ次の画像のようになっていました。
図にあるように、データの整合性を監視またはチェックするためのさまざまなバッチがあります。
- データ転送完了の監視バッチ
- 1時間ごとのサーバーごとのデータ数とCDHのデータ数の比較
- MySQL レポート DB と CDH のデイリーのデータ数/金額の比較
最初の2つのバッチは、正常終了したことを示すために S3 バケットに空のファイル（S3 ファイル）を生成します。しかし、これらのファイルを後続バッチ（集計バッチ、レポートデータ生成バッチ）がチェックしていませんでした。その為、データ欠損したまま実行され、その結果、COMPASS 管理画面のレポート画面に乖離したレポートが表示されます。
データのリカバリは次の手順で行われます
- データの再転送
- raw 変換バッチの手動再実行
- 集計バッチの手動再実行
この手順では、エンジニアの時間が無駄に浪費してしまっていました。
改善後
データ欠損したまま集計されないようにするために、既存のデータ整合性チェックバッチを利用することにしました。
バッチ実行後に S3 ファイルを生成、後続バッチはその S3 ファイルが生成されるまで待機することで、実行タイミングを調整します。
これにより、1時間ごとのデータ数比較バッチによってファイルが生成されるまで、集計バッチが待機します。
集計バッチが MySQLのレポートデータを正常に更新した後に S3 ファイルを生成します。
これにより、1日分のデータ集計が完了している場合のみ、デイリーのデータ数/金額の比較バッチが実行されます。バッチは S3 ファイルを生成して、 許容される精度のデータであることを保証します。
レポートデータ生成バッチは、データ整合性チェックバッチの S3 ファイルが存在する場合のみ実行されます。
改善後は次の図のようになります。
システムの変更点は下記通りになります。
毎時の集計バッチ
- wait する S3 ファイルを「raw 変換バッチ」から「毎時 raw と CDH データ件数比較バッチ」に変更
- 完了後 S3 ファイル作成を追加
毎日 実績妥当性チェックバッチ
- 毎時 集計バッチの S3 ファイル wait（前日24時間分）を追加
- 完了後 S3 ファイル作成を追加
毎日 外部連携レポートバッチ
- 毎日 実績妥当性チェックバッチの S3 ファイル wait を追加
改善によるもうひとつのメリットは、リカバリ時にバッチを手動で再実行する必要がなくなることです。もちろん、データ欠損によりバッチが待機を続けた場合はアラートが送信されます。
終わりに
ただし、これらは一時的な解決策にすぎません。データ欠損自体の発生率を下げる方法も検討が必要です。新しいデータ転送の方法に置き換える話が進行中で、こちらに進展があれば担当者が説明してくれると思います。
