バックエンドの面接質問をひとつずつ見ると、あまりつながりがないように見えます。システム構成、MySQLエンジン、Linuxのパッケージマネージャ、SSHトンネリング、ERD、Redis、デプロイ、WAS最適化、PayPal連携、セキュアコーディングまで。範囲が広すぎますよね。
でも面接を何度か受けてみると見えてきます。質問はバラバラでも、選別しているものはほぼひとつです。
自分が作ったシステムを一枚で描けるか、そしてその中の箱をひとつ深く開けられるか。
この記事では、その視点でよく出てくる13の領域の核心を整理しました。模範解答ではなく、自分の経験を見直すためのチェックリストとして読んでみてください。
システム全体を一枚に描く#
面接の最初の質問は、たいてい似ています。
「前のプロジェクトのシステム構成を説明してください。」
この質問が見ているのはシンプルです。自分が触ったシステムを一枚で描けるかどうか。描ければ続きの質問が意味を持ち、描けなければそのあとの質問が全部詰まります。
良い構成図には三つの要素が入ります。
- コンポーネントと責務 — クライアント、ロードバランサー、WAS、DB、キャッシュ、外部APIがそれぞれ何をしているのか
- コンポーネント間の通信 — HTTP/HTTPS、gRPC、JDBC、キュー、どのプロトコルで何がやり取りされるのか
- 失敗経路 — ひとつのコンポーネントが落ちたらどこにフォールバックするか、どのデータが失われるか
デプロイも、実はこの絵の延長線上にあります。「どこに載せるか」(EC2、ECS、EKS、Lambdaなど)、「どうやって無停止で切り替えるか」(ブルー・グリーン、カナリア、ローリング)、「ロールバックはどうするか」 — この三つがデプロイ質問の本質です。
WASのセットアップと最適化は、この絵の中のひと箱を深く覗き込むことです。TomcatでもSpring Bootの内蔵サーバーでも、核心は同じです。
- スレッドプールのサイズ — 同時に処理できるリクエスト数、CPUとI/Oの特性に合わせて調整
- コネクションプールのサイズ — DBが受けられる接続数と揃える必要あり (WAS × インスタンス数 ≤ DBのmax_connections)
- タイムアウト — レスポンス、DB、外部呼び出しで別々の値を明示
- JVMオプション — ヒープサイズ、GCアルゴリズム (通常はG1が標準、大きいヒープではJDK 21+の Generational ZGC が事実上の推奨)
データをどう扱うか#
データ領域は三つがまとまります。DB選定、スキーマ設計、キャッシュ戦略。
MySQLを使ったなら、どのエンジンを使ったか#
「MySQLを使いました」だけでは足りません。どのストレージエンジンを使ったかが本当のシグナルです。
| エンジン | 特徴 | いつ |
|---|---|---|
| InnoDB | トランザクション、外部キー、行単位ロック、クラスタードインデックス | ほぼすべての一般ケース |
| MyISAM | トランザクションなし、テーブル単位ロック、高速なカウント | ほとんど使わない (レガシー) |
| Memory | RAM保存、永続性なし | 一時テーブル |
実際の現場ではInnoDBが事実上の標準です。だから、より深い質問は「分離レベルは何にしましたか?」につながります。REPEATABLE READ(デフォルト)とREAD COMMITTEDの違い、そしてギャップロックがデッドロックにどう影響するか、ここまでは答えられるべきです。
ERDを描くときに何を見るか#
ERDを描く人と書き写すだけの人を分ける線はここです。
- 正規化と非正規化の意図 — 1NF/2NF/3NFを暗記することではなく、どこまで正規化して、どこから意図的に非正規化するかを決められるか
- インデックスを意識したキー選択 — よく検索されるカラムがPK/UK/インデックスに入っているか、複合インデックスはカーディナリティの高いカラムが先頭に来ているか
- 外部キーポリシー —
ON DELETEをCASCADEにするかRESTRICTにするか、それともアプリケーションが責任を持つか - 変更に強い設計 — よく変わる属性は別テーブルに分けておくと、マイグレーションが楽になります
Redis(またはValkey)は自前構築かマネージドか#
2024年のRedisのライセンス変更(SSPL/RSALv2)以降、Linux Foundationが主導するValkeyフォークが主流のOSS代替として定着しました。AWSのElastiCacheやMemoryDBもValkeyをデフォルトオプションとして提供しています。どちらを使っていても、質問の本質は同じです。
「自分で構築しましたか? それともマネージドを使いましたか?」
これが重要なのは、運用の深さを分けるからです。
- 自前構築 — マスター・スレーブ複製、Sentinel(HA)、Cluster(シャーディング)のどのモードか、メモリポリシー(
maxmemory-policy)はどう設定したか - マネージド (ElastiCache、MemoryDBなど) — 運用負荷は下がるが、コスト構造と制約(パラメータグループの制限、クラスターモードの違い)の理解が必要
キャッシュそのものについても整理しておくと良いです。何をキャッシュするか(読み込みが多く更新が少ないデータ)、有効期限ポリシー(TTL、LRU)、キャッシュミス時に起きること(thundering herdの防止)。答えが深くなります。
インフラを自分で触る#
Linux、パッケージ管理、SSHはたいていまとめて出てきます。結局のところ「ターミナルで仕事ができるか」を見ているんです。
どのLinuxを使ったか = どのパッケージマネージャに慣れているか#
| ディストリビューション | パッケージマネージャ |
|---|---|
| Ubuntu / Debian | apt, dpkg |
| RHEL / CentOS / Amazon Linux | yum, dnf, rpm |
| Alpine | apk (Dockerイメージでよく見かけます) |
| Arch | pacman |
同じパッケージでも、ディストリビューションによって名前が違い、依存関係ツリーも違います。aptだとnginx一発ですが、Alpineではnginxと一緒にca-certificatesまで明示する必要があったりします。
「パッケージを公開した」は意外と価値があります#
社内のプライベートリポジトリでもnpm/PyPI/Maven Centralでも、一度でもパッケージを公開した経験は、次のことを示してくれます。
- セマンティックバージョニング(SemVer)の意味が分かる —
major.minor.patchの変更基準 - 依存関係を明示的に管理できる — peer/dev/optionalの違い
- メタデータ(README、license、keywords)が発見性にどう影響するかを知っている
ライブラリをひとつ作って社内にでも公開してみると、ライブラリを使う視点だけだったときには見えなかったものが見えてきます。
SSHキーとトンネリング#
- キー生成は
ssh-keygen -t ed25519 -C "email"— RSAより短くて速いです - 公開鍵の登録はサーバーの
~/.ssh/authorized_keysに一行追記 - 権限は重要:
~/.sshは700、authorized_keysは600
トンネリングは、外部からは塞がれている内部リソースへ安全にアクセスする標準的な方法です。
# ローカル 13306 → bastion 経由 → RDS 3306
ssh -L 13306:rds.internal:3306 user@bastion.example.comこれを開いておけば、ローカルのMySQLクライアントからlocalhost:13306に繋ぐだけで済みます。VPNを立てずに、本番DBに少しだけ繋ぎたいときによく使います。
セキュリティをコードレベルで考える#
セキュアコーディングと決済連携は、実はひとつのまとまりです。外部と接するすべての地点に対する健全な疑いです。
セキュアコーディングの大きな4つ#
- 入力は常に検証する — SQLインジェクションはパラメータバインディングで、XSSは出力時のエスケープで
- 認証と認可は分ける — 「誰なのか」(authentication)と「何ができるか」(authorization)は別の層
- 秘密情報はコードに置かない — 環境変数、シークレットマネージャ(AWS Secrets Manager、Vault)で
- ログに機密情報を残さない — カード番号、トークン、個人情報はマスキング
PayPalのような外部決済の連携でいちばん大事なこと#
機能の動作よりも状態と冪等性です。
- 決済の状態機械を明確に定義する —
PENDING → APPROVED → CAPTURED → REFUNDEDのような流れをコードとDBに同じ形で刻む - Webhook(IPN)の検証 — PayPalからのコールバックかどうかを署名で確認し、同じイベントが再送されても一度だけ反映されるようにidempotency keyで処理
- 返金・キャンセルのトランザクション整合性 — 外部API呼び出しと自社DBの更新が食い違わないように、補償トランザクションやoutboxパターンを検討
- 決済情報は直接保存しない — カード番号はトークンとしてのみ保管 (PCI DSS 4.0基準)
この領域は「動くコード」と「運用しても壊れないコード」の差が、いちばん大きく出る場所です。
結局ひとつの問いに収束する#
13の領域を全部見てきましたが、結論は最初と同じです。
自分が触ったシステムを一枚で描けて、ひと箱をもう一段深く開けられるか。
面接対策は「MySQLの分離レベル4つを暗記する」みたいな話ではありません。自分が実際に触ったシステムの絵をもう一度描いてみて、各箱について「なんでこれを選んだんだっけ?」と自問することです。そうすれば、同じ質問が来ても模範解答ではなく自分の答えが出てきます。
最後についてくる非技術的な質問も、実は同じ系統です。「これから何を上手くなりたいか」「3年後どんな姿でいたいか」「他にも面接を受けているところはあるか」 — これは、自分のキャリアの構成図を描いたことがあるかを問うているんです。自分がどこに向かっているかを一枚で描ける人は、答えが速いんです。
技術もキャリアも、結局は同じ筋肉です。一枚で描いてみて、箱をひとつ開けてみる習慣。
Spring is a time for rebirth and the fulfilment of new life.
— Byron Pulsifer
