Scala Days 2015 San Francisco に参加してきました (3)


(前回から続く)

Scala Days 2015 サンフランシスコの 2日目のレポートです。
私が聴講したセッションについてポイントをまとめます。

尚、発表スライドはこちらにリスト化されていますので、あわせてご覧ください。

2日目


この日からは終日のセッションです。会場に入ると、朝食が用意されていました。

sf2-1

[09:00] Why Open Languages Win

sf2-2
2日目のキーノートを務めたのは、オープンソース界の女王という二つ名を持つ Danese Cooper さん。オープンソースに対する熱い思いを語ってくれました。
(スライドの表紙は スパイvsスパイ)

  • これまでの軌跡
    • Microsoft, Apple, Symantec, Sun などで様々なプロダクトのオープンソース化に尽力
    • Java One Tokyo (2005年) で サプライズ的に Java のオープンソース化を発表した
  • オープンソースをめぐる戦い
    • C++ vs Java
    • S vs R (統計ソフト)
    • Windows vs Linux
  • GitHub 時代の到来
    • 「ただプロトタイプを作っているだけ」と装っている間に完成させてしまおう (笑)
    • もし新しい言語を作るなら、オープンソースであることが必須条件
      • 金に目が眩むと絶対失敗する
    • Scala の未来は明るい
  • 質疑応答
    • 大変だったことは?
      • コミュニティを形成させてゆくプロセス。
    • マネタイズのモデルは?
      • スポンサー、基金、ライセンスモデルの選択などで成功事例がある。
    • ライセンスについて
      • 法律家に聞くこと。国や、(アメリカでは)州によってルールは色々。

[10:25] Visualize the things

sf2-3

ビッグデータの可視化ツール Sparkle の紹介。

  • オープンソースのデータ可視化クライアント
    • Kafka, Cassandra, D3.js を使用
    • WebSocket と独自の Sparkle プロトコルでストリーミング処理
  • デモ
    • sbt run で Webサーバが立ち上げる
    • D3 ならではの綺麗な見た目で、ズーム処理もスムーズ
  • パフォーマンスとスケーラビリティ
    • スループットを向上するために、メモリ構造から根本的に考えぬいた
    • Reactive Streams を使うことで GC 頻度も減らせる
  • ライブ・レイヤーとデータ・アーキテクチャー
    • Extract Transform Load
    • ライブ処理とバッチ処理

[11:35] Shattering Hadoop’s Large-Scale Sort Record with Spark and Scala

sf2-4

Databricks の共同創設者であり Spark のコミッターでもある Reynold Xin 氏が、Spark の速さの秘訣を紹介してくれました。

  • Spark プロジェクトは、以下の全てをカバーすることが目的
    • 様々なデータサイズ (GBから TB, PB級まで)
    • 様々なストレージ・メディア (RAM/HDD/SSD)
    • 低レイテンシーが要求されるストリーム処理から、長時間のバッチ処理まで
  • ソート処理でベンチマークを取る
    • ディスクI/O, ネットワーク帯域なども含め、総合的なベンチマークになる
  • 高速化へのポイント
    • アプリレベルでの最適化 (よい子はマネしないでね)
      • while loop を使う
      • Scala/Javaのコレクションライブラリを避ける
    • GC 対象外のメモリプールを作る
      • DirectByteBuffer / sun.misc.Unsafe
      • ただし、メモリ使用率が 50% を超えた場合はチューニングの効果は薄くなりがち
    • キャッシュに最適化したソート
      • TimSort / AlphaSort といったアルゴリズム
  • 質問
    • JNI を使わないのはなぜか?

[12:20] ランチ

sf2-5

[13:20] Scala – The Real Spark of Data Science

sf2-6

Spark の話題かと思いきや、フタを開けてみたら「ハンドベル」の話でした。

  • ハンドベルの会社の喩え
    • SCHULMERICH vs Malmarlk
    • どちらが優れているかを議論するのは、よい時間の使い方ではない
      • それよりもユーザ体験向上に尽力すべき
    • Hadoop vs Spark の議論も同じこと
  • 関数型言語と手続き型言語の比較
    • Haskellや圏論、ラムダ計算を知らないと関数型言語を使えない? そんなことはない
    • 逆に手続き型で全てを成し遂げようとしたほうが複雑
    • 関数型のデータ構造の考え方(あるいは基本的な数学)は、ビッグデータに応用できる
  • まとめ
    • 関数型は直感的だ
    • 関数型はシンプルだ
    • 関数型はパワフルだ

[14:30] Type-level Programming in Scala 101

sf2-7

  • Scala におけるコンパイル時の計算
    • val, lazy val, def キーワードは実行時に評価されるが、type はコンパイル時に評価される
  • 組み込み型の値を「型」で表現してみる
    • Boolean
    • Int
    • List[Int]
      • コンパイル時に要素数を知るための工夫
  • 主な用途
    • コンパイル時計算 (実行時計算の削減)
    • コンパイル時バリデーション
  • 質疑応答
    • 今回のコードは実践的なプログラムで使えるか?
      • 「否、これはただの遊びだ」
  • 所感
    • final val でも確かコンパイル時の最適化が走ったかと思います
    • C++のTMPを思い出しました。C++14ではconstexprが大幅に制限緩和され非常に使いやすくなりましたが、Scalaにもいつかその流れが来るのでしょうか。

[15:40] Stream as Scala Collections

sf2-8

今回の Scala Days のゴールドスポンサーでもあるニトロソフトウェアの発表。AWS S3 の処理のために、独自のストリーム処理ライブラリを作ったとのこと。

  • ニトロソフトウェアについて
    • クラウド上でのドキュメントサービスを提供
    • ユーザ体験、状態の変化、変動する負荷、予期せぬエラーに対して、全てがリアクティブに設計されている
    • 数十億個の S3 オブジェクトを常時利用
  • なぜストリーム処理か
    • 仮に 1% のエラーでも数千万件のオブジェクトを失う。ビジネス損失が大きい。
    • AWS S3 に合わせた並列化: Amazon の環境は遅くなったり早くなったりする
  • コードは GitHub(https://github.com/nitro/streamcollections/)で公開
  • 質疑応答
    • ライブラリから、ストリーム部分だけを切り出してライブラリ化したほうがよいのではないか。AWSライブラリへの依存は重すぎる。

[15:40] Type-safe off-heap memory for Scala

sf2-9

前のセッションが早めに終わったので、もう一つ見に行きました。型安全な off-heap メモリを実現するライブラリ scala-offheap の紹介。

  • off-heap メモリの必要性
    • GC対象としたくない
      • 巨大なデータをメモリに乗せる
      • 厳しいレイテンシ要件を満たしたい
    • ネイティブコードとのメモリ共有
  • off-heap メモリの使い方
    • Direct byte buffers
      • 1バッファあたり2GBという制限
      • 境界チェックによる性能劣化
    • sun.misc.Unsafe
      • メモリの不正アクセスやリークの温床となりがち
    • C言語でコードを書き、JNI/JNAでアクセス
      • 多くのボイラープレートコード
      • 構成の複雑化
      • メモリリークの問題
  • 具体例
    • 二次元座標
  • パフォーマンスを重視
    • メモリプーリングは定数時間で実行可能
  • 質疑応答
    • off-heap メモリと on-heap メモリをクラスからシームレスに使うことはできるか?
      • sun.misc.Unsafe ベースであるため実現は難しい
    • off-heap メモリの共有はできるか?
      • 現状、サポートしていない

[16:50] Function-Passing Style, A New Model for Asynchronous and Distributed Programming

sf2-10

今や Josh と並び Scala Days の顔である、 Heather さんの発表。昨年の Scala Days で発表した Spores を発展させ、関数パッシングモデルという新しいプログラミング手法のアイデアを披露しました。

  • アイデアは Actor の逆
    • メッセージではなく、関数をやり取りする
    • 分散プログラミング・高分散モデルへの適用が狙い
  • コンセプト
    • Silos (サイロ): データを保管するための貯蔵庫。データは全て immutable
    • Spores: ポータブルかつシリアライズ可能な関数
    • サイロの間をラムダが行き交うイメージ
  • 現在の状況
    • 論文のドラフトを作成中
    • googleグループ function-passing でも議論中
  • 質疑応答
    • 関数の合成とは何が違うのか
    • Spores が巨大になったらメモリを使い果たすのではないか
      • 課題として認識しているとのこと
    • パフォーマンスはどうか
    • master ノードの冗長性は?

[18:00] Easy Scalability with Akka

sf2-11

初心者向けセッションの部屋でしたが、DDDD (Distributed Domain-Driven Design / 分散型ドメイン駆動設計) がテーマの熱い内容でした。

  • キーワード
    • DDD: ドメイン駆動設計
    • Akka は Erlang/Elixir と似ているが、よりベターである
    • CORS: Command Query Responsibility Segregation
    • ES: Event-Sourcing
  • 従来のDDD
    • I/O がボトルネックになる
    • データストアの共有が必要
    • 大量のインスタンスが必要
  • DDDD
    • スケーラビリティ
    • フェールオーバー
    • シンプルさ
  • オンライン・オークションの実装例
    • Gatling で性能測定してみた
      • 測定結果の形状に大きな違い
      • ボトルネックが変わったため
  • CRUD の場合
    • ノードを追加しても、性能が線形に向上しない
    • コンテンション(競合状態)が増える
    • チューニングがあまり役に立たないことも多い
  • CQRS の場合
    • 結果的に CRUD の約3倍のスループットを達成
    • ノードを追加すると、ほぼ線形に性能も上がる
    • 競合なし
    • チューニングが重要
  • 質疑応答
    • ビジネスドメインが変わって、DBのスキーマが変わったら?
      • 過去は変えるな by Jonas
      • とはいえ、デシリアライズの工夫など泥臭い対応も必要
    • Apache Camel おすすめ

[18:45] コミュニティパーティー

この日はセントパトリックデーということもあり、アイルランドにちなんだ料理が並んでいました。

sf2-12

(つづく)