Scala, F.O.X

1. F.O.Xを支えるScala
CyberZ 鈴木 雄登

2. 自己紹介
• 鈴木 雄登
• 株式会社CyberZ
• @moc_yuto
• http://yuutookun.hatenablog.com/

3. 株式会社 CyberZ
スマートフォンに特化した広告マーケティング会社です。
■事業
①F.O.X（スマホ広告計測ツール）
toBプロダクト：アドテクノロジー事業
②OPENREC（ゲームプレイ動画メディア）
toCプロダクト：スマートフォンメディア事業
e-Sports大会「RAGE」開催

4. F.O.Xとは？
F.O.Xとは、スマホ広告におけるマーケティングの統合プラットフォーム
アプリDL、計測、解析、レポートまでを
ワンストップで行うことができます。

5. F.O.Xとは？
• 機能の例としては
• どの広告からどれくらいインストールされているか？
• アプリの継続率はどれくらいか？
• あるイベントポイントにどれくらい到達したか？

6. 今日のアジェンダ
• Scalaとの出会い
• Scalaでの開発
• 現在のScala

7. Scalaとの出会い

8. Scala導入前
• 2014年以前の話
• 作っているものはF.O.Xオンリー

9. F.O.Xの構成
• SDK
• SDKとの通信APIサーバ
• 集計サーバ
• 管理画面

10. F.O.Xの当時の構成
集計
計測データ
RDB & KVS
計測サーバ（Java）
管理画面（PHP）

11. 当時の使用言語
• サーバーサイド
• PHP
• Java
• フロントエンド
• jQuery…

12. 大量のレガシーコード
この先生きのこれない
新しいチャレンジをしよう！

13. 次のプロダクトを新しい言語
で作ってみよう！

14. 言語選定によりScalaに決定

15. Scalaへの決定要因
• やりたいと手を上げた人が多かった
• 理由としては一番大きい
• もともとJavaを使っている人が多かった
• 関数型という新しいパラダイムを触れる

16. 実際何を作ることに
なったのか？

17. 当時の作成予定のプロダクト
• F.O.X新管理画面
• BidExpress

18. 当時の作成予定のプロダクト
• F.O.X新管理画面
• BidExpress
こちらについて
話します

19. F.O.Xの当時の構成（再掲）
集計
計測データ
RDB & KVS
計測サーバ（Java）
管理画面（PHP）

20. F.O.Xの当時の構成
集計
計測データ
RDB & KVS
計測サーバ（Java）
管理画面（PHP）
ここのリプレイス

21. F.O.Xの新構成
設定
レポート 解析
マーケット調査

22. この構成で直面した問題
• F.O.XのDBのアクセス部分を各サービスで作る手間
• データモデルの理解が難しい上、
DBもいろんな要件で複雑化
• DBではバリデーションもできない
APIサービスとして切り出し
※モデルの変更は今回のスコープ外

23. F.O.Xの新構成
ここをつなぐAPIが欲しい

24. F.O.Xの新構成
APIサーバ

25. F.O.Xの新構成
APIサーバScala

26. Scala導入期

27. Scala投入プロジェクトを決定
• DBアクセスを担うAPIをScalaで作ろう
• 新管理画面もScalaで作ろう

28. 開発をスタートするも。。。
• 参考にするソースもわからない
• そもそもチーム全員の経験が浅い
• レビューワーがいないため
• Scalaのベターな書き方がわからない
• 汚いコードに。。

29. 発生する開発遅延
• Scalaの経験が浅いため工数が読めない
• 悩めるSlick
• コードの可読性の低下
• 非同期処理のハンドリング

30. 可読性低下の要因
• implicit defの多用
• 省略しすぎ
• case classに定義しないでtupleだらけ
• mapとタプルの組み合わせで_1だらけに
• 各レイヤーで責務が分離されていない
• 抽象化できず、コピペ(ry

31. 非同期処理
• WebサーバのデータソースがAPI＝非同期処理
• API経由なので、ロジックの中がほぼFuture
• 初期はこれが辛かった。
• Seq[Future[Int]]をFuture[Seq[Int]]に変えるとか
• 逆にFutureに慣れるスパルタな練習にもなった

32. ツールの選定

33. フレームワーク選定基準 API
• Sprayを選定
• APIなので、薄めのフレームワークがよかった
• 速い
• 既にCyberAgentのアドテクスタジオが運用していた

34. フレームワーク選定基準 Webサー
バ
• Play Framework
• 日本語ドキュメントが多い
• ブログ記事も一番多い

35. ORM選定基準
• Slick2系を選択
• 利用ユーザ数が多いとのことで結構エイヤで決めてしまっ
た。
• Typesafeがバックアップしていたというのも大きかった

36. コネクションプール選定
• CommonsDBCPを選択
• これは元々Javaで使っていたので選択。

37. シャーディング時の複数DB接続
• メモ化でホスト名を可変に

38. 約1年後のいま

39. 運用
• F.O.X新管理画面、BidExpressともに運用フェーズ
• 基本的に運用はほぼJavaと同じ

40. 監視
• インフラ周りの監視は基本的に全てZabbixを利用
• Javaを使っていたので(ry
• akkaなどを使っている場合は、メッセージボックスの監
視など必要だが、今のところそこをチューニングするほ
どには至っていない。
• そろそろ入れる予定

41. コードレビュー体制
• Scalaでコードレビューできる人材が着実に増えている
• チームの2人がLGTMを出したらマージ
• レビューする文化を育む
LGTM

42. 現在のF.O.Xチーム内のScala
• 利用率：約45％
• チーム数：4チーム
• 使われている場所
• 管理画面用のWebサーバ
• API
• 高トラフィックな新プロジェクト

43. リリースサイクル
• リリースサイクルは1週間に一度
• CI環境
• Jenkins
• コンパイルが遅いので
• CPU4コア、16GBのサーバ
• 2プロジェクトで共用

44. アドテク×Scalaでのメリット
• アドテクはとにかく連携が多い
• 連携について統一的な規約がない
• なるべく汎用的に作る必要がある
• 言語レベルで抽象化がしやすい（型パラメータとかimplicitとかtupleとか）
• 新しい連携仕様が度々追加され、変更も多い
• 型があると、ドラスティックにリファクタができる
• パフォーマンスが求められる部分に最適
• JVMベースなのでパフォーマンスが出しやすい
• 非同期処理のハンドリングがすごい楽

45. まとめ
• 初期コストは高い
• 継続すると初期コストに見合ったリターンがある
• やりたいという気持ちが大事
• アドテクはScalaが向いている（と思っています）

46. CyberZでは一緒に
ScalaでF.O.Xを成長させる方を
募集中です！！
お気軽にお声がけください！

47. ご清聴ありがとうございまし
た。