『Webを支える技術』学習メモ
Part1 Web概論
Ch01 what's Web
- Webの作用
- 非線形なhyper media @Web
- distributed system @Web
- simple protocol
Ch02 Web history
- Web以前のhyper media
- hyper media: hyper textの拡張
- 必要最小のリンク機能のみ持つWeb
- RPC, CORBA, DCOM
- Web以前のdistributed systemの問題
- Webの起源
- simpleな単方向リンク
- client-server間のIF．simple protocolとしてのHTTP
- IETF→W3Cでのstandardize
- especially HTML, CSS
- Webのstandardize
- RESTの起源，意味
- HTTPはresourceのstateの表現を転送している
- REpresentational State Transfer
- Hyper Media Format: HTML, RSS, Atom, microformat, JSON
- RESTの起源，意味
- Web API
- SOAP @RPC/distributed object
- WS-*
- mashupのためのREST
- SOAP @RPC/distributed object
- REST, Ajax, CometによるWebの進化
Ch03 REST: Web architecture style
概要
- architecture style: architecture pattern
- e.g. MVC, Pipe&Filter, Event System
- architecture style > micro architecture pattern(design pattern) @粒度
- architecture styleをもとに，architectureを決定する
内容
- REST: network systemのarchitecture style
- Web: client/server style
- REST: client/server + 制約
| 抽象度 | Webでの例 |
|---|---|
| architecture style | REST |
| architecture | browser, server, proxy, HTTP, URI, HTML |
| implement | Apache, Firefix, IE |
詳細
- resource: Web上の名前を持ったあらゆる情報
- resource name, identifier: URI
- addressability
- URIによってresourceが表す情報にアクセス
- client-server間でやり取りするdata: resourceの表現
- 1つのresourceは複数表現を持てる
- e.g. html, pdf
- 1つのresourceは複数表現を持てる
- addressability
- RESTの構成
- RESTは複数のarchitecture styleを組み合わせて構築した複合architecture
- a.client-server
- Web: httpでclient-serverが通信するというarchitecture style
- merit: client-serverを分離できる
- multi platform @client + serverの冗長化で可用性UP
- b.stateless server
- clientのapplicationのstateは管理しない
- c.cache
- resourceをclient側で再利用
- d.統一IF
- 統一IFにより，client-server間の独立性を高める
- GET, POSTなど限定的なmethodのみを持つ
- 統一IFにより，client-server間の独立性を高める
- e.階層化system
- 統一IFにより，load balancerやproxyを使用したsystemの階層化が容易になる
- f.code ondemand
- a-fを組み合わせたarchitecture styleがREST
- REST以外のarchitecture style: P2P
- RESTの2つの側面
- RESTとHypermedia
- resourceをリンクで接続することで1つのapplicationを構成する
- 接続性: RESTの基幹をなす
- RESTとdistributed system
- linkをたどってapplication stateを遷移することで性能劣化を抑える．
- 統一IFにより互換の問題が起こらない．
作用
- RESTというdistributed network systemのための理論により，Webが機能する
- RESTの制約に従っていること: RESTful
Part2 URI
Ch04 URIの仕様
目的
- URI: Uniform Resource Identifier
- resourceを統一的に識別するID
概要
詳細
まとめ
Ch05 URI design
目的
概要
詳細
- Cool URI
- usability高まる
- URIの変更のためのredirect
- 拡張子でresourceの表現を特定
- 言語を指定する拡張子
- → Content Negotiationのためのbrowserの設定不要
影響
Part3 HTTP
Ch06 HTTPの基本
目的
- TCP/IPの基礎とHTTPの歴史を見る
- HTTPは以下のRESTの重要な特徴を実現する，Webの基盤となるprotocol
- 統一IF
- stateless server
- cache
概要
- TCP/IPの観点
- 階層型protocol → 層ごとに抽象化して実装
- application layer
- transport layer
- internet layer
- IPでpacket単位でdataをやり取り．IPに相当．
- 自分のnetwork IFでのdata送信の保証
- network IF層
- 物理的な部分
- 階層型protocol → 層ごとに抽象化して実装
詳細
- HTTP history
- client-serverのarchitecture style
- client ≒ user agent
- request-response型のprotocol
- @client, @server
- HTTP message: request-response message
- request messageの構成
- request line
- method, request URI, protocol version
- header
- body
- request line
- response messageの構成
- status line
- header
- body
- request messageの構成
- stateless HTTP
- application state = session state
- statefulの欠点
- client増 → scaleout difficult
- statefulの欠点
- stateless の利点
- 自己記述的messageでscaleout easy
- statelessの欠点
- performance down
- data量，冗長（認証など）
- 通信エラー
- performance down
- application state = session state
作用
- simple HTTPにより，Web ServiceとWeb APIが同じprotocolで表現
Ch07 HTTP methods
目的
- 8 methodsのうち，主要な6つのmethodsの使い方を見る
- and, HTTPの設計上の工夫を見る
- method数が少ないからこそHTTPやWebは成功
概要
- HTTP methodsの観点
詳細
- methodの使用の観点
- POSTでPUT/DELETEを代用
- _method parameter
- X-HTTP-method-override header
- 条件付きrequest
- 冪等性(idempotence)と安全性
- idempotence: PUT, DELETE
- idempotence and safe: GET, HEAD
- どちらでもない: POST
- methodのproper use
- 他methodでできることにPOSTを使わない
- PUTの冪等なuse
- DELETEの冪等なuse
- POSTでPUT/DELETEを代用
作用
- 数少ないmethodによりprotocolをsimpleに保つ
- RESTの統一IFの実現
Ch08 status code
- 観点
- status line
- status codeの分類による意味
- client-server間を疎結合に
- 先頭の数字でclientが解釈
- よく使われるcode
- status codeとerror handling
- {protocol, Accept header}に従ったformatのerror
- status codeの設計
Ch09 HTTP header
目的
- HTTPの構成要素
- method
- status code
- header
- meta dataをstandardize
- 認証やcacheを実現
- history
- headerの成り立ち
- mailと共通の部分
- mailと異なり双方向
- headerの成り立ち
概要
- 観点
- GMTでのdate
- MIME: Multipurpose Internet Mail Extensions
- Content-Type
- charset → textのときの文字化け
- Content-Language: resource表現の自然言語
- Content Negotiation: client がrequest
- Accept
- Content Length
- chunk transfer @画像などを分割
- 認証: realmの値: URI空間
- cache
- cache用headerでcontrol
- 条件付きGET
- 持続的接続 @HTTP1.1でdefault
- pipeline化
- closeで切断
- その他のHTTP header
作用
- various 技術標準の組み合わせでheaderを構成する．十分な調査によりHTTP headerを扱える．
- authenticationやcacheなどのHTTPの重要な機能を実現
Part4 HyperMediaFormat
Ch10 HTML
- HyperMediaFormatとしてのHTMLを見る
Ch11 microformats
目的
- microformatsによりlinkの細かい意味やevent informationを表現
問題
- semantics(意味論)
- program semantics
- program languageのもつ意味を確定させる理論
- Web semantics「semantics Web」
- resourceの持つ意味を確定させる理論
- program semantics
- RDFの問題とmicroformatsでの解決
概要
- microformatsのstandardize
- 分類
- elemental
- compound
- 分類
作用
- microformatsで解決できない部分
- RDFa(RDF-in-attributes)での解決
- 可能性
- microformatsによりWeb pageをそのままWeb APIとして提供
- Web page/APIの機能差少ない
- 保守・開発コスト小さい
Ch12 Atom
目的
概要
- resource model
詳細
- entryの構成
- feedの構成
- Atomの拡張
- Feedの分割
- archived feed
- Open Search
作用
- Atom: title, author, update timeなどの基本的なmeta dataを持ったresource表現のためのformat
Ch13 Atom Publishing Protocol
- Atom Publishing Protocol
- Atom Publishing Protocolのresource model
- 1つのresourceがmulti 表現
- member resourceの操作
- service document
- Atom Publishing Protocolに向いている/いないWeb API
Ch14 JSON
- JSON: hashや配列などのdata構造の記述
Part5 Web Serviceの設計
Ch15 Read Only Web Serviceの設計
目的
- resource designの観点
概要
- resource指向のarchitectureのapproachの観点
- RESTfulなWeb Serviceの性質
- addressability
- stateless
- 接続性
- 統一IF
詳細
- 各手順の観点
作用
- resource design skillの習得でよい設計
Ch16 writable Web Service
目的
- ROのServiceより観点多い
概要
- 観点
- resource create/update/delete
- batch処理
- transaction
- 排他
詳細
- create
- factory resource
- PUT作成
- 〇 作成と更新の区別不要
- × clientにURI構造流出
- update with PUT
- bulk update
- partial update → 通信料cut
- update error
- delete
- 子resource
- batch: POSTでURIを非指定
- response
- transaction
- transaction resource
- (or batchのtransaction化)
- 上位resourceへの操作
- 排他
- pessimistic lock
- LOCK/UNLOCK @WebDAV
- 独自Lock resource
- optimistic lock
- conflictを解消
- Condition PUT/DELETE
- conflictを解消
- pessimistic lock
作用
- 以下の観点でバランス
- なるべくsimple
- 別resourceで解決
- 必要ならPOST
Ch17 resource design
目的
- dataの特定とdataのresource分割のための方法を見る
内容
- 関係モデルからの導出
- data model with math的基盤
- 中心tableの1行を1 resource
- 自己記述のため非正規 → network負荷減
- resourceに必要な項目をすべて入れる
- 階層 difficult
- linkのためのER図
- Object Oriented modelからの導出
- 主要entityからresource
- 階層関係 → URI構造
- link by object reference
- top levelは別に作る
- information architectureからの導出
- information分類の観点: information architecture
- resource oriented architectureと相互補完
- information architectureがinformationを分類し，resource oriented architectureにつながる
作用
- 既存の3つの手法を，serviceとAPIを分けずに用いることで，resourceを導出できる
『Kubernetesで実践するクラウドネイティブDevOps』学習メモ
Ch01 Cloud Revolution
目的
- 3つの革命
- クラウドの創造
- DevOps
- コンテナ
- → Cloud Native with OS:Kubernetes
- revolutionのhistory, 重要性を見て，ソフトウェア deliveryへの作用を考える
- 想定される変化
- Cloud Native DevOpsがtheme
概要
- (1) クラウド
- 処理能力を買う
- SaaS
- Iaas
- Undifferentiated Heavy Lifting(UHL)
- (2) DevOps
- (3) コンテナ
- 依存関係, config
- history, background
- Puppet, AnsibleなどのConfig Management System
- omnibus package
- VM Image
- 問題多い（コスト，不安定）
- 特性: 可搬容量，コストdown, 規模の経済，扱いやすさ
- イメージ fileをコンテナ runtimeで実行
- 仮想化による実行効率downの解決 with real CPU
- file システムのlayerをaddress指定
- → コンテナ間でlayerの共有や再利用〇
- コンテナは再利用の単位
- scalingの単位，リソース配分の単位でもある
- コンテナが依存するのは唯一OSのkernelのみ
- Kubernetes
- history @ Borg
- コンテナをserverのpoolで実行するための割り当てとschedulingを行う集中管理システム
- history @ Borg
- values
- Kubernetesによる従来のシステム 管理 taskのautomate
- デプロイの容易さ
- zero down time デプロイ with Rolling Update
- canaria デプロイ, bluegreen デプロイ in Continuous デプロイ
- auto scale
- 冗長性とfail overでの信頼性と耐障害性up
- cost down by 能力の浪費cut
- クラウド providerと疎である by Kubernetesの抽象化
- コンテナはソフトウェアを定義するための可搬性の方法 & Kubernetes リソースはソフトウェアの実行方法の可搬性のための方法
- Kubernetesの制約
- DBなどのステートフルなworkloadへのcost 大
- → 代わりにmanaged serviceを使用
- Faas, (server served platform). e.g. AWS Lambda
- functionとコンテナのhybrid: Funtainer
- → Knative
- (4) クラウドネイティブ
- 一般的用法: クラウド, コンテナ, orchestrationを活用し，多くの場合OSSをbaseとする，最先端アプリケーションやserviceを簡潔に表現する手段．
- 自動化されたInfrastructure as Code
- 特性
- automate可能
- Ubiquitous and flexible
- resilient(弾力的) and scalable
- dynamic
- Obserbable
- distribution: 分散化，非集中化
- codeを単一のentity(monolithus)としてデプロイ
- or multi 分散 micro servicesで構成
- micro server: 1つのことを実行する自己完結型service
- monolithusの方が理解しやすく，相互作用を追跡できる
- but, monolithusは拡張difficult
- 一般的用法: クラウド, コンテナ, orchestrationを活用し，多くの場合OSSをbaseとする，最先端アプリケーションやserviceを簡潔に表現する手段．
作用
- 運用の観点
- Developer Productivity Engineering(Developer生産性工学), DPE team
- Site Reliability Engineering(SRE)
- Kubernetesの重要性 pointsのまとめ
Ch02 Kubernetes first step
概要
- Docker
- Dockerは複数で異なる but 関連する要素から成る
- コンテナ イメージ format
- コンテナ run time library
- コンテナのlifecycleの管理
- command line tool
- コンテナ 管理用API
- コンテナ イメージ: ZIP fileのようなもの
- 実行のためには，ID or URLを指定するだけ
詳細
(1) コンテナ build
- docker image build with Dockerfile
- Dockerfile specifies all what イメージ has to have
- 既存のイメージ(: base イメージ)にもとづいて新しいイメージをbuild
- multi stage build
- scratch イメージにbuilded binaryをcopy → 軽量化， attack surface(攻撃対象領域)の縮小
- -tによるtagづけ
portの転送
''' -p HOST_PORT:CONTAINER_PORT '''
- docker image build with Dockerfile
(2) コンテナ Registry
- Docker IDをgetし，Docker Hubにオリジナル イメージをpush
- イメージの命名とpush
- → どこからでもコンテナ イメージを実行可能
- (3) Kubernetes
- Enable Kubernetes @Docker Desktop
- demo アプリケーションの実行
- deploymentのcreate
- port forward
- (4) Minikube
まとめ
- コンテナをbuild and runの実践
- Kubernetes環境の確率
Ch03 Kubernetes 環境の選択
目的
- クラスタのbasical structureの理解
- Kubernetesの実行方法を決定するための情報
- managed serviceの長短
概要
- クラスタのarchitecture
- Kubernetesがmulti serverを接続して1つのクラスタとする
- controll plain
- このcomponentを実行するメンバ（ノード）: master ノード
- kube-apiserver
- etcd: DB
- kube-scheduler
- kube-controller-manager
- クラウド-controller-manager
- ノードのcomponent @Worker ノード
- kubelet
- kube-proxy
- コンテナ runtime
- 高可用性
- network partitionも処理〇
- controll platformの高可用性の重要性
- quorumを維持
- e.g. 本番クラスタは3つが最小
- quorumを維持
- multi availability zoneへの分散
- testの実施が重要
詳細
- (1) self hosting Kubernetesのcost
- buy or build
- cost 大．engineerの給与約100万ドル
- 初期セットアップから稼働を通してcareが必要
- まずはmanaged service
- (2) managed Kubernetes services
- GKE
- 高可用性
- multi zone/ regional クラスタ
- auto scale
- 高可用性
- EKS
- 後発＆割高
- AKS
- OpenShift: PaaS
- IBM Cloud Kubernetes サービス
- HKs
- GKE
- (3) turnkey方式のKubernetes solution
- (4) Kubernetes installer
- kops @AWS
- Kubespray with on-premised install & bare(何も導入されていない) metal server
- TK8 with Terraform and Kubespray
- Kubernetes The Hard Way: 教育に◎
- kubeadm: Kubernetesのinstallに◎
- Tarmak: 変更をノード 設定にrolloutする処理の迅速性と安全性up
- RKE: simple & high-speed
- Puppet Kubernetes module
- Kubeformation: 既存のautomate toolのwrapper
- (5) 原則
- running ソフトウェアを減らす
- standard technologyのuse
- cost 大のタスクはoutsource
- 長寿の競争優位
- → managed Kubernetesの推奨
- クラウドネイティブ: 差別化につながらない要素をoutsourceしビジネスを加速
- self-hostingならkops, Kubespray
- 限られた予算 e.g. Raspberry Pi
- running ソフトウェアを減らす
- (6) clusterless コンテナ service
- Amazon Fargate, ACI
まとめ
- Kubernetes クラスタをservice providerに任せ，確実性と経済性を得る
Ch04 Kubernetes objectの基本操作
目的
- Kubernetesの基本object: Pod, Deployment, サービス + Helm tool
概要
- (1) Deployment
- Superviserの機能 @Kubernetes
- 個々のプログラムに対応
- Deployment Objectを作成
- Deployment controllerによる制御
- Default: コンテナのrestart
- Deployment 情報 get command
- (2) Pod
- 1つ以上のコンテナのグループ ← クジラの群れ
- Podの仕様(spec: specification)のcontainers list
- kubectl run: Deploymentを作成 → DeploymentがPodを起動
- Deployment: 「あるコンテナを持つPodを1つ実行し続ける必要がある」といった，望ましい状態の宣言
- (3) ReplicaSet
- Deployment-ReplicaSet-Pod
- ReplicaSet controllerが必要な数（同一）のPod,ReplicaSetのグループを管理
- → DeploymentがReplicaSetを管理: ユーザのReplicaSetのupdateをcontroll
詳細
- (1) Keep desirable state
- 調整loop
- Deploymentのshutdown
- 調整loop
- (2) Kubernetes scheduler
- DeploymentがKubernetes DBにPod リソースを作成 & Pod into cueue
- → schedulerがPodを取り出してrunnabeなノードを見つける
- ⇔ Podをノードにscheduling
- → kubeletがPodが含むコンテナを起動
- DeploymentがKubernetes DBにPod リソースを作成 & Pod into cueue
- (3) YAML形式のリソース manifest
- Kubernetesは本質的に宣言的
- → continuous reconcliation(調整; cal-, -cli-: 呼び集める)
- → specを変更すればKubernetesが処理してくれる．
- DeploymentやPodなどのKubernetesのリソースはすべて内部のDBのrecordで表現
- 「kubectl run」でnew recordをinsert or 「リソースのmanifestを読み取るよう指示」
- コンテナ イメージの名前とPortが重要
- @DeploymentのYAML Manifest
- ↑→ kubectl runで指定していた
- kubectl applyでmanifestをクラスタに送信
- サービス リソース
- 単一の変化しないIP address or DNSnameを付与
- → 対応するPodへ自動ルーティング
- → Podにnetwork経由でconnect
- Web proxyやload balancerのようなもの
- backendのPodのグループにリクエストを転送
- 単一の変化しないIP address or DNSnameを付与
- サービスのYAML Manifest
- multi Pod → load balance
- 後始末 kubectl delete -f Kubernetes/.
- Manifestのdirectoryをdelete
- kubectlでのクラスタへのquery
- kubectl get
- kubectl describe pod/dem-dev-6c...
- YAML Manifestでの宣言的デプロイにおける繰り返しの解消 → Helm
- Kubernetesは本質的に宣言的
- (4) Helm: Kubernetes package manager
- command line toolでDeployment リソースとサービスをHelmが作成．
- アプリケーションをinstall and configure
- chart: real コンテナ イメージを含まないyaml manifestのwrapper.同じクラスタ内に何度もinstall可能
- アプリケーションをKubernetesで実行するために必要なリソースの定義がすべて格納されるHelm package
- repository: chartの収集と共有
- release: Kubernetes クラスタで実行されるchartの特定のinstance
- helm install -name
- helm list, helm status
- command line toolでDeployment リソースとサービスをHelmが作成．
作用
- 何ができるかを理解
- ↑ PodやDeploymentのメカニズム
Ch05 リソース 管理
目的
- クラスタの最大活用
- リソースの使用状況の管理と最適化など
概要
- リソースの理解
- Kubernetes schedulerの観点
- Podが求めるリソースの量を把握
- リソースの単位: CPU, milliCPU, MiB@memory
- リソース要求: min
- リソース制限: max
- over commit〇: ノードのリソース総量を超えた制限可能
- コンテナのminimize
- Kubernetes schedulerの観点
詳細
- (1) コンテナ lifecycle 管理
- Liveness probe by HTTP
- Probeの遅延と頻度
- death loopの回避
- initialDelaySeconds, periodSeconds
- ほかのtypeのProbe
- TCP, gRPC
- Readiness Probe: 「一時的にリクエスト処理不可能」を知らせる． → 常に「200 OK」を返す必要
- zero downtime upgradeにeffective
- file based Readiness Probe
- minReadySeconds
- Pod Disruption Budget: 失ってもよいPodの数
- minAvailable, maxUnavailable
- (2) Namespace
- (3) クラスタ cost optimize
- Deploymentのoptimize
- serviceが求める処理能力と可用性のビジネス要件
- その要件より少なく達成できるか
- Podのoptimize
- normal 運用のmax + α → リソースのPackman状態の回避
- Vertical Pod Autoscalar
- Nodeのoptimize
- 観察
- 典型的なPodをat least 5個実行数rのに十分なサイズ
- stranded リソース(残されたリソース)の割合をunder 10%
- 10個いじょうなら5%
- Storageのoptimize
- I/O operation 毎秒(IOPS)で観察
- 未使用リソースのclean up
- kubeletのgarbage collection設定を調整
- 所有者metadata Annotationを使用し，Annotationのないリソースを強制終了候補にする
- ↑ すべてのリソースに所有者Annotationを設定
- 使用率が低いリソースの発見
- 受信リクエストの数をPodがメトリクスとして公開
- Web コンソールで各PodのCPUとメモリの使用率の数値をチェック
- finished jobのclean up
- 余剰capacityのcheck
- reserved instanceのuseでのcost down
- preemptive (spot) instance
- preemptive ノードはクラスタ全体の2/3以下にする
- ノード affinityでpreemptive ノードへのscheduling制御
- Kubernetes scheduler: workloadを多くのノードに均等にassign & replicaを異なるノードにおいて高可用性
- schedulerはノード間でPodを移動しない．
- → Deschedulerというtoolでのmove
- schedulerはノード間でPodを移動しない．
- Deploymentのoptimize
Ch06 クラスタの運用
概要
- (1) クラスタのsizingとscaling
- (2) 適合性チェック
- test suite がKubernetesにある
- CNCF認定: Certified Kubernetes, CKA, KCSP
- Sonobuoyでの独自クラスタのtest or managed service
- Sonobuoy Scanner
- (3) 検証と監査
- tool
- (kubernete Guard: Kubernetes クラスタのcommon 問題 check)
- Copper / instrumenta / Conftest
- kube-bench: 不要なことも多い
- Kubernetesの監査logging
- tool
- (4) Chaos Test
- Chaos Monkey Test
- 自動化と継続
- chaos kube
- kube-monkey
- powerful Seal
- → 高可用性を保証
Ch07 Kubernetes's tools
目的
- Kubernetesの作業のためのtoolやutility
- kubectlの高度な使い方と便利なutility
概要
- (1) kubectl
- shell alias
- @.bash_profile: alias k=kubectl
- flagの短縮形のuse
- リソース typeの省略
- kubectlでの自動補完 + aliasでの自動補完
- helpの表示: kubectl -h
- Objectのhelp: kubectl explain {pods, RESOURCE.FIELD, --recursive}
- 詳細な出力の表示
- kubectl get pods -o wide
- JSON形式の出力とjqなどでのfilter (→ jqのinstall)
- or JSON Pathでのquery
- Objectのsupervise: kubectl get pods --watch
- kubectl describe pods demo-xxx・・・
- shell alias
- (2) リソースを使った作業
- (3) コンテナを使う作業
- log: コンテナがstandard output or standard error outputのstreamに書くものすべて
- logの閲覧: kubectl logs -n kube-システム --tail=20 --follow(-f) etcd-docker・・・
- → supervise continuous output
- --tail/--since/--timestamps
- コンテナへのattach
- KubesprayでのKubernetes リソースの監視
- コンテナ Portの転送: kubectl port-forward
- コンテナでのcommand execution: kubectl exec
- debugのためのコンテナ実行
- kubectl run NAME --イメージ=IMAGE --rm(→del after completed) --it(i: 対話型, t: terminal) --restart=Never --command --・・・
- BusyBox(BB) commandの仕様
- 対話型のshell in クラスタ + shell alias → bb
- BBのコンテナへの追加
- BBはたった1MiB
- DockerfileでCOPY --from 命令
- → kubectl exec -it POD_NAME /bin/busybox sh
- コンテナへのプログラムのinstall
- kubesquashでのlive debug(本格的debugger)
- debuggerをコンテナにアタッチ: kubesquash
- with goのdebugger: dlv
- (4) ContextとNamespace
- Context: クラスタ, ユーザ, Namespaceの組み合わせ
- → bookmarkになる
- kubectl: 今のContext
- kubectl config get-context
- kubectxとbubensでContext切り替え高速化
- kube-ps1で現在のContextをpromptに追加
- → [( )]
- Context: クラスタ, ユーザ, Namespaceの組み合わせ
- (5) Kubernetesのshellとtool
- kube-shell: 補完のpopup
- Click: 対話型kubectl
- kubed-sh: クラスタ自体の上でプログラムを実行
- Stern: log
- (6) オリジナル Kubernetes toolの構築
- client-goでkubectlができるすべてを実現
作用
- kubectlで必要なことは何でもできる
Ch08 コンテナの実行
目的
- ~Ch07: 運用
- Ch08: 最も基礎的なObject in Kubernetes: コンテナ
概要
- (1) コンテナとPod
- Pod: Kubernetesでの{minimum デプロイ, schedule}単位
- Pod Objectが{単一/複数のグループ} コンテナを表す
- Kubernetesのすべての実行はPodを使用する
- 同じ実行環境上のアプリケーション コンテナ + storage volumeの集まり
- 1つのPod内のコンテナはすべて同じマシン上に配置
- コンテナ: 1つのソフトウェア, 依存関係, config, データなど，実行に関するものすべて
- 実行の担保はプロセス
- プロセス: 実行するアプリケーションのbinary codeとmemory statusを表現し，同じglobalなNamespaceに存在
- → プロセス間のやり取り〇．同じリソースのpoolを共有
- プロセス: 実行するアプリケーションのbinary codeとmemory statusを表現し，同じglobalなNamespaceに存在
- コンテナ: オリジナル Namespace内にある分離されたプロセス(のグループ)を表現する
- コンテナの内外ではプロセスは隠れる
- 実行の担保はプロセス
- コンテナの構成要素
- Podの構成要素
- Pod: 相互に通信してデータを共有する必要がある
- コンテナのグループを表現
- ともにschedule. 起動終了も同時．同じ物理マシン上で実行
- ⇔ 常に同じノード上で実行
- 異なるマシンで動作しないコンテナをPodでグループ化する
- Pod: 相互に通信してデータを共有する必要がある
- Pod: Kubernetesでの{minimum デプロイ, schedule}単位
- (2) コンテナのManifest
- 複数のコンテナsのtemplate spec
- name, イメージ
- イメージ識別子
- registry hostname, repository Namespace, イメージ repository, tagの4つで構成
- tagの例
- latest tag
- default: latest e.g. alpine:latest
- 本番環境ではlatestは×
- コンテナのdigestで決定的デプロイ
- ←→ tagでの非決定的デプロイ
- base イメージのtag
- 特定のtag/ digestのuse
- Port: Kubernetes上には意味なし．しかし，Manifestには含める
- リソース要求制限
- イメージのpullについてのpolicy: imagePullPolicy
- 基本はIfNotPresent
- 環境変数の設定
- 複数のコンテナsのtemplate spec
- (3) コンテナのSecurity
- principle of least privilege
- bug riskのminimize
- 一般ユーザの割り当て: runAsUser
- UID 1000: first not root ユーザ
- security maximize: コンテナごとのUID
- データを共有するためのアクセス: 共通UID
- runAsNonRoot: true
- readOnlyRootFileSystem: true
- allowPrivilegeEscalation: false
- setuid（権限昇格）のmechanismから守る．
- Capability
- 従来のnormal/super ユーザ問題への対応
- default CapabilityのDropと特定のCapabilityのadd
- 一部のConfigはPodのレベルでも〇
- Pod Security Policy リソースにより，クラスタ levelでsecurityを指定
- Podのサービス Accountの指定
- defaultは,Namespaceのdefaultのサービス Accountが持つpermissionで実行
- principle of least privilege
- (4) Volume
- 同じPodの別のコンテナとのデータ共有 & restart後もデータを永続保持
- emptyDir
- download fileや生成データのcaching
- データ処理ジョブ用のtmpworkspace
- Pod内コンテナのファイル共有
- コンテナへのマウント方法
- PodのVolumes field
- コンテナのvolumeMounts field
- lockはない
- 永続Volume
- DBはほかのクラウドで〇．Kubernetesは×．
- ↑ stateless Kubernetesのため．
- DBはほかのクラウドで〇．Kubernetesは×．
- (5) restart policy
- restartPolicy: Always(default)/ OnFailure/ Never
- → Job リソース
- (6) Image Pull Secret
- registryに認証情報を提供
まとめ
- コンテナの概要
- Pod内でのコンテナの連携
- Kubernetesでのコンテナの実行のコントロール
Ch09 Pod 管理
目的
- Podのfeatureを見る
概要
- (1) Label
- definition: PodなどのObjectにつくkey-value pair
- core システムのsemanticsを直に構成しない．Object識別属性を指定するためのLabel
- e.g. Podが属するアプリケーションをlabeling → documentation
- selectorと組み合わせて価値が生じる
- selector: Label(or Labelのset)との一致条件を記述
- → リソースのグループをLabelでspecify
- 用途
- サービスとPodを接続
- kubectl get ~ --selector(-lでもOK) app=demo
- --show-labelsでLabelを確認
- selector: Label(or Labelのset)との一致条件を記述
- サービスは等価selectorのみ
- Labelの使い方
- staging/real
- カナリアデプロイ track: stable/canary
- Label: リソースを識別 ←→ Annotation: 外部toolやservice
- どちらもk-v pair
- definition: PodなどのObjectにつくkey-value pair
- (2) Node Affinity
- schedulingの選好性の表現
- hard: required ...
- soft: preferred ...
- schedule時のみ
- Hard Affinity
- Podを実行させたいノードの種類を述べる． @nodeSelectorTerms
- Soft Affinity
- weightの指定
- schedulingの選好性の表現
- (3) PodのAffinityとAnti-Affinity
- ノード内のPodの状態をAffinityに反映する
- Podの同居: hard/soft Pod Affinity
- Podの分離: podAntiAffinity
- soft Anti-Affinity
- Pod Affinityでしか解決できない問題にのみ使用
- (4) Taint(汚染)とToleration
- ノードの属性に基づき，ノードがPodを避ける
- kubectl taint ←→ kubectl taint ~-(-: minusでdelete)
- TolerationでTaintにも許容
- e.g. networkが×のときのunreachable
- (5) Pod Controller
- 手動workのautomate
- 主要はデプロイ → ReplicaSetを管理
- デプロイ以外
- DaemonSet: クラスタ内の個々のノードで，Podのcopyを1つだけ実行
- e.g. logging
- StatefulSet: Podを特定の順序で起動・終了
- 番号でPodを識別 to Redis, MongoDB, Cassandra
- Headless サービスでaddress指定
- DaemonSet: クラスタ内の個々のノードで，Podのcopyを1つだけ実行
- Job: Podを指定した回数だけ実行する
- ←→ デプロイ Pod数を指定しcontinuousに実行
- completions
- parallelism
- Cron Job
- Jobのschedule
- Horizontal Pod Autoscaler(HPA)
- needsに応じてKubernetesがreplica数をautoscale
- Vertical: replica自体を大/小化
- CPU使用率などのメトリクス{での決定, の指定}
- システム/service(← ユーザのdefinition) メトリクス
- needsに応じてKubernetesがreplica数をautoscale
- Pod Preset
- admission controllerの一部
- admission controller: objectへの変更を監視．変更の直前にaction
- Pod Presetのconfigは，個々のPodのconfigとmergeされる
- admission controllerの一部
- OperatorとCustom リソース Definition
- ステートフル setを超えたcomplicateな管理が必要なアプリケーションのため．
- (6) Ingress リソース
- (7) Istio
- サービス mesh: 複数アプリケーションsやサービスの相互通信のある環境の運用のための技術
- (8) Envoy
- 高度なload balancer
作用
- Kubernetesの全てはPodの実行にかかわる
Ch10 Config, Secret データ
目的
- Kubernetesのlogicとconfigの分離
- Podのspecでdefineする環境変数で値をアプリケーションに引き渡す
- or ConfigMapとSecret ObjectでConfigをKubernetesに直に保存
概要
- (1) ConfigMap
- KubernetesにConfig データを保存するためのmain Object
- kubectl create configmap demo-config --namespace=demo --from-file=config.yaml で作成
- kubectl getでManifestを出力
- ConfigMapで環境変数を設定
- ConfigMapから環境全体を設定
- encFromでConfigMapから全keyを取り込む
- ←→ envがprior
- encFromでConfigMapから全keyを取り込む
- command argumentで環境変数を使う
- $(VARIABLE)は環境変数のVARIABLEの値で置き換える
- → コンテナのentry pointにcommand line argumentとして与えられる
- $(VARIABLE)は環境変数のVARIABLEの値で置き換える
ConfigMapからConfig fileを作る
'''
データ: config: | greeting: Buongiorno'''
- |は生データのblockを表す
'''
volumes: - name: configMap: name: items: - key: config path: demo.yaml'''
Configの変更を伴うPodの更新 @Helm
- Annotationを設定 @デプロイのyaml
- (2) KubernetesのSecret
- (3) Secret Data Management戦略
- 問題
- secret データの可用性のための保存場所
- running アプリケーションがsecret データを使う
- secret データの変更へのrunning アプリケーションの対応
- version 管理でのsecret データのencrypt
- デプロイ時にdecrypt
- secret データのrotationがdifficult
- 容易さ〇，柔軟さ〇
- secret データのremote 保存
- 一元補完
- 手間アリ
- 変更の管理のために監査ログが必要
- workflow必要
- 専用のsecret データ 管理 tool
- 大規模組織のみ
- infrastructureがcomplicateになる．コスト大
- 推奨
- SOPSなどの軽量encrypt toolのuse
- 問題
- (4) SOPSでのsecret データのencrypt
作用
- 必要なconfigやデータをアプリケーションと結びつける方法の理解
Ch11 Security and Backup
目的
- Kubernetesにおけるsecurityとaccess controllの仕組みの検討
- 脆弱性をscanするための代表的toolやservice
- Kubernetesのデータとstateのbackup と復元方法
概要
- (1) access controllとpermission
- クラスタ別のaccess controll
- クラスタ運用者/ アプリケーション developerの2group化
- 本番/ staging
- RBAC(Role-Based Access Control) @Kubernetes
- 有効化
- 確認: kubectl describe pod ...
- 有効化
- Role
- ユーザが持つpermissionの特定のsetをroleが統制
- namespaceやクラスタを対象に
- RoleBinding ObjectでユーザとRoleを紐づけ
- 加法的Permission
- 必要なrole: defined roleのクラスタ-admin, edit, viewでおおよその要件は〇
- クラスタ-admin ≒ root
- not クラスタ 運用者やinternetにopenなservice accountには×
- アプリケーション専用のservice accountに対してRoleBinding Objectでroleを紐づける
- CD toolにのみアプリケーションのデプロイを許可
- "edit" role
- RBACの問題の対処方法
- API serverのログでRBAC DENYを探す
- クラスタ別のaccess controll
- (2) Security Scan
- (3) Backup
- (4) クラスタのstatusの監視
- kubectl
- クラウド providerのconsole
- Kubernetes Dashboard
- securityが重要
- never public internet
- minimumの権限．kubectl proxy経由のaccess
- 不要なら使わない
- Weave Scope: クラスタの監視と視覚化
- kube-ops-view: クラスタ内の視覚化
- ノード-問題-detector: Kubernetesのaddon ノードの問題の検出
作用
- 知識・思考・注意を要するcontinuous プロセス: security
Ch12 Kubernetes アプリケーションのデプロイ
目的
- Manifest fileからアプリケーションを実行
- アプリケーション用のHelm Chartのbuild
概要
- (1) HelmでのManifestのbuild
- fileの保守 + 配布の問題を解決
- 設定値や変数を生のmanifest fileから分離
- ほかのアプリケーションやserviceへの依存関係も公開できる
- Chartの内部校正
- Helm template
- 依存関係の指定 → helm 依存関係 update
- requirements.yaml
- fileの保守 + 配布の問題を解決
- (2) Helm Chartのデプロイ
- 変数の設定
- 追加の値file. releaseにおける値の指定: helm install ~ --values...
- 値の確認: helm inspect values
- Helmでのアプリケーションの更新．何度でも〇
- helm upgrade \<既存のデプロイ>
- 追加の値file. releaseにおける値の指定: helm install ~ --values...
- 指定のversionへのrollback: helm rollback \<デプロイ name> 1
- rollforwardもrollbackで〇
- helm-monitorによるauto rollback
- Helm Chart Repositoryの作成
- 普通はアプリケーション独自のrepositoryに保存のため不要
- Secret by SOPS in Helm Chart
- secret データを値fileにいれ，SOPSでencrypt
- command, 適用手順
- 変数の設定
- (3) Helm fileによる複数 Chartの管理
- (4) 高度なManifest 管理 tool
- ksonnet: 計算やlogicが必要な大規模でcomplicateなデプロイに〇
- → projectが中止
- Jsonnet: JSONの拡張．KubernetesはJSONも〇
- prototypeの導入: よく使われるManifest pattern
- Kapitan
- 設定値の階層DB: inventory
- → 環境やアプリケーションに合わせて異なる値でmanifest patternを再利用
- 設定値の階層DB: inventory
- kustomize
- plainなYAML
- overlayでパッチとして適用
- kustomize build ~ | kubectl apply -f ~
- kompose
- docker-compose.yml: 連携して機能する一連のコンテナを定義, and デプロイ + コンテナの通信方法を定義
- → Kubernetes Manifestに変換するtool
- Ansible
- 混合infrastructureの場合に強力
- Kubernetes クラスタのinstallと設定
- Kubernetes moduleでデプロイやサービスなどのKubernetes リソースを直に管理
- kubeval
- Manifestの検証 to schema by version
- CD パイプラインへの追加が〇
- Conftestも〇
- ksonnet: 計算やlogicが必要な大規模でcomplicateなデプロイに〇
作用
- Kubernetesでのデプロイの簡単化
Ch13 Development workflow
目的
- localのdevelopmentからKubernetes クラスタへの更新のデプロイまでのアプリケーションのlifecycleを扱う
概要
- (1) development tool
- Skaffold: development workflowのspeed up
- skaffold.yamlにworkflowを定義
- → skaffold command line toolの実行でパイプライン start
- Draft
- Skaffoldと同様， by Azure team
- Draft Pack: アプリケーションが使用する言語に対応したDockerfileとHelm Chart
- draft init && draft createで言語を特定
- リソースの適用: draft up
- Telepresence: local machineをremote クラスタに参加させられる
- Knative: 開発中． コンテナ化されたアプリケーションやserverless styleの機能を含めたあらゆるworkloadをKubernetesにデプロイ
- KubernetesとIstioの両方と統合
- build プロセスのsetup, デプロイ のautomate, Eventing
- Skaffold: development workflowのspeed up
- (2) デプロイ戦略
- zero downtime デプロイ → ユーザのリクエストに対応するアプリケーションでは必要
- Rolling Update( 0 downtime ) ←→ Recreate (high speed)
- デプロイ Manifestで定義
- default: RollingUpdate
- minReadySecondsでroll outをPodの安定まで待機． @RollingUpdate
- MaxSurgeとmaxUnavailable: 基本は変える必要なし
- blue green デプロイ
- サービスからtrafficを受信するPodを決定するため，Labelを使う
- → サービスのselectorのdeployment fieldに設定
- blue, green, ... → rainbow デプロイ
- canaria デプロイ → Istioを使うと高度なデプロイが〇
- (3) Helmでの移行
- DBがかかわるときに必要な「移行」
- Job リソースで実現
- Helmのhookで可能
- Job リソースで実現
- Helmのhook: デプロイ中の処理準をcontroll
- JobのAnnotationで指定
- 失敗にも対応〇
- pre-upgrade以外のhook
- hookのchain化: 複数 hooks をchain化 by order
- helm.sh/hook-weight propertyを使う
- DBがかかわるときに必要な「移行」
作用
- Kubernetes アプリケーションの開発の高速化． by tools
- 変更の本番環境へのrooloutが容易
Ch14 KubernetesでのCD
目的
- CDとCDのKubernetes based クラウドネイティブ 環境での実現
- Kubernetesと連携して動くCD パイプライン
- コンテナ化されたアプリケーションのパイプラインの典型
- codeの変更をgit repositoryにpush
- build システムがbuild & test
- test ok → コンテナ イメージがコンテナ Registryに対してpublish
- new builded コンテナがautomatically デプロイ to staging 環境
- automatic acceptance test in staging 環境
- tested コンテナ イメージ tobe デプロイ to production 環境
- デプロイの対象の成果物は〇コンテナ， ×Source Code
対応
- (1) CD tool
- (2) CDのComponent
- 既存のCDにコンテナ用Componentの追加のe.g.
- Docker Hub
- Gitkube: self hosting. simple + 可搬性〇．setupも間t何
- Flux: with GitOps extended
- Keel ≒ Flux
- 既存のCDにコンテナ用Componentの追加のe.g.
- (3) CD Pipeline のe.g. by Cloud Build
- Google CloudとGKEのセットアップ
- test run
- アプリケーション コンテナのbuild → アプリケーション コンテナの作成
- Kubernetes Manifestの検証
- イメージのPublish
- Git SHA tag @成果物 → Codeのsnapshotになる
- triggerの作成: 監視target Git Repository, active化の条件, パイプライン fileの指定
- triggerのテスト
- CD パイプラインからのデプロイ
- Kubernetes クラスタへの認証情報の獲得
- ユーザ definitionの置換
- 環境 tagの追加
- クラスタへのデプロイ
- Kubernetes クラスタへの認証情報の獲得
- デプロイ triggerの作成
- tagのpushでtrigger
- 代入変数
- Build PipelineのOptimize
- コンテナ based CD Pipeline toolは，各stepのコンテナをminimize
- multi stage buildでオリジナル custom イメージをbuild
- コンテナ based CD Pipeline toolは，各stepのコンテナをminimize
作用
- アプリケーションのためにCD Pipelineをsetup → 一貫した方法と高い信頼性でソフトウェアを迅速にデプロイ
Ch15 オブザーバビリティと監視
目的
- オブザーバビリティと監視の関係
- Kubernetesでの監視，logging, メトリクス tracingの扱い
概要
- (1) オブザーバビリティ
- 監視を超えた概念
- 監視
- automatic 監視 @DevOps
- blackbox監視
- up/down test
- logging: 中央DBに集約 → 問題のtrouble shoot
- limit: developerのjudgeで作成．query difficult, signal/noise比が△
- scale difficult
- logを超えた方法が必要 → Metrics
- メトリクスの導入
- @アプリケーション's メトリクス
- @Infrastructure's メトリクス
- プロセス/コンテナのCPU使用率
- ノードやServerのdisc I/O activity
- machine, クラスタ, load balancerのI/O network traffic
- メトリクス: 「なぜか」の解決に有用
- 予測にも使える
- アプリケーションを内部から監視
- 実際の動作に基づいてシステムの隠れた側面に関する重要 情報を外に伝えられる
- → 〇内からの監視/ ×reverse engineering
- tracing @分散 システム
- メトリクスやtracingなど全体をカバーした用語としてのオブザーバビリティ: システムがなぜ正しく機能しないのかの理解
- ←→ 監視: システムが正しく機能しているかどうか
- データについてのオブザーバビリティも重要
- 不透明なソフトウェアを測定
- Codeのdevelopmentとproduction 環境での大規模実行との間のloopを縮める重要 tool culture
- (2) オブザーバビリティ Pipeline
- bufferによる統合 with standard メトリクス style by structured データ
詳細
- Kubernetesでの監視
- 外部からのblackbox check
- 監視はユーザの挙動を模倣
- 外部からサービスの可用性を監視 vs 機能停止: Monitoring as a サービス
- 既存サービスを使用する（安価 or freeのため）
- 内部health check
- ユーザ's happinessが観点となる
- @コンテナ
- × Liveness check
- 〇 Readiness check to 依存関係 failures
- circuit breaker pattern
- elegant 劣化とする
- 外部からのblackbox check
作用
- クラウドネイティブ環境で監視が目指すべき方向性
- オブザーバビリティの価値 with メトリクス
Ch16 KubernetesにおけるMetrics
目的
- Metricsの扱い方
- Metricsとは
- 特定の対象を測定した数値
- → 特定の瞬間における状況のsnapshot + 変化を示す
- 時系列データ by sampling
- メトリクス値: Counter/Gauge
- Counter: increment only or reset to 0.
- 量の表現
- Gauge: 増減〇. memory使用率など
- 比率の表現
- Counter: increment only or reset to 0.
- 異常やfailureの通知 + 機能状況の表示
- → 「なぜか」の解決
- 特定の対象を測定した数値
概要
- (1) 優れたメトリクスのchoice
- メトリクスの一部へのfocus
- 要件ごとのオブザーバビリティのためのメトリクス pattern
- service: RED pattern
- リソース: USE pattern → 性能問題の分析とボトルネックの発見のためのbottom up型の方法 ←→ service
- :システムの健全性のcheck, 高速で可視性高い
- Utilization: 使用率
- Saturation: 飽和度
- Error
- 対象は〇リソース/ ×Service
- → システム 性能のbottleneckの発見
- e.g. CPU, disc, networkのIFやLink
- → システム 性能のbottleneckの発見
- ビジネス メトリクス
- 加入者についてのデータの把握
- funnel analysis
- 解約率
- 収益/顧客
- help, support pageの有効性
- System Status pageへのtraffic量
- funnel analysis
- 共通のdatalakeを使用 in two or more groups
- 加入者についてのデータの把握
- Kubernetesのメトリクス
- クラスタ healthのメトリクス
- ノード数
- ノードのhealth status
- Pod数/ノード or Pod数 in all
- リソース使用率, 割り当て by ノード or 全体
- クラスタ healthのメトリクス
- デプロイのメトリクス
- デプロイの数
- デプロイごとのreplicaの設定数
- デプロイごとの利用不可のreplicaの数
- コンテナに関するメトリクス
- コンテナ/Podの数 by ノード or 全体
- リソース使用率 to リソース要求/リソース制限
- コンテナのLiveness/Readiness
- コンテナ/Podのrestart 数
- 各コンテナのnetwork I/O traffic and error
- アプリケーションのメトリクス
- アプリケーションの機能による
- 性能や可用性の問題のため
- アプリケーションの実行内容，頻度，処理時間
- とりあえず不明なら記録する
- SLOやSLAに対するアプリケーションの性能も知る
- runtimeのメトリクス
- プロセスのrun statusを知る
- 6こ
- 性能の劣化やcrashについての診断に〇
- プロセスのrun statusを知る
- (2) メトリクスの分析
- (4) メトリクスのdashboardによるグラフ化
- (5) メトリクスに基づくアラート
- アラートの問題
- 分散 システムは完全upにはならない
- S/N比を高める必要
- アラートは，直ちに人間が対処すべきもの(という単純な事実)のみ表すべき
- いずれ対処 → mail, chatでのアラートでよい
- OnCallの負担の軽減の重要性
- アラートは緊急かつ重要で対処可能なもののみ
- → 一握りのメトリクスに限定
- → そうでないものは非同期通知
- 要因についてのメトリクス
- アラートの問題
- (6) メトリクス 管理のtool, サービス
- OSSが優秀
- Prometheus: defact standard with Kubernetes
- scraping(収集) プロセスでautomaticにメトリクスを収集
- Helmでcommand 1つでKubernetes クラスタにinstallできる
- simpleな構成・仕組み
- pull type の監視
- Grafanaなどで，Prometheusで収集・保存した情報を活用
- → 時系列データのグラフ化
- Alertmanager
- 重複排除 → アラートのグループ化 → 通知serviceにルーティング
- Open メトリクスのbaseとなっている
- その他のtools
作用
- proper データの収集 → proper方法で処理 → properな問題の解決に活 → proper方法でvisualize → properな事項をproperな対象者にアラート
『パーフェクトRuby on Rails』学習メモ
Part1 Rails overview
Ch01 Ruby on Railsの概要
- Rakefile
- rake -T : タスク一覧
- rake (taskname) : タスク実行
- bundle
- gem packageを束ねる
- Gemfileが作られる．
- Railsの思想
- Web application開発のためのframework
- CoC(Convention over Configuration)
- 設定より規約
- 規約により設定が不要になる．
- DRY
- REST(REpresentational State Transfer)
- 自動テスト
- まとめ
- Railsをはじめよう
- rails new (project name)
- 重要なファイルなど
- binstubファイルとして，binにbundle exec省略可能なコマンドを置いている．
- MVC architectureとして，appディレクトリ以下にmodels, views, controllers + Viewで使うhelpers + assets for frontend + others
- rails s: Web applicationを起動. s: server
- libは，独自に実装したRakeタスクなどを配置するのみ．かつては，独立性の高いコードを置く運用もあった．
- よく使うrailsコマンド
- routes: display routing information
- runner: 処理を明確にするため，Rakeとは個別のコマンドとして用意された単体スクリプトの実行
- rails new (project name)
- scaffold(足場)
Ch02 Ruby on RailsとMVC
目的
内容
- MVC architecture
- Model
- DBとの接続とデータに対する操作，およびビジネスロジック
- View
- Modelの内容を参照し，視覚表現を行う
- Controller
- Modelのロジック呼び出し，必要なViewの選択など，ModelとViewをつなぐ部分
- モデルの基礎と考え方
- modeling: システムを作ることは，解決する問題に対して必要な概念を探して，命名・関係性の整理を行うこと．
- ActiveRecordでのmodelのimplementation
- ActiveRecordでのmodelの役割
- DBのrecordとActiveRecord objectを結びつける
- ActiveRecordの内部のActiveModelというモジュールにより，ビジネスロジックの実装的な振る舞いの部分を実行する．
- ActiveRecordでのmodelの役割
- modelとCRUDとの対応．
- Model
- modelを扱う
- modelを通じた検索
- ActiveRecord::Relationクラスについて
- ActiveRecordのQuery Interfaceによる操作結果をオブジェクトとして表現するもの
- SQLの情報を保持し，実際に必要になったときのみDBにアクセス．
- 明示的にSQLを発行するときは，to_a method
- Scopeで，よく使う検索条件をまとめて命名
- nilを返す必要があるときはクラスメソッドで定義する方が〇
- default_scopeは安易には使えない
- ActiveRecord::Relationクラスについて
- model同士のrelation
- 関連付け
- SQLite3のための対応必要．
- has_many, has_one, belong_to
- 多対多
- 中間テーブルが必要．
- 関連付け
- dataの更新
- create, save
- validation
- !をつけるとvalidation失敗時に例外発生
- callback
- callbackpoint
- enum
- !, ?
- modelを通じた検索
- controllerの役割
- hook
- CSRF(Cross Site Request Forgeries)対策
- resources routing
- exception
- rescue_from
- StrongParameters
- Mass Assignmentで利用できるHashのkeyの許可リストを定義する
- 権限の扱いなど
- controllerとviewの協調と，view templateの基本
- renderingまでの流れ
- contentsのtypeに合わせる
- respond_to
- redirect_to
- 部分テンプレート, layout
- variantsによるtemplateの切り替え
- about view template
- Prefixの値 + _path で，routingで定義したpathを取得できる
- _urlでは，ドメインなども含んだ完全なURL
- helper methodの活用例
- url_for
- link_to
- form_with
- stylesheet_link_tag, javascript_pack_tag
- その他
- 独自メソッド定義
- app/helpers
- escape 処理
- XSS対応
- そのまま表示 → raw
- XSS対応
- template engine
- API server として振る舞うときのviewについて
- Prefixの値 + _path で，routingで定義したpathを取得できる
まとめ
- Model層について，ActiveRecordの基本的な操作，validation，callback
- Controller層について，ModelとViewをつなぐこと，request objectやaction callback，脆弱性への対処
View層について，受け取ったModelを表示すること，template engine， helper method，様々なformatでの表示
applicationの主要なlogicはなるべくModelに書くべき
- Fat Modelへの対応必要．
Ch03 Railsのbasic機能
- testの種類と実行方法
- RackとRailsの関係
- Rack: Web application serverとWeb application frameworkの中間において，interfaceを共通化した仕様・実装
- 疎結合なやり取りを行えるようにするもの
- Rack application: call methodから受け取ったHTTP request dataなどを元にresponceとして返す内容を決定し，call methodの戻り値とするもの
- Rack middleware
- middlewareは，initializeで後続として処理していくapplication(or middleware)のオブジェクトを受け取り，自身のcall methodが呼ばれたときにinitializeで受け取ったオブジェクトのcall methodを呼ぶことで，後続処理を行うという流れ．
- Pylonsの説明にある玉ねぎの図
- config内で，使用の有無を管理
- middlewareの上下関係の設定もできる
- Rack: Web application serverとWeb application frameworkの中間において，interfaceを共通化した仕様・実装
- DBの管理
- 秘密情報の管理
- versionごとに管理方法が異なる
- より開発プロセスにあった形になっている．
- HTTPとRails application
- Early Hints
- 200 OKの前に，103 Early Hints
- HTMLのパース中にアセットのロード可能
- 200 OKの前に，103 Early Hints
- CSP(Contents Security Policy)
- config/initializers/content_security_policy.rb
- nonce
- strict-dynamic
- Early Hints
Part 2 Railsの周辺知識
Ch04 frontendの開発手法
- Railsで利用するエコシステムの軸をfrontend開発の標準的な仕組みに移している．
- JSを管理
- CSSや画像の管理
- 自動ビルド
- ビルド方法の切り替え
- libraryの統合
- plugin, loaderの追加
- CSSの管理
- 控えめなJS framework
- Stimulus: 規約をもたらすframework
- server sideにbusiness logicの実装が寄る
- HTMLはサーバから返す
- server sideとfrontendを合わせたトータルの工数が少ない
- frontendで表現できる幅が狭まる
- server sideにbusiness logicの実装が寄る
- Stimulus: 規約をもたらすframework
Ch05 Rails標準の機能を活用して素早く機能実装する
- Active Jobによる非同期実行
- mail sending, data集計→CSVファイル作成などの時間がかかる処理に使う
- 実装，キュー，引数，バックエンドの設定，複数キューの管理，ジョブの例外処理，ジョブのテスト
- Active Storageによるファイルアップロード
- 動作，設定
- サムネイルの生成
- access制限
- direct upload
- helperの不足
- cacheの不足
- Action Mailerによるメール送信
- 使い方，動作確認
- 設定
- test
- Action Mailerによるメール受信
- 対応サービス
- 事前準備
- projectの作成
- 処理の流れと実装手順
- test
- Action TextによるRich text 機能
- 使い方
- N+1問題
- customize
- Action Cableによるreal time通信
- web socketを使ったリアルタイム処理
- chat serviceの作成
- config
- 認証
- worker数の設定
- UT
Part3 Web Application development
Ch06 Rails application development
- Railsの機能をいつどのように使うか，一般的なWeb applicationを開発する際に気を付けるべきポイントを見る
- event notify applicationを作る
- applicationの作成と下準備
- OAuthを利用して「GitHubでログイン」機能を作る
- GitHub applicationの登録
- ログインのための機能の作成
- user model作成
- ログイン処理の作成
- ログアウト処理の作成
- event registration機能の作成
- eventの閲覧機能を作る
- l: localize
- eventの編集・削除機能を作る
- 関連を利用する
- 登録されたeventへの参加機能，参加キャンセル機能を作る
- 退会機能を作る
- 基本の7つ以外のアクションを作りたくなったら別のコントローラを作る．
- おわりに
- なぜこのような機能があるのかが重要
Ch07 Rails applicationの test
- test codeをどう書いていくか
- minitest, RSpec
- test data作成
- factory_bot
- sequenceで，固定値を回避
- 乱数を同じにする場合はseedをオプションで指定する．
- factory_bot
- system test
- 環境の問題の解決が必要@wsl2
- controller test
- 権限のテスト
- viewのテストはシステムテストで集約することが多い
- model test
- stub, mock
- ランダムな値で都合のいいデータを回避
- validationのテストの扱い
Part4 Rails applicationの拡張・運用
Ch08 Rails application 拡張
- file upload機能の作成
- libvipsを使う
- direct upload時のvalidationは注意点アリ
- gemで機能拡張する
- Kaminari: pagenation
- searchkick
- https://www.elastic.co/guide/en/elasticsearch/reference/current/targz.html
- 単純な検索はGET， 複雑な検索フォームならPOST
- その他の機能
- error handling
- rescue_fromは後に登録したものから順番に判定
- Rack Middlewareを使ったerror handling
- 独自の例外でpublic/500.html以外を表示したい場合に設定する
- dynamic error pageのdemerit
- routingの制限
- error handling
- gemの選定
Ch09 コードの品質を上げる
- CI
- GitHub actions
- Elasticsearchとplugin
- GitHub actions
- gemの定期更新
- Dependabot
- static analysis
- coverage測定
- SimpleCov
- Coveralls
- Application Performance Measure(APM)
- Skylight
- rack-mini-profiler
- localで手軽に動かせる
Ch10 containerを利用したRails applicationの運用
- Rails applicationのinfrastructure概要
- Infrastructure as Code → Docker
- Disposable
- 基本的なDocker imageの構築
- 開発環境におけるDockerの活用
- ホストマシン上のdirectoryをコンテナ上にマウント
- docker-compose
- 環境によって可変する設定値や秘匿情報の管理
- log出力
- stdout
- error tracking
- 外部サービスをuse
- HTTP serverとの通信
- nginxなど，速さ，扱いやすさなどで必要
- Herokuのガイドなど
- kubernetesについて
Part5 expert Rails
Ch11 複雑なドメインを表現する
- architecture patternから見るRails
- domain modelとActiveRecord
- RailsではデータストアにRDBを想定
- ActiveRecordというarchitecture patternを用いて，DBのレコードとオブジェクトを対応付け
- RailsではデータストアにRDBを想定
- what's ActiveRecord
- 単一table継承
- あるクラスから派生するすべてのサブクラスを1つのtableに対応させる
- type columnで，各レコードがどのクラスに属するか識別
- 扱いがほかのカラムと異なる
- type columnで，各レコードがどのクラスに属するか識別
- 継承の是非の検討が必要
- あるクラスから派生するすべてのサブクラスを1つのtableに対応させる
- domain modelとActiveRecord
- value object
- entity: 属性の値にかかわらず一意に識別
- 値objectに切り出す
- composed_of
- service object
- 複数のobjectを組み合わせて表現するとき
- eventで表現できる場合はeventで表現する
- test doubleを使えないdemeritあり
- 実装rule, interface
Ch12 複雑なUCを実現
- UCとmodel
- DBと紐づかないmodelを作る
- UCのlogic の分離
- ActiveModel
- DBに紐づかないmodel
- Attributes, Callback
- Serialization
- attributes
- Validations
- Model
- controller, viewのメソッドでobjectを使えるようにする
- form object
- UC logicを実装するobject, application serviceやInteractor, にform_withとの連携に必要なIFを持たせたもの
- Userとのやり取りに用いるformを簡単に実装できる
- 共通のvalidation ruleの定義
- UC logicを実装するobject, application serviceやInteractor, にform_withとの連携に必要なIFを持たせたもの
- presenter
- view helperの問題点への対応
- a.c.a. Decorator
- ActiveDecorator
Ch13 複雑なデータ操作を実装する
- Concern
- data 操作に関するlogicの実装と関連付けの宣言を行うlayer
- ActiveSupport::Concern
- included, class_methods, module間の依存関係解決
- @routing
- Callback Object
- 実装方針
- 更新系はCallback Object
- for test
- 参照系には利用できない
- 更新系はCallback Object
- 実装方針
VSCodeでGitを使うときに覚えておくこと
VSCodeでGitを使うときに覚えておくこと。
https://qiita.com/y-tsutsu/items/2ba96b16b220fb5913be
コマンドパレット：ctrl+shift+P
リポジトリの初期化 or clone
ファイル追加→ステージング
コミット
コミットログの確認
ブランチの作成
画面の左下のブランチ名（master）が表示されている個所をクリックし，新しいブランチを作成
マージ
まずはmasterに切り替え
Git Historyでマージ元となるnew-branchの右にあるアイコンをクリックしてMerge this commit into current branch
マージ後のブランチの削除
リモートリポジトリの作成
git remote add origin (remote URL)
origin：リモートリポジトリの識別子
リモートへのプッシュ
git push -u origin master
ログからのブランチの作成
競合、部分コミット
（フェッチ→）プル
gitignore
GitHub実践入門はP200から読む。 GitよりもGitHubの方がメインとなっていると思う。 ワークフローについて。
『データ指向アプリケーションデザイン ――信頼性、拡張性、保守性の高い分散システム設計の原理』Part 3 導出data
Part3 導出data
目的
- 複数の異なるdata systemを結合
→ 一貫したapplication archtectureにすることのproblemを検証
ⅲ-1 Systems of Recordと導出data
- dataを保存し処理するsystemの2分類
- Systems of Record (a.c.a. Source of truth)
- normalized(正規化)
- 導出data system
- cacheなど
- 非正規化 value, index, materialized viewも
- original sourceから再生成可能のもの
- 冗長．but, readのperformanceのために必要
- denormalized
- Systems of Record (a.c.a. Source of truth)
- system内のdata flowの明確のために，区別はvery beneficial
- systemの各部のI/Oと依存関係の明確化
- dbは単なるtool
- → application内でどう使うかで分類が決まる
- dataを保存し処理するsystemの2分類
Ch10 batch processing
目的
- Part 1, 2で，request, query, responce, resultを議論
- 多くのrecent data systemのpreposition
- online system: responce timeが重要
- Web, HTTP/REST baseのAPIで，request/responce styleがgeneral
- ↑→ ほかのapproachにもメリットあり
- 3つのsystem type
- Service(Online System)
- requestとresponce
- responce time， 可用性が重要
- batch processing System(Offline System)
- 大量の入力dataをprocessingするJobをregular実行
- throughput で測る
- stream processing system(near line processing, 準real time system)
- 入力から出力生成．online processingとbatch processingの中間
- not request/responce
- eventはすぐprocessing ←→ batch jobは固定集合に実行
- → latency低い than batch system
- Service(Online System)
- trusted scalable(maintainable) systemのために，batch processingは重要なbuilding block
10.1 Unixのtoolによるbatch processing
目的
- simpleなe.g.
- request, processingのたびにlog fileに行を追記
対応
- !1 simple logのanalyze
- !2 Unixの哲学
- 「programをpipeでつなぐ」
- automation, rapid prototyping, incremental iteration, experiment(実験)への親和性, 大規模projectの管理可能なchunkへの分割
- !!1 一様なinterface
- 全programが同じinterface
- @Unix: file(file descripter) ← orderを持つbyteの並び
- ASCII textのinterfaceはnot beautiful
- e.g. △{print $7}より，〇{print $request-url}
- 結合性が重要
- 全programが同じinterface
- !!2 logicと結線の分離
- stdin, stdout
- 疎結合(loose coupling), late binding, inversion of controlの1形態
- → 入出力の結線をlogicから分離
- → 小さいtoolから大きいsystemを合成
- → 入出力の結線をlogicから分離
- !!3 transparencyとexperiment
10.2 MapReduceとdistributed file system
目的
- MapReduceとUnix toolsは似ている
- MapReduceのJobは，distributed file system上のfileをread/write
- Hadoopでは，HDFS(Hadoop Distributed File System)という，Google File System(GFS)のOpenSourceの再実装
- GlusterFSや，Quantcast File System(QFS)もある
- Amazon S3， Azure Blob Storage, Open Stack SwiftなどのObject Storage Serviceも似ている
- HDFSは，shared nothingの原則に基づく
- ↑→ NAS(Network Attach Storage), SAN(Storage Area Network)のarchtectureでの共有discのapproachと対照的
- customのhardwareや，fiber channelなどの特殊なnetwork infra必要
- ↑→ 特別なhardware不要．datacenter内のnetworkでつながったcomputer群があればOK
- ↑→ NAS(Network Attach Storage), SAN(Storage Area Network)のarchtectureでの共有discのapproachと対照的
- HDFS: network serviceを公開
- name nodeという中央Serverが，file blockingのmachineへの保存状況を追跡
- → 全machineのdisc領域から，1つの巨大なfile systemを生成
- リードソロモンcodeのようなerasure codingで，完全なreplicationによりoverheadを抑える
対応
- !1 MapReduce Jobのexecution
- !2 Reduce側での結合とgroup化
- 結合: {foreign key, document reference, 辺}の両端のrecordにaccessしなければならないcodeで必要
- MapReduceのjobはfull table scan
- analytic queryでは〇
- especially, 複数マシンにわたってconcurr
- → dataset中の何らかの関連をすべて見出す
- analytic queryでは〇
- !!1 事例: userのactivity analyze
- 図10-2: batch jobでの結合の例
- MapReduceを使って関連するrecordsをすべて同じところにまとめ，effectiveにprocessing
- !!2 sortmerge 結合
- 図10-3: flow
- secondary sort: reducer内でさらにsort
- mapperの出力がkeyでsort → reducerがmerge
- 図10-3: flow
- !!3 関連するdataを同じ場所にまとめる
- !!4 GROUP BY
- e.g. sessionization
- mapperがgroup化のためのkeyを使う
- !!5 skewのprocessing
- linchpin object: 不均衡なactive db record
- a.c.a. hot key
- → skew(hot spot)が生じる
- → 対応
- e.g. Pigでのskewed join method
- hot keyを扱うprocessを複数reducerに分散
- → concurr度up
- crunchでのsharded joinも同様だが，explicitなhot keyの指定必要
- hotspotの緩和のためのrandom化と似ている
- Hiveでは別の方法
- map-side join
- hot keyを扱うprocessを複数reducerに分散
- hot keyでのgroup化では，2つのstageに分割
- e.g. Pigでのskewed join method
- linchpin object: 不均衡なactive db record
- !3 map-side join
- joinを高速化
- reducerなし．sortなし
- !!1 broadcast hash join
- 小さい入力が大きな入力のすべてのpartitionにbroadcast
- hash: 小さい入力をinmemory hashtableにloadする
- local disc上のread onlyのindexにstoreも〇
- Pig, Hive, Cascading, Crunchで使える
- Impaleなどの，DWH query engineでも使われている
- !!2 partition化 hash join
- joinのinputがどちらも同じkey, 同じhash functionに基づいて同じ数のpartitionを持っているときのみ使える
- Hiveでのbucketed map join
- e.g. 先行するMapReduce jobでinput data generationのcase
- joinのinputがどちらも同じkey, 同じhash functionに基づいて同じ数のpartitionを持っているときのみ使える
- !!3 map-side merge join
- partition化を同じkeyでsortedのcase
- 先行するManagement jobがproceededのcase
- !!4 map側でのjoinを行うMapReduceのworkflow
- map-side joinでは，distributed file system中のdatasetのphysical なlayoutが重要 ← preposition 名詞のため
- → Hadoopのecosystem中では，これらのmetadataをHCatalogやHiveのmetastoreで管理
- !4 batch workflowのoutput
- batch processingは，OLTPでもOLAPでもない
- !!1 search indexの構築
- 固定されたdocument群への全文検索には，index作成のためのbatch processingはeffective
- !!2 batch processingのoutputとしてのK=V store
- search index以外のe.g. of batch processing workflowのoutput
- classifyerのようなmachine learning systemや，reccommendation systemの構築
- batch processingからのoutputのapplicationが使うＤＢへの適用方法
- 全く新しいDBをbatch job内部で作成
- Voldemort, Terrapin, ElephantDB, Hoosebulk loadingなどでsupported
- → distributed file system中のjobのoutput directoryにwrite out
- → read onlyのqueryをprocessするServiceへbulk load 〇
- こういったDB fileの構築: MapReduceの良い利用法
- WAL(Write-Ahead Log)も不要
- 全く新しいDBをbatch job内部で作成
- search index以外のe.g. of batch processing workflowのoutput
- !!3batch processingのoutputでの哲学
- Unixの哲学と同じ
- inputはimmuteで副作用を避け，batch jobのperformance up + maintenanceはるかに楽
- human fault toleranceあり ← ↓rollback 容易
- minimizing irreversibility (回復不能性の最小化)
- automatic retryが安全
- 同じfile集合を多様なjobのinputに使える
- logicを結線(in/out directory)からisolation
- 関心の分離. codeのreuse〇
- inputはimmuteで副作用を避け，batch jobのperformance up + maintenanceはるかに楽
- Unixとは異なる点
- Hadoopでは，よりstructuredなfile formatを使い，parse processingを省略可能
- ↑ effectiveなschema baseのencodingを提供
- schemaを進化させられる → Avro, Parquetがよく使われる
- Unixの哲学と同じ
- !5 Hadoopとdistributed datacenterの比較
- Hadoop: Unixのdistributed versionのよう
- !!1 storageの多様性
- Hadoopは，無差別にdataをHDFSに書き込み，後からprocessingの方法を見つければよいという可能性を打ち出した
- ↑→ MPP DBでは，db originalのstorage formatにインポートするため，あらかじめdataとquery patternをmodeling要
- DWHと似た考え．: data を生のままcollect
- 全く異なるdatasetのcollection speed高い: Datalake, enterprise data hub
- DWHと似た考え．: data を生のままcollect
- dataの解釈は，consumerのproblem ← schema on read
- → 任意の変換可能
- → sushi principle: dataは生が〇
- → Hadoopは，ETL(Extract-Transform-Load) processingの実装に使われてきた
- ↑ distributed file systemが任意のformatでのdata encodingをサポート．
- → 任意の変換可能
- !!2 processing modelの多様性
- !!3 often faultに備えた設計
- MapReduce とMPP dbの違い
10.3 MapReduceを超えて
目的
- batch processingのMapReduce以外の選択肢を見る
対応
- !1 中間的なstateの実体化
- 実体化 ←→ streaming(: unixのpipe)
- 実体化のproblem(MapReduceのproblem)
- タスクの待ち
- mapperは冗長
- temporary dataのreplicationは無駄
- !!1 data flow engine
- MapReduceのproblemに対応
- e.g. Spark, Tez, Flink
- workflow全体を1つのjobとして扱う
- 複数stageのdata flowをexplicitにmodel化: data flow engine
- 入力をpartitioning → taskをconcurr
- mapやreduceはなく，operatorを使う
- operatorの接続のchoicesとmerit
- map, reduceと同じ処理のcodeは，修正鳴くほかのengineでも使える
- MapReduceのproblemに対応
- !!2 fault tolerance
- !!3 実体化についての議論
- !2 graphとiterativeなprocessing
- graph全体へのoffline processingやanalyze
- → recommendation engineやranking systemといったmachinelearningのapplicationで生じる
- e.g. PageRank
- data flow wngは，directed acyclic graph(DAG)内にoperatorを置くが，operator間のdataglowのみgraph化していて，data事態はrelational styleのtaple
- 図2-6: transitive slosure(推移的閉包)のようなalgorithm
- → iterativeなstyleで実装
- Managementで実装はnot effective
- !!1 Pregelのprocessing model
- batch processing graphのoptimise: 演算processingのbulk sync parallel (BSP) modelが広がる
- ある頂点がほかの頂点にmessageを送信
- 頂点が自分のstateをiteration内でmemoryに記憶する
- → functionは，新しいmessageのみproceedでOK
- actor modelとの違い 0 頂点のstateと頂点間のmessageにfault-toleranceと永続性あり
- !!2 fault-tolerance
- Pregel jobのperformance高い: messageをbatch化して通信待ち時間削減
- → iteration間でのみ末
- 透過的なfaultからのrecovery
- ↑ iterationの終わりに全頂点のstateのcheckpoint processing ← regularly
- Pregel jobのperformance高い: messageをbatch化して通信待ち時間削減
- !!3 concurrency
- Pregelのprogramming model: 1度に1つの頂点のみ扱う
- graphのalgorithm: 大量マシン間の通信のoverheadあり → distributed graph algorithmのspeed 大きく減少
- → 単一machine上のalgorithm > distributed batch processing @ performance
- GraphChiなどのframeworkを使う単一machineでのprocessingが〇
- Graph algorithmのconcurrencyは研究中
- !3 高レベルAPIと様々なlanguages
- programming modelの改善， processing effectivityの改善
- これらの技術が扱えるproblem領域の拡大に目が向く
- Hive, Pig, Cascading, Crunchといった高レベル languageやAPIの登場
- Tezにより移行〇
- SparkSQL, Flink ← Flume Javaから
- これらのdataflow APIは，relational styleのbuilding blockで演算処理を表現
- code少ない + interactive
- !!1 宣言的なquery languageへの移行
- relationalなoperatorの指定 → frameworkがjoinのinputの性質を分析
- → タスクにとっていずれのjoin algorithmが良いかautomatic judge〇
- e.g. Hive, Spark, Flink
- ↑→ joinを宣言的に指定 → query optimiserがjudge
- ほかのSQLの完全な宣言的query modelとの違い
- relationalなoperatorの指定 → frameworkがjoinのinputの性質を分析
- !!2 various領域への特化
- e.g. 統計，数値処理のalgorithm for classificationやrecommendation systemといったmachine learningのapplication
- reuse〇な実装の出現
- e.g. Mahout, MADlib
- e.g. 空間algorithm
- e.g. k近傍鳳(k-nearest neighbors), 近似(approximate) search for genome analyze
- → algorithmのdistributed executionのために，batch processing engineが使われる領域は広がっている
- batch processing systemの機能や高レベルの宣言的operatorが増え，MPPdb がprogrammingし易く柔軟になることで，似てきている．
- どちらも単なるdataを保存し処理するsystemに過ぎない
- e.g. 統計，数値処理のalgorithm for classificationやrecommendation systemといったmachine learningのapplication
- programming modelの改善， processing effectivityの改善
まとめ
- batch processing について
- distributed batch processing frameworkで解決する問題
- partitioning
- 関連するdataをすべて同じ場所にまとめる
- fault tolerance
- 中間stateの扱い．影響
- partitioning
- MapReduceでのjoinのalgorithmは，MPP DBやdata flow engineの内部でも使われている．
- sortmerge join
- broadcast hash join
- partitionかhash join
- distributed batch processing engine(framework): 制限あるprogramming model
- → 副作用minimum
- → distributed systemのproblemを隠蔽〇
- → retry安全
- frameworkにより，fault-tolerance〇
- 完治不要．強力なtrustnessのsemantics
- especially important: inputdataを変更しない
- input dataは有限．既知のサイズ． → 官僚のjudge可能
- stream processing
- 非限定stream
- stream processing
- input dataは有限．既知のサイズ． → 官僚のjudge可能
Ch11 Stream processing
目的
- data managementの仕組みとして，event streamを見る
- incrementalにprocessされるdata
11.1 event streamの転送
目的
- event: recordを指す
- 自己完結したimmutableなobject
- producer(a.c.a. publisher)が1回生成し，複数consumer(subscriber)が扱う
- file名ではなく，topic, streamとしてgroup化
- fileかdbがあれば，producerやconsumerとconnect可能
- pollingではなくpublishが〇
- これまでのdbにない機能のためのtoolがdeveloped
- triggerなどは限定的
- これまでのdbにない機能のためのtoolがdeveloped
対応
- !1 messaging system
- eventの通知に使う
- UnixのpipeやTCP connectionにより拡張
- → ・複数producerが同じtopicにmessage 送信
- ・複数consumerが同じtopicにmessage 受信 → publish/subscribe model
- 送信 > 受信のprocessing @speedのcase
- messaging systemがdrop/queueでのbuffering/ back pressure(flow control)
- node crashやofflineのcase
- messaging lost okか，applicationに依存
- batch processing systemでは，強いtrust〇
- → streamingでも提供する
- !!1 producerからconsumerへのdirect messaging
- latencyの低さがimportantな金融 → UDP + applicationでのrecovery
- ZeroMQやnano messageなど，brokerなしのmessaging library: TCP/IP multicast上でproducer/consumer messagingを実装
- StatsDやBrubeck: UDP messaging
- consumerがnetwork上にservice公開 → producerはHTTPやRPC requestを発行して，messageをpush
- webhooksのbackground
- これらのdirect messaging systemは，message lostの可能性を, applicationのcodeが関知する必要ある
- fault-toleranceは限定的
- !!2 message broker(a.c.a. message queue)
- a type of DB
- Server, producerやconsumerがClient
- → clientの出入りに耐えられる．永続性の問題も隠蔽〇
- consumerはasync by queuing
- !!3 message broker とdbのcompare
- consumerへの配信官僚 → message(data)をdelete
- working set 小さい， queue短いという前提
- → 大量messageのbufferingは全体のthroughput down
- secondary indexなどではなく，pattern matchのtopic 部分集合を取得
- dataに変化があれば，clientに通知 ←→ snapshot
- ここまでは旧来のmessage broker. JMS, AMQPといったstandard
- e.g. RabbitMQ, ActiveMQ, HornetQ, Qpid, TIBCO Enterprise, IBMMQ, Azure Services Bus, Google Cloud Pub/Sub, Message Service
- !!4 複数consumer
- 図11-1: load balancingとfanout: messagingの2つのpattern
- load balancing
- どれか1つのconsumerに配信
- a.c.a. shared subscription
- どれか1つのconsumerに配信
- fanout
- 全consumerにdeliver．独立した複数consumer
- 2 patternの組み合わせも〇
- !!5 承認と再deliver
- 承認(acknowledgement) → messageのdelete @ broker
- 図11-2: order変化 @ load balancing
- → consumerごとにqueuingが必要なpattern
- !2 partition化されたlog
- dbでの複数のあるstorageというapproachと，messagingでの低latencyのnotify機能のcombine
- → log base message broker
- !!1 message storageへのlogの利用
- !!2 従来のmessagingとlogの比較
- log baseのapproach → fanout型のmessaging support easy〇
- load balancingは欠点アリ
- → message processing負担大きいことあり， message単位でparallel processing, messageのorder not importantなら
- → JMS/AMQP styleのmessage brokerが望ましい
- ↑→ message processingのthroughput高い必要がある，1つのmessageは高速， orderがimportantなら，log base applicationが◎
- → JMS/AMQP styleのmessage brokerが望ましい
- log baseのapproach → fanout型のmessaging support easy〇
- !!3 consumerのoffset
- brokerはacknowledgementの追跡不要: 管理のoverhead少ない
- → batchやpipelineといった手法を取るchanceが生まれる → throughput高い @ log base system
- 5.1.2のlog sequence numberと似ている
- brokerはacknowledgementの追跡不要: 管理のoverhead少ない
- !!4 disc領域の利用
- 循環buffer, ring bufferingを使う
- throughputはhistoryの量による
- !!5 producerにconsumerが追い付かないcase
- consumerのdelayが大きくなったら警告
- 各consumerは独立
- !!6 古いmessageのreplay
- AMQPやJMS styleのmessage brokerは破壊的
- ↑→ log baseのmessage brokerはread only
- → 繰り返し可能
- → maintenance〇． 組織内のdata flowとの組み合わせのためのtoolとして log baseのmessagingは〇
- → 繰り返し可能
11.2 dbとstream
目的
- DBとstreamのつながりはdisc上のlogのphysical storageをこえて，本質的なもの
- e.g. replication log
- e.g. state machine replication(9.3.3)
- heterogeneousなdata systemのproblemを，streamの着想でresolveする
- e.g. replication log
対応
- !1 systemのsyncの保持
- 複雑なapplicationの要求は，異なる技術の組み合わせで解決
- それぞれの目的にoptimiseした形式で各々がcopyをもつ
- → syncが必要
- e.g. ETL process @DWH(3.2.1): batch processing
- → syncが必要
- dual writesの重大なproblem ← dual writesは，dumpが低速なcaseの代替案
- 図11-4: race condition
- version vector(5.4.4)などが必要
- fault-toleranceのproblem
- 2 system間不整合
- 図11-4: race condition
- それぞれの目的にoptimiseした形式で各々がcopyをもつ
- 複雑なapplicationの要求は，異なる技術の組み合わせで解決
- !2 変更dataのcapture(Change Data Capture, CDC)
- 図11-5: flow. 変更のstreamをproducerとconsumerで扱う
- producerは記録するsystemのdb, consumerはsearch indexやDWH
- !!1 CDCのimplement
- logのconsumerは導出data system
- ↑ CDCはconsumerが正確なcopyとなることを保証
- dbのtriggerが使える
- ただし，triggerは壊れやすく，performanceでの大きなoverhead
- implementのe.g. → p.498
- CDCはasync
- !!2 初期のsnapshot
- dbのsnapshotと変更ログの対応必要
- !!3 logのcompaction
- snapshotの代替
- log baseのmessage brokerやCDCでも〇
- e.g. Apache Kafka
- message brokerを一過的messagingのみならず，永続性あるstorageとしても使える
- !!4 change streamのためのAPI support
- change stream: first classのinterfaceとしてDBでsupport
- e.g. RethinkDB, Firebase, CouchDB, Meteor, VoltDB, Kafka Connect
- change stream: first classのinterfaceとしてDBでsupport
- 図11-5: flow. 変更のstreamをproducerとconsumerで扱う
- !3 event sourcing
- event sourcingとCDCの違い
- (event streamingはDDDのcommunityでdeveloped)
- event sourcingでは，event storeには追記のみ
- ↑→ CDCはapplicationのdbをmutableに使う
- eventは低レベルの変化でなく，application levelで起きたことを反映
- event sourcingは, applicationの進化に〇. bugからguard
- event sourcingはchronicle data modelとsimilar. star schemaのevent logとfact tableにも掃除
- event sourcingのstreaming systemとの関連を見る
- !!1 event logからのnow のstateの導出
- 決定的なlogでlog → state
- logのstoreのproblem
- 決定的なlogでlog → state
- !!2 commandとevent
- commandがvalidated → event
- event: fact. logのimmutableな一部
- → commandのvalidationはsync 必要
- serializableなtransactionの利用
- or, eventの分割
- → commandのvalidationはsync 必要
- event: fact. logのimmutableな一部
- commandがvalidated → event
- event sourcingとCDCの違い
- !4 state, stream, immutability
- immutabilityの原則: event sourcingやCDCの強さ
- dbはapplicationの現在のstateをstore
- readにoptimise
- stateの変化とimmutabilityとの折り合い
- stateの変化: eventのresult
- mutableなstateとimmutableなeventからなる追記飲みのchange log
- log が矛盾しないことがimportant
- → change log: stateの進化の表現
- 図11-6: applicationのstateとevent streamのrelation
- log: fact
- db: logのcache
- !!1 immutableなeventのmerit
- 監査制，problemのrecovery，分析
- !!2 event log からの複数viewの導出
- mutableなstateをimmutableなevent log からisolation
- event logからdbへのexplicitなconvert step
- → 時間とともにapplicationの進化〇．新旧共存
- dataのwrite formatとread formatのisolation → 大きな柔軟性
- ⇔ CQRS(Command Query Responsibility Segregation
- → 正規化，非正規化はほぼ無意味
- ↑ convert processがreadにoptimiseされたviewとevent logと整合性を保てば，viewでdataを非正規化〇
- !!3 concurrency control
- event sourcingとCDCのasyncの欠点
- → 5.2.1(p.173)で解決
- or → stateをevent logから生成
- event sourcingでは，user actionの自己完結した記述: event
- 同じpartitionなら，single threadで処理〇
- !!4 immutabilityのbound
- Datomicのexcision(切除)や，Fossilのshunning(回避)が必要なcaseあり．
11.3 streamのprocessing
目的
- streamをprocessして，new導出streamをgenerate
- operator, job
- streamは終わりなし
- → sort merge join×．fault toleranceの仕組み別に必要． ← crash時に初めからは×
対応
- !1 stream processingの利用．
- stream processing は，monitorのために使われてきた
- alertのnotify
- 洗練されたpattern matchingとの関連付け必要
- ほかの使い方の出現
- !!1 複合event processing(Complex Event Processing, CEP)
- !!2 stream analyze
- !!3 materialized viewの管理
- applicationのstateもmaterialized viewの1つ
- ただし，全event必要．log compactionも必要
- applicationのstateもmaterialized viewの1つ
- !!4 streamでのsearch
- streamのsearch: queryをstore → CEPのようにdocumentがqueryを通る
- queryのindexづけ
- !!5 message passingとRPC
- RPC的systemとstream processing間は重なる領域もあるが，そもそもは異なる
- stream processing は，monitorのために使われてきた
- !2 timeに対する考察
- localのsystem clockでwindowを決定
- simple
- but, eventのgenerationとprocessingの間が小さいときに限る
- !!1 event timeとprocessing time
- 図11-7: processing timeでwondow processしたときのproblem
- !!2 preparedのcheck
- はぐれ(straggler) event のproblem
- 虫 or correction
- はぐれ(straggler) event のproblem
- !!3 結局，どのclock?
- 3つのtimestampをlogging
- eventが実際に起きたtimeの推定必要
- !!4 windowのtype
- Tumbling window
- 固定長，全eventがいずれか1つのwindowにのみbelong
- Hopping window
- smoothingのためにwindow同士が重なる
- sliding window
- ある期間が動く．長さのみ決まっている
- session window
- 期間非固定
- 時間的近さ
- web siteのanalyzeに使う
- Tumbling window
- localのsystem clockでwindowを決定
- !3 stream のjoin
- stream processing: data pipelineを限度ないdatasetのincrementalなprocessingに一般化したもの
- → joinが同じく必要
- !!1 stream-stream join(window join)
- stream processorがstateを管理する必要
- !!2 stream-table join(streamのenrich)
- stream processorがもつdbのlocal copyの最新化が必要
- → CDCでresolve〇
- stream-stream joinとの違い: stream-table joinでは，tableのchange log streamに対して，新versionのrecordで旧recordをoverwrite. with 「時間の始まり」までのwindow
- stream processorがもつdbのlocal copyの最新化が必要
- !!3 table-table join(materialized viewのmaintenance)
- cacheの使用が例
- !!4 joinのtimeに対する依存
- いずれのjoinもstream processorがjoinへのinputの1つに基づくstateを管理
- → stateを管理するeventのorderがimportant
- Slownly Changing Dimension(SCD)のproblem
- → joinするrecordのversionごとにidを使う
- joinはdecisive, but logのcompaction不可能
- → joinするrecordのversionごとにidを使う
- stream processing: data pipelineを限度ないdatasetのincrementalなprocessingに一般化したもの
- !4 fault-tolerance
- exactly-once semantics(事実上effectively-onceがより正しい) @batch job
- streamはより複雑な対処必要
- !!1 micro batch processingとcheckponit processing
- !!2 atomicなcommit再び
- !!3 冪等性(idempotence)
- e.g. Kafka, StormのTrident
- いくつかの前提必要
- わずかなoverheadでexactly-once semanticsをrealized〇
- !!4 fault後のstateのrebuild
- stateをstream processorのlocalにstore, and regularly replication
- e.g. FlumeJava, Samza, Kafka Streams, VoltDB
- infraのperformance特性に依存
- exactly-once semantics(事実上effectively-onceがより正しい) @batch job
まとめ
- event streamについての目的とprocessing方法
- unboarder streamをprocessing ←→ batch processing
- message brokerとevent logの使用
- AMQP/JMS styleのmessage broker
- log baseのmessage broker
- Streamとしての表現〇のe.g.
- change log, CDC, event sourcing, log compaction
- dbをstreamとして表現
- index, cache, analysis systemのような導出data system
- streamとしてstateをmanagement, messageをreplayする機能
- stream のjoinやvarious stream processingのframeworkのfault-tolerance実現のための手法の基礎
- stream processingの目的
- event pathのsearch(CEP), Window集計の演算(Stream analysis), materialized view
- stream processorのtimeの扱い
- stream processingでのjoin
- stream-stream join
- stream-table join
- table-table join
- stream processorでのfault-toleranceとexactly-once semanticsの実現
Ch12 data systemの将来
目的
- Ch11まで: 現在の姿．Ch12: あるべき姿
- 本書の目標: trusted, scalable, maintainableなapplicationやsystemの構築方法を見る
- Ch12の目標: 頑健性，正確性，進化性，人類への貢献において，よりよいapplicationを設計する方法の発見
12.1 data のintegration
目的
- software productsと，適した環境の対応付けを見出す
- 複数softwareのcombine
対応
- !1 dataの導出による特化したtooldのcombination
- data joinの必要性は，組織全体のdata flowを考える必要あり
- !!1 data flowについての考慮
- 入出力の明示
- 全てのwriteのorderを決定する単一system
- 全order決定の原理がより重要．than which CDC or event sourcing log
- 導出data systemをevent logにもとづいてupdate: 決定的で冪等〇
- faultからのrecovery容易
- !!2 導出dataとdistributed transaction
- various data system間で一貫性を保つための古典的approach: distributed transaction
- distributed transactionと導出data systemのcost comparing
- lockかlogか
- atomic commit or 決定的retryと冪等性
- transaction: linearizabilityを提供 ←→ 導出data system: timingの保証なし
- ただし，transactionのコスト大きい
- XAのfault-toleranceとperformance特性は貧弱
- → distributed transactionの有用性は限定的
- XAのfault-toleranceとperformance特性は貧弱
- various data systemのjoinは，導出data system(log based)が〇
- !!3 全orderのboarder
- 小さなsystemのみ，全orderのevent log 〇
- 全order broadcast(consentと等価)は，orderingを単一のcodeで行う
- 複数nodesでのconsent algorithmのdesignは未解決
- !!4 因果律の把握のためのeventのordering
- simpleなanswerなし
- logical timestamp
- systemのstateをlogにwrite
- conflict resolveのalgorithm
- simpleなanswerなし
- !2 batch processingとstream processing
- data joinの目標: dataを適切なところに適切なformatでおく
- これを達成のためのtool: batch/stream processor
- extract datasetを出力
- これを達成のためのtool: batch/stream processor
- Sparkはstreamをmicrobatchに分割して，batch processing engine上でstream processing
- Apache Flinkは，batch processingをstream processing engine上でexecution
- → 違いがぼやけてきている
- !!1 extracted stateの管理
- batch processing: function型programmingと同じにおい
- stream processingは，operatorがfault-tolerantな管理されたstateを扱う
- I/Oがdefinedな決定的functionの原則
- fault-tolerant〇
- 組織内のdata flowの考慮をsimplize〇
- search index, statistics model, cacheなど，extracted data systemを考えるときに考えること
- dataset extractionのpipeline, function型application codeを使ったsystemからのstateの変更のpush, extract systemへの変更の適用
- asyncな管理 → fault-tolerance〇，trusted, scalable
- !!2 applicationの進化に伴うdataのreprocessing
- reprocessing: datasetを全く異なるmodelにrebuild〇，新しい要求への対応〇
- 比喩: dual gage
- 段階的進化〇 → systemの改善speed up
- !!3 lambda archtecture
- batch processingとstream processingのcombine
- 核の着想: input data はevent sourcingのようにimmutableなeventを常に成長し続けるdatasystemに追加することで記録すべき
- Hadoop MapReduceのようなbatch processing systemと，Stormのようなstream processing systemという2つの異なるシステムをconcurr〇
- eventからは，readにoptimiseされたviewをextract
- batch,とstreamのいいとこどり，but 現実的なproblemあり
- batch/stream processingともに，logicのmaintenance必要
- stream pipelineとbatch pipelineの各出力のマージ難しい
- batch layerが複雑化
- !!4 batch processingとstream processingの統合
- data joinの目標: dataを適切なところに適切なformatでおく
12.2 databaseをときほぐす
目的
- db Hadoop OSはいずれもinfo management system
- Unix: especially 低レベルなhardwareのabstraction
- ≠ relational db: disc上のdata structure, concurrency, crashからのrecoveryなどの複雑さを隠蔽する，高レベルのabstraction
- 両者の良い部分をcombineする: 目標
対応
- !1 data storage technologyのcombination
- dbの機能，動作
- secondary index, materialized viwe, replication log, 全文検索index
- !!1 indexのgeneration
- 既存のdataに対する新しいviewとしてindexをextract
- !!2 すべてにかんするmeta db
- 組織全体にわたるdata flow: 1つの巨大なdb
- batch stream, ETL のprocess
- federated db: readのintegration(a.c.a. polystore)
- 統一されたquery interfaceの提供
- e.g. PostgreSQLのforeign data wrapper
- unbundled db: writeの結合
- 機能の解体(unbundle)
- 組織全体にわたるdata flow: 1つの巨大なdb
- !!3 processingのunbundle
- 複数system間のwriteの動機は要考慮．technology的にdifficult
- 冪等なwriteのasync event log >>> distributed transaction
- はるかに頑健で実践的
- transaction protocolがnot standarizedで統合とても難しい
- log baseの結合: 疎結合なcomponentsにできる〇
- @system level, @human level共に
- !!4 unbundled systemとjoined system
- 解体と合成が必要なのは，すべてのrequireを満たす単一のsoftwareがないときのみ
- !!5 欠けているものは何か?
- Unixのshellのようなものがない
- update cacheの事前calculation
- differential data flowが研究中
- dbの機能，動作
- !2 data flow 中心のapplication design
- database insideout approachというdesign patternの中身
- O2やJuttleなどのdata flow language
- FRP(Elmなど)
- BloomのようなLogical Programming Language
- Unbundlingは，Jey Krepsが提唱
- !!1 extract functionとしてのapplication code
- custom codeは多くのdbで苦労を伴う
- !!2 application codeとstateのisolation
- dbはapplication developmentのrequireを満たさない
- systemの一部として永続性あるdata storageに特化した部分を持ち，ほかはapplication codeの実行に特化が〇
- web applicationは，stateをもたないserviceとしてdeploy
- → stateはdb
- → stateのないapplication logicをdb(state management)からisolation
- applicationからはsubscribeがdifficult. (e.g. observer pattern)
- dbでもpolling必要
- !!3 data flow: stateの変化とapplicationのcodeとの相互作用
- 1980's のtaple 空間 model: stateの変化の監視と藩王のprocess
- dbのunbundle
- e.g. cache, 全文検索index, machinelearning, analysis system
- extracted dataの管理は，async jobのexecutionとはdifferent
- stateの変更のorderがimportant
- fault-toleranceがimportant
- → stream processorで実現可能
- applicationのcodeはstreamのoperatorとして動く
- stream processorを，data flow周りに大規模systemをつくるために合成〇 ←→ dbでは不可能． about 任意のcode execution
- !!4 stream processorとservice
- application development style: serviceの集合に機能を分割
- → 疎結合で組織的scalability〇
- streamのoperatorを合成は，同じ特徴あり〇
- ただし，layerのcommunicationの仕組みは大きく異なる: 1方向のasync message stream
- fault-tolerance + performance 高い〇
- RPCの代わりに，stream joinが◎
- ただし，いずれにせよ時間への依存性の対応が必要
- RPCの代わりに，stream joinが◎
- application development style: serviceの集合に機能を分割
- database insideout approachというdesign patternの中身
- !3 extracted stateの監視
- write path: extracted datasetを最新のstateに保つprocess
- e.g. 図12-1 ← 先行evaluation
- 後にread pathがくる ← 遅延evaluation
- extracted dataset: write/read pathの接点
- !!1 materialized viewとcache
- 全文検索indexのe.g.
- 頻出queryの有限集合にのみ，事前calculation: cache, materialized view
- → cache, materialized, indexは,extracted datasetの位置(path間のboarder)をずらしている
- 全文検索indexのe.g.
- !!2 statefulでoffline動作できるclient
- clientがstateを持つapplicationの出現
- offline firstのapplication
- device上のstate: server上のstateのcache
- offline firstのapplication
- clientがstateを持つapplicationの出現
- !!3 clientへのstateの変化のpush
- !!4 e2eのevent stream
- stateを持つclientやUIをdevelopするためのtools
- e.g. Elm Language, FacebookのReact toold, Reduxなど
- 内部的なclientのstateをmanagement, with event stream の subscribe
- instant messagingやonline gameなどで，このような「realtime」archtectureを使っているが，ほかのapplicationにも使える
- → request/responceのinteractionではなく，data flowのpublish/subscribeに移行必要
- → 反応性の良いUIとoffline supportの向上〇
- stateを持つclientやUIをdevelopするためのtools
- !!5 readもevent
- requestのprocessingと，joinは本質的に似ている
- userのactionまでのreadのrebuild可能〇
- → 因果関係の追跡〇
- but, storageとI/O cost増
- → 因果関係の追跡〇
- !!6 複数 partitionにわたるdataのprocessing
- readのevent化は，複雑なqueryのdistributed executionの可能性になる
- e.g. Stormのdistributed RPC機能
- e.g. twitterであるURLを見た人数の計算，不正detection
- e.g. Stormのdistributed RPC機能
- MPP dbでのinner query execution graphも似た特徴あり
- queryをstreamとして扱う: 大規模applicationの実装の選択肢の1つ
- readのevent化は，複雑なqueryのdistributed executionの可能性になる
- write path: extracted datasetを最新のstateに保つprocess
12.3 正確性を求めて
目的
- trustedで正確なapplication構築
- consistencyのdefineは不明瞭
- transactionは最後の手段ではない
- applicationのcodeがdbの機能を正しく使う必要あり
- weak isolation levelやquorumなど，間違い起き易い
対応
- !1 dbのe2e論
- applicationのbugのcase
- → immutableが〇
- !!1 exactly-once
- 冪等〇
- with metadata, fencing
- 冪等〇
- !!2 duplicationの抑制
- 2PCはnot enough
- !!3 操作id
- networkのcommunicationを複数hop 経由する操作を冪等にする
- ↑requestのe2eのflowを考える必要
- not serializableなisolation levelでは，unique(→ 7.2.4, p.266)性checkに難あり
- event logとしてのrequest table → 例12-2
- networkのcommunicationを複数hop 経由する操作を冪等にする
- !!4 e2e論
- duplicationの抑制は，communication system自体の機能では不可能
- → transaction IDが，end userのclientからdbまで渡される必要
- e2eはnetworkでのdataの整合性にも必要
- encryption
- 低レベルの機能の上に成り立つ
- duplicationの抑制は，communication system自体の機能では不可能
- !!5 data systemへのe2eのapply
- 高levelのabstractionにenoughな方法まだない
- transactionもnot enough
- 高levelのabstractionにenoughな方法まだない
- applicationのbugのcase
- !2 制約の強制
- unique性などの制約を守らせる
- !!1 unique 制約にはconsent必要
- unique必要なvalueをpartitionに分ける
- async のmulti master replicationは例外
- !!2 log baseのmessagingでのuniqueness
- log: total order broadcast = consentと等価
- partition数を増でscale〇
- いずれの制約にもsequencialにprocess可能
- basic 原則: conflictable writeは同じpartitionに送られ，sequencialにproceedされる
- conflictのdefineはapplicationに依存しうるが，stream processorは任意のlogicを利用可能
- log: total order broadcast = consentと等価
- !!3 multi partitionのrequest processing
- partitioningされたlogを使い，atomicなcommitなしで同等のaccuracy〇
- 単一objectへのwriteは，ほぼすべてのdata systemでatomic
- → 複数partitionにまたがるatomic commit不要
- 「複数partitionにわたるtransactionを，partitioningの方法が異なる2stageに分割し，e2eのrequest idを用いる」ことで，faultがあっても，atomicなcommit protocolを用いずに同じaccuracy達成〇 → p.563, 12.2.3.6と似る
- !3 timeliness(適時性), integrity(整合性)
- transactionのよい性質: linearizable
- 複数stageのstream processorではasyncだが，出力streamのmessageをclientがwait 可能
- → syncの通知 ← 待機の目的
- consistency(一貫性)の2つの要求
- timeliness
- userが，systemの最新のstateの観察を保証
- CAP定理: 強制約，read-after-write: 弱制約
- userが，systemの最新のstateの観察を保証
- timeliness
- integrity
- dataに矛盾や間違いがないこと
- especially 正しいextract data
- 明示的なcheckとrepair必要
- ACID transactionでは，consistencyはある種のapplication固有のintegrityの表現
- atomicityとeternityが整合性を保持するための重要なtools
- dataに矛盾や間違いがないこと
- timelinessの違反: 結果整合性
- integrityの違反: 恒久的なnot consistency
- importance: integrity >>>> timeliness
- !!1 data flow systemのaccuracy
- ACID transactionはtimeline(linearizability)とintegrity(atomicなcommit)を共に保証
- event baseのdata flow systemは，timelinessとintegrityをisolate
- streaming systemの中核はintegrity
- exactly-onceは，integrityのための仕組み
- atomic commit不要
- integrityのための複数仕組みのcombination
- writeを単一のmessageで表す
- 決定的なextract function(SPのようなもの)
- clientがgenerateしたrequest idを全levelで渡す
- → e2eのduplication抑制・冪等性
- messageをimmutableにし，extracted dataをあとからreprocessing可能
- → recovery easy
- !!2 制約のゆるやかな解釈
- unique制約の強制: consistency必要
- より弱いuniquenessでenoughなcase
- compensating(補正) transaction
- linearizability不要なcase
- 謝罪のコストはbusiness上のjudge
- 許容， → 弱い制約
- → integrityは必要，but timelinessは不要
- !!3 調整を回避するsystem(coordination-avoidance system)
- 2つの所見
- data flow system: extracted data でのintegrityの管理をatomicなcommit, linearizability, partition間syncなしに達成〇
- 弱制約でも，integrityが〇ならok
- → coordination不要
- → 高performance, fault-tolerance〇
- e.g. multi leader構成で複数datacenterにまたがり，region間でのsync replication可能
- → 高performance, fault-tolerance〇
- serializable transactionは一部の使用で有益
- 2つの所見
- !4 信頼しつつ検証も
- system modelでの仮定
- 現実における確率的problem
- e.g. rowhammer
- !!1 softwareのbugがあってもintegrityを保つ
- !!2 約束を盲信は×
- auditing(監査): dataのintegrity check必要
- 速いうちの検出が〇
- !!3 検証の文化
- systemの自己検証・自己監査必要
- 監査性のdesign必要
- ↑weak consistencyが普通になった
- !!4 監査性のためのdesign
- transactionは, transactionの意味・理由が不明
- ↑→ event based system: よりよい監査性
- userのinputは単一のimmutable event
- → stateの更新はeventからextracted
- extractは決定的で再現可能
- → stateの更新はeventからextracted
- data flowの明確化 → dataの系統(provenance)も明確化
- → integrityのcheckはるかにeasy
- event logはhashでevent storageのcheck〇
- extracted stateは，batchやstream processorのreprocessingでevent logからstate extract〇
- → integrityのcheckはるかにeasy
- userのinputは単一のimmutable event
- → data flowがdecisiveで十分にdefined
- → systemの行いの理由のためのdebugやtraceがeasy
- bug検出時の環境再現も〇
- !!5 e2e論再び
- dataのintegrity checkはregularに必要
- e2eでのcheckが〇 → 内部もimplicitにcheck〇
- systemの変更や新storage technologyのrisk減
- → applicationの進化〇
- systemの変更や新storage technologyのrisk減
- e2eでのcheckが〇 → 内部もimplicitにcheck〇
- dataのintegrity checkはregularに必要
- !!6 監査可能なdata systemのためのtools
- encryptionのtoolsで，hardware, softwareのproblemやcrackingへのtoleranceをもつようにsystemのintegrityを証明する方法あり
- e.g. Bitcoin, Ethereum, Ripple, Stellerのような暗号通貨, block chain, distributed台帳のtechnology
- ただし，Byzantine fault体制は△(or ×)
- このtechnologyはたいていMerkle treesに依存
- integrityのcheckや監査のalgorithmを使うsystemが，scalableでperformanceのpenalty少となるように研究必要
- encryptionのtoolsで，hardware, softwareのproblemやcrackingへのtoleranceをもつようにsystemのintegrityを証明する方法あり
12.4 正しいことを行う
目的
- すべてのsystemはある目的のために構築される
- → 目的をこえた影響もあり．これにも責任必要
- dataを，人間性とrespectをもって扱う
- 今日は，倫理的選択が一層含まれる
- → 目的をこえた影響もあり．これにも責任必要
対応
- !1 予測分析(predictive analytics)
- !!1 biasと差別
- algorithmのinputのbiasに気づけない
- machinelearningは，biasをmoneyロンダリング
- algorithmのinputのbiasに気づけない
- !!2 責任と説明責任
- dataに基づく意思決定の間違いを正す方法必要
- !!3 feedbackloop
- system thinkingでriskyなfeedbackloopを避ける
- !!1 biasと差別
- !2 privacyと追跡
まとめ
- applicationは目標を満たすため，複数のvarious softwareをcombine必要
- このdata integrationのproblemを，batch processingとevent streamingで解決
- index, materialized view, machinelearningのmodel, 統計summaryなどを管理〇
- asyncで疎結合〇
- → 頑健，fault-tolerant〇
- → applicationの進化〇
- ↑ dbをcomponentsにunbundle. → dataflow applicationを構築
- offlineでも動くinterface
- e2eの操作ID → 冪等
- asyncなevent processing
- 制約をasyncにcheck → 強いintegrityの保証を実装
- 多くのbusiness processにadapt
- 制約の対応(e.g. compensation)
- applicationをdataflowを中心において構成し，制約をasyncにcheck
- → ほとんどの調整回避〇
- → 地理的にdistributedなenvironmentで，faultを考えながらも，integrityを保ち，高performanceでsystemが動く
- 監査でdata integrity check
- data指向applicationの倫理的問題
『データ指向アプリケーションデザイン ――信頼性、拡張性、保守性の高い分散システム設計の原理』Part 2 分散データ
Part 2 distributed data
目的
- Part 1: 単一のマシンにデータを保存．
- Part 2: 複数マシンにデータを保存．
- 複数マシン保存の目的
- scalability: 負荷分散
- 耐障害性，高可用性
- latency
- !1 高負荷へのscaling
- simple: scale up(vertical)
- 共有memory archtecture
- problem: cost upが性能upに対して比例以上．
- 共有disc archtecture
- problem: 競合．ロックのoverheadでscalabilityに制限
- 共有memory archtecture
- !!1 shared nothing archtecture(a.c.a. horizontal scaling, scaleout)
- 利用広がる
- node ← 独立
- bestな費用対効果のマシンを自由に選択
- 地域分散 → latency down, 高可用
- 小企業でも可能
- 制約やトレードオフの認識必要
- merit多いが，applicationが複雑化
- → data modelの表現力に制約生じる
- !!2 replicationとpartitioning
- replication: 冗長性，performance良化
- partitioning(a.c.a. sharding)
- 図Ⅱ-1: e.g.
- simple: scale up(vertical)
Ch05 replication
目的
- 目的
- 地理的近さ → latency down
- 高可用性
- read queryを処理するmachineをscale out → throughputを高める
- dataへの変更の扱いが重要
- single leader, multi leader, leaderless
- tradeoff
- sync, async
- 障害中のreplicaの扱い
- 結果整合性について
- read-your-write, monotonic reads
5.1 leader, follower
目的
- 図5-1 leader base(a.c.a. active-passive, master-slave) replication
- replication log, or 変更streamの一部としてleaderがfollowerに送信
- e.g.
- PostgreSQL, MySQL, Oracle Data Guard, SQL Server AlwaysOn可用性groupなどのrelational db
- MongoDB, RethinkDB, Espressoなど非relational db
- KafkaやRabbitMQ高可用性queueなどのdistributed message brokerもこのarchtectureを利用
- DRDBなどnetwork filesystemやreplicationを行うblock deviceにも同様のものある
対応
- !1 sync/asyncのreplication
- 図5-2: sync/asyncのfollower各1つ
- 通常は1つのみsync, 他はasync
- semi-synchronous
- 完全asyncも多い
- sync型の変種: chain replication @ Azure Storage
- !2 新しいfollowerのset up
- snapshot
- snapshotのreplication log上の位置: log sequence no.(@PostgreSQL), binlog coordinates(@MySQL)
- → catchup
- snapshot
- !3 nodeのfaultへの対処
- !!1 followerの障害: catchup recovery
- !!2 leaderの障害: fail over
- !4 replication logの実装
- !!1 statement baseのreplica
- problem多い，compact〇
- e.g. MySQL, VoltDB
- !!2 Write-Ahead Log(WAL)の転送
- e.g. PostgreSQL, Oracle
- 欠点: logはとても低レベル → storage engineとの結合強い
- → version mismatchがよくない → upgradeにdowntime必要
- !!3 login(行base) log replication
- logic log ←→（独立） storage engineの(physical) log
- e.g. MySQLのbinlog
- 互換性〇．外部applicationのparse〇 → DWHや，custom indexやcacheの構築に〇
- → 変更データのキャプチャ → Ch11
- !!4 trigger base replication
- !!1 statement baseのreplica
5.2 replication lagにまつわるproblem
目的
- 読み取りscaling archtecture
- async replicationのみ
- 「eventual consistency(結果整合性)」と非一貫性のproblem
対応
- !1 自分が書いた内容のread
- 図5-3: read-after-writeの必要性(a.c.a. read-your-write)
- 多くの方法
- userが変更しうるものはleaderから，他はfollowerから
- 更新時刻の追跡．@user, replica
- logicalなtimestampもreal system clockも使える
- cross-device read-after-write 一貫性
- metadataの集中配置
- routing
- !2 monotonicなread
- 図5-4: より過去の情報の取得
- eventual consistencyよりは強い一貫性を保証
- 各userが各々同じreplicaからread
- !3 一貫性のあるprefix read
- 図5-5: e.g.
- !4 replication logへの対処
- dbがreplicationのproblemに対処 → transactionの意義．→ 強い保証を提供
5.3 multi leader replication
目的
- multi leader(a.c.ca. master-master, active-active replication)
- leader base replicationの自然な拡張
対応
- !1 multi leader replicationのUseCase
- !!1 multi datacenterでの運用
- !!2 offlineで運用されるClient
- 各deviceがleaderとしてactするlocal dbを持つ
- → 全device上でasyncのmulti leader replication processingあり
- 実装が困難
- CouchDBは，このような運用に応じたdesign
- !!3 collaborativeなedit
- !!2のoffline editと多くの点で共通
- !2 writeのconflictのprocessing
- 図5-7: e.g.
- !!1 syncのconflict detectとasyncのconflict detect
- !!2 conflictの回避
- あるrecordへのwriteは同じleader
- 多くのケースで推奨
- !!3 一貫したstateへの収束(convergent)
- 各writeにunique ID → Last Write Wins(LWW)
- → 損失リスク大の手法
- replicaにunique ID →↑
- 値のマージ
- 全ての情報をstoreするdata struct → conflictを記録
- → application codeで解決． ← userに確認要求
- !!4 customのconflict resolution logic
- !!5 Whats's Conflict?
- → Ch07, Ch12
- !3 multi leader replicationのtopology
5.4 leaderless replication
目的
対応
- !1 when a node is down, write to db
- 図5-10
- read requestも複数nodeに送る
- !!1 read repairと反entropy
- read repair: readがoftenなとき〇．ただし耐久性低い．
- Anti-entropy処理．
- background processing．遅延あり・
- !!2 writeのためのQuorum
- w + r > n を満たすwrite, read → Quorum read(or write)
- ingeneral: nはodd, w=r=(n+1)/2
- 図5-11: e.g.
- !2 Quorumの一貫性の限界
- w + r <= n → 低latency, 可用性up
- w + r > nでもoldなvalueが返るケース
- → 絶対的な保証ではない．結果整合性〇
- → transactionや合意が必要
- !!1 delayのmonitoring
- replicaのhealthnessについてのalert要
- leaderlessでは難しいmonitoring
- 結果整合性の「結果」の数値化が重要
- !3 sloppy quorum, hintつきhandoff
- leaderless replication: 高可用性と低latencyがdesire
- sloppy quorum: writeの可用性upに重要
- optionとなる
- !!1 multi datacenterでの運用
- leaderless replicationも〇
- e.g. Cassandra, Voldemort
- leaderless replicationも〇
- !4 並行writeのdetect
- 図5-12: case e.g.
- !!1 LWW
- Cassandra, Riakのoption
- 耐久性のコスト
- data lossが×なら不十分
- keyがimmutableなときのみ安全
- !!2 happens-before relationと並行性
- happens-before(因果関係あり) ←→ 並行
- 2者間不関知 → 並行
- !!3 happens-before relationの補足
- version no.の使用
- !!4 並行で書き込まれた値のマージ
- 並行の値: sibling
- tombstone for delete
- siblingのmergeは複雑
- → 自動でmergeできるdata structureがdeveloped
- e.g. RiakのCRDT
- !!5 version vector
まとめ
- replicationの目的
- 高可用性
- 切断stateでのmanupulation
- latency
- scalability
- 難しい問題多い
- replicationの3つのapproach
- single leader replication
- multi leader replication
- leaderless replication
- replication logへの対応
- read-after-write一貫性
- monotonicなread
- 一貫性あるprefix read
- multi leaderやleaderlessでの並行性のproblem
Ch06 Partitioning
目的
- 非常に大規模なdatasetやqueryのthroughputがとても高い
- 目的: scalability
6.1 Partitioning, replication
目的
- 図6-1: replicationとpartitioningのcombination
6.2 K-V dataのpartitioning
目的
- 目標: dataとqueryの負荷をノード間で均等に分散
- 一部の負荷大: skewなstate, 一部: hotspot
- → hotspotを避ける．
対応
- !1 keyのrangeにもとづくpartitioning
- !2 keyのhashにもとづくpartitioning
- !3 workloadのskewとhotspotの軽減
- applicationがskewを抑える必要
- 負荷が集中する少数のkeyに限定 → n倍のkeyをreadなど，管理のための処理増
- 分割されたkeyの追跡必要
- 将来的には，datasystemが自動でskew workloadを検知 → 対処
6.3 Partitioning, Secondary index
目的
- secondary indexは，SolrやElasticsearchなどの検索serverの存在意義（レーゾンデートル）
- secondary indexとpartitioningの対応づけのproblemに対応
対応
- !1 documentによるsecondary indexでのpartitioning
- 図6-4: e.g.
- documentでpartitioningされたindex: local index
- queryはすべてのPartitionに送る必要: scatter/gather
- 負荷極大のケースアリ
- e.g. MongoDB, Riak, Cassandra, Elasticsearch, Solr Cloud, VoltDB
- !2 語によるsecondary indexでのpartitioning
6.4 Partition のrebalancing
目的
- 負荷をcluster内のあるnodeから別のnodeに移行: rebalancing
- 要求
- 負荷がcluster内node間でfairに分配
- rebalancing中も，dbはread/writeを受け付ける
- node間のdataの移動は最小限．rebalancingは高速でnetworkやdisc I/Oの負荷を最小にする．
- 要求
対応
- !1 rebalancingの戦略
- !!1 取るべきでない方法: hashの剰余
- node数に場所が依存
- !!2 Partition数の固定
- 図6-6: balancingの前後
- Partitionのnodeへのアサインのみ変わる
- e.g. Riak, Elasticsearch, Couchbase, Voldemort
- Partitionの数は固定が多い
- → datasetの合計サイズに大きな変動があると，設定が難しい
- 図6-6: balancingの前後
- !!3 dynamicなPartitioning
- HBaseやRethinkDBなど，keyのrangeによってPartitioningされたDBは，dynamicにPartitionを作成
- BTreeのtop level と似た処理
- 固定 number (Partition)と同じく，各nodeは複数Partitionを扱える
- dynamic Partitioningのメリット
- Partitionの数をdataの総量に適合
- 事前分割も可能
- keyのrangeとhash Partitioningどちらにも〇
- e.g. MongoDB
- !!4 node数に比例するPartitioning
- metadataのoverheadを低く抑える by 新しいhash function
- e.g. Cassandra, Ketama
- nodeあたりのPartition数を固定
- hash baseのPartitioning → Partitionの境界をランダムに選択
- ↑ context hash法の元々の定義に近い
- !!1 取るべきでない方法: hashの剰余
- !2 運用: 児童のrebalancingと手動のrebalancing
- 自動化と児童のフォールト検知の組み合わせ
- → カスケード フォールトのリスクあり
- どこかで人の処理があった方が〇
- 自動化と児童のフォールト検知の組み合わせ
6.5 requestのrouting
目的
- service discoveryのproblem
- 図6-7: 3つの方法
- routingのjudgeを行うcomponentがどのようにしてPartitionのnodeへのアサインの変化を知るか
- 図6-8: ZooKeeperを使った，Partitionからnodeへのアサインの追跡
- e.g.
- LinkedInのEspressoは，Helix(relys on ZooKeeper)を使用．routing層あり．
- HBase, SolrCloud, KafkaもZooKeeper
- MongoDBはoriginalのconfig serverとrouting layer: mongos
- CassandraとRiakは，node間でgossip protocol
- Couchbaseは，moxiというrouting層で構成
- auto rebalancingなしのため単純
- connect先IP addressはDNSで十分なこと多い
対応
- !1 parallel queryの実行
- OLAPで使われるMassively Parallel Processing: MPP（大規模並列処理）
- relational dbは複雑なqueryをサポート．
- ↑→ NoSQL distributed datastore: 単一のkeyのread/write
- especially, datasetの大部分へのscanをするqueryで〇．
- OLAPで使われるMassively Parallel Processing: MPP（大規模並列処理）
まとめ
- 大規模なdatasetを小さな部分集合にPartitioning
- dataに適したPartitionのschemaを選択 ＋ rebalancing
- 2つのPartitioningのapproach
- keyのrangeによるPartitioning
- rebalancingはdynamic
- hash Partitioning
- 固定数のPartitionがgeneral. dynamicなPartitioningも使える〇．
- hybridなapproachも可能
- keyのrangeによるPartitioning
- secondary index のPartitioningの2つの方法
- documentによりPartされたindex(local index)
- scatter/gather必要
- WordによってPartitioningされたindex(global index)
- writeで複数Partitionをupdate, readは単一Partitionで処理〇．
- documentによりPartされたindex(local index)
- routing
- 全てのPartitionはほぼ独立に動くようdesign
Ch07 Transaction
目的
- Transaction: 複数read/writeをlogicalな単位にまとめる
- → systemの様々なフォールトへの対処 → 信頼性
- commit/abort/rollback
- Transactionの目的: dbにaccessするapplicationのためのprogramming modelを単純にする
- → 安全性の保証
- あらゆるapplicationがTransactionを要するわけではない
- Transactionを弱めると，performanceや可用性が上がりうる
- どのような安全性の保障と，それらに伴うcostを見る
- especially, concurrency control
- race condition, read committed, snapshot isolation, serializability
- especially, concurrency control
- 単一ノードのdbにも分散dbにもあてはまるproblemを見る
7.1 Transactionというとらえどころのない概念
目的
- MySQL, PostgreSQL, Oracle, SQL Serverとも，IBMがSystem R(1975)に導入したものに似ている
- 非relational dbは，Transactionをはるかに弱い保証群として再定義
- Transactionにはどちらでもないメリットと制限がある
対応
- !1 ACIDの意味
- Atomicity, Consistency, Isolation, Durability
- 実情は，ただのマーケティングワード
- ACID ←→ BASE(Basically Available, Soft state, Eventual consistency)
- BASE: 「ACIDでない」という意味のみ
- !!1 Atomicity
- concurrencyとは無関係
- commit or abort・rollback
- → abortabilityが本来の意味をよくとらえる語
- !!2 Consistency
- dataについて常に真でなければならない何らかの言明・不変性がある
- e.g. 貸借一致
- → applicationの特性でありdbの特性ではない
- CAP定理では，線形化可能性の意味
- dataについて常に真でなければならない何らかの言明・不変性がある
- !!3 Isolation
- concurrencyのproblem, race condition
- 図7-1: e.g.
- a.c.a. serializability(直列化可能性)
- performanceのproblemのため，実際は使われない
- snapshot分離というserializabilityより弱い保証もある
- !!4 Durability
- written dataはlostしないことを保証(完全はありえない)
- discへのwriteとreplication → 多くの手法を併用すべき
- !2 単一Objectと複数Objectの操作
- multi Object Transaction
- !!1 単一のObjectへのwrite
- storage engineは，単一nodeにおける単一Objectのレベルで，Atomicity（← log）, Isolation（← ロック@ Object）を提供
- 一部: increment操作などのさらに複雑なatomic操作
- 広く使用: compare-and-set
- 複数Clientが並行に同じObjectにwriteしたときの更新lossを防ぐ
- 通常，Transactionとは，複数Objectへの複数操作を1つの実行単位としてグループ化する仕組み
- !!2 複数ObjectのTransactionの必要性
- 多くの分散データストアでは放棄
- relational data model, document data model, secondary indexでの必要性
- !!3 errorとabortの処理
- Transactionの重要な機能: error時にabort.安全にretry
- aborted Transactionのretry: simple & effectiveなerror処理の仕組み．ただし完全でない
- 別途重複排除必要
- 過負荷へのexponential backoffが必要
- eternal errorへのretryは×
- 2相コミットが必要なケース ← DB外副作用
- Clientのprocessing downは×
7.2 弱いisolation level
目的
- ある種(not all)concurrency problemへの保護のみのsystemがgeneral
- ↑→ serializableなisolation: performance重い
- → bugもありうる
- → concurrencyのproblemの種類と回避策をし折る
- → 信頼でき正しく動くapplicationを，手の届くtoolsで構築
対応
- !1 read committed
- 2つの保証
- ①dirty readなし
- ②dirty writeなし
- most basical levelのTransaction isolation
- !!1 dirty readなし
- 図7-4: e.g.
- dirty read回避のメリット
- 複数Objectの更新
- rollback
- !!2 dirty writeなし
- いくつかのconcurrency problem回避
- 図7-5: e.g.
- counterのincrementのproblem(図7-1)は回避不可能
- いくつかのconcurrency problem回避
- !!3 read committedの実装
- e.g. Oracle11g, PostgreSQL, SQL Server 2012, MemSQL etc.
- 行levelロックが一般的
- ほとんどのDBでは，図7-4のようなapproach ← 旧新2つを保持
- read committed isolation levelのためのロックは，IBM DB2と，read-committed snapshot=offのSQL Serverのみ
- 2つの保証
- !2 snapshot isolationとrepeatable code
- 図7-6: read-committedで生じるbug
- non repeatable read(a.c.a. read skew)
- skew: timingの異常． ≠ hotspotによるskew
- temporary not consistencyが×なケース
- backup
- Analytic queryとconsistency check
- → snapshot isolationで対処
- 各Transactionがconsistentなsnapshotからread
- 長時間のreadだけのqueryに有益
- e.g. PostgreSQL, Storage engineとしてInno DBを使うMySQL, Oracle, SQL Server etc.
- !!1 snapshot isolationの実装
- readはwriteをnot block, writeもreadをnot block
- MVCC(Multi-Version Concurrency Control)と呼ぶ
- 図7-7: PostgreSQLでのsnapshot isolation by MVCC
- !!2 Consistent snapshotを見るためのvisualize rule
- Objectが見えるcondition
- overheadを小さく抑える．一貫したsnapshotを提供
- !!3 indexとsnapshot isolation
- append-only/copy-on-writeなど，実装の細部
- !!4 repeatable readとnameの混乱
- readのみのTransactionに特に有益
- 別名多い @Oracle → SERIALIZABLE, @MySQL,PostgreSQL → Repeatable Read
- SQL Standardのisolation levelの定義は欠陥
- Repeatable Readの正式な定義を満たす実装はほぼない
- !3 更新のlostの回避
- clobber(ひっぱたく)
- !!1 atomicなwrite
- 最もよい選択肢
排他ロック，カーソル固定(stability)
ORM frameworkでは，unsafeなread-modify-write cycleが起こりうる
- !!2 explicit lock
- applicationによるlock
- 例7-1
- 実装複雑
- !!3 更新のlostの自動検知
- snapshot isolationとの併用が効率的
- Transaction Managerが検知 → abort → retry
- applicationが特別な処理の呼び出し不要 → 素晴らしい．
- !!4 compare-and-set
- snapshotからのreadがあるときは注意
- !!5 conflictのresolutionとreplication
- compare-and-setは×
- siblingを生成〇 → 事後にconflictのresolutionやマージする
- 交換可能な操作 → atomicな操作〇 @ replication
- LWWは×だが，多くのDBでdefaultになっている
- !4 write skewとphantom
- 図7-8: e.g.
- serializationかexplicit lock(→ !!1 what's write skew)
- !!2 write skewのほかの例
- 例7-2: 会議室予約システム
- e.g. multiplayer game．利用するusernameの要求．2重支払いの防止
- !!3 write skewを生じさせるphantom
- phantom: あるTransactionのwriteがほかのTransactionのreadに影響
- !!4 conflictの実体化
- lock集合のtable作成: 最後の手段
- → serializable isolation levelの方がはるかに◎
7.3 serializability
目的
- race conditionに弱いTransactionにかんするproblem
- isolation levelの理解難しい．DBごとに非一貫
- safeかどうか判定が難しい
- race condition detectのためのtoolなし
- serializable isolation: 最も強いisolation level
- → 考えられる全race conditionを回避
- implementとperformanceのproblem
対応
- !1 完全な順次実行
- 単一threadでTransactionを処理 → serializable isolation level
- RAM price down
- OLTP Transactionは短く少ないread/writeしかない
- e.g. VoltDB/H-Store, Redis, Datomic
- lockによる調整のoverheadなく，高性能たりうる
- !!1 SPへのTransactionのencapsulate
- Transactionは1つのhttp request内でcommit
- 単一threadで順処理では，外部とのやり取りを行う複数文を含むTransactionをprohibit
- → 代わりにSPとして登録 → dataがmemoryにあれば極めて高速
- 図7-9
- !!2 SPのmerit, demerit
- !!3 Partitioning
- 複数PartitionにまたがるTransactionでは，SPのthroughputは数桁down
- !!4 順次実行のまとめ
- Transactionの順次実行がserializable isolation level実現のための制約
- 全Transactionが小さくて高速
- activeなdatasystemがメモリに収まるUseCase → or, anti caching
- write throughputが，単一のCPU coreで十分処理できる程度には低い
- or Partitionをまたぐ調整なしにTransactionをPartitioningできる
- PartitionをまたがるTransactionでは，hard limitを設けられる
- Transactionの順次実行がserializable isolation level実現のための制約
- 単一threadでTransactionを処理 → serializable isolation level
- !2 two phase lock(2PL)
- 30年間唯一のserializable isolation levelのための2PL ← 特にSS2L(Strong Strict Two-phase Locking)と呼ぶ
- 2PL ≠ 2PC(Commit)
- writerはほかのwriterに加えてreaderをブロック
- readerもwriterをブロック
- ↑→ snapshot isolation level
- → すべてのrace conditionへのguardを提供
- !!1 2PLの実装
- e.g. MySQL(InnoDB), SQL Serverのserializable isolation level, DB2のrepeatable read isolation level
- shared modeとexclusice mode
- deadlockのproblemと対応
- 自動の対応
- !!2 2PLのperformance
- performanceはbad
- ↑ 多くのlockのoverheadと，concurrencyの低下
- latency不安定 → 高p値の速度低い
- !!3 predicate(述語) lock
- phantomに対しても適用可能
- !!4 index range lock(a.c.a. next-key lock)
- preciseではないが，overheadははるかに低い
- !3 serializableなsnapshot isolation(SSI)
- 完全なserializableかつsnapshot isolationよりperformance〇
- 2008～
- e.g.
- 単一node: PostgreSQL 9.1～
- 分散DB: FoundationDB
- !!1 pessimisticなconcurrency controlとoptimisticなconcurrency control
- pessimistic: 相互排他(multithread programmingでdata structureを保護)に似ている．
- ↑ 順次実行
- optimistic ← SSI
- 十分な要領でtransaction environmentの競合がそれほど高くない → performance〇
- 競合: 交換可能なatomicな操作で減らせる
- snapshot isolationの上に，write間のserializableのconflictの検知アルゴリズム
- pessimistic: 相互排他(multithread programmingでdata structureを保護)に似ている．
- !!2 古くなったpremiseにもとづくjudge
- premise: transactionのstart時は真だったfact
- readとwriteの因果を示す必要
- 要考慮点
- 古いversionのMVCC Objectのreadのdetect(!!3)
- 前のreadに影響sるwriteがあるときのdetect(!!4)
- !!3
- snapshot isolation level ← MVCCで実装
- 図7-10: e.g.
- !!4
- 図7-11: e.g.
- !!5 SSIのperformance
- reader, writer間はブロックなし
- latency予測〇, 変動小さい
- readのみのqueryはロック不要
- 単一CPU coreのthroughputにunlimited
- 複数マシンのPartitioningにも対応
- read/write transactionは極短がneeded
- 2PLや順次実行ほどは，低速なtransactionの影響なし
- reader, writer間はブロックなし
まとめ
- Transaction: abstractionのlayer
- concurrencyやhardware, softwareのproblemを隠す
- → simpleなtransactionのabortにまとめる → retryのみでOK
- concurrency controlのlevel
- read committed
- snapshot isolation(a.c.a. repeatable read)
- serializable
- race conditionとisolation level
- dirty read/write
- non repeatable read(a.c.a. read skew)
- MVCC
- 更新のlost
- write skew
- phantom read
- 全てをresolveはserializable isolation levelのみ
- 〇順次実行
- ×2PL
- 〇SSI
Ch08 distributed systemのproblem
目的
- distributed systemと単一マシンsystemの根本的違い
8.1 faultと部分fault
目的
- 単一マシン: 決定的
- distributed system: 部分fault → 非決定的
- 成功したか分からない
対応
- !1 Cloud computingとsuper computing
- 大規模なcomputing systemの構築方法の哲学のスペクトラム
- HPC(High Performance Computing)
- 演算中心型のscientific calculation task
- cloud computing
- traditionalな企業datacenterは，この間のどこか
- HPC(High Performance Computing)
- → フォールトへのapproach異なる
- softwareにフォールトtoleranceの組込必要
- 信頼性のないcomponentからtrustnessあるsystemを構築
- 様々なフォールトへのテスト必要
- 大規模なcomputing systemの構築方法の哲学のスペクトラム
8.2 低trust network
目的
- shared nothing system by network
- internetとdatacenter内の大部分の内部network(Ethernet)は，async packet network
- 図8-1
- 各problem ^ timeoutでの対応
- internetとdatacenter内の大部分の内部network(Ethernet)は，async packet network
対応
- !1 networkのfaultの実際
- networkの分断: network partition, netsplitと呼ぶ
- 必ずしもtolerantである必要はない
- networkのproblemへの反応の認識が重要
- networkの分断: network partition, netsplitと呼ぶ
- !2 faultのdetect
- requestのsuccessは，applicationからのproperなresponce以外確認不可能
- errorはtimeoutでjudge
- requestのsuccessは，applicationからのproperなresponce以外確認不可能
- !3 timeoutと限度のない遅延(unbounded delay)
- !4 sync networkとasync network
- sync networkでは，bounded delay by 回線，connection
- !!1 network delayの予測
8.3 低trust clock
目的
- 期間と時点
- 時間の複雑さ
- clockのsync
対応
- !1 単調increment clockと時刻のclock
- !!1 時刻のclock
- a.c.a. wall-clock time, real time
- NTPとsync
- 解像度のproblem @ 旧マシン
- !!2 単調incrementのclock
- 期間の計測に〇
- 絶対値はno mean
- 各CPU timerは必ずしも同期でない
- slewing: 進ませる頻度の調整
- distributed systemの期間計測に使える．
- !!1 時刻のclock
- !2 clockの動機とaccuracy
- !3 sync clockへの依存
- softwareがclockのずれをmonirtor要
- !!1 順序relationをもつeventのtimestamp
- 図8-3: e.g.
- LWWのproblem
- → logical clockの使用が〇
- 相対順序の決定．単調increment
- ≠ physical clock: 時刻のclockや経過時間を観測する単調increment のclock
- → logical clockの使用が〇
- !!2 clockの値の信頼区間
- !!3 globalなsnapshotのためのsync clock
- distributed system(machine), 複数datacenterなどでのDBにおけるsnapshot isolation levelのproblem @transaction idの生成
- SpannerはTrueTime APIを使い，clockのtimestampをTransaction IDとして用いる
- distributed transactionでのclockのsyncは重要
- !4 processingの一時停止
- distributed systemにおけるleaderの扱い
- leaderがleaseを取得
- lease: timeoutつきlockのようなもの
- leaseについてのclockのproblem
- leaderがleaseを取得
- !!1 responce timeの保証
- hard real time system. RTOS(Real Time OS)
- 組込systemのreal time ←→ Webのreal time
- physicalなものをcontrolするsystem
- worst proceed timeの保証
- cost 極大．performance 悪い
- safetyが極めてimportantな組込deviceを使う
- ↑→ 多くのServer side data proceed system
- hard real time system. RTOS(Real Time OS)
- !!2 GCによるimpactの制限 → 有益
- distributed systemにおけるleaderの扱い
8.4 知識・真実・虚偽
目的
- system model(仮定)を設定して設計する
- distributed systemでの知識と真実を見る
対応
- !1 真実(truth)は多数決で決まる
- 多くのdistributed algorithmはquorumに依存
- !!1 leader とlock
- 図8-4: bugのe.g.
- !!2 フェンシングtoken
- 図8-5: e.g.
- e.g.: ZooKeeperでのzxid, cversion
- Server sideでのtoken chack: 〇
- !2 ビザンチンフォールト(Byzantine)
- nodeはuntrust, but誠実がpreposition
- Byzantine fault-tolerant: attackerへも耐性
- complicate protocol必要．hardware levelでのsupportに依存
- P2P networkでは考慮必要
- !!1 weakなうそからの保護
- !3 system modelと現実
- 3つのmodel
- sync model
- ほとんどのcaseで現実的でない．上限は現実ではないこと多い
- 部分 sync model
- 多くのsystemで現実的
- async model
- 制約強い
- sync model
- nodeについての3つのmodel
- crash stop fault
- crash recovery fault
- Byzantine fault
- 部分sync modelとcrash record faultのペアが一番beneficial
- !!1 algorithmの正しさ
- 性質(properties)によって正しさを定義
- e.g. unique性，単調increment sequence(→ ここまで安全性), 可用性(→ live性)
- !!2 安全性とlive性
- live性: 「eventual」 ←→ 安全性: いつも起こらない
- !!3 現実世界へのsystem modelのmapping
- 実際の実装では，起こりえないことへの対処のcodeが必要
- 理論的分析と実践的testは等しく重要
- 3つのmodel
まとめ
- distributed systemでの幅広いproblem
- 部分fault
- faultのdetect
- quorumが合意するためのprotocolで耐性付け
- distributed systemの目的: scalability, fault-tolerance, low latency
- ↑→ 単一node
Ch09 一貫性と合意
目的
- fault-tolerantなdistributed systemの構築のためのalgorithmとprotocol
- abstractionでproblemを隠蔽が重要
- 重要なabstraction: 合意
- 可不可の限度の認識が重要
- abstractionでproblemを隠蔽が重要
9.1 一貫性の保証
目的
- eventual consistency(convergence(収束性)の方が良い表現) @replicationをするdb
- とてもweakな保証
- boundの認識が重要
- edge case: systemのfaultや，並列性極高のときに生じる
- → より強い一貫性modelを見る
- 対価: performance, tolerance down
- distributed 一貫性modelと，transactionのisolation levelの階層は，focusがそれぞれ独立．
- transactionは，race conditionの回避
- distributedの一貫性は，delayやfaultに際してのreplicaの調整
- ただし，両社は深くrelationあり
- linearizability(線形化可能性): the strongest
- distributed systemでのeventの順序付けの問題
- especially 因果律と全順序(total ordering)のproblem
- atomicityを保ちつつcommit @ distributed transaction
- → 合意のproblemの解決方法
9.2 linearizability
目的
- linearizability: a.c.a. atomic consistency, strong consistency, immediate consistency, external consistency
- dataのcopyが1つしかないように見せる
- recency guarantee(最新性の保証)
- 図9-1: 反例
- recency guarantee(最新性の保証)
- dataのcopyが1つしかないように見せる
対応
- !1 systemをlinearizableにするcondition?
- 図9-2: xはregister. read, write, concurrのe.g.
- 図9-3: concurrencyでの制約．新旧どちらか不明な登録(regular register)
- 図9-4: complicate case ← compare and set
- linearizabilityとserializability
- linearizability
- 個々のObjectに関すること．registerのread/writeでのrecency保証
- serializability
- transactionのisolation．複数Objectを扱う．transactionの実際の順序とは関係なし．
- 共に提供: strict serializability(a.c.a. strong-1SR, strongest one-copy serializability)
- SSIはnot linearizability
- linearizability
- !2 linearizabilityへの依存
- !!1 lockとleader election
- lockはlinearizability must
- e.g. Apache ZooKeeperやetcd. for distributed lock, leader election
- 合意algorithmを使い，fault tolerantを保って，linearizableな操作を実装
- Apache Curatorのようなlibraryが，ZooKeeper上で高レベルの処方を提供． to 多くの繊細なproblem
- → 協調taskの基盤になる
- distributed lockは，Oracle Real Application Clustors(RAC)のようなdistributed db 中で極小levelで使用
- RAC: lockをdiscのpageごとに使う
- linearizable lockは，transaction実行のcritical path
- → db node間communicationに，専用のcluster inter connection networkを使う
- !!2 制約およびuniqueの保証
- unique制約を保証するためのlinearizability
- lockと類似
- unique制約を保証するためのlinearizability
- !!3 cross channel timing依存relation
- 図9-5: e.g. cross channel
- → linearizability 必要
- !!1 lockとleader election
- !3 linearizable systemの実装
- replication for fault-tolerance
- !!1 linearizabilityとquorum
- 図9-6: quorumでのrace condition
- performanceを代償にすれば，linearizableにできる
- compare-and-setは×
- → 不可能と考えてよい
- !4 linearizableにするコスト
- 図9-7: linearizability or availabilityのselection
- !!1 CAP定理
- linearizabilityとavailabilityのtradeoffの議論の出発点
- CAP 3つから2つではなく，C(Consistency: linearizability)かAvailabilityの一方をselect when network fault
- Availabilityには矛盾した複数の定義アリ → CAPは使えない
- linearizabilityとnetwork分断のみを扱うもの
- → historicalなinterestのみある
- !!2 linearizabilityとnetwork delay
- 実際にlinearizableなsystemはほとんどない
- e.g. multi core CPUのRAMも not linearizable. without memori barrier or fence
- performanceとのtradeoffのため
- 実際にlinearizableなsystemはほとんどない
9.3 Orderの保証
目的
- 順序付け: important basic concept(概念)
- Ch05, 07, 08
- 順序とlinearizability合意の間の深い関係
対応
- !1 Orderと因果関係
- Orderは因果関係
- e.g. request/responce, 事前発生(Ch05), Consistency, skew(Ch07), 図9-1
- 因果律からのorderに従う: 因果律において「causually consistent」
- e.g. snapshot isolation
- !!1 因果律にもとづくorderと全orderの違い
- incomparable: {a,b}, {b,c}
- → partially ordered(単順序) → {a} ⊂ {a,b}など
- linearizable systemは全order
- 因果律: 半orderを定義
- concurrencyはincomparable
- → linearizable systemにはconcurrencyなし
- concurrency: 枝分かれ．別々の分岐はincomparable
- !!2 因果律の一貫性より強いlinearizability
- linearizabilityは因果関係を暗に含む
- しかし，performanceやavailabilityの大小アリ
- linearizability以外でも因果律は実現可能
- → causually consistencyがnetwork delayで速度が落ちないconsistencyの中でstrongest
- network faultがあっても利用〇
- → ごく最近の研究で扱われている． about causually consistency
- → causually consistencyがnetwork delayで速度が落ちないconsistencyの中でstrongest
- linearizabilityは因果関係を暗に含む
- !!3 因果律における依存関係の補足
- 操作の先行を知る必要: 半order
- nodeのacknowledgeを記述する必要
- version vectorの利用 ← 5.4.4と似ている
- dbがread dataのversionを知ることが必要
- nodeのacknowledgeを記述する必要
- 操作の先行を知る必要: 半order
- Orderは因果関係
- !2 sequencial numberのorder
- sequencial number( or timestamp)でのeventのorderづけ
- timestampはlogical clockで〇
- compactで全orderを提供
- especially, sequencial numberは因果律とのconsistencyをもつ全orderを持たせて生成〇
- e.g. single leader replicationのdbは，replication logがwriteの全orderを規定
- !!1 因果的でないsequencial number生成器
- 単一leaderなし → sequencial numberの発行は，不透明
- 個別のsequencial number発行は，因果律のconsistencyなし
- ↑ 複数nodeでの操作のorder補足不可能
- 個別のsequencial number発行は，因果律のconsistencyなし
- 単一leaderなし → sequencial numberの発行は，不透明
- !!2 Lamport timestamp
- !!3 timestampでのorderづけでは不十分
- Lamport timestampは，distributed systemのgeneral な多くの問題の解決には不十分
- ↑ 操作の全orderは，すべての操作がcollectできたあと
- → unique制約には，操作の全orderでは不十分
- → いつまでに確定するかが重要
- sequencial number( or timestamp)でのeventのorderづけ
- !3 全orderのbroadcast
- problem
- 操作のthroughputが単一leaderでproceedできる以上のもののときのsystem scale 方法
- leaderのfail over
- (↑2つ)→ total order broadcast ( or, atomic broadcast)と呼ぶ
- Partitionごとのleaderのときは，total order broadcastよりさらにcomplicate processingが必要
- total order broadcast: node間のmessage交換protocolとして記述
- 2つの安全性の保障
- trusted cast(配信)
- total ordered cast
- 2つの安全性の保障
- !!1 total order broadcastの利用
- ZooKeeperやetcdのような合意serviceは，total order broadcastを実装
- total order broadcast: dbのreplicationに必要なもの
- ↑ state machine replication
- serializable transactionの実装にも使われる
- messageがcastされた時点で順序確定
- → timestampでのorderingよりstrong
- logの生成とみることも〇
- fencing serviceをserveするlock serviceの実装にも使える
- @ZooKeeperのzxid
- !!2 total order broadcastを使ったserializable storageの実装
- serializabilityとtotal order broadcast(合意のproblem)は密な関係
- total order broadcast: async ←→ linearizabilityは最新性
- but, total order broadcast可能 → linearizable storage構築〇
- linearizable compare-and-set操作は，total order broadcastを，追記のみ行われるlogとして使う
- 全てのnodeが，どれが初めか合意
- → writeのcommitとabortの合意
- → log baseのserializable multi object transactionの実装にも使える
- → writeはlinearizable, readはnot linearizable
- → sequencial consistency(a.c.a. timeline consistency) <(わずかに) linearizability
- readもlinearizableにする方法，approach
- → writeのcommitとabortの合意
- !!3 linearizableなstorageを使ったtotal order broadcastの実装
- linearizable sequencial number generatorを使う ← 合意のalgorithm
- linearizable (increment) compare-and-set registerと，total order broadcastはどちらも合意と等価
- → どちらかをresolve → もう一方にも変換〇
- problem
9.4 distributed Transactionと合意
目的
- consent: distributed computingで，most importantでbasicalなproblemの1つ
- replication, transaction, system model, linearizabilityとtotal order broadcastの上に立つproblem
- node群のconsentがimportantなcase
- leader elegant
- atomic commit
- → atomic commit problem
- consent の不可能性
- FLP帰結(consent不可)は，async system modelでの証明
- 通常のdistributed systemはconsent可能
対応
- !1 atomic commit と2PC
- transactionのatomicity
- !!1 単一nodeからdistributed atomic commitへ
- 単一nodeでのtransactionのcommitは，dataが永続性をもってdiscにwriteされるorderに完全に依存
- data のwrite → commit recordのorder
- read commit isolationのため，commitは消せない
- !!2 2PC
- !!3 約束のsystem
- commit point
- 2つのpoint of no return
- !!4 coordinatorのfault
- in doubt, uncertain
- 図9-10
- coordinatorのrecoveryを待つ必要
- in doubt, uncertain
- !!5 3PC
- 2PC: blocking atomic commit protocol
- 3PC: nonblocking
- but, 制限あり．現実にはnot atomic
- non blocking. atomic commitはperfect failure detector必要
- 実際は難しい
- non blocking. atomic commitはperfect failure detector必要
- but, 制限あり．現実にはnot atomic
- !2 distributed transactionの実際
- distributed transactionへの2つの評価
- ほかのwayでは提供できない重要なsafenessの保証を提供
- ↑→運用上のproblemの原因．performanceを損ない提供可能以上の約束をしている．
- → 実際は，多くのcloud serviceで，distributed transactionは実装していない
- 2つのdistributed transaction
- db内部のdistributed transaction → 特定の技術固有のoptimise〇
- heterogeneous(不均一な，hetero: other)なdistributed transaction → 特定の技術固有のoptimise×
- 参加者は2つ以上の異なる技術を使う
- !!1 exactly-onceなmessage proceed
- !!2 XA transaction
- X/Open XA (eXtended Architectureの略): heterogeneous technologyでの2PCのstandard
- transaction coordinatorがXA APIを実装
- !!3 in doubt下のlockの保持
- lockのproblemあり
- !!4 coordinatorのfaultからのrecovery
- orphaned(孤立) in doubt transaction
- heuristic decisions を緊急避難ハッチとする実装
- atomicityを破る決定を回避
- !!5 distributed transactionのboarder
- XA transaction: 複数参加者のdata system間consistencyを保つという，realで重要なproblemを解決
- but 運用上の大きなproblemあり
- → transaction coordinator自体が一種のDB
- replication必要
- application serverのstateのproblem
- SSIとともにはXAは×
- db内部のdistributed transactionは制限小さい
- → SSIのdistributed versionはrealizable
- but, distributed transactionはfaultを増幅
- distributed transactionへの2つの評価
- !3 耐障害性をもつconsent
- consent: 非形式的には，複数nodeが何かについて同意すること．
- 形式的には，1つ以上のnodeがpropose → 合意algorithmがそれらの値から1つを決定
- uniform consent
- 4つの性質
- uniform agreement
- integrity(整合性)
- validity(妥当性) (ここまで3つが合意の核．安全性)
- termination(終了性): 耐障害性．(live性)
- 4つの性質
- いかなるalgorithmも，terminationの保証にはat least 過半数のnodeが正常であることが必要
- 安全性は，ほとんどのnodeが×でも保証できる
- Byzantine faultはないことを前提
- !!1 consent algorithmと total order broadcast
- 耐障害性のconsent algorithm
- e.g. ViewStamped Replication(VSR), Raft, Paxos, 2ab
- 形式的modelでなく，値の並びに決定 → total order broadcast
- → × 1つの値ごと， 〇 各orderでconsent → effective
- 耐障害性のconsent algorithm
- !!2 single leader replicationとconsent
- leader electionのためにleader必要
- !!3 epoch numberとquorum
- epoch: a.c.a. ballot, view, term
- 2 roundのvote(ballot)
- electionと2PCの違い → consent algorithmの正しさと耐障害性のkey
- coordinatorは2PCではnot elect
- 2PCではすべての参加者 ←→ 耐障害algorithmでは過半数
- epoch: a.c.a. ballot, view, term
- !!4 consentのbound
- consent algorithm: distributed systemの大きなbreakthrough
- すべてが不確定なsystemに，強い安全性(3つ)と耐障害性を与える
- total order broadcastを提供．耐障害性を保ちつつlinearizable and atomicな操作を実装
- performanceとcostのproblem → 使われないcaseあり
- 非固定集合では，sync membership extention必要
- timeout依存 → network delay大のcase → performance×
- e.g. Raftなど
- → 低trust networkに対する耐性アリのalgorithmは研究中
- consent algorithm: distributed systemの大きなbreakthrough
- consent: 非形式的には，複数nodeが何かについて同意すること．
- !4 membershipと強調service
- ZooKeeperやetcd: distributed key-value store, 協調および設定service
- 完全にmember内に収まる少量のdataを保持
- 耐障害total order broadcastを使って全nodeにreplication
- ZooKeeper ← GoogleのChubby
- total order broadcast 以外の機能群あり
- linearizable and atomicな操作
- 操作の全順序
- fencing token
- fault detect
- ephemeral node ← sessionがもつ任意ロック
- 変更通知
- 通知をsubscribe
- !!1 nodeへの処理のassign
- ZooKeeper/ Chubbyがeffectiveなcase
- processing/ serviceの複数インスタンスからleader, primaryをelect
- Job Schedulerやほあkのstateful systemでも〇
- partitioningされたresource(db, message system, filestorage, distributed actor system etc.)
- どのnodeにどのpartitionをassignかjudge
- processing/ serviceの複数インスタンスからleader, primaryをelect
- ZooKeeperのatomic操作， ephemeral node, 通知により達成可能
- Apache Curatorのようなlibraryあるが，簡単ではない
- ZooKeeperはnode間協調作業をoutsourcing
- applicationのstateをnode間でreplication → Apache BookKeeper
- ZooKeeper/ Chubbyがeffectiveなcase
- !!2 service discovery
- ZooKeeper, etcd, Consul
- linearizability不要なread requestにresponceできる
- !!3 membership service
- consentとfault detectの組み合わせ
- どういったnode群でmembershipが構成されているか．Systemでconsent生成は有益
- ZooKeeperやetcd: distributed key-value store, 協調および設定service
まとめ
- 一貫性とconsent
- linearizability ← 一貫性model
- 因果律
- 全eventのorder
- 弱い一貫性model
- 分岐と合流のversion history
- → consentのproblem
- 合意のproblemと等価なもの
- linearizable compare-and-set register
- atomicなtransactionのcommit
- total order broadcast
- lockとlease
- membership/ 協調service
- unique制約
- single leaderがin faultのcase
- leaderのrecovery待ち
- XA/JTA transaction coordinator
- 終了性なし → consentを解決しない
- 手動fail over
- 低速
- algorithmで自動に新leader elect
- consent algorithm
- networkの状況に対処必要証明
- leaderのrecovery待ち
- 耐障害性をもつconsentのためのalgorithm system
- ZooKeeper
- consent不要なcase
- multi leader replication system
- 単にlinearizabilityなしに対処．分岐や合流を伴うversion historyをもつdataを扱えばよい．
- multi leader replication system
『データ指向アプリケーションデザイン ――信頼性、拡張性、保守性の高い分散システム設計の原理』Part 1 データシステムの基礎
Part 1 データシステムの基礎
Ch01 信頼性，スケーラビリティ，メンテナンス性にすぐれたアプリケーション
目的
- データ指向であり，演算指向でない
- データ指向アプリケーションの機能
- DB
- cache
- search idx
- stream処理
- batch処理
- DB
- データシステムの原理と実用性，それらの適用．
考察
対応
- !2 信頼性
- フォールトトレラント ≒ レジリエント（リバウンドが語源．元に戻る力．）
- 障害 ＠ システム全体 ＞ フォールト ＠ 仕様を満たさないコンポーネント
- エラー処理でフォールトを正しく作り出す．
- !!1 hardwareの障害
- !!2 softwareのエラー
- softwareのシステマティックなフォールト
- → テスト，検証，設計での積み重ねによる対処．
- softwareのシステマティックなフォールト
- !!3 human error
- sandbox env.
- automatic test
- telemetry
- !!4 trustnessの重要度
- userの責任
- フォールトトレラント ≒ レジリエント（リバウンドが語源．元に戻る力．）
- !3 scalability
- !!1 負荷の表現
- !!2 performanceの表現
- throughput， responce time @ online system
- latency, responce timeの違い
- responce time は クライアントから見た値
- latencyは，処理を待つ時間．
- △ mean（平均）を見る → ユーザの体験は説明できない
- 〇 percentileを使う． → 〇median(a.c.a p50, 50 percentile値)を見る．
- 外れ値: p95, p99, p999を見る
- tail latency: service experienceに直にかかわる．重要．
- 外れ値: p95, p99, p999を見る
- responce time 100ms 大 → 売上1%down
- 1 sec latency → customer satisfaction 16%down @ Amazon
- p値はSLO(Service Level Objectives), SLAに使われる．
- 大きなpのresponce値は，queuingのdelayによるものが大部分．
- head-of-line blocking(HOL blocking)
- Clientでのresponce timeの計測が重要
- head-of-line blocking(HOL blocking)
- 図1-5: 1つのrequestの処理にbackendのcallが複数必要なパターン
- tail latencyの増幅
- 最小限のCPUとメモリのコスト下で，十分な室でpの概算値を計算するアルゴリズムがある．
- responce timeのデータ集計: histgram同士を加算する．
- !!3 負荷への対処のアプローチ
- scale up: 垂直, scale out: 水平
- shared-nothing archtecture: 複数マシンに負荷分散
- elastic: 負荷増検知 → 自動でコンポーネントリソースを追加
- → 手動の方がシンプル．
- scalableなarchtecture: 負荷のパラメータの下に構築．
- iterationが重要．
- !4 maintenance性
- 3つのdesign doctrine
- 運用性
- 単純性
- 進化性: 拡張性，修正容易性，plasticity(可塑性，成形力，プラスチックと同じ)
- !!1 運用性
- 定型のタスクを容易にする @ datasystem
- runtimeの挙動やシステム内部の可視化の機能を，優れたモニタリングとともに提供．
- automationと標準ツールとの結合サポート
- 個々のマシンへの依存性を持たせない．
- 優れたドキュメンテーションと分かりやすい運用モデル
- デフォルトの挙動を優れたものにする
- 管理者のオーバーライド可
- 自己回復 @ 正常なとき
- 管理者の手動コントロール
- 予期できる挙動
- 定型のタスクを容易にする @ datasystem
- !!2 単純さ．複雑さの管理
- 巨大な泥団子
- 実装のみから生じる複雑さの除去
- 偶発的な複雑さ
- → 抽象化
- !!3 進化性: 変更への配慮
- アジャイル: TDD, refactor
- 小さなローカルスケール
- → より大規模なレベル
- 単純性と抽象化が重要．
- アジャイル: TDD, refactor
- 3つのdesign doctrine
- まとめ
- 機能要求・日機能要求
- !2, !3, !4の内容
Ch02 data modelとquery lang
目的
- data model: problemへの考え方についてとても重要
- softwareにできること，できないことをとても大きく決定する．
- → アプリケーションに適したdata model が重要
- dataの保存とクエリのための汎用できdata modelを見る.
- 各レイヤでの表現
- clean data model ← 抽象化
2.1 Relational model, Document model
目的
- dataをrelation(SQLではtable)として構成．
- 各relationは，順序なしのタプル(SQLでの行)の集合．
- 起源: business dataの処理
- transaction 処理, batch処理
- network modelや階層モデルを倒す @ 1970's - 80's
- とても汎用的
対応
- !1 NoSQLの誕生
- 実際には特定の技術を指していない
- OSの非 relational distributed databaseのためのhashtag @ 2009
- → Not Only SQLとなった
- NoSQLの採用要因
- 極大datasetや優れた書き込みthroughputなど，relational DBよりscalability実現用意
- freeでopenなsoftwareが好まれる ＞ 商用
- relational DBにできない特殊なクエリ操作
- relational DBのスキーマ制約へのフラストレーションと，よりダイナミックで表現力のあるdata modelへの欲求．
- 併用．ポリグロットパーシステンス(複数モデルでの永続化)．
- 実際には特定の技術を指していない
- !2 objectとrelationのmismatch
- impedance mismatch
- application code内のobjectと，テーブルなどのdb model間の不格好な変換レイヤが必要．
- ActiveRecordやHibernateなどのORM frameworkは定型コードを減らすが，完全には隠せない．
- 図2-1: relational schemaでのLinkedInのプロフィール表現
- JSONの問題もある．
- JSONでの表現: localityに優れている
- impedance mismatch
- !3 多対1と多対多のrelation
- id, 文字列
- copyの問題
- id自体は意味なし → 〇変更不要
- → 正規化で回避可能
- 意味のある情報がコピー → ×書き込みのoverhead + 不整合リスク
- id自体は意味なし → 〇変更不要
- 正規化: 多対1 → ドキュメントDBは非サポート
- 1対多の木構造には結合不要．
- data同士のつながり
- entity化．ユーザ間の関係．
- 図2-4: 多対多の関係
- 結合が必要
- !4 document DBとhistory
- IMS(Information Management System) @ 1990's
- 階層モデル
- → 多対多への対応×
- → relational model(→ SQL)とnetwork model(→ 廃れた)が解決．
- !!1 network model
- conference on Data Systems Langs(CODASYL)
- CODASYL model
- access path
- queryやupdateのcodeが複雑で柔軟でない
- 変更に弱い．
- CODASYL model
- conference on Data Systems Langs(CODASYL)
- !!2 relational model
- query optimiserがクエリの実行順序やどのインデックスを使うか判断
- → 新機能の追加容易
- query optimiserがクエリの実行順序やどのインデックスを使うか判断
- !!3 document DBとの比較
- document DB: 階層モデルに回帰 ＋ 多対1，多対多の関係の表現〇
- ↑ 関係のあるアイテムはユニークな識別子で参照．
- document reference @ document DB = foreign key @ relational DB
- document DB: 階層モデルに回帰 ＋ 多対1，多対多の関係の表現〇
- IMS(Information Management System) @ 1990's
- !5 今日のrelational DBとdocument DB
- document data modelのメリット: schemaの柔軟性，localityによるパフォーマンス，データ構造がアプリケーションに近い．
- relational DBのメリット: 結合や多対一および多対多の関係のサポート〇
- !!1 applicationのコードをシンプルにするためのデータモデル
- relationでの細分化 → スキーマが込み入ってapplication code複雑
- 多対多の関係が必要 → 整合性のためにrelational modelが〇．
- ↑ document modelはとても複雑．パフォーマンス大きくdown.
- data item間のrelationの種類に依存 → dataの関係性強い → graph model > data model > document model
- !!2 document modelでのschemaの柔軟性
- Schema on read(Schemalessは誤用) ←→ Schema on write @ relational model
- left: dynamic型check, script language
- right: static型check, compile language
- 大規模なテーブルへのupdateの回避: nullを設定して起き，読み取り時に内容を埋める．
- Schema on readが有用なパターン
- 数多くのオブジェクトを個別テーブルに保存するのが現実的でないとき
- data structureが外部システムで決定される．変更を予期できないとき．
- ←→ すべてのレコードが同じ構造であるべき → document化と構造の強制．
- Schema on read(Schemalessは誤用) ←→ Schema on write @ relational model
- !!3 queryのためのdata locality
- documentの保存形式
- storageのlocality: document全体にaccessする場合はmeritあり．
- 1度にdocumentの大部分が必要なとき以外は不要．
- → documentは小さく保つという制約がdocument dbにはある．
- localityをいかすため，関連するデータ同士をグループ化．
- !!4 documentおよびrelational dbの融合
2.2 dataのためのquery language
目的
- SQL: 宣言的query language ←→ IMS, CODASYL: 命令的code
対応
- !1 Web上での宣言的query
- !2 MapReduceでのquery
- 大量dataを多くのマシンにまたがってまとめて処理．by Google
- e.g. MongoDB, Couch DBなどのNoSQLが限定的にサポート．
- 宣言的と命令的の間のどこか．
- map, reduceはpure function: parameterのみがinput
- 任意の場所と順序〇．
- cluster上のdistributed processingのための，とても低レベルなprogramming model.
- query中のJSのcodeもMapReduce以外でもOK
- MapReduceの問題: codeの整合を取るのが難しい
- → MongoDB 2.2: aggregation pipelineという，宣言的なquery languageをサポート．
- 大量dataを多くのマシンにまたがってまとめて処理．by Google
2.3 Graph型のdata model
目的
- 一対多(tree structure)や，record同士が関係弱い
- → document modelが〇
- 多対多 → Graph としてdataをmodelingが〇
- Graph: 頂点（a.c.a. node, entity)と辺(a.c.a. edge, relation, 弧)という2つのObjectで構成．
- e.g. Social graph, Web graph, 道路や電車のnetwork
- 一貫性を保ちながらまったく異なる種類のobjectを単一のdata structureに保存するのにもGraphは〇
- e.g. 図2-5(Graph structureのデータの例)
- property graph modelと，triple store model
- query: Cypher, SPARQL, Datalog, Gremlin, Pregel
対応
- !1 property graph
- important 3 points
- 関連付けは任意
- 任意の頂点への入出力の辺をeffectiveに見つけられる
- → graphを検索できる
- 関係の種類ごとに異なるラベル → cleanなdata modelを保ち，単一のgraph内に様々な種類の情報．
- 構成
- 頂点
- id, 外への辺集合, propertyのcollection(K, V)
- 辺
- id, 始点，終点，2頂点間の関係を示すラベル，propertyのcollection
- 頂点
- 柔軟，進化性〇．
- important 3 points
- !2 Cypher query language
- property graph用のquery language
- e.g.
- query optimiser ← 宣言的language
- property graph用のquery language
- !3 SQLでのgraph query
- !4 triple store, SPARQL
- ほぼproperty graph modelと同じ
- application構築のために価値ある様々なtoolsやlanguagesある
- 3部分からの言明（主語，術後，目的語）． e.g. (Jim, likes, bananas)
- 目的語は，primitiveなdata 型の値 or 別の頂点．
- 記法: 例2-7
- !!1 semantic web
- RDF(Resource Description Framework)
- → "web of data", internet規模での「あらゆる情報のDB」
- tripleは，applicationの内部的なデータモデルとして優れる．
- RDF(Resource Description Framework)
- !!2 RDF data model
- !!3 SPARQL
- Cypherの元となったもの(about pattern matching)
- 変数が?から始まる
- 優れたquery language
- !!4
- graph dbとnetwork modelの比較
- graph >>> network
- graph dbとnetwork modelの比較
- !!5 礎となったもの: Data log
まとめ
- document db: dataが自己完結しているdocument群．document間の関係がそれほどないUCがターゲット．
- graph db: あらゆるもの同士が関係するようなUCがターゲット．
- どちらも，保存するデータにスキーマを強制しない．
- 各モデルには独自のquery languageやframeworkあり．
- その他のmodel
Ch03 storageを抽出
目的
- dbの根本task: dataの保存とrequestへのresponce
- 保存と取り出しのDBの内部動作を見る．
- → 自分のapplicationに適当なengineの選択
- transactionと分析のためのoptimiseの各engineは大きく異なる
- log-structured storage engineと，B木のようなpage指向のstorage engine
3.1 dbを駆動するdata structure
目的
- log: 追記のみできるrecordの並び．
- index
- metadataを追加で横に置いておく
- 追加のdata structure
- dataの書き込みのoverhead. 合わせて更新必要．
- → 要選択
- ↑ 書き込みは低速
対応
- !1 hash index
- K=V store: dict型に似ている
- 図3-1: inmemory hash mapでindexづけ
- e.g. Bitcask
- 図3-2: K-V更新ログのcompaction
- 図3-3: compactionとsegmentationのマージを同時実施
- 詳細
- fileformat
- recordのdelete
- tombstone
- crashのrecovery
- 部分レコードへの対応
- checksum
- concurrency control
- 追記のみの利点
- hash table indexの制約
- key数多いとメモリ内に収まらない． → disk上は遅い．
- 範囲へのquery効率×．
- !2 SSTableとLSMTree
- keyでsort
- → Sorted String Table. → SSTable
- SSTableのメリット
- 図3-4: merge容易．merge sortと似ている．
- indexが疎でよい．
- 圧縮可能．disc領域とI/O band削減
- !!1 SSTableの構築と管理
- inmemory tree: memorytable
- !!2 SSTableからLSMTreeの作成
- !!3 performanceのoptimise
- bloom filter: 集合の内容の概要を保持．メモリ効率〇．
- sizeごと，levelごとのcompaction.
- SSTableをバックグラウンドでマージ．: simple and effective.
- memory両の制約なし
- 範囲へのquery〇
- 書き込み: sequencial
- keyでsort
- !3 B Tree
- log-structuredよりgeneral(ほとんどのDBの標準)で，全く異なる
- K-V pairをsortして保持することのみ似ている．
- log-structuredはsegmentに分割 ←→ B Treeは固定サイズのブロックやページに分割
- 図3-6: B Tree indexのkeyのlookup
- root, leaf page
- baranching factor: 子ページへの参照数．一般的には数百．
- 図3-7: ページ分割
- treeはbalanced → n個のkeyのB Treeの深さは常にO(logn).
- およそ3から4の深さで収まる．
- !!1 B Treeのtrustnessを高める
- その場でファイル変更 ←→ LSMTreeなどlog型の構造のインデックス
- crash耐性のため，write-ahead log (a.c.a. WAL, redo log)
- concurrency control ← latch(軽量ロック)で保護
- → log-structuredのapproachの方がシンプル
- !!2 B Treeのoptimise
- crachのrecovery
- keyの短縮
- disc上の場所 ←→ LSMTreeはsequencial
- 追加のポインタ: 隣接ページ
- fractal treeなど，B Treeの変種
- !4 BTreeとLSMTreeの比較
- 大まかにはBTreeの方が成熟している．
- LSMTreeはperformance特性〇．
- writeが高速 ←→ BTreeはreadが高速
- !!1 LSMTreeのメリット
- !!2 LSMTreeのデメリット
- compactionがrunningのread/writeに影響しうる．←→ BTreeは高percentileも予測しやすい．
- 高p値が極めて高くなりうる．
- compactionでwriteのthroughput増大しうる
- writeのペースとcompactionのペースの不一致への対応 → 明示的にモニタリング
- BTreeは，keyがindex中の1か所のみある．
- → 強いtransactionのsemanticsに〇
- ↑ keyの範囲でロック．
- compactionがrunningのread/writeに影響しうる．←→ BTreeは高percentileも予測しやすい．
- !5 その他のindex構造
- ここまでのK-V indexは，PKのindexのようなもの
- secondary indexも使われている．
- 同じkeyをもつ行への対応
- BTreeやlog-structuredなindexをsecondaryにも使える
- !!1 indexへの値の保存
- heap file: 行が保存されている場所．非cluster化index
- data のコピーを回避
- cluster化index: index内に行を直保存
- PKに使われる． @ MySQL, SQL Server
- 中間: covering index. a.c.a. 付加列を持つindex
- 一部の列のみindexに持つ．
- clusterかindexやcovering indexは，読み取り高速，書き込み中速
- transaction保証の負担もある．
- heap file: 行が保存されている場所．非cluster化index
- !!2 複合index
- 連結index: 複数フィールドを1つのkeyとする
- keyの部分の検索には使えない
- 多次元index
- 2次元を単一数値に変換
- RTree
- e.g. PostGISは，PostgreSQLのGiST(Generalized Search Tree) indexの機能を使ったRTree．
- → 地理空間index
- 地理に限らず，多parameterなほかの例にも使える．
- 連結index: 複数フィールドを1つのkeyとする
- !!3 全文検索とあいまいなindex
- !!4 全データのメモリでの保持
- discはdataの配置が重要 for performance
- 永続性，容量あたりコスト安が〇
- → RAMが安くなり，コストのメリットが薄れている
- → inmemory db
- inmemoryのperformanceのメリット
- memory内のdata structureをディスクに書く形式にエンコードするoverheadを回避できること．
- performance以外のメリット
- disc baseでは実装困難なデータモデルの提供
- e.g. Redis: priority queueや集合などのdata structureに対するDBのようなインターフェースを提供
- disc baseでは実装困難なデータモデルの提供
- anti caching approach
- 使えるメモリより大きなdatasetをサポート．
- swapfile @ OS よりeffectiveにmemoryを管理 by db
- indexはすべてmemoryに収まる必要
- 使えるメモリより大きなdatasetをサポート．
- 不揮発性memory(Non-Volatile Memory, NVM)が広まれば，さらなる変化が見込まれる．
- discはdataの配置が重要 for performance
3.2 transaction? analyze?
目的
- transaction ← commercial transactionから
- 必ずしもACIDという意味ではない
- Clientが低latencyでr/wをするということのみ意味する
- ↑→ batch処理
- OLTP: OnLine Transaction Processing
- interactive
- ↑→ data analyze: OLTPとはaccess patternが大きく異なる．
- 大量レコードのスキャン．要約統計（レコード数，合計，平均など）を計算．
- → Business Intelligenceの向上のためのレポートに含まれる．
- a.c.a. OLAP(onLine Analytic Processing)
- 表3-1: OLTP, OLAPの違い
- 別個のDB: Data Ware House, DWH
対応
- !1 DWH
- OLAPがOLTPに負荷をかけないようにしたいという要件
- ETL(Extract-Transform-Load)で，OLTP dbからOLAP dbにロードする．
- 図3-8: 概略
- 大企業，多くのOLTP systemをもつ， でDWHをもつ
- DWHを分析的なaccess patternにoptimise
- !!1 OLTP dbとDWHの違い
- !!2 Star, Snowflake
- 多くはStar schema(a.c.a. dimension model)
- 中心はfact table
- 図3-9: e.g.
- dimension table
- table同士のrelationの可視化 → factをdimensionが加工 → Star
- snow flakeの方が正規化だが，Starの方がシンプルで〇
- 多くはStar schema(a.c.a. dimension model)
3.3 列指向storage
目的
- 例3-1: analytic query
- OLTP: 行指向 ←→ OLAP: 列指向
- 図3-10
- 非relational modelでも使える
- e.g. Parquet ← GoogleのDremelが元．
- document data model
- e.g. Parquet ← GoogleのDremelが元．
対応
- !1 列の圧縮
- 図3-11: bitmap encode
- Big Tableの列familyは行指向
- !!1 memoryの帯域とベクトル化処理
- vectorized processing ← AND, OR
- compaction → 効率〇
- !2 列storageでの sort order
- sort → 圧縮〇
- !!1 複数sort order
- 異なる方法でstore e.g. Vertica
- 列のみが値を持つ ←→ secondary index
- !3 列指向storageへの書き込み
- LSMTreeで書き込み．× BTree
- !4 集計．data cube, materialized view
- materialized aggregates(実体化された集計)
- data cube, OLAP cube: materialized viewに特化したケースで広く利用
- 図3-12: 2次元data cube
- 計算済みにしておく
- 柔軟なqueryには使えない．
まとめ
- OLTP
- discのseekがbottle neck
- OLAP
- discの帯域がbottle neck → 列指向 storage
- OLTPのstorage engine
- log-structured(fileへの追記と古いfileのdeleteのみ), LSMTree
- BTree
- update可の固定サイズのページ集合
- log-structuredはrecent developed.
- sequencialな書き込みに変換 from discへのrandom access
- OLTPのindex構造， inmemory db
- OLAPのarchtecture
- tuning parameterの増減の影響の理解
Ch04 encodingと進化
目的
- 進化性
- data formatやschemaの変更
- rolling upgrade a.c.a. 段階的rollout
- Clientのupdateはuserのtiming
- → 新旧バージョンのコードと新旧バージョンのdata formatがsystem内で共存
- → 後/前方互換性ともに必要
- dataをencodeする多様なformatを見る
- → 新旧dataとcodeが混在するシステムのサポート
- → data storageとの通信でどう使われるか
- e.g. REST, RPC, Message Passing System
4.1 data encodeのformat
目的
- dataを2つのdifferent表現で扱う by program
- memory内: Object, struct, list, array, hashtable, tree
- CPUでのaccessや操作がeffectiveなため
- fileへの書き込み，ネットワークでの送信: 自己完結したbyteの並びとしてencodeが必要
- e.g. JSON documentとしてのencode
- pointerは同一プロセスのためのみ有用
- inmemoryからbyte列への変換: encoding(a.c.a. serialization, marshalling)
- 逆はdecoding(a.c.a. parse, deserialization, unmarshalling)
- serializationにはtransactionにて別の意味もある
- libraryやencode formatには多様な選択肢
- memory内: Object, struct, list, array, hashtable, tree
対応
- !1 Language固有のformat
- !2 JSON, XML, various binary format
- !3 Thrift(Facebook)とProtocol Buffers(Google)
- 同じ原理のbinary encode
- encodeするdataへのschema要
- IDL(If Def. Lang.)
- 図4-2: ThriftのBinary Protocolでencodeしたレコード
- field tagの使用
- → 図4-3: Compact Protocol → わずか34byte
- 図4-4: Protocol Buffers
- !!1 field tagとschemaの進化
- schema: 時とともに変化は避けられない → schema evolution
- → 互換性のため，field tag が必要
- 新しいfieldは初期値などの必須は不可．
- !!2 data typeとschemaのevolution
- Protocol Buffersのrepeated → 図4-4
- Thriftには専用のlistdata typeあり
- nested listをサポート．
- !4 Avro(Apache Avro)
- ThriftがHadoopのUCに合わなかったことで開発．
- Avro IDLとJSON baseの2つのschema language
- tag no. なし
- decodeは書き込みと全く同じschemaが必要
- !!1 writerのschemaとreaderのschema
- writerとreaderの同一性不要．互換性あればOK
- → libraryが2つを並べて writer → reader変換
- 図4-6: 解決
- !!2 schemaの進化の規則
- union型: null含めた型指定．
- fieldの変更
- !!3 writerのschemaとは
- どうreaderが知るか
- 大量レコードなら戦闘で1度渡す
- schemaのバージョンのリスト
- networkでのnegotiation
- どうreaderが知るか
- !!4 dynamicに生成されたschema
- Avro: dynamic生成 schemaと相性〇
- relationalなschemaからAvroのschema生成容易．
- → dbの内容をAvroのobject Container fileにdamp可
- db schemaの変更 → Avroでは自動変換．ThriftやPBでは手動にtag割り当て必要．
- relationalなschemaからAvroのschema生成容易．
- Avro: dynamic生成 schemaと相性〇
- !!5 code generationとdynamic変換
- !5 schemaのmerit
- Thrift, PB, Avro: 実装や使い方が単純なのが◎．
- DBのnetwork protocolからのresponceをdecodeしてinmemoryのdata structureに変換するdriverの例: ODBC, JDBC,API
- binary encodeの長所
- binary: JSONよりはるかにcompact
- schema: documentとしての価値．常に最新
- schemaの互換性をデプロイ前にチェック
- compile時にtypecheck〇 ← code generation
- → schemaのevolution: schema less/ onreadのJSON dbと同様に，ある種の柔軟性を提供しながら，dataへの保証up．より優れたtoolを提供．
4.2 data flowの形態
目的
- processing間でのdata flowを見る
対応
- !1 db経由のdata flow
- !2 service経由でのdata flow: REST, RPC
- 大規模なapplicationを機能の領域ごとに小さいserviceに分割: micro service archtecture(古くはSOA)
- → 各serviceが独立
- !!1 Web Service
- !!2 RPCのproblem
- 場所の透過性の抽象化における根本のproblem
- remote serviceとlocal objectは根本から異なる
- → RESTはnetwork protocolであることを明示していて〇．
- !!3 現在のRPCの方向性
- !!4 RPCのdata encodingとevolution
- !3 非同期のMessage Passingによるdata flow
- RPCとdbの中間
- message broker(a.c.a. message queue, message try middleware)
- db的
- messageが低latencyでdeliver: RPC的
- RPCに比べたmessage brokerのメリット
- 信頼性up by buffering
- messageのロスの回避 by resend
- 宛先の完治不要
- 複数宛先に送信可能
- 送信と受信を論理的に分離
- 一方，RPCとことなり単方向communication ← 非同期
- !!1 message broker
- !!2 distributed actor framework
- actor model: 単一のprocessing内での並行処理
- actorにカプセル化するprogramming model
- → distributed actor framework: applicationを複数ノードにscale.
- 場所の透過性〇
- ↑ 単一processingですらlossを考えているため
- message brokerとactor modelを1つのframeworkに統合
- e.g.
- actor model: 単一のprocessing内での並行処理
まとめ
- encodingが効率性, archtecture, deployの選択に影響
- 進化性のためのrolling upgrade
- 互換性
- data encode formatと互換性についての特性
- data flowの携帯
- ↑ data のencodeが重要な多くのケース
