記事概要＆本記事で述べたいこと
この記事は，DeNAの【短期】ソフトウェアエンジニアリングコースのインターンシップの体験記について記述したものです。DeNA社員ではなく、学生である私（高根沢）がインターンシップ期間前に，チームメンバーとやっていた事前準備と，本番前後の心境について述べていきたいと思います！また，私の担当はインフラ分野だったので，インフラメインで話していきたいと思います！
インターンシップの概要
本インターンシップは，開発が中途半端になっていたチャットサービス（大規模を想定せず）を数日後にリリースしなければならず，２日間という短い期間で大規模の利用者数が想定されるアプリになるよう改修するという内容になっています。また，大規模の利用者数の想定としては，「10000rpsに耐えられるサービスを作ってください！」という要件でした。
インターンシップの感想
私がインターンシップで経験した経験・学びは以下になります！
- （経験）事前準備が万全だったがために，本番で想定外の対応がいくつも発生した。
- （学び）解決しなきゃいけない課題の優先順位付けの重要さについて
- （学び）自分だけの開発スピードだけでなく，チーム全体を見る必要性がある。
- （学び）バックエンド/インフラエンジニアもサービスに寄り添った開発を心がけること！
それでは各項目について述べていきたいと思います！
1.（経験）事前準備が万全だったために，本番で想定外の対応がいくつも発生した。
事前準備について
本インターンの2週間ほど前に，チーム発表があり，その時点でチームビルディングが行われます。私たちはチームAで，担当としてはバックエンド２名，フロントエンド２名の計４人のチームで活動することになりました。
チームビルディング後，メンバーで事前準備でやることを話し合った結果，アイスブレイクも踏まえてサンプルのWebサービスをチームメンバー全員で作ることにしました。技術スタックとしては，フロントエンドVue.js，バックエンドGo，インフラAWSで作りました。私の担当はインフラだったため，事前準備で以下のようなインフラを実装しました。バックエンド・フロントともに本番の３日前までには動くものを作り，インフラもGitHub Actionsを用いたCI/CDを実現し，自動テスト後にAWS ECSへのデプロイも行えるように実装し，事前準備としてはかなり満足度の高いプロトタイプを作ることができたと考えています。
本番環境における環境のギャップ
インターン本番を迎えると，AWS環境にはあえて以下の制限が加えられていることがわかりました。
- EC2インスタンスは１０台まで
- ECS・ECR・RDSの利用不可
- IAMの作成，変更不可
これは完全に想定外でした。私としては，事前準備で実装したかった環境が実現できていたので，後は実装するだけと思っていたのですが，上記制限より，ECS(EKS)・ECR・ElasticSearch・Github Actionsを活用したインフラ構成や，CI/CDが実現することが難しいことがわかり，当日にピボットを行うことになりました。
ピボットした内容としては，EC2インスタンス１０台を有効活用して，高負荷に耐えられるインフラ環境を構築することを目指しました。
（画像：提案後のインフラ，EC2の10台インスタンスをWeb5台，DB5台構成で動かしている。Web->DBにはELBで負荷分散している。）
サービスの負荷試験について
まず，初期構成のサービスがどれくらいの負荷に耐えられるのか，Loader.ioで実測のrps(Request Per Second)を計測すると，16rpsしかなく，目標の10000rpsには程遠いことがわかりました。その問題に対する初期分析としては，以下の項目が挙げられました。
- 初期構成ではEC2インスタンス1台でWebServer(Go)，DB(MySQL)が動いており，スケールアウトできない＆どこがボトルネックになっているのか測定しづらい
- 画像がDBに格納されており，400GB超のデータがDBに格納されていて，ボトルネックになっている点
- 上記理由により，データベースを分離するうえで移動コストが掛かる問題を解決しなければならない点
上記問題を解決するべく，まずは現在の構成であるWebServer＆DBの構成を変更したうえで，WebServerをDBを複数台構成に対応，その次にDBをレプリケーション構成にし，最後に負荷テストを行い10000rpsへ向けたチューニングを行うことにしました。
EC2インスタンスでDBのレプリケーション構成を行ううえでの想定外
EC2インスタンス上でレプリケーションを組むため，EC2インスタンス6台をDBレプリケーション構成にして動かしていました。その際に，レプリケーションの設定をマルチマスター構成(いずれかのDBに変更を加えたら，他のDBに変更が走る，全MASTER兼SLAVE構成のレプリケーション）で動かしていました。
実装してから半日は負荷テストやその他APIテストもパスしており問題無かったように思えたものの，最終発表の１時間くらい前に，レプリケーション遅延でフロントのチャット更新表示の部分に不具合が発生するという状況にぶつかりました。
私の初期対応としては，インフラ側で対応しようと思い，DB構成を最小にして対応しました。また，最終発表の１時間前ということもあり，EC2インスタンス１０台をフルに使ってチューニングしていたため，構成の巻き戻しの作業も非常に苦労しました。（発表までにはギリギリインフラ側でフロントの同期更新のバグを解消し，デモを行うことができました）
こうして，不測の事態にも対応できたものの，もうちょっとインフラ面をしっかり作って行きたかったという課題が残るインターンになりました。
（DB用EC2インスタンスで動かしていたレプリケーションのマルチマスター構成。いずれかのDBに負荷分散し，いずれかのDBで変更があると他のDBに伝播する設定）
2.（学び）解決しなきゃいけない課題の優先順位付けの重要さについて
学びの１つ目として，今回のインターンでは，限られた時間で何をチーム内で大事にし，ゴールへ向けてやっていくのかというのが最重要項目でした。時間さえ掛ければ，誰もが自分がやりたい理想のシステム構成が実現できると思います。しかし今回は２日間（課題発表から最終発表までの期間で言うと，ほぼ１日しかありません）の期間内で完成させることがMUSTであり，やりたいことも絞る必要がありました。
そんな中で，メンターさんからも色々アドバイスを受けながら，チーム内で大事だなと思ったマインドとしては，「各担当領域において，これだけは実現したい項目を実現しよう」という共通項を用意したことでした。バックエンド・インフラ・フロントでそれぞれ解決しなければならない分野・項目は別であるものの，「最初に掲げた目標は，最小限でも良いから達成できるようにしよう」と決めたことで，途中で方向性がブレること無く，やりきることができたと考えています。
私もインフラとして高負荷に耐えられるインフラを実現することを最も重要視する項目として挙げ，最大で8651rpsに耐えられるインフラを実現することができました。
（画像：作ったインフラが8651rpsに耐えられている様子。チャット取得APIで処理できたリクエストが15秒間に129766リクエスト=8651rps)
3.（学び）自分だけの開発スピードだけでなく，チーム全体を見る必要性がある。
学びの２つ目として，サービスをゴールまでに完成度高く持っていくためには，「チーム全体の開発スピードを俯瞰して見れるようにする」というのも重要な項目であると感じていました。私たちのチームでは，それぞれメンバーで担当を分け，一人ひとりが課題を見つけ，解決へ向けて達成したい目標を決め，動いているという形でした。そのため，結果としてはみんながやりたいことやれた。という形にはなりましたが，サービスの完成度を高めていく上では，それぞれ活動していた内容を定期的にまとめることをより積極的に行うべきだなと感じました。
4.（学び）バックエンド/インフラエンジニアもサービスに寄り添った開発を心がける。
学びの３つ目として，自分の担当領域に関わらず，サービスに必要な技術を横断的に見れるエンジニア・連携が必要だったということです。私たちのチームでは，バックエンド・インフラとフロントで分離して開発していたため，バックエンド・インフラチームがフロントに触れる機会があまりなく，各々の課題をとにかく解決するために活動していました。そのため，不具合の発見等が遅れ，発表時間前までバグ対応に追われていた記憶があります。そのため，フロント担当＝サービスの見た目に関わるから，フロントにUI/UX面を任せっきりになるのではなく，インフラ・バックエンドも一般利用者として，フロントを使い，「こうしたほうがいいんじゃないか」，「この機能はそもそも今回の要件に必要だっけ？」といった議論をよりしていけたら，より良いアウトプットが生み出せたという反省点がありました。
おわりに
今回のインターンは，エンジニアが会社で関わるとされるあらゆる場面を経験することができ，また開発開始～終了まで何が起こるのかわかりません。そのため，「順調」という言葉はなく，いかに臨機応変に対応していくかがキーポイントになります。このインターンでは，実装力（実装の速さ，正確さ）・エンジニア知識の広さ・チーム内のコミュニケーション等々のいろいろな能力が試されます。エンジニアとして自分に足りない部分はどこなのか，力試しにはもってこいだと思います。ぜひ参加してみてください！
この記事を読んで「面白かった」「学びがあった」と思っていただけた方、よろしければ Twitter や facebook、はてなブックマークにてコメントをお願いします！
また DeNA 公式 Twitter アカウント @DeNAxTech では、 Blog記事だけでなく色々な勉強会での登壇資料も発信してます。ぜひフォローして下さい！
最後まで読んでいただき、ありがとうございます！
この記事をシェアしていただける方はこちらからお願いします。