データ基盤をオンプレ＋AWSに刷新！ 技術選定とプロジェクト進行のポイントをマイナビの事例に学ぶ

【15-C-5】マイナビの全社データ基盤のモダナイズ

データ基盤をオンプレ+AWSに刷新！ どのような構成に？

　こうした課題に対して、マイナビではどのように解決したかを見ていこう。まずは導入したツールだ。「収集」「加工」では、データプレパレーションツール「Paxata」を導入した。事業部のユーザーなど非エンジニアでもデータ加工できるETLツールとなっている。「蓄積」はデータクラウド「Snowflake」。「活用」に関してはBIツール「Tableau」を導入した。なお、「検索」に関してはデータカタログに相当するものになるが「まだありませんが、導入を進めていきたいと思っています」とよそじ氏は言う。

　解決前後を比較するために、まずは導入前の構成から見ていこう。当初はすべてシステムはオンプレで構成されていた。他システムのSQL Serverから、WindowsのバッチとSystemwalkerでデータマートのSQL Serverへとデータを連携させていた。この主な理由は元システムの負荷を高めないようにするためだ。

　ただ課題もいくつかあった。データ連携部分では、処理スピードがなかなか出せず、Windowsバッチをうまく扱えるエンジニア確保にも苦戦した。またSSIS（ETL）がSQL Serverに依存していて技術の見直しが難しい、バージョン管理にも苦戦していた。

従来のオンプレ環境における課題

　スペックを高めようにも、オンプレなのでハードウェア増強は簡単ではなく、またVMのリソース管理も大きな負担になっていた。ディスクサイズを節約するためにデータ長を最小限にしたら、取得元のデータ長が変わってしまい対応に苦労したこともある。スペックを増やせない状況では、負荷増加を懸念してユーザーも気軽に増やせないという不自由さもある。

　BIはTableauを使用していたものの、6年前のスペックで使用していたため表示が遅い状態になっていた。データプレパレーションツールPaxataは一度データを貯めたうえで処理する仕様になっていたところ、ユーザーの利用量予測が難しくディスクサイズが足りなくなる事態にも遭遇していた。

　モダナイズ後は下図の通り。オンプレは残るものの、データ連携以降の右側をAWS（クラウド）に移行し、技術刷新した。

オンプレ+AWS環境に

　データ連携部分はWindowsからLinuxへとOSを変更し、インフラエンジニアに比較的馴染みがあるシェルスクリプトが使えるようにした。続いてEmbulkと組み合わせることで、データ加工におけるWindows依存を解消した。

　またワークフローエンジンにAirflowを採用、ここでPythonを使えるようになり、さらに並列化で処理スピードを改善できた。またサーバーレスのMWAAを採用することで運用コストを削減した。

　データレイクはAmazon S3にすることで、メンテナンスがほぼ不要となり、スケーラビリティも確保した。またデータマートで採用したSnowflakeとの相性がいいことも選定の決め手となった。S3はSnowflakeの外部ステージとしてログ分析なども行える。

　そしてデータマートにSnowflakeを採用することで、これもスケーラビリティを確保できて、ウェアハウスを分離できるので負荷分散も可能となる。また利用時のみ即時立ち上げができるため、利用料を最小限にできてコスト削減につなげることができた。よそじ氏は「SnowflakeはSaaSなので保守が要らなくなり、デジ戦が本来やるべきデータの民主化に注力できるようになったのはすごく良かったです」と話す。そして随所にGitHubでバージョン管理とレビューができる体制を敷き、オペレーションミスが減った。