nginxとNFS：CPUが空いていても応答できない

このページの使い方

当時の判断を思い出すことを入口に、今の自分の知識を更新する。思い出せない事実はunknownのまま、必要な仕組みを学び直してよい。 対話はChatGPT、編集と同期はCodexで行う。ケース一覧から別のケースも選べる。

2026-09-14、Issue #16としてObsidianの retrospective.md から整理した初稿。元ノートの要約であり、全ログ・コードの独立確認や今回の再実験ではない。実際の学習sessionはまだない。原文の観測と解釈、AIによる補足を分ける。

ChatGPTで振り返り、知識を更新する

ChatGPT開始文

https://github.com/MFQWKMR4/tech2026 を参照してください。
AGENTS.md、CHATGPT.md、src/content/docs/career/index.md、
src/content/docs/projects/nginx-nfs-investigation.md、reviews/experience-nginx-nfs.yaml、
.github/ISSUE_TEMPLATE/session-sync.mdと、reviewが参照する必要なsessionを読んでください。
読めたファイルとcommit SHAを示し、読めなければ読んだとせずsession packを求めてください。
今回はsession_type: experience、topic: experience-nginx-nfsです。
当時の状況・担当・判断を一問ずつ聞いて回答を待ち、記憶を埋めるだけで終えず、必要な仕組みを学び直す時間も取ってください。
最初は「AZごとの失敗の偏りを見たとき、最初に何を比較しようと考えましたか？」と聞いてください。
元ノートの記載、当時の解釈、今回の記憶、自力の説明、AIの補足、今なら考える案を区別してください。
過去の結論を正解と固定せず、必要な箇所で一次資料と対象バージョンを確認し、日本語で説明してください。
不明な用語や前提を一つずつ説明し、理由・trade-off・例外・運用・切り分けへつないでください。
説明後は条件を少し変えた短い問いで現在の理解を確認し、解説後の回答であることを記録してください。
変更条件は「演習上の追加条件」と明示し、当時の事実へ混ぜないでください。
記憶を深掘りできない場合や私が仕組みを知りたい場合は、過去の確認に留まらず今の疑問へ進んでください。
技術の説明だけから過去の担当能力・実績を評価せず、経験の確認と現在の理解をsummaryでも分けてください。
全節や全質問を一回で消化せず、一つの仕組みを深めてください。模範の経験談を先に作らないでください。
思い出せない実務事実はunknownのまま残し、未質問を不足や忘却と判定しないでください。
会社名・顧客名・識別情報・非公開の社内情報は記録しないでください。
開始時刻を確認できれば記録し、40分付近で区切りを提案。時刻不明なら推測しないでください。
終了時は実際の問い・回答・ヒント・理解の変化・未確認事項をYAML＋Session narrativeへまとめ、
MFQWKMR4/tech2026に[Session Sync] Issueを作り、URLを返してください。
repository_requestsには、このページへ戻す経緯・新しい技術解説・再確認したい問いを記載してください。
元ノートや教材作成を私の学習evidenceにせず、今回の回答を根拠にしてください。
Issue作成機能が使えなければ未作成と明示し、コピーできるタイトルと本文を返してください。

【求人との接点を意識した深掘り】
以下は2026-09-14に私が提示した求人の観点です。求人の最新性や、私が要件を満たすことを確認済みとは扱わないでください。
必須：バックエンドWebアプリ開発、REST APIの設計・実装、チームでの技術検討と開発、クラウド／サーバー基盤の基礎知識。
歓迎：高頻度・高負荷アクセスへのスケーラブルな設計・開発・運用、RDBMS／KVSの利用・最適化・運用、LB／CDNによる高可用性、HTTP/HTTPSの仕様理解。
歓迎：AWS／Google Cloudの構築・開発、ECS(Fargate)／Cloud Run等のコンテナ運用、ALB・Lambda・SQS・DynamoDB等を組み合わせる設計。
歓迎：長期運用と機能拡張を見据えた保守性、テスト・CI/CD、DDD、認証・認可・セキュリティ、OIDC／OAuth 2.0、TLS・暗号・署名検証。
歓迎：ゲーム専用機／IoT機器向けAPI、WebRTC、分散システムの開発。
人物像：課題の本質を追い最後まで取り組む、長期運用を考え抜く、新技術を楽しみ挑戦する、クライアント／企画まで視野を広げる、複雑な課題を正しく言語化し周囲を尊重して協働する、利用者視点でチームと課題を解く。

既存needs_revisitを優先しつつ、このケースと回答に関係する観点を1〜2個選び、一問ずつ掘り下げてください。全項目をチェックリストのように消化しないでください。
「どの課題・利用者影響があったか → 自分の担当・行動 → 判断の理由と代案 → チーム内の検討・合意 → 検証・運用結果 → 今なら変えること」を、回答に応じて確認してください。
私が実施した設計・実装、運用・調査、現在理解している知識、未経験／未確認を分けてください。規模・期間・成果の数値は回答に根拠がある場合だけ使ってください。
技術名が登場しただけで経験ありとせず、求人項目を自動でgap・needs_revisit・学習evidenceにしないでください。歓迎要件をすべて経験している前提で質問しないでください。
当時の情報が足りなければunknownを残し、今知りたい仕組みは一次資料で補足して理解を更新してください。解説後の回答を当時の能力へ書き換えないでください。
実際の回答が集まったら、まず私自身に面接で話す短い説明を試してもらい、その後で根拠のある経験と求人との接点、追加確認が必要な点を整理してください。合否や数値スコアは付けないでください。
Session Syncのsummaryとnarrativeには、扱った求人観点と回答根拠、当時の経験／今の学びの区別を残してください。repository_requestsにはページへ戻す補足を記載してください。
このケースで優先する候補：高負荷時の性能、ロードバランサーと可用性、HTTP/HTTPS、クラウドの配置と長期運用、利用者影響。既存構成の調査と私自身の設計・構築を分けてください。

GitHubを読めない場合はCodexで npm run session:pack -- experience-nginx-nfs を実行し、出力を渡す。ChatGPTがローカルVaultを読めることは前提にしない。

本人の経験：元ノートにあること

問題と調査の経緯

複数AZのnginxがオンプレミス側のupstreamへTLS接続し、共有ファイルをNFSから参照する構成で、ピーク時間帯に一部AZで502が発生した。共有ストレージの稼働ノードと同じAZは正常だったと記録される。ノート内の台数表記に不一致があるため、正確な構成台数はunknownとする。

段階	ノートの観測・検証	当時の解釈と残る確認
失敗区間を絞る	TCP接続後にClientHelloの送出が遅れ、約10秒でupstream側からRST。AZ別にエラーが偏る	TLS処理を進める側の遅延を疑った。接続確立の成功だけで全ネットワーク要因を除外はできない
OSとNFSを見る	CPU idleが高く、load averageは高い。nginx workerのD stateとopenatからNFS RPC待ちへ至るstackを採取	取得した時点でworkerがNFS処理を待つ根拠。全502との対応・待ちの持続時間は別の確認
AZ差を測る	statの繰り返しとpingを比較し、別AZの所要時間が大きいと記録	配置と往復時間の差を疑う。pingのRTTとNFS操作の時間は同じ量ではない
検証環境で条件を変える	nginxとNFSを同一ホストに置き、キャッシュ設定とnetemの遅延を変更。RPC増加とRPS低下、D stateを記録	同期I/Oと遅延の影響を再現。元の全コマンド・集計期間は未収録で、本番全体の完全再現とは扱わない

ノートの検証値では、キャッシュありで約12,500 RPS、noacで約5,500 RPS、遅延を大きくした条件では約65 RPSとなる。これは元ノートに記された検証値で、今回の再実測ではない。loopback全体への遅延はNFS以外の通信にも作用し得るため、実験条件の確認が必要。

判断の変化・結果

調査はTLSエラーから始まり、workerが共有ファイルへの同期アクセスで止まる可能性へ移った。ノートはnoac・AZ間の遅延・ピーク負荷の組合せを原因として整理している。スキャンとリトライの寄与、RPCスロットの飽和は、記載されたstackだけでは確定しない。提案した改善策の本番採用と改善後の観測、本人と他の担当者の役割分担はunknown。

AIによる技術補足：今の理解を更新する

Default / Why：属性キャッシュが減らしている仕事

NFSの属性キャッシュは、ファイルの属性を毎回サーバーへ確認する負担を減らす。noacは属性キャッシュを無効にし、書き込みを同期化する。ファイルデータの全キャッシュを無効にする指定とは同一ではない。属性確認の頻度は操作・パス・NFS版にも依存するため、「全HTTP要求で必ず3回GETATTR」という一般則にしない。nfs(5)。

Trade-off / Exception：鮮度と待ち時間

キャッシュを戻す案では、更新が他のクライアントへ見えるまでの許容時間を先に確認する。鮮度要求が厳しければ、更新の配布方法・版付きファイル・参照方法も比較する。原文の「noacを外す」は、そのサービスの整合性条件を確認して初めて選べる対策である。

nginxの aio threads はファイルのread/sendをthreadへ移す機能で、すべてのopen/statやパス解決が非同期になる保証ではない。詰まっているsyscallを確認してから適用範囲を照合する。nginx aio（threadsは1.7.11以降、ビルド条件あり）。

Production / Troubleshooting：モデルと観測の境界

概念モデルとして、worker数をc、要求当たりの直列I/O回数をn、I/O一回の平均待ちをrとすると、他の仕事を無視した処理能力の目安は c / (n × r)。これは待ち行列分布を仮定せず得る粗い上限であり、それだけでM/M/cモデルの妥当性を証明しない。

原文のLittleの法則の使い方は見直す。ある瞬間に4 workerがD stateだったことは、平均の系内リクエスト数が4という意味ではない。4 / RPS をHTTP要求の平均滞在時間とするには、数える対象と時間区間を揃える必要がある。RPSとloadが近似モデルに合ったことも、本番の原因が一意に確定した証拠ではない。

CPU平均だけで増設を判断せず、worker状態・該当syscallの所要時間・NFS操作数・要求の待ち時間を同じ区間で比較する。同一AZへ集約すれば通信時間を減らせても、AZ障害への耐性を下げ得る。キャッシュ、ローカル配布、共有依存の分離を容量計画とTraffic設計へつなげる。

次の対話：当時から今へ

• 当時：どのstackや比較結果でNFSを優先して調べる判断になったか。検証条件は誰が設計したか。
• 仕組み：属性の確認とファイル本文の読み取りを分けて説明できるか。分からなければそこから学ぶ。
• 今なら：イベントループの待ちをどう計測し、どの対策を一つずつ比較するか。
• 設計判断：鮮度を維持しながら共有ストレージが遅いときの影響を局所化するにはどうするか。

経験エピソードの核は、エラーの発生層から依存先へ降り、正常系との比較と条件を変えた検証で仮説を絞ること。採用されていない対策を本人の成果にしない。

出典・対象環境

ノートはnginx・NFSv4系・共有ストレージのケース。OS/kernel/nginxの正確な版はunknown。一次資料は2026-09-14確認のnfs(5)とnginx公式の現行Web文書。対象環境の実装は別途照合する。待ち時間の式は本ページの概念モデルで、追加の本番観測ではない。

セッションと次の更新

元資料の参照は2026-09-14。原文は変更せず、顧客情報・内部情報を転載していない。本人の独力回答や深掘りsessionは未登録。質問候補と補足は学習済みの証拠ではない。ChatGPTのSession Sync後に、当時の経緯と今の理解の変化を区別して追記する。