前半メモ #ichigayageek

株式会社ネクストビート衣笠様オフショアでもScala開発

からのしっかりとした仕組み

Appliv
Akkaを使って1年ほど開発
(これから使うひと向け)
インスタンス
- システムをリアクティブにするためにActorを呼ぶ
即応性/耐障害性/弾力性/メッセージ駆動
- 早くレスポンスが返ってくるようにすること
- リアクティブ宣言を読む
Actorでないとき
- メッセージの遅延が全部に行き渡る
Actorであるとき
- 別スレッドで動いている
- メッセージを送り続ける
Actorでないとき
- エラーが全部に行き渡る
Actorであるとき
- 別スレッドで動いている
- 次の処理に進む
順次処理するので過負荷を防ぐ
- メッセージキュー
  - ほぼ同時にメッセージが来ても、キューで制御
  - シングルトンにしておけばデッドロックもない
- メッセージに基づいた処理を行う
冗長化が楽
- Akka
- withRouterメソッドとRoundRobinRouterを使って、冗長化 + ラウンドロビンできる
RemoteActor
- サーバーをまたいで処理をしたいという需要にこたえる
- 設定ファイルいろいろ書く
Actorはメッセージ駆動であること粗結合であるので遅延/エラーの伝搬を防ぐ/負荷の調節/サーバーをまたいだ処理もできる
スライド: preparing for distributed system failure

マイケル・ジャクソン 1975
- やるな
- 上級者向けはまだやるな最適化がひつような場合はやる必要があるかもね
ドナルド・クヌース 1974
- ただしい問題を解くこと
苦労があるが、パフォーマンス対策に手間をかける必要はないと思う
- でもパフォーマンス対策は必要
New Relic APM
- JVM Thread Profilling
2014/9/6
- Map keyとしてTupleをやめてみよう
- ハッシュコードの計算がTuple2では遅いかも
- case classにすると早いかも→早くなった
- こんな感じでいろいろ潰したら10倍くらいのパフォーマンスになったのでだいたいOKになった
プラクティス
- デプロイしてから考える
- 事前検証はほどほどに
  - 人工的なテストデータは難しいから
  - 機能が動いてお金を稼ぐほうが尊い機会損失のほうがつらい
  - サービスレベルを若干低く扱う
- どこが重要かは会社によって違う
  - リクエストのトランザクション
  - 過去データ
  - 広告掲載面
設計判断は経営判断であること
- デプロイをしたらパフォーマンスが落ちた