giantneco’s blog

技術メモ

新宿 Geek Lounge 第2回に参加してきた

参加報告 プログラミング

9/5に新宿で行われた新宿 Geek Lounge に参加してきた。 新宿 Geek Lounge はセプテーニオリジナルさん主催のイベントで、今回が2回目の開催になる。

Future of Reactive Architectures

今回の目玉はこの Jamie Allen さんのセッション。Jamie Allen さんは Lightbend(Scalaの考案者が創業したところ)からスターバックス(コーヒーを飲むところ)に移られて、現在ディレクターとして活躍されている方である。

タイトルは上記の通りだが、Scala と Reactive について詳しく触れるわけではなく、内容としては次のようなものだった

スターバックスでのソフトウェア部門の立ち上げ

  • スターバックスでのソフトウェア部門を立ち上げる際には、
    • ビジネス上の価値を出すことに重点を置いた
    • 未経験者も多かったため、どのように学ばせるかを模索していく必要があった
    • Scala を関数型プログラミングスタイルで書くか、リアクティブプログラミングスタイルで書くかなどを部門のスタンダードで決めなかった
      • これは最初に集まったメンバーが何を得意としているか把握していなかったため
      • また FP も Reactive のどちらも大事にいsたかったため
    • 実装にあった手はメンバにとって一番やりづらい方式を採用するようにした
      • たとえば通信は Restful スタイルにした
      • 当然時間はかかったが、勘所をつかむことができた
    • チーム全体に関数型プログラミングやリアクティブをいきわたらせるのは難しい
      • とはいえ完全に理解していてもそれで価値を出せるわけではないのでそれでよい
    • チームをどうつくればいいか？
      • TypeSafe では、新しい人を加えられないチームがたくさんあった
      • 前提となる知識が深すぎて、新しい人を受け入れることができない

Starbucksのデータベース

  • データはどうしているか
    • Starbucks では AWS で構築し、IaaC を推進している(=自動化は進んでいる)
    • セキュリティはしっかり組み込まれている
      • Starbucksは銀行としての役割もある。これはプリペイドカードに結構お金が使われているため
    • Cassandra はいい
      • 一貫性には問題あり
      • アプリケーション側で担保している
      • 他のデータベースも検討中

最近のデータベース

  • CAP定理
    • 分散DBに関する制限
    • 一貫性をとるか、可用性をとるか？をこれまでは考えないといけなかった
  • Google Spanner
    • CAP 定理を克服している
    • 「TrueTime」という仕組みにより分散した状態でも一貫性を保っている
  • CockrouchDB
    • OSS版の Google Spanner
    • TrueTime はないが、NTP を使ってノードでどちらが先に起こったかを調べる
    • ただし、NTP は完全ではないので注意
  • CAP定理が間違っているという前提に立つと
    • 可用性に注意してから一貫性をやれば良さそう
  • FaunaDB というのがある
    • Calvin Fauna のペーパー
      • ネットワークパーティションは「相対的に」大した頻度で起きない
      • Calvin によると、分散したログに書き込むことはできる
      • そのあと順番を見ればいい
      • そのあとで一貫性をすべてのノードにPUSHすればよい
    • CAP定理でなく、CAP else?

線形コンシステンシー

  • 線形コンシステンシー
    • 分散 DB が 5 つで、write consistency が 3 とすると
      • 3つのノードで合意を立てないといけない
      • 残りのノードに read が行行われていると、どんな値が読みだされるかわからない
    • read も同じように consistency をもつ
    • 時間で見て一貫性を担保するのも難しい
      • これは 100 % まではうまくいかないが十分信頼できる
    • Starbucksで気にしているのは順序
      • すべてのノードで値を読みだす必要がある
        • これに必要なのが線形 consistency

メモ：線形コンシステンシーについてはちょっとよくわかってない。後で調べておきたい。

まとめ

  • どこでも Reactive は必要か？
    • まあ、そう
    • しかし必要以上の苦労をしょい込む必要はない
    • ひとつのツールに固執するのは避けたほうがよい
    • 価値をだすためになにができるかをよく考えよう

LT

今回の LT は 1 つで、Scala の Future による並列・並行プログラミングの話だった。 - Future は ExecutionContext を定義して渡すことで挙動を制御できる - 例えばデフォルトではスレッドプールとキューの上限が両方溢れたらエラーになるが、 上限をなくしてしまうこともできる

感想

Jamie さんの話は思ってたのと違って Reactive の話はそれほどなかったが、 最近の分散 DB の話は追っかけていなかったので聞けて良かった。 特に Google Spanner は名前は知っていたが、CAP 定理を克服しようとしているというのは知らなかったので、これは結構驚いた。 Fauna DB と線形コンシステンシーの話はあまりよくわかっていないので、できれば調べておきたい。