初めまして。
私たちはカバー株式会社25卒エンジニアのYとKです。
本記事では、私たちが参加した日本CTO協会の「新卒エンジニア合同研修」での学びをご紹介します。
「新卒エンジニア合同研修」とは？
私たちが参加した「新卒エンジニア合同研修」は、一般社団法人日本CTO協会が主催する、企業の垣根を越えたエンジニア育成プログラムです（参考）。
今日の日本では、エンジニアの採用・育成はあらゆる企業にとって経営の重要な要素となっています。しかし、国内のエンジニアは慢性的に不足しており、特にスタートアップや中小企業にとっては、採用コストに加えて育成コストの負担が大きいことが課題です。また、新卒エンジニアが1つの企業に所属するだけでは、多様な視点や実践的な経験を得る機会が限られてしまうという現状もありました。
このような背景から、日本CTO協会は、将来のエンジニアリーダーやCTOを育成することを目的に、採用だけでなく「育成」の側面に注力した本研修を2024年に開始しました。企業の枠を越えて共に学ぶことで、日本の技術力全体の向上に貢献することを目指しています。
研修内容
本研修では、日本CTO協会の会員企業が講師となり、多岐にわたるテーマで実践的な講義や演習が行われました。2025年度に実施された主な研修内容は以下の通りです。
- クラウド技術の習得:
- グーグル・クラウド・ジャパン合同会社様による「BigQuery & Gemini」の活用研修
- アマゾンウェブサービスジャパン合同会社様による「AWS JumpStart」初学者向け研修
- エンジニアとしてのキャリア形成:
- 日本CTO協会および株式会社LayerX様のCTOによる講話
- 株式会社Progate様による「生成AI時代のソフトウェアエンジニアの働き方」に関する講義
- 実践的な技術演習:
- GMOペパボ株式会社様による「サーバー解体研修」
- 株式会社PR TIMES様による「日本CTO協会ISUCON新卒研修」
- 最先端技術の動向:
- 日本マイクロソフト株式会社様による「生成AIに関する講義」
各分野の第一線で活躍する企業から直接指導を受けることで、最新技術の知識を深めるとともに、キャリア形成などエンジニアとしての視野を広げる大変貴重な機会となりました。
本記事では、Yがサーバー解体研修、KがISUCON新卒研修について、それぞれの学びをご紹介します。
サーバー解体研修（レポート：Y）
初めまして。
カバーはUnityエンジニア担当、クリエイティブ制作本部 技術開発部 第1開発チームはエンジニア見習い、Yyyyyyyyyyyでございます！🐚
普段の業務ではバラエティ企画や生誕ライブなど3D配信の実装を担当しています。
私からはGMOペパボ株式会社様によるサーバー解体研修の学びについて説明します。
本研修の会場はGMOインターネットグループ様にご提供いただきました。
サーバー解体研修では文字通り物理サーバーの解体を体験しました。本研修を受講することで得られた主な学びは以下の3点です。
・サーバーに物理的な障害が発生した際、内部の部品を修理・交換するといった保守作業が必要になることがあります。今回の分解・組立の経験は、そうした緊急時の対応に向けた実践的なトレーニングとなりました。
・クラウド技術の実体である物理サーバーを触ることにより、クラウドがどのような土台の上で動いているかを具体的にイメージでき、クラウド技術への理解につながりました。
・実際にサーバーの中身を見ることで、データの流れや部品の配置とつながりを体感することができ、教科書などで学んだ知識が生きた知識として実感できました。
デル・テクノロジーズ株式会社様から検証用のサーバーをお借りしました。解体の様子を写真付きで紹介していきます。
まずこちらは段ボールから取り出したばかりのサーバーの外観です。今回扱ったのは、データセンターなどのラックに搭載するラックマウントサーバーです。このサーバーは薄型なため、拡張カードをそのまま挿すスペースがありません。そこでライザーカードという部品を使い、カード類をマザーボードと水平に設置することで、限られたスペースに多くの部品を搭載しています。
いよいよサーバーの中身を見ていきます!
これから各部品の解説をしていきますが、その前にどこにどのような部品があるか考えてみてください。また、少し難しい質問ですが、インフラエンジニアの方は各部品についている青い印は何を表しているのか考えてみてください。（写真には写っていませんが、ファンはオレンジ色の印なのがヒントです）
CPU+ヒートシンク：CPUは、メモリからデータを受け取って処理を実行する、サーバーの「頭脳」にあたる非常に重要なパーツです。CPUは処理中に高熱を発するため、ヒートシンクがその熱を効率的に逃がす（放熱する）役割を担います。 また、サーバーは一般的なクライアントPCとは異なり、24時間365日の連続稼働が求められます。そのため、データの誤りを自動で訂正するECCメモリに対応したCPUが採用されています。
こちらがCPUが搭載されているソケットです。CPUの熱をヒートシンクに効率よく伝えるための熱伝導グリスの跡が見えます。稼働する状態でサーバーをお返しする必要があったため、さすがにこれ以上の分解は控えました。
GPU(Graphics Processing Unit)：グラボとも呼ばれるグラフィックボードに搭載されている、並列計算に特化した半導体チップです。ディスプレイの各ピクセルに何色を出力するか決定するレンダリングという工程では膨大な計算を同時に行う必要があります。この処理は並列計算と非常に相性がよいため、GPUが主たる役割を担います。高精細なゲームやCG制作に強力なGPUが不可欠なのはこのためです。近年では、この並列計算能力をグラフィックス以外の目的で活用する GPGPU (General-Purpose computing on GPU) という技術が発展しました。これはAIの学習に必要な行列計算にも極めて有効であるため、AI分野でのGPU需要が急激に高まっています。弊社でも大量の照明計算やタレントさんの質感を高めるための高度なシェーディングに強力なGPUを使用しています。
ちなみに各チームのサーバーにGPUが入っていたわけではなく、幸運にもたまたま筆者のチームにGPUが搭載されていたそうです。
今回内蔵されていたGPUはNVIDIAのRTX6000という型番で主にワークステーション向けのものでした。
メモリ：CPUが処理を行うためのデータやプログラムを一時的に記憶する役割を持ちます。今回のサーバー内では16GBのメモリモジュールが16枚搭載されており、合計256GBの容量でした。取り外しは簡単でしたが、戻すときはメモリを上から強く押さないといけなかったためメモリが折れそうで少し怖かったです。CPUの節でも言及しましたが、サーバーではデータの信頼性を高めるため、ECC（Error Correcting Code）メモリが一般的に使用されます。通常のメモリは片面に8個のチップ（黒い部品）が搭載されているのに対し、ECCメモリはエラー訂正用のチップが1つ追加されているため、合計9個のチップが搭載されているのが物理的な特徴です。
ECCメモリはエラー訂正メモリと呼ばれることもあります。極まれに（年に1回程度）電気的なノイズや宇宙線などの影響でビットが反転してしまうことがあります(参考)。金融機関や医療機関のような社会インフラを支えるシステムはもちろん、多数のユーザーが利用しサービス停止が事業に甚大な影響を及ぼすソーシャルゲームのサーバーなどでは、たとえ年に一度のデータ誤りでも重大な問題となります。このビットの誤りを自動で検知・訂正し、システムのクラッシュを防ぐのがECCの重要な役割です。
ファン：サーバー内を効率よく冷やすため、側面に空冷ファンが一列に取り付けられています。サーバー内が効率よく冷やせるように部品配置がなされているようです。
こちらができるだけ部品を取り除いたサーバーです。達成感がすごい！（この後写真をもとに部品をすべて元に戻しました。GPU部分が硬くて元に戻すのに苦労しました）
さて、冒頭で青とオレンジの印が何を表しているのか考えていただきました。
正解は青がコールドスワップ（電源を落とさないと取り外せない）でオレンジがホットスワップ（電源がついたまま取り外し可能）です。CPUやメモリなど重要な部品がコールドスワップになっていて、ファンなど演算には直接関係しない部品はホットスワップになっています。
おまけ
こちらは懇親会で自由に分解していいといわれ寄ってたかって分解したハードディスクと3Dスキャンした物理サーバーです。
日本CTO協会ISUCON新卒研修（レポート：K）
にゃっはろー！🌸
CTO室 インフラチームのKです。
普段の業務では、ホロプラスのエンジニアチームにて、バックエンドの開発を担当しています。
私からは、株式会社PR TIMES様主催の「日本CTO協会ISUCON新卒研修」に参加し、Webサービスのパフォーマンスチューニングに取り組んだ経験と学びについてご紹介します。
研修の会場はピクシブ株式会社様にご提供いただきました。
ISUCONとは
ISUCONは「Iikanjini Speed Up Contest」の略で、与えられたWebサービスをルールの中でいかに高速化するかを競うコンテストです。参加者にはWebサービスの実行環境が提供され、その性能をベンチマーカーというツールでスコア化します。スコアは処理できたリクエスト数で決まるため、Webサービスの処理能力を上げることが高スコアに繋がります。2011年から開催されており、昨年で14回を迎える人気の技術コンテストです。
ISUCON研修では、当日初めてお会いした他社の新卒の方々と3人チームで、この高速化に挑戦しました。
競技課題のWebサービス
課題として与えられたWebサービスは画像投稿サービスです。画像の一覧表示と詳細表示、画像やコメントの投稿、ユーザー登録やログインなどの機能があります。
初期状態の確認
まずは現状把握から始めました。計測ツールとしてDatadogを導入し、APM（Application Performance Monitoring）でアプリケーションの動作を可視化し、その上で最初のベンチマークを実行しました。
初回ベンチマーク後、トップページへのアクセス数が多く、また平均2000msもの時間がかかっていることが判明しました。
また、DatadogからトップページのTraceを見ると
- commentsテーブルへのクエリに時間がかかっている
- N+1クエリを実行している
ことが分かりました。
テーブルへのインデックス追加
特に遅かったのが、commentsテーブルからpost_idを指定して、created_atの降順でコメントを取得する以下のクエリでした。
SELECT * FROM comments WHERE post_id = ? ORDER BY created_at DESC LIMIT ?原因を探るため、EXPLAINを使ってこのクエリの実行計画を確認しました。
EXPLAIN SELECT * FROM comments WHERE post_id = 100 ORDER BY created_at DESC LIMIT 10; 
EXPLAINの実行結果がこちらです。
typeがALL（フルテーブルスキャン）となっており、インデックスが全く使われていないことがわかりました。
また、ExtraにUsing filesort と表示されています。これは約95,000件のレコードの中から該当データをソートしているため、非常に効率の悪い状態です。
そこで、post_idとcreated_atの複合インデックスを追加しました。
CREATE INDEX idx_comments_on_post_id_and_created_at ON comments (post_id, created_at DESC);
インデックス追加後の実行計画では、typeがrefに変わり、新しく作成したインデックスが使われるようになりました。ExtraからもUsing filesortが消えたことが確認できます。
こちらはpost_idとcreated_atの複合インデックス追加後のTraceの画像です。
commentsテーブルに対するクエリの速度が向上していることがわかります。
全件取得とN+1問題の改善
commentsテーブルへのインデックス追加後もトップページにはまだ改善の余地がありました。
SELECT id, user_id, body, mime, created_at FROM posts ORDER BY created_at DESC;トップページにおいて最も時間のかかっていたクエリがこちらです。
typeがALL（フルテーブルスキャン）であり、ExtraにUsing filesortが表示されています。これは先に解説したようにクエリの速度を低下させる原因です。
では、なぜ全件取得するようなクエリが実行されていたのでしょうか。
トップページの仕様は、削除フラグが立っていないユーザーの投稿を20件表示するというものでした。
この仕様を実現するため、元々のコードでは
- postsテーブルから全投稿取得する
- 取得した投稿ごとにusersテーブルからユーザー情報を取得する
- 削除フラグが立っていないユーザーの投稿を取得する
- これを20件取得できるまで繰り返す
という実装になっていました。
つまり、投稿を取得した後にユーザーが削除済みかを確認する必要があるため、単純にLIMIT 20では絞り込むことができません。取得した20件の中に削除済みユーザーの投稿が含まれていると、表示件数が20件に満たなくなるためです。
この実装は以下の点が問題です。
- 最終的に必要な投稿は20件のみであるにもかかわらず、postsテーブルから全件取得している
- 投稿ごとにusersテーブルへのクエリが実行されている(N+1問題)
この問題を改善するため、JOINを使って投稿とユーザーの情報を一度に取得し、さらにLIMITで取得件数を制限するようにクエリを修正しました。
修正後のクエリ
SELECT
posts.id, posts.user_id, posts.body, posts.mime, posts.created_at
FROM
posts
JOIN
users ON users.id = posts.user_id
WHERE
users.del_flg = 0
ORDER BY
posts.created_at DESC
LIMIT 20;さらに、ORDER BY posts.created_atを効率化するため、posts(created_at)にインデックスを追加しました。
CREATE INDEX idx_posts_on_created_at ON posts (created_at DESC);クエリ修正、インデックス追加後のEXPLAIN実行結果がこちらです。
これらの改善により、トップページの処理時間は初期の2000msから約8msへと大幅に短縮されました。
そして次のボトルネックは、GET /imageエンドポイントであることもわかります。
学び: 推測するな計測せよ
私たちのチームにはISUCON経験者がおらず、初手の動きをどうするべきか悩んでいました。
他チームの方にアドバイスを求めたところ、「まずは計測から」と教えていただきました。
幸い業務でDatadogの導入経験があったため、限られた時間の中でも計測環境をすぐに構築できました。（※Traceの自動計装にはorchestrionを利用しました）
計測から始めることで、憶測ではなくデータに基づいてボトルネックを特定し、的を射た改善を繰り返すことができました。この「計測→改善」のサイクルを実践できたことが最大の学びです。
当日の反省: ボトルネックの見極め
研修中はデータベースの改善でスコアが伸びたことに満足していましたが、実は「システム全体のボトルネックが本当にデータベースなのか？」という根本的な確認を飛ばしていました。今回は結果的にmysqldのCPU使用率が高く、データベースがボトルネックでした。しかし、もしアプリケーション側がボトルネックであれば、的外れな改善になっていたでしょう。
最初にtopコマンドなどでリソース状況を確認し、CPU、メモリ、I/Oのどこに負荷がかかっているかを見極めるべきでした。この視点は、今後の業務でも意識したいです。
研修後の振り返りとして、初回ベンチマーク実行時とインデックス追加後のCPU使用率を改めて確認しました。
こちらは初回ベンチマーク実行時のCPU使用率を示した画像になります。
mysqldのCPU使用率が高く、データベースに負荷がかかっていることがわかります。
次に、commentsテーブルへのインデックス追加後のCPU使用率を示した画像がこちらです。
インデックスの追加によって、mysqldのCPU使用率が低下し、データベースの負荷が改善されたことがわかります。
業務への活用
今回の研修で学んだ「まずは計測する」という原則は、そのまま日々の業務に活かせます。例えば、ユーザーから「アプリが重い」という報告があった際も、憶測でコードを修正するのではなく、まずはログやメトリクスを確認します。そして、具体的なボトルネックを特定してから改善にあたります。このアプローチをこれからも大切にしていきます。
全ての研修を終えて
サーバー解体研修を担当したYです。
サーバーサイドの経験はほとんどなく、主にゲームエンジンのフロントエンドを触ってきたため物理サーバーを分解したのは貴重な経験になりました。
弊社でも様々なハードウェアやサーバーを用いているため、普段の開発でも低レイヤやバックエンドのことを意識して開発していきたいと思いました。
各研修を通して様々な企業の新卒の方と話したり、多様な講義を拝聴したりしたため視野と人脈を広げることができました！
ISUCON新卒研修を担当したKです。
ホロプラスの業務を通して学んだことを研修で活かし、スコアを上げることができて楽しかったです！
研修で得た実践的な知識はもちろん、他社の皆さんと交流し、人脈を広げられたことも大きな学びです。
今後も勉強会等で継続的に交流したいと考えています。
謝辞
最後に、このような学びと出会いの場を提供してくださった日本CTO協会の皆様、熱意あるご指導をいただいた講師の皆様、そして本研修を支えてくださったスポンサー企業の皆様に、心より感謝申し上げます。また、弊社も飲食スポンサーとして本研修に微力ながら貢献できましたことを光栄に思います。
本当にありがとうございました。
