iAdvize へのインタビュー

Prometheus ユーザーへのインタビューシリーズを継続し、iAdvize の Laurent COMMARIEU が、レガシーな Nagios と Centreon の監視を Prometheus にどのように置き換えたかについて語ります。

iAdvize がどのような事業を行っているか教えていただけますか？

私は iAdvize のシステムエンジニア、Laurent COMMARIEU です。5人のシステムエンジニアからなるチームで、60人規模の研究開発部門に所属しています。私たちの主な仕事は、アプリケーション、サービス、および基盤となるシステムが稼働していることを保証することです。開発者と協力して、彼らのコードが本番環境にスムーズにデプロイされるようにし、各段階で必要なフィードバックを提供しています。そこで監視が重要になります。

iAdvize は、フルスタックの会話型コマースプラットフォームです。ブランドが、コミュニケーションチャネル（チャット、電話、ビデオ、Facebookページ、Facebook Messenger、Twitter、Instagram、WhatsApp、SMSなど）に関係なく、顧客と一元的にやり取りできる簡単な方法を提供しています。お客様は、eコマース、銀行、旅行、ファッションなどの40カ国で事業を展開しています。私たちは、フランス、イギリス、ドイツ、スペイン、イタリアにオフィスを持つ200人の従業員からなる国際的な企業です。2015年には1600万ドルの資金調達を行いました。

Prometheus導入前のモニタリング経験について教えてください。

私は2016年2月にiAdvizeに入社しました。それ以前は、ネットワークおよびアプリケーション監視を専門とする企業で働いていました。私たちは、Nagios、Cacti、Centreon、Zabbix、OpenNMSなど、オープンソースソフトウェアや、HP NNM、IBM Netcool suite、BMC Patrolなどの商用ソフトウェアも扱っていました。

iAdvize は、監視を外部プロバイダーに委託していました。彼らは Nagios と Centreon を使用して24時間365日の監視を行っていました。このツールセットは、レガシーな静的なアーキテクチャ（ベアメタルサーバー、VMやコンテナなし）ではうまく機能していました。この監視スタックを補完するために、Pingdomも使用していました。

モノリシックなアプリケーションをマイクロサービスアーキテクチャ（Dockerを使用）に移行し、現在のワークロードをインフラストラクチャクラウドプロバイダーに移行したいという意向から、監視に対するより多くの制御と柔軟性が必要になりました。同時に、iAdvize は3人を採用し、インフラストラクチャチームは2人から5人に増えました。以前のシステムでは、Centreon に新しいメトリクスを追加するのに数日または1週間かかり、実質的なコスト（時間とお金）がかかっていました。

Prometheusを検討することにした理由は何ですか？

Nagiosのようなものが良い選択ではないことはわかっていました。Prometheus は当時注目の的であり、PoC（概念実証）を行うことにしました。Sensuも当初リストにありましたが、Prometheus の方が我々のユースケースにとってより有望に見えました。

サービスディスカバリシステムである Consul と統合できるものが必要でした。マイクロサービスにはすでに /health ルートがあり、/metrics エンドポイントを追加するのは簡単でした。我々が使用していたほぼすべてのツールについて、エクスポーターが利用可能でした（MySQL、Memcached、Redis、nginx、FPMなど）。

理論上はうまくいきました。

どのように移行しましたか？

まず、Prometheus が適切なツールであり、開発者がアプリケーションにエクスポーターを追加する必要があることを、開発者チーム（40人）に納得させる必要がありました。そこで、RabbitMQ のデモを行い、RabbitMQ エクスポーターをインストールし、開発者に利用状況メトリクスを表示するためのシンプルなGrafanaダッシュボードを構築しました。キューを作成し、メッセージを送受信するための Python スクリプトも作成しました。

キューとメッセージがリアルタイムで表示されるのを見て、彼らは非常に感銘を受けていました。それまで、開発者は監視データにアクセスできませんでした。Centreon は、インフラストラクチャプロバイダーによって制限されていました。今日、Grafana は iAdvize の全員が利用でき、Google Auth 連携を使用して認証しています。78のアクティブアカウントがあります（開発チームから CEO まで）。

Consul と cAdvisor を使用して既存のサービスを監視し始めた後、コンテナの実際の存在を監視しました。これらは Pingdom チェックで監視されていましたが、十分ではありませんでした。

データベース（MySQL および Redis）からビジネス指標をスクレイピングするために、Go でいくつかのカスタムエクスポーターを開発しました。

すぐに、レガシーな監視をすべて Prometheus で置き換えることができるようになりました。

切り替え以降、どのような改善が見られましたか？

ビジネス指標は非常に人気があり、セール期間中は誰もが Grafana に接続して、記録を更新できるかどうかを確認しています。同時会話数、ルーティングエラー、接続中のエージェント、iAdvize タグを読み込んでいる訪問者数、APIゲートウェイへの呼び出し数などを監視しています。

私たちは、Newrelic exporterおよび [Percona dashboard for grafana]（https://github.com/percona/grafana-dashboards）に基づいた分析により、MySQL サーバーの最適化に1ヶ月間取り組みました。これは実質的な成功であり、非効率性を発見し、データベースサイズを45%、ピークレイテンシーを75%削減する最適化を実行することができました。

語るべきことはたくさんあります。AMQPキューにコンシューマーがない場合や、異常に増加している場合がわかります。コンテナが再起動したときもわかります。

可視性はとにかく素晴らしいです。

それはレガシープラットフォームに関するものでした。

ますます多くのマイクロサービスがクラウドにデプロイされるようになり、Prometheus はそれらを監視するために使用されています。サービスを登録するために Consul を使用し、メトリクスルートを検出するために Prometheus を使用しています。すべてが順調に機能しており、多くの重要なビジネス、アプリケーション、およびシステムメトリクスを含む Grafana ダッシュボードを構築することができます。

私たちは、Nomadでサービスをデプロイするためのスケーラブルなアーキテクチャを構築しています。Nomad は正常なサービスを Consul に登録し、タグのリレーベル付けにより、「metrics=true」というタグ名を持つものをフィルタリングできます。これにより、監視のデプロイにかかる時間が大幅に短縮されます。何もする必要がありません^^。

EC2 のサービスディスカバリも使用しています。これはオートスケーリンググループで非常に役立ちます。インスタンスをスケールアウト/インしたりリサイクルしたりしても、すぐに監視されます。外部インフラストラクチャプロバイダーが本番環境で何が起こっているかに気づくのを待つ必要はもうありません。

alertmanager を使用して、SMS またはFlowdockにアラートを送信しています。

iAdvize と Prometheus の将来について、どのようにお考えですか？

• キャパシティプランニングのための、長期かつスケーラブルなストレージを追加する簡単な方法を待っています。
• いつか、オートスケーリングが Prometheus のアラートによってトリガーされるようになることを夢見ています。応答時間とビジネス指標に基づいた自律的なシステムを構築したいと考えています。
• 以前、Netuitiveで作業していましたが、これには自動相関を備えた優れた異常検知機能がありました。Prometheus にもそのような機能があれば素晴らしいでしょう。