乐胖代购免代理版

初めまして。DSOC Data Direction Groupの有山と申します。
現在、Data Direction Groupでは私を入れて主に2名のメンバーがデータエンジニアとして職務と向き合っています。
ところで、データエンジニアの仕事とはどういうものを想像するでしょうか。Data Direction Groupでは以下の業務を行うべき職務と定め、実行しています。*1

データ分析基盤の設計・構築・保守・運用・改修
多部署との連携や調整
BIツールを用いたダッシュボード作成
メタデータ管理

その中でも今回はメタデータ管理についてこのブログで解説していこうと思います。

概要

メタデータ管理の内容について

そもそもメタデータとはどういうデータでしょうか。
一般的には「データに関するデータ」として説明され、データそれ自身が付加的に持つデータと理解されます。
テーブルの中に格納されるデータを例にとると、例えば以下のような項目がメタデータと考えられます。

データのスキーマ(形式/データ型など)
データのファイルサイズ
データの作成日付
格納されるテーブル名
そのテーブルのカラム

このように、データそれ自身について説明してくれるデータのことをメタデータと呼び、データの管理をする上でとても重要な情報だと言えます。
メタデータ管理とは、このメタデータを収集、管理することで、日々扱っているデータを適切にマネジメントしていく業務と定義しています。

取り組みを始めた経緯

この取り組みは、主に以下の背景、課題、要望を理由にスタートしました。

サービスのスケールに比例して、DBのテーブルやS3バケットなど、作成しなくてはならないリソースが常に増えていく。
増えていくリソース全てに対して、その使われ方、どういうデータを格納しているかを把握して開発やデータ管理に役立てたい。
検証で作った一次テーブルなど、不要となったリソースは即時削除したい。
作成したリソースに対する、エンジニアへの管理の意識づけをより徹底したい。

システムの解説

システムの設計方針

DSOCは開発環境として主にAWS,GCPを使用しており、各々のクラウドサービスを使用してメタデータを収集、管理するシステムを構築しています。
クラウド毎に環境の分け方が異なり、AWSは開発の用途ごと、GCPはプロジェクトごとに環境を作成しているため、それに合わせてシステムを構築しています。
具体的な処理内容として、日次でテーブルやバケットなどのクラウドリソースの取得、週次でデータの集計、抽出、管理用のスプレッドシートの更新を行なっています。
また、データマネジメントという目的に則り、管理するサービスはDB、ストレージなどのデータを保有できるものとしました。

システム全体構成

AWSについて、環境が本番、ステージング、開発と分かれているため、全ての環境で同一のシステムを構築するようにしました。
具体的には本番環境で構築したシステムをCloudFormationという構成管理ツール*2で他の環境にデプロイできるように構築しています。
f:id:seinberg:20200118185742p:plain
GCPの場合は、専用のプロジェクトを一つ作成し、そこからDSOCの保有する全てのサービスへアクセスできるようにしました。
f:id:seinberg:20200112235659p:plain

日次システム構成

管理対象となるクラウドリソースからメタデータをクロールする処理を日次で行なっています。
青枠がクロールするシステムで、赤枠がクロール対象となるサービスです。
AWSの場合、StepFunctionsからAWS Lambdaで各サービスのリソース一覧をクローリングし、結果をS3バケットに保存するようにしています。
f:id:seinberg:20200118185039p:plain
GCPでは、CloudFunctionsでクローリングし、Bigqueryへ保存する処理を行なっています。
GCPにはStepFunctionsに相当するサービスがないため、一つのPub/Subトピックをサブスクライブする形でCloudFunctionsを処理させています。
f:id:seinberg:20200118181554p:plain

週次システム

日次で収集したメタデータと、管理用のスプレッドシートを比較し、以下のデータを抽出、整形して、スプレッドシートに反映させます。

当週新規に作成されたリソース
カラムの追加など、差分のあったリソース
変更のなかったリソース

日次処理と同様にAWSではLambda、GCPではCloudFunctionsを使用して差分の抽出、反映を行なっています。
f:id:seinberg:20200118184705p:plain
f:id:seinberg:20200118182728p:plain

工夫した、つまづいた点

AWS環境のシステム要件の一つに、全ての環境で同一のシステムを展開、管理できるという内容があり、この要件に対応するため、構成管理ツールであるCloudFormationのStacksetsという機能*3を使用しました。
今回はAWS Lambdaの関数をデプロイするときに少しハマりどころがあったのでそちらを共有します。

関数のデプロイ方法について

通常、Lambdaのコードを記述する方法として、以下の二つがあります。

テンプレートにコードを直接ベタ書きする。
zipファイルをs3などに配置し、テンプレートはそのディレクトリを指定する。

関数のコードとテンプレートは通常分けたほうが管理しやすいため、一般的には2つ目の方法で記述します。
しかし、2つ目の方法で実行するとき、CloudFormationはコードの差分を読み取ることができず、コードの変更を反映させたい時には、zipファイルの名称を変更しなければいけなくなります。
例えば、以下のケースだと、S3Keyに指定したsample_file.zipのファイル名を、コードを修正するたびに変更しなければいけません。

samplelambda:
  Type: "AWS::Lambda::Function"
  Properties:
    Code:
      S3Bucket: "sample_bucket"
      S3Key: "sample_file.zip"
    FunctionName: sample_lambda
    Handler: sample_lambda.lambda_handler

これを解決するために、aws cloudformation packageコマンドを使ってテンプレートを修正してデプロイするようにしました。
上記のコマンドは、ローカルに存在するコードを一意な名前でS3にアップロードし、ファイル名が上書きされたテンプレートを自動で作成してくれるコマンドです。
例えば、先ほどのsample_file.zipをローカルディレクトリの所定のフォルダで展開し、そのフォルダパスを以下のように記述します。

sample_template.yaml

samplelambda:
  Type: "AWS::Lambda::Function"
  Properties:
    Code: "local_directory/sample_file"
    FunctionName: sample_lambda
    Handler: sample_lambda.lambda_handler

次に、オプションを以下のように指定してaws cloudformation packageコマンドを実行します。

aws cloudformation package \
   --template-file sample_template.yaml \ #元となるテンプレート名
   --s3-bucket sample_bucket \ #コードをアップロードするバケット名
   --s3-prefix sample_directory \ #s3のフォルダパス
   --output-template-file packaged_template.yaml #作成するテンプレート名

実行後、以下のようなコードに置きかわり、S3にもコードがアップロードされます。

packaged_template.yaml

samplelambda:
  Type: "AWS::Lambda::Function"
  Properties:
    Code:
       S3Bucket: sample_bucket
       S3Key: c6b5f8540fdfc9228e228e11c76fc42c
    FunctionName: sample_lambda
    Handler: sample_lambda.lambda_handler

f:id:seinberg:20200113184451p:plain
以上の手順を実施することで、最新のコードを都度一意な名前に変換し、またそれが反映されたテンプレートを作成することができます。
もし同じようにCloudFormationでLambdaの関数を管理したいという方がいらっしゃればこちらの手順を参考にしてみてください。
また今回のような要件がない場合は、CloudFormationを使わずにAWS SAMなど、よりライトな他のフレームワークを使用してみるのも良いと思います。

運用について

運用は、毎週更新済みのスプレッドシートをWorkplace*4で全開発チームに展開し、新規で作成されたリソース、変更のあったリソースについて、詳細な情報を記入していただいています。
記入内容は主に以下の項目を定めています。

保有チーム名
作成日
データの性質
どのような意図で使われているか
変更のあったリソースについて、変更後の記載内容にアップデートがないか

以上の情報を保有する全てのリソースに記入し管理することで、個々のリソースがどのようなデータを保有しているか、開発、サービスにおいてどのような使われ方をされているかがわかるようになり、また、詳細に知りたいときの問い合わせ先もわかるようになりました。
また、毎週定常的にチェックを行うことによって、開発チーム全体でのリソース管理の意識づけの強化にも繋がりました。

終わりに

この記事では、メタデータ管理の内容、またその効果についてご紹介しました。
一見すると地味な印象ではありますが、こうした運用を続けることで、普段使用する環境を、より整頓された、安心感のある環境へと改善できたのではないかと思います。

最後となりますが、現在Data Direction Groupでは、データエンジニアを募集しています。
ご興味のある方がいらっしゃれば、まずはお話をするだけでも構いませんのでお問い合わせをお待ちしています。
hrmos.co

*1:データエンジニアの職務について、同グループ所属の千葉がこちらの資料でも説明しています。https://speakerdeck.com/sansanbuildersbox/construction-of-business-card-data-analysis-infrastructure-and-future

*2:JSON/YAMLでテンプレートを記述し、それを元にサービスリソースを作成/更新/削除できるサービスです。

*3:CloudFormationのテンプレートの内容を複数の環境にまたがって反映できるという機能で、例えば、IAMの管理を全ての環境で同一にしたい時などに特に便利な機能です。

*4:ビジネス向けコミュニケーションツール。Sansanでも活用しています。

Sansan Tech Blog

Sansanのものづくりを支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信

DSOCで行なっているメタデータ管理について

概要