ShuttleCloudへのインタビュー

Prometheusのユーザーへのインタビューシリーズの続きとして、ShuttleCloudはPrometheusの使用を開始した経緯について語ります。ShuttleCloudのIgnacioは、PromCon 2016でPrometheusは小規模スタートアップに最適であると題して発表したことについても説明しました。

ShuttleCloudは何をしていますか？

ShuttleCloudは、世界で最もスケーラブルなメールおよび連絡先データインポートシステムです。私たちは、GoogleやComcastなどの大手メールおよびアドレス帳プロバイダーの一部を支援し、データインポートによるスイッチングエクスペリエンスを自動化することで、ユーザーの成長とエンゲージメントを向上させています。

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

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

ShuttleCloudのGoogleのGmailプラットフォームとの統合。 Gmailは、当社のAPIを使用して300万ユーザーのデータをインポートしています。

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

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

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

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

幸いなことに、大口顧客が現れ、SLAがより厳しくなりました。そのため、パフォーマンスを測定し、すべてのSLAを遵守していることを確認するために、別のものが必要になりました。当社が必要とした機能の1つは、パフォーマンスとビジネス指標（つまり、完了した移行の数）に関する正確な統計を持つことでした。そのため、監視よりもレポート作成がより重要でした。

以下のシステムを開発しました。

• 必要なすべてのデータのソースは、CouchDBにあるステータスデータベースです。そこでは、各ドキュメントが操作の1つのステータスを表します。この情報は、ステータスインポーターによって処理され、MySQLデータベースにリレーショナルな形式で保存されます。

• コンポーネントがそのデータベースからデータを収集し、情報が集計され、いくつかのビューに後処理されます。

  • ビューの1つは、レポート作成のために必要だったメールレポートです。これはメールで送信されます。
  • もう一方のビューは、簡単に制御できるダッシュボードにデータをプッシュします。使用していたダッシュボードサービスは外部のものでした。Ducksboardを信頼していたのは、ダッシュボードのセットアップが簡単で見た目が美しかっただけでなく、しきい値に達した場合に自動アラートを提供してくれたからです。

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

当時のシステムにはいくつかの欠点がありました。

• 集中管理された監視システムがない。各メトリックタイプに異なるシステムがありました。
  • システムメトリック → Ansibleによって実行されるスクリプト。
  • ビジネスメトリック → Ducksboardとメールレポート。
  • ブラックボックスメトリック → Pingdom。
• 標準化されたアラートシステムがない。各メトリックタイプに異なるアラート（メール、プッシュ通知など）がありました。
• 一部のビジネスメトリックにはアラートがありませんでした。これらは手動でレビューされていました。

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

いくつかの監視およびアラートシステムを分析しました。ソリューションが成功するか失敗するかを確認するために、すぐに手を動かしたかったのです。テストをすることにしたシステムは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

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

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

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

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

Prometheusはどのようにあなたの状況を改善しましたか？

以前のソリューションと比較することはできません。なぜなら、ソリューションがなかったからです。しかし、Prometheusのどの機能が私たちにとってハイライトであるかについて話すことはできます。

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

ShuttleCloudとPrometheusの将来はどうなると思いますか？

Prometheusには非常に満足していますが、新しいエクスポーター（たとえばCeleryやSpark）はいつでも歓迎です。

新しいアラームを追加するたびに直面する質問があります。アラームが期待どおりに機能することをどのようにテストしますか？アラームを発生させてテストできるように、偽のメトリックを注入する方法があると便利でしょう。