課題解決をシンプルに、エラーに探究心を : 短期就業型インターン

はじめに

はじめまして。2025年1月から2週間の内定承諾前の学生向け短期就業型インターンにソフトウェアエンジニアとして参加していました、26卒の村木乃乃香です。情報系の大学院に在学中で、研究室ではファジング(ソフトウェアのテスト手法の一つ)の研究をしています。

DeNAについて理解を深めるために、インターンに参加しました。

インターンでのタスク

大きく分けて以下の2つのタスクに取り組みました。

DeNA社内で利用されている動画プラットフォームであるMirucaのAI機能の改善
動作が不安定なDockerfileの調査

以下では、それぞれのタスクについて詳しく紹介します。

1. MirucaのAI機能の改善

MirucaとはDeNA社内向けの動画共有、視聴管理サービスです。DeNAのDrive内で共有された動画が自動で貯まっていて、チャンネル登録や閲覧した動画の履歴が見れたりと、Googleドライブ内の動画を一括管理できるサービスです。

MirucaのAI機能について

MirucaにはAI機能があり、動画のチャプターや、文字起こし、要約の生成を行なっています。 AI機能はチャンネルごとにオン/オフの設定ができます。今まではこのオン/オフの設定はMIRUCAの管理者がユーザーから申請を受けて手動で行なっていましたが、最終的にこの制限が不要になったという背景がありました。

今回のタスク: AI機能のオン/オフをユーザーが行えるようにする

そこで今回のタスクは、AI機能のオン/オフをユーザーが行えるようにするというものです。この変更により、管理者に依頼しなくても、チャンネルの編集ページからAI機能をオン/オフできるようになります。すでにオン/オフ切り替えのための管理者用のページがあったので、メインで考えるべきことはAI機能をオンにしたときのslack通知についてでした。

AI機能に付随するslack通知の設定

MIRUCAでは、AI機能をonにすると、動画のアップロード時に以下のようなフローが回ります。

要約の自動生成
アップロードされた動画に対して、AIが自動的に要約を生成します。
動画の投稿者へのSlack通知
要約の生成が完了すると、動画の投稿者へSlackのDM通知が送信されます。このDMには、生成された要約を編集できる専用ページへのリンクが含まれており、投稿者はこのリンクを通じて、生成された要約を確認、修正できます。これによりヒューマンインザループ(=AIが生成したものは人間が確認してから利用する)を確実に回すことができます。

今回の問題

通知に利用されているMIRUCAのslackアプリが主にエンジニア交流用として使われているワークスペースにインストールされていたことが課題でした。これにより、通知を送れる相手に制限があり、動画の投稿主がエンジニア交流用ワークスペースに入っていない場合にはDM通知をすることができませんでした。解決アイデアとしては以下の2点がありました。

既存のエンジニア交流用ワークスペースにインストールされているMIRUCAのslackアプリをそのまま利用する
この場合、AI機能をオンにしたユーザーにDMを送れなかった場合には、AI機能をオンにしない仕様とする。
通知専用のslackアプリを新しく作る
DeNA関係者全員が所属しているワークスペースにインストールし、DMを送れる相手に制限をかけないようにする。

実装がシンプルでAI機能を多くの動画に活かせるという観点から、2のアイデアを採用しました。新しいslackアプリをインストールする際には、社内IT部門に認可を受ける必要がありましたが、そこも問題なく進めることができました。

実際にデプロイ

デプロイまで行うことができました。デプロイの際に、goのバージョンを上げたことで少し詰まったので、デプロイの準備をもう少し早く行うべきだったと感じています。告知をチャンネルで行ったところ、たくさんスタンプがついて嬉しかったです。 alt text

2. 動作が不安定なDockerfileの調査

上記のMirucaのタスクが早めに終わったので、次のタスクとしてローカル環境でMirucaを動かす際に動作しなかったDockerfileの調査を行いました。(最初のタスクをやる際には、ワークアラウンドとしてdbをdockerではなくlocalでたてていました) このDockerfileは、社内でも動かすことができる人とできない人がおり、原因がとにかく分からない(M1とM2の違い?OSのバージョンの違い?など)状態でした。

私のMacの環境は以下でした。

Macbook Pro 2023
チップ Apple M2
メモリ 32GB
macOS Sequoia 15.2(もともと13のVenturaだったのですが、インターン初日にアップデートしていました)

とりあえず動くようになるまでと、根本の原因の調査に3~4日かかったので、解決までのフローを簡単にまとめたいと思います。

とりあえず動くようになるまで

具体的には、

The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

というエラーが出ていました。

大まかな原因の把握

上のerrorから、amd64アーキテクチャをエミュレートできていないということがわかったので、Dockerfileが問題というより、macOS上に構築していたコンテナランタイム(今回はcolimaを使用)が問題ということが分かります。

colimaは以下のコマンドで起動していました。

colima start --arch aarch64 --vm-type=vz --mount-type virtiofs --mount-inotify --vz-rosetta --cpu 4 --memory 8 --disk 100 --dns 8.8.8.8

--vz-rosettaというオプションで、AppleのRosetta2を使って、ARMベースの仮想マシン内でもx86アーキテクチャが動作するはずでした。ここで、詳細オプション付きでcolimaを起動してみると、実際に以下のerrorが出ており、rosetta2が起動できていないことがわかりました。

[hostagent] Unable to configure Rosetta: failed to create a new rosetta directory share caching option: unsupported build target macOS version for 14.0 (the binary was built with __MAC_OS_X_VERSION_MAX_ALLOWED=130300; needs recompilation)

似たissueを発見

このerrorでとりあえずググってみると、該当するissue が見つかりました。colimaが依存しているlimaをreleaseバージョンではなく、HEADから持ってくることで、とりあえず解決するとあったので、実際に試してみましたところ、確かに動くようになりました…。

このままだとググりエンジニアになってしまうので、結局何が原因だったのかを調べるために引き続き調査を行いました。

なぜ動くようになったのかの調査

HEADとreleaseの差異を見てみる

単純に考えると、HEADとreleaseバージョンの差異によりerrorが解消されたと考えられますが、これは以下の理由からすぐに却下しました。

issueの時のHEADバージョンより、現在のreleaseバージョンの方が新しいこと
実際にHEADとreleaseのdiffを見てみたが、rosetta2に関わるものはなかったこと

errorを出しているところのコードを追う

次に、出ていたerrorであるunsupported build target macOS version for 14.0 (the binary was built with __MAC_OS_X_VERSION_MAX_ALLOWED=130300; needs recompilation)をlimaのコードを見て追ってみることにしました。

実際に追ってみると、limaがimportしているパッケージである vzのコードでerrorが出ていることが分かりました。

このerrorは簡単にまとめると、OS14以上でしか動かない機能をOS13用のSDKで動かしているために起きているerrorでした。

原因の究明1: HEADをinstallしてうまくいったのはなぜか？

ではなぜ、HEADをinstallした時に同様のerrorが出なかったのかについでです。ここでhomebrewからlimaをinstallするときの挙動について、HEADとreleaseを取ってきている時の違いをまとめたいと思います。

releaseをinstallする場合: 現在のOSに応じたすでにビルド済みのバイナリを落としてくる HEADをinstallする場合: コードを持ってきて手元でbuildする

このことを考慮すると、HEADをinstallした時に、私のOS15用のSDKでbuildしたために、上記errorが解消されたと考えられます。つまり、HEADとreleaseバージョンの差異ではなく、手元でbuildしたかすでにbuildしたバイナリを持ってきていたかの差異だったということです。

原因の究明2: 何が起こっていたのか？

ここまでをまとめるとlimaのOS13用のバイナリが、OS14以上でしか動かない機能を含んでいたことがerrorの原因だったことが分かりました。しかし詰まったのがなぜOS13用のバイナリが入っていたのかということです。ここで、自分がインターンが始まった時に、別の問題の関係でOSのバージョンを13から15にアップデートしていたことを思い出しました。つまり、errorが起きるまでの流れをまとめると以下のような仮説が立てられます。

インターン初日: OS13でcolimaをbrewからinstall。この時は13のventura用のビルド済みのlimaがbrewからinstallされていて、バグが含まれている。
↓
別の問題の関係で、OSを15にアップデート
↓
まだ13用のバグっているバイナリが残っている。colima startしたときに、the binary was built with __MAC_OS_X_VERSION_MAX_ALLOWED=130300; needs recompilationのerror発生。

以上の仮説を立てて、blobから13用のバイナリを取ってきて動作させると再び同様のerrorが起きるようになったので、この仮説はほぼほぼ正しかったと推定されました。

lima側の対応

lima側は、リリースバージョンをmac OS15でbuildするように変更することで対応していました。( 該当PR ) つまりlimaが出しているリリースバージョンはOS13でも正しく動くはずです。

しかしhomebrew側で各OSに対応するbottleを作る際に、おそらくventura用のbottleは、OS13のSDKでbuildされてしまい、このようなエラーが発生したと考えられます。

まとめと感想

結局は、OSを15にアップデートしたあとの、ventura用のバグが含まれているlimaが原因だったわけですが、そこに至るまでにかなり回り道をしました。回り道をした要因の一つは、該当issueにあった解決策をそのまま適用してうまくいってしまったことでした。そのissueの解決策が本質的でなかった(=手元のOS15でbuildしたからerrorが出なくなっただけ)ことで、余計なことを調べる時間も多く、結果的に3~4日かかる原因になったと思います。errorを出しているところのコードをもっと早く調べるべきでした。

その他、会社の環境について

メンターの方について

インターンシップに参加する前はDeNAに対して、割と個人プレーのようなイメージを抱いていたのですが、参加してみると困ったときにはいつでも相談に乗っていただける環境だということが分かりました。初日にメンターの方に、15分困ったら相談してね、と言っていただいたので、進捗状況を見えるdocumentを共有しておき、また困ったときは自分一人で悩まずすぐ相談することを意識していました。時には、2~3時間一緒にああでもないこうでもないと話しながら調査したこともあったのですが、全く嫌な顔をすることなく、相談に乗っていただけたことが大変ありがたかったです。

働く環境について

環境はとにかく快適でした。研究と並行しながら行う必要がありましたが、時間や働く場所はかなり融通をきかせてくださいました。これはインターン生だからではなく、正社員の方も同様の印象を受けました。またインターン中には美味しいランチにも連れて行っていただきました。しゃぶしゃぶを食べました。いつでもコーヒーや紅茶が飲めるのもありがたく、特に45階のコーヒーがとても美味しかったです。