ふつうのデータ基盤移行 - Part 1. 戦略策定編
このポストについて データ基盤移行について書かれた各社の技術ブログなど見かけることがありますが、割とさらっと書かれていることが多いように思います。 本当はいろんな面で苦労があり、記事に表れていない辛さや工夫などがあるはず。 ということで今自分が経験している普通の会社の普通のデータ基盤移行について、詳しく記事にしてみようと考えました。 何回かに分けてデータ基盤移行のいろいろな側面を、うまくいったこともいかなかったことも含めて書いていきます。 とはいえ現在進行形なので、全編書き終わるのはかなり先になりそうです。 移行の背景 組織 まずイメージしやすいよう、どういった組織におけるデータ基盤移行なのかについて軽く触れておきます。 社員規模: 〜100名 web 系の B2C ビジネス データチームの構成 マネージャ: 1名 (データエンジニアリングの経験はほぼない) データエンジニア: 2 -> 3名 (途中で採用) 中小のベンチャー？企業ではありますが、意思決定プロセスは JTC 感があります。 私はデータエンジニアのポジションとなっており、その視点からの話であることにご留意ください。 小さい組織ということで私は移行の計画から設計、開発その他のあらゆるフェーズに中心的に関わっています。 どこもそうだと思いますが、人員的にはまあまあきびしい。 よくある中小 IT 企業のよくあるデータ基盤移行の話だと思っていただきたく。 大企業ではないのでそこまでちゃんとはしていません。 (ちなみに自分のブログで本件を記事にしていいかは上長に確認の上、OK をもらっています) 旧データ基盤 一連のポストでは移行前のデータ基盤のことを「旧データ基盤」と表記するものとします。 旧データ基盤は AWS 上で構築されており、アーキテクチャについて簡単に挙げると storage: S3 ETL: Glue Job, Athena SQL engine: Athena workflow orchestration: MWAA のようになっていました。 旧データ基盤の開発・運用側 (データエンジニア) としても、また社内の利用者側としてもいろいろと問題が挙がってきてはいました。 しかしそれをうまく集約・言語化できていないという状況でした。 そんな中でエライ人の鶴の一声で移行しようぜ！ということになり、データ基盤の移行を検討することに相成りました。 移行計画を考えるにあたり まず考えたこと データ基盤の移行は組織におけるデータマネジメントにおいて重要な位置づけとなるはず。 したがって単なる技術スタックの置き換えというスコープで考えるのはもったいないです。 組織のデータマネジメントの未来を想定して、戦略を持って開発・運用を進めるべきであると考えました。 そのためにはイシューを明確化しないといけません。 でもどの抽象度レベルで？ ボトムアップの戦術策定 まずは現場感覚、ボトムアップでの課題を明らかにすることを考えました。 本来は後述する戦略レベルから先に考えるべきですが、実際に目に見えている課題があり、取り組みやすかったというところで戦術のレベルから考え始めています。(良し悪しはある) 現状のアーキテクチャと運用では戦略策定への対応が難しいため、せめてそのための地ならしとして今見えている課題に対応できる状態にしたいというのもありました。 ...