19장 데이터베이스는 저장 버튼의 뒷면이다

사용자가 저장 버튼을 눌렀을 때 원하는 것은 바이트를 디스크에 쓰는 일만이 아니다. 데이터가 규칙에 맞고, 중간에 실패해도 이상한 상태로 남지 않으며, 다른 사용자와 동시에 작업해도 일관성이 유지되기를 기대한다. 데이터베이스는 이런 요구를 다루기 위한 구조와 기능을 제공한다. 파일보다 무조건 고급이라는 뜻이 아니라 더 복잡한 약속을 관리하는 도구다.

관계형 데이터베이스에서는 표와 관계, 제약 조건으로 데이터를 모델링한다. 기본키는 행을 구별하고 외래키는 연결된 데이터의 관계를 지키는 데 사용한다. 입력 화면에서 검사했다고 서버와 데이터베이스의 검증을 생략할 수는 없다. 화면을 통하지 않는 요청이나 동시에 실행되는 작업도 있기 때문이다. 지켜야 할 규칙은 가능한 한 신뢰할 수 있는 경계에서 강제한다.

모두 하거나 하지 않거나

트랜잭션은 여러 작업을 하나의 논리적 단위로 묶는다. 가상의 재고 시스템에서 수량을 줄이고 주문을 기록하는 두 작업 중 하나만 성공하면 곤란하다. 트랜잭션의 원자성은 이런 부분 성공을 다루는 데 중요하다. 다만 외부 결제 서비스나 메시지 발송까지 자동으로 하나의 데이터베이스 트랜잭션에 포함되는 것은 아니다.

격리 수준은 동시에 실행되는 트랜잭션이 서로의 변화를 어떻게 보는지와 관련된다. 데이터베이스 제품과 격리 수준마다 동작이 다르므로 이름만으로 모든 경우를 추측하면 안 된다. 동시 주문의 마지막 재고를 다룰 때는 실제 제약과 잠금, 실패 후 재시도를 시험해야 한다. 한 사용자만 사용하는 시험에서는 보이지 않던 문제가 동시성에서 나타난다.

다음은 시험용 데이터베이스에서만 읽어 볼 개념 예다. 실제 실행을 위해서는 표와 제약을 먼저 준비해야 한다. 수량이 충분한 경우에만 줄이는 조건과 영향을 받은 행 수 확인이 중요하다. 아래 코드는 완성된 주문 시스템이 아니라 트랜잭션 경계를 보여 준다.

BEGIN;

UPDATE inventory
SET quantity = quantity - 1
WHERE product_id = 'NET-101'
  AND quantity >= 1;

-- The application must check that exactly one row changed.
-- Only then should it create the matching order record.
-- If the condition is not met, ROLLBACK instead of COMMIT.

COMMIT;

인덱스의 값과 비용

인덱스는 조건에 맞는 데이터를 찾는 데 도움이 되는 별도의 구조다. 책의 찾아보기처럼 전체를 훑는 비용을 줄일 수 있다. 그러나 모든 질의가 같은 인덱스를 활용하는 것은 아니고, 데이터의 분포와 선택도에 따라 전체 스캔이 나을 수도 있다. 실행 계획을 보고 실제로 어떤 방법을 선택했는지 확인해야 한다.

인덱스를 추가하면 저장 공간을 쓰고 데이터를 바꿀 때 유지 비용이 생긴다. 모든 열에 인덱스를 붙이는 것은 공짜 최적화가 아니다. 자주 사용하는 검색과 정렬, 조인 조건을 바탕으로 설계하고 쓰기 비용을 함께 측정한다. 큰 운영 표에 인덱스를 만드는 작업은 잠금과 부하에 영향을 줄 수 있으므로 제품의 온라인 생성 기능과 주의사항을 확인해야 한다.

연결도 한정된 자원이다

웹 요청마다 데이터베이스 연결을 새로 만들면 준비 비용이 늘어난다. 연결 풀은 기존 연결을 재사용하도록 관리한다. 하지만 풀을 무조건 크게 잡으면 데이터베이스가 감당하지 못하는 동시 작업을 밀어 넣을 수 있다. 응용 서버가 열 대라면 각 서버의 풀 크기를 합친 최대 연결 수를 계산해야 한다. 한 서버에서 적절한 숫자가 전체에서는 과부하가 될 수 있다.

느린 질의는 CPU 부족뿐 아니라 잠금 대기, 저장 장치 대기, 비효율적인 계획, 네트워크, 과도한 결과 전송 때문일 수 있다. 응용 프로그램에서 데이터베이스 호출 전체 시간만 기록하면 연결을 기다린 시간과 실행 시간이 섞인다. 풀 대기와 실제 질의, 결과 처리 구간을 나눠 보면 병목이 다르게 보인다.

백업은 복원할 수 있어야 한다

백업 파일이 있다는 사실만으로 복구 가능성을 보장하지 않는다. 복원에 필요한 버전, 키, 설정, 권한과 절차가 함께 있어야 한다. 암호화한 백업을 안전하게 보관했는데 복호화 키가 같은 장애로 사라지면 사용할 수 없다. 백업의 완성은 별도 시험 환경에서 실제로 복원하고 주요 데이터를 확인하는 데 있다.

복제본도 백업과 다르다. 실수로 지운 데이터가 빠르게 복제되면 양쪽에서 동시에 사라진다. 시점 복구와 보존 정책, 별도 권한과 저장 위치가 필요하다. 얼마나 최근까지의 데이터를 잃어도 되는지와 얼마나 빨리 복구해야 하는지를 정해야 비용과 절차를 설계할 수 있다. 모든 데이터가 같은 복구 목표를 가져야 하는 것은 아니다.

데이터베이스 선택은 유행보다 데이터의 규칙과 접근 방식에서 시작한다. 관계와 일관성이 중요한지, 어떤 질의가 많은지, 운영자가 무엇을 관리할 수 있는지 살핀다. 익숙한 도구로 단순한 구조를 정확하게 운영하는 편이 낯선 도구 여러 개를 불완전하게 묶는 것보다 나을 때가 많다. 선택의 근거를 남기면 나중에 한계를 만났을 때도 바꿀 이유가 분명해진다.