アクセス制御を厳格に行っている環境からの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 構築、より良い運用環境整備の参考になれば嬉しく思います。

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

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

社内システムのクラウド移行

こんにちは、IT基盤部の田村です。
社内システムのインフラを担当しています。

我々が管理・運用しているシステムは、先月、エンジニアブログでジュンヤさんの記事にもあった通り、Windows、Linux、アプライアンスなど様々なOS、ミドルウェア、ハードウェアを使用していますので、クラウドへ移行するのも同様に様々なパターンがあります。そのため、オンプレミスと同じような構成で移行できるのか、はたまた、AWS上のサービスを利用出来るのか、模索しながら移行を進めています。

現在、社内システムは、本番環境と開発環境、合わせて300台ほどあります。これらを2019年度末までにクラウドへ移行する予定です。

migration_systems.png ※2019年9月現在の進捗状況

Windowsのシステムを先行して移行していますが、その中から、アプリケーション(WindowsServer2012R2)+コンソールPC(Windows7)のシステム構成をどのように移行したか書きたいと思います。

オンプレミスの構成と利用方法

本番セグメントのサーバーにログインするには、セキュリティー上、必ずゲートウェイサーバーにリモートデスクトップで接続し、そこから本番サーバーに接続するルールになっています。ゲートウェイサーバーでは、ユーザーが何をやったか後から追えるよう、証跡を取っています。
このアプリの担当者は、ゲートウェイを経由してコンソールPCに接続後、コンソールアプリを起動して業務を行います。 コンソールPCはWindows7なので、1台1人しかログインできません。 担当者は十数名いるので、利用時は声を掛け合って利用してます。

on-premises.png

まずはAWSにインスタンスを立ててみよう!

練習がてら、Windowsのインスタンスを立ててみます。
すると、いきなり問題発生!

Amazon Machine Image(AMI)にWindows7がない!
Windows10もない!!

これは困りました。
WindowsServer2012R2で立てるしかないのか。。。と諦めかけたとき、救世主登場!
Amazon WorkSpacesというセキュアなクラウドベースのデスクトップサービスがありました。

Amazon WorkSpacesを使ってみる!

これは使えるかも?ということで、WorkSpacesにインスタンスを立ててみます。

OSは、Windows7か10、またはAmazon Linux2から選べます。
Windows7のEOSは2020年1月14日なので、Windows10を選択します。

料金体系は、月額料金と時間料金のいずれかを選択できます。
今回構築するコンソールPCはそれほどスペックはいらないので、Windowsバンドルのバリューを選択することにします。

 OS         バンドル    月額料金    時間料金
 Windows    バリュー    34USD       10 USD/月 + 0.30 USD/時間

利用時間が月80時間を超えるようであれば月額料金がお得です。
ただ、時間料金だとアクティブではなくなってから指定された期間が経過した後に自動的に停止しますので、起動に時間がかかります。

15分ほどで構築が完了し、実際接続してみます。
自分のPC(MacBook Air)に接続アプリをインストールして直接繋ぐ???
なるほどー、こうやって使うのか!と感心してたのもつかの間、またもや問題発生しました!

  • WorkSpacesを作成したときのアカウントでしか接続出来ない。1つのWorkSpaceに対して最大20ユーザーまで登録が可能だが、ADと連携している場合、1アカウントあたり1つのWorkSpaceとなり、1アカウントで複数台に接続設定をすることが出来ない。
    つまり、担当部署全員を全てのWorkSpacesに権限を付与することが出来ません。
  • 証跡が取れないので、担当者が悪いことをしてもバレない
  • どこからでも接続出来る?

3つ目の「どこからでも接続出来る?」の問題は、WorkSpacesの管理画面にIPアクセスコントロールの設定がありましたので、オフィスのOutbound IPを設定すれば制限出来ました。 しかし、それ以外は仕様上解決出来そうにありません。

根本的に構成を見直し

接続ツールは諦め、IDCとAWSが専用線で接続されているので、IDC経由でコンソールPCに接続出来ないか検証します。
結論を先に述べさせていただくと、全ての問題を解決した理想通りの構成となります!

やりたかったことをおさらい

  • ゲートウェイ経由でアクセスし証跡を取る
  • 個人アカウントで全てのコンソールPCにログイン出来るようにする
  • 接続アプリ経由ではアクセスさせない
  • アクセス元制限をかける

事前に用意するもの

  • WorkSpacesを作成する際に必要なアカウントをActiveDirectoryのUserに必要台数分登録する。
  • AWS Direct ConnectまたはAWS VPNでIDCとクラウド間を接続する。
  • AD Connectorを設定し、ADからユーザー情報が引けるようにする。

構成図

aws.png

実際に構築していきます!

  1. Amazon WorkSpacesコンソールを開きます。
  2. WorkSpacesの起動をクリックします。
  3. 「ディレクトリの選択」
    作成済みのAD Connectorを選択します。
  4. 「ユーザーの特定」
    追加するユーザーは、事前に用意するものに書いてあるWorkSpaces作成用のアカウントです。
  5. 「バンドルの選択」
    使用したいバンドルを選択し、ボリュームサイズを指定するのですが、このユーザーは初期設定時しか使わないので、ユーザーボリュームは最小限(10GB)にしてください。ルートボリュームも後から増やせるので最小の80GBで設定します。
  6. 「WorkSpacesの設定」
    実行モード、暗号化、タグの管理は用途に合わせて設定します。
  7. 内容を確認してWorkSpacesを起動します。
  8. プロビジョンが完了するとログイン手順などが書かれたメールが届きますが、この情報は担当部署には共有しません。
  9. IPアドレスは固定にしたいので、Elastic IPを設定しておきます。
  10. このIPアドレスをDNSに登録しておくと、リモートデスクトップで接続する際便利です。
  11. WorkSpacesのIPアクセスコントロールの設定のところは、OfficeのOutboundIPを設定しておきますが、接続アプリでは接続させたくないので、リモートデスクトップで接続出来るようになったら削除します。

リモートデスクトップで接続

WorkSpacesのセキュリティグループの設定を行い、RDP接続が出来るようにします。

  1. Amazon WorkSpacesコンソールを開きます。
  2. 接続したいWorkSpaceの詳細を表示し、[WorkSpace IP] のIPアドレスをクリップボードにコピーします。
  3. Amazon EC2コンソールを開きます。
  4. ナビゲーションペインの [ネットワークインターフェイス] をクリックします。
  5. 検索ボックスに、先程のIPアドレスをペーストし対象を絞り込みます。
  6. 詳細の[セキュリティグループ]に表示されているリンクをクリックします。複数表示されたら設定したい方を名前をクリックします。
  7. [インバウンド] タブを選択して、[編集] をクリックします。
  8. [ルール追加]で下記を追加します。
    タイプ:RDP
    プロトコル:TCP
    ポート:3389
    ソース:今回はゲートウェイサーバーからのみアクセスさせたいので、そのIPアドレスを入力します。
    説明:allow rdp
  9. [保存]をクリックします。

※参考資料
AWS Knowledge center 「どうすれば、RDP を使用して WorkSpace に接続できるのでしようか?

Windows10の接続権限設定

Windowsに、WorkSpacesの接続ユーザー以外でもログイン出来るようにします。

  1. 接続アプリを使用して、WorkSpacesに接続します。
  2. コンピュータの管理 - ローカルユーザーとグループを開きます。
  3. グループ内のAdministratorsにアクセスさせたいユーザーが属するグループを設定します。

これで設定完了です。
担当部署全員が、ゲートウェイサーバーを経由して、使いたいコンソールPCにログイン出来るようになりました。証跡もバッチリ取られています。

特記事項

  • DドライブにはUserProfileに割り当てられています。この領域はWorkSpaces作成時「ユーザーの特定」で設定したユーザーのみしか使えないため、今回は利用しません。ユーザーボリュームを最小限で作成したのはそういった理由です。
  • 「ユーザーの特定」で登録していないユーザーでログインすると、C:\Users以下にプロファイルが作成されます。(通常のWindowsと同じ)
  • エクスプローラを開いたとき、Cドライブは見えないため、窓にC:\と入力して開く必要があります。
  • ルートディレクトリは定期バックアップ対象ではありませんので、基本的にローカルにデータは置かないほうがいいです。

最後に

Windowsのアプリケーション(WindowsServer2012R2)+コンソールPC(Windows10)のシステムをAWSに立てるというのは、極稀れかも知れませんが、社内ではこの構成が2種類ありますので、きっと需要はあるはずです。そのような方に参考になれば幸いです。

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

コンピュータビジョンの最新論文調査 Single Image Super-Resolution 前編

コンピュータビジョンの最新論文調査 Single Image Super-Resolution 前編

はじめに

こんにちは、AIシステム部でコンピュータビジョンの研究開発をしている中村です。 我々のチームでは、常に最新のコンピュータビジョンに関する論文調査を行い、部内で共有・議論しています。今回はSingle Image Super-Resolutionの前編として中村遵介が調査を行いました。

Single Image Super-Resolutionとは、一枚の画像を入力として受け取り、対応する高画質の画像を推定するもので、日本語では単一画像超解像として知られています。

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

目次

論文調査のスコープ

コンピュータビジョンの最新論文調査 Single Image Super-Resolution 編は前編と後編からなり、全体としては、Convolutional Neural Network(CNN)が初めてSingle Image Super-Resolution(SISR)に用いられたSRCNNを皮切りに、CVPR2019で発表された論文までで重要と思われるものをピックアップして調査を行っております。

今回の前編では、「スケールやパラメータを含め縮小方法が既知の画像から、なるべく元の画像に近づくよう高画質な画像を推定する」というタスクに取り組んだ論文を紹介します。
後編では、「縮小方法が完全に未知、もしくは一部未知の画像から、なるべく元の画像に近づくよう高画質な画像を推定する」というものや「元画像にとても近いとは言えなくとも見た目が綺麗になるよう推定する」というタスクに取り組んだ論文を主に紹介する予定です。

前提知識

Single Image Super-Resolution

Single Image Super-Resolution(SISR)は、日本語では単一画像超解像として知られ、一枚の画像を入力として受け取り、対応する高画質の画像を推定するタスクです。

SISRのイメージ図(蝶の画像はSet5データセットより引用)

ある低画質画像と対応する高画質画像は複数存在するため、このタスクは解が定まらない不良設定問題として知られています。下の画像は後編で紹介するPhoto-Realistic Single Image Super-Resolution Using a Generative Adversarial Networkより引用したものですが、一つの低画質画像に対応する高画質画像が複数あることを示しています。

不良設定問題の例不良設定問題の例

そのような中、大量のデータから拡大方法を学習するCNNモデルは、この5年ほどで大きな注目を集めています。大量の低画質画像-高画質画像のペアデータから拡大方法を学習することで、未知の画像であってもかなり綺麗に拡大することが可能になってきました。以下の図は一般的にSISRをCNNで解く際の訓練と推論のイメージ図です。訓練時は高画質画像を縮小して入力し、元の画像を復元するように学習します。前編で紹介する論文は、アンチエイリアスをかけた高画質画像をBicubic法によって1/2, 1/3, 1/4 もしくは 1/8に縮小したものを用いています。

SISRのCNN適用方法(画像はSet14データセットから引用)

評価方法

今回紹介する手法においては、正解画像と推定画像の「近さ」はPeak Signal-to-Noise Ratio(PSNR)とStructure Similarity Index(SSIM)で評価しています。PSNRは画像の二乗誤差に対数を用いた評価指標で、高ければ高いほどモデルの精度が良いことを示しています。しかしPSNRはあくまで二乗誤差なので、ノイズのようなものをうまく指標に反映できないという欠点があります。そこで、PNSR以外の指標として、注目領域の画素の平均や標準偏差と言った統計情報を使用したSSIMも重要となっています。SSIMは0-1の範囲の指標で、これも高ければ高いほど精度が良いことを示しています。

ただし、どちらも「値は高いが見た目としてはあまりよくない」という結果を生む可能性もあり、絶対的に信頼できる指標ではありません。現状では既存手法との比較のしやすさや他により良い選択肢がないということもあり、これらの指標が採用されています。

SISRの評価指標

関連データセット

学習用

  • ImageNet: 1000万枚を超える超巨大データセットです。実際に学習する際は35万枚程度をサンプリングして使用します。画像サイズはまちまちですが、400x400程度のものが多いです。超解像の学習では192x192などにクロップされるため、おおよそ1枚の画像から4つほど完全に異なるデータを取得できます。
  • DIV2K: CVPR、ECCVのコンペで使用されるデータセット。800枚と枚数は少ないですが、非常に品質が高いことで知られています。また画像サイズも大きく、2040x1300-1500程度の画像により構成されています。おおよそ1枚の画像から60-70枚ほど完全に異なるデータを取得できます。

評価用

  • Set5: 5枚のデータセット。CNNモデル登場以前から頻繁に用いられていました。人の顔や蝶、鳥のような自然画像が入っています。
  • Set14: 14枚のデータセット。一部、Set5と被る画像もあります。白黒画像やイラスト調の画像が増えました。
  • BSD: 100枚、200枚など使用する枚数は異なりますが近年は100枚を使用するケースがほとんどです。動物や人物、飛行機のようなものから景色の画像まで、幅広い自然画像が入っています。
  • Urban100: 建物の画像を主に集めたデータセットです。画像内の自己相関性が高い事で知られています。
  • Manga109: 漫画のデータセットですが、主に表紙のカラー画像を評価対象に用いられます。

あるSISRモデルを複数の画像に対してそれぞれ適用した際のPSNRは一般的にばらつきがちです。そのため、数枚の画像で評価をすることが難しく、ほとんどの論文では複数の評価データセットについてそれぞれの平均PSNRを記載して既存手法との相対評価を行います。

論文紹介

SISRは辞書ベースのアプローチが行われていましたが、最近ではCNNを利用したアプローチが盛んになっています。まずはCNNモデルのベースとなった辞書ベースの手法についてその手法を大まかに説明します。

辞書ベース超解像

辞書ベースの手法の大まかな流れは以下のようになっています。

  1. 事前に高画質画像の一部領域を切り出したパッチと、それを縮小した低画質パッチを大量に用意します。
  2. 大量の低画質パッチ群をある基底行列(辞書)とそれぞれのスパースベクトルの積で近似表現します。これは、低画質パッチを、代表的な特徴群の中のいくつかの和で表現することで、より少ない情報で画像を表現しようとしています。
  3. 低画質パッチを変換したベクトルと、高画質パッチの対応表を作成します。
  4. 超解像の対象となる入力された低画質画像から小領域を切り出します
  5. 切り出した小領域を 2. の方法でベクトル表現します。
  6. 6. の対応表の中から最も近いベクトルを探し出し、対応する高画質パッチを、小領域に対応する高画質画像として使用します。
  7. 4-6.を繰り返して高画質画像を生成します

2.において特徴表現を工夫したり6.の最近傍探索においてアルゴリズムを工夫することで、高速な超解像や正確な超解像を行なっていくもの(A+: Adjusted Anchored Neighborhood Regression for Fast Super-Resolution)や、事前に用意する画像群を外部データを利用せず、入力された画像だけから作成する手法などが存在します。最近だとCVPR2015で画像の自己相関を利用したSelfExSR: "Single Image Super-Resolution from Transformed Self-Exemplars"が発表されていたのが記憶に新しいです。

SRCNN: "Image Super-Resolution Using Deep Convolutional Networks"(TPAMI2015)

目的

従来の超解像のうち、辞書ベースに基づいた手法をCNNに置き換えることで高精度化を図りました。

要約

辞書ベースの手法が行なっていた操作を、CNNに置き換えた論文です。初めてSISRにCNNを用いましたが、既に従来手法を大きく上回る精度を達成しました。

提案内容

全体は3層のCNN構造になっています。

  • 1層目が 9x9 の畳み込みで、「小領域を切り出す」という操作に該当
  • 2層目が 1x1 の畳み込みで、「小領域を特徴ベクトルに埋め込む」という操作に該当
  • 3層目が 5x5 の畳み込みで、「特徴ベクトルから対応する高画質画像を検索する」という操作に該当

損失は、生成結果と正解画像の平均二乗誤差です。CNN内部では拡大を行わず、Bicubic 法で事前に拡大処理したものをCNNで refine するという手法をとっています

SRCNNのアーキテクチャ図

結果

4x4倍に拡大した画像と実際の高画質画像から計算されたPSNRの各データセットにおける平均値です。

4x4 PSNR Bicubic A+ SRCNN
Set5 28.42 30.28 30.49
Set14 26.00 27.32 27.50
BSD300 25.96 - 26.90

A+はCNN手法ではなく、辞書ベースのものですが当時の最高手法の1つです。SRCNNがPSNRにおいて高い精度を達成したことを示しています。

以下は論文から引用した3x3倍超解像の結果です。既存手法に比べて鮮明な結果となっています。

SRCNNの結果

問題点

SRCNNはCNNのSISRへの適用ということで注目を浴びた論文でしたが、以下の2つの問題を抱えていました。

  • Bicubic法で事前に拡大された画像を処理するため計算コストが大きい
  • 3層で構成されており、表現能力が乏しい

そこで、この2つに取り組んだ論文をそれぞれ紹介します。まずは1つ目の計算コストが大きい問題に取り組んだ論文を2つ紹介します。

ESPCN: "Real-Time Image and Video Super-Resolution Using an Efficient Sub-Pixel Convolution Neural"(CVPR2016)

目的

SRCNNではBicubic法で拡大した画像をCNNで処理していたため計算コストが大きい問題がありました。この論文はその計算コストの縮小を図ったものです。

要約

実際の拡大をCNN入力前のBicubic法で行うのではなく、CNNの最終部分でsub-pixel convolutionを導入することで実現しています。これにより、CNN内部のほぼ全てのレイヤで小さなサイズの画像のまま計算を行うことを可能にしました。SRCNNのおよそ4-5倍の速度を出しています。

提案内容

SRCNNで前処理として行なっていたBicubic法を除外し、最終層の9x9の畳み込みをsub-pixel convolutionに置き換えることで最終層で拡大を行います。

sub-pixel convolutionは、width, height方向への拡大を行うのではなく、channel方向にr^2倍の拡大を行います。その後、reshapeとtransposeによってテンソルを変形させ、width, height方向にそれぞれr倍した結果を出力します。

ESPCNのアーキテクチャ図

結果

4x4倍に拡大した画像と実際の高画質画像から計算されたPSNRの各データセットにおける平均値です。

x4 PSNR Bicubic SRCNN ESPCN
Set5 28.42 30.49 30.90
Set14 26.00 27.50 27.73
BSD300 25.96 26.90 27.06

以下は論文から引用した3x3倍超解像の結果です。

ESPCNの結果

FSRCNN: "Accelerating the Super-Resolution Convolutional Neural Network"(ECCV2016)

目的

SRCNNではBicubic法で拡大した画像をCNNで処理していたため計算コストが大きい問題がありました。この論文はその計算コストの縮小を図ったものです。

要約

SRCNNを提案したチームが、さらに高速化を行ったFast-SRCNN(FSRCNN)です。ESPCNはsub-pixel convolutionを採用していましたが、FSRCNNはtransposed convolutionを採用しています。どちらも表現能力は変わりません。元のSRCNNのおよそ10倍の速度を出しています。

結果

4x4倍に拡大した画像と実際の高画質画像から計算されたPSNRの各データセットにおける平均値です。

x4 PSNR Bicubic SRCNN FSRCNN
Set5 28.42 30.49 30.71
Set14 26.00 27.50 27.59
BSD200 25.97 26.73 26.98

以下は論文から引用した3x3倍超解像の結果です。

FSRCNNのアーキテクチャ図

以上のように、この後はCNNの最終層近くでtransposed convolutionか、sub-pixel convolutionで拡大を行うようになっていきます。

これにより、SRCNNの2つの問題点である、

  • Bicubic法で事前に拡大された画像を処理するため計算コストが大きい
  • 3層で構成されており、表現能力が乏しい

の一つ目が解決されていきます。

二つ目の

  • 3層で構成されており、表現能力が乏しい

に取り組んだ初期の重要な論文が以下の2つです。単純に層を増加させても学習が不安定になってしまうところを、Residual Learningという手法で防いでいます。

VDSR: "Accurate Image Super-Resolution Using Very Deep Convolutional Networks"(CVPR2016)

目的

SRCNNは3層で構成されており、表現能力が乏しい問題がありました。この論文は多層化させることで不安定になる学習を安定化させることを目指したものです。

要約

Bicubic法で拡大した画像からの差分だけをCNNに学習させるResidual Learningを提案し、深い層のモデルを用いても学習を安定化させた論文です。差分のみを学習できるようにglobal skip connectionを用いています。

提案内容

CNN自体は3x3の畳み込み層を20枚積んだモデルを提案しています。入力はBicubic法で拡大された画像ですが、モデルの出力にこの拡大された画像を足し合わせて最終出力とすることで、結果的にモデルが「正解画像とBicubic法による拡大画像との差分」のみを学習するように制限をかけています。

Bicubic法は単純なフィルタ処理ですが、それでもある程度補間は行えるため、残った僅かな差分だけを学習させることで、学習を容易にしています。この頃は20層のモデルでもvery deepという名前がついたことに少し感慨を覚えます。

VDSRのアーキテクチャ図

結果

x4 PSNR / SSIM Bicubic SRCNN VDSR
Set5 28.42 / 0.810 30.49 / 0.863 31.35 / 0.884
Set14 26.00 / 0.702 27.50 / 0.751 28.01 / 0.767
BSD100 24.65 / 0.673 25.60 / 0.718 27.29 / 0.725
Urban100 23.14 / 0.658 24.52 / 0.722 25.18 / 0.752

以下は論文から引用した3x3倍超解像の結果です。

VDSRの結果

DRCN: "Deeply-Recursive Convolutional Network for Image Super-Resolution"(CVPR2016, Oral)

目的

SRCNNは3層で構成されており、表現能力が乏しい問題がありました。この論文は多層化させることで不安定になる学習を安定化させることと同時に、多層化によるパラメータ増加を抑えることを図ったものです。

要約

VDSRと同じ著者が同じ会議に提出した論文で、こちらは口頭発表になっています。
基本的にはVDSRと同じくResidual Learningを導入していますが、さらに中間層を再帰構造にさせることでパラメータ数の増加を防いでいます。

提案内容

Residual Learningを導入して Bicubic法と正解画像との差分のみを学習しますが、さらに中間層を再帰構造にしています。最大16回再帰させることで、16枚の超解像画像を生成し、最後にそれらをアンサンブルすることで最終出力を得ています。単純な加算平均ですが、PSNRのように二乗誤差を元にするような指標では、こういった加算平均は大きなズレを抑制し、精度が上昇することが知られています。

DRCNのアーキテクチャ図

結果

x4 PSNR / SSIM Bicubic SRCNN DRCN
Set5 28.42 / 0.810 30.49 / 0.863 31.53 / 0.885
Set14 26.00 / 0.702 27.50 / 0.751 28.02 / 0.767
BSD100 24.65 / 0.673 25.60 / 0.718 27.23 / 0.723
Urban100 23.14 / 0.658 24.52 / 0.722 25.14 / 0.751

以下は論文から引用した4x4倍超解像の結果です。

DRCNの結果

以上が SRCNNの3層問題を解決した2つの論文でした。

ここまでで、

  • 計算効率をあげるために最終層付近で畳み込みベースの拡大を行う
  • 層を増やしたほうが精度が上がる。安定化のためにはskip connectionを用いたResidual Learningが良さそう

という 2点が明らかになりました。その結果、これ以降のデファクト・スタンダードとなるSRResNetが誕生することになりました。

SRResNet: "Photo-Realistic Single Image Super-Resolution using Generative Adversarial Network"(CVPR2017, Oral)

Using GAN と入っていることから明らかなようにこの論文ではGANを使用したモデル、SRGANを主軸に提案しています。それに加えて、Generatorとして一緒に提案されているSRResNetが当時のPSNR / SSIMを大きく向上させた手法だったので、今回はSRResNetに注目した解説を行います。

目的

ESPCNFSRCNNを経てCNNの後段で拡大することや、VDSRDRCNによって多層化の知見が得られたため、それらを組み合わせることで高精度な超解像を行います。

要約

Global skip connectionではなく、ResNetのように、モジュール内にskip connectionを組み込んだlocal skip connectionを使用したモデルを提案。最終層付近でsub-pixel convolutionを用いた拡大を行い、その後にもう一度畳み込みを行うことでさらなる補正を行っています。

提案手法

Residual blockと呼ばれる、local skip connectionを導入したモジュールを積み重ねることで、40層近い大規模なネットワークを構築しつつ安定した学習を可能にしたモデルです。
最終層の手前でsub-pixel convolutionによって拡大を行い、最後に9x9の畳み込みで補正をかけたものを最終出力としています。
Residual Learningは導入していませんが、最初の層の直後とsub-pixel convolutionの手前までのskip connectionを導入し、global skip connectionに近い効果を狙っています。

SRResNetのアーキテクチャ図

結果

x4 PSNR / SSIM Bicubic SRCNN DRCN SRResNet
Set5 28.42 / 0.810 30.49 / 0.863 31.53 / 0.885 32.05 / 0.902
Set14 26.00 / 0.702 27.50 / 0.751 28.02 / 0.767 28.49 / 0.818
BSD100 24.65 / 0.673 25.60 / 0.718 27.23 / 0.723 27.58 / 0.762

以下は論文から引用した4x4倍超解像の結果です。SRGAN という記載のものについては後編で解説いたします。

SRResNetの結果

ここで再びブレイクスルーが発生しているのがわかるかと思います。
このあたりまで来ると、PSNRの上下変動に対して、生成結果の見た目の変動がパッと見では分からず、画像の一部を切り出したものを注視して比較する必要が出てきます。

一方で、層を増やした影響としてリアルタイム処理には不向きになっています。

EDSR: "Enhanced Deep Residual Networks for Single Image Super-Resolution"(CVPRW2017)

目的

SRResNetが大きく精度向上をさせられることがわかったため、更に発展させることを目指したものです。

要約

SRResNetから一部の無駄なモジュールを削除しつつ、モデル自体を深さ・広さ共に巨大化させることに成功しました。

提案手法

基本はSRResNetを踏襲しますが、SRResNetではモデル内の1つのモジュールが Conv + BN + ReLU + Conv + BN (+ skip connection) で構成されていたのに対し、Conv + ReLU + Conv (+ skip connection) のようにバッチ正規化を除外したモジュールを提案しています。論文内では、除外の理由はバッチ正規化は値の範囲を制限してしまう点で超解像に不向きであると主張されています。また、バッチ正規化を除外したことでGPUのメモリ消費量を40%近く抑えることができたとも主張しています。

また、SRResNetはモジュール数が16、それぞれの畳み込み層のチャンネル数が64だったのに対し、EDSRはモジュール数を32、チャンネル数を256に変更しています。モデルサイズはSRResNetのおよそ30倍にも及びます。モデルサイズを巨大化させて行く風潮を強く感じる論文です。

一方で、バッチ正規化を除外しモデルを巨大化させたため、中間特徴の値が次第に爆発してしまうことがわかりました。そこで、モジュールの最終部に0.1倍の定数スケーリング層を追加しています。これにより学習を安定化させることに成功しました。

EDSRのアーキテクチャ図

結果

x4 PSNR / SSIM Bicubic SRResNet EDSR
Set5 28.42 / 0.810 32.05 / 0.891 32.46 / 0.897
Set14 26.00 / 0.702 28.53 / 0.780 28.80 / 0.788
BSD100 24.65 / 0.673 27.57 / 0.735 27.71 / 0.742

以下は論文から引用した4x4倍超解像の結果です。+とついているのは後述するgeometric self-ensembleをおこなったもので見た目の変化はほとんどありませんがPSNRが上がるtest time augmentationです。

EDSRの結果

RCAN: "Image Super-Resolution Using Very Deep Residual Channel Attention Networks"(ECCV2018)

目的

ResNetベースのモデルが成功を収めたので、さらに広げてSENetをベースにすることでさらなる大規模化を図ったものです。

要約

さらにモデルを巨大化させます。といってもSRResNetを直接巨大化させるのはEDSRで達成されているので、この論文はresidual in residualモジュールとself-attentionを使用するアプローチを取っています。

結果として400層のネットワークを構成するのに成功しました。一方でforwardにかかる時間も増加しています。

提案手法

Local skip connectionを組み込んだブロックを複数繋げ、それらを一つのグループとみなし、それらを連結させることでモデルを構成しています。各グループにもlocal skip connectionが導入されているので、residual in residual構造と呼ばれています。

さらに各モジュールにはチャンネルベースのself-attention構造を取り入れています。論文内では畳み込みの受容野の小ささによるコンテキスト情報の欠損を防ぐために導入していると主張されています。

また、ablation studyも行われ、residual in residualが性能向上に大きく貢献していることがわかります。一方でattentionによる性能向上は僅かな値程度に留まり、パラメータ数の増加による性能向上との比較が難しいというのが個人的な見解です。

RCANのアーキテクチャ図

結果

x4 PSNR / SSIM Bicubic EDSR RCAN
Set5 28.42 / 0.810 32.46 / 0.897 32.63 / 0.900
Set14 26.00 / 0.702 28.80 / 0.788 28.87 / 0.789
BSD100 24.65 / 0.673 27.71 / 0.742 27.77 / 0.744

RCANの結果

ここまで結果の表の数字を真剣にご覧になっている方はお気づきかもしれませんが、精度の上がり幅がかなり小さくなってきています。

現時点で4x4倍の単一画像超解像はPSNRの精度において大幅な精度上昇は起きていません。
また、PSNRは1.0変化してようやく人の目にもそれがわかる程度なので、RCANの見栄えが劇的にEDSRに比べてよくなっているわけでもありません。

やはり毎年残っているごく僅かな精度向上を目指して数多くの論文が公開されているのですが、こういった現状を受けて最近は異なる問題設定のタイプの単一画像超解像が登場するようになりました。
次回のTech Blogでそういった論文を紹介していきます。

それでは今回の締めくくりとして、PSNRを高めることを目的とした超解像の訓練Tipsを載せておしまいにしたいと思います。

Tips: PSNRの向上を目的とした超解像モデルの訓練方法

訓練データセット

ImageNet, DIV2Kが使用されていますが、最近はDIV2Kのみが使用されることが多いです。もともと超解像のコンペ用に作成されただけあって、非常に質のいい画像が揃っています。

また、ImageNetで訓練する場合は、数十万枚を使用するケースが多いですが、DIV2Kは800枚の訓練画像でも十分な精度に至ります。そもそもImageNetでもそこまで枚数を必要としないのかもしれませんが、この枚数差は大きいです。

Augmentation

Augmentationにはcropとflipと90, 180, 270度のrotate が使用されます。
Cropのサイズはモデルによってまちまちですが、だいたいのケースでは入力 48x48 -> 出力 96x96, 144x144, 192x192のサイズ感が好まれています。もともとPSNRを高めるためならそこまで画像のコンテキストを厳密に考慮する必要がないので、このサイズ感で問題ないと考えられています。
そこからさらにflip、rotateによって最大8種類の画像を作成して訓練に使用します。

また、test time augmentationとして、flip, rotateで作成した8枚の入力画像をそれぞれ超解像し、その後で再びflipとrotateを適用して元の方向に戻してそれぞれの結果を加算平均する、という手法が存在します。8枚のどれかで一部間違った推論が行われたとしても、残りの7枚との平均計算によって誤差が小さくなり、PSNRが上昇することが期待されます。このtest time augmentationは、geometric enesembleとも呼ばれ、最近の手法でこれを導入していないものはほとんど見ません。
それくらい劇的にPSNRが上昇します(本ブログでの結果の表は全てtest time augmentationを行なっていない時の値です)。

大抵の超解像論文では「Ours, Ours+」のように + でgeometric ensembleの数値結果を表記するため、モデルの性能評価を行いたいときは geometric ensembleしているもの同士、していないもの同士で比較しなければならないことに十分注意してください。ほぼ間違いなく既存手法の精度を表記する際はgeometric ensembleしていない場合の値が表記されます。

損失関数

PSNRの向上を目的とする場合は現状、二乗誤差もしくは絶対誤差が使用されます。二乗誤差よりは絶対誤差の方が収束の速さから好まれる傾向にあります。ただし、現状のPSNR向上モデルの一つであるRCANは二乗誤差を採用しており、一概にどちらの方が精度が良い、という断言はできません(RCANの著者はGitHubのissueの中で、二乗誤差と絶対誤差の選択は大して精度に影響を与えないがより良い損失関数があるかもしれない、と記載しています)。

初期値

バッチ正規化を除外したままモデルを巨大化していくと特徴のスケールが発散する傾向にあるので、モデルの初期値はガウス分布ではなく、一様分布でスケールを調整したものを使用するのが良いです。

入力正規化

RGBの[0, 255]を単純な割り算で[0, 1], [-1, 1]に正規化する人もいれば、そのまま使用する人、データセットの平均RGBを引いて使用する人もいます。最近は訓練データの平均RGB値だけ引いて、特にスケールは変更しないまま使用するケースが多いです。

評価

PSNRの計算は式が単純なだけにさっと実装しておしまいにしてしまいがちですが、実はフレームワークによって算出される値が異なります。というのも、PSNRは輝度から計算されますが、RGBからYCrCbへの変換式が統一されていないからです。SelfExSRという画像の自己相関を利用した手法に関してGitHubで著者による実装が公開されていますが、その中でMATLABによる評価コードが書かれており、これを使用するか、独自で実装した場合は他のモデルの出力結果も自身のプログラムによって再計算するのが良いです。

参考レポジトリ

巨大化してきたモデルの構造を把握するのは実際にコードを見るのが早いという点でこれらの著者実装を眺めてみるのもいいと思います。ただし、どちらも訓練にはある程度のGPUを必要とします。

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

Kotlin Fest Reject Conference 2019を開催しました!

こんにちは、品質管理部の田熊です。

先日DeNAでKotlin Fest Reject Conference 2019を開催しましたので、イベントレポートをお届けしたいと思います。

Kotlin Fest Reject Conferenceとは?

2019/8/24にKotlin Fest 2019が開催されました。 Kotlin Festは「Kotlinを愛でる」をビジョンに、Kotlinに関する知見の共有とKotlinファンの交流の場を提供する技術カンファレンスです。 セッション・LTは公募制になっており、審査の後に採択・不採択が決定します。

Kotlin Fest Reject Conferenceは、このKotlin Festで不採択になってしまったセッション・LTを楽しむために企画されました。

  • 惜しくも不採択になってしまったけれど、Kotlinの知見の詰まったの発表を聞きたい!
  • 社内でも不採択になった方々がいるので、その発表の機会を作りたい!
  • Kotlin Festの熱が冷めやらぬうちにイベントを企画して、Kotlinコミュニティを盛り上げたい!

このような思いから、DeNAでKotlin Fest Reject Conferenceを開催することを決めました。

トーク紹介

ここでは、当日行われた各発表について紹介させていただきます。どの発表も大変ためになるものばかりでした。

EduToolsについて調べてみた

EduToolsという言語学習用のIntelliJ Pliginと、それを活用して独自学習コンテンツを作る方法の紹介をしていただきました。 EduToolsは使い方などまとまった情報があまりないので、貴重な情報の詰まった発表でした!

Gradle Task with Kotlin

KotlinでGradleのタスクを書いていくためのナレッジについての紹介でした。 最小構成のタスクからBuildSrcやタスクのClass化にも触れられており、step by stepで理解できてとてもわかりやすかったです!

サーバサイドKotlinでgRPCをやってみよう

Kotlin FestでGraphQLのセッションがあり、そのセッションのタイトルをインスパイアしたという前置きが面白かったです。 gRPC・Protocol Buffersの仕組みと、サーバーサイドKotlinに導入する手順が丁寧に説明されており、大変勉強になりました!

Kotlin DSL パターン

Library等でよく使われているKotlinのDSLをパターン化して紹介していました。 パターン化するという試みも面白いですし、それらの実装方法についても踏み込んでいて、是非自分でも実装してみたいと思いました!

inline Classを使おう

Kotlin 1.3から入ったInline classの使い所についての紹介でした。 Inline classを使ったコードがデコンパイルされるとどうなるかについて触れられており、Inline classについての理解が深まる内容でした!

JavaからKotlinにさらにKotlinらしく書き換えることでコードがリファクタされていった話

JavaからKotlin化するにあたって、簡単な置き換えでも効果があるというKotlin化に興味があるけれど踏み出せていない人の背中を押すような発表でした。 とくにKotlin化のサイクルの図が面白いので、是非実際にスライドを確認いただければと思います!

JavaからKotlinに書き換えてハマる話

こちらは前のトークとは少し趣旨が異なり、AndroidアプリをJavaからKotlin化するなかで直面する問題についてまとめてくださっています。 問題についての対処法もまとめられており、Kotlin化を進める際に参考すると勘所がわかってスムーズに進められるのでないかと思いました!

Immutable Collections Library for Kotlin

kotlinxライブラリの1つである、Immutable Collections Libraryについての紹介でした。 話を聞いていて今後標準的に使われるようになるのではないかと感じましたし、今後もLibraryのアップデートに注目したいと思うきっかけになる発表でした!

イベントの様子

Kotlin Festトートバッグ

日本Kotlinユーザグループ様のご厚意により、Kotlin Fest 2019のノベリティ入トートバッグを参加者の皆様に配布させていただきました! 100個ほどありましたが、全て完売...!知り合いに配ったところ好評だったとのお声もいただき何よりでございます。

bag.jpg


懇親会

Kotlinは音の響きからよく小鳥に例えられます。ということで、懇親会のお食事には焼き鳥をご用意しました。 焼き鳥は大変好評でして、すぐに完売...!

yakitori.jpg

終わりに

ご参加・ご協力いただいた皆様のおかげで、Kotlin Fest Reject Conference 2019は、盛況のうちに終えることができました。

DeNAでは、今後も技術コミュニティを盛り上げる活動を積極的にやっていきたいと思いますので、今後ともどうぞよろしくお願いします!

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

DeNA品質管理部 検証自動化の取り組み

DeNA品質管理部 リリースサポートグループ 古屋秀平です。
DeNA品質管理部では今期よりQA主体で検証自動化に取り組んでいます 。

DeNA品質管理部での自動化

リリースサポートグループ QA Evolution(QAE)チームが中心となり、
E2E(End to End)テスト領域における検証自動化を進めています。

複数の端末を連携させての自動実行

当社では様々なジャンルのアプリをリリースしているため、
自動化を進めていくには端末単体での自動化だけでなく、
複数の端末を連携させての自動化への対応も必要になります。
そこで、QAEチームでトライして意図した動きを実現できましたので、
動画に収録してみました。


当社がリリースしているMOVにおいて自動実行をさせた際の動画です。

  • 右側・・・MOVがインストールされた「ユーザー端末」
  • 中央・・・タクシー車内の後部座席に設置される「後部座席タブレット」
  • 左側・・・タクシー車内で乗務員の方が操作する「乗務員端末」

「配車依頼-迎車-乗車-支払」までのフローを自動実行しています。

0:01 ユーザー端末から「タクシーを呼ぶ」をタップし配車依頼リクエストを実行
0:10 乗務員端末で「OK」をタップし配車依頼リクエストを承認
0:18 乗務員端末で「現着」をタップ
0:26 乗車状態となり後部座席タブレットの「ご乗車ありがとうございます」などの
        表示を確認
0:30 支払状態となり乗務員端末で「OK」をタップ、後部座席タブレットの金額等を確認
0:36 乗務員端末で「決済する」をタップし決済を実行
0:45 ユーザー端末で「OK」をタップ
0:48 ユーザー端末で評価操作を実行
0:54 後部座席タブレットの「ご乗車ありがとうございました。」等のメッセージを確認

上記のようにマニュアル操作での検証と同様に各ステップでの
各端末における期待結果をスクリプト内でチェックしながら処理が進んでいます。

実現方法について

Airtest(https://github.com/AirtestProject/Airtest)で実現しています。
(画像認識ベースのUI自動化フレームワークです)

特徴的な点は同一スクリプト内でシーケンシャルに実行できていることです。
2台を連携させた実行事例はあるかもしれませんが、3台を連携させた実行例は
珍しいかと思います。

また、iOS端末・Android端末が混在する形での実行も可能で、動画内では

・ユーザー端末(iOS端末)
・後部座席タブレット(Android端末)
・乗務員端末(Android端末)

を組み合せて実行しています。

複数端末での自動実行を実現できることで、DeNAの他プロダクトでの展開も期待できます。

今後について

複数台実行も可能な技術確立はできましたが、定期実行環境の構築なども必要になりますので
引き続きトライしていきます。

最後に

今後も自動テストを活用してMOVをはじめとしたDeNA全プロダクトの
品質向上に貢献していきます。

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

Hadoop環境のクラウド移行

IT基盤部の nodoka です。

私の業務はWebサービスの運用が中心でしたが、数年前からhadoopを中心とした分散基盤環境のインフラも見るようになりました。 当初は巨大なhadoop環境の管理を体系化して引き継ぐことと、運用における属人性を排除することが喫緊の課題でした。 それが落ち着くと、ご多分に漏れずクラウド化を検討・推進するようになったので、その流れをまとめてみようと思います。

  1. DeNAのHadoop環境と改善策
  2. hadoopが抱える課題
  3. GCPへの移行
  4. embulk利用におけるTips

DeNAのHadoop環境と改善策

DeNAにおけるhadoop環境の歴史は古く、DeNAのほとんどのサービスが利用しています。 各サービスでは分析したいログやDBのスナップショットをhadoopのファイルシステムであるHDFSに一旦置きます。 そのHDFSに置かれたファイル群をhadoopを代表とする様々な分析ツールを使って解析します。 時代の流れとともに分析ツールは変化していきますが、データを集積するデータレイクの役割は一貫してhadoopが担ってきました。

hadoop_env.png

データレイクを構成する数100台のdatanodeサーバたちには、cassandraやelasticsearchなどの様々なコンポーネントが相乗りしていました。 よく言えばリソースをぎりぎりまで使い切る工夫と言えましたが、高負荷なコンポーネントが無関係なコンポーネントの障害を誘発してしまう悪環境でもありました。 また、膨大な数のディスクを抱えているにも関わらず、ディスク障害が即時の手動対応を必要とすることも大きな問題の1つでした。 この現状を踏まえて、以下の改善策を進めていきました。

  • ambariによる統合管理の導入
  • hadoopバージョンアップによる不具合の改善
  • 相乗りを解消して、コンポーネントごとのサーバ棲み分け

datanodeが大きなディスクI/Oを伴うので、まずはそれと相性の悪いコンポーネントを外出ししました。 それだけでも大部分の不可解な問題は起きなくなり、障害があったとしても速やかに切り分けできるようになりました。 また、バージョンアップによってディスク周りの不具合も減り、ディスク故障についても即時の対応はいらなくなりました。

さらに構造をシンプルにするため、古いデータのパージや圧縮を行って、リソースにばらつきの目立つ古いサーバたちを処分しました。 ambariによって視覚的な構成管理ができるようになったものの、可能な限り構成や設定を単純化してバリエーションを減らしました。 数種類程度のサーバ構成に抑えることで、慣れないエンジニアたちでも罠に陥らずに運用できる体制を築きました。

hadoopが抱える課題

ようやく落ち着いたところで今後のhadoop運用をどうするか思いを巡らすと、最も大きな課題として浮かび上がったのが、HDFSというファイルシステムの存在でした。

ご存知の通り、hadoopは分散処理フレームワークの中にHDFSという独自の分散ファイルシステムを内包しています。 このHDFSが良くも悪くもhadoopの特徴となっており、その構造を巨大化・複雑化している一因とも言えます。 分散処理とHDFSが一体化しているが故に、バージョンアップ時にも幾つかの問題を抱えてしまいます。

  • バージョンアップ時に長時間ファイルシステムが停止してしまう。
  • バージョンアップ時にダウングレードによる切り戻しを行うのが困難。
  • ファイルシステムが巨大過ぎるため、バックアップが事実上不可能。

バージョンアップによる効率改善を継続したかったのですが、上記理由でカジュアルにアップグレードという訳にはいきませんでした。 仮にHDFSが長期間使えない障害が起きた場合、その業務影響は計り知れないものになってしまいます。 また、独自性が高く分析処理以外で使うことのないファイルシステムを、積極的に運用したがるエンジニアがいないことも課題でした。

以上の理由で、分散処理としてのhadoopはともかく、HDFSの運用を続けることは難しいという判断を下しました。

GCPへの移行

hadoopの移行を検討した際に、選択肢に挙がったのはAWSやGCPといったクラウド環境でした。 hadoopのマネージドサービスを使えば、分散処理とファイルシステムを分離して運用することが可能になるからです。 一方で、並行して分析基盤チームの方でも次期分析ツールの選定を進めており、既に一部で利用していて実績もあるBigQueryへの全面移行が決定しました。

これに伴って、私の方でもBigQueryの利用を前提としたGCPへの移行を検討することにしました。 BigQueryは対象データを自身のストレージに取り込む必要があるのですが、データを展開した状態で保持するので、圧縮された素のデータファイルよりも格納効率が悪くなってしまう可能性があります。弊社の実データで比較してみたところ大きな差が出てしまったので、ペタレベルに膨張したデータレイクの移行先としては選択しづらい状況でした。そこで考えたのがクラウドストレージであるGCSをデータレイクとして併用することです。

直近のデータのみをBigQueryに持って、大部分の古いデータはGCSに置くことにしました。 弊社での利用実績はないものの、BigQueryはGCSのデータも分析対象にすることも出来ることになっています。 何らかの事情でそれが難しい場合は、一時的にhadoopクラスターを組むのもありだと考えました。 BigQuery一本化に比べれば構成的には複雑になってしまいますが、それでも利用頻度やコストを鑑みれば妥当な配置という判断になりました。

データレイクをGCSへ移行する場合、サービス系DBに対して行われていたETL処理も見直す必要がありました。 現在は巨大なhadoopクラスターを利用したSqoopによってDBのスナップショットを毎日取得しています。 しばらくはDBがオンプレに残ることを考えると、クラウドでSqoopを動かすのはリソース及び権限管理、どちらにおいても悩ましい状況でした。 そこで、単体でシンプルに動作し、インプット・アウトプットの選択肢も豊富なembulkへ移行することにしました。

embulk利用におけるTips

embulkでのMySQLからのデータ抽出は、非常に使い勝手がよかったです。 環境さえ整えてしまえば、YAMLファイルを準備するだけで簡単に対象を増やすことが出来ます。 また、抽出処理で問題になりがちなフェッチ数や並列度などもプロパティで制御可能です。 今はデータソースがMySQLだけですが、その気になれば様々なデータに手を広げられるという拡張性も魅力です。

それでも幾つか使い方に悩んだ点はあり、最後におまけとしてそれらを共有させて頂きます。

制御コード問題

まず、初めにつまづいたのは制御コードの問題でした。

旧仕様に合わせてtsvファイルを生成、BigQueryに bq load してみるとエラーで失敗となりました。 該当レコードを確認してみると、エスケープされていない制御コードが含まれていることに気付きました。 tsv以外のフォーマットであればどれもエスケープしてくれたので、利便性を優先してjsonに変更することにしました。 ファイルサイズは圧縮時で1.3倍になってしまったので、ストレージコストが問題になる場合は再検討するつもりです。

文字化け問題

次に問題になったのが、マルチバイトの文字化けでした。

長く続いているサービスはエンコーディングがSJISだったりするので、これにも悩まされました。 文字化けについては、JDBCオプションで characterEncoding を適切に指定すると解消しました。 MySQLのJDBCオプションは結構便利そうなものが少なくないので、一読しておいても損はなさそうです。

具体的には以下のような設定をembulkのliquid.yamlファイルに追加しました。

 options: {characterEncoding: Windows-31J}
タイムアウト問題

そして、最も苦しんだのがタイムアウト問題でした。

今回のembulk構成は embulk-input-mysql でデータを抽出し、 embulk-output-gcs でデータをアップロードします。 embulk-input-myql は一貫性のある読み出しを行うためにトランザクションを開始してからデータの抽出を行います。 その後に embulk-output-gcs のアップロードが始まるのですが、その完了を待ってからトランザクションを閉じます。

  1. トランザクション開始
  2. MySQLからデータ抽出
  3. GCSへデータアップロード
  4. コミット

従って、データ量が大きいとアップロード処理に時間を取られてしまい、トランザクションがタイムアウトするという事態に陥ります。 とはいえ、この時点で抽出もアップロードも終わっているので、処理的には何ら問題になりません。 ただ、embulkの終了ステータスが 1 を返してしまうため、エラーハンドリングが難しくなってしまいます。

たかがタイムアウト、何らかのパラメータを変更すればすぐ直ると思っていました。 ところが、MySQLで幾つかのtimeout値を大きくしても一向に改善しません。 途方に暮れて my.cnf を眺めていると、 wait-timeout が100秒に設定されていることを発見しました。 MySQLクライアントで確認したときには8時間になっている認識だったのです。

賢明な諸兄ならお気付きかもしれませんが、インタラクティブなMySQLクライアントの wait-timeoutinteractive-timeout で上書きされるんですよね。 つまり、インタラクティブでないembulkのタイムアウトは8時間でなく、100秒で動いていたと考えられます。 MySQLクライアントでtimeout値を確認する場合は、global オプションを付けておくことを強くお勧めします。

 show global variables like '%timeout';

wait-timeout は意図的に小さくしているようなので、embulkによるDB接続をインタラクティブ扱いすることで回避しようと思います。 今回もJDBCオプションで interactiveClient を設定することで、タイムアウトを interactive-timeout の値に変更することができました。 先ほどの characterEncoding に加えて、以下のような設定をembulkのliquid.yamlファイルに追加しました。

 options: {interactiveClient: true, characterEncoding: Windows-31J}

以上です。共に日々を戦う皆様の助けになれば幸いです。

備考

記事内に出てくるOSSをまとめておきます。

  • MySQL 5.1
  • Hadoop HDP 2.6.2
  • ambari 2.5.1
  • embulk 0.9.16
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

オンプレミスとGKEを併用したインフラについて

こんにちは、IT基盤部の宮崎です。
DeNAが提供するヘルスケア系サービスのインフラを担当しています。
今回は、クラウド移行とアーキテクチャ刷新に取り組んでいるプロジェクトがオンプレミスとGKEを併用する構成になりましたので、クラウド移行の過渡期にあたるシステムの紹介を通し構築過程で得た気づきをお伝えさせていただきます。詳細はドキュメントに頼る事が多く説明不足な所があると思いますが、何か得られるものを見つけていただければ幸いです。

概要

はじめに、アーキテクチャ刷新の目的とクラウドプラットフォーム選定の経緯を簡単に紹介します。
その後、システム概要図から、クラウド環境に焦点をあて分割していきます。
アプリケーションはGKE上で動作し、SharedVPCで払い出すネットワークを利用してオンプレと通信します。

アーキテクチャ刷新の目的

オンプレミスのシステムに以下の課題を持っていました。

  • 事業展開スピードに合わせて、プロダクト改善を進められるようにしたい
  • テストの所要時間が長い
  • デプロイにかかる時間が長い
  • コンポネントを容易に増やしたい
  • パフォーマンス面の懸念を動的に解決したい

それを解決するためにコンテナ技術を活用,マイクロサービスアーキテクチャを採用することに決定。

クラウドプラットフォーム選定の経緯

以下の要件や構想を元に、AWSGCPを候補に検討をはじめました。

  • アプリケーションレイヤーにKubernetesを利用する。
    • 懸念無し (ECS, EKS, GKE)
  • 外部連携のデータ受け渡しは専用線を利用する。

  • マネージドサービスを積極的に利用する。

    • CloudMemoryStoreがベータいつGAになるか不明
    • CloudSQLのメンテナンス時間 (CloudSQL Proxyの管理どうする)
    • 懸念なし (LB, RDB, Redis, Storage 等の利用予定のマネージドサービス)
  • BigQueryを分析で利用する。

どちらも機能は備えているが、クラウド上に我々の運用フロー(作業証跡・認証)を別途準備するのは変わらない
BigQuery利用する事が決まっているから、アカウント管理を考えるとGCPに統一した方が楽なのではないか?この事からGCPをメインで検証を進め、最終的にこのプロジェクトはGCPを利用する事に決めました。 2018年秋頃に検討したものなので、2019年9月現在は状況が変わっていると思います。

システム概要図

システムの構成要因は、以下の通りです。

  • システム環境
    • GKE環境
    • オンプレミス環境
  • 外部連携システム
    • ファイル授受
  • 外部サービス
    • 外部API連携
  • システム利用者
    • サービスユーザ
    • 社内メンバー(企画、CSメンバーなど)

これらの関係を図示すると以下のようになります。

onpre_gke_summary.png

オンプレミス環境には既存システムが存在しています。GKE環境からオンプレのSFTPサーバ・メールサーバを利用しています。オンプレ依存を少なくするため外部メールサービス利用を検討しましたが、完全移行まで費用を抑えたい事と海外事業者への第3者情報提供をしないなどの制約を満たすため、完全移行まではオンプレのメールサーバを利用する事にしました。

アプリケーションは全てGKE上で動作し、積極的にマネージドサービスを利用しています。
GKE環境を、クラウドサービスのコンポネントで置き換えると以下のような構成です。

k2_design.jpg

次に、オンプレとどのように接続しているかを説明するため、ネットワークとGCPプロジェクトについて紹介します。

ネットワークとGCPプロジェクト

GCPのネットワークリソースは、リージョン・プロジェクトを跨いで存在できるので、HostProjectで一括管理しServiceProjectにリソースを払い出す事にします。こうするとオンプレとGCP間のVPN接続を3環境(開発, ステージング, 本番)準備する必要があるところが1環境に集約出来てVPN接続を減らすことが出来ます。


VPN接続 一系統(2本)の費用 約[110 USD/月]

ネットワーク管理とログ管理の2つの視点から次の通りGCPプロジェクトを分割しています。

  • HostProject
    • ネットワークの一括管理、SharedVPCでServiceProjectへ払い出す、VPN接続・Firewallルール管理
  • ServiceProject
    • HostProjectから払い出されたネットワークを利用してGKEクラスタ上でアプリケーションを動かす
  • AuditProject
    • 監査ログを保存するプロジェクト

これらの関係を図示すると以下のようになります。ServiceProject, AuditProjectのみ環境毎に存在します。

NW_vpn_SharedVPC.jpg

SharedVPCとアドレス設計

SharedVPCでServiceProjectにネットワークを払い出すのですが、クラスタサイズを決めるためアドレス設計が必要になります。

Defaults and Limits for Range Sizes の通り、標準設定では大量のIP(Node:/20 + Pod:/14 + Service:/20)を必要とします 同様に潤沢に割り当てたいところですが、オンプレと通信するため他の環境と重複しないようにアドレス管理が必要になります。 オンプレとクラウドのネットワークの話の通りサービス数が多く、サービス規模に合わせたアドレス設計が必要です。

 "Considerations for Cluster Sizing"を参考にNodesを決めるとPodが決まります。
 ServiceのIPは削減できると思いますが、GKEクラスタ操作用のoperation networkも含め(/15)に収まるようにしています。

 ## 合計 (/15)
 -------------
 # GKEクラスタ
 Nodes   : /24
 Pod     : /16
 Service : /20

 # Operation
 bastion : /24

 クラスタを追加する場合には、Serviceネットワークのみ別途割り当てる。
 性能不足にはNodesのScaleUPで当面対応できると考えてました。

これらの関係を図示すると以下のようになります。

SharedVPC_GKE.jpg

GKEクラスタ

ネットワーク割り当てが完了しましたので、クラスタを構築したいと思います。
セキュリティを考慮し限定公開クラスタとし、マスターの制御元をoperation networkに限定するためマスター承認済みネットワークとします。

キーワードと、ドキュメントは以下を参考にしています。

  • 共有VPC内に限定公開クラスタを作成する
  • 限定公開クラスタ
    • VPCネイティブクラスタ
    • VPCネットワークピアリング
  • マスター承認済みネットワーク

  • VPC Network Peering

  • authorized networks

以上をまとめると、クラスタ作成するコマンドは次のようになります。

 cluster_name=FOO-BAR-platform-green
 network_project_id=dena-FOO-BAR-platform-nw-gcp  # HostProject  
 vpc_network=vpc-FOO-BAR-platform-1
 subnetwork=subnet-FOO-BAR-platform-1-ane1-node-172-17-100-0-24
 pod_range=subnet-FOO-BAR-platform-1-ane1-pod-172-16-0-0-16
 service_range=subnet-FOO-BAR-platform-1-ane1-service-172-17-0-0-20
 master_range=172.18.0.0/28
 authorized_network=172.17.200.0/24 # operation network
 num_node=6
 node_type=n1-standard-4

 gcloud beta container clusters create $cluster_name \
 --enable-autoupgrade \
 --enable-ip-alias \
 --enable-private-nodes \
 --enable-private-endpoint \
 --enable-master-authorized-networks \
 --no-enable-basic-auth \
 --no-issue-client-certificate \
 --master-authorized-networks $authorized_network \
 --network projects/$network_project_id/global/networks/$vpc_network \
 --subnetwork projects/$network_project_id/regions/asia-northeast1/subnetworks/$subnetwork \
 --cluster-secondary-range-name $pod_range \
 --services-secondary-range-name $service_range \
 --master-ipv4-cidr $master_range \
 --cluster-version=latest \
 --enable-stackdriver-kubernetes \
 --machine-type=$node_type \
 --num-nodes=$num_node \
 --tags=$cluster_name

最後にアプリケーションをデプロイし、セキュリティ構成を付加したサービスレベルの俯瞰図は次の通りになります。

service_security.jpg

最後に

今ではサービスを提供出来る状態になりましたが、ここに到るまでSharedVPC環境でクラスタが作成出来ないSharedVPC配下でGKE Ingressリソースが作成出来ないなど、構築過程でさまざまな問題がありました、エラーログを元に調査しても手がかりが無い場合もありサポートケースGCP Office Hourで相談しながら都度解決してきました。その情報は英語・日本語共にドキュメントを修正していただきましたが、日本語への反映には時間がかかる事に気づきました。

ドキュメントのリンク先を英語で書きましたが、これが今回お伝えしたい気づきです。

❗英語のドキュメントも読もう。❗

常識的な事かもしれませんが、日本語と英語のドキュメントの乖離はあり、一年以上に及ぶのもあります。

この文章を通して、オンプレとGKEを併用したインフラを紹介させていただきました。

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

音声の印象に基づくグラフィック生成: "fontgraphy" の裏側

はじめに

こんにちは、AIシステム部の高山、橘です。声からオリジナルグラフィックを生成する「fontgraphy(フォントグラフィー)」を9月13日に公開しました。fontgraphyは、デザイン×AIの取り組みであり、一般公開されています。ぜひスマートフォンのブラウザで体験してみてください。https://fontgraphy.dena.com
本記事ではfontgraphyを構成する技術をご紹介します。

result_screen.png

fontgraphyについて

fontgraphyは、声からオリジナルグラフィックを生成します。まず、声を入力すると、その声の印象を推論します。次に、フォントとイメージ画像を検索します。最後に、そのフォントに対してイメージ画像の画風を転写することでグラフィックを生成します。画風の転写にはスタイル変換という技術を用いています。

fontgraphy_arch.png

声の印象推定

印象語の選定

話者の声の特徴を直感的な言葉で制御できる音声合成技術 [1] を参考に、甘い、クール、落ち着いた、生き生きした、エレガント、渋い、ポリシーのある、優しい、の8つの印象語を選びました。

データセットの作成

印象語がつけられた公開されている音声データがないので、自前でデータを用意する必要があります。まず、音声データの収集にあたり、発話内容を検討しました。発話内容が異なっていると印象語を評価することが難しくなる、また予測も困難となることから、固定としました。発話内容は、印象スコアが予測できるほどの長さを確保する必要があります。そこで感情認識のデータセットSAVEE [2] を参考にしました。このデータセットでは長くとも4秒程であったため、同様の長さとなる発話内容(「私のロゴを作ってください。」)に設定しました。そして実際に社員800人の音声を録音しました。音声は個人データにあたるため、音声の利用に関する許諾確認書にサインしてもらう必要がありました。800人の席まで行き、許諾確認書にサインしてもらった上で、音声を録音するという大変な作業をデザイン本部が主導して進めました。
次に、録音した音声に対して、印象語をつけました。音声一つに印象は一つと定まらないことが多いため、各印象語へのスコア付けすることで評価することとしました。下図はスコア評価ツールを示しています。スコアは、0:感じない、1:かすかに感じる、2:少し感じる、3:感じるの4段階としました。主観評価になるため、各音声に対して最低3人で評価し、その平均を取りました。デザイン本部が作成したウェブページを使って評価データを集めました。

example_evaluation.png

印象語推定手法

音声から声の印象語を予測するにあたり、感情認識の手法 [3] を参考にしました。感情認識では音声から特徴量を抽出し、抽出された特徴量を機械学習モデルに入力し、出力結果から感情を認識します。これを踏襲することとしました。まず余分な区間を削除するため、振幅値ベースの音声区間検出を行い、検出された音声区間から特徴量を抽出しました。そして、その特徴量を入力として、スコア付けした印象語を予測するモデルを学習しました。音声の特徴量は、感情認識で多く用いられているOpenSMILE [4] のopenSMILE/openEAR 'emobase' set [5]の988次元から、下記に示す音響特徴の統計量からなる731次元を選択しました。

用いた音響特徴

  • Intensity
  • loudness
  • 声の高さ
  • ゼロクロス率
  • 24次のメルケプストラム係数
  • 13次のメル周波数ケプストラム係数とその一次微分

用いた統計量

  • 最大値
  • 最小値
  • 平均
  • 分散
  • 歪度
  • kurtosis
  • 1次関数近似の傾きと切片
  • 3種のinterquartile range
  • 3種のpercentile

また音声分析のために、WORLD [6] (D4C edition [7]) 、SPTK [8]を用いました。 抽出された731次元の特徴量から、印象語のスコアを予測する深層学習モデルを印象語それぞれに対して作成しました。深層学習モデルは隠れ層が128次元の4層からなるFeed-forwardモデルを採用しました。検証データにおいて、予測した各印象語のスコアと人手のスコアの相関係数は0.70となりました。また以下に散布図を示します。横軸が予測スコア、縦軸が人手でつけられたスコアの平均です。この結果からよく予測出来ているとと見てとれます。

voice_scatter.png

感情ごとの相関係数は以下のようになりました。ここから、感情ごとに予測精度に違いあることが確認できます。

感情 相関係数
可愛い 0.61
クール 0.48
落ち着いた 0.65
生き生きした 0.57
エレガント 0.72
渋い 0.14
ポリシーのある 0.71
優しい 0.43

エレガントが高く、渋いが低い結果となりました。特定の印象語によった結果となっており、この要因を探るため、上記の散布図よりエレガント(下図1枚目)と渋いのみ(下図2枚目)を取り出しました。散布図からもエレガントは相関が強く、渋いは相関が弱いことが分かります。

elegant.png

classic.png

次に人手でつけたスコア自体に偏りがなかったのかを調査しました。印象語ごとに人手でつけられた評価スコアの平均と分散を示します。この結果から印象語によったばらつきには、上記相関係数と同様の傾向は見られませんでした。印象語による予測精度の違いについては、今後調査が必要です。

感情 平均 標準偏差
可愛い 1.85 0.25
クール 1.58 0.39
落ち着いた 1.92 0.37
生き生きした 2.33 0.33
エレガント 1.19 0.48
渋い 1.88 0.26
ポリシーのある 1.39 0.59
優しい 1.65 0.20

フォントとイメージ画像の検索

データセットの作成

声の印象に近いフォントとイメージ画像を検索するには、フォントとイメージ画像にも8つの印象のスコアが必要になります。フォントは、Monotype株式会社(米国Monotype Imaging Inc.の日本法人)から提供されたものを利用しました。大量のフォントへのスコアづけは大変な作業となるため、各フォントについた31個のタグとその評価値を、印象語のスコアに変換することにしました。具体的には、word2vecを使ってフォントのタグと音声の印象語をベクトルとして表現し、コサイン類似度を計算します。1つの印象語に対して31個のタグとの類似度が得られるので、評価値での重み付き和をその印象語のスコアとして算出しました。イメージ画像の印象のスコアは、音声データと同様に、デザイン本部のメンバーが4段階評価でスコアをつけました。

印象の距離の計算

音声の印象、フォント、イメージ画像をそれぞれ8次元のベクトルで表現することができるようになったので、実際に音声の印象に近いものを検索します。fontgraphyではユークリッド距離の最も近いフォントとイメージ画像を検索しています。

スタイル変換

コンテンツ画像にスタイル画像の画風を反映させることをスタイル変換と言います。スタイル変換は、物体の形状はコンテンツ画像に近くなるように、色や風合いといった画風はスタイル画像に近くなるように変換します。リアルタイムで様々なスタイルに変換できるよう研究が進められています。いくつかのスタイル変換の手法を試した結果、fontgraphyに最も適したUniversal Style Transfer via Feature Transforms [9] を採用しました。スタイル変換の技術詳細に興味がある方は「2018年版 深層学習によるスタイル変換まとめ」をご覧ください。

example_styletransfer.png

Universal Style Transfer via Feature Transforms

論文:https://arxiv.org/abs/1705.08086

Universal Style Transferの説明に入る前にオートエンコーダについて説明します。オートエンコーダは、入力画像を復元するニューラルネットワークです。入力画像を表現する特徴を抽出するエンコーダと、抽出した特徴から入力画像を復元するデコーダから構成されます。

autoencoder.png

Universal Style Transferは、エンコーダとデコーダの間にWCTレイヤーを入れてスタイルを変換します。WCTレイヤーではwhiteningとcoloringという処理をかけます。2つの処理は物体の形状の特徴を変えることなく、色や風合いといったスタイルの特徴を変換します。具体的には以下のステップを踏みます。

  1. コンテンツ画像とスタイル画像をそれぞれエンコード
  2. コンテンツ画像の中間特徴を白色化:whitening
  3. スタイル画像の中間特徴の固有値固有ベクトルを使って白色化した特徴を変換:coloring
  4. 変換した特徴をデコード
  5. 1-4の処理を繰り返し

wct.png

whitening

コンテンツ画像の中間特徴を白色化します。白色化により物体の構造情報を保ったまま画風の情報を削ぎ落とすことができます。以下の画像は白色化した特徴をデコードした結果です。

example_whitening.jpg

対角成分に固有値を並べた行列Dc、固有ベクトルを並べた行列Ec、平均ベクトルmcを使って、エンコードした特徴fcを白色化します。 math_whitening.png

coloring

白色化した特徴をスタイル画像のパラメータで変換します。この変換は、画風の情報を削ぎ落とす白色化と逆の変換になります。対角成分に固有値を並べた行列Ds、固有ベクトルを並べた行列Esを使って、白色化した特徴を変換します。 math_colofing.png

coloringした特徴とコンテンツ画像の中間特徴を混ぜ合わせてからデコードすることで、画風の度合いをコントロールすることができます。 math_alpha.png

下図のように、alphaが大きいほどスタイル画像の画風が強く反映されます。

example_alpha.jpg

生成結果

fontgraphyは、以下のようなグラフィックを生成します。フォントは919種類、イメージ画像は400枚使っています。画風の度合いをコントロールするalphaを0から0.6まで0.1ずつ変化させて7パターンの変換をしています。以下の図はalphaを0.6とした結果です。

example_fontgraphy.png

おわりに

本記事では声からオリジナルグラフィックを生成するfontgraphyの要素技術についてご紹介しました。DeNAは引き続き技術を蓄積し、デザイン×AIの取り組みに挑戦していきます。

参考文献

[1] Surrey audio-visual expressed emotion (savee) database

[2] 話者の声の特徴を直感的な言葉で制御できる音声合成技術

[3] The INTERSPEECH 2009 Emotion Challenge

[4] openSMILE ‒ The Munich Versatile and Fast OpenSource Audio Feature Extractor

[5] OpenSMILE

[6] WORLD: a vocoder-based high-quality speech synthesis system for real-time applications

[7] D4C, a band-aperiodicity estimator for high-quality speech synthesis

[8] Speech Signal Processing Toolkit(SPTK)

[9] Universal Style Transfer via Feature Transforms

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