オンプレとクラウドのネットワークの話

IT基盤部エンジニアブログリレー第4回目。
こんにちは、IT基盤部ネットワークG torigoe です。
オンプレとクラウドのネットワークをどう繋げるのか、クラウド内のネットワークをどうするのか考えた話を書きます。

多くの内部サービスを持っていて、オンプレからクラウドに移行を検討しているネットワークエンジニアの人に読んで頂ければと思います。

はじまり

2018年ある日、mtgに呼ばれて急に DeNAのインフラ全てをオンプレからパブリッククラウド(しかもマルチ)に変えようと思うがどうよ? と言われました。正直その日まであまりパブリッククラウドサービスを触った事がありませんでしたが、説明された内容には納得できたのでそんな事は噯にも出さず同意し、次の日からオンプレ-クラウド移行の為に必要なネットワークの検討を開始する事になりました。(元々Openstackは触ってました)

まずはAWSを色々と触ってみました。 ちらほらなんでこんな仕様なの?という疑問をいだきつつも、ドキュメント読んだり触ったりして大体使い方を把握しました。
AWSの次はGCPを触り、それぞれ次のような感想を持ちました。

  • AWSはユーザファーストの意識が高いように思える
  • GCPはアーキテクチャに拘っていて独自性が高い

要件を整理する

オンプレとクラウドを繋げるネットワークを設計するにあたって、まず要件を整理する事にしました。
ざっくり書き出すと、

  • 最終的にクラウドをマルチ(AWS/GCP)に使いたい
  • DR化も踏まえて検討したい
  • DeNAは非常にサービス数が多い=VPC数が多くなる
  • 各VPCとオンプレ間/VPC間はセキュリティを考慮しつつボトルネック無く通信したい
  • オンプレに多少サービスが残る可能性もケアしておく
  • オンプレネットワーク機器の保守期間の残りや延長可否について決める
  • ネットワーク運用にかかる工数を削減したい
  • ネットワークセキュリティも整理したい

といったところでした。
要件の中に一部弊社オンプレ環境の問題もありますので、今回のブログでは主にクラウドのネットワーク周りにフォーカスして書きます。

検討開始

現状のネットワークの課題整理、クラウド側のネットワーク仕様、最終形、という3つを意識しつつ検討を始めました。

オンプレ~クラウド間の接続

まずオンプレとパブリッククラウドの間を物理的にどうやって繋げるのか検討しました。 経験上インターネットVPNでの通信は遅延や品質を考えると、サービスで使えるものでは無いと判断していました。 ファイアウォールのスペック次第ですがVPN通信のスループットはそこまで大きな帯域を確保出来るものではありませんし、インターネット上をパケットが流れるので我々のコントロール外のネットワークで輻輳や障害が発生しパケロスが発生する事があります。

実際今までにAWS/GCPとのVPN接続を何本も張っていますが、運用中にそこそこの頻度でAWS/GCPとのVPNが落ちる事を経験していました。VPN接続も冗長化している為大きなロスにはならないですが、やはり多少のインパクトはあります。 移行期間中はマスターDBがどちらかにある状態なので、VPNを介したサービスはレイテンシやパケロスにより遅延が発生する事が想定されます。 という事で、本格的にサービス移行&サービス利用用途としての通信手段はVPNでは無く専用線を引くしか無いだろうと考え、専用線の物理接続構成の検討を進めました。

2018年検討時点でのクラウド側(AWS/GCP)の10G専用線接続ポイント(データセンター)は下記の通りでした。

  • AWS Equinix TY2(Tokyo)
  • AWS @Tokyo(Tokyo)
  • AWS Equinix OS1(Osaka)
  • GCP Equinix TY2(Tokyo)
  • GCP ComSpace1(Tokyo)
  • GCP Equinix OS1(Osaka)
  • GCP NTT Dozima(Osaka)

※201906現在GCPは@Tokyo(Tokyo)も接続可能です

弊社のオンプレ環境は上記DCにはありませんので、AWS/GCPと直接通信する為には弊社DCと上記DCのどこかの区間に専用線を敷設する必要があります。 検討を進めていく中で、オンプレに多少サービスが残る可能性がネックになってきました。 というのも、万一最終的にオンプレにある程度のサービス・ラックが残るとなると,最善の最終DC構成がコスト見合いで変わってくる事がわかってきたからです。 そこで一旦不透明な最終形は考えずに、とりあえず現状が使いやすいように専用線を引く方向で検討を進める事にしました。専用線は敷設までの納期や最低利用期間等を考えると引き直しのハードルがやや高いのですが、それは許容する事にしました。

私の考えたマルチクラウドネットワーク+オンプレのロケーションの理想は、 AWS/GCP両方が同一DCで構内接続可能なEquinix or @Tokyoにラックを借りてルータを置き、両パブリッククラウドと構内接続する、サービスラックはそのDCに置くです。そうすれば全て構内配線で接続出来るので、回線周りのコスト・納期やレイテンシ等で優位性があります。

全て同一DCに収めるイメージ

全て同一DCに収めるイメージ

オンプレ-クラウド間のネットワークの繋ぎ方

次にオンプレ-クラウド間のネットワークをどうやって接続するのかを考えてみました。
要件でも挙げた通り、DeNAの特徴として サービス数(アカウント数/VPC数)が非常に多い ので専用線経由で多VPC接続という事を考慮する必要があり、 AWSの専用線ネットワークについて調査を進める中で、AWS DirectConnectのある制限に引っかかる事がわかりました。2018年検討当時、DirectConnect経由でVPCに接続できるのは50本までという制限がありました。(※今も制限ありますが、今はDirectConnectGatewayの仕様変更により50以上接続できます) DeNAのアカウント数は余裕で200を超える事が想定されていたので、この制限数の50に引っ掛かります。世の中のワークアラウンドを調べても、VPC内にルータインスタンスを立ててルーティングさせる、という非常にクラウドっぽく無いノウハウが散見されました。せっかくのクラウドなのでオンプレのようなネットワーク運用はしたくありません。

AWSの場合

DeNAではAWS Office Hourという毎週AWSの人が来社して気軽に相談出来るSpecialなmeeting timeが提供されていたので、早速AWSの人にカジュアルに相談を開始しました。タイミングが良かったのか、相談開始して程無くAWS Transit Gateway(以下TGW)という新ネットワークサービスが始まる、という事をUnderNDAで教えてもらいました。

※201907現在TGWはGAですが、東京リージョンのDirect Connectではまだ利用できません

TGWの仕様を細かく調べると多少課題は見つかったものの、概ね我々のやりたい事は出来そうでした。簡単に説明するとTGW=マネージドルータで、オンプレからTGWに接続すればTGWが各VPCにルーティングしてくれます。

TGWはこんな接続イメージです

TGWはこんな接続イメージです

AWS TGWの特徴は下記の通りです。

  • AWSサービスのマネジメントルータ
  • (TGWの)冗長性を気にする必要は無い
  • ルータなので経路情報を持つ事が出来る
  • TGWから他AWSアカウントのVPCに対して接続可能
  • TGWはデフォルトルートを持つことが可能
  • AWS Internet Gateway (IGW)と接続可能
  • AWS Direct Connect Gateway (DXGW)経由でオンプレと接続可能
  • ip addressの重複は不可
  • IPv6利用可能
  • TGWの帯域等はかなり大きく、ボトルネックにならなそう

TGWが無い場合のオンプレ-多VPC間の接続は大変だと思います。 VPC間通信のみを考えてもVPCピアリングやPrivateLinkというVPC間を繋ぐサービスもありますが、どちらも弱点があり今回の設計ではスコープから外しました。各VPC内のインスタンス上にルータをにたててルーティングさせるという前述の方法を採用すれば目的は達成できそうですが、そのルータの冗長化やネットワーク運用を考えると辛いです。

TGWの仕様を調べる中で課題がいくつか見つかったので、課題についてEBC (Executive Briefing Center)というAWSのサービス開発チームの人との個別セッションの場をAWSの方にセッティング頂き、DeNAの要望をAWSの開発の人に余す事無く伝えきる事が出来ました。まだ一部要望した機能は実装されておりませんが、サービス開発のロードマップには乗っています。
2018年 AWS EBC 集合写真(シアトル)

2018年 AWS EBC 集合写真(シアトル)

DeNAでは、AWSとオンプレのネットワーク接続にTGWを採用する事を決めています。

GCPの場合

並行してGCPも調査していましたが、やはりGCPもAWS同様専用線経由のProjectとの接続数制限がありました。 GCPもAWS同様GCP Office Hourという素晴らし(ry、GCPの人に相談したところ、GCP Shared VPCというサービスがある事がわかりました。
AWSのTGWとはかなり毛色が違い、ある1Project(Host Project)から他のProjectに対してVPCをシェアする、というネットワークサービスです。既に利用出来る状態だったので早速調査&検証を開始しました。

SharedVPC.png

SharedVPC接続イメージです

特徴は下記の通りです。

  • (TGWのような)ルータサービスでは無い
  • Host Project によって作成された1つの VPC を複数の Project で共有するサービス
  • Route, Firewall, Subnet, VPN を Host Project から一元管理できる
  • Organization 内で SharedVPC が有効化された Project が Host Project となる
  • Host Project に Attach した Project(Service Project)が共有されたリソース内でGCPサービスが利用できる(GCP全サービスではない)
  • Service Project 固有のスタンドアローンな VPC やその他のサービスも今で通り利用可能

大体やりたい事が出来る事はわかりましたが、TGWと違ってややイレギュラーな思想の為、TGWとは全く違う課題がいくつか見つかったのでGCP Office Hourの場で改善希望を伝えました。

DeNAでは、GCPとオンプレのネットワーク接続にShared VPCを採用する事を決めて、既に利用を開始しています。

その他考慮するポイント

ネットワークアドレスの管理、ネットワークセキュリティを考慮する必要があります。

ネットワークアドレス設計

当たり前の話ですが、オンプレ-クラウド間・VPC間でNATを介さずに自由に通信させたい場合は、オンプレ・クラウド全てでプライベートIPアドレスを重複しないように管理する必要があります。 クラウドだからと自由にアドレス採番をされてしまうと、 オンプレとネットワークを繋げる事が出来ないケースが出てきます。

※アドレスの設計詳細はセキュリティの都合上お伝えできませんが、書ける範囲で書きます

例えば10.0.0.0/8のプライベートアドレスがすべてクラウドで使えるとしても、前述の通りDeNAはサービス数が非常に多いので、全サービスが/16を使いたいと言い出した場合、本当にあっという間にアドレスが枯渇します。 また、そもそもDeNAはオフィス・社員数が多いので、オフィス用のプライベートアドレス空間は大きめに確保しています。また、データセンターにも数千台規模のサーバ群があるので、こちらもvlan毎に大きめにアドレス空間を確保しています。なので、プライベートアドレスは決して潤沢とは言えません。クラウド側にフルにプライベートアドレスを割り当てられるという事はありませんし、今後AWS/GCP以外にも利用クラウドが増えていく事を考えると、プライベートアドレスの管理はしっかりと運用していく必要があります。 クラウド側は耐障害性を考えてAZを分ける等の対応を取る必要があるので、/24ではほぼ足りず、規模に応じて/22-/20の間で各サービスに採番する事にしました。

その他にも細かいアドレス採番ルールもあるので、プライベートアドレスはIT基盤部で採番管理する事にしています。

ネットワークセキュリティ

実はネットワークセキュリティの検討については一番時間を使ったかもしれません。 現在オンプレ環境ではオフィス-DC間、DC内のvlan間でフィルタを設定していますが、このセキュリティ設定管理が非常に煩雑なのでここをどうにかしたいと考えていました。

その中でも、社内の人間のサービスリソースへのアクセス制限の管理が特に煩雑なポイントでした。 机上で考えるとただ決められたセキュリティルールに基づき初期設定すれば良いだけと思えますが、実際はかなりのイレギュラーケースが発生し、毎日のようにフィルタ設定の変更をする必要が出てきます。開発環境-本番環境間のフィルタも同様で、恒常的にフィルタ設定の変更をする必要があります。

vlanベースでのフィルタの設定にも限界がありました。具体的には、例えばサービスを複数跨ってアクセスするような人がいる場合、vlanベースだと人はvlan Aかvlan Bのどちらかにしか所属してしないのでどちらかにかアクセス出来ません。必要であれば最悪その人の為だけにわざわざ新しいvlanを作成する必要があり、vlanベースの通信制御は破綻していきます。 また、サービス=部署単位では無いので、部署単位でvlanを作ってもその通りにアクセス制御をする事も出来ません。

つまり、やりたい事としては、

  • サービス単位のグループで通信制御
  • 人はグループを跨ってもOK
  • そのグループのメンバーはサービス側で管理する

です。
DeNAではGSuiteを利用している為、GoogleGroupでグループ作成する事が一般的でAD連携が出来る仕組みもあったので、GoogleGroupを活用したアクセスの仕組みを考えました。色々と考えましたが、オフィスからもリモート(自宅)からも同一のセキュリティポリシーでアクセスさせたい事を考えるとVPNで制御するしかないかな、という結論に至りました。いくつかのVPN製品を調べていく中で、これも2018年検討当時に AWS ClientVPN がリリースされるという情報をAWS OHで教えて貰いました。(UnderNDA)
既にリリースもされているのでご存知の方も多いと思いますが、特筆すべきはADのSIDベースで制御できるという部分で、ここがマッチしそうでした。リリースされてから色々と触った所、いくつかの課題が見つかりました。

  • フィルタの順序が変えられない(順序を変えるには全消しして入れ直さないといけない...)
  • SIDを同時に複数指定出来ない
  • denyが書けない
  • クライアントのデバイスが固定出来ない

実際に使ってみて頂くとわかると思いますが、通信制御周りが使いづらいです。 上記に挙げたものは全て重要で、改善要望をあげています。

その他にもネットワークセキュリティ設計として、ネットワークセキュリティポリシーの設計をしました。ここの詳細はセキュリティの都合上割愛します。ポイントとしては、クラウド側のVPCのセキュリティポリシーを誰がどうやって制御するのか、具体的にどういうセキュリティポリシーにするのかといった内容で、セキュリティ部の人達と議論を重ねて大枠を決めていきました。

最後に

スケジュール感としては、2018年8月頃から検討開始、その後2018年内は毎週のように議論を重ねて、設計の大枠が出来たのが2018年末だったと思います。その後は細かい微調整やクラウド側への要望を続けたり、という事を継続しています。

この文章を通して、DeNAのオンプレとクラウドとのネットワーク接続への考え方が伝わればいいな、と思います。

色々と相談に乗って頂いたAWS/GCPの方々、どうもありがとうございました!
今後も引き続きよろしくお願いします。

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

コンピュータビジョンの最新論文調査 Segmentation 編

はじめに

こんにちは、AIシステム部でコンピュータビジョンの研究開発をしている唐澤です。 我々のチームでは、常に最新のコンピュータビジョンに関する論文調査を行い、部内で共有・議論しています。今回は Segmentation 編として唐澤 拓己(@Takarasawa_)、葛岡 宏祐(facebook)、宮澤 一之(@kzykmyzw)が調査を行いました。

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

論文調査のスコープ

2018年11月以降にarXivに投稿されたコンピュータビジョンに関する論文を範囲としており、その中から重要と思われるものをピックアップして複数名で調査を行っております。今回は主に Segmentation 技術に関する最新論文を取り上げます。

前提知識

Segmentation

segmentation とは領域分割という意味で、画像を入力としてピクセルレベルで領域を分割しラベルを付けていくタスクです.そのラベリングの意味合いから、画像上の全ピクセルをクラスに分類する Semantic Segmentation、物体ごとの領域を分割しかつ物体の種類を認識する Instance Segmentation、最後にそれらを組み合わせた Panoptic Segmentation というタスクに大別されます。特に、最後の Panoptic Segmentationは ECCV 2018で新しく導入されたタスクです。

Semantic Segmentation

塗り絵のように画像上全てのピクセルに対して、クラスカテゴリーをつけるタスクです。画像を入力とし、出力は入力の画像と同じサイズで、各ピクセルに対してカテゴリーラベルがついたものとなります。特徴として、空や道といった物体として数えられないクラスの領域分割も行える一方で、車や人のような数えられるクラスに対して、同クラス間で重なりがある場合、同クラスの領域として認識するため、物体ごとの認識・カウントができません。評価指標としては mIoU(mean intersection over union)が使われています。

このタスクのネットワークは、Fully Convolutional Network [1] が発表されて以来、FCN 構造が基本となっています。有名な手法(ネットワーク)として、高解像度特徴マップをエンコーダからデコーダに取り入れる U-Net(MICCAI 2015)[2]、upsampling の際にエンコーダでの max pooling の位置情報を使用する SegNet(arXiv 2015)[3]、複数のグリッドスケールでspatial pyramid pooling を行う PSPNet(CVPR 2017)[4]、atrous convolution を取り入れた DeepLab 系 ネットワーク(ICRL 2015~) [5, 6, 7, 8] などがあります。

Instance Segmentation

Object detection のような物体の認識をピクセルレベルで行うタスクです。画像を入力とし、出力は物体の存在する領域を、ピクセルレベルで検出したものとなります。Semantic Segmentationと異なり、重なりのある同一物体などを正しく別々に検出する一方、物体候補領域、すなわち RoI(region of interest)に対して segmentation を行うので、画像全てのピクセルに対してラベルを振ることは行いません。評価指標としては物体検出と同様に mAP(mean average precision) が使われています。

アプローチは、detection 手法を用いて instance 領域を取得後、それぞれの領域に対して mask を予測する detection ベースのアプローチ、まずそれぞれの pixel をラベリングした後ピクセル群をグルーピングする segmentation ベースのアプローチの二つに大別されます。高精度な手法は特に前者に見られる印象で、Mask R-CNN(ICCV2017)[9] は有名なネットワークです。他にも DeepMask(NIPS 2015) [10]、FCIS(ICCV2017)[11]、MaskLab(arXiv2017)[12] などがあります。後者のアプローチとしては境界検出を利用した Instancecut [13] や、watershed algorithm を使用した手法 [14] が存在します。

Panoptic Segmentation

Semantic Segmentation と Instance Segmentation を足し合わせたようなタスクです。入力は画像で、出力には Semantic Segmentation のように、全てのピクセルにラベルが振られ、かつ数えられる物体に関しては、個別で認識した結果が返されます。

数えられるクラス(車や人)を Thing クラスといい、数えられないクラス(空や道)を Stuff クラスといいます。Thing クラスに対して Instance Segmentation、Stuff クラスに対してSemantic Segmentation を行うタスクと考えればわかりやすいです。評価指標には、後述するPQ(panoptic quality)を使っています。こちらは比較的新しいタスクのため、提案されているネットワークの数が他の segmentation タスクと比べ少ないのですが、本記事では CVPR で発表されたものを数本紹介します。

関連データセット

  • Cityscapes:semantic segmentation、instance segmentation、panoptic segmentationを含む。
  • PASCAL VOC:semantic segmentation を含む。segmentation だけでなく detection 等も含む。
  • ADE20K:semantic segmentation を含む。
  • COCO:instance segmentation、panoptic segmentation を含む。segmentationだけでなく、detection等も含む。

論文紹介:Semantic Segmentation

Auto-DeepLab: Hierarchical Neural Architecture Search for Semantic Image Segmentation(CVPR 2019 oral)

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

要約

semantic segmentation のような、解像度に対して sensitive なタスクに対して有効性を発揮しなかった NAS(neural architecture search) においてセルの探索だけでなくネットワークレベルでの探索を行う階層的なアーキテクチャ探索を提案。

提案内容

  • 従来の cell レベルの構造の探索に加え network レベルの構造の探索をすることを提案。これにより階層的な探索空間を形成。
  • Darts [15] により提案された continuous relaxation を network レベルにも拡張した、gradient-based なアーキテクチャ探索を提案。

アーキテクチャ探索空間:cell(小さい fully convolutional module)レベル

  • cell は、内部の B 個の block で構成され、それぞれの出力を順に結合し cell の出力とする。
    • block:2ブランチ構造。2つの入力から出力を行う。(I1, I2, O1, O2, C)で表現。
      • I1, I2:入力の組み合わせ。取りうる選択肢は一つ前のセルの出力、二つ前のセルの出力、一つ前のセル中のそれぞれのブロックの出力
      • O1, O2:それぞれI1, I2に対応して行われる処理。取りうる選択肢は、
        • 3x3/5x5 depthwise-separable conv
        • 3×3/5x5 atrous conv with rate 2
        • 3x3 average/max pooling、skip connection、no connection(zero)
      • C:それぞれのブランチの出力を組み合わせ block としての出力を行う処理。論文中ではelement-wise な足し算のみ。

図1:cell レベルの探索空間の結合関係。H は各出力。H の右上の添字は cell の番号、H の右下の番号は block の番号。左上の添字 s は解像度を表し下記の network レベルの空間にて用いる。

アーキテクチャ探索空間:network レベル

  • 多様なアーキテクチャに共通する二つのルールを元に探索空間を構築。
    • 各層の次の層の解像度は二倍、半分、同じ、のいずれか。
    • 最も低解像度までダウンサンプリングした部分で、1/32。
  • 最初は1/4までダウンサンプリング(ここまでを stem と呼ぶ)し、その後は 1/4 から 1/32 の範囲内で探索。

図2:network レベルの探索空間。横軸がレイヤーのインデックス、縦軸がダウンサンプリングの倍率を表す。ASPP = Atrous Spatial Pyramid Pooling。

最適化方法

  • continuous relaxation により gradient ベースで最適化可能に。
  • 学習データを二つに分け、ネットワークの重みとアーキテクチャの重みを交互に更新。
  • 損失関数は cross-entropy。

Continuous Relaxation

  • cell architecture:O(H) は重み付け和で近似(continuous relaxation)。この重み alpha を gradient ベースで最適化する。重みは非負で総和1。softmax で実装。

  • network architecture:
    • network レベルの探索は、各レイヤが解像度により最大4つの隠れ状態を持つ。
    • 各解像度の出力は cell レベルの出力を重み付け和で以下のように近似(continuous relaxation)。この重み beta を gradient ベースで最適化。重みは非負で総和1。同様にsoftmaxで実装。

  • beta は、もちろんレイヤー・解像度ごとに存在するが、alpha は全てのブロックで共通。

探索後のアーキテクチャのデコーディング

  • cell architecture:各入力に対するオペレーションは argmax で選択。入力の二つの選択は、各入力に対応する no connnection のオペレーションを除いた全オペレーションに対する alpha らの最大値が大きいものから二つ選択。
  • network architecture:beta は状態遷移確率とみなせるため、最適な状態系列(最適経路)をを求めるアルゴリズム、Viterbi アルゴリズムを用いる。
実験結果

Cityscapes データセットに対してアーキテクチャサーチを行い獲得したモデルを用いて、Cityscapes、PASCAL VOC 2012、ADE20K データセットを用いて評価を行った。

アーキテクチャサーチ実装詳細

  • 12 layers、セル内のブロック数:B = 5 を使用。
  • フィルター数:feature tensor の幅高さが半分とするときフィルター数を倍にするという一般的な方法に従い、ブロック数をB、sを図2のダウンサンプリングの倍率、Fをフィルター数を制御するハイパラとして B x F x s/4。
  • downsample: stride 2 の convolution、upsample: 1x1 convolution + bilinear upsampling
  • 局所最適を防ぐため、alpha, beta は 20 epoch 後から学習。

図4:Cityscapes に対する実験で実際に得られた探索結果。左図のグレーの破線矢印は各ノード間の重みが最大となる矢印を表す。atr: atrous convolution. sep: depthwise-separable convolution。

実装詳細

  • シンプルなエンコーダデコーダ構造を使用。
    • エンコーダ:上記のアーキテクチャサーチで獲得したモデル
      • "stem"部分は 3つの 3x3 convolutions (1つめと3つめはstride 2)
    • デコーダ:DeepLabv3+ [8] と同じものを使用。

モデルの多様性に関する ablation study。

  • フィルター数を制御するハイパラFを増やすと計算コストは大きくなるが良いパフォーマンスとなる。

図5:異なった多様性をもったモデルの validation に対する結果。フィルター数を制御するハイパラFを変化させたときの比較。ImageNet のカラムは ImageNet で pretrain したかを表す。

Cityscapes データセットを用いての他手法との比較。

  • pretraining なしで、ベストなモデル(Auto-DeepLab-L)はFRRN [16]、GridNet [17] を大きく上回る。
  • Cityscapes データセットの coarse annotation データについても使用することで、pretraining なしで PSPNet [4] 等を上回り、55%もの積和演算を削減できた上で DeepLabv3+ [8] 等に匹敵するパフォーマンスを出した。
  • また、PASCAL VOC 2012、ADE20K に対しても ImageNet での pretrain なしで他手法に匹敵するスコア。

図6:Cityscapes test set に対する実験結果。ImageNet のカラムは ImageNet で pretrain したかを表す。Coarse は coarse annotation を使用したかを表す。

Devil is in the Edges: Learning Semantic Boundaries from Noisy Annotations(CVPR 2019 oral)

論文:https://arxiv.org/abs/1904.07934 、github:https://github.com/nv-tlabs/STEAL

要約

Semantic Segmentation に類似した課題である Semantic Edge Detection において、アノテーションのノイズにより検出エッジが厚みを持ってしまうことを指摘。この課題に対しエッジ細線化のための新たなレイヤを導入すると共に、アノテーションを自動的に補正して高精度化する手法も提案。

提案内容

Semantic Segmentation の双対問題である Semantic Edge Detection(画像からエッジを検出すると共に、各エッジがどの物体の境界なのかをラベル付けする)において、従来手法では検出されるエッジが厚みを持ってしまうという問題がある(図1右の中央列が従来手法による結果)。本論文では、これは学習データにおいて真値として与えられている物体境界が不正確であることが一因であると指摘(図1左)。

図1:アノテーション誤差(左)と、エッジ検出結果の従来手法との比較(右)

この問題に対し、提案手法ではまず、エッジを細線化するための Boundary Thinning Layer と呼ばれる新たなレイヤを提案している(図2中央の黄色領域)。このレイヤでは、CNN が出力したエッジマップにおいて、エッジ上の各点で法線方向にサンプリングを行い、SoftMax を適用することでエッジ以外の点で値が大きくなることを抑制している。これにより、従来手法よりも細く正確なエッジを得ることが可能となる(図1右端列)

図2:提案手法の概要

また、本論文では学習データにおける不正確なアノテーションを補正する手法も提案している。これを Active Alignment と呼び、具体的には動的輪郭モデルを用いて真の物体境界に近付くようにアノテーション境界を徐々に移動させていく(図2右の青色領域)。動的輪郭モデルとしてはレベルセット法を採用しており、学習時にエッジ検出のための CNN のパラメータ更新と、レベルセット法による輪郭の高精度化の2つを交互に繰り返すことで検出モデルと学習データの両面からの改善を実現している。

実験結果

SBD(semantic boundary dataset)と Cityscapes を用いて、従来手法としてよく知られている CASENet およびその改良手法(CASENet-S、SEAL)との比較を行なっている。実験結果を図3に示す。Semantic Edge Detection は検出問題であるため、物体検出などと同じように precision と recall での評価が可能であり、図3における MF(maximum F-measure)とは PR カーブの各点におけるF値の最大値である。MF、AP(average precision)のいずれにおいても、提案手法は従来手法よりも高い精度を達成している。図4はSBDにおける検出結果を定性的に比較したものであるが、提案手法で検出されたエッジは従来手法よりも大幅に細く正確であることがわかる。

図3:実験結果(上:SBD、下:Cistyscapes)

図4:SBDにおけるエッジ検出結果(左から順に、入力画像、CASENetによる結果、提案手法による結果、真値)

また、Active Alignment の効果を図5に示す。図5上段が初期値として与えた不正確なアノテーションであり、下段が Active Alignment により補正を実施した後の結果である。Active Alignment により物体境界が高精度化されていることがわかる。

図5:Active Alignmentの効果(上:補正前、下:補正後)

論文紹介:Instance Segmentation

Mask Scoring R-CNN(CVPR 2019 oral)

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

要約

従来の instance segmentation 手法は、出力結果の信頼度を classification confidence として出力しているが mask の信頼度と一致していないことを指摘。mask の confidence を出力するブランチを Mask R-CNN [9] に加え適切な mask の信頼度を使用することを提案。

提案内容

  • 従来の classification confidence を用いた信頼度の出力の不適切さを指摘。
    • object detection でも言及される問題点。参考:IoU-Net

図1:mask があまり良い結果でないにもかかわらず高い classification score を出力してしまっている例。(MS R-CNNは提案手法が出力するスコアで mask confidence も考慮された上で出力されている。)

  • IoU(Intersection over Union)を直接学習する MaskIoU Head と呼ばれるブランチを Mask R-CNN [9] に追加した、Mask Scoring R-CNN(MS R-CNN)を提案。
    • MaskIoU Head により出力される IoU の予測値を MaskIoU と呼ぶ
    • 単に分岐するブランチではなく、RoI Aligin により抽出された特徴マップに加えて予測された mask も加えて入力する。
    • 出力の次元数はクラス数。各クラスで IoU を予測する。
    • 学習:予測されたマスクを閾値0.5で二値化したマスクと正解マスクの IoU を ground truth として L2損失で学習。
    • 推論:MaskIoU を出力し、MaskioU と classification score を掛け合わせることによって各 instance への適切なscoreを出力する。

図2:Mask Scoring R-CNN 全体のアーキテクチャ。

実験結果

  • COCO 2017 に対して実験を行い、バックボーンの種類に依存せず、また FPN(feature pyramid network)や DCN(deformable convolution network)の使用の有無に依存せず安定してスコアを改善することを示した。(図3, 図4)

図3:複数のバックボーンに対する Mask Scoring R-CNN の実験結果の比較。APm は instance segmentation の結果。APb は object detection の結果。(COCO 2017 validation 結果)

図4:FPN、DCN の使用に対する Mask Scoring R-CNN の実験結果の比較。APm は instance segmentation の結果。APb は object detection の結果。(COCO 2017 validation 結果)

  • 他手法との比較については図5のように掲載されている。論文中で優劣についての考察は言及されていない。

図5:他手法との instance segmentation 結果の比較。(COCO 2017 test-dev 結果)

論文紹介:Panoptic Segmentation

Panoptic Segmentation(CVPR 2019)

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

要約

新しいタスクとして、Panoptic Segmentation を提案した論文。新たな評価指標として、Panoptic Quality(PQ)を提案し、既存のセグメンテーションネットワークに事後処理を加え、PQ を出し、人間との精度比較やベンチマークを構築した。

提案内容

Instance Segmentation と Semantic Segmentation を足し合わせた新しいタスク、Panoptic Segmentation を提案。数えられるクラス(人や車)を Thing クラス、数えられないクラス(空や道)を Stuff クラスと定義し、それぞれに対し Instance / Semantic Segmentation を行う。

Semantic Segmentation 同様、出力は、入力画像と同じサイズで、各 pixel にクラスのラベルが振られているもの。ただし Semantic Segmentation と異なり、Thing クラスに対しては、個々の物体を正しく pixel レベルで認識する。Instance Segmentation では、物体間での overlap は発生するが、Panoptic Segmentation では、1つの pixel が2つのクラスカテゴリーを持つことはない。

図1:異なる Segmentation の比較。右上から Semantic Segmentation 左下に Instance Segmentation、そして右下に、それらを統合した Panoptic Segmentation。

新しい評価指標として、Panoptic Quality(PQ)が提案された。PQとは数式では以下のように表される。Recognition Quality(RQ)は物体検出などで使われる、F1 スコアで、SQ は Semantic Segmentation で使われる、mIoU となっており、それらを掛け合わせたものが、PQ となっている。

図2:新タスクの評価指標として提案された、PQ。Instance Segmentation の精度を表現する RQ と Semantic Segmentation の精度を表現するSQから成る。

実験結果

既存の Instance Semgmentation と Semantic Semgmentation のネットワークを使用し、Cityscapes, ADE20k, Vistas データセットでの評価をし、ベンチマークを構築し、人間のアノテーション精度と比較を行った。

図3:Cityscapes データセットで、Semantic Segmentation に PSPNet [4]、Instance Segmentation に Mask R-CNN [9] を使い比較をした結果

図4:ADE20k データセットで、2017 Places Challenge の優勝者の手法を使い、精度の比較をした結果

図5:Vistas データセットで、LSUN 17 Segmentation Challenge の優勝者の手法を使い、精度を比較した結果

Panoptic Feature Pyramid Network(CVPR 2019 oral)

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

要約

既存の Panoptic Segmentation ネットワークは backbone を統一していないネットワークが多いが、Mask R-CNN [9] に少し改良を加えることによって、Semantic Segmentation に応用できるということを主張し、結果的に backboneの統一を行い、end-to-end なPanoptic Segmentation ネットワークを作った。

提案内容

Mask R-CNN [9] に Semantic Segmentation Branch と言う新しいブランチを付けることによって、Instance Segmentation だけでなく、Semantic Segmentation にも対応できるようにした。

Semantic Segmentation Branch は FPN のサイズの異なる特徴マップを入力とし、それぞれに対して3x3 conv, GN, ReLU 最後に bilinear upsampling を行い、各サイズの特徴マップを入力画像比 1/4 のサイズに統一する。最後にサイズが同じの特徴マップに対して、1x1 conv, blinear upsampling、最後に softmax を行い、入力画像のサイズと同じにすることによって、pixel レベルでの classification を行う。

図1:Semantic Branchの構成図。FPN の出力(図左)に対して、3x3 conv などを行い、出力のサイズを入力画像比1/4に upsampling し、1x1 conv, bilinear upsampling などを行い入力画像と同じサイズにする(図右)。

Lossの定義は

  • Classification Loss: Instance Branch
  • Bounding Box Loss: Instance Branch
  • Mask Loss: Instance Branch
  • Cross Entropy: Semantic Branch

を適用していて、Instance BranchのLossとSemantic BranchのLossはパラメータλによってバランスが保たれている。

前半で紹介したPanoptic Segmentationの論文と同様に、結果がOverlapした場合には、以下のポリシーを用いて処理している。

1) Instance同士でのOverlapでは、NMS同様Confidence Scoreを元に片方を抑制する

2) ThingクラスとStuffクラスでOverlapが発生した場合は、Instanceの結果を優先する

実験結果

Mask R-CNN に Semantic Branch を付けた Semantic FPN と、既存 Semantic Segmentation モデルでの精度比較と、提案手法と既存 Panoptic Segmentation モデルでの精度比較を、COCO, Cityscapes のデータセットを用いて行なった。

Semantic FPN と既存手法での精度比較を Cityscapes で行った結果、下の図の様に、既存手法と同等の精度が出ることが確認された。既存手法の多くに dilated conv が使われている中、Semantic FPN は Semantic Segmentation 特有のオペレーションを使用していないため、比較的に少ないメモリー使用量で、backbone 選択の制約を低くした。

図2:Semantic Branch を Mask R-CNN に付け、既存の Semantic Segmentation のネットワークと mIoU を用いて性能比較をした結果。backbone 中にある「D」は dilated conv を指す。

最終的に COCO を用いて PQ で評価した結果、既存の single network を大幅に上回る精度が出た。特に Thing クラスでの精度向上が大きく、これはベースとなっている Mask R-CNN が Instance Segmentation のネットワークだからと著者は言っている。

図3:既存 single network と PQ を用いて性能評価をした結果。特に Thing クラスでの性能向上が大きく、統合された結果では 8.8pt 向上している。

最後に、定性的に評価した結果は以下の様になっている。

図4:COCO(図上)とCityscapes(図下)に対して Panoptic Segmentation を行なった結果。

UPSNet: A Unified Panoptic Segmentation Network(CVPR 2019 oral)

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

要約

Mask R-CNN [9] に新しい Head を追加し、Semantic Segmentation に応用し、双方の結果をマージするために新しい Parameter-free Head、Panoptic Head を提案した。既存の single network と separated network と性能を比較したところ、同等、もしくは既存手法より高い精度を end-to-end のネットワークで出した。

提案内容

deformable conv を使った Segmentation Head を提案し、Instance Segmentation モデルの Mask R-CNN [9] を Semantic Segmentation に応用した。Semantic Head と Instance Head の出力は parameter を必要としない、Panoptic Head によってマージされ、それらの結果が最終的な出力となる。

図1:全体の構成図。Mask R-CNN に新たに Semantic Head を追加することによって、Semantic Segmentation を行い、それらの結果をマージする Panoptic Head を新たに提案し end-to-end なネットワークを作った。

Semantic Head の目的は、Stuff クラスを正しく認識し、かつ Thing クラスの精度向上にも貢献することである。構造は以下の様になっており、deformable conv をFPNの出力にまず行い、そして入力画像比 1/4 まで upsampling される。全ての特徴マップのサイズを揃えた後、チャンネル方向に concat、1x1 conv 最後に softmax を行い、pixel レベルの classification を行う。

図2:Semantic Head の詳細図。FPN の出力を入力とし、deformable conv を行い、upsampling をし 1/4 のサイズに揃える。これらの結果が Stuff クラスと Thing クラスの予測に使われる。

Instance Head は Mask R-CNN と同じで、それら両方の結果が Panptic Head によって統合される。Semantic Head の出力は、Thing クラスの予測と Stuff クラスの予測に分かれ、Xthing と Xstuff として下の図では表現されている。Xstuff はそのままPanoptic Logits にマッピングされ、Xthing は GT の bounding box 座標をもとに cropping され、Xmask として Thing クラスの予測に使われる。Xmask と Yi は同じサイズに揃えた後、element-wise に足し、その結果が Panoptic Logits の Thing クラスの予測にマッピングされる。

図3:Panoptic Head の詳細図。Xthing と Xstuff は Semantic Head の出力で、Yi は Instance Head の出力。それらの結果は統合され、最終的に Panoptic Logits として出力される。

実験結果

COCO データセットを用いた、既存 Panoptic Segmentation との性能を比較。

図4:COCO2018 test-dev での性能比較の結果。上の3つは leader board の上位3つのモデル。

Cityscapes データセットを用いた、既存 Panoptic Segmentation との性能を比較。 図5:Cityscapes データセットでの 既存 Panoptic Segmentation との性能比較。COCO と書いてあるモデルは、COCO で pre-train 済みのモデルを使用。

おわりに

今回は Semantic Segmentation、Instance Segmentation、Panoptic Segmentation を含めた segmentation に関する最新論文をご紹介しました。segmentation タスクへの手法が発達してきたことで、Panoptic Segmentation といったより高難易度な新しいタスクへのアプローチの提案が行われてきており、興味深いです。 DeNA CVチームでは引き続き調査を継続し、最新のコンピュータビジョン技術を価値あるサービスに繋げていきます。

参考文献

[1] J. Long, et. al. Fully convolutional networks for semantic segmentation. CVPR 2015

[2] O. Ronneberger, et. al. U-net: Convolutional networks for biomedical image segmentation. MICCAI 2015

[3] V. Badrinarayanan, et. al. Segnet: A deep convolutional encoder-decoder architecture for image segmentation. arXiv 2015

[4] H. Zhao, et. al. Pyramid scene parsing network. CVPR 2017

[5] L.-C. Chen, et. al. Semantic Image Segmentation with Deep Convolutional Nets and Fully Connected CRFs. ICLR 2015.

[6] L.-C. Chen, et. al. Deeplab: Semantic image segmentation with deep convolutional nets, atrous convolution, and fully connected crfs. TPAMI 2017

[7] L.-C. Chen, et. al. Rethinking atrous convolution for semantic image segmentation. arXiv 2017

[8] L.-C. Chen, et. al. Encoder-decoder with atrous separable convolution for semantic image segmentation. ECCV 2018

[9] K. He, et. al. Mask rcnn. ICCV 2017

[10] P. O. Pinheiro, et. al. Learning to segment object candidates. NIPS 2015

[11] Y. Li, et. al. Fully convolutional instance-aware semantic segmentation. ICCV 2017

[12] L.-C. Chen, et. al. Masklab: Instance segmentation by refining object detection with semantic and direction features. arXiv 2017

[13] A. Kirillov, el. al. Instancecut: from edges to instances with multicut. CVPR 2017

[14] M. Bai and R. Urtasun. Deep watershed transform for instance segmentation. CVPR 2017

[15] H. Liu, et. al. Darts: Differentiable architecture search. ICLR 2019

[16] Z. Yu, et. al. CASENet: Deep Category-Aware Semantic Edge Detection. CVPR 2017

[17] T. Pohlen, et. al. Full-resolution residual networks for semantic segmentation in street scenes. CVPR 2017

[18] D. Fourure, et. al. Residual conv-deconv grid network for semantic segmentation. BMVC 2017

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

DeNA の QCT マネジメント

DeNA の土屋と申します。2014 年に新卒で入社して以来一貫して IT 基盤部に所属し,現在は第四グループのマネージャーとして,全世界向けに提供している超大規模ゲームタイトルおよびゲームプラットフォームのインフラ運用をリードしています。

IT基盤第4G.png

私のグループでは直近 1 年間,クラウド環境におけるコストコントロールの施策中心に,インフラの QCT (Quality, Cost, Time) マネジメントに取り組んで来ました。その具体的な方法や成果については先日の AWS Summit Tokyo 2019 で発表させて頂きました (以下が発表資料です)。

この資料だけを見ると極めて体系的かつ順調に各施策を進めることができた,ともしかしたら見えるかもしれませんが,実際は様々な試行錯誤がありました。本記事ではそのような苦労話に触れつつ,インフラコスト 60% 削減達成までの道のりについてお話しします。

インフラに求められる QCT とは

インフラノウハウ発信プロジェクト第 1 回目の記事でも触れられていた内容ですが,具体的な話に入る前にインフラの文脈における QCT がどのような内容を指すかについて改めて整理したいと思います。

  • Quality
    • 最高品質のインフラを提供することを指します。インフラ起因による障害をなくすことはもちろん,品質維持・向上のためにできることは全て行い,工数の許す限り稼働率 100% を維持し続けることを目指してインフラを運用しています。
  • Cost
    • インフラ費用を適切にコントロールすることを指します。DeNA のインフラ部隊は創業当時から非常に高いコスト意識を持っています。ただし,ただ安ければ良いという考え方ではありません。管理工数や利便性などに照らしてメリットがあるサービスや商品についてはたとえ割高であっても利用するという判断をします。
  • Time (Delivery)
    • インフラ提供のリードタイムを短くすることを指します。品質とコストを求めるあまり,インフラ提供までに何ヶ月も掛かるような状態では DeNA の事業展開スピードを支えられません。どのようなスケジュールでも安定したインフラを提供することも重要なミッションの 1 つです。

本記事ではコスト削減がメインの話題になりますが,他二つの水準を落とさないということは大前提になります。

なぜコストコントロールが必要になったのか

DeNA はもともとメインのシステム基盤にはオンプレを採用していましたが,私のグループが担当するサービスは全世界向け,そして必要リソースが大幅に乱高下するため,サービス開始当初から 100% クラウドで運用していました。

そのような中,2018 年 6 月に大きな意思決定がなされます。全サービスのシステム基盤をクラウド化するという決定です。当時の DeNA インフラの概況や,クラウド化の経緯についての説明は以下の資料に譲り,ここでは割愛します。

オンプレ環境において,DeNA のインフラは圧倒的な低コストを実現していました。これは同一スペックのサーバを同時に大量に購入して調達価格を下げるという工夫や,サーバのリソースを使い切るための技術およびノウハウによるものです。

この状態からクラウド環境へ移行すると費用はどのくらい増えるかを試算したところ,何も工夫せずに移行するとなんと 3 倍にまで膨れ上がるという結果になりました。何も工夫せずと書きましたが,前述のオンプレ環境における技術やノウハウを適用してもなおこのくらい費用が増えてしまうという状況でした。

そこで,このコスト差を埋めるためにコストコントロール施策の実証が必要になった訳です。検討ではなく,実証です。この時点で候補となるような施策はいくつか挙がっていましたが,それらの施策は本当に実現可能なのか,コストは下げられたが品質が劣化することはないか,運用工数が増えることはないか,などの懸念は実際にやってみなければ払拭できません。クラウド移行がすべて完了した後になってやはり実現は無理でした,という事態は何としても避けなければなりませんでした。

システム基盤のクラウド最適化や移行スケジュールの精緻化など,クラウド化の準備として行うべきことは他にもたくさんありましたが,このコストコントロールの実証はすでにクラウドを用いてインフラ運用を行なっている私のグループで担当することになりました。

机上の計算では 50% の削減が可能

クラウドならではのコスト削減はクラウド化の全社決定がなされる前から様々検討はしていました。本腰を入れて進めるにあたり,まずは考えられる手段を列挙し,それらが仮にうまくいった場合に現状のコスト構造に照らしてどの程度のコスト削減が見込めるか,という試算を行いました。その際,阻害要因となるものも一緒に洗い出しています。

例えばオートスケーリング。担当のシステム構成においては,クラウド費用全体の 90% が IaaS の費用であり,その内 60% 程度がオートスケーリングを適用できるサーバでしたので,オートスケーリングによってこれらのサーバの費用が 20% 減らせると仮定すれば全体の費用は 0.90 * 0.60 * 0.20 で約 10% 程度全体の費用を下げられる,というような試算をしました。また,阻害要因としてはオートスケーリングの仕組みを作るための実装コスト,安定して稼働させるまでの導入コスト,またインフラ運用メンバの工数不足などを挙げていました。

他の施策についても同様に試算を行い,全てうまくいった場合 50% の費用削減が可能であるという皮算用を得ました。

ここで重要なのは,もちろんコストを 50% 程度は下げられそうという試算結果も大事なのですが,どの施策から進めるのが費用削減効果と実施工数両方の観点から良さそうか,という優先順位を決めることです。通常のシステム運用をこなしながらこれらの施策を進めていく必要がありましたので,全部を一気に並列に進めることはできません。この優先順位を決めるにあたっては,コスト削減効果の精緻な見積もりよりも (そもそも実際にやってみないと推測の域を出ないので,精緻な見積もり自体不可能),だいたいのオーダ感とどのくらい大変そうかという工数感の方が必要です。

ただし,数値の算出根拠だけはきちんと説明できるようにしておくべきです。先のオートスケーリングの例では 90%,60%,20% という数値が出て来ましたが,90% と 60% は事実なので定数,20% の値は実際のシステムのワークロードに大きく依存するので変数ということになります。こういう説明ができると各施策の勝算の確度が分かるので,優先度を決めるための判断材料の 1 つになりますし,どのくらい未確定要素を含んでいるのか,という認識を関係者間で正しく合わせることにも役立ちます。

オートスケーリングを最優先で導入

コスト削減試算の結果,効果が最も大きかったのはやはり API サーバへのオートスケーリング導入でした。実はオートスケーリングは突発的なトラフィック急騰時のサービス品質への備えとして自動スケールアウト機能だけはすでに導入できていました。また,時間指定の台数の増減もバッチ処理により何とか動いていました。

しかし,これらの既存の仕組みは相当に辛い状態でした。インスタンスの起動,削除,必要台数の計算などオートスケーリングに必要なあらゆる処理が 1 つの巨大なモジュールに全て記述されており,ここに自動スケールインのロジックを追記したり,各処理に対する冪等性担保のための処理やリトライ,エラーハンドリングを入れていくことはもはや不可能でした。台数の自動増減も非常に原始的で crontab に以下のような記述があるだけでした。

 0 21 * * * api-server-service-in  --ammount 50 # API サーバを 50 台追加
 0  0 * * * api-server-service-out --ammount 50 # API サーバを 50 台削除

そこで,既存の資産は活用しつつオートスケーリングの仕組みを抜本的に改善することにしました。この改善施策自体はクラウド化が決定する前の段階から進めており,これから本番環境に導入していくというフェーズでした。刷新後のオートスケーリングシステムの設計や実装の詳細は今後の記事で他メンバから紹介してもらおうと考えていますので,この記事では本番に導入していく過程や,今現在どのように運用しているかをお話ししたいと思います。

本番環境で実際に運用するにあたっては,何よりもまずは安定性を重視しました。API サーバはゲームサーバの根幹を担うものであり,これの台数管理を司るオートスケーリングシステムを安定して稼働させることは大前提です。そうはいっても 1 日に数百台というサーバを作っては壊しという作業をひたすら行うため,どこかしらで必ず不具合が出てきます。

そのため,まずは各処理に対してきめ細やかにエラーハンドリングやリトライを入れていきました。例として対象サーバに対して ssh 接続できるか確認する,という処理の設定ファイルの一部を以下に示します。詳しい書式や定義はここでは省略するとしてリトライ間隔,リトライ回数,タイムアウトが指定できるようになっていることがお分かり頂けると思います。

 [Task]
 Name = "CheckNetowrkSSH"
 Description = "check network connection SSH"

 [Task.Component.Params]
 RetryInterval = 5
 Retry = 30
 Port = 22
 Timeout = 3

また,実際に ssh 接続確認を行うコードは以下の通りで,当然ではありますがきちんとエラーハンドリングを行うコードになっています。

 func checkTCP(target string, timeout time.Duration) error {
     conn, err := makeConnection("tcp", target, timeout)
     if err != nil {
         log.Error(
             "Failed to make a connection.",
             zap.String("protocol", "tcp"),
             zap.String("target", target),
             zap.Error(err),
         )
         return err
     }
     defer conn.Close()
     return nil
 }

続いて,突発的なトラフィック急騰への対応も必要になります。ゲームサーバというものはイベントの開始・終了のタイミングや,日跨ぎ処理のタイミングでトラフィックがわずか数秒間に 3 倍にまで増えるということが毎日起きます。スケールアウトの高速化の工夫は色々と行いましたが,どれだけに高速化してもサーバ起動からサービス投入までに 3 分は要します。

そのため時間指定でのサーバの増設も必要になります。この機能もバッチ処理ではなくオートスケーリングの機能として折り込みました。現在は以下 (10 分間に 20 台ずつ,計 40 台増設する例) のようにコードで設定を書くようになっていますが,将来的には GUI を用意し,インフラメンバだけでなく開発者やビジネスサイドのメンバにも開放し,事前のキャパシティ増設をワンストップでできるようにしたいと考えています。

 launch => {
     amount        => 40,
     time_settings => [
         {
             from   => '05:50:00',
             to     => '05:59:00',
         },
         {
             from   => '06:00:00',
             to     => '06:09:00',
         }
     ]
 }

さて,オートスケーリングの安定化のための工夫をご説明してきましたが,想定外の出来事はどうしても起きます。そういう事態に備えて,オートスケーリングの不具合を早期に検知できるような監視を導入し,問題を検知したらインフラメンバにオンコールで通知することによって 24 時間 365 日即時対応できるような体制を整えています。ここまで至ることは稀ですが,仮に手動対応が必要になったとしても次回以降同じ問題が発生しないようにシステムを改修するということを繰り返し,現時点では相当高品質なシステムに仕上がりました。

最後に実際にオートスケーリングが稼働している様子をお見せします。図 1 からサーバ台数は日々大きく変動していることが分かる一方,図 2 からは CPU 使用率はほぼ一定となるように制御されていることが分かると思います。この結果,最終的に API サーバの費用は 30% 削減することができました。また,これまで手動で台数調整を行ってきましたが,その手間が不要になりましたので運用工数の削減にも大きく寄与しました。

図 1. サーバ台数 (IP Address 数) の推移

図 1. サーバ台数 (IP Address 数) の推移

図 2. API サーバ 1 台の CPU 使用率の推移 (赤: スケールアウト水準,青: スケールイン水準)

図 2. API サーバ 1 台の CPU 使用率の推移 (赤: スケールアウト水準,青: スケールイン水準)

スポットインスタンスへの挑戦

オートスケーリングの導入に加えて,インスタンスタイプの最新化なども一段落したタイミングで基盤が AWS のシステムにおいてはスポットインスタンス導入を進めていくことなりました。2018 年 8 月の下旬頃から仕様確認や実サービスへの導入方法の検討を本格的に始め,その 2 ヶ月後には実際に運用を開始していましたので,かなりのスピード感で進めていたことがお分かり頂けるのではないでしょうか。

実は計画当初,スポットインスタンスの活用は考慮に入れていませんでした。存在自体は認識していましたが,突然シャットダウンされるという話を聞いただけで,最高品質のインフラを提供するための基盤として利用する選択肢には入れられない,入れられたとしても負荷試験用途やワンショットのバッチ処理などサービスに直接影響が及ばない範囲内で,という考えが正直なところありました。しかし,オンデマンドインスタンスと比較すると非常に安価に利用できるという点はやはり無視できず,このタイミングで俎上に載ってきました。

実際に仕様確認を進めていくと,スポットの中断通知から実際にシャットダウンされるまでの 2 分間で完全にサービスから切り離すことさえできれば,あとは通常のインスタンス故障時の対応を自動化だけで品質を落とすことなく運用に落とし込めるということが分かりました。実際に導入を担当したメンバが「スポットインスタンス は高頻度で故障するインスタンスであると考えれば良い」と話をしていたのが印象的です。

また,オートスケーリングに比べて導入できる対象サーバが多いという点もスポットインスタンスの魅力でした。オートスケーリングの導入対象は,台数が非常に多いこと,負荷の変動が大きいこと,スケーリングの判断基準が明確であること,という大きく 3 つの条件を満たす必要があります。これらを満たさないと十分なコストメリットが得られず,オートスケーリングシステムの管理工数の方がかえって高くつくためです。一方スポットインスタンスであれば,ステートレスなサーバに対しては前述の仕組みさえ整えればコストメリットを得ることができます。最終的には API サーバだけでなく,Cache サーバや非同期処理用の Daemon サーバなどステートレスサーバのほぼ全てに対してスポットインスタンス を導入できました。

インスタンス管理の自動化はオートスケーリングのシステムでほぼできていましたので,2 分以内のサービスからの切り離し処理を教科書通りに実装し,まずは数台実際にサービスに投入してみるというところから導入を開始していきました。

ここから先,スポット率をどう上げていくかというところが一苦労でした。最終的にはセカンダリ IP を活用することで図 3 のように使用するプール数を大量に増やし,安定した運用に落とし込むことができたのですが (詳しくは冒頭の AWS Summit Tokyo 2019 の発表資料にまとめていますので,そちらをご参照下さい),そこに至るまでには様々な試行錯誤がありました。

spot-instance-pool.png

図 3. プールごとのスポットインスタンス数

例えば,異なるインスタンスタイプを混ぜて使うための方法は初めから MyDNS とセカンダリ IP で行こうと決められたわけではありません。インスタンスタイプごとにロードバランサも分け,DNS で重み付けすることよってトラフィックのコントロールを行う方法を検討したり,クラウドベンダに対してロードバランサの重み付けラウンドロビンの機能追加リクエストを出したりもしました。

また技術的な課題だけでなく,スポット率を上げて本当に問題ないかという懸念に対して問題ないと示す必要もありました。幸いにもこのケースにおいてはサービス影響が出る確率を評価することができたため,その定量評価によって関係者全員が納得した状態でスポット率を 100% に設定することができました。リスクの伴う変更を行う際はインフラチームのみの判断ではなく,開発者はもちろん事業部の方々にも十分説明をした上で進めることが重要です。

導入当初は 10% 程度だったスポット率も最終的には 100% まで引き上げることに成功し,ステートレスサーバのコストは 60% 削減することができました。また,スポット中断による障害は起きていないという点も特筆事項だと思います。

spot-instance-rate.png

図 4. スポットインスタンス使用率の推移

DB サーバの QCT マネジメント

DeNA が DB サーバとして MySQL を使用していることはご存知の方も多いと思いますが,クラウドにおいても変わらず MySQL を利用しており,なおかつマネージドサービスではなく IaaS 上に MySQL を立てて運用しています。ここでは DB サーバに対する施策について,ゲームサーバにおける DB サーバの負荷傾向について触れながらご説明します。

DB サーバはゲームのリリース当日から数週間程度 CPU,I/O ともに負荷が高い状態となりますが,特に書き込みがボトルネックになり,これをきちんと捌けるかどうかが安定リリースの要となります。この高負荷に対応するため,DeNA ではシャーディング (水平分割) を多用します。タイトルの規模感に合わせて調整しますが,多いものだとシャード数は 3 桁に及びます。また読み込みのスケーラビリティ確保のために,シャーディングされた DB はそれぞれ master-slave 構成を組んでいます。

一方,リリースからしばらく時間が経つとアクティブユーザの数がリリース当初よりは落ち着いてくるため,CPU 負荷も下がっていきます。他方,データは溜まり続けるため,I/O がボトルネックになるという傾向は変わりませんし,ディスクのサイズがネックになることもあります。

このようにリリースフェーズとその後の運用フェーズで大きく負荷傾向が変わってくる DB サーバの運用は非常に難しいです。ステートレスなサーバと違い,単純な台数調整やスペック調整を行うことが難しいからです。特に難しいのがシャーディングした DB のシュリンクです。一度シャードを広げてしまうと,その後の縮小は容易ではありません。しかし,容易ではないからといって放置するわけにもいきません。大量のシャードを運用し続けると膨大な費用が掛かります。したがってシャードの集約が必須になると同時に,どの程度までシャードを集約できるかがそのまま DB サーバのコストコントロールの成果に繋がります。

シャード集約におけるポイントは 2 つあります。

1 つ目は I/O 性能です。シャードを集約していくわけですから,例えば 2 つのシャードを 1 つに集約したら単純に I/O は 2 倍に増えるということになります。ただでさえ I/O がボトルネックであるのに,集約によってその傾向に拍車がかかるため,当然集約後のサーバに対しては高い I/O 性能が求められます。ネットワークストレージをマウントしたインスタンスではこの I/O を捌くのは難しく,私たちはローカルストレージを持つインスタンスを採用することにしました。AWS であれば i3 あるいは i3en インスタンスが,GCP であればローカル SSD をマウントしたインスタンスがこれに相当します。

ローカルストレージは高い I/O 性能を得られる一方で,インスタンスを再起動したり,インスタンス障害などでインスタンスが止まってしまうとデータが全て消えてしまいます。まさに諸刃の剣です。この問題に対しては,データを 4 重に持つことで対応することにしました。すなわち master 1 台に対して slave は必ず 3 台以上用意するということです。また,万一の自体に備えて MySQL のフルダンプを毎日取得し,クラウドストレージへ保存するという仕組みも整えています。

さて,高い I/O 性能は確保できたので次は 2 つ目のポイントである集約方法について考えていきます。普通にシャード集約を行うことを考えると,あるシャードに対して別なシャードのデータを流し込むというのが一般的な方法だと思います。実際に DeNA でも過去この方法を取っていたことがありました。しかしこの方法ではサービスの長時間の停止を伴うメンテナンスが必須になります。他の目的で実施されるメンテナンスに合わせて実施すれば良いと考えられる方もいらっしゃるかもしれませんが,データの流し込みには何時間も要するため,結局シャード集約のためにメンテナンス時間を延長する必要があります。

そこで私たちは 1 つの MySQL プロセスに対してデータを集約していくという方法は諦め,1 台のインスタンスに複数の MySQL プロセスを立てるという構成を取ることでシャード集約を実現しました。この方法は 1 台の物理サーバの性能を使い切るための方法としてオンプレ環境でも多用しています。

まずは 1 台のインスタンスに複数のプライベート IP アドレスをアタッチします。

 $ ifconfig
 eth0      Link encap:Ethernet  HWaddr 02:E1:0C:0A:6E:8A
           inet addr:10.228.155.252  Bcast:10.228.155.255  Mask:255.255.252.0
           inet6 addr: fe80::e1:cff:fe0a:6e8a/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1
           RX packets:1999977249 errors:0 dropped:0 overruns:0 frame:0
           TX packets:4789699563 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000 
           RX bytes:2036044138753 (1.8 TiB)  TX bytes:6290789751880 (5.7 TiB)

 eth0:ae49853 Link encap:Ethernet  HWaddr 02:E1:0C:0A:6E:8A
           inet addr:10.228.152.83  Bcast:10.228.155.255  Mask:255.255.252.0
           UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1

 eth0:ae49922 Link encap:Ethernet  HWaddr 02:E1:0C:0A:6E:8A
           inet addr:10.228.153.34  Bcast:10.228.155.255  Mask:255.255.252.0
           UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1

 eth0:ae49af9 Link encap:Ethernet  HWaddr 02:E1:0C:0A:6E:8A
           inet addr:10.228.154.249  Bcast:10.228.155.255  Mask:255.255.252.0
           UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1

 eth0:ae49bd4 Link encap:Ethernet  HWaddr 02:E1:0C:0A:6E:8A
           inet addr:10.228.155.212  Bcast:10.228.155.255  Mask:255.255.252.0
           UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1

次に,各プロセスに対する MySQL の設定ファイルを用意し,以下のようなスクリプト (実際に私たちが使っているスクリプトを簡略化して記載) で MySQL プロセスを起動します。

 sub start_mysql {
     my ($hostname, $mysqld_opts) = @_;
     my $pid = fork();
     unless ($pid) {
         close STDIN;
         close STDOUT;
         close STDERR;
         exec "/usr/bin/mysqld_safe --defaults-file=/etc/my-$hostname.cnf $mysqld_opts &";
         exit;
     }
 }

すると以下 (ps auxf の結果を整形) のように複数の MySQL プロセスが起動している状態になります。

 root   /bin/sh /usr/bin/mysqld_safe --defaults-file=/etc/my-ae49853.cnf
 mysql    \_ /usr/sbin/mysqld --defaults-file=/etc/my-ae49853.cnf --basedir=/usr --plugin-dir=/usr/lib64/mysql/plugin --user=mysql ...
 root   /bin/sh /usr/bin/mysqld_safe --defaults-file=/etc/my-ae49922.cnf
 mysql    \_ /usr/sbin/mysqld --defaults-file=/etc/my-ae49922.cnf --basedir=/usr --plugin-dir=/usr/lib64/mysql/plugin --user=mysql ...
 root   /bin/sh /usr/bin/mysqld_safe --defaults-file=/etc/my-ae49af9.cnf
 mysql    \_ /usr/sbin/mysqld --defaults-file=/etc/my-ae49af9.cnf --basedir=/usr --plugin-dir=/usr/lib64/mysql/plugin --user=mysql ...
 root   /bin/sh /usr/bin/mysqld_safe --defaults-file=/etc/my-ae49bd4.cnf
 mysql    \_ /usr/sbin/mysqld --defaults-file=/etc/my-ae49bd4.cnf --basedir=/usr --plugin-dir=/usr/lib64/mysql/plugin --user=mysql ...

後は集約前の master から上記で起動した MySQL プロセスに対してレプリケーションをつなぎ,master を切り替えていくだけです。DeNA では MHA を利用して MySQL の master 切り替えをオンラインで実施できるようにしていますので,メンテナンスなしでのシャード集約が可能です。

この方法を用いることで,DB サーバの数を最大 75% 削減することに成功したタイトルもありました。また,メンテナンスなしでシャード集約を行える方法が確立したことで,今後はリリース初日は DB サーバに十分なキャパシティを持たせるためにあえて最初から数百から数千のシャードを用意しておき,負荷の様子をみながら無停止でシャードを集約していくという運用が可能になりました。

これまでは DB サーバのシャード集約の難しさや維持コストの高さから,必要最低限のシャード数でリリース当日を迎えることがほとんどでしたが,こうしてしまうと万一予想を上回るトラフィックが押し寄せてしまった場合は長期間の障害は免れませんでした。したがって,今回ご説明した運用方法は超大規模ゲームタイトルの安定リリースに大きく貢献し,なおかつコストも速やかに削減することができる非常に優れた方法であると言えると思います。

最後に

今回は主にオートスケーリング,スポットインスタンス,DB サーバの運用に焦点を当ててこの 1 年間の取り組みについてご紹介させて頂きました。QCT 全てを高い水準で満たすために様々な工夫をしているというところを少しでも感じ取って頂けましたら幸いです。技術的な詳細はかなり省略した箇所もありましたが,その内容については今後他メンバからご紹介させて頂く予定ですので,もっと具体的な話にご興味をお持ちの方は引き続き本ブログをご覧下さい。

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

DeNA の AWS アカウント管理とセキュリティ監査自動化

こんにちは、IT 基盤部髙橋です。
DeNA が提供するエンタメ系やヘルスケア系のサービスのインフラを見ており、そのグループのマネージャをしています。
先日 AWS Loft Tokyo で DeNA における AWS セキュリティについて発表してきたので、発表では述べられなかった具体的な設定についていくつか記載します。

presentation.jpg

DeNA の AWS アカウント管理とセキュリティ監査自動化 from DeNA

AWS アカウント管理

AWS アカウント管理を効率的に行うために、スライドの中でいくつかの施策を挙げています。 その中の一部をコマンド例を交えて紹介します。

AWS Organizations を利用したマルチアカウント管理

AWS Organizations の特徴としては以下のようなものが挙げられます。

  • アカウントの一元管理
    • OU (Organization Unit) を用いた階層的なグループ化も可能
  • 一括請求 (Consolidated Billing)
    • アカウントの請求と支払いを統合
  • リザーブドインスタンスの共有
    • 他のアカウントで購入したリザーブドインスタンスを共有することができる
  • サービスコントロールポリシー (SCP) の利用
    • Organization 配下の各 AWS アカウント (メンバーアカウント) の権限を指定できる

また AWS Organizations を利用すればコマンドで AWS アカウントを作成することが可能になります。 連絡先情報やクレジットカード情報は Organization マスターアカウントの情報が引き継がれます。
--role-name には作成されるアカウントへの AdministratorAceess 権限を持つロール名を指定します。デフォルトでは以下に記載している通り OrganizationAccountAccessRole という名前になります。 --iam-user-access-to-billing には IAM ユーザーに請求情報へのアクセスを許可する場合は ALLOW を、拒否する場合は DENY を指定してください。

 aws organizations create-account \
     --email ${EMAIL} \
     --account-name ${ACCOUNT_NAME} \
     --role-name OrganizationAccountAccessRole \
     --iam-user-access-to-billing ALLOW

 

 {
     "CreateAccountStatus": {
         "RequestedTimestamp": 1564398749.614, 
         "State": "IN_PROGRESS", 
         "Id": "car-01234567890abcdefghijklmnopqrstu", 
         "AccountName": "sample-account1"
     }
 }

アカウント作成の状況は以下のコマンドで確認することができます。 State の値が SUCCEEDED になるまで定期的に監視すれば、後続の作業も自動化できます。

 aws organizations describe-create-account-status \
     --create-account-request-id ${ACCOUNT_ID}

 

 {
     "CreateAccountStatus": {
         "AccountId": "123456789012", 
         "State": "SUCCEEDED", 
         "Id": "car-01234567890abcdefghijklmnopqrstu", 
         "AccountName": "sample-account1", 
         "CompletedTimestamp": 1564398812.234, 
         "RequestedTimestamp": 1564398749.696
     }
 }

AWS アカウント作成時の初期設定や設定変更方法の整備

AWS アカウントを作成するときには同時に各アカウントに必要な初期設定もしています。 aws sts assume-role コマンドを利用して設定先アカウントの AdministratorAccess 権限を取得します。 ACCOUNT_ID には上記の出力結果から得られたものを入れます。 --role-session-name は権限を得たロールのセッションの識別子のようなものでここでは適当な値を入れておきます。

 aws sts assume-role \
     --role-arn arn:aws:iam::${ACCOUNT_ID}:role/OrganizationAccountAccessRole \
     --role-session-name "RoleSession1"

上記コマンドで得られた情報から AccessKeyId SecretAccessKey SessionToken の値を以下のように環境変数に設定します。

 export AWS_ACCESS_KEY_ID=ABCDEFGHIJKLMNOPQRST
 export AWS_SECRET_ACCESS_KEY=abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMN
 export AWS_SESSION_TOKEN=abcdefghijk...<remainder of security token>

まず以下のようにして作成しようとしているロールが存在するか判定します。 ROLE_NAME には作成したいロールの名前を入れてください。

 aws iam get-role --role-name ${ROLE_NAME}

IAM ロールがまだなければ作成をします。 --assume-role-policy-document で信頼関係の内容を記載した json 形式のファイルを指定します。

 aws iam create-role --role-name ${ROLE_NAME} \
     --assume-role-policy-document file://path/to/${ROLE_NAME}-Trust-Policy.json

次に IAM ポリシーの作成をします。 POLICY_NAME には作成したいポリシーの名前を入れてください。 --policy-document でポシリーの内容を記載した json 形式のファイルを指定します。 path/to/${ROLE_NAME}-Policy.json には適切なファイルパスを指定してください。

 aws iam create-policy --policy-name ${POLICY_NAME} \
     --policy-document file://path/to/${ROLE_NAME}-Policy.json

作成した IAM ロールに先ほど作成した IAM ポリシーをアタッチします。

 aws iam attach-role-policy --role-name ${ROLE_NAME} \
     --policy-arn arn:aws:iam::${ACCOUNT_ID}:policy/${POLICY_NAME}

このようにして初期設定に必要なロールやポシリーの作成を繰り返し行います。 その他初期設定として CloudTrail の設定やそのログを保管する S3 Bucket の作成なども DeNA では行っています。

全 AWS アカウントの設定変更に関しては、上記で述べた各アカウントに存在する OrganizationAccountAccessRole を使い、同じように aws sts assume-role をして設定変更を行います。 AWS Organizations を使えば全 AWS アカウントのリストを取得することも可能なので、これで取得できた全アカウントに対して操作するようなものを書けばよいでしょう。

 aws organizations list-accounts

 

 {
     "Accounts": [
         {
             "Name": "sample-account1", 
             "Email": "sample-email@dena.jp", 
             "Id": "123456789012", 
             "JoinedMethod": "CREATED", 
             "JoinedTimestamp": 1536059567.45, 
             "Arn": "arn:aws:organizations::123456789013:account/o-abcdefghij/123456789012", 
             "Status": "ACTIVE"
         }, 
         {
             "Name": "sample-account2", 
             "Email": "sample-email2@dena.jp", 
             "Id": "123456789013", 
             "JoinedMethod": "CREATED", 
             "JoinedTimestamp": 1536059568.45, 
             "Arn": "arn:aws:organizations::123456789000:account/o-abcdefghij/123456789013", 
             "Status": "ACTIVE"
         }, 
         ...
     ]
 }

IAM ユーザー管理

発表の中では社内ディレクトリで管理されるフェデレーティッドユーザーを利用した AWS マネジメントコンソールログインの方法について説明しました。

ID フェデレーションによる AWS マネジメントコンソールログイン

下記は踏み台アカウントから各サービスのアカウントに Switch Role を利用してロールの切り替えを行う図ですが、この時の各アカウントに存在するロールのポリシーと信頼関係について解説します。

aws-management-console-login-by-id-federation.png

踏み台アカウントにある step-service-account1-admin ロールのポリシーは以下のようにしています。

 {
     "Version": "2012-10-17",
     "Statement": {
         "Effect": "Allow",
         "Action": "sts:AssumeRole",
         "Resource": "arn:aws:iam::*:role/service-account1-admin"
     }
 }

踏み台アカウントにある step-service-account1-admin ロールの信頼関係は以下のようにしています。
STEP_ACCOUNT_ID には踏み台アカウントのアカウント ID を入れてください。 SAML_PROVIDER_NAME には作成した SAML プロバイダの名前を入れてください。

 {
   "Version": "2012-10-17",
   "Statement": [
     {
       "Effect": "Allow",
       "Principal": {
         "Federated": "arn:aws:iam::${STEP_ACCOUNT_ID}:saml-provider/${SAML_PROVIDER_NAME}"
       },
       "Action": "sts:AssumeRoleWithSAML",
       "Condition": {
         "StringEquals": {
           "SAML:aud": "https://signin.aws.amazon.com/saml"
         }
       }
     }
   ]
 }

各サービスアカウントにある service-account1-admin ロールのポリシーは以下のようにしています。(ここでは AdministratorAccess 権限となっています。)

 {
     "Version": "2012-10-17",
     "Statement": [
         {
             "Effect": "Allow",
             "Action": "*",
             "Resource": "*"
         }
     ]
 }

各サービスアカウントにある service-account1-admin ロールの信頼関係は以下のようにしています。 STEP_ACCOUNT_ID には踏み台アカウントのアカウント ID を入れてください。

 {
   "Version": "2012-10-17",
   "Statement": [
     {
       "Effect": "Allow",
       "Principal": {
         "AWS": "arn:aws:iam::${STEP_ACCOUNT_ID}:role/step-service-account1-admin"
       },
       "Action": "sts:AssumeRole"
     }
   ]
 }

上記は AdministratorAccess 権限についての設定例ですが、ReadOnlyAccess やカスタマイズした権限ももたせることが可能になっています。

AWS セキュリティ監査自動化

発表では AWS セキュリティ監査自動化システムの実装例としていくつか述べました。 ここではさらにどのようなコマンドを使って判定するかを具体的に書いていきたいと思います。

ルートユーザーに対して MFA を有効化すること

概要: 認証情報レポートでルートユーザーに対して mfa_active の値が true であるか確認します

まずはレポートの生成をします。

 aws iam generate-credential-report

 

 {
     "State": "STARTED", 
     "Description": "No report exists. Starting a new report generation task"
 }

次に生成したレポートを取得します。

 aws iam get-credential-report

取得された内容は Base64 エンコードされているのでデコードする必要があります。 <root_account> の行で mfa_active の値が true であれば MFA が有効であることになります。

 user,arn,user_creation_time,password_enabled,password_last_used,password_last_changed,password_next_rotation,mfa_active,access_key_1_active,access_key_1_last_rotated,access_key_1_last_used_date,access_key_1_last_used_region,access_key_1_last_used_service,access_key_2_active,access_key_2_last_rotated,access_key_2_last_used_date,access_key_2_last_used_region,access_key_2_last_used_service,cert_1_active,cert_1_last_rotated,cert_2_active,cert_2_last_rotated
 <root_account>,arn:aws:iam::123456789012:root,2018-06-20T13:38:27+00:00,not_supported,2019-07-02T09:23:21+00:00,not_supported,not_supported,true,false,N/A,N/A,N/A,N/A,false,N/A,N/A,N/A,N/A,false,N/A,false,N/A
 ...

IAM で利用が完了し使われてないアクセスキーは無効化・削除すること

概要: list-users でユーザ一覧を出し、 list-access-keysStatusActive なものの中で、 get-access-key-last-used から得られる LastUsedDate が特定の期間内であるか確認します

まずは list-users で IAM ユーザ一覧の情報を取得します。

 aws iam list-users

 

 {
     "Users": [
         {
             "Arn": "arn:aws:iam::123456789012:user/sample-user1",
             "UserId": "ABCDEFGHIJKLMNOPQRSTU",
             "CreateDate": "2018-07-23T09:37:10Z",
             "UserName": "sample-user1",
             "Path": "/"
         },
         {
             "Arn": "arn:aws:iam::123456789013:user/sample-user2",
             "UserId": "ABCDEFGHIJKLMNOPQRSTV",
             "CreateDate": "2018-08-01T11:51:47Z",
             "UserName": "sample-user2",
             "Path": "/"
         },
         ...
     ]
 }

次に list-access-keysStatus の情報を取得します。 --user-name には上記で取得できたユーザー名を指定します。

 aws iam list-access-keys --user-name sample-user1

 

 {
     "AccessKeyMetadata": [
         {
             "AccessKeyId": "ABCDEFGHIJKLMNOPQRST", 
             "Status": "Active", 
             "CreateDate": "2019-01-09T08:15:14Z", 
             "UserName": "sample-user1"
         }, 
         {
             "AccessKeyId": "ABCDEFGHIJKLMNOPQRSU", 
             "Status": "Active", 
             "CreateDate": "2019-07-29T16:35:35Z", 
             "UserName": "sample-user1"
         }
     ]
 }

最後に --access-key-id でアクセスキー ID を指定してそのキーの LastUsedDate を求めます。得られた LastUsedDate が特定の期間内であるか確認します。

 aws iam get-access-key-last-used --access-key-id ABCDEFGHIJKLMNOPQRST

 

 {
     "AccessKeyLastUsed": {
         "Region": "us-east-1", 
         "LastUsedDate": "2019-01-09T10:52:00Z", 
         "ServiceName": "iam"
     }, 
     "UserName": "sample-user1"
 }

ELB のアクセスログを有効化すること

概要: describe-load-balancer-attributesaccess_logs.s3.enabled の値が true であるか確認します

aws elbv2 コマンドを使います。 --load-balancer-arn には情報を取得する LB の ARN を指定します。

 aws elbv2 describe-load-balancer-attributes --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/sample-alb1/abcdefghijklmnop

以下のように色々な値が取れます。今回は access_logs.s3.enabled の値を確認します。

 {
     "Attributes": [
         {
             "Value": "false", 
             "Key": "access_logs.s3.enabled"
         }, 
         {
             "Value": "", 
             "Key": "access_logs.s3.bucket"
         }, 
         {
             "Value": "", 
             "Key": "access_logs.s3.prefix"
         }, 
         {
             "Value": "60", 
             "Key": "idle_timeout.timeout_seconds"
         }, 
         {
             "Value": "false", 
             "Key": "deletion_protection.enabled"
         }, 
         {
             "Value": "true", 
             "Key": "routing.http2.enabled"
         }
     ]
 }

RDS でインターネットからのアクセスが不要な場合はパブリックアクセシビリティを無効にすること

概要: describe-db-instancesPubliclyAccessiblefalse であるか確認します

aws rds コマンドを使います。 --db-instance-identifier には DB の識別子を指定します。

 aws rds describe-db-instances --db-instance-identifier sample-db1

PubliclyAccessible の値が false であれば問題ないです。(かなり多くの情報が取れるので省略します。)

 {
     "DBInstances": [
         {
             "DBInstanceIdentifier": "sample-db1", 
             "AvailabilityZone": "ap-northeast-1a", 
             "DBInstanceClass": "db.m5.large", 
             "BackupRetentionPeriod": 7, 
             "Engine": "mysql", 
             "PubliclyAccessible": true, 
             ...
         }
     ]
 }

おわりに

以上、DeNA での AWS アカウント管理とセキュリティ監査自動化について説明してきました。 DeNA ではこれまで以上に大規模に AWS を利用していくために、セキュリティレベルの高い状態をより効率的に構築管理できる方法を日々考えています。

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

DeNAインフラノウハウの発信プロジェクトを始めます

20190801_blog_1.jpg はじめまして.DeNA システム本部IT基盤部 部長の金子です. IT基盤部は,DeNA全グループの全てのシステム基盤を横断して管理しているインフラ部門です.

DeNAは様々な事業分野にチャレンジし,多種多様なサービスを展開しています. IT基盤部では,その全てのサービス/システムの成功を支えていくために,インフラ部門として,日々様々な技術的なチャレンジを繰り返しています.

  • システムのクオリティ
  • システムのコスト
  • システムのデリバリー

これらの一見,両立/鼎立が非常に難しい3つの要素,この全てで世界最高の水準を達成することが目標です.

  • システムを24時間365日,安定して動かし「続ける」ためには何が必要なのか
  • 数十万リクエスト/秒のトラフィックや,PBクラスのデータを取り扱うには,どのようなインフラ構成が必要になるのか
  • システムの基盤やアーキテクチャはどのような基準で選択すべきなのか
  • システムの運用コストを1円でも安くするためには何をすればよいのか

DeNA創業から20年間,IT基盤部では常にこのような課題にチャレンジし続け,技術的ノウハウを多く蓄積してきました.

また,昨年2018年の6月に,今までシステム基盤のメインとして使ってきたオンプレミス環境を,全てpublicクラウド環境へ移行させることを意思決定し,プロジェクトを開始しています. プロジェクト名は「クラウドジャーニー」,略して「C-Jプロジェクト」と呼んでいます. 現在,このC-Jプロジェクトも順調に進められており,ここでも新たなノウハウが数多く生まれてきています.

このように,技術的なチャレンジを数多く行い,世界にも誇れるノウハウを蓄積してきた IT基盤部なのですが,今まではそのノウハウをあまり多く発信してきてはいませんでした.

そのような中,ここ最近は外部のカンファレンスやセミナーで登壇する機会を頂くことが増え,自分達のチャレンジから得た学びやノウハウを発信してみたところ,非常に多くの方々からご好評を頂き,また多くの方々から詳細についてお問い合わせも頂きました.

20190801_blog_2.jpg

このように多くのリアクションを頂けることは,純粋にエンジニアとしてのモチベーションになります.そしてなにより,この学びやノウハウをより多くの方々と共有し,みなさまに更に使い倒していただくことによって,みなさまと更にエンジニアリングの高みを目指すことができれば,エンジニアとしてこれに勝る喜びはないと思います. そして,DeNAに少しでも興味を持って頂けるキッカケにもなれば嬉しいと考えています.

そこで,本日から来年の4月までの間のほぼ毎週,我々IT基盤部のメンバがそれぞれの業務で得たノウハウを,このDeNAエンジニアブログにて発信していきたいと思います.

担当者の業務都合により,もしかしたら記事を出せない週もあるかもしれませんが,なにとぞ暖かく見守って頂けますと幸いです.

これから約1年間,我々のノウハウをできるだけ多くの方々にお届けできるよう頑張っていきますので,応援のほど,どうぞよろしくお願いします.

20190801_blog_3.jpg

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

コンピュータビジョンの最新論文調査 Object Tracking 編

はじめに

こんにちは、AIシステム部でコンピュータビジョン研究開発をしている唐澤(@Takarasawa_)です。 我々のチームでは、常に最新のコンピュータビジョンに関する論文調査を行い、部内で共有・議論しています。今回はObject Tracking編として唐澤 拓己が調査を行いました。

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

論文調査のスコープ

2018年11月以降にarXivに投稿されたコンピュータビジョンに関する論文を範囲としており、その中から重要と思われるものをピックアップして複数名で調査を行っております。今回は主にObject Tracking技術に関する最新論文を取り上げます。

Object Tracking の位置付け

Object Tracking とは物体追跡という意味で、動画中で変化・移動していく物体を追跡するタスクです。動画中の物体を認識する上で基本的なタスクといえ、様々な応用面がありながらも、未だにチャレンジングなタスクとして存在しています。

Object tracking は、動画像中で指定されたひとつの物体を追跡する Single Object Tracking(SOT)、複数の物体を同時に追跡する Multiple Object Tracking(Multi-Object Tracking、MOT)に大別され、与えられる動画像の時間(フレーム数)が短いもの(Short-term)と長いもの(Long-term)でさらに異なるアプローチが取られることが多いように感じます。動画像の長さによりアプローチが異なるのは、時間が長い動画像においてある物体を見失った際(見失ったあとの全ての時間を失敗とみなされるため)低い評価を得てしまうことに起因して occlusion(物体が他のものに隠れてしまうこと)への対策等に重きが置かれるためだと思われます。

今回の論文紹介では最も中心的な、Short-term の SOT タスクに対して提案されている論文を紹介いたします。(以下、Object Tracking とはこのタスクのことを指して述べます。)

前提知識

Object Tracking

動画像と、その動画像の初期フレームにおける物体の位置が矩形(bounding box)として与えられ、次フレーム以降の同一物体の位置を bounding box として検出するタスクです。

このタスクの難しい点は、追跡する中で対象物体の外観が未知の状態へ変化していくこと(照明条件の変化や物体そのものの変形、見えない側面への視点の変化など)と、追跡中に生じる occlusion や他物体の交わりなどの外的影響に大別される印象です。また、物体検出との大きな違いとして基本的にクラスに依存しない物体全般へのタスクでありつつ、同クラスであっても異なる物体かの判断が必要な繊細な検出であることが挙げられるかと思います。

また、動画タスクの需要のひとつとして精度だけでなくリアルタイム性が重視されることが多く、速度と精度のバランスについてはよく議論される内容です。

アプローチ

Object Tracking に対して深層学習を用いた近年の主要なアプローチに、対象物体に対してオンライン学習を行うCorrelation Filter 系アプローチ、オフラインで汎用的な類似性マップを出力するための学習を行うSiamese Network 系アプローチがあり、今回紹介する論文に関わりが深いためそれぞれ概要を紹介いたします。他にもそれらを複合的に使用したものや物体検出タスクと併せてタスクを解くアプローチなど手法は多岐にわたります。

参考:https://github.com/foolwood/benchmark_results/

Correlation Filter 系アプローチ

Correlation Filter系アプローチは、基本的には与えられた目標画像(target template)に対してオンライン学習を行うことでターゲット特有の追跡モデルを獲得するアプローチのひとつで、得られた目標画像から正例と負例のサンプリング、それらのデータを用いて目標画像特有の識別器を学習、という流れであることが一般的です。オンライン学習により目標画像特有の識別器を学習するアプローチは比較的昔からある手法で、識別器に Boosting や SVM を用いる手法も存在します。その中で特にCorrelation Filter 系アプローチは、探索画像(search region)において物体に該当する場所をフィルタにより畳み込み演算を行った時に大きな値となるように学習を行います。

物体周辺からランダムサンプリングされていた従来手法に対して、このアプローチではまずピクセル単位でシフトさせることで密にサンプリングを行います。密にサンプリングされた画像群は巡回行列として扱うことができ、フィルタを用いた巡回行列に対する畳み込み演算(巡回畳込み)は、離散フーリエ変換を用いて簡単に計算できるという特性を用いて高速なオンライン学習を実現しています。(畳み込み演算と CNN などに用いられる畳み込み(convolution)は厳密には異なる計算です。)

現在は学習済み識別モデルにより得られた複数解像度の特徴マップに対してフィルタの学習を行うことが主流となっています。また、オフライン学習との複合的なアプローチも見られます。

Siamese Network 系アプローチ

Siamese Network 系アプローチは、Object Tracking の問題を、目標画像(target template)から抽出される特徴表現(feature representation)と探索画像(search region)から抽出される特徴表現間の、相互相関(cross-correlation)により得られる汎用的な類似性マップ(similarity map)を学習することで解決を図ります。

ネットワーク構造は以下の図のように2つのネットワークで構成されており、Siamese Networkとはこの特徴的な2つのネットワークで構成される構造を指し、Object Trackingタスクでなくても用いられる言葉です。一方のネットワークは目標画像から、他方のネットワークは探索画像から特徴マップを抽出し、目標画像から抽出された特徴マップを用いて探索画像から抽出された特徴マップを畳み込むことで類似性マップを獲得します。応答マップ(response map)と呼ばれることもあります。学習の際は類似性マップが正解となるように学習を行い、追跡の際は類似性マップを元に追跡を行います。

このアプローチの基本となる手法として、SiamFC(ECCV2016 workshop)[1] と SiamRPN (CVPR2018)[2] の2つの手法が存在します。SiamFC はより直感的な考え方で、類似性マップは正解の存在する場所のグリッドの値が大きくなるように学習されます。SiamFCはこのアプローチが類似性マップを計算する処理も畳み込み(convolution)で表現されるため全体の構造が fully convolutional(FC)であることに名前が由来しています。他方で SiamRPN は、物体検出手法の代表的な手法のひとつである Faster R-CNN 中で使用されている物体候補領域を予測する region proposal network(RPN)を参考に、各グリッドに bounding box の基準となるアンカーを設定し、各グリッドは、各アンカーの物体らしさとアンカーの bounding box の正解への座標と幅と高さへの補正値を出力するように学習します。基本的には後者のほうが精度が良くなる傾向にあります。これらの2つの手法の提案された年代から、まだこれらの Object Tracking 手法の発達が浅いことがわかります。

SiamFC アーキテクチャ図。各特徴量を共通のネットワークφを用いて取得し、畳み込みを行うことで類似性マップを出力しています。( [1] より引用)

tracking_b.png

SiamRPN アーキテクチャ図。SiamFC と同様に Siamese Network を通したあと region proposal network のように物体らしさを出すブランチと bounding box の回帰を行うブランチにより結果が出力されます。( [2] より引用)

全体的な特徴として、Correlation Filter系アプローチと異なり基本的にはオフラインで学習を行い追跡時には重みを固定することが多いため(追跡時に学習を行わないため)、近年の高精度な手法らの中では追跡速度が速いことがあげられます(参考)。他方で欠点としてオンラインで目標画像の学習を行っていないため、目標物体と類似した物体のような紛らわしいものという意味のディストラクタ(distractor)に弱いことがよく述べられます。現在ではディストラクタなどの問題に対処するためオンライン学習をとりいれた手法や、特にディストラクタ認知モジュール(distractor-aware module)を備えた DaSiamRPN(ECCV2018)[3] などの手法も提案されており DaSiamRPN は今回紹介する CVPR2019 の論文中でも state-of-the-art として比較されることが多い手法となっています。

Siamese Network 系アプローチは Object Tracking のリアルタイム性の需要から、精度と速度のバランスの良さについて言及されることが多く、近年発達してきており今回紹介する論文も大半がこちらです。

参考文献

[1] Luca Bertinetto, Jack Valmadre, João F. Henriques, Andrea Vedaldi, Philip H.S. Torr. "Fully-Convolutional Siamese Networks for Object Tracking." ECCV workshop (2016)

[2] Bo Li, Wei Wu, Zheng Zhu, Junjie Yan. "High Performance Visual Tracking with Siamese Region Proposal Network." CVPR (2018 Spotlight)

[3] Zheng Zhu, Qiang Wang, Bo Li, Wu Wei, Junjie Yan, Weiming Hu."Distractor-aware Siamese Networks for Visual Object Tracking." ECCV (2018)

関連するデータセット

  • OTB(object tracking benchmark)2013, 2015:VOTと共にデファクトスダンダートとされるデータセット
  • VOT(visual object tracking)2013〜18:ICCV/ECCVで毎年開催されるコンペで公開されるデータセット。ICCV2019もコンペ開催中。
    • 2014から bounding boxが回転したものを用いられるようになった。(通常は画像軸と平行な bounding box)
    • 2018から long-termのデータセットも導入
  • LaSOT(large-scale single object tracking):最も新しく導入されたデータセット(ECCV2018)
  • 他に TrackingNet(2018)、UAV123(2016)など。

動画の長さと動画数についての各データセットのプロット(LaSOTより引用)

tracking_c.png

評価指標

  • AUC(area under curve):正解とみなす overlap の threshold を変化させてできる precision の変化をプロットした際の曲線の下側の面積(area under curve)。いずれの threshold でも precisionが大きいほうが良いため大きいほうが良い。
  • Robustness:VOTで使用される評価指標。追従中に overlap が0になってしまったときを追従失敗とみなし、1つの動画シーケンスに対して何回追従失敗するか。
  • EAO(expected average overlap):VOTで使用される評価指標。accuracy と robustness を組み合わせた概念。複数動画長の各条件で追跡のoverlapの平均を算出し、それを全条件にて平均したスコア。ただしこの時追跡失敗後の overlapは全て0とみなされる。

論文紹介

【SiamMask】 "Fast Online Object Tracking and segmentation: A Unifying Approach"(CVPR 2019)

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

要約

従来の SiamFC, SiamRPN に Mask を出力するブランチを追加し、object tracking と semi-supervised video object segmentation を同時に解く SiamMask を提案。また、併せて segmentation mask を用いて適切な bounding box を付与することで tracking のスコア自体も向上。

提案内容

  • 従来の SiamFC, SiamRPN に Mask を出力するためのブランチを追加することで、object tracking と semi-supervised video object segmentation を同時に解く SiamMask を提案
  • Siamese network において Target template と Search region からそれぞれ抽出される feature map 間の畳込み演算は depth-wise convolution を採用し、multi-channel の response map を使用する。(従来は通常の畳込みを行い single-channel の response map が出力される。)

全体のArchitecture

(a)three-branch 構造. SiamRPN は元々2つのブランチが存在するためこちらに該当。 

(b)two-branch 構造. SiamFC は元々が1つのブランチしか存在しないためこちらに該当。

  • *d の部分が depth-wise convolution.
  • Mask ブランチにおける hφ は1x1 conv を2つ重ねた2 laye rの conv net。mask は各グリッドで直列化された状態で表現される。

tracking_d.png

(画像は本論文より引用)

Mask ブランチのアウトプットから Mask 画像への Upsampling

  • 高解像度レベルの特徴マップを取り入れて refinment しつつ Upsampling を行う

tracking_e.png

(画像は本論文より引用)

Upsampling の際、高解像度を取り入れる部分の詳細 Architecture(図は U3 について)

tracking_f.png

(画像は本論文より引用)

Mask ブランチからアウトプットされるスコアマップ

  • 各グリッドに該当グリッドを中心としたTarget画像サイズのMaskが格納される

tracking_g.jpg

(画像は本論文より引用)

Bounding box の付与方法。Box ブランチによる出力も行われるが、Maskを用いてより詳細な回転を含む適切な bounding boxの付与を付与する。

  • 赤: Min-max 通常の画像軸に平行な外接矩形。
  • 緑: minimum bounding rectangle(MBR)。segmentation mask を包含する bounding box の中で最小となる box の選択。
  • 青: *従来研究で提案された optimization によりえられる bounding box。ただし計算コストが非常に大きい。
*M. Kristan, et al. The visual object tracking vot2016 challenge results. (ECCV  2016)

tracking_h.png

(画像は本論文より引用)

学習に使用する損失関数

  • g は depth-wise convolution。
  • h は Mask ブランチ. m はそれにより出力される mask。

tracking_i.png

  • yn は ±1。RoW(各グリッドのこと)が mask 部分に該当するかどうか。
  • yn がポジティブ(1+yn は yn がネガティブなときに0)な RoW に対してのみ全ピクセルについて binary logistic regression loss を算出して総和を取る。

tracking_j.png

  • 2ブランチのときと3ブランチの時の全体の損失。mask 以外に関しては通常の SiamFC、SiamRPN のロスでsimはsimilarity mapのロス、score, box はRPNのそれぞれのロスを表す。λ は影響度の調整を行うハイパーパラメータ。

tracking_k.png

実験結果

VOT-2016, VOT-2018 を用いて visual object tracking の評価。

bounding box の付与の仕方の違い。(VOT-2016)

  • 比較対象の oracle の表記は ground truth 情報を用いたもので、各手法のスコアの上限の評価に相当しているとのこと。
    • Fixed:アスペクト比を固定した場合の ground truth。SiamFC に対応。
    • Min-max:画像軸並行の制約条件。SiamRPN に対応。
    • MBR:SiamMask に対応。
  • 従来の手法は ground truth が回転された bounding boxでありながら、画像軸に平行な bounding box を出力している。
  • binary mask を使用するだけで画像軸に平行な bounding box の出力に対して大幅な差をつけられる。

tracking_l.png

(表は本論文より引用)

他手法との比較

  • SiamMask:3ブランチ(SiamRPNの拡張)
  • SiamMask-2B:2ブランチ(SiamFCの拡張) 
  • 従来手法に対して大きな差で上回る。

tracking_m.png

(表は本論文より引用)

Siam RPN++: Evolution of Siamese Visual Tracking with Very Deep Networks (CVPR 2019 oral)

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

要約

Siamese network 系アプローチのバックボーンは従来 AlexNet 等モデルであり、ResNet 等のモデルでは精度が落ちることが知られている。それを学習時にターゲットが中心に偏らないサンプリング方法で対処し、multi-layer の類似度マップ、depth-wise な畳み込みを用いて深いモデルの良さをさらに発揮するモデルを提案。

提案内容

  • Siamese network 系アプローチのためのサンプリング方法の提案(spatial-aware sampling strategy)
    • Response map による追従では双方の特徴の不変性(translation invariance)が必要。
    • 他方で深いネットワークは、ネットワークを深くするために padding が多く含まれており、これが translation invariance を崩している。
    • また通常、学習の際に response map の中央にターゲットが来るような学習がされており、そのため translation invariance が崩れているネットワークでは中心に response がでやすくなるバイアス(center bias)が学習されてしまっている。
    • これに対して学習のサンプリングの際にランダムに適切な大きさの shift を行う spatial-aware sampling strategy を提案。
  • 深いモデルをさらに効果的に使用するため multi-layer の類似度マップを使用する multi-layer aggregation を提案。
    • tracking は粗い特徴から細かい特徴まで見るべきだが、従来はネットワークが浅かったため有効に利用できていなかった。
  • depth-wise cross correlation filter の使用。(SiamMaskと同一の提案)
    • Up-channel していた SiamRPN に比べ、パラメータの数が減り、パラメータの数のバランスがよくなるとのこと。
    • 学習の収束が容易となる。

spatial-aware sampling strategy

  • 学習時のサンプリングの際にランダムなshiftを加えて学習を行った結果。rand shift range はランダムな shiftの範囲の最大値。
  • データセットごとに適切なshift(VOTの場合、±64)が存在することを指摘。

tracking_n.png

(図は本論文より引用)

multi-layer aggregation

  • 各層の特徴マップから得られる response mapは重みづけて総和。 tracking_o.png
  • (画像は本論文より引用)
    tracking_p.png

depth-wise cross correlation layer と従来の cross correlation layer との違い。

(a) SiamFCにおける cross correlation layer 

(b) SiamRPNにおける cross correlation layer 

(c) 提案された depth-wise cross correlation layer 

tracking_q.png
(画像は本論文より引用)

実験結果

OTB2015データセットを用いてバックボーンによる精度の比較。

  • 横軸は ImageNetに対する分類精度を表す、top1 accuracy on ImageNet(論文中では top1 accuracyとあるが図は top1 errorとあり記述ミス。)
  • 分類タスクと同じ傾向でバックボーンによる精度向上を行えるようになったことが示唆される。 tracking_r.png
(グラフは本論文より引用)

multi-layer、depth-wise correlation に関する ablation study。

  • depth-wise cross correlationは全体的に精度向上に寄与。
  • multi-layerに関しては、
    • 2種の組み合わせ:いずれの組み合わせでも精度向上してほしいが、conv4独立に勝ててるのはconv4, 5の組み合わせのみ。
    • 3種の組み合わせ:最も良い精度となり multi-layer aggregationの有効性を示唆。

tracking_s.png

(表は本論文より引用)

depth-wise cross correlation による response mapの出力の図示

  • tracking はクラス依存しないタスクであるが、クラスごとに反応する response mapが異なる。

tracking_t.jpg

(画像は本論文より引用)

他手法との比較

  • 精度に関しては上昇しているが、その反面robustnessは下がる。

tracking_u.png

(表は本論文より引用)

速度と精度との比較

  • mobile netにも適用

tracking_v.png

(グラフは本論文より引用)

他データセット、UAV123, LaSOT, TrackingNetへも実験を行っており、また、VOT2018 long-termへのtracking performanceについても論文中では実験され比較されている。

Deeper and Wider Siamese Networks for Real-Time Visual Tracking (CVPR 2019 Oral)

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

要約

Siamese network系アプローチのバックボーンは従来 AlexNet 等モデルであり、ResNet 等のモデルでは精度が落ちることが知られている。その原因を詳細に解析し、Paddingの悪影響を対処する新モジュールの提案をメインとした、deep/wide なモデルを提案する。

提案内容

  • 分析:Siamese network系アプローチの(ResNetやInceptionなどへの)バックボーンの単なる置換の際のパフォーマンスの低下に関する詳細な定量的分析、(特にpaddingに対する)定性的分析。
    • stride、最終層におけるreceptive field、出力するfeature mapのサイズに対する詳細な分析。それを踏まえたネットワーク構造へのガイドラインの提示。
    • 特にPaddingでは、Siamese networkで response map を出力する際のpadding付近の他部分に対する一貫性のなさを定性的に指摘。
  • 新しいResidual モジュールの提案:従来の residual unit や inception module からpadding の影響する部分をクロッピングした Cropping-Inside Residual (CIR) Units 等の提案。
    • Cropping-Inside Residual (CIR) Units
    • Downsampling CIR (CIR-D) Units
    • CIR-Inception Units
    • CIR-NeXt Units
  • ネットワークの提案: receptive field size、 strideの分析とともに、CIR Unitモジュールを含めたネットワークを提案

Cropping-Inside Residual (CIR) units、Downsampling CIR(CIR-D)units

(a)通常の residual unitの構造:3層の conv layer + skip connection。 

(a')CIR unitの構造:residual unit の出力後、padding の影響を受ける部分をクロッピングする。

b)通常の down sampling residual unitの構造:skip connection部分についても conv の stride を2にして down sampling される。 

(b')CIR-D unitの構造:residual unit の内部では down sampling せず、出力後(a')と同様に padding の影響を受ける部分をクロッピングしたあと、maxpooling によって down sampling するようにする。

tracking_w.png

(画像は本論文より引用)

他モジュール図

  • Inceptionモジュール、ResNeXtについても同様にクロップするモジュールを提案。

tracking_x.png

(画像は本論文より引用)

response mapの可視化

  • 左上がpaddingバイアスの小さいような物体が中心に位置している状況。
  • 左上以外について従来のresnetアーキテクチャでは適切に検出できていない。

tracking_y.png

(画像は本論文より引用)

実験結果

OTB-2015、VOT-2016、VOT-2017を用いて評価。

ベースラインである AlexNet をバックボーンとした場合との比較。

  • いずれもベースラインの精度を提案手法が上回る。

tracking_z.png

(表は本論文より引用)

ベースラインである AlexNet のバックボーンを ResNet と単に置換した場合と提案手法との精度比較。

  • 実際に単に置換した場合では、 AlexNet の場合より悪くなるが、提案手法では精度が向上している。

tracking_aa.png

(画像は本論文より引用)

他手法との比較

tracking_bb.png

(表は本論文より引用)

ATOM: Accurate Tracking by Overlap Maximization(CVPR 2019)

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

要約

従来のオンラインで学習される target classifier では高次な知識を要する複雑なタスクには限界があることを指摘し、それに加え、高次な知識をオフラインで学習する target estimator を組み合わせることで正確な tracking を実現。

*IoU-Netの前提知識を多く用いるため、IoU-Netの論文についても後に紹介する。

提案内容

物体検出タスクで提案された、検出された bounding box と ground truth の IoU(Intersection over Union)を予測する IoU-Net、それにより予測されたIoUを目的関数とし、IoU が最大となるように refinementを行う手法を tracking に応用し、target estimator を構築する。

target estimator

  • IoU-Net はクラス依存なしで汎用的に行うことは難しく、現論文では class ごとにモデルの学習を行っている。
  • そのため、IoU-Netの入力に target image を特徴として加えることで target 特有の IoU-Net となるように学習を行う。
    • modulation based network を追加することで、target image の特徴は modulation vector として付加させる形で取り入れる。

target classifier

  • target 画像に対してオンラインで学習し、targetかどうかの分類を行う。出力は 2D グリッドマップ。
  • conv の2層構造で、オンライン学習のため Gauss-Newton法と、Conjugate Gradientを組み合わせて解く。

オフライン学習済み target estimator と target classifier のオンライン学習を組み合わせた Tracking の流れ

  1. target classifier の適用。粗く target の存在する場所を特定する。
  2. 候補領域の生成。confidence が最大となる座標、ひとつまえの bounding box の幅と高さから最初の候補領域を生成する。このとき局所最適を避けるため一様分布のノイズを加えて10通りの候補領域を生成する。
  3. IoU-Net ベースのリファインメントを行なった後、IoU スコアが高い3つの bounding box を平均してtracking 結果とする。
  4. 結果を用いてオンライン学習により target classifier を更新する。

テスト時の全体図

  • IoU predictor は reference image(target image)を modulation vector として取り入れる。
  • Classifier はターゲット画像に対してオンラインで学習がされている。

tracking_cc.png

(画像は本論文より引用)

全体のアーキテクチャ詳細図

tracking_dd.png

(画像は本論文より引用)

実験結果

他手法との定性的な実験結果の比較

  • DaSiamRPN は先にも紹介した Siamese network 系アプローチの最も良いとされる手法。UPDT はcorrelation filter に基づく手法。
  • UPDT は target state estimation コンポーネントがないためアスペクト比が異なるものを扱えない。
  • DaSiamRPN は bounding box regression を採用しているが変形や回転に弱い。

tracking_ee.jpg

(画像は本論文より引用)

様々なデータセットによる比較。全てのデータセットで最も良い精度となっている。

  • NFS、UAV

tracking_ff.png

(グラフは本論文より引用)

  • Tracking Net

tracking_gg.png

  • LaSOT

tracking_hh.png

  • VOT2018

tracking_ii.png

(表は本論文より引用)

【IoU-Net】 "Acquisition of Localization Confidence for Accurate Object Detection"(ECCV 2018)

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

*先に紹介した ATOM に与える影響が非常に大きいため紹介。

要約

通常のCNNベースの物体検出手法は classification confidence は出力されるが、localization の confidence については出力されず物体検出の confidence として乖離があることを指摘。検出された bounding box と ground truth の IoU を予測する IoU-Net を提案する。

提案内容

  • 検出された bounding box と ground truth の IoU を予測する IoU-Net を提案
    • 出力される IoU = localization confidence を得ることができる。
  • 予測したIoUを利用したIoU-guided NMSを提案。
  • 予測したIoUを目的関数とした、最適化ベースの bounding box refinement 手法を提案
    • この中で、refinement を行うための、出力に対して bbox の座標を用いて微分可能な Precise RoI Pooling を提案。

classification scoreとlocalization scoreの不一致についての具体例

tracking_jj.jpg

(画像は本論文より引用)

IoU-Net アーキテクチャ 

  • RPNで検出される RoIに 小さい揺らぎを与え IoU を ground truth として IoU ブランチを学習。

tracking_kk.png

(画像は本論文より引用)

IoU-guided NMS

  • classification score でなく、localization confidence の高いものから優先した NMS(non-maximum suppression)。
  • 通常の NMS と同様に thresholdを超えて重複ボックスを消す際は、classification scoreは高い方を採用する。
  • 要するに結果として、 NMS で bounding box をマージする際、localization confidence, classification confidence の良い方を互いに採用し、bounding box は loacalization confidence が高いものを採用するということ。

tracking_ll.png

Optimization-based bounding box refinement

  • localizaton confidence score が最大となるように、勾配を用いて bounding box の座標の補正を行う。
  • そのため 出力に対して bbox の座標を用いて微分可能な Precise RoI Pooling を提案。

Precise RoI Pooling

  • bilinear でfeature map を補完して連続値の座標に対して特徴量の値を定義。その後連続座標に対して(average poolingの場合でいえば)積分して面積で割ることでpoolingを行う。

tracking_mm.png

(画像は本論文より引用)

おわりに

今回は Object Tracking という分野におけるコンピュータビジョンに関する最新論文をご紹介しました。 冒頭でも述べましたが、Object Tracking はまだまだ発達途上な印象を受けます。今回紹介した Siamese network 系アプローチについても、ResNet 等のバックボーンの使用が Oral に取り上げられており、深いモデルによる特徴抽出の恩恵を享受することの難しさが分野の共通認識として存在していたことが感じ取られます。とはいえまだまだこれからも発達し様々な場面で利用されてくると考えられます。DeNA CVチームでは引き続き調査を継続し、最新のコンピュータビジョン技術を価値あるサービスに繋げていきます。

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

CVPR 2019参加レポート

はじめに

皆さんこんにちは。DeNA AIシステム部の李天琦(leetenki)です。 DeNAのAIシステム部では、物体検出、姿勢推定、アニメ生成等、様々なComputer Vision技術の研究開発に取り組んでいます。また、AIシステム部では世界の最新技術トレンドにキャッチアップするために、年一回国際会議に自由に参加できる機会が設けられています。 今回は、アメリカ ロングビーチで開かれたComputer Visionに関する世界トップの国際会議の一つである「CVPR 2019」に、AIシステム部コンピュータビジョンチームのメンバー7名 (加藤直樹、葛岡宏祐、洪嘉源、鈴木智之、中村遵介、林俊宏、李天琦)で参加してきましたので、その内容について紹介したいと思います。また、今回は聴講としてだけでなく、DeNAからコンペ入賞も一件あり、DSチームの加納龍一と矢野正基の2人が発表してきたので、その様子についても紹介したいと思います。

なお、今回のレポートは加納龍一、洪嘉源、林俊宏、矢野正基、李天琦の5名で協力し執筆しています。

CVPR2019とは

CVPRの正式名称は「Computer Vision and Pattern Recognition」で、ECCV、ICCVと並ぶComputer Vision分野における世界三大国際会議の一つです。ちなみにComputer Visionというのは人間の視覚をコンピュータを用いて表現することを目指した技術分野で、画像や映像認識技術全般を指しています。そのComputer Visionの分野において世界三大国際会議の一つがこのCVPRです。そして近年ではDeep Learningを始めとするAI技術の飛躍的な進歩により、あらゆるComputer Vision分野でDeep Learningを使うことが当たり前になってきているので、CVPRでもDeep Learningの手法を応用した論文が大半を占めるようになりました。

cvpr2019_schedule.png

今年の開催期間は6/16〜6/20の5日間です。最初の2日は特定のテーマに絞ったTutorial & Workshopで、後半の3日間がMain Conferenceです。また、Main Conferenceの3日間では、Expoと呼ばれるスポンサー企業の展示会も並行して行われ、世界をリードするIT企業の最新の研究成果や製品などが展示されました。

開催場所

今年の開催場所はアメリカカリフォルニア州のロングビーチで、Long Beach Convention & Entertainment Centerという、北アメリカ最大級のイベント施設を貸し切って会議が開かれました。会場の立地も良く、ロングビーチの海が一望できる最高のリゾート地でした。

longbeach_conference_center.jpg

[ 会場のLong Beach Convention & Entertainment Center ]

参加統計

近年AI技術への注目の高まりを受けて、CVPR参加者は年々増加し、今年は参加者も採録論文数も過去最高となりました。統計によれば、今年の投稿論文数は5160本で、採録論文数は1294本でした。そして今回のCVPR参加人数は9227人と、CVPR 2018の時と比べて1.5倍以上にものぼっています。ここ数年の増加率があまりにも高すぎて、「このまま増え続ければ2028年には投稿論文数100億本になる」と主催者も冗談交じりに話していました。

CVPR2019参加者統計.png

[ 参加者の統計 ]

参加者の国別統計.png

[ 参加者の国別統計 ]

CVPR2019投稿論文数の統計.png

[ 投稿論文数の統計 ]

セッションの様子

CVPRに採録された論文のうち、評価の高かったものはOralと呼ばれる口頭発表形式のセッションで発表されます。例年であれば、論文の内容に応じて発表時間が長いLong Oralと短いShort Oralに更に分割されますが、今年は論文数があまりにも増えすぎたために全て発表時間5分のShort Oralとなりました。また、Oralを含めた全採録論文はPosterセッションで展示され、そこでは著者と直接ディスカッションを行うことができます。

CVPR2019_Oralセッション会場.jpg

[ Oralセッションの様子 ]

ネットワーキングイベント

Main Conference期間中、初日の夜に立食形式の「Welcome Dinner」と、2日目の夜に「Reception Party」という2つの公式ネットワーキングイベントが開催されました。Reception Partyでは、会場付近のEntertainment Centerを貸し切ってのお祭りが行われ、世界各国の研究者達と親睦を深めることができました。

CVPR2019_Reception_Partyの様子.jpg

[ Reception Partyの様子 ]

キーワード分析

今年採録された論文のタイトルから、頻出キーワードを抽出してみたところ、以下の結果となりました。特に3Dや、Detection、Attentionなどを取り扱った論文が多いことがここから読み取れます。 頻出キーワード統計.png

[ 頻出キーワード統計 ]

これ以外にも、現地で実際によく目についたキーワードとして、unsupervised、 self-supervised、 weakly-supervised、few-shot、zero-shot、NAS(Neural Architecture Search) 、adversarial examples等が多い印象でした。 実際にCVPR2013〜CVPR2019の7年間で、各年の採録論文数全体に対するキーワードを含む論文数の比率をグラフ化してみました。確かに○○supervisedや○○shotといった、データやアノテーションが限定された問題設定の論文が全体的に増加傾向にあることがここから見てわかります。

キーワードの推移1.png

[ キーワードの推移1 ]

同様に、ネットワーク構造を自動で探索するArchitecture search系の論文や、なんらかのモデルを騙すための攻撃 & 防御を扱ったadversarial examples等の論文も増加傾向にあることがわかります。その他にもいくつか増加傾向にあるキーワードを下図に示します。

キーワードの推移2.png

[ キーワードの推移2 ]

受賞論文

今回CVPR2019で発表された論文の中で、受賞されたものをいくつか紹介します。

A Theory of Fermat Paths for Non-Line-of-Sight Shape Reconstruction

まず、CVPR2019 Best Paperに選ばれたのが、こちらの"A Theory of Fermat Paths for Non-Line-of-Sight Shape Reconstruction" (Shumian Xin et al.) です。

NLOS物体復元.png

[ NLOS物体復元 ]

Non-Line-of-Sight(NLOS)物体というのは、カメラなどの視界に直接映らない(撮影できない)物体のことを指します。それらのNLOS物体に対して、周辺環境での反射などを利用して画像化や形状復元する技術をここでは扱います。例えば、曲がり角の向こうにある物体を見ることや、厚い分散媒質を通して物体を透視することなどがこれに当てはまります。NLOS技術は、自動運転、遠隔センシングや医用画像処理など様々なシーンで応用することができるため、コンピュータビジョン領域でも徐々に注目を集めています。今回のCVPR2019では、NLOS に関する論文はBest Paperを含めて6本も採録されています(Oral: 3, Poster: 3)。

提案手法概要図.png

[ 提案手法概要図 ]

この論文ではNLOS物体を測定するために、高速変調光源と時間分解センサー(time-resolved sensors)を使用しています。時間分解センサーは光子の数とカメラに到達する時間を測定することができ、トランジェントカメラ(transient camera)と呼ばれます。NLOS物体からの光子を直接トランジェントカメラで観測することはできませんが、付近の可視表面で反射した光子を受信することで、その不可視の物体を探知することが可能になります。この論文では、可視表面とNLOS物体の間の光のフェルマーパス(Fermat paths of light)に関する理論を提唱しています。著者のXinらは、フェルマーパスがトランジェント測定値の不連続点と対応することを証明しました。さらに、これらの不連続点が対応するフェルマーパスの長さの空間微分とNLOS物体表面の法線と関連する制約条件を導き出しています。これに基づいて、視線範囲外の物体の形を推測するアルゴリズムFermat Flowを提案し、初めて幾何的な制約条件だけを利用して精確にNLOS物体の3D表面を復元することに成功しています。

Learning the Depths of Moving People by Watching Frozen People

次はHonorable Mentionを受賞した2本の論文のうちの1つである"Learning the Depths of Moving People by Watching Frozen People" (Li, et al.) を紹介します。

提案手法の概要図2.png

[ 提案手法概要図 ]

こちらの論文ではRGB入力からの人の深度推定を扱っています。Kinectのようなデバイスは屋外では使えないということもあり、これまで様々な姿勢・シーン・年齢などをカバーした大規模データセットはありませんでした。この論文では、2016年後半からYouTubeで一大ブームになったマネキンチャレンジの動画に着目して、それら約2,000本の動画から大規模データセットを構築し、それを使ってモデルを学習しています。ちなみに、マネキンチャレンジというのは人が様々なポーズをした状態でマネキンのように静止し、そこをカメラが移動しながら撮影するというものです。マネキンチャレンジの動画では人を静止物として扱えるため、SfM (Structure from Motion), 及び MVS (Multi-View Stereo) の技術により人の深度を推定でき、それを教師としたデータセットを構築できます。最終的に学習されたモデルの性能も素晴らしいですが、それ以上にマネキンチャレンジ動画に目をつけてデータセットを作るというアイディアが光っており、とても興味深い論文です。

A Style-Based Generator Architecture for Generative Adversarial Networks

最後は、Honorable Mentionを受賞した2本の論文のうちのもう1つである "A Style-Based Generator Architecture for Generative Adversarial Networks" (Tero Karras, et al.) を紹介します。

StyleGANの概要図.png

[ StyleGANの概要図 ]

こちらの論文は1024×1024の高解像度な画像生成を扱ったものです。Style-Transfer等でよく使われるAdaINのアイデアを取り入れることで、より制御しやすく、狙った生成を可能にしています。本論文の著者であるTero Karrasさんは、先行研究として以前にICLR2018でPGGAN (Progressive Growing of GANs) を発表しています。そちらの論文では、GANの生成学習において、段階的にネットワーク層を増加させ、生成画像の解像度を徐々に上げていくことで、安定的に高解像度な生成を実現しています。本論文はその基礎の上で、更にGenerator部分に工夫を施し、潜在表現ベクトルzをGeneratorの最初ではなく、Mapping Networkを通じてAdaINのパラメータとしてネットワークの途中途中に埋め込んでいます。 解像度ごとに異なる潜在ベクトルzを埋め込むことで、coarse(姿勢、顔の形)、middle(髪型、目)、fine(髪質、肌色)といった、異なるレベルのstyleを分離して制御できるようになっています。また、上記AdaINとは別に、ランダムノイズを各特徴マップに足し合わせることで、生成画像の確率的な要素(髪の流れ方や肌のシワ等)の操作を可能にしています。

StyleGANの生成例.png

[ StyleGANの生成例 ]

このような高解像度な画像生成を、教師なし学習で、かつStyleを制御可能にできたことが本論文の最大のContributionです。

DeNAのPoster発表

今回、Tutorial & Workshopと並行して開催された、「iMet Collection 2019」という美術品の画像識別コンペにて、DeNAのDSチームから加納龍一と矢野正基の2人が参加し、金メダルを獲得することができたので、Poster発表を行いました。

iMet_Collection_2019のPoster発表の様子.jpg

[ iMet Collection 2019のPoster発表の様子 ]

こちらのコンペでは、ニューヨークのMetropolitan美術館でデジタル化されている約20万枚の美術品の画像を用いて、作品の内容や文化的背景などの観点からつけられたタグ付けを予測する多クラス分類問題の精度が競われます。今回金メダルを受賞したDeNAの加納龍一と矢野正基のチームでは、Pseudo labelingやBlendingといった従来のコンペで実績を残している手法に加え、CVPR2019に採録されたAttention Branch Networkという新しい技術を導入していくことで、金メダルを獲得することができました。

全体の感想

今回、DeNA AIシステム部から7名でCVPR2019に参加し、各自のスペシャリティを活かした効率的な情報収集を行いました。今回発表されたOralプレゼンテーションは全て、こちらのYouTubeチャンネルでも公開されていますが、実際に現地に行くことで論文の気になる点を作者に直に聞けたり、ネットワーキングもできる等のメリットがあります。自分は今年で3度目となるCVPR参加ですが、技術的な収穫はもちろん、ネットワークも広がって凄く良い刺激になりました。

また、今回のEngineer Blogとは別に、現地に参加したメンバーで、注目度の高い論文や有益性の高いと判断した論文30本を厳選し、解説資料 (Slide Share) にまとめて公開しましたので、興味ある方はそちらも合わせてお読みください。

DeNA CVチームでは引き続き調査を継続し、最新のコンピュータビジョン技術を価値あるサービスに繋げていきます。

参考文献

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

コンピュータビジョンの最新論文調査 キーポイントによる物体検出編

はじめに

こんにちは、AIシステム部でコンピュータビジョンの研究開発をしております本多です。 我々のチームでは、常に最新のコンピュータビジョンに関する論文調査を行い、部内で共有・議論しています。今回我々が読んだ最新の論文をこのブログで紹介したいと思います。

今回論文調査を行なったメンバーは、林 俊宏、本多 浩大です。

論文調査のスコープ

2018年11月以降にarXivに投稿されたコンピュータビジョンに関する論文を範囲としており、その中から重要と思われるものをピックアップして複数名で調査を行っております。今回はキーポイント検出の手法を用いた物体検出に焦点を当て、最新論文を取り上げます。

Short Summary

  • CornerNet (ECCV18) の改良版と言える、キーポイント検出ベースの物体検出手法が続々と提案されている。
  • いずれも検出ターゲット矩形の端や中央を、ヒートマップを用いて検出する手法である
  • Single-shot型 (bottom-up) とTwo-stage型 (top-down) に分かれる
  • いずれもCornerNetと同等ないし高い精度を示している
  • Object as Points (CenterNet) の精度と速度のトレードオフ性能 (speed-accuracy trade-off) の高さが目立つものの、他手法とフェアな比較はできていない

図1は本稿で取り上げる各手法の検出点比較である。
fig1.png

図1: 各手法の検出点比較。(a) Faster R-CNNやYOLOなどアンカーを基準にboxを学習する手法 (b) CornerNet (c) Objects as Points (CenterNet) (d) CenterNet: Keypoint Triplets for Object Detection (e) Bottom-up Object Detection by Grouping Extreme and Center Points (f) Grid R-CNN

前提知識

物体検出

画像から物体の位置を矩形 (bounding box) として検出し、かつそれぞれの物体の種類(クラス)を分類するタスクです。

  • Faster R-CNN: 画像から特徴マップを抽出し、Region Proposal Networkで物体の存在する領域を検出、それぞれクロップしてHead Networkにて詳細な位置推定とクラス分類をおこなう。物体検出のデファクトスタンダード。
  • Feature Pyramid Network (FPN) : Faster R-CNNにおいて、複数のスケールでRegion ProposalおよびHead Networkの実行を行うことで、高精度に小さな物体を検出する。
  • RetinaNet : FPNにおけるRegion Proposal Network部において、bounding boxの位置検出とクラス分類を完結することで高速化をはかっている。Single-shot検出器と呼ばれ、YOLOと同種の検出器にあたる。

キーポイント検出を用いた物体検出

 今回、キーポイント検出の手法を物体検出に用いている論文を取り上げます。これら論文の源流となるのはECCV2018で発表されたCornerNetです。

  • CornerNet : bounding boxの座標を回帰によって学習するのではなく、左上と右下隅をキーポイントと見立てたヒートマップを学習する。人物姿勢認識におけるキーポイント検出にヒントを得ている。推定されたキーポイントは、embedding vectorの照合によりグルーピングする。
  • Hourglass Network : ResNetなどのネットワークでスケールダウンしながら特徴抽出したのちに、アップサンプリング層によってスケールアップする、砂時計型のネットワーク。

関連するデータセット

MS-COCO 物体検出・セグメンテーション・人物姿勢等のラベルを含むデータセットで、recognition系のタスクではデファクトスタンダード。

参考:弊社エンジニアによるサマリー。本稿で取り上げる論文も紹介されている。
最近の物体検出
CVPR 2019 report

性能比較

今回紹介する4論文と、ベースラインとなるCornerNet及びRetinaNetとの性能比較を表1に示す。全ての論文をフェアに比較することは困難であるが、いずれも単一スケールでのテストに揃えて比較した。特に性能にインパクトがあると思われる実験条件をbackbone、他条件に記載した。

keypoint-table1.png 表1: COCO test-devによる各手法の性能比較。

論文紹介

Objects As Points

要約

bounding box中心のみをヒートマップで予測、大きさ・オフセット・クラスは各位置で回帰、速度と精度の良いトレードオフを実現する。

提案手法

クラスごとにbounding box中心をヒートマップとして学習する。Backboneは高速側から、ResNet18+upsampling, DLA34 [2], ResNet101, Hourglass104を用いている。upsamplingレイヤとしてbilinear inetrpolationとconvolutionを用いている。single-scale の高解像度特徴マップをヒートマップ出力に使う。

各グリッドではクラスごとの確率に加え, bounding boxサイズ及びグリッドからのオフセットを回帰学習する(図A1)。推論時は、各グリッドの近傍8グリッドと比較して最大または等しいconfidence値となる100のグリッドをピックアップする 。ピックアップされた複数のアンカーを用いるYOLOv3と異なり、アンカーが存在せず、bounding boxサイズを直接、クラス毎に出力する。

Lossの定義は

  • ヒートマップ:CornerNet と同様、 focal loss の亜種を用いる。
  • 中心のオフセット:L1 loss
  • bounding boxサイズ:L1 loss

bounding boxのサイズ・オフセット推定チャンネルをタスクに応じて変更することで、3D bounding boxの推定や人姿勢推定にも適用できる(図A2)。

その他 Non-Maximum Suppression (NMS) を行っても精度が大きく変化しなかったため不使用。 ResNetとDLAでは、deformable convolutionレイヤをupsampling部に用いている。deformableレイヤはAP向上に寄与していると思われるが、本論文ではablation studyは行われていない。

結果

backbone 等の変更により精度-速度(レイテンシ)のトレードオフを測定、YOLOv3などの従来手法よりもトレードオフが改善した(図A3)。COCO test-devの評価では、高精度側でもCOCO AP=42.1 (single scale test) を示した(表A1)。

keypoint-d1.png 図A1:CenterNet手法の紹介。centerキーポイントの特徴としてbounding boxのサイズなどを学習させる([1]より引用)

keypoint-d1.png 図A2:CenterNetの様々なタスクへの応用。上段:物体検出 中段:3D物体検出 下段:キーポイント検出([1]より引用)

keypoint-d1.png 図A3:backboneネットワークやテスト条件を変化させたときの、推論時間とCOCO val APのトレードオフ。([1]より引用)

keypoint-d1.png 表A1:COCO test-devによるstate-of-the-art検出器との比較評価結果。上がtwo-stage、下がone-stage検出器。APが二種類記載されているものは、single-scale / multi-scale test を表す。([1]より引用)

リンク

[1] https://arxiv.org/abs/1904.07850
[2] DLAネットワーク:Deep Layer Aggregation

CenterNet: Keypoint Triplets for Object Detection

要約

CornerNet の改良版であり、コーナーだけでなく中心も予測することで正確性を向上する。

提案手法

CornerNetによって検出されたbounding boxには誤検出が多く、正解との重なり (IoU) が5%の条件においても32.7% がFalse Detectionとなっていた。一方2-stage detectorのようにROI poolingを用いると計算量が大きくなる。本論文では、図B1のように、CornerとCenterを照合することにより検出の正確性を向上する。また、CornerとCenterの3点のembedding情報のみをpoolingするため、ROI poolingのように計算量が大きくならない。

cascade corner pooling CornerNetで提案されているcorner pooling を、 bbox の端だけでなく内部も見るように cascade poolingとして改良する(図B2)。得られたembedding情報はcornerのグルーピング、およびオフセット推定に用いる。

center pooling CornerNetに対し、boxの中心を予測するheadネットワークを追加、corner pooling同様のcenter poolingによってembedding情報を得る(図B2)。このembedding情報は、cornerと異なりグルーピングには使用せず、中央点のオフセット推定にのみ用いる。

Loss lossは以下のように定義される。CornerNetにて提案されているlossに対し、中央点の項が追加されている。 eq_b1.png

Inference時 Cornerのペアから予想される領域にCenterがあるかどうかでTripletを組み合わせる。

結果

CornerNet と同条件 (Hourglass101, single scale) で比較すると、COCO APが40.5 -> 44.9と大きく改善している(表B1)。 keypoint-d1.png 図B1 : CenterNetの全体構成図。上段がCornerブランチ、下段がCenterブランチ、最終的に統合する。([3]より引用)

keypoint-d1.png 図B2 : Center Pooling(左)、Corner Pooling(中央)、およびCascaded Corner Pooling(右)([3]より引用)

keypoint-d1.png 表B1 : COCO test-devによるベンチマーク結果。CenterNet511はsingle-scale testにおいて COCO AP = 44.9となっている([3]より引用)

リンク
[3] https://arxiv.org/abs/1904.08189

Bottom-up Object Detection by Grouping Extreme and Center Points

要約

画像中の複数オブジェクトの上下左右の端点及び中央をヒートマップで求め、上下左右点と中央点を照合することでボトムアップでboxをグルーピングする。

提案手法

  • Ground truthとして、bounding boxだけではなくinstance segmentation labelを用いる。boxとsegmentationマスクから、上下左右の端点と中央の正解座標を求める。
  • Hourglassネットワークで画像全体から上下左右点・中央点のヒートマップを学習する(図C1)。
  • 推論時には、上下左右点の組み合わせごとに、該当する中央点があるかどうかを照合し、スコアが高い場合にグルーピングする(図C2)。
  • 端点と中央点を照合するという発想は、上述のCenterNet: Keypoint Triplets for Object Detectionと類似している。

結果

COCO test-devの結果、single scale同士だとCornerNetと同等のAP=40.2であり、multi-scaleではCornerNetを上回るAP=43.7となった(表C1)。 推論時に、端点を利用した多角形表示をすることも可能である(図C3)。

keypoint-d1.png 図C1: 推定フレームワーク。([4]より引用)

keypoint-d1.png 図C2: 推定された上下左右・中央のヒートマップから、bounding boxを決定するまでの流れ。([4]より引用)

keypoint-d1.png 表C1: COCO test-devでの結果。SS=single scale test, MS=multi-scale test。SS同士ではCornerNetと同等のAPとなっている。([4]より引用)

keypoint-d1.png

図C3: 推論結果。([4]より引用)

リンク
[4] https://arxiv.org/abs/1901.08043

Grid R-CNN

要約

2ステージ物体検出において、box座標をRegressionするかわりに、Boxのグリッド点をヒートマップで学習する。

提案手法

図D1のように、入力画像に対してbackboneネットワークで特徴抽出、Region Proposal NetworkおよびROIAlignでROIクロップをおこなう。ここまではMask R-CNNと同じである。

grid prediction branch:クロップしたfeature map (14 × 14) に対し、8層のdilated convolution層、および2層のdeconvolution層を経て、56 x 56 x (N x N) のfeature mapを得る。N x N はグリッドの点数であり、標準は3 x 3である。Ground Truthは正解グリッド点を中心とする+型の5画素がpositiveとされており、推定されたヒートマップとのBinary Cross Entropy Lossにより学習される。
アップデート版として公開されたGrid R-CNN plus [6]では、56 x 56のうち、実際にグリッド点が存在する28 x 28のみに限定して用い、またdeconvolutionをdepth-wiseとすることで高速化をはかっている。

feature fusion module(図D2):隣接するgrid点には空間的相関がある。feature fusion moduleでは隣のgrid点を用いてgrid featureを修正する。Fiを注目するgrid点のfeatureとすると、近隣のFjに対しいくつかの5x5 convolution層を通し、Tj->i(Fj)を作る。Fiとそれらの和を最終的なgrid featureとする。
推定時は、得られた各グリッドヒートマップにおいて、最大値をとる座標がピックアップされて元画像にマッピングされる。

結果

ResNeXt-101 Feature Pyramid Networkを用いた場合、COCO test-dev APが43.2となった(表D1)。 Faster R-CNNと同条件で比較すると、特に高IoUのAP (IoU=0.8 and IoU=0.9)において10%程度の改善となった。

keypoint-d1.png 図D1 Grid R-CNNのパイプライン。([5]より引用)

keypoint-d1.png 図D2 Feature Fusion Moduleの説明図。([5]より引用)

keypoint-d1.png 表D1: COCO test-dev評価結果。([5]より引用)

リンク
[5] https://arxiv.org/abs/1811.12030
[6] Grid R-CNN plus: https://arxiv.org/abs/1906.05688

おわりに

今回はキーポイント検出の手法を用いた物体検出の最新論文をご紹介しました。ECCV2018で提案されたCornetNetを皮切りに、キーポイントベースの物体検出が洗練されてきました。「物体をboxで検出する」というタスクの本質に迫っており、興味深いアプローチです。DeNA CVチームでは引き続き調査を継続し、最新のコンピュータビジョン技術を価値あるサービスに繋げていきます。

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

de:code 2019 CD07 AWS 技術者向け Azure サーバレス

はじめに

am 8:45 の時点で行列になっていると聞いて出遅れたことを悟り、家からのライブストリーミング配信から始まった de:code 2019。

もったいないかもしれないですが、AWS re:invent や Google Cloud Next などでも基調講演は基本的にリモートから見るようにしています。(字幕、腰、トイレ的な観点で)

ということで、Microsoft de:code 2019 に初めて参加してきました。システム本部技術開発室の放地宏佳です。

自分は普段、社内でクラウドアーキテクトをしており、GCP 及び AWS を活用したアーキテクチャを考えています。

今回、普段クラウドを触っている人間として、「CD07 AWS 技術者向け Azure サーバーレス」を聞いて、他社クラウドを触っている人がどのようなことを感じ取ったかについてお話できればと思います。

免責事項となりますが、僕自身は Azure を普段触っておらず、また、セッション情報以上に各サービスの詳細には調べておりませんので、事実とは異なることがあることご了承ください。

資料の公開があるとのことでしたが、残念ながらサインインした状態でしか資料を見れないようです(6/14時点)

decode:2019 のマイページより「セッション資料及び動画の閲覧」から 「CD07」 を検索することで資料を見ることが可能です。

セッションについて

こちらの「CD07 AWS 技術者向け Azure サーバーレス」のセッションについては、主に Azure Functions を中心に、その周辺を取り巻くサービスについての説明がありました。

スライドにも記載されていますが、主に AWS Lambda からの差分・注意点・学習ポイントについて説明されているものです。

アーキテクチャを選定するにあたって必要な情報がまとまっており、また、開発者に寄り添った内容で、Azure Functions の便利機能を説明されており、技術選定をする人は是非確認するべき内容だと感じました。

以降 PDF のページにそってお話させていただきます。

p5-p10 「サーバレスアーキテクチャ」

サーバレスを用いて構築するアプリケーションについてのまとめをされています。

AWS Lambda と Azure Functions の利用用途が一緒であることを述べて、同じレイヤーで話せることを一番始めに定義されています。

このように俯瞰的なまとめ、また具体的なサービス含めていることから、これ以降のスライドがとてもわかり易くなっています。

また、サーバレスを知らない人にとっても、サーバレスというものでどのようなことが実現できるかのイメージが付いたかと思います。

p13-p17 「トリガーとバインディング」

このトリガーとバインディングという機能。とても良いと感じました。

スライド前項の方でも述べられていましたが、サーバレスなサービスは糊的な感じで、何かと何かをつなげるということが多くあります。

Azure Functions ではこのつなぎ合わせ部分をトリガーとバインディングとして定義できることで、「何を元に、何を出力とするか」というのを明確にすることができるようです。

これは見た目として明確になるのもそうですが、今まで他のサーバレスなサービスを使っていた際に、次の出力を定義するためのコードがエラー処理などを含め、大多数をしめており、実際にやりたいこと以上に労力を割いてたと考えると、レイヤーを分けたこのような機能はとても有用だと感じます。

何を基準に起動するか(トリガー)だけではなく、その処理の中で追加でどういったものが必要なのか(インプットバインディング)その結果、どういったものにデータを書き込むのか(アウトプットバインディング)をきれいに記述できるのは大きなメリットです。

エラー処理については p29 にかかれているように現在サポートされているものは「Azure BLOB Storage」「Azure Queue Storage」「 Azure Service Bus (キュー/トピック)」の3種類となってるとのことですが、こういった機能がサポートされているのであれば、今後増えていくことも期待できますし、何より、リトライや有害キュー(失敗したら退避)などがデフォルトで定義されているとコードに集中できて良さそうです。

Custom Binding も作れるとのことなので(どこまでできるかわからないものの)、こういったよくある Input/Output を個別に切り出すことができるのは多くのメリットがあると感じました。

また、 p14 の例では、複数の Functions を扱うようなディレクトリ構成を取っています。

イベントドリブンな処理であれば、これらの必要度は低いのですが、ユーザからのリクエストを受けるような Web Application においては、それぞれが独立していることは少なく、同じリソースに対する処理であったり共通的な処理というのが書かれることが多数ですので、はじめからどのような構成にすればいいか悩むことなく、書き始めることができると感じました。

p18-p25 「ホスティングプラン」

Azure Functions には「従量課金プラン」と「App Serviceプラン(固定)」の両方が提供されているようです。

Functions を通常のインスタンスで起動できるというプランのようです。また、それらは互いに変更可能のように見えました。

例えば、途中から要件がかわって固定IPが必要になった。1 request に対して巨大な処理をしなければいけなくなった。

といった開発途中で起こりうる変更についても、フレキシブルに対応できるのはとても便利に見えます。

それも独立したサービスではなく Azure Functions の中のオプションとして設定できるので、とても気軽です。

もちろん最近は Container をそのままサーバレスで動かすということもできるようになってきていますが、じゃあそれをサーバレスからサーバがある環境に移すとなると、アプリ側やインフラ側で一定の対応が必要でした。

それがなく、起動プランとして選択できるのは多くのメリットを享受できるのではないでしょうか。

また、 Premium プラン というものも今後出てくる(現在はプレビュー)とのことで、こちらではよくあるコールドスタート問題の解決であったり、より詳細なスケーリングの制御ができるようです。

自分は Google App Engine のスケーリングが好きなのですが、 Premium プランはそれと同様な概念に見えましたので、とても期待が高まっています。

p43-p48 「Durable Functions」

Durable Functions は「ステートフル関数を実現する拡張機能」として説明をされました。

サンプルを見ただけでは、基本的にはプログラミングにおける関数を分けただけで、ちょっとメリットがわからなかったですが、

聞いているうちに、おそらくこういうことなのかなってことを思いました。

・別の Azure Functions へ処理を委譲することによるスケーラビリティ

・それらのエラー処理、フロー処理の簡略化 (内部状態の保持)

p47 のサンプルにも JavaScript の Promise の例が書かれていましたが、それを裏側のサーバリソースを気にすることなく(単一インスタンスではなく)書くことができるのが、 Duable Functions なのでは無いでしょうか。

Durable Functions での Orchestrator とはフローを記述するもの。そして、そのフローにおいて、余計なことを気にすることなく、バインディング同様にコードに集中できるソリューションだと。

クラウドサービスは「何でもできるようになっている」反面、色々なものを新しく学ばないといけないというのが難しいところですが、Durable Functions は Azure Functions + α の知識でフロー処理をかけるのでとても強力だと感じました。

p50 「Microsoft Learn」

最後に紹介されたのが Microsoft Learn でした。

アカウントで不要で無料でサンドボックス機能を提供してくれるものです。

すぐに作れるっていうのがクラウドの利点ではあるのですが、技術検証や本当に Azure 使うのかといったことを検証する際には、アカウントの作成などをしなければ行けないわけですが、 そういうのがなく、とりあえず触ってみるっていうのができるのはかなりの利点ではないでしょうか

まとめ

さて、普段 AWS / GCP しか使っていない自分が本セッションを聞いて色々想像してみました。

Azure Functions はその一つのサービスで色々なことができることから、アプリケーション開発者としてはかなり強力なサービスだと感じます。

すぐにでもアプリケーションを書き始めることができる。ロジックを書くのに集中する仕組みがある。そして要件変更にも対応する事ができる。このようにアプリケーション開発をする人に寄り添ったサービスなのではないでしょうか。

こういったイベントでは Ask The Speaker と呼ばれる直接発表者の方と話すことができる場も設けられているので、色々聞いてみて、色々質問してみて、色々考察してみると楽しいと思います。

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

iOS de KANPAI ! 【WWDC 2019 報告会】を開催しました

48065744158_39e6bfc024_z.jpg 2019年6月3日〜7日に、アメリカのサンノゼにて、 Apple 社が主催する World Wide Developers Conference(WWDC)2019 が開催されました。DeNA からは 6名のエンジニアが WWDC 2019 に参加しました。この WWDC で得た学びをコミュニティに還元すべく、2019年6月14日に iOS de Kanpai! を開催しました!こちらの記事でその様子をご紹介します。

乾杯 & OverView

48065797282_9672e17263_k.jpg まずは @feb19 が乾杯してスタート。 OverView として、WWDC でどのようなことが発表されたか それぞれ概要を説明しました。

Xcode 新機能 + テスト周りの変更点

48065692236_de57530747_k.jpg 続いて、 DeNA SWET グループの @tobi462 が Xode 11の新機能と、テストまわりの改善点について話しました。

今回の WWDC19 では開発者が望んでいた機能が数多く発表されたように思えます。Xcode 11 ではエディタ周りの刷新やGitサポートの強化、デバッグまわりの新機能など、便利な機能が多数追加されました。

テストまわりでは「Test Plans」という名前で、テスト実行のコンフィギュレーションを構成できる仕組みが用意され、今までよりもずっと楽に様々な設定でのテストが実行できるようになりました。また、XCTest にも便利な API が追加されました。なお、今回は時間的に発表で触れることが出来ませんでしたが、テストの成果物を1つにまとめる「Result Bundle」という機能も追加されています。

テスト周りの変更点については、いずれ DeNA Testing Blog でも取り上げていこうと思いますので、楽しみにしていただければと思います。

ソーシャルライブサービスから見た WWDC 2019

48065689786_f74a934046_k.jpg 次に、ライブ配信アプリ Pococha の開発を行っている @noppefoxwolf が話しました。

ソーシャルライブサービスを開発している目線から、Metalの新機能とARKitの新機能についてお話ししました。 実運用ではまだまだOpenGLESを使っている箇所があるのですが、今回のシミュレータ周りのアップデートでMetal移行も現実的になってきたことが分かりました。

また、シミュレータでMetalが動く仕組みから、メモリ共有をシミュレータで再現するTIPを紹介したりしました。

後半はARKitやRealityKitの機能を紹介しました。これまで高価な機器やSDKを使わないと出来なかったことが、どんどん手の届く技術になってワクワクするようなアップデートでしたね。

Sign in with Apple

48065688506_f0fad356a8_k.jpg 続いて、 @monoqlo が、今回 WWDC 2019 で発表された新機能のである、 Sign in with Apple について、実際に組み込んで試してみた結果など交えつつ発表しました。

サードパーティー製ログインを採用しているアプリは Sign in with Apple は対応が必須になる見込みです。今年後半から目にする機会が増えてくることでしょう。

発表ではβ版を使用したデモやスクリーンショットを交え、概要にとどまらず、実際に触ってみて現時点で判明していること、まだよくわかっていないことなどをお伝えしました。

WWDC19 Design

48065789622_c3d237d2fe_k.jpg 10分の休憩を挟んだ後、DeNA デザイン本部サービスデザイン部デザインエンジニアリングG マネージャーの @feb19 が、WWDC のデザイン周りの内容をラップアップしてお話しました。

また、こちらに @feb19 のレポートブログが掲載されています。 - iOS Developer の視点 - WWDC19 で注目したい新しいテクノロジー - UI Designer の視点 - これからの iOS アプリの UI デザイン - Apple のヘルスケア関連新サービスと、WWDC の健康アクティビティ、アメリカのヘルスケア産業 - DevRel の視点 - 会場運営における UX/UI デザインの工夫、エンジニアがグッとくる Apple の魔法 - Frontend Engineer の視点 - Safari と WebKit の進化ほか

Machine Learning の新機能

48065735213_000d77f434_k.jpg @koooootake は、WWDC19で発表された Machine Learning の新機能まとめを発表しました。CreateMLのDEMOでは、カレーと、ハンバーガーと、どんぶりと、3Dモデルの女の子のスクリーンショットを精度高く、ドラック&ドロップで簡単に分類できることを披露しました。

このスライドを見ればWWDC19のML関連の話題がだいたい掴めるのでぜひご覧ください。

SwiftUI / Combine について

48065785607_f612e6b906_k.jpg 最後に、@bannzai がSwift UI、Combine について、実際にうごかしてみながら紹介しました。

SwiftUIとCombineについてラボで質問した内容、公開セッションと現状のフレームワークの内容に差異があることをお話しました。また、Mac Pro についての最高スペックの値段予想が出ていたことについても紹介しました。

まとめ

今回実施した WWDC 報告会は、 WWDC 2019 に行く前から企画し、WWDC に参加した DeNA のエンジニアは聞く内容、発表する内容を分担して準備を行い、発表しました。

WWDC 2019 で発表された内容は膨大で、1人1人が個別にキャッチアップするのも大変でした。今回の発表で iOS アプリ開発エンジニアのみなさんが WWDC で発表された内容のうち、興味ある内容を理解する助力になれば幸いです。

DeNA は今後もこのようなイベントを行っていきますので、引き続きどうぞよろしくお願いします。

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