イベント会場ネットワークにさくらのクラウドを活用してみた　第2回 - 会場クラウド間ネットワーク編

公開日
更新日

はじめに

IT業界に限らない話だと思いますが、昨今様々なイベント・カンファレンスが開催され、私たちに学習の機会をふんだんに与えてくれるようになりました。そうしたイベント・カンファレンスでは WiFiによるインターネットアクセスが提供されていることもあり非常に便利ですよね。本記事では、そのようなイベント会場のWiFiネットワークがどのように作られているかの一例として、さくらのクラウドを活用したネットワーク構築についてご紹介したいと思います。

どちら様でしたっけ

第1回の記事をご覧いただくとおわかりいただけるかと思いますが、CONBU(COnference Network BUilders)のコアメンバーを務めさせていただいております、外山(トヤマ)と申します。
イベント会場ネットワークを通じて、参加者・運営者の方々のより良い学びの一助と位置付けてこのような記事を書かせていただくことに燃える、しがないいち技術職でございます。燃えてるくせに、前回記事からほぼ1年も経過しており面目次第もございませぬ…以下にお見せする構成図の翌年の同イベントをご支援させていただいた後という時間軸で誠に申し訳ございません。。。

当記事の全体像

今回の記事のスコープは赤枠の部分です。


会場とクラウド間をVPNで接続している構成になりますが、この部分について今回は少々マニアックに述べていきたいと思います。

なぜVPNなのか

CONBUのイベント会場ネットワーク構築の初期は、すべての物品を会場に持ち込むものでした。
つまり、会場NW機器だけではなく、本連載で述べたISP部分や必要になるDNS, DHCPサーバのハードウェアそのものを、です。
このスタイルには以下の3点のデメリットがあります。

  • 持ち込み物品の故障(実際に発生)
    • 重量のある機器を頻繁に運送するので、稼働もかかるしリスキー
  • 準備期間・準備工数の増大
    • 現地で機器セットアップして初めて動くかどうか判断できる、これも極めてリスキー
  • 物品量やキャパシティの限界
    • イベント規模に物品量は比例しますし、運送できる物品量の限界がイベント会場ネットワークのキャパの限界をそのまま決めてしまう

誰もがイベント会場でインターネット接続できるようになるために、このデメリットと戦い続けるのは得策ではない。
そこで、私たちはISP部分とサーバリソースをクラウドにおいて、会場とクラウド間をVPN接続する構成に舵を切りました。

OpenVPN採用までの経緯

イベント会場となる場所には、その会場既設のインターネット回線を用いるか、開催イベント用に新規にインターネット回線を引き込みます。
いずれの場合においても、FTTH回線とISPから払い出されるPPPoEアカウントでインターネット接続可能な状態にします。
必然的に、会場に割り当てられるGlobal IPアドレスは動的な割当になります。
そのあたりを加味し、イベント会場とクラウドをVPNで接続する際に求められる要件はおおまかに以下の3つと定めています。

  • VPN区間の片側(クラウド側)が固定IPアドレスで動作する
  • IPv4, IPv6を上に通せるVPNである
  • 100Mbps程度のスループット

CONBUが旧構成で実績を持っていたのは、IPsec + IKEv1でしたので、上記3要件と実績ある方式をパブリッククラウドで再現できないか、という検証を開始しました。

試した製品は、SEIL、VyOSの2つで、結論から言うとどちらも実用に足るものではありませんでした。その理由は以下の通りです。

  • SEIL
    • ポリシーベースIPsecの際にIPv6をオーバレイできない
  • VyOS
    • IPsec aggressiveモードをサポートしていない

こうなってくると、IPsecに拘泥しているわけにもいかないため、3つの要件を満たす別の方式を検討する必要性が出てきました。そこで、クラウド側でNAPTを担っているpfSense(前回記事参照)を会場側でVPNゲートウェイとして利用し、トンネル技術としてOpenVPNに着目した上でフィージビリティ検証を始めたのです。
結果的に、この方式が比較的使えそうであるという結論に至ったので採用とし、クラウド側のpfSenseにexternal向けのNAPTとinternal向けのVPN両方を兼ねさせる設計にしました。

今回のNW設計思想と「さくらのクラウド」ならではのメリット

前回の記事と合わせると、これでクライアントからインターネットまでの経路をどうするか、技術レベルでは確定したことになります。
そこで、以下の想定と制約からNW設計を実施しました。

  • クライアント数は1,000を想定
    • イベント次第ですが、主催者の想定や会場のキャパシティを考慮しての値
  • 1クライアントあたりのセッション数は1,000を想定
    • 特にセッションを消費するアプリであるiTunes利用時に、200セッション消費する知見がある
    • ここから200セッションを最低限度とし、安全率を考慮して1,000セッションと設定
  • NAPTにて全体で1,000,000セッションを上限に設定
    • クライアント数と1クライアントあたりのセッション数を掛け合わせた値としてpfSenseに設定
    • 参考情報として、さくらのクラウドで提供しているVPCルータのセッション上限は1,000,000

これに伴って、pfSenseインスタンスにそれなりの量のメモリの割り当てが必要になります。
また、実際の運用ではピーク時のpfSenseのstatesが125,000程度であったため、セッション数に関しての設計はなかなかよかったのではないでしょうか。

さくらのクラウドでの利点は、こうしたNW設計に対するリソースの増減をシームレスに行えることです。(クラウドサービスなので当たり前ではあるのですが)会場側のVPN機器(= pfSense)は持ち込みハードウェアでしたが、なんとか2つのイベントを裁くことができました。

OpenVPNの先に見える景色

CONBUにとって初回のパブリッククラウドの挑戦は、NW面ではOpenVPNに落ち着きました。しかし、実はOpenVPNが唯一解ではない、その先の景色が我々には見えています。
たとえば、OpenVPNを含めた今回の構成について以下の課題が未解決です。

  • OpenVPNのスループットはCPU性能に依存する
    • トンネルがユーザランド処理、マルチコア非対応という構造上の欠点
    • イベント規模の大きさ(クライアント数の多さ)にリスクが比例する
      • 今回のイベントでもPCU使用率が上限に張り付いておりOpenVPNそのもののスループット上限に近かった可能性があった
  • 会場側のVPN機器がSPOF
    • 会場側VPNゲートウェイとして用いる機器が万一壊れた場合サービス停止
    • ここを冗長化するとなるとデザイン、デプロイが難化

その他OpenVPNの範囲の外でも以下のような課題が見えています。

  • 今回の構成ではDHCPリレー機能を会場L3に同居できなかった
  • VPN製品の入手のしやすさとデプロイのしやすさにまだ難あり

その他にも、

  • pfSenseでのIPsec + IKEv1検証は未実施
  • SoftEther VPNは未検証
  • 手堅い構成とするなら、本当は商用NWアプライアンスが必要なのかもしれない
  • 会場の物理構成のベストプラクティスにも答えが出ていない
  • そもそもVPN技術に関して、最新の・鉄板の知識体系があまりまとまっていないように思える

こういった課題の解決は、やはりCONBUのいない世界には不可欠なのだろうと思っています。こうした課題の解決に挑んでみたい方を、CONBUは絶賛募集しておりました(過去形、募集期間2017/6/21まで + 2017/12の募集期間)。

もしよろしければ、次回のCONBUのプロジェクトメンバ募集へご応募いただき、課題解決へのご助力をお願いできれば幸いです。また、今回の記事に関しても「もう少し突っ込んで！」など、もしよろしければ@conbu_netまでお寄せいただけますと大変嬉しいです。

ではまた次回！(次はすぐ書こう…今回も書き出しは早かったんですが(言い訳)+(遠い目))