SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2024 セッションレポート(AD)

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

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

  • X ポスト
  • このエントリーをはてなブックマークに追加

 1973年8月に「毎日コミュニケーションズ」として誕生し、2011年に社名変更したマイナビは、2023年で50周年を迎えた。当初は新聞の発行、出版、絵画の輸入販売から始まり、今では多様な事業を展開するグローバル企業となっている。今回はマイナビが取り組んだ全社データ基盤のモダナイズについて、同社 デジタルテクノロジー戦略本部 よそじ氏と蛭田彩代子氏が解説する。

  • X ポスト
  • このエントリーをはてなブックマークに追加

マイナビのデジタル戦略と、データ活用を5つのフェーズに分解して見えた「ある共通点」

 マイナビは2023年に50周年を迎えた。事業セグメントはキャリアデザイン、HR、ヘルスケア&ウェルネス、人材派遣&BPO、メディア&サービスなどがあり、50を超える多様なサービスを展開している。同社 デジタルテクノロジー戦略本部 IT企画推進統括部 IT企画推進部 IT企画推進3課 蛭田彩代子氏は「50年の変遷で培ったノウハウは大きな強みです」と話す。

株式会社マイナビ デジタルテクノロジー戦略本部 IT企画推進統括部 IT企画推進部 IT企画推進3課 蛭田彩代子氏
株式会社マイナビ デジタルテクノロジー戦略本部 IT企画推進統括部 IT企画推進部 IT企画推進3課 蛭田彩代子氏

 同社では、かつてITやWebマーケティング職をそれぞれの事業部署に分散していた。しかし急速なデジタル変革に適応するため、2022年10月にITやWebマーケティング職を集約したデジタルテクノロジー戦略本部を設立した。社内では「デジ戦」と呼ばれている。現在では500名を超えるメンバーが在籍しており、今後も拡大していく予定だ。

 このデジ戦は「Drive Digital Innovation」をミッションに掲げ、組織の理想像や中長期的な目標として「1人ひとりが常にチャレンジし、既存の枠組みを超え、新たなイノベーションを生み出す」ことをビジョンに描いている。具体的には全社のデジタル戦略の立案と実行を担うため、各部署と連携しながら全社横断的なプロジェクトに携わっている。

デジタルテクノロジー戦略本部
デジタルテクノロジー戦略本部

 つづいて、蛭田氏と同じくデジタルテクノロジー戦略本部で、データ活用を推進するよそじ氏が、今回のテーマでもあるデータ基盤のモダナイズについて解説した。まず前提知識として、よそじ氏は「データ活用」をいくつかの段階に分解。それが「収集」「加工」「蓄積」「検索」「活用」の5つとなる。

株式会社マイナビ デジタルテクノロジー戦略本部 デジタルプラットフォーム統括本部 データソリューション統括部 データ活用推進部 データ活用推進1課 課長 よそじさん氏
株式会社マイナビ デジタルテクノロジー戦略本部 デジタルプラットフォーム統括本部 データソリューション統括部 データ活用推進部 データ活用推進1課 課長 よそじ氏

 ざっと説明すると、「収集」はサイトのログや、各部署のExcelファイル、データベースなどからデータを収集する。「加工」は、例えばExcelならピボットテーブルやセル結合など、そのままではデータ活用できないものを加工する。「蓄積」では、例えばExcelファイルだと重くなるにつれ扱いが不便になるので、どこかのデータベースなどに蓄積したりする。このようにしてデータが増えると探すのに苦労するので「検索」が必要になる。そして最後に、「活用」することが最も重要だ。

 それぞれのフェーズにおける課題には次のようなものがある。「収集」「加工」では、データ連携や変換のための仕組みが必要になる。また「蓄積」では、データベースの維持にコストがかかることや、複雑なクエリでスピードが出ないなどの課題がある。「検索」では必要なデータがどこにあるか探すためにテーブルの定義書や各種ドキュメントを参照したり、データの管理者に問い合わせたりする。そして「活用」では、データ更新が難しい、レポート作成のたびにグラフを作成し直すなど、効率的に活用するにはまだまだ工夫が必要だ。

 ここでよそじ氏は「共通している部分があります。それはデータ活用を進める上で、エンジニアの負担が大きいことです」と指摘する。

データ活用ではエンジニアの負担が大きい
各フェーズのエンジニアの負担が大きい

データ基盤をオンプレ+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でバージョン管理とレビューができる体制を敷き、オペレーションミスが減った。

移行のための技術選定とプロジェクト進行のポイントは?

 技術選定のポイントには、大きく分けて組織と技術の2つの観点がある。組織的な観点だと、「人的なコストも含めたTCO(総保有コスト)を考慮する」「仕様変更がある場合に事業部ユーザーが対応できるか」「人材が多く確保できる言語・技術を選定する」「メンバーが疲弊しないようにチーム全体で運用・保守できるか」「他組織との連携」が挙げられる。

 技術的な観点としては、「要件を満たせるか(既存の利用・運用維持が最低限)」が当然ながら大事になる。そのうえで5年先を見すえて「大きな改修・廃止をしないですみそうか」「ベンダーロックインしにくいか」も考慮しておいたほうがいいだろう。

 プロジェクトは約1年半ほどかけた。最初に非機能要件を事前に検証し、社内調整した。もし非機能要件を満たせなければオンプレ更改も視野にいれていたものの、社内調整で許容範囲内に収めることが可能となった。続いて、OS変更やアップデートでコンテンツ移行がうまくいくか、想定通りデータマートまで流せるか、各処理で同じデータを流せるか、既存の年次切り替えなどのオペレーションが実現できるかなどを検証した。

 検証は優先順位が高いものから実施し、ある程度進むと残処理の開発を並行して行った。終盤にはコンテンツが今まで通り使えるかを確認するために環境移行と並行稼働を挟み、最後に事業部ユーザーと協力してコンテンツを移行し、新環境の利用を開始した。

 プロジェクトを振り返り、あらためて良かった点としてよそじ氏は「机上の見込みではありますが、向こう5年のTCOを約8000万円削減、データ連携速度は1時間以上短縮、エラー対応時間は少なくとも年100時間以上削減できました。またユーザーを増やしやすくなったことで、新たな用途の提案も出てきています」と話す。

 逆に反省点を挙げるなら、技術選定時に把握しきれなかった仕様があったこと。例えばSnowflakeにはクエリ長やリスト数の制限がある。BIツールと組み合わせることでフィルターでクエリ長が長くなり、上限に達してしまうことがあった。他にもMWAAのオートスケーリングではバグを踏んでしまい、ゾンビタスク(実行されるはずだが実行されていないタスク)が発生してしまった。ここはオートスケーリングを回避することで対処した。

 他にもユーザー部門との調整時間の見積もり不足が挙げられる。ユーザー部門は通常業務の合間に対応するため、なかなか時間がとれず進行的に危ぶまれたものの、ドキュメント作成や作業巻き取りなどでカバーした。最後に他部署担当機能の仕様に対する理解不足もある。例えばSnowflake利用でAzureADを利用することになったものの、SnowflakeとAWSを繋ごうとした時に社内ルールの都合でプライベートリンクを利用できなかった。「関連部署と詳細な情報を連携して確認すべきだった」とよそじ氏は言う。

 最後によそじ氏は「データ活用はそれぞれのフェーズで課題があり、エンジニアの負担が大きいものの、こうして技術刷新でエンジニアの負荷軽減と採用しやすい体制作りに取り組んでいます。技術選定では組織的な観点と技術的な観点の両面から考慮する必要があります。プロジェクトを進めるうえでは、落としてはならないところを確認し、段階を踏んでいくことが大切です」とまとめた。

 今後については「モダナイズが進んだことで、データ民主化に充てられる時間が増えました。ユーザー向け勉強会開催ほか、戦略策定、全社KPI、データ統合、AI民主化、ツール導入など、やりたいことが多くあります。他部署とも力を合わせてデータ民主化に資する活動を行っていきたいと思います」と力強く述べた。

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加

提供:株式会社マイナビ

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/19163 2024/05/10 12:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング