Systems Performance / OS / Networkの入口
Backendの応答時間には、CPUで処理する時間だけでなく、実行順・接続・I/O・DBを待つ時間も含まれる。Platform Engineerが増設や設定変更を判断するには、アプリの遅延をOS・Networkの動きまで結び付ける必要がある。Nintendo Systems求人の性能分析・安定運用・HTTP・コンテナ・スケーラブルな設計と接続する基礎であり、同社の内部構成を説明するページではない。
まずこの入口を読み、用語と観測の目的を理解してから会話learnへ進む。全コマンドを実行したり、面接の正解を覚えたりする必要はない。
基本概念：処理しているのか、待っているのか
Section titled “基本概念：処理しているのか、待っているのか”Processは実行中プログラムの資源を管理する単位、Threadは実行の流れ。CPU schedulerは実行可能なthreadへCPU時間を割り当てる。実行可能でもCPUを得られなければrun queueで待ち、I/O完了やlockを待つthreadは別の待ち状態になる。Context switchは実行対象の切替で、回数の増加だけでは障害と決められない。
仮想メモリはプロセスから見えるアドレス空間。Page faultは必要なページへのアクセスをOSが処理する契機で、必ずディスクI/Oを伴うわけではない。Swapはメモリ圧迫時などにページを退避する仕組みで、空きメモリの少なさだけでは枯渇を証明できない。キャッシュや回収・待ち時間も見る。
File descriptor（FD）は開いたファイルやsocket等を参照する番号。Socketは通信端点であり、HTTP request数とsocket数は同じではない。Keep-Aliveは接続を再利用し、connection poolは再利用可能な接続と貸出数を管理する。HTTP/2・HTTP/3では多重化もあるため、プロトコルと実装を確認する。
レイヤーをつなぐ
Section titled “レイヤーをつなぐ”例えばAPI呼出しは、名前解決（DNS）→ 接続確立 → 必要ならTLS → リクエスト処理 → DB／外部API → 応答という段階を持つ。接続再利用時にすべてをやり直すとは限らない。HTTP/1.1・HTTP/2は通常TCP上、HTTP/3はQUIC/UDP上なので、TCPの観測を全通信へ当てはめない。
アプリはsyscallでkernelへI/Oなどを依頼する。NICなどの割込みとsoftirqによる処理にもCPUを使う。CPU平均に余裕があっても、一部coreやネットワーク処理に偏りがあれば待ちが増えうる。まずrequestのどの区間が延びたかを測り、対応する資源を見る。
主要メトリクスと、値から立てる仮説
Section titled “主要メトリクスと、値から立てる仮説”ここは診断候補であり、実測結果ではない。正常時との変化、同じ時間帯、対象process/core/container、単位と集計期間を揃える。使用率・待ち・エラーを分ける考え方はUSE Methodを参照する。
| 観察対象 | 疑うこと・次に照合するもの | 主な道具 |
|---|---|---|
| CPU utilization、core別使用率、run queue | 実行待ち・core偏り。containerのCPU制限／throttlingも確認。低い全体平均だけでCPU要因を除外しない | top、vmstat、sar |
| Context switch | thread数・同期・頻繁な待ち起こし。件数だけで良否を判定せず処理量と比較 | vmstat、sar、perf |
| Memory、page fault、swap入出力 | 割当て・回収・ディスクからの読込。minor/major faultとアプリ遅延を照合 | top、vmstat、sar |
| FD使用数と上限 | socket等の増加・解放漏れ・上限接近。接続失敗ログと比較 | /proc、ss（socketの内訳） |
| TCP状態、listen/accept待ち | 接続確立かaccept処理かを区別。ESTABLISHED・SYN-RECV・TIME-WAITは役割が違い、数の多さだけで異常扱いしない | ss、TCP統計 |
| Retransmission、packet loss、throughput、latency | 輻輳・経路・受信側処理などの仮説。再送増加だけで発生箇所を断定しない | ss、sar、通信の計測 |
| Disk/network I/O、待ち時間 | deviceや経路の詰まり、アプリ側の待ち。I/O waitだけで原因deviceを決めない | iostat、sar、trace |
| syscall、interrupt、softirq | 頻繁なkernel処理、CPU偏り、時間を使う関数 | perf、eBPF系の目的別ツール |
| DNSの所要時間・失敗 | resolver・cache・上流問い合わせを分離。APIの処理時間と区別 | 名前解決の計時、resolverログ |
| connection poolの使用数・待ち時間 | DB接続を借りる前の待ちか、借りた後のquery/lock/I/Oか | アプリのpoolメトリクス、DB統計・trace |
topはprocess/thread、vmstatは実行待ち・メモリ・I/O等の概要、iostatはdevice、ssはsocket、sarは資源の時系列、perfは実行箇所などを調べる入口。eBPF系ツールは選んだイベントを観測する手段で、「eBPFを入れれば原因が出る」というものではない。権限・kernel・計測負荷を確認し、問いに合う道具を選ぶ。
LinuxのTCPでは、接続確立途中のキューと、確立後にacceptされるのを待つキューを区別する。listen(backlog)は後者に対応し、somaxconnの上限も受ける。キュー上限を増やすだけでは処理速度は上がらず、待ち時間を増やす可能性がある。listen(2)、tcp(7)。
同じ性能劣化を高レイヤーからも見る
Section titled “同じ性能劣化を高レイヤーからも見る”演習上の追加条件：10,000 RPSでlatencyが急増し、ホスト全体のCPU平均は40%。 実際の本人のケースや会社の測定値ではない。次は観測前の仮説例で、原因はunknown。
- Pool待ちなら、DB時間と接続保持を調べる。アプリ増設は総接続数を増やしてDBを悪化させる可能性がある。
- 接続確立が遅ければ、DNS・TCP・TLSの区間と再利用を分ける。socket待ちをDBの遅さと取り違えない。
- 一部coreやI/Oに偏るなら、全体CPUを基準にしたAuto Scalingが反応しない可能性がある。待ちの解消と負荷の分散を比較する。
対応する設計判断はTraffic設計の入口へ。観測 → 仮説 → 追加観測による切り分け → 対策 → 副作用の確認を一組にする。
AWSと現職のケースへの接続
Section titled “AWSと現職のケースへの接続”調査ケースから知識を更新する — epoll・NFS・Go/futex・起動障害・パッケージ・DNSの7ケース。経験の経緯から今の理解・設計判断へつなぐ技術補足と開始プロンプト。
EC2ではOSとアプリの両方を観測し、EBS・network・LB・DBの待ちと時刻を合わせる。ECS/FargateやLambdaではホストkernelへのアクセスが制限されるため、同じ道具を使える前提にしない。利用できるserviceメトリクス、container/app計測、traceを組み合わせる。
ALBのTargetResponseTimeはtargetへ送信後、応答headerを受け取り始めるまでを測る。利用者のDNSや接続を含むend-to-end時間とは異なる。ALBメトリクス定義を確認して比較する。
日々のLinux/AWSケースでは「どの区間が遅いか」「どの資源が待っているか」「Backend設計なら何を変えるか」を問いにする。教材に戻すのは一般化した概念だけとし、顧客情報や未共有の担当実績を加えない。
最低限の理解とセッション開始
Section titled “最低限の理解とセッション開始”開始時に、CPU実行と待ち時間の違い、requestとconnectionの違い、メトリクス一つで原因を確定できないことを言葉にできればよい。分からない用語はlearnで説明を求める。読了だけでは習得を認定しない。
AGENTS.md、CHATGPT.md、careerの最新方針とsystems-performanceの入口を読んでください。今回はlearnです。まず入口の用語で不明なものを一つ確認し、必要な説明から始めてください。その後、一つの性能劣化を題材に、最初の問い → 条件追加 → 観察すべきメトリクス → 原因仮説 → 設計上の対策 → トレードオフの順で、回答を一つずつ待ってください。未提示の条件はunknown、追加条件は「演習上の追加条件」と明示してください。約40分で区切り、実際の回答・ヒント・未回答だけを既存Session Syncへ残してください。一次資料・対象
Section titled “一次資料・対象”確認日：2026-09-11。Linux一般の概念入口。実験環境・kernel・各ツールのバージョンは未指定で、実測は未実施。コマンドのoptionやしきい値はセッションの環境で確認する。
- Brendan Gregg：USE Method — 著者による観測方法。
- Linux man-pages 6.19：listen(2)、tcp(7) — TCP・socketの意味。
- Linux kernel：Networking StackのScaling — rolling文書、対象kernel版は実環境で確認。受信処理とCPU分散。
- AWS ALB CloudWatch metrics — サービス文書、固定版なし。