Google Cloudに おけるバッチ 処理基盤の選定ヒント

わたしが携ってきたお客様案件におけるノウハウです。

Transcript

1. Google Cloudに おけるバッチ 処理基盤の選定 コスト・自由度・信頼性・依存関係について 2021-2 yutaro KAMENASHI
2. 目次 1. 概観 ベストプラクティスなどない 2. コスト 3. 自由度 4. 信頼性 5. 依存関係 6. 総論
3. 1. 概観 ベストプラクティスなど無い まず断っておきます。ベストプラクティスというのは、お客様自身が見出し、お 客様ごとに発生するものです。 たとえば、仮に「メルカリ」社で適用できたDataWareHouse(DWH)のプラク ティスが、あるとします。 これを、たとえば中小企業、八百屋さんに適用したとしましょう。 資本のサイズも調達可能な人員も、まったく異なります。 そもそも八百屋さんはGoogle Cloudを必要としているでしょうか？ さあ、商談を考えましょう。
4. 2. コスト 石油王だろうと、日雇いの現場鉱夫だろうと、絶対に避けては通れないのが、コ ストです。 技術者はコストを度外視する傾向にあります。あるいは、デスマーチの経験から 過剰にコストを見積もる傾向にあります。 口で言うだけは誰だってできるわけです。 地に足をつけたコスト計算をすることができるのが、よいシステムエンジニアと 言えるでしょう。 よって、Cloud Scheduler、Cloud Tasks、Airflow、Cloud Workflow、 Cloud Composer、JP1/AJS、Systemwalker Operation Managerなどか ら、お客様のコスト要件にあったものをまず選定します。
5. 3. 自由度 もうこれはGoogle App Engine(GAE)とKubernetes Engine(GKE)、 Compute Engine(GCE)の関係とまったく同じです。 ようするに、クラウドベンダー側に寄せれば寄せるほど運用コスト(金額)はス ケールメリットにより下がり、自由度(すぐ止めたいとか、すぐリリースしたい とか)はどんどん下がります。 全てを自分でコントロールしたい方に、パブリッククラウドは向いていません。 オンプレミスで構築しましょう。
6. 4. 信頼性 Googleといえど、人の集まりです。 Googleがコロナ禍の発生を予測できなかったことからわかる通り、Googleは神 ではありません。 神ではないから、SLAというものを設定し、返金ポリシーで代償を贖う、と定め てあるわけです。 よって、100% SLAというのはCloud DNS以外にありません。(なんで可能な の？) ゆえに、コスト・信頼性・自由度のトレードオフで、再実行、失敗の通報などを 設計します。
7. 5. 依存関係 たとえば、既存ベンダーとお客様の契約があり、JP1/AJSを使わざるを得ないと します。 これをGoogle Cloudのプロダクトに恣意的に変更するように誘導するのは、悪 手です。 自分がわからないからといって、お客様にとってそのツールが重要でないかどう か決めてはいけません。 それを決定していいのはお客様です。私達ではありません。 Airflowに依存しているのであれば、Composerで代替できる可能性はありま す。
8. 6. 総論 1. Google Cloud Pricing Calculatorでまず予算に収まるのかどうか確 認しましょう。 2. 予算が十二分に余っていれば、お客様のワークロードを試算に追加しましょ う。 3. さらにデータ分析基盤の予算も追加しましょう。 4. それでもなお、バッチ基盤に割ける予算が残るのなら。そこで初めて、 Kubernetes Batchやら何やらが選択肢に入ってきます。バッチ着火装置 の優先度は低いはずです。とにかく低いはずです。 5. 以上。