今回より五回にわたり、指標に基づく洞察を活用し、開発工程（と開発者のコーチング方法）を改善することをテーマとしたシリーズ記事を投稿します。
素早く行動し、物事を試す。Indeed ではこのようにプロダクトを開発しています。少数の素晴らしいアイデアに賭けるのではなく、多くのアイデアを素早く試すようにしています。
こうしたアプローチを成功させるためには、多様な視点を持った、革新的なチームメンバーが必要となります。わたしたちは、We help people get jobsというミッションの元に、アイデアをすぐに調べることに対して前向きなメンバーを採用しています。入社後には、当事者意識と自主性を持って、こうしたゴールに取り組んでもらいます。また、こうした実験の経過観測し分析するためのツールを与えています。
ミッション遂行のための最適なツール
上記のツールのいくつかは、社内で開発し、オープンソース化しました。その一つが、データ分析のプラットフォームである Imhotep です。Imhotep は、大規模な時系列データセットの高速な調査と分析を可能にします。クエリ言語 (IQL) 、web ベースの UI、そして分散型のバックエンドを含んでおり、拡張可能で、効率的、そして高速です。
Imhotep は拡張可能
Imhotepは、汎用的なハードウェアやクラウド上で実行できるデーモン・インスタンスを追加することで、水平方向の拡張が可能です。Indeed 内部のImhotep のクラスタは、何千ものデータセットの中で、毎週 500 万件のクエリを処理しています。そのうち約 90% のクエリは、自動化されたシステムから届きます。
最も使用されているデータセットには、昨年だけで 39 億件のイベントが存在しています。そのデータセット単体だけでも、毎月 2 万 5 千件程度のクエリが届きます。
Imhotep は効率的
Imhotep を支えるデータ構造は転置インデックスなので、ほとんどの時系列データセットのディスク使用量は、非常に小さく済んでいます。上記で触れたデータセットは、39 億件のイベントと各イベントにつき最大で384 件のフィールドを含んでいいますが、ディスク上で 5.7 TB の大きさです。つまり、各イベントは 146 バイト程度です。
このようなストレージの効率化により、サンプリングではなく全データを分析用に保存することを可能にします。サンプリングは、集計データのおおよその動向を確認したい場合は良い方法です。ですが、もしデータをじっくり読み込み、外れ値を検証したい場合には、サンプリングでは、外れ値を確実に発見したり、効果を確認することはできません。
Imhotep は高速
Imhotep のスピードは、素早く開発サイクルを回し、メンバーが協力しあうことを可能にします。Indeed では過去 90 日間において、内部のクラスターは2百万件の対話型の Imhotep クエリ（web アプリから実行されたクエリ）を処理しました。応答時間の中央値は 276 ms でした。
パワフルなキャッシュ実装が、この驚異の速さに貢献しており、実際に対話型クエリの 60％ 近くがキャッシュからきています。しかし、キャッシュされていないクエリですら、応答時間の中央値が 4 秒と、かなりの速さとなっています。長期間キャッシュ化されていないクエリはもっと時間がかかりますが、大差はありません。365 日間キャッシュされていないクエリでは、応答時間の中央値はおよそ 9 秒でした。
Imhotep のパフォーマンスのこうした統計をどのように確認しているかと言うと、Imhotep の使用量に対しても Imhotep のデータセットを持っているからです。数分のうちに、このデータセットに繰り返しクエリをかけて、最近のクラスターのパフォーマンスを理解することが可能なのです。
Imhotep はインサイトと改善を促す
Imhotepはプロダクトを検証し、素早く改善することを可能にします。私たちは、こうしたデータドリブンのアプローチを、開発工程の改善に取り入れています。次回の記事では、工程改善にどのように指標を活用しているか詳しくお伝えしたいと思います。
本シリーズのその他の記事のリンク
- スケーラブル、効率的、そして高速 —— Imhotepとは
- 開発工程の改善（とコーチング）に指標を活用する方法
- 指標に基づく工程改善の事例
- Imhotepを活用しプロジェクトの動向を理解する- ASFの事例
- Hindsight のメリット: 指標に基づくコーチング方法