Aurora Capacity Unit(ACU)이 계속해서 Spike를 쳐 순식간에 24ACU를 찍고 내려오는 상황이 반복되었습니다. 1 ACU는 약 2GB의 메모리를 의미합니다. 데이터베이스가 계속해서 24 ACU를 요동친다는 것은 48GB 이상의 메모리 자원을 쏟아붓고 있다는 의미입니다.
이 상황의 중심에는 비효율적인 쿼리가 있었습니다. 해당 비효율적인 쿼리 문제의 핵심 원인은 9단계에 걸친 중첩 JOIN과 메모리를 고갈시키는 거대한 GROUP BY가 결합된 해서는 안되는 안티패턴이었습니다.
시스템을 마비시킨 두 가지 안티패턴
첫 번째는 데이터의 '양'을 두 번째는 데이터의 '무게'를 감당 불가능하게 만들었습니다.
1-1. 첫 번째 안티패턴 분석 - 과도한 JOIN과 카디널리티 폭증
문제의 쿼리는 9개 이상의 테이블을 'Nested Loop Join' 방식으로 연결하고 있었습니다. 이는 데이터베이스 엔진 입장에서 최악의 시나리오 중 하나입니다.
Nested Loop Join(NLJ) 방식은 Driving Table의 각 데이터를 순회할 때마다 Driven Table 전체를 반복해서 스캔합니다.
가장 큰 문제는 이 과정이 무려 9단계로 중첩(9-depth) 되었다는 점입니다. 드라이빙 테이블의 행 하나당 매번 새로운 테이블을 풀 스캔해야 하므로, 데이터베이스가 계산해야 할 경우의 수(Cardinality)가 기하급수적으로 폭증하게 됩니다.
데이터베이스 옵티마이저(Optimizer)는 적절한 커버링 인덱스가 없거나 통계 정보가 부정확할 때 이런 비효율적인 실행 계획을 선택해 버립니다. 대량의 데이터 처리에는 해시 조인(Hash Join)이나 소트 머지 조인(Sort Merge Join) 같은 더 효율적인 방식이 있음에도 불구하고, 최악의 시간 복잡도일 수 있는 N의 9제곱을 하게 만든 것입니다.
결과적으로 인덱스를 타지 못하고 눈덩이처럼 불어난 이 거대한 연산은 AWS Aurora DB 엔진이 감당할 수 있는 임계치를 넘어섰고, 결국 ACU를 한계치까지 폭증시킨 첫 번째 원인이 되었습니다.
1-2. 두 번째 안티패턴 분석 - 무거운 GROUP BY와 블로킹 연산
과도한 JOIN이 처리해야 할 중간 데이터의 '양'을 늘렸다면, 거대한 GROUP BY는 그 데이터 하나하나의 '무게'를 감당 불가능한 수준으로 만들었습니다.
데이터베이스는 GROUP BY 연산을 위해 지정된 컬럼들을 기준으로 데이터를 정렬하거나 해시 테이블을 생성합니다. 이때 실행 계획에서 발견된 width=398이라는 수치가 나오게 됩니다. 이는 정렬 대상이 되는 행 하나의 평균 크기가 398바이트에 달한다는 의미입니다.
Sort (cost=1600.61..1600.95 rows=134 width=398)
Sort Key: chain.depth, c.id, cr.id, tk.address, ... (엄청나게 긴 키)
Sort Method: quicksort Memory: 25kB간단히 비교해 보겠습니다.
- 일반적인 ID 정렬: 보통 8바이트 크기의 ID값 100만 개를 정렬하는 데는 약 8MB의 메모리면 충분합니다.
- 문제의 쿼리: 행 하나가 398바이트라면, 단 10만 개의 행을 정렬하는 데 약 40MB에 육박하는 메모리가 필요합니다.
문제는 PostgreSQL이 단일 쿼리의 정렬 작업에 허용하는 기본 메모리 임계치(work_mem)가 보통 4MB에 불과하다는 점입니다. 이처럼 무거운 데이터를 정렬하려는 시도는 곧바로 허용된 RAM 용량을 초과해 버립니다.
이 두 가지 안티패턴(과도한 JOIN과 무거운 GROUP BY)이 결합하여 PostgreSQL 내부에서 어떤 연쇄 작용을 일으켰는지 아래에서 설명해 드리겠습니다.
개선 전 쿼리의 실행 계획
GroupAggregate (cost=2456.56..2463.93 rows=134 width=492) (actual time=0.082..0.085 rows=0 loops=1)
Output: c.id, c.value, c."prevId", c."parentId", c."createdAt", c."updatedAt", c."imageSrc", c."jsonValue", COALESCE(jsonb_agg(DISTINCT (jsonb_build_object('user', jsonb_build_object('id', ru.id, 'userName', ru."userName")))) FILTER (WHERE (ru.id IS NOT NULL)), '[]'::jsonb), jsonb_build_object('id', cr.id, 'profileImageUrl', cr."profileImageUrl", 'userName', cr."userName", 'userNameTag', cr."userNameTag", 'displayName', cr."displayName", 'userType', cr."userType", 'isPreOrdered', cr."isPreOrdered", 'Token', jsonb_build_object('address', tk.address, 'isCexListed', tk."isCexListed")), COALESCE(jsonb_agg(DISTINCT jsonb_build_object('text', ht.text)) FILTER (WHERE (ht.text IS NOT NULL)), '[]'::jsonb), jsonb_build_object('RePost', count(DISTINCT rp.id), 'Like', count(DISTINCT l.id), 'children', count(DISTINCT ch.id)), chain.depth, cr.id, cr."profileImageUrl", cr."userName", cr."userNameTag", cr."displayName", cr."userType", cr."isPreOrdered", tk.address, tk."isCexListed"
Group Key: chain.depth, c.id, cr.id, tk.address
Buffers: shared hit=16
CTE chain
-> Recursive Union (cost=0.42..855.95 rows=101 width=12) (actual time=0.008..0.015 rows=1 loops=1)
Buffers: shared hit=4
-> Index Scan using "Content_id_duplicateCheck_contentsType_isBlocked_value_idx" on public."Content" c_1 (cost=0.42..8.44 rows=1 width=12) (actual time=0.007..0.007 rows=1 loops=1)
Output: c_1.id, c_1."prevId", 0
Index Cond: (c_1.id = 317282)
Buffers: shared hit=4
-> Nested Loop (cost=0.42..84.65 rows=10 width=12) (actual time=0.006..0.006 rows=0 loops=1)
Output: p.id, p."prevId", (chain_1.depth + 1)
Inner Unique: true
-> WorkTable Scan on chain chain_1 (cost=0.00..0.20 rows=10 width=8) (actual time=0.001..0.001 rows=1 loops=1)
Output: chain_1.id, chain_1."prevId", chain_1.depth
-> Index Scan using "Content_pkey" on public."Content" p (cost=0.42..8.44 rows=1 width=8) (actual time=0.005..0.005 rows=0 loops=1)
Output: p.id, p."prevId"
Index Cond: (p.id = chain_1."prevId")
Filter: (NOT p."isBlocked")
-> Sort (cost=1600.61..1600.95 rows=134 width=398) (actual time=0.081..0.083 rows=0 loops=1)
Output: c.id, chain.depth, cr.id, tk.address, c.value, c."prevId", c."parentId", c."createdAt", c."updatedAt", c."imageSrc", c."jsonValue", ru.id, ru."userName", cr."profileImageUrl", cr."userName", cr."userNameTag", cr."displayName", cr."userType", cr."isPreOrdered", tk."isCexListed", ht.text, rp.id, l.id, ch.id, (jsonb_build_object('user', jsonb_build_object('id', ru.id, 'userName', ru."userName")))
Sort Key: chain.depth, c.id, cr.id, tk.address, (jsonb_build_object('user', jsonb_build_object('id', ru.id, 'userName', ru."userName")))
Sort Method: quicksort Memory: 25kB
Buffers: shared hit=16
-> Nested Loop Left Join (cost=3.41..1595.88 rows=134 width=398) (actual time=0.040..0.042 rows=0 loops=1)
Output: c.id, chain.depth, cr.id, tk.address, c.value, c."prevId", c."parentId", c."createdAt", c."updatedAt", c."imageSrc", c."jsonValue", ru.id, ru."userName", cr."profileImageUrl", cr."userName", cr."userNameTag", cr."displayName", cr."userType", cr."isPreOrdered", tk."isCexListed", ht.text, rp.id, l.id, ch.id, jsonb_build_object('user', jsonb_build_object('id', ru.id, 'userName', ru."userName"))
Buffers: shared hit=8
-> Nested Loop Left Join (cost=2.98..1362.39 rows=134 width=394) (actual time=0.040..0.041 rows=0 loops=1)
Output: chain.depth, c.id, c.value, c."prevId", c."parentId", c."createdAt", c."updatedAt", c."imageSrc", c."jsonValue", rp.id, ru.id, ru."userName", cr.id, cr."profileImageUrl", cr."userName", cr."userNameTag", cr."displayName", cr."userType", cr."isPreOrdered", tk.address, tk."isCexListed", l.id, ht.text
Inner Unique: true
Buffers: shared hit=8
-> Nested Loop Left Join (cost=2.70..1321.18 rows=134 width=389) (actual time=0.040..0.041 rows=0 loops=1)
Output: chain.depth, c.id, c.value, c."prevId", c."parentId", c."createdAt", c."updatedAt", c."imageSrc", c."jsonValue", rp.id, ru.id, ru."userName", cr.id, cr."profileImageUrl", cr."userName", cr."userNameTag", cr."displayName", cr."userType", cr."isPreOrdered", tk.address, tk."isCexListed", l.id, ct."hashTagId"
Buffers: shared hit=8
-> Nested Loop Left Join (cost=2.28..1221.64 rows=97 width=385) (actual time=0.039..0.040 rows=0 loops=1)
Output: chain.depth, c.id, c.value, c."prevId", c."parentId", c."createdAt", c."updatedAt", c."imageSrc", c."jsonValue", rp.id, ru.id, ru."userName", cr.id, cr."profileImageUrl", cr."userName", cr."userNameTag", cr."displayName", cr."userType", cr."isPreOrdered", tk.address, tk."isCexListed", ct."hashTagId"
Buffers: shared hit=8
-> Nested Loop Left Join (cost=1.99..1188.59 rows=97 width=381) (actual time=0.039..0.040 rows=0 loops=1)
Output: chain.depth, c.id, c.value, c."prevId", c."parentId", c."createdAt", c."updatedAt", c."imageSrc", c."jsonValue", rp.id, ru.id, ru."userName", cr.id, cr."profileImageUrl", cr."userName", cr."userNameTag", cr."displayName", cr."userType", cr."isPreOrdered", tk.address, tk."isCexListed"
Inner Unique: true
Buffers: shared hit=8
-> Nested Loop Left Join (cost=1.57..1134.65 rows=97 width=337) (actual time=0.039..0.040 rows=0 loops=1)
Output: chain.depth, c.id, c.value, c."prevId", c."parentId", c."createdAt", c."updatedAt", c."imageSrc", c."jsonValue", rp.id, ru.id, ru."userName", cr.id, cr."profileImageUrl", cr."userName", cr."userNameTag", cr."displayName", cr."userType", cr."isPreOrdered"
Inner Unique: true
Buffers: shared hit=8
-> Nested Loop Left Join (cost=1.14..1070.61 rows=97 width=227) (actual time=0.039..0.039 rows=0 loops=1)
Output: chain.depth, c.id, c.value, c."prevId", c."parentId", c."createdAt", c."updatedAt", c."imageSrc", c."jsonValue", c."creatorId", rp.id, ru.id, ru."userName"
Inner Unique: true
Buffers: shared hit=8
-> Nested Loop Left Join (cost=0.72..890.86 rows=97 width=218) (actual time=0.039..0.039 rows=0 loops=1)
Output: chain.depth, c.id, c.value, c."prevId", c."parentId", c."createdAt", c."updatedAt", c."imageSrc", c."jsonValue", c."creatorId", rp.id, rp."reposterId"
Buffers: shared hit=8
-> Nested Loop (cost=0.42..850.97 rows=97 width=210) (actual time=0.038..0.039 rows=0 loops=1)
Output: chain.depth, c.id, c.value, c."prevId", c."parentId", c."createdAt", c."updatedAt", c."imageSrc", c."jsonValue", c."creatorId"
Inner Unique: true
Buffers: shared hit=8
-> CTE Scan on chain (cost=0.00..2.02 rows=101 width=8) (actual time=0.009..0.016 rows=1 loops=1)
Output: chain.id, chain."prevId", chain.depth
Buffers: shared hit=4
-> Index Scan using "Content_pkey" on public."Content" c (cost=0.42..8.41 rows=1 width=206) (actual time=0.021..0.021 rows=0 loops=1)
Output: c.id, c.value, c."prevId", c."parentId", c."createdAt", c."updatedAt", c."imageSrc", c."jsonValue", c."creatorId"
Index Cond: (c.id = chain.id)
Filter: ((NOT c."isBlocked") AND (c.id <> 317282))
Rows Removed by Filter: 1
Buffers: shared hit=4
-> Index Scan using "RePost_contentId_idx" on public."RePost" rp (cost=0.29..0.37 rows=4 width=12) (never executed)
Output: rp.id, rp."contentId", rp."reposterId", rp."createdAt", rp."updatedAt"
Index Cond: (rp."contentId" = c.id)
-> Index Scan using "Users_pkey" on public."Users" ru (cost=0.42..1.85 rows=1 width=13) (never executed)
Output: ru.id, ru."userName"
Index Cond: (ru.id = rp."reposterId")
-> Index Scan using "Users_pkey" on public."Users" cr (cost=0.42..0.66 rows=1 width=114) (never executed)
Output: cr.id, cr."profileImageUrl", cr."userName", cr."userNameTag", cr."displayName", cr."userType", cr."isPreOrdered"
Index Cond: (cr.id = c."creatorId")
-> Index Scan using "Token_creatorId_key" on public."Token" tk (cost=0.42..0.56 rows=1 width=48) (never executed)
Output: tk.address, tk."isCexListed", tk."creatorId"
Index Cond: (tk."creatorId" = cr.id)
-> Index Scan using "contentId_idx" on public."ContentTags" ct (cost=0.29..0.32 rows=2 width=8) (never executed)
Output: ct.id, ct."hashTagId", ct."contentId"
Index Cond: (ct."contentId" = c.id)
-> Index Scan using "Like_contentsId_idx" on public."Like" l (cost=0.42..0.84 rows=19 width=8) (never executed)
Output: l.id, l."userId", l."contentsId", l."createdAt", l."updatedAt"
Index Cond: (l."contentsId" = c.id)
-> Index Scan using "HashTags_pkey" on public."HashTags" ht (cost=0.28..0.31 rows=1 width=13) (never executed)
Output: ht.id, ht.text, ht.activate, ht."createdAt", ht."updatedAt", ht.count
Index Cond: (ht.id = ct."hashTagId")
-> Index Scan using content_parent_idx on public."Content" ch (cost=0.42..1.67 rows=7 width=8) (never executed)
Output: ch.id, ch."parentId"
Index Cond: (ch."parentId" = c.id)
Filter: ((NOT ch."isBlocked") AND (ch."contentsType" = 'REPLY'::"ContentType"))
Query Identifier: -575830414252295307
Planning:
Buffers: shared hit=728 read=10
I/O Timings: shared read=9.769
Planning Time: 15.786 ms
Execution Time: 0.357 ms메모리와 디스크 사이의 병목 현상
안티패턴들이 어떻게 PostgreSQL 내부의 메모리 관리 및 연산 처리 메커니즘과 상호작용하며 시스템 전체를 병목 상태로 몰아넣었는지, 그 원리를 자세히 분석해 보겠습니다. 문제는 메모리와 디스크 사이에서 벌어지고 있었습니다.
1-1. 메모리 병목 분석: Shared Buffers 그리고 Buffer Cache Thrashing
PostgreSQL은 디스크의 데이터를 8KB 페이지 단위로 'Shared Buffers'라는 공유 메모리 공간에 올려두고 처리합니다. 효율적인 데이터 처리를 위해서는 필요한 데이터 페이지가 이 메모리 공간에 존재해야 합니다. Cache Hit의 목적입니다.
하지만 9단계 JOIN으로 인한 무작위적인 랜덤 액세스는 'Buffer Cache Thrashing' 현상을 유발했습니다.
- 특정 JOIN 연산에 필요한 데이터 페이지를 메모리에 로드합니다.
- 하지만 곧바로 다음 단계의 JOIN을 위해 새로운 데이터 페이지가 필요해집니다.
- 새로운 페이지를 위한 공간을 확보하기 위해, 방금 올렸던 데이터 페이지가 메모리에서 방출(evict)됩니다.
이 과정이 반복되면서 캐시 히트율(Cache Hit Ratio)은 바닥을 쳤고, 데이터베이스는 거의 모든 데이터를 훨씬 느린 Disk I/O를 통해 읽어야만 했습니다. ACU를 24까지 늘려 48GB 이상의 메모리를 확보했음에도 성능이 나아지지 않은 이유는 바로 이 비효율적인 데이터 접근 패턴 때문이었습니다. 값비싼 메모리 자원은 제대로 활용되지 못한 채 낭비되고 있었습니다.
1-2. 연산 병목 분석: work_mem 초과와 블로킹 오퍼레이터(Blocking Operator)
GROUP BY와 같은 정렬 연산을 위해 PostgreSQL은 work_mem(4MB)이라는 별도의 전용 메모리 공간을 사용합니다. 문제는 처리할 데이터의 크기가 이 work_mem 공간을 단 1바이트라도 초과하는 순간 발생합니다. 데이터베이스는 'Disk Sort(External Merge Sort)'라는 최후의 수단을 사용하게 됩니다.
- 쓰기 단계: 메모리에 다 담지 못하는 거대한 데이터를 여러 조각으로 나누어 디스크의 임시 파일에 씁니다.
- 병합 단계: 디스크에 저장했던 조각들을 다시 읽어와 병합하며 최종 정렬 결과를 만듭니다.
이 과정에서 발생하는 디스크 I/O는 메모리 연산보다 수백 배 이상 느립니다. 더 치명적인 것은 Sort 연산이 대표적인 '블로킹 오퍼레이터(Blocking Operator)'라는 점입니다.
블로킹 오퍼레이터란? 데이터베이스 연산은 보통 파이프라인(Streaming)처럼 앞 단계의 결과가 나오면 바로 다음 단계로 흘려보냅니다. 하지만 정렬과 같은 블로킹 오퍼레이터는 모든 입력 데이터가 도착할 때까지 다음 단계로 단 한 줄의 결과도 전달하지 않고 작업을 막아버립니다.
이로 인해 전체 쿼리 실행 파이프라인이 정지되고, CPU는 연산을 하고 싶어도 디스크에서 데이터가 정렬되어 올라오기만을 하염없이 기다리는 'I/O Wait' 상태에 빠집니다. 수십만 개의 중간 데이터를 398바이트라는 무거운 행으로 정렬하려던 시도가 결국 시스템 전체의 병목을 유발했습니다.
이처럼 데이터베이스 내부에서 발생하는 근본적인 병목을 이해하고, 이를 해결하기 위해 아래 해결 전략에서 설명하겠습니다.
해결 전략: 데이터 처리 전환
문제의 본질을 해결하기 위해 단순히 SQL 구문을 수정하는 것을 넘어, 데이터 로딩과 처리 방식의 근본을 바꾸었습니다. '모든 것을 한 번에' 처리하려던 방식에서 '필요한 것만, 필요한 시점에' 처리하는 방식으로 변경했습니다.
1-1. JOIN을 서브쿼리로 - '즉시 로딩'에서 '지연 로딩'으로
기존 쿼리는 필요한 모든 데이터를 한꺼번에 JOIN해서 가져오는 '즉시 로딩(Eager Loading)' 방식이었습니다. 이를 최종적으로 필요한 데이터의 범위를 먼저 확정한 뒤, 그 범위 내에서만 추가 정보를 조회하는 '지연 로딩(Lazy Loading)' 방식으로 전환했습니다.
CTE(Common Table Expression)와 스칼라 서브쿼리를 활용해 필요한 데이터의 범위를 먼저 좁히고, 그 결과에 대해서만 선택적으로 추가 데이터를 조회하도록 구조를 변경했습니다.
/* 개선 후: CTE와 서브쿼리를 조합한 전략적 선택 */
WITH filtered_content AS (
-- [1] Early Filtering: 최소한의 ID 목록(Driving Table)을 먼저 확정
SELECT * FROM content
WHERE status = 'PUBLISHED'
ORDER BY created_at DESC
LIMIT 10 -- 페이징 적용
)
SELECT
content.*,
-- [2] 지연 로딩: 확정된 10건에 대해서만 관련 데이터 조회
(SELECT ROW(u.id, u.name) FROM users u WHERE u.id = content.user_id) AS creator,
(SELECT COUNT(*) FROM likes l WHERE l.content_id = content.id) AS like_count
FROM filtered_content AS content;
이 방식이 압도적으로 빠른 이유는 '실체화(Materialization)' 비용을 원천적으로 제거했기 때문입니다.
• 기존 JOIN 방식 (Late Filtering): 최종 결과가 단 10개뿐이라도, JOIN 과정에서 수십만 개 행으로 이루어진 거대한 '중간 결과 집합'을 메모리에 생성합니다. 이 과정에서 버퍼 캐시 스레싱과 메모리 고갈이 발생합니다.
• 개선된 CTE 방식 (Early Filtering): 먼저 LIMIT 10을 통해 필요한 10개의 ID를 확정합니다. 그 후, 딱 그 10개에 대해서만 서브쿼리를 실행하여 추가 정보를 조회합니다. 수십만 건을 처리할 필요가 사라진 것입니다.
이 전략의 효율성은 PostgreSQL 실행 계획(EXPLAIN)의 한 줄로 증명되었습니다.
SubPlan ... (never executed)이 문구는 메인 쿼리에서 필터링된 결과가 없으면, 연결된 서브쿼리는 단 한 번도 실행조차 되지 않았음을 의미합니다. 조건에 맞지 않는 수많은 데이터에 대해 CPU와 메모리 자원을 전혀 낭비하지 않아 연산 비용을 원천적으로 '0'으로 만든 것입니다.
1-2. 전략 : GROUP BY 제거 - 'Index Only Scan'
집계 연산을 서브쿼리로 분리하면서 메인 쿼리에서 GROUP BY 절을 완전히 제거할 수 있었습니다. 이를 통해 ACU Spike의 주범이었던 Disk Sort의 원인을 근본적으로 차단했습니다. 그리고 이는 데이터베이스가 사용할 수 있는 가장 이상적인 실행 계획으로 이어졌습니다.
인덱스만으로 끝내는 'Index Only Scan' 입니다. 최적화된 쿼리의 실행 계획에서는 다음과 같은 이상적인 지표가 포착되었습니다.
Index Only Scan using idx_content_composite ... > Heap Fetches: 0이는 커버링 인덱스(Covering Index)를 의미합니다.
- Index Only Scan: 쿼리 처리에 필요한 모든 컬럼이 인덱스에 포함되어 있어, 실제 테이블 데이터(Heap)를 조회하지 않고 인덱스만으로 모든 연산을 끝냈다는 뜻입니다.
- Heap Fetches: 0: 실제 테이블 접근이 단 한 번도 발생하지 않았음을 나타내는 명확한 증거입니다.
이것은 9단계 JOIN이 유발했던 '버퍼 캐시 스레싱'의 근본 해결책이기도 합니다. 더 이상 여러 테이블의 데이터 페이지를 메모리에 올렸다 내리며 Disk I/O를 유발할 필요 없이, 오직 하나의 작고 효율적인 인덱스 구조 안에서 모든 작업이 완료되기 때문입니다.
1-3. 'Heap Fetches: 0'을 가능하게 한 Visibility Map
여기서 한 걸음 더 나아가, Heap Fetches: 0이 가능했던 더 깊은 이유를 살펴보겠습니다. PostgreSQL은 MVCC(다중 버전 동시성 제어) 환경이므로, 인덱스에 데이터가 있더라도 "이 데이터가 현재 트랜잭션에서 보이는가?"를 확인하기 위해 보통 원본 테이블(Heap)을 다시 확인합니다.
하지만 이번 사례에서는 PostgreSQL의 '가시성 맵(Visibility Map)' 덕분에 이 과정마저 생략할 수 있었습니다. 가시성 맵은 특정 데이터 페이지의 모든 행이 모든 트랜잭션에게 보인다는 사실을 미리 기록해 둡니다. 인덱스 스캔 시 이 가시성 맵 비트가 설정되어 있다면, PostgreSQL은 "굳이 테이블을 다시 확인하지 않아도 이 데이터는 안전하다"고 판단하여 힙 접근을 완전히 생략합니다.
그 결과, 디스크 I/O가 줄어든 것입니다. 가시성 맵은, 불필요한 I/O를 한 번이라도 더 줄이려는 데이터베이스의 정교한 최적화 장치이며, 이는 대규모 JOIN과 정렬로 인해 I/O Wait에 빠졌던 기존 쿼리의 상황과 극명한 결과 차이를 보여줍니다.
결과 및 영향
쿼리 최적화라는 기술적 성공은 시스템 안정성, 비용, 사용자 경험 측면에서 즉각적이고 측정 가능한 비즈니스 가치로 이어졌습니다.
가장 핵심적인 성과는 ACU MAX가 24에서 4로 83% 감소했다는 점입니다.
- 시스템 안정성: 동일한 자원으로 이전보다 훨씬 많은 트래픽을 안정적으로 감당할 수 있는 견고한 체력을 확보했습니다. 예기치 않은 트래픽에도 시스템이 마비될 것이라는 불안감에서 벗어날 수 있었습니다.
- 비즈니스 가치: 장애 대응을 위해 불필요하게 인프라를 확장하는 데 드는 막대한 비용을 획기적으로 절감했습니다. 자원을 효율적으로 사용하여 기술 부채를 줄이고 경제적 이익을 창출했습니다.
- 사용자 경험: 서비스 응답 불능 상태에서 밀리초(ms) 단위의 쾌적한 응답 속도로 전환되었습니다. 이는 직접적으로 사용자 만족도 향상과 이탈률 감소로 이어졌습니다.
결론적으로, 인프라 사양 증설만으로는 해결되지 않던 근본적인 문제가 데이터베이스의 내부 메커니즘에 대한 깊은 이해를 통해 해결되었습니다.
하지만, 시스템이 안정화된 후 우리는 근본적인 질문을 던져야 했습니다. "왜 애초에 9단계 JOIN이 필요했을까?" 이번 장애의 진정한 원인은 단순한 SQL 작성 실수가 아니라, 데이터 모델링 단계에서의 '반정규화(Denormalization)'에 대한 고려가 없었기 때문입니다. 엄격한 정규화 원칙에만 얽매여 읽기 성능을 위한 모델을 분리하지 않았고, 그 결과 런타임에 모든 릴레이션을 엮어야 하는 아키텍처의 기술 부채가 버퍼 캐시 스레싱과 ACU 24 폭주라는 장애로 발현된 것입니다. 향후 유사한 도메인에서는 철저한 읽기/쓰기 모델 분리(CQRS)와 통계 데이터의 비정규화를 아키텍처 초기 단계부터 반영해야 함을 배웠습니다.
'Project > 기록' 카테고리의 다른 글
| 10분마다 치는 spike 평탄화 작업기(feat. ACU 45% 절감) (0) | 2026.02.08 |
|---|---|
| CS 이론으로 풀어낸 EKS 소켓 서버 최적화: DNS, 커널, 그리고 오토스케일링의 함정 (0) | 2026.02.01 |
| Log 영속성을 위한 MQ 도입 (1) | 2025.06.10 |
| MySQL에서의 Lock 경합 문제 해결과 성능 개선 (2) | 2025.06.09 |
| Bullmq Document + CS 관점으로 다시 생각 (1) | 2025.06.05 |
