技術面接で「ユーザー数が10倍になったら」と聞かれたらどうする？【IT就活一問一答】

Q.技術面接で「仮にユーザー数が10倍になったらどこがボトルネックになりますか」と聞かれ、上手く答えられませんでした。どのように返せば良かったのでしょうか。

先日受けたサマーインターンの技術面接の終盤で、自分が作ったポートフォリオのシステム構成について話していた際、「もしこのアプリのユーザー数が一気に10倍になったら、全体のどこが最初にボトルネック（負荷の集中によって処理が遅くなる場所）になりますか？」と質問されました。

その時は焦ってしまい、「全体のアクセスが増えるので、サーバー全体のスペックを上げるか、データベースを新しくします」と大雑把に答えてしまったところ、面接官の反応はあまり良くありませんでした。

実務経験のない学生の立場で、10倍の負荷に耐えられるかどうかなんて想像がつかないのですが、どのように答えるのが正解だったのでしょうか。面接官を納得させられるエンジニアらしい論理的な答え方が知りたいです。

A.現在のシステム構成における負荷の仮説を立てた上で、負荷テストやプロファイリングツールを用いて、どこがボトルネックになるかを数値ベースで検証・特定するプロセスを伝えましょう。

自分が作ったプロダクトのユーザー数が10倍になるというのは、個人開発の段階ではなかなか実感が湧かないシチュエーションですよね。

ですが、面接官はあなたに「いきなり完璧な正解を言い当てる予知能力」を求めているわけではありません。

実際の開発では、アクセス急増によるシステムダウンを防ぐために、「どこに負荷がかかるか」を論理的に推測し、実験によってデータを集めて対策を打つ業務が日常的に発生します。

面接官が見ているのは、あなたの勘やイメージではなく、実務同様に推測（仮説検証）と計測（データ）に基づいてボトルネックを特定し、それに対する的確なアプローチを導き出せる論理的思考力です。

まずは質問の裏にある、面接官の本当の意図を紐解いていきましょう。

面接官が質問する本当の意図

面接官がアクセス急増時のボトルネックを尋ねる際、注目しているのは現在のシステム構成の理解度と、限られたリソースの中で最適解を見つけ出すエンジニアとしての思考の深さです。具体的には、以下の2つの観点から実力を測ろうとしています。

データに基づいた課題発見力

「なんとなくサーバーが重そうです」という主観や勘ではなく、負荷テストなどの数値データを根拠にボトルネックを語る実務的な視点があるかを見ています。問題の原因をログやメトリクス（計測データ）から冷徹に突き止められるスタンスがあるかを確認しています。

費用対効果を意識した対策の引き出し

闇雲にサーバーのスペックを上げる（課金して解決する）のではなく、コストを抑えた効率的な打ち手から検討できるかを見ています。コードの修正やクエリの最適化など、まずはアプリケーション側でできる対策を行い、それでも限界がある場合にインフラを増強するという、優先順位の付け方ができるかを確認しています。

ボトルネックに対する答え方

面接官の意図を汲み取り、主体的に開発を行っている学生としての視座の高さを示すためには、ただ「インフラを強くします」と答えるだけでは不十分です。以下の2つのポイントを意識して、具体的なアプローチのロードマップを語りましょう。

推測と計測のプロセスを伝える

「ユーザー数が10倍になった場合、複雑なテーブル結合を行っている〇〇の機能において、データベースの結合・集計処理（CPU・メモリ、場合によってはディスクI/O）がボトルネックの候補になると推測（仮説）しています。

そこで、実際にJMeterなどの負荷テストツールを用いて擬似的に10倍のトラフィックをかけ、CPU使用率やレスポンスタイムの計測データを取ることで、正確なボトルネックの位置を特定します」というように、検証の手順をロジカルに伝えます。

低コストな順に対策のロードマップを提示する

特定したボトルネックに対して、打ち手の優先順位を語ります。「いきなりサーバーのスペックを上げるのではなく、まずはインデックスの追加やクエリの書き換えといったDB側のチューニング、次にキャッシュ導入などソフトウェア面の最適化を行います。

それでもハードウェアの限界を迎える場合は、データベースのリードレプリカ導入によるインフラ側のスケールアウト（負荷分散）を検討します。書き込みやロックが原因の場合はレプリカでは解決せず、シャーディングやキューイング等の別手段が必要です）」というように、費用対効果の高い順に対策を語ることで、実務を見据えた高度な判断力をアピールできます。

回答例文

実際の面接の場で、これらのポイントがどのように評価に影響するのか、具体的な例文とで比較してみましょう。

NG例文：勘による主観的な判断・コスト度外視のインフラ増強

「ユーザー数が10倍になったら、全体的にアクセスが集中するので、トップページの画面表示が一番重くなると思います。画像データなども多くて通信に時間がかかりそうなので、そこがボトルネックになるのではないでしょうか」

「もし負荷が高まって処理が遅くなるのであれば、クラウドの管理画面からWebサーバーとデータベースのインスタンスタイプを上げて、スペックを高くすることで対応します。サーバーの数を増やしてアクセスを分散させれば問題ないと思います」

【解説】

「画面表示が重そう」「画像が多いから」というイメージだけの回答や、具体的な原因特定をしないまま「スペックを上げる、サーバーを増やす」という力技の回答は、技術選考の場では評価されにくいです。実務でこれをやると、原因が解決しないままインフラコストだけが膨れ上がるリスクがあるためです。面接官が求めている「推測と計測、そしてコストを意識した段階的な打ち手」の視点が伝わりません。

OK例文：仮説検証のプロセスと、コストを意識した段階的なアプローチ

「ユーザー数が10倍になった場合、現状のシステム構成では、ユーザー同士の紐付けを多対多で処理しているタイムライン生成機能において、データベースの結合・ソート処理（CPU・メモリ、場合によってはディスクI/O）が最初の限界を迎える候補になると推測しています。

ただし、これはあくまで私の仮説ですので、まずは『計測』によってデータを特定します。具体的には、JMeterを用いてピーク時の10倍を想定し目標RPSや同時ユーザー数を設計した負荷シナリオで段階的に負荷をかける負荷テスト環境を構築します。その上で、データベースのI/O速度やスレッド数の推移、スロークエリログ（処理に時間がかかっている命令の記録）や該当クエリの実行計画（EXPLAIN）を確認し、どの処理がボトルネックになっているのかを数値ベースで検証します。

対策のロードマップとしては、いきなりインフラの課金スペックを上げるのではなく、費用対効果の高い順に進めます。ファーストステップとして、対象クエリへの適切なインデックスの追加や、アプリケーション側での内部キャッシュ処理の実装による、データベースへのアクセス頻度自体を下げる最適化を行います。

もしこうしたコードやクエリ側のチューニングを行ってもなお、ハードウェアの限界によってスループットが向上しない場合に初めて、データベースのリードレプリカを配置して読み込み処理をスケールアウト（負荷分散）させるインフラ側の増強を検討します」

【解説】

「タイムライン生成機能の多対多の処理」という具体的なアーキテクチャの課題（推測）からスタートし、負荷テストツールを用いて「数値ベースで検証する（計測）」というエンジニアらしいアプローチが語られています。さらに、対策の順番が「コード側の最適化（低コスト）」、その次に「インフラのスケールアウト（高コスト）」と段階的になっており、費用対効果を意識した実務レベルの視点を十分に満たした回答です。

なお、実際の面接の場では一気に言い切るのではなく、会話に応じて適宜区切って伝えましょう。

仮説検証のプロセスを明確にし、実務レベルの視点を示す

技術面接において、現在のポートフォリオにボトルネックや弱点があること自体は問題ありません。

大切なのは、アクセス急増という課題に対して、どのようなステップを踏めば原因を特定し、解決できるかという「エンジニアとしての問題解決のアプローチ」を持っているかです。

「サーバーを強くします」と一言で片付けるのではなく、面接前に自分のプロダクトのどの機能にデータが集中的に集まるかを振り返り、それをどうやって計測し、どういう順番で改善していくかをロジカルに整理してみましょう。

主観的な勘に頼ることなく、どの数値をどう計測し、どこからコスト最適なチューニングを施していくかをロジカルに整理しておくことで、面接官の深掘り質問に対しても実務を見据えた解像度の高い受け答えができるようになります。

この質問の回答者

ITエンジニアを目指す新卒学生向け就活エージェントならレバテックルーキー

レバテックルーキーは、レバテックが運営するITエンジニア専門の就活エージェントです。多数のITエンジニアのキャリア支援経験のあるアドバイザーが、あなたのスキルと希望に合わせた企業の紹介から、人事目線での面接対策など、就職までを一貫してサポートします。ES添削、面接対策、ポートフォリオ作成サポートなども実施していますので、まずは一度カウンセリングにお越しください。

就活アドバイザーに相談してみる