JANOG45 Meetingに参加してきました - シナプス技術者ブログ

中野です。

2020年1月22〜24日の3日間、北海道札幌市にて開催されたJANOG45 Meetingに参加してきました。今回の記事は、JANOGの紹介と、JANOG45 Meetingの参加レポートです。

JANOGって何?

JANOGとはJApan Network Operators' Groupを意味し、インターネットに於ける技術的事項、および、それにまつわるオペレーションに関する事項を議論、検討、紹介することにより日本のインターネット技術者、および、利用者に貢献することを目的としたグループです。

引用元: JANOG | General Information

JANOGのWebサイトに記載されているとおり、日本のインターネット技術者、その中でも特にネットワークやインフラなどを担当する技術者を中心としたグループです。

参加されている方は、通信事業者、ISP/CATV事業者、通信機器メーカー、データセンター事業者、教育機関、官公庁、研究機関と、インターネットに関わる様々な方々が参加されています。

JANOGへの参加には制限はなく、メーリングリストに登録することでJANOG会員となります。先日のJANOG45 MeetingのJANOGの最近の情報を伝えるJANOGアップデートによると、メーリングリストの参加人数は「4,947」となっているようです。

JANOGの活動としては、「メーリングリスト」「ワーキンググループ」「ミーティング」の3つで、「ミーティング」はその名のとおり、JANOGの参加されている方々が1箇所に集まり、情報共有・情報交換・意見交換・議論を行う場となっています。

このミーティングの1回目であるJANOG1は1997年11月に開催され、それから年2回のペースで、先日45回目が開催されました。

JANOG45 Meeting

今回参加したJANOG45 Meetingは、2020年1月22日(水)〜24日(金)の3日間、北海道札幌市の札幌プリンスホテル国際館パミールにて開催されました。 f:id:ryonkn:20200122133711j:plain

3日目の最終プログラムの閉会宣言・次回開催予告によると、本会議の参加者数は1,529人、懇親会は902人と、大規模なイベントでした。

JANOG Meetingの特徴として、本会議への参加は無料となっていて、会議に必要となる会場やその他必要な物のすべてを、ホスト企業やスポンサー企業からの協賛により運営されています。 f:id:ryonkn:20200122133726j:plain

さて、今回のJANOG45 Meetingでは多数のプログラムに参加しましたが、その中でも特に興味深かった2つのプログラムについて、取ってきたメモをもとに紹介します。

「共催イベント: TDNOG 1.5」

プログラムのページはTDNOG1.5 :: JANOG45で、『地域ISP（通信事業者）の将来像を考える』『先輩地域NOGから、NOG継続の心得～伝授～』の2つ内容にて進められました。

『地域ISP（通信事業者）の将来像を考える』

地域ISPとしての役割は?
- 地域ISPや大学間でのトラフィックは少ない
- コンシューマのトラフィックは地域終端が少ない
- スマホのトラフィックも地域終端が少ない
- 地域に終端されたコンテツがほとんどない
これからのIoTや5G
- 移動体事業者のトラフィックを地域終端することで変わってくる
  - 超低遅延・超高信頼性を実現
    - 地域ISPの必要性・役割は何?
地域の放送局の同時送信(地域コンテンツ)が変わってくる
- 地域コンテンツの出現待ち
5Gはいつくるの?
- 5Gは超低遅延・超高信頼性・広帯域
  - FTTHはもはや不要に?
- 地域にMECサーバが配備?
- 5GのMVNO・ローカル5Gで地域ISPは活路が見えるのか?
地域ISPは、自然淘汰を待つだけなのか?
- 移動体+大手ISPの寡占状態に収束するのではないか
- 地域ISPの生業と食い扶持はどこにあるのか
- B2B、B2B2Cのモデルが残っていくのか
- 災害時、有事の際は、地域情報は必要ではあるが、その際の地域ISPの立ち位置はどこ
  - 無形物(データ)を囲っておくべき
これからの地域ISP
- ISP事業の投資を極力抑えて、「地域の価値」向上に質っする
- ISP事業が必要な環境を残しつつ、他の市町村にないもの、より価値のあるものを創造する
- AI/ICTを十二分に活用した新たな街づくりに貢献
- そのために、地域コミュニティの重要性を再認識すること、エンジニアを育てることが大切

『先輩地域NOGから、NOG継続の心得～伝授～』

QUNOG
- 九州・沖縄を拠点にネットワーク技術者が“集う場”を提供している任意の団体
- ネットワーク技術者以外の九州・沖縄のコミュニティにどのようにリーチするかが問題
- 地域NOG間がいい感じに連携しないといずれお互いがパイを奪いあうかもしれない問題
- 次回のQUNOG 16 Meetingは、2020年3月6日(金)に大分県別府市にて開催
大阪ピアリングフェスティバル
- 大阪・西日本のインターコネクト事情を中心としたイベント
- すべてボランタリティによって運営
- 現地参加できない方のためにストリーミング提供
- 次回のOPF2020は、2020年5月21日(木)に大阪府大阪市で開催
ENOG
- ENOG = Echigo Network Operators Group
- ENOGはとても大切な存在
  - 地域技術者を結びつけ、勇気付けるもの
  - 地域技術者の結びつきは、地域の活性化につながっている

ディスカッション

現地参加の意義とはなんだろう
- ENOGは、早い段階でストリーミングをしている
  - ストリーミングしている事で話しづらいという事はない
- 方言を気にしなくていい、ホームで開催している意識
- ストリーミングでは伝わらない部分もある
- 会って話をすることが大事
NOGという看板を使って、ゲストスピーカーを呼ぶというのはあり
失敗談として、秋田NOGをはじめたがメンバーが全国の方々だった、その後クローズドにしようとしたが、うまくいかなかった
失敗談として、JANOGを仙台でした。
- JANOGに参加を促しても参加しないエンジニアに対して、地元でやったら参加すると思ったが、やっぱり参加しなかった

「急成長を支えるFastlyスケーラブル・グローバルネットワーク」

プログラムのページは急成長を支えるFastlyスケーラブル・グローバルネットワーク :: JANOG45です。

Faslytとは
- いわゆるCDN事業者
  - Edge Cloud Platform
- 本社はサンフランシスコで、従業員は504名
  - 33%がリモートワーク
- 2019年5月にニューヨーク証券取引所にて株式公開
Fastlyのネットワーク
- 66箇所の接続ポイント(POP)、トラフィックは58Tbps、75のIXに接続
- 1700キャッシュサーバ
- 1日6,000億リクエスト
- 1POPあたりサーバは25台ぐらいの規模
オペレーションチーム
- 世界中に分散したリモートチームで、15名前後
- 1日4ローテーションを地理的に、分散して運用
Scalable Network Arcitacture
- バックボーンはない
  - 拠点間は接続していない
  - IPエニーキャストにて各POPより、同じプレフィックスを広報
  - 理由
    - POPを作りやすい
    - POPは同じ構成にできる
    - 機器のコンフィグがシンプル
- ルータはない
  - スイッチを代わりに使っている
    - Arista EOSの上にソフトウェアを載せている
    - トランジット/IX/PNIを接続
    - 1POPあたり、2〜4台
    - BGPはソフトウェア(BIRD)を利用
  - 理由
    - ポートの多いルータが高いから
- ハードウェアロードバランサーはない
  - IPエニーキャストをBGPで行い、ISP側がベストパスを選定
  - GSLBはない
  - スイッチからサーバへは、ECMPにてバランス
  - サーバからISPへ
    - ECMPロードバランス
    - サーバでもBGPを動かし、サーバもフルルートを持っている
      - サーバがベストパスを選択して、トラフィックを転送
Network Automation
- Network Configuration
  - Day0(事前)
    - コンフィグレーションはGitHubで管理
    - 設定を変更してGitHubにてPull Request
    - CI Test
    - Review
    - Merge
    - Ansibly(デプロイ)ツールにてDry Runを実施
  - Day1(当日)
    - Ansiblyにてデプロイ
    - あとはスイッチに自動で設定が入る
    - 人間はモニタリングに集中して、異常がないことを確認
- Full Automation
  - 現在の運用
    - アラートが発生すると、Slackに通知が飛ぶ
    - 人間がトラフィックを確認する
    - 人間がPeer Slasher(トラフィック迂回)を実行
  - 今後の運用
    - アラートが発生すると、Event Driven Platform(StackStorm)を呼ぶ
    - Peer Slasherを自動実行

ディスカッション

ロードバランスはECMPでバランスできてる?
- 基本的には大丈夫、年に1回ぐらい変なことがあるレベル
アラート対応で、経路削除をしていると思うが、経路戻すのはどうしているのか
- 人手でやっていた時は、経路戻しも人手でやっていた
- 現在は、トラフィックがオフピークになったら自動的に戻すようになっている
IPエニーキャストは便利だが、トラフィックの流入はISPに依存してして、それで問題になったことはあるか
- ISPのポリシーで変なところから流れるところがあるが、発生してから調べて対応するフロー
TCPをIPエニーキャストで動かすのは怖いが、影響はないか
- TCPのリトランスミッションはモニタリングしている
- そこまで大きな影響はないので、深刻な問題としては扱っていない
CDNのお客様側のトラフィックのコントロールはどうやっているか
- DNSのCNAMEを変更して対応している
トラフィックを迂回する制御はどのようにしているのか
- 試行錯誤の結果、迂回させたいトラフィック量にマッチする経路を落としている
すべてのPOPがIPエニーキャストとの事だが、POP〜POP間、オリジン〜POP間の通信はどのようにしているのか
- 各POPはIPエニーキャストで広報するプレフィックス以外に、POP毎に異なるIPアドレスを広報している
設定変更の際のレビューは誰がやっているのか
- チームメンバーがチェックする