アプリケーション設計

上流（ユーザーに近い側）ほどタイムアウトを長く、下流ほど短くする。逆だと、上流が諦めた後も下流が処理を続けてしまう。gRPC のようにデッドラインを下流へ伝播させる仕組みもある。

第12章「パフォーマンスチューニング」：接続プールとスレッド数の考え方を図で詳しく

多段のサービスがそれぞれ3回リトライすると、3段で 3×3×3 ＝ 27倍の負荷になる。リトライは1か所（多くは最上流か最下流）に集約するのが望ましい。

ジッターでリトライの時刻をばらけさせ、回復しかけた相手を再び落とさない。

リトライは掛け算で効く。どこか1か所に集約する。

第6章「Web技術（HTTP・URI・REST）」：HTTPメソッドの安全性と冪等性を図で詳しく

Openの間は依存先を呼ばないので、待ちが積み上がらず自分まで倒れるのを防げる。

レート制限は、同じ相手（IP アドレス・ユーザー・API キーなど）からのリクエストの回数に上限を設け、超えた分を断る仕組みです。一部の利用者やボットの大量アクセス、リトライの嵐から、サービス全体と後ろの DB を守ります。断るときは 429 Too Many Requests を返すのが一般的です。

回数の数え方（アルゴリズム）によって、短い時間に集中するアクセス（バースト）をどこまで許すかや、必要なメモリが変わります。面接では「どの単位で数えるか」「複数のサーバーで回数をどう共有するか」まで話せると強いです。

サーバーが複数台ある環境では、台ごとに数えると上限が台数倍になってしまうので、Redis でカウンタを共有するのが定番です。

下の「ブラウザで試す」の図では、API サーバーが2台あるときに、回数を Redis で共有する流れを順に追えます。台ごとに数えると上限が2倍になるところから始めて、固定ウィンドウ（INCR と EXPIRE を MULTI でまとめる）で 101 回目に 429 と Retry-After を返す手順、窓の境界の前後で2倍通ってしまう手順、スライディングウィンドウで「数えてから足す」を別々に送ると数え間違えるので Lua スクリプトにまとめる手順、トークンバケットでバーストを通し、使い切ったら待たせる手順と続きます。最後に、何をキーにして数えるか（ユーザー・API キー・IP）と、Redis が落ちたときに通すか止めるか（fail-open／fail-closed）を確かめてください。

第6章「Web技術（HTTP・URI・REST）」：HTTPキャッシュと多層キャッシュを図で詳しく

キャッシュは、DB などから読んだ結果を Redis のような速い置き場に一時的にコピーしておき、次からはそこから返す仕組みです。応答が速くなり DB の負荷も下がりますが、DB とキャッシュの2か所にデータがあるので、「誰がいつキャッシュに入れ、更新のときにどう扱うか」を決めておかないと、古い値を返し続けたり、データを失ったりします。

その決め方がキャッシュ戦略です。読み取りと書き込みのそれぞれで、アプリとキャッシュ層のどちらが DB とやりとりするかに注目して比べます。

更新時に「キャッシュを更新」ではなく「キャッシュを削除」が推奨されるのは、同時更新で古い値が残る競合を減らせるため。

書き込み時は値を入れ直さず削除する。次の読み取りで最新が入る。

下の「ブラウザで試す」の図は、いちばんよく使う Cache-Aside の流れです。まず Redis を見て、なければ（キャッシュミス）DB から読んで TTL 付きで Redis に入れ、次の読み取りはヒットして DB に行かない、という順番を見られます。更新のときに DB を更新してからキャッシュを DEL で消すところと、消し忘れても TTL が古さの上限になるところに注目してください。

キャッシュは「DB の前の盾」として負荷を引き受けているので、キャッシュが効かなくなった瞬間に、その負荷がまとめて DB に向かいます。下の問題はどれも、形は違っても「本来キャッシュが受けるはずのリクエストが DB に流れ込む」か「一部に集中する」ことで起きます。

平常時のヒット率だけを見ていると気づきにくく、ピークの時間帯やデプロイ・障害の直後に表に出がちです。DB の CPU や接続数が急に跳ねたときに、キャッシュの側で何が起きたかを疑えるようにしておきます。

下の「ブラウザで試す」の図の後半で、表のうち2つを順に見られます。1秒に数千回読まれる人気のキーの TTL が切れて全員が同じ重い集計を DB に投げるキャッシュスタンピードと、SET NX でロックを取れた1つのリクエストだけに作り直させる対策、そして Redis そのものが止まって全部のリクエストが DB に向かうキャッシュ全損です。DB の負荷がどこで跳ね上がるかに注目してください。

キャッシュは、ブラウザ、CDN、リバースプロキシ、アプリ（Redisなど）、DBのバッファプールと、多くの層に置けます。それぞれの使い方は、HTTPキャッシュと多層キャッシュ、キャッシュ戦略の比較、キャッシュで速くするで解説しています。ここでは、どれを使うかを決めるための全体の考え方をまとめます。

5番目の「全部外れたら」に答えられないキャッシュは、障害の引き金になる。

非同期処理では、すぐには終わらない処理（メール送信・画像の変換・集計など）を「メッセージ」にしてメッセージブローカー（メッセージを預かって受け手に渡す仕組み）に預け、別の処理（受け手、コンシューマー）があとから取り出して処理します。リクエストを受けたアプリは、預けた時点で応答を返せます。

ブローカーには大きく2つの型があります。キュー型（Amazon SQS など）は、受け手が処理し終えたメッセージを消します。1つのメッセージは1つの受け手が処理するので、仕事を分け合うのに向きます。ログ型（Apache Kafka など）は、メッセージを読んでも消さずに、トピック（メッセージの種類ごとの置き場）に届いた順に溜めておきます（保持期間や容量の上限を過ぎると消えます）。受け手はそれぞれ「どこまで読んだか」の位置（オフセット）を持つので、複数の受け手が同じメッセージを別々に読んだり、過去の位置から読み直したりできます。トピックはパーティションに分けて並列に読み書きし、順番が保たれるのはパーティションの中だけです。Amazon Kinesis Data Streams も同じログ型で、パーティションにあたるものをシャードと呼びます。

サービスをまたぐ処理は、ロールバックの代わりに取り消し処理を流す。

「DBは更新したがイベントが飛ばなかった」を防ぐ定番の手法。

「マイクロサービスにすべきか」と聞かれたら、組織の規模とチーム構成、運用能力を前提に判断すると答えるのがよい。

• グレースフルシャットダウン：SIGTERM 受信後に新規受付を止め、処理中のリクエストを完了させる。K8s の preStop、LB の登録解除待ちと組み合わせる

• ヘルスチェックの設計：liveness（再起動すべきか）と readiness（トラフィックを受けられるか）を分ける。依存先DBの状態を liveness に含めると連鎖再起動を招く

• 設定と秘密情報：環境変数、Secrets Manager / Parameter Store。コードに埋め込まない

• フィーチャーフラグ：デプロイとリリースを分離し、問題時に即座に無効化できる

• N+1・重いクエリ：APMのトレースで発見し、開発チームと改善する流れを話せるとよい

第12章「パフォーマンスチューニング」：N+1問題の検知と直し方を図で詳しく

アプリは、言語のランタイム（Node.js、Python、Ruby、Javaなど）と多数のライブラリでできています。バージョンはセマンティックバージョニング（メジャー.マイナー.パッチ）で表すのが一般的で、メジャーが上がると互換性のない変更があり得ます。ロックファイル（package-lock.json、poetry.lock、Gemfile.lock、go.sumなど）で、実際に入る版を固定し、誰がいつビルドしても同じ結果になるようにします。

更新を長く放置すると、メジャーバージョンを何段も一度に上げることになり、影響が大きすぎて手が出せなくなります。その状態で重大な脆弱性が出ると、修正版に上げられず、回避策でしのぐしかなくなります。「小さく・頻繁に」が結果的に一番安全で安くつきます。

更新が止まっているリポジトリは、それ自体がリスクとして管理する。