データ基盤移⾏のリアル スタートアップにおけるデータ分析基盤移⾏の実態 2023-12-13 Snowflake Technical Round Table 越境(@contradiction29)

⾃⼰紹介 ● 株式会社Algoage ○ 社員数150名ほどのスタートアップ ○ 主⼒事業：チャットブーストCV（アドテク系） ● 普段のお仕事 ○ データエンジニア‧アナリティクスエンジニア ○ データプラットフォーム統括チームのマネジャー ● Snowflake‧dbt‧dagsterあたりが好き ● 東京在住 ○ 「健常者エミュレータ事例集」の管理⼈ ○ ↑ググると出てくるので調べてみてね 越境 @contradiction29

やりたいこと ● データ基盤移⾏のリアリティを伝えたい ○ えぐめの話（政治権⼒の集中過程） ○ テクニカルな話（技術選定のポイント） ○ リアルな話（実際の進⾏上気をつけなくてはいけないこと） ● スタートアップならでは感はある ○ 参考程度にしてください

参考：旧データ基盤の全体像と管轄範囲

基盤移⾏のモチベーション ● 開発者体験が悪い→ユーザーからのニーズにすぐ応えられない ○ ⼀⼈エンジニア体制なのにgit-flow ○ JSONを展開するためだけのGlue Job ○ エラーの頻発するAmazon Athena ○ テスト環境が悪すぎて本番環境でテストする有様 ○ コードレビューすらままならない ● 運⽤がつらい→本質的な価値追求に時間を使えない ○ 事故った時の復旧が⼤変 ○ その割によく事故る ● 迫り来るEOSL→そもそもシステム全体が⽌まる ○ Athenaのパーティション制限とテーブル設計のミス ○ あと半年くらいで重要なテーブルが使えなくなる⾒込み → 腹を括って移⾏を決意 https://nvie.com/posts/a-successful-git-branching-model/

データ基盤移⾏に必要な政治権⼒の集中 ● Before : ○ データ基盤に関する権限がプロダクト本体チームとデータチームで分散されていた（先述） ○ 現実はそんなに綺麗に分割できるはずもなく、開発⽅針が決まらずgdgd化 ■ 例）インフラまで踏み込んだ開発はできない ■ 分割の指⽰を出したのは⾮エンジニアのマネージャー ● After： ○ データ基盤に関するすべての権限をOps-dataチーム（⾃分たちのチーム）で掌握 ○ 全権限を⼀つのチーム内で掌握したことにより、移⾏の下準備が整った ■ システムを丸ごと取っ替えるつもりなら、強めの権限が必要 根回し＋実⼒⾏使によりマネージャーの判断を現場でひっくり返す

技術選定：Architecture for Leadership ● 先代アーキテクチャのイケてないところを考えてみる ○ 設計思想がない。根底的な思想がないため、⾏き当たりばったりの改築ばかりやっている ○ 技術選定に合理性がない。外部の「有識者」からアドバイスを受けただけの技術選定をしている ○ 考えたこと：「リーダーシップがとりづらいアーキテクチャになっている。では、リーダーシップのとりやすいアーキテ クチャにすればいいのでは？」 ● 参考思想：Architecture is Leadership（※） ○ 「アーキテクトはリーダーシップとトレーニングを通じて技術的決定を広める役割がある」という考え ○ しかし、技術選定を間違えればArchitecture is Leadershipの実現は不可能 ● 「リーダーシップがとりやすいアーキテクチャ」ってなんだろう？(Architecture for Leadership) ○ 設計思想がある ○ 設計思想に沿っている ○ 技術選定に合理的な説明を加えることができる →まずは設計思想⾃体が必要 ※Reis, Joe; Housley, Matt. Fundamentals of Data Engineering (English Edition) (pp.145-146). O'Reilly Media. Kindle 版.

技術選定：設計思想を練る ● 既存の基盤を運⽤した経験から設計思想をネリネリする ○ 既存の基盤をアンチパターンとして捉え、逆⽅⾯に理想を描けばいい ○ 思想があれば、トレードオフに遭遇しても迷わずに済む ● 詳しくはこちら ○ 【連載】データ分析基盤をdbt‧Snowflakeに移⾏する【移⾏前のつらみと設計原則編】

最終的に出来上がったデータ基盤の設計思想 1. アジリティ重視： 変化するニーズに応え、迅速に価値を提供で きるようにする 2. 運⽤労⼒最⼩化：運⽤にかかる労⼒が最⼩限となり、データ利 ⽤者への価値提供に集中できるようにする 3. 利⽤者⽬線：データ分析基盤の利⽤者への「分析者体験」の最 ⼤化を第⼀の判断基準とする

技術選定：開発フロー‧ファーストな技術選定 ● 開発フローを極⼒シンプルに保つ ○ アジリティの実現のため ○ 運⽤労⼒の最⼩化のため ● シンプルな開発フローを実現できる技 術を選ぶ ○ 開発フロー‧ファーストな技術選定 ○ この過程でSnowflakeが出てくる ○ dbt, dagster cloudも同様の観点で選定 ● ←参考：現在運⽤中の開発フロー ○ GitHub-Flow ○ AIレビューも導⼊済み

移⾏のHow：リスクの排除 データ基盤移⾏に伴うリスクはたくさんある。取るべきリスクに集中するために は、取る必要がないリスクは可能な限り排除する必要がある。 1. タイミングリスク 2. 時間切れリスク 3. ⼈⼿不⾜リスク 4. 資⾦リスク 5. 政治リスク

タイミングリスク ● ⼀般論：すでに稼働しているシステムに対して、数か⽉かけて⼤規模な変更を加えること は躊躇される傾向がある ○ タイミングを間違えれば、メンバーやステークホルダーの離反を招く ● 逆にいうと、タイミングを合わせれば良いだけ ○ ちょうど障害が頻発していた時期 ■ （今考えてみれば暴論だったが）「技術スタックを総⼊れ替えすれば解決するだろ」という論法が説得 ⼒を持ちやすい時期だった ○ Athenaのパーティション数制限（もしくはテーブル設計時の考慮漏れ）により、EOSLまで残り数ヶ⽉ ■ データマート作成に⽤いているAmazon Athena (SQLクエリエンジン）はパーティションの数が100く らいまでしか対応していない →タイミング的には絶好の機会

時間切れリスク ● Athenaのパーティション制限がある以上、時間切れは明確に存在する ○ 設計‧実装に時間をかけすぎれば、移⾏しきらないうちにデータ分析基盤が停⽌ ○ 現場でデータを必要とするユーザーにデータを届けることが不可能となる ○ 開発にかけられる時間は少ない ● 解決策：「曳光弾開発」⼿法を使う ○ end-to-endで動く最⼩構成をまずつくり、機能を拡充しながら段階的にニーズを満たしてい く開発⼿法（出典：『達⼈プログラマー』） ○ データ基盤開発において、最も難易度が⾼いのはend-to-endでうごく最⼩構成ラインの構築 ○ 曳光弾開発＝難易度の⼀番⾼いものから順に解決していく⼿法が⼿戻りの最⼩化に繋がる

技術的リスク ● 技術的なリスクは⼤きい ○ 選択した技術では、⾮機能要件や機能要件を満たせない ○ 技術選択を誤れば構築に時間がかかり、時間切れになる可能性がある ● 解決策：曳光弾開発 ○ ⾮機能要件‧機能要件を確実に満たせる保証をしながら開発できる

⼈⼿不⾜リスク ● 移⾏に伴い多くの作業が発⽣するため、⼈⼿が⾜りなくなることが想定 ○ 今回のケースでは期限の超過がデータ分析基盤システムそのものの停⽌を意味する ○ ⼈員不⾜による遅れは極⼒避ける必要がある ● 対応 ○ 極⼒⼿戻りを抑え、かかる⼈⼿を最⼩限に抑える ■ やっぱり曳光弾開発 ○ ⼈⼿が必要になったタイミングでチームメンバーの助けを借りる ■ チーム内へのスキル普及も同時にできるため、⼀⽯⼆⿃ ■ 事前に頭出しや説得を念⼊りに⾏う必要がある

資⾦リスク ● データウェアハウスやSaaSの費⽤がかさみ、想定を超えてしまうリスク ○ ステークホルダーからの信⽤を失う ● 対応 ○ 無料期間中にしっかり⾒積もりを⽴てる ■ Snowflakeには30⽇分の無料期間と$400分のクレジットがある ■ その間に、ウェアハウスの利⽤料の⾒積もりとストレージ費⽤の⾒積もりをざっくり出 しておく ○ 求められなくても、コストに関する報告は優先して実施する ■ 報告をしっかりしておくだけで、怒られが発⽣するリスクはかなり減る（経験談）

政治リスク ● 政治的な問題により、移⾏プロジェクト⾃体が尻切れトンボになる ○ 例1）チーム内メンバーの協⼒が得られない ■ ⼈⼿を借りられず、時間切れになる ■ 新たな技術を導⼊しても普及しない ■ 通常業務に忙殺され、データ基盤移⾏に稼働時間を割けない ○ 例2) ステークホルダーの合意が得られず、移⾏⾃体が中⽌になる ■ SaaSの利⽤に対して承認が得られない ■ 「鶴の⼀声」で移⾏⾃体が⽴ち消えになる ● 対応 ○ メンバーへの頭出しや根回し、個別の説得 ○ 開発の進捗共有 ○ ⾦の巡りは⾎の巡り

基盤移⾏プロセスの実際の進⾏ 1週間 3週間 1ヶ⽉ ● 技術選定をしながらend-to-endのプロトタイプを構築 ● ELTのうちELの部分を構築 ● 旧基盤のデータを移⾏ ● Tのうち⼀部を構築し、メンバー向けの説明を準備 ● メンバーをサポートしつつ、データマート以降を構築

移⾏した直後の全体像

補⾜：Snowflakeを選んだ理由 ● 選択肢はRedshift, BigQuery, Snowflakeの3択 ● BigQuery→ちょっと⾯倒 ○ バックエンドがAWSなので、⼀⼿間かかる ● RedShift→Snowflakeに負ける ○ ほとんどすべての点でSnowflakeの⽅が良い ■ コスト⾯ ■ 機能の豊富さ ■ 運⽤の楽さ ○ 運⽤の楽さは⾮常に重視しているため、Snowflakeを選んだ ■ 安定性 ■ マイクロパーティショニング機能

移⾏した結果 ● データパイプラインの実⾏時間が約30倍⾼速になる ○ Glue Job, Glue Crawlerなど、時間のかかる処理が無くなった ○ ELTの構成にしたことにより、Snowflake⾃体がもつクエリの速さがフルに活かせるようになった ● 開発速度が（体感）10倍くらい早くなる ○ 開発フローがgit-flowからGitHub-flowになり、変更⼿順がシンプルになった ○ ブランチデプロイが可能になり、データエンジニアリングのコストが下がったこと ○ ローカルでのテスト実⾏が可能になり、検証が容易になった ● 運⽤の労⼒削減 ○ 運⽤コストの⾼いGlue Job (Spark)を排除し、ほとんどの変換処理をSQLで統⼀した ■ チーム内の⾮エンジニアメンバーでも保守‧運⽤できる範囲が広くなった ○ エラー発⽣確率の⾼いGlue Data Catalogを排除できた ■ Snowflakeでは滅多にエラーが起こらない ○ 開発が容易になったたため、「運⽤を楽にするための開発」がしやすくなった

最後に...

これは移⾏した直後（2023年9⽉くらい）の構成図

データ分析基盤は⼀度作り切って終わりではない 変化し続けるユーザーからのニーズに応え、 継続的に作り込み、 発展させていく必要がある ↓ Always be architecting

Always be Architecting ● データアーキテクトの役割 ○ 現状のアーキテクチャに関する深い知識を持つこと ○ 理想的なアーキテクチャを描くこと ■ ビジネスと技術の変化に応じて「理想的なアーキテク チャ」は変わりうる ■ ビジネスと技術の変化にキャッチアップし、常にアー キテクチャを設計し続ける ○ その上で理想と現実の間を埋める計画を策定し、実⾏できる 状態にする ● Google Cloud 5 principles for cloud-native architectureから引⽤ https://cloud.google.com/blog/products/application-development/5-principles-for-cloud-native-architecture-wh at-it-is-and-how-to-master-it?hl=en

3ヶ⽉後にはこうなりました

No content