Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

F.O.Xを支える技術

2,290 views

Published on

Scala, F.O.X

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

F.O.Xを支える技術

  1. 1. F.O.Xを支えるScala CyberZ 鈴木 雄登
  2. 2. 自己紹介 • 鈴木 雄登 • 株式会社CyberZ • @moc_yuto • http://yuutookun.hatenablog.com/
  3. 3. 株式会社 CyberZ スマートフォンに特化した広告マーケティング会社です。 ■事業 ①F.O.X(スマホ広告計測ツール) toBプロダクト:アドテクノロジー事業 ②OPENREC(ゲームプレイ動画メディア) toCプロダクト:スマートフォンメディア事業 e-Sports大会「RAGE」開催
  4. 4. F.O.Xとは? F.O.Xとは、スマホ広告におけるマーケティングの統合プラットフォーム アプリDL、計測、解析、レポートまでを ワンストップで行うことができます。
  5. 5. F.O.Xとは? • 機能の例としては • どの広告からどれくらいインストールされているか? • アプリの継続率はどれくらいか? • あるイベントポイントにどれくらい到達したか?
  6. 6. 今日のアジェンダ • Scalaとの出会い • Scalaでの開発 • 現在のScala
  7. 7. Scalaとの出会い
  8. 8. Scala導入前 • 2014年以前の話 • 作っているものはF.O.Xオンリー
  9. 9. F.O.Xの構成 • SDK • SDKとの通信APIサーバ • 集計サーバ • 管理画面
  10. 10. F.O.Xの当時の構成 集計 計測データ RDB & KVS 計測サーバ(Java) 管理画面(PHP)
  11. 11. 当時の使用言語 • サーバーサイド • PHP • Java • フロントエンド • jQuery…
  12. 12. 大量のレガシーコード この先生きのこれない 新しいチャレンジをしよう!
  13. 13. 次のプロダクトを新しい言語 で作ってみよう!
  14. 14. 言語選定によりScalaに決定
  15. 15. Scalaへの決定要因 • やりたいと手を上げた人が多かった • 理由としては一番大きい • もともとJavaを使っている人が多かった • 関数型という新しいパラダイムを触れる
  16. 16. 実際何を作ることに なったのか?
  17. 17. 当時の作成予定のプロダクト • F.O.X新管理画面 • BidExpress
  18. 18. 当時の作成予定のプロダクト • F.O.X新管理画面 • BidExpress こちらについて 話します
  19. 19. F.O.Xの当時の構成(再掲) 集計 計測データ RDB & KVS 計測サーバ(Java) 管理画面(PHP)
  20. 20. F.O.Xの当時の構成 集計 計測データ RDB & KVS 計測サーバ(Java) 管理画面(PHP) ここのリプレイス
  21. 21. F.O.Xの新構成 設定 レポート 解析 マーケット調査
  22. 22. この構成で直面した問題 • F.O.XのDBのアクセス部分を各サービスで作る手間 • データモデルの理解が難しい上、 DBもいろんな要件で複雑化 • DBではバリデーションもできない APIサービスとして切り出し ※モデルの変更は今回のスコープ外
  23. 23. F.O.Xの新構成 ここをつなぐAPIが欲しい
  24. 24. F.O.Xの新構成 APIサーバ
  25. 25. F.O.Xの新構成 APIサーバScala
  26. 26. Scala導入期
  27. 27. Scala投入プロジェクトを決定 • DBアクセスを担うAPIをScalaで作ろう • 新管理画面もScalaで作ろう
  28. 28. 開発をスタートするも。。。 • 参考にするソースもわからない • そもそもチーム全員の経験が浅い • レビューワーがいないため • Scalaのベターな書き方がわからない • 汚いコードに。。
  29. 29. 発生する開発遅延 • Scalaの経験が浅いため工数が読めない • 悩めるSlick • コードの可読性の低下 • 非同期処理のハンドリング
  30. 30. 可読性低下の要因 • implicit defの多用 • 省略しすぎ • case classに定義しないでtupleだらけ • mapとタプルの組み合わせで_1だらけに • 各レイヤーで責務が分離されていない • 抽象化できず、コピペ(ry
  31. 31. 非同期処理 • WebサーバのデータソースがAPI=非同期処理 • API経由なので、ロジックの中がほぼFuture • 初期はこれが辛かった。 • Seq[Future[Int]]をFuture[Seq[Int]]に変えるとか • 逆にFutureに慣れるスパルタな練習にもなった
  32. 32. ツールの選定
  33. 33. フレームワーク選定基準 API • Sprayを選定 • APIなので、薄めのフレームワークがよかった • 速い • 既にCyberAgentのアドテクスタジオが運用していた
  34. 34. フレームワーク選定基準 Webサー バ • Play Framework • 日本語ドキュメントが多い • ブログ記事も一番多い
  35. 35. ORM選定基準 • Slick2系を選択 • 利用ユーザ数が多いとのことで結構エイヤで決めてしまっ た。 • Typesafeがバックアップしていたというのも大きかった
  36. 36. コネクションプール選定 • CommonsDBCPを選択 • これは元々Javaで使っていたので選択。
  37. 37. シャーディング時の複数DB接続 • メモ化でホスト名を可変に
  38. 38. 約1年後のいま
  39. 39. 運用 • F.O.X新管理画面、BidExpressともに運用フェーズ • 基本的に運用はほぼJavaと同じ
  40. 40. 監視 • インフラ周りの監視は基本的に全てZabbixを利用 • Javaを使っていたので(ry • akkaなどを使っている場合は、メッセージボックスの監 視など必要だが、今のところそこをチューニングするほ どには至っていない。 • そろそろ入れる予定
  41. 41. コードレビュー体制 • Scalaでコードレビューできる人材が着実に増えている • チームの2人がLGTMを出したらマージ • レビューする文化を育む LGTM
  42. 42. 現在のF.O.Xチーム内のScala • 利用率:約45% • チーム数:4チーム • 使われている場所 • 管理画面用のWebサーバ • API • 高トラフィックな新プロジェクト
  43. 43. リリースサイクル • リリースサイクルは1週間に一度 • CI環境 • Jenkins • コンパイルが遅いので • CPU4コア、16GBのサーバ • 2プロジェクトで共用
  44. 44. アドテク×Scalaでのメリット • アドテクはとにかく連携が多い • 連携について統一的な規約がない • なるべく汎用的に作る必要がある • 言語レベルで抽象化がしやすい(型パラメータとかimplicitとかtupleとか) • 新しい連携仕様が度々追加され、変更も多い • 型があると、ドラスティックにリファクタができる • パフォーマンスが求められる部分に最適 • JVMベースなのでパフォーマンスが出しやすい • 非同期処理のハンドリングがすごい楽
  45. 45. まとめ • 初期コストは高い • 継続すると初期コストに見合ったリターンがある • やりたいという気持ちが大事 • アドテクはScalaが向いている(と思っています)
  46. 46. CyberZでは一緒に ScalaでF.O.Xを成長させる方を 募集中です!! お気軽にお声がけください!
  47. 47. ご清聴ありがとうございまし た。

×