ScalaMatsuri 2018 0日目（Training Day） 備忘録

ScalaMatsuri2018に参加するので参加したセッションについて自分用にまとめておきます。
後ほど整理して別途どこかで公開します。（おそらく会社のブログ）

Scalaに関する神話と真実 株式会社ドワンゴ 水島宏太さん

Scalaって使われてるの？

世界中で使われています。
Twitter, Strabucks, Goldman Sucks, Foursquare, MorganStanleyなど

Scalaは難しすぎて実用的じゃ無い？

はい、少し難しいかもしれない。
が、適切な資料と講師がいれば育成は可能。

はてなやドワンゴの研修用テキストがGithubで公開中。
普通に学んでもらえば大丈夫。

Scalaを使うには関数型プログラミングの知識が必要？

高度な知識までは必要ありません。

• Scalaの標準コレクションライブラリの使い方
• 不変オブジェクトの作り方・活用方法 あたりをおさえておけば大丈夫。

Scalaは記号メソッドが濫用されている？

そういうライブラリもあります。
昔よりは減少傾向にあります。

例）periodic table of dispatch operators

ScalaはJavaより遅い？

いいえ。ただし、プログラミングスタイルによります。
Javaと同じスタイルで書けばほぼ同じ速度。
関数型プログラミングのスタイルで書いた場合、遅くなる傾向がある。

Scalaはコンパイルが遅い？

はい。ただし、大幅に和らげることができます。

金の弾丸

• ノートPC：Core i5以上
• メモリ：16GB
• sbtを立ち上げっぱなしにする
• IntelliJ IDEAの場合
  • sbt shellを使う
• Scala 2.12.4にバージョンを上げる
  • 20〜30%のコンパイル時間削減

implicitという機能が怖い。どうすればいい？

利用する上での規約を定めれば問題ない
* 二つのimplicit
* implicit conversion
* implicit parameter

Scalaは後方互換性を軽視している？

いいえ
マイナーバージョンが変化しても互換性は維持（2.11.x -> 2.11.y）
メジャーバージョンが変わると互換性は維持されない（2.a -> 2.b）
クロスビルディングにより複数バージョンバイナリ生成可能

Scalaコミュニティって怖い人が多いんでしょ？

いいえ。怖くないよ！

Gitter: scalajp/public
Slack: scala-jp

Akkaで分散システム入門 大村伸吾さん

分散システムとは何か

* 複数のプロセスがネットワークを介して通信しながら強調して何かを遂行するシステム
* 部分的な故障を許容するシステム（故障に注目した定義）

• 普通のWebアプリ
  • DBが単一障害点になりがち
  • 最近はSpannerなど分散DBも出てきた

分散システムをなぜ作るのか

* スケーラビリティ
* 耐障害性

分散システムの難しさ

• 考えることがとても多い
  • 分散コンピューティングの落とし穴
  • たくさんのコンセプト・アルゴリズム
  • CAP定理を全て満たす分散システムは存在しない
    • 一貫性
    • 可用性
    • 分断体制
  • FLP不可能性（分散合意についての限界） ## Akkaとは
• アクターモデルによる並行・分散プログラミングツールキット
• 状態を持つActorが、イベントループによってメッセージを待っているイメージ
• Actor階層とsupervisorによる障害処理
  • 親が子の状態を管理して、再起動したりする
  • 親が死ぬとその子孫も全部死ぬのでリソースを適切に使える

• ActorRefによる位置透過なActorプログラミング

• Akkaは分散システムと相性が良い

  • イベントベースの並行処理
  • Actor階層とSupervisorによる適切な内部状態の復旧
  • 位置透過

Akkaの分散システム系モジュール

• Akka Cluster
  • AmazonDynamo, Riakに影響を受けている
  • 非中央集権的なクラスタメンバーシップ管理
    • ゴシッププロトコルによるメンバーシップ管理
    • メンバーリスト情報を知っているメンバーと交換し続ける
    • Accrual Failure Detector
      • 心拍数（ハートビート）の履歴をずっと取っておく　
    • Split Brain Resolverによる解決法
      • お互いにDownし合わないようにする
      • 分断/障害前の情報はそれぞれ持っているのでそれを元に自分が残るべきかというルールを作って、結果として高々１クラスだけが残るようにする
    • 再起動時のsedd node誤指定によるSplitBrain
• Akka Cluster Singleton
  • クラスターの中でSingletonActorをつくってくれる
  • 用途としては下記
    • クラスタ全体での集中管理
    • 外部システムへの連携ポイント
  • 簡単にボトルネックになってしまうので注意
• Akka Cluster Sharding
  • Actorをいい感じに分散してくれる
  • ShardCordinatorがどのノードにシャードがあるかを管理
  • DDDととても相性が良い
  • Akka Persistenceによって、ノードの状態をDBに保存・復元が可能
• Akka Distributed Data = CRDT
  • バラバラに更新されても全部操作をマージすれば結果的にはOKなデータ構造
  • 足し算の交換法則のようなイメージ

逆引き！Scala × ビッグデータ

もし卓球部部長がビッグデータ解析を始めたら

• ビッグデータを使って卓球部を強くできないか？
• スポーツの世界でもリアルタイムのデータ解析が進んでいる（Data Studium）
• ラズパイ、赤外線センサー、加速度センサーでボールのトラッキングができるシステムを構築（fluentd -> 分散メッセージングシステム -> ストリームデータ処理エンジン）

• ビッグデータの処理プロセス

  • 収集
  • 変換
  • 統合＆蓄積
  • 分析
  • 活用

• 分散メッセージングシステムとは

  • Apache Kafka
  • Amazon Kinesis
  • Cloud Pub/Sub

• ストリームデータ処理エンジン

  • Apache Spark
  • Apache Flink
  • Apache Beam
  • Heron
  • Apache Kafka Streams

• なぜ大量データ処理にScalaがよく使われるのか

  • 参照透過なコードを書きやすいから
  • Javaの資産を利用しやすいから

• 分析

  • 定常分析
    • デイリー、アワリーでのレポーティング等
    • GoogleDataStudio、AmazonQuickSightなど
  • アドホック分析
    • 随時思いついた疑問を分析する等
    • Apache Zeppelinなど

Implicit入門

implicit parameter

• implicit parameter の目的
  • 拡張性の高い多態を実現するため
• 普通のtraitの問題点
  • ライブラリが提供しているクラスなど定義を変更できない場合に自前のtraitをmixinすることができない
• なぜ明示的ではなく、暗黙的に渡すのか
  • コンパイラに任せることで以下のメリットが生まれる
    • ある種の証明として使うことができる
      • implicitな値を定義する際にdefを使うとimplicit parameterを使うことができる
    • 複雑な合成が必要な時にコードの本筋が埋もれない

implicit conversion

• implicit parameterのおまけ
• 目的
  • 変更できないクラスにメンバを追加したい
  • C#の拡張メソッドと同じモチベーション
  • Rubyのモンキーパッチとの違いはimplicit val が存在しているスコープのみ有効な点
• しかし今ではEnrich my libraryパターンが推奨されており、implicit conversionは積極的には使うべきではない

Enrich my libraryパターン

• 追加したいメンバを保持したクラスを定義し、型としてはそのクラスを使わない手法
• implicit classという省略記法が追加された（クラス定義と変換を同時に行う）
• さらにvalue classと合わせて使用することで無駄なメモリ割当も削減できる