Booking.comのエンジニアリングチームは、小規模クラスタで運用していた同社のGraphiteデプロイメントをスケールアップし、毎秒数百万のメトリック処理を可能にした。スケールアップの過程において、同チームは、Graphiteのコアコンポーネントであるcarbon-relay, carbon-cache,レンダリングAPIの修正と最適化を実施した。
Booking.comでは、Graphiteを使って、テクニカルメトリクスとビジネスメトリクスの両方をトラッキングしている。2012年にGraphiteを導入した同社では、当初はRAID 1+0のセットアップを使用していた。このセットアップは同社のデータベースでも使用していたものだが、Graphiteではうまく拡張することができなかった。そのためチームでは、ストレージノード間にトラフィックを分散させる必要性が論じられたが、メンテナンスが困難であるため、RAID 1構成をSSDに切り替えることにした。
デフォルトのcarbon-relayはPythonで記述されていたため、CPUボトルネックに突き当たると同時に、それが単一障害点にもなっていた。チームはこれをCで書き直し、デプロイメントモデルを変更して、各監視対象ホストがひとつずつ所持するようにした。この変更により、より大きなrelayによって支えられた複数のデータセンタのエンドポイントにメトリクスが送信され、障害発生時に備えてローカルにバッファされるようになった。また、サーバ間のメトリクスの不均衡を回避する手段として、一貫性のあるハッシュアルゴリズムを実装したが、新たなストレージノードの追加という問題が残ったため、データセンタ間を同期するためにシェルスクリプトを使用する必要があった。また、ディスクへの書き込み(更新)の頻度が高いため、SSDを常に交換(12～18ヶ月毎)しなければならなかった。ストレージバックエンドとしてHBaseやRiak、Cassandraを検討したことはあったが、取り組みがその後も続けられたかどうかは明らかになっていない。他のエンジニアリングチームの中には、スケーラブルなGraphiteバックエンドとしてCassandraの導入に成功したものもあった。
チームが初期に実施した最適化のひとつはcarbonzipperの導入だった。Booking.comのシステム管理者だったVladimir Smirnov氏の説明によると、これはWebフロントエンドからストレージバックエンドのクラスタへのリクエストをプロキシできるものだ。最終的には、標準のcarbon cacheとチームが書き直したrelayを、Go言語ベースの実装で置き換えなければならなかった。このgo-carbonプロジェクトの成果が、Go言語で記述された現在のgraphite/carbonスタックの実装である。
Booking.comは"Event Graphite Processor"を分散運用しており、イベントストリームからGraphiteメトリクスを生成し、毎秒50万以上のイベントを処理している。イベントストリームはスタック全体にわたって生成され、Riakに格納される。"Booking.comでは、テクノロジスタックの全レイヤでグラフを多用しています。グラフの大部分はイベントから生成されます"と、同社シニアソフトウェアエンジニアのDamien Krotkine氏と、シニアソフトウェア開発者のIvan Paponov氏は述べている。イベント以外でも、さまざまなコレクタやスクリプトが、Booking.comのシステムからメトリクスを収集している。当初はcollectdで始まったが、その後、PythonベースのメトリクスコレクタのDiamondにスイッチされた。メトリクスの命名規則は標準化されたのだろうか？ある程度は。最初にsys.*(システムメトリクス用)とuser.*(テストなど)を予約し、それ以外は開発者にすべてを任せて、使いたいメトリクス名を決定させている。
キャパシティ計画やトラブルシュートとは関係なく、Booking.comでは、"ビジネストレンドをシステムやネットワーク、アプリケーションレベルのトレンドに相関させる"ためにGraphiteを使用している。可視化のためのフロントエンドにはGeafanaを採用している。