【インターン体験記】ミラティブで学んだ大規模データ管理APIの設計と実装

はじめまして！2025年10月に1ヶ月間、株式会社ミラティブ・バックエンドチームでインターンをさせていただいた渋谷圭亮と申します！

この記事では、株式会社ミラティブで1ヶ月インターンをして取り組んだタスクやミラティブで働くことの楽しさを書いていきます。
これからインターンを検討されている学生の方に届けば嬉しいです。

自己紹介

信州大学大学院修士1年の渋谷と申します。大学院では農作業における暗黙知を収集するためのソフトウェア開発や手法の研究を行っています。

僕自身コンピュータサイエンスを学ぶ学科に所属していましたが、今年に入ってからWeb開発を始めました。Web開発ではバックエンドをよく触ります。

なぜミラティブのインターンを選んだのか

きっかけはWantedlyでスカウトをいただいたことでした。
以前から長期インターンを探しており、ミラティブが募集していることは知っていました。当初は技術的なハードルを感じてなかなか応募できずにいたのですが、技術に向き合い続ける中で「そろそろ挑戦できるかも」と思ったタイミングでスカウトがきました！

以下の2点で魅力を感じ、書類選考 + 面接（1回）を経て参加となりました。

個人開発では体験できない大規模サービスに対して実装してみたい（爪痕...？）
「わかりあう願いをつなごう」というミッションがエンジニアにも浸透しており、働きやすさを感じた

カジュアル面談で人事の方と話した際に、インターン生を受け入れる際にエンジニアの方もかなり協力的であること、配属チームのMGRとの面接で僕という人間をしっかり見てくださり、丁寧に対応いただいた部分が決め手で参加となりました。（本当に書ききれないくらいミラティブはいい人ばかりです...）

実際やったこと

取り組んだタスクとしては、以前までCSVで管理していたデータをDBで管理できるようにし、その際にミラティブ独自の管理画面から処理ができるようにするといったタスクでした。

インターンでは、以下の流れで取り組みました。

環境構築・模擬タスクの実施
割り振られたタスクについてPdMまたはメンターと相談、実装仕様に落とし込む
バックエンド相談会
実装

まず、ミラティブは環境構築のノウハウがConfluenceにかなり丁寧にまとまっており、困っていたらメンターさんがすぐに対応してくださるおかげで特に詰まることなく終わりました（大感謝）。

模擬タスクについては、PdMさんからの仕様に基づいてメンターさんが想定したToDoを設けてくださり、そこで実装を行ってリポジトリに対する理解を深めました。

それを終えると正式な仕様書が渡され、仕様書に書いていないがはっきりさせておかないといけない部分をひたすら質問し、考えて実装仕様書に落とし込みます。

そして、バックエンド相談会という僕がジョインしたチームのバックエンドエンジニアが全員集まるミーティングで実装仕様について話し合い、「仕様として問題がないか？」「見落としがないか？」を見極めます。
実際僕は2回開催させていただき、話していくうちに足りてない実装・観点に気づくことができ、より深く考えるようになったので非常に良い仕組みでした。

これらをすべて終えて、実装に取り掛かります。今回は僕が取り組んだ、管理画面から新規データを挿入する箇所および更新する箇所について述べていきます。

要件

タスクとしては、従来スプレッドシートで管理していたデータをゲームサーバで管理できるようにリプレイスするといったものでした。そのためのデータ管理画面及びAPI作成・DB設計が必要でした。僕はAPI作成・DB設計を行いました。

管理画面から送られるデータは、複数カラムを持つCSV形式で、1回の取り込みで複数レコード（数万行規模）を扱うことが想定されていました。
具体的には

CREATE：新しいCSVデータを挿入
READ：データ自体を見れるようにダウンロード
UPDATE：既存データに対して新しいCSVデータを挿入（更新）

をできるようにすることです。

また、定期的に不要になったデータを削除するためのDELETE処理もAPIの実装要件に入りました。
この記事では、CREATEとUPDATEの部分に絞って書いていきます。

実装

要件を理解しつつ、いざ実装に入りましたが、これまで作ってきた単なるCRUD処理とは全く異なり、応用的な要素が多く苦戦しながら取り組みました。

その際に、以下の課題が浮かび、メンターさんと相談しながら対応したことが印象的だったので記載します。

共通：CSVは数万行もあるが、管理画面から実行して途中で失敗したらどうするのか？
UPDATE処理：重複したデータも含めて再度すべて更新するのか？

今回の実装では

DBをスパイクさせないようにDBへの操作をする
データを受け付け、どうすれば効率よく、そして楽に実装・処理できるか

といった部分にフォーカスしてタスクに取り組みました。

CREATE処理

まず、CREATE処理についてです。
新規データをDBへ挿入する場合に、管理画面からRequestをもらいBulk insertなどを用いて行い、管理画面に成功を返せば良いと思っていました。

しかし、メンターさんと相談すると、
「いきなり数万行もinsertしてしまえばSQLサーバーが高負荷な状態となる。この実装がその負荷を与えるほど優先度が高い処理か？」
という意見をいただきました。

そこで、取得したCSVからDBへinsertする処理自体を非同期またはバッチ処理で行い、10行 / second ずつ行う実装としました。
ミラティブでは、QPS（Query Per Second）という観点で、実装する際のルールがあります。これは、その実装でDBに1秒ごとにどれくらいのクエリを投げていいかというルールです。それに従った実装となります。

次に、同期処理・バッチ処理どちらで実装するかという決定をしました。
同期処理・バッチ処理の違いとして

同期処理：APIのリクエスト処理の中でDBへの処理まで実行し完結させる
バッチ処理：APIのリクエスト処理を受け付け、実際のDBへの処理を別の仕組み・タイミングに任せる

となります。

同期処理を用いて、管理画面にステータスを表示し、成功を返すというフローを僕は考えていました。しかし、その処理が失敗してしまった場合、管理画面からもう一度CSVを上げ直すという手間が生じてしまいます。

そこで、バッチ処理にすればinsert処理が途中で失敗した際にユーザーからもう一度アクションを取って貰う必要がなくなります。それは、失敗しても処理を行う別の仕組みがバッチの実行時間になればinsert処理が行われるからです。

UPDATE処理

次に、UPDATE処理についてです。
既存のデータに対する更新データをDBへ挿入する際に、重複するデータが複数あったとしても、更新データを再度DBへ挿入するのかという点が議論になりました。

例えば、DBに存在するデータAが30,000行のCSVで成り立っているとします。更新としてデータBという30,000行で成り立っており、後半2,000行のみ違うCSVデータを挿入した場合

30,000行の余計なデータが残る
重複したデータの管理

が課題と考えました。実際どちらを正として登録するのか問題でした。
そこで、以下の決定を行いました

データレコードごとにバージョニングする
削除はバッチ処理に任せる

DBにとって削除というのはかなりコストが掛かる実装であり、削除してから更新データを挿入するといったアプローチは不適切と判断し、DBのテーブル設計にversionというカラムを追加し、更新データを新しいバージョンとしてインクリメントした値を付与しつつinsertを行います。

そして、管理画面への出力・DLにおいては最新バージョンのデータのみ出力することで解決しました。

働く環境・イベントについて

インターン期間中はただタスクを振られて取り組むのではなく、社内のイベントや会議に参加させていただく機会が多かったです。

ウェルカムランチ
定例会（朝会）
レトロスペクティブ会
プレミアムエモいデー（社内の売上などを報告する全社集会）
週次1on1

特に入社して2、3日ほどで配属先のエンジニアの方々とランチを食べるウェルカムランチはすごく良かったです。
仕事の事以外でなんでも話し合うことで緊張もほどけましたし、その後のオンライン上でも話しやすかったです。

その他、チームの朝会やレトロスペクティブ会でチームがどんなタスクを進めているかや、どのように進めているかがわかるのでチームの雰囲気がわかりやすかったです。ここで自分のタスクについても話したりするのですが、かなりウェルカムな雰囲気で臆さず発表できました。

プレミアムエモいデーは、全社員が金曜日の夕方に集まって各部署がどんなことをしているか、そして全社でどんな方針を掲げているか再認識することができます。
インターン生に対しても、会社や人についてオープンな雰囲気がかなりありました。

1on1では週1回、メンターさんたちと「タスクの進捗がどうか？」「現在の取り組み方に心配がないか？」のみならず、現状での取り組み方に対するFBをいただくことができました。
ハッカソンや個人開発では得られない視点での助言や、自分がどう見えているかをたくさん教えてくださり、プロのエンジニアとして働くために必要な取り組み方について見えてくるようになりました。