DeNA ネットワーク運用監視ツールの紹介 [DeNA インフラ SRE]

はじめに

こんにちは。IT基盤ネットワークグループの守屋と申します。主に社内のネットワーク、CDN (Content Delivery Network)関連の業務を担当しています。

今までのブログではネットワークグループで採用しているサービスや、ネットワーク移行についてご紹介してきましたが、今回は DeNA のネットワーク運用監視で使用してるツールをご紹介いたします。

DeNA のネットワークについて

ネットワークは障害や品質が悪いと複数のサービスやユーザに影響を与えます。そのため、24/365体制で、業務を円滑に進められるようなネットワークを運用監視することがネットワークグループの基本方針となります。ただし、リソースは有限なため Quality（品質）、Cost（コスト）、Delivery（納期）を最適にすることは常に意識しています。たとえば、オーバースペックな製品を購入して運用コストを上げないことや、必要以上にメンバーの運用負荷が高くならないように注意しています。

ネットワークグループの運用の範囲は主にクラウド・オフィス・データセンター（小規模）となります。規模感としては 2024/10 時点で 20 拠点以上のオフィスと店舗のネットワークで、トータルの利用者数は 3000 名程度のものとなります。サービス側のネットワークに関しては、ほぼすべてのサーバがクラウドに移行しているので、事業部側で管理をしています。ただし、サービス側のクラウド環境と社内ネットワークへの接続箇所はネットワークグループで管理をしています。

アラート対応について

アラート対応はネットワーク運用において非常に重要なものです。障害やネットワーク品質の悪化を検知して、それを即時に対応するのはユーザの満足度にも直結するので、ネットワーク運用における重要な指標のひとつにしています。

ただし、すべてのアラートに対して即時対応するのはチームメンバーに対する負荷が必要以上に高くなる可能性があります。そのため、アラートに対する緊急度を定義しており、緊急度が高いものに対しては即時対応、緊急度が低いものに関しては日勤帯対応にするようにし、運用負荷を最適化するようにしています。たとえば、ファイアーウォールやコアスイッチなどの重要な機器のアラートは緊急度が高いため即時に対応し、深夜帯のオフィスの通信遅延は業務影響が少ないものは緊急度が低いため日勤帯での対応する、などのようにしています。

ネットワーク運用監視について

DeNA ネットワークグループでは、ネットワークの品質を確保するために以下のような監視をしています。オフィスネットワークでスマートフォンを使用した検証作業などがあり、ネットワーク品質が悪いと開発効率に影響します。そのため、通信品質に関しても細かく見るようにしています。

死活監視
メトリック監視
ログ監視
通信品質監視
コンフィグ監視

また、アラートが発報されないような長期的なトレンド（e.g. トラフィック、利用者数の傾向など）を確認するために月次でネットワーク状況の確認しています。ネットワークグループ全体で２時間程度の MTG を開催し、各拠点のネットワークの状況を確認し、ネットワークリソースが不足していないかなどを確認しています。

死活監視、メトリック監視

ネットワーク機器障害やリソースの逼迫を検知するために、死活監視とメトリック監視をしています。

ネットワーク機器の死活監視は ICMP で行っており一定時間応答がない場合にアラートを発報しますが、一部のアラートは利用者に直接送信するようにしています。たとえば、執務室に設置してある小型のスイッチ等は利用者による電源ケーブルの誤抜きなどで落ちることが多々あるため、利用者に直接アラートを送信して対応していただくようにしています。

ネットワーク機器のメトリック監視には SNMP を利用し、リソースの逼迫( e.g. トラフィックや CPU の高騰など ) を検知した際にアラートを発報するようにしています。メトリック監視でもアラートの緊急度を定義しており、即時対応するものと、日勤帯中に対応するもの2つの優先度を定義して運用負荷を高くならないようにしています。

なお、無線は有線よりもサービス品質の低下するような異常を検知するのが難しいので、細かいメトリックを監視するようにしています。主に監視しているのは、アクセスポイントのクライアントとトラフィック、無線全体の混雑状況と遅延状況ですが、既知のバグでアクセスポイントに不具合が発生することもあるので、メトリックを分析してアラートを発報するようなスクリプトも内製しています。

上記の死活監視、メトリック監視には Prometheus を使用しており、 Grafana と連携して可視化もしています。 Prometheus による死活監視、メトリック監視の構成は下図のようになり、 AWS EC2 上に構築しています。

また、社内ネットワークに問題が発生していないかを確認できるステータスページをユーザに提供して問い合わせの数を減らすような工夫をしています。オフィスから通信がうまく行かないときにユーザが問題を自力で切り分けられるようにしています。チェック項目は、オフィスから以下の対象と ICMP で疎通が取れているかで、1 分以上の通信断が発生した場合は赤色のセルを表示し、それ以外は緑色のセルを表示させるようにしています。

アクセスポイント
インターネット
クラウド
データセンター

実際のステータスページは以下のような画面になります。この場合はすべて緑色のセルとなっているので、通信断は発生しておらず、ネットワークに問題がないことを確認できます。

ログ監視

ネットワーク機器のエラーや異常な挙動(e.g. バグ起因の障害)を検知するためにログ監視をしています。ネットワーク機器のログは Syslog で出力しており、監視には Loki を使用しています。 AWS のインスタンス上に監視サーバで構築しており、メトリック監視と同様に可視化には Grafana 利用しています。

ログ監視の方針は企業によってさまざまだと思いますが、DeNA ではブラックリスト方式でログを監視しています。基本的に Severity でアラートの通知するか否かを判断し、通知する場合でも時間帯によって送信する宛先を分けています。一部のメッセージは検知しても対応不要のものがあるので、そのようなアラートに関しては日々の運用でログを無視するようにしています。また、アラートが大量に出た場合は、アラートをひとつにまとめて通知するようにしており、大量のアラートでメールを埋め尽くすようなことは発生しないようにしています。

上記のログ監視は Loki の監視の構成は下図のようになり、 AWS EC2 上に構築しています。各要素の詳細については割愛いたしますので、興味のある方は Loki の公式サイト等をご参照頂けると幸いです。

通信品質監視

拠点間通信、拠点とインターネット間の通信品質の悪化を検知するために、通信品質監視をしています。通信品質の指標には以下を使用しています。

応答速度( RTT値 )
パケットロス率

基本的には ICMP で監視していますが、一部環境では ICMP の優先度を意図的に落としている箇所があるので、そこに対しては TCPPing で監視しています。通信断の発生、応答速度(RTT値) が閾値を超えた、パケットロス率が閾値を超えた場合にアラートを発報するようにしています。クラウドと拠点内に監視サーバに導入しており、拠点間通信、および、インターネット宛の通信を監視しています。通信品質は逆方向で異なることがあるので監視サーバをクラウドに集約せず、拠点内にも監視サーバを設置しています。

通信品質監視および、通信品質の可視化には Smokeping を使用しています。ただ、Smokeping に関しては、非常に古いツールでアラート管理などに課題があります。そのため、現在は Prometheus と AlertManager へのリプレースを検討しています。

Smokeping で取得したグラフは以下のようになります。縦軸が応答速度( RTT値 )、横軸が時間帯、線色がパケットロス率を表しています。以下の例だと RTT値が 3ms 程度で安定していますが、11:20 前後にわずかにパケットロスが発生していることがわかります。

また、通信品質が悪化する原因は拠点側ではなく、インターネット側にある可能性もあります。実際にあった例だと、インターネットキャリアに障害が発生して特定拠点間通信のみ一時的にパケットロスと通信遅延が発生したことがありました。このような場合は、障害復旧後の調査は難しいため、MTR を取得し、障害時に通信経路のどこで問題が発生したかわかるようにしています。 MTR の取得には mtr-exporter を利用しています。経路情報とパケットのロス率を mtr-exporter で計測し、Prometheus と連携させてメトリックを保存するようにしています。将来的にはパケットのロス率でアラートを発報する予定ですが、現在は閾値を調整中で本運用には載っていません。

コンフィグ監視

意図しない設定変更、設定ミスを検知するためにコンフィグ監視をしています。意図しない設定変更は、日次でネットワーク機器のコンフィグを Rancid を利用して取得しており、コンフィグに差分が発生した場合に差分を通知しています。取得したコンフィグは基本的にはネットワークグループのみがアクセスできる GitHub リポジトリで管理しています。一部の NW 機器のコンフィグに関しては、セキュリティ監査で別部署に提供する必要があるので、それらの機器のコンフィグに関して専用のリポジトリを用意してアクセスできるようにしています。

コンフィグミスの検知は Batfish という OSS を利用した内製ツールで行っています。 Batfish とは、ネットワーク機器のコンフィグを分析できるツールです。これを利用することで、ACL のルールチェック、ルーティング情報の可視化などができるようになります。 DeNA では、ACL のルールチェックに利用していますが、すべての設定をチェックするのは困難なため、ファイアーウォールの通信許可設定のみをチェック対象にしています。 Rancid で取得したファイアーウォールのコンフィグを読み込ませ、最低限守るべきルール( e.g. SSH 通信は拒否するなど )が守られているかを日次で確認し、違反するルールがある場合はアラートを発報するようにしています。このツールを導入することにより、意図しない通信許可設定を防止できました。

なお、コンフィグ管理に関しては、 Ansible を利用したコード化を進めています。 Ansible で NW 機器をコード管理できるようにすれば、手動作業を減らすることができるので、より安全な運用になることを期待しています。