マイナビ流、内製開発を支えるマルチテナント型集約基盤、そのメリットと課題とは

「デベロッパーをスターにし、世の中のアップデートを加速する」というミッションを掲げ、2003年から毎年開催されているITエンジニアの祭典「Developers Summit（デブサミ）」。2025年2月13日～14日の2日間にわたって開催された「Developers Summit 2025」には、ビジネスの最前線で活躍するITエンジニアが集結し、生成AIをはじめとした最新テクノロジーの活用方法や、企業や社会の価値を高める取り組みが紹介された。本稿では、2月13日に行われたマイナビのセッション「マイナビの内製開発を支えるコンテナ基盤設計開発の舞台裏～自動化で楽々デプロイ！でもアプリチームからはちょっと不評？～」についてレポートする。

既存の内製開発プロセスで顕在化していた3つの課題

2023年に創業50周年を迎えたマイナビは、1973年に就職情報誌の発行や出版業、絵画の輸入販売を手がける企業として設立して以来、多様な事業を展開する大手人材・広告企業へと成長を遂げ、「キャリアデザイン」「HR」「ヘルスケア＆ウェルネス」「人材派遣BPO」「メディア＆サービス」「海外」という6つのセグメントで、50以上のサービスを展開している。

規模もジャンルも異なる多種多様なサービスの一部におけるクラウドインフラ環境を内製で開発しているのが、本セッションに登壇したデジタルテクノロジー戦略本部ビジネスイノベーション統括本部クラウドインテグレーション統括部クラウドエンジニアリング部の小原夏々子氏と横尾風太氏だ。

内製構築チームにて新規プロダクトや集約基盤の開発運用を担当している小原氏は、マイナビにおける内製開発、及び運用において顕在化していた課題について語り、セッションを開始した。

「これまでの内製開発では、サービスの企画を担当する企画チームとアプリチームが要件をすり合わせ、ある程度固まった段階で私たちクラウドインフラチームに具体的な話が降り、そのタイミングでクラウド開発に着手する形でした。アプリチームはクラウドインフラが構築されるまではローカルのDocker環境で開発を進めて、インフラ環境が整い次第、クラウド上での開発に移行するという流れで進めてきましたが、そこにはいくつかの課題がありました」（小原氏）

小原氏は、既存の内製開発が直面していた課題として、次の3つを挙げる。

① リードタイムの長さ（最低でも1カ月程度のリードタイムが発生）
② インフラ環境を渡した後の手戻り
③ 運用の属人化

「アプリチームとクラウドインフラチームでは動き出しのタイミングが異なったため、クラウドインフラ環境を提供するまでにはどうしても1カ月以上のリードタイムが発生してしまいました」と、小原氏は①の課題について説明。さらに、ローカル環境で開発が進められていたアプリをクラウドにデプロイした後にトラブルが多発し、手戻りが発生していたと②の課題にも言及する。

マイナビのクラウドインフラ開発では、IaC（Infrastructure as Code）ツールとして「AWS CDK」を採用し、AWSが提供するテンプレート「BLEA（Baseline Environment on AWS）」を自社向けにカスタマイズする形でCDKベースコードを開発、プロジェクトの要件に応じてベースコードを改修している。コードに改善点が見つかった際にはベースコード側に取り込むことで、次のプロジェクトに反映するというアプローチで行われてきた。

「プロジェクトごとにCDKベースコードを改修しているため、開発に携わったメンバーしか詳細を把握しておらず、運用フェーズで問題が発生した際の対応が遅れるといった問題が生じていました」と小原氏。担当するプロジェクトが多いこともあって、③で提示した属人化の課題が顕在化していたと話を続ける。

「集約」「自動化」「開発環境の最適化」をキーワードに集約基盤の開発に着手

こうした課題を解決するため、マイナビは「数日のリードタイムで環境を提供」でき、「開発時の手戻りが少なく」、「誰でも運用可能」なプラットフォームの開発に着手する。キーワードは「集約」「自動化」「開発環境の最適化」と小原氏は語る。

株式会社マイナビデジタルテクノロジー戦略本部ビジネスイノベーション統括本部クラウドインテグレーション統括部
クラウドエンジニアリング部エンジニアリング1課課長小原夏々子氏

構築・運用の対応だけで手一杯になってしまう状況を改善するために、マルチテナント型集約基盤の構想に至ったと小原氏は説明する。

「コンテナとデータベースを社内サービスとして提供するコンテナ基盤を用意し、インフラのデプロイを自動化することでリードタイムの短縮を図るのに並行して、初期段階からクラウド上で開発できるようになるため、アプリをクラウドにデプロイした際の手戻りも減らすことが可能です。運用の属人化に関しては、1つの基盤上に複数システムを集約し、全員で運用することで属人化の進行を防げると考えました」（小原氏）

「集約」に関しては、AWSアカウントを集約することで事務手続きにかかっていたアカウント発行までのリードタイムを短縮。サービスや環境ごとに作成される大量のAWSアカウントの管理も不要となり、運用負荷も軽減された。また、環境単位で作成してサービスを共用する「共有リソース」と、サービス単位で個別に作成する「専有リソース」の切り分けを行うことで、一部のリソースを節約することに成功したという。

「自動化」に関しては、Googleフォームへの申請内容からCDKパラメータファイルを自動生成することで、工数削減とリードタイム短縮を実現。申請を受けてから1営業日でインフラ環境の提供が可能になったと小原氏は語り、「自動化のアプローチにより、集約基盤構築の目的であるリードタイム短縮、運用属人化の解消への一歩を踏み出すことができました」と手応えを口にする。

「開発環境の最適化」に関しては、コンテナデプロイ方式のパターン化とオブザーバビリティツールの選定という2つのアプローチを推進。前者ではecspressoを使用したローリングデプロイとCodeDeployを使用したBlue/Greenデプロイの2パターンを用意。デプロイ方式の標準化とナレッジの蓄積により、デプロイ時のトラブル軽減とアプリチームの属人化解消にも寄与しているという。後者ではコンテナログやCloudWatchメトリクスなど集約基盤で扱うAWSサービス関連データを収集でき、アプリログの収集・監視までを一元管理できるNew Relicを採用。アプリチームが開発しやすい環境の提供を目指したという。

デプロイ自動化に向けた開発アプローチ、工夫したポイントとは

セッション中盤では、集約基盤の開発を担当した横尾氏が登壇。デプロイ自動化に向けた開発アプローチについて、より踏み込んだ内容が語られた。

株式会社マイナビデジタルテクノロジー戦略本部ビジネスイノベーション統括本部クラウドインテグレーション統括部
クラウドエンジニアリング部エンジニアリング1課横尾風太氏

これまで手動で対応していたCDKパラメータファイルの作成を自動化することでデプロイの効率化を図ったと言う横尾氏。

「集約基盤では、複数のサービスを管理するため、サービス単体への切り分けが不可欠です。各サービスに異なるパラメータが必要になるため、パラメータファイルによる管理方式を採用し、GoogleフォームからCDKパラメータファイルを自動生成する仕組みを導入しました。」

実装内容について横尾氏は次のように説明する。

「まずGoogleフォームで入力したデータをGAS（Google Apps Script）に連携し、JSONファイルに変換します。S3（Amazon Simple Storage Service）に保存後、Lambdaが動作して作業者に承認を求め、承認されるとLambdaが実行され、CDKパラメータファイルを含むCDKコードが自動作成されるプルリクエストになります。ここまででパラメータファイルの自動作成は完了しますが、さらにリソースを構築する場合は、作業者がプルリクエストをマージすることでGitHub Actionsが実行され、自動デプロイが可能になります」（横尾氏）

ただ、この実装ではパラメータファイル作成の自動化は実現できたものの、CDKだけでは対応できないケースが発生したという。集約基盤のAWSアカウントとRoute53の管理アカウントが分かれていることから、必要なクロスアカウントでのACMのDNS検証が、CDKではサポートされないため、カスタムリソースを活用してACMのDNS検証の自動化を図ったと横尾氏は説明する。

「カスタムリソースは、CloudFormationの処理を拡張する仕組みです。CDKはCloudFormationのテンプレートを転換する仕組みのため、CloudFormationのサポート外となる処理については実装することができません。このため、今回のケースではカスタムリソースを活用して自動化を実現しています」（横尾氏）

カスタムリソースを活用した結果、今まで手動で実施していたACMのDNS検証設定が自動化でき、AWSリソースをCDKで一元管理できるようになったと横尾氏。「申請から1日で環境の引き渡しが可能となりました」と自動化による効果を語った。

新規内製案件での利用実績を増やすとともに、既存サービスの集約も推進していく

セッション後半では、小原氏が再び登壇。集約基盤構築後の運用フェーズで見えてきた課題や反省点について話が展開された。

集約基盤が形になり、内製開発での利用が始まったものの、実際に使用したアプリチームからは「AWSのマネジメントコンソールに入れず開発しづらい」「デプロイ手順が複雑でわかりにくい」「新しいソリューションの使い方がわからない」といった意見が寄せられたという。アプリチームから不満の声が生じた要因について、次のように分析する。

「本来はプラットフォームエンジニアリングの考え方のもと、開発者が効率的に開発を行える基盤を作ることが理想だったのですが、開発者であるアプリチームへのヒアリングが不足していることに気付きました」（小原氏）

小原氏は、New Relicの活用を進め必要なログ・メトリクスの収集を効率化することでマネジメントコンソールへ入れない不自由を解消したり、デプロイ設計を見直し、手順を簡素化したりといったアクションで、フィードバックに対応したと説明。

「まだまだ課題点が残る集約基盤ですが、新規内製案件での利用実績を増やし、軌道に乗った段階で既存サービスの集約も進めていく予定です。今後は、New Relicの APMを導入することで、KPI/KGIといったビジネス指標をダッシュボード上で可視化し、アプリチームだけでなくSE職や経営層にとっても利用価値のある集約基盤を目指していきます」（小原氏）と今後の展望を語り、セッションを締めくくった。