こんにちは、あるいはこんばんは。インフラ部ネットワークグループの佐々木です。
昨年秋頃から今年の3月にかけて、DMMオンクレ事業のクレーン拠点のネットワーク構築というプロジェクトを行いました。今回はそのプロジェクト内で構築したネットワーク環境についてご紹介します。
プロジェクトの背景
今回のネットワーク構築のプロジェクトの背景は、「DMMオンクレ」というサービスの立ち上げに伴い、本物のクレーンゲーム機をオンラインで操作できるゲームクレーン筐体を置いている現地のネットワーク構築をしてほしいと依頼があったことがきっかけでした。
拠点内にはおよそ1000ステーション(遊べるクレーンの数)が存在する想定と聞いた時は、それなりの台数規模になるな〜とぼんやり思いました。(実際に収容するNode数はもっと多くなりましたが…)
構成の検討時は
- クレーンゲームの制御用NodeとAPIサーバまでのhop数を揃えて遅延に差が出ないようにする
- 収容Node数が増える時のスケールしやすさ
- leafだけで数十台になる規模感
上記を総合的に検討して、一般的なleaf-spine構成で構築を実施しました。
ネットワーク構成について
構成の紹介の前にDMMオンクレというサービスについて簡単に説明します。
DMMオンクレとは、前述した通り、スマホさえあればどこにいてもクレーンゲームを遊ぶことができるサービスです。
一般的な景品のほかに、DMMオンクレならではの景品も用意してあります！
みなさんぜひ遊んでみてください！
URLはこちらになります！
図1. オンクレネットワーク概略図
それでは早速、今回構築したネットワークについて紹介していきます。
簡単にシステム的な構成について説明すると、顧客からのアクセスはAWS上のEC2で終端します。
そのEC2からオンクレ拠点内のNodeに対してクレーンの制御信号を送信し、クレーンを撮影しているカメラからの映像をNodeからEC2に送信しています。このAWS - オンクレ拠点間の接続については、AWS DirectConnectと専用線を利用しています。
オンクレ拠点ではleaf-spineの3段構造となっています。拠点内部ではOSPFを構成し、拠点間部分ではStaticRouteとBFDを併用しています。
OSPFを利用した理由としては、3段構造の為StaticRoute単体での制御は現実的ではないからと、細かい経路制御が不要で別拠点への経路とConnectedの経路を配送できれば良いためです。
これは構成の検証時に確認したのですが、機器障害から立ち上がる際に、OSPFのネイバーは張れるがパケット転送はできないような状態が発生したため、HoldMaxCostの設定もしています。
external
オンラインクレーン拠点とFront endのサーバのある拠点を接続する為のスイッチです。(extと省略して記載します。)
上述の通り拠点内ではOSPFを回しているのですが、拠点間の接続についてはStaticRouteで行っています。
StaticRouteを設定している箇所は専用線サービスを利用していて、インターフェースはダウンにならないがパケット転送できなくなる可能性(サイレント障害)も考慮し、BFDを併用しています。
もちろんこの経路を後述のleafが持っていないと通信できませんので、extでFront endの拠点向けのStaticRouteをOSPFに再配送しています。
また、Act-Actで利用するためにOSPFのコストに差はつけていません。拠点間の専用線のコストの兼ね合いで、襷掛けの構成にはせず、その代わりにext同士で渡を持つことで障害時もspineを経由せずに迂回するように設計しています。
spine
各leafとextを収容する為のスイッチです。図1上のspineとleafが半分で別れているのは別のフロアに存在する為で、各フロアのleafを集約する役割も担っています。それぞれのフロアに2台ずつで冗長化を図っています。
leaf
各Node(=クレーン筐体)を収容する為のスイッチです。図1を見ていただければわかるのですが、ext/spineについては冗長性が担保されていますがleafはStandaloneとなっています。これは、収容するNodeがStandaloneという事もあり、leafの冗長化が不要なためです。
収容しているNodeは上述の通り、クレーンの制御通信用のものとクレーンを撮影するカメラ用のものがあり、クレーンの台数より多くのNodeを収容しています。
また、Nodeの存在するフロアがデータセンターのようなラックではなく、クレーン筐体を置くために広い空間となっています。そのためUTPの有効距離を超えてしまうので、各フロアにleafを点在させてNodeを収容し、光ケーブルを使ってspineまで転送しています。
また、各Nodeに対してDHCPでIPアドレスを付与しているため、leafがDHCP Relayの役割も担っています。
DHCP
DHCPについて簡単に記載すると、IPアドレスを持っていないNodeに対してIPアドレスを渡す機能です。
図2. DHCPのイメージ図
図2やleafの項目で軽く触れた通り、Nodeに対してIPアドレスを割り振っています。leafではDHCP Relayの設定をしているので、各Nodeが出したDHCP RequestをDHCP Serverに転送します。この際に、Nodeが出した情報の他に、leafのどのインターフェースからのRequestであるかを追加します。
Nodeの故障時の交換対応の簡略化のため、スイッチのインターフェース単位で固定のアドレスを割り振るようにしているのですが、上記のleafがDHCP Relayを行う際に付加する情報によって、固定のアドレス割り振りが可能になっています。
これにより、故障したNodeを交換して差し替えることで同一のIPアドレスを利用することが可能になっています。
構築方法について
この拠点の構築にあたり、実際にはleafが数十台となるため、手作業による構築では時間がかかると判断しました。
そのためZTP+Ansibleによる構築を検討したのですが、使用した筐体のAnsibleのModuleが存在しないので、AnsibleのTemplate Moduleを利用して作成したConfigをZTPで配布する、という方法で構築を実施しました。
これは構築後に設定変更が発生しないという前提があったため実装できた方法なので、あまりおすすめはできません。
今回の手法はもちろん、私自身ZTP自体を利用したことがなかったので手探り状態でしたが、無事に実装でき、当初の想定の時間より大幅に構築期間を短縮できました。
さいごに
DMMオンクレのネットワークの構成や構築方法について多分わかりやすく紹介しました。こちらの記事上にある機器の設計やDHCP、構築方法について、自分で検討と検証を重ねながら無事に構築を完了できたのは非常に良い経験となりました。
一言でこの環境をまとめると、スケールしやすい一般的なleaf/spine構成ということになります。
現在ネットワークグループでは、一緒にDMM.com Groupの様々なサービスのシステムインフラを支えるメンバーを募集しています。今回紹介したサービス用ネットワークだけでなく、データセンターネットワーク、coreネットワーク、ネットワークの自動化にも取り組んでいます。
ご興味のある方は募集ページからご応募下さい。
