皆さんこんにちは、earlgray(@earlgray329) と申します。
10月17日〜12月19日の期間で、株式会社ミラティブの就業型インターンシップに参加していました。私は基盤開発技術部のバックエンドチームに所属して様々なタスクに携わらせて頂きました。
インターンシップの中で、普段行なっている趣味開発と Mirrativ という規模の大きいアプリケーションの開発の間で様々なギャップを経験することができたので、今回はインターンの中で着手したタスクとそれによって得られた知見等を紹介します。
目次
基盤開発技術部とは
バックエンドチームという言葉で一括りにすると「新規 API の設計・開発」が思い浮かびそうですが、ミラティブの場合、バックエンドエンジニアは「プロダクト開発技術部」と「基盤開発技術部」のどちらかに所属することとなります。
プロダクト開発技術部では、主にユーザーさんが直接触れるような機能をプロダクトマネージャ主導のもと、デザイナとアプリケーションエンジニアが一緒になって新規設計・開発を行なっています。 それに対し、基盤開発技術部ではシステム全体の安定性やコスト最適化・エンジニア全体の生産性向上などを目的として、エンジニア主体で運用されています。少しイメージがつきにくいですが、例としては以下のタスクを進行しています。
- インフラコストの改善
- 過去に Perl で実装された API などの Go へのリプレイス
- CI の整備
- リリースフローの改善
- などなど
Mirrativ のバックエンドを Perl から Go に移行した話は、クリーンアーキテクチャを採用した話と共に夏さんの記事にて細かく記述されていますので、気になる方は是非ご覧ください。 https://tech.mirrativ.stream/entry/2020/11/30/142354
着手したタスク
1. Mirrativ 管理画面のログイン画面の SPA(React) 化
インターン join 後の初タスクでした。
背景・概要
Mirrativ 管理画面のそれぞれのページは元々 MPA で実装されていました。最近になって SPA 化が行われましたが、ログイン画面が未着手であったために、ログインの際はリクエスト先のホストを SPA のポートから MPA のポートに変えなければならないという問題が発生していました。
これを解決するため、Mirrativ のバックエンドのキャッチアップを含めてログイン画面の SPA 化を進めました。
苦労したこと・得られたこと
1. QA 環境での動作確認
タスク自体はそれほど難しいものではなかったのですぐにこなすことができましたが、ミラティブでは動作確認をする際に複数の環境を使用するため、これに慣れるのに時間を要しました。
Mirrativ の開発では主に「ローカル環境(Mac)」、「QA 環境」の2つの環境を使用し、それぞれ以下のような作業を行います。
1. ローカル環境 ... docker compose で複数サービス(Go による Web プロセス、MySQL、Elasticsearch、etc.)が立ち上げられる
2. QA 環境 ... 本番環境と似たインフラ構成でデプロイされる
私は趣味開発の時は基本的にローカル環境で開発は進め、本番環境で差異が生じた場合は 本番環境で動作確認を行なっていました。そのため、今回のように一度 QA 環境を挟んだ開発はとても新鮮であり、少し規模が大きい開発では趣味開発でも QA 環境を使って動作確認をすることが重要だということに気がつくことができました。
とはいえ、初めの頃はデプロイされるタイミングを間違えていたり、ローカル環境と QA 環境のインフラの違いを考慮できていなかったりしたため、慣れるという点で少し苦労したのは確かでした。
2. フロントエンドとバックエンドのデプロイタイミングが異なる点の考慮
Mirrativ の開発では、フロントエンドとバックエンドのデプロイタイミングが異なります。更に、バックエンドについても当然複数台で動作しており、これらは順次に更新されていきます。そのため、デプロイは以下のような工程を踏んで行う必要があります。
- 最初に追加差分のみをデプロイする
- フロントエンドの反映が終わったタイミングで削除差分をデプロイする
- 全てのデプロイが完了！
趣味開発レベルであればそれほどフロントエンドとバックエンドのデプロイタイミングの差異を気にする必要はなかったため、ユーザ体験を最大化するためのこのような仕組みの理解やそれに応じた修正には少し時間を要しました。
2. 任意のユーザとしてログインできるようなデバッグ機能の追加
背景・概要
QA チームからバグの報告があった際、基本的には担当エンジニアがアプリ上でそのバグを再現できるようにあれこれすることになります。しかし、そのバグの再現手順が複雑であったり100%の頻度で再現ができなかったりする場合、そのバグが OS 固有(iOS / Android)のものなのか、バックエンド側のものなのかを判断するのは困難です。
これを解決するため、バグが発生したユーザとしてログインすることができるようなデバッグ機能を実装しました。これにより、詳細がなくてもそのユーザとしてログインして再現をすぐに行うことができるようになり、iOS、バックエンドのどちら側のバグなのかの判断も容易となります。
デバッグ機能の利用方法ですが、バックエンド側のみの修正で対応できるよう、/user {user_id} のような形式でユーザ検索を行うと指定した user_id のユーザとしてログインできるような仕様としました。(もちろん本番環境で利用することはできません)
フィードバック
デバッグ機能はエンジニア向けの機能となっているのですぐにフィードバックを頂くことができました。
このように作った機能に対して slack の times チャンネルなどで感想を頂けるのもミラティブの良いところだと感じましたし、単純に嬉しくて開発のモチベーションアップにもなりました！
3. エモカラのオススメのアーティスト一覧と似ているアーティスト一覧を返す API の Go 移植
設計は含みませんが、初のユーザーさんが直接利用する機能の API 開発タスクとなりました。少し大きめのタスクだったので楽しかったですが、一番苦労しました。
背景・概要
エモカラのオススメのアーティスト一覧と似ているアーティスト一覧はそれぞれ以下のように表示されます。
これらの API は以下のような問題がありました。
- Perl で実装されている
- 楽曲を1曲も持たないアーティストも一覧に表示されてしまう
- エモカラの楽曲は定期的に削除・追加されていきますが、その中で楽曲を1曲も持たないアーティストが発生してしまうという問題がありました。
そのため、今回のタスクでは主には Perl から Go への移植を行い、またサブタスクとして楽曲を1曲も持たないアーティストを除くように修正を行いました。それぞれについてやったことを簡単に紹介します。
1. Perl から Go への移植
Perl という言語は聞いたことぐらいしかなかったため最初は不安でしたが、今回の API は比較的シンプルであったため、 Perl の経験がない私でも難なく読み進めて移植を進めていくことができました。
2. 楽曲を1曲も持たないアーティストを除くように修正
これは単純にエモカラアーティストのテーブルから該当するアーティストの行を削除することで実現が可能です。あとは論理削除をするか物理削除をするかの問題ですが、他のテーブルから外部キー経由で利用されていたり、今楽曲がないアーティストも今後楽曲が追加される可能性があるため、論理削除で実装を進めることとしました。
苦労したこと・得られたこと
1. 新たに追加した全ての SQL について EXPLAIN を実行し、パフォーマンスの調査
趣味開発で DB を使用して SQL を書くことは何度もありましたが、EXPLAIN という言葉を聞いたのは今回が初めてでした。つまり、これまで私は雰囲気で DB を使用しており、パフォーマンスについて考えたことは一切ありませんでした。そのため、今回全ての SQL について EXPLAIN でパフォーマンスを調査することはとても新鮮な体験でした。
ところで、EXPLAIN についてあまり馴染みがない方もいると思うので簡単に説明をします。ある SQL について EXPLAIN を実行することにより、その SQL がどのようにして実行されるかを知ることができます。具体的に知ることができる項目としては以下のものが挙げられます。
- フルテーブルスキャンが行われているかどうか
- その SQL を実行する際にどの index が候補として挙げられるかどうか
- index が利用されず filesort や temporary が extra 項目に出てしまっていないかどうか
- スキャンされるレコードの数が適切かどうか
EXPLAIN で全ての SQL のパフォーマンスを調査すること自体は何も難しくありませんが、それを修正することが少し大変でした。「2. SQL のパフォーマンスを改善すること」に続きます。
2. SQL のパフォーマンスの改善
EXPLAIN でパフォーマンスの調査をし、結果としてフルテーブルスキャンが行われていたりした場合は当然ながら修正が必要となります。ここで、修正の方法としてほとんどの場合は index を新たに追加することが挙げられると思います。私自身も最初はその方針で進めていましたが、ここで趣味開発と大規模開発との違いが発生します。それは「安易に index を追加できない」という点です。
Mirrativ は2015年頃からサービスを継続して運用されており、またユーザ規模も一定以上あるため、過去に作成されたテーブルがいかに大きいかは察しが付くと思います。例えば、今回対象とするテーブルの行数はなんと1億行にも上ります。
このように非常に大きいテーブルとなっているため、テーブルに対して特定の SQL のパフォーマンスを改善するだけの index を新たに張ったりカラムの型を修正したりする alter は、実行中の DML 操作のブロックやテーブルコピーが発生するため困難です。どうしてもそれらの操作を行いたい場面も当然あるとは思いますが、今回は「楽曲を1曲も持たないアーティストを除くようにする」というだけであるため、本番の DB を止めてまで行うべき操作とはあまり言えません。よって、今回の場合は愚直に「楽曲を1曲も持たないアーティストを除くような SQL」を書くのではなく、ある程度融通を効かせて修正を行う必要がありそうです。
結果としては、今回の場合は若干の API の仕様変更を行うことにより、既存の index を使用する形にしてパフォーマンスの改善を行いました。このように、仕様変更を行うことによって既存の index の活用ができるようになる場合もあるため、大規模開発では ALTER INDEX にかかるコストと API の仕様変更の影響を天秤にかけてコスパ良く対応する能力が問われるということ学ぶことができました。
インターンを通して
インターンを通して得られたミラティブの印象を ミラティブの行動指針 と関連付けながら紹介します。
1. 経験年数やポジション(インターン、正社員)等関係なく、誰でも議論に参加することができる(=わかりあおうとし続ける)
私が出した PR のレビューは基本的にメンターの夏さんにして頂いてました。私はレビューの中で頂いた指摘に対して「なぜ？」や「〜というつもりでやったけどこれはダメなのか？」のような反応をすることが何度かありましたが、それぞれの疑問に対して夏さんは丁寧に解説してくださり、また気づきの機会を設けてもらいました。
私がインターン生でしたが、丁寧な対応をして頂いたため、ミラティブの行動指針の1つである「わかりあおうとし続ける」は全体に浸透しているというように感じました。エンジニアの場合は、Mirrativ の開発に関わる以上は誰もが対等である環境だと感じています。
しかし、これは同時に「インターン生だから」、「まだ始めたてだから」、というような言い訳は通用せず、開発の責任や成果等も問われます。そのため、ミラティブにエンジニアとして join するのであれば、これらの意識も必要だと感じています。
2. すご飯会を通してエンジニア同士の仲を深められる(=そして楽しみ続ける)
ミラティブは「わかりあう願いをつなごう」というミッションのもとで全社員が常に課題に向き合っています。しかし、課題に向き合うというのはとても大変なことであり、これだけを続けているといずれ疲弊してしまいます。
これを防ぎ、業務とは別の場でエンジニア同士の仲を深めて課題に向き合い続けるため、ミラティブでは複数のチームビルディングのための福利厚生が設けられています。すご飯会 は数ある福利厚生の中の1つです。詳細を知りたい方はインターンに参加してみると良いと思いますが、このすご飯会という制度を使うことによって美味しいご飯をエンジニア同士で食べに行くことが可能となります。
私は11月にこの制度を利用した食事会に参加させて頂き、そこで多くのエンジニアの方や他のインターン生の方と話す機会を頂きました。ミラティブではリモートワークが中心であるため、このようにエンジニア同士の交流の機会を設けているのはとても良いなと感じました。
ちなみに、すご飯会では RIO GRANDE GRILL というお店に行き、本格的なシュラスコを体験しました。以下の画像はその時の様子です。
感想
2ヶ月という短い期間ではありましたが、上記のように趣味開発と大規模開発のギャップをあらゆる面で体験することができ、技術面で非常に満足のいくインターンシップとなりました。また、ミラティブの行動指針である「わかりあおうとし続ける」、「課題に向き合い続ける」、「期待を超え続ける」、「そして楽しみ続ける」を肌で感じてミラティブという企業への理解を深められたという点でも、とても有意義なインターンシップであったと思います。
最後になりましたが、数々の「なぜ？」、「どうして？」という質問に対して常に丁寧な回答をくださったメンターの夏さん、すご飯会にて雑談から就活まで様々な相談に乗ってくださったバックエンドチームの方々、ミラティブの皆様、二ヶ月間本当にありがとうございました。
We are hiring!
ミラティブでは新卒およびインターンを募集しています！
興味を持った方は、是非エントリーお待ちしています。
Mirrativ Engineering - ミラティブのエンジニア情報を伝えるポータルサイト -
