동블

그래프 뷰

04. 백엔드 운영 체크포인트 상세

8 min read

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

  • 백엔드 개발자는 DB 운영에서 어떤 기본 체크포인트를 가져야 하는가?
  • 개인 프로젝트를 운영 가능한 수준으로 보이게 하려면 무엇을 챙겨야 하는가?
  • 인프라/DBA와 대화할 때 어떤 지표를 알아야 하는가?

개요

DB 운영은 DBA만의 일이 아니다. 백엔드 개발자는 DB를 사용하는 코드를 만들고, 그 코드가 운영 지표를 바꾼다. 최소한의 운영 체크포인트를 알고 있어야 장애를 줄이고 협업이 빨라진다.

운영 감각은 대형 회사에서만 필요한 것이 아니다. 개인 프로젝트에서도 장애를 재현하고 복구할 수 있는 구조를 만들면 결과물의 수준이 달라진다.

원리

DB 운영 체크포인트의 목적은 장애 중에 처음 보는 지표를 줄이는 것이다. 백엔드 개발자는 DB 서버를 직접 운영하지 않더라도, 자신의 코드가 connection, query time, lock, WAL/binlog, replica lag, disk usage를 어떻게 바꾸는지 알아야 한다.

운영 지표는 책임 떠넘기기용 숫자가 아니라 대화의 공통 언어다. 백엔드가 endpoint, SQL, 배포 시각, batch 실행 여부를 제공하고, 인프라/DBA가 wait event, lock, I/O, replication 상태를 제공할 때 원인 분석이 빨라진다.

기본 체크포인트

백엔드 개발자가 알아야 할 DB 운영 지표는 다음이다.

  • slow query
  • active connection
  • connection pool active/idle/pending
  • lock wait
  • deadlock count
  • DB CPU/I/O
  • replica lag
  • backup status
  • migration history
  • disk usage
  • query timeout과 error rate
  • top query by total time/calls
  • long transaction과 idle in transaction

모든 지표를 직접 운영하지 않아도, 문제 상황에서 어떤 지표를 요청해야 하는지는 알아야 한다.

PostgreSQL에서 긴 트랜잭션이나 대기 상태를 확인할 때는 다음 쿼리가 출발점이 된다.

SELECT pid,
       state,
       now() - xact_start AS tx_age,
       wait_event_type,
       wait_event,
       left(query, 200) AS query_sample
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY tx_age DESC NULLS LAST;

MySQL 계열에서는 Performance Schema, slow query log, SHOW PROCESSLIST로 같은 질문을 한다. “어떤 세션이 오래 열려 있는가”, “무엇을 기다리는가”, “어떤 SQL fingerprint가 시간을 가장 많이 쓰는가”를 보는 것이 핵심이다.

개인 프로젝트 기준

개인 프로젝트에서 최소한 챙길 것:

  • migration 도구 사용
  • 주요 테이블 PK/FK/Unique 제약
  • 핵심 목록 API 인덱스
  • 커넥션 풀과 timeout 명시
  • 정기 백업 또는 dump 방법
  • 운영 DB 직접 쿼리 주의사항
  • README에 DB 설계 의도 기록

예를 들어 README에 이런 설명이 있으면 좋다.

게시글 목록은 board_id + created_at desc + id desc cursor pagination으로 구성했다.
이를 위해 posts(board_id, created_at desc, id desc) 인덱스를 둔다.
좋아요 중복은 post_likes(post_id, member_id) PK로 막는다.

기업 운영 기준

기업 환경에서는 다음까지 본다.

  • 배포 전후 slow query 변화
  • migration lock 영향
  • replica lag와 read/write split
  • RTO/RPO와 복구 리허설
  • pool 총량과 DB max connections
  • batch와 API 리소스 분리
  • 장애 회고와 재발 방지 알림

백엔드 개발자는 인프라/DBA에게 SQL과 코드 맥락을 제공하고, DBA는 DB 내부 지표와 운영 제약을 제공한다.

장애 공유 메시지는 다음처럼 구체적일수록 좋다.

14:05 배포 이후 GET /orders/{id}/items p99가 250ms에서 2.8s로 증가했습니다.
Hikari pending이 0에서 35까지 올랐고, slow query는 order_items by order_id 조회에 집중됩니다.
오늘 추가한 fetch join 변경이 있으며, batch 작업은 없습니다.
실제 SQL과 trace id 샘플을 첨부합니다.

이 정도 정보가 있으면 인프라/DBA는 DB 내부 wait, lock, plan 변화와 빠르게 대조할 수 있다.

실전 팁

  • DB 관련 장애는 endpoint, SQL, 지표를 한 세트로 기록한다.
  • 운영 쿼리는 항상 대상 건수와 rollback 가능성을 확인한다.
  • migration은 배포 계획과 함께 검토한다.
  • pool size 변경은 인스턴스 수와 DB max connections를 함께 계산한다.
  • 개인 프로젝트에서도 백업 복구를 한 번은 실제로 해본다.
  • dashboard에는 평균보다 p95/p99, pool pending, error rate, slow query 추세를 우선 둔다.
  • 장애 전파를 막기 위해 feature flag, batch stop switch, read-only fallback 같은 운영 스위치를 준비한다.

위험 신호!

  • 운영 DB 백업 상태를 모른다.
  • migration 파일 없이 수동으로 테이블을 바꾼다.
  • slow query를 볼 방법이 없다.
  • connection timeout이 나도 pool 지표가 없다.
  • 인프라/DBA에게 실제 SQL 없이 장애를 전달한다.
  • 운영 장애 중에 처음으로 slow query log, Performance Schema, pg_stat_activity를 찾아본다.
  • migration 성공 여부만 보고 lock 대기, replica lag, long transaction 영향을 보지 않는다.

확인 질문

  • 백엔드 개발자가 DB 운영 지표를 알아야 하는 이유는 무엇인가?
    • 자신이 작성한 SQL과 트랜잭션이 DB 부하와 장애 지표를 만들기 때문에 원인 분석과 협업에 필요하다.
  • 개인 프로젝트에서 운영 가능한 DB 설계로 보이게 하는 기준은 무엇인가?
    • migration, 제약, 인덱스, timeout, 백업, 설계 의도 문서화가 있어야 한다.
  • pool size를 변경할 때 함께 계산해야 하는 것은 무엇인가?
    • 애플리케이션 인스턴스 수, DB max connections, batch와 admin 연결, 운영 접속 여유다.
  • DB 장애 상황에서 백엔드 개발자가 먼저 정리해야 할 정보는 무엇인가?
    • 영향 endpoint, 시작 시각, 최근 배포와 batch, 실제 SQL과 bind 값 패턴, 호출량 변화, pool 지표, timeout/error 변화다.

참고 문서

관련 문서