秋葉原ラボ技術報告
volumeiAkihabara Lab

巻頭⾔「問われる基盤⼒」
秋葉原ラボ 研究室⻑ 福⽥ ⼀郎

技術報告

Vol.3

新型コロナウィルス感染症の影響下で外出⾃粛やリモート勤務，短縮営業，営業⾃粛などという⾔葉とともに，仕事と私⽣活の双⽅で今までに経験したことがない環境になっている．我々のようなインターネットサービス開発に関わる者がただちにできるのは，状況を改善するために可能な限りのリモート勤務の実施と私⽣活においても不要
不急の外出を避けることくらいである．最前線のいわゆる「エッセンシャルワーカー」の⽅々には感謝の念しかない．
このような緊急事態で問われるのは基盤がいかに整備されているかということであろう．今
回は医療・検査体制やリモート勤務が可能な環境に⽬が向けられている．⽇ごろからどこまで基盤を整備し，あらかじめ緊急事態への対応能⼒を確保しておくべきかは判断が難しい問題だ．
秋葉原ラボ技術報告の巻頭⾔なのでやや強引に関連付けるが，近年流⾏りの機械学習に関わるシステムにも基盤整備は⽋かせないものとなっている．アルゴリズムに注⽬が集まりがちではあるが，システムの裏側にデータ収集・集計・分析基盤やモデル管理・サービング基盤などが整備されていることで，より⾼品質かつ迅速に機械学習をサービスに適⽤できる．
共通化や基盤化をどこまで進めるかは想定される効果をもとに考えれば良いと思われるとこ
ろだが，秋葉原ラボが所属する当社のメディア事業では新しいサービスが次々と作られ，それらが対象とする領域も多岐にわたるので，効果の程度の予測も難しいのが実情だ．そのためにどのようなサービスであっても共通となるであろう要素を抽出し，できる限り抽象化したうえでシステムとして落とし込むことを⼼がけた開発を⾏っている．

Vol.3 となる今回の秋葉原ラボ技術報告では機械学習システムを⽀えるデータ基盤を中⼼に取り上げ，さらに画像処理技術のサービス適⽤を機械学習の応⽤事例として紹介する．
機械学習システム向けの基盤整備という課題に対する私達の取り組みをご覧いただくことで，この分野の技術発展に多少なりとも寄与することを期待している．特に基盤を作る際に抽象化
レイヤを意識して開発しているところに注⽬して読んでいただけると幸いである．

⽬次

巻頭⾔「問われる基盤⼒」

i

1 データ活⽤のための基盤システム

1

1.1

秋葉原ラボの研究開発とシステム運⽤を⽀えるクラウドネイティブ環境

2

1.2

スキーマ定義に基づき key-value ストアにアクセスする API サーバの構築と運⽤

13

1.3

ストリーム処理を考慮したデータ転送管理システムのレイヤ化

21

1.4

ストリーム処理におけるステートフルデータの管理⼿法

29

2 機械学習システム

35

2.1

フィルタ基盤の開発における取り組みと利⽤されている技術

36

2.2

データと処理の依存関係を整理する機械学習モデル管理基盤の開発

45

3 画像処理51

3.1

マッチングサービスにおける画像審査の⾃動化

52

3.2

NG 画像フィルタの設計から運⽤まで

58

発表⼀覧

67


データ活用のための基盤システム
秋葉原ラボは大規模データ処理を支える基盤システムを開発しデータ活用を促進している．
これらの基盤システムは当社のインターネットサービスの多様性や，コンテンツ推薦・検索などの様々なデータ用途をふまえ改善されてきた．本章では基盤システムの取り組みとして，システムの礎となるクラウドネイティブ環境と，ストリーム処理基盤について解説する．

2
Akihabara Lab

1.1
岩城 洋⼀

佐藤 栄⼀

秋葉原ラボの研究開発とシステム運⽤を⽀えるクラウドネイティブ環境

松原 周平

概 要 秋葉原ラボでは各サービスを⽀援するための基盤や機械学習システムの開発運⽤を⾏っている．当社のプライベートクラウド環境はインフラコストやハードウェア選定などの⾯でメリットがあり，このプラ
イベートクラウド環境との親和性が⾼いクラウドネイティブ環境を提供することが重要となる．本稿ではクラウドネイティブ環境の構築と運⽤の取り組みについて紹介する．

Keywords

クラウドネイティブ，Kubernetes，OSS，OpenStack，プライベートクラウド

1 はじめにの⾼い環境の構築と運⽤を⾏うことである．これはクラウドネイティブ環境を Amazon Web Ser-

秋葉原ラボでは ABEMA や Ameba ブログ，広vices（AWS）や Google Cloud Platform（GCP）

告プロダクトなどから⽇々⽣成される⼤量のデーなどのパブリッククラウドのみで運⽤する場合，

タを活⽤したレコメンデーションシステム，サー

当社が運⽤する社内向けプライベートクラウドのビスの有害なコンテンツを効率良く検出するため恩恵を受けられないためである．社内向けプライのフィルタリングシステムなどを開発し，サービ

ベートクラウドには，（i）インフラコストが低い，ス改善に貢献している．

（ii）ハードウェアの選定などの⾃由度が⾼い，（iii）

これらのシステムのベースとなる機械学習やデータ分析の分野は進歩が著しく，オープンソー

既存のデータが集約されておりデータ活⽤との相性が良い，といった特徴がある．

スソフトウェア（OSS）やクラウドサービスが⽇々

本稿では，秋葉原ラボが運⽤するクラウドネイ

登場する．このためこのような⽇々新たに登場す

ティブ環境である秋葉原ラボ向け Kubernetes 環

るものや⼿法を効率的に取り込みながら研究開発

境の概要，プライベートクラウド上のインフラリ

およびシステム運⽤の改善を進めていくことが重ソースとの連携，Operator やアドオンなどの活⽤要となる．

事例，ワークロード最適化の取り組みについて紹開発および運⽤の改善，効率化などについては介する．

近年 Docker や Kubernetes などによるクラウドネ
イティブ技術が注⽬されており，秋葉原ラボでもこれらの技術を活⽤することにより本問題の解消を進めている．
秋葉原ラボのクラウドネイティブ環境を実現す
るにあたって重要な要件の⼀つがプライベートク
ラウドが提供する各種インフラリソースと親和性

2 関連⽤語
本章では Kubernetes に関する⽤語が多く登場するため，本節で主な⽤語について説明する．

• kubelet — kubelet は各ノードで実⾏される

3 概要と構成

3

Kubernetes の主要コンポーネントの⼀つであ• CRD — Custom Resource Definition の略称．

る．Kubernetes API を提供するコンポーネン

ユーザが定義可能な Kubernetes リソースの定トである api-server と連携し，PodSpec で宣義を指す．たとえば Deployment や CronJob

⾔されたコンテナの実⾏に対して責務を負う．

のような Kubernetes リソースを独⾃に定義でまた，Kubernetes クラスタへの Node の登録，

きる．

Node や Pod の状態の api-server への通知も• Operator — Operator*5 は Kubernetes の⾏う．

CRD とコントローラによって構成される「ア• Cloud Provider — Cloud Provider は，Ku-

プリケーション指向のコントローラ」である．

bernetes がロードバランサなどの外部のイン

Operator を使⽤することにより，Prometheus

フラと連携するためのしくみの総称．Cloudや MySQL などを CRD として宣⾔的に記述しProvider では，主に Cloud Controller Man-て登録し，複雑なコンフィグ，デプロイ，クラager と呼ばれるコンポーネントによって，Ku-

スタなどの管理運⽤を Operator 側で⾃動的に

bernetes 外のインフラに対して設定の同期な

⾏わせることができる．

*1

どを⾏う．AWS ⽤のもの，GCP ⽤のもの，• Pod — Kubernetes リソースの⼀つ．Kuber-

OpenStack ⽤のものなど，動作環境に合わせてnetes でデプロイできる最⼩かつ最も基本的なさまざまな実装が提供されている．

オブジェクト．Docker コンテナなどのコンテ• CNI — Container Network Interface*2 の 略

ナが 1 つ以上含まれており，Pod 内のコンテナ

称．CNCF（Cloud Native Computing Foun-はストレージやネットワークなどを共有する．

dation） のプロジェクトで，コンテナに対し• PV — PersistentVolume の略称．Kubernetesて任意のネットワークを公開するための標準イ

リソースの⼀つ．ストレージクラスによってプンタフェースである．Kubernetes ではネット

ロビジョニングされるクラスタのストレージリ

ワークプラグインとして CNI プラグインを利

ソース．

*3

⽤できる．

• PVC — PersistentVolumeClaim の略称．Ku-• CSI — Container Storage Interface*4 の略称．

bernetes リソースの⼀つ．ユーザによって要求コンテナに対して任意のストレージを公開すされるストレージリソース．新しく PVC を作るための標準インタフェースである．CSI を実成すると，その設定内容を満たす PV が確保さ装した Kubernetes の CSI プラグインを導⼊

れて PVC と紐づけられる．

することにより，ストレージを Kubernetes の

PV/PVC リソースとして扱うことができる．
多くの主要なストレージシステムの CSI プラ
グインが Kubernetes チームやサードパーティ

3 概要と構成

ベンダによって提供されている．

• コントローラ — Kubernetes リソースを監視し，期待する状態と実際の状態を⼀致するよう

本節では，秋葉原ラボ向け Kubernetes 環境（以に処理を⾏うコンポーネント．この処理ループ

降は lab-k8s と呼称）の全体の⽅針と構成を簡単には Reconcile ループと呼ばれる．

紹介する．

*1 https://kubernetes.io/docs/concepts/architecture/cloud-controller/*2 https://github.com/containernetworking/cni*3 https://www.cncf.io/*4 https://github.com/container-storage-interface/spec/blob/master/spec.md*5 https://coreos.com/blog/introducing-operators.html

1.1 秋葉原ラボの研究開発とシステム運⽤を⽀えるクラウドネイティブ環境

4
3.1

要件・設計⽅針

秋葉原ラボで開発・運⽤されるアプリケーショ

ロールする必要がある．

3.2

コンポーネント構成

ンは多岐にわたるため，さまざまなワークロード

ここでは，それぞれのコンポーネントについて簡への対応が必要となる．構築時には下記の内容を単に説明する．独⾃に実装しているコンポーネン

考慮した．

トには（*）を付けている．詳細については後の節• ステートフルなワークロードを扱えること．

を参照されたい．図 1.1.1 のように，Kubernetes

データベースなど，秋葉原ラボで扱うワーク

本体といえる部分は少なく，多くのコンポーネン

ロードには永続的なストレージを必要とする

トが協調して動作している．

ものも多いため，そのデータ移⾏を考慮した場
合，Kubernetes クラスタ間でワークロードをネットワーク・DNS

移⾏することは難しい．バージョンアップは，• OpenStack Port CNI(*): Pod に Open-

新しいバージョンの Kubernetes クラスタを作

Stack の Port を直接割り当てる構成の CNI プ

りワークロードを移⾏する⽅法ではなく，運⽤

ラグイン．

するクラスタを継続的にアップデートしていく
⽅法を前提とする．

• lab-k8s-cloud-provider(*): 主に，Kubernetes の Service リソースから⾃動で外部の• バッチワークロードへの対応．API サーバやロードバランサの設定を⾏うためのコンポーネ

データベースなどの⻑時間起動しているワーク

ント．後述の ExternalDNS によって，作成さロードに限らず，CI のジョブや定期バッチなれたロードバランサにはクラスタ外からでも参どで起動・終了を繰り返し，瞬間的なリソース

照可能な DNS レコードが⾃動設定される．

消費が激しいワークロードにも対応する必要が• CoreDNS, nodelocaldns: ク ラ ス タ 内 のある．

• ネットワーク処理のオーバーヘッドが少ない
こと．低レイテンシ・⾼トラフィックを要求

DNS を提供するアドオン．CoreDNS への負荷を軽減するために各 Node にキャッシュを配備している．

するワークロードも多いため，オーバーレイ• ExternalDNS: type: LoadBalancer な ど

ネットワークおよびネットワークアドレス変換の Service を lab-k8s 外から参照できるよう（NAT）は原則使⽤しない．これは，トラブルにするために，Amazon Route 53 に DNS レ

シューティングの複雑化を避ける⽬的を兼ねてコードを登録している．

いる．

• マルチデータセンター構成に対応できるこストレージと．当社には複数のデータセンターにそれぞ• Cinder CSI Plugin: OpenStack の Cinder

れ OpenStack クラスタが存在するため，それストレージを利⽤するための CSI プラグイン．

らを透過的に使⽤できることが望ましい．ま• PV GC Controller(*): 解放された PV を⼀た，データセンター間でのワークロードやスト

定期間後に⾃動削除するためのコントローラ．

レージのポータビリティを実現できることが望ましい．

ログ・モニタリング• マルチテナンシーの実現．秋葉原ラボには複数• Fluent Bit: 各 Node で動作して，コンテナののチームが存在するため，権限や計算リソース

ログを Stackdriver Logging に転送している．

を適切な粒度で分離し，利⽤者間・ワークロー
ド間でお互いに影響を及ぼさないようにコント• Prometheus

Operator,

Prometheus,

Alertmanager: 監視には主に Prometheus

4 インフラとの連携

5

図 1.1.1 コンポーネント構成

4 インフラとの連携を利⽤している．

• NodeExporter,

kube-state-metrics,

etc.: Kubernetes や Node の状態の監視のためのメトリクスを公開するコンポーネント．これらのメトリクスは Prometheus によって収集される．

• Grafana: Prometheus で収集したシステムのメトリクスなどの可視化を⾏う．

• Kubernetes Dashboard: Kubernetes の状
態を確認するためのダッシュボード．

当社ではインフラチームが複数のオンプレミスのデータセンターに世代の異なる OpenStack ベースのプライベートクラウドを構築・運⽤している．

lab-k8s はそれらのプライベートクラウドを横断する形でクラスタを構築しており，Kubernetes 上からは Node ラベルを使⽤することでワークロードを実⾏するデータセンターを選択できる．明⽰的な aﬃnity の指定がない場合，ワークロードは任意のデータセンターで実⾏される．また，インフラチームによって提供される SLB と呼ばれるソフ
トウェアロードバランサを Kubernetes の Exter-

nal Load Balancer として利⽤している． 本節ではノードの構築や設定，Cloud Providor，CSI や

CNI などのプラグインによるインフラとの連携にその他ついて記載する．

• Redis Operator, MySQL Operator: 利⽤者が簡単に MySQL や Redis Sentinel を構

4.1

ノードの作成と準備

築・運⽤するための Operator を導⼊している．

Kubernetes にはクラスタ内のオブジェクトの• cert-manager: 証明書の⾃動発⾏・更新を⾏状態を制御するコアコンポーネントが稼働する

うためのコンポーネント．⼀例として，発⾏

Control Plane ノード，コンテナ化されたアプリ

した証明書は lab-k8s-cloud-provider によってケーションが実⾏される Worker ノードおよび

ロードバランサに⾃動設定できる．

メタデータを保存する etcd が必要になる．Ku-• ECR Token Refresher(*): コンテナレジス

bernetes クラスタのブートストラッピングにはトリとして利⽤している Amazon Elastic Con-kubeadm を利⽤している．etcd は Kubernetes

tainer Registry（ECR）の imagePullSecret をの Control Plane ノードとは異なるインスタンス

⾃動更新するための DaemonSet．

VM で実⾏する HA 構成を採っている．Worker

1.1 秋葉原ラボの研究開発とシステム運⽤を⽀えるクラウドネイティブ環境

6

ノードは Terraform からインスタンス VM の起動

Quota の設定を⾏っている．これによって，を⾏うと⾃動的にクラスタに参画するように構成誤ったマニフェストによる意図しない過度なリしており，新規ノードの追加を容易にしている．

ソースの消費を避けられる．

etcd，Control Plane ノード，Worker ノード，

• kube-reserved や system-reserved を 設 定 す

ノードで実⾏される Pod など，それぞれの間の通ることでユーザの実⾏するワークロードと信は OpenStack の SecurityGroup を利⽤して制

kubelet やコンテナランタイムなどの Kuber-

御している．

netes のシステムコンポーネントとの間でリソースの競合が起きないよう，安定稼働に必要

4.2

クラスタ設定なリソースをあらかじめ確保している．

秋葉原ラボ内の多様なアプリケーションやバッ• cpu-management-policy を static に設定し，特チ処理を実⾏する上で，リソースの分離や可⽤性

定のアプリケーションが CPU を排他的に利⽤の向上のための設定を⾏っている．

できるようにしている．コンテキストスイッチ
や CPU キャッシュミスの影響を⼤きく受ける
ワークロードのパフォーマンスの向上が期待で

権限管理

きる．

RBAC と PodSecurityPolicy による権限管理を⾏う．lab-k8s は複数のチームが単⼀の Kuber-

netes クラスタを共有するマルチテナント環境であ

4.3

Cloud Provider は，Kubernetes が環境ごとにるため，利⽤者が Pod を実⾏する場合には原則，
特権コンテナや root 昇格，root ユーザでの実⾏，
ホストパスボリュームのマウント，ホストネット
ワークの使⽤など多くの権限を制限した PodSecu-

rityPolicy のみ使⽤できる設定となっている．ア
プリケーションを開発・運⽤するチームの単位でNamespace を分割し，Namespace 内の管理者権限を割り当てている．

Cloud Provider の実装

異なるロードバランサなどの外部のインフラと連携するためのしくみである．たとえば，type:

LoadBalancer の Service を 作 成 し た 際 に ，実
際 の ロ ー ド バ ラ ン サ の 作 成・更 新 を ⾏ っ た り ，OpenStack などの IaaS から，Node に関する情報（状態，インスタンスタイプ, etc.）を取得して Kubernetes で利⽤できるようにする． Cloud

Provider を 作 成 す る た め の フ レ ー ム ワ ー ク がクラスタ内のサービスルーティング
クラスタ内のサービスルーティングには Service
数と Pod 数に⽐例し負荷が⾼くなる可能性がある iptables プロキシではなく IPVS プロキシを利⽤している．IPVS プロキシによりスケーラビリ
ティの向上や柔軟なロードバランシングが可能になる．

リソース管理リソースの競合を回避するために以下の管理を⾏っている．

• ユーザが利⽤する Namespace には Resource-

提 供 さ れ て い る た め ，Go ⾔ 語 の イ ン タ フ ェ ース cloudprovider.Interface*6 を実装することで，独⾃の Cloud Provider を作成できる．

lab-k8s では，インフラチームによって提供されているロードバランサや複数の OpenStack クラス
タとの連携のため，独⾃に Cloud Provider を実装
して利⽤している．

ロードバランサとの連携
ロードバランサとの連携は，Service/Pod の増減や状態の変化を監視（Watch）して，ロードバランサの設定を適切な状態に同期することで実現している．SLB では，ノードの追加などの各種操作*6 https://godoc.org/k8s.io/cloud-provider#Interface

4 インフラとの連携を API 経由で⾏うことができるため，これを利⽤
している．

7
4.4

ネットワークとストレージの連携

OpenStack が提供するネットワークとストレー

多くの type: LoadBalancer の実装では，まずジのリソースを Kubernetes で利⽤するため，Ku-

は Kubernetes の Node にトラフィックを分散さ

bernetes の CNI と CSI を経由して各種リソース

せてからそこからさらに Pod にトラフィックをとの連携を⾏っている．それぞれの概要と，より振り分ける構成を採るが，この⽅式では経由する

⾼可⽤性を実現するための取り組みや⼯夫についNode が多いためオーバーヘッドなどが⼤きくなって紹介する．

てしまう（図 1.1.2）．lab-k8s では，SLB を含む社
内のインフラから直接ルーティング可能な IP アド
レスを Pod に付与しているため（詳細は CNI の項を参照），ロードバランサから直接トラフィック
を Pod に届けるコンテナネイティブロードバラン
シングと呼ばれる構成を採⽤している．

CNI
Kubernetes では既存の CNI プラグインがいく
つか⽤意されており，⼤きくオーバーレイネット
ワーク⽅式とアンダーレイネットワーク⽅式のものに分類されるが，それぞれ以下の⽋点，制約がある．

• Flannel などのオーバーレイネットワーク⽅式
OpenStack との連携
Kubernetes は，Cloud Provider のしくみにより，Node の情報（IP アドレス，インスタンスタイプ）や Node の存在性，起動状態などを，Open-Stack などの IaaS から取得して利⽤する．lab-k8s
は OpenStack の VM インスタンス上で稼働しているため，OpenStack API からこれらの情報をの CNI プラグインの場合，ネットワーク処理のオーバーヘッドが発⽣したり，トラブルシュー
ティングが複雑化する．

• Calico などのアンダーレイネットワーク⽅式の場合，L3 ネットワーク間の通信を⾏うために BGP などのプロトコルが必要となったり，ルータ側の設定が必要になる．

取得する必要がある．すでに OpenStack Cloud

このような問題を回避するため，lab-k8s では

Provider*7 が存在するが，lab-k8s では以下の機能「各 Pod に対して OpenStack Port をアタッチ∕などを実現するために Cloud Provider を独⾃に実デタッチする⽅式」の独⾃の CNI プラグインを装している．

開発・運⽤している．また OpenStack が提供する• 複数の OpenStack クラスタに対応する必要があるため，Node の FQDN を基に，Node の情報を問い合わせるべき OpenStack API のエン
ドポイントを決める．

• OpenStack のインスタンス VM に複数の Portが付与される（詳細は CNI の節を参照）ため，

Port を使⽤することにより，OpenStack の SecurityGroup によるネットワークセキュリティ制御
を利⽤可能になるといった利点もある．

OpenStack Port CNI は CNI プラグイン，CNI
エージェント，CNI サーバの 3 つにより構成される．（図 1.1.3）

Node ⾃体に設定されている IP アドレスがどれ• CNI プ ラ グ イ ン: kubelet か ら 実 ⾏ さ れ る

なのか OpenStack API からは判別できない．

OpenStack Port CNI のエントリポイント．

このため，プロビジョニング時に設定されたイ

OpenStack Port を確保するための CNI プラ

ンスタンス VM のメタデータから Kubernetes

グイン，および適切な iptables/IPVS を設定すの Node の IP を参照する．

るための CNI プラグインが順番に実⾏される．

*7 https://github.com/kubernetes/cloud-provider-openstack1.1 秋葉原ラボの研究開発とシステム運⽤を⽀えるクラウドネイティブ環境

8

図 1.1.2 コンテナネイティブロードバランシング• CNI エージェント: 各 Kubernetes ノードに配Stack から OpenStack Port を確保し，必要な置される DaemonSet のエージェント．ノード

IP アドレス/iptables/IPVS 等の設定を⾏う．

上の OpenStack Port の管理を⾏う．また後述

これを Pod で使⽤可能な IP アドレスなどの情する Port のプーリングにより OpenStack へ

報としてを kubelet に応答を返す．

の負荷を軽減する機能を備えている．

• CNI サーバ: OpenStack Port の作成，削除，アタッチ，デタッチを管理する．CNI サーバは

4. kubelet は CNI プラグインの応答として受け取った IP アドレスなどの情報を利⽤して Podを作成する．

OpenStack 環境ごとに配備される．
OpenStack Port CNI を 運 ⽤ す る に あ た り ，OpenStack の負荷や障害などの予兆も含めて検出するために，CNI エージェントおよび CNI サー
バでは複数のメトリクスを公開している．たとえば CNI ⾃体のメトリクス，OpenStack API に関連するメトリクスなどが含まれる．これを監視す
ることにより障害時の問題の切り分けを⾏うことができる．

OpenStack の 不 具 合 な ど に よ り OpenStack
Port が適切にデタッチ，削除されずにリークした状態となる特殊ケースがあるため，CNI エー
ジェントではこれらのリークを検出して CNI サー
バにリーク情報を通知するしくみも導⼊している．
以下に Pod 作成時の OpenStack Port CNI を含めた処理の流れを⽰す．

1. Kubernetes が Pod 作成リクエストを受信し，特定の Node に Pod をスケジューリングする．

2. スケジュールされた Node 上の kubelet が Podに必要な IP を確保するために，OpenStack

Port CNI の CNI プラグインを実⾏する．
3. CNI プラグインが実⾏されると，前述した CNI
エージェントと CNI サーバが協調して Open-CSI
lab-k8s で は プ ラ イ ベ ー ト ク ラ ウ ド の OpenStack の Cinder Volume を利⽤するために，OpenStack Cloud Provider の中で提供される Cinder
CSI プラグインを導⼊している．しかし lab-k8sに導⼊した 2019 年当初は OpenStack に関連する不具合などにただちに対応する必要があったた
め，Cinder CSI プラグインのソースコードに独⾃の修正を加えている．その後は lab-k8s においてStatefulSet の可⽤性を⾼めたり，OpenStack の
UI 上から lab-k8s の PVC リソース情報との対応付けによって可視性を⾼めるために機能追加や改善も⾏っている．⼀部の機能追加を実現するために Cinder CSI プラグインに加えて，Kubernetesの storage-sig が提供する external-provisioner も独⾃に拡張を加えている．

• 作成した Cinder Volume に PVC や Namespace などのメタ情報を付与することにより，OpenStack と Kubernetes の対応関係を明確にする．

• 同 ⼀ イ ン ス タ ン ス VM 上 の 並 列 ア タ ッ チ/
デタッチの排他制御を実装することにより，

5 Operator, アドオンの運⽤

9

図 1.1.3 OpenStack Port CNI の構成

OpenStack で不整合状態が発⽣するバグを回チャ，ツールなどの各種知識とノウハウが必要と避する．

なるため導⼊するための敷居が⾼くなる．このた• Kubernetes の PVC 作成時に Cinder Volumeの Availability Zone（以降は AZ と呼称）を⾃め本節で紹介する Operator, アドオンを導⼊して運⽤を⾏っている．

動分散することにより，StatefulSet などにおける⾼可⽤性を実現する．
この独⾃拡張した Cinder CSI を使⽤する場合
は，PVC を作成する際に適切なストレージクラス

5.1

Operator

本項では lab-k8s で使⽤する代表的な Operatorを紹介する．

および設定を指定する．以下にストレージクラス
および設定の特徴を⽰す．

• Cinder Volume のタイプを指定可能．SSD，HDD などを指定する．
• Cinder Volume の AZ を指定可能．各 AZ を指定するか，⾃動分散を指定する．

• reclaimPolicy は Retain/Delete を指定可能．
Retain の場合は Cinder Volume の削除は後述
する PV のガベージコレクトによって⼀定期間を経てから削除されるため，誤って削除した場
合でもデータを復旧することが可能．

5 Operator, アドオンの運⽤
Kubernetes 上にデータベース，キャッシュレイ
ヤなどのミドルウェアやアプリケーションを導⼊することは⽐較的容易である．しかし HA 構成とMySQL Operator
MySQL Operator*8 は MySQL の HA クラスタ
環境を提供する Operator である．MySQL Op-

erator ではクラスタの管理および運⽤のために，
MySQL Orchestator および Percona Server を使⽤しているため，MySQL クラスタの管理，運⽤，
監視においてこれらのツールや UI などを利⽤できる．

lab-k8s では MySQL Operator の可⽤性などを⾼めて運⽤するために，以下の独⾃の拡張および修正を加えている．

• バックアップ，サイドカーなどの各種コンテナの resources や securityContext を CRD から指定できるように拡張．

• いくつかの Kubernetes 関連バグを回避するた
めの修正．

したり各種メンテナンスを⾏ったりするところま• バックアップ関連のバグを修正．

で考慮した場合，対象となるミドルウェア∕アプ• 各クラスタノードのボリュームの AZ が分散さ

リケーションに加えて Kubernetes のアーキテクれるように対応（Cinder CSI プラグイン側の*8 https://github.com/presslabs/mysql-operator

1.1 秋葉原ラボの研究開発とシステム運⽤を⽀えるクラウドネイティブ環境

10
拡張により対応）．

上記の対応により，リソース⾯，セキュリティ
⾯，可⽤性⾯の課題を解決した MySQL クラスタの構築および運⽤を実現している．なお MySQL

変更などを検知したうえで Redis の HA 構成を適切に管理運⽤できる．なお Redis を構成する Podの可⽤性を⾼めるため，MySQL Operator と同様の podAntiAﬃnity 設定を⾏っている．

クラスタの可⽤性を⾼めるため，podAntiAﬃnity
により MySQL クラスタの Pod を同じホストに配置しないように設定している．また前述した Cin-der CSI プラグインの AZ ⾃動分散を利⽤することによりストレージ⾯での可⽤性を⾼めている．

Prometheus Operator
Prometheus Operator*11 は「Prometheus イン
スタンスのデプロイ」と「Prometheus で⾏うモ
ニタリングの設定」とを分離するというアイデアに基づき設計され，デプロイやライフサイクル管理を意識せずにモニタリングの設定を可能にする

Redis Operator
Redis Operator*9 は Redis Sentinel*10 を利⽤することで Redis の HA 環境を提供する Operator
である．

Redis Sentinel による HA 構成を実現可能するためのソリューションは Redis Operator 以外にもある．たとえば Kubernetes のアプリケーション
管理ツールである Helm には Redis Sentinel ベースの Helm パッケージがいくつか存在する．しかしこれらの Helm パッケージは⼀般的に以下の課題と制約がある．

Operator である．
たとえば Kubernetes ⾃体のモニタリングでは多くのコンポーネント（kubelet，cAdvisor，api-

server，controller-manager，scheduler など）のメトリクスをスクレイピングする必要がある．
しかしメトリクスを収集する対象が多くなるとPrometheus の設定が複雑になり，監視対象やア
ラートルールを追加，変更する際のコストが上がってしまう．Prometheus Operator が提供する Ser-

viceMonitor や PodMonitor などの CRD により，スクレイピング対象が多い場合でも監視対象やア
ラートルールの追加，変更が容易になる．

• ノードダウンなどにより Pod の IP アドレスが変わった場合，Redis Sentinel では IP アド
レスの変更を把握できない．このためフェイル
オーバーを繰り返すことにより⾒かけ上はダウン状態の Pod が増え続けることになり，最終的にフェイルオーバーができなくなる．

• 上記の問題を解消するために各 Pod にサイド

5.2

メンテナンス管理

Kubernetes 環境上でのアプリケーションなどを運⽤する場合，その利⽤者がメンテナンスなどを⼿動かつ定期的に⾏うことは極⼒排除することが望ましい．本項ではメンテナンス管理に関連する取り組みの⼀例を紹介する．

カーコンテナを配置して定期的に各 Sentinel の状態を管理および制御することはできる．しかしこの場合は各 Pod の中ですべての Sentinelの状態監視，更新などの処理を実装する必要があるためしくみが複雑となる．

コンテナレジストリ認証トークンの⾃動更新

lab-k8s で は 共 通 コ ン テ ナ レ ジ ス ト リ と し てECR を使⽤している．しかしオンプレミス上の
lab-k8s から ECR の Docker イメージを Pull すRedis Operator で Redis Sentinel による HA 環

る場合，それぞれの利⽤者が認証トークンを im-境を構築した場合，上述した Pod の IP アドレス

agePullSecret として指定する必要がある．さらに*9 https://github.com/spotahome/redis-operator*10 https://redis.io/topics/sentinel*11 https://github.com/coreos/prometheus-operator

6 ワークロードに対する最適化

11

ECR の認証トークンには期限が設定されているた

3. ガベージと判定された PV リソースの reclaim-

め，利⽤者は認証トークンの指定および⾃動更新

Policy を Delete に更新することで OpenStack

を各⾃で導⼊して運⽤する必要がある．

側の Cinder Volume を削除する．

各⾃でそのようなしくみを導⼊する煩雑さを解消するために，ECR の認証トークンを⾃動的

6 ワークロードに対する最適化に設定および定期更新するためのエージェント
を各ノードに DaemonSet として配置している．

秋葉原ラボのアプリケーションは機械学習など

Kubernetes ではイメージの Pull は各ノード上のにより⽣成されたモデルなどを活⽤するものがあkubelet が担当しているため，エージェントではるため，ETL のようなワークフロー∕バッチ関連

kubelet が参照する認証トークンを定期的に更新のワークロードを⼤量かつ並列に動かすことが要している．以下にエージェントの処理内容を⽰す．

求される．ここでは最適化に関する取り組みの⼀部について紹介する．

1. AWS から新しい ECR 認証トークンを取得
2. 取得した ECR 認証トークンをもとに kubelet
向けコンフィグファイルを作成

3. ⽣成した kubelet 向けコンフィグファイルを
kubelet に反映

6.1

OpenStack Port CNI の Port プーリング

前述した OpenStack Port CNI は Pod 単位にOpenStack Port を作成してノードにアタッチするため，バッチなどの⼤量かつ並列に Pod の作成
および削除が発⽣するようなワークロードを運⽤

PV のガベージコレクト
Cinder CSI 経由で OpenStack の Cinder Volume を作成した場合，Kubernetes の PVC リソー
スを削除した時点でこれに対応するボリュームである Cinder Volume は Kubernetes からは利⽤できなくなる．しかし PVC リソースの reclaimPol-icy が Delete 以外となっている場合，OpenStack
では Cinder Volume が削除されず残ったままとな
り，不要なストレージリソースのコストがかかる問題がある．
このような問題に対処するために，PV ガベージ
コレクト機能を controller-runtime*12 をベースに開発して導⼊している．

した場合は OpenStack 側に⼤きな負荷を与えることになり，Pod のネットワーク作成に⾮常に時間がかかったり失敗したりする問題を引き起こすことがある．特に秋葉原ラボでは機械学習などに関連する定期処理バッチが運⽤されているため，これらのバッチが増えるにつれて OpenStack APIの遅延やエラーが増加していった．
この問題に対応するため，前述した CNI エージ
ェントに対して OpenStack Port をプーリングするしくみを導⼊している．具体的には CNI エージ
ェントがインスタンス VM 上の OpenStack Portをプーリングすることにより OpenStack Port を再利⽤できるように改良している．また Kuber-

netes では各ノードのリソース利⽤状況によって

1. Release 済みの PV リソースがある場合，該当特定のノードに対して Pod のスケジューリングがPV リソースに Release ⽇時をアノテーション

集中する場合があるため，これを考慮して Open-として設定する．

Stack Port のプーリング数に下限と上限を設けて2. Release 済みの PV リソースにすでに Releaseいる．下限を超えて確保された OpenStack Port

⽇時がある場合，Release ⽇時から⼀定期間

は⼀定期間未使⽤の状態が続くと⾃動的に削除さ経過したかをチェックしてガベージかを判断

れる．

する．

これによりバッチ処理のような⼤量かつ並列に*12 https://github.com/kubernetes-sigs/controller-runtime

12

1.1 秋葉原ラボの研究開発とシステム運⽤を⽀えるクラウドネイティブ環境

Pod の作成および削除が発⽣するようなワークについては，各 OSS プロジェクトにフィードバッ

ロードの安定運⽤を実現している．

クする予定である．
現在秋葉原ラボの主なサービスは Docker コン

7 まとめ
本稿では，秋葉原ラボにおけるクラウドネイティ
ブ環境である lab-k8s におけるプライベートクラ
ウドのインフラリソースとの連携，および改善のための各種取り組みについて紹介した．lab-k8s では Kubernetes エコシステムの各種ツールや Op-

erator などの導⼊に加えて，独⾃のアドオンを開発したり OSS に対して独⾃の拡張や変更を⾏ったりすることによって，より効率的で信頼性の⾼い環境を提供している．これらの独⾃の拡張や変更

テナ化および Kubernetes 対応が完了しており，

lab-k8s の本番環境に移設されて運⽤されている．
今後は機械学習などの各種実験のためのアドホッ
クなワークロードや CI/CD などの⽤途での利⽤を促進することで研究開発およびシステム運⽤のさらなる改善を⽬指していく．また，GPU などの専⽤ハードウェアを搭載したマシンをクラスタに組み込むことにより，機械学習など⼤きな計算リ
ソースを必要とするワークロードの⾼速化および効率化を⾏う予定である．

13
Akihabara Lab

1.2

スキーマ定義に基づき key-value ストアにアクセスする API サーバの構築と運⽤

渡邉 敬之

概 要 システムの整理統合をするために，宣⾔的にスキーマを定義することで key-value ストア上のデータをテーブルとしてアクセスする API サーバ（開発コード:Zumwalt）について紹介する．key-value スト
アを使う場合，データを key-value の形式に変換する．この変換処理はアプリケーションによって異なり，アクセスパターンの変更には変換処理⾃体の修正が必要となる．そのため技術的負債や属⼈化の原因となる．紹介する API サーバはスキーマ定義に基づき変換を⾃動化することで key-value ストアの知識がない開発者でも key-value ストアを利⽤したアプリケーション開発・保守が可能となる．本章では，
key-value ストアを⽤いたアプリケーション開発の課題と秋葉原ラボで開発運⽤しているスキーマ定義に基づき key-value ストアにアクセスする API サーバの構築と運⽤について述べる．
Keywords key-value ストア，HBase，Kubernetes

1 はじめに当社のメディア事業では ABEMA や Ameba ブ
ログなどのサービスを提供しており，ユーザの⾏
動ログなどさまざまなデータが⼤量に発⽣している．このデータをうまく活⽤することがサービスの改善を⾏う上で重要になる．⼤量のデータを効率的に処理するためには key-value ストアの利⽤が有⽤である．key-value ストアは Key と Value
のみで構成されるシンプルなデータ構造をもち，Key を指定するとそれに紐づいた Value に対して操作できる機能を提供する．データ構造がシンプ
ルなため，⼤量のデータを低コストで容易に分散管理でき，かつ⾼速にデータの読み書きができる．
そのため従来の関係データベースに⽐べて⾼いス
ループットを出すことができる．
⼀⽅で，key-value ストアを利⽤したアプリケー
ション開発は関係モデルで表現されるアプリケー
ションデータと key-value の変換処理が必要になるため，関係データベースのみを⽤いたアプリケー

ションに⽐べて複雑になる．また，アプリケーショ
ンデータをどのように key-value として変換する
かはアプリケーション全体の性能に影響を与える．
そのため，アプリケーションのアクセスパターンに基づいて適切に key-value を設計する必要がある．
各アプリケーションで適切に key-value の設計をするということは，アプリケーションごとに異なった変換処理を実装しなければいけないということである．また，アプリケーションの仕様の変
更でアクセスパターンが変わってしまった場合には，key-value の設計も変更する必要があり，その結果，変換処理の実装まで書き換える必要がある．
これらのことから key-value ストアを⽤いたアプ
リケーションは実装や保守にかかるコストが⼤きいという問題がある．
本章では，スキーマ定義に基づき変換処理を⾃動化する技術 [1] についての概要を説明し，その技術を組み込んだ API サーバの構築と運⽤に関して記述する．2 節では，key-value ストアのスキーマ

1.2 スキーマ定義に基づき key-value ストアにアクセスする API サーバの構築と運⽤

14

設計について述べる．3 節では，スキーマ定義に位で分割しており，Region は RowKey の範囲に基づく API サーバの実装について述べる．4 節でよって分割される．そのため，同じ RowKey をは，スキーマ定義に基づく API サーバの構築と運もっているデータは必ず同じ Region に所属する．

⽤について述べる．5 節では，まとめと今後の取りさらに，同じ Region 内のデータは ColumnFamily

組みについて述べる．

単位でさらに分割される．そのため，同時にアクセスする Qualifier を同じ ColumnFamily にまと

2 key-value ストアのスキーマ設計

めるとよい．

key-value ストアを利⽤したアプリケーション

2.2

HBase のスキーマ設計

では，関係モデルで表現されるアプリケーション

key-value の設計はアプリケーションの性能に⼤データを key-value として変換する必要がある．

きな影響を与える．そのため，開発者はアクセス

その際，どのようにアプリケーションデータをパターンに基づいて適切に設計する必要がある．

key-value へと変換するかは重要である．アクセス

HBase においても前述の通り RowKey と Colum-

パターンにあった設計をできれば，効率的に key-nFamily がインデックスとなっているため，アプ

value を読み書きできるからである．本稿ではこのリケーションデータをマッピングする際に意識し変換⽅法の定義をスキーマと呼ぶこととする．

て設計する必要がある．

本節では，key-value ストアの⼀種であり秋葉図 1.2.1 を例として HBase におけるスキーマ設

原ラボにおいても利⽤されている Apache HBase

計を説明する．これはアプリケーションデータと（以下，HBase と呼ぶ）を例として説明し，スキー

key-value の変換の例であり，1 種類のアプリケー

マ設計がアプリケーション性能に与える影響と実

ションデータを 2 種類の異なる key-value へと変装における課題について議論する．

換している．

2.1

HBase のデータ構造

HBase*1 は BigTable [2] の設計を元にして作られたデータベースである．HBase の論理データ構
造は関係データベースと同じ表形式であり，各⾏はRowKey で⼀意に識別され，各列は Qualifier で構成される．また，Qualifier をグルーピングする

ColumnFamily と呼ばれる概念がある．RowKeyと Qualifier が交差する部分にデータ（Value）とタイムスタンプを保持するようになっている．
⼀⽅で物理データ構造ではデータは key-value
形式で格納され，RowKey，ColumnFamily，Qual-• 変換 1： RowKey にキー属性である key1 とkey2 をセパレータ⽂字（,）で連結して配置している．Value に⾮キー属性である value1，

value2 をセパレータ⽂字（,）で連結して配置している．

• 変換 2： RowKey に key1 をハッシュ化した値の 3byte を先頭に付与し，それに続けてそれぞれの⽂字数を接頭辞として key1，key2 をつなげたものを配置している．Qualifier に⾮キー属性である value1，value2 を異なる key-valueに配置している．

ifier，タイムスタンプの 4 つの Key を構成する

変換 1 は key1 を使った範囲検索をするのに適しフィールドに対して Value が対応している．また，ている．また，アプリケーションデータが 1 つのRowKey，ColumnFamily，Qualifier，タイムスタ

key-value で表現されるので空間効率がよくなる．

ンプの優先度で Key がソートされて格納されて⼀⽅で，同じ値をもった key1 が連続するためアクいる．

セスが集中してしまい，またセパレータ⽂字（,）がHBase では Table のデータを Region という単
*1 https://hbase.apache.org/

key1 の値に含まれてはいけない制約ができる．⾮3 スキーマ定義に基づく API サーバの実装

15

キー属性が 1 つの key-value で表現されているの例を図 1.2.2 に⽰す．これは図 1.2.1 の変換 2 ので不要なデータの読み取りが必要になる場合があ

RowKey をアプリケーションデータへ変換する部

るといったデメリットもある．

分の処理を表している．key-value は内部でバイト変換 2 は先頭にハッシュを付与しているため負配列として扱われている．バイト配列を String 型

荷分散される．key-value は RowKey でソートさへと変換し，セパレート⽂字（,）を探索して key1，

れているため，ハッシュなどを先頭に付与していkey2 に分解する処理を⾏っている．この処理は変ない場合には，似た RowKey が連続してしまいア

換 2 にのみしか使⽤できず，変換 1 ではセパレー

クセスが集中する可能性がある．また，⾮キー属

タ⽂字ではなくキー属性の⽂字数で分割するなど性ごとに key-value を分けているため，属性ごとのの異なる変換処理を実装する必要がある．⼀⽅で，読み書きや新しい属性の追加が容易にできる．たセパレート⽂字で分割したり，ハッシュを先頭にとえば，アプリケーションデータに新たに⾮キー付与して負荷分散するなどスキーマ設計によく使属性である value3 を追加したい場合には，value3

われる共通のテクニックが存在する．

を Qualifier に指定した key-value を追加すれば良い．⼀⽅で，ハッシュを付与することで Key が連

3 スキーマ定義に基づく API サーバの続しなくなり範囲検索ができなくなる．さらに，実装

⾮キー属性ごとに key-value を分けているために

RowKey が重複し Region が分割しにくくなってしまう．
このようにアプリケーションデータを key-valueに変換するさまざまな設計⼿法がある．あるキーに対して正規表現を⽤いて検索したい場合には変換 1 のように先頭に検索したいキーを置く．キー

本節では，スキーマ設計によって異なる変換処理の実装コストを下げるための，アプリケーショ
ンデータと key-value のマッピングの汎⽤化について述べる．本節ではスキーマ定義の記述のみでkey-value ストアにアクセスできる API サーバの実装を紹介する．

に時系列データがある場合には最新のデータが同

API サーバの概要を図 1.2.3 に⽰す．API サー

じリージョンに集まり負荷が集中する可能性があバはアプリケーションデータ（Tuple）を⼊⼒とるので変換 2 のようにハッシュを先頭に付与するなど，アクセスパターンを元に適切にスキーマ設
計することが重要である．

して key-value（Record）を挿⼊する，もしくはSQL-like なクエリ（Query）を⼊⼒としてアプリ
ケーションデータを探索する操作が可能である．
変換処理を⾏うコンポーネントをそれぞれ説明

2.3

変換処理の実装

HBase のような key-value ストアはデータ構造

する．

3.1

Schema Mapping Definition

がシンプルなために，アプリケーションの複雑なSchema Mapping Definition はどのようにス

データとのギャップが存在してしまう．そのためキーマをマッピングするかを定義したファイルで前述のような HBase のスキーマ設計を実現するたある．スキーマ定義の例を図 1.2.4 に⽰す．このめには，アプリケーション開発者がアプリケーショ

図での例は図 1.2.1 のアプリケーションデータとンデータと key-value 間の変換処理の実装を⾏う

key-value の変換を定義したものである．このファ必要がある．変換処理はアプリケーションデータ

イルには 3 つの定義が書かれている．1 つ⽬はリから key-value への変換を⾏うシリアライズとそ

レーションの属性を定義しており，残りの 2 つはの逆に key-value からアプリケーションデータへ

スキーマを定義している．スキーマでは HBase のの変換を⾏うデシリアライズがある．

key-value の各フィールドに対して配置する属性を

HBase における RowKey のデシリアライズのコロン（:）でつなげている．suffix（,）{key1}

1.2 スキーマ定義に基づき key-value ストアにアクセスする API サーバの構築と運⽤

16

アプリケーションデータ

変換1

RowKeyColumnFamily

QualifierValueaaaa,bbbf

RowKeyColumnFamily

QualifierValue

6a2 4 aaaa 3 bbb

fvalue13

6a2 4 aaaa 3 bbb

fvalue2

12{“key1”: “aaaa”,“key2”: “bbb”,“value1”: “3”,“value2”: “12”

変換2

}

3,12

key1,key2はキー属性

図 1.2.1 スキーママッピングの例

アプリケーションデータ
public Tuple deserializeRowKey(byte[]
key){
String buf = new String(key);
String[] splits = buf.split(“,”);tuple.set(“key2”, splits[0]);tuple.set(“key1”, splits[1]);return tuple;}

RowKeyaaaa,bbb{“key1”: “aaaa”,“key2”: “bbb”,}

図 1.2.2 HBase における RowKey のデシリアライズの例

Schema Mapping Definition

insertApplication

select

Tuple

Tuple Serialization

RecordQuery

Query Serialization

Scan

Tuple

Tuple Deserialization

Record

KVS

図 1.2.3 スキーママッピング技術を⽤いた API サーバの概要

や size{key1} は各属性をセパレータ⽂字や⽂の問い合わせにシリアライズするコンポーネント

字数の接頭辞などで分割することを表している．

を実装した．Tuple（アプリケーションデータ）とhash[key1] は key1 をハッシュ化することを表し

Record（key-value）間の変換処理を⾏うコンポーている．

ネントは以下の 3 つがある．

3.2

Tuple と Record 間の変換処理

変換処理は 2.3 項で説明したように，シリアラ• Tuple Serialization: insert 操作においてスキーマ定義に従い Tuple を Record に変換する
処理を⾏う．

イズとデシリアライズを⾏う必要がある．それに• Tuple Deserialization: select 操作において加えて API サーバの実装では SQL-like なクエリ

スキーマ定義に従い Record を Tuple に変換す

でデータを操作できるようにクエリを key-value

4 スキーマ定義に基づく API サーバの構築と運⽤

17

define relation order {key1 string key,
key2 string key,value1 string,value2 string};
define schema layout_1 for orderon hbase(“localhost”) {table “s1”,row hash[key1]:size{key1}key1:size{key2}:key2
family attr_name[key1, key2],
value attr_value[key1,key2]};
define schema layout_2 for orderon hbase(“localhost”) {table “s2”,row suffix(,){key1}:key2,
family “f”,
qualifier “”,
value suffix(“,”){value1}:value2};
図 1.2.4 スキーママッピング定義の例

る処理を⾏う．

• Query Serialization: select 操作においてSQL-like なクエリをスキーマ定義に従い key-

ことができる．そのため，スキーマを定義したファイルを容易に差し替えられるようにすればこの要件は達成できる．

value の問い合わせ（Scan）に変換する処理を• 新たに API サーバを利⽤するアプリケーショ

⾏う．なお，ジョインや集計操作には対応してンを追加できるようにする．また，不要なアクいない．

セスを防ぐため，アプリケーションごとにアクセスできるスキーマを制限できるようにする．

4 スキーマ定義に基づく API サーバの構築と運⽤

• 運⽤や保守の負担を減らすため，スキーマの変
更やアプリケーションの追加が⾏われても監視や障害対策の設定を変更する必要がないように

本節では，スキーマ定義に基づく API サーバのする．

構築と運⽤⽅法について紹介する．

4.1

設計⽅針

API サーバの構築と運⽤をする上で次の内容を考慮して設計を⾏った．

4.2

構築環境

API サーバを構築している環境について説明• アプリケーションの仕様の変更によるアクセス

する．図 1.2.5 は構築環境のコンポーネントを⽰

パターンの変更に対応するため，変換処理の更している．API サーバはコンテナ化され，コンテ新を容易に⾏えるようにする．前節で説明した

ナレジストリである Amazon Elastic Container

ように API サーバはスキーマを定義するだけ

Registry (Amazon ECR) にイメージが保存されでデータストアへ接続しデータにアクセスするている．

1.2 スキーマ定義に基づき key-value ストアにアクセスする API サーバの構築と運⽤

18

lab-k8s

zumwalt

appB

appA
schemadefinition

pull image

schemadefinition

Amazon ECR

zumwalt

zumwalt

図 1.2.5 コンポーネント図

Kubernetes

スキーマ定義ファイルをマウントするようにしてKubernetes はコンテナ化されたアプリケーショ

いる．ConfigMap でスキーマ定義を管理することンのデプロイなどの管理を⾃動化するためのプ

により，API サーバのコンテナイメージに依存すラットフォームである．秋葉原ラボでは独⾃のることなく容易にスキーマ定義を差し替えること

Kubernetes 環境 (以下，lab-k8s と呼ぶ) を運⽤が可能となっている．

している．環境構築や運⽤の負担を減らすため

また，アプリケーションごとに異なる API サーに lab-k8s クラスタ上に API サーバを構築する．

バを構築している．つまり，それぞれに対して使⽤する Kubernetes のリソースは以下の通りでPod，ConfigMap，Service のリソースを作成してある．

いる．図 1.2.5 では lab-k8s 内に appA と appB の• Pod: コンテナを実⾏するためのリソース．
Amazon Elastic Container Registry から API
サーバのイメージを pull し実⾏している．

• ConfigMap: 設定情報などを Key-Value として保持するためのリソース．スキーマ定義ファイルを保存するために使⽤している．

２種類のアプリケーションが構築されている．ア
プリケーションごとに構築することにより，アクセスできるスキーマを制限することが可能となる．
それぞれの Service リソースで Pod へのアクセス制限を設定することで，限られたアドレスからしかその Pod の API を利⽤できないからである．

• Service: Kubernetes クラスタ外と通信を⾏う た め の リ ソ ー ス ．lab-k8s で は Service リ
ソースを作成すると⾃動で外部のロードバラ
ンサーの設定を⾏い，lab-k8s 外から参照できるような仕組みになっている．

API サーバは起動時にスキーマディレクトリを

Helm
Kubernetes のパッケージマネージャである．こ
こでは，テンプレートからマニフェストを作成するテンプレートエンジンとして Helm を利⽤している．

参照し，スキーマ定義を読み込む．そのためスキー

Kubernetes では YAML 形式で書かれたマニ

マディレクトリに ConfigMap として保存してある

フェストファイルを作成してデプロイする必要がある．しかし，システムの規模が⼤きくなると⼤5 まとめ量のマニフェストを作成することになり，管理や

19
送る．

変更を⾏うことが困難になる．そこで，Helm を利⽤することでマニフェストを汎⽤化して扱うことができるため，マニフェストの管理を簡単に⾏う
ことができる．

Helm を利⽤してマニフェストを作成するには，
Template と values の 2 種類のファイルが必要になる．

Grafana
Prometheus で収集したメトリクスの可視化を⾏うツールである．lab-k8s では全プロジェクト共⽤の Grafana が提供されている．共⽤の Grafana
から Prometheus サーバに接続することでメトリクスを可視化している．

• Template: Kubernetes のマニフェストのテ
ン プ レ ー ト と 変 数 を 定 義 す る ．つ ま り API
サーバ共通の部分をテンプレートとし，アプ
リケーションごとに異なる部分を変数として定義する．

Circuit Breaker
データストアへのリクエストを監視し，障害などの発⽣でレスポンスが返ってこなくなった場• values: Template で定義した変数の設定値を合にデータストアを⼀時的に切り離すことができ記述する．アクセス元 IP や接続先の情報など

る．Circuit Breaker を実現するためのライブラ

アプリケーションごとに異なる設定値を記述

リとして Resilience4j*2 を導⼊している．Circuit

する．

Breaker はスキーマ定義単位に作成しており，ス
キーマ定義に記述されているデータストアに障これらのファイルからアプリケーションごとのマ

害が発⽣した場合にはデータストアを切り離しエニフェストを作成し，lab-k8s クラスタへ API サー

ラーをすぐ返すようにする．エラーをすぐ返すこ

バをデプロイしている．

とで障害発⽣時でも応答時間を維持することがで

4.3

監視と障害対策

API サーバの監視と障害対策に利⽤している
ツールとその設定を紹介する．

Prometheus

き，他のスキーマ定義に記述されている正常なデー
タストアへのリクエストの影響を少なくすること
ができる．

5 まとめ

オープンソフトウェアの監視ツールであり，時系列で様々なメトリクスを収集することができる．

本稿では，スキーマ定義に基づく API サーバ

Prometheus は様々なコンポーネントで構成され（開発コード: Zumwalt）を紹介した．アプリケーているが，API サーバの監視は lab-k8s クラスタ上

ションデータと key-value 間の変換処理を⾃動化に Prometheus サーバと AlertManager を構築ししスキーマ定義として宣⾔的に記述することで，ている．Prometheus サーバはメトリクスの収集

key-value ストアを利⽤したアプリケーションを統と保存を⾏うコンポーネントであり，API サーバ

合でき，開発や運⽤の負担を減らすことができるのスループットやレイテンシなどのメトリクスをようになった．

収集している．Prometheus サーバに設定してあ

今後の予定として，属⼈化を排除するためにス

るモニタリングの閾値を越えると，AlertManager

キーマ定義登録から API サーバ⽴ち上げまでのへアラートのリクエストが送られ，AlertManager

⾃動化をすることで管理者の負担を減らす予定ではそのリクエストを元に外部のシステムに通知をある．

*2 https://resilience4j.readme.io/1.2 スキーマ定義に基づき key-value ストアにアクセスする API サーバの構築と運⽤

20

参考⽂献

Hsieh, D. A. Wallach, M. Burrows, T. Chandra, A. Fikes, and R. E. Gruber. Bigtable:[1] 善明 晃由, 津⽥ 均. スキーマ定義に基づく

A distributed storage system for structured

SQL ライクな Key-Value ストアクライアン

data. In Proceedings of the 7th USENIXト, 第 8 回データ⼯学と情報マネジメントに関Symposium on Operating Systems Design

するフォーラム (DEIM2016), 2016.

and Implementation — Volume 7, OSDI ’06,

[2] F. Chang, J. Dean, S. Ghemawat, W. C.

p.15, 2006.

21
Akihabara Lab

1.3

ストリーム処理を考慮したデータ転送管
理システムのレイヤ化

新平 和礼

概 要 インターネットサービスを提供するシステムは⽇々さまざまなデータを出⼒する．これらのデータはBI ツールによるデータ分析や効果測定，推薦や検索などのさまざまな⽤途で利⽤される．データを活⽤するためには⼤量のデータを⽬的のシステムに転送しなければならない．その際，データの種別によって利⽤⽬的が異なるため，データごとに適切なシステムへ転送する必要がある．また，転送中のデータに対し，
不正なフォーマットのデータを排除するフィルタリングや転送先システムに応じたデータ加⼯などの処理が求められる．適⽤する処理についてもデータを⽣成したシステムやデータの種別，⽤途などの条件によって異なるためデータに応じた設定が求められる．データ転送⽤のミドルウェアを⽤いることでデータ転送や転送中のデータに対する処理の適⽤が可能となるが, 単⼀のミドルウェアでさまざまな経路を管理することや，転送と転送中のデータに適⽤する処理が深く結び付くことなどから転送設定が複雑化するという課題がある．本稿ではこれらの課題を解決するためデータ転送の責務を分離する階層構造を提案し，本階層構造に基づくデータ転送を提供する基盤について述べる．

Keywords

ストリーム処理，データマネジメント，データ転送

1 はじめに転送の信頼性確保や，ミドルウェアを起動するマシンの追加による処理性能のスケールアウトの機システムが⽣成するデータは BI ツールによる能を提供する．ミドルウェアの機能を利⽤するこ

データ分析や効果測定，外部システムとの連携なとで，各転送経路の信頼性やスケーラビリティをどさまざまな⽤途で利⽤される．また，システム向上できる．

が出⼒するデータの利⽤⽬的は多岐にわたり，利しかし，単⼀のミドルウェアで多数の経路を管⽤⽬的によってリアルタイム処理やバッチ処理な理する場合， 経路の増加とともにデータ転送ミド

ど異なるシステムでデータを処理する必要がある．

ルウェアの設定が複雑になる．その要因として，

そのため，データを活⽤するためにはさまざまなデータの形式や経路選択の設定⽅法，適⽤する処システムが出⼒したデータを⽬的に応じたシステ

理が経路ごとに異なる点があげられる．データ転ムに転送しなければならない．

送の経路には異なる⽤途，形式のデータが混在す

データ転送や転送中の処理の適⽤を実現するソ

るため，それぞれのデータから転送先の情報を抽出

フトウェアとして Apache Flume*1 や Fluentd*2 な

し適切な宛先に転送する必要がある．また，デー

どのデータ転送ミドルウェアがあげられる．これ

タ転送においては転送先システムへのデータ投⼊らのミドルウェアは到達保証設定に応じたデータ*1 https://flume.apache.org*2 https://www.fluentd.org/

1.3 ストリーム処理を考慮したデータ転送管理システムのレイヤ化

22

前に不正な形式のデータを排除したり，重複したるデータは JSON 形式となっており，メッセージ

データを排除するなどの前処理が必要となるケー

キューへ転送を⾏う必要がある．また，システム

スも存在する．これらの条件が異なる複数の経路

B が⽣成するデータは TSV 形式となっており，スが同⼀のミドルウェアの設定に混在することで設トレージへデータ転送を⾏うものとする．

定が複雑化する．
また，転送ミドルウェアにおける設定では，転送設定と処理が密に結合する課題がある．適⽤する処理内の関数の戻り値ごとに転送先を設定するな
ど，転送先の設定と処理の実装が混在し，転送経路の把握が困難となる．
本課題を解決するために我々はデータの転送情報を抽象化してレイヤ構造として定義する取り組

図 1.3.1 転送設定の異なる経路が混在する転送構成例

みを⾏っている．データ転送のレイヤ化ではデー
タ転送の責務を 4 つの階層で定義することで，デー⼀般的なデータ転送ミドルウェアでは，異なる

タ転送における経路の選択⽅法を共通化するとと複数のポートでデータを受信することでこのよ

もに，アプリケーションレベルの処理とデータ転うな異なる条件や宛先の転送設定を実現できる．

送を分離する．

図 1.3.1 の例では JSON 形式のデータを 41414 番

本稿ではレイヤ構造に基づくデータ転送処理基ポートで待ち受け，TSV 形式のデータを 41415

盤を試作し，本基盤上でデータ転送を⾏う事例を番ポートで待ち受けることで条件の異なる形式の紹介する．本稿の構成を以下に⽰す．2 節で既存データをそれぞれ異なる宛先へ転送できる．

のデータ転送における課題について述べる．3 節

しかし，この設定⽅法ではデータ形式の差異がミでは本稿で提案するデータ転送の定義について説

ドルウェアのネットワーク設定にまで波及してい

明し，4 節で開発したデータ転送処理基盤のアーキ

る．送信側でデータの形式に応じてポートを選択

テクチャについて述べる．5 節で本システムの適する必要がある点やポート番号の変更時にデータ

⽤事例について述べ，6 節で本稿をまとめる．

の送信側と受信側で同期的に設定変更する必要が*3あることなど，データ転送の管理が複雑化する．

2 背景
本節ではデータ転送の設定が複雑になる要因について述べる．

2.2

処理と転送の結合

データ転送⽤のミドルウェアでは転送中のデー
タに対しストリーム処理を適⽤できる．2.1 項で⽰した条件の転送は本機能を利⽤することでも実現

2.1

転送設定の異なる経路の混在可能である．

転送設定の異なる経路が混在することにより複図 1.3.2 にストリーム処理を適⽤する場合の転雑化するデータ転送の構成例を図 1.3.1 に⽰す．

送構成例を⽰す．本転送設定では 41414 番ポート

本構成では，拠点 1 に構築されたシステム A，B がでデータを受信し，受信データに対し独⾃に実装し⽣成するデータをストレージとメッセージキュー

た処理である DataSelector を適⽤する．DataSe-の 2 ヵ所へ転送する．拠点 1 に配置されたシステ

lector は受信データの形式に応じた分岐処理を⾏ム A，システム B はそれぞれ異なる運⽤が⾏わう機能を有し，これにより受信ポートの設定を分れ，データの形式も異なる．システム A が⽣成す

離せずにデータ形式に応じた転送先の選択を実現*3 独⾃のプラグインを実装することでネットワーク設定への影響を軽減できるが，後述する転送と処理の⼀体化の問題がある．

3 データ転送処理のレイヤ化可能となる．

23
この転送設定を⾏うためにはまず拠点 1 の転送設定を確認し，どの形式のデータを何番ポートで待ち受けているかを把握する必要がある．本例では JSON 形式は 41414 番ポートで待ち受けているため，拠点 2 に対し JSON 形式のデータを拠点 1の 41414 番ポートへ送ることで転送が成⽴する．
このように複数拠点にまたがって転送を成⽴させる場合に複数拠点の設定を理解して設定する必要がある．また，拠点 2 の設定には拠点 1 の 41414
番ポートへ送信するという情報しか記述されない
ため，システム C の転送経路全体を把握するには
拠点 1，拠点 2 両⽅の設定をすべて確認する必要が⽣まれる．このように経路選択ロジックが局所化

図 1.3.2 プラグイン処理によるデータ転送の構成例

⼀⽅で本設定では転送設定が処理の実装に依存
し，⼀体化するという問題がある．たとえば本設
定では 41414 番で受信したデータに対し処理を適⽤する設定を⾏うが，その処理内容は実装に依存する．処理の内容を理解した設定が必要になるな
ど，転送時に⾏う処理と転送設定が⼀体化することで経路設定の難易度が上がり，経路の把握も難
しくなる．

2.3

複数の拠点をまたぐ転送経路の管理することで全体の転送設定の把握が困難となる．

3 データ転送処理のレイヤ化
データ転送における課題の要因として，共通的な転送先の決定⼿順や宛先情報の定義が存在しな
いこと，転送中のデータの加⼯やフィルタ，分岐といった処理内容と転送が密に結合していることがあげられる．
これらの課題を解決するため，データ転送の責
務を 4 層に分離するレイヤ構造（以降，データフ
ローレイヤ）を提案する．データフローレイヤではデータ転送における⼿続きの共通的な規定と責務の分離を⾏う．本節では，データフローレイヤの階層構造とレイヤ化による課題解決について説
明する．

3.1
図 1.3.3 経路を追加する場合のデータ転送の構成例

データ転送におけるレイヤ構造

データフローレイヤは下位レイヤから順にインフラストラクチャレイヤ，リンクレイヤ，ルーティ

複数の拠点をまたぐ転送経路の管理が複雑化す

ングレイヤ，アプリケーションレイヤによって構成る例を図 1.3.3 を⽤いて説明する．図 1.3.3 では図される．各レイヤは最下層のレイヤであるインフ1.3.1 の例に拠点 2 のシステム C からのデータ転ラストラクチャレイヤから順に，レイヤ 1，レイヤ送が追加されている．追加する経路では，システ

2，レイヤ 3，レイヤ 4 と呼称する．データフロー

ム C のデータを拠点 1 のメッセージキューに格納

レイヤにおけるデータ転送処理のフローとデータ

する．対象となるシステム C が送信するデータはの変化を図 1.3.4 に⽰す．

JSON 形式であり，メッセージキューへ転送する
ものとする．

送信処理では上位レイヤから下位レイヤに向かって処理を⾏い，処理したデータを下位レイヤ

24

1.3 ストリーム処理を考慮したデータ転送管理システムのレイヤ化

図 1.3.4 データフローレイヤの送受信処理イメージに引き渡す．また，各レイヤは上位レイヤから受での送達管理を⾏う．

け取ったデータに対し，それぞれのレイヤで必要
レイヤ化による課題解決となる転送情報を付与する．ここで各レイヤで付

3.2

与する情報をヘッダと呼ぶものとする．

転送設定の異なる経路の混在

受信処理では下位レイヤから上位レイヤに向2.1 項では転送設定が異なる経路が混在する構

かって処理を⾏い，処理したデータを上位レイヤ

成を例に，ミドルウェアの待ち受けポート番号をに引き渡す．上位レイヤでの処理内容の変更が下送信側が意識する必要があることを⽰した．また，

位レイヤの転送処理に影響を与えてはならない．

これによりミドルウェアの増設やポート番号変更

受信処理では各レイヤは上位レイヤにデータを引などの設定変更が送信元の設定にも影響を与える

き渡す際，それぞれのレイヤのヘッダ情報を削除すことを述べた．

ることで上位レイヤに必要なデータのみを伝達す

データフローレイヤではこれらの課題を解決する．各レイヤの責務の詳細について以下で述べる．

るため隣接する転送装置間のデータ転送をインフ

アプリケーションレイヤ — アプリケーション

ラストラクチャレイヤとリンクレイヤに分離する．

レイヤはアプリケーション固有の規定を定める．

リンクレイヤでは隣接する転送機能間のデータ転サービスや⽤途に応じたデータ形式の規定はアプ送の責務を担い，インフラストラクチャレイヤはリケーションレイヤの責務となる．データ転送中

具体的なミドルウェア実装による転送処理を管理のデータの変換やフィルタなどのロジックについする．

てもアプリケーションレイヤで処理される．

リンクレイヤはミドルウェアの IP アドレスやルーティングレイヤ — ルーティングレイヤは

ポート番号で識別される送信先を抽象化する．同

データ転送における経路選択の責務を担う．本レ

⼀設定で実⾏される複数のミドルウェアをリンク

イヤで管理する経路情報に従いデータの宛先に対

レイヤでは 1 つの宛先としてみなすことが可能とする経路を選択し，次の送信先を決定する．

なり，インフラストラクチャレイヤのミドルウェ

リンクレイヤ — リンクレイヤでは隣接するデー
タ転送装置間のデータ送受信を管理する．上位レ

アにおける設定変更や増設などの変更をリンクレ
イヤから隠蔽できる．

イヤから受領したデータおよび送信先を解釈し，ミドルウェアレベルの宛先情報に変換したうえでインフラストラクチャレイヤにデータと宛先を渡す．
インフラストラクチャレイヤ — インフラストラ
クチャレイヤはデータ転送に利⽤するミドルウェ
アを管理する責務を担う．ミドルウェア実装によるデータの送受信を担当し，ミドルウェアレベル

転送と処理の密結合

2.2 項で転送設定と処理の結合に関する課題を例⽰した．本課題の原因はデータ処理における分岐や加⼯が転送設定と密に結合することにある．たとえば，加⼯処理によって設定される値をミドル
ウェアの転送設定で参照するなど，ミドルウェア

4 データ転送処理基盤

25の設定において実装によって決定される値の記述

ヤの処理を担当し，インフラストラクチャレイヤが求められるケースが存在する．データフローレ

として⾃⾝が接続するストレージやミドルウェア

イヤではアプリケーションレベルの処理をレイヤを制御している．基盤上のそれぞれの転送処理は4 として定義し，転送処理を⾏うルーティングレイ

レイヤ 1 のミドルウェアによって接続される．

ヤ以下と分離する．これにより，アプリケーショ

本基盤では，転送経路やストレージの差異を吸ンレベルの加⼯や分岐などの処理と転送処理を分収するため，リンクレイヤにおいて Source，Sink

け，転送設定の複雑化を解消する．

と呼ばれるインタフェースを提供する．Source は
データの⼊⼒を定義するものであり，Sink はミド

複数拠点間の経路の混在

ルウェアやストレージへのデータの出⼒を定義す

2.3 項では経路選択の⽅法が標準化されていないるものである．Source，Sink によって転送経路やことによる転送設定の複雑化の例を⽰した．本課

ミドルウェア，ストレージの実装の詳細が隠蔽さ題の要因としては転送先を選択する条件がデータれるため，上位レイヤを特定の実装に依存しない間で統⼀されていないことや，データの最終的な形で定義できる．

宛先情報および宛先に対する次の転送先の情報がルーティングレイヤにおける経路の選択やアプ管理されていないことからミドルウェアの設定にリケーションレイヤにおけるアプリケーション

異なる条件の経路設定が混在し，複雑化することが固有の処理の実装を定義するため，本基盤は In-あげられる．データフローレイヤではルーティン

terceptor と呼ばれるインタフェースを提供する．

グレイヤからインフラストラクチャレイヤでデーInterceptor は⼊⼒データに対する出⼒データを返

タ転送における経路選択に必要な情報と責務を分す関数として定義される．

離し，共通化することで本課題を解決する．
ルーティングレイヤは経路情報を管理し，最終的な宛先と宛先に対する次の転送先の対応関係を保持する．リンクレイヤは隣接する転送機能間のデータ転送を管理し，インフラストラクチャレイ
ヤは具体的なミドルウェアを利⽤したデータ転送
を⾏う．データ転送に関わる情報と責務を定義することで，データ転送の経路全体を通して共通的な設定⽅法を提供し，設定の複雑化を防ぐことが
できる．

4.2

データ転送処理モデル

本項では本基盤において定義できるデータ転送
処理のモデルについて述べる．データ転送処理の構成例を図 1.3.6 に⽰す．
本基盤では Source，Interceptor，Sink の総称を

Task と呼称し，Task の⼊出⼒の接続を Port と呼称する．転送処理は Task と Port の組み合わせで定義する．Source はミドルウェアから受信したデータ列を出⼒ Port に書き込み，Sink は⾃⾝の⼊⼒ Port に書き込まれたデータを接続するスト

4 データ転送処理基盤

レージやミドルウェアに書き込む．Interceptor は

当社では 3 節で述べたモデルに基づいたデータ

⼊⼒ Port で受信したデータを処理し，結果に応じ転送処理基盤の開発を⾏っている．本節では試作て出⼒する Port を選択する．なお，⼊⼒データにした基盤のシステム構成について記載する．

対し常に 1 つの出⼒ Port を選択する Interceptor
を Transform と呼び，⼊⼒データに対し複数の出

4.1

データ転送処理基盤の概要

⼒ Port を選択可能な Interceptor を Router と呼図 1.3.5 に本転送処理基盤によるデータ転送の称する．また，Router において出⼒ Port を 2 つ

概要を⽰す．本基盤は各拠点に配置され，それぞ保持する Interceptor を Filter と呼ぶこととする．

れのデータ転送をストリーム処理として実⾏する．

開発した基盤では本項で述べた Task の構成情

本基盤はリンクレイヤからアプリケーションレイ

報を DSL で記述することで転送処理を構築し実⾏

1.3 ストリーム処理を考慮したデータ転送管理システムのレイヤ化

26

図 1.3.5 データ転送処理基盤による転送処理の概要

できる．DSL の記述例については 5 節で述べる．

4.3

ユーザはデータ転送処理を⾏う Pipeline 構成を定義し，API にリクエストを送信する．API

システム構成は Orchestrator に Pipeline の実⾏を要求し，Or-開発した基盤の構成を図 1.3.7 に⽰す．

chestrator は管理する複数の Manager からユーザ
リクエストに応じて適切な Manager を選択する．

Manager はユーザが定義した Pipeline 構成を検証し，実⾏エンジンに適した処理に変換して転送処理を起動する．

5 適⽤事例
図 1.3.7 データ転送処理基盤のシステム構成

本基盤はユーザが定義したデータ転送処理を受領し，構成情報をパース，ストリーム処理に変換し，Apache Flink などの実⾏エンジン上で実⾏することでデータ転送処理を実現する．本基盤はユーザ

本節では 4 節で述べたデータ転送基盤によるデータ転送の適⽤例について記載する．以降の説
明では適⽤例としてデータの品質チェックを伴う
データの転送を⽤いる．本処理の構成を図 1.3.8 に⽰す．

からのリクエストを受け付ける API，実⾏エンジンの管理を⾏う Manager，複数の Manager や実⾏
中の Pipeline を統括管理する Orschestrator で構成される．Manager は実⾏エンジンを管理しデー
タ転送処理を実⾏する機能部であり，実⾏エンジ

図 1.3.8 処理を伴うデータ転送の構成例

ンごとの差分を Manager が吸収することで本基盤では複数の実⾏エンジンの利⽤を可能とする．

本処理では Kafka からデータを取得し， 取得

図 1.3.6 ストリーム処理の構成

6 まとめ27

したデータが定められたフォーマットに準拠して

ここで，図 1.3.9 に⽰す Source，Sink の設定はいるかを判定する．判定の結果に基づき，フォー

基盤に事前登録することが可能となっている．こ

マットに準拠しているデータとフォーマットに準れらの設定を基盤に事前登録しておくことでデー

拠しないデータを異なる宛先へ転送する．

タ転送処理を記述する利⽤者からインフラストラ

図 1.3.8 の転送を試作したデータ転送処理基盤

クチャレイヤの転送情報を隠蔽できる．これらはで実⾏する際の設定を図 1.3.9 に⽰す．なお，ここ

基盤管理者によって設定されるため，データ転送で利⽤した Task は簡単のためルーティングレイ

処理を起動する利⽤者はインフラストラクチャレ

ヤによる経路選択は⾏わず，Sink による固定的なベルレイヤの接続情報を意識することなく転送設

宛先へのデータ送信を⾏う処理として実装した．

定を記述可能となる．

図 1.3.9 の上部は転送処理の実⾏時にユーザが記述する DSL を⽰している．本基盤の DSL では tasks セクションで転送処理の接続関係を定義する．14–19 ⾏⽬に記述した Filter 処理でフィル
タリング処理を⾏い，Filter の出⼒ポートである

valid port，invalid port でポート名を定義することで後続の処理との接続関係を記述する．Valida-

tionFilter は type が Filter であることから，分岐を伴う処理であることは本設定から明らかであり，ユーザは出⼒ポートに対して後続処理を設定する
ことで，実装で決定する値を意識することなく分岐を含むデータ転送を定義することが可能となる．

6 まとめ
本項では既存のデータ転送が複雑化する要因について述べた．また，データ転送管理における設定の複雑化を改善する枠組みとしてデータ転送の情報を階層化して定義するデータフローレイヤを提案し，本定義に基づくデータ転送処理を⾏う基盤を試作した．試作した転送処理基盤におけるデー
タ転送処理の適⽤事例を⽰し，データ転送における関⼼の分離ができることを確認した．
今後は，データフローレイヤの仕様を詳細に定義
し，より⼤規模な転送管理に適⽤する予定である．

28

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

1.3 ストリーム処理を考慮したデータ転送管理システムのレイヤ化--global_option :name : " example "description : " pipeline for example "runner :type : FLINK
parallelism : 3tasks :
kafkasource :type : Source
ref : " kafka_source "output_port : " kafka_source "validation :type : Filter
i mp le m e nt e d _ cla ss : | com . example . task . filter . ValidationFilte r
input_port : " kafka_source "valid_port : " validation_ok "invalid_port : " validation_ng "ok_kafkasink :type : Sink
input_port : " validation_ok "ref : " ok_kafka_sink "ng_kafkasink :type : Sink
input_port : " validation_ng "ref : " ng_kafka_sink "kafaka_source :type : Source
i mp le m ent e d _ c la ss : com . example . source . KafkaSource
output_port : " O V E R R I D E _A T _ R U N T I M E " # 実⾏時に決定される
properties :topic : " test_input "bo o ts t ra p _ s e rv e rs : " kafka01 . server :9092
ok_kafka_sink :type : Sink
im p l em en t e d _ c la ss : com . example . sink . KafkaSink
input_port : " O V E R R I D E _ A T _ R U N T I ME " # 実⾏時に決定される
properties :topic : " ok_topic "b oo ts t r ap _ s e rve rs : " kafka01 . server :9092
ng_kafka_sink :type : Sink
im p l em en t e d _ c la ss : com . example . sink . KafkaSink
input_port : " O V E R R I D E _ A T _ R U N T I ME " # 実⾏時に決定される
properties :topic : " ng_topic "b oo ts t r ap _ s e rve rs : " kafka01 . server :9092

図 1.3.9 Validation を⾏う DSL 定義例29
Akihabara Lab

1.4

ストリーム処理におけるステートフル
データの管理⼿法

斎藤 貴⽂

概 要 ストリーム処理においてステートフルなデータを簡潔に処理するための解析基盤 Phalanx について解説する. ストリーム処理ではイベントの到着順序が保証されないため，更新順序を考慮する必要があるス
テートフルなデータの扱いが難しい．Phalanx では CRDT のデータモデルに基づいて，ステートフルなストリーム処理を実現する．CRDT で⽤いられるデータ型は更新の順序を問わず同じ状態となることが保証されるため，データの到着順序が保証されない状況でのステートフルなデータへの管理を簡素化できる．そのような結果整合性をもつデータ型を利⽤することで，Phalanx ではイベントを CRDT の操作に対応付ける記述のみでステートフルなデータの変更を実現できる．

Keywords

ストリーム処理，CRDT

1 はじめにタがある．ステートフルデータとは現在の状態に依存して次の状態が決まるデータである．イン

近年，インターネットサービスのデータ解析においてストリーム処理は重要視されている．スト
リーム処理ではイベントという単位のデータを⼊⼒として受け取り逐次処理する．そのため⼊⼒
データを時刻で区切った単位でまとめて処理を⾏
うバッチ処理に⽐べてリアルタイム性の⾼い処理を⾏うことが可能である．
実運⽤におけるストリーム処理のイベントはさ
まざまなライブラリやシステムの転送パイプラインを経てストリーム処理エンジンに届けられるため，ストリーム処理ではイベントが発⽣した時刻と同じ順序でストリーム処理エンジンに届くという保証はない．たとえばパイプライン中の転送経路を並列化した場合，負荷の不均質が原因で経路間で転送速度が異なり到着順序が⼊れ替わる可能性がある．
転送順序が保証されないためストリーム処理で扱うことが困難なデータとしてステートフルデー

ターネットサービスにおけるステートフルデータにはソーシャルゲームのユーザの所持アイテムリ
スト，Web サイトの PV やセッション数など多岐に渡る．
ストリーム処理でステートフルデータを更新することでリアルタイムで最新の状態を参照できる
ようになる．しかしステートフルデータの変更は現在の状態に依存し，ストリーム処理ではイベントの順序が保証されないのでステートフルデータの整合性を維持するのが難しい．
本章ではストリーム処理においてステートフ
ルなデータ処理を簡潔に記述するための処理基盤

Phalanx について説明する．Phalanx では CRDT
（Conflict-free Replicated Data Type）[1] のデー
タモデルを参考に更新順序が保証されない場合も同じ状態になることを保証する結果整合性をもつ
データ型を⽤意している．結果整合性を担保する
データ型を利⽤することで更新の順序を考慮する

1.4 ストリーム処理におけるステートフルデータの管理⼿法

30

図 1.4.1 イベントの順序に変更がないときの例

図 1.4.2 購⼊取消イベントが購⼊追加イベントより先に到達した例

ことなく，イベントとステートフルデータへの操

時刻順に到達した場合を表している．このときア作を対応付けるのみでストリーム処理でステート

イテムリストは正しい状態でデータストアに反映

フルデータを扱うことが可能になる．

される．⼀⽅，図 1.4.2 では時刻 t0 のアイテム購
⼊イベントが時刻 t1 のアイテム購⼊取消イベント

2 背景

より遅れて到達した場合を表している．このときアイテムリストには本来削除されるはずのアイテ

ステートフルストリーム処理について

ム A が存在する．これはアイテムの購⼊取消をア

バッチ処理でステートフルデータの変更を⾏う

イテムの購⼊後に対して⾏うはずであるのに，更場合，実際のイベントの発⽣時刻とステートフル

新の順序が⼊れ替わることでアイテムが存在しな

データへの変更が反映されるまでの時刻に差異がい状態のリストに対してアイテムの購⼊取消を試⽣じる．たとえば⽇次バッチ処理によってステーみるためである．

2.1

トフルデータを変更する場合，発⽣したイベント

このようにイベントの順序が⼊れ替わることでは翌⽇にならなければステートフルデータに変更

更新の順序も⼊れ替わりステートフルデータに対が反映されない．対してステートフルストリームして誤った変更を⾏うことが起こりえる．

処理ではリアルタイムにステートフルデータの変更が可能なので最新のデータを参照できる．

3 Phalanx のシステムデザイン

しかし，ストリーム処理でステートフルデータを扱うことは難しい．それはストリーム処理ではイベントの到着順が保証されないためである．

本節ではステートフルストリーム処理基盤である Phalanx のシステムについて説明する．

ソーシャルゲームにおけるユーザのアイテム
リストをストリーム処理で更新する例を挙げ

3.1

システムの概要

る．イベントにはアイテムの購⼊を表すイベン

ステートフルストリーム処理を実現するためにト（type=buy）とアイテムの購⼊の取り消しを表はイベントが順不同で到達する状況で整合性を保す購⼊取消イベント（type=cancel）の 2 種類がつ必要がある．Phalanx では CRDT [1] という流れると仮定する．2 つのイベントにはアイテム

データの更新の順序を問わず結果整合性を担保す名が付与される．ストリーム処理エンジンは購⼊るデータ型を参考にしてデータ型を⽤意した．

イベントが到達するとアイテムリストにアイテム

CRDT（Conflict-free Replicated Dataを追加する．購⼊取消イベントが到達するとアイ

Type）は分散環境における個々の複製への更新

テムリストに該当のアイテムが存在する場合アイを複製間で衝突させずに結果整合性を担保する

テムをリストから削除する．図 1.4.1 はイベントがためのデータ型である．CRDT には Operation-

3 Phalanx のシステムデザイン

31

based（Commutative Replicated Data Types,

づいてイベントを更新操作に変換し Storage に追CmRDTs）と State-Based（Convergent Repli-

加する．

cated Data Types, CvRDTs）の 2 種類が存在

ステートフルデータを参照する際には Serving

する．CmRDT は複製の更新操作を可換にするこ

Layer に問い合わせる．Serving Layer ではテーブとで更新が順不同であっても必ず同じ状態になる

ルスキーマに従って Storage の更新操作をデータことを保証する．CvRDT は参照する際に可換か型の集約関数を⽤いて集約した結果を返す．

つ結合的である集約関数を⽤いてすべての複製を結合する．集約関数は可換であるため CmRDT 同様，各複製への更新が順不同であっても整合性を担保する．

Phalanx では CmRDT を参考にして，更新時に

3.2

Phalanx のデータモデル

本項では Phalanx のデータモデルについて説明する．まず Phalanx のデータ型について説明する．次にデータ型を踏まえて Storage のデータ構

ステートフルデータを変更するのではなく更新操造について説明する．最後に Phalanx のメタデー

作を保存し*1 ，更新操作を集約してステートフル

タについて説明する．

データとして提供する．このデータ型によってス
トリーム処理においてイベントの発⽣と到着の順

Phalanx のデータ型序が不同であっても参照時に集約することで結果

Phalanx は更新時にステートフルデータを変更

整合性を担保する．また更新時にイベントの到着するのではなく，参照時に更新操作を集約してス順を考慮する必要がなくなるため，ステートフル

テートフルデータを返す．Phalanx のデータ型 D

データの更新の記述を簡略化できる．

は以下のタプルで構成される．

図 1.4.3 は Phalanx のシステムの概要図であD = (P, p0 , U, q)(1.4.1)

る．Phalanx はメタデータを保存する Metadata

Store，⼊⼒イベントを更新操作に変換する Up-

P はステートフルデータへの変更の集合を表す

dater Layer，ステートフルデータへの更新操作を

ペイロードである．P はバージョン V と更新値保存する Storage，ストレージのデータをステー∆ の直積 P = V × ∆ とする．ペイロードのバー

トフルデータとして提供する Serving Layer で

ジョン V は更新の順序を定める値であるので, ペ構成される．

イロード P はバージョンに従って順序付けられる

ま ず ⼊ ⼒ ス ト リ ー ム の イ ベ ン ト は Updater

Layer に渡される．イベントはイベントが発⽣順序集合である．更新値 ∆ はデータ型によって規定される．

した時刻を表すタイムスタンプをもつ．Updaterp0 = (ver0 , val0 ) : ver0 ∈ V, val0 ∈ ∆ はペ

Layer は Metadata Store から Table Schema

イロードの初期値を表す．ver0 は V の最⼩値と（テーブルスキーマ）と Updater Rule（更新ルーする．

ル）の 2 種類のメタデータを参照して処理を⾏

U は⼊⼒イベント E をペイロード P に変換

う．Phalanx ではステートフルデータはテーブル

する更新メソッドの集合である．更新メソッドはスキーマで規定される Table（テーブル）ごとにデータ型によって複数存在することがある．更新

管理する．更新ルールは Updater Layer に届いた

メソッドは⼊⼒イベントとペイロードの間で単調イベントを更新操作に変換する際に⽤いられる．

性を満たす関数である．

テーブルスキーマ・更新ルールについては 3.2 項で説明する．Updater Layer では更新ルールに基q はペイロードを状態に変換する参照メソッド
である．

Phalanx のデータ型は CRDT と同様，データ型*1 Phalanx では複製の扱いについては考えない1.4 ストリーム処理におけるステートフルデータの管理⼿法

32

図 1.4.3 Phalanx のシステム概要に更新メソッドや参照メソッドが⽤意されている．

する集合を保存するための型である．

しかし CRDT と違い，Phalanx では状態を保持す

2P-Set 型 — Set は更新時に与えられた値をるのではなくペイロードを保持し，参照メソッド

要素とする集合を保存するための型であり，2P-を⽤いてペイロードをステートフルデータに変換

Set(Two-Phase-Set) は要素の追加だけでなく削除する．

も可能な集合である．2P-Set は add と remove の

次に Phalanx でサポートするデータ型について

2 つの更新メソッドが⽤意されている．2P-Set 型

いくつか説明する．

は下記の様に表すことができる．

Register 型 — Register 型は更新時に与えられた値を保存するための型である．Phalanx では Last Writer Wins ベースの Register（LWW-

Register）を⽤意している．LWW-Register では最新の更新操作によって与えられた値を返す．Pha-

lanx ではバージョンを元に最新の値を返す．
Register 型は下記の様に表すことができる．
p a y l o ad : V v , X x
i n i t i a l : ver0 , n u l l
3 update :s e t (V u , X y ) : V v , X x
4
let v = u5
let x = y
6 query :query (P ) : X x
7
mv = ver08
mx = n u l l
9f o r p ∈ P do
10
i f p . v > mv
11
then mx = p . x ; mv = p . v ;12l e t x = mx

1
2
3
4
5
6
7
8
9
10
11
12

p a y l o a d : V v , s e t AS , s e t RSi n i t i a l : ver0 , ∅ , ∅update : add (V u , X x ) : V v , s e t AS , s e t RS
let v = ul e t AS = {x}l e t RS = ∅update : remove (V u , X x ) : V v , s e t AS , s e t RS
let v = ul e t AS = ∅l e t RS = {x}query : query (P ) : s e t S
l e t S = ∪P.AS \ ∪ P.RS

1
2

Storage のデータ構造
ペイロードはバージョンによって順序付けられる集合である．そのためペイロードの要素は Stor-

age においてイベントの到着順序にかかわらずイ
ベントの発⽣時刻に基づいたバージョン順に配置される．参照時はペイロードをスキャンしデータ型で規定される参照メソッドを⽤いてステートフ

Set 型 — Set は更新時に与えられた値を要素とルデータへの変換を⾏う．

4 Phalanx の実装

33
カラム名

データ型

user id

要素型

Stringlast login date

RegisterStringitems

SetString

表 1.4.1 Phalanx のテーブル例

メタデータ

4.1

HBase におけるペイロードのフォーマット

テーブルスキーマは Phalanx で扱うアプリケー

Phalanx の Storage には Apache HBase*1 を⽤ションのデータ構造を定義するための記述であい た ．HBase の デ ー タ は Cell と い う 単 位 で 構る．表 1.4.1 はソーシャルゲームにおけるユーザ成される．Cell は Row, ColumnFamily, Quali-のステータスを表すテーブルスキーマの例である．

fier, Timestamp, Value をフィールドとしてもつ．

Phalanx のテーブルスキーマは主キーとステート

HBase の Cell の配置は⾏キー（Row）と列属性群

フルデータの 2 種類のデータを扱うカラムによっ（ColumnFamily）と列属性値（Qualifier）で決めて構成される．主キーはレコードを⼀意に表す値

られる，また Cell は Qualifier の辞書順にソートさでステートフルデータを参照する際に使われる．

れる．Phalanx の実装では Row に主キーの値とス

また複数のカラムを⽤いて複合主キーとしても利テートフルデータを扱うカラム名の順で構成され⽤可能である．ステートフルデータを扱うカラム

るバイト配列を与える．また ColumnFamily は常は必ず 1 つのデータ型と紐付く．またデータ型のに単⼀の値を固定して使⽤する．そして Qualifier

ペイロードの要素値を規定する要素型も定義する．

にバージョンを付与し Value にデータ型に合わせPhalanx では主キーを指定することでステートフ

たペイロードの更新値もしくはスナップショット

ルデータを参照できる．その際，ステートフルデーの集約値を与える．そのため Row ごとのペイロー

タを扱うカラムに紐づくデータ型の参照メソッド

ドはバージョンでソートされた状態で配置される．

に従ってペイロードをステートフルデータへと変
換する．

4.2

ストリーム処理の到達保証

更新ルールはストリームで流れてくるイベント

ストリーム処理を実装する際にイベントの転送をペイロードに変換する記述である．Phalanx での到達保証について考慮する必要がある．イベン

はデータ型によって順序に関係なくステートフル

ト転送の到達保証は⼤きく 3 つに分けられる．

データへの更新を⾏うことが可能である．そのた• At Most Once Semantics

め⼊⼒イベントをデータ型の更新メソッドに変換• Exactly Once Semantics

するようなシンプルな更新ルールを記述するだけ• At Least Once Semantics

で更新を実現することが可能になる．

At Most Once Semantics はイベントが最⼤で 1
回到達，Exactly Once Semantics はイベントが⼀度だけ到達，At Least Once Semantics はイベント

4 Phalanx の実装が少なくとも 1 回以上到達を保証する．つまり At

Most Once Semantics はイベントが転送途中で失われる可能性があり，At Least Once Semantics は
本節では Phalanx の実装について説明する．
*1 https://hbase.apache.org/

イベントが重複して届く可能性があることを⽰す．

1.4 ストリーム処理におけるステートフルデータの管理⼿法

34

⼀番望ましいのは Exactly Once Semantics であ

時の例である．1 つの⼊⼒ストリームから取得しるが，Exactly Once Semantics を実運⽤で実現すたイベントを user status テーブルへの更新操作にるためには厳密な送達制御が必要となり，送達制変換する．このとき⼊⼒イベントは JSON フォー

御のオーバーヘッドが性能劣化を引き起こすこと

マットであることを仮定している．この更新ルーが起こりうる．MillWheel [2] ではイベントにあらルではイベントから更新値を抽出する際に jq*2 をかじめユニークな ID を付与し ID による重複除去

JSON 操作⽤ DSL として利⽤している．

の機構を設けている．Phalanx では MillWheel を参考に，イベントの到達保証が At Least Once Se-

5 まとめ

mantics のときでも同じイベントに対する更新を繰り返し⾏わない仕組みを設けている．Phalanxの⼊⼒イベントには必ずユニークな UUID の付与を必須と定めており，ペイロードのバージョンにはタイムスタンプに加え UUID を追記している．もし重複するイベントが Updater Layer に届いてもペイロードは同じバージョンになるため，

HBase の同⼀の Cell として上書きされる．そのた
め Phalanx では参照時にはペイロードの重複が除去されていることを保証する．

ステートフルデータをストリーム処理で扱うための処理基盤 Phalanx を開発した．Phalanx では
イベントの到着順が保証されないストリーム処理
においてステートフルデータの変更を可能にするために更新時にステートフルデータを変更するのではなく参照時に更新操作を集約しステートフル
データに変換するデータ型を⽤意した．このデー
タ型では結果整合性を保証する．Phalanx のデー
タ型は順不同で更新が可能であるのでステートフ
ルデータの変更をイベントとデータ型への操作を

4.3

更新ルールの実装

対応するだけの平易な更新ルールを記述するのみで実現可能にした．

参考⽂献[1] Marc Shapiro, Nuno Preguica, Carlos Baquero, and Marek Zawirski.

Conict-freereplicated data types. In Proceedings ofthe 13th International Conference on Stabilization, Safety, and Security of Distributed
Systems, SSS’11, pp.386–400, Berlin, Hei図 1.4.4 更新ルールの例

delberg, 2011. Springer-Verlag.
[2] Tyler

Akidau,Alex

Balikov,

Kaya

更新ルールは⼊⼒ストリームから受け取った

Bekiroglu, Slava Chernyak, Josh Haber-

イベントをペイロードに変換する．⼊⼒ストリー

man, Reuven Lax, Sam McVeety, Daniel

ムからはさまざまな種類のイベントが Updater

Mills, Paul Nordstrom, and Sam Whittle.

Layer に届くため，適切なイベントを選択して更Millwheel: Faulttolerant stream processing

新操作に変換できるようにする必要がある．

at internet scale.

図 1.4.4 は更新ルールを YAML 形式で記述した*2 https://stedolan.github.io/jq/

Proc. VLDB Endow.,

6(11):1033–1044, August 2013.


機械学習システム
機械学習を計算機システムに組み込むにあたっては，学習アルゴリズムと訓練データによる無数の組み合わせから生まれる学習済みモデルを統合的に管理しながら開発および運用・保守を行う必要がある．ここではそのための秋葉原ラボの取り組みとして，フィルタ基盤の開発の実践およびその設計思想と，機械学習に特有なモデル管理の課題とその解決のために開発している基盤システムについてそれぞれ紹介する．

36
Akihabara Lab

2.1

フィルタ基盤の開発における取り組みと利⽤されている技術

Connolly, Juhani

概 要 秋葉原ラボではさまざまなデータ活⽤システムを開発・運⽤しており，共通して必要となる機能としてコンテンツのフィルタリングがある．データ活⽤の普及に伴って，フィルタリング処理のスケーリング
や管理の効率化が課題となっていた．そこで，秋葉原ラボでは，フィルタリングロジックの分散処理やリソース利⽤の効率化を可能にし，新しいフィルタの開発やデプロイを容易にするフィルタ基盤を開発した．本稿では新たに開発したフィルタ基盤の開発・運⽤や今後の改善点について紹介する．

Keywords

Filtering，Microservices，CI/CD

1 フィルタ基盤の背景

た．既存のシステムは，1 つのサーバですべてのリクエストを集中的に処理しており，スケーラビリ

インターネットサービスを運営する上で必要不

ティに課題があった．また，モノリシックな構成

可⽋な処理としてフィルタリングがある．当社でで 1 つのアプリケーションにさまざまなフィルタ

も ABEMA のコメントや Ameba ブログの有害コ処理やそれらに必要なモデルデータが混在し，管ンテンツ・スパム投稿などを防ぐため，それらの検理が複雑化していた．そこで，以下を⽬的とした知機能をもつフィルタを開発している．フィルタ

新しいシステムの開発を⾏った．

が扱うデータはテキストデータ，画像データ，機械学習の特徴量データなど多様であり，ロジックもシンプルなルールベースのものから機械学習を使うものまでさまざまである．
秋葉原ラボではさまざまなフィルタを開発してきたが，フィルタの増加に伴い，フィルタ処理や機械学習モデルの管理の効率性が課題となっていた．たとえば，複数のフィルタが混在するシステ
ムでは，1 つのフィルタロジックの変更によりほかのフィルタが影響を受ける可能性がある．また，複数の機械学習モデルが共存していると CPU やメモリなどの計算機リソースのスケジューリング
も課題となる．
これらの課題に対応するために，フィルタ処理を効率的に管理するためのシステムの基盤化を⾏っ• 複数のフィルタの連続処理を定義・管理・実⾏
する，簡単にスケールできるサービスを提供
する．

• フィルタの開発・デプロイ・デバッグを簡単にし，インフラを開発者に意識させないようにする．

• リソースの利⽤を効率的にし，利⽤状況を把握できるようにする．

• フィルタごとにリクエスト数が異なるため，それに応じてリソースの割り当てを最適化する．

• 特定のサービスからのリクエストがスパイクして全体のパフォーマンスと可⽤性に影響を及ぼすことを防ぐ．

2 システム構成

37
Filter requests
Plannedtraffic/service

Existing Traffic

gRPC traffic

フィルター基盤インフラ
Filters
Aggregators

Manual model
creation

Gateway(filter execution,
discovery)

Storage

JSON gRPC proxy

JSON gRPC proxy

Provisioning

UI/Edge server(Status, Admin)

Model DB

Chain conf
DB

Batch service
ユーザー

機械学習インフラ

図 2.1.1 フィルタ基盤構成

マイクロサービスと UNIX Philosophyのプロトコルとサービスから構成される．このプフィルタ基盤の開発にあたっては，UNIX Phi-

ロトコルは Protocol Buﬀers/gRPC（3.1 項）で定

losophy*1 に基づき，サービスだけでなく開発プロ

義されており，各サービスはそれにしたがってコセスの分割も明確にした．現在，⼤規模なシステ

ミュニケーションを⾏う．

1.1

ムを複数のパーツに分けるマイクロサービス型の以下各サービスについて説明する．

システムアーキテクチャが注⽬されている．このマイクロサービスというコンセプトのメリットは，

2.1

ゲートウェイ

⼤規模なシステムを複数の⼩さなモジュールに分

ゲートウェイはフィルタ基盤の中⼼となるサー

ける事により，複雑なシステムを理解・メンテナン

ビスである．このサービスはコーディネーターのスしやすい⼩さなシステムに分解させる事にある．

役割を持ち，定義されているフィルタチェインを

これは，UNIX Philosophy の中⼼的な⾔葉であ実⾏する．

る “Design programs to do only a single thing,

この実⾏は以下の処理により構成される．

but to do it well, and to work together well with• フィルタのディスカバリ

other programs.” をインフラとアーキテクチャに• フィルタのグループの並列実⾏とその結果の適⽤したものとみなせる．

集計• メトリック収集

2 システム構成
フィルタ基盤の構成を図 2.1.1 に⽰す．図 2.1.1
は，現在提供しているサービスに加え，今後対応予定のサービスも含んでいる．フィルタ基盤は複数*1 http://www.linfo.org/unix_philosophy.html• フィルタのリトライ・タイムアウトとエラー処理• 集計結果をベースにした処理フローの分岐
これらの処理はサブシステムに分離されており，

2.1 フィルタ基盤の開発における取り組みと利⽤されている技術

38

リプレイスが容易である．また，ディスカバリはバに存在するフィルタの実装を発⾒し，リモートインフラへの依存を防ぐためプラガブルになってフィルタのファクトリ機能を提供するディスカバ

いる．

リ処理をもつ．

基本的に gRPC での利⽤を想定しているが，*2

フィルタ処理は，チェインやステージなどの各

grpc-gateway を使ってプロトコル定義ファイル

レベルごとに明確に役割が分離されたランナーにから JSON のプロキシを⾃動⽣成することによより実⾏される．

り，JSON でのアクセスも可能となる．

チェインレベルのランナーは，チェインのロードと初期化を⾏い，ステージのランナーへのリク
エストの転送と処理結果の受信，およびクライア

ゲートウェイの動き

ントへの返信の処理を⾏う．
ステージのランナーでは各フィルタのランナー

Request received

へリクエストを転送し，その結果に対して必要な処理を⾏う． フィルタのランナーは定義されていLoad/Initialize chain

る外部のフィルタにリクエストを転送する．また，リトライやタイムアウトなどのエラーハンドリン

Process next stage

グをチェインの設定にしたがって実⾏する．
フィルタ処理の結果に対して集約処理が必要な

Route requests to filters

場合は，対応するアグリゲーターの呼び出しと集Retry

約後の分岐処理を⾏う．アグリゲーターでは Min/

Process errors/timeouts

Max/Mean などの組込みの集約処理に加えて，カNo

スタムの集約処理を拡張することができる．また，

HasAggregator
Yes

必要に応じて，フィルタと同様に，リモートのアグ

Send results to aggregator

分岐処理では結果に応じて次に実⾏すべきス
テージを決定し，チェインのランナーに通知する．

Process branching

Has next
stage?
No

リゲーターを⽤いて複雑な集約処理を定義できる．

次のステージを決定するために，BranchRule の確
Yes

認を⾏う．BranchRule がない場合は次のステー
ジを実⾏する．

Return final result2.2
図 2.1.2 フィルタチェインの処理の流れ

チェインストア

チェインストアは，フィルタチェインの保存先であり，フィルタの具体的な実装を抽象化したもの

ゲートウェイは複数のフィルタで構成されるを提供する．また，フィルタチェインのバリデー

チェイン（パイプラインとも呼ぶ）のオーケスト

ションを⾏う．今後は，より複雑なバリデーショ

レーションを⾏うシステムである．各チェインはンの対応や，チェインの変更検知などを実装する

複数のステージで構成され，各ステージは並⾏に予定である．また，ゲートウエイと同じく，チェイ

処理される複数のフィルタからなる．図 2.1.2 にそンストアは，gRPC もしくは JSON プロキシによの流れを⽰す．また，ゲートウェイは，異なるサー

り利⽤できる．

*2 https://grpc-ecosystem.github.io/grpc-gateway/

3 利⽤技術
2.3

UI/エッジサーバ

39
これらを使う事によって，フィルタ基盤の開UI は SPA によって簡単にフィルタチェインの発を効率的に⾏うことができた．また，Protocol

変更を⾏えるインタフェースを提供する．また，

Buﬀers を⽤いることでデータ定義に後⽅互換性

クラスタ外からの唯⼀のエントリポイントであり，をもたせることが可能であり，データ定義に新し

リバースプロキシとしてほかのサービスの機能をい項⽬の追加や削除があっても，変更前のインタ

外部に公開する．

フェースを⽤いてコミュニケーションを⾏える．
このためクライアントとサーバのバーションミス

2.4

フィルタ

フィルタ基盤における実際のフィルタ処理の実マッチが発⽣しにくく，プロトコルの変更を計画
的に⾏うことができる．

装はエンドユーザにより提供される．gRPC のプ

また，grpc-gateway ライブラリを⽤いることで，ロトコルの実装とディスカバリの設定（実装してプロトコルの定義から JSON のプロキシを容易にいるフィルタの名義，サポートしているデータタ⽣成できる．

イプなど）により，ゲートウェイはフィルタを検出することが可能となり，フィルタチェインで利⽤できる．
また，チェインの設定により各フィルタの設定を上書き可能であり，異なったパラメータでフィルタを再利⽤することも可能となる．また，フィルタ設定を変えるための再起動なども不要である．

OpenAPIUI は TypeScript で書かれているため，サーバとは JSON 形式のデータでコミュニケーションできることが望ましい．
マニュアルで UI のコードを管理する場合，プロ
トコルが変更されるたびに更新が必要になる．
これを避けるため，grpc-gateway に加えて Open-

3 利⽤技術API（旧 Swagger）の定義も⽣成する．OpenAPIの定義をベースに TypeScript の SPA のクライア

3.1

Protocol Buﬀers/gRPC

UNIX Philosophy における規範の１つとして明ントコードを⾃動⽣成を⾏う事ができ，JSON プ
ロキシとのやりとりを効率的に実現できる．

確なインタフェースがある．明確なインタフェー

gRPC と OpenAPI を使う事によって⼀つの定スを確保するためには利⽤するものの開発のしや義で複数のシステム間のコミュニケーションプロ

すさ，効率，周辺ライブラリの充実などが重要となトコルを明確にできる．また，周辺ツールが充実

る．また，複数の⾔語でコミュニケーションをすしており，プロトコルを拡張しやすいというメリッるためには，特定の⾔語に依存しないシリアライ

トもある．インタフェースは明確かつ柔軟になっズ⽅式が必要となる．

ているため，利⽤コンポーネントの⼊れ替えが必

そこでフィルタ基盤では，データ（インタフェー

要な場合も柔軟に対応できる．また，プロトコルス）の定義に Protocol Buﬀers*3 を⽤いた．Prot-に不備がある場合も，適切な計画を⽴てることに

col Buﬀers は，Google 社のライブラリで複数のプ

よって変更や拡張はスムーズにできる．

ログラミング⾔語間での構造化データの受け渡しを可能にする．また，gRPC*4 を採⽤し，Protocol

3.2

Java/Spring/Jib

Buﬀers のデータ定義から⽣成されたクライアン

フィルタ基盤の開発では，ロジック，設定，パットやサーバインタフェースのテンプレートを基にケージングを分離しそれぞれの責務を明確にした．

フィルタ基盤を実装した．

これにより，問題があった場合のメンテナンスや*3 https://developers.google.com/protocol-buffers*4 https://grpc.io/2.1 フィルタ基盤の開発における取り組みと利⽤されている技術

40
リプレースを容易にした．

できる．

フィルタ基盤のコアの部分のアプリケーション

適切なメトリックの利⽤により，システムの問

コードはすべて Java で実装した．また，コアコー

題を容易に把握するだけでなく，デプロイフロー

ドは特定のフレームワークに依存しないようにしの中での問題に対して，リグレッション検知を⾏った．これにより，挙動が理解しやすく，明確なインてロールバックも可能になっている（5.4 項）．

タフェースをもったアプリケーションとして実装
できた．

4 インフラの抽象化

コア以外のモジュールでは，Spring をもちいた
アプリケーションの設定とパッケージングを実装した．Spring の設定を 1 ヵ所に集約することで，前述のアプリケーションは，特定の環境に依存しないように実装されている．具体的にはアプリ

モジュール間の関係の理解が容易になり，フレーケーションの jar ファイルと，それを含む Docker

ムワークの「魔法」に頼る所が少なくなる．

イメージである．本節では，それらの Kubernetes

Spring Boot を使う⼀つの⼤きなメリットに環境（lab-k8s）上での運⽤について説明する．

Externalized configuration*5 がある．これを使う事によって設定情報をパッケージング時に⼊れず

4.1

lab-k8sに，デプロイ時に YAML/JSON ファイルや環境

秋葉原ラボは独⾃の Kubernetes 環境を開発・運変数で設定できる．これにより，設定の⾃由度が⽤している．lab-k8s では，標準の Kubernetes に

⾼くなり，あらゆるインフラへのデプロイが可能

加えて，いくつかの Custom Resource Definitionになる．

（CRD）がインストールされており，さまざまなタJava のアプリケーションは，Google の Jib*6 を

スクを効率化している．ただし，インフラの実装

⽤いることで Dockerfile など別の設定ファイルをは変化する可能性があり，また，ほかの環境へのデ記述することなく，コンテナ化してデプロイする．

プロイが必要となる可能性もあるため，本フィル

Jib を使う事によって，Docker のレイヤキャッシ

タ基盤が lab-k8s の各機能を利⽤するかは切り替

ングの効率化や，変更がない時コンテナのハッシュえることができる．

も変わらないというメリットがある．

4.2
3.3

監視

Helm

Helm*7 は Kubernetes のパッケージマネージャ

フィルタ基盤は Prometheus とログベースにである．1 つのアプリケーションとその依存など

よる監視を⾏っている．各コンポーネントではを抽象化し，パッケージ化するしくみを提供する．

Prometheus のメトリックの形でリクエストカウ

そのパッケージの中では Pod,Deployment,Service

ント，エラーカウント，同時リクエスト数，リクなどのテンプレーティングを⾏い，エンドユーザ

エストレイテンシなどのメトリックを記録していからインフラの詳細を隠蔽し，1 つの設定ファイル

る．フィルタ基盤は秋葉原ラボで開発・運⽤してに集約する．

いる Kubernetes クラスタ（以降，lab-k8s と呼ぶ．

フィルタ基盤では，このファイルに Spring の設

4.1 項参照）上にデプロイされている．lab-k8s で定，Prometheus モニタリングの⾃動設定（CRD

は，Prometheus のサーバ⽴ち上げや管理をする

依存あり）の有無，レプリカ数，DB の⾃動プロ

prometheus-controller があり，監視を容易に管理

ビジョニング（CRD 依存あり）などをまとめて*5 https://docs.spring.io/spring-boot/docs/1.2.2.RELEASE/reference/html/boot-features-external-config.

html*6 https://github.com/GoogleContainerTools/jib*7 https://helm.sh/5 開発プロセス
いる．CRD のない Kubernetes 環境に移動して41
で詳細を説明する．

も，そのフラグをオフにするだけで lab-k8s 以外のKubernetes 環境にも対応できる（ただし CRD で
プロビジョニングされている DB などの導⼊や設定は必要となる）．

5.1

ビルドシステムとリポジトリ

フィルタ基盤の開発における主なリポジトリと

4.3

Kubernetes ディスカバリの実装

して，アプリケーションのコードを管理するもの

ディスカバリのシステムは抽象化されているが，がある．フィルタ基盤の開発においては，アプリ

実際に機能するかはインフラの実装に依存する．

ケーションコードのリポジトリが，CI/CD のシス

Kubernetes 環境では，ディスカバリは容易に実現

テムやデプロイ先のインフラに依存する設定を含できる．

める必要がないように開発プロセスを設計した．

まず，各フィルタのパッケージの設定にディスフィルタ基盤の⼤部分のコードは Java で実装

カバリの情報を含める．具体的にはポッドのメタされているため，現時点ではビルドシステムとしデータのアノテーションとして設定する．そしてて Maven*8 を採⽤している．豊富なプラグインがゲートウェイにより，Kubernetes の API にリス提供されているため Java のコンパイルやテストナを作成する．このリスナは Kubernetes のネーだけでなく，Docker コンテナの作成やほかのビル

ムスペース内のポッドの変更を監視し，関連する

ダ（UI のコードのコンパイル）なども連携可能で

アノテーションが付与されている場合，フィルタある．

と認識して必要な処理を⾏う．

アプリケーションコード以外のリポジトリとし処理の内容としてはアダプタの処理を⾏ってては，インフラコードやデプロイのコードを管理す

ディスカバリプロセッサに必要な接続情報（ホスるリポジトリがある．これらは，アプリケーショ

ト，ポート，フィルタの名称など）を送信する．プ

ンコードと依存関係をもたないように設計した．

ロセッサはマッチするフィルタの接続プールを探インフラコードの管理を分離することによって，し（ない場合は作る），gRPC 接続を作成し，プー

たとえば Kubernetes から VM の環境に移⾏する

ルに追加する．フィルタが必要になった際に，Fil-事があったとしても，アプリケーションコードのterFactory はディスカバリプロセッサからリモー

変更を不要にできる．別の環境への移⾏は，新環

トフィルタに必要なコネクションプールを取得し，境⽤のインフラのコードだけを追加することで実フィルタを⽴ち上げる．

現できる（ただしインフラに依存するディスカバリ
の実装の追加は必要になる可能性がある）．また，

5 開発プロセス
1.1 項で述べた UNIX Philosophy は開発にも適⽤されている．

アプリケーションの変更など，さまざまなコミッ
ト履歴が混在されず，変更履歴が理解しやすいメ
リットもある．
同様に，デプロイのコードも独⽴に管理されてそれぞれのリポジトリに明確な役割を与えるこいる．CD のシステムが変われば，そのシステムとによって CI や CD の依存関係を疎にでき，CIの設定⽅法なども変更が必要となる．デプロイのや CD の実装に変更があったとしてもほとんどのコードを分離することにより，CD の実装とアプリ

コードに影響のない開発プロセスとリポジトリ構

ケーションの疎結合を維持できる．

成を実現している．
開発プロセスの全体像を図 2.1.3 で⽰す．以降*8 https://maven.apache.org/index.html

この分割によって各リポジトリの関⼼を分離させることができる．

2.1 フィルタ基盤の開発における取り組みと利⽤されている技術

42

App code

Containers
CI

Infrastructure
code

Infrastructure
artifacts

CD

Deploymentsoninfrastructure

Deploymentcode
図 2.1.3 存在するリポジトリの種類と CI/CD の関係

本来のビルドシステムの問題

今後の可能性・Bazel

Maven では豊富なプラグインが提供されている

以 上 の 問 題 に 対 し て ，Google は 数 年 前 にが，Java 以外の⾔語のコンパイルは最終的に Exec

Bazel*9 というシステムをオープンソースにした．

plugin を使って実⾏する．このように，マルチ⾔

このシステムでは細かいレベルで依存関係を定語のプロジェクトでは Java 以外で書かれている義する事ができ，⼤きなリポジトリのビルドを効

ソースは低いプライオリティーになり，可能なビ率化できる．変更箇所とその依存部分のみのビル

ルド処理に制限がある．

ドだけが実⾏されるようになっており，中間アー

また，⼤規模なリポジトリではビルドにかかる時

ティファクトは決定的に作られているため，ビル間が問題となる．モジュール間の細かい依存関係

ドキャッシュをそのまま使うことが可能で無駄なの定義は困難なため，ビルドがプロジェクト単位な

くビルドを⾏う事ができる．変更に直接かかわる

ど⼤きな粒度で⾏われることが⼀般的である．単箇所のみの再ビルドが実⾏されることにより，ビ

⼀の⾔語で書かれていないリポジトリでは Maven

ルドやリリースの速度を向上させ，問題のあるコー

で詳細な依存情報を定義するのは不可能なため，ドも早期に発⾒できる．

システムによって変更のないアーティファクトまでビルドやテストが実⾏され，それらのパッケー

ただし，Bazel への移⾏はコストが⾼く現在進めていない．

ジが各リポジトリにプッシュされてしまう．
スクリプトなどによって⼀部のサブモジュールのビルドを除外するのは可能だが，それを開発するのは困難で新しい問題の原因となりうると考える．
全アーティファクトがプッシュされる事によって，CD にトリガなどがセットされている場合，本来不要なアーティファクトまでデプロイが実⾏されてしまう．このため，無駄が多く，ソースコードの変更からインフラで反映されるまでの間が⻑くなり，CI/CD による効率化が⼗分に⾏えない．

5.2

CI

CI の役割は再現可能な形ですべてのビルド，ユニットテストとパッケージングを⾏う事である．
これを実現するためにはその実⾏を Docker コン
テナ内で⾏う．フィルタ基盤は特定の CI ツールに依存しない構成であるが，ユニットテスト内のDocker の利⽤があるため，それをサポートしている CircleCI を採⽤している．

5.3

CD

デプロイの効率化と早期の問題の発⾒のために
最近 CD（Continuous Delivery もしくは Contin*9 https://bazel.build/6 まとめuous Deployment）が注⽬されている．

43
5.4

問題のあるリリースを避ける⽅法

フィルタ基盤では，Harness*10 を⽤いて CD を

CI の中でユニットテストやインテグレーション

実現している．Harness はほかのコンポーネント

テストを⾏っているが，それらで検知できない問題と同じく適切な抽象化がなされており，既存のイもある．たとえば，ディスカバリのコードに問題

ンタフェースを変えずに組み込むことができる．

があれば，Kubernetes 環境にデプロイされるまで今後問題があったとしても，ほかのコードに影響問題が顕在化しない場合がある．また，パフォー

なくリプレイスできる．

マンスのリグレッションなどは CI の中でのユニットテストで検知することは難しい．
このような問題を検知するために，ステージン

CD の⽬的
フィルタ基盤の CD では以下を⽬的とした．

• ⾃動化されたデプロイによるデプロイの操作ミ
スの防⽌• デプロイフローにおける問題を防ぐためのス
モークテストの統合• エンドユーザからインフラを隠蔽するためのデプロイの抽象化• デプロイの⽅法のバーション管理（いわゆるGitOps に近い）
• rollback 可能なデプロイ戦略の実現

グ環境のデプロイを⾏う際に，Harness の Verifi-

cation 機能を使って，負荷テストを組み込んでいる．負荷テスト中に Harness はログとメトリック（Stackdriver Logging/Prometheus のもの）を収集し，過去の実⾏と⽐較する．これらに問題があれば（たとえばスループットの低下），デプロイがrollback され，プロダクション環境へのデプロイが中⽌される．この取り組みによってリグレッションなどの問題をもつデプロイを防⽌することが可能になっている．

6 まとめ
本稿では秋葉原ラボで開発しているフィルタ基

Harness での実装盤について紹介した．各レベルでは適切な抽象化

前述のようにアプリケーションとインフラレイを意識し，各システムとサブシステムのカプセル

ヤのコードのリポジトリとは別にデプロイ（CD）

化を⾏っている．開発プロセスではコードベースのリポジトリを構築してある．

をアプリケーション，インフラ，デプロイで分離

デプロイリポジトリはハーネスのすべての設定

し，メンテナンス性を向上させている．CI/CD のを管理する．ハーネスではいくつかの抽象化されプロセスの中にテストを組み込むことによって，た機能があり，それらを使う事によって再利⽤可

さまざまな段階で問題のあるコードを早期に検知能なワークフロー（1 つのサービスのデプロイの⽅することが可能になっている．開発プロセスにつ法）とパイプライン（複数のワークフローの連携）

いてもメンテナンスのしやすさを意識した設計をを定義できる．

しており，新しいテストの追加が容易なフレーム

サービスレベルではサービスが使うコンテナイ

ワークが実現できている．フィルタ基盤は継続的

メージ，Helm パッケージの設定の overload（Helmに開発していく予定であるが，シンプルなインタの Values ファイルの中⾝）を定義している．またフェースで作る事によって，問題のある部分も容環境に特化した設定（たとえば利⽤するリソース・易に改善していくことができると考える．

デバッグ設定）は，Values の環境別の overload により実現できる．
*10 https://harness.io/

今後は，より利便性を⾼めるために，いくつかの拡張を⾏う予定である．まず，秋葉原ラボで開発

44

2.1 フィルタ基盤の開発における取り組みと利⽤されている技術

しているモデル管理システムとの連携により，フィタフェースで即時にプロビジョニングするサービルタが使う機械学習モデルの管理を効率化するこ

ングのシステムを検討する予定である．また，UIとがある．さらには，特定のモデルを簡単なインにはまだ改善の余地が多い．

45
Akihabara Lab

2.2

データと処理の依存関係を整理する機械
学習モデル管理基盤の開発

⼤内 裕晃

概 要 秋葉原ラボではコンテンツ推薦，動画や画像の特徴量抽出，⾃然⾔語処理などのシステムで機械学習を活⽤している．機械学習モデルの再現性を担保するためのバージョン管理では，通常のソフトウェア開発のようにコードを管理するだけではなく，学習に利⽤したデータセットやほかの機械学習システムの出⼒を利⽤しているといった依存関係を含めて管理を⾏う必要がある．そこで，機械学習モデルの開発に関連する依存関係の整理を⾃動化するため，我々は機械学習モデル管理基盤 Etna を開発した．Etna は抽象化された機械学習のデータフローに基づき，モデルのバージョン管理およびデータの依存関係を管理するシステムである．本稿ではモデル管理基盤となる Etna 開発の背景やその機能について紹介する．

Keywords

機械学習，モデル管理，機械学習⼯学

1 背景

ジョン管理システムで管理するだけで⼗分であったが，機械学習モデルの開発ではプログラムコー

近年，様々な分野で機械学習システムが活⽤さドに変更がない場合でも⽤いるデータやハイパー

れるようになった．秋葉原ラボでもコンテンツ推パラメータ，実⾏環境が変わることで得られるモ

薦や動画の特徴量抽出，不適切なコンテンツのフィ

デルの性能が変化するため，プログラムコードのルタリングなどに機械学習システムを⽤いている．

バージョン管理だけでは不⼗分である．また，機械

しかし，フレームワークなどの発展により機械学

学習システムにおける技術的負債の例としてデー

習システムの開発や導⼊は容易になりつつある⼀タの依存関係や宣⾔されていない消費者の存在が⽅，⻑期的に機械学習システムを維持することはある [2, 3]．機械学習システムにおけるデータの依依然として困難であることが多い．従来のソフト

存関係はソフトウェア⼯学におけるコードの依存

ウェア開発ではプログラムの変更に伴う保守性を関係と⽐較できる．従来ではプログラムコードの向上させるために，技術的負債 [1] を定義しそれら更新を追従したり静的解析を⽤いることで依存関を避けるための取り組みが⾏われていたが，機械係を抽出できるが，機械学習モデルの更新ではプ

学習システムの開発ではこの技術的負債を回避す

ログラムコードの更新だけでなく，学習スクリプ

るための⼿法を適⽤することが困難であることにトの変更，学習データの変更，ハイパーパラメー

加え，機械学習システム特有の技術的負債も発⽣

タの変更などの要因が挙げられ，これらの解析はする．たとえば従来のソフトウェア開発における困難である．データの変更についても前処理を変バージョン管理では最終的な成果物を作成するた

更した場合，⽣データを変更した場合などがあり，めに⽤いたプログラムコードを Git*1 などのバー*1 https://git-scm.com/

46

2.2 データと処理の依存関係を整理する機械学習モデル管理基盤の開発

コードの依存関係よりもデータの依存関係の⽅がるため，モデルはプログラムコードだけでなく利より複雑である．このようなデータの依存関係を⽤するデータの変更によってその精度が変動する．

適切に管理できていない場合，モデル⽣成の再実

特にデータの変更については CASE（Changing

験が困難になり，最新のモデルや実際に運⽤した

Anything Changes Everything）という法則 [3]モデルを作成した際に利⽤した学習データを誤っがあり，データ数の増減や分布の変更などわずかて削除してしまうといった運⽤上の課題が発⽣すなデータの変更であっても，その予測の結果に⼤る可能性がある．宣⾔されていない消費者は，あきな影響が出る可能性があるとされている．そのる機械学習モデル（親モデル）の出⼒を⼊⼒としてため，機械学習システムの推論の結果が意図した学習や推論を⾏う機械学習モデル（⼦モデル）のものでなくデバッグを⾏う際には，システムで利ことである．機械学習モデル間にこのような依存⽤されたモデルの学習プログラムコードにバグが関係があるとき，親モデルの更新によって出⼒が含まれていないかだけではなく，どのデータを利変更された場合には⼦モデルには意図しない影響

⽤して学習したものなのかを知ることは重要であが発⽣する可能性がある．この依存関係による影る．しかし，このような情報は学習を⾏った環境

響を把握するためには，⼦モデルの開発者は親モにしか残っておらず，また機械学習エンジニアがデルの更新を検知し内容を把握する必要があるが，⾃⾝の使いやすいような環境や使い捨ての仮想環

それぞれのモデルが異なる開発者によって管理さ境で⾏うため，属⼈化してしまうといったことがれている場合には検知が難しく，特に親モデルの起こってしまう．その結果，実験の再現性が担保開発者は依存をもつ⼦モデルが増えることで親モされなかったり，モデル間の依存関係が不明瞭に

デルの更新時に考慮すべきことが増え保守性が低なったりする課題がある．以下，これらの 2 つの下することもある．

課題について述べる．

これらの課題を解決するために，我々はデータの依存関係を含めた状態で学習済みモデルを管理する基盤である Etna を開発した．Etna は学習済
みモデルや学習データをバージョン管理し，モデル
学習時に利⽤したコードのバージョンや学習デー
タ，親モデルのバージョンを保存する．学習済み
モデルと学習時の情報を管理することにより実験の再現性の向上やモデル間の依存関係を容易に把
握できる．

2.1

実験の再現性が担保できない

1 点⽬の課題はモデル作成時に利⽤した学習デー
タやスクリプトが把握できず，同じ性能のモデルを作成できないことである．機械学習モデルの開発では期待する精度のモデルが得られるまでパラ
メータやプログラムを変更させながら試⾏錯誤を⾏うため，開発中にどのようなパラメータで学習を実⾏したかを管理する必要がある．このような本稿では，2 節で機械学習システムにおける問題

実験時の情報が管理されていない場合，別の開発者

点を具体的に述べる．次に 3 節で既存の機械学習が追実験できずモデルの開発が属⼈化してしまっ

ツールと⽐較を⾏い，さらに 4 節で課題を解決すたり，デバッグが困難になるといった問題が発⽣るためのデータフローの抽象化および Etna の設するため，実験の再現性を担保することは機械学計と機能について説明する．そして 5 節でまとめ

習システムの運⽤上重要となる．実験を再現すると今後の課題を述べる．

ためには，学習に利⽤したデータセット，プログラ
ムコード，実⾏時のハイパーパラメータの情報が2 機械学習におけるデータ依存の課題

必要になる．またデータセットについては，単にデータセットのバージョンやデータの保存場所を

機械学習はデータセットを利⽤し，それを学習管理するだけではなく，そのデータセットを⽣成プログラムで処理することでモデルを作成していするための前処理に問題がある場合も考慮し，前

3 既存ツールとの⽐較

47

処理プログラムの情報や前処理前の⽣データの情など機械学習に関連する⼿続きを汎⽤的に管理で報も同時に管理する必要がある．

きない．Etna はモデルだけでなくデータセットの作成過程も含めて管理でき，より汎⽤的に機械学2.2モデル間の依存関係が不明瞭

習のデータフローを管理できる点で既存ツールよ2 点⽬の課題はデータを通じたモデル間の依存り優れている．

関係が不明瞭になってしまうことである．学習済
みモデル A を作成するために，別の機械学習モ

4 Etna の概要

デル B から出⼒されたデータを学習データとして利⽤している場合に，その 2 つのモデルはデータ

Etna は機械学習におけるデータフローをデーを通じて依存関係をもつことになる．依存関係をタとデータへの処理という 2 つの観点から抽象化もった機械学習のデータフローではモデル A の開し，それらのバージョン管理および関連を管理す

発者，モデル B の開発者双⽅に負担が発⽣するこるシステムである．開発者が作成した機械学習モとがある．モデル A の開発者はモデル B が更新

デルと関連するデータセットと学習プログラムのを検知できず，モデル A を更新する際に最新のモ情報とを関連付けて保存することで，機械学習のデル B を⽤いたデータセットが利⽤できるが古い

フローを容易に把握できるようにしている．本節

データセットで学習を⾏ってしまうため，精度がでは，Etna における機械学習データフローの抽象

向上せず，効率的に学習を⾏うことができないと化の⽅法，システムの設計および依存関係を表⽰

いった問題が発⽣する．⼀⽅でモデル B の開発者するグラフについて説明する．

はモデル B を更新する際に依存をもったモデルに対する影響分析ができず，モデルの変更や更新が4.1

機械学習データフローの抽象化

2 節で挙げた課題を解決するためには，機械学習困難になるといった問題が起きる．

モデルの作成に利⽤したデータセット，プログラ
ムコード，ハイパーパラメータを管理する必要があ

3 既存ツールとの⽐較る．さらにデータセットに加⼯を加える前処理や，

2 節で挙げた課題は既存のモデル管理サービスで
*2

*3

*4

機械学習モデルの推論結果を⽤いた学習もあるこ

ある MLflow ，Comet や ModelDB といったとから，前処理，推論といったデータへの処理もクラウドサービスや OSS ですべてを解消すること管理することが求められる．しかしモデルやデーが困難であった．既存のモデル管理ツールは学習

タの定義は開発者や使⽤するライブラリによって実⾏時のデータとハイパーパラメータの管理に特異なりあいまいである [5]．それらすべてを個別に化しており，モデル間の依存関係を把握できない．

管理するようなシステムを開発・維持していくこ

データについても学習実⾏時にスナップショットとは難しい．そこでデータセットやハイパーパラを保存するだけであったり，ファイル名を保存す

メータ，モデルファイルなどをデータとして，デー

るのみであり，そのファイル⾃体がどのように作成

タへの処理を加える関数をプロセスとして抽象化されたのかまでを追跡することは困難である．まし，汎⽤的にモデルの作成過程を管理できるようたシステムは公開されていないが，Amazon が設な設計を⽬指し，次のようなデータ，プロセスの概計を公開しているシステム [4] と⽐較すると，デー念を導⼊する．これにより，前処理や学習，推論とタセットのバージョニングを⾏う点では同じだが，いった機械学習に関わる処理を，⼊⼒と出⼒をも同様にモデルの⽣成過程しか管理できず，前処理つものとして抽象化できる．

*2 https://mlflow.org/*3 https://www.comet.ml/site/*4 https://github.com/VertaAI/modeldb

2.2 データと処理の依存関係を整理する機械学習モデル管理基盤の開発

48
データ

データの名前やそのデータ⾃⾝が⽣データなのか

機械学習を⾏うために必要なデータセットやハ

加⼯済みのものなのか，モデルなのかといった種別

イパーパラメータ，学習の結果によって得られたの情報はテーブル DataSeries によって管理され学習済みモデルファイル，推論結果やモデルの評

る．同様にプロセスはテーブル Process によって価結果をデータとして定義する．データセットやバージョンやコードの情報，そのプロセスの⼊出⼒

機械学習モデルファイルをデータという同⼀の形型の情報を管理する．⼊出⼒型の情報は省略可能

式で抽象化している．これによって，前処理済みだが処理の内容を理解する際に開発者を助けるほのデータセットの作成過程（処理前のデータ，処理

か，登録された情報を基に 2 つのプロセスを連続

内容が記述されたコードなど）やモデルの作成過して処理可能かを判別することに使われる．デー

程（データセット，学習処理が記述されたコードな

タとプロセスを利⽤したという情報はテーブルど）を，「データ作成に利⽤したデータ」の管理とExecution によって管理される．Execution はして同⼀の⽅法で管理することが可能になる．

利⽤したデータセット，プロセスに加えて実⾏したコマンドラインの情報も管理し実験の再現性をプロセス向上させている．またデータが特定の Execution

⼊⼒をデータ，出⼒をデータとするような関数によって作成されたという情報はテーブル Data

をプロセスとして定義する．機械学習においてはのカラム ExecutionId によって管理される．こ前処理，学習，推論，学習済みモデルの評価などがの設計は Amazon のシステムでの例を参考にしてプロセスに相当する．たとえば，ある⽂書から空いる [4]．

⽩・改⾏を除く前処理では処理したい⽂書ファイ
ルを⼊⼒，処理済みの⽂書ファイルを出⼒とする

4.3

データ依存関係を⽰すグラフ

プロセスとして扱うことができ，機械学習モデル

Etna は機械学習モデルに登録されたデータ，プを利⽤してブログ内容が不適切コンテンツかを判

ロセスの依存関係に基づき，その作成過程のグラ

別する推論では，学習済みモデルファイルとブロフを描画する．例として次のような機械学習モデグのコンテンツを⼊⼒，不適切コンテンツである

ルの開発を考える．

確率を出⼒とするプロセスとして扱うことができる．なおプログラムの中には，プログラム中でラ

1. 学習⽤データセット（text-dataset）を⽤意する

ンダムに⽂字列を⽣成するものや，データベース

2. text-dataset を⽤いて機械学習モデル A を作への接続設定やクエリがハードコーディングされ成するているようなものが存在する．このように実⾏に

3. ⼊⼒⽤データセット（raw-dataset）を⽤意する必要となる⼊⼒データが存在しない場合には例外

4. raw-dataset と機械学習モデル A を⽤いて学習的に⼊⼒のデータが存在せず出⼒のみをもつプロ
セスとして扱う．

⽤データセットとテストセットを作成する

5. 学習⽤データセットとテストセットを⽤いて機械学習モデル B とそのメトリクスを得る

4.2

Etna の設計

これを Etna に登録した場合に得られる依存関

図 2.2.1 に Etna のデータベース設計の⼀部を⽰

係グラフを図 2.2.2 に⽰す．図の中で四⾓形のノー

す．データはテーブル Data によってそのバージョドはデータ，円形のノードはプロセスを⽰しておンやフォーマット，保存場所などが管理される．まり，データ名およびバージョンが記述されている．

た，ハイパーパラメータやモデルの評価結果などプロセスの左側にあるエッジはプロセスを実⾏しデータがファイルとして保存されないものについた際に⼊⼒として利⽤されたデータを表し，右側てはカラム content にデータの内容を保存する．

にあるエッジは出⼒されたデータを表している．

5 まとめと課題

49

図 2.2.1 Etna の ER 図

図 2.2.2 Etna でのデータ依存関係の表⽰例

これによって，機械学習のデータフローをデータを介した登録の⽅法が存在する．

とプロセスが交互に連続する 2 部グラフとして可視化することが可能になる．たとえば，機械学習
モデル B の作成およびメトリクスの取得には 2 つ

5 まとめと課題のデータが利⽤されており，それらのデータがど

本稿では機械学習におけるデータの依存関係をのように作成されたのかといった情報が可視化さ管理するためのシステムである Etna を紹介した．

れている．なお Etna は登録および依存関係表⽰

Etna は機械学習エンジニアが作成したモデルおよのための Web インタフェースを備えており，登録びデータセットのバージョン管理を⾏うこと，機に際しては Web インタフェース上からの登録以外

械学習モデル間の依存関係の把握のために活⽤さに Python モジュールを介した登録，CLI ツール

れている．

50

2.2 データと処理の依存関係を整理する機械学習モデル管理基盤の開発

今後の課題としては，モデル間の差分抽出や機を標準化したうえで，本番環境やテスト環境で適械学習の⾃動化に向けた取り組みがある．モデル

⽤されているといったシステム運⽤上の情報をモ間の差分抽出は 2 つのバージョンの間でどのよう

デル管理基盤上に反映させることが考えられる．

な差異があるのかを簡潔に⽰すことである．たと実際の適⽤状況を反映することでモデル開発者のえば更新前後のモデル間でメトリクスの向上が⾒意図しないモデルが本番に適⽤されてしまうことられたとき，その要因がデータセットの変更なのを検知しやすくするほか，それを防⽌することがか，プログラムコードの変更なのか，もしくはハイ可能になる．これを実現するためには，Etna とモ

パーパラメータの変更なのかを⽰すことで，モデデルをデプロイするシステムとの連携が必要だと

ル精度向上の要因を簡単に知ることができるよういえる．今後はこれらの課題の解決に取り組む予になる．また，メトリクスの管理については 2 つ定である．

のモデル間のメトリクスが⽐較可能なのかといった情報も重要である．たとえば評価に⽤いたデー

参考⽂献

タが異なるなど同⼀の条件で評価が⾏われていな
い場合，それらのモデル性能を⽐較することは困難であり，評価の条件も含めてモデルを管理することで，モデルを正しく⽐較できることをモデル
管理基盤を通じて担保することが可能になる．4.1
項で述べたように，Etna はデータやモデル，ハイパーパラメータ，メトリクスといった機械学習で扱われるものを同⼀のデータという概念で抽象化して管理している．そのため，メトリクスの変化であってもハイパーパラメータの変化であってもEtna 上ではデータの差分として扱うことができ，それを表⽰するようなインタフェースを提供すれば良い．また扱うデータの種別によって確認した
い差分の内容が異なる場合には，それに応じてインタフェースを変更すれば良いため拡張しやすいといえる．
機械学習の⾃動化に向けた取り組みとしては，登録された依存関係情報の活⽤や利⽤状況の反映が考えられる．依存関係情報の活⽤については，現在の Etna では依存関係を依存関係グラフの描画にしか⽤いていないが，データの依存関係に基づき親データセットや親モデルの更新があった時に，モデルの再学習を実⾏したり，開発者に再学習のタイミングを通知するなど，モデルの継続的な更新の負荷を下げることで機械学習システムの安定化に貢献することも可能である．利⽤状況の反映については，機械学習モデルをデプロイする⼿順[1] Ward Cunningham.:

The wycash portfo-

lio management system, Addendum to theProceedings on Object-Oriented Programming Systems, Languages, and Applications(OOPSLA), pp.29–30, (1992).
[2] Sculley, D. et al.: Hidden Technical Debt
in Machine Learning Systems, Advances in
Neural Information Processing Systems 28(NIPS2015), pp.2503–2511, (2015).
[3] D. Sculley, Gary Holt, Daniel Golovin,
Eugene Davydov, Todd Phillips, Dietmar
Ebner,

Vinay Chaudhary,and Michael

Young: Machine Learning: The High Interest Credit Card of Technical Debt, SE4ML:
Software Engineering for Machine Learning(NIPS 2014 Workshop), 2014.
[4] S. Schelter, J.-H. Boese, J. Kirschnick, T.
Klein, and S. Seufert.: Automatically Tracking Metadata and Provenance of Machine
Learning Experiments, Machine Learning
Systems workshop at NIPS, (2017).
[5] Sebastian Schelter, Felix Bießmann, Tim
Januschowski,

David

Salinas,StephanSeufert, and Gyuri Szarvas: On Challenges
in Machine Learning Model Management,
IEEE Data Eng. Bull., vol.41, pp.5–15,(2018).


画像処理
コンピュータビジョン（CV）の分野は畳み込みニューラルネットワーク（CNN）などの深層学習技術の普及により急速に発展しており，多くのタスクで目覚ましい成果が挙がっている．
しかし，深層学習技術を実社会に応用することは簡単ではなく，データセットの品質や実社会の問題とのギャップ，実際のシステムへの組み込みなどの問題がある．これらの問題に対する取り組みを，実環境での実例を交えて紹介する．

52
Akihabara Lab

3.1

マッチングサービスにおける画像審査の
⾃動化

上岡 将也

概 要 メディアサービスを運営する上でサービスの健全化は重要な課題である．当社のメディアサービスの多くはユーザによるコンテンツ投稿が可能であり，不適切なコンテンツの投稿により健全性が損なわれる危険がある．当社ではそれらのサービスの健全化のためにユーザが投稿したコンテンツを監視している．秋葉原ラボでは監視を効率的にかつ精度よく⾏うためにルールに基づくフィルタや機械学習を⽤いた
フィルタを開発・運⽤している．本稿では，当社のマッチングサービスであるタップルで投稿されたプロフィール画像の審査を⾃動化するために開発したフィルタを紹介する．これは現在も実際に導⼊されており，複数の機械学習技術を組み合わせることで⾼い適合率を維持しながら，審査結果のブレの防⽌や監視コストの削減，審査時間の短縮などに貢献している．

Keywords

機械学習，画像処理，監視，CNN

1 はじめにマッチングサービスではコメントなどのテキス
ト情報以外にもプロフィール画像の監視が重要で当社のメディア事業では，ユーザがコンテンツを投稿できるサービスを数多く展開している．たとえば，テレビ＆ビデオエンターテインメント

ABEMA では，リニア配信中にコメントを投稿でき，ブログサービス Ameba ブログでは，テキストや動画像を含む記事やそれぞれの記事に対するコ
メントを投稿できる．
ユーザがコンテンツを⾃由に投稿できるサービスを運営する上では，不適切なコンテンツの投稿を監視し，サービスの健全性を維持することが重要となる．たとえば⾓⽥ら [1] は，Ameba ブログにおける不適切コンテンツの類型化を⾏い，その中でも⽐較的に多くの割合を占めているコピーコンテ
ンツスパムを検出するフィルタを開発して Ameba

ある．プロフィール画像とはユーザがサービス利⽤開始時に登録する顔画像のことで，マッチング
サービスのしくみ上，多くのユーザの⽬に触れるものであり，サービスの利⽤にあたっては必須となる．もし，顔のサイズが⼩さい画像や加⼯が強い画像などの本⼈を識別するには不適切な画像による登録ができると，ユーザからの信頼を失ってサービスの価値を損なってしまう．
当社のマッチングサービスであるタップルでは，
プロフィール画像に対して厳格な基準をもうけて

24 時間体制で監視することによりサービスの健全性を維持している．しかしプロフィール画像審査には次のような課題があった．

• 多くの画像を 24 時間体制で迅速に審査するにブログの健全化に取り組んでいる．
*1 監視オペレータの稼働時間だけを考えればよいわけではなく，厳密な基準の下に公平に監視できるように育成するコストやまたそういった⼈材を採⽤するコストも含む．

2 タップルの画像審査は，多くの⼈員を確保する必要があり，監視コ
スト*1 が⾼い．

53
2.2

フィルタ開発の課題

1 節で述べたとおり，タップルのプロフィール画• 審査基準を明確にして監視オペレータへの共有

像審査では，監視コストやオペレータによる監視を徹底しても，⼈の主観的な判断が⼊るために

結果のばらつきが問題となっていた．我々はそれ*2

監視結果にばらつき が⽣じる．
これらの問題を解決するため，我々は機械学習を⽤いたフィルタを開発し，プロフィール画像審
査の⾃動化に取り組んだ．

らの問題を解決するために機械学習フィルタの開発を検討したが，検討段階で次のような課題が予想された．

• 課題 1：解くべき問題は，ユーザが投稿した画

本稿では，まず 2 節でタップルのプロフィール

像を承認すべきか否認すべきかを判別する 2 ク

画像審査やその基準について紹介し，そのフィル

ラス分類だが，画像処理や機械学習の技術を⽤タを開発する上での課題を述べる．続いて 3 節でいてこの問題を解こうとすると，審査基準が多は，タップルの画像審査⾃動化のために開発した様であるために，そのすべてを満たせる 1 つのフィルタについて説明する．次に 4 節でフィルタ

機械学習モデルを作ることが難しい．

を⽤いた画像審査の処理の流れやフィルタ導⼊後• 課題 2：⼀部の否認理由に該当する画像においの効果について紹介し，最後に 5 節で本稿を総括て，外部の要因でデータの分布が頻繁に変わる

して今後の課題について述べる．

ことが考えられる．たとえば，顔写真の加⼯ア
プリケーションなどによって加⼯された画像が2 タップルの画像審査
タップルでは，なりすましや写真の悪⽤等を防ぐためにプロフィール画像の審査を⾏っている．
本節では，タップルのプロフィール画像審査やその基準について説明し，画像審査を⾃動化する上での課題を述べる．

2.1

審査基準と監視作業

それにあたる．画像が加⼯されたものかを判別するモデルを学習させて判別できたとしても，
加⼯アプリケーションのアップデートで新たな加⼯処理が追加された場合，データの分布が変わってしまい，以前のモデルではうまく判別できなくなってしまう．

3 機械学習フィルタ

画像審査を公平かつ的確に⾏うためには，審査

今回開発したフィルタの概略図を図 3.1.2 に⽰基準を適切に決める必要がある．公開されている

す．2.2 項で述べたフィルタ開発の課題 1 は，図⼀部の否認例*3 について表 3.1.1 に，具体的なサン

3.1.2 のように，基準に沿った複数の機械学習技術

プル画像を図 3.1.1 に⽰す．実際には，表 3.1.1 のを組み合わせてフィルタを構築することで解決しような公開している基準よりも細かく厳密に決めた．課題 2 は，アップデートの頻度を考慮してフィられた基準を下に審査を⾏っている．

ルタを分割することで解決した．本節では，それ監視オペレータは，投稿されたプロフィール画

らの解決⽅法の詳細を具体例を⽤いて説明する．

像が承認か否認かを決めるだけでなく，否認する場
合は，否認した理由を基準の中から選択する．こ3.1

基準に沿ったフィルタの構築

れは，否認理由により投稿の悪質度が異なるので，

2.2 項の課題 1 で述べたとおり，タップルのプ

それに応じてサービス側の対応を変える必要があ

ロフィール画像審査は，審査基準が多様であるたるためである．

めに簡単な分類問題としては解くことができない．

*2 ぼかしが⼊っている画像など数値化が難しいものや，芸能⼈などの監視オペレータの知識依存になってしまうものなど．
*3 https://support.tapple.me/hc/ja/articles/360007366514- メイン写真が否認されるのはなぜですか-3.1 マッチングサービスにおける画像審査の⾃動化

54

図 3.1.1 否認されるプロフィール画像の具体例

表 3.1.1 タップルの画像審査で否認される例

否認理由

詳細

顔を認識できない

顔の半分以上確認できないもの，⽬元が確認できないもの

加⼯

加⼯が強すぎるもの

顔のサイズが⼩さい

画像全体に⽐べてあまりにも顔の部分が⼩さもの

不鮮明

画素数が低く，画像が不鮮明なもの

写真の写真

カメラで写真やプリクラ，証明書などを撮影した画像

複数⼈

複数⼈が写っていて，誰が本⼈かがわからない

芸能⼈

芸能⼈や明らかに本⼈でない画像

⼈間以外

⼈物ではないイラストや動物，景⾊などの画像

個⼈情報

個⼈情報が書き込まれている画像

卑猥

卑猥な画像

グロテスク

グロテスクな描写を含む画像フィルタを開発するにあたって，開発前に画像審

きさや数をルールベースで 3 カテゴリに分類した査の基準書や実際のデータを分析することで，複ほうが精度が⾼かった．もう⼀つは，顔検出の結数の機械学習技術の組み合わせが必要なことがわ

果を，後段のフィルタで使⽤するためである．表かった．以下，図 3.1.2 の複数のフィルタのうち，3.1.1 の否認理由は，「加⼯」や「不鮮明」といった

顔検出フィルタについて詳しく説明する．

顔の領域のみで判断できるものと，「卑猥」や「グロテスク」，「個⼈情報」のように顔の領域以外での顔検出判断が必要なものとに分けることができる．それ

表 3.1.1 の否認理由のうち，「顔のサイズが⼩さらのうち顔の領域のみで判断できる否認理由を分い」と「⼈間以外」，「複数⼈」を⾃動で検知したい

類するフィルタは，顔検出の結果を使⽤して顔の場合は，分類問題として解くのではなく，物体検出領域のみを切り抜いた画像を⼊⼒することで精度（顔検出）の問題として解くこととした．その理由

よく分類できた．これは背景や体など判断に必要は⼤きく 2 つある．⼀つは「顔のサイズが⼩さい」のない情報を取り除くことができて，かつ顔の位と「⼈間以外」，「複数⼈」の 3 つの否認理由を精置も固定できたためである．

度よく分類するためである．3 カテゴリ分類の問

次に顔検出フィルタの詳細について述べる．顔題をそのまま機械学習で解くよりも，顔検出の問検出には，モデルサイズや推論速度を考慮して題を機械学習で解き，検出した顔の候補領域の⼤CNN（Convolutional Neural Network）の有名な

3 機械学習フィルタ55

図 3.1.2 フィルタ構成の例

モデルである MobileNetV2 [2] を特徴抽出器とすり，これらの課題を解決した．

る SSD（Single Shot MultiBox Detector）[3] のモデルを使⽤した．顔検出の後処理には，Soft-NMS [4] を⽤いた．

3.2

アップデートを考慮したフィルタの構築

2.2 項の課題 2 で述べたとおり，⼀部の否認理由

ここで，後処理に Soft-NMS を⽤いた理由を簡に該当する画像において，外部の要因でデータが単に説明する．⼀般的に物体検出の後処理によく頻繁に変わることによる機械学習モデルの陳腐化使⽤されている NMS（Non-maximum Suppres-が問題となっていた．それを解消するためには機sion）は，モデルが予測した候補領域の中に，信頼械学習モデルのアップデートが必要だが，適切な度が⾼い領域とその領域に重なっている候補領域

頻度は分類対象の否認理由によって異なる．仮にがあったときに，領域の重なり度合いを表す IoU

複数の否認理由を 1 つの機械学習モデルで多クラがある閾値以上の場合に重なっている候補領域をス分類した場合，ある 1 つの否認理由に該当する

削除するというものである．しかし NMS には次データが外部要因によって変わったときに，それの問題がある．隣接した物体に対する候補領域のに伴って機械学習モデルをアップデートすると，ほ信頼度がどれほど⾼くても，IoU が閾値を超えてかの否認理由に対する分類結果も変わってしまう

しまった場合には隣接した物体に対する候補領域

おそれがある．これを避けるために，アップデーが除外されてしまう．タップルのプロフィール画

トの頻度が多いフィルタは可能な限り分離した．

像として投稿されて，⼈の⼿によるラベリングでこれにより，ほかの否認理由を分類するフィルタ「複数⼈」という理由で否認された画像の中には，の精度への影響を避けることができ，精度検証も

2 つの顔が⾮常に近いものが多く，⾃動処理によしやすい．

る顔検出で 2 つの顔を⾼い信頼度で検出できても，タップルのプロフィール画像審査では，特に加後処理で NMS を使⽤すると，いずれかの候補領域

⼯を検知する分類モデルの更新頻度が多いので，図が IoU の閾値処理によって除外されてしまい，顔3.1.2 のように，「加⼯」を分類するモデルと，「卑が 1 つだと判定されて承認してしまうケースが多猥」や「グロテスク」を分類するモデルとを分離くあった．このことから，IoU の値を使って信頼し，それぞれを別々のフィルタとすることでアッ度を減少させて信頼度に対して閾値処理を⾏うア

プデートしやすいしくみとした．

ルゴリズムである Soft-NMS を使⽤することによ

しかし，このようにいずれも分類問題として解こうとしているものを，否認理由ごとに異なる機

56

3.1 マッチングサービスにおける画像審査の⾃動化

械学習モデルを学習させてフィルタを分けたときする画像の割合を指している．現在稼働しているには次のような短所があると考えられる．⼀つは，システムにおける適合率は常に 99% を超えるもの

複数の機械学習モデルが必要になるために，デーになっている．

タセットの作成や学習および評価がそれぞれのモデルで必要となり，管理が難しくなってしまうことである．もう⼀つは，推論に必要となるマシン
リソースや推論時間が増加することである．
タップルのプロフィール画像審査においては，これらの問題を考慮したうえでも，⾼頻度でアップ

実際にフィルタを導⼊することで，次の 3 つの効果があった．

• 監視コストの削減• 審査結果のブレの防⽌• 審査時間の短縮

デートするフィルタを分離するほうがアップデー

⾼い適合率を保ちながら，1 節で述べたプロトの作業も最⼩限で済み，フィルタ全体の精度のフィール画像審査の課題の 2 つを解決できただけ

ブレが⼩さくなるため，加⼯を分類するモデルはでなく，審査時間の短縮も同時に実現できた．

分離することとした．

またフィルタ導⼊後もフィルタの品質を担保することは重要であり，フィルタの精度の悪化や投4 フィルタの導⼊と結果開発した機械学習フィルタは，内製の総合監視基盤システム Orion（オライオン）[5] 上で動作している．監視オペレータは，⽇々 Orion の Web UI
を通して，ユーザが投稿したコンテンツを効率的に監視している．
タップルの画像審査における Orion での処理の流れを，図 3.1.3 を⽤いて簡単に説明する．タップ
ルで投稿されたプロフィール画像は，まずサービ

稿されるデータの変化をただちに検知する必要がある．そのためにフィルタの予測結果の割合や⾃動承認率などのメトリクスを定常的に収集し，それらに⼤きな変化があった場合はアラートを通知するしくみも整えている．また図 3.1.3 にあるよ
うに，通常はフィルタが承認した画像を監視オペ
レータが⽬視で確認することはないが，定期的にその⼀部を監視オペレータが⽬視で確認すること
で，フィルタの精度の悪化やデータの変化をいち早く検知できるように努めている．

スを提供するサーバから Orion に転送され，本稿で説明した機械学習フィルタにより⾃動審査が⾏われる．機械学習フィルタが承認できると判定した場合は，そのまま投稿された画像が承認であることをサービス側に返す．もし否認と判定した場
合は，今までと同様に監視オペレータが⽬視で審査を⾏ってサービス側にその結果を返す．これにより，機械学習フィルタで承認と判定される画像の分の監視コストを削減できる．ただし機械学習

5 まとめ
本項では，当社のマッチングサービスであるタッ
プルのプロフィール画像審査における課題を紹介
し，それを解決するための機械学習フィルタの開発における⼯夫などを具体例を⽤いて紹介した．
今後は Precision を維持したまま，⾃動否認の導⼊などを視野にコスト削減率の向上に取り組んでいきたい．

フィルタで⾃動承認した画像は，監視オペレータが⽬視で審査を⾏うことはないため，不適切なプ
ロフィール画像が⾃動承認されてしまうと，サー

参考⽂献

ビス品質が低下する可能性がある．これを防ぐた[1] ⾓⽥ 孝昭，數⾒ 拓朗： アメブロを護る：不適め，適合率（Precision）を最も重視して機械学習

切コンテンツの傾向分析と検知⼿法の検討 ，フィルタを構築した．ここでの適合率は，フィル

CyberAgent, CyberAgent 秋葉原ラボ技術報

タが承認する画像のうち，監視オペレータも承認

告 Vol. 2，2018.

参考⽂献

57

図 3.1.3 画像審査の簡略図[2] M. Sandler, A. Howard, M. Zhu, A. Zhmogi-

Davis: “Soft-NMS—improving object detec-

nov, and L. Chen: “MobileNetV2: Invertedtion with one line of code,” 2017 IEEE In-

residuals and linear bottlenecks,” The IEEEternational Conference on Computer Vision

Conference on Computer Vision and Pattern(ICCV), 2017.

Recognition (CVPR), pp. 4510–4520, 2018.

[5] Y. Fujisaka: “Orion: An Integrated Mul-

[3] W. Liu, D. Anguelov, D. Erhan, C. Szegedy,

timedia Content Moderation System for

and S. E. Reed: “SSD: single shot multibox

Web Services,” The Annual ACM Interna-

detector,” European Conference on Com-tional Conference on Multimedia Retrieval

puter Vision (ECCV), 2016.

(ICMR), Industrial Session, 2018.

[4] N. Bodla, B. Singh, R. Chellappa, and L. S.

58
Akihabara Lab

3.2

NG 画像フィルタの設計から運⽤まで

岩井 ⼆郎

概 要 ブログプラットフォームにおける有害画像の検出という技術課題を端緒にして，より⼀般的な課題として画像分類フレームワークの開発と推論 API のインフラ構築に取り組んだ．画像分類フレームワークとして複数サービスの要求に迅速に低コストで応える gmclf を提案する．個々のサービスの要求の共通性と相違点の分析に基づいて導出した gmclf のアーキテクチャの特徴について述べ，gmclf の適⽤事例として

NG 画像フィルタを紹介し，評価結果を報告する．推論 API のインフラ構築については NG 画像フィルタ
を例にしてコンポーネントの構成と技術選定および現状の課題について述べる．

Keywords

機械学習, コンピュータビジョン，畳み込みニューラルネットワーク, CNN, 画像分類

1 はじめにザの投稿を監視する必要がある．
従来 Ameba ブログでは Orion によるユーザ投

1.1

ビジネス課題稿の有⼈監視を⾏ってきたが，最近ではテキスト

⼀般的に Web でサービスを提供する企業にとっについてはキーワードマッチングや機械学習などて魅⼒的なサービスを提供し続けるということはの技術を⽤いた監視の⾃動化が積極的に進められ企業の存在理由そのものであり，当然のことながている．しかしながら画像については⼀⽇あたり

らステークホルダーにとって⼤きな関⼼事である．

数⼗万枚の投稿を 24 時間体制で有⼈監視していサイバーエージェントのメディア事業においてるというのが実情であり，サービス品質の維持とも Ameba ブログ，ABEMA，タップルなどのさともにコスト削減のために監視の⾃動化が喫緊のまざまなインターネットサービスを展開している

課題となっていた．以上のような背景を踏まえてが，ユーザにとって有益なコンテンツ，プラット

本稿では以下の 2 つの課題に焦点を絞って話を進フォームを提供することはいうまでもなく，低コ

める．

ストで⾼いサービス品質を維持することも常に優• サービス品質の維持

先度の⾼い課題である．たとえば，Ameba ブログのようなブログのプラットフォームではユーザがテキストだけでなく，静⽌画像，動画像を投稿する• コスト削減
1.2

技術課題

しくみが提供されている．ユーザの投稿するコン

上記のビジネス課題を踏まえて秋葉原ラボの画

テンツは多くのサービス利⽤者の⽬に触れるため，

像チームでは機械学習を⽤いて Ameba ブログの

有害なコンテンツが投稿されるとサービスの価値

投稿画像から有害画像を検出するという技術課題を毀損しビジネスに負のインパクトを与える．しに取り組んできた．

たがってサービス品質維持のために継続的にユー多くの画像の中から何らかの基準を満たす，ある2 画像分類フレームワーク gmclf

59

いは満たさない画像を検出するタスクはより⼀般

今後需要が⾒込まれるさまざまなサービスの要求的な既定クラスへの画像分類のタスクの⼀部としに合わせてその都度迅速に画像分類器を作成できてとらえることができる．画像分類はコンピューる汎⽤的な画像分類器作成のためのフレームワー

タビジョンの分野では古くから扱われてきたタスクを開発することを試み，このフレームワークをクであるが，2012 年の CNN（畳み込みニューラ

gmclf と名付けた．以下に gmclf が備えるべき特ルネットワーク）の登場 [1] 以降⾶躍的に分類精度

徴を列挙する．

が向上して実⽤レベルになっている．CNN を実際のアプリケーションに適⽤する場合は分類器の学習に膨⼤な教師データが必要になるため，どのよ
うにデータを収集するか，そのコストをいかに低減するかが課題となる．また，Ameba ブログ以外のサービスにおいても画像の何らかの属性に基づくサービス提供をしたいという需要は多く，今後さまざまなサービスへ機械学習による画像分類の適⽤が⾒込まれている．
複数のサービスへ機械学習による画像分類を適• 分類器のモデル変更が容易である• 利⽤できる教師データが少ない場合でも実⽤的な分類器を作成できる• データ収集を⽀援するしくみがある• 精度を確認しながらデータを容易に選別するしくみがある• 複数の分類器を作成してもコードが重複することがない• コードとデータを分離して管理できる⽤する場合，個々のサービス要求に応じて最⼩限

上記の特徴が実現されるように個々の分類器への開発コストで迅速に分類器を学習できる環境がの要求によって変化すること（共通性），変化しな整備されていることが開発効率を向上させてコスいこと（相違点）を明確にしてアーキテクチャを決トの削減につながるという意味で重要である．さ定した．共通性と相違点とをまとめると以下のよ

らに，運⽤および保守という観点からはレイテン

うになる．

シやスループット，可⽤性についてサービスの要
求に応える分類器の推論 API のインフラをいかに低コストで提供するかということが課題となる．
技術課題をまとめると以下のようになる．

共通性• 画像分類の基本的な技術• データ収集の⼿順• 画像分類器開発の汎⽤的な環境の整備• 学習の⼿順• 推論 API のインフラの構築• 分類器の精度の評価，可視化の⽅法

以降の 2 節では上記の 1 つ⽬の技術課題を解決するために開発した画像分類フレームワーク gm-

相違点

clf について詳述し，3 節では gmclf を使って作成• データ

したブログの有害画像検出を⾏う NG 画像フィル• 分類器のモデル

タとその性能評価について述べ，4 節では推論 API• 学習のパラメータとインフラの構築について簡潔に議論し，5 節では以降でこれらの共通性と相違点を実現する仕様

まとめと今後の課題について述べる．

と技術およびその選定理由について述べる．gmclf
は画像のダウンロードや分類器の学習，テスト⽤

2 画像分類フレームワーク gmclf

API，可視化ツールなどのデータによって変わらないアルゴリズムを Python で実装し，gmclf とは別

前節で述べた技術課題を考慮し，特定のサービのディレクトリ（以降プロジェクトディレクトリ

スに特化した画像分類器を作成するのではなく，という）に，画像に加えて CNN の学習済みモデル

3.2 NG 画像フィルタの設計から運⽤まで

60

図 3.2.1 gmclf のアーキテクチャ

や学習パラメータなどを指定する設定ファイルをは転移学習を使うことで初期状態から学習するよ

YAML で記述し配置する．この構成により上記のりも教師データの量や学習時間をはるかに削減で共通性と相違を実現するとともにコードとデータきるということが挙げられる．学習済みモデルはの分離を図っている．

ほかの学習パラメータとともに設定ファイルで以

画像分類の基本的な技術としては CNN を採⽤

下のように指定する．

している．検討開始時点で実⽤的な精度を期待できる技術としては CNN 以外の選択肢がなかったというのが実際のところであるが，むしろ近年の

CNN の精度向上によって gmclf の開発が可能になったという⽅が適切である．

CNN を実現する深層学習のフレームとしては
Python の深層学習ライブラリ Keras*1 ，バックエ
ンドとして TensorFlow*2 を採⽤した．Keras では
画像分類器として利⽤できる学習済みモデルが多数サポートされていること，記述の⾃由度は下がるが TensorFlow を直接に使うよりも少ないコー
ド量で⽬的を達成できることなどが採⽤理由である．検討時はバックエンドとしては TensorFlowと Theano*3 が選択できたが TensorFlow の⽅がNV_GPU: 0
BATCH_SIZE: 64
EPOCHS: 10
PATIENCE: 10
BASE_MODEL_NAME: vgg16
FIXED_LAYERS: ~OPTIMIZER:
name: adamparam:
lr: 1.0e-04
L2: 0.001
DROPOUT: 0.5
MODEL_NAME: catndog_vgg16_v1

シェアが⾼く今後の発展性があると判断して採⽤

ここで BASE_MODEL_NAME: が学習済みモデルを表した．

す．データ収集の⼿順に関しては⼀般論としてはKeras の画像分類のための学習済みモデルは代

サービスごとに収集⽅法が異なるが，gmclf では画

表的な CNN のモデルを ImageNet*4 を使ってあら像は URL で⽰されるものとして定めて，画像の収かじめ学習されており，⽬的に応じて精度とモデ集を統⼀的に扱うことができるようにしている．

ルの複雑さについてトレードオフを検討できる．

画像分類のためのデータセットは画像を⽰す

さらに学習済みモデルを⽤いることの利点として

URL と教師ラベルを⽰すテキストの組の集合と*1 https://keras.io/ja/*2 https://www.tensorflow.org/*3 http://deeplearning.net/software/theano/*4 http://www.image-net.org/

3 NG 画像フィルタとその性能評価

61

して CSV 形式で表現する．ユーザは分類器の学

ROUTE_API: /catndog/api/v1/classify

習に先⽴ってあらかじめデータセットとして CSV

ROUTE_WEB: /catndog/web/v1

ファイルを⽤意する．gmclf は分類器の学習の前

PORT_API: 5003

処理として CSV ファイルにしたがって画像をダウ
ンロードして Keras の形式に沿って画像を保存す
る．画像が少ない，あるいはまったくない場合でもキーワードを指定して Web クローリングにより画像を収集できる．キーワードは教師データのク
ラスごとに複数のキーワードを組み合わせて指定できる．たとえば⽝と猫の画像を判別する分類器を作成する場合は設定ファイルに以下のように指定できる．

図 3.2.2 に⽰すように Web UI では画像の URLを指定して分類器の推論結果を視覚的に確認できるほか，Grad-CAM [2] というアルゴリズムにより CNN のモデルで判断の根拠として画像のどの部分が重要視されているかをヒートマップで表⽰する．
さらに画像の下の追加ボタンを使って表⽰されている画像をプロジェクトディレクトリに追加できる．プルダウンメニューでは画像を学習データ

CLASSES:に追加するか検証データに追加するかの選択と，ど- catのクラスに追加するかの選択とを⾏う．上部の検-索タブを選択すると図 3.2.3 のように混同⾏列を- ’ 三⽑猫’

表⽰し，⾏列要素を選択して検索ボタンを使って- ’ アメリカンショートヘアー’

誤分類した画像を確認できる．画像の直下に表⽰- ’ マンチカン’

されるプルダウンメニューでクラスを変更してア- dog

ノテーションの誤りを修正したり，不適切なデー-

タを学習データから除外したりできる．

- ’ シェルティー’

⽝画像と猫画像の分類器を作成する場合の例を- ’ 柴⽝’

挙げると，画像分類や CNN に関する知識のない⼈- ’ ゴールデンレトリバー’

であってもまったく教師データがない状態から数

データセットを表す CSV ファイルと設定ファイルをプロジェクトディレクトリに⽤意し，gmclf を

clone したディレクトリで以下のようにプロジェ

⼗分程度で精度 90% 程度の分類器を作成できる．

3 NG 画像フィルタとその性能評価

クトディレクトリを指定してコマンドラインから

本節では gmclf を Ameba ブログの有害画像検

make を実⾏するとデータのダウンロード，重複出に適⽤して作成した NG 画像フィルタについて

チェック，分類器の学習までが⾃動的に⾏われる．

述べる．

$ make PRJ_DIR="プロジェクトディレクトリ名"
データセット
学習終了後，api をターゲットとして make を実⾏するとテストと可視化のための Web サーバがローカル環境で動作する．

NG 画像フィルタの元のデータセットは 75 種類のラベルが付けられた 13400 枚の画像からなる．

NG 画像フィルタを作成するにあたって画像分類$ make PRJ_DIR="プ ロ ジ ェ ク ト デ ィ レ ク ト リ

タスクとしての難易度やクラス間のデータ数の不名" api均衡などを考慮してクラスを 12 種類に統合した．
さらにデータ数が⼗分にあり実際にブログへの投URL のパスおよびポート番号は以下のようにあらかじめ設定ファイルに指定しておく．

稿で頻発する 4 種類のクラスに属する画像のみを取り出し，データ数の不均衡を是正するようにダ3.2 NG 画像フィルタの設計から運⽤まで

62

図 3.2.2 可視化ツールの UI（1）

図 3.2.3 可視化ツールの UI（2）ウンサンプリングとクローリングによる画像の追加を⾏った．各クラスの意味とデータ数は図 3.2.4
左上のとおりである．

モデルの学習と精度評価
学習済みモデルとしては InceptionResnetV2 を使⽤し，conv 層の重みは固定した上で元の全結合を削除して新たに付加した全結合層のみを学習した．全結合層は Global Average Pooling 層，1024
ユニットの全結合層，4 ユニットの全結合層を付加

3 NG 画像フィルタとその性能評価

63

し，活性化関数としてはそれぞれ ReLU，softmaxの場合とをそれぞれ⽰している．残念ながら今回を使⽤した．

試⾏したパラメータの範囲内では NG 画像フィル

データセットを 8 対 2 で学習データと検証デー

タのデータセットでは VAT の効果が確認できな

タに分割して，最適化⼿法として SGD およびかった．原因については転移学習で浅い層の重み

Adam を⽤い，学習率を固定して NVIDIA の GPUを固定しているために精度向上につながる特徴がV100 を使って 2000 エポック学習した．学習時間

⼗分に学習できていないなどの理由が推測されるは 48 時間程度である．検証データの学習曲線と精が，詳しい検証は今後の課題である．

度評価の結果を図 3.2.4 左下および右に⽰す．

データセットを CSV ファイルとして準備すれ
ば，以降のモデルの学習，精度評価，データの追加

Virtual Adversarial Training
CNN による画像分類は⼈間に認識できない画と削除の作業はすべて gmclf だけで完結しているので，試⾏錯誤のイテレーションを迅速に⾏える．

像のわずかな変化で分類結果が⼤きく変わってしまう脆弱性 [3] が指摘されているが，これを逆⼿

実際の投稿画像での評価に取って摂動を加えた画像を学習データとして⽤実際に Ameba ブログに投稿された画像で NGいることにより分類精度を向上させる Adversarial

画像フィルタを評価した結果について述べる．評

Training [4] [5] という⼿法が提唱されている．NG

価データは 2019 年 11 ⽉から 2020 年 1 ⽉に投稿

画像フィルタの分類精度向上の⼀環として gmclf

された画像からランダムに 10 万枚を選択した．

に Adversarial Training の⼀種である VAT（Vir-NG 画像フィルタは 1 枚の画像に対して 4 つのtual Adversarial Training）[6] を実装し，NG 画

クラスについての確率を推論する．4 つのクラス

像フィルタのデータで精度評価を⾏った．以下のはそれぞれ e3（卑猥），g3（グロテスク），id（QR

ように VAT を⽤いるか否かの指定とパラメータのコード），ok（適切な画像）であり，ok に分類さ値もプロジェクトディレクトリの設定ファイルでれる確率を OK 確率，1−OK 確率を NG 確率，あ指定できる．

る画像について OK 確率が閾値以上の場合 OK 画
像，閾値より⼩さい場合 NG 画像とここでは呼ぶ

VAT:ことにする．

USE: true
PARAM:
EPS: 5.0
XI: 10.0
IP: 1

評価データについての OK 確率をヒストグラムで表⽰すると図 3.2.6 左上のようになる．ヒスト
グラムから，過半数の画像が OK 確率 0.9 から 1.0に含まれることが分かる．ヒストグラム中で⾚で⽰している部分は⽬視で有害と判断できる画像の学習済みモデルとしては ResNet50 を使⽤し

枚数のサンプリングによる推定値である．サンプ

164 層までの重みは固定し 165 層以降と元の全結リングではヒストグラムの各レベルで 1000 枚の画合を削除し新たに付加した全結合層を再学習した．

像をランダムに抽出して⽬視によって有害画像か

全結合層の構造，データセットの分割，GPU は前どうかを確認した．図 3.2.6 右上では閾値の変化に

述のとおり変更せず，最適化⼿法として Adam を伴う NG 画像の割合を⽰している．閾値 0.5 で全⽤い，学習率を固定して学習した．学習時間は 12

画像の約 28% を NG 画像と判定している．これに〜48 時間程度である．検証データの学習曲線と精より OK 画像について有⼈監視をしないことにす

度評価の結果を図 3.2.5 に⽰す．緑が VAT を使⽤ると 72% コスト削減が可能となることが分かる．

しない場合を⽰し，⾚と灰⾊が VAT を使⽤した

実際のコスト削減については，NG 画像フィル

ときに画像に与える摂動のノルムが 1 の場合と 2タの運⽤により 60% 程度の削減を確認している．

3.2 NG 画像フィルタの設計から運⽤まで

64

図 3.2.4 データセットの内訳，精度評価結果

図 3.2.5 VAT の精度評価

図 3.2.6 左下では閾値の変化に伴って OK 画像への有害画像の混⼊率の上限がどのように変化する

4 推論 API のソフトウェアとインフラ構成

かをヒストグラムから計算して⽰した．ヒストグ
ラムの各階級における有害画像の枚数が正規分布に従うとし，有意⽔準 0.05 における信頼区間か
ら混⼊率の上限を定めた．閾値 0.5 で OK 画像の0.027% が有害画像となっている．これは Ameba
ブログのサービス品質として⼗分許容できる値であり，実際の有害画像の含有率も上限を下回っている．

本節では 2 つ⽬の技術課題である推論 API のイ
ンフラ構成と関連するソフトウェアの構成について述べる．NG 画像フィルタの推論 API は平均で3RPS，ピーク時で 30RPS のリクエストに 3 秒以内に応答することが求められ，99% 以上の可⽤性を維持することが努⼒⽬標となっている．
インフラ構築に必要な時間，障害発⽣時に容易に復旧できること，適⽤範囲の拡⼤に伴うリソースの柔軟な増強ができることなどを考慮して Amazon*5 https://aws.amazon.com/jp/

5 まとめと今後の課題

65

図 3.2.6 左上：OK 確率のヒストグラム，右上：NG 画像の割合，右上：有害画像の混⼊率，左下：インフラ構成

Web Services（AWS）*5 にインフラを構築した．パては⻑期的にパブリッククラウドを⽤いるよりもブリッククラウドとしてはほかの選択肢もあるがオンプレミスの⽅が有利になる可能性が⾼いので社内でのサポートが得やすいことから AWS を採

オンプレミス環境への移設を検討中である．

⽤した．
開発効率と汎⽤性を考慮しアプリケーションを5 まとめと今後の課題

構成する主要なコンポーネントは Docker コンテナとして実装している．RESTfull API は gunicorn，

画像分類が必要となる Web におけるサービス品

flask を使って実装し，推論サーバについては OSS

質の維持とコスト削減という課題に対する解決⽅の NVIDIA Triton Inference Server*6 を採⽤して法の⼀つとして画像分類フレームワーク gmclf をいる．採⽤理由としては汎⽤性の⾼さと GPU の提案し共通性と相違点の分析に基づくアーキテク

特性を考慮したパフォーマンスチューニングがで

チャが複数のサービスの要求にどのように応える

きることが挙げられる．gmclf で作成したモデルか詳述した．gmclf の適⽤例として NG 画像フィをサーバの所定のディレクトリにアップロードす

ルタを紹介し，ブログのプラットフォームにおけることにより推論サーバのローリングアップデー

る有害画像検出という技術課題をどのように解決

トが可能であり，モデルを変更することで NG 画

するかについて精度とコスト削減を定量的に⽰す

像フィルタ以外のアプリケーションでも動作可能

とともに，インフラ構成の技術選定とその課題にな汎⽤的な構成となっている．

ついて述べた．

インフラ構成の概念図を図 3.2.6 右下に⽰す．本

gmclf の仕様は現状のサービス要求に⼗分に応稿執筆時点での推論 API への要求，ソフトウェア，

えられるものであるが，実装⾯ではコードの冗⻑

インフラ構成について述べたがこれは必ずしも最さ，構成の分かり難さがあることは否めず，CI/CD

良の選択であるとは限らない．特にコストについが整備されていないなどの課題もある．今後はオンプレミス環境への移設や，Kubernetes などのコ

*6 https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/

3.2 NG 画像フィルタの設計から運⽤まで

66
ンテナオーケストレーションの導⼊を意識し画像

ceedings of the IEEE international confer-

分類だけに限定しないより⼀般的な画像解析基盤

ence on computer vision (ICCV), pp.618–

として改良することを計画している．

626, 2017.

本稿が汎⽤的なソフトウェアの開発に取り組む[3] Szegedy, Christian, et al.: “Intriguing prop-

開発者にとって何らかの参考になれば幸いである．

erties of neural networks,” arXiv preprint
arXiv:1312.6199, 2013.

参考⽂献[4] Alexey, Kurakin, et al.: “Adversarial machine learning at scale,” arXiv preprint[1] Krizhevsky, Alex, et al.: “Imagenet classi-

arXiv:1611.01236, 2016.

fication with deep convolutional neural net-

[5] Tram è r, Florian, et al.: “Ensemble adver-works,” Advances in neural information pro-sarial training: Attacks and defenses,” arXiv

cessing systems (NIPS), pp.1097–1105, 2012.

preprint arXiv:1705.07204, 2017.

[2] Selvaraju, Ramprasaath R., et al.: “Grad-[6] Miyato, Takeru, et al.:“Distributionalcam: Visual explanations from deep net-smoothing with virtual adversarial training,”

works via gradient-based localization,” Pro-

arXiv preprint arXiv:1507.00677, 2015.

67
Akihabara Lab

2019 年発表⼀覧

技術報告

Vol.3

書籍・解説記事• 森下 壮⼀郎，⽔上 ひろき，⾼野 雅典，數⾒ 拓朗，和⽥ 計也： データマイニングエンジニアの教科
書 ，C&R 研究所，2019．

• ⽔上 ひろき，福⽥ 鉄也，⼭下 剛史，Juhani Connolly，武内 慎，數⾒ 拓朗，福⽥ ⼀郎： AWA における類似プレイリスト探索システムの構築 ，デジタルプラクティス誌 招待論⽂，Vol.10，No.2，2019．
論⽂誌・国際会議（査読付き）• M. Takano, F. Taka, S. Morishita, T. Nishi, and Y. Ogawa: “Expressing Modern/Oldfashioned
Racism against Zainichi Koreans in Japan depending on News Contents of Internet Television,”
5th International Conference on Computational Social Science (IC2S2), Extended Abstract, 2019.
• T. Masanori and T. Tsunoda: “Self-Disclosure of Bullying Experiences and Social Support in
Avatar Communication: Analysis of Verbal and Nonverbal Communications,” The 13th in International AAAI Conference on Web and Social Media (ICWSM-2019), 2019.
国内学会/セミナー• 松⽥ 和⼰，鈴⽊ 元也，和⽥ 計也： インターネットテレビ局 AbemaTV におけるコメントデータ解析〜BI ツール Tableau を⽤いた可視化〜 ，⽇本計算機統計学会 第 33 回シンポジウム，2019．

• ⽔上 ひろき： ⾳楽配信サービスにおける推薦システムの概要と数理モデルについて ，⽇本数学会
2019 年度秋季総合分科会 ワークショップ「数学ソフトウェアとフリードキュメント XXIX」，2019．
• ⾼野 雅典： アバターコミュニケーションにおける⾃⼰開⽰とソーシャルサポート —ピグパーティの⾏動ログ分析と質問紙調査— ，⽇本⼼理学会第 83 回⼤会 公募シンポジウム「サブリミナルソーシャ
ルインパクト —環境に埋め込まれたエージェント性とその展開—」，話題提供，2019．

• 上岡 将也： マッチングサービスの画像審査における機械学習の応⽤ ，第 12 回 Web とデータベースに関するフォーラム（WebDB Forum 2019），2019．

• 上辻 慶典，⼤内 裕晃，⾓⽥ 孝昭，數⾒ 拓朗，善明 晃由： Orion Annotator ：機械学習を⽀えるア
ノテーションシステム ，ソフトウェアエンジニアリングシンポジウム 2019，2019．

• 武内 慎： 他⼈への⾳楽推薦⾏動の拡散現象のモデリング ，ネットワーク科学セミナー，2019．
• ⾼野 雅典： インターネットテレビの視聴データによるメディア・コミュニケーション研究 ，マルチメディア，分散，協調とモバイル（DICOMO2019）シンポジウム，招待講演，p.223，2019．

• ⻄ 朋⾥，⼩川 祐樹，服部 宏充，⾼ 史明，⾼野 雅典，森下 壮⼀郎： インターネットテレビのニュー2019 年発表⼀覧

68

ス番組におけるコメント内容の分析 ，第 33 回⼈⼯知能学会全国⼤会，2D4-OS-1a-03，2019．

• ⾼野 雅典，⾼ 史明，森下 壮⼀郎，⻄ 朋⾥，⼩川 祐樹： 現代的∕古典的レイシズムの表出におけるニュース番組の影響：インターネットテレビに投稿される差別的コメントの分析 ，第 33 回⼈⼯知能学会全国⼤会，2D5-OS-1b-05，2019．

• 森下 壮⼀郎： メディアサービスにおけるユーザの継続の冪分布に基づくモデル化 ，第 33 回⼈⼯知能学会全国⼤会，1J4-J-3-01，2019．

• 涌⽥ 悠佑，善明 晃由，松本 拓海，佐々⽊ 勇和，⿁塚 真： Secondary index を活⽤する NoSQL ス
キーマ推薦によるクエリ処理⾼速化 ，The 3rd cross-disciplinary Workshop on Computing Systems,

Infrastructures, and Programming (xSIG), 2019．
• ⾼野 雅典： AbemaTV の視聴データを⽤いたメディア・コミュニケーション研究の試み ，ウェブサ
イエンス研究会 オープンセミナー vol.8，2019．

• ⼭⼝ 想，⾼野 雅典，森下 壮⼀郎，⼭本 悠⼆，福⽥ 鉄也，福⽥ ⼀郎，梁⽊ 俊冴，⾼屋 英知，栗原 聡：
映像シーンに対応した視聴者の感情・印象抽出 ，社会システムと情報技術研究ウィーク（WSSIT19），

ICS10，2019．
• ⾼野 雅典： ⼈と Web サービスの相互作⽤：ピグパーティ、AbemaTV がユーザと社会に与える影
響 ，HAI シンポジウム，招待講演，2019．

• 涌⽥ 悠佑，善明 晃由，松本 拓海，佐々⽊ 勇和，⿁塚 真： Secondary index を活⽤する NoSQL ス
キーマ推薦による Query 処理⾼速化 ，第 11 回データ⼯学と情報マネジメントに関するフォーラム（DEIM2019），H2-4，2019．

• 武内 慎： Hawkes 過程を⽤いた⼈の⾳楽鑑賞⾏動の解析 ，第 3 回計算社会科学ワークショップ（CSSJ2019），2019．

• ⾼野 雅典，⾼ 史明，森下 壮⼀郎，⻄ 朋⾥，⼩川 祐樹： ニュースを起点とするレイシズム表出におけるニュース番組の性質と個⼈の性質の関連：インターネットテレビに投稿される差別的コメントの分析 ，第 3 回計算社会科学ワークショップ（CSSJ2019），2019．

CyberAgent 秋葉原ラボ 技術報告 Volume.3
発 行日
発行所

2020年11月1日 初版
CyberAgent 秋葉原ラボ 技術報告編集委員会〒101-0021
東京都千代田区外神田1丁目18番13号
秋葉原ダイビル 13 階

編

集

數見 拓朗
上辻 慶典
松井 美帆
善明 晃由
森下 壮一郎

デザイン

デザインファクトリー

印刷所

昭栄印刷株式会社© 2020 CyberAgent, Inc.

柴 尚子