世界最大のデジタルフェスティバル「DreamHack」の監視

2015年6月24日筆者: Christian Svensson (DreamHackネットワークチーム)

編集者注：この記事はPrometheusユーザーによって書かれたゲスト投稿です。

数万人の要求の厳しいゲーマーのためにネットワークを運用しているなら、ネットワークの内部で何が起こっているかを真に知る必要があります。ああ、そしてすべてをたった5日間でゼロから構築する必要があります。

DreamHackについて以前聞いたことがないなら、こちらが説明です。2万人を集め、その大半が自分のコンピューターを持参します。プロのゲーミング（eSports）、プログラミングコンテスト、ライブミュージックコンサートを組み合わせます。その結果、すべてデジタルに特化した世界最大のフェスティバルが生まれます。

このようなイベントを可能にするには、多くのインフラストラクチャが必要です。この規模の通常のインフラストラクチャは構築に数ヶ月かかりますが、DreamHackのスタッフはすべてをたった5日間でゼロから構築します。これにはもちろん、ネットワークスイッチの設定などの作業が含まれますが、電力配線の構築、飲食店の設置、さらには実際のテーブルの構築なども含まれます。

ネットワークに関連するすべてを構築・運用するチームは公式にはネットワークチームと呼ばれていますが、私たちは通常、自分たちをtechまたはdhtechと呼んでいます。この投稿では、dhtechの仕事と、DreamHack Summer 2015でPrometheusを使用して監視をさらに一歩進めようとした方法に焦点を当てます。

設備

1万台以上のコンピューター向けに高性能ネットワークを構築するには、少なくとも同数のネットワークポートが必要になることが判明しました。私たちの場合、これらは約400台のCisco 2950スイッチの形で提供されます。これらをアクセススイッチと呼んでいます。これらは、参加者がコンピューターを設置する会場のいたるところにあります。

*整列して任務を遂行するアクセススイッチは、高速接続でDreamHackerを迎える準備ができています。*

もちろん、これらのすべてのコンピューターをスイッチに接続するだけでは十分ではありません。そのスイッチも他のスイッチに接続されている必要があります。ここでディストリビューションスイッチ（またはディストスイッチ）が登場します。これらは、すべてのアクセススイッチからの数百のリンクを受け取り、より管理しやすい10ギガビット/秒の大容量ファイバーに集約するスイッチです。ディストスイッチは、さらにコアに集約され、そこでトラフィックが目的地にルーティングされます。

これらすべてに加えて、私たちは独自のWiFiネットワーク、DNS/DHCPサーバー、その他のインフラストラクチャを運用しています。完成すると、私たちのコアは以下の画像のようになります。

*ディストリビューション層とコア層の計画マップ。コアは「ホールD」にはっきりと見えます。*

全体として、これは監視するものの長いリストになりつつあります。では、皆さんがここにいる理由、つまり「何が起こっているのかをどうやって確認しているのか」に移りましょう。

導入：dhmon

dhmonは、ネットワークを監視するだけでなく、他のチームが任意のメトリクスを収集できるようにするシステムの総称です。

ネットワークを5日間で構築する必要があるため、監視システムは、インフラストラクチャの変更（デバイスの追加や削除など）を土壇場で行う必要がある場合に、簡単にセットアップし、同期を保つことが不可欠です。ネットワークの構築を開始するときは、機器の不具合や予期していなかった問題をできるだけ早く発見できるように、できるだけ早く監視を開始する必要があります。

過去には、Cacti、SNMPc、Opsviewなどの一般的に利用可能なソフトウェアを組み合わせて使用しようとしました。これらは機能しましたが、クローズドシステムであることに焦点を当て、必要最低限のものしか提供しませんでした。数年前、チームの数人が「もう十分だ、自分たちでもっと良いものができる！」と言って、カスタム監視ソリューションの作成を開始しました。

当時、選択肢は限られていました。数年の間に、システムはGraphite（スケーラビリティの問題）、カスタムのCassandraストア（高い複雑性）、InfluxDB（未熟なソフトウェア）から最終的にPrometheusを使用することになりました。私は2014年にJulius Volzに会ったときに初めてPrometheusを知り、それ以来試してみたいと思っていました。この夏、私たちはついに、InfluxDBベースのカスタムメトリクスストアをPrometheusに置き換えました。ネタバレ：もう後戻りすることはありません。

アーキテクチャ

監視ソリューションは、収集、保存、表示の3つの層で構成されています。最も重要なコレクターはsnmpcollector（SNMP）とipplan-pinger（ICMP）で、それにdhcpinfo（DHCPリース統計）が続きます。また、他のシステムの統計情報をnode_exporterのtextfileコレクターにダンプするスクリプトもいくつかあります。

*2015年夏時点のdhmonの現在のアーキテクチャプラン*

Prometheusを中央の時系列ストレージおよびクエリエンジンとして使用していますが、収集するバイナリ情報（Prometheusに合理的な方法で保存できない場合や、非常に新しいデータにアクセスする必要がある場合）のスナップショットビューをエクスポートするためにRedisとmemcachedも使用しています。

そのようなケースの1つが、プレゼンテーション層にあります。dhmap Webアプリケーションを使用して、アクセススイッチ全体の健全性を把握しています。エラーを効果的に解決するためには、データ収集からプレゼンテーションまで約10秒のレイテンシが必要です。私たちの目標は、顧客が気づく前、または少なくともサポート担当者に問題を報告するために歩いて行く前に問題を解決することです。このため、当初からmemcachedを使用してネットワークの最新スナップショットにアクセスしていました。

今年は低レイテンシデータにはmemcachedを引き続き使用し、履歴データやレイテンシにそれほど敏感でないすべてのデータにはPrometheusを使用しました。この決定は、Prometheusが非常に短いサンプリング間隔でどのように動作するかわからなかったため、単純に行われました。しかし最終的に、このデータにもPrometheusを使用できない理由はないとわかりました。次のDreamHackでは間違いなくmemcachedをPrometheusに置き換えることを試みます。

*dhmonによって可視化されたアクセス層の概要*

Prometheusセットアップ

これまで「Prometheus」と呼ばれてきたブロックは、実際には3つの製品で構成されています。Prometheus、PromDash、そしてAlertmanagerです。セットアップは非常に基本的なもので、3つのコンポーネントすべてが同じホストで実行されています。すべてはリバースプロキシとして機能するApache Webサーバーによって提供されています。

ProxyPass /prometheus https://:9090/prometheus
ProxyPass /alertmanager https://:9093/alertmanager
ProxyPass /dash https://:3000/dash

ネットワークの探索

Prometheusには強力なクエリエンジンがあり、ネットワーク全体から収集されたストリーミング情報を使って非常にクールなことができます。しかし、時にはクエリが処理するデータ量が多すぎて、合理的な時間内に完了しないことがあります。これは、合計約18,000のリンクから使用率の高い上位5つのリンクをグラフ化しようとしたときに発生しました。クエリは機能しましたが、タイムアウト制限に設定した時間とほぼ同じ時間がかかり、遅くて不安定でした。そこで、重いクエリを事前計算するためにPrometheusの記録ルールを使用することにしました。

precomputed_link_utilization_percent = rate(ifHCOutOctets{layer!='access'}[10m])*8/1000/1000
                                         / on (device,interface,alias)
                                       ifHighSpeed{layer!='access'}

この後、`topk(5, precomputed_link_utilization_percent)` を実行すると、驚くほど高速でした。

リアクティブであること: アラート

この段階で、ネットワークの状態を問い合わせるものができました。しかし、私たちは人間なので、物事が正常に動作しているかどうかを常にクエリを実行して確認するのに時間を費やしたくありません。そのため、当然のことながらアラートが必要です。

例：すべてのアクセススイッチがアップリンクとしてGigabitEthernet0/2を使用していることを知っています。ネットワークケーブルが長く保管されていたために酸化し、希望するフル1000Mbpsでネゴシエートできないことがあります。

ネットワークポートのネゴシエートされた速度は、SNMP OID `IF-MIB::ifHighSpeed` で確認できます。しかし、SNMPに詳しい人なら、このOIDが任意のインターフェースインデックスによってインデックス付けされていることを認識するでしょう。このインデックスを理解するためには、実際のインターフェース名を取得するためにSNMP OID `IF-MIB::ifDescr` のデータと相互参照する必要があります。

幸いなことに、私たちのsnmpcollectorは、Prometheusメトリクスを生成する際に、このような相互参照をサポートしています。これにより、データをクエリするだけでなく、便利なアラートを簡単に定義できます。私たちの設定では、SNMPコレクションを構成して、`IF-MIB::ifTable` および `IF-MIB::ifXTable` OIDの下のすべてのメトリクスに `ifDescr` をアノテーション付けしました。これは、`GigabitEthernet0/2` ポートのみに関心があり、他のインターフェースには関心がないことを指定する必要がある場合に役立ちます。

そのようなアラート定義がどのようなものか見てみましょう。

ALERT BadUplinkOnAccessSwitch
  IF ifHighSpeed{layer='access', interface='GigabitEthernet0/2'} < 1000 FOR 2m
  SUMMARY "Interface linking at {{$value}} Mbps"
  DESCRIPTION "Interface {{$labels.interface}} on {{$labels.device}} linking at {{$value}} Mbps"

完了！これで、スイッチのアップリンクが突然最適でない速度でリンクした場合にアラートが届きます。

また、DHCPスコープがほぼ満杯になったときのアラートがどのようなものかも見てみましょう。

ALERT DhcpScopeAlmostFull
  IF ceil((dhcp_leases_current_count / dhcp_leases_max_count)*100) > 90 FOR 2m
  SUMMARY "DHCP scope {{$labels.network}} is almost full"
  DESCRIPTION "DHCP scope {{$labels.network}} is {{$value}}% full"

Prometheusや時系列データベースの経験がなくても、アラート定義の構文は読みやすく理解しやすいと感じました。

*おっと！不良アップリンクがあることが判明しました。すぐに修正しに行きましょう！*

プロアクティブであること：ダッシュボード

アラートは監視の不可欠な部分ですが、時にはネットワークの健全性を全体的に把握したいだけの場合もあります。これを実現するために、PromDashを使用しました。誰かがネットワークについて何か質問するたびに、その答えを得るためのクエリを作成し、ダッシュボードウィジェットとして保存しました。最も興味深いものは、誇らしげに表示する概要ダッシュボードに追加されました。

*PromDashを搭載したDreamHack概要ダッシュボード*

未来

どのようなシステムにおいても不可欠な部分を変更することは複雑な作業であり、Prometheusをたった1つのイベントに統合できたことを嬉しく思いますが、改善すべき点は間違いなくたくさんあります。一部の領域は非常に基本的です。パフォーマンス向上のためにより多くの事前計算済みメトリクスを使用したり、アラートを追加したり、既存のアラートを調整したりすることです。別の領域は、オペレーターにとってより簡単にすることです。ネットワークオペレーションセンター（NOC）に適したアラートダッシュボードを作成したり、オンコールの担当者にページングするか、NOCにアラートをエスカレートさせるかを検討したりすることです。

追加を計画しているより大きな機能としては、syslog分析（大量のsyslogがあります！）、侵入検知システムからのアラート、Puppetセットアップとの統合、そしてDreamHack内の異なるチーム間でのさらなる統合があります。私たちは、電流センサーの1つから監視システムにデータを取り込む概念実証を作成することに成功しました。これにより、デバイスが故障しているのか、単に電力が供給されていないのかを簡単に確認できるようになりました。また、イベントの店舗で使用されているPOSシステムとの統合にも取り組んでいます。アイスクリームの売り上げをグラフ化したいと思わない人がいるでしょうか？

最後に、チームが運営するすべてのサービスがオンサイトにあるわけではなく、イベント後も24時間365日稼働しているものもあります。これらのサービスもPrometheusで監視したいと考えており、長期的にはPrometheusがフェデレーションをサポートするようになったら、オフサイトのPrometheusを利用してイベントのPrometheusからメトリクスを複製する予定です。

結びの言葉

Prometheusと、それがスケーラブルな監視とアラートをゼロから設定することをいかに容易にするかに、私たちは本当に興奮しています。

イベント中、FreeNodeの`#prometheus`で私たちを助けてくれたすべての人に感謝します。Brian Brazil、Fabian Reinartz、Julius Volzには特に感謝します。ドキュメントを十分に読んでいなかったことが明らかだった場合でも助けてくれてありがとう。

最後に、dhmonはすべてオープンソースなので、興味があればhttps://github.com/dhtech/にアクセスして見てください。参加したいと思ったら、QuakeNetの`#dreamhack`にアクセスして、私たちとチャットしてください。もしかしたら、次のDreamHackの構築を手伝ってくれるかもしれませんね？