こんにちは。
メディア広告部門(MDH) ADテクノロジー局でフロントエンジニアをやっている木田と申します。
ぽかぽかとした陽気が続き、すっかり春めいてきました。
弊社オフィスのある、渋谷マークシティ入り口の桜も綺麗に咲き始めていますよ。
MDHでは、技術者のための勉強会 「 LT Thursday 」を隔週で開催しています。
この勉強会を通して、社員のスキルセットを知ることや個人のスキルの幅を広げることを目的としており、1回あたり3～4名のエンジニアが持ち回りで発表を行っています。
今回の「 LT Thursday 」 は、4人のエンジニアが下記の題材でプレゼンを行いましたので、ご紹介させていただきます。
- IndexedDB 使ってみての感想
- 外れ値検索のアルゴリズム（2）Isolation Forest
- こんな動画広告はいやだ
- API-Gateway & Lambda を使ってみた所感
１．IndexedDB 使ってみての感想（AbemaTV 星野）
AbemaTV 広告局の星野が IndexedDB を採用した際の知見を発表しました。
IndexedDB は、ブラウザで利用できるローカルデータ保存用のデータAPIの一種です。
よく使われている localStorage などのクライアントサイドストレージと比較すると、次のような特徴を持っています。
- localStorage より多量のデータ保存
- Key-Value 型の NoSQL
- 高パフォーマンス
- トランザクションが使える
今回は星野が担当している Abema Zone Select ( AZS ) という社内向けプロダクトでの IndexedDB 採用事例です。
AZS は弊社営業メンバー向けの内製ツールで、iPad 上で利用できる直感的な広告枠プランニングツールです。プロダクトの性格上、オフラインで動作する部分も多く IndexedDB との相性も悪くはないとのこと。
しかし IndexedDB そのものの仕様が勧告レベルのため、動作する環境に制限がある、参考にできる文献が少ないなどの悩みもあったようです。
（スライドは非公開となります）
２．外れ値検索のアルゴリズム（2）Isolation Forest（MDH 大澤）
LT Thursday では珍しい続きモノ発表です。
以前 Vol.15 で大澤が発表した、
「 外れ値検出のアルゴリズム(1) Minimum Covariance Determinant 」の続編。
記事広告の読了率を調べるという命題に対し、異常値を弾くために調査したアルゴリズムの解説です。
ちなみに「異常値 = 外れ値」の定義は以下の通り。
- 他と比べて「変」なデータ
- 「期待されるパターン」にそぐわないデータ
そしてIsolation Forestでは、データ分離を行うために次のように仮定します。
- 正常値 = “数が多くてどれも似通っている”
- 外れ値 = “数が少なくて互いに異なる”
この正常値・外れ値が混ざった状態の値の分布に対して次のような処理を行い、分離を行う手法です。
- ランダムに閾値を設けて分割
- 分離木(Isolation Tree)を作成
- 分離木を通った各データが属する深さ(=分割数)を求める
探索のために Isolation Tree をいっぱい作成することから、
“木” がいっぱい → “森” で Isolation Forest なのだそうです。
詳しい手法とその解説についてはスライドを御覧ください。
大澤曰く、
「前回の説明が難しいという指摘を踏まえ、キャッチーかつグラフィカルな説明を多用する」
を心懸けて資料を作成したとのこと。
その言葉通り非常にわかりやすい発表となっており、会場の声も好評でした。
過去の経験を糧にして聞き手に寄り添いキッチリ改善してくる姿勢は、筆者も見習いたいところです。
３．こんな動画広告はいやだ（AWA 斉藤）
AVA 動画広告チームの斉藤の発表です。
時に、使い手は開発側が想定していない自由な発想と使い方でエンジニアに新たな気付きを与えてくれます。
本当にこんな動画広告があったら…いや、きっとフィクションでしょう。
詳しくはスライドを御覧ください。
４．API-Gateway & Lambdaを使ってみた所感（AbemaTV 末松）
AbemaTV 広告局の末松の発表です。
トップバッターの星野と同じく Abema Zone Select ( AZS ) の開発を担当しています。
AZS では様々な経緯からサーバレス化を断行。
その際に採用したサーバレス技術である、Amazon API Gateway と AWS Lambda についての知見を発表しました。
- サービス化の方法
- API Gateway の謎の仕様にハマった話
- Lambda 対応している言語の中から複数の言語で同じ処理を書き、本当に Scala が早いかを検証（したかった）話
またスライドにはありませんが、発表後の質疑応答にも興味深い事例がありましたので抜粋してご紹介します。
Q. アクセス集中のスローダウンなどのトラブルシューティングはどうしているか？
A. すべてのサービスは 1s 以内に処理完了して返しており、実行時間が 1.5s を超えたら Slack に通知している。
問題が起きたらどの関数で時間がかかっているかを調査していく。外部に接続する部分の I/O で時間がかかるケースが多い。
Q. ELB みたいにプレウォーミングする必要があるのか？
A. Lambda は裏側で EC2 インスタンスが動いているので、最初のアクセス時は起動に時間がかかる。
10 分周期で強制的にポーリングしてウォーミングさせている。
応答性の高いアプリケーションに対しては、コールドスタート状態からの反応は厳しい。
Q. Lambda には関数デプロイパッケージのサイズに制限があるが、どれくらい使用している？
A. 現在 50MB 中の 20MB 使用している。Scalaを選択すると容量が厳しくなってくるかもしれない。
以上、第17回 「 LT Thursday 」 レポートでした。
最後に宣伝となりますが、MDHでは社内外問わず技術交流・合同勉強会を共同開催して頂ける企業様を絶賛募集中です。
もしご興味を持っていただけましたら、メディア広告部門(MDH) の facebook 宛などにお気軽にご連絡ください。
Author:
株式会社サイバーエージェント
メディア広告部門(MDH) ADテクノロジー局
フロントエンジニア
木田 哲路
▼メディア広告部門(MDH)
Ameba Ownd：https://ameba-ad-pr.amebaownd.com/
Facebook：https://www.facebook.com/AmebaAds.CyberAgent/
Twitter：https://twitter.com/amebaads_pr