9/1〜9/28で、株式会社MIXIでインターンシップに参加しました?♀️
その振り返りブログです。
きっかけ
サポーターズの逆求人イベントがきっかけです。
丸1日かけて、様々な企業のエンジニアや人事の担当の人と1対1（本当に1対1、なんなら自分1人に対して複数人で参加してくださる企業様も）で話せて、自分のこれまでの経験について話したりして、濃密な時間を過ごせます。
（サポーターズの回し者ではありません）
そこでMIXIの人事の方とお話しした後、オファーをいただき、参加することにしました。
選考
↑のオファーとして、書類選考が免除になって、いきなり面接でした。
（便宜上、というかその後の面接でも使われる情報なので、ESはちゃんと出します）
人事の方と1回、現場のエンジニアと1回、合計2回の面接でした。
緊張でガチガチだったので、覚えていない部分も多いのですが、「インターンでどんなことを学びたいか」だったり、これまでの経験みたいなものを話した記憶はあります。
部署選び
SNSのmixiは「知ってはいるけど使ってなかった」という世代ですし、モンストも遊んでないので、MIXIって結局何してるんだろう・・・？という感じで、インターンを希望する部署もなかなか決めかねていたのですが、人事の方と一緒にすり合わせた結果「家族アルバム みてね」のSREチームへ配属となりました。
（現場エンジニアとの面接の前に、部署が決まりました）
子どもってかわいいですよね、写真を撮るのも好きなので、実は近からずも遠からずという存在でした。
入社
オフィス
MIXIのオフィスは渋谷スクランブルスクエア(長いので以下「スクスク」)にあります。
別でアルバイトしている会社のオフィスもスクスクなので、アクセス自体は「1つ隣のゲートから入る、新鮮〜」くらいの感触です。
スクスクは渋谷で1番高いビルなので、とても見晴らしがよく、天気がいいと富士山とか筑波山が見えます。(スクスクの回し者ではないですが、渋谷SKYも綺麗ですよ！)
MIXIのオフィスは全体的に黒や茶色のような色が多く、シックというか落ち着いた雰囲気でした。
他のインターン生でも、在宅勤務をしている人は多かったのですが、自分は自宅ではメリハリがつかなくて、長時間作業ができないので、毎日出社していました。
気分に合わせて窓際のフリースペースで作業したり、フリードリンクもあるので、作業環境的にはとても良かったです。
昇降デスクってどうなの？とずっと思っていたのですが、ずっと座って疲れたなーと思ったときに立って仕事すると、いい感じに集中できてよかったです。
初日
インターンとはいえ有給のインターンなので、普通にアルバイトとしての入社です?
初日はPCセットアップや入社手続き、eラーニングの受講などで1日を終えました。
インターンの部署について
「みてね」のインフラ
みてねでは、EKS上でサービスを運用しており、ユーザーがアップロードした画像や動画はS3に保存されています。
（日々の子どもの写真や動画が上がっていくので、とにかくストレージのコストがとても高いのが特徴です。詳しくは↓のスライドもご覧ください）
EKS上のKubernetesリソースはArgoCDで管理されており、その他の(EKSクラスタ自体を含む)AWSリソースなどはTerraformで管理されています。
この辺りのGitOpsやIaCを触れるのは初めてですし、大規模なAWS環境に関わること、なんなら(これまでGCP一辺倒だったため)AWS自体触れるのがほぼ初めてレベルだったので、とにかく情報量に圧倒されました。
インターンで取り組んだこと
自分で言うのもアレですが、「小さく、たくさん成果を出す」インターンになったと思います。
ここではその一部をご紹介します。
GitHubのTerraform化
先述の通り、みてねのAWSリソースなどはTerraformで管理されています。
これと同じように、GitHubのTeamへのinviteや、TeamとRepositoryの紐付け(権限など)もTerraform化しよう！というミッションでした。
「iOS開発者の人だから、このTeamとこのTeamに追加して・・・」などを手作業でやるのは一苦労ですし、間違って作業してしまう可能性もあります。(その時のロールバックも骨が折れます)
まさしくToilだなと思いました。
Terraform RegistryにGitHub公式のTerraform Providerが公開されています。
GitHubのPersonal Access Tokenや、GitHub Appの形でGitHubのAPIを叩くことで、GitHub上の様々なリソースを管理することができます。
既にあるリソースをTerraform管理下に置きたい場合は、以下のようなコマンドでimportをします。
$ terraform import github_team.iOS iOSこれで、stateファイルにTeamの情報が書き込まれるため、terraform state show github_team.iOSみたいな形で書き出します。
最後に、参照にできる項目は参照に置換して終了です。
これら全て手作業で行うのは大変ですし、ミスの原因にもなるので、shell scriptを書いて半自動化しました。
(具体的なコードは伏せますが)こんな感じのフローでGitHub上のTeamやTeamMember、TeamRepositoryをTerraform化します。
- GitHub Teamのリストから、チーム名とslugを取得する
nameだけではTerraformの命名規則に違反してしまうことがあるため、slugを使ってTerraformのリソース名を命名したいという背景があります。
- チーム名を使って、定義だけを一時的に使うtfファイルに書き込む
- この後のimportで怒られるため、リソースを定義するだけします。
- Teamのimportを行う
- TeamMemberとTeamRepositoryを取得して、それぞれ同じようにimportする
- importの結果出来上がったstateを、
terraform showで書き出して、tfファイルに保存する - tfファイルを整形する(ここだけ手作業、VSCodeの置換機能を駆使しました)
team_idなど、全てハードコードされているので、参照に置換できるところは置換する- Attributes Referenceの値も書き出されているので、削除する
ここまでできたら、terraform planで差分が出てこないことを確認して、GitHubにpushします。
なお、これだけだと単純にリソースをベタ書きしているだけであり、(特にみてねのような規模の大きいチームでは)保守性が良くないため、for_eachなどを適切に使い、リファクタする必要があります。
GitHubのAPIを叩くのにGraphQLを初めて使いました。
一気に色々な値を、必要なだけ取り出せるというのはとてもメリットに感じました。
New Relicを使ったオブザーバビリティの向上
Kubernetes上の様々なメトリクスを、みてねではGrafanaやNew Relicといったツールで監視しています。(もちろん、監視対象はKubernetes内に限りません。AuroraやALBのような、Kubernetes外部のリソースも含めて、システム全体を監視しています。)
実際にNew Relic Integration(以下長いので「NRI」)をクラスタにインストールしてみました。
・・・と言っても、今思えばやっていることは単純で、各NodeにNRIが配置されるようDaemonSetを作成するだけです。
AgentはNodeにいるkubeletと連携して、クラスタのメトリクスをNew Relicに飛ばしてくれます。
インターンでは既にあるNRIを対象のクラスタにも配置するようにHelm Chartを変えたのですが、おそらく普通にHelm Chartをインストールするだけで完成してしまうと思います。
NRIのRepositoryは↓こちら↓
実際動かしてみると、HealthyなPodの数や、NodeのCPU使用率など、リソースの状況が一目で分かる超いい感じのDashboardが生えてきました。
これはおうちクラスタに欲しい。
New Relicは個人から見ると目玉が飛び出るくらい高いのですが、学生なら結構ガッツリな無料枠が使えるので、遊べるかなりいい勉強になると思います。
(New Relicの回し者ではありません)
インターンを振り返って
ここで紹介したものはタスクの一部で、1ヶ月の間に色々なことに挑戦することができました。
Grafanaによる日々の監視もそうですが、日々のメトリクスの中の小さな変化に対して「なんでこんなにエラーが出てるんだろう？」とか「この時間すごいCPU使用率上がってる」みたいな形で気づくことで、障害を未然に防ぐというところに感服しました。
様々なツールを駆使して、まさに「縁の下からサービスを支える」ことを体感することができ、インフラエンジニアとして成長していくモチベーションにもなりました。
SREって結局なんや？
インターンでSREというロールを実際に経験するまで、正直なところSREというロールをあまりよく知らず、「何をやっているんだろう」と思っていました。
インターンを振り返ってみると、「サービスの信頼性を高めるためであれば【何でもやる】」というのが所感でした。
もちろん、プロダクトのコードにガッツリ入るわけではないのですが、プロダクトで「どんなコードが動いているのか」や、「どういうデータを」「どのように」扱っているかという、インフラに限らない幅広い知識を使って、他のエンジニアと連携しているところがとても印象的でした。
また、社内の開発者に使ってもらうための開発環境やsandbox環境など、サービス自体を支えるだけでなく、「サービスを支えるエンジニア」を支えているという一面も知ることができました。
最後に感想
「2週間はあっという間だったけど、さすがに1ヶ月は結構長く感じるやろ」と思っていたら、1ヶ月もあっという間でした。
技術的なサポートだけでなくランチなどでご一緒させていただいたチームの皆様、インターン参加までの様々なところで相談に乗っていただいた人事の方、本当にありがとうございました！
