DeNAのリアルイベントの舞台裏〜ネットワーク構築編

はじめに

こんにちは、IT基盤部の兵藤です。 主に社内ネットワークのインフラを担当しています。

弊社では、DeNA TechConなどの技術系イベント、Pocochaで開催しているリアルイベントなどを主催しており そのイベント会場のネットワーク構築は我々(IT基盤部ネットワークグループ)が行っています。

今回のブログでは、そのイベントの舞台裏となる 会場ネットワーク構築の手順などをお伝えしていこうと思います。

イベントのネットワーク構築の流れ

イベントのネットワーク構築は ざっとこのような手順で行っていきます。

  1. イベント会場のネットワーク状況の把握
  2. ネットワーク設計
  3. キッティング
  4. 当日の構築

一つずつ簡単に説明していきます。

1.イベント会場のネットワーク状況の把握

まずはイベント会場のネットワーク状況について把握する必要があります。 会場によって既設の設備も様々であり、利用させてもらえるものは利用したほうが費用が安く抑えられる場合もあるからです。 無線の設備がある会場もなかにはありますが、こちら側で無線の状態などコントロールができないため、基本的には利用していません。

会場の既設ネットワークの確認では主に以下の項目を確認しています。

  1. 回線の種類は何を使っているのか。 こちらについては利用している回線の種別から、回線の品質についてある程度判断しています。 例えばフレッツ光ネクストを利用しているのであれば、ベストエフォートで1Gbpsの回線であることがわかります。

  2. 回線の実効速度はどの程度か。 回線の種別がかわかったとしても、実効速度がどの程度あるのかを調べておかないと、ベストエフォート回線では致命的になります。 フレッツ回線の場合はまず間違いなく1Gbpsは出ませんので、実際に接続させてもらい、複数の速度測定サイトなどを利用して平均値を測っています。

  3. 回線は安定して利用できているか。 こちらについては情報があればもらうようにしています。 上記で実効速度を測ったとしても、それは観測時点での結果であり、継続してその速度が出る保証はどこにもありません。 なので、ある程度のスパンで回線の状況について計測しているデータが有ればもらうようにしていますが、フレッツを利用しているところは大抵持っていませんので判断に困ります。

上記のようなことを総合して、既設回線を利用するのか、新規に安定した回線を引き込むのかを判断して対応しています。

これまで対応してきた中では、会場の状況については下記のようなものが挙げられます。

  1. 会場の既設ネットワークが利用可能であり、帯域的にも十分利用に耐えうる
  2. 会場の既設ネットワークが利用可能ではあるが、帯域が乏しく利用が難しい
  3. 会場の既設ネットワークが利用不可だが、回線の引き込みは可能
  4. 会場の既設ネットワークが利用不可でありかつ、新たな回線の手配も不可能

ほとんどの会場が2か3に該当することが多く、会場となる場所へ新規にインターネット回線を引き込みさせていただいています。 1ができる会場は稀で、4についてはそもそも会場選びの候補から外してもらっています。

TechConで利用しているヒカリエホールは、1に該当してますが、通常利用ではベストエフォート100Mbpsの帯域のみの利用であるため、帯域を1Gbpsへ拡張するために利用料を上乗せして払っていたりします。

インターネット回線を会場へ引き込む場合、新規の回線敷設には1.5ヶ月〜3ヶ月必要と回線業者から言われることが多く、早め早めに行動することが必要になってきます。 回線敷設については、NTTが絡むことが多く、回線業者でもコントロールすることが難しい部分もあるため、毎度綱渡り状態で回線敷設していたりします。

2. ネットワーク設計

会場の状況が確認でき、インターネット回線利用の方向性が固まったら、次にネットワーク設計をします。 基本的な構成は下図のように設計・構築しているのですが、会場によっては既設部分とのつなぎの仕様を確認したりして柔軟に対応しています。

Network-diagram.png

会場の大きさ、形、有線LAN利用の要望などを考慮し、無線のカバレッジホールができないように、機器の台数、設置位置などについて設計していきますが、、、

DeNAではイベント用に専用のネットワーク機器を確保しているわけではありません。 都度、必要台数を設計し、通常運用で確保している予備機器を利用して、構築しています。 予備機の状況によっては、要件を満たずのが困難だったりもしますが、その時は必要最低限の箇所に絞ってもらい対応するなどしています。

また、論理設計だけでなく、物理設計についても都度会場に合わせて設計をしています。 会場によって、どこに電源があるのか、どこに機器を設置するのか、どのようにケーブルを取り回して配線するのか、など考慮する必要があります。 ケーブルの長さ、本数などが足りなければ購入するなどして対応しています。

3. キッティング

設計が終わればキッティングを実施します。 キッティングと言ってもすでに何度もイベントを実施しているため、基本的な設定はすべて完了しているため、ただただ地道にコンフィグ設定をしていきます。

設定が全て終われば、仮組みをし設定に問題がないか確認します。 仮組みで問題なければ、機器、ケーブル、電源タップなど必要機材一式を梱包し、会場へ配送手配をします。

4. 当日の構築

イベントでは前日に準備日を設けている場合と、そうでない場合があります。 前日準備が可能であれば、構築時間も潤沢にあるので問題ないのですが、当日準備の場合は限られた時間の中で構築する必要があり、NOCメンバー全員で手分けして構築作業をしています。 広い会場では物理的な配線作業が一番時間を要します。多いときは6人で3時間ずっと配線作業していたりします。

物理的な構築が完了したら、無線のカバレッジホールが無いかどうか、会場全体を無線スキャンしながら回ります。 問題がなければ基本的な構築は完了です。あとは本番に向けて監視の設置をしていきます。

監視についてはnagios(機器監視)などを構築して使っていたり、Cisco Meraki機器を利用してネットワーク構築した際などはMeraki Dashboard上でトラフィックの傾向確認をしていたりします。。 機器監視については、本番中に機器が停止していないか、CPUなどのリソースは問題ないかを監視しています。 過去の例では、イベントの関係者が誤って電源を抜いてしまったなどのトラブルがありましたが、監視のおかげですぐさま復旧させ事なきを得ました。

トラフィック傾向確認については、今後のイベントのために傾向を見れるように可視化するために使っています。 過去のTechConでは来場者1000人程度に対して、最大同時接続650台程度で300Mbps程度のトラフィックを観測しています。

イベントが終了したあとは、撤収作業も自分たちで行っています。撤収も時間が限られているため時間との戦いです。 設営のときほど気を使わなくていいので、一気に撤去作業を進めていきます。整理整頓は後でいいので撤去優先でどんどん実施します。

自社によるネットワーク構築のメリットデメリット

このようにイベントにおいて自社でネットワークの環境を構築していると普段あまり体験しないレイヤー1の部分からすべて自分で対応することで、ネットワーク構築の経験を積めるといったメリットがあります。 構築費用面においても、自分たちですべて実施することで、外部への費用流出を抑え低コストで実施できます。 設計についても自分たちでやることで、柔軟に対応でき、スピード感を持って対応することができます。

一方でトラブル時などは全て自分たちで解決しないといけないといったデメリットは懸念されるところですが、事前検証をみっちりやることで未然にトラブルを防ぐようにしています。

おわりに

以上、ネットワーク構築の流れやメリットなどを紹介させて頂きました。

簡単ではありますが、少しでも良い環境構築の参考になれば嬉しく思います。 最後までお読みくださり、ありがとうございました。

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

VimConf 2019参加レポート

MOVのサーバサイドエンジニアをしている古舘(@178inaba_)です。
11月3日に行われたVimConf 2019に参加しましたので参加レポートをお届けします。

VimConfとは

テキストエディタVimの国際会議で2013年から開催されているカンファレンスです。
今年のキーノートスピーカーはvim-lspasync.vimasyncomplete.vimの作者であるPrabir ShresthaさんとNeovimのリードメンテナーであるJustin M. Keyesさんのお二人でした。

国際会議なのでスライドはすべて英語でした。
また、公式サイトを見てもらうと分かる通り英語のセッションが日本語より多かったです。
ですが同時翻訳がしっかり完備され、英語があまり得意でなくてもセッションの内容はわかるようになっていました。

DeNAとVimConf

DeNAはGold SponsorとしてVimConfにスポンサードさせていただきました。
ノベルティとして挿入モードの補完チートシートをお配りさせていただきましたが皆さん使っていただけていますでしょうか。

cheat_sheet.png
ノベルティとして配布させていただいた挿入モードの補完チートシート

実はこちら、弊社の鈴木(@dice_zu)が昨年のVimConf 2018で登壇した資料から作成されたものなのです。

そして、昨年に引き続き今年も鈴木が通常セッションで登壇致しました。
タイトルは「Usage and manipulation of the tag stack」です。
手前味噌ですがtag stackの実装が図を用いて解説されており、非常にわかりやすかったです。
ぜひご一読ください。

懇親会ではスポンサーセッションも行いました。
スポンサーセッションでは鈴木がVimConfをスポンサードする価値を会社にプレゼンした内容を赤裸々に語り、懇親会の盛り上がりに一役買えたのではないかと思います。

セッション

今年のテーマは「how to be more productive with Vim?」という事でVimを使ってより生産性を高める方法が多く紹介されていました。
特にvim-lsp関連のセッションが多かった気がします。
それぞれのセッションについては公式サイトにスライドPDFがありますので詳細はそちらに譲ります。

ここでは筆者が特に気になったセッションをいくつかご紹介します。

"Vim Renaissance" by Prabir Shrestha

筆者も使っているvim-lspの作者であるPrabir Shresthaさんのキーノートです。
lspプロトコルの詳細やvim-lspを作った動機を話されていました。
LSP(Language Server Protocol)の登場以前はエディタ毎に補完やタグジャンプ等の機能を実装しなければならなかったが、LSP登場以後は言語毎にLanguage Serverを作っておけばエディタ側はvim-lspを入れるだけでよくなりました。 これは確かにルネッサンスだなと思いました。
また、次の革命についてVim向けのJavaScriptインタフェースが入ったら多くの人たちがplugin開発に参加しやすくなり革命が起こるだろうと話されていました。

"We can have nice things" by Justin M. Keyes

NeovimリードメンテナーのJustin M. Keyesさんのキーノートです。
2016年まではVimは安定性にフォーカスしており、なかなか新しい機能が入らなかったため新しい機能が頻繁に入るVimを目指してNeovimが産まれたそうです。
実際、4日開発が止まっただけで「Neovimは死んだ?」と言われたそうで、それだけ頻繁に新しい機能が実装されているという事ですよね。
「NeovimのゴールはVimを置き換える事ではない。Vimの最大化がゴール。」と話されていたのが印象的でした。

"make test" by m-nishi

Vim本体のテストについてのセッションです。
このセッションに触発されて自分の手元でmake testしてみたら余計なファイルが残ったので余計なファイルが作成されないようにするPull Requestを提出しました。

https://github.com/vim/vim/pull/5177

結果的には別な修正方法での解決になりましたがきっかけをもらったセッションでした。

"My Vim life" by gorilla0513

DeNAも会場提供させていただいているゴリラ.vimのオーガナイザーであるgorillaさんのセッションです。
約一年前からVimを使いはじめてVimの勉強会を開催したり技術書典でVimの本を頒布したりとバイタリティ溢れる活動をしているgorillaさんがどのようにVimを学んできたかを紹介していました。
個人的にヘルプを読み込むという話は目からウロコでした。
自分は困ったときしかヘルプを読んでいなかったので今後読み物としてVimのヘルプを読んでみようと思いました。

"13 Vim plugins I use every day" by Tatsuhiro Ujihisa

ujihisaさんはVimConfの前身であるujihisa.vimを主催していた方で今回のVimConfの運営もされています。
そんな長年Vimに貢献されているujihisaさんが毎日使っているpluginを紹介するセッションです。
紹介されていた中ではgina.vimlexima.vimが気になりました。
また、ライブコーディングでHTTPサーバを実装するという事もしていて、このライブコーディングが非常に鮮やかでした。
立て板に水ということわざがありますが、筆者はujihisaさんのライブコーディングを見て『立て板にVim』という言葉が思い浮かびました。
それほどすごかったです。
動画がアップされたらぜひとも見返したいセッションです。

お弁当

お弁当がすごかった事はぜひ皆様にお伝えしたいです。

今半のすき焼き弁当です。
運営のujihisaさんが「我々が用意できる最高のものを用意したのでゆっくり楽しんで」とおっしゃっていて、実際に最高でした!

まとめ

本当に最高のカンファレンスでした。
Vimのカンファレンスというのは世界中探してもこのVimConfだけのようです。
そんな世界的なカンファレンスに参加できたことはすごく幸せなことだと思いました。
また、技術への情熱、Vimへの情熱にあふれる方のセッションを聞くことができたのは筆者にとって大変貴重な時間でした。

個人的ではありますがGo言語コミッターであるmattnさんに会えた事はすごく嬉しかったです!
(筆者がmattnさんのgo-mastodonにContributeしたことを覚えてくださっていた事に感激しました。)

Vim漬けの一日で非常に情報量が多く、いい意味で精神的に圧倒された部分もありましたが次回もまた参加したいと思いました。

運営のみなさん、登壇者のみなさん、懇親会で話してくれたみなさん、ありがとうございました!

DeNAはこれからもVimを応援し続けます!

非公式VimConf後夜祭

先述のゴリラ.vimとgirls.vimの共催で非公式VimConf後夜祭が開催されます。
非公式とは言うものの、VimConf運営メンバーのKoRoNさんが「VimConfの作り方」というタイトルで登壇します。
ぜひ足を運んでみてください。

ゴリラ.vim
ゴリラ.vim #10 非公式VimConf後夜祭

girls.vim
girls.vim vol.3 - 非公式VimConf後夜祭

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

Auto Scaling から見るInfra System の構成

こんにちは、IT 基盤部の Wei です。大規模ゲームタイトルおよびゲームプラットフォームのインフラを運用しております。

私のグループが運用しているシステムでは Auto Scaling を導入してからもうすぐ2年が経ちます。

この2年で Infra System の構成は徐々に変わってきました。今回は Auto Scaling という観点から、現時点の Infra System の構成がどのようになっているかをご紹介します。

Instance の台数管理

Auto Scaling を導入する前、Instance の台数管理は人手でした。台数管理には必要台数の計算から Instance の構築・撤去まで Instance 関連の処理が全て含まれるため、人手で行うには多くの工数が掛かります。また、人手で対応するため想定外のトラフィックが押し寄せた場合に台数を増やすのに時間が掛かるというケースも多々ありました。更に、人手だと管理頻度にも限界があり、余剰リソースを持つ時間帯が多く、それゆえ無駄なコストも掛かっていました。

以上の課題を解決するため、Instance の台数管理を自動化する必要があります。当時マネージドの Auto Scaling サービスで我々のシステムの要件を満たすものはなく、また Spot Instance との併用時に求められる柔軟性などを考慮し、Auto Scaling システムは独自に実装することにしました。ちなみに、このシステムは現時点では GCP の Managed Instance Group と連携するなど、一部マネージドサービスの機能も取り込んでいます。

台数管理システムには大きく2つの Component があります。台数維持を担当する Component (以下、Instance Controller)と台数計算を担当する Component (以下、Auto scaler)です。

Instance Controller は、設定された台数を維持することを目標にします。サーバが落ちたら自動的に Instance を作成しますし、Instance 台数が設定値を上回ったら Instance を撤退します。Instance Controller に対する入力は必要台数の総数のみですが、単に台数を足すだけではなく様々な事情を考慮する必要があります。Spot Instance と On-demand Instance の比率をどうするのか、複数の Instance タイプをどのように混在させるのか、どの Availability Zone に Instance を立てるのかなど。例えば Spot Instance が枯渇したら On-demand Instance を利用する必要がありますし、特定の Instance タイプの在庫が枯渇した場合は別な Instance タイプを利用する必要があります。ちなみに、なぜ種類が多いか以前の記事 DeNA の QCT マネジメント を参考できると思います。

一方、Auto scaler は必要台数を計算して Instance Controller に伝えます。台数の計算は、Metrics (基本的にCPU) に基づいていますので、Metrics 集計システムが必要です。一般には CloudWatch、Prometheus などが使われますが、我々のシステムはここも独自実装になっています。フラッピングを避けるため、Auto scaler は CPU 利用率が一定の範囲内に収まるように指示を出します。具体的には CPU 使用率が60%を超えたら台数を増やし、40%を下回ったら台数を減らす、という具合です。そして、Instance の構築はどれだけ高速化を頑張っても数分単位で時間が掛かるため、瞬間的になトラフィック増には間に合いません。そのようなケースは事前に予測可能なことがほとんどなので、事前に台数を増やしておくことで対応しています (そのようなスケジューリング機能も持っています)。

flow0.png

Instance の作成

DeNA にはサーバのメタデータを管理するための専用のシステムが存在します。これは主にオンプレ環境でサーバを維持管理するために必要なシステムでした。クラウドの IaaS 環境においても、このサーバのメタデータ管理システムが必要です。

このメタデータ管理システムと連携するため、Synchronizer と呼ばれるコンポーネントを開発しました。オンプレ環境においてはこのシステムに登録する作業は人手で行なっていましたが、IaaS 環境においては Terrafrom や Google Managed Instance Group や AWS Auto Scaling Group などと連携する必要があり、その処理を自動化するために Synchronizer が必要です。

クラウドのリソース情報をメタデータ管理システムと連携させるにはもう一つ問題があります。それは利用するクラウドの種類が増えるたびに、そのクラウド専用のロジックを実装する必要があることです。この問題を解消するため、我々は Cloud Adapter と呼んでいる抽象化層を実装しました。例えば、Instance にアタッチする Volume として AWS であれば EBS、GCP であれば Persistent Disk がありますが、これらはVolume という概念で抽象化しています。こうすることで他システムからはクラウドサービスの違いを意識することなく統一した Interface で扱うことが可能です。

flow1.png

ちなみに、Interface 自体は、Protocol Buffers で定義しています。例えば、Instance の定義:

 message CloudInstance {
   string id = 1;
   cloud.CloudProvider provider = 2;
   string zone = 3;
   string name = 4;
   // Private IP of first NIC
   string private_ip = 5;
   // Public IP of first NIC
   string public_ip = 6;
   // Subnet Reference of first NIC
   cloud.ResourceReference subnet_ref = 7;
   string instance_type = 8;
   map<string, string> label = 9;
   google.protobuf.Timestamp launch_time = 10;
   string fqn = 11; // Fully qualified name such as self-link, ARN, etc.
 ...
 }

以上で、Instance を作成したら同時にメタデータ管理システムにも登録することが可能になります。同時に Instance の Life cycle も開始されます。

Instance の Life cycle 管理

Instance を作成したら、OS 設定、アプリケーションコードのデプロイ、テスト、監視設定などの作業を行います。この一連の作業はこれまで専用のスクリプトで行なっていましたが、スクリプトだと以下のような問題がありました。

  • スクリプトがどんどん太り、メンテナンスコストが増え続ける
  • 長大なスクリプトは冪等性を担保することが難しい
  • 処理の途中からリトライさせるような処理を書きづらい
  • スクリプトの実行ホストが落ちた場合に構築・撤去処理自体が失敗する
  • 構築・撤去処理がどこまで進んでいるのか見えづらい
  • 構築・撤去処理の負荷分散がしづらい
  • 構築・撤去処理の並列実行やパイプライン化が難しい
  • 実行してるスクリプトを丁寧にキャンセルしにくい

構築台数が増えれば増えるほど、上記の問題は顕在化してきます。この問題を解消するため、Workflow というシステムを開発しました。

Workflow は大きく2つの Component から成ります。タスクの管理とディスパッチを行う Scheduler とタスクを実際に実行する Executor です。Scheduler と Executor はそれぞれ冗長化していますので、数台落ちても Workflow の実行に与える影響は軽微です。Workflow は各処理に対してリトライやタイムアウトを設定することが可能です。またタスクの単位を小さくすることで冪等性も実装しやすくなります。

Workflow は Jenkins のように設定したタスクを順番に実行していきます。さらに、Workflow はタスクの分散処理、パイプライン化、自動リトライ、依存関係を考慮したタスクの実行などを行うことができます。Workflow で実行するタスクを設計する上で二つ重要なポイントがあります。1つ目は各タスクに冪等性を持たせること、2つ目はタスク間の依存関係を減らすことです。この2つを満たすことでタスクの途中失敗を減らすことができます。

flow2.png

Instance の構築タスクは前述の通り様々ありますが、その中で一番難しいのはアプリケーションのデプロイです。デプロイの方法次第では、その処理自体が非常に時間が掛かってしまいます。この問題には、事前に最新のアプリケーションをデプロイした Image を用意しておき、そこから Instance を作成するという方法で対処することにしました。

Instance の撤退

Instance の Life cycle の終わりは、Instance をサービスから完全に切り離し、Instance 自体を削除することです。メタデータ管理システムからの削除も行う必要があります。これで Instance の撤退が完了だと思いますが、実はそうではないです。Volume の Life cycle も考慮する必要があります。

なぜ Volume の Life cycle と Instance の Life cycle が違うかというと、主にログ回収のためです。ログの回収は、エラーログなど即時転送しているログもありますが、データ量によって即時転送していないログもあります。さらに、転送先(例えば Fluentd サーバや Stackdriver Logging など) の障害が起きる可能性があります。障害のタイミングによってログを即時に回収できない場合もあります。溜まっていたログを転送するために、その間 Instance を起動し続けるのは非効率ですし、AWS Spot Instance や GCP Preemptible Instance などは Instance は短時間で削除されてしまうので、Volume の Life cycle と Instance 分けるのは一つの案になります。

そのため、Instance を撤去するときは Instance はそのまま削除しますが、ログがある Volume はまだ消さないようにします。我々のログ回収システムは、使い済みの Instance の Volume を mount して、中身を S3 や Google Cloud Storage に転送しています。ちなみに、転送したログは、AWS Athena と Google BigQuery を活用して、検索することも可能です。

まとめ

今回は Auto Scaling の観点から、私のグループの Infra System の構成を大ざっぱに紹介しました。構成はそんなに複雑ではないですが、様々な問題に対処するため、工夫を凝らしています。そして、紹介したシステムは一気に完成したのではなく、最初は簡単なスクリプトから始まり徐々に進化してきました。現在でもまだ進化中です。もし詳細にご興味をお持ちの方やシステムをより進化させるために一緒に取り組んでくださる方がいらっしゃれば、ぜひ DeNA に join してください。

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

ゲームサーバ開発エンジニアがみた Go Conference 2019 Autumn

Go Conference 2019 Autumn

19新卒の勝倉です。今回、スポンサー枠でGoConference2019に参加させていただきましたので、レポートをお届けいたします。 それぞれのセッションに関しては、Twitterの#goconでスライドが共有されておりますので、詳細はそちらに譲ることとして、普段の開発に役立てられそうな点を振り返りたいと思います。

Go Conferenceに参加するにあたって

どれも非常に面白そうで全部聞きたかったのですが、当日は2会場展開だったため、なるべく業務に役立ちそうなセッションを重点的に聞こうと思いました。 (全体としては、コンテナ技術やデータ解析に絡んだトピックが多かったように思います。) ゲームサーバーを開発するチームに所属しているので、キーワードとしては、「パフォーマンス」「テスト」「自動生成」あたりをメインに、個人的に関心のある「つくってみました」系もいくつか選んで参加しました。

OSS Performance Tuning Tips

概要

スライドはこちら

「OSSで公開されているライブラリのパフォーマンスを向上させていくためには、どのようにアプローチしていけば良いか」というお話でした。 パフォーマンスチューニングの流れとしては、

  • ボトルネックになっている箇所をpprof(またはgithub.com/pkg/profile)を使って絞り込む
  • 怪しい箇所のベンチマークを書く
  • 試行錯誤してベンチマークを向上させる

発表の中では、試行錯誤を行なっていく際に、どういったポイントに目をつけていくとよさそうか、という紹介もありました。 たとえば、

  • 順序が保証される必要のないsliceをmapにかえることで、探索をO(n)からO(1)で終わるようにできる。
  • 何回も読み書きが必要なところは、都度bufferを確保するのではなく、sync.Poolでバッファープールを作ってあげると無駄なメモリ消費を減らせる。
  • 必要以上に強力なhashアルゴリズムを使っているところは、他の軽いアルゴリズムで代替できれば速くなる。

といったtipsが紹介されていました。

感想

はじめてGoに触ったとき、(=はじめて静的型付け言語に触ったとき)、ポインタの仕組みを理解しないで、でっかい構造体のスライスを毎回コピーしていたら、rubyの10倍くらい遅いコードができあがり、「『Goだから速い』のではなく、『Goを正しく使うから速い』」という教訓を得たときのことを思い出しました。

それ以降は、たとえば、

 // hogeは[]string
 s := []string{}
 for _, v := range hoge {
   s = append(s, v)
 }

このような書き方は避けるようになったのですが、このセッションで、他にも書き方のコツを仕入れることができて、良い勉強になりました。

またセッションの中で、メンテナンス性が下がるので非推奨ではありますが、AVOというパッケージを使えば、いい感じにGoのコンパイラの特性を生かしてアセンブリをかけるという紹介もありました。

いつの日か、どうしようもないボトルネックになってしまっている箇所を、アセンブリで華麗に解決できたらと思います。

Continuous Automated Go Fuzz Testing

概要

(スライドは共有されていませんでした。)

gofuzzを使って、Fuzz testingを導入して、コードの品質をあげよう」というお話でした。

Fuzz testingは、テスト対象の関数の引数をビット反転などの演算によってsemi-randomに生成し、カバレッジが閾値を超えるまで回し続けて予期せぬエラーが発生しないかを確認するテストのことだそうです。

このテストを導入することによって、たとえば、

 // fooは、与えられたバイト列が「d.e.n.a」ならtrue、それ以外ならfalseを返す関数
 func foo(s []byte) bool {
   if len(s) >= 3 {
     if s[0] == 'd' && s[1] == 'e' && s[2] == 'n' && s[3] == 'a' {
       return true
     }
   }
   return false
 }

 var testcases = []*struct{
   in []byte
   want bool
 }{
   {
     []byte("dena"),
     true,
   },
   {
     []byte("baystars"),
     false,
   }
 }

このような関数とテストケースを書いてしまった時に、効果を発揮するとのことでした。

Goの標準パッケージでも、Fuzz testingを使って、100件以上のバグが見つかっているらしいです。 https://github.com/dvyukov/go-fuzz#trophies

注意点として、unit testやintegration testの代替となるわけではなく、実装方法に関する不備を見つけ出すためのテスト、ということでした。

感想

最近、チームで負荷試験の話になったときに「1回の負荷試験で数百万円かかる」と聞き、以前にもましてテスト設計をしっかりと考えたり、意識して変な値(絵文字など)を入れたりするようになりました。 Goの標準Testingパッケージでは、命令網羅率を測ってくれますが、上の例を見せられた時に、自分の書いたシナリオでカバレッジが高くても安心できないなと、ドキッとしました。 たとえば、validationのヘルパー関数などはいちいち関数ごとにテストを書くのはなかなか大変ですが、一番ちゃんと書かないといけないところでもあります。

そういった部分を、こういった手法で自動化できれば、いまと変わらないコストで、いまより自信をもってプロダクトを提供できると思いました。

総括

これ以外にも、CPUやVRAMの挙動をgoでエミュレートしてみたり、OCIのcontainer runtimeを実装してみたり、GCの仕組みを紹介してくれたりと、goをいろんな角度からいじっていてとてもよい刺激となりました。普段の業務でアプリケーションのコードを書いているだけではなかなか持ちづらい観点からGoを見ることができました。 持ち帰った知識はプロダクトにもしっかりと反映させて、その経験をコミュニティに還元できたらと思います。

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

Auroraの高速フェイルオーバーと無停止での切り替え

こんにちは、IT基盤部の川原﨑です。

私の所属する第四グループでは、超大規模ゲームタイトルおよびゲームプラットフォームのインフラを運用しております。 そこでのAuroraの高速フェイルオーバーの仕組みと、実際に無停止で切り替えを行った手順について紹介させていただきます。

はじめに

第四グループでは、コストコントロールの一環でInstance数の増減・Instance Typeの変更を頻繁に実施しています。
例えば、

  • イベントなどでリクエスト増加が見込まれるときにInstance数を増やす、またはInstance Typeを1つ上のものに変更する
  • リクエストが減少傾向にあれば、Instance数を減らす、またはInstance Typeを1つ下のものに変更する

などです。
これはWebサーバだけにとどまらず、DBサーバについても同様です。

EC2上でMySQLを運用している環境では、フェイルオーバーの仕組みとしてMHA for MySQLを使用しております。
MHA for MySQLでは数秒でフェイルオーバーが完了するため、ピークタイムを避けた時間帯であればエラー率も無視できるレベルです。 しかし、Aurora導入後はドキュメントに記載されている通り、フェイルオーバーに1分ほど要してしまうことが見込まれるため、フェイルオーバーの品質が大幅に下がってしまう懸念があります。

ダウンタイムの検証

まずは実際にどれぐらいのダウンタイムが発生するのかを確認しました。

検証環境

db.r4.large Multi-AZの3台構成
Auroraバージョン 5.6.10a

事前準備として検証で使用するテーブルを作成しておきます。

 CERATE DATABASE aurora_test;
 CREATE TABLE test (
     col int(10) DEFAULT NULL
 ) ENGINE=InnoDB;
 INSERT INTO test (col) VALUES (unix_timestamp());
確認コマンド
 while sleep 1
 do
     date && echo "update test set col=unix_timestamp();"  | mysql -uroot -p<password> -h<Cluster Endpoint> -N --connect-timeout=1 aurora_test
 done

 

 while sleep 1
 do
     date && echo "select col from test;"  | mysql -uroot -p<password> -h<Reader Endpoint> -N --connect-timeout=1 aurora_test
 done
検証結果

手動フェイルオーバーによるダウンタイム秒数

role1回目2回目3回目4回目5回目
writer28s11s17s14s24s
reader27s21s13s21s12s

1分までとはいかないまでも平均して20秒程度かかっています。

writer側では接続エラーが収まった後に以下のエラーがしばらく継続し、完全に切り替わるようです。

 ERROR 1290 (HY000) at line 1: The MySQL server is running with the --read-only option so it cannot execute this statement

reader側では接続できるときとできないときが上記秒数の間に発生するという状況が確認できました。 これはCluster Endpoint/Reader Endpointの更新までにタイムラグがあることが推測されます。

次にReaderであるInstanceを減らす際のダウンタイムについても計測してみましたが、Reader Endpointに対しての接続エラーは計測 できませんでした。 Instanceの削除には時間がかかり、Statusがdeletingの状態でもしばらく接続ができる状態であるため、接続ができなくなる前にDNSへの変更が完了するからかもしれません。

MHA for MySQLと比較するとフェイルオーバー時のダウンタイムは見劣りしてしまうため、本番サービスにAuroraを導入するにあたり ダウンタイムを短くすることが課題とわかりました。

高速フェイルオーバーの仕組み

Auroraの高速フェイルオーバーの仕組みとして

  • MariaDB Connector/J
  • ProxySQL
  • HAProxy

などが知られていますが、 私たちのチームではこれから紹介させていただく仕組みで高速フェイルオーバーを実現させています。

DeNAでは、ローカルのDNSとしてMyDNSを使用したDNSラウンドロビンの仕組みがあります。 この仕組みでは応答しないサーバを検知してMyDNSのレコードを消して自動でサービスアウトする、アプリケーションはMySQLを直接参照することでDNSラウンドロビンのデメリットである近いIPアドレスに集中しないよう分散させています(書籍『Mobageを支える技術 』参照)。

AuroraもEC2インスタンスと同様にMyDNSに登録しています。 それにより以下のメリットがあります。

  • AuroraのEndpointを使用しないのでDNSへの更新に関するタイムラグがない
  • アプリケーション側は既存の仕組みのままでいい
  • Instance Typeの変更・Instanceの再起動時にはMyDNSからレコードを削除すればよい

ただ、既存の検知の仕組みではサービスアウトさせるということしかできないため、Aurora用に別途検知の仕組みが動いております。

check-aurora.png

  • failoverが実行された際にinnodbreadonlyが0のInstanceでwriterのレコードをREPLACEする
  • readerが応答しない際にweightを0にする
  • すべてのreaderが応答しない際にreaderのレコードにあるwriterのweightを100にする

以下は、failover実行時の時系列での状態です。
aurora-test-w が書き込み用、aurora-test-r が読み込み用のMyDNSに登録されているEndpoint名です。

通常時

endpointinstanceinnodb_read_onlyweight
aurora-test-waurora-test-instance-010100
aurora-test-raurora-test-instance-021100
aurora-test-raurora-test-instance-031100
aurora-test-raurora-test-instance-0100

failover時のWriter候補再起動時

nameinstanceinnodb_read_onlyweight
aurora-test-waurora-test-instance-010100
aurora-test-raurora-test-instance-021100
aurora-test-raurora-test-instance-0310
aurora-test-raurora-test-instance-0100

Writer切り替え後

nameinstanceinnodb_read_onlyweight
aurora-test-waurora-test-instance-030100
aurora-test-raurora-test-instance-021100
aurora-test-raurora-test-instance-0300
aurora-test-raurora-test-instance-0110

旧Writer復帰時

nameinstanceinnodb_read_onlyweight
aurora-test-waurora-test-instance-030100
aurora-test-raurora-test-instance-021100
aurora-test-raurora-test-instance-0300
aurora-test-raurora-test-instance-011100

以下、高速フェイルオーバー導入後のダウンタイムの計測結果です。

手動フェイルオーバーによるダウンタイム秒数

role1回目2回目3回目4回目5回目
writer5s7s4s6s7s
reader6s1s4s7s5s

MHA for MySQLまでとはいかないまでも、ダウンタイムはInstanceが再起動の時だけに限定されるため、かなり早くなりました。

無停止でのAuroraへ切り替え

MySQLからAuroraへ切り替えはメンテナンスを設けずに無停止で以下の手順で実施しました。

まずはMySQLのReplication SlaveとしてAuroraクラスタを構築します。 もし問題があった場合にMySQLに切り戻しができるよう、Auroraのbinlogを有効にしておきます。

migration.png

  1. ttlを1秒にする
  2. MyDNSのslaveの向き先をAuroraのreaderに向ける
  3. MySQL側で書き込み権限があるユーザをRenameし、書き込みを止める
  4. Aurora側に上記がReplicationされてしまっているのでAurora側でユーザ名を戻す
  5. MySQLとAurora間のReplicationを止める
  6. SHOW MASTER STATUSでMaster Positionを確認する
  7. MyDNSのmasterの向き先をAuroraのwriterに向ける
  8. ttlをもとに戻す
  9. 上記7で確認したMaster PositionをもとにMySQLをAuroraのReplication Slaveと設定する

MySQLに戻す場合は上記の手順をMySQLに置き換えて再度実行することになります(実際に切り戻すことはありませんでしたが)。 この状態でしばらく様子を見て、問題なければMySQLを撤去します。

上記の手順のうちエラーが発生するのは3~7の間だけです。実際の切り替え時は手順の1~8までをスクリプト化しており、failoverとほぼ同等レベルのダウンタイムで切り替えることができました。

最後に

以上、Auroraの高速フェイルオーバーの仕組みと無停止による切り替えについて紹介させていただきました。 Auroraに切り替えることで、深夜問わず発生するEC2インスタンスのダウンなどによるDBサーバの再構築という工数が削減できており、インフラエンジニアに優しい運用になりました。
MyDNSの利用による運用はDeNAに特化したことであまり参考にならないかもしれませんが、 Aurora導入の参考になれば幸いです。

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

メールを送信する話

こんにちは、IT基盤部の中村です。 主に社内システムのインフラを担当しています。 現在の業務内容とは少しずれてしまいますが、最近までメール系のインフラには深く携わっていたこともあり、今回はメールシステムについてお話します。

今どきSMTPなどレガシーな話かもしれませんね。しかしながら良くも悪くも枯れたSMTPはインターネット基盤の根底に位置する息の長い技術でもあります。 きっとみんなまだ使ってるはずなのに、あまりノウハウが出回っていないのが辛いと感じているそこの担当者の方、よろしければ少しの間お付き合いください。

サービスでのメールの利用用途

我々がサービスとしてメールを取り扱うとき、その主だった利用用途は下記の2つです。

  1. メールマガジンなどの情報発信
  2. 入会・ユーザ登録時などのユーザ存在確認

メールマガジンはユーザーに情報を新たに届けたり、あらたに弊社の別のサービスに触れて頂く機会を提供するために送信されています。 こちらは単位時間あたりの送信量も送信時間もコントロールが可能ですし、宛先不明メールなどの送信不能メールを予めクリーニングを実施した上で送信できます。

逆に入会系のメールは、とあるゲームやサービスがリリースした直後に爆発的に急増します。こちらは時間帯のコントロールができない上に、流量についてもある程度の予測をしたところでそれを上回ってくる事が多く、さらにユーザ登録時のメールアドレス間違いなどで一定数の宛先不明メールも発生します。

graph.png

これらのメールを確実に(できるだけ)早く先方に届けることがシステム上の命題となります。

特に「入会・ユーザ登録」は大事な顧客獲得のチャンスでもあり、インフラの問題でメールが届かないなんてことは可能な限り避けなければなりません。

今回は、世界に向けて発信したサービスの導入時に発生した、ユーザ登録のメールを相手に届けるにあたって検討・設定したことについてお話したいと思います。

クラウド化に向けて

閑話休題ですが、これらの仕組みをクラウドに持っていくにあたってはAWSのSESなどのマネージドサービスを検討しました。 残念ながら、既存のメール配信のマネージドサービスは、突発的に大量にメールを送信する可能性がある弊社の環境とは相性が良くありませんでした。 逆に、大量のメールを定期的に送信するような環境であれば積極的に利用すべきです。

我々の場合は、クラウド上に自前でメールサーバを構築し、運用するという選択をしました。

メールを送信するということ

メールを送信する。ということは当然受信する相手がいるわけです。 いくらこちらからメールを送り付けたところで、受信者側の対応如何でこちらからのメールは一方的に破棄されてしまいます。 受信者側の対策は世の中には公開されていません。どうすれば100%相手に到達するかといったノウハウは受信側からは提供されません。

受信側はおそらく送り手側が怪しいメールの送信者でないかという観点で受信したメールを受け入れるべきか判断しているはずです。 送信元としてはそれが正しく自分たちの送出したメールであり、さらに迷惑メールを送信するようなサーバではないことを証明し続けるほかありません。

送信ドメイン認証

自らの出自を明らかにするための方法として送信ドメイン認証という考え方があります。 細かい説明はもっと詳しいサイトがあるのでそちらに譲りますが、要するに送信者のアドレスが正規なものであることを証明する技術です。 SPF/DKIM/DMARCなどがあります。 設定の優先度はSPF>DMARC>DKIMの順でしょうか(DMARCはDKIMの設定を実施していなくても設定できます)。

サービス開始当初はSPFとDKIMのみ設定していましたが、一部のフリーメールでは、どちらも正しく設定されているのにスパム判定されてしまいました。 DMARCを投入することで問題なく受け入れてもらえるようになりました(DMARCの投入にはそれなりに面倒がありましたが、それはまたの機会に)。

レピュテーションへの対策

レピュテーションは送信元メールサーバのIPアドレスの「評判」です。行儀の悪いメールサーバの評判は悪くなり、逆に正しく振る舞うほどに評価は上昇します。 評価が悪くなっていく状況を我々はよくIPアドレスが「汚れる」と言っています。 IPアドレスが汚れれば汚れるほど、そこからやってくるメールは、受信側に受け取ってもらえない可能性が高まります。

評判を公表しているサイト

いくつかのベンダーがIPアドレスのレピュテーションを公開してくれています。これが全てではありませんが、我々は以下のようなサイトを参考にしています。 AWSでEIPをとったタイミングでこれらのサイトで検索してみると、近い過去にメールサーバとして使われていたかどうかなどがわかる場合もあります。

DNSBLの監視

最も端的にIPアドレスが汚れているか判断できるのはDNSBLだと思います。 いわゆるブラックリストです。これに登録されてしまうと、即座にブロックが始まるので、できれば迅速に対応したいところです。 どれだけ手厚くみていても、たった一通のバウンスメールで登録されてしまうこともあります。油断は禁物です。

複数のブラックリスト検索には一覧検索に優れたサイトを使います。現状を知るには良い方法です。

影響度が大きいと思われるブラックリストは個別に監視して、登録され次第リストからの消去などのアクションを起こすようにします。 他にもいくつか見ていますが、主に下記あたりは注視しておいたほうがよいです。

それでも問題は起きる

とまあこれだけ対策しても、大量にメールを送信すると問題は発生します。

メール送信が始まってものの10分ほどでとあるドメイン宛のメールがすべて遅延するようになりました。

おそらく単位時間あたりの流量や、それまでのメール送信元サーバのIPアドレスからのメール到達の実績との差異などがトリガーとなっているのだと思われます。 普段はほとんどメール送信がないメールサーバからいきなり大量にメールが送信されると、その挙動そのものが怪しげなものに見えるようです(先述の通り、こちらからするとこれはこれで正しい挙動なのですが)。 一定の期間後メールは受信してもらえるのですが、この遅延は入会へのモチベーションに対しては致命的です。

暖気

確証は有りませんでしたが、通常時のメール流量が殆どないメールサーバーからの送信が怪しいのであれば、最初から少しは流しておけばいいと考えました。 特に流量による制御を実施していると思われるフリーメールに対しては、だいたいサービスリリースの2週間くらい前からメールを定期的に送信しておくようにしました。 我々はメールサーバの暖気と呼んでます。 実際こちらを実施することにより、長期間のメールのブロックはかなり減りました。

IPアドレスは多めに用意

それでも受信側のメールサーバの挙動は分からないことが多いです(特に海外のドメイン)。 メールログからなにか規則性を探ろうとしましたがほとんどが徒労に終わりました。

最後は力技ですが、仕方がありません。

メールキューの監視を行いつつ数十個のIPアドレスを用意して問題があれば利用を停止するようにしました。潤沢なグローバルIPアドレスをあてにするこの手法はパブリッククラウドならではの手法でありました。

まとめ

大量にメールを送りたいなら

  • 送信ドメイン認証は手を抜かず確実に設定しましょう
  • レピュテーションには常に気を配りましょう
  • 暖気も時には有効
  • それでもだめなら力技もあり

最後に

いかがでしたでしょう。 実際、大量のメール送信というユースケースはあまりないかもしれません。 当時は調べても有用な情報が出てこず頭を抱えたものでした。 詳細を省略している部分も多いですが、おおよそ我々がとった対応については記載しました。同じようなことで悩んでいるどなたかの参考になれば幸いです。

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

アプリログを BigQuery に入れるまで

こんにちは、IT基盤部の貴田です。

DeNA では分析環境の BigQuery 移行を進めています。
先の記事では、移行の背景や、 MySQL のデータを Embulk を用いて BigQuery に入れる工程を紹介しました。
今回は、ウェブアプリケーションが出力したログを定常的に BigQuery に入れて活用するフローについて書きます。

文中の料金については、すべて 2019年10月時点の 東京リージョンのものです。

大まかな流れ

applog2BQ.png

  1. アプリがログを吐く
  2. サーバー内の daemon がログを処理し、適切な Cloud Storage Bucket にアップロードする
  3. Cloud Storage から BigQuery に import する

というシンプルな構成ですが、設計するにあたりいくつか考慮した点があるので、順に説明します。 概略図中に、 1 ~ 4 の数字を振っている部分です。

(1) どうして直接 BigQuery にデータを送信せず、 Cloud Storage に格納するのか?

web server から bq load や ストリーミング挿入 を用いて直接 BigQuery にデータを集めることも検討しましたが、コストと安定性を考え、まずは Cloud Storage にデータを格納し、必要なものを必要なタイミングでだけ BigQuery にエクスポートする構成としました。

コスト

1GB・1ヶ月あたりの料金はこのようになっており、 めったに使わないデータは Coldline Storage に置くことでストレージコストを下げられます。

サービス料金
Cloud Storage (Standard Storage)$0.023
Cloud Storage (Coldline Storage)$0.006
BigQuery$0.023

また、 BigQuery のストレージ料金は非圧縮の状態のデータサイズが課金対象となります。
Cloud Storage 上に gzip で圧縮した状態で保持することで、ストレージ料金を大きく下げることができます。

Cloud Storage から BigQuery にエクスポートする際に料金が少しかかりますが、それについては後述します。

安定性

BigQuery のテーブルは型を持っているため、何かしらのバグでログに不正な文字列が入ると、 BigQuery へのインサートは失敗します。その場合にログを web server 内部に溜めてしまうと web server のディスク領域が逼迫したり、本番稼働しているサーバーに入っての復旧作業が必要となったりするデメリットがあります。

まずはどんなデータでも受け入れてくれる Cloud Storage にデータを入れてしまい、その後起きうる問題と web server を切り離す意味でも、まずは Cloud Storage にデータを入れる構成が優位です。

(2) gcs daemon の役割

分析用のアプリログはもともと hdfs に格納することを前提に出力していたため、各行が下記フォーマットになっています。

 ${hdfs上のpath情報}\t${その他メタ情報...}\t${データ本体(JSON または LTSV)}

また、 DeNA の web app は多くの場合、分析用のアプリログを単一のファイルに書き出し続けています。

そのため、

  • hdfs上のpath情報 を Cloud Storage Bucket 名・path への変換を行う
  • ログファイルを一定時間ごと・bucket/pathごとに分割する
  • BigQuery に直接 export できるファイル形式(json.gz) に変換する

という処理を行っています。

(3) BigQuery へのデータ取り込み vs 外部データソースの活用

Cloud Storage に格納されたデータを活用する場合、2通りの方法があります。

  • データを BigQuery にエクスポートする
  • BigQuery の 外部データソース機能 を用いて Cloud Storage 上のデータを直接活用する

DeNAでは前者の BigQuery にエクスポートする方法を採用しました。

ドキュメントに記載があるとおり、後者の方法を用いると、 BigQuery の機能が一部制限されてしまいます。

なかでも、

  • テーブルのパーティショニングがサポートされない
  • クエリの実行結果がキャッシュされない

という制限は致命的で、大規模なデータを扱った場合にクエリ料金が跳ね上がる恐れがあります。

一方、前者の方法でエクスポートする場合、それ自体にほとんど料金が発生しません。
Cloud Storage (Standard Storage) と BigQuery が同リージョンにある場合、エクスポートで発生する料金は下記のもののみです。

  • Cloud Storage の get api 料金 10,000ファイルあたり $0.004
  • BigQuery ストレージ料金 1ヶ月・1Gb あたり $0.023
    • 時間単位での課金なので、利用後すぐに消せば費用が非常に小さくなる

このとおり、 Cloud Storage -> BigQuery へのエクスポートは非常に安価に行うことができます。
エクスポートすれば BigQuery の機能をフルに活用できるため、大規模なデータ分析において外部データソースの機能を使うシーンはほぼ無いと思います。

(4) 型自動判定の夢...

Cloud Storage 上の JSON を BigQuery にエクスポートする際、すべてのカラムの型を明示的に指定しています。
利用者にあらかじめスプレッドシートにカラム名と型を記載してもらうことで実現しています。

BigQuery へのデータ読み込みでは、型の自動判定機能があり(CLI でいうところの --autodetect オプション)、当初はこちらの活用を考えていました。

実際、ほとんどのケースでは自動判定はうまく働きます。
しかし、極稀にエラーが起きてしまうケースがありました。
例えば、ほとんどの行は version: "3.0" と記載されており、実数値として判定されるが、新しく version: "3.0.1" がリリースされるとこれは実数に変換できないのでエラーになる、というケースです。

BigQuery には一部のカラムだけの型を指定してデータを取り込む機能がないため、利用者に全ての型をあらかじめ入力してもらう UX となってしまいました。

BigQuery は型を意識した分析用だと割り切る必要がありそうです。

まとめ

今回の設計を通して得られた知見をまとめます。

  • BigQuery にデータを直接入れるのではなく、 Cloud Storage をデータレイクとして活用することで、安価でかつ安定する
  • Web server 上で BigQuery に読み込ませられる形式に変換・圧縮して Cloud Storage に配置することで、後続の処理をシンプルにできる
  • BigQuery の外部データソース機能は使わず、 Cloud Storage から都度 export するほうがよい
  • BigQuery を使う以上、型を意識した設計にすべき。 型自動判定は万能でなく、アドホックな処理のみに利用する

最後に

hadoop を用いた分析基盤から BigQuery を用いた分析基盤に移行するにあたり、とくに迷った部分・試行錯誤の結果当初の方針を変更した点などを紹介させていただきました。
何かしらの参考になれば幸いです。

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

アクセス制御を厳格に行っている環境からのs3利用

こんにちは、IT基盤部第一グループの生井です。
DeNAが提供するヘルスケア系サービスのインフラを担当しています。

ヘルスケア領域ではセンシティブ情報を扱いますので、日々高レベルなセキュリティ設計・運用を行う必要があります。 今回はその一例として、アクセス制御を厳格に行っている環境からS3を利用する際に行った対応を紹介したいと思います。

はじめに

あるプロジェクトで、センシティブ情報を扱う環境から、S3の特定バケットにのみ、awscliでのデータdownload/uploadを許可したいという要件がありました。
  補足:特定バケットに限定するのは出口対策のためです。任意のS3バケットへのアクセスを許可してしまうと、内部犯行によるデータの持ち出しや、マルウェア感染によるデータ漏洩のリスクが高まります。

対応として、この環境で実績のある、FWでのFQDNベースでのアクセス制御を行うことにしました。 S3へのAPIアクセスは、以下2つの形式がありますが、

  • パス形式:s3-<region>.amazonaws.com/<bucket>
  • 仮想ホスト形式:<bucket>.s3-<region>.amazonaws.com

バケットの命名規則に従ってバケットを作成していれば、 awscliはデフォルトで仮想ホスト形式<bucket>.s3-<region>.amazonaws.comのアドレスでS3にアクセスします。
したがって、仮想ホスト形式のFQDNに一致する場合のみ、FWで許可するようにしました。

ところが、S3の場合には、FQDNは一致しているのにもかかわらず、通信が拒否されてしまうケースが発生し期待通りにアクセス制御ができないことがわかりました。
FWのFQDNベースでのアクセス制御は、FQDNに対するDNS問い合わせ結果をFWがキャッシュとして保持し、クライアントが名前解決を行い接続するIPと、FWのDNSキャッシュ情報にあるIPが一致する場合にアクセスを許可する、という動作でしたが、 S3のようにTTLが短い接続先の場合は、IPが一致しないケースが発生してしまうことが原因でした。
また、ベンダーに問い合わせた結果、この環境におけるFWの仕様として、FWのDNSキャッシュ期間をコントロールできないことがわかりました。

そこで、FWでの制御をあきらめ、代替策としてproxyサーバを用意して対応することにしました。
この環境の構成について次項に書きます。

構成

1g.aws.proxy.blog.png

上図は、システム構成の概要を示した図です。AWS環境にproxyサーバを建てて、Site-to-Site VPNで接続しています。通信品質の優れるDirect Connectを選択する案もありましたが、この環境の使用方法では妥協ができること、及び、コストが抑えられること、後からDirect Connectに変更することが容易であること、からSite-to-Site VPNを選択しています。
proxyインスタンスは異なるアベイラビリティゾーンに1台ずつ作成しLBを通して冗長化しています。インスタンスOSはCentOS7です。
セキュリティグループやproxy設定、IAMやバケットのポリシーでアクセス制御を行っています。許可する通信を最小限にするため、利用するAWSサービスの各種VPC endpointを作成しています。ログ保管や監視では、CloudWatchを利用しています。
以下で、もう少し具体的に構成について紹介していきます。

proxy

proxyは、ApacheやSquidがメジャーですが今回はホワイトリスト管理のしやすいSquidを採用しました。
squid.confでホワイトリストファイルを次のように指定します。

 acl whitelist-domain dstdomain "/path-to/whitelist-domain"

ホワイトリストファイル(上記例だとwhitelist-domain)には、アクセス許可したいバケットのFQDNを列挙します。

  <bucket1>.s3-<region>.amazonaws.com
  <bucket2>.s3-<region>.amazonaws.com
  ・・・
S3へのアクセス制御

VPC内からのS3バケットアクセスのみを許可するため、S3用のVPC endpoint を作成して、 IAMユーザに割り当てるポリシーのCondition要素で、接続元のVPC endpoint idが一致する場合のみアクセス許可するように設定しています。VPC endpointとS3は同一リージョンである必要があります。

       "Condition": {
         "StringEquals": {
           "aws:SourceVpce": "<vpce-id>"
         }
       }
ログの保管
infra.awslog.blog.png

ログ保管のため、Squidログやsecureログなどのセキュリティ系ログをインスタンスから CloudWatchへ送っています。ログを送るためインスタンスでawslogsを稼働させています。
CloudWatchに恒久的にログを保管すると、費用が高くつきますので、古いログはさらにS3に退避するようにしています。このためログ保管専用のバケットを用意しています。
S3へのログ退避は、ログをS3にexportする処理を行うLambda関数を作成して、 CloudWatch Eventsをトリガーとして、dailyで定期実行するようにしています。
またS3のアクセスログ記録も有効にして、log保管用の専用バケットにログを保管するようにしています。

改竄防止

セキュリティ系ログを改竄されないように、バケットポリシーで権限を最小限に絞り、ログの削除・変更をできないようにしています。 以下はバケットポリシーに追加する設定の例です。ログを保管するバケットではバージョニングを有効にしています。

 {
     "Version": "2012-10-17",
     "Statement": [
         {
             "Sid": "<description>",
             "Effect": "Deny",
             "Principal": "*",
             "NotAction": [
                 "s3:List*",
                 "s3:Get*",
                 "s3:AbortMultipartUpload",
                 "s3:PutObject",
                 "s3:PutObjectTagging",
                 "s3:PutBucketTagging",
                 "s3:PutMetricsConfiguration",
                 "s3:DeleteObjectTagging",
                 "s3:DeleteObjectVersionTagging",
                 "s3:ListBucket"
             ],
             "Resource": [
                 "arn:aws:s3:::<bucket>",
                 "arn:aws:s3:::<bucket>/*"
             ]
         }
     ]
 }

rootアカウントでは、バケットポリシーの変更が可能ですが、弊社にはAWSアカウントの自動監査 の仕組みがあり、この仕組みによりrootアカウントログインがあった場合は通知により気づくことができます。

インスタンスへのログイン

許可する通信を最小限にしたかったので、sshのinbound許可の必要がないSSM セッションマネージャを利用しました。
注意点としまして、WebSocket に対応していないproxyを経由してAWS マネジメントコンソールにアクセスしている場合は、SSM セッションマネージャでのコンソール操作ができません(私の使用しているクライアントPCでは動作確認用にinstallしていたツールがWebSocket に対応しておらず、この問題に躓きサポートに頼りました)。
SSM セッションマネージャの利用のためscreenがinstallされていない場合はinstallしておく必要があります。また、amazon-ssm-agentをインスタンスで稼働させる必要があります。このために必要な作業は一時的にsshアクセスを許可して行いました。
SSM セッションマネージャの設定は、AWS マネジメントコンソールでは[セッションマネージャ]の[設定タブ」から行います。
証跡ログを残すため、セッションログをS3に暗号化して保管するようにしています。このログを保管するS3バケット側でも暗号化が有効になっている必要があります。
また、アクティブなセッションデータをKMSで暗号化するようにしています。
amazon-ssm-agentに必要な権限はインスタンスのIAMロールで与えています。デフォルトで用意されているポリシーAmazonEC2RoleForSSMは権限が強い(リソース制限なしのs3:GetObject, s3:PutObjectがある)ので、 必要な権限だけ与えるようにカスタマイズしたポリシーを作成して権限を付けました。 最低限必要な権限は、公式ドキュメントの最小限の Session Manager アクセス権限 と、SSM エージェント の最小 S3 バケットアクセス許可を参照しています。
ログを保管するバケットに対しては、s3:PutObjectの権限が必要で、上記のようにセッションログを暗号化して保管する場合には、ログを保管するバケットに対して、s3:GetEncryptionConfigurationの権限も必要となります。

通信制御

セキュリティグループで許可する通信を最小限にするため、以下のVPC endpointを作成しています(既出のS3 endpointも以下に含めています)。
S3のみgateway type、他はinterface typeのendpointです。

  • com.amazonaws.<region>.s3
  • com.amazonaws.<region>.ssm
  • com.amazonaws.<region>.ec2messages
  • com.amazonaws.<region>.ec2
  • com.amazonaws.<region>.ssmmessages
  • com.amazonaws.<region>.kms
  • com.amazonaws.<region>.monitoring

ssm,ec2messages,ec2,ssmmessagesのendpointはSSM セッションマネージャの利用に必要な通信のため作成しています(詳しくは公式ドキュメントを参照下さい)。 SSM セッションマネージャでセッションデータの暗号化をする場合には、KMS endpoint作成も必要です。monitoring endpointはCloudWatch用です。
仕上げとして必要な通信だけ許可するようにセキュリティグループで設定します。 VPC内のipと、vpn経由の通信以外は、inboundに必要な通信はありませんのでdenyします。
outboundについては、VPC内のipと、vpn経由からの通信以外に、S3 endpointのプレフィックスリストIDに対して、80port,443portを許可します。
80portはSSM セッションマネージャでセッションログをS3に保管する場合に許可が必要です、公式ドキュメントの「Systems Manager の前提条件」に記述がありませんが、ソース の以下箇所で使用しています。S3バケットに対してHEADメソッドを使ってリージョン情報を取得する処理です。

 func getRegionFromS3URLWithExponentialBackoff(url string, httpProvider HttpProvider) (region string, err error) {
    // Sleep with exponential backoff strategy if response had unexpected error, 502, 503 or 504 http code
    // For any other failed cases, we try it without exponential back off.
    for retryCount := 1; retryCount <= 5; retryCount++ {
        resp, err := httpProvider.Head(url)
監視

基本的なリソース監視としてcpu,メモリ,ディスクの使用率をCloudWatchで監視するようにしています。一定の閾値を超えた場合CloudWatchのアラーム設定により通知が飛びます。 メモリ,ディスクの使用率のモニタリングにはインスタンスにモニタリングスクリプトを設置して定期実行する必要があります。
死活監視としてインスタンスのステータスチェックのアラームも作成しています。
また、想定しないアクセスがあった場合に通知するように、CloudWatchに送っているSquidログに対して、メトリクスフィルターを作成し、ログにSquidホワイトリストにない宛先がある場合には、アラーム設定で通知が飛ぶようにしています。

切り替え

新しく環境を用意する場合は気にする必要はありませんが、元々internet経由から接続元IPを制限してS3を利用している場合には、 接続元が特定IPの場合と、特定VPCの場合を、or条件でアクセス許可して、VPCからのアクセスができることを確認してから、特定VPCの場合のみ許可するように絞るのが進め方として安心です。
ポリシー設定で、Conditionの列挙はandで評価されるため、両方の場合を許可するのには、以下のように、特定VPCでない場合、かつ特定接続元IPでない場合をdenyするポリシーを設定します。

   "Statement": [{
     "Effect": "Deny",
     "Action": "s3:<action>",
     "Resource": [
       "arn:aws:s3:::<bucket>",
       "arn:aws:s3:::<bucket>/*"
     ],
     "Condition": {
       "StringNotLike": {
         "aws:sourceVpce": [
           "<vpce-id>"
         ]
       },
       "NotIpAddress": {
         "aws:SourceIp": [
           "<ip-range>"
         ]
       }
     }
   }]

この状態で動作確認行い、S3バケットのアクセスログから、接続元IPがプライベートIPとなっていることを確認できればokです。 最後にVPC経由のアクセスのみ許可するようにポリシーを設定してinternet経由ではアクセスできなくなったことを確認します。

おわりに

以上、proxy環境が必要になった経緯と用意したproxy環境についての紹介をさせて頂きました。
TTLが短い場合にFWでのFQDNベースでの制御が効かないケースは他にも見かけます。類似の問題に取り組んでいる方がいるかと思います、そのような方のお役に立てば幸いです。

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

コンピュータビジョンの最新論文調査 動画認識編

はじめに

こんにちは,AIシステム部でコンピュータビジョンの研究開発をしている鈴木智之です.我々のチームでは、常に最新のコンピュータビジョンに関する論文調査を行い,部内で共有・議論しています.今回は動画認識編として鈴木 智之 (@tomoyukun) が調査を行い,CVPR 2019と今年10月末開催のICCV 2019に採択された動画認識に関する最新論文を紹介します.

過去の他タスク編については以下をご参照ください.

前提知識

動画認識は,行動分類や行動検出などに代表される,動画情報を入力に定義されるタスク全般のことをさします.近年では,画像認識同様,様々な動画認識のタスクにおいてCNNを用いたアプローチがメジャーです.CNNを用いた動画認識モデルは,目的タスクに応じて多少の差異はあるものの,特徴抽出部分やそれを構成する基本的なモジュールはタスク横断で汎用的に用いられることも多いです.行動分類や行動検出は,そういった動画認識モデルの汎用的な性能を測る上で最も重要視されるタスクで,これらのタスクで高い性能を達成したモデルは,動画認識の他タスクのモデルにもbackboneとして広く使用される傾向にあります.今回も,主に行動分類や行動検出を通して動画認識モデルの汎用的な有効性を主張する研究を紹介します.
動画は画像に対して時間方向の次元が追加されたデータですが,主に時間情報と空間情報の特性の違いが起因して,画像認識で有効な手法の単純な拡張が動画認識において十分とは限りません.特に,時間方向の特徴抽出方法については,入力からend-to-endでタスクに適した特徴表現を獲得するとされるCNNが登場した後も,盛んに議論が続けられるトピックの一つであり,動画認識における性能向上の肝となっていると言えます.今回紹介するCVPR 2019・ICCV 2019の研究では特に,学習方法の観点,さらには動画認識モデルの基本的な計算モジュールの観点から時間特徴抽出の改良に取り組み,動画認識モデルの性能向上を達成しているものが多いです.

タスク

動画認識に属する代表的な2タスクの概要と,関連するデータセットについて紹介します.

行動分類

各動画に1つ割り当てられた行動クラスを推定するタスクです.動画認識モデルの性能を評価する上で,最も重要視されます.

評価指標は動画単位のaccuracy (video accuracy) を見ることが最も多いです. 基本的に動画単位のラベルは,動画から決められた時間長で複数のclipをサンプリングし,各clipをモデルに入力することで得られる推定値の平均とされます.サンプリングは,決められた数のclipを一様もしくはランダムに抽出する方法,sliding windowで抽出する方法 (動画の長さによってclipの数が可変) などが用いられます.

関連する主なデータセットは以下です.基本的に,各動画に対応する行動クラスが与えられます.

  • Kinetics:膨大なデータ量と高いアノテーションの質から,現在最も信頼できるデータセットの一つ.複数種類が存在.
    • Kinetics-400 (2017):400クラス,306245動画.
    • Kinetics-600 (2018):Kinetics-400の拡張版.600クラス (内368クラスはKinetics-400と共有), 495547動画.
    • MiniKinetics (2018):Kinetics-400のsubset.200クラス (全てKinetics-400のsubsetと共有), 85000動画.
    • Tiny-Kinetics (2019):Kinetics-400のsubset.150クラス (全てKinetics-400のsubsetと共有), 約100000動画.
  • UCF101 (2012):Kinetics登場以前に最も用いられていたデータセットの一つ.101クラス, 13320動画.
  • HMDB51 (2011):51クラス, 6766動画.
  • SomethingSomething v1 (2017):174クラス, 108499動画.

UCF101のサンプルフレーム [19].
行動検出

動画内の行動クラスとその時空間的位置を推定するタスク (空間的位置は行動している人物の位置を意味します) です.行動検出には時空間的位置を推定するものと,時間的位置のみ推定するものが存在しますが,今回は紹介する論文の中で取り組まれている時空間行動検出タスクについて説明します(以降,行動検出は全て時空間行動検出をさします). 具体的には,フレーム単位の人物矩形もしくはaction tubeletと,それらに対応する行動クラスのスコアづけを行います.action tubeletとは,同一人物,同一行動クラスに属すると推定される,時間的に連続な人物矩形集合をさします (下図). 動画認識モデルの汎用的な性能を測る上では,既存の行動検出手法の特徴抽出部分を,提案する動画認識モデルに変更して比較評価する方法が多く用いられます.

action tubeletの概要図 [1].

評価指標にはframe mean average precision (frame mAP), video mean average precision (video mAP) が用いられます. frame mAPは,フレーム単位で推定される人物矩形とground truthの人物矩形のIntersection over Union (IoU) が閾値以上となっているものを正解とした時のaverage precisionをクラスごとに算出し,全クラスで平均したスコアです. video mAPはフレーム単位の人物矩形に代わり,action tubeletのIoUを元にaverage precisionの算出し,クラス方向の平均をとったものです.

関連する主なデータセットは以下です.基本的に,各動画の一部 or 全部のフレームにおける人物矩形とそれらに対応する行動クラスが与えられます.

  • AVA (2018):15分 × 437動画から作成されたデータセットで,アノテーションは1秒間隔で付与.60クラス,268005動画.
  • UCF101-24 (2013):UCF101のsubset.24クラス,3207動画.
  • J-HMDB (2013):HMDB51のsubset.21クラス,928動画.
  • UCF-Sports (2008):10クラス,150動画.

従来のアプローチ

動画に含まれる時空間情報のうち,空間特徴抽出は画像認識でその有効性が確認されている2D CNNの考え方を用いることができます.そのため,動画認識モデルでは時間方向の特徴抽出方法が議論になることが多く,今回はそこに焦点を当て従来のアプローチを紹介していきます.

optical flowの活用

動画における時間方向の関係を表す情報形式の1つとして,optical flowがあります. フレーム間のピクセルの空間方向移動ベクトルであるoptical flowは,単一フレームのピクセル輝度値から得られる「見え (appearance)」情報に対して,「動き (motion)」情報として動画認識においてCNN登場以前から広く使用されてきました.CNNを用いた動画認識手法においてもoptical flowの活用は非常にメジャーです.
2014年に提案され,近年でも多くの手法の元になっているものとして,Two-Stream Convolutional Networks (Two-Stream CNN) [2]があります.Two-Stream CNNは,単一フレーム (RGB) 画像を入力とするCNN (RGB-Stream) と時間方向にstackされたoptical flowを入力とするCNN (Flow-Stream) を学習し,各Streamからの出力をfusionする (例えば,平均をとる) 手法です.実際に,RGB-StreamからTwo-Streamにすることで大幅に性能を向上することができ,RGB / Flow-Streamが相補的な特徴を捉えていることが示唆されています. 他にも,Two-Stream CNNの派生としてRGBとoptical flowのfusion方法の最適化を模索する研究が行われており [9, 10],今回紹介する中にもそういった研究含まれています,
性能も高く,直感的にもわかりやすいoptical flowベースの手法ですが,デメリットの1つとしてoptical flowの高い計算コストがあります.そこで,CNNを用いて低計算コストで高精度に推定可能なoptical flowを活用し,全体としての計算コストを削減する試みもあります [17].また,optical flowの動画認識における有効性は,輝度変化への頑健性や動体の形状情報によるものであると実験から考察し,「動き」としての寄与を疑問視する研究もあります [16].こういった観点から,optical flowの動画認識への最適化という方針でより有効な動画特徴を模索する取り組みも存在します [11, 12].今回紹介する論文にも,これらのモチベーションが含まれているものが複数あります.

Two-Stream CNNの概要図 [2].
3D CNN

3D CNNは,2D CNNの2D畳み込み処理を時間方向に拡張した3D畳み込み処理 (下図) で時間方向の情報を考慮するモデルです.3D CNNの先駆け的手法として,2015年に提案されたC3D [3]があります.optical flowと異なり,タスクに適した時空間特徴をend-to-endで学習可能とされる3D CNNですが,C3Dの段階では,行動分類タスクにおいてTwo-Stream CNNに性能が劣っています (on UCF101).この結果を受けて,指摘された問題点は,2D CNNに対して大きく増加した3D CNNのパラメータを最適化するのに動画認識データセットのデータ量が十分ではなかったという点です (2D CNNの成功に大きく貢献したImageNetのサンプル数が100万を超えるのに対し,当時最もメジャーなデータセットであるUCF101の動画数は約13000).

3D畳み込みの概要図 [3].

これに対して,パラメータ数の削減のアプローチをとったのがP3D (Pseudo 3D CNN) [4] や(2+1)D CNN [5] (下図) です. P3Dや(2+1)D CNNは3D (x,y,t) の畳み込み演算を2D (x,y) -> 1D (t) の畳み込みで擬似的に表現することで,パラメータ数を削減し,結果的に精度を向上させました.

3D畳み込み (a) と(2+1)D畳み込み (b) [5].

データ量に関しても,30万以上の動画を有するKinetics-400が提案され,同データセット上の評価では3D CNNはTwo-Stream CNNを超える精度を記録しています [6].3D畳み込みカーネルの空間方向の重みをImageNet学習済みモデルの2D畳み込みカーネルの重みで初期化するInflationも提案され [6],動画認識におけるデータ量のボトルネックがさらに解消されました.

Attention

比較的最近提案されたアプローチとしては,自然言語処理などで有効性が確認されているAttention機構の応用があります.代表的なものは,Non-local Neural Networks [7] です.Non-local Neural Networksは,通常の2D / 3D CNNに対して以下のNon-local operationを中間的に導入をしたものです.

ここで,xは入力特徴マップ,yは出力特徴マップ,添字は座標のindexを表しています.gは座標単位で埋め込みを計算する線形結合で,入力特徴マップが3Dの場合は1×1×1畳み込み (2Dの場合は1×1畳み込み) として並列計算が可能です.fは座標iから見た座標jのAttentionを入力特徴マップにおける座標i, jの値を元に計算する関数です.出力特徴マップの座標iの値は,このAttentionによって各座標におけるgからの出力の重み付け和をC(x)によって正規化したものになります. Attentionの算出方法は複数提案されていますが,シンプルかつ高い効果が確認されているDot product (下式) が広く用いられています.

ここで,θ,φは線型結合で,gと同様入力特徴マップが3Dの場合は1×1×1畳み込みとして計算されます. 実際にはNon-local operationの後段に畳み込み処理を施し,残差構造を持たせたNon-local block (下図) が使用されます.これは,後段の畳み込み処理の重みを0で初期化することで,任意の事前学習済みモデルに対して学習初期におけるその挙動を妨げることなくNon-local operationを導入するためです.

Non-local blockの概要図 [5].

Non-local operationは,座標単位の線型結合・同一の関数fによる任意の座標ペアからのAttention算出・Attentionを用いた重み付け和という時空間的な局所性に捉われない処理で構成されることから,より大域的な特徴抽出に優れていると主張されています.2D CNNに対して時空間的なNon-local blockを導入することで3D CNNを上回る (on Kinetics) 結果も記録されており,時間方向の特徴抽出方法としての有効性も実験的に示されています [5]. 局所性を考慮した特徴抽出として用いられる3D畳み込みや隣接フレームからピクセルの動きとして抽出されるoptical flowなどの時間情報の考慮方法とは独立な意味合いをもつ印象が強く,3D CNNやTwo-Stream CNNなどに追加で使用することで一貫して性能を向上させる傾向にあります.

3D CNN + optical flow

3D畳み込み処理とoptical flowの組み合わせが行われる場合もあります.特に,3D CNNをTwo-Streamにする実験は頻繁に行われており,2D CNNの場合と同様,Two-StreamにすることでRGB-Streamのみの場合から大幅に精度が向上します.さらに,データセットによっては (UCF101,HMDB51など),Flow-Streamの方が精度が高い場合もあります [6]. このような結果から,パラメータ数の観点でのモデル改良やデータ量のボトルネックの軽減が進められた後も,3D CNNはoptical flowが捉えているような動画認識に有効な特徴を抽出しきれていない可能性が示唆されます. 3D CNNが「動き」を捉えていることを疑問視する研究 [8] も存在し,CNNを用いた動画認識モデルの最適性に関してはいまだに議論の余地が多くあると言えます. 今回紹介する論文は,こういった3D CNNの課題感から新たな学習方法やアーキテクチャの提案をしている研究も複数含んでいます.

論文紹介

動画認識に関する最新論文を1つずつ紹介していきます. 特に断りがない限り,図は紹介論文から引用しています.

Representation Flow for Action Recognition (CVPR 2019)

AJ Piergiovanni and Michael S. Ryoo, "Representation Flow for Action Recognition", the IEEE Conference on Computer Vision and Pattern Recognition (CVPR), 2019. [Paper] [Project page] [Code]

要約

optical flowの計算方法から着想を得た,動き特徴を抽出するための新しい計算モジュール,Representation flow layerを提案しました.CNNに組み込んでend-to-endに学習が可能で,各行動分類データセットにおいて大幅に精度を改善しました.

提案内容

Representation flow layer
Representation flow layerはTV-L1 optical flowの計算方法を元に定義されます.TV-L1 optical flowは,「時間的に隣接した画像間の対応点の輝度値は等しい」というoptical flow拘束と,「optical flowは空間方向に滑らかに変化する」という制約を元に定義されたエネルギー関数を最小化することで得られます.エネルギー関数はiterativeな計算を用いて最小化できることが知られており[15],このiterativeな計算は微分可能なので,CNNに組み込むことができます.これを新たな動き特徴を抽出する層と捉えたものがRepresentation flow layerです. Representation flow layerの計算方法とその概念図を以下に示します.基本的にTV-L1 optical flowのiterativeな計算と同一の処理です.

(左) Representation flow layerの計算方法.(右) Representation flow layerの概要図.

上記計算のうち,空間方向の微分計算はSobel filerの畳み込みとして表されます.

また,ダイバージェンスは以下のように計算されます.

学習時に,TV-L1 optical flow最適化のハイパーパラメータである θ,λ,γ やSobel filerの重み,さらにはダイバージェンス計算の重みの勾配計算が可能で,学習パラメータとすることができます.これらを学習パラメータに含め,end-to-endに学習することで,目的タスクに最適化された動き特徴を抽出できると主張しています.
また,Representation flow layerはRGB画像に対してのみではなく,CNNの中間層に組み込むことで,特徴マップに対しても動き特徴を計算します.これは,optical flow拘束が特徴マップ上においても成立する,すなわち「時間的に隣接した特徴マップ間の対応点の値は等しい」という仮定から,意味のある動き特徴が抽出できるという考えです.
論文中では,RGB画像,もしくは特徴マップに対してRepresentation flow layerによって抽出される動き特徴をRepresentation flowと呼称しています.

Flow-of-Flow
Representation flow layerの時間的受容野は隣接フレーム間に限られます.時間的受容野を広げる方法の1つとして,Representation flow layerのcascadeがあげられます. しかし,一般にoptical flow mapにおいては (特に非線形な動きをしている場合),optical flow拘束,すなわち「時間的に隣接したoptical flow mapの対応点の値 (動き) は等しい」という仮定が成り立つとは限りません.したがって,optical flow mapに対してさらにoptical flowを計算しても,(動画認識において) 有用な意味を持たず,Represetation flowにおいてもこれは例外ではないと予想されます. そこで,Represetation flow layerの間に畳み込み層を挟み,end-to-endに学習する方法 (Flow-of-Flow) を取っています.こうすることで,畳み込み層が,次のRepresentation flow layerによって意味のある特徴が抽出されるような (例えば,optical flow拘束を満たすような) 変換を行い,上記の問題が解消され,より広い時間長の考慮が可能になると主張しています.

Flow-of-Flowの概要図.
実験結果

Representation flow layerをCNNのどこに組み込むか,また何を学習パラメータとすべきかを検証する意図で,Tiny-KineticsとHMDB51で実験を行なっています.
下に示す結果から,RGB入力の直後にRepresentation flow layerを入れる場合は,通常のoptical flowを入力するCNN (図中 Flow CNN) と近い精度となりますが,より深い層に組み込むことで精度が向上していることがわかります.Block4以降で精度が下がっていることに関しては,特徴マップの抽象度が高くなることで,隣接フレーム間で類似したものとなり,有用な動き特徴が抽出しにくいためと考察しています.
また,学習パラメータに関しては.θ,λ,γとダイバージェンスの重みを学習する場合が最も良い精度を記録しています.

(左) Representation flow layerの組み込み位置の検証結果.(左) Representation Flow Layerの学習パラメータ選択の検証結果.(評価指標はaccuracy,backboneは全て2D ResNet-34.)

次に,Representation flow layerとRGB情報のfusion方法について,以下の3種類について検証を行なっています. 結果から,著者らは,適切な深さでRepresentation flowを抽出すればRGB情報とのfusionの効果は薄いと主張し,以降の実験ではfusionを行わない方法を取っています.

(左) Representation flow layerとRGB情報のfusion方法.(a) fusionしない (None) (b) 最終的な出力の平均をとる (Late) (c) 中間特徴の要素和,要素積,結合 (Add / Multiply / Concat).(右) Representation flow layerとRGB情報のfusion方法の検証結果.(評価指標はaccuracy.backboneは全て2D ResNet-34.)

Flow-of-Flowの効果についての検証結果を以下に示します.畳み込み層を挟まずにRepresentation flow layerを2回重ねる (図中 Flow-of-Flow) と予想通り精度が低下するのに対して,畳み込み層を挟むと (図中 Flow-Conv-Flow) 大幅に向上しています.精度向上の要因の一つとして,時間的な受容野の拡大が挙げられています.一方で,3回以上重ねると精度が低下し,この原因を上述の特徴マップの抽象化と考察してます.

Flow-of-Flowの検証結果.(評価指標はaccuracy.backboneは全て2D ResNet-34.)

3D CNNや (2+1)D CNNに対して組み込んだ場合の結果を以下に示します.すでに時間方向の特徴を抽出しているこれらのCNNに適用した場合も,2D CNNの場合と同様にRepresentation flow layerの効果は大きく,Two-Streamにした場合よりも高い精度を記録しています.ここから,Representation flow layerは3D,(2+1)D畳み込み処理では捉えられないような動き特徴を抽出できていると考察しています.

3D CNNや (2+1)D CNNへのRepresentation flow layerの適用結果.(評価指標はaccuracy.backboneは全て2D ResNet-18.)

Kinetics-400,HMDB51における従来手法とのaccuracy,Run-timeの比較を以下に示します. 低い計算コストで,従来手法を上回る精度を記録しています.Representation flow layerはoptical flowと比較して,ダウンサンプリングされた特徴マップ上で計算されること,精度をあげるために行われるmulti scale warping処理がないこと,最適化のiterarion数が少ないことにより,計算コストを大幅に抑えることができています.

従来手法との比較結果.(Run-time計測のbackboneは全てResNet-34.評価指標はaccuracy.それぞれのbackboneは異なり,提案手法のbackboneはResNet-50.)

MARS: Motion-Augmented RGB Stream for Action Recognition (CVPR 2019)

Nieves Crasto, Philippe Weinzaepfel, Karteek Alahari and Cordelia Schmid, "MARS: Motion-Augmented RGB Stream for Action Recognition", the IEEE Conference on Computer Vision and Pattern Recognition (CVPR), 2019. [Paper]

要約

学習時にFlow-Streamを教師モデルとしてRGB-Streamに知識蒸留を行うことで,テスト時にはRGB入力のみでTwo-Streamに近い性能を達成しています.optical flowの計算が不要であるため,全体としての推論時間と精度のトレードオフを大幅に改善しました.

提案内容

メインとなるロスに加えて,Flow-Streamの中間出力を模倣する (知識蒸留) ようにRGB-Streamを学習することで,RGB入力のみからFlow-Streamによって獲得されているような動き特徴も抽出するよう促します.計算コストの高いoptical flow計算が必要なのは学習時のみであるため,推論時の処理はTwo-Streamと比較して高速となります.学習手順の異なる2つのパターン (MERS:Motion Emulating RGB Stream,MARS:Motion-Augmented RGB Stream) が提案されており.いずれの場合もまずFlow-Streamのみをメインとなるロス (行動分類の場合はCross Entropy) で学習し,その重みはRGB-Stream学習時は固定されます.

MERSは以下の2段階で学習されます.

  • Step1:RGB-Stream (MERS) とFlow-Streamそれぞれの最終層入力前の中間特徴のMean Squared Error (知識蒸留のロス) を最小化するように学習します.
  • Step2: MERSの最終層以外の重みを固定して,教師ラベルとのCross Entropyを最小化します.

MERS学習の概要図.

MARSは,知識蒸留とCross Entropyの最小化を段階的に行うMERSに対し,教師ラベルとの知識蒸留のロスとCross Entropyの重み付け和をend-to-endで最小化します.Flow-Streamへの模倣をしつつ,RGB入力からの推定に最適化された特徴抽出を行わせることを意図しています.

MARS学習の概要図.
実験結果

各行動分類データセットにおける,結果を下図に示します. MERSに注目すると,どのデータセットでもFlow-Streamと近い精度を記録しています.また,Flow-Streamとのアンサンブルと (MERS + Flow) 比較して,RGB-Streamとのアンサンブル (MERS + RGB) の方が精度向上が大きいことがわかります.これらから,MERSはRGB入力であるのにも関わらず,Flow-Streamの特徴抽出をうまく模倣できていることを主張しています.MARSについては,どのデータセットにおいてもRGB / Flow-Streamよりも高い精度を記録しており,Two-Streamに近い精度を達成しています.全体としてはMARSの方が高精度であり,Flow-Streamの特徴抽出の模倣とメインのロスの最小化を同時にend-to-endで行うことの有効性が確認できます.

行動分類の結果 (評価指標はaccuracy.backboneは全て3D ResNeXt-101.).

各手法のMiniKineticsにおける精度と推論時間を下図に示します. 提案手法であるMARS, MERSは推論時にoptical flowの計算が不要であるため,TV-L1 optical flowを用いたTwo-Streamに匹敵する精度を記録しつつ,推論時間は高速です.

各手法の精度と推論時間.(backboneは全て3D ResNeXt-101.)

Kinetics-400において,MARSによってRGB-Streamから精度向上 / 低下した上位3クラスとそれらに対する各Streamの精度を下図に示します.精度の向上が大きかったクラスはFlow-Streamで高い精度を記録していたクラスであり,クラスによってはFlow-Streamを上回っています.また,精度が低下したサンプルはFlow-Streamで精度が低かったクラスですが,Flow-Streamと比較するとMARSは高い精度を記録しています.これらから,MARSはRGB / Flow-Streamの中間的な特徴,もしくは双方を組み合わせることによる相乗効果で各Single-Stream以上に有効な特徴を抽出していると主張しています.

RGB-Streamに対してMARSによって精度向上した上位3クラス (Top3) と精度低下した上位3クラス (Bottom3).(backboneは全て3D ResNeXt-101.)

Kinetics-400,UCF101,HMDB51,SomethingSomething v1における従来手法との比較を下図に示します.Kinetics-400では,事前学習なしにも関わらず,既存手法に匹敵する精度を記録しました.UCF101,HMDB51,SomethingSomething v1においても,RGB入力,RGB + Flow入力いずれの条件でも最高精度を達成しました.

(右) Kinetics400における従来手法との比較結果,(左) UCF101,HMDB51,SomethingSomething v1における従来手法との比較結果.(評価指標はaccuracy.それぞれのbackboneは異なり,提案手法のbackboneは3D ResNeXt-101.)

Learning Spatio-Temporal Representation with Local and Global Diffusion (CVPR 2019)

Zhaofan Qiu, Ting Yao, Chong-Wah Ngo, Xinmei Tian and Tao Mei, "Learning Spatio-Temporal Representation with Local and Global Diffusion", the IEEE Conference on Computer Vision and Pattern Recognition (CVPR), 2019. [Paper]

要約

通常の2D / 3D 畳み込み処理による特徴抽出を行うLocal pathに加え,入力動画全体の特徴を集約するGlobal pathを含む,Local Global Diffusion (LGD) blockを提案.行動分類,行動検出タスクの様々なデータセットで,一貫した精度向上を記録しました.

提案内容

Local Global Diffusion (LGD) block
一般に,CNNで時空間的にlong-rangeな依存関係を考慮したい場合は,畳み込みやpoolingなどの局所的な処理を多層にして,受容野を広げます.これに対し,著者らは,受容野内でも時空間的に遠い領域の影響は相対的に小さくなると主張しています.提案するLGD blockに含まれるGlobal pathは入力動画全体の特徴を集約する役割をもち,効率的にlong-rangeな依存関係の考慮を行います.

下図にLGD blockの概要図を示します.LGD blockを構成するLocal pathとGlobal pathは,それぞれLocal representation (C × T × H × W),Global representation (C × 1 × 1 × 1) を出力します (Cはチャネル数,T, H, Wはそれぞれ特徴マップの時間方向,高さ方向,幅方向の次元数).また,これらは相互にpathを有しています.

LGD blockの概要図.

上図に対応させて各pathからの出力を式で表すと以下のようになります.

Upsamplingは,Global representationの値を各時空間座標にコピーして,Local representationと同じ次元に揃える処理です.Local Transformationは,通常の2D / 3D 畳み込み処理が用いられます.Weighted connectionsは,線形結合を表し,その重みは学習対象となります.また,Function of sumは,要素和を表します.最終的にはLGD blockを複数連結したモデルを構築します.最初のLGD blockに入力するLocal representationは入力clipにLocal Transformationを一度施したもの,Global representationはそれに対してGlobal Average Pooling (GAP) をしたものとします.

LGD-2DとLGD-3D
論文中では,Local Transformationに2D畳み込みを用いる場合はLGD-2D,3D畳み込みを用いる場合はLGD-3Dと呼称しています.LGD-2Dは,Local Transformationとして,weight-shareな2D畳み込みがフレームごとに行われます.また,long-termな情報を効率よく考慮するために,動画全体をT個のsegmentに分割し,各segmentから1フレームを選出することで,入力を作成しています.対して,LGD-3Dは連続した複数フレームを入力とし,Local Transformationとして3D畳み込みが行われます.実験では,計算コスト削減のためP3Dが用いられています.

LGD-2DとLGD-3Dの概要図.
実験結果

提案するLGD blockの最適性を検証するために,Kinetics-600においてLGD blockのvariantsと比較しています.

  • block_v1: 前blockのGlobal representationからのpathをなくした構造で,この場合のGlobal representationは以下のように表されます.

  • block_v2: Local representation計算時に要素和ではなく要素積をとる構造で,SE block [13] と近い処理となります.Local representationは以下のように表されます.

結果は以下になります.LGD blockのaccuracyが最も高いことから,LGD blockの有効性とその構造の最適性が主張されています.ベースラインとなる手法に対しても精度向上が確認できます.

LGD blockの最適性に関する検証結果.(評価指標はaccuracy.TSN baseline, P3D baselineはLGD-3D, LGD-2DそれぞれにおいてLGD-blockを導入する前のベースモデルでbackboneはResNet-50.)

次に,Kinetics-400,Kinetics-600における従来手法との比較結果を以下に示します.RGB,Flow,Two-streamのいずれの場合でも,LGD 3Dが最も高い精度を記録しています.Kinetics-600では,より深いbackbone (ResNet-152) を用いたモデルよりも高い精度を記録しています.

従来手法との比較結果.(左) Kinetics-400,(右) Kinetics-600.(評価指標はaccuracy.)

J-HMDBとUCF101-24における行動検出でもLGD blockの評価を行っています.人物候補領域はResNet-101ベースのFaster R-CNNによって検出し,それを用いてLGD-3DのLocal prepresentation上でRoI poolingされた特徴量から,各行動クラスのスコアを算出しています.結果は以下であり,従来手法を大きく上回る結果となりました.

J-HMDB,UCF101における従来手法との比較結果.(評価指標はvideo mAP.)

Dance with Flow: Two-in-One Stream Action Detection (CVPR 2019)

Jiaojiao Zhao and Cees G. M. Snoek, "Dance with Flow: Two-in-One Stream Action Detection", the IEEE Conference on Computer Vision and Pattern Recognition (CVPR), 2019. [Paper] [Code]

要約

optical flowを入力とするbranchからの出力を元に,RGB-Streamの複数の中間特徴をscale,shiftする,Two-in-one Stream CNNを提案.空間的なlocalizationに強く,特に行動検出タスクにおいて,精度向上を達成しました.

提案内容

Two-in-one Stream CNN (Two-in-one) の概要を下図に示します.RGB-Streamの決められた層の特徴マップに対して,optical flowを入力にMotion condition (MC) layerとMotion modulation (MM) layerを通じて計算されたβ,γを用いて,scaleとshiftを行います.MC layer,MM layerは下図に示すようにcascadeされており,MC layerはネットワーク全体で重みを共有,MM layerはRGB-Streamにおいて導入する位置によって異なる重みを持ちます.β,γは対応するRGB-Streamの特徴マップと同一次元であり,それぞれ特徴マップとの要素積,要素和が計算され,次のRGB-Streamの層に入力されます.
Two-in-oneは,Single-Streamに対して,2倍近くになるTwo-Streamと比較すると計算コストの増加は少なくすみます.また,RGB-StreamとFlow-Streamを別々に学習するTwo-Streamに対して,RGB画像とoptical flowを同一のネットワークに入力して,end-to-endに学習している点が異なります.実験の中ではTwo-in-oneに対して,さらにFlow-Streamを加えたTwo-in-one two streamも用いています.

Two-in-one Stream CNN (Two-in-one) の概要図.
実験結果

UCF101-24における行動検出,UCF101における行動分類の結果を下図に示します.行動検出においてはTwo-Streamに対して,低計算コストで高い精度を達成,行動分類においても各Single-Streamよりも高い精度を記録しており,Two-in-one two streamにするとTwo-Streamを超える精度となります.特に,行動検出において効果を発揮した要因としては,optical flowを元に特徴マップをscale,shiftするのは動体領域の情報をRGB-Streamに加える効果があり,空間的なlocalizationに強くなるためであると考察しています.

(左) UCF101-24における行動検出,(右) UCF101における行動分類の結果.(sec / frameにはoptical flowの計算時間は含まれていない.backboneはVGG-16.)

MM layerの位置による精度の変化を下図に示します.入力に近い層に単一のMM layerを入れる方法が最も良い結果となっています.MM layerは主に動体領域の抽出の役割をしているという観点から,特徴マップの空間方向の抽象化が進行する前の浅い層で効果を発揮しているのではないかと考えられます.

MM Layerの位置 (横軸) ごとのUCF101-24における行動検出精度 (縦軸) .(a) 単一のMM layerの場合 (b) 複数のMM layerの場合.(backboneはVGG-16.)

MC / MM layerの出力とshift,scaleされた特徴マップの可視化例を下図に示します.MC / MM layerからの出力は,RGBのみでは抽出できていなかった動体領域に大きく反応していることがわかります.

MC / MM layerの出力とshift,scale前後の特徴マップの可視化例.2行目以降は,各列が特徴マップにおける同一のチャネルに対応.

各行動検出データセットにおける従来手法との比較を下図に示します.特にIoU閾値が厳しい条件において,Two-in-one,Two-in-one two streamが高い精度を記録しており,MC / MM layerを導入することにより,空間的なlocalizationの性能が向上していることがわかります.

各行動検出データセットにおける従来手法との比較結果.(提案手法と同一のbackboneで,Two-Streamとなっている手法は,Single-frameでは表中のSinghらの手法,Multi-frameでは表中のKalogeitonらの手法.評価指標はvideo mAPで2行目は検出矩形のIoU閾値.提案手法のbackboneはVGG-16.)

SlowFast Networks for Video Recognition (ICCV 2019 Oral)

Christoph Feichtenhofer, Haoqi Fan, Jitendra Malik and Kaiming He, "SlowFast Networks for Video Recognition", the International Conference on Computer Vision (ICCV), 2019. [Paper (arXiv)]

要約

低い時間的解像度で空間的な意味特徴の抽出を担うSlow pathwayと,高い時間的解像度で動き特徴の抽出を担うFast pathwayからなるSlowFast Networksを提案.計算コストと精度のトレードオフを大幅に改善しました.

提案内容

動画認識で重要な特徴を,空間的な意味情報 (例えば,写っている物体クラスやそれらの大まかな配置,シーン情報など) とそれらの動き情報に分割できると考え,前者の時間的な変化は遅いが,後者を捉えるには高い時間的解像度が必要と仮定.そこで,各々の特徴抽出を異なる時間解像度入力のネットワーク (Slow pathway,Fast pathway) に担わせるSlowFast Networksを構築しました.
SlowFast Networksの概要図と,3D ResNetをベースにした場合の各pathwayの構造を以下に示します.Slow pathwayは入力の時間解像度は低く,res4,res5以外のblockは空間方向の2D畳み込みとなっています.これは,時間的な解像度が低いときフレーム間の物体の移動量が大きいため,空間方向の受容野が十分に拡大されない浅い層では時間方向の関係性を見ても効果は薄いと考えれるためです. Fast pathwayはSlow pathwayと比較して時間的解像度は高いですが,チャネル数や空間方向の情報が削減 (実験参照) されているため,計算コスト(FLOP数)はSlowFast Networks全体の15 ~ 20%に抑えられます.また,決められたblockの直後にpathway間の結合(lateral connection)を持たせており,この結合は実験通してFast pathwayからSlow pathwayのみの単一方向と決めています.具体的な結合方法についてはablation study(実験参照)を行なっています.

(左) SlowFast Networksの概要図と,(右) 3D ResNetをベースにした場合の各pathwayの構造.

実験結果

従来手法との比較を以下に示します.optical flowの使用や事前学習をせずに従来手法よりも高い精度を記録していること,Slow pathwayに対してFast pathwayを加えることで,計算コストと精度のトレードオフが大幅に改善していることがわかります.

(左) Kinetics-400における従来手法との比較結果 (評価指標はaccuracy.SlowFastの右に示される表記は順に,(Slow pathwayの入力フレーム数) × (Slow pathwayの時間方向のstride数), SlowFast Networksのbackbone.backboneはそれぞれ異なる.) (右) Kinetics-400における,計算コストと精度のトレードオフ.

Slow pathway,Fast pathway間のlateral connection方法に関して,以下の3種類を比較検証しています.

  • (i) Time-to-channel (TtoC):Fast pathwayの特徴マップを時間方向に分割,それらをchannel方向に結合する形でreshapeし,特徴マップのサイズをSlow pathwayの特徴マップに合わせる方法.最終的に,Slow pathwayの特徴マップとsum or concat.
  • (ii) Time-strided sampling (T-sample):Fast pathwayの特徴マップを時間方向にsamplingし,Slow pathwayの特徴マップと時間方向の次元数を合わせる方法.最終的に,Slow pathwayの特徴マップとconcat.
  • (iii) Time-strided convolution (T-conv):Fast pathwayの特徴マップにstrideありの3D畳み込みを行うことで,Slow pathwayの特徴マップと時間方向の次元数を合わせる方法.最終的に,Slow pathwayの特徴マップとconcat.

結果を以下の (a) に示します.単純な最終出力のconcatのみでは精度向上が0.9%に止まるのに対し,latetal connectionを入れると改善幅が大きくなります.特に,Time-strided convolutionを用いる場合が最も良い結果を記録しています.

Fast pathwayのchannel数に関する検証結果を以下 (b) に示します.βが1/8程度までの範囲では,channel数の増加による精度の向上が見られますが,それ以上は向上幅が小さい,もしくは精度が悪化する傾向にあります.Slow pathwayに対してFast pathwayのchannel数が相対的に少なくても十分であることが判断できます.

Slow pathwayの軽量化方法に関する検証結果を以下 (c) に示します.空間的解像度の削減,グレースケール化,時間差分画像,いずれの軽量化を施したFast pathwayを用いてもSlow pathwayのみのベースラインと比較して精度向上が確認できます.特にグレースケール化は,計算コストと精度の双方において最も良い結果となりました.

(a) lateral connection方法の検証結果.SlowFastの内,表記がないものは各pathwayの最終出力のconcat.(b) Fast pathwayのchannel数に関する検証結果.βはSlow pathwayに対するFast pathwayのchannel数の割合を示す.(c) Slow pathwayの軽量化方法に関する検証結果.(評価指標はaccuracy,backboneは全て3D ResNet-50.)

行動検出のbackboneとしてのSlowFast Networksの性能をAVA datasetにおいて検証しています.人物候補領域はDetectron [14] のFaster R-CNNをAVAでfine-tuningしたモデルによって検出,それを元にSlowFast Networksの特徴マップ上でRoI alignベースのpoolingを行い,各人物矩形の行動クラス推定を行なっています.結果は下図のようになり,optical flowを使用せずに従来手法を上回るmAPを記録しています.

AVA datasetにおける行動検出の従来手法との比較結果.(評価指標はframe mAP,提案手法のbackboneは3D ResNet-101.)

さらに,下図にSlow pathwayのみとSlowFast Networksの場合におけるAVAの各クラスの精度を示します.全体としてFast pathwayを使用することによる精度の向上は大きく,"hand clap","swin","run / jog"をはじめとする動き情報が大きな手がかりとなると予想されるクラスの改善が特に大きいことがわかりました.

AVA datasetにおける行動検出のクラスごとの精度.(評価指標はframe mAP,提案手法のbackboneは3D ResNet-101.).

おわりに

今回は動画認識分野におけるコンピュータビジョンの最新論文をご紹介しました.単一画像に対してよりリッチな情報である動画を用いてコンピュータビジョンのタスクを解く試みは,可能性に満ちており以前から注目され続けていますが,計算コストと精度の両面においてデファクトスタンダードとなる動画認識モデルの確立は長らくされていなかったように思います.一方で、今回紹介した論文の中には,動画情報の特性と先行研究の課題感から従来の動画認識モデルに大きな変更を加えて性能改善を行ったものもあり,こういった最近の研究の流れが動画認識分野を一気に前進させる可能性にも期待できます.DeNA CVチームでは引き続き調査を継続し,最新のコンピュータビジョン技術を価値あるサービスに繋げていきます.

参考文献

  • [1] Kalogeiton et. al, "Action tubelet detector for spatio-temporal action localization", ICCV 2017.
  • [2] Simonyan et. al, "Two-stream convolutional networks for action recognition in videos", NIPS 2014.
  • [3] Tran et. al, "Learning spatiotemporal features with 3D convolutional networks", ICCV 2015.
  • [4] Qiu et. al, "Learning spatio-temporal representation with pseudo-3d residual networks", ICCV 2017.
  • [5] Tran et al, "A closer look at spatiotemporal convolutions for action recognition", CVPR 2018.
  • [6] Carreira et. al, "Quo vadis, action recognition? a new model and the kinetics dataset", CVPR 2017.
  • [7] Wang et. al, "Non-local neural networks", CVPR 2018.
  • [8] Huang et. al, "What Makes a Video a Video: Analyzing Temporal Information in Video Understanding Models and Datasets", CVPR 2018.
  • [9] Feichtenhofer et. al, "Convolutional two-stream network fusion for video action recognition", CVPR 2016
  • [10] Feichtenhofer et al, "Spatiotemporal residual networks for video action recognition" NIPS 2016
  • [11] Lee et. al, "Motion feature network: Fixed motion filter for action recognition", ECCV 2018.
  • [12] Y.-H. Ng et. al, "Actionflownet: Learning motion representation for action recognition", WACV 2018.
  • [13] Hu et. al, "Squeeze-and-excitation networks", CVPR 2018.
  • [14] Girshick et. al, Detectron. https://github.com/facebookresearch/detectron, 2018.
  • [15] Zach et. al, "A duality based approach for realtime tv-l1 optical flow", DAGM Conference on Pattern Recognition 2017.
  • [16] Sevilla-Lara et. al, "On the integration of optical flow and action recognition", GCPR 2018.
  • [17] Ilg et. al, "Flownet 2.0: Evolution of optical flow estimation with deep networks", CVPR 2017.
  • [18] Kay et. al, "The kinetics human action video dataset", arXiv 2017.
  • [19] Soomo et. al, "UCF101: A Dataset of 101 Human Actions Classes From Videos in The Wild", CRCV-TR-12-01 2012.
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

Cisco WLC を Act-Act で運用する話

こんにちは、IT 基盤部ネットワークグループの寺増です。

前回の 無線 LAN の通信品質を見える化する話 に続き、今回はヒカリエ本社における Act - Act 構成の WLC 運用とその中での自動化手法を紹介します。内容はネットワークエンジニア、特にエンタープライズの無線 LAN を運用中の方、これから構築を行われる方、そして無線 LAN に興味をお持ちの方向きになっています。

目次

  • はじめに
  • メリット/デメリット
  • 内製 CLI について
    1. 概要
    2. 処理フロー
    3. 自動化への応用
  • 最後に

はじめに

まずは、ヒカリエ本社の無線 LAN 基盤に関するネットワーク構成を簡単に紹介します。

img01.png

主要な機器は以下の通りです。

  • 無線 LAN コントローラ (以下、WLC)

    • Cisco Catalyst 9800 2 台
  • アクセスポイント (以下、AP)

    • Cisco Aironet AP4800 127 台 (1 フロアあたり 16 - 20 台)

全 VLAN とも CAPWAP を用いた Central Switching モデルで、二台の WLC に AP を分散して帰属させた所謂 Act - Act 構成を採用しています。

この Act - Act 構成にはメリットとデメリットが存在しています。本記事ではここから紹介していきます。

補足:本記事で紹介する運用は全て Catalyst 9800 / AP4800 の前身にあたる Cisco CT Series ならびに Lightweight AP でも有効です。

メリット/デメリット

最初にメリットです。これらは実際に我々が肌で感じているポイントです。

  • 費用面 / Cost

    • HA 構成時の N+1 スタンバイ WLC に類する予備機が不要
  • 運用面 / Quality

    • 実質スタンドアローン 2 台で、AP の片寄せが容易に可能
    • 同上の理由につき、トラフィックの負荷分散が可能
    • 同上の理由につき、段階的なバージョンアップ/ダウンが可能
    • 同上の理由につき、HA 構成に関連するバグの回避が可能
    • トラフィックが常に流れているので通信区間の異常に気づき易い
    • HA 構成の運用で発生する設定変更による全断と無縁
    • WLC 障害時の切り替えが比較的高速 (最大約 10 秒程度)

いずれも運用コストや通信品質を重要視する環境では捨てがたい特性となっています。次にデメリットを見ていきます。

  • 費用面 / Cost

    • HA 構成に比べて二倍の AP ライセンスが必要
  • 運用面 / Quality

    • 複数の AP が別々の WLC に帰属するため全体を俯瞰することが困難 (*図2)
    • 端末の移動等でそのデータを持つコントローラが不規則に変動する (*図3)

    img03_2_act_act.png

    図2: メトリクス (Channel Utilization) データが分散

    img02.png

    図3: 端末の移動によってデータを持つ WLC が変動

補足:2 台の WLC 両方で同じ設定変更を実行する必要がある点はデメリットではないと考えています。これは CUI 運用においてさほど大きな手間ではなく、それよりも全断無しで設定変更作業を行えるメリットが大きいと感じているためです。

先述のうち、費用面については Cisco Smart Account の登場によって解消されました。従来は WLC が AP ライセンスを持つモデルでしたが、2019/9E 現在、最新の WLC + AP の構成では AP 自身がライセンスを持つモデルとなっています。つまり Secondary WLC 用の余分なライセンス購入は不要です。

一方の運用面については変わらずで、これらは長期的に見て大きな手間となりえます。解決策として、別途アプライアンス Prime InfrastructureDNA Center を利用する手もありますが、これらはいずれも一長一短です。「可能な限りリアルタイム全体を俯瞰 する」目的においては、どちらも最善の一手と言い辛い部分が残っていました。

DeNA では、これを補う CLI を内製し、運用に組み込むことで Act - Act 構成の環境を成立させています。次項ではこれを紹介していきます。

内製 CLI について

1. 概要

CLI は wlap (cli wrapper for WLC and APs) と命名しています。主たる責務は「WLC を意識せず AP を管理すること」です。

実装について述べる前に、この CLI の利用で改善されているポイントを 3 つほど紹介します。

(1) 判読性の向上

無線 LAN は構成要素やメトリクスが非常に多く、かつ複数台の AP で 1 つのネットワークを構成するという特徴があります。このため、単一コマンドの実行結果だけで全体を俯瞰することが困難です。そしてこれは AP が 2 台の WLC に分散して帰属している Act - Act 構成の環境では尚の事となります。

例えば、単一のカバレッジ (ヒカリエ本社では「1 フロア」が該当します) を構成する AP の設定値と主要メトリクスを網羅的に確認したい場合、通常は以下の 3 ステップが必要になります。

1. 各 WLC で帰属する AP のリストを取得

(例) show advanced 802.11a summary

 # WLC1

 (Cisco Controller) >show advanced 802.11a summary

 Member RRM Information
 AP Name  MAC Address        Slot  Admin    Oper   Channel     TxPower
 -------- ------------------ ----- -------- ------ ----------- -------------
 AP1      6c:9c:ed:eb:e0:a0   1    ENABLED  UP     (136,132)*  *1/7 (17 dBm)
 AP3      24:b6:57:5b:6f:70   1    ENABLED  UP     (136,132)*  *1/7 (17 dBm)

 # WLC2

 (Cisco Controller) >show advanced 802.11a summary

 Member RRM Information
 AP Name  MAC Address        Slot  Admin    Oper   Channel     TxPower
 -------- ------------------ ----- -------- ------ ----------- -------------
 AP4      24:b6:57:35:0d:90   1    ENABLED  UP     (36,40)*    *2/7 (14 dBm)
 AP2      24:b6:57:35:22:70   1    ENABLED  UP     124*        *2/7 (14 dBm)
  • 表示は AP の帰属順です、sort 相当の機能は提供されていないため視認性に難があります
  • Radio に関する各種ステータスは確認出来ますが、RF の主要なカウンタは確認出来ません

2. 各 WLC で取得した AP それぞれで 802.11a の情報を取得

(例) show ap auto-rf 802.11a AP1

 (Cisco Controller) >show ap auto-rf 802.11a AP1
 Number Of Slots.................................. 2
 AP Name.......................................... AP1
 MAC Address...................................... 6c:9c:ed:eb:e0:a0
   Slot ID........................................ 1
   Radio Type..................................... RADIO_TYPE_80211a
   Sub-band Type.................................. All
   Noise Information
     Noise Profile................................ PASSED
     Channel 36...................................  -94 dBm
     Channel 40...................................  -97 dBm
     Channel 44...................................  -95 dBm
     Channel 48...................................  -96 dBm
     Channel 52...................................  -96 dBm
     Channel 56...................................  -96 dBm
     Channel 60...................................  -96 dBm
     Channel 64...................................  -96 dBm
     Channel 100..................................  -96 dBm
     Channel 104..................................  -95 dBm
     Channel 108..................................  -96 dBm
     Channel 112..................................  -96 dBm
     Channel 116..................................  -96 dBm
     Channel 120..................................  -95 dBm
     Channel 124..................................  -93 dBm
     Channel 128..................................  -93 dBm
     Channel 132..................................  -96 dBm
     Channel 136..................................  -95 dBm
     Channel 140..................................  -96 dBm
   Interference Information
     Interference Profile......................... PASSED
     Channel 36................................... -128 dBm @  0 % busy
     Channel 40................................... -128 dBm @  0 % busy
     Channel 44................................... -128 dBm @  0 % busy
     Channel 48................................... -128 dBm @  0 % busy
     Channel 52................................... -128 dBm @  0 % busy
     Channel 56................................... -128 dBm @  0 % busy
     Channel 60................................... -128 dBm @  0 % busy
     Channel 64................................... -128 dBm @  0 % busy
     Channel 100.................................. -128 dBm @  0 % busy
     Channel 104.................................. -128 dBm @  0 % busy
     Channel 108.................................. -128 dBm @  0 % busy
     Channel 112.................................. -128 dBm @  0 % busy
     Channel 116.................................. -128 dBm @  0 % busy
     Channel 120.................................. -128 dBm @  0 % busy
     Channel 124.................................. -128 dBm @  0 % busy
     Channel 128.................................. -128 dBm @  0 % busy
     Channel 132.................................. -128 dBm @  0 % busy
     Channel 136.................................. -128 dBm @  0 % busy
     Channel 140.................................. -128 dBm @  0 % busy
   Rogue Histogram (20/40/80/160)
     .............................................
     Channel 36...................................  0/ 1/ 0/ 0
     Channel 40...................................  0/ 0/ 0/ 0
     Channel 44...................................  0/ 1/ 0/ 0
     Channel 48...................................  1/ 0/ 0/ 0
     Channel 52...................................  0/ 0/ 0/ 0
     Channel 56...................................  0/ 2/ 0/ 0
     Channel 60...................................  0/ 0/ 0/ 0
     Channel 64...................................  0/ 0/ 0/ 0
     Channel 100..................................  0/ 2/ 0/ 0
     Channel 104..................................  0/ 0/ 0/ 0
     Channel 108..................................  0/ 0/ 0/ 0
     Channel 112..................................  0/ 0/ 0/ 0
     Channel 116..................................  0/ 0/ 0/ 0
     Channel 120..................................  0/ 0/ 0/ 0
     Channel 124..................................  0/ 0/ 0/ 0
     Channel 128..................................  0/ 0/ 0/ 0
     Channel 132..................................  0/ 3/ 0/ 0
     Channel 136..................................  0/ 0/ 0/ 0
     Channel 140..................................  0/ 0/ 0/ 0
   Load Information
     Load Profile................................. PASSED
     Receive Utilization.......................... 0 %
     Transmit Utilization......................... 0 %
     Channel Utilization.......................... 22 %
     Attached Clients............................. 31 clients
   Coverage Information
     Coverage Profile............................. PASSED
     Failed Clients............................... 2 clients
   Client Signal Strengths
     RSSI -100 dbm................................ 0 clients
     RSSI  -92 dbm................................ 0 clients
     RSSI  -84 dbm................................ 1 clients
     RSSI  -76 dbm................................ 1 clients
     RSSI  -68 dbm................................ 0 clients
     RSSI  -60 dbm................................ 12 clients
     RSSI  -52 dbm................................ 17 clients
   Client Signal To Noise Ratios
     SNR    0 dB.................................. 0 clients
     SNR    5 dB.................................. 0 clients
     SNR   10 dB.................................. 1 clients
     SNR   15 dB.................................. 1 clients
     SNR   20 dB.................................. 0 clients
     SNR   25 dB.................................. 0 clients
     SNR   30 dB.................................. 3 clients
     SNR   35 dB.................................. 9 clients
     SNR   40 dB.................................. 8 clients
     SNR   45 dB.................................. 9 clients
   Nearby APs
     AP 00:08:30:d7:30:bf slot 1..................  -86 dBm on  44  40MHz (172.24.54.161)
     AP 6c:9c:ed:eb:c9:2f slot 1..................  -72 dBm on 128  40MHz (172.24.54.161)
     AP 7c:95:f3:74:a3:9f slot 1..................  -62 dBm on 128  40MHz (172.24.54.161)
     AP 7c:95:f3:fc:88:1f slot 1..................  -70 dBm on  36  40MHz (172.24.54.161)
   Radar Information
   Channel Assignment Information
     Current Channel Average Energy...............  -50 dBm
     Previous Channel Average Energy..............  -50 dBm
     Channel Change Count......................... 21
     Last Channel Change Time..................... Tue Sep 19 14:52:55 2019
     Recommended Best Channel..................... 128
   RF Parameter Recommendations
     Power Level.................................. 1
     RTS/CTS Threshold............................ 2347
     Fragmentation Threshold...................... 2346
     Antenna Pattern.............................. 0

   Persistent Interference Devices
   Class Type                 Channel  DC (%%)  RSSI (dBm)  Last Update Time
   -------------------------  -------  ------  ----------  ------------------------
   All third party trademarks are the property of their respective owners.
  • 表示が冗長です、egrep 相当の機能は提供されていないため判読性に難があります
  • RF の主要なカウンタは確認出来ますが、Radio に関する各種ステータスは確認出来ません

3. 取得した全 AP の情報をマージおよび整形

この作業を手動で行った場合、慣れていても 5 分 - 10 分程度の時間を要してしまいます。

このようなステップが以下のようなワンライナーで処理出来るようになっています。

 $ wlap show overview --hostname AP1 -i 11a
 This process takes about 4 seconds. Please wait...

   +----------+-------------------+------------+---------------+----------------+-------------+--------------------+--------------+-------------+
   | Hostname | MAC               | OperStatus | ChannelNumber | TxPower        | ClientCount | ChannelUtilization | APGroupName  | Controller  |
   +----------+-------------------+------------+---------------+----------------+-------------+--------------------+--------------+-------------+
   | AP1      | 6c:9c:ed:eb:e0:a0 | UP         | (136,132)*    | *1/7 (17 dBm)  | 31 clients  | [#####     ] 53 %  | Group6       | WLC1        |
   | AP2      | 24:b6:57:35:22:70 | UP         | 124*          | *2/7 (14 dBm)  | 1 clients   | [          ] 9 %   | Group3       | WLC2        |
   | AP3      | 24:b6:57:5b:6f:70 | UP         | (136,132)*    | *1/7 (17 dBm)  | 39 clients  | [######    ] 63 %  | Group4       | WLC1        |
   | AP4      | 24:b6:57:35:0d:90 | UP         | (36,40)*      | *2/7 (14 dBm)  | 13 clients  | [#         ] 16 %  | Group2       | WLC2        |
   +----------+-------------------+------------+---------------+----------------+-------------+--------------------+--------------+-------------+

WLC の存在を意識していないことはもちろん、利用頻度の高いメトリクスに表示を限定した上でテーブル形式とすることで判読性を高め、かつ文字整形の手間も完全に省いた形です。本来数分かかる作業が数十秒で完了することは非常に効率的です。

img04_2.png 図4: メトリクス (Channel Utilization) データが集約
(2) 操作性の向上

単一 AP の設定変更操作を行う場合、Act - Act 構成の環境では最初にログインする WLC を選択する必要があります。しかし、運用で生じる 100 台以上の AP の帰属先変更に、人間の脳で追従することは非常に困難です。そしてこの結果、どうしても「AP1 の設定変更のため WLC1 にログインしたが、実際の帰属先は WLC2 だった」という時間のロスが発生してしまいます。

加えて対象の WLC にログインした後も、複数のコマンドを実行して初めて目的の設定変更を完了出来る場合があります。例えば、従来の CT シリーズでは、特定 AP の Channel を変更するために以下の 3 コマンドを実行する必要がありました。

 (Cisco Controller) > config 802.11a disable AP1
 (Cisco Controller) > config 802.11a channel ap AP1 48
 (Cisco Controller) > config 802.11a enable AP1

補足:Catalyst 9800 では syntax が改善され 1AP あたりワンラインで完結出来るようになっています。

この書式では Channel 番号が二行目にあたるため、100 台以上の AP に対する流し込みコマンドを作成すると設定の見通しが非常に悪くなります。また、事前の設定状態を確認するには更に別のコマンドも必要です。

このようなステップが以下のようなワンライナーで処理出来るようになっています。

 $ wlap set channel --hostname AP1 -i 11a --channel 48 --width 20
 AP1 found on WLC1.

 Current : Global (36,+1ch)
 New     : 48


 ****** CAUTION: AP will STOP PROPAGATION ******

  - Associating devices will be disassociate.

 Are you really sure? (y/n)y
 Applying...

先程と同様 WLC の存在を意識せず、事前・事後の差分と影響範囲を正しく認識した上で変更作業が実行出来る形です。対話式で影響範囲を明示しているのは「コマンド 1 つであっても必ず処理内容を確認し、影響範囲を理解した上で実行する」という我々 IT 基盤の運用文化が背景にあります。AP の設定変更は局所的な瞬断を伴うケースが非常に多いため、これにより改めてリスクに対する警戒を促しています。

(3) 自動化のサポート

無線 LAN コントローラに限らず、元来ネットワーク機器には以下のような特徴があります。

  • スイッチやルータにカテゴライズされる機器のメモリは数百 MB ~ 数 GB 程度
  • niceionice のようにプロセスの優先度を制御するコマンドが存在しない
  • 通信において中間に位置する機器であるため、有事の際の影響範囲が非常に広い

これらの仕様から、ネットワーク機器における無闇なメモリの使用は控えたほうが良い、というのが通説です。対して、サーバサイドで実行速度を制御出来る CLI を使うことで、ここにある程度の融通が利かせられるようになります。

補足:この通説には近い将来動きがあると予測しています。これはコンテナ技術の普及によって、ユーザに提供するメモリを厳格に制限出来るようになったことが背景です。

加えて、サーバ起点でオペレーションが行えるということは、他サーバとの連携も可能であるということを意味します。実際に我々は監視サーバと連携して一定数のオペレーションを自動化しています、後述でその一部を紹介します。

img05.png 図5: 監視と連動して設定変更を行うモデル

2. 処理フロー

CLI の処理フローは至って単純です。以下の 3 ステップで完結しています。

  1. AP の帰属する WLC を特定
  2. その WLC に対して所定の CLI のコマンドを発行 (TTY)
  3. コマンドの実行結果をパースして必要な情報を表示

1 つだけ、Act - Act 構成の運用に大事な事前準備を要するのでまずはこちらを紹介します。

事前準備

Act - Act 構成の環境では AP の帰属先 WLC が運用によって変動します。これに順応するため、前もって WLC の SNMP Agent が公開する情報から AP のリストを生成しています。

この処理は以下のワンライナーで実現しています。

 $ wlap init wlcapmap -C <SNMP Community Name>

情報収集の対象となる WLC は予め YAML で定義しています。

 ---
 production:
   controllers:
     - WLC1
     - WLC2

SNMP Agent のアクセス先は AIRESPACE-WIRELESS-MIB に含まれる OID: 1.3.6.1.4.1.14179.2.2.1.1.3 (bsnAPName) です。

サンプルの値を snmpwalk で取得してみます。バージョン、コミュニティ名等の引数は $SNMP_OPTIONS でまとめて渡しています。

 $ snmpwalk $SNMP_OPTIONS WLC1 1.3.6.1.4.1.14179.2.2.1.1.3
 SNMPv2-SMI::enterprises.14179.2.2.1.1.3.0.167.66.226.0.32 = STRING: "AP1"
 SNMPv2-SMI::enterprises.14179.2.2.1.1.3.92.90.199.97.218.128 = STRING: "AP3"

 $ snmpwalk $SNMP_OPTIONS WLC2 1.3.6.1.4.1.14179.2.2.1.1.3
 SNMPv2-SMI::enterprises.14179.2.2.1.1.3.92.90.199.75.186.160 = STRING: "AP2"
 SNMPv2-SMI::enterprises.14179.2.2.1.1.3.92.90.199.129.183.224 = STRING: "AP4"

<AP MAC を 10 進数に変換した値> (以下、AP OID) とともに、value として AP のホスト名が取得出来ました。 AIRESPACE-WIRELESS-MIB は、このように <OID>.<AP OID> の配下で値を持つことが特徴です。

ここで取得した AP OID とそのホスト名および帰属先コントローラ情報を、以下のような YAML として保存しています。

 ---
 - host: WLC1
   name: AP1
   apoid: 0.167.66.226.0.32
 - host: WLC1
   name: AP3
   apoid: 92.90.199.97.218.128
 - host: WLC2
   name: AP2
   apoid: 92.90.199.149.23.64
 <snip>

このマップファイルをオペレーションの起点に照会することで、帰属先 WLC を意識しない AP 運用が可能になっています。

続いて、CLI 実行時の処理を見ていきます。

1. AP の帰属する WLC を特定

実際にオペレーションを行う CLI の基本書式は以下のようになっています。

 $ wlap <動詞 (init|show|set|exec)> <目的語 (channel|txpower|overview|...)> --hostname <AP ホスト名>

何かしらのコマンドが実行されると、まずは --hostname を元に先のマップで帰属先 WLC を逆引きします。

2. WLC に対して所定のコマンドを発行

次に、逆引きで特定した帰属先 WLC に対して TTY 経経由で所定のコマンドを実行し、その結果を取得します。

現在稼働している多くのネットワーク機器は、未だ十分なプログラマブルインタフェースを持ちません。このため、情報の取得には TTY + expect を採用しています。例えば、先に紹介した show advanced 802.11a summary の取得は以下のような関数で処理しています。

 def show_adv_a_sum(controller, username, password)
   commands = [
     { read: 'Password:',               input: password },
     { read: '\(Cisco Controller\) \>', input: 'config paging disable' },
     { read: '\(Cisco Controller\) \>', input: 'show advanced 802.11a summary' }
   ]
   { management: "ssh #{username}@#{controller}", operation: commands }
 end

この実装には、以下のようなメリットも内包しています。

  • Infrastructure as Code

    ChefAnsible 等と同じく、定義がそのまま操作手順になります。これにより一部の手順書作成は不要になります。

  • 学習コストの低減

    CLI のコマンドだけ覚えておけば OS 別にコマンドを学習する必要が無くなります。これは他社製品への乗り換えはもちろん、Cisco 製品における AireOS から IOS-XE への乗り換えでも効果を発揮しています。

3. コマンドの結果をパースして必要な情報を表示

最後に、取得した結果から必要な情報を抽出、フォーマットを調整しつつ標準出力して処理完了です。

show 系コマンドの処理は以上となります。setexec 系コマンドの場合は、再度 (2) / (3) を繰り返して変更/実行までを実施しています。

3. 自動化への応用

先に紹介している set channel は対話式でしたが、この set 系コマンドにはそれをスキップする --quiet オプションを実装しています。そして、これを監視と連携させることで障害からの復旧をある程度自動化しています。

監視に関する詳細は説明を省きますが、例えば以下のようなケースがこの対象となっています。

1. レーダーによる停波状態からの自動回復

ヒカリエ本社のある渋谷は、西から W53、南東から W56 のレーダーが多く飛来する RF 環境です。AP はこのレーダーを受信すると法規的な仕様に基づき無線の電波を停波し、利用可能な Channel が無ければ最短 30 分間はそのままの状態となります。

img06.png 図6: レーダーによって電波が停波

これに対する一般的な対策には以下のようなものが挙げられますが、いずれも一長一短です。

  • カバレッジにローミング用の W52 AP を混ぜ込む手法

    レーダー検知時にある程度のカバレッジロスを許容することになります。レーダーの受信頻度が低い、または安定したスループットが不要な RF 環境では最適解と考えています。

  • RF Profile の Channel List に W52 Channel を混ぜ込む手法

    DCA 任せになるので、レーダーを受信していない状況下でも混雑の激しい W52 Channel を選定する場合があります。W52 が比較的クリーンな RF 環境では有効な手法と考えています。

DeNA では、通信品質の観点からこれらを採用することが困難でした。このため、別途 Radio ダウン時、周囲の AP と干渉しない W52 Channel に固定化する仮復旧処理W53/W56 の Blacklisting 開放後、Channel の固定化を解除する切り戻し処理 を自動で実行しています。

img07.png 図7: レーダーによって停波した AP #2 の電波伝搬を再開

Hook のトリガーとしている監視は、切り替え時が OID: 1.3.6.1.4.1.14179.2.2.2.1.12 (bsnAPIfOperStatus)、 切り戻り時は OID: 1.3.6.1.4.1.14179.2.2.24.1.1 (bsnAPIfRadarDetectedChannelNumber) が返す合計 Channel 数の閾値監視です。

2. クライアント超過状態からの自動回復

無線 LAN の CSMA/CA は半二重通信です。クライアントが増えれば増えるほど通信待ち時間、つまり遅延の発生する可能性が高くなります。

img08.png 図8: AP #2 のクライアントが超過

これを未然に防ぐため、クライアント接続数が一定数を超えた AP に対して、特定 ESSID に接続する端末を deauth し、再接続を促すことでクライアント数を平準化する処理 を自動で実行しています。

img09.png 図9: AP #2 のクライアントを分散

Hook のトリガーとしている監視は、OID: 1.3.6.1.4.1.14179.2.2.2.1.15 (bsnApIfNoOfUsers) の閾値監視です。

最後に

以上、ヒカリエ本社を例に Cisco WLC の Act - Act 構成運用手法と関連する自動化を紹介させて頂きました。

無線 LAN はまだまだ発展途上の技術です。2020 年に予定されている 802.11ax の標準化もさることながら、その後も更に変化が続いていくものと予想されています。そして、この需要増とともに品質に対する要求が増加することもまた必然です。我々の持つナレッジが、少しでもより良い無線 LAN 構築、より良い運用環境整備の参考になれば嬉しく思います。

最後までお読み頂きありがとうございました。

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る