カーキ色はヒンディー語らしい

技術記事は https://zenn.dev/notrogue

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は動かし続けますが、いつかはコードを変更する必要が出てきます。

その時の選択肢として

  1. ジョブのUpdate
  2. cancelとdrain
  3. (cancelかdrainと組み合わせて)Pub/SubのSeekでデータを戻して再実行
  4. 並行して複数のパイプラインを実行(重複考慮した実装が必要)

が紹介されています。

 

Dataflowジョブのライフサイクル

Dataflowのジョブがサブミットされて、ワーカーで処理されるまでの流れが紹介されています。

特に、シャッフル(GroupByKey,Combine,CoGroupByKey)は、

  • 通常はワーカー・そのディスク上で処理される
  • Streaming Engine/ Shuffleの場合は、ワーカーの外で処理される

ことが紹介されています。

 

ベストプラクティス

(いずれも要件・コスト次第だとは思いますが)

  • 複数リージョンに依存しないようにする
  • ワーカーの指定には、ゾーンよりリージョンを指定するようにする(起動時にいい感じに選んでくれる?)
  • ただし、ジョブが起動してからはゾーン依存なので注意
  • リージョン死んでも大丈夫なように、GCSやBigQueryにデータ入れとく
  • リージョン依存の障害が起きたとき、バッチの場合は建替えが無難
  • ストリーミングは待つくらいしかないが、強く必要な場合は、独立したリージョンに、ソース、パイプライン、シンクを冗長化しておく

 

July Tech Festa

techfesta.connpass.com

イベント自体は知っていましたが初参加。

 

感想

  • インフラエンジニアの勉強会(Peatixかどこかに記載あったはず)だと思っていますが、キャリア一般とかフロントエンドとか範囲広いのですね。
  • 資料を事前・事後に(SpeakerDeckなどで)共有してくれる方が多いのが、凄いく嬉しいです
    特に、オンラインイベントだと文字が潰れて見にくい事もあるので。
  • C4の「凡人エンジニアの生存戦略」が特に印象に残っています
    (ちょうど自分も同じような焦燥感を‥)

 

運営、登壇者の皆様お疲れ様でした

 

TrackC1 テクニカルサポートエンジニアという働き方 - 技術と英語で立ち向かうOSSエンタープライズの世界

しがないラジオでお話聞いたことがあるお方。

  • ひよこ大佐の経歴(国内サポートエンジニアー>SES->レッドハット)
  • これまでのスキルを転職で活かす。特にスキルの掛け算大事
  • スキルを増やすには、知的好奇心とキャリアに関するオーナーシップ
  • ひよこ大佐さんの仕事(テクニカルサポートエンジニア、TSE)の話
    (関連する技術の話も多い)
  • 英語の話(レッドハットのTSEは英語必須。チーム・お客さんともに)
  • 広範な知識がいるので、SIer時代に色々触っていたのが生きている
  • RedHatOSSとの関わり
  • トラブルシューティングの方針(重要度、再現、似たような事例‥)
  • 切り分け大事
  • ログ大事。ちゃんと読もう

 

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のメモ

cloud.google.com

開発前に気にすることが紹介されている資料のメモです。他の章のメモはこちら。

 

サービスレベル

Data Freshness

何%のデータが時間内で処理される、未処理の一番古いデータがある時間、パイプラインが一定時間内に終るなどの指標。

 

Data correctness

開発時はユニットテスト結合テストBuilding production-ready data pipelines using Dataflow: Developing and testing data pipelinesで説明)で確認。

 

Data isolation/load balancing

重要度の異なるメッセージを処理する時、パイプラインを分けた方がやりやすい。

 

ソースとシンク

スケーラビリティを確保するために、ソースとシンクに関して

  • 外部システムのスケーラビリティ(Kafkaならパーティション数など)
  • ファイルフォーマット(並列化出来るか)
  • データやネットワークのロケーション
  • GCPのサービス)クオータ

を気にする必要がある

外部システムの負荷を減らすためには、batching(element毎に呼ぶのではなく貯めて呼ぶ)や、ワーカー増えると外部サービスの呼び出しも増える事に注意。

 

リージョン

  • ソースやシンクの近く
  • 法的な制限
  • 特定のリージョンしかサポートされていない機能(Shuffle,Streaming Engine)

などで決定。

ワーカーとEndpointは別に設定出来るが、同じにした方が良い(特にStreaming EngineとShuffle)。

 

暗号化とネットワーク

  • デフォルトで暗号化するが、KMSでカスタムの暗号化キーを使えるよ
  • プライベートIPアドレスに出来るよ(ただしPrivate Google Accessが必要)

 

Building production-ready data pipelines using Dataflow: Overview 読んだ

Googleが2020/6月に公開したDataflowの記事が勉強になったのでメモ。

 

 

開発

cloud.google.com

 計画

cloud.google.com

自分のメモ

not-rogue.hatenablog.com

 

 

デプロイ

cloud.google.com

自分のメモ

not-rogue.hatenablog.com

 

 

モニタリング

cloud.google.com

 

 

Apache BeamのDoFnで匿名クラス使う時はSerializableに気をつけようという話

BeamでDoFn書く時に、↓のように匿名クラスを使って書けます。

PCollection<Integer> wordLengths = words.apply(
  "ComputeWordLengths",                     // the transform name
  ParDo.of(new DoFn<String, Integer>() {    // a DoFn as an anonymous inner class instance
      @ProcessElement
      public void processElement(@Element String word, OutputReceiver<Integer> out) {
        out.output(word.length());
      }
    }));

  しかし、Beam Programming Guideを良く見ると

 Take care when declaring your function object inline by using an anonymous inner class instance. In a non-static context, your inner class instance will implicitly contain a pointer to the enclosing class and that class’ state. That enclosing class will also be serialized, and thus the same considerations that apply to the function object itself also apply to this outer class.

という注意書きがあります。

  • BeamのDoFnはSerializableである必要がある(ワーカーに送るので)
  • Javaの匿名クラスは、enclosing class(匿名クラスを含んでいるクラス)への、暗黙の参照を持つ (参考: SER05-J. 内部クラスのインスタンスをシリアライズしない
  • ので、enclosing class(とそのフィールド)はSerializableである必要がある

というわけです。

 

気をつければ大丈夫な話ですが、

  • 引っかかりやすい
  • ネストが深くなるので見にくい
  • 匿名クラスの部分のテストしづらい

ので、DoFnを書く時、私は匿名クラスとしては書きたくない派です。

Airflowの動的なDAGでclearする時の話

ハマったのでメモ。(Airflow 1.10.2/Cloud Composer)

 

状態

  1. Airflow Variableにも基づき、Airflowのタスクを動的に作成していた
    Apache Airflow: Create dynamic DAG – Big Data & ETLのようにタスク外の部分でループしている感じ)
  2. DAG Runが実行・修了
  3. Airflow Variableを修正し、DAGにタスクインスタンスが追加される
    (Airflow Variablesの変更によって追加されたTaskはstatusが空欄)

通常はclearでTask Instanceを再実行する事ができますが、今回の場合は対象のTask Instanceをclearしても実行されません。

 

 

f:id:toukoudo:20200712075431p:plain

Task Instanceが増えた状態のDAG Run

 

f:id:toukoudo:20200712075528p:plain

増えたTask Instanceをclearした時のエラー

 

対応

  1. 対象のTask Instanceを「Mark Failed」にする
  2. 対象のTask Instanceをclearする
  3. DAGがRunningになり、Task Instanceが実行される

増えたTask Instanceが複数ある時、どれか一つで1・2を実行すると、追加されたTask Instanceは全て実行されます。

 

原因

  1. AirlfowはDAG Run・Task InstanceをDBのレコードとして持っている
  2. clearを実行すると、Airflowは、Task Instanceのレコードを探しステータスを変える
  3. DAGが変化した時、過去のDAG Runに対応するTask Instanceのレコードは追加されない(下図)
    (画面からは追加されたように見えますが、見えているだけ)

ので、DAGが変化してTask Instanceが増えた時、増えたTask Instanceは単純にはClear出来ないです。

 

f:id:toukoudo:20200712081324p:plain

Task Instanceが増えた状態のtask_instanceテーブル

 

しかし、前述の対応を取ると、

  1. Mark Failedすると、対象のTask Instanceのレコードが出来る
    (=Clear出来るようになる)
  2. ClearするとDAGがRunningになり、StatusがSuccessでもFailedでもないTask Instanceがスケジュール・実行される
    (=増えたTask Instanceが実行される)

となり、増えたTask Instanceが実行されます。

 

f:id:toukoudo:20200712081347p:plain

MarkFailed&Clear後のtask_instanceテーブル

 

 

 

今日聞いたPodcast: Materialize (Software Engineering Daily)

softwareengineeringdaily.com

概要

  • テーマ:Streaming SQLエンジンのMaterialize
  • ゲスト:開発元の創業者Arjun Narayan(元Cockroach)と、Frank McSherry(元Microsoft

 

materialize.io 

Materializeの説明

What is Materialize? とかArchitecture OverviewとかWhat’s inside Materialize?がわかりやすいです。

  • ストリーミングデータ(Kafka)、RDBの両方のデータにSQLを投げられる
  • (DBのデータはDebeziumでChange Data Capture可)
  • 普通のクエリも使えるが、materialized viewにすると継続的に更新し続けることができる(かつ早い)
  • PostgreSQL互換のSQLが使える(大変だったらしい)
  • Cloudサービスだけを提供

 

Streamingの話

Materializeの歴史

Microsoftのnaiadプロジェクトが源流

その後Microsoftがプロジェクトを解散。しばらく後に、Materializeが生まれた。

 

 

その他・感想

  • スクリプト見ると30ページあってスゴイ。聞くだけで理解出来なかったけど、そんだけ長ければ‥
  • 他のStreaming系(Apache Druid、Spark SQL、Beam SQL‥)との違い・使い分けが気になる
  • 事例的な物ってあるのだろうか
  • 人はなぜプロダクト名に一般名詞を付けるのか(検索しづらい)