Download to read offline
![非同期処理
• WebサーバのデータソースがAPI＝非同期処理
• API経由なので、ロジックの中がほぼFuture
• 初期はこれが辛かった。
• Seq[Future[Int]]をFuture[Seq[Int]]に変えるとか
• 逆にFutureに慣れるスパルタな練習にもなった](https://image.slidesharecdn.com/f-160516140009/85/F-O-X-31-320.jpg)
More Related Content
![[db tech showcase Tokyo 2016] B15: サイバーエージェント アドテクスタジオの次世代データ分析基盤紹介 by 株式会社サイ...](https://cdn.slidesharecdn.com/ss_thumbnails/6i9kohhirrcoablwy2vg-signature-de1723da869232faf642797bf4411177191c3ef937923c1c3c4b18848e6dd30c-poli-160721053413-thumbnail.jpg?width=640&height=640&fit=bounds)
![[社内勉強会]ELBとALBと数万スパイク負荷テスト](https://cdn.slidesharecdn.com/ss_thumbnails/elbalb-160822022623-thumbnail.jpg?width=640&height=640&fit=bounds)
![[社内勉強会]ワークフローエンジンdigdag研究&プロダクトF.O.Xに導入](https://cdn.slidesharecdn.com/ss_thumbnails/digdag-181227045136-thumbnail.jpg?width=640&height=640&fit=bounds)
![[F.O.XMeetup#2]インフラ業務を開発エンジニアへ移譲して_2年間の軌跡_](https://cdn.slidesharecdn.com/ss_thumbnails/tittle-180330034333-thumbnail.jpg?width=640&height=640&fit=bounds)
F.O.Xを支える技術
- 1.
- 2. 自己紹介 • 鈴木 雄登 •株式会社CyberZ • @moc_yuto • http://yuutookun.hatenablog.com/
- 3.
- 4.
- 5. F.O.Xとは？ • 機能の例としては • どの広告からどれくらいインストールされているか？ •アプリの継続率はどれくらいか？ • あるイベントポイントにどれくらい到達したか？
- 6.
- 7.
- 8.
- 9. F.O.Xの構成 • SDK • SDKとの通信APIサーバ •集計サーバ • 管理画面
- 10.
- 11. 当時の使用言語 • サーバーサイド • PHP •Java • フロントエンド • jQuery…
- 12.
- 13.
- 14.
- 15. Scalaへの決定要因 • やりたいと手を上げた人が多かった • 理由としては一番大きい •もともとJavaを使っている人が多かった • 関数型という新しいパラダイムを触れる
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22. この構成で直面した問題 • F.O.XのDBのアクセス部分を各サービスで作る手間 • データモデルの理解が難しい上、 DBもいろんな要件で複雑化 •DBではバリデーションもできない APIサービスとして切り出し ※モデルの変更は今回のスコープ外
- 23.
- 24.
- 25.
- 26.
- 27.
- 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サー バ • PlayFramework • 日本語ドキュメントが多い • ブログ記事も一番多い
- 35. ORM選定基準 • Slick2系を選択 • 利用ユーザ数が多いとのことで結構エイヤで決めてしまっ た。 •Typesafeがバックアップしていたというのも大きかった
- 36.
- 37.
- 38.
- 39.
- 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.
- 47.