Spring Boot アプリのパフォーマンスをどうチューニングするのか: pool、caching、N+1?

Question

IT Interview Practice · Accepted Answer

Spring Boot のパフォーマンスチューニングは、ほとんどがデータベースの境界に関するものです: コネクションプーリング、キャッシュ、そして N+1 クエリ問題の撲滅です。まず計測し (Micrometer + Actuator メトリクス)、それから最大のコストを攻めます。 ## N+1 問題 — JPA の最大の殺し屋遅延関連は親ごとに 1 クエリ、そして子アクセスごとにさらに *もう* 1 クエリを発行します: ```java List orders = orderRepo.findAll(); // 1 query for (Order o : orders) { o.getItems().size(); // N extra queries — one PER order (the "N+1") } ``` 単一の join で関連を取得して修正します: ```java @Query("SELECT o FROM Order o JOIN FETCH o.items") // one query, items eagerly loaded List findAllWithItems(); // Or @EntityGraph(attributePaths = "items") on the repository method. ``` ## コネクションプールのサイジング HikariCP がデフォルトのプールです。大きいほど良い、では **ありません** — 接続が多すぎると DB を痛めつけます。よくある式は `cores * 2` あたりから始めます: ```yaml spring: datasource: hikari: maximum-pool-size: 10 # match DB capacity, not thread count connection-timeout: 3000 # fail fast instead of piling up requests ``` ## ホットな読み取りのキャッシュ ```java @Cacheable(value = "products", key = "#id") // serve from cache after first load public Product findById(Long id) { return repo.findById(id).orElseThrow(); } @CacheEvict(value = "products", key = "#p.id") // invalidate on write public Product update(Product p) { return repo.save(p); } ``` インスタンス間で共有するキャッシュには Redis (`spring-boot-starter-data-redis`) で裏打ちします。 ## なぜ重要なのかシニアの面接は、最適化する前に診断するかを試します。最も強い答えは、ボトルネックを *証明する* ツールを挙げ (`spring.jpa.show-sql` または datasource-proxy を有効にしてクエリを数える、Actuator から p99 レイテンシを読む)、*なぜ* 過大なプールが害になるかを説明し、キャッシュを単なる速度のつまみではなく正しさの問題 — 古いデータと無効化 — として扱います。

N+1 問題 — JPA の最大の殺し屋

コネクションプールのサイジング

ホットな読み取りのキャッシュ

なぜ重要なのか

関連する質問