株式会社ネクストビート 衣笠 様 オフショアでもScala開発
- さくらのクラウド
- C
からのしっかりとした仕組み
- stage1 ドメインモデル設計
- ヘキサゴナルアーキテクチャ
- case classのオブジェクト
- コンパニオンオブジェクト
- stage2 モデルとDBのマッピング設計
- slick
- stage3 リポジトリの設計
stage4 フロントエンド実装
- リポジトリを叩く
リリース
- Slack
- ECRに直接コミット
企画書とSlackでのやりとり
- ドメインの設計は小さいものならベトナムの人にやってもらう
- 全部ドキュメント化してアサインした人のレベルを引き上げる
ナイル株式会社 的場 様 何故AkkaのActorを使うのか?
- Appliv
- Akkaを使って1年ほど開発
(これから使うひと向け)
インスタンス
- システムをリアクティブにするためにActorを呼ぶ
即応性/耐障害性/弾力性/メッセージ駆動
- 早くレスポンスが返ってくるようにすること
- リアクティブ宣言を読む
Actorでないとき
- メッセージの遅延が全部に行き渡る
Actorであるとき
- 別スレッドで動いている
- メッセージを送り続ける
Actorでないとき
- エラーが全部に行き渡る
Actorであるとき
- 別スレッドで動いている
- 次の処理に進む
順次処理するので過負荷を防ぐ
- メッセージキュー
- ほぼ同時にメッセージが来ても、キューで制御
- シングルトンにしておけばデッドロックもない
- メッセージに基づいた処理を行う
- メッセージキュー
冗長化が楽
- Akka
- withRouterメソッドとRoundRobinRouterを使って、冗長化 + ラウンドロビンできる
RemoteActor
- サーバーをまたいで処理をしたいという需要にこたえる
- 設定ファイルいろいろ書く
Actorはメッセージ駆動であること 粗結合であるので遅延/エラーの伝搬を防ぐ/負荷の調節/サーバーをまたいだ処理もできる
- スライド: preparing for distributed system failure
株式会社VOYAGE GROUP 大谷 様 高スループット・低レイテンシーなWEBサービスにおけるパフォーマンス対策の現実
- katzchang
- 増田が好き
- Survlet on Tomcat
- Zucks Ad Network
人類の限界
- マイケル・ジャクソン 1975
- やるな
- 上級者向けはまだやるな 最適化がひつような場合はやる必要があるかもね
- ドナルド・クヌース 1974
- ただしい問題を解くこと
- 苦労があるが、パフォーマンス対策に手間をかける必要はないと思う
- でもパフォーマンス対策は必要
- New Relic APM
- JVM Thread Profilling
2014/9/6
- Map keyとしてTupleをやめてみよう
- ハッシュコードの計算がTuple2では遅いかも
- case classにすると早いかも→早くなった
- こんな感じでいろいろ潰したら10倍くらいのパフォーマンスになったのでだいたいOKになった
プラクティス
- デプロイしてから考える
- 事前検証はほどほどに
- 人工的なテストデータは難しいから
- 機能が動いてお金を稼ぐほうが尊い 機会損失のほうがつらい
- サービスレベルを若干低く扱う
- どこが重要かは会社によって違う
- リクエストのトランザクション
- 過去データ
- 広告掲載面
- 設計判断は経営判断であること
- デプロイをしたらパフォーマンスが落ちた
株式会社セプテーニ・オリジナル 高嶋 様 IntelliJでScala開発をする上で抑えたいポイント
- IntelliJ + Scala
Scalaプラグインについて用意している機能について知らない人が多い
型がわかる
- implicit conversion highliting
- どの型がimplicitされているかわかる
- scala console
- sbt consoleをその場で
scala worksheet
- その場で計算して結果を出してくれる
scala pluginのマニュアルを読んだほうがいいとおもう