マイナビの内製開発におけるクラウドインフラ構築で抱えていた「3つの課題」
就職・転職・アルバイトなどの人材サービスや、ニュースメディアをはじめとした生活情報サイトの運営など50以上の多種多様なサービスを運営するマイナビでは、これまで一部サービスのクラウドインフラを内製開発してきたが、その開発・運用プロセスにはいくつかの課題を抱えていたという。
同社の内製開発の大まかな手順は、まずは企画チームとアプリチームが要件をすり合わせた後、クラウドチームがクラウドインフラの開発に着手する。アプリチームはインフラ環境が整うまでの間、ローカルのDocker環境で開発作業を進め、環境が整いしだいクラウド上での開発に移行するという流れで進められてきた。
なお同社では、IaC（Infrastructure as Code）ツールとしてAWS CDK（Cloud Development Kit）を採用している。AWSが提供しているBLEA（Baseline Environment on AWS）を自社用にカスタマイズしたベースコードを開発しており、プロジェクトの要件に応じてリソースの追加、設定変更、削除といった改修を行い、AWSリソースをデプロイしている。またコードに改善点が見つかった場合は、ベースコード側に取り込むことで次回以降のプロジェクトに反映されるような改善サイクルを確立している。
しかしマイナビ デジタルテクノロジー戦略本部 ビジネスイノベーション統括本部 クラウドインテグレーション統括部 クラウドエンジニアリング部 エンジニアリング1課 課長 小原夏々子氏によれば、この一連のプロセスには3つの大きな課題があったという。
「1つ目の課題は、クラウド環境を提供するまでのリードタイムが長いという点でした。アプリチームとクラウドチームの動き出しのタイミングが異なるため、クラウドチームに話が来てから初めてヒアリングや要件定義の作業を開始し、構築を行う必要がありました。そのため、クラウドインフラ環境の提供までに1か月以上のリードタイムが発生していました」
なお2つ目の課題は、「インフラ環境を提供した後の手戻り」だった。アプリエンジニアはローカルのDockerで開発を行うケースが多いため、自ずとクラウドインフラ構成もコンテナを用いた構成が多くなる。しかし、ローカル開発が進んだタイミングでクラウド環境へデプロイを行うと、アプリケーションのデプロイがうまくいかないほか、ローカルで動いていたものがクラウドのインフラ環境では動かないといったトラブルが多発していた。
そして3つ目の課題は、「運用の属人化」だった。個別にAWS CDKコードを改修するため、開発に関わったメンバーや担当者しか詳細を把握できておらず、運用フェーズで問題が発生した際に状況把握に時間がかかっていた。担当しているプロジェクトが多いこともあり、全体像の把握は困難で、結果として運用の属人化が深刻化していた。
「集約」「自動化」「開発環境の最適化」による解決アプローチ
これらの課題を解決するためにマイナビが目指したのが、「数日間のリードタイムで環境を提供でき、開発時の手戻りが少なく、誰でも運用可能な集約基盤の開発」だった。具体的には、ALB（Application Load Balancer）やコンテナ、データベースなどをプラットフォーム化し、一元的に構築・管理できるとともに、複数のユーザーの要請に応じてクラウドリソースを素早く提供できる「マルチテナント型集約基盤」の実現を目指すことにした。
この仕組みを実現する上で重要なポイントになったのが、「集約」「自動化」「開発環境の最適化」の3つの取り組みだった。まず「集約」については、AWSアカウントとリソースの集約を実施。アカウント発行までのリードタイムを短縮し、サービスや環境ごとに作成される大量のAWSアカウント管理の負荷も軽減した。さらに、環境ごとに作成して複数サービス間で共有して利用する「共有リソース」と、サービスごとに個別に作成する「専有リソース」を切り分け、一部の共有可能なリソースを節約することにした。
「自動化」においては、コンテナ構成のパターン化とパラメータファイルの自動生成を実現した。コンテナ構成をパターン化することで、ヒアリングや構成検討にかかるリードタイムを短縮するとともに、プロジェクト独自の構成がなくなることで誰もが運用可能になり、「運用の属人化」という課題も解決できた。
さらには、インフラ構築のリードタイムを短縮するため集約基盤の新規サービス作成依頼をGoogleフォームから受け付け、CDKをデプロイする際に必要なプロジェクト独自の設定を記述したパラメータファイルを自動生成する仕組みも構築した。その実装を担当した同社 デジタルテクノロジー戦略本部 ビジネスイノベーション統括本部 クラウドインテグレーション統括部 クラウドエンジニアリング部 エンジニアリング1課 横尾風太氏は、具体的な仕組みと成果について次のように説明する。
「Googleフォームで入力したデータをGoogle Apps Scriptで連携してJSONに変換し、Amazon S3に保存します。その後AWS Lambdaが動作し、承認者の確認を経てCDKパラメータファイルを含むCDKコードが自動作成され、プルリクエストが投げられる仕組みを実装しました。これにより、後続のGithub ActionsとAWS CodePipelineによる自動デプロイを実現しました。さらに今まで手動で対応していたクロスアカウントでのACMのDNS検証についても、カスタムリソースを活用してCDKで対応できるようにし、自動化を実現したことでインフラのデプロイがCDKで完結するようになりました」
そして「開発環境の最適化」では、まずコンテナデプロイ方式のパターン化を実施した。これまでの内製開発ではプロジェクトごとにデプロイ方式を選定していたため、標準化されたデプロイ方式がなく、アプリチームでナレッジが蓄積されにくい状況だった。そこで、Amazon ECS用のデプロイツール「ecspresso」を使用したローリングデプロイと、AWS CodeDeployを使用したBlue/Greenデプロイの2パターンを用意。これによりプロジェクトごとの違いがなくなり、ナレッジの蓄積が進むとともにデプロイ時のトラブルも減少したという。
また、オブザーバビリティツールとしてNew Relicも新たに採用した。集約基盤ではAWSアカウントを集約している関係上、アプリチームのAWSコンソールへのアクセスを制限している。そのためコンソールに入れなくても開発に支障が出ないよう、コンテナログやCloudWatch Metricsなど、集約基盤で扱うAWSサービス関連のデータを収集でき、アプリログの収集・監視までも一元管理できる環境を整備した。
集約基盤の運用開始後に明らかになった課題とその解決策
しかし実際にコンテナ集約基盤の運用を開始すると、いくつかの課題が浮上した。「AWS Management Consoleに入れず開発しづらい」「デプロイ手順が複雑で分かりにくい」「新しいソリューションの使い方が分からない」といった声がアプリチームからあがってきたのだ。その理由について、小原氏は次のように考察する。
「本来は利用者であるアプリチームに対して『どういった環境であれば開発しやすいのか』『どのような形で開発を進めたいのか』などの点について、詳細にヒアリングして開発を進める必要がありました。しかし開発者目線でのヒアリングが不足していたため、開発者の立場に立った集約基盤構築ができていませんでした」（小原氏）
これらの課題に対し、同社はさまざまな改善策を施した。まずデプロイ手順の課題についてはハンズオン形式でレクチャーを実施し、開発チームによる利用が軌道に乗るまでのフォローを行うとともに、デプロイ設計を見直してより簡素化を図った。
AWS Management Consoleが直接利用できないという課題については、ビルドステータスのチャット連携の追加や、New Relicダッシュボードのカスタマイズによる必要なログやメトリクスの収集・確認の効率化、さらにはスプレッドシートとGitHubワークフローを利用したSecrets更新とECSタスク定義ファイルの更新の自動化など具体的な改善策を複数実施した。
こうした対策が功を奏し、同社の内製開発における集約基盤の活用は前進しつつあるが、小原氏は「現在の集約基盤はまだまだ未成熟な状態です。この状態で既存サービスを乗せ替えてしまうのはリスクが大きいため、まずは新規の内製案件の実績を増やし、軌道に乗った段階で既存サービスの集約も進めていきたいと考えています」と今後の抱負を語る。
さらに中長期的には、未対応のAWSサービスへの対応やサービス側からの要望に対する開発、他のクラウドサービスとの連携やマルチクラウド化なども視野に入れているという。最後に小原氏は「常に開発を続け、マイナビの新たなイノベーションへの貢献につなげていきたい」と意気込みを語った。
