Beam Summit 2020 #1
Beam Summit 2020とは
- 2020/08/24~28に行われた、Beamのオンラインイベント
- 2019年は、Beam Summit North America 2019 - YouTubeとBeam Summit Europe 2019 - YouTubeがあった
- 録画もある
- 英語
聞いてみたセッションの話
Program | Beam Summit多いので選ぶの大変…
- タイトル通り、Beamの歴史の話・今やっていること・今後やりたいこと
- プロジェクト状況（現在のチケット状況やコミッター）
今やっていること
今後やりたいこと
- 言語またいだTransform
- C#
- 操作性の向上（スナップショット・Stateの異動・failoverやbackfill）
- ループ（今も出来るけどBeam modelぽくした）
- CEP(複合イベント処理 - Wikipedia)（何かよくわらかん）
- 最適化の向上
- Retractions（これ？Retractions in Beam - Google ドキュメント）
- BeamのPMC二人と、Googleの人
- BeamにあるStateの話ではなく、Beamの全体像・アーキテクチャの話
- 従来とPortable Frameworkの違い（SDK HarnessやBeamとRunnnerの連絡など）
- Beamを便利にするためにやっていること（Jupyterとうとう）
- 各言語のSDKの状況
- IO Connector(SnowFlake, Spanner, 各ConnectorのSplittableDoFn化)
- 各Runnerの状況（Spark, Flink, Dataflow）
Streaming Systems: The What, Where, When, and How of Large-Scale Data Processing読んだ(1)
数少ない（唯一？）Dataflow/Apache Beam本で、著者はGoogleでDataflowの開発していた人です。
良かった
- 個々の話題は、Streaming 101: The world beyond batch – O’ReillyとかBeam Programming GuideとかGCPブログに載っている情報が多いですが、まとまって読める
- 最後の章（Chapter10）で、ストリーミングの仲間たち（Spark/Storm/Flink/Beam/Dataflow…）の流れをつかめる
- Dataflowの裏側の情報も一部載っている
（watermarkの計算とか）
悪かった
Dataflow・Beamの本ではなくてStreaming Systemsな本です。
具体的には、
- Beamに（今は）無い機能がシレッとあったりする
（Acuumulating modeのRetractingとか） - Beamでよく使う機能(いわゆるCore TransformationsとかCoder)の説明がなかったりする
- Streamingに関係ない説明はバッサリ省略されている（デプロイとか）
ので、この本だけでDataflow/Beamを学習するのは難しくてBeam Katas/Beam Programming Guideあたりも読んだ方いいと思います。
Apache Flink眺めてみる
streamingsystems.netでApache Flinkがやたら褒められていたので、Flinkが気になってきた夏の日です。
Apache Flinkとは
ストリーミング処理が行えるフレームワークで、カテゴリー的には
あたりの仲間です。
独立でも使えますが、Apache BeamのRunnerとしても使え、かつApache Beam Capability Matrix的にはDataflowと同レベルのサポートです。
2011年からいるので、結構な古参です。
#FlinkForward SF 2017: Kenneth Knowles - Portable stateful big data processing in Apache Beam
面白げな機能
Dataflowでいいじゃんとなりそうですが、↓のような差別化がありそうです。
- 実行環境を色々（Kubernates/Local/Hadoop…）選べる
（DataflowはDataflowでしか動かない…） - Portability Framework Roadmap（※）
（Support Matrixを見ると2020/8時点だとDatalfowより対応すすんでます） -
State（※※）
- Backpressure
- マスコットがかわいい
※Runner/言語でポータブルに出来るなにか。Beam Stockholm 2019 - Portability Framework - Google スライドがわかりやすい
※※ BeamにもStateがありますが、より柔軟に使えそうな印象
マネージドサービス
※「 Apache Flink をベースとしたオープンソースライブラリが含まれている」らしい。完全互換なのか知らないので詳しい人教えてください
事例
有名企業むっちゃいます。
日本企業の例は↓
学習リソース
みんな大好き公式ドキュメント
O'reillyから本がでています。
困った時のUdemy
Flink Forward
Building production-ready data pipelines using Dataflow: Deploying data pipelinesのメモ
cloud.google.comデプロイに関するノウハウ記事で、気になったところのメモです。他の章のメモはこちら。
Streamingだと全般的にジョブの更新面倒そうなのが辛い‥Flinkとかだと違うのでせうか。
CI/CD
CI/CDの一般論的な話も多いですが、
- DirectRunnerによるテスト
- BatchはCD出来るが、Streamingはジョブの置き換えがある関係で大変
- CI/CDに必要な権限
などのDatalfow固有の話題が紹介されています。
テンプレート vs 普通のジョブ
Dataflow テンプレートのドキュメントでは、パイプラインの起動が楽になるなどのメリットが紹介されていますが、こちらのドキュメントでは、
- batchジョブでは、ジョブが繰り返し起動される事が多いのでテンプレートが向いてる
- Streamingジョブでは、長時間実行され続ける（ので起動回数が少ない）、テンプレートではジョブのupdateがサポートされないので、普通のジョブが向いている
と、バッチとストリーミングで向き不向きがあると紹介されています。
Streamingジョブの更新
Streamingは動かし続けますが、いつかはコードを変更する必要が出てきます。
その時の選択肢として
が紹介されています。
Dataflowジョブのライフサイクル
Dataflowのジョブがサブミットされて、ワーカーで処理されるまでの流れが紹介されています。
特に、シャッフル（GroupByKey,Combine,CoGroupByKey）は、
- 通常はワーカー・そのディスク上で処理される
- Streaming Engine/ Shuffleの場合は、ワーカーの外で処理される
ことが紹介されています。
ベストプラクティス
（いずれも要件・コスト次第だとは思いますが）
- 複数リージョンに依存しないようにする
- ワーカーの指定には、ゾーンよりリージョンを指定するようにする（起動時にいい感じに選んでくれる？）
- ただし、ジョブが起動してからはゾーン依存なので注意
- リージョン死んでも大丈夫なように、GCSやBigQueryにデータ入れとく
- リージョン依存の障害が起きたとき、バッチの場合は建替えが無難
- ストリーミングは待つくらいしかないが、強く必要な場合は、独立したリージョンに、ソース、パイプライン、シンクを冗長化しておく
July Tech Festa
イベント自体は知っていましたが初参加。
感想
- インフラエンジニアの勉強会（Peatixかどこかに記載あったはず）だと思っていますが、キャリア一般とかフロントエンドとか範囲広いのですね。
- 資料を事前・事後に（SpeakerDeckなどで）共有してくれる方が多いのが、凄いく嬉しいです
特に、オンラインイベントだと文字が潰れて見にくい事もあるので。 - C4の「凡人エンジニアの生存戦略」が特に印象に残っています
（ちょうど自分も同じような焦燥感を‥）
運営、登壇者の皆様お疲れ様でした
TrackC1 テクニカルサポートエンジニアという働き方 - 技術と英語で立ち向かうOSSとエンタープライズの世界
しがないラジオでお話聞いたことがあるお方。
- ひよこ大佐の経歴（国内サポートエンジニアー>SES->レッドハット）
- これまでのスキルを転職で活かす。特にスキルの掛け算大事
- スキルを増やすには、知的好奇心とキャリアに関するオーナーシップ
- ひよこ大佐さんの仕事（テクニカルサポートエンジニア、TSE）の話
（関連する技術の話も多い） - 英語の話（レッドハットのTSEは英語必須。チーム・お客さんともに）
- 広範な知識がいるので、SIer時代に色々触っていたのが生きている
- RedHatとOSSとの関わり
- トラブルシューティングの方針（重要度、再現、似たような事例‥）
- 切り分け大事
- ログ大事。ちゃんと読もう
TrackG2 プロジェクトチームで取り組む実践的なクラウドコスト最適化
Sansan DSOCの大澤さん。
- Cloud Cost Optimization Engineer（という肩書らしい）
- AWSコスト最適化の同人書いたよ。商業誌も出るよ
- SansanとDSOCの紹介
- コスト最適化の歴史
- システム規模以上にコスト増大
- アカウントに複数システムあり、コスト追跡が難しかった
- 予測困難
- トップダウンでプロジェクトチーム
- AWS Well-Architected Frameworkに沿っている
↑おすすめらしい - やったこと
- リソースにコスト配分タグ（チーム単位）付けて、追跡出来るように
- タグ付け大変なのでAWS Lambdaで自動付与（名前から推測。ただし間違う部分は手動）
- AWSアカウント構造の話。素直にやるならマスターアカウントが必要で大変
- Cost and Usage Report(CUR)＋Athenaで対応
- redashでAWS/GCPのコストの両方を可視化
- TCO（総保有コスト）と費用対効果を意識して、優先度付け
- 事例1：DynamoDBとの通信がNAT Gateway経由になっていた
- 事例2：DynamoDBをキャパシティモードからプロビジョニングモード
- 事例3：Auroraのストレージ容量の削減（自動でストレージ容量増えるが、使用量減っても容量減らない）
- 事例4：Glueジョブの見直し（間隔、不要なジョブの削除）
- コスト最適化の評価は削減額で評価（難しそう‥）
使用量や名刺一枚のデータ化に関するコスト - コスト最適化スキルは（パブリッククラウドに関する）エンジニアには必須スキル
- ↑クラウドに対するりかい、自分たちのシステムに関する理解が必要。
TrackF3 バックエンドエンジニアの私がお勧めするSPAフロントエンド開発環境
ハートビーツの渡辺さん。
- バックエンドの人がフロントにキャッチアップするの辛いよね
- 自分用のボイラープレート作っておいて、作り回しているよ
- React/MobX/TypeScript/MaterialUIあたり
TrackC4 凡人エンジニアの生存戦略
ソフトバンクの高市さん。SonarQube本の著者。
- プログラミング超好きというわけではなく、 若手キャリアの焦燥感を感じていた
- まつもとゆきひろの「プログラマー勉強会」
- 自分を知ってもらうことで価値があがる
（観測可能な成果） - 締め切り駆動で公開
- 発表するために調べるので、どんどん知見が広がる
- Trellloつかって定期的に振り返り
- 努力を習慣化するために頑張る
- 習慣化する数を少なく、それぞれの目標を小さく
- 根性論より人間の習性に従う
- 他人と比べない
- 短所より長所を見る
- 後知恵バイアスを気にしない
（私もまつもとさんの勉強会見て、Twitter始めたりしました）
TrackG5 クラウド時代の今こそ！理解して拡げる分散システムの基礎知識
こば（@tzkb）さん。Fukabori.fmとかQiitaとかでお見かけ。
- DXとかクラウド
- マイクロサービスの話
- DBを共有していると拡張性などに影響（するのでマイクロサービスと言いたくない）
- かといって、DBを分割すると分散トランザクションが生じてくる
- マイクロサービスでトランザクションを実行するSagaパターン
- それぞれのサービスがローカルトランザクションし、問題があったらそれぞれロールバック
- そのままではACIDのうちIsolationが満たせない（ローカルトランザクションされたら覗ける）
- 分散・マイクロサービスにしても、スケールするとは限らない
- 特にステートフルなDBが危ない
- 対応1)single leaderのreadのreplication
（writeがスケールしない。非同期な同期が耐障害性が低い） - 対応2)Multi-Leader(Viess, Oracle RACなど)
- 地理的な拡張性
- 東京大阪で20msくらい、海外まで行くと100ms程度かかる
- 量的・地理的な拡張性のあるデータベースの例
Spanner、Cockroach、Yugabyte、TiDBなど - シャード（テーブルの分割）毎にリーダーがいる
Building production-ready data pipelines using Dataflow: Planningのメモ
開発前に気にすることが紹介されている資料のメモです。他の章のメモはこちら。
サービスレベル
Data Freshness
何％のデータが時間内で処理される、未処理の一番古いデータがある時間、パイプラインが一定時間内に終るなどの指標。
Data correctness
開発時はユニットテスト・結合テスト（Building production-ready data pipelines using Dataflow: Developing and testing data pipelinesで説明）で確認。
Data isolation/load balancing
重要度の異なるメッセージを処理する時、パイプラインを分けた方がやりやすい。
ソースとシンク
スケーラビリティを確保するために、ソースとシンクに関して
を気にする必要がある
外部システムの負荷を減らすためには、batching（element毎に呼ぶのではなく貯めて呼ぶ）や、ワーカー増えると外部サービスの呼び出しも増える事に注意。
リージョン
- ソースやシンクの近く
- 法的な制限
- 特定のリージョンしかサポートされていない機能(Shuffle,Streaming Engine)
などで決定。
ワーカーとEndpointは別に設定出来るが、同じにした方が良い（特にStreaming EngineとShuffle）。
暗号化とネットワーク
