【総量規制1TB対策】RTX830でフレッツ2セッション活用 → Raspberry Piで通信量を可視化 → ビジネスはヤマハYNOが最適解

こんにちは、ランシステムのヒロ田中です。
今回は、少しだけ自宅回線の失敗談からお話しします🏠

ある日、インターネットが妙に遅い。動画もクラウドも引っかかる。
原因を確認すると、プロバイダの月間下り1TBの総量規制に到達し、通信制御がかかっていました。

設備の問題ではありません。回線品質の問題でもありません。
単純に、「今月どれだけ使っているか」を把握していなかっただけです。

ネットワークは、止まってから考えるものではありません。
止まらない仕組みを、どう作るかです。

目次

月間1TBで通信制御。そこから始まった見直し

自宅で利用しているフレッツ回線は、実は2セッション同時接続が可能です。
総量規制にかかって初めて、その選択肢に気づきました。

もともと冗長化目的で構成していたわけではありません。
制限に直面したことで、RTX830でPP1/PP2の2セッションを設定し、さらにスケジュールによる自動切替へと変更しました。

RTX830 コンフィグ抜粋

# PP1 / PP2 セッション設定
pp select 1
 pppoe use lan2
 pp enable 1

pp select 2
 pppoe use lan2
 pp enable 2

# スケジュールによる自動切替
schedule at 101 */1 00:00:00 * ip route default gateway pp 1
schedule at 111 */16 00:00:00 * ip route default gateway pp 2

まずは運用を安定させる仕組みを整えました。

しかし、ここで疑問が生まれます。

本当に分散できているのか。
このまま運用して、また1TBに到達しないのか。

結局、数字で把握できていなければ管理できません。

“見える化”しなければ管理できない

そこで初めて、通信量の可視化が必要だと気づきました。
構成はシンプルです。
RTX830からSNMPで情報を取得し、その受け皿としてRaspberry Pi上に監視基盤(snmp_exporter/Prometheus/Grafana)を配置しました。

RTX830 → SNMP → Raspberry Pi(snmp_exporter → Prometheus → Grafana)

重要だったのはsnmp_exporter.ymlで64bitカウンタの使用です。
32bitではオーバーフローが発生し、月間集計が破綻します。

# 64bitカウンタを使用(32bitではオーバーフローするため)
 rtx830_pp_traffic_64:
    walk:
      - 1.3.6.1.2.1.2.2.1.2          # ifDescr
      - 1.3.6.1.2.1.31.1.1.1.6       # ifHCInOctets (Counter64)
      - 1.3.6.1.2.1.31.1.1.1.10      # ifHCOutOctets (Counter64)

Grafanaでは月間累計、使用率、残量を算出しました。

# PP1 月間累計(GB)→ 「今月いくら使っているか」
sum(increase(ifHCInOctets{ifDescr="PP[01]"}[$__range])) /1e9

# 使用率 → 「1TB上限に対して何%か」
(sum(increase(ifHCInOctets{ifDescr="PP[01]"}[$__range])) /1e9) / 1000 * 100

# 残量 → 「あと何GB使えるのか」
1000 -(sum(increase(ifHCInOctets{ifDescr="PP[01]"}[$__range])) /1e9)

👉重要なのは、PP1とPP2を個別に管理することです。
合計値は参考にすぎません。どちらか一方が上限に到達すれば、その回線は制御対象になるからです。

これでようやく、

「今月あと何GB残っているのか」
「このペースなら月末はどうなるのか」

といった話が、感覚ではなく“数字”でできるようになりました。

これまでは「なんとなく多い気がする」「そろそろ危ないかもしれない」といった曖昧な判断でしたが、可視化してみると状況は一目瞭然です。通信量が見えるというだけで、ここまで安心感が違うのかと実感しました。

ビジネス用途であれば、ネットワーク統合管理サービス

今回の流れを振り返ると、とてもシンプルです。

自宅ではRaspberry PiによるDIY監視環境を構築しました。
しかし企業環境では、安定運用・再現性・サポート体制まで含めた設計が求められます。

拠点が増え、担当者が変わり、障害時の責任所在が問われる環境では、属人的な監視には限界があります。

そこで現実的な選択肢となるのが、Yamaha製品とネットワーク統合管理サービス
Yamaha Network Organizer(YNO) の組み合わせです。

見える化は必須である。
しかし、その実現方法は環境に応じて選ぶべきである。

その観点で見ると、Yamaha Network Organizer(YNO)は監視ツールではありません。
トラフィックの可視化、機器状態監視、拠点一元管理、アラート通知までをクラウドで統合し、経営リスクを下げる仕組みを提供します。

通信はIT部門の問題ではありません。業務継続性と経営リスクの問題です。

ネットワークは、問題が起きてから慌てて対処するものではありません。
止まらない仕組みを、最初から選ぶことが重要です。

ヤマハ製品およびYNOを活用したネットワークソリューションについては、こちらをご覧ください。
👉 https://cyber-telework.jp/solutions/yamaha

自社環境に合った“合理的な見える化”を検討してみてはいかがでしょうか。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次