オンプレミスサーバーからクラウドへ
マイナビのSnowflakeを活用したデータ基盤構築
HR事業やニュース、ウエディングなどの生活情報事業をはじめ、多角的な事業を展開している株式会社マイナビ（以下、マイナビ）では、管理効率の向上・コスト最適化を目的に、これまで社内で活用していたオンプレミスサーバーからクラウドへ移行するためデータ基盤をSnowflakeで構築されました。
本記事では、マイナビがSnowflakeへマイグレーションした背景や、構築中の工夫や苦労された点、導入後のアプローチについて、プロジェクトを推進されたマイナビの照井さま・長谷川さま・寺井さまと、同社のプロジェクトをサポートさせていただいたDATUM STUDIO 執行役員 兼 データエンジニアリング本部 本部長の菱沼の対談によりご紹介します。
スピーカー紹介
課題とSnowflake導入の背景
菱沼： 貴社が抱えられている課題とSnowflakeの導入に至った背景についてお聞かせいただけますか。
寺井さま：Snowflakeの導入を考えるきっかけとなったのは、これまで活用していたオンプレミスサーバーのリース終了でした。当初はサーバーリプレースも検討していましたが、いくつか課題がありました。スペック管理が煩雑でオンプレミスゆえ安易に増強することが難しい状況であることに加え、ライセンス数の制限がありました。また、一度導入した機器を使用し続けることは最新の環境と比較してスペックが劣ってしまいます。他にも、契約の複雑さが原因で工数を費やしていたこともあり、様々な課題を抱えていました。
オンプレデータベースの課題
Snowflake導入の決め手
寺井さま：これらを解決するにはクラウドへの移行が最適ではないか、と考えSaaSに焦点を当てて検討しました。データベースは、DWH（データウェアハウス）やデータレイクハウス製品を比較、検討しました。その中でも弊社の課題をダイレクトに解決できると考えたSnowflakeに注目し、特に次のメリットが導入の決め手となりました。
・SaaS型データプラットフォームで、サーバー管理が不要
・コンピュートとストレージのリソースを分離
・ウェアハウスが独立していることで、他のユーザーへの影響がない
・即時起動が可能なコンピューティングリソースで、コスト削減が可能
・高速なパフォーマンス
これらを踏まえ、TCO（Total Cost of Ownership：システムを導入してから廃棄・更新するまでにかかる総所有コスト）の観点でも、Snowflakeが圧倒的だと判断し、すぐにPoC（Proof of Concept：概念実証）を開始しました。
また、オンプレミスからクラウドへ移行した後で適切に運用していけるのか不安もあったため、DATUM STUDIOさんに相談し、Snowflakeの性能や可用性を事前に確認するべく、非機能要件の事前検証から始めました。
菱沼： 事前検証をしっかり行ったことでSnowflakeの凄みを実感・納得いただいた上で導入に至ったと思いますが、その後の成果についてはいかがでしたか。
Snowflake導入後の成果
長谷川さま：従来のリレーショナルデータベースではカラムごとの設定が必要でしたが、Snowflakeではこれらの制約が解消されたので、運用が大幅に簡略化されました。また管理者は、任意のユーザーやグループに対して、利用するウェアハウスを柔軟に指定でき、利用状況の集計を迅速に行えるようになりました。
性能面では、ほとんどのウェアハウスを最小構成（XS）に設定しているにもかかわらず、優れたパフォーマンスを発揮しています。以前のデータベースサーバーでは、クライアントアクセスライセンス数が利用者数を超えないよう常に注意を払う必要がありましたが、Snowflake移行後はその懸念も解消されました。加えて、外部サービスからのアクセス制限が緩和されたことでアクセスしやすくなりました。もちろん、セキュリティも十分担保されています。
さらに、社内の非エンジニアメンバーからの要望に基づき、BIツールを活用したダッシュボードでデータの可視化・共有が実現したことで、データの民主化が加速し、社員のデータ利活用が着実に進んでいます。
菱沼：Snowflakeの導入でこれまでの課題が解決され、効果を実感いただいているようで安心しました。弊社はこれまでも数々のクライアント企業のクラウドシフトをご支援してきましたが、それには多くの苦労が伴うことも事実です。貴社においてSnowflakeへのマイグレーションでどんな点に苦労されましたか。
マイグレーションにおける苦労と工夫
寺井さま：特に苦労したのは、Tableauとの連携です。
BIを活用して様々な切り口からデータを分析するため、フィルターが多用されます。その結果、必然的に条件やクエリが増えることになるためそこで苦労がありました。具体的にはクエリテキストサイズの制限と、IN句やWHERE句における要素数の上限という2点です。これらの課題についてはDATUM STUDIOさんにも調査・調整をしていただくなど、ご尽力いただきました。
菱沼：あれは本当に大変でしたね。クエリテキストのサイズ制限により、1ステートメントあたり1MBを超えるクエリはメタデータストアに永続化される前に切り捨てられることが明示されています。BIの仕組みを考慮しながら解決策を検討し、マイナビ様の社内調整を経てBI側の修正を実施しました。
寺井さま：若干力業な部分もありましたが（笑）、データソース側に依存せずBI側でデータのフィルタータイミングや最適化を図る必要性をあらためて感じました。要素数の上限については、BI側のフィルターのかけ方が原因となり要素が大量になっていたため、その部分を修正しました。ただ、参照すべきドキュメントが見つけられず、その際もDATUM STUDIOさんのフォローアップに助けられました。
菱沼：対応すべきダッシュボードの数も多かったので、あれも大変な作業でしたね。
寺井さま：その後、Power BIのセキュリティ統合の設定にも苦労しましたね。ユーザー追加時にデフォルトロールを設定していなかったため、何らかのデフォルトロールが指定されていないと認証がうまくいかなかったことを覚えています。
マイナビ社内のSnowflakeユーザーは非エンジニアの方も多いため、ユーザー登録時には「PUBLIC」をデフォルトロールとして設定するようにしました。
菱沼：これについては仕様上致し方ない部分ではありますが、現在はPower BIとの統合時におけるエラーのトラブルシューティングがドキュメントに記載されています。当時と比べて対応が難航するケースは減ったと思います。
寺井さま：ツールからのドライバ利用の部分では、テキスト型で取り込まれていたのがデータ型で認識されてしまいドライバの挙動が既存のデータベースと異なっていたケースもありました。DATUM STUDIOさんがテスト時に発見してくださったおかげで、テキスト変換処理を入れることで元の挙動を維持できました。
菱沼：我々もこれまでの経験とナレッジを活かして注意すべきポイントを予測することはできますが、バージョンアップの都度、挙動の変更や改善があるので、丁寧に一つずつ確認していくことが最善策です。
他にも転送検証を実施しましたが、長谷川さま、いかがでしょうか。
長谷川さま：私がクラウドシフトにあたり最も心配だったのは、「毎日の更新データをSnowflakeにきちんと送信できるか」でした。
以前は、送信元と送信先が同じデータセンター内にありかつ、Gbit（ギガビット）のLANで接続されていたので、データ通信の帯域を気にすることはありませんでした。
しかし、調達したAWSへの回線は500Mbps（毎時180GB）で、本プロジェクトの途中でデータ送信に時間を要するという理由で立ち往生したくはありませんでした。
1日の送信データ量が約600GBで、それを毎時180GBで送るためには理論上では3時間20分ほどかかってしまいます。
送受信するデータ量の検証
SnowflakeはCSVだけでなく、圧縮したCSVやORC、ParquetといったHadoopエコシステムで生み出されたファイルフォーマットに対応しているので、データを圧縮して送信する方法を検討しました。「Zstandard」（※）という、当時登場したばかりの圧縮ツールで検証した結果、圧縮データを毎時180GBでAWS S3に格納できました。
この検証は苦労というより、工夫しながら楽しんだ点です。
圧縮形式の比較検証
菱沼：SnowflakeがZstandardに対応していたことは本当に良かったです。gzipやbzip2などの既存の圧縮方式ではなく後発の方式なので、圧縮率はそのままで高速化されています。データ連携において可能であれば選択したい圧縮形式です。
※Facebookが開発した高効率な圧縮アルゴリズムで、データ圧縮と解凍の速度が非常に速く、圧縮率も高いという特長がある。
Snowflake活用した今後のデータ基盤
照井さま：マイナビには複数の組織によって構築されたことでデータ基盤がサイロ化しています。一部は既にクラウド移行が完了していますが、オンプレミスの基盤も残っている状況です。サイロ化したデータ基盤を全社で統合するため、Snowflakeとdbt™を活用することで統一されたデータ基盤の構築を目指しています。
マイナビが目標とする今後のデータ基盤（目標とする構想）
全社データの統合においてSnowflakeを採用する理由は、既に実績があり効果が証明されているためです。加えてdbt™を選定した理由は、当社のデータ基盤において数千件に及ぶデータ加工処理をしなくてはならないことにあります。従来はジョブフローやデータパイプラインの処理順序を設計書ベースで管理・運用してきましたが、データの依存関係と処理順序を別々に管理する必要があり、その結果として構造が複雑化し管理上の負担が大きくなっていたことが課題でした。
dbt™を導入することで、テーブルの依存関係から自動的に処理順序が決まるので、データの依存関係と処理順序を一元管理することができます。また、dbt™ではデータの依存関係が解析された状態で動作するため、ドキュメントが自動生成され設計情報と実装がシームレスに連携し、二重管理が不要となる点も大きなメリットと言えます。
ただし、全てのデータ基盤を統合することが必ずしも最適解ではないと思います。当社は様々なサービスや組織で編成されており、AI開発やマーケティングを担う組織では、施策のスピード感が重要です。
データ基盤の統合とスピード担保を両立するため、データ基盤をハイブリッド構成で運用することを考えています。マイナビの各組織では施策のスピードを重視して独自のデータ基盤を活用し、全社的なデータ統合ではSnowflakeとdbt™を中心とした盤石なデータ基盤を構築することで、データの利活用を健全なガバナンスが機能した形で実現していきます。
「データメッシュな各組織のスピード」と「データファブリックな全社統合」を両立させながら、データ基盤の最適化を進めていきます。
マイナビが目標とする今後のデータ基盤（現実的な構想）
菱沼：非常に意欲的なデータ基盤を目指されていますね。データスペシャリストとして、私たちDATUM STUDIOの面々も技術力を深化させてまいります。
マイナビ様のプロジェクトは、今後も支援させていただきますので引き続きよろしくお願いいたします！
本日はありがとうございました。
DATUM STUDIOのケイパビリティ
マイナビ様からは、本プロジェクトのマイグレーション中に発生した問題や課題に対する原因調査から解決までのスピードと確実性において「DATUM STUDIOは技術者の精鋭集団である」と高い評価をいただきました。
DATUM STUDIOは、国内における多種多様な業種のお客さまのデータエンジニアリング、データサイエンス、データ分析プロジェクトで培った豊富な実績と知見があります。
当社に在籍する100名以上の「データのスペシャリスト」がお客さまの経営上の課題を的確に捉え、その解決と安定的なデータ運用を実現するためのアーキテクチャを設計・構築します。また、Snowflakeを活用した分析サービスやCRMなどの各種システムと連携させた施策実行まで、End to Endでサポートします。
