kentac55 · September 5, 2017 13:54 · Sep 5, 2017
diff --git a/gl2.md b/gl2.md
@@ -0,0 +1,172 @@
+# jamesさん
+元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
+gRPCを使ってこれらの問題を解決していく
+→すべてのサービスをRESTコールをしない
+RPCには弱点がある→RESTfulセマンティクスに対応しない
+よって必要な場合には、REST形式を使う
+
+他のインプリメンテーションを加えることができる
+
+## Kubernetes
+エコシステムを加えれば誰も使ってないtoolkitを延命させることができる
+→利用者が増えるからね
+
+## Istio
+
+
+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では古いデータというものは存在しないが、順番がわかる
+
+# Wrap up
+あらゆるところでReactiveは必要だが、だからといって高コストを払う必要はない
+ツールを選ぶ際はどこで付加価値が生まれるのかを精査すべきである
+できるだけできるだけツールのグループを少なくしたほうが良い
+システムをシンプルに保つことでチームは成功する
+マイクロサービスアーキテクチャではこれを続けることは難しいが必要に応じて痛みの小さい方を選んで
+
+## Renearizable consistance
+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が必要
+
+
+# @qtamaki
+
+FutureのExcutionContextについて
+
+# adam gibson
+mesos
+
No results found