ShuttleCloud とのインタビュー

2016年9月7日筆者: ブライアン・ブラジル

Prometheus ユーザーへのインタビューシリーズを続けています。今回は ShuttleCloud がどのように Prometheus を使い始めたかについて語ります。ShuttleCloud のイグナシオは、PromCon 2016 での講演「Prometheus はあなたの小さなスタートアップに良い」で、その方法も説明しました。

ShuttleCloudは何をしていますか？

ShuttleCloud は、世界で最もスケーラブルなメールおよび連絡先データインポートシステムです。Google や Comcast を含む主要なメールおよびアドレス帳プロバイダーが、データインポートによる切り替え体験を自動化することで、ユーザーの増加とエンゲージメントを向上させるのに貢献しています。

当社の API を自社のサービスに統合することで、お客様はユーザーがメールや連絡先をある提携プロバイダーから別のプロバイダーに簡単に移行できるようにし、新しいプロバイダーに切り替える際にユーザーが直面する摩擦を軽減しています。24時間365日対応のメールプロバイダーには、Comcast、Time Warner Cable、AT&T、Verizon など、すべての主要な米国のインターネットサービスプロバイダーが含まれます。

エンドユーザーにメール移行の簡単なパスを提供することで（インポートツールの UI を完全に制御できるようにしながら）、お客様はユーザーのアクティベーションとオンボーディングを劇的に改善しています。

ShuttleCloud's integration with Gmail ShuttleCloud と Google の Gmail プラットフォームとの統合。 Gmail は当社の API を使用して 300 万人のユーザーのデータをインポートしました。

ShuttleCloud のテクノロジーは、インポート処理に必要なすべてのデータを暗号化し、さらに最も安全な標準（SSL、oAuth）に従って API リクエストの機密性と完全性を確保しています。当社のテクノロジーにより、最大 99.5% の稼働率保証でプラットフォームの高い可用性を保証できます。

ShuttleCloud by Numbers

Prometheus 導入前の監視経験はどのようなものでしたか？

当初、当社のインフラストラクチャに対する適切な監視システムは、主要な優先事項の一つではありませんでした。現在ほど多くのプロジェクトやインスタンスがなかったため、何かが正常に動作していない場合に警告し、それを制御下に置くための他のシンプルなシステムを使用していました。

私たちは、マシンに関するほとんどの運用メトリクスを監視するための自動スクリプトのセットを持っていました。これらは cron ベースで、中央のマシンから Ansible を使用して実行されていました。アラートは開発チーム全体に直接送信されるメールでした。
外部のブラックボックス監視と、すべてのフロントエンドが稼働しているかどうかの確認には Pingdom を信頼していました。彼らは、外部サービスに到達できない場合に備えて、簡単なインターフェースとアラートシステムを提供してくれました。

幸いなことに、大口顧客が到来し、SLA はより要求が厳しくなり始めました。そのため、パフォーマンスを測定し、すべての SLA を遵守していることを確認するための何らかの対策が必要になりました。私たちが必要としていた機能の一つは、パフォーマンスとビジネスメトリクス（つまり、何件の移行が正常に完了したか）に関する正確な統計情報を持つことであり、監視よりもレポート作成に重点を置いていました。

私たちは以下のシステムを開発しました

Initial Shuttlecloud System

必要なすべてのデータのソースは、CouchDB のステータスデータベースです。そこでは、各ドキュメントがオペレーションの 1 つのステータスを表します。この情報はステータスインポーターによって処理され、リレーショナルな方法で MySQL データベースに格納されます。
コンポーネントがそのデータベースからデータを収集し、情報が集約され、いくつかのビューに後処理されます。
- ビューの一つは、レポート作成のために必要だったメールレポートです。これはメールで送信されます。
- もう一つのビューはデータをダッシュボードにプッシュし、そこで簡単に制御できます。使用したダッシュボードサービスは外部のものでした。Ducksboard を信頼したのは、ダッシュボードの設定が簡単で見た目も美しかっただけでなく、しきい値に達した場合に自動アラートを提供してくれたからです。

これらすべてが整った状況で、プロジェクトの数が増え始めるにつれて、適切なメトリクス、監視、およびアラートシステムが必要になることに気づくのに時間はかかりませんでした。

当時使用していたシステムの欠点は以下の通りです

中央集中型監視システムがない。各メトリクスタイプに異なるシステムがあった。
- システムメトリクス → Ansible で実行されるスクリプト。
- ビジネスメトリクス → Ducksboard とメールレポート。
- ブラックボックスメトリクス → Pingdom。
標準的なアラートシステムがない。各メトリクスタイプに異なるアラート（メール、プッシュ通知など）があった。
一部のビジネスメトリクスにはアラートがなかった。これらは手動で確認されていた。

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

いくつかの監視およびアラートシステムを分析しました。私たちは、あるソリューションが成功するか失敗するかを実際に試してみたいと熱望していました。私たちが試すことを決定したシステムは Prometheus であり、その理由は以下の通りです

まず第一に、作業を開始するために固定のメトリックシステムを定義する必要はありません。メトリックは将来的に追加または変更できます。これにより、まだ監視したいすべてのメトリックが不明な場合に、貴重な柔軟性が得られます。
Prometheusについてご存知であれば、メトリクスには異なる時系列が考慮されるという事実から抽象化されたラベルを持つことができることをご存知でしょう。これは、そのクエリ言語と相まって、さらに柔軟性と強力なツールを提供しました。たとえば、異なる環境やプロジェクトに対して同じメトリクスを定義し、特定の時系列を取得したり、適切なラベルで特定のメトリクスを集計したりできます。
- http_requests_total{job="my_super_app_1",environment="staging"} - アプリ "my_super_app_1" のステージング環境に対応する時系列。
- http_requests_total{job="my_super_app_1"} - アプリ "my_super_app_1" のすべての環境に対する時系列。
- http_requests_total{environment="staging"} - すべてのジョブのすべてのステージング環境に対する時系列。
PrometheusはサービスディスカバリのためにDNSサービスをサポートしています。私たちは偶然にもすでに社内DNSサービスを持っていました。
外部サービスをインストールする必要はありません（たとえば、RedisのようなデータストレージサービスとRabbitMQのようなメッセージバスを必要とするSensuとは異なります）。これは決定的な要因ではないかもしれませんが、テストをより簡単に行い、デプロイ、維持するのに役立つことは間違いありません。
Prometheus のインストールは非常に簡単で、Go の実行可能ファイルをダウンロードするだけです。Docker コンテナも正常に動作し、簡単に起動できます。

Prometheus をどのように使用していますか？

当初、私たちはnode_exporterによって提供される一部のメトリクスのみを使用していました。

ハードドライブの使用量。
メモリ使用量。
インスタンスが稼働しているか停止しているか。

当社の内部 DNS サービスはサービスディスカバリのために統合されているため、すべての新しいインスタンスは自動的に監視されます。

node_exporter がデフォルトで提供していない一部のメトリクスは、node_exporter の textfile collector機能を使用してエクスポートされました。Prometheus Alertmanager で宣言した最初のアラートは、主に上記の運用メトリクスに関連していました。

その後、システムの状況をほぼリアルタイムで把握できるオペレーションエクスポーターを開発しました。これは、すべてのオペレーションのステータス、受信移行数、完了移行数、エラー数などのビジネスメトリクスを公開しました。これらを Prometheus 側で集約し、さまざまなレートを計算させることができました。

以下のメトリクスをエクスポートして監視することにしました

operation_requests_total
operation_statuses_total
operation_errors_total

Shuttlecloud Prometheus System

当社のサービスのほとんどは、2つのGoogle Cloud Platformのアベイラビリティゾーンに複製されています。これには監視システムも含まれます。2つ以上の異なるゾーンに複数のオペレーションエクスポーターを配置するのは簡単です。Prometheusはそれらすべてのデータを集約して1つのメトリクス（つまり、すべての最大値）を作成できるからです。現在、PrometheusやAlertmanagerはHA構成ではありません。メタリモニタリングインスタンスのみですが、これに取り組んでいます。

外部のブラックボックス監視には、Prometheus のBlackbox Exporterを使用しています。外部フロントエンドが稼働しているかどうかの確認だけでなく、SSL証明書の有効期限のメトリクスを取得するのに特に役立ちます。証明書のチェーン全体もチェックします。Robust Perception がブログ記事で完璧に説明してくれています。

いくつかのダッシュボードで視覚的な監視のために Grafana にいくつかのグラフを設定しましたが、Prometheus との統合は簡単でした。グラフを定義するために使用されるクエリ言語は Prometheus と同じであり、その作成を大幅に簡素化しました。

Prometheus と Pagerduty を統合し、重要なアラートのためのオンコールのスケジュールを作成しました。重要ではないと判断されたアラートについては、メールのみを送信しました。

Prometheus はどのように状況を改善してくれましたか？

以前は監視ソリューションがなかったので Prometheus と比較することはできませんが、Prometheus のどの機能が私たちにとって優れているかについて話すことができます。

メンテナンス要件が非常に少ないです。
効率的です。1台のマシンでクラスタ全体の監視を処理できます。
コミュニティは開発者もユーザーも友好的です。さらに、Brian のブログは非常に良い情報源です。
サードパーティの要件はありません。サーバーとエクスポーターのみです。（RabbitMQ や Redis を維持する必要はありません。）
Go アプリケーションのデプロイは簡単です。

ShuttleCloud と Prometheus の将来はどうなるとお考えですか？

Prometheus には非常に満足していますが、新しいエクスポーター（例えば Celery や Spark）は常に歓迎されます。

新しいアラームを追加するたびに直面する疑問の一つは、アラームが期待通りに機能するかをどのようにテストするかです。アラームを発生させるために偽のメトリクスを注入する方法があれば、テストに役立つでしょう。