元lightbend→スタバ スタバエンジニア部門を一から構築 第一回scalamatsuriで講演
2ヶ月前にCAnadaで講演
スタバで割と重要なプロジェクト
リワードプログラムのリプレース
でもコーヒー飲まない人
Jonas Boner(akka, Lightbend(CTO, founder
全く何もしない、resilienceが完璧なシステムは恩恵はない →resilienceの中身よりもビジネスの価値をもたらすプログラム 同時に、チームをしっかり構成していく必要がある
もし貴方が何かの専門家だったとき、どう知識を継承していくか
scalaコミュニティでは常について回る FPなのか？Reactiveなのか？ →両方使おう
何もscalaわかってない人を集めてScalaチームを結成した（.NETの人だったりテスターだったり・・・ →どのように学ばせるのかを模索する必要があった あるグループは純粋FPを あるグループはいろんなものを命令型で・・・ →Scalaをやるにはコーディングスタンダードが必要とみんな言う →そんなことはない
いろんな方法を経てシステムを構築 →あまり良くなかったが、メンバーが何に長けているのかを理解することができた →それによって初めてコーディングスタンダードを作ることができた
サービスの間のcallはREST APIで →そんなにスピードが出ないシステム →そしてやりずらいシステム →これによってどのようにやるとNGなのかを理解することができた
akkaクラスターは使っていない →別に嫌いだからとかそういうわけではなく、必要ないから →必要ないなら使う必要ない
3-4年前のapple kafka→cassandra (15億/日 →ステートレスなのでakka必要なかった
議論を呼ぶかもしれないが・・・ 純粋FP知識はスケールしない（つまり知識伝播しにくい
けどそれでもOK Akkaだって同じくらい伝わりにくい
そこまで深く物事が理解できる人の数は多くない
これはscalaやakkaに限定されることではい 例えばjavaの並列処理ライブラリに対する深い知識を持っている人はどれくらいいるのか？
チームを効果的にするにはどうすればよいのか？
typesafeやlightbendでは拡張性のないチームをいくつも見てきた（Akkaやscalaへの知識が深すぎて、ついていける人を入れられる余裕がなかった
Reactiveを理解してほしいし、そういった人材が必要
gRPCを使ってこれらの問題を解決していく →すべてのサービスをRESTコールをしない RPCには弱点がある→RESTfulセマンティクスに対応しない よって必要な場合には、REST形式を使う
他のインプリメンテーションを加えることができる
エコシステムを加えれば誰も使ってないtoolkitを延命させることができる →利用者が増えるからね
AWS上にシステムを構築
- IasCode
- Security Design
スタバは銀行である →プリペイドカードとかに入金できるし →一年あたり70億ドル なのでセキュリティはしっかりとしている
バグバウンティもやってるよ
DBはcassandraを使った めっちゃいい データの一貫性は良くないかもしれないが・・・ 拡張性が非常に高い なので、不十分な点をscalaで補う
CAP定理はどっちかしか取れないのではない（とCAP定理提唱者が言ってた
google spannerがCAP定理をひっくり返した →世界中にあるnodeにデータを買い替えている →真時間というコストを使って数あるものの中で何が一番最初に起こったことなのかを探している →真時間は知ることができない 一貫性が担保された分散されたDB
clockroachDB →OOS →KVS(reacやredisと同様の) spannerと同じだが、真時間は存在しないのでntpを使う が、ntpは完璧ではない、、、時間から揺れる(drifted)ことがありうる →つまり遅くなる・・・が真時間のほうが精度が高い
Spanner, Calvin, Fauna(100%scalaDB)
分散して書き込む→順番を見る→すべてのノードにpush outする
Faunaはリージョン単位で分散書き込みに対応する（別にグローバルに対応する必要がない 必要なら裏でアグリゲートすれば良い globalデータが必要ない場合は非常にうまく動くだろう
一貫性よりも可用性を選べ 分散型DBでは古いデータというものは存在しないが、順番がわかる
あらゆるところでReactiveは必要だが、だからといって高コストを払う必要はない ツールを選ぶ際はどこで付加価値が生まれるのかを精査すべきである できるだけできるだけツールのグループを少なくしたほうが良い システムをシンプルに保つことでチームは成功する マイクロサービスアーキテクチャではこれを続けることは難しいが必要に応じて痛みの小さい方を選んで
senializability: 順序性 Lenearizable consistance: 5つのノードが有ったとき・・・ 3つでwriteのconsistanceがあったとする 5つのノードがupdateしたと合意する必要があるしwriteも検証する必要がある そうするといろんなノードでゴシックする(Gothic Protocol) 3つのノードに2つのノードは合わせるようにする どのノードがreadのconsistanceを受け取るのかは不明 つまり、最初にwriteがいったノードにreadがきたら正確なデータが帰ってくる ただし、行ってないノードにreadが来た場合いつ更新されるのかはわからない cassandraはここで工夫を行っている 2つのノードは値が会っていることを検証する 間違っていた場合どっちが正しいのかはわからない（clock timeも使えない) vector clockやCRDTや https://aphyr.com/posts/343-scala-days-2017-jepsen-keynote destributed
mongodbはtrain wreckではない kyleのおかげで
古いデータ(淀んだデータ)をどのように扱うのかということをkyleが解決 jepsonのテストスイート
distributed programing
akkaを使うべきシーン statefulなシステムならakkaが必要
FutureのExcutionContextについて
mesos