こんにちは、横浜国立大学大学院の櫛引淳之介（@kusshi94）です。2023年12月中旬から2ヶ月間、株式会社MIXIのインターンシップ ”DIVE INTO MIXI 2023-2024” に参加してきました。取り組んだことと感想をまとめます。

参加までの経緯

直接のきっかけは、サポーターズの逆求人イベントでの接触です。元々MIXIに対してはインフラ関係でチャレンジングなことをしている会社というイメージがあり*1、自分の興味とマッチしたSRE枠でインターン選考に進みました。

応募したのは「Dive into MIXI 2023 夏季」というサマーインターンの募集枠だったのですが、他社インターンなどの都合で12月に入社が延びてしまいました。柔軟に対応してくださった人事と現場の皆様に感謝です。*2

配属部署と取り組んだタスク

配属部署は開発本部 CTO室 SREグループでした。SREグループは全社横断型の部署で、社内の様々なニーズに応えるため機動的に活動しているチームです。プロダクトのインフラ関連技術支援、一部システムの保守運用、全社課題の技術的解決などを幅広く担当しています。

私の取り組んだタスクも、全社横断で技術面から課題解決に取り組むものでした。具体的には、下記2つをアサインされました。

社内サーバのクラウド移行
メール送信システムのためのDMARCレポート監視システムの構築

とはいいつつも、この2つだけをやっていた訳ではなく、PRのレビューやタスクに関連するミーティング、全社での情報共有など、元々のスコープ外にも少しはみ出てお仕事させていただいていました。特に、後述するGmailの迷惑メール対策ガイドラインの強化については、どのように対応していくか相談しながら考えていくような形で進めさせていただきました。実際の運用を考えられるようになっていきたい気持ちがあるので、何よりありがたいことでした。全般的に、会社の一員として迎え入れていただいたという感覚が強く、タスク外のところからの学びも多いインターンでした。

DMARCレポート監視システムの構築

今回のインターンで取り組んだメインのタスクは、事業部の使用するメール送信システムで使用する、DMARCレポート監視システムの構築でした。

Gmailは2024年2月1日（インターン期間中！）を境に、迷惑メール対策に関するガイドラインを強化しました。具体的には、1日あたり5,000件以上のメールをGmailのアドレス宛に送信する送信者に対して、送信メールの認証などの対策が義務化されました。

MIXIには、ユーザ宛のメール配信機能をもつシステムがいくつも存在します。MIXIで運用しているID基盤システムの中のメール送信システムはその一つで、SREグループが実運用を担当していました。このシステムも1日あたり5,000件以上のメールを送信するため、新しいガイドラインに準拠するようメール認証に関する設定を行う必要がありました。

support.google.com

メール認証による迷惑メール対策の手順は、大まかに以下の4フェーズに分かれます。

SPFとDKIMを設定
DMARCレポートを受信できるよう、DNSにDMARCレコードを追加する
DMARCレポートを定期的に受け取り、設定ミスなどによる誤判定がないか監視をする
DMARC認証に失敗したメールを、受信拒否するようDMARCレコードを変更する

SREグループの運用するID基盤システムでは1番目が完了しており、インターン期間中にメンターさんと確認しながら2番目の設定を行いました。その後、3番目のDMARCレポートの定期的な受け取りのためのシステムの開発に取り組みました。このシステムは、ID基盤システムでのDMARCレポート監視用に動かし始め、他のメール配信システムでも利用することを想定するものです。

処理の流れを簡単に説明します。Gmailなどのメールサービスなどから送られてきたDMARCレポートはAmazon SESで受信され、S3に保存されます。S3にメールが保存されるとLambdaが起動し、前処理としてオブジェクトキーにメールを受診した日付の情報を付与します。これをEventBridge Schedulerによって定期的に実行するLambdaで解析し、Slackへの通知を行います。通知内容は、SPF/DKIM/DMARCの認証に失敗した件数です。シンプルな構成ですが、セキュリティ上の理由で処理対象のメールサービスプロバイダを絞り込んでいることもあり、入力データの量が大きく変動することなどもないと考えこのような形にしました。

実際には、図の前処理用Lambdaの実装と、EventBridge Schedulerの構築まではできず、半手動での動作確認を行った状態でインターン終了の日が来てしまいました。本番運用に乗るところまで見届けられなかったのは少し残念ですが、方針を考え変えていきながらの対応だったことも踏まえると、主処理をなんとか作り終えることができてよかったです。また、最終的に採用しなかったものも含めてこれまで経験のなかった他のAWSのサービスの利用を検討してみたりと、実際のユースケースを通じてよい質の高いインプットができました。

生活

参加期間自体は2ヶ月と長めでしたが、勤務日数はそれほど多くなく、数えたところ合計20営業日でした。背景には、学業との兼ね合いで週3勤務だったことに加え、年末年始を挟んだり、研究室の海外出張に参加していたりと、少し長めの休みが入ったことがあります。今思えばもう少し働きたかったところですが仕方ない。

オフィスが魅力的で、週1ペースで出社もしていました。渋谷駅直結の超好立地、安くて美味しい社食と社内カフェ、窓から見える景色、昇降デスクとアーロンチェアなど、快適に働ける環境が整っていました。特にビュッフェ形式の社食は気に入ってしまい、出社する度に食べすぎていました。

それから、社内のイベントには沢山参加させていただきました。イベントでお話させていただいた方は皆活躍されている方ばかりで、MIXIにはすごいエンジニアが大勢集まっていることを実感しました。

今日はクリスマス会兼 25エンジニア懇親会を開催中🎄
最後まで楽しんでいってくださいね🥳✨#25卒 #26卒 #エンジニア pic.twitter.com/FzmVS8qO5Q
— MIXI 新卒採用公式アカウント (@HR_mixi) 2023年12月21日

学んだこと

今回のインターン全体を通して、運用の難しさを学びました。特に、影響範囲の調査と、外的要因との向き合い方の難しさを垣間見ることができました。

例えば、インターネットの基盤となっているDNSやメールが、運用する側から見ると少々扱いづらい側面があることを設定しながら体感できました。特にDNSは名前空間と権限が対応する形で設計されているため、一つのドメインを色々なところで使おうとすると一般的と思われるユースケースでも管理のコストが大きくなります。少しずつ継ぎ足しで拡張されてきた仕組みにはつらいものがありますね。その意味で、今回のタスクと直接の関係はありませんが、IPv4とIPv6の互換性を切る判断をした先人たちの気持ちが分かってきました*3。

また、運用を楽にするためのIaCやCI/CDも、長い時間軸で見るとメンテナンスコストがかかるということを実例を見て学びました。運用は変化させずシンプルにしておければそれに越したことはありませんが、一方で、予測しづらい外的要因による変化もあり、やはり一筋縄ではいきませんね。

今後の課題

インプットにもっと時間を使っていきたいです。他社のものを含めると約半年間連続でインターンに参加していましたが、期間中は研究との両立のためにいつも時間に追われており、業務の中でインプットしたいことが出てきても勉強する時間を満足に取れないでいました。

今回DMARCレポート監視システムを開発するにあたり、自分の設計、開発力の不足を思い知りました。今は反省を受けて積んでいたDDDの本を読んでいますが、先に読んでおけばもっといい設計ができた気がしています。やはり、基本的なところは誰かに整理されているものですね。というわけで、当分は、ソフトウェア設計・開発の基本的なところをインプット中心に抑えていこうと思います。

以下に、具体的な反省点と、勉強したいことを残しておきます。

DMARCレポートの解析用Lambdaの実装では、テストを書くことを後回しにしたせいで、全てのテストを書ききれておらず、また、実際にコードをLambdaに乗せて動作確認するまで初歩的なミスに気づかないという場面がありました。これはテスト駆動開発をしていれば避けられたはずです。現在はテストをどう書いていけばよいのかというところから怪しいので、基本から勉強していきたいと思います。

加えて、これは責務の整理と表裏一体ですが、インターフェースの命名もあまり分かりやすいものになっていないという課題もあります。また、コードレビュー、ドキュメントライティング、ログ実装などについても、必ずしも明確な意思に基づいて行えてはいませんでした。これらの点については完全に我流でやっており、「守破離」の「守」から始める必要があると考えています。

今回知った運用の難しさも、ある程度は単純な力量で十分に解決できる側面があると思っています。今認識している伸びしろを逃さず、力をつけていこうと思います。