何がしたかったのか

NewsPicksでは、AWSのRedshiftを用いて、アクセスログやユーザーの行動ログの蓄積と解析を行っています。
解析の結果は、マーケティングの指標や機械学習などに利用されています。

これらのログですが、生データは、RDSやnginxにあるので、それらを加工して、Redshiftに流すスクリプトがありました。
このデータ移送スクリプトをAWS Glueを用いた新しいスクリプトでリプレースすることになりました。

どんな課題があったのか

ほぼほぼ完成して後はリリースのみ、となったときにテストをどうしようかという問題が発生しました。
今回のケースは元々あったスクリプトの置換なので、旧移行ツールと新移行ツールに等価のインプットを入れて等価のアウトプットが得られれば、検証としてはOKです。
しかし、過去全てのデータでこれを行うとデータ量が膨大すぎるという問題がありました。

400万ダウンロードのアプリでユーザーのアプリ上での行動ごとにログを取っているので、たとえ1日分であっても億件オーダーのデータがあります。
過去分全てのデータを逐一突合するのは、リソースの面から言って現実的ではありませんでした。

どう解決したのか

今回扱うデータは主にアクセスログで、マーケティングだったり、機能の利用実態を調べたり、機械学習に用いたりといった用途で利用されていました。
それらは業務データや顧客データのように、100%厳密性を求められるわけではありません。

データ利用者に説明できる精度でバグがないことを証明すれば、今回の用途では十分です。
そのため、サンプリング調査の考え方を応用して、一体何件のサンプルを突合させれば一定の精度でバグがないことを証明できるか計算することにしました。

ここでは、とりあえずわかりやすく100件に1件のバグを99%の確率で検出できる試行回数を計算してみます。

中学数学の確率のくじ引きで、「n回くじを引いて、少なくとも1回あたり出る確率」という計算と同じように計算できます。
例えば、1%の確率で当たるくじを5回引いて、1回でも当たる確率は 100% から5回連続で外れる確率を引けば求められます。

1 - (1 - 0.01)^5 ですね。

ここでは、x回引いて、99%の確率で少なくとも1回当たりを引けばいいので、以下の不等式で表すことができます。

1 - ( 1 - 0.01)^x > 0.99

(厳密に言うと1回引いたくじを箱に戻す場合とそうでない場合で計算が異なるのですが、今回は億件オーダーのデータが母体なので、同じくじを2回以上引いてしまう事象については無視しています。)

上記の指数不等式の解を求めれば、99%の確率で1%のバグを検出できる試行回数が分かります。
ここでは、459回が99%の確率で1%の混入したバグを検出できる最小の試行回数でした。

(ちなみに、確率の計算の構造としては、ガチャでx%の排出率キャラクターをn回試行すると、少なくとも1回引く確率を計算するのと同じなので、計算がめんどくさい人はネット上に公開されているガチャ排出確率計算ツールで同様の計算できたりします。)

実際には、もう少し色々計算して、テストに利用できるリソース量と、ビジネス的に許容できる精度を鑑みて、件数を決定し、テストを行い、無事データ移送基盤のリプレースを終えることができました。

終わってみて思ったこと

実際にやってみて、サンプリングはうまく利用できれば、とても力強いツールになりうるなと思いました。
中学校の数学程度の知識であっても、現実にうまく応用すればきちんと課題を解決できるんだと言うことがわかったことは大きな収穫でした。
サンプリングの力は凄まじく、1万分の1程度の確率のエラー（1億件のうち1万件が間違っている程度）を99%の確率で発見するにも5万件弱の試行回数があれば足ります。

私も、今までのエンジニア生活で、ビジネス的にそこまでは必要はないのに、完璧を求めすぎて、そのことが逆に負担になっている現場をよく目にしてきました。
今回のように、確率によって品質を定量化することで、少ない検証コストで、一定以上の品質が保証できるので、余ったリソースを他のことに利用できるのはとても有意義なことだと思います。

また、こう言った一定の割り切りを含む定量化を試みた時に、話が通じる環境とそうでない環境があると思うのですが、(例 : 何がなんでもバグは絶対に0件じゃないと許さない、等) 弊社では、先日のチームのランチ会でも、みんなで数学をきちんと勉強したいねーと言う話が出ており、そういった環境で仕事ができているのもとても幸せなことだと感じています。

最後まで読んでいただきありがとうございました。
今回の記事が読んでくださった方の何かの参考になれば幸いです！