iAdvizeとのインタビュー

Prometheusユーザーへのインタビューシリーズを続け、iAdvizeのLaurent COMMARIEU氏が、従来のNagiosとCentreonによる監視をPrometheusに置き換えた経緯について語ります。

iAdvizeについて教えていただけますか？

私はiAdvizeのシステムエンジニア、Laurent COMMARIEUです。60人規模のR&D部門で、5人のシステムエンジニアチームの一員として働いています。私たちの主な仕事は、アプリケーション、サービス、および基盤となるシステムが稼働していることを確認することです。開発者と協力して、コードを本番環境に最も簡単に移行できるようにし、あらゆる段階で必要なフィードバックを提供しています。ここで監視が重要になります。

iAdvizeは、フルスタックの会話型コマースプラットフォームです。ブランドが、チャット、通話、ビデオ、Facebookページ、Facebookメッセンジャー、Twitter、Instagram、WhatsApp、SMSなど、どのようなコミュニケーションチャネルであっても、顧客と一元的に簡単にやり取りできる方法を提供します。当社の顧客は、40か国のEコマース、銀行、旅行、ファッションなどで事業を展開しています。フランス、イギリス、ドイツ、スペイン、イタリアにオフィスを構える200人の従業員を擁する国際企業です。2015年には1600万ドルを調達しました。

Prometheus導入以前の監視経験について教えてください。

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

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

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

Prometheusの検討を決めたのはなぜですか？

Nagiosのようなものは良い選択ではないと分かっていました。Prometheusは当時台頭してきていたので、PoCを行うことにしました。Sensuも当初は候補に挙がっていましたが、Prometheusの方が私たちのユースケースにはより有望に見えました。

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

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

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

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

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

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

Goでいくつかのカスタムエクスポーターを開発し、データベース（MySQLとRedis）からビジネスメトリクスをスクレイピングしました。

ほどなく、すべてのレガシー監視をPrometheusに置き換えることができました。

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

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

Newrelicエクスポーターと[Grafana用Perconaダッシュボード] (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にもそのような機能があれば素晴らしいと思います。