Entry #01: 내 완벽한 API가 실제로 물에 빠지고 있었다
Source: Dev.to
Introduction
오랫동안 나는 API가 200 OK 상태 코드를 반환하면 백엔드 개발자로서의 내 작업은 끝났다고 믿어왔습니다. 하지만 이제는 도구와 라이브러리를 사용하는 것뿐만 아니라 그것이 어떻게 작동하는지도 이해해야 한다는 것을 깨달았습니다. 나는 최고라고 들어서 Postgres를 사용해왔지만, 왜 그런지 정말 몰랐습니다—지금은 알게 되었습니다.
고급 백엔드 아키텍처 탐구 여정의 Entry #01에 오신 것을 환영합니다.
The Life of a Query
나는 쿼리가 들어가면 데이터를 가지고 나오는 것이라고 생각했었습니다. 실제로 쿼리의 생명 주기는 매우 엄격합니다—릴레이 경주와 같습니다.
- Connection – Node.js 애플리케이션에 쿼리를 보내면 연결이 생성됩니다(현재는 안정성을 위해 커넥션 풀을 사용하고 있습니다).
- Backend process – 그 연결이 백엔드 프로세스를 스폰합니다.
- Postgres planning – Postgres가 정보를 어떻게 가져올지 결정합니다. 데이터를 빠르게 찾을 수 있으면 인덱스 스캔을 수행하고, 모든 데이터를 살펴봐야 하면 시퀀셜 스캔을 수행합니다. 선택은 전적으로 쿼리에 달려 있습니다.
내게 가장 놀라웠던 점은 Postgres가 매번 디스크에 접근하지 않는다는 것입니다. 대신 Shared Buffer라는 메모리를 사용합니다. 필요한 데이터가 이미 그 메모리에 있으면 응답이 빠릅니다. 없으면 Postgres가 디스크에서 읽고, 이후에 사용할 수 있도록 공유 버퍼에 캐시합니다.
What Happens When Things Go Wrong?
개발자들을 밤새 고민하게 만드는 몇 가지 시나리오를 살펴보고자 했습니다.
Scenario 1: The Morning Spike
Problem: PayWave에서 /wallet/balance 엔드포인트가 아침 러시 동안 50 ms에서 500 ms로 급증했습니다.
Solution:
- 서버를 재시작하는 대신 dead tuples를 검사하세요. 진공 작업이 이루어지지 않은 오래된 튜플이 많으면 데이터베이스가 크게 느려질 수 있습니다.
- 쿼리가 실제로 만든 인덱스를 사용하고 있는지 확인하세요.
Scenario 2: The Growing Table
Problem: ShopSphere에서 orders 테이블이 일주일 만에 2 GB에서 6 GB로 성장했지만 매출은 3배가 되지 않았습니다.
Solution:
- 테이블 크기의 급격한 증가는 **bloat(팽창)**를 의미하는 경우가 많습니다.
autovacuum을 활성화했더라도 변경량을 따라가지 못할 수 있습니다.autovacuum_vacuum_cost_limit값을 검토하여 자동 진공 프로세스가 과도하게 제한되고 있는지 확인하세요.
Scenario 3: The Mid‑Transaction Crash
Problem: CryptoBank에서 분기별 DR 테스트 중에 기본 노드가 트랜잭션 도중에 충돌하도록 시뮬레이션했습니다.
Solution:
- **Write‑Ahead Logging (WAL)**이 이 경우를 처리합니다. 충돌 후 WAL 파일을 재생하여 시스템을 일관된 상태로 복구하고, 마지막 몇 초의 트랜잭션을 보존합니다.
My Key Takeaways
- 인덱싱은 속도를 높이는 가장 좋은 친구입니다.
- **팽창(bloat)**은 조용히 파괴하는 요인입니다; dead tuple을 정기적으로 모니터링하세요.
- 커넥션 풀을 사용하면 백엔드 프로세스를 관리해 “Too Many Connections” 오류를 방지할 수 있습니다.
나는 단순히 코딩하는 것에서 내 코드를 실행하는 환경을 배우는 쪽으로 초점을 옮기고 있습니다. Postgres 성능 튜닝에 관한 질문이나 시나리오가 있다면 댓글로 자유롭게 공유해 주세요.
다음 Entry #02에서 뵙겠습니다.