aretan.jp

ブロックチェーン時代の認証¶

Double jump.tokyo株式会社　満足さん
Webとブロックチェーンは公開鍵認証という共通点
ブロックチェーンゲームは、アイテムなどが運営からの借りるのではなく、ユーザーの所有物になる
デジタルアセットは、量と質を扱うことができる
複数サービスでの汎用性、二次流通市場など・・・
MyCryptoHeroesでゲームのアイテムとかを交換できるようにした

ゲームとコンピュータ
ゲームとインターネット　：　ネトゲ
ゲームとコミュニティ　：　ソシャゲ
ゲームと・・・エコノミー　：　ブロックチェーンゲーム

インセンティブを導入して成り立たせたのがビットコイン
SmartContractというアプリケーションをつけたのがイーサ
EVMで実行されるSolidity言語で記述できる
ブロックチェーンで不可逆になったおかげでリアルに近づいた

ブロックチェーンではECCを使ったDSAが用いられる
曲線はSecp256k1を使う
NISTに採用してなくて、SECGに採用されている
重要：RSAではなく、電子署名である

Web3：ETHを扱うライブラリを指す
管理者不在でことこでやりとりできる

Walletを搭載したブラウザはwindow.web3ってノードが出てくる
（もしくはWindow.ethreum）
Metamaskが有名、OperaがCryptoWalletに対応している
サービス提供者はインジェクトされたこれでSmartContractへアクセス

全てをブロックチェーンで処理できない
・スケーラビリティ
・実行コストが利用者
だからオフチェーンと併用する必要がある
だから、なんらかの方法でオンチェーンのアカウントと紐付ける

パスワード認証は、結局ユーザーの負担が高くなっている
知識：パスワード、秘密の質問
所有：セキュリティキー、sms
生体：指紋、静脈、顔

FIDO2/Web Authnが最近でてきた
ブラウザでFIDO認証をするってやつ

いかにして、秘密鍵をユーザーに持たせるか・・・
でも結局、ネイティブアプリでよくね？

アカウントの信頼
・KYCすることでアカウントと現実を結びつける
・権利を購入する
・行動履歴

KYC：Know your customer身元確認
インスタとリアルの自分は同じではない・・・
KYCが成り立つのは国に守られているから

ブロックチェーン会員権というのはかんたんに作れる
トークンをもっている人だけ入れるコミュニティなど
Block punkがやってる、ビデオ視聴権トークン

行動履歴
SSIDが目指しているブロックチェーンが得意な部分
健全な取引をしている人だから良い人だろう
何かへのイベントの参加記念トークン・・・

アカウントが大量に発行できちゃうから
・アカウントへの優遇施策は、あまりよくない
・抽選とかと相性がわるい
・有効なアカウントとは、会員システム？

未来の世界では、鍵の紛失がアイデンティティの喪失

生体情報から鍵を生成する技術を使う？
階層的決定ウォレットというのも？

RMTがダメな理由は、ガチャがあるからである

署名交換会とかが、ありだというのか？
複数アカウントを許容する設計をするしかない

CN Buildpacksが作る未来¶

GMOペパボ　山下
STNSというのを個人でつくっている
Lib sis-stnsとstnsで名前解決する

CloudNative Buildpacks
HerokuはCloudFoundryで作られてきた
アプリケーションコードを見てコンテナイメージを生成する
でも、herokuとCloudFoundryで微妙に動かないことがある。
PivotalとherokuでCN Buildpacksがはじまる。
OCI（Open Container Initiative）イメージがつくれる
そうするとDockerとかで動かせるようになるよ
Detect -> Analyze -> Build -> Export
$ pack build test-ruby-app
Sinatraでwebサーバたてるだけ
build pack.tomlにいろいろ書いてる
$ pack create-builder
$ docker push
/layersディレクトリに配置していく
cloudfoundryが各種CNBを用意してくれている
GitHub.com/Cloudfoundry/php-dist-cnb
CN Buildpacksは相互に依存解決しながらコンテナイメージ作れる
そしてtomlで定義できるし
先見のやつを参考につくれる
SecurityFixのときどうする？
Dockerfileは・・・それぞれちょうがんばる
CNBなら・・・CNBだけなおす
Dockerでがんばるならベースイメージを運用するよね
でもベースが変わったときに、アプリちゃんとうごくの？
CNBなら、プログラマブルに依存解決ができる
ビルダーを更新すればそれを利用するリポジトリは自動で最新になる
Build意思決定の違い
Dockerfileでバージョン書く、CNBはpack buildで
でも、CNBでは、Dockerデーモンに依存しているので特権が必要

CNBは中央集権的に意思決定の定義を行い遅延実行できる

ペパボでの事例
Drone-CIでテストとビルドしてkubernetesに出す

Telepresenceのまえは・・・docker-composeで全部あげる
Telepresenceつかうと・・・必要なサービスだけ手元で起動

そして、CNBが作る未来・・・
Kubernetesでインフラレイヤーが一段抽象化された
セキュリティ、パッケージ、とか次誰がやるの？
プラットフォームエンジニアになって、その領域に
CNBの開発はプラットフォームエンジニアの仕事になる

IaCでアプリエンジニアがインフラ層におりてくると思ったけど
より一層分業がはかどるようになったんじゃないのか？

CNBは複数の言語、バージョンが混在している環境で強い
コンテナイメージをプログラマブルに構成管理できる

非同期処理の歴史から見たコンピューティングの進化¶

マーベリック株式会社
現代のアプリケーション開発は非同期処理が重要になっている
スレッドセーフじゃなくない？非同期なのにフリーズ・・・
2018年スマホ15億台
CPUは3.4GHzからあまり上がってない
2005年からマルチコアCPU

Java 5の非同期処理　（2004年）
Oracle Concurrency Guide 今日一番覚えて欲しい資料
Thread & Runnableという機能で実現していた
Swingでは3つのスレッドを使用していた
Initial Thread, Event dispatcher, worker threads（処理）
Executed Threadというのが出てきた
スレッドプールに投げれるようになった
そこで起こる問題 Thread interference (非atomic処理)
インクリメントはatomicじゃないので途中の値がでる
Synchronizedという宣言で使える
それは・・・Happens-beforeという能力ももつ
データレースという問題も解決される
Lock, ReadWriteLock, Condition, Volatileなど
Volatileでhappens-beforeの変数を作れる
AtomicIntegerなどの変数もでてきた
スレッドセーフなコレクションConcurrentHashMap

Systems PerformanceのCPUの章・・・
Registers L1 L2 L3 メモリ ストレージ

2005年 Google Maps (Ajax)
スレッドを意識せずにコールバックのみで非同期

C10k problem
Webサーバアーキテクチャ序論 ゆううき
10000スレッドが増えるとコスパが悪い・・・
それでイベントループのモデルがでてきた
Node.jsとおなじくNginxも少ないスレッドでさばく

JavaScript Callback Hell
Promiseでcallbackをいい感じにかけるようになった
そしてAsync awaitが使えるようになった 2017
読みやすさというのが重視されるように
非同期処理のchainingを使うように
ReactiveXなどのストリーム処理にも通じる

Immutable Objectを使う関数型プログラミングも出てくる

AkkaとActorModel
Richでリアルタイムなアプリケーションが増えてきた
アプリに状態がどんどんと増えていく・・・
Shared mutable: 複雑さの元凶な反面、おもしろさの源でもある
じゃあデータベースに全部状態を逃そうっていうモデル
Akkaのアクターでは、オブジェクトの状態をアプリで隠蔽する
Actor ! Message
Class myactor extends actor { def receive }
これはconcurrentLinkedQueue（CASループ）で実装している
Actor modelはshared mutable管理の一つの解
AkkaはJava5時代のツールを内部で使う

関数型の進化（Scala）
Scala標準, Monix, Cats Effect, ZIOなど・・・
Semaphoreなどでコンビネータとともに定義する
コンパイラが安全に非同期を組むことができる
Scalaのfor文とモナドを組み合わせるテクニックでchainingを実現
[Thread pool best practices]
・computation CPUを忙しくする
・event dispatcher イベントハンドラ
・blocking io
ZIOはtry/catcheで安全にする。こっちもコンビネータでchaining

全体のまとめ
非同期処理の進化の方向性
・処理の細分化、書きやすさ
・抽象化
・堅牢性
・効率

Javaの非同期がこわかったけど、
Actor modelの実装であるakkaに興味をもって勉強はじめた
そこからDigっていった。

Q.非同期ってデバッグが大変だけどどうするのか
A.そんなスマートじゃない、printデバッグしてる、ログ。
どのツール使っても一緒、地道にやるしかない。

ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ¶

末並さん

DDD, TDD, RDB, rails, react, java, postgresql, check制約
すえなみチャンスがあれば、焼肉を奢る
SoR, SoE 接点と構造　記録のシステム、UXのシステム
バズワードになると、本来の意味を失ってしまう。
SoR,SoEは物理的に分解されてる必要はない言語やFWでもOK
Microservices界隈でもそのように、
物理的に分けるのはリリースサイクルや組織構造による

モデルとは何であって、何でないのか @吉祥寺.pm
問題領域から必要と思われる情報を抽出し可視化したもの
メルカトル図法など地図の図法は目的に応じて変わる
つるかめ算の連立方程式とかも、これの一例である
モデル駆動設計：設計と分析を一緒にやる

既存の設計手法とSoR/SoE
クリーンアーキテクチャ：SOLIDのクラスの変更理由は一つであるべき
変更理由をアクターと言い換え、DBAや経営者もアクターにする
システムを使う人、というよりソフトウェアを広く使う人をモデルする
「商品」や「購入」はユビキタス言語のようにみえるが、次第に剥離

利用者アクターは自分がやりたいことややるべきことを簡単にストレスなく遂行する
事業者アクターは自分たちの事業を円滑に進めること
ドメインモデルは事業者アクターの視点のモデルが多い気がする

購買者向けシステム、事業者のモデル、店舗向けシステム
このように分けるというのはどうだろうか、という提案

PresentationDomainSeparation（PDS）マーティン・ファウラー
プレゼンテーションロジックとドメインロジックは分離するべき
HTMLとかJSONオブジェクトがプレゼンテーションモデルなのか？

CQRS、Cの堅牢性、Qの柔軟性は、SoE/SoRと似ている
SoR/SoE, Command/Queryの直行表 @スライド確認のこと

設計観点：バリデーション、整合性、採番、状態、キャッシュ

いいねボタンとか結果整合性でいいよね。
でも、決済とかはそうもいかないよね
与信を同期、決済は非同期でいいんじゃないのか？
BFFの前提で、一つのJSONオブジェクトの中でもexpireをわけてもいい

クレジットカードの通信プロトコルISO8583と戦う¶

Acquirer - Brand - Issuer
Brand プラットフォーム
Acquirer カード加盟店の開拓
Issuer カード会員の開拓
この3社の間の通信がISO8583

オーソリゼーション：与信
クリアリング：売上確定
PAN : カード番号

Message Type: 0x0100
Packed BCDで解釈する
0100
0 バージョン
1 目的
0 機能
0 発信元

国内利用時のみ出現するData Element
リボ払いのフラグがあった
ApprovalCodeは英数字なのに数字のみ（通例）

Protocol Buffersのスキーマを利用した開発¶

GRPCの普及とともに多くの機会で目にするように
$ proton —go_out=plugins=grpc:./proto user.proto

1Protoファイルをパースして、実装コードを自動生成する
Protocのプラグイン機能を利用して、生成する
Plugin.CodeGeneratorRequest

2プラグインじゃなくてprotocでstdoutででてきたのパースする

3jhump/protoreflectというのを使う
これを使うとパースされた結果表示がいいかんじになってる
サードパーティとはいえprotobuf v2はこれを参考にしてるぽい
Protobuf-goがprotobuf v2のリポジトリーになっている

だからこの3を使ってコードを自動生成するよー

応用編　Google.api.httprule
Grpc-gatewayでも利用している仕様
Annotations.protoってのを使う
Case *annotations.http_rules.get
ただ、、、httpruleの中身もっとすごいから大変になるよ

応用編2 Postmanのリクエストパラメータ作りたい
Protoreflefctのdynamicパッケージを使って生成する
Msg.MarshalJSONPB()

パースするライブラリたち
Protoc-gen-gohttp
Evans
Grpc-gateway
Proto-to-postman

ProtobufはシリアライゼーションツールでありIDLでもある

Elixirを支える技術「落ちない」システムの秘密に迫る¶

4年エリクサーを使い続けている
メモリ枯渇させたとき以外は落としてない
ErlangとElixirのデザインと原則を共有したい

Erlangはスウェーデンでエリクソンが作りはじめた
1998年にオープンソースになった
スイッチのPush通知はErlangで使っていた
（1億接続に耐えるシステム）
LoLのチャットシステムも、Whatsappも

プロローグを参考につくってるので文法が似てるよ
プロセスというものが特長的な点である
Erlangを起動するだけで大量のプロセスが立つ
プロセス間はメッセージを使って非同期
（Goのチャンネルと似ている）
複数のランタイムの通信も可能
プログラマーは気にすることなく透過的にアクセス可能

Elixirとは・・・
シンタックスと一部の拡張をのぞけばほぼErlang
Railsのコアコミッターが作ったもの
ExUnitはPowerassertみたいになっている
Phoenixの便利なルーティング機能

Elixirの場合はElixirの標準ライブラリが刺さってるだけで
Erlangの上にのっかってるだけである

エラーが起こっても回復できれば落ちないシステムになる
Process Isolation, Fault tolerance, Self healing

OTPというフレームワークでスーパーバイザーで監視する

The Erlang Virtual Machine: BEAM
プロセスはCの構造体で作られている
Heap, Stack, Mailbox, PCB（Process Control Block）
CPUの数と同じスケジューラーがいて
スケジューラーがRun Queueをいい感じに実行する
Erlangにはループはなく、再起で実装されている
GCはプロセスごとになっている

Optimization
HiPEというのがある
Erlangのコードをネイティブコードにする
LLVMを使っている
BEAMJITというのがある
2014年から実行時にネイティブコードにする
BEAM自体も最適化されてっているよ

どういう設計にしたらいいの？
書籍としては：Erlangなら作者の書いた本
「すごいErlang楽しく学ぼう」とかもオススメ
プロセス周りの分割は難しいね
ソースコードは標準ライブラリよむとかいいよ

スーパーバイザーの設定どうするの
出来る限りスーパーバイザー使わないようにしてる
シングルポイントにしないように、可能な限りステートレス

Lisp時代からマクロは賛否両論
Rubyなど動的言語と比べるとコンパイルするのでエラー見つけやすい

入門サービスメッシュ¶

Tetrate 米スタートアップ 小野

業界がサービスメッシュに至るまでの変遷
・Microservicesでの課題
・ライブラリアプローチの限界
・サービスメッシュの登場
プロダクション事例
・Extending SmartStack
・Hybrid workloads with containers and VMs
・Incremental adaptation to Istio
サービスメッシュ選球眼（どういうとき使う？）

VMやベアメタルでもサービスメッシュは利用価値はある

小さいチームがそれぞれ小さいアプリケーションを開発する
クラウド技術で動的なデプロイを可能にする
そういうときの運用課題
・traffic control
・observability
・Failure recovery, fault isolation
・サービス認証、セキュアな通信
じゃあ、この辺のこと全部やってくれるの作ろう！
Finagleに代表されるライブラリアプローチの興隆
でも問題が
・言語ごとに実装しなきゃいけない
・デプロイが各チームに移譲されたのに、ライブラリアップグレードのコストが高い

2011 Finagle
2013 SmartStack (AirBNB)
2914 Prana (Netflix)
2016 Linkerd (service meshという言葉がでる)
2016 Envoy (LIFT)
2017 Istio

SmartStackがアプリケーションと同じホストで動いてるプロキシ
新しいホストがデプロイされたときに動的にそっちにふる
Synapse, Nerveで DBはzookeeper、プロキシはHAproxy

Pranaからサイドカーという言葉がでてきた

Linkerdとかから・・・
Routing、Failure recovery、TLS En-decryption
などをプロキシでやるサービスメッシュの発想
そして、オブザーバビリティを確保する

Control Planeを自作するのが一般的だった・・・
これは、レガシーなどの対応も必要だったから

マネージドサービスとしても
GCP Traffic Director
AWS App Mesh
とかでてきた

Linkerd v2もサービスメッシュの実装

2018年のEnvoyカンファレンスででてきたYelpというサービス
Haproxyでは分散環境での問題がやっぱりあった
だから、Haproxyだけをenvoyに置き換えた

Istioを段階的に適応するという事例 メルカリ Google Cloud Next 19
Adopting istio for a multi-tenant kubernetes cluster in production

サービスメッシュ選球眼
自分たちの規模を見据える
・大規模になるなら開発運用の分散化が重要になる
・高度に分散化した環境では通信そうでの仕事は必須
自分たちの環境を分析してソフトウェアを選ぶ
・brown fieldか、green fieldか
時代待ちできるのか
・serverlessとかでいいかんじになるかもしれない
・それまでの過渡期と捉える

まとめ
サービスメッシュはmicroservicesの課題を解決する
・そもそも解決したい問題はadvanced
・自分たちの問題に合わせて少しづつ利用する
・いつかフルマネージドになるので待ってもいい
サービスメッシュはいろんな環境で多様に利用できる
・service mesh is not for k8s only

キーボード¶

Planckキーボード 47キー 40%サイズ
Mister Barocco 離すことできる
Planckが割れたもの lets split

売られてるキーボードの種類は使う人に比べて少ない