べにやまぶろぐ

技術寄りの話を書くつもり

AJITO(アジト）×キャリア・ラボラトリー アドテク勉強会（11月21日開催）に参加してきました #ajiting

セミナー・勉強会 アドテク DevOps Scala

VOYAGE さんの AJITO で開催されている勉強会 http://careerlaboratory.jp/archives/656 に参加してきました。

登壇者との距離が非常に近くて、いろいろと貴重なお話を聞かせていただきました。メモの公開許可を頂きましたので、おそらく差し支えないであろう範囲で書かせていただきます。

「SSP：FluctでのBlue-Green Deproyment事例」 (@_nishigori さん)
  • @_nishigori さん : adingo の DevOps エンジニア
  • Fluct SSP で blue green deployment を実現している
  • AWS の Route53 を使ってバランシング対象を切り替えている
    • ELB & autoscaling
    • EC2 instance & puppet
    • service in (green)
    • service out (blue)
  • 最初から設計していたわけではなく、結果的にそうなった
    • impression 増大でサーバに同梱している CookieSync は他に逃したかった
    • オンプレを徐々に AWS に移行した
    • オートスケーリングをスケジューリングしている
    • サービスインしていないほうで ServerConfiguration もデプロイも全て試せた
    • AWS での Management Console 上での操作が辛かった
    • ELB の Pre-warming には事前に電話での申請が必要だった
    • AWS-Cli は JSON ばかりだった
    • Elastic beanstalk もあるがそこまで AWS にロックされたくなかった
    • 突然 EC2 instance が reboot したりする
    • 息を吐くようにインスタンスを上げ下げしたい
  • aws 用デプロイツールを作った
    • YAML で設定を書ける
    • ELB なんちゃって warm up ができる(徐徐に負荷を上げる)
  • 今後は AMI にして構築済みのイメージをデプロイするようにしたい
  • その先に RDB などはつながっていない
    • DB は blue green にするコスト見合っていない
  • 切り替えは 20分以上かかる
  • テストについて
    • cookie を焼けたかのテストはインスタンス上げたときにテストしていて、落ちたらサービスインできないようになっている
    • テストをした環境が本番になるといいなという気持ち
「Scalaのアドテク事例」(@katzchang さん)
  • Zucks Ad Network : スマホ向け課金型広告ネットワーク
    • Scala : 広告配信サーバ
    • PHP : 管理画面
    • Scheme (Gauche) : バッチ処理
      • fluentd と連携させて使っている
      • Scala より質問が少ないくらいなじみやすい (SICP の本の読書会をやっている)
  • Fluentd, Tomcat, AWS, GitHub, New Relic（モニタリング）...
  • Scala : 少量で高いスループットを安定して処理する必要がある
  • 最初は Java で書いていた
    • 広告配信はフィルタの連続 : Function, Predicate クラスを独自実装
    • 不具合なくしたい == ぬるぽなくしたい Option クラスを独自実装
      • Scala は Option 便利
    • IDE がしっかりしていてリファクタリングができる
      • IDE は IntelliJ
  • Scala のつらくないところ
    • プログラマの確保、みんな書ける
    • GC 問題、たまに応答ないけれど全体としては稼げてるのでとりあえず問題ない（たまにフルGCかかるけど全体的には商売で稼げてる、許容できないとしたらそもそも JVM 向いてない）
  • つらいところ
    • コンパイル遅い、sbt 複雑すぎる（マルチプロジェクト構成の資料がない）
      • 普段は立ち上げっぱなしでコマンド打ったりしている
    • パフォーマンスの予測がつかないところがある
    • リリース後５日感がサーバ台数増やしてチューニングの時間を稼いでいた
    • 直接 DB につながず、内部にハッシュマップを持たせて掲載しているメディアの情報等を引いていた
      • 恐ろしく遅かった
      • ベースになる JSON のマッパーの実装が悪かった疑惑（罠）
    • Tuple で ((int),(int)) のハッシュマップ使っていたりしたとき New Relic で見たときサーバリソースの３割使っていたりした
      • Hash 値計算に時間がかかってた
      • Case クラスをキーにすることで解消、全体のスループットが２割くらい上がった
        • pre compile されたハッシュコードを持っている？？
        • 3,000 件の get に 50ms かかっていた
      • Scala のバージョン 2.1 くらい
    • toList とか気軽に使わない
      • 数メガから数百メガのファイルを読まないといけないとき全行一気にメモリに全部載せてしまっていたので、一行一行処理してやるようにした
      • Java の BufferedStream だとあまり問題にならないだろう
  • Tomcat => とりあえず servlet でもそれなりのパフォーマンスは出る
  • ID をもらって広告をハッシュマップで返す
  • New Relic 見るとどのプロセスがリソース使用しているか一目で見える

参考)