組織がデータ駆動型であるためには，データの山を積み上げるだけでは不十分だ。 そのデータが正確で，かつ意味を持っていなくてはならない。PreziのデータエンジニアであるJulianna Göbölös-Szabó氏は，DevelopsDays Amsterdam 2015で，他の部署で働く人たちが提供するデータの品質を向上するために，氏のチームがどのような働きかけを行い，よりよいビジネス的洞察を得ることができたかについて講演した。氏らが選択したソリューションは，全チームを正しい方向に向かわせる手段として，契約をベースとした軽量アプローチを採用し，それによって非構造的データから構造的データに移行する，というものだ。
データ品質の問題に取り組むと決めた時点で，Preziはいくつかの課題に直面していた。同社では，１日に数百ギガバイトというログを取得していたが，それを処理して有用な情報にすることが困難だった。同社が重視していたのは主にシステムやインフラストラクチャ状態の監視であり，ビジネス関連の情報を取得することではなかったため，ツールがその目的に合わなかったのだ。エンジニアリングチームはデータ品質について，優先度の高いものとは見なしていなかった。データ品質の責任が複数のチームに分散していたのだ。
Göbölös-Szabó氏のチームは，これらの課題に取り組む上で，オーナーシップの明確化が重要であると判断した。データ品質を製品に組み込むための労力を削減して，コミュニケーションやコラボレーションにより多くの時間を費やす必要があると考えたのだ。
クリックストリームデータを格納する最も一般的な方法は，非構造型データを使用することだ。このアプローチはスマートとは言えないものの，Preziの企業規模が小さく，社員の大部分が技術者であった頃は十分に機能していた。担当者が正規表現やいくつかのスクリプトを駆使して，問題を見つけ出す方法をコーディングすることができたからだ。しかしPreziが，技術的なバックグラウンドを持たない社員が150名，１日あたりのログが400GBというポイントに到達すると，“非構造データとたくさんのスクリプト”というアプローチのスケールアップでは対応できなくなった。データは大量にあるが，それを効果的に利用するための障壁が非常に高いことから，有益なビジネス的考察を引き出すために苦労するようになったのだ。
Göbölös-Szabó氏は，開発チームの注意をデータ品質に向ける上で，氏のチームが直面した課題を説明するものとして，いくつかのストーリを公開した。ある例では，実行するプレゼンテーション – 同社はプレゼンテーションソフトウェアを販売している – に動画が組み込まれている頻度を調べる必要があったのだが，全ログデータから見つけ出す以外に，これを知る方法がなかった。別の場合には，誤ってログ呼び出しがコードから削除されたために，結果として３日分のデータを失うことになった。Preziにとって幸運だったのは，それがトラフィックの低い週末であったことだ。データのオーナーシップに関して氏があげたのは，ロケーションデータの例だ。誰が所有者だろう？収集したWebチームか，その正確性に基づいて資金を使うマーケティングチームか，それを処理するデータチームなのか？
Preziのデータチームはここで方針を変えて，技術的なソリューションと非技術的なソリューションのふたつを採用することにした。技術的な面では，非構造的なログ形式から，JSONをベースとした構造的な形式に移行した。JSONを選択したのは，人にもマシンにも可読性があり，自己文書化が可能だからだ。既知の構造化スキーマを選択することにより，ツーリングの構築も容易になる。さらにチームは，コラボレーションを意識した，“生きたドキュメント”のプロセスを構築した。ドキュメントは事実の唯一の源泉として機能する。データのログ保存の必要なチームは，そのログスキーマを文書化する。そのドキュメントは後に契約(contract)の役目を果たす。運用中に取得されたログは，そのドキュメントの内容で検証することで不整合を検出すると同時に，ドキュメントが最新の状態であることも確認できる。この事実の唯一の源泉により，ダッシュボードの作成も非常に少ない労力で可能になる。
InfoQはGöbölös-Szabó氏に連絡を取り，プロセスの詳細を聞くことにした。
InfoQ: 講演の中で，Logsterの解析スクリプト作成が容易になる，という話がありましたが，具体的にはどのようなことなのでしょう？
Göbölös-Szabó: 構造化ログを導入する方法としては，JSON形式以外に，プレーンテキストを用いるという選択肢もありましたが，私たちは，必須構造も合わせて導入することにしたのです。個々のログ情報はすべて，アクション，オブジェクト，トリガという３つの必須フィールドを持つ必要があります。さらにこれらは，プラットフォーム上のイベントをユニークに定義できるものでなくてはなりません。ログに他のフィールドを加えるのはもちろん自由ですが，最低限これだけは必要です。私たちのツールは，これら３つのフィールドを参照して，次の２つの処理を実行します。
- ３つの句の有効な組み合わせそれぞれについて，ログ情報がいくつ到着したかをカウントします。これを見れば，注目しているイベントの発生の有無が確認できます。また，最新のリリースで機能に問題が発生していないか，確認することも可能です – ただし，データ品質の保証には役に立ちません。あくまでも開発者にとって便利，というレベルです。
- アクション，オブジェクト，トリガという３つの句に基づいて，ログ情報の定義を識別し，スキーマに対する検証を実施します。これはデータ品質のチェックです。リリース後には，ここで矛盾が見つかることが多々あります。例えば，あるチームは整数値を“契約”していたにも関わらず，実際には文字列(例えば“NULL”)をログしていました。
Logsterルールを追加するには，Pythonモジュールの追加が必要になりますが，私たちの作業ではごく一般的なことです。私たちはログカテゴリを知っていますから，そのカテゴリの全てのログスキーマをクエリして，その中からマッチするスキーマを選択すればよいのです。基本的には，私たちのチームがテンプレートを提供します。必ず書き換えなくてはならないのは，ログカテゴリのみです。もちろん，独自のルールやメトリックが必要であれば，対応するPythonファイルにそれを加えればよいのです。一般的なユースケースには十分な，デフォルトのLogsterも用意しています。これを使用すれば，利用するチームは特に何もすることはありません。
InfoQ: ドキュメント/契約と実際のコード動作の不整合を，どうやって見つけるのでしょう？検証はいつ行うのですか？
Göbölös-Szabó: 不整合を見つけることができるのは，その機能がどこか(例えば試行段階)に展開されて，ログ情報が送信された時に限られます。アクション-オブジェクト-トリガという３要素を数えれば，ログ情報を送信しているコードに問題があるかどうかはすぐに分かります。
プロジェクトの始めの頃は，Jenkinsにチェックを統合することや，不正なログ情報を受け入れない(ログ情報を永続的な保管場所であるS3に送らない等)という方法も検討しました。しかし私たちは，チームを支援して，彼らがそれを使うことでハッピーになるようなツールを作りたかったのです。私たちの開発したものが彼らのフラストレーションを増長するだけのものであれば，彼らはそれを使うのを止めて無視するようになるでしょう。私たちの努力が無駄になるのです。
ですから私たちは，防弾チョッキのようなデータ品質チェックシステムを開発するのではなく，チームがログの品質をもっと意識するように支援し，奨励するようなシステムを作り上げることにしたのです。
デフォルトのダッシュボード。 中央は，コードとスキーマの不整合が表示される場合のあるメトリックの表示例。
InfoQ: ダッシュボードの開発には，特別なビルドツールを使用しているのでしょうか，あるいは一般的に公開されているツールを使っていますか？
Göbölös-Szabó: 標準設定のLogsterは，メトリックをGraphiteに提供します。 これはPreziが以前から使用しているツールです。開発者の多くがそれに精通しているので，このシステムを選択しています。
ダッシュボードにはGrafanaを使用しています。GrafanaはGraphiteからデータを取得しますが，UIやUXははるかに優れていて，JSONファイルでダッシュボードを記述することが可能です。ログスキーマ資料の情報を参照して，すべてを作り直すことも簡単にできます。
データウェアハウスには，AWSのRedshiftを使用しています。ログは処理されてクリーンアップされた後，Redshiftに転送されるので，Chart.ioを使ってチャート(あるいは表やファンネルチャート)を作成することが可能です。今の時点では，Redshiftにデータをロードする前段階の処理がいくつか必要ですが，より高品質な構造化ログを使うことで，最終的にはこれらのステップを廃止したいと思っています。
InfoQ: ダッシュボードには，どのような情報を表示できるのでしょう？
Göbölös-Szabó: Logsterが生成したメトリックスを使用することができます。次のようなものが表示可能です。
- アクション-オブジェクト-トリガの数
- スキーマ毎の有効なログ情報の数
- 処理したログ情報数や破棄された数(あり得ないが，JSON形式でない場合など)といった，ごく一般的な数値
- “列挙型”フィールド(スキーマには列挙型の定義が可能)の割り当て
デフォルトでは，特定のログカテゴリのすべてのログ定義について，上記４つの中のひとつのタイプを表示するダッシュボードが提供されます。例えば私たちは，各ログ定義の有効ラインを示す約50のチャートを使ってandroidのログを表示する，巨大なダッシュボードを運用しています。
この情報は，主に技術者にとって有効なものです。計数される対象が非常に基本的なもの – アクションAが何回実行されたか，スキーマSにマッチするログ情報はいくつあるか – なので，未加工の形式では，ビジネス側にとって有り難いものではありません。例えばこのデータが，フィルタリングされるべきテストユーザの情報を含んでいることも，珍しくはないのです。その一方で私たちは，ビジネスパーソンに大きな洞察力を与えるようなファンネルチャートを，即時に生成できるような機能は用意していません。ただし私たちは，メトリックを報告する専任チームや，多数のステークホルダが存在します。品質の高いログを持つことは，彼らにとって非常に重要なのです。