次のステップ

統計学とエンジニアリングを統合する方法はたくさんあるので、うまく始められるように幾つかご紹介しましょう。

計測ツール

統計学の基本に焦点を当ててきましたが、そもそも、どうやって関連するデータセットを生成すればいいのでしょうか？　私たちの答えは、コンポーネントの計測ツールを構造化することです。しかるべき所に正しいフックを使用すれば、私たちが問題をデバッグするために残業しても、パフォーマンスを向上させるために予備のサイクルがある時でも、データは必要な時に得られます。

PayPalのPythonサービスの堅牢性の多くは、信頼性の高いリモートロギング基盤によるものです。そしてこれは rsyslog と似ていますが、より強力なものです。それでも、データを上流に送信する前に、このプロセスは内部の指標を収集する必要があります。メジャーリリースがもう間近なので、2つのオープンソースプロジェクトを活用します。

• faststat – 最適化された統計アキュムレータ
• lithoxyl – 次世代のロギング及びアプリケーション計測ツール

Lithoxyl は、アプリケーションのイントロスペクション用に設計された高レベルのライブラリです。 可能な限り最もPythonらしいロギング・フレームワーク であることを目的としています。これには、レザボアサンプリングやP2などを含む構造化されたロギング及び様々なアキュムレータが含まれています。しかし、もっと重要なのは、Lithoxylは出力レベルとフォーマットを計測ポイント自体とは別に管理することができるので、アプリケーション用に独立した計測イメージを作成できることです。

Faststat は、より下位のレベルで動作します。その名の通り、Faststatは、ここで説明した指標とさらに多くの指標のためのアキュムレータを実装する、コンパイル済のPythonの拡張機能です。これには、 幾何/調和 平均から、統計情報の更新間の時間を追跡するメタメトリックに対するマルコフ過程のような遷移の追跡までの全てが含まれています。Faststatはオーバーヘッドが少ないため、ポイント当たりわずか半マイクロ秒あまりで、私たちのフレームワークコードの最深部まで到達することができます。Faststatは独自の出力メカニズムを持っていないので、私たちの内部フレームワークには、統計情報を閲覧する簡単なWeb APIとUIはもちろん、警告とアーカイブ用のリモート蓄積サービスにfaststatデータを絶えずアップロードするgreenletが含まれています。

早くから計測ツールへ投資する利点の1つは、データ収集におけるパフォーマンスのオーバーヘッドに対する感覚を得られることです。信頼性や機能は、企業向け分野ではパフォーマンスより、はるかに重要です。私が取り組んできた多くのクリティカルなサービスは、計測ツールがなければ何倍も速いかもしれませんが、この点を除去すると、サービスのメンテナンスができなくなります。それが次のポイントです。

優れた仕事は、サイクルを要します。ここで説明した方法論は全てパフォーマンス優先ですが、サイクルを取り戻すためにサイクルを消費します。飛行機は、最前部の重い計器類が全くなければ、もっと多くの乗客を運ぶことができるでしょう。ほとんどのサービスにとって、ロギングと指標が機能そのものに次いで重要だという理由を簡単に想像できるはずです。機能と計測ツールのどちらかを選ばなければならないという状況は、アプリケーションや構成の信頼性にとって悪い前兆であることを常に忘れず、理解してください。

すぐにでも実行に移す必要があり、再利用または購読を望んでいる人には、 New Relic や Prometheus など、幾つか有望な選択肢があります。言うまでもありませんが、私たちには私たち自身のシステムがありますが、こうした製品には パーセンタイル値 と ヒストグラム があります。

拡張

上記のメインコースを損なわない限り、このセクションはデザートとして存在します。存分に味わってください。しかし、上記のコンセプトがPayPalのような企業のSOA環境下における要求の95パーセントを満たしていることを忘れないでください。

ここでは、記述統計、ノンパラメトリック統計を数値として応用することに焦点を当てます。統計学とは統計以上のものなのです。専用の用語があるということは、適切な回答と無回答の間には違いがあるということです。拡張の余地と業務へ応用されてきたやり方があります。

ノンパラメトリック統計 は分位数を出しますが、それ以上のものも提供します。一般的に ノンパラメトリック では、統計的な構造を記述しますが、確率分布（例 正規分布や2項分布）についての仮定を作るものではありません。つまり、記述統計のツールボックスには、最も広範囲に応用が利くツールがあるということです。それは、見慣れた ヒストグラム からなめらかな カーネル密度推定 （KDE）まで、あらゆるものを含んでいます。同時に幅広い各種の ノンパラメトリック手法 もあり、数量的に自分のデータの分布を見出したり、パラメトリック手法の世界へ拡張したりすることも視野に入れています。

パラメトリック統計 は、ノンパラメトリック統計とは対照的に、データが既存の確率分布に従うと仮定されています。自分のデータが 数多くの既存の分布 の1つのモデルとすると設定または仮定できれば、一般化に向けた優れたセットを手に入れたも同然で、自分のシステムについて論理的な説明がつきます。Pythonのバックエンドサービスの色々なパーツから想定される確率分布について1つの論文が書き上げられるかもしれません（ヒント：多くの 魚 と 電話 に期待あり）。自分のシステムにある固有のグラフ曲線を解きほぐすのは全く大変な仕事です。しかし、現実の観測から遠く離れるのは禁物です。あらゆる拡張モデルの練習問題と同様、 ブラックスワン の警告の鳴き声に注意しましょう。

推測統計 は 記述的 統計とは対照的に、モデルを発展させ、将来のパフォーマンスを予想することが目標です。 回帰分析 や 分布近似 のような予測モデルの応用は、十分にデータを集めたのか、あるいはいくつかの指標が不足しているのかを判断するのに役立ちます。信頼できるモデルをサービスに設定し、モニタリングやアラートのシステムへ接続できれば、 SRE の境地へ達するでしょう。一方、多くのチームが先週のチャートに上書きして予測をしています。これは、しばしばとても効果的で、数値的な推測の必要性が低くなりますが、常に人の手を介した解析が必要で、長期にわたるトレンドの分析がうまく構築されない上に、前の週が典型的時期ではない場合（つまり、停滞期かピークの時期）にはまともに働きません。

カテゴリカルな統計 は、数値による統計と対照的に、データを数学的に計算できるものではありません。カテゴリカルデータはIPアドレスや電話番号のように大量であるか、またはエンドユーザ言語のように少量であるかです。私たちのキーである非数値的な指標とは、カテゴリカルデータの大体の計算、あるいは 濃度 のことです。ストリーミング配信の濃度の予測のために、いくつかのコンポーネントでは HyperLogLog と Count-Min sketches が使われてきました。レザボアのサンプリングが非常に容易になり、加えてカテゴリカルデータ用にも使えるようになったのです。併せて、HLLとCMSは増大した空間効率性を提供し、さらに重要なことに、エラーの領域を明らかにしました。レザボアのサンプリングを把握した後、ただしさらに深く濃度を掘り下げる前に、PayPalのPythonサービスで広く使われている boltons ThresholdCounter 、つまり 相当数ヒットする要素のカウンタ を見たくなるかもしれません。しかし、まずは、 この統計の基本的なデータタイプの一覧表 を見てください。

多変量解析 を使うと多数の出力変数を一度に分析できます。多次元になるので、突出した次元を探すと必ず見つかるというような具合に、やり過ぎてしまいやすくなります。それにもかかわらず、単純で実践的な 相関 を追究すれば、冗長なデータ収集に関して情報を得られるのはもとより、自分のシステムに対するセンスも磨かれます。

測定値は現実の行動を覆うブランケットみたい。

多峰分析 は現実の世界のデータの中にたくさんあります。そこでは、複数のピークや複数の分布が1つのデータセットに組み込まれています。HTTPサービスのレスポンス時間を考えてみましょう。

• リクエストの成功（ 200番台 ）は“ノーマルな”待ち時間。
• クライアント側の失敗（ 400番台 ）は、リクエストが不正で何もなされないため、即座に終了。
• サーバエラー（ 500番台 ）は、即終了（バックエンドのダウン）か、長時間（タイムアウト）。

ここで想定できるのは、ピークが明らかに3つある、複数の重なり合ったグラフがあるということです。この誇張されたグラフから要約統計量だけを見ていると、データの実際の意味を見誤ってしまうことがはっきりと分かるでしょう。ピークが2つの場合は有効な統計的手法の範囲が狭まり、3つ以上だとピークを見るのが非常に難しくなります。有意義に分析するために、データセットを分離させたり追跡したりしたい時もあれば、あえてこの形を残し、データをいっしょくたに見ることで、より理解が深まる時もあるのです。

時系列の統計データ は、測定値を1つの全体的な傾向、つまり時間間隔に当てはめることによって、測定結果を変換します。PayPalでは、 OpenTSDB に送られる1分ごとのトランザクションとエラー率からPythonチームが作った $PYPL Pandas株価分析 にいたるまで、時系列をあらゆる所で活用しています。全てのデータが時系列で意味をなしているわけではありません。時系列ストリームの上に何かアルゴリズムを実装することは簡単かもしれませんが、適用しすぎることについては気をつけてください。タイムバケットはデータをゆがめ、サンプルを安全に結びつける方法を減らし、誤解を招く恐れのある相関を引き起こしてしまうことにつながります。

移動指標 は、時にローリング指標やウィンドウ指標と呼ばれることもありますが、測定結果と時間を結びつけて計算する、もう1つの効果的な種類です。それには例えば、 指数加重移動平均 （EWMA）があり、 平均負荷を算出するためにUNIXで使われていることは有名ですね 。

$ uptime
10:53PM  up 378 days,  1:01, 3 users, load average: 1.37, 0.22, 0.14

この出力結果には、コンパクトながら多くの情報が詰まっています。そして、追跡する時のコストを抑えられますが、内容を正しく解釈するには、ある程度の知識と理解が必要です。EWMAはおなじみの方法であると同時に繊細でもあります。時系列スタイルの離散するバケットを取るか、移動統計の連続するウィンドウを取るかを考えるのは楽しいものでしょう。例えば、昨日のデータを扱うのか、それとも過去24時間のデータを扱うのかといったものです。または1時間前を見るのか、直前の60分間を見るのかといったこともありますね。PayPalのPythonサービスでは、アプリケーションに人々が投げかける問題を基にして、移動指標はほとんど使わず、通常は時系列の方を多く利用しています。

生存率モデリングを少し使うだけで、クリーンなコードになる。

生存率分析 は、システムコンポーネントの生存期間の分析に使われます。そして信頼性に関するエンジニアリングの論文に登場するべきものです。 故障率曲線 の基本的な理解によって、実行しているプロセスの生存期間についての見識を得られます。シミュレーションや事後分析における調査さえも、故障率曲線を使うと非常に有益です。障害は、予測されている生存期間の初めや中間、そして終わりに引き起こされたものに起因します。生存期間が上書きされ、集計された故障率曲線が生成される場合です。ソフトウェア業界がハードウェア業界と同じくらいこの分析を活用するようになる時、技術の世界は、今よりも間違いなくクリーンな場所になるでしょう。

まとめ

ここまで来るのに長い説明をしてきましたが、何か新しいことを学んでもらえたとしたらよかったと思います。少なくとも、私たちが取っている方法については分かってもらえたでしょう。以下の3つの教訓については、覚えておいてください。

1. 統計は、必要かどうかも判断できないような非常に独特な専門用語とテクニックを使う。しかし、それらを学ぶのに時間をかける価値はある。

2. 平均やモーメントをベースとした測定結果は、ソフトウェアのパフォーマンスや信頼性を阻害するものではなく、決して異常値を過小評価してはいけない。

3. ソフトウェアの詳細を調べるにあたっては、意味のある適切なデータを生成するために、分位数、集計値、その他の安定した指標を使う。

統計、特に記述統計学からの分岐について、もっと学びたい場合は、 Allen Downey の映像による講義『 Data Exploration in Python 』や彼が出している無料の本『 Think Stats―プログラマのための統計入門 』そして『 Think Bayes―プログラマのためのベイズ統計入門 』をお勧めします。企業向けソフトウェア開発をもっと学びたい場合やトレーニングが必要な開発者を抱えている場合、私の新たな映像による講義『 Enterprise Software with Python 』を見てみてください。PayPalのPython開発によるソフトウェアの基本がさらによく解説されており、 oreilly.com や Safari で視聴できます。

あなたがこの記事で説明されたテクニックを適用してみたり、紹介したリンク先を活用してみたりすることによって、この記事が時間の節約になるような、十分に使える指針になるとすれば幸いです。実社会で数年働いたあとには、誰もが統計について再度向き合ってみる必要が出てきます。学校で統計を学んだとしても、実社会や実データ、そして実際の問題は、学校で統計の試験をパスした人でさえも、悩ませてしまうものです。相互接続性が増せば、全てのソフトウェアエンジニアリングというボートが、堅牢な測定結果という上げ潮に、うまく乗れることになるでしょう。