GreeChat
アクティビティの活性化を目的とする
数十万人の利用を目的とするバックエンドの構築
- 対象者はこれからScalaを使ってなんかアプリを作る人向け
- チーム開発
- 問題点
Scalaを選んだ理由
GREEChatの要件
- 何十万人のユーザー
- リアルタイム
- 少ないサーバ(サーバ資源の効率化)
- 保守性(5年以上)
候補
- PHP(社内で使っているから。)
- ストリーミングの問題
- シングルスレッド マルチプロセス(サーバを効率よく使うのが難しい)
- 保守性の問題
セミコロン
Scala
- 並行プログラミングとの親和性とサーバ台数を減らせる
- 一つのプロセス、複数のコネクション
- 関数型言語→副作用がない→保守性
- 社内技術の活性化
- コード量を少なく
- 社内にScala大好きな人がいた
どのようにScalaを学んでいったか
2/7(チームでのScala力の向上)
- 自主学習(基本的な構文の理解)
- コップ本
- 逆引きレシピは網羅性が高い
- Twitterのwebドキュメント
- EffectiveScala
- オープンソースのコードを読む
- Twitterの人
- チームでの勉強会
- 個々の学びをチームで共有
- 階乗計算問題をコードを書いてチームで見せ合う(varを使うとバグのもと)
- 必要最小限の副作用
- ペアプロ
- 効果的な学習
- ツールの使い方の共有
まとめ1
- 並行プログラミングとの親和性
- 経験者の負荷は高め
GREE Chatのアーキテクチャ
- キューで分かれている
API Server
- リクエストを受け付けて、イベントをキューに積む
- ロジックを非同期で書く
- 非同期前提
- finagle(サーバだけでなくクライアントとしても使っている)
EventBusServer
- akka
- 並行分散処理をより簡単に書く
- 競合やデッドロックのことを考える必要がなくなる
- 耐障害性をサポート
Stream Server
- 接続数を増やしたい…
- ユーザ情報をメモリで管理
- akkaやfinagleを利用した非同期処理
まとめ2
- サーバをキューで分けてる
- 非同期と親和性の高いfinagle
- 並行処理が出来るakka
開発の問題点
JVM
- Full GC問題 Javaパフォーマンス改善 - Full GCの原因とその解決方法について - Java入門
- JVM
- あまり目にすることがないのでコーディングに気をつける
Scalaライブラリの自作
- シャーディングライブラリが必要だった
- GREEにはもともとシャーディングライブラリがあったけど、それはPHP用だった
- AuroraとChatシステム
- auto_incrementをPKとするとinsertに時間がかからないけどuuidをPKとすると時間がかかる
- Snowflakeに代わるライトウェイトなやつを作りたかった(→Cornflake)
- シャーディングをするためのライブラリをOSSとするけど、組み込みに時間がかかった
まとめ3
- 並行プログラミングとの親和性
- チームとの共有
- アーキテクチャはAkkaとFinagle
- ライブラリの自作とOSSへの貢献
追記
一部削除しました。
