新卒3年目がISUCONで身につけたインフラ実践知5選

はじめに

こんにちは、楽天で新卒3年目のアプリケーションエンジニアをしている @edgissa です。

私は入社同期と一緒に、隔週ペースでISUCONの過去問を解き続けています。去年はその成果もあって、800チーム以上が参加したISUCON14本戦で 23位入賞 という結果を残すことができました。

ISUCON（Iikanjini Speed Up Contest）は、LINEヤフーが運営窓口となって開催している限られた時間でWebサービスを高速化するコンテストです。参加するたびに「本番運用を模した環境に向き合うこと」になり、自然と実務にも直結する知識が身につきます。

最近ではクラウドやコンテナが当たり前になり、アプリケーション中心で仕事を進めることが多い一方で、「Linuxコマンド」「nginxやMySQLのconf」「証明書やSSH」などの “手触りのあるインフラ経験” を積みにくい場面も増えています。そんな中で、ISUCONの練習はエンジニアとしての基礎体力を鍛える最高の場になりました。

この記事では、この勉強会を通じて得られた実践知5選 を「学びの記録」としてまとめます。
Tips集というより「自分がISUCONで経験したこと」の記録ですが、同じように学んでいる方の参考や共感になれば嬉しいです。

1. HTTPSが怖くなくなった：オレオレ証明書を発行してみた

ISUCONではベンチマーカーと競技環境が HTTPSで通信します。
そのため証明書の設定ができていないと、正しくリクエストが届かず、点数すら出せないケースがあります。

実際に数年前の過去問を解くとき、証明書の期限が切れていてHTTPS通信ができずにハマります。
とくにISUCON13の解き直しでは、HTTPSに対応していないと一部のリクエストがnginxを通らず、直接アプリ側に飛んでしまうという罠もありました。
これではアクセスログが取れず、ボトルネックの調査もままなりません。

こうした経験から「自己証明書 (オレオレ証明書) を自分で発行して環境に組み込む」ことを覚えました。

---

証明書を発行する

秘密鍵（P-256）を生成し、ワイルドカードとルートドメインをSANに含めた証明書を作成します。

# 秘密鍵（P-256）: 速くて軽い
openssl ecparam -genkey -name prime256v1 -noout -out _.u.isucon.dev.key

# ワイルドカード + ルートドメインを SAN に入れる
openssl req -new -x509 -key _.u.isucon.dev.key -sha256 -days 365 \
  -out _.u.isucon.dev.crt \
  -subj "/CN=*.u.isucon.dev" \
  -addext "subjectAltName=DNS:*.u.isucon.dev,DNS:u.isucon.dev"

生成した .crt と .key をnginxに設定し、ベンチマーカー側では /usr/local/share/ca-certificates/ に配置して

sudo update-ca-certificates

を実行すれば信頼されるようになります。

補足: このコマンドの意味

証明書の発行コマンドはただの暗号呪文に見えますが、実際には以下の意味があります。

秘密鍵（Private Key）

サーバーが持つ「自分だけの鍵」。
公開鍵とペアで使われ、暗号化通信や署名検証の基盤になります。
今回は P-256（prime256v1） という楕円曲線暗号を利用していて、RSAより軽量・高速です。

SAN（Subject Alternative Name）

証明書が有効なドメインを列挙するフィールド。
例えば *.u.isucon.dev と u.isucon.dev を入れると、

• a.u.isucon.dev
• b.u.isucon.dev
• ルートの u.isucon.dev

すべて同じ証明書でカバーできます。

コマンドの分解

# 秘密鍵の生成（楕円曲線 prime256v1）
openssl ecparam -genkey -name prime256v1 -noout -out _.u.isucon.dev.key

# 自己署名証明書の発行（有効期限365日）
openssl req -new -x509 -key _.u.isucon.dev.key -sha256 -days 365 \
  -out _.u.isucon.dev.crt \
  -subj "/CN=*.u.isucon.dev" \
  -addext "subjectAltName=DNS:*.u.isucon.dev,DNS:u.isucon.dev"

• -new -x509 : 自己署名証明書を作る（オレオレ証明書）
• -subj : Common Name（古い仕組み、今はSAN必須）
• -addext "subjectAltName=..." : SANに複数ドメインを指定

秘密鍵を作って、それを元に「このドメインで使える証明書」を自分で署名して発行するという流れです。

---

実務にどう活きたか

実務では、自前で証明書を発行するよりも、社内ネットワークで用意された証明書を信頼させて使う場面の方が多いです。
ISUCONで自分で発行する経験をしたことで、証明書やproxyの仕組みを理解でき、社内環境での設定にも抵抗がなくなりました。

2. SSH/Linuxコマンドに慣れた：rsync, chmod, jqを駆使できるようになった

ISUCONでは、アプリケーション・nginx・MySQLが入った複数台のVMが渡されます。
競技中はそれぞれのサーバーにSSHで入り、設定を変更したり、ファイルを転送したり、ログを調査したりしながらチューニングを進めます。

最初はSSHでサーバーに入って突発的な作業をするときに調べながらで、非常に時間がかかりました。

---

rsyncで効率的に同期

scpを繰り返すより、rsyncで差分を同期した方が圧倒的に効率的です。
競技を通して以下のような使い方が自然に身につきました。

# DBの設定ファイルをローカルに同期
rsync -a --delete -e "ssh -p ${PORT}" --rsync-path="sudo rsync" \
    ${SERVER}:${DIR_DB} ${OUTPUT_DIR_DB_CONF}

# 初期SQLをサーバーに反映
rsync -P -a --delete -e "ssh -p ${PORT}" --rsync-path="sudo rsync" \
    ${OUTPUT_DIR_SQL_INIT} ${SERVER}:${DIR_SQL_INIT}

ISUCONでは、デプロイや計測などのコマンドはMakefileで管理してこれらのコマンドをすぐに使えるようにしています。

chmodでディレクトリを共有する

アプリが書き込んだファイルをnginxから配信するために、ユーザとグループの権限を調整する場面がありました。そのときに「chmodの4桁指定」を理解することができました。

# 共有グループを作成し、アプリとnginxを所属させる
sudo groupadd webshare
sudo usermod -aG webshare isucon
sudo usermod -aG webshare www-data

# ディレクトリのグループ変更
sudo chgrp -R webshare /var/www/app/public/icons

# setgid + 権限設定
sudo chmod 2775 /var/www/app/public/icons
sudo find /var/www/app/public/icons -type f -exec chmod 664 {} \;

ここで「2 はsetgidで、ディレクトリに適用すると新しいファイルも同じグループに揃う」という知識を体で覚えました。

補足：chmodの4桁指定とは？

chmod 2775 のような4桁指定は次の意味を持ちます。

• 1桁目（特殊ビット）
  • 2 = setgid → 新しく作られるファイルやディレクトリが親ディレクトリのグループを継承する
• 2桁目（所有者） : 7 = rwx
• 3桁目（グループ） : 7 = rwx
• 4桁目（その他） : 5 = r-x

例：chmod 2775 /var/www/app/public/icons
所有者・グループは自由に使え、その他は読み取りのみ。さらにsetgidでグループが揃うので、アプリとnginxの双方から安全に扱えます。

jqでログをフィルタする

サービスログの調査では、JSON形式のログを jq でフィルタしてエラー行を抽出する方法を覚えました。

# errorフィールドが存在する行を抽出
jq -cR 'fromjson? | select((.error // "") | tostring | length > 0)' < logfile.log

ISUCONではjournalctlと組み合わせて使いましたが、実務ではアプリケーションログの解析に応用できています。障害調査のときに「必要なログだけを拾う」力が鍛えられました。

---

実務にどう活きたか

• 「ちょっとファイルを上げて動作確認したい」ときに rsync を自然に使えるようになった
• jqでログを絞り込んで障害調査ができるようになった

SSHでサーバーに入って作業する際に調べる回数が減った のが大きな成果です

3. Vimマクロで作業が効率化した

Vimの基本操作を覚えると、どのエディタでも同じ操作ができるようになるので便利です。
InteliJ IDEAとVSCodeにもVimプラグインがあります。

Vimを使うときに特に役立つのが マクロ です。マクロを使うと「繰り返し可能な一連の操作」を記録して、何度も再生できます。

---

MySQLの結果をGoのmapに変換する

ISUCONの過去問を解いていると、MySQLの初期データをそのままアプリケーションに埋め込んで効率化したい場面があります。例えば tags テーブルを map[int]string に直したいとき、手作業で一行ずつ書き換えるのは非効率です。

ここで役立ったのが Vimマクロ でした。

例: SQLの結果

MySQL isucon@127.0.0.1:isupipe> select * from tags;
+-----+--------------------+
| id  | name               |
+-----+--------------------+
| 43  | DIY                |
| 66  | DIY電子工作        |
| 31  | DJセット           |
| 10  | FPS                |
| 19  | Q&Aセッション      |
| 9   | RPG                |
| 94  | UFO                |
| 38  | お料理配信         |
| 56  | アウトドア         |
| 11  | アクションゲーム   |
| 25  | アコースティック   |
| 4   | アドバイス         |
| 45  | アニメトーク       |

変換後: Goのmap

var TAG = map[int]string{
	43:  "DIY",
	66:  "DIY電子工作",
	31:  "DJセット",
	10:  "FPS",
	19:  "Q&Aセッション",
	9:   "RPG",
	94:  "UFO",
	38:  "お料理配信",
	56:  "アウトドア",
	11:  "アクションゲーム",

Vim マクロの操作

1. まず変換したい最初の行にカーソルを置く
2. qa でマクロの録画を開始（レジスタ a に記録）
3. 一行分を次のように編集する
   • ciW → 行内の WORD を削除し挿入モードへ
   • <C-r>" → 直前に削除した内容を無名レジスタ (") から呼び出して "..." で囲む
   • 行末にカンマ追加
4. Esc で抜けて q でマクロ終了
5. 100@a のように繰り返し適用して一気に変換

実際のマクロ操作 (GIF)

実際の操作を録画しました。
文字が小さいので全画面にしていただけると嬉しいです。

実務にどう活きたか

• 設定ファイルやログの整形など、「大量の繰り返し作業」を一瞬で片付けられるようになった
• マクロを意識することで、普段のエディタ操作も「繰り返し可能か？」と考える習慣がついた

Vimが使えると、サーバー上でも安心して操作ができます。

4. Proxmox VEで練習環境が提供できるようになった

練習環境をProxmox (自宅サーバー) で再現する

ISUCONを練習するとき、手元に本戦と同じ構成の環境を用意したくなります。
ただAWSで複数台のEC2を建てるとコストがかかるし、解き直しのたびにStart/Stopするのも面倒です。
そこで使ったのが Proxmox VE on 自宅サーバーです。

ProxmoxはKVMベースの仮想化環境で、複数のVMをGUIから簡単に立てられます。
さらに Cloudflare Tunnel を組み合わせ、自宅外のネットワークからでも安全にアクセスできる環境を構築しました。

今ではチームメンバーそれぞれがProxmox環境を持ち, 模擬戦では当番制で環境構築を回すようになりました。

実務にどう活きたか

• 仮想化の知識が広がった
  • クラスタ構成でVMの移動（vMotionに近い操作）や、CPUのリソース共有問題なども確認できた
• ansibleを使ったSSHの公開鍵配布、hostnameの設定の自動化など, IaCの基礎が身についた
  • AWS CDKやTerraformへの抵抗感がなくなった

5. Nginx, MySQLのconfを読めるようになった：抵抗感がなくなった

設定ファイルに向き合う

ISUCONの過去問を解いていると、NginxやMySQLの設定に直接手を入れる場面が必ず出てきます。

• Nginx

  • 静的ファイルを直接配信する
  • 特定のエンドポイントだけ別サーバーに proxy する
  • buffer_size や worker_connections の調整

• MySQL

  • innodb_buffer_pool_size
  • max_connections など

こうしたパラメータは「秘伝のタレ」のように見えますが (実際のISUCONでは秘伝のタレと呼びますが)、ドキュメントを読みながら一つずつ意味を理解して調整できるようになりました。

また、/etc/nginx, /etc/mysql 配下の設定ファイル、/var/log のログディレクトリや /usr/local 配下のバイナリ配置といった Linuxのディレクトリ構成 にも自然と慣れました。

---

実務にどう活きたか

• 設定ファイルを恐れず「まず読んでみる」姿勢が身についた
• 本番運用でログや conf を調査するときにも /etc や /var/log の構成をすぐ把握できる ようになった

今どきこうした設定ファイルを読んだり、設定したりすることはあまりない分、いざというときに「デフォルトの設定で大丈夫なのだろうか？」「この設定ファイル、メンテされてないけど大丈夫なのだろうか」と確認することができるようになりました。

おわりに

ここでは触れていませんが、ISUCONの醍醐味は計測とチューニングのサイクルを高速で回せることです。業務では色々な制約があって、なかなか自由にチューニングできないことも多いですが、ISUCONでは思う存分試行錯誤できます。

slowqueryログを眺めながら、DBのインデックスをバチバチと貼ってみたり、N+1問題を解消したりすると、アプリケーションのパフォーマンスが劇的に改善されるのはとても楽しい体験です。
後半戦になるとprofiler (pprof) を使ってアプリ側のボトルネックを解消していくことになり、ロジックの改善やキャッシュの効率化など腕の見せ所も増えます。
ISUCONの練習を通じて、アプリケーションエンジニアとしての基礎体力が鍛えられていると感じています。

例年ISUCON本戦は12月に開催されるのですが、今年 (2025年9月時点で) はまだ開催が発表されていません。開催されることを願いつつ、引き続き過去問を解き続けていきたいと思います。

一緒にISUCONを楽しむ仲間も募集中ですので、興味がある方はぜひご連絡ください！