blog

DeNAのエンジニアが考えていることや、担当しているサービスについて情報発信しています

2021.11.18 技術記事

DeNA 本社移転でネットワーク構築・移行作業を実施しました

by Kunitate Katagiri

#infrastructure #network #infra-quality #infra-delivery

はじめに

こんにちは、IT 基盤部ネットワークグループの片桐です。 DeNA グループ全体のネットワークの管理、運用等を行っています。

今年8月、DeNAは本社拠点を渋谷ヒカリエから、WeWork渋谷スクランブルスクエアに移転しました。

この移転は我々としても、大きなプロジェクトでした。せっかくなので、オフィスネットワークにおける移転の裏側を紹介致します。

DeNAオフィス移転におけるネットワーク

WeWorkへの移転であれば、ネットワークもWeWorkの設備を使うのでは、と考えられた読者もおられるのではないかと思います。

最初に移転プロジェクトメンバーと新オフィスのネットワークについて議論しましたが、 渋谷ヒカリエで運用していたネットワークと同じレベルの帯域・ネットワークの安定性・クラウドとの内部通信・ネットワークセキュリティ・ネットワーク運用体制の維持、 これら全てが必須要件でした。 従って、WeWork 渋谷スクランブルスクエアオフィス内の DeNA スペースにネットワークの構築が必要と判断し、我々ネットワークグループがネットワークを構築する事になりました。

当初、新オフィスのネットワーク機器を一新する予定でした。 しかし、世界的なトレンドである半導体不足により、ネットワーク機器の納期が長期化しており、 オフィス移転までに間に合わないことが、プロジェクト開始後に判明しました。

なので、新オフィスのネットワーク構築には、ヒカリエオフィスと、クラウド移行によるDeNAのデータセンターの移設・縮小1にて、使わなくなったネットワーク機器を流用しました。

オフィス構築におけるネットワーク構築スケジュール

オフィスネットワーク構築はオフィス構築の一環であり、当然オフィス側の構築スケジュールに合わせて実施します。

今回はWeWorkオフィスへの移転であり、多くの設備が最初から用意されているため、これまでのオフィス構築にて必要となるような工事は比較的少なめでした。 WeWorkやDeNA総務部にて調整されているB工事、C工事2のスケジュールに合わせて、ネットワーク構築のスケジュールを組み、下記のようなスケジュールにて進行しました。

ネットワーク構築スケジュール

ネットワーク構築スケジュール

物理作業内容

我々が、移転のために具体的に行った物理作業は下記でした。

  1. 回線・専用線の発注・同工事立ち会い
  2. LAN接続工事の発注・同工事立ち会い
  3. 新オフィスへのネットワーク機器、サーバ機器の移動・設置
  4. 各ネットワーク機器の設定初期化と、新設定の流し込み(キッティング)
  5. オフィスフロアの有線LAN、無線LANのテスト
  6. 無線アクセスポイントの稼働開始、品質チェック、トラブル対応
  7. IP電話、複合機、他特殊な開発環境ネットワークの設置

これらの作業とは別に、ネットワーク要件のヒアリング、ネットワーク設計、ネットワーク設定(コンフィグ)の作成があり、 それらが完了していること前提での作業となります。

回線の発注・同工事立ち会い、LAN接続工事の発注・同工事立ち会い

ネットワーク構築において、回線・専用線の新規発注と工事は、特にリードタイムが長くかつ、スケジュールコントロールのし辛い箇所の一つです。

基本的に手配して立ち会うのみですが、意外と作業コストは大きいです。 一般的にビル側への事前の入館申請の必要なMDF室(通信回線をすべて収容し、集中的に管理する集線装置MDFを設置している部屋)への入室を伴う作業が何回も発生するなどし、 関わる手配の全てのリードタイムが長いです。 なので、スケジュールに余裕も持たせ、オフィス設備側の工事などが始まる前の最初期からの手配を進めるように注意しなければいけません。

また、LAN配線工事について、大規模なオフィスネットワークであれば、

  • LAN配線へのタグ敷設
  • タグと対応した各席LAN口の番号の管理シートの作成

を実施するように手配しておかないと後々の運用に難をきたすため、 構築の忙しい中であっても、地味かつ大変ですが、タグ付け作業を徹底するように、 プロジェクトを進めることが重要です。

ほとんどのLANケーブル接続に写真のようにタグ付けをしています

ほとんどのLANケーブル接続に写真のようにタグ付けをしています

新オフィスへのネットワーク機器、サーバ機器の移動・設置

新オフィスのネットワークの構築で使った機器について、オフィス内のサーバが既にクラウド移行完了していたため、ネットワーク機器と最低限の物理サーバのみで済みました。 もし、オフィス内にファイルサーバや認証サーバが多く稼働している状況であれば、この移転プロジェクトはもっと大変なものだったと思います。

ただ、移転先で700席規模のオフィスで必要なネットワーク機器の数は少ないものではなく、移動は大変でした。

  • ヒカリエオフィスにあったネットワーク機器
  • データセンターにあったネットワーク機器

をそれぞれ流用しましたが、 データセンターからの機器移動については、カーゴ便によりヒカリエオフィスへ移動し、 その後、ヒカリエオフィスにあった機器も一緒に宅配便、ハンドキャリーで移動しました。 (当然、重すぎる機器のハンドキャリーはせず、歩行者への迷惑やカードゲート通過においても問題の無いよう細心の注意を払っておりました)

このあたりは、移転先オフィスがかなり近い場所にあるオフィスであったため、 必要に応じて、機器の移動ができ、助かりました。

ネットワークグループメンバー全員の多くの稼働を使い、 梱包、伝票の起票、ハンドキャリー、部材の整理を行いましたが、 それでも最終的に完了するまでには何日もかかり、大変でした。

梱包し、宅配便で発送 ゆうパックのサイズでギリギリでした(箱はヤマトですが)

梱包し、宅配便で発送 ゆうパックのサイズでギリギリでした(箱はヤマトですが)

ハンドキャリーした機器、帯電防止ビニールで包んで、故障しないように注意しました

ハンドキャリーした機器、帯電防止ビニールで包んで、故障しないように注意しました

各ネットワーク機器の設定初期化と、新設定の流し込み(キッティング)

ネットワーク機器のキッティング作業は、ヒカリエオフィスの一部デスクスペースと会議室に AP・スイッチを並べ、4名でひたすらにキッティングをしました。

新オフィス構築で使うAPとスイッチを合計して100台ほどです。 各自のPCに接続したコンソールケーブル3を通してひたすらに、

  1. 設定の初期化
  2. 機器の再起動
  3. あらかじめ作っておいた設定を投入(コピペの繰り返し)

の作業を繰り返しました。 一部のコア部のネットワーク機器の設定については、実機にて設定投入変更しながら作成する必要がありましたが、 100台のうちのほとんどは、あらかじめ前日までに作っておいた設定をコピペしてターミナルに貼り付けて流し込むだけの作業です。

ただし、それでも細かい点であらかじめ作っておいた設定にミスがあり、それを修正するなどあったため、梱包も含め1日と半日以上の時間を使いました。

ヒカリエの天井から降ろされたAPです。このあとキッティングするために並べられています

ヒカリエの天井から降ろされたAPです。このあとキッティングするために並べられています

オフィスフロアの有線LAN、無線LANのテスト

ネットワーク機器の設定はヒカリエにて実施したため、移動しラックにマウントし電源を投入してLANケーブル接続さえすれば、新オフィスでネットワークは稼働します。

しかし、ネットワーク設定はヒカリエオフィスの設定をベースとしているものの、全く同じ設定というわけではなく、 アドレスのアサインなどは別のものになっていますし、設定も作り直して投入しています。 よって、一通りの構築作業完了後、あらかじめ作成しておいた試験項目表を基に各種試験を実施しました。

  • ネットワーク機器の単体試験
    • ネットワーク機器の各ステータスが想定通りか
    • 機器間の接続が設計通りであるか、配線に問題はないか
  • ネットワーク結合テスト
    • 各フロアの有線LANが問題なく使えるか
    • 各フロアの無線LANが問題なく使えるか
  • 冗長部においては障害試験を実施
    • 機器を片系ずつ電源を落として復旧までの断時間を測定
    • LAN接続を片系ずつ抜線し復旧までの断時間を測定

作業自体は、単体試験・障害試験はネットワークラック前で淡々とコンソール操作による状態確認をしながら、抜線など必要な作業を実施します。

結合試験は、オフィスフロアを回っていき、各所で有線LAN、無線LANの接続を実施、接続PCやSSIDに応じたIPが割り振られるか?認証機能は正常に機能しているかなどを確認しました。 これも地味ですが重要な作業です。

無線アクセスポイントの稼働開始、品質チェック、トラブル対応

オフィスネットワークでは、多くのスタッフが手軽に使える無線LANをメインで利用しており、無線LANの品質には気を使わなければいけません。

無線LANのチェックは、単純に「つながる・つながらない」のみのチェックでは足りず、 「どの端末でも、指定フロア内のどの場所でも、安定して接続できるか?」という点も確認が必要です。

今回の構築では、無線機器はヒカリエから持ってきた機器を使い、つながる端末もヒカリエから移動するスタッフの端末、配信する無線規格もヒカリエと一緒となりますので、 機器相性はあまり気にしなくて良い問題でしたが、フロア構成と無線LANアクセスポイントの配置には変更があるため、下記のチェックを実施しました。

  • 全オフィスフロアの電波強度(RSSI)のチェック
  • APの障害時のローミング動作チェック(全無線アクセスポイントの直下を回っていき、同無線アクセスポイントを電源オフ、近くの無線アクセスポイントに短時間でローミングされることを確認)

全オフィスフロアの電波強度(RSSI)のチェックについては、スライドツールにフロア図の画像を貼り付け、上から印を付け、 その場所に移動しつつ、取得した「BSSID, RSSI, CHANNEL」の値を記録していきます。 情報の取得は、MacOSX標準のCLIツール(airport)を使って実施しました。

専用のWi-Fiヒートマップの作成ツールを使い、より見やすい電波強度の視覚化を図るのも手ではあると思いますが、 現オフィスの広さですと、手間に対する費用対効果の観点からも、CLIの取得結果テキストをフロアマップにプロットしていく方法がちょうど良さそうと考えています。

RSSI取得結果の記録

RSSI取得結果の記録

ヒートマップ図を作成した際のイメージ。※実際には壁の透過による減衰があるのできれいな円状にはなりません。

ヒートマップ図を作成した際のイメージ。※実際には壁の透過による減衰があるのできれいな円状にはなりません。

上記で、端末相性についてはあまり気にしなくても良い問題と書きましたが、 実際には、オフィス移転でのタイミングで、無線LANコントローラのOSを最新のメンテナンス配布版へのバージョンアップしたため、 この作業に起因して、一部のスマートフォンにて無線接続ができないという問題が、無線稼働後のオフィスリリース前に判明しました。

ただし、この問題については以前にヒカリエオフィスでも経験しており既にナレッジがあったことから、早くに原因のあたりがつけられました。

問題の原因は、一部のバージョンの無線LANコントローラー管理下のアクセスポイントで配信される無線フレームに付与されるフィールドが、 特定のバージョンのAndroid一部のチップセットを持つ端末で処理できないこと(Android側のバグ)によるものでした。

Android側のバグであるものの、「特定バージョンのAndroid端末を使わないで欲しい」とオフィス利用者に頼むようなことは、困難なので、 ワークアラウンドとして、無線LANコントローラをバージョンダウンすることで一旦の問題解消をしました。

無線フレームキャプチャにはMacOSX標準のWi-fiトラフィックキャプチャツールなどを使っています

無線フレームキャプチャにはMacOSX標準のWi-fiトラフィックキャプチャツールなどを使っています

IP電話、複合機、他特殊な開発環境ネットワークの設置

各試験完了後(実際は時間がないので並行してですが)、オフィスに設置するIP電話、複合機と、特殊環境に対する個別の設定を実施しました。

IP電話についてはPoE(LANケーブルでの給電)にて動作する機器を使っており、 依頼があるたびに、ラック側でLANケーブルをPoE対応スイッチに物理的な繋ぎ変えをします。 また、1フロア内で多くのIP電話を使用する箇所では、PoEの小型スイッチをデスク横にマグネットで設置し、対応しています。

複合機などの外部ベンダー提供のオフィス機器については、社内管理のPCと同じポートでの認証は厳しいため、 特別にポート設定をして対応しています。

また、現在DeNAは豊富にグローバルIPを持っているため、真に必要であれば、 グローバルIPが使えるWANを、特定の開発席のLAN口に割り振って、開発側の社内スタッフが直接管理しているルータで特定グローバルIPをインターネット接続できるようにするなど、 WeWork渋谷スクランブルスクエアに移転後でも、 開発側の要望に対してできる限り柔軟にネットワーク環境を提供するようにしています。

新旧オフィスにて、数週間のネットワーク並行稼動を実現するために

ネットワークのオフィス移転におけるポイントの一つは、新旧オフィスにて並行稼動が必要な期間の有無と長さです。

本件における、オフィスの並行稼動期間は、数週間ありました。 ただし、この並行稼動期間のためだけに何百万円もするネットワーク機器を購入するわけにはいきません。

また、物理的なネットワーク機器の問題だけでなく、グローバルIPも二拠点で共有できない点も問題でした。

冗長構成片系ずつの移動

前提として、DeNAのオフィスネットワークは小規模拠点を除いて、ほとんどが冗長構成をとっており、ヒカリエオフィスにおいても冗長構成をとっていました。

数週間のみ片系ずつでの稼働とすることで、新しいネットワーク機器の追加無く、移行することとしました。 多少のリスクはある移行方法ではありますが、幸いDeNAは少し前まで、大規模なオンプレ設備を抱えていた背景から、それなりの種類と数のネットワーク機器の在庫があります。

もし最悪いずれかの機器が故障したとしても、在庫機器での代用により、復旧までに時間がかかる可能性はあるものの、全く復旧できないという状態にはならないため、取り返しのつかない大きなリスクを抱えた移行方法というわけではありませんでした。

片系づつ取り外してのネットワーク移転

片系づつ取り外してのネットワーク移転

グローバルIPの移行・BGPオペレーション

オフィスで提供している社内認証ネットワークなどは、特定のグローバルIPにNATされインターネット利用できるよう設定していますが、 各部署で使っているWebツールでは、そのグローバルIPを元にアクセス制御を行っており、新旧拠点にて同じグローバルIPを継続して使えることは重要です。

特にDeNAの本社拠点は、多くのグローバルIPによるネットワーク提供をしており、 そのためBGPトランジット契約し、保持しているグローバルIPをBGP広報する比較的大規模なグローバルIP運用を実施しています。

また前述のように、DeNAは元々大規模オンプレを抱えていたため、多くのグローバルIPを持っています。 そこで、本社オフィス拠点利用のグローバルIPセグメント「AA.AA.AA.0/24」に対して、 同レンジの「BB.BB.BB.0/24」を、移行期間の約一ヶ月間限定で使う仮セグメントとしてアサインしました。

新旧のBGPルーターやファイアーウォールのベースの設定は同じものを使っており、第4オクテットは仮セグメント共通とすると決めた上での移行を実施したため、 並行運用期間においても、各部署のツールの利用において各移行段階における状況周知を徹底した上で、大きな混乱なく移行を完了することができました。

また、自社グローバルIPの広報といえど、BGPトランジット側の経路フィルタのルールは、契約先ごとに異なることがあるため、 契約先のBGPトランジットのオペレータとのコミュニケーションも間違いなく行った上で、移行を進めるよう留意しました。

BGPルーターの移動と経路設定

BGPルーターの移動と経路設定

新旧オフィスネットワークの違い

DeNA新オフィスにおけるネットワーク環境は、移転前のネットワーク環境と実質同じものであり、 社内スタッフの利用においては差異はありません。

が、席数の減少により、運用するネットワーク機器の数は減りました。 コアネットワーク部の機器の構成は変わらないですが、基本的には、

  • 無線を提供する面積と、設置するAPの数は、比例する
  • 提供するポート数と、設置するスイッチの数は、比例する

となりますので、座席数と面積の差がそのままそれぞれの数となっています。

そして、新オフィスでは必要最低限以外のサーバの設置を廃止しました。 なので、オフィス内で利用しているラック数も激減しました。

旧オフィス 新オフィス
無線AP数 120 39
全ラックマウントスイッチ 150 60
ラック数 23 5

新旧ネットワークにおいて変更した点

オフィス移転のタイミングで、無線LANコントローラの設置場所をオフィス内ラックへの物理アプライアンス設置から、 クラウド上への移行を実施しました。

本社オフィスでは、無線をCisco Catalyst 9800とCisco Aironet AP4800を使って提供しています。4 この、Cisco Catalyst 9800(無線LANコントローラ)について、AWSクラウドでも動作できることがわかっており、 以前よりクラウド移行の検討をしていたため、オフィス移転のタイミングにて、クラウド移行を実施しました。

無線LANコントローラのクラウド移行により、専用線を経由しての接続となったため、 動作の安定性、専用線帯域の抑制のために、FlexConnectモードを導入しました。 本変更における、違いは下記のようになります。

旧オフィスにおける無線通信の流れ

旧オフィスにおける無線通信の流れ

新オフィスにおける無線通信の流れ

新オフィスにおける無線通信の流れ

この変更により、電源の管理、故障リスクなどでの運用コストの大きい、 オフィス内の物理アプライアンスの稼働を無くすことができました。

運用開始から、オフィスとクラウド間でのプライベート通信不安定は何度かありましたが、 FlexConnectの技術により、無線クライアントが接続済みの状態であれば、クラウドとの通信品質に関係なく、問題なく通信ができるため、 クラウド上の無線コントローラとの通信不安定が原因で、 体感でのオフィスの無線品質に大きな影響があったというケースは今のところないです。

DeNAでは、DHCPサーバやRADIUSサーバのクラウド移行も完了しており、これらのサーバへのアクセスは全て専用線経由です。

今回の変更で、ネットワークと連携するほとんどのサーバが、クラウド上で動作する構成となりました。

旧オフィス 新オフィス
無線ワイヤレスコントローラの設置場所 オフィス内ラック クラウド

締めと今後

オフィス移転とともに、オフィスネットワーク移行も、多くの関係者様のご協力のもと、なんとか終えることができました。

ネットワークまわりは現状でも多くの物理運用があり、移転についても多くの面倒な作業があり、移転が楽だったとは言い難いです。 が、全社的なクラウド移行により、既にオフィス内にほとんどサーバが残っておらず、 新拠点でもクラウドと、専用線やVPNでプライベート接続さえしてしまえば、 オフィスネットワークの提供に必要なサービスをほぼほぼ利用することができるという状況が既にあることで、 目の前の物理構築作業に専念できた点は大きいと考えており、そういう意味では、クラウド移行の利点を感じられたプロジェクト だったと考えています。

ネットワークグループとしては、物理ネットワーク規模の縮小、連携する各サーバのクラウド化によって、運用工数削減が進んでいるため、 今後は、クラウドのネットワークに注力するとともに、オフィスネットワークにおける細やかな要望や疑問にも対応しやすい状況になってきたかと思います。

移転後のWeWork渋谷スクランブルスクエアにおいても、セキュアかつ、快適なネットワーク環境を提供できるよう尽力していきますので、 どうぞよろしくお願いいたします。


この記事を読んで「面白かった」「学びがあった」と思っていただけた方、よろしければ Twitter や facebook、はてなブックマークにてコメントをお願いします!

また DeNA 公式 Twitter アカウント @DeNAxTech では、 Blog記事だけでなく色々な勉強会での登壇資料も発信してます。ぜひフォローして下さい!


  1. DataCenter 移設してみました · DeNA Engineers' Blog  ↩︎

  2. B工事、C工事などの説明は省略させていただきます。気になった方は検索していただければと思います。 ↩︎

  3. 主にCisco製品などを操作する際に必要なRJ45のコンソールケーブルです。 オフィス島スイッチ運用の負担軽減のための工夫 · DeNA Engineers' Blog でも説明。 ↩︎

  4. Cisco WLC を Act-Act で運用する話 · DeNA Engineers' Blog でも説明。 ↩︎

最後まで読んでいただき、ありがとうございます!
この記事をシェアしていただける方はこちらからお願いします。

recruit

DeNAでは、失敗を恐れず常に挑戦し続けるエンジニアを募集しています。