every Tech Blog

株式会社エブリーのTech Blogです。

『DELISH KITCHEN』のA/Bテスト基盤を構築しました

f:id:nanakookada:20211008171022p:plain

はじめに

こんにちは。株式会社エブリーでデータサイエンティストをしている伊藤です。

『DELISH KITCHEN』では、サービスをより良くするため、新機能の開発や既存機能・デザインの改善など様々な施策が行われています。 これらの施策は、一部のユーザのみを対象とする「A/Bテスト」によってオンライン評価され、その効果が認められてからユーザ全体にリリースされます。

直近、A/Bテストの信頼性・アジリティをより高めるため、データチームが主導となり新しくA/Bテスト基盤を構築・導入しました。 本記事では、新しく導入したA/Bテスト基盤の概観を紹介させていただきます。

今回紹介するA/Bテスト基盤の活用については、少し前の記事でも紹介していただいているので、そちらも是非合わせてご覧ください。

tech.every.tv

これまでの課題

これまで、A/Bテストは各運営チームが主導となって実施されてきましたが、改めて運用体制を見直すといくつかの課題点がありました。

ここでは特に

  • ユーザグループの選び方
  • 評価指標設定と結果の解釈プロセス

の2つに関して詳しく解説します。

ユーザグループの選び方

A/Bテストは Randomized Controlled Trial (RCT) とも呼ばれ、何らかの変化(介入)がユーザにもたらす因果効果を評価するための分析手法です。 具体的には、ランダムなユーザの割り当てによって2つの同質なグループを用意し、その片方のグループ(テスト群)にのみ介入を加え変化を計測します。

2つのグループが介入の有無を除き同質ならば、計測された変化をそのまま介入による効果として扱えますが、注目する介入以外の影響が混入している場合計測された変化にはバイアスがかかり、正確な因果効果が評価できません。 従って、A/Bテストではいかにランダム性の高いユーザ選定を行うかが重要になります。

これまで『DELISH KITCHEN』で実施されていたA/Bテストでは、アプリユーザにランダムに付与されるユーザIDを利用し、その末尾の数字を元に割り当てグループが決められていました。 この方式は、ランダムなユーザIDを元にグループを分けており、また「末尾1のユーザはテスト群にする」など集計時にSQLで表現しやすいというメリットもあるため、一見すると有効な方法だと思えます。

しかしながら、この方式は割り当ての粒度が粗く、運用する上で

  1. 同時に実施される別の施策と割り当ての重複が発生しやすい
  2. 割り当て対象は施策の担当者が決定する場合が多く、選ばれる番号に偏りが生じやすい

といった状況が発生します。

1つ目の状況では、関係のない施策の効果が本来計測したい介入効果のバイアスとなるため、正確な評価が難しくなります。 また、これを回避するために関係者間での調整が発生するため、アジリティの低下に繋がる可能性があります。

2つ目の状況では、過去に実施した施策の影響(キャリーオーバー効果)が特に問題となります。 特定のユーザグループに何度も介入を続けると、そのグループは複数の介入効果を含んだ性質を持つため、一度も介入を受けていないグループとの差分が単一の施策によるものであるという保証が難しくなります。

以上から、よりランダム性の高いユーザ選定を実施するためには、ユーザID末尾を用いない方式が必要だと考えられます。

評価指標設定と結果の解釈

A/Bテストでは、CVRや機能利用回数といったビジネス目標・ユーザ体験を表す評価指標を複数設定し、コントロール群・テスト群の差分から結果を評価します。

そのため、適切な意思決定を行うためには

  • 評価指標が正しく定義され、かつ継続的に正しさが担保されている
  • 結果を解釈・評価するプロセスが整備されている

の2点が重要となります。

『DELISH KITCHEN』ではデータ分析のためのBIツールにRedash1を採用しており、誰でもSQLを書いてログの分析やダッシュボード作成が可能な環境が整備されています。

A/Bテストについても、担当者それぞれがRedashを使って評価指標設定と結果の解釈を行っていましたが、それ故に

  • 評価指標集計のために書かれたクエリが散逸しており、統一的に管理されていない
  • 結果の解釈の仕方が担当者それぞれの方法に依存してしまっている

といった課題も生じていました。

従って、より信頼性の高いA/Bテストの運用体制を実現するためには、これらのプロセス整備も必要だと考えられます。

A/Bテスト基盤方針

要件整理

以上挙げた課題をふまえて、まずA/Bテスト基盤の要件を整理したいと思います。

2017年にMicrosoftから発表された論文では、A/Bテスト環境の成長過程を表現したExperimentation Maturity Modelsが提案されています2

このモデルでは、1つ1つのA/Bテストが単発的に実施される段階から、数多くのA/Bテストが絶え間なく実施される段階までを、Crawl、Walk、Run、Flyの4段階に分類しています。

A/Bテスト基盤での技術的な観点に注目すると、A/Bテストをより効果的かつ効率的に実施するためには、以下のような仕組みが必要であるとわかります。

  • 適切な割り当てグループの作成(検定力分析、A/Aテスト、キャリーオーバー効果の制御)
  • ユーザ体験への悪影響の最小化(アラートシステム、A/Bテストの自動停止、イテレーションの効率化、介入の相互作用の制御と検知)
  • A/Bテストの実施履歴の保存

全体像

Experimentation Maturity Modelsで示されていた技術要件全てをいきなり実現するのは難しいですが、これまでの課題と照らし合わせ、最初の取り組みとして新しいA/Bテスト基盤では次の内容に取り組みました。

  • 評価指標を管理するための評価指標ライブラリの作成
  • 他の施策の影響が含まれないランダムなコントロール群・テスト群の割り当て方式の整備
  • 統計的手法に基づく考察と意思決定が可能なダッシュボードの作成

f:id:sbrf:20211006162342p:plain
A/Bテスト基盤全体像

以下では、これら3つのより詳細な内容について紹介したいと思います。

A/Bテスト基盤内容

評価指標を管理するための評価指標ライブラリの作成

評価指標ライブラリでは、A/Bテストに使われる様々な評価指標の登録と管理を行います。

ひとくちに評価指標といっても、その集計プロセスは

  • イベントデータの組み合わせ方といった大枠の集計フロー
  • 集計軸や期間・アプリバージョンなどの集計条件

の2つの要素に分解できます。

例として「アクティブユーザ数」を挙げてみます。 大枠の集計フローは、評価指標自体の性質から「アクセステーブルに記録されたユーザ数」となります。 集計軸や集計条件はユースケースにより変化し、

  • ユーザ全体について日別で集計する場合 (DAU) は、集計軸を日付に設定
  • あるA/Bテスト実施期間内のアクティブユーザ数を集計する場合は、集計軸に割り当てられるユーザグループ、集計条件にA/Bテスト対象のユーザや実施期間、対象となるOSなどを設定

というような流れになります。

従って、評価指標を扱う上では、評価指標それぞれに対して大枠のフローを定義し、それに追加条件を付与する形で集計クエリを操作できると、運用上使いやすくなると考えられます。

エブリーのデータ基盤はLakehouseプラットフォーム3を採用しており、イベントデータのETL処理は一通りSparkSQLで記述してDatabricks4上で実行可能です。 このプラットフォームを活用し、SparkSQL形式で評価指標を登録でき、用途に応じてDatabricksから集計軸などのパラメータを与えてクエリを呼び出せるような、評価指標ライブラリを構築しました。

f:id:sbrf:20211006162526p:plain
評価指標集計の流れ

評価指標ライブラリは

  1. PythonによるSparkSQLクエリの発行
  2. 集計される統計量に応じた評価指標の分類
  3. 分類ごとに使用される統計手法(サンプルサイズ計算・仮説検定など)と可視化方式の管理

の3つの機能を持ちます。

1つ目の「PythonによるSparkSQLクエリの発行」は上で述べたような流れを実現する機能で、登録されている評価指標に必要なパラメータを渡すとSparkSQLクエリが文字列として発行されます。

2つ目の「集計される統計量に応じた評価指標の分類」、 3つ目の「分類ごとに使用される統計手法(サンプルサイズ計算・仮説検定など)と可視化方式の管理」は、登録される評価指標をユースケース別に管理するために用意した機能です。 例えば「アクティブユーザ数」は単純にユーザ数をカウントする評価指標ですが、「1人あたりの検索回数」の場合は検索が実行された回数をユーザごとに集計した値の平均値が統計量となります。 集計される統計量が変わると統計処理や可視化の方式も変わるため、これらを対応づけた状態で整理しておくと、他のチームメンバーも統一した形で評価指標を発行・利用できます。

以上のような評価指標ライブラリを活用し、A/Bテスト基盤では評価指標を集約的に管理された状態で運用しています。

他の施策の影響を取り除くランダムなコントロール群・テスト群の割り当て方式の整備

前述のように、A/Bテストではランダムなグループ選定によって同質なコントロール群・テスト群を用意する必要があります。 また、介入による変化で思わぬ悪影響が発生した場合にその影響を最小限に留めるため、割り当てグループは必要十分なユーザ規模であることが望ましいです。

これらを実現するため、新しいABテスト基盤では

  1. サンプルサイズ計算
  2. ランダムサンプリング
  3. A/Aテスト

の3段階による割り当てプロセスを構築しました。

本記事では、特に2つ目の「ランダムサンプリング」について紹介します。

ランダムサンプリング

ランダムサンプリングでは、計算されたサンプルサイズを元にユーザをランダムに選定し、コントロール群とテスト群を用意します。

ここで注意すべきは、「同時期に実施されているA/Bテスト」と「過去に実施されたA/Bテスト」の両方の影響を受けないようなグループでなければならない、という点です。

これを満たすような割り当て方式として、今年の3月にSpotifyのテックブログで紹介されていたBucket Reuse方式が目に留まり、エブリーでも実現可能だと判断できたため採用してみました。 ここでは大まかな方針を紹介に留めるため、詳細はSpotifyのテックブログをご覧ください。

engineering.atspotify.com

Bucket Reuseでは、何人かのユーザがランダムに所属するバケットというグループ単位を定義します。 ユーザの所属バケットは、アプリのユーザIDをハッシュ化し10進数に変換したものを、バケットの総数Nで割った余りによって算出され、サンプリングもバケットを最小単位として行います。 例えば、バケットあたりのユーザ数が7人だった場合、サンプルサイズ40人のA/Bテストでは6バケット(42人)をサンプリングします。

ここまではユーザID末尾をより拡張したグルーピングと考えられますが、Bucket Reuseの肝はA/BテストをNonexclusive experiments(非排他実験)とExclusive Experiments(排他実験)の2種類に分類し、それぞれに応じたサンプリング方式を選択する点にあります。

非排他実験は、割り当てられたユーザ(バケット)が別のA/Bテストにも同時に割り当て可能なA/Bテストで、サンプリングは他の実験を意識せずバケット全体から実施されます。 つまり、非排他実験に割り当てられたユーザは、並行して実施されている他の実験にも同時に属する可能性があります。

f:id:sbrf:20211006162606p:plain
非排他実験サンプリング例

例えば、「バナーのデザインを変更するA/Bテスト」の実施中に、「ボタンのアイコンを変更するA/Bテスト」を非排他実験として開始したいとすると、割り当て対象のユーザは全体からランダムに選ばれるため、すでに実施中の「バナーA/Bテスト」に割り当てられているユーザの一部は、これから開始する「ボタンA/Bテスト」にも割り当てられる、という状況になります。

一見すると、複数の実験に割り当てられたユーザが存在すると、測定される介入効果にバイアスが含まれるように感じます。 しかし、バケットは全体からランダムにサンプリングされているため、コントロール群・テスト群それぞれに他の実験のバケットが混ざる確率は同等になり、結果としてそれぞれの平均の差を測定する上では、他の実験によるバイアスが抑制されるとみなせます(より厳密には、このサンプリング方式の元で、測定された平均の差による推定量はATEの不偏推定量になるとBucket Reuse記事内の論文で証明されています)。

一方排他実験は、互いに割り当てユーザ(バケット)の重複が発生しないようなA/Bテストを指し、同時期に実施されている他の排他実験を除いた上でサンプリングを行います。 つまり、排他実験と非排他実験のバケットは重複する可能性がありますが、排他実験同士は重複がないような割り当てとなります。

f:id:sbrf:20211006162637p:plain
排他実験サンプリング例

排他実験は、検索画面などの介入の影響が大きい配信面でのA/Bテストで特に重要となります。 例えば、「検索画面のレシピの表示方法を変更するA/Bテスト」の実施中に、「検索結果のソートアルゴリズムを変更するA/Bテスト」を開始したいとします。 これらは検索体験に強く関わる介入であるため、同時に両方の介入を受けたユーザは検索体験が大きく変化してしまうおそれがあります。 従って、この2つのA/Bテストは排他実験に分類し、ユーザは多くともいずれか一方にしか割り当てられないように設定するのが望ましい状態となります。

非排他実験とは異なり、排他実験のサンプリング方式の元で算出された介入効果(平均の差)は、過去に実施された排他実験によって均質にサンプリングされず、バイアスが生じます。 しかしながら、前回の割り当てから十分な空白期間(必要な期間の計算方法も論文中で記載されています)があれば、そのバイアスは緩和可能であると示されており、運用上の工夫で対処可能であると考えられます。

以上紹介したようなBucket Reuse方式による割り当てによって、「同時期に実施されているA/Bテスト」と「過去に実施されたA/Bテスト」による影響の少ない効果測定が可能になりました。

統計的手法に基づく考察と意思決定が可能なダッシュボードの作成

A/Bテストでは、ユーザの確率的な行動によりコントロール群とテスト群との間に多かれ少なかれ差分が出るため、施策の影響が全く無かったとしても差分がゼロになるのは極めて稀です。 このような結果の解釈では、適切な意思決定へ繋げるために「得られている差分が本当に意味のある差分なのか」を慎重に吟味する必要があります。

新しいA/Bテスト基盤では、適切な解釈プロセスを統一化された形で実現するため、統計的仮説検定などの検証手法を組み込んだダッシュボードをRedashで提供し、結果のレポーティングを実施しています。

ダッシュボードでは

  • コントロール群・テスト群それぞれのサンプルサイズと結果
  • 差分の統計的仮説検定と有意な結果のハイライト
  • 差分の信頼区間

を表形式で可視化しています。

f:id:sbrf:20211006162659p:plain
ダッシュボード例

可視化処理は、直接Redash上で記述すると管理が難しくなるため、社内向けのPythonライブラリにまとめてRedashサーバにデプロイしておき、Pythonデータソースからimportして使用できるようにしました。

実際の運用では、このダッシュボードを使いながら、運営チームとA/Bテストの結果を確認しつつ「事前に設定していた見込みの効果量と比較して意味ある差分が得られているか」「なぜこのような結果になったのか」といった部分を中心に議論を行っています。

現状と今後の展望

本記事では、新しく導入したA/Bテスト基盤の概観を紹介させていただきました。

導入にあたっては、所属するデータチームのメンバーをはじめ、バックエンド開発チームやクライアント開発チーム、プロダクトマネジャーの方々に多々ご協力をいただきました。

はじめに述べたように、これまでは

  • ユーザグループの選び方
  • 評価指標設定と結果の解釈プロセス

といった課題がありましたが、今回の取り組みを通して

  • Bucket Reuse方式による他の施策の影響が抑制されるユーザ選定
  • 評価指標ライブラリによる評価指標の管理と統計的手法を組み込んだダッシュボードを用いた結果の考察

が実現でき、以上の課題は一定以上解消できたと思います。

もちろん、A/Bテスト基盤としてはこれで完成ではなく、より信頼性・安全性の高いA/Bテストが絶え間なく実行可能なRun, Flyフェーズに向けて継続的に改善を続けていきたいと考えています。

お読みいただき、ありがとうございました。

参考文献

最後に、A/Bテスト基盤を作成する上で参考になった書籍・記事をいくつか紹介したいと思います。

  • Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing5
    • A/Bテストを通じたサービス改善の文化から具体的な方法までが一通りまとめられている書籍です。 Experimentation Maturity Modelsなども紹介されており、A/Bテスト基盤の構想はこの本を足掛かりとして進めました。 最近は邦訳版も出版されています。
  • Spotify's New Experimentation Platform (Part 1, Part 2)
    • SpotifyがA/Bテストをどのように運用しているかが紹介されています。評価指標ライブラリの設計やダッシュボードの設計で参考になりました。
  • Spotify's New Experimentation Coordination Strategy
    • 同じくSpotifyの記事で、ユーザ割り当てのBucket Reuseが紹介されています。
  • Reimagining Experimentation Analysis at Netflix
    • NetflixのA/Bテスト分析基盤について紹介されており、評価指標ライブラリの設計で参考になりました。
  • サンプルサイズの決め方6
    • サンプルサイズの計算方法について、基礎的な部分から体系的にまとめられており、勉強のための良い参考書でした。
  • 効果検証入門7
    • A/Bテスト (RCT) とは何か、A/Bテストが実施できない状況ではどのような分析があるのか、などが具体例を通じて紹介されており、実際に施策を進めていく中で活用しやすい書籍だと思います。

  1. https://redash.io/

  2. Aleksander Fabijan, et al. 2017. The Evolution of Continuous Experimentation in Software Product Development. In ICSE.

  3. Michael Armbrust, et al. 2021. Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics. In CIDR.

  4. https://databricks.com/jp/

  5. Ron Kohavi et al. 2020. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press.

  6. 永田 靖. 2003. サンプルサイズの決め方. 朝倉書店.

  7. 安井 翔太,株式会社ホクソエム. 2020. 効果検証入門〜正しい比較のための因果推論/計量経済学の基礎. 技術評論社.

定期購読の難しいところ

f:id:nanakookada:20210922211918p:plain

定期購読の難しいところ

システム開発部部長の内原です。

今回はバックエンドエンジニア観点で、定期購読(サブスクリプション)を扱う際に問題となるであろう様々なことについてお話しします。

私は現在システム開発部という部署を担当していますが、以前はDELISH KITCHENのプレミアムサービスチームでバックエンドエンジニアとして働いていたので、その経験を元にして実装や運用で難しさを感じたことについて語ります。

はじめに

DELISH KITCHEN においてもプレミアムサービスという定期購読サービスを提供しています。 内容は以下のようなものです。

DELISH KITCHEN プレミアムサービスとは

  • 機能面

    • お気に入り数無制限
    • 人気順検索
    • プレミアムレシピ(ダイエット、ヘルスケア、美容・健康、作りおき)
    • おまかせ献立(1週間ぶんまるごとで献立を提供)
    • プレミアム検索(糖質オフ、塩分控えめ、などの検索条件を利用可能)
  • 価格面

    • 月480円、半年2,400円、年4,500円
    • 初回登録時は1ヶ月無料(キャンペーン時期により2ヶ月無料、3ヶ月無料)

決済システムについて一般的なお話

DELISH KITCHENに限らず、自社アプリに決済機能を設ける場合は、なんらかの外部サービスが提供する決済システムを利用するケースが殆どではないでしょうか。

自前の決済システムを構築するとなると、技術的難易度が上がることもさることながら、それ以上にセキュリティや法律の観点での考慮が重要になりますので、決済システムそのものがコア技術となるようなサービスを開発するのでない限り、費用対効果を考慮して外部が提供している決済システムを利用することが多いと予想します。

DELISH KITCHENでは、決済システムとして以下を利用しています。 そもそも、iOS/Androidについてはアプリ内でデジタルコンテンツを販売する場合はIAP/IABを利用する必要があるため、事実上の標準となっています。

  • iOS
    • Apple In App Purchase (IAP)
  • Android
    • Google Play Billing Library (In App Billing / IAB)
  • 携帯キャリア (DoCoMo/au/Softbank)決済。DELISH KITCHEN WEBで利用
    • 外部決済システム

※クレジットカードや銀行口座、コンビニ払いといった支払い方法には現状対応しておりません

そもそも決済システムは難しい

そもそも、定期購読に限らず消費型(買い切り型)の商品を扱う場合でも、決済システムの構築にはいくつか考慮しなければならない問題があります。

決済プラットフォーム別の調査&実装が必要である

決済プラットフォーム間でいろいろと仕様が異なる部分が存在します。プラットフォーム間での相違から、必要となるデータが得られないというケースもあり、そうすると差分を埋めるために独自に実装が必要になることも多いです。例えば、IAPでは講読更新ごとに講読更新日時が取得できるが、IABだと初回の講読日時しか取得できないといったケースです。

決済処理は処理のフローが不安定なケースがある

ユーザ側の操作として、(初回は決済方法の指定が必要、など)いったん別画面に遷移したりすることが多いので、途中でユーザが脱落したり、通信エラーが発生したりする頻度も自然と高くなります。さらに、決済部分はアプリ外の挙動であり、課金ボタンはタップしたがその後脱落というケースが多くても、その原因は分からないということが多いです。プラットフォーム側で決済は完了したが、正しく通達できていないというケースのことです。

決済状態と内部システムの同期が必要である

上記問題に対応するため、購入情報の同期を行う機能が必要になります(アプリ内では購入情報の復元と表現されます)。

不具合対応やお客様対応の難易度が高くなりやすい

そもそも不具合が発生すること自体が問題ではあるのですが、金銭的損害が絡まない場合に比べて問題が複雑化&深刻化する傾向が高いです。また、お客様のお問い合わせ対応において返金作業が別途必要になるなど、他の問題と比較してお問い合わせクローズまでの時間が長くなりやすいです。

購読の状態が複雑

定期購読は、未購読、購読中、定期購読中止(未解約)、解約済、といった状態が時系列で存在しているため、いったん確定した購読状態が時間経過によって変化することになります。 よってこれらの状態変化を正しく認識する必要があります。

以下に購読ライフサイクルの例を挙げます。 特にユーザが操作をしていなくても、時間経過によって購読状態が変化する場合があるのが分かります。

購読、解約

- 登録直後 0.5ヶ月後 1ヶ月後 1.5ヶ月後 2ヶ月後 現在
購読中 無料期間 - 更新1回目 - 更新2回目 購読中
購読後解約A 無料期間 - 更新1回目 定期購読中止 解約 解約済
購読後解約B 無料期間 定期購読中止 解約 - - 解約済

解約後、再購読

※過去に購読→解約を経験しているため、無料期間が存在しない

登録直後 1ヶ月後 1.5ヶ月後 2ヶ月後 6ヶ月後 現在
無料期間 更新1回目 定期購読中止 解約済 更新通算2回目 購読中

購読後、商品切替(1ヶ月→半年)

※購読している商品の購読期間を変更することが可能

登録直後 1ヶ月後 1.5ヶ月後 7ヶ月後 現在
無料期間(1ヶ月) 更新1回目(1ヶ月) 購読切替(半年) 更新2回目(半年) 購読中

分析要件の難しさ

「どのような理由で購読/解約したのか?」、「どのような施策が売上に効いている/効いていないのか?」、「キャンペーン内容は適切であるか否か?」といった様々な観点での分析が必要となります。

前述の通り、購読状態は時間とともに複雑に変化するため、時系列での評価を行わなければならなくなります。

なにを見たいか

  • 課金ページ閲覧数、課金数
  • 新規購読UU
  • 全体購読UU
  • 課金転換率
    • 無料期間によって対象期間は変わる
  • 解約率
    • 購読開始してから何日めか、が重要

なんの軸で集計するか

  • 購読期間別
    • 1ヶ月、6ヶ月、1年
  • 無料期間別
    • 1ヶ月、2ヶ月、3ヶ月、6ヶ月
  • 登録日別
    • キャンペーンやプロモーションの影響を分析する
  • 訴求内容別
    • 献立、ダイエット、ヘルスケア、など
  • 上記の組み合わせ

過去の状態を判定

分析観点において、特定ユーザのN日前の購読状態を知りたいというニーズがあったとしても、状態遷移としては購読開始、購読更新×N、定期購読中止(未解約)、解約済、という起点があるだけです。単にN日前のデータを見ただけでは判別ができないということになります。 よって、時系列で購読状態を解釈する必要性があります。

プラットフォーム差異

前述したように、プラットフォームごとに提供される機能やデータ種類に差分がありますが、DELISH KITCHENシステムとしてはなるべくプラットフォーム差異を意識しないで済むようにしたいので、これらの差分を吸収する実装を行う必要が出てきます。 とは言え、そもそもの仕様が異なる関係で、完全に吸収することは難しいものも存在します。

例えば以下のように、IAP/IABでは仕様が異なる部分があり、いずれかに合わせる、または代替となるデータを自前で算出する機構を実装するなどの対応が必要になります。

- 価格 無料期間 購読履歴 定期購読中止日 購読商品切替時
IAP 価格帯から選択 期間帯から選択 取得可能 取得不可 現購読完了後に切替
IAB 1円単位で指定 1日単位で指定 取得不可 取得化 即時切替

本番での課金テストの辛さ

検証環境でのテストを十分に行っていたとしても、本番環境での検証を一切しないままだと不安が残ります。 よって、検証環境ほどの作業項目ではないにしても、最低限の動作確認は本番環境でも行っておきたいところです。 ただそれについても困難が伴います。

初回無料に関するテスト

初回無料が有効になるのは、ストアアカウントごとに1回ずつというのがIAP/IABにおける仕様です。 つまり、初回Nカ月無料が本当に正しくシステムで捕捉できているかといったようなテストを行う際は、都度ストアのアカウントを作り直さないといけないということになります。

解約済に関するテスト

いったん購読開始した後、定期購読を中止して解約済になった状態でテストする必要が出てきたとします。

しかし、実際に提供している商品の購読期間は1カ月や6カ月といった単位なので、定期購読中止してもその期間内はまだ購読済みのままです。 解約済み状態にするには最低でも1カ月前には準備しておかなければならないということを意味します。

終わりに

定期購読(サブスクリプション)に関する実装、運用の観点からの難しさについて記述しました。 今後の参考になりましたら幸いです。

MetabaseとDatabricksを接続する方法

f:id:nanakookada:20210910173109p:plain

はじめに

エブリーでは日々大量のデータをDatabricksで処理し、MetabaseなどのBIツールで可視化や分析を行っています。
MetabaseとDatabricksのデータベースを接続する方法がまとまっている記事があまりなかったので、ここにまとめたいと思います。

手順

1.Databricks用のJDBCドライバー入りのMetabaseイメージを作成

2.MetabaseとDatabricksを接続する

1. databricks用のJDBCドライバー入りのMetabaseイメージを作成

こちらのフォークリポジトリを使って、ローカルにDatabricks用のJDBCドライバー入りのMetabaseイメージを作成します。

git clone https://github.com/rajeshkumarravi/metabase-sparksql-databricks-driver.git

cd metabase-sparksql-databricks-driver

curl -L "https://github.com/rajeshkumarravi/metabase-sparksql-databricks-driver/releases/download/v1.2.0/sparksql-databricks.metabase-driver.jar" -o sparksql-databricks.metabase-driver.jar

Dockerfileの一部を修正します。

FROM metabase/metabase:v0.37.0.2

ENV MB_DB_CONNECTION_TIMEOUT_MS=60000

#コメントアウトor削除
#COPY ./target/uberjar/sparksql-databricks.metabase-driver.jar /plugins/

COPY sparksql-databricks.metabase-driver.jar /plugins/

「metabase-blog」と名前をつけたMetabaseイメージを作成します。

docker build -t metabase-blog .

コンテナを作成し、http://localhost:3000/ にアクセスしてMetabaseの画面が表示されれば成功です。

docker run -d -p 3000:3000 --name metabase metabase-blog

2. MetabaseとDatabricksを接続する

Metabaseの管理画面から「データベース」→「データベースを追加」をクリックします。

DatabricksからMetabaseと接続したいクラスターの「configuration」に進み、「Advanced Options」から「JDBC/ODBC」に表示される値を確認します。

f:id:kthimuo:20210907124909p:plain

これらをMetabaseに入力していきます。

「データベースのタイプ」→ Spark SQL (Databricks)

「ホスト」→ databricks画面の「Server Hostname」

「データベース名」→ default

「ユーザー名」→ token

「パスワード」→ Databricksのアクセストークン

「追加のJDBC接続文字列オプション」→ Databricks画面の「JDBC URL」の <personal-access-token> を1つ上の「パスワード」に置き換えたもの

「簡単なフィルタリングと要約を行うときに自動的にクエリを実行する」→ False

「データベースが大きいため、Metabaseの同期とスキャンのタイミングを選択します」→ True

f:id:kthimuo:20210907124959p:plain

これでデータベースとの接続は完了です。

3. 確認する

最後にDatabricksのサンプルデータベース「default」にあるテーブル「smsdata」にクエリを投げてみます。

f:id:kthimuo:20210907125020p:plain

ちゃんと接続されているようです。

以上です。最後まで閲覧いただきありがとうございました。

カンファレンススタッフに参加してみよう!

f:id:nanakookada:20210906185641p:plain

はじめに

はじめまして。最近創立されたSite Reliability Engineering(SRE)チームに所属している吉田です。

今回は「カンファレンススタッフ」についてお話しようと思います。

”カンファレンススタッフをやってみたいけど、まだまで全然プログラミングできないから貢献できないかも…”という方がいらっしゃったらぜひ読んでいただければと思います!

カンファレンススタッフって何?

名の通りカンファレンスのスタッフをします。

といっても何をしてるの?という疑問が出てくると思うので、実際に僕がメインで参加しているPyConJPを例にご紹介します。

(全部はリストアップできないので一部です

  • webサイトの構築
  • タイムテーブル作成
  • プロポーザル
  • グッズ・ノベルティ作成
  • 宣伝
  • 予算組み
  • スポンサー様とのやりとり
  • 進行の台本作成
  • 企画組み
  • keynote決定
  • 通訳業者様とのやりとり
  • ロゴデザイン
  • チケット設計
  • 会場下見・決定
  • 託児所決め
  • etc…

パッと見てわかった人もいらっしゃるかもしれませんが、Pythonを使わないタスクが多いです。Pythonどころかプログラミングの知識が必要なタスクは意外とありません。

もちろんPythonの知識は生かせないというわけではなく、keynoteやプロポーザルなどではPythonの専門知識が必要となります。

お伝えしたいのは「その言語に対しての知識が無いからカンファレンススタッフは無理か」とはならないということです。これはPyConJPだけではなく他カンファレンス様でも同様のケースが多いと感じています。

f:id:yskn-beer:20210903162204p:plain
(photo by PyConJP)

モチベーション

では何故カンファレンススタッフを始めたか、続けているモチベーションは何かという話です。

IT業界に還元したい

僕の場合はプログラマーとして日々インターネットで様々な情報をインプットしています。インプットというのは誰かがアウトプットしているから成り立つものです。

それ以外にも開発でOSSを使用していますが、OSSも湧いて出てくる訳もなく誰かが時間を割いてコミットしてくれたものです。

「その行為に対して何か還元できないか」という気持ちは昔からあったのですが、当時は自分の技術的にOSSコミットは難しいな…アウトプットできるほどの知識も無いな…と思っていてなかなか踏み出せずにいました。しかしたまたまスタッフ募集のお知らせを見かけて自分にもきっとなにかできることはあるやろという精神でエイッと入ったのがカンファレンススタッフになった経緯となります。

実際に入ってみたら本当にプログラミング1mmもわからんという人でもタスクが山程あったので結果オーライでした。

面白い人に出会える

カンファレンススタッフには様々な会社・業種・レイヤー・国籍の人がいます。

個人的にはNOC(Network Operations Center)というタスクを中心に行うことがあり、そこで知り合った方たちとカンファレンス以外でも交流が続き、界隈の情報交換など色々な話が聞け非常に有意義な時間になっています。

これは小話なんですが、カンファレンススタッフの中には複数のカンファレンスを跨いでスタッフをしてる人も少なくないので、交流を持つことで他のカンファレンスのスタッフ求人を紹介してもらって数珠つなぎに色んなカンファレンススタッフに参加しやすくなることが多々あります。僕自身も複数のカンファレンスのスタッフをNOC繋がりでやったこともあり、それぞれのカンファレンス同士でスタッフが手伝いする循環が発生することがあります。

f:id:yskn-beer:20210903162424p:plain
(photo by PyConJP)

市場価値向上

これは入った後に気づいたのですが、カンファレンススタッフをやること自体が個人の実績として有用であり1エンジニアとして市場価値が付与されるというものがあります。

上記にも記載したとおりコミュニティへの貢献という文脈として社内外の評価が上がることがあります。

自分の場合はたまたまメディアスポンサー様のご協力の元カンファレンスレポートを執筆し、無事執筆実績の解除を行うことがありました。感謝します!

自分のペースで進められる/お互いリスペクトしあえる

実際にカンファレンススタッフになってみて一番思うことはカンファレンススタッフというのはあくまで有志のボランティアなので、プライベートの時間に合わせて作業が進められるという点です。

学生は学業が、社会人には仕事があるので時には振られたタスクを締め切りまでにこなすことが難しいときがありますが、そういった時でもキチンと「ちょっと期限までには厳しいです」と言うだけで手が空いている人が率先して手伝いや引き継ぎを行ってくれることが多く、非常に心理的に助かる面があります。

これは互いが本業を持っていること・プライベートの時間を割いていることを自覚していてリスペクトしあっているからこそ為せることだと思っています。

逆に本業が早めに終わったりしてプライベートの空き時間が開いてる時は残ってるタスクや、手一杯になっている他の人の手助けを積極的に行える環境が整っていることが多く無理なく自分のプライベートの時間に合わせて無理なく進めることができます。

スタッフTシャツがもらえる

寝間着が増えます

まとめ

"カンファレンススタッフ"と聞いて腰が重かった方もいらっしゃると思いますが本当にカジュアルにプライベートのスキマ時間を使ってコミュニティに貢献ができます。

「コミュニティ貢献はしたいけどそれでもカンファレンススタッフはまだちょっと…」という方も大丈夫です。コミュニティの貢献は色んな方法があり、これは一例です。財団への寄付やSNSでイベントの宣伝、その言語やフレームワークを使うこと自体で十分貢献できてきます。

イベントをスタッフとして作り上げるのは非常に達成感があります。ぜひ一緒にカンファレンス・コミュニティを盛り上げていきましょう!

f:id:yskn-beer:20210903162517p:plain
(photo by PyConJP)


P.S.

そして何故このタイミングでこういった投稿をしたかと言うと、僕が参加しているPyConJP2021が10月15・16日と開催されます!

https://2021.pycon.jp/

更に更にPyConJPではサポートスタッフを募集中です!

PyCon JP 2021 サポートスタッフ募集開始のお知らせ

Apache AirflowのPoCをした話

f:id:nanakookada:20210820142542p:plain# Apache AirflowのPoCをした話

はじめに

弊社『DELISH KITCHEN』のデータプラットフォーム上では、日々発生するデータをLakehouseプラットフォームに集約しており、Databricks上で処理される多数のETLジョブが存在しています。しかし、現在利用しているジョブ管理ツールでは、Databricksのジョブ同士の依存関係を細かく設定することが出来ず、実行ジョブが肥大化してしまう問題があります。
これらを適切な粒度で依存関係を設定出来るようにするため、DAGによるワークフロー定義が可能なApache Airflowを導入しました。その際に行ったPoCでの所感をお話します。

Lakehouseプラットフォームについてはこちらの記事で紹介されています。
Delta LakeとLakehouseプラットフォームによるデータウェアハウス設計

現状

Databricks Jobsによる管理

弊社ではデータ分析基盤として主にDatabricks を利用しており、ETLバッチジョブの多くをDatabricks Jobs を用いて管理・運用しています。
ETLバッチジョブの各タスクの依存関係や実行順を定義するワークフローは、DatabricksのNotebook上で定義されます。これらのジョブのスケージュール、アラートなどの設定はDatabricks JobsのWeb UI上から行っています。

これらのジョブは次のサンプルコードのように、Notebook上で定義して処理されます。

// Bigqueryからイベントの生ログを転送し、イベント毎に保存するジョブ
// task01,02が順次実行される
dbutils.notebook.run("./bronze/01_ExtractEventDataFromBQ")
dbutils.notebook.run("./silver/02_TransferAppEventToDelta")

次の図のように、Web UI上からスケージュールなどの設定をします。

f:id:ngmk:20210818153922p:plain
Databricks Jobsスケジュール設定画面

実際のアプリケーションのジョブでは、以下のようなデータ処理が実行されています。

  • BigQuery上のApp/Webのイベントの生ログを転送後、イベント毎に分解して保存
  • S3上に保存されるサーバーログをイベント毎に保存
  • 各事業部のKPIを計算

Databricks Jobsによるジョブ管理の問題点

これらのDatabricks Notebookで処理されるジョブには、ジョブ間の依存関係を設定できない問題が存在します。この問題は、処理方式がCRONとなっており、時間制御によるジョブスケジュール管理ツールのため、他のジョブの状態を考慮していないことから発生しています。
ジョブの完了をトリガーとしたジョブの実行ができず、トリガーとなるジョブのワークフロー内に後続ジョブの実行を定義する必要があります。
ジョブのワークフロー内に別のジョブ実行を定義することは、本来ジョブが持つ関心事を曖昧にし、データワークフローの見通しが悪くなるだけでなく、データワークフロー管理の観点やジョブ肥大化の観点などにおける様々な問題を引き起こします。

例えば以下のような3つのジョブがあるとします。

  • アプリのログを保存する
  • アプリ内検索のKPIを計算する
  • アプリ内課金のKPIを計算する

検索、課金のKPIを計算するジョブは、アプリログを保存するジョブの完了を実行条件として要求します。
3つのジョブの流れを図に起こすと次のようになります。

f:id:ngmk:20210818182916p:plain
3つのジョブのワークフロー

各ジョブには論理的な繋がりがなく、関心事毎に個別のジョブとして定義・管理されている状態が望ましいですが、Databricks Jobsでは依存関係の設定ができないため、本来は個別に定義されるべきジョブが1つのジョブとして定義されてしまいます。

例えば、アプリログを保存するジョブの完了をトリガーに、各KPIを計算するジョブの実行が不可能なため、1つのジョブ内でそれぞれのジョブを定義することになります。
次の図はそれぞれのジョブが同一のノートブック内に1つのジョブとして定義されている状態を表します。

f:id:ngmk:20210818183010p:plain
依存関係を設定できない場合のワークフロー

単一のジョブとして定義された各ジョブは、順次実行されるため実行時間が長くなるだけでなく、ジョブ毎に要求される適切な計算資源の割当ができません。そのため最も重い処理に要求される計算資源を長時間使い続けることになります。大きな計算資源を長時間使用することは、ジョブの運用に要求されるコストを増加させるため望ましくありません。

例えば、KPIの計算はアプリログを保存するジョブと比較して計算資源を要求しませんが、ジョブをまとめて定義してしまったことで、必要な計算資源よりも大きな計算資源が割り当てられてしまい、不必要なコストの増加が起こります。

このように、関心事によって適切な粒度でジョブを分割し定義されていない状態は以下のような問題を引き起こします。

  • ジョブの肥大化による実行時間の長期化
  • ジョブの計算量に応じた適切な計算資源の分配ができない
  • 上記2つに起因するコストの増加
  • 将来的なワークフロー変更に対応できない
  • データワークフローの見通しの悪化

Apache Airflowの導入

ジョブ間の依存関係を設定できない問題を解決するため、Apache Airflow を導入します。
Apache Airflowはジョブ間の依存関係を設定できるだけではなく、GCP、AWS、Databricksなどの弊社で利用している様々なサービスへのタスク実行をサポートしているため、検討することにしました。

Apache AirflowではETLバッチジョブのワークフローをDAG(有向非巡回グラフ) として、1つのPythonファイルで定義します。これらのジョブのスケジュール、アラートなどの設定もDAGを定義したPython ファイル内で定義され、ワークフローだけではなくジョブの設定を含めたコードベースでの管理が可能です。

次のサンプルコードのように、Databricks上のジョブを実行するDAGを定義できます。

# need pip install airflow==2.0.2, apache-airflow[databricks]==2.0.2

import datetime

from airflow import DAG
from airflow.providers.databricks.operators.databricks import

DatabricksRunNowOperator, DatabricksSubmitRunOperator
from airflow.utils.dates import days_ago

cluster_settings = {}

with DAG(
        # アラート、スケジュールを設定
        dag_id='example_databricks_jobs',
        default_args={
            'owner': 'admin',
            'depends_on_past': False,
            'email_on_failure': False,
            'email_on_retry': False,
            'retries': 2,
            'retry_delay': datetime.timedelta(seconds=10)
        },
        schedule_interval='@hourly',
        start_date=days_ago(2)
) as dag:
    task1 = DatabricksRunNowOperator(
        task_id='run_now_operator',
        job_id='65',  # databricks > jobs > job ID
        notebook_params={'env': 'prd'}
    )
    task2 = DatabricksSubmitRunOperator(
        task_id='submit_run_operator',
        json={
            'notebook_task': {
                'notebook_path': 'Product/bronze/01_ExtractEventDataFromBQ',
                'base_parameters': {'env': 'prd'}
            },
            'new_cluster': cluster_settings
        }
    )
    # ワークフローを定義
    task1 >> task2

定義したDAGによるワークフローは、ダッシュボード内のGraph Viewによって可視化できます。データワークフローが可視化されることは、依存関係の素早い把握に繋がり、多数のジョブの運用を助けます。

次の画像は上記のDAGによるワークフローが可視化されたもの表しています。

f:id:ngmk:20210818154549p:plain
airflowによるワークフローの可視化

ジョブ間の依存関係の考慮

Apache Airflowでは、ExternalTaskSensorモジュールという他のDAGに定義されているタスクの実行結果(成功/失敗)を検知するモジュールを使用することで ジョブ間(DAG間)の依存関係を設定できます。
このモジュールを後続として実行したいDAGの最初のタスクとして定義すると、アプリログを保存するジョブの終了後にKPIを計算するジョブを実行するなどのジョブの依存関係を設定したワークフローを表現できます。ジョブの実行結果を検知するタスクを後続のワークフロー内に定義することで、トリガーとなるジョブ内に後続ジョブの実行を定義する必要がなくなります。
ジョブのワークフロー内に別のジョブ実行を定義する必要がなくなったことは、ジョブが持つ関心事を明確にし、データワークフロー管理の観点やジョブ運用の観点などに様々な利点をもたらします。

次の図のようにジョブを個別のDAGとして定義できます。

f:id:ngmk:20210818183055p:plain
依存関係を設定したワークフロー

ジョブを個別に定義することで、並行実行による実行時間の短縮や、ジョブごとの適切な計算資源の割当により、不必要な計算資源を長時間使い続けることがなくなります。 必要な計算資源を必要な時間だけ使用することにより、ジョブの運用に要求されるコストが最適化されます。

例えば、アプリのログを保存するジョブには大きな計算資源を、各KPIを計算するジョブには小さな計算資源を割り当て、KPI計算を並行して実行することで、ジョブ全体での実行時間の短縮と計算資源の適切な割当により運用コストを抑えることができます。

このように関心事が分離され、適切な粒度でジョブを分割することで以下のような恩恵を受けます。

  • ジョブの計算量に応じた適切な計算資源配分
  • 上記によるコスト削減
  • ジョブの並列実行によるワークフロー全体で見た実行時間の短縮
  • ワークフロー変更に対する柔軟性
  • データワークフローの見通しの好転

最後に

以上、ETLバッチジョブの管理ツールとしてApache AirflowをPoCした話でした。
Apache Airflowを導入したことで、ジョブ間の依存関係を考慮したワークフロー定義が可能になり、適切なジョブの定義によりで様々な恩恵を得ることができました。
ジョブを関心事毎に適切な粒度で定義することで、各ジョブの見通しがよくなる、コストが最適化されるなどの恩恵を享受でき、多数のETLバッチジョブを長期に渡る管理・運用を可能とすることが期待されます。

参考

  1. Databricks
  2. Jobs | Databricks on AWS
  3. Apache Airflow
  4. Apache Airflow Concepts
  5. 有向非巡回グラフ - Wikipedia