トップ > Data Management > データプラットフォーム統合プロジェクトの紹介


データプラットフォーム統合プロジェクトの紹介

Data Management 仕事紹介 技術的な取り組み

Loading...

KADOKAWA Connected / ドワンゴの @saka1 です。

少し前までは株式会社ドワンゴのWebバックエンドエンジニア的な仕事をしていたのですが、最近は出向1してKADOKAWAグループのDXを推進する戦略子会社である株式会社KADOKAWA Connected（以下KDX）でデータ分析周りのお仕事をしています。この世界はジョブチェンジが激しいですね。

しばらく開発に関与していたドワンゴ・KADOKAWA向け新データプラットフォームの初期リリースに成功したので、この記事ではその話を書きます。KDXのデータエンジニアリングに関する取り組みのほんの一端ではあるのですが、なんとなく雰囲気が伝わればいいなと思っています。

この記事は全体概要編のようなものです。

  • 移行プロジェクトとしての事例紹介を中心にして書きました。プロジェクトの置かれたコンテキストや、出てくる課題にどう判断をつけていったかを、できるだけ紹介しようとしてみました。
  • 採用した個別製品についての知見などはあまり詳細に書けていません。記事の厚さの割にテクニカルな内容は控えめです。

後者の、より技術寄りの話については、どんどん別の記事などの形でアウトプットできたらいいなと考えています。

※ 説明を単純化するため、あたかも筆者が課題を次々と倒したかのように書かれてますが、実態とはかなりずれています。開発チームを含めた関係者の膨大な尽力がありました。

TL;DR

  • データ分析のためのプラットフォームが乱立しててつらいので統合するプロジェクトを実施中
  • プロジェクトの状況がややこしかったので頑張った
  • 選定した主要製品・サービスは Snowflake on AWS, Auth0

データプラットフォームとは？

この記事では、データの収集・保存・分析のために必要な諸機能を備えたシステムのことを指して、データプラットフォームと呼びます。諸機能とは、例えばコンピューティングリソースの払い出しや利用者のアカウント管理などです。

データプラットフォームの構成要素の一つにデータウェアハウス(DWH)があります。DWHは、保存されたデータに対して、SQLクエリなどを通じてデータ処理を行える機能を提供します。世の中の代表的な製品はGoogle BigQueryやAmazon Redshiftでしょうか。

大量のデータを業務に活用している企業では、例えばDWHとしてBigQueryを採用し、BIツール（Tableau, Google Data Portal, ...）や業務プロセス（利用にはこういう申請が必要で、権限を払い出すには……etcetc）などを整備してデータ分析業務を作っていると思います。

具体例の一つですが、筆者が所属するドワンゴにおいても一連のデータ分析用スタックが整備されていました。よくあるラムダアーキテクチャの変種みたいなものだと理解していただけるといいかなと思います。

f:id:kdx_writer:20211019110408j:plain
現行データプラットフォームおよびその周辺の概要。特にApache Kafka, Apache Hive, Apache Impala, Apache Spark, Apache Pig, Apache HadoopはApache License 2.0が設定されています。そのほかfluentd, embulk, Amazon Kinesis Data Streams, Amazon S3, Elasticsearch, Kibanaを記載しています。

このうち 現行データプラットフォーム が新データプラットフォームに置き換わる範囲になります。

前史

新データプラットフォームの面倒なところを紹介するには、関連する各社の歴史的経緯についても触れないわけにはいきません。この節では少し寄り道して、関係各社の大まかな変遷を紹介2しておきます。

ドワンゴ・KADOKAWA・KDX

ドワンゴのデータプラットフォーム整備が始まったのは、遅くとも2012年ごろだったようです3。オンプレミスのサーバ群にHadoopをインストールする形で利用が始まったと聞いています。その後、商用ディストリビューションであるCloudera Enterprise (CDH)への切り替えが行われるなどハードウェア・ソフトウェア両面での更新を経つつ、現在でもHadoopクラスタは運用されています。

f:id:kdx_writer:20211019203557j:plain
当時のHadoopについての経緯が描かれたホワイトボード（一部黒塗りにしています）

一方のKADOKAWAでも昔からデータ利活用の機運はあったようで、たとえばデータウェアハウス製品を導入しての売上分析などは行われていました。ただし、ドワンゴのようにデータエンジニア・データアナリストなど専門職のチームがある、といった形にはなっていなかったようです。

ドワンゴとKADOKAWAが経営統合を発表したのは2014年のことです。その頃から徐々に事業や会社活動の交流が始まりました。そしてグループ全体の成長にむけてDXを推進するために、ドワンゴとKADOKAWAの二社からDXに関連する人員が集結4して、2019年にKADOKAWA Connectedが設立されました。

f:id:kdx_writer:20211016211103j:plain
KDX IDS部の設立

データエンジニアやデータアナリストといった、いわゆるデータ分析に関するスキルを持つエンジニアたちは、基本的にKDXに集約される方向となりました。KDXからみるとドワンゴやKADOKAWAは顧客です。Hadoopクラスタやデータ分析支援サービスなどをご提供して、対価をいただく関係になっています。

現在は、「Integrated Data Service部」という部署をKDXに設置して、ドワンゴ向けKADOKAWA向けでそれぞれ別の、複数のデータプラットフォームを運用しています。この部署（Integrated Data Service部）について興味がある方は紹介記事を参照してください。

engineering.kdx.co.jp

データプラットフォームを統合したい

さて、データに関する部署（人員）がKDXに集約された後のことです。やっとこの記事の本題に近づいていくのですが、次に取り組むテーマの一つに、複数あるデータプラットフォームの統合が掲げられることになりました。

統合のメリットは大きい💪

データプラットフォームの統合にはメリットがいくつもありそうでした。

  • データプラットフォームは、大雑把な傾向として、取り扱うデータ量とカーディナリティ（種類）が増えるほど便利になります。価値ある関係などを抽出できる可能性が広がるからです。
    • 直感的には驚くべきことですが、事業がかなり違うはずのドワンゴとKADOKAWAで、保有するデータを横断的に分析したいというユースケースが既に出ていました。そういった場合にはプラットフォームが異なるためデータエンジニアがアドホックな対応をするしかなく、作業負荷が高い状態でした。
  • ドワンゴのHadoopクラスタは、会計上つぎの更新を考えてよい時期でした。つまり、幅広い選択肢を改めて検討しやすいタイミングでした。
  • プラットフォームが少ないほうがランニングコストが下がると予想できていました。エンジニアの人件費はもちろん、コンピューティングリソースなどについても二重調達を避けられるはずだからです。
    • 利用形態によってはボリュームディスカウントが効きそうでした。
    • 動作しているバッチジョブやアドホック分析のクエリについて利用状況を調査したところ、時間的な偏りがありました。したがって、IaaSやSaaSでリソースをオンデマンドに調達すれば費用を抑えられそうだという期待がありました。
  • KADOKAWAグループの中には自社データプラットフォームを持たない会社・事業部門もあります。データの利活用をドワンゴ・KADOKAWAに留まらずグループ全体に推進していくにあたって、横展開の容易なプラットフォームが求められていました。
    • この点で、例えばドワンゴのHadoopクラスタは社内イントラネットに構築されていたため、社外の組織がアクセスするのが困難でした。
  • データエンジニアの技術スタックを更新するタイミングでもありました。
    • 現代的なデータプラットフォームでは、いわゆるクラウドの利用はごく当たり前になっています。Google Cloud Platform(GCP)は使い込んでいなくてもGA360とBigQueryを使ったことがある、というアナリストの方もいると思います。
    • 部署のデータエンジニアは、限られた案件でAWS, GCPを利用していたものの、十分に技術的なキャッチアップができているとは言い難い状況にありました。

困難も多い😨

この大方針は、事業的にも技術的にも理にかなっていて一石N鳥いい事ずくめ……に見えるのですが、多数の困難もまた見えていました。

  • ドワンゴとKADOKAWAは別会社です。会社のあらゆる設備やルールが別でした。
    • データプラットフォームに蓄積されるデータの取り扱いひとつとっても、例えばデータポリシーが両社で整合していませんでした。
    • Google Workspaceは両社で導入されていましたが、別ドメインになっていました。
    • 両社で共通にドキュメントを閲覧できる場所は存在しませんでした。そもそもドキュメントの共有をしていいのか？ についてルール整備もなされていませんでした。
  • 既存のコード資産が大量にあるので、大掛かりな移行計画が必要になりそうでした。
    • 現データプラットフォームは、利用者側にコードを書いてもらう形でも利用されています。ということは全利用者の多様なコード（Hive SQL, Impala SQL, Spark, ...）の書き換えを計画しなければなりませんでした。
      • 古くから保守されているバッチの中にはApache Pigで書かれたものさえありました。Pigを読めるエンジニアはごく限られていました。
      • 移行先のデータプラットフォームは、UIはもちろん提供形態が大きく変わるはずなので、数百人の利用者には再学習をしてもらうことになりそうでした。

要するに、ぜんぜん違う会社のシステムをくっつけたい、しかも新規導入ではなくシステム移行になるわけですから、あっちこっちに課題が出るわけです。基盤となるデータプラットフォームを導入すれば成功だ、という単純な話では収まりません。

プロジェクトの難しいところはどこか

データプラットフォーム統合プロジェクトの構造的に難しいところは、まずは前節で述べたように「複数社またがった」「移行」プロジェクトだ、という点にあります。

さらに具体的に見ていきます。結構な制約があります。

  • 移行元システムの中には、複数年単位のライセンス契約を設定しているものもありました。万が一にも、移行に手間取って契約更新時期を逃した場合は、契約延長等の対応をせざるを得ず、部署に莫大な出費が降り注ぐことがわかっていました。そうなるぐらいならデータプラットフォーム統合プロジェクトをやらないほうがまだマシでした。
  • データエンジニアはそれほどAWS, GCP等に習熟していませんでした。絶対的な習熟度が不足していたので「こんなことを実現するシステムを作りたい」と言われたときに、具体的なソリューションを効果的に提案できませんでした。

移行プロジェクトでありかつ絶対的なデッドラインがあるのは、QCDSのコントロールという視点からは不利です。例えば「期日までに9割がた移行に成功したが1割は無理だった」のような状況を作ってしまうと移行元システムを停止できません。大損害です。そうなってしまうと、システムに予定の9割の価値はあったよね、とはなかなか言えないのです。

納期(D)とスコープ(S)がある程度固定されているとすると、プロジェクトの調整余地が小さいと見なさざるを得ません。かといって「品質(Q)を下げていいから早く作れ」のような方針は、多くの場合に現実的な方針とは言えません。Robert C. Martinは品質を下げる発想を端的に戒めています。

速く進む唯一の方法は、うまく進むことである。
『Clean Agile - アスキードワンゴ』 p.46

さて、課題は山積みで調整の柔軟性はないプロジェクトではあったのですが、幸いなことに期間自体はかなりたっぷりありました。スケジュールバッファを大きく取り、スケジュールが間に合う確率を上げること自体はできそうでした。

エンジニアがクラウドに慣れていないのはしょうがないので、地道に学習の時間を取るしかありません。AWSを使う別のプロジェクトに参加したり、学習の期間をかなり大きめに設定して業務時間で学習をしたり、AWSさんに勉強会を開いてもらったりと、いろいろな施策を通じてスキルを付けることになりました。

リスク駆動という発想

単純に期間を取るだけでは効率的なプロジェクトとは言えません。時間を効果的に使うためにも、プロジェクト全体の進め方を工夫する必要があるのは明らかでした。

部署では、いわゆる「アジャイル的な」タイムボックスを設定してその中で成果を出そうとしてみる、またプロセス改善を試行錯誤する開発スタイルに取り組んでいます。しかしながら、例えばDWHの選定に重大な問題があった場合、漸進的に修正できるか……というと事実上不可能だろうと予想できます。かといって、具体的な製品を想定しないまま開発を始めるのも難しいと想像できます。

つまるところ、このプロジェクトで素朴に反復的なアプローチを採用すると、効果的に反復できないままプロジェクトが爆発する懸念がありそうでした。

『Design It!』では、Barry Boehmらの成果を参照する形で「リスクに道案内させる」リスク駆動型アプローチについて述べられています。一部を引用します。

新しいソフトウェアプロジェクトで最初に行われるステークホルダー会議の直後には、いつも胃の中に巨大な穴が空きそうになるのを感じる。もしそうした気持ちにならなかったとしたら、私は逆に心配になるだろう。構築する価値のあるソフトウェアには、リスクがつきまとうものだ。新しいプロジェクトの開始時には、多少でも居心地の悪さを感じなければならない。最初に全てが分かっていて、構築すべきものに何の質問もないようなら、アーキテクトなんて必要ないはずだろう？

私たちは直感の武器を有利に生かすことができる。リスクは成功を妨げるかもしれないものを測るための優れた指標だ。第六感を生かすために、ソフトやシステムについて心配に思うことを全て書き出そう。そして、最も問題を引き起こす可能性が高いものがリストの一番上にくるように、リストに優先順位をつけよう。そして、最後に気になる点を一点選び、リスクを減らすためのデザインマインドセット選択しよう。
『Design It!』 p.42

リスクを下げるような方法を探すことは、その状況で適切なアーキテクチャを探求することにつながる、という意味だと筆者は理解しています。参照先の『アジャイルと規律』にてBoehmはもう少し別の表現もしているように読めます。

リスク分析はアジャイル手法や計画駆動型手法に特有のリスクを定義し対処するためだけなく、何かをやり足りない・・・・・・リスクとやりすぎる・・・・・リスクとのバランスを取り、種種雑多の「どれくらいやれば十分なのか」という疑問に答えるためにも用いる。
『日経BP SHOP｜アジャイルと規律』 p.126

改めて、プロジェクトでは何がハイリスクだと言えるのか検討したところ、主に次の三点がありそうでした。

  • 開発者のスキル不足
  • IDプロバイダ問題（後述）
  • DWH選定の問題

これらを本格的に開発を始める前に対処し、リスクを十分下げることがプロジェクト進行上とても重要そうでした。そのため、プロジェクトチームでは、ハイリスクな課題をプロジェクト初期に持ってきた上で、フェーズ分割をしました。そしてそれぞれの段階で成果物をつくり、フェーズ完了時には関係者で成果物を確認し、次のフェーズに進むべきかを判定する方針でプロジェクトを進めました。

フェーズ 内容 成果物
初期調査 候補となるDWH・クラウドプロバイダ・IDaaS等についての調査。学習の期間を兼ねる。 調査結果の資料。例えば想定アーキテクチャ図や製品比較結果の星取表などを含む。
IDaaS PoC 候補になった製品が我々のユースケースに向いているかなど、概念実証(PoC)を実施。 調査結果の資料。例えば製品比較結果の星取表などを含む。
DWH PoC 候補になった製品が我々のユースケースに向いているかなど、概念実証(PoC)を実施。 設定した項目が達成できていることの確認。例えば主要なユースケースをサポートできることが確認できたか。
より対象製品に詳しくなる意味もあった。
開発 PoC結果を実際のプロダクトに反映させる形で開発を行う。 N/A

前述の通りプロジェクトのスケジュールは柔軟性がありません。最悪の場合はプロジェクトを早期に中止し、事業的な被害を押さえる必要がありました。

もっとも、状況がややこしいとはいえ開発規模自体は大規模というほどではなかったので（開発チームは10人以下です）、あまりにガチガチに計画を組むのは計画自体のオーバーヘッドが大きくなりすぎたり、アーキテクチャの探求を過剰に制約する恐れがありそうでした。

このプロジェクトではそういったバランスを、リスク駆動とマイルストーンの設定によってコントロールしようと試みたわけです。

技術選定

探してきた良さそうな製品を自分たちの用途に合うか一通り叩くことを、KDXではPoCと呼んでいます。

PoCをこなすことで初期のアーキテクチャが設定できそうということで、今年の頭ぐらいは集中的にPoCしていたと思います。

DWHの選定

DWHの選定とは要するに、AWS(S3 + Redshift + ...)でいくのか、GCP(GCS + BigQuery + ...)にするのか、それとも他の選択肢があるのか、といった話です。データプラットフォームの特性に大きく影響しますし、DWHの選択によってGCPかAWSかそれ以外か、クラウドプロバイダの選択も影響を受けるので運命の分かれ道です。

結論としては、我々が選定したのはSnowflakeです。

特にデータエンジニア・データアナリストではない方だと、Snowflakeは耳慣れないかもしれません。2020年2月の東京リージョン立ち上げ以来、日本でも採用例が増えてきたかもしれない（？）DWH5です。過去にData Engineering Studyで紹介されたことがあるので、概要をつかむにはそのアーカイブを確認すると分かりやすいと思います（Snowflake社の方も発表しています）。

forkwell.connpass.com

Snowflakeをうまく使うポイントの一つは、ウェアハウスの利用方法にあるようです。 ウェアハウスは、論理的にはSnowflakeのコンピュート部分に相当し、利用料金上もかなりの割合を占めます。ウェアハウスは独立したSQLのジョブキューを持っていて、エンドユーザが投げたSQLを元にバックエンドのS3から順次データを読み出して評価を行ってくれます。AWSのEC2インスタンスなどと同じく起動中のみの課金です。というか中身はEC2インスタンスみたいなのですが、Snowflakeが内部的にプールしているらしく瞬時に起動します。

したがってウェアハウスをどう作成し割り当てるかによって、コストと利用者の利便性は変わってきます。例えば、時間がかかっても構わない長時間バッチは、サイズの小さな専用ウェアハウスでゆっくり動かすことで費用を抑える方針が考えられます。ウェアハウスが別ならジョブキューも別なので、他の利用者が長時間バッチの影響を受けることはなくなります。

そんな感じで、Snowflakeの提供するモデルは、言うなればRedshiftほど計算ノードがむき出しではないものの、BigQueryほど抽象度が高くない感じです。ほどほどにチューニング余地があるのはチームの中でも評価が高かったと思います。

Snowflakeの内部構造の一部についてはNSDIに論文が出ているそうで、要約した方がいるので紹介しておきます6。

zenn.dev www.usenix.org

我々がSnowflakeを選定したのは、前述のウェアハウスのような「技術的に筋が良さそうな感じ」ももちろんあるのですが、それだけでない総合的な判断をしています。

  • Snowflakeはクラウドベンダー上に展開するSaaSなため、ある種の中立性がありました。特定のクラウドベンダーに引っ張られすぎないと期待しました。
  • KADOKAWAグループは（経験的には）かなりの頻度で企業再編や新規事業の立ち上げを行います。Snowflakeのデータ連携やリソース調整の機能は柔軟なので、我々の事業環境によく合っていそうでした。

などなど、製品としての純粋な優劣を比較したというよりは、我々の置かれた環境で最も良さそうだったと表現するほうがより適切かもしれません。

クラウドDWH製品は、各社が互いの製品を意識した競争をしているようです。例えば、ストレージとコンピュートが分離しているのはSnowflake（やBigQuery）の特徴でしたが、RedshiftもRA3世代から分離されるようになりました。RA3はストレージバックエンドがS3らしく、ある意味Snowflakeと似てきています。

今後も各社の動向を追う必要はありますが、少なくとも選定時点で我々にとってSnowflakeはとても良い製品でした。

AWS

Snowflakeを選定したことで、クラウドプロバイダは自然とAWSを選択することになりました。というのも日本にあるSnowflakeのリージョンはAWSのみだったからです（記事執筆時点ではAzureの東日本リージョンがアナウンスされています）。

AWSを選択することになったのはむしろ好都合でした。部署のデータ転送システムの一部はAmazon Kinesisファミリーを使って構築されていたりと、Snowflake on AWSと既存システムの親和性は悪くなさそうでした。また、KADOKAWAグループはAWSをそれなりにヘビーに使っていることもあり、ディスカウントやサポートの恩恵を受けやすい立場にありました。

SnowflakeはSparkライクなデータ処理インタフェースをサポートしていません（Snowparkには期待していますが執筆時点ではまだGAになっていません）。既存のコード資産にはSparkで書かれているものも大量にあったので、それをまともにSQLに書き換えるのではなく、AWS Glue上で動かすように移植することでマイグレーションすることになりました。

グループ横断のユーザ認証

認証については（経験的には）しばしば汎用サブドメインとして切り出される領域です。ある種のサブシステムになることも想定しつつ、具体的なアーキテクチャを検討することにしました。

　「汎用サブドメイン」は、業務的に特別ではないが、今回のシステムにおいて必要な箇所を表します。例えば認証機能やERPやECなど、極端な場合、交換されたとしても差し支えのない機能が該当します。
実践DDD本 第2章「ドメイン」「サブドメイン」「境界づけられたコンテキスト」を読み解く

大前提として、データプラットフォームでの独自アカウント管理は極力したくありませんでした。ドワンゴやKADOKAWAの社員に紐付いたアカウントの棚卸しなどをやるのは現実的でないので、既存のIDプロバイダ(IdP)と連携したシングルサインオン(SSO)方式が実現できないか探ることになりました。

ややこしいのは、ドワンゴとKADOKAWAで社員アカウント管理が別系統になっていることです。SnowflakeはSSOをサポートしていますが、連携設定は単一のIdPに対してのみ7行なえます。つまり、複数のGoogle WorkspaceとSSO連携させることはできませんでした。

また、そもそもとして社員に紐付かない存在（連携する別チームのシステムなど）がデータプラットフォームにアクセスするユースケースがありました。つまり、したくないと言いつつ結局アカウント管理はしないといけないのですが、管理コストを極力下げたいという思いもありました。繰り返しになりますが、我々にとってアカウント管理はコアドメインとは言い難い領域でした。

ところで、アイデンティティ管理は専門分野が発達していて、Identity as a Service(IDaaS)のカテゴリで知られています。上で述べたような問題はIDaaSの導入で軽減・解決するんじゃないかと考えて、うまい製品がないか調べることにしました。

  • 認証部分は自前管理したくないので、IDaaSであること
  • 複数の既存IdPと連携したシングルサインオンが実現できること
  • 独自のID管理も組み合わせることができること

こんな製品あるの！？ と思いつつ製品調査をした結果、有力候補として浮上したのがAuth0です。

世の中のIDaaSはおおむね二方向のカテゴリに分かれています。Oktaのような社員にアカウントを配ってSSOを実現する製品と、Auth0, Firebase Authentication, Azure AD B2Cのような利用してもらうサービス側の立場からアカウント連携を支援する製品です。利用形態からして今回ほしいのは後者の製品でした。候補の中から最終的にAuth0を選定したポイントはいくつかあります。

  • Auht0は資料が豊富でした。
  • Auth0の中心にある概念はOAuth/OpenID Connect(OICD)でした。標準によく適合しているのは安心感がありました。
  • 機能的には、Azure ADでも同等以上のことができたかもしれません。ただ、ID管理のために利用クラウドプロバイダを増やす（Azureの利用も始める）のはシステム構成の複雑さを招く懸念が否めませんでした。その点でAuth0はAWS東京リージョンで利用可能でした： Auth0、AWS東京リージョンで提供開始｜Auth0株式会社のプレスリリース

採用してからしばらく経ちますが、基本的には完成度が高い製品です。あえて欠点を挙げるなら課金周りの体系がちょっとややこしい点でしょうか。あとはAuth0の機能そのままでは我々のユースケース8をカバーしきれなかったり、課金上の問題が発生しそうになったりしたので、一定程度の独自実装は不回避でした。その辺りの工夫については別の記事で知見紹介できるといいなと思っています。

節の最後に、IDaaS比較の参考資料として↓を挙げておきます。この分野は微妙に資料が少なく初期調査に難儀したのですが、全体像を掴むのにとても役立った本でした。

booth.pm

得られたアーキテクチャ

ここまでの一連の調査を経て、ようやく全体のアーキテクチャ像をそれらしく描くことができました。Snowflakeと、AWSと、Auth0をくっつけます。これらだけだとただのインフラなので、我々の利用方法に合わせたロジックの実装も要るのでアプリケーションサーバも用意しました。「あとはこれ作ればいいんだな」ってわけです。

f:id:kdx_writer:20211019214548j:plain
新データプラットフォームのアーキテクチャ図（概要）

記法はC4モデルを参考にしています。あまり描き慣れていないので変な所があるかもしれません。

www.infoq.com

……ご想像どおり、この図は抽象度が高いのであまり省略は入っていないのですが……完成形はもうちょっと……いやだいぶ複雑です。あれこれコンポーネントを足したり若干ダーティな仕様で妥協したり、紆余曲折した過程があるのですが、それについてもいずれ触れる機会があればなと思っています。

まだできていないこと

最初のリリースには成功したとはいえ、新データプラットフォーム利用は始まったばかりです。ミニマルな機能に絞ってリリースしたので、機能面がそれほどリッチとは言えませんし、改修したい場所もたくさんあります。データの移行などマイグレーション作業も今まさに取り組んでいます。

新データプラットフォームあるいは部署の近未来テーマは無数にあります。中でも特に、注目している領域として二つ紹介します。今回のような事例をこれからも紹介し続けられるといいですね。

メタデータ管理

メタデータとは、おおまかにはデータについてのデータだとされます。データ分析の世界では、そのデータの型（"id"という名前のint型のカラムがある、等の情報）やアノテーション（カラムに自然言語による注釈を付けたもの）など、様々なものをメタデータとして扱います。しばしばデータをどう発見するか（Data discoveryの問題）や、データの利用過程をどう追跡するか（データリネージの問題）と関連して論じられます。

メタデータをどう管理するかは、会社の事業構造などと比較的強く結びつきやすいからなのか？ デファクトスタンダードがまだないようです。巨大企業でも（巨大企業だからこそ？）、各社独自のシステムを作り込んでいる様子があります。

我々もメタデータの管理は行っていますが、作業のルール化こそしてあるけども……程度の習熟度に留まっています。言ってしまうとWikiやスプレッドシートなどを駆使した人力で頑張っている箇所がかなり多いです。運用コストが高いのは分かっているので早めになんとかしたくはあります。

データとデータパイプラインは誰のもの？

データプラットフォームに入力されたデータは、しばしば順次発火するバッチ（と便宜上呼びます）などで何段階かの変換を経てBIツールで可視化して、のように使われることがあります。変換の処理の連鎖をデータパイプラインと呼びます。

データプラットフォーム上のデータおよびデータパイプラインの管理に責任を持つのは、データ専門部署のデータエンジニアとするのが一つのやり方です。こうすると大規模データ分析特有の実装知識などをデータエンジニアに集約できます。

ところが、このデータおよびデータパイプラインは事業内容と強く紐付いていることが多いです。特定事業のデータなのだから当たり前ですが……バッチを保守するには事業特有の知識（このIDカラムの意味はこういうものだとか）や特有の品質特性（金曜日分は件数がスパイクしやすいとか）など様々な事を把握していなければなりません。そして事業の変化に引っ張られてデータパイプラインのロジックも変化を求められることが多いです。必然的にデータパイプラインの保守は部署間（事業部門 - データ部門）のコミュニケーションとなり、調整コストが高くなります。

また、これはあるあるだと思いますが「BIツールの出力が変なんだけど〜」と言われて調べると、データパイプラインは悪くないがデータソースに問題があった、といったケースがあります。トラブルの調査は組織をまたいだコミュニケーションになりがちで、大した問題でなくとも保守コストを高くしてしまう原因になります。 たとえ自分たちが悪くなくても、申し訳ない気持ちになっちゃうし調査しないわけにもいかないのがデータエンジニアですね。

もし、事業部門が自分たちの生成したデータおよび関連するデータパイプラインに関して責任を持つようにすると、部署間調整は発生しづらくなります。別の言い方をすると、データプラットフォーム上にデータがあるからといってデータの部署に管理責任を持たせているのは本質的なミスマッチなのでは、という視点が近年登場しています。データはそれを生成した事業領域が提供も含めて管理責任を負うほうが自然だとする観点です。

以上がデータメッシュについての筆者なりの理解です。仮にデータメッシュを理想とするとしても変革のハードルがかなり高いので、いきなりこの未来に近づけるとは思っていません。例えば、データプラットフォームのセルフサービス化をずっと強化する必要があったり、データエンジニアを事業部門に派遣するような組織設計が必要になったりもするかもしれません。

ここで述べたデータメッシュ的なアプローチをどれぐらい推進するかはともかくとして、部署では最新の知見をキャッチアップしたり、自分たちなりに仕事に適用する活動を進めていきたいとは考えています。

参考資料：

まとめ

だいぶ駆け足になってしまいましたが、新データプラットフォーム統合プロジェクトについて紹介してきました。

次の技術記事を書くタイミングは特に予定できていないのですが、記事にできそうな話はいくつもあるので、何がしかの形で発表できればいいなあと思っています。もしかしたら筆者ではない別のエンジニアが書いたりするかもしれません。

  • Slackワークフローを使った各種申請手続きを整備した話（仮）
  • Auth0でM2Mトークンキャッシュの実装を作った話（仮）
  • SnowflakeのJDBC接続でクレジットを大量に溶かした話（仮）
  • Snowflakeのロール階層による権限管理をラップする実装を作った話（仮）
  • AWSでGlueが止まらなくなって費用が爆発したので対策した話（仮）
  • ドキュメント管理システムとOIDC認証の話（仮）
  • データプラットフォームをDataDogで監視する話（仮）

データプラットフォームの整備は、これからやりたいことの一里塚ぐらいに過ぎないです。データプラットフォームの発展というだけでも前述したような明らかな宿題がありますし、そもそもデータプラットフォームを使って利用者に何らかの良いこと（価値）を届ける活動は継続していく必要があります。先はだいぶ長いなあと思いながら少しずつ前進していく予定です。

Appendix: Q&A

Q. プロジェクトをフェーズに分割したのは効果的だった？

分割しなかった場合と比較はできないのですが、感覚的には意味があったように感じます。ただ、PoCの評価項目に漏れがあり「想定と違う！！」となった事もありました。項目をどれぐらいうまく洗い出しきれるかが効果的にやる上でのポイントの一つなのかもしれません。

Q. AWS, GCP, Snowflake以外に検討したDWHはあった？

他にも複数ありました。例えばAWS主体で使うけどDWHはBigQueryにするとメリット出るんじゃないかとか、Clouderaも最近はCloudera Data Platform (CDP)を出してるが独特のメリットがありそうだとか、ちょっと簡単には紹介しきれないぐらいの組み合わせがありました。

選定に使える時間の制約もあり、全てについて入念に調査できたわけではないのも事実です。Azure Synapse Analyticsはもしかしたらすごく優れた製品なのかもしれませんが、まったくと言っていいほど調査していません。

Appendix: 悪条件ばかりではなかった

新規開発を行う上で、必ずしも困難ばかりだったわけではありません。筆者の視点では関係各社上層部は比較的理解があったように思います。上司や、上司の上司（最近Chief Data Officerになったらしいです）がとても頑張ったのかもしれませんが……。

  • ドワンゴの特にニコニコなどを手掛ける事業部門は、新データプラットフォームへの移行に関して多大なコストが見込まれました。しかしKADOKAWAグループ全体でのメリットを踏まえて、移行計画を進めることについて理解していただくことができました。
  • KADOKAWAもデータ利活用が事業上重要だという理解があり、新データプラットフォームについて会社戦略の一部に組み込んでもらえました。
  • KDXのデータ専門部署は大きな権限移譲を受けていました。合理性説明が立つ範囲であれば高度な裁量がありました。

偉い人たちが大枠を支持してくれているのは良いことです。もちろん、それだけで全ての問題が解決するわけではないのですが。

  1. 会社の中では珍しい、ドワンゴ所属かつKDXで勤務なので事務処理上のコーナーケースを踏んでいるらしく、たまに不思議なトラブルが起きて面白いです。↩

  2. なお、筆者は2014年ぐらいからのドワンゴを多少知っているのですが、KADOKAWAの知識はあまりありません。↩

  3. R&Dが行われていたのはもっと昔からだったようです。↩

  4. あくまで歴史的経緯です。現在のKDXには中途採用にてジョインなさった方もたくさんいらっしゃいます。↩

  5. 彼らはデータクラウドを標榜しているようです。確かに「セキュアデータ共有」など純粋にDWHというには収まらない機能を持っているように見えます。↩

  6. 論文時点と現時点が一致しているとは限らない点には注意してください。↩

  7. おそらくですが、この種の制約はよくあるものの1つです。Slackもそうだとか聞いたことがある気がします。↩

  8. 特に困ったのはAPIキーの問題です。他の事例を見てもあまりきれいな解決策がないようで難儀しました：権限制御可能な永続化APIキーをAuth0で発行する - Qiita↩

©KADOKAWA Connected Inc.