メトリクス駆動開発

原文(投稿日：2012/11/30)へのリンク

この記事は私がローマで開催されたDevOpsDaysで"メトリクス駆動開発"について話したことに基づいています。

現在、ITの世界でのリリースは数時間や数分単位で行われています。すべてが大きくなったり小さくなったり、右へ行ったり左へ行ったりします。それゆえ、優れた監視システムが必要不可欠です。IT組織にとってアプリケーションはビジネスのコアです。しかし、監視は運用チームが単独で行っています。アプリケーション開発をしたことがない人が、です。なぜでしょう。なぜそしてどうやってこれを変えなければならないのでしょう。どのようにすればより良い結果が生まれるでしょうか。この記事では開発チームと一緒にメトリクスを活用しようとした私の経験と考えを共有したいと思います。

この記事で紹介するアイディアは私がITアーキテクト(開発チームと運用チームの間)としてAdform社で働いた経験に由来します。Adformはデジタル広告の企業で独自の開発チーム(65人)と運用チーム(8人)があります。運用チームはリリースプロセスや開発環境、ネットワークやサーバの準備やメンテナンスに責任を持ちます。一方、開発チームは開発し運用されているアプリケーションのメンテナンスに責任を持ちます。ここで紹介するアイディアは実際に開発者を支援してメトリクスと監視の領域で働いた経験に基づきます。この領域は以前までは運用チームだけの領域と考えられていました。

メトリクス駆動開発とは何か

TDD、テスト駆動開発はよく知られています。TDDよりは知られていないかも知れませんが、BDD、振る舞い駆動開発も聞いたことがあるかもしれません。さらに知られていないADD(Scott Berkunn氏のブログには開発手法の名前が一覧されています) しかし、メトリクス駆動開発(MDD)はどこでも言及されていません。

MDDとは何でしょう。私はMDDをメトリクスを使ってアプリケーション開発全体を推進する手法と定義しています。MDDを採用している企業では性能や利用パターンから利益まですべてが計測されます。さらに、開発者や運用担当者、ビジネスサイドの意思決定もすべてメトリクスに基づいて下されます。メトリクスはチームのパフォーマンスを監視し、パフォーマンスのボトルネックを解消し、必要なハードウエアを見積もります。開発のライフサイクルの各段階の目的を達成するために利用されるのです。

メトリクス駆動開発の主な原則は、

• メトリクスをメトリクスのオーナに割り当てる
• レイヤ化されたメトリクスを作成し、傾向の相関を探る
• 意思決定する時にメトリクスを利用する

各メトリクスはオーナを持ちます。オーナはそのメトリクスを実装しメンテナンスするために必要な知識と方法を持っています。メトリクスのオーナはアプリケーションやサービス、そしてサーバについて責任を持ち、正しく監視されデータが集められていることを保証します。さらに、既存のメトリクスを最新状態に維持し、新しいアプリケーションや機能のためのメトリクスを作成します。

また、メトリクスを構造化するのも重要です。ある条件でグループ化されたりレイヤ化されたメトリクスはビジネスサイドの人から開発者まで誰でも理解できます。さらに、関連性を見つけたり、傾向を見つけたりするのも簡単になり、問題の発見から解決まで素早くできるようになります。

MDDを実践することで開発プロセス全体が視覚的になります。それゆえ、意思決定の精度を速度が上がり、ミスは見つかったとたんに直すことができます。そべてが計測され最適化されます。別の言い方をすれば、MDDはアプリケーションの脈拍を計測し、継続的な改善に必要な機会を提供します。

そして、MDDでメトリクスを使ってスプリントのゴール決めれば、はTDD、BDD、スクラムのような既存の手法にも負けません。メトリクスは、受け入れテストの時には気付かなかった問題や(実運用環境の)利用パターンを明らかにします。例えば、Lance Armstrongのバグ、つまり、コードは必ずテストを通過するのに、エビデンスを見ると正しく動いていないことがわかるという現象です。または機能を作ったのに利用されないというビジネス上のバグです。メトリクスを使えばこれらの“バグ”のエビデンスを収集できます。MDDは実際に動いているアプリケーションの使われ方を取り込みながら効率的で効果的な開発プロセスを実現できる手法なのです。

メトリクスを作成するのは誰か

白紙の状態から何かを始めるのは、概念を再考し、プロセスにイノベーションを持ち込んだり、プロセス全体を完全に変えてしまう機会です。Adformでもこのような機会が訪れました。要求を書き、完璧な監視リューションをどのようにイメージするかについてコンセプトを描いたところ、巨大なミスマッチがあることがわかりました。私たちはアプリケーションとサービスについてより多くの情報を集めたいと思っていたのですが、監視は運用チームが単独で行っていたのです。運用チームがインフラについては詳しかったものの、サービスやアプリケーションの内部の動作についての知識は限られていました。

企業はサーバをスムーズに動かすこと(これはとても重要なことですが)でお金を稼ぐのではありません。10ギガビットのインターネット接続を持っているのでお金を稼ぐのではありません。アプリケーションやサービスの機能をスムーズに提供する(これは"サーバをスムーズに動かす"こととは違います)ことでお金を稼ぎます。したがって、アプリケーションを実際に書いている開発者を監視作業に巻き込むことが問題を素早く発見する上で最も重要です。実際、開発者が開発した製品についてすべての知識を有している場合、期待通りにアプリケーションが動かないことにすぐに気付きます。

さらに開発者が監視作業を行うことで次のようなメリットがあります。

• 開発チームは開発中に監視ポイントを埋め込む方法を手に入れることができる
• 開発チームは実運用環境のアプリケーションから素早くフィードバック(性能、バグ、利用パターン)を受け取ることができる
• 開発チームはインフラについての知識を増やし、開発期間中にボトルネックについて考えることができる

運用チームは長い間、監視を行ってきました。CPU、メモリ、IOを監視するのは彼らの基本です。しかし、アプリケーションやサービスのメトリクスのオーナは開発チームです。開発チームはアプリケーションに必要な知識と改善を行うためのスキルを持っています。したがって、運用チームだけで監視を行ってはならないのです。開発チームは運用チームと一緒にメトリクスの作成とメンテナンスをする必要があります。次のセクションでは私たちの企業がどのようにしていままでのやり方を変えることを決断し、開発者を監視とメトリクスの領域に巻き込んだのか説明します。

MDDの原則をRTBプロジェクトに適用する

開発チームがメトリクスに習熟するのを支援するのは、理解と学習と失敗のプロセスですが最終的には成功します。開発チームがまったくメトリクスを使えないかいきなりメトリクスを使って意思決定をし始めるかのどちらかという二者択一の状況ではありません。企業文化や従業員の態度、マネジメントのポジション、労働習慣など多くの要因が最終結果に影響を与える、長く険しい旅です。マネジメントと開発の両方から承認をもらうため、始めにメトリクスの価値を提示するのが重要です。私たちの場合は偶然、リアルタイム入札のプロジェクト(RTB)でこのことを実践することになりました。

RTBはリアルタイムでオンライン広告を売買する比較的新しい手法です。簡単に説明すると、この手法では"Ad Exchanges"という構造を通じて顧客の入札額リクエストを受け付けて、特定のサイトを見た特定のユーザにバナーを表示します。リクエストを受け付けて処理するときにレスポンスを元のサーバに返します。秒間40000クエリを処理し、単一のトランザクションラウンドトリップを100ミリ秒以内で処理するのは運用上の要件でした。

アプリケーションを運用してみると状況は壊滅的でした。たった5000 QPSしか処理できなかったのです。さらにその中の30%のトランザクションが失敗していました。1回のラウンドトリップに100ミリ秒以上かからないようにするという要件を満たせていなかったのです。さらに悪いことになぜこんなに性能が悪いのか明確な理由がわかりませんでした。ネットワークに問題があるのか、サーバの能力なのか、アプリケーションレイヤなのか、何に関連する問題があるのかわからなかったのです。

最終的にはメトリクスを使って問題の原因を特定し回避することができました。70000 QPS(最初の14倍)以上処理できるようになり、トランザクションの失敗も0.5%以下になりました(最初の50分の1)。しかし、これを達成するためには、次のセクションで紹介するように、データをいっそう視覚化して構造化する必要がありました。

レイヤ化されたメトリクス

RTBの開発を始めたときすでにメトリクスのプロジェクトも開始していましたので、アプリケーションにいくつかのメトリクスを埋め込むことができました。さらに、サーバとネットワークのメトリクスもありました。しかし、十分なデータがあるように思えますが、本質的なデータを取り出し、傾向を理解してなぜパフォーマンスが要求値を下回っているのかを理解するのは簡単ではありませんでした。単なるデータの集合だけでは役に立たなかったのです。

そこで、データを3つのレイヤで表現することにしました。

• ビジネスのメトリクス
• アプリケーションのメトリクス
• インフラのメトリクス

このようにレイヤにすることでメトリクスはよりはっきりと構造化され、開発者もビジネスサイドの人間にも理解可能、利用可能になりました。アプリケーションの状態を確認するのはビジネスダッシュボードを共通で利用しました。誰もがアクセスしてSLAや利用傾向や収益を確認できました。必要であれば、アプリケーションダッシュボードでアプリケーションコンポーネントごとの性能やサーバグループごとの遅延やデータの増量を確認します。実際にはアプリケーションダッシュボードのいくつかのメトリクスはビジネスダッシュボードを同じで、より詳細になっているだけです。例えば、ビジネスダッシュボードではアプリケーションの性能をグラフ化し、アプリケーションダッシュボードではアプリケーションの各部分がどの程度の性能が出ているかをグラフ化します。最終的にはインフラダッシュボードでCPUやメモリ、I/Oを確認しました。

(クリックして拡大)

図1. ビジネスダッシュボード上でのアプリケーションのパフォーマンス

(クリックして拡大)

図2. アプリケーションダッシュボードでのアプリケーションの性能

問題の根本原因を特定するための次のステップはメトリクス同士の相関を見ることでした。インフラのメトリクスの上にアプリケーションのメトリクスを置き、その上にビジネスのメトリクスを置きました。このようにすることで、トップダウンでグラフを見てQPSの変動がアプリケーションの性能やサーバのCPUに与える影響を見ることができます。逆にボトムアップで見ることで突出したI/OのSLAへの影響を確認できます。

(クリックして拡大)

図3. メトリクスの関連 (トップダウン: QPS, SLA, 入札サービスのパフォーマンス、CPU負荷)

このようにメトリクスをレイヤ状にしたことで開発者はプロジェクトのビジネスサイドを見ることができます。実際、彼らはどこからどのくらいの収益を上げているかを分単位で確認できました。開発者は新しい機能やバグ修正がリリースされたとき、ビジネスダッシュボードの収益のチャートを見ることで、そのリリースが収益にどの程度影響を与えたかを確認することができました。逆に、ビジネスサイドの人々はプロジェクトの技術的な側面を理解し、開発者が直面している課題と同様に負荷の限界を視覚的に把握できました。実際、私たちはさらにもう一段階進んで、MDDをスクラムに組み込んでメトリクスベースで目標を設定しました。最終的に、プロジェクトに関わるすべての人々がプロジェクトのすべての部分について理解することができればすごい成果になるでしょう。

メトリクスを使って意思決定する

すべての活動において最も重要なのは目標とその背後にある根拠に対する知識と理解です。ダッシュボードを作りメトリクスを作っても意思決定に利用されなければ価値がありません。メトリクスの意味や必要性を理解しないまま複数のメトリクスを作成したチームの例をいくつか知っていますが、彼らは意思決定のガイドとしてメトリクスを使うという原則を無視していました。また、アプリケーションがどのように動いているかを知らずに意思決定をするのも悪い例と言えるでしょう。メトリクスを持っているものの、十分な価値を手に入れられていないのです。

MDDの良い所は誤解を最小限にできることです。メトリクスをベースに意思決定をすることで、解釈の余地がなくなります。決定は明確で論理的で説明しやすくなり、論駁しにくくなります。素早く正確に意思決定ができ、チーム雰囲気も改善します。さらに、このような効果はチームを超えて広がります。チーム間のコミュニケーションも感情的ではなくなり、データ駆動になります。開発チームと運用チームの間で起きうる非難合戦も最小限になります。あるいは、完全になくなるかもしれません。

ただし、場合によっては既存のメトリクスを使っても問題の原因を疑えるだけで、それが原因だと証明できない場合もあります。このような場合の解決策は当初の仮定を支持する、あるいは否定するメトリクスを追加で作成することです。

メトリクスを使って意思決定をするのはすべての人にとって利点があります。インフラとアプリケーションのさまざまな側面の情報を提供するという目的以上に、MDDはチーム間の関係を改善するのに役立ちます。

私たちが学んだこと

組織全体にMDDを適用するのは時間がかかります。技術的な変化以上に文化の変化が必要だからです。すべての人が開発プロセスに対する認識や態度、理解を改める必要があります。ビジョンを追求するなかで、私たちもさまざまな成果を得ました。このセクションでは読者の皆さんがMDDを実践する上で役に立つ教訓を紹介します。

私たちが学んだ重要な教訓の第一は、開発チーム向けの環境をスムーズに整えるのに全力を投入し、中間者として振る舞うのを避けることです。私たちは当初、運用チームと開発チームがひとつのメトリクスサーバを共有するようにしました。しかし、上手くいきませんでした。まず、運用チームは開発チームをブロックしてしまい、開発チームがメトリクスを変更するのにいちいち運用チームの許可が必要でした。また、運用チームは開発チームが頻繁にメトリクスを変更するのを快く思っていませんでした。私たちは開発チーム向けの専用サーバを用意し、そこからすべてのサーバ上のメトリクスを触れるようにすることにしました。そのサーバ上から開発チームがリリース作業も特別な許可も必要なく変更できるようにしたのです。そのサーバではほとんどすべてのことができました。サーバを監視から外すこともできました。開発者が自由に変更を決め、実装し責任を取るのは怖いことかもしれませんが、この専用のサーバを用意したことは私たちの決定の中で最良のものでした。

また、'監視の方針'や'監視ツールの要件'を文書化するのに時間を使うのは無駄だということも学びました。方針や実装は変わり続けるからです。メトリクスツールの選定に時間をかけるのも無駄です。ニーズを完全に満たすツールは存在しません。扱いやすいと感じたものを選択するべきです。私たちの場合はZabbixを選びました。ラトビアで開発されているオープンソーのツールです。制限があり画面遷移が複雑ですが、このツールを選んだおかげで迅速に作業を開始することができました。また、データの収集とグラフ化についてのサンプルを用意するのを忘れてはいけません。

皆が見ることができ楽しめるようにするのも重要です。ロビーや作業場にTVを置いて重要なメトリクスを投影するのもいいでしょう。プロジェクト毎の収益をグラフにするのも面白いかもしれません。例えば、ある程度の回数連続してリリースに成功したら報賞するのもいいでしょう(see picture 4). 1日、1週間、1ヶ月あたりの訪問者やトランザクションが最高値に達したらお祝いをします。このような方法を採用することで、関係者は疑問を持ち、質問をしてメトリクスの世界に参加するようになります。単純なグラフを追加することから始めます。そして同僚と一緒にグラフを見てみれば、素晴らしい改善案が思い浮かぶでしょう。

(クリックして拡大)

図4. リリース成功の報賞

MDDに必要な文化的変化はすべての人を怖がらせます。とりわけ開発者は怖がるでしょう。以前は誰も気付かなかったアプリケーションの問題を監視するようになるからです。Adformでは考え方は完全に変わりました。以前は、誰も文句を言っていなければアプリケーションは問題なく動いていると考えていましたが、今はこの考え方はアプリケーションの性能を考える上で良くないと理解しています。今やメトリクスを扱うのは開発者の得意な領域です。皮肉なことに初期の開発チームがメトリクスを見ずにアプリケーションは良好に動いていると感じていたのに対し、今はメトリクスがないと不安を感じています。

現在の関心事と今後の計画

MDDを組織全体に拡大するにつれ、新しい課題が浮かび上がっています。複数のチームが異なるニーズを満たすメトリクスを作成する場合、そのメトリクスの方針や解釈がバラバラになってしまいます。私たちは不要なメトリクスは定期的に削除して、新しいプロジェクトのメトリクスを作成するようにしています。

現在、ガイドラインを作成してすべての開発者が同じ考えを持つようにしようとしています。開発チームは次の3つの質問に答えられなければなりません。

1. アプリケーションが正しく動いていることをどのようにして確かめているか(バグがないだけでは不十分、他の証拠が必要)
2. アプリケーションの性能はどのように推移しているか(最後のリリース前と比べて速くなっているか遅くなっているか。負荷が高いときでも十分な性能が出ているか)
3. アプリケーションはどの程度の頻度で使われているか(何人のユーザが同時にレポート作成をしているか。1日どのくらいのバナーがシステムに発行されているか。どのくらいの回数のトランザクションを受け付けているか)

この3つの問いはすべてのアプリケーションが計測されており、実運用に入る前に均一のレベルでメトリクス化されていることを保証します。

将来の改善案として現在取り組んでいるのは、トラフィックの軽量な監視レイヤ(図5参照) メトリクス駆動のハードウエア性能の見積もりです。

(クリックして拡大)

図5. アプリケーションの信号

メトリクスを使った開発には大きな可能性があります。この方法に組織を巻き込むのは難しいです。しかし、得られるものは巨大です。開発者もビジネス側の人々もアプリケーションとビジネスのパフォーマンスを視覚化し、実際のデータに基づいて意思決定を素早く正確に下すことができます。チーム内のコミュニケーションも改善するでしょう。

著者について

Mantas Klasavi?iusはAdformのインフラストラクチャアーキテクト。Windows、Linux、ネットワーク管理に9年の経験を持つ。現在は、高パフォーマンスコンピューティング、継続的配置、クラウドサービスを専門にしており、監視を利用した開発者の支援に注力している。