PHP 서비스의 저장소 선택 — MariaDB로 시작하고 Redis·문서 DB를 추가하는 판단 기준

데이터베이스 제품의 기능을 나열하는 것만으로는 저장소를 선택하기 어렵다. PHP 웹 서비스에서는 데이터의 정본이 무엇인지, 어떤 일관성이 필요한지, 실패했을 때 어떻게 복구할지를 먼저 결정해야 한다. 이 글은 회원·게시글을 가진 서비스를 기준으로 저장소 역할을 나누는 방법을 설명한다.

1. 기본값은 하나의 관계형 DB

회원, 게시글과 권한처럼 서로 관계가 있고 함께 변경되어야 하는 데이터는 MariaDB 같은 관계형 DB에서 시작하는 편이 단순하다.

START TRANSACTION;

INSERT INTO posts (member_id, title, status)
VALUES (42, '저장소 선택 기준', 'public');

INSERT INTO post_audit (post_idx, action, member_id)
VALUES (LAST_INSERT_ID(), 'created', 42);

COMMIT;

두 변경이 모두 성공하거나 모두 취소되어야 한다면 트랜잭션 경계가 중요하다. 기술이 새롭다는 이유만으로 이 데이터를 여러 저장소에 먼저 나누면 실패·복구 경로가 늘어난다.

2. Redis는 정본이 아닌 파생 데이터부터

게시글 상세 조회가 반복될 때 Redis를 캐시로 붙일 수 있다. 이때 정본은 MariaDB이고 Redis 값은 다시 만들 수 있어야 한다.

1. cache key 조회: post:73
2. 값이 있으면 반환
3. 없으면 MariaDB 조회
4. 결과를 짧은 TTL로 저장
5. 게시글 수정 시 해당 key 삭제

Redis 장애 시에도 DB에서 읽어 서비스가 제한적으로 동작하도록 설계한다. 세션이나 작업 큐처럼 Redis 데이터 자체가 중요하다면 지속성, 복제와 장애 복구 조건을 별도로 검토한다.

3. 문서 DB를 검토할 질문

• 레코드마다 구조가 크게 다르고 함께 읽는 중첩 문서인가
• 관계와 조인보다 문서 단위 읽기·쓰기가 중심인가
• 필드 변경과 데이터 이관을 어떻게 관리할 것인가
• 중복 저장된 값의 일관성을 누가 책임지는가
• 팀이 백업·복원·모니터링까지 운영할 수 있는가

스키마가 유연하다는 것은 스키마가 없다는 뜻이 아니다. 애플리케이션 검증, 인덱스와 문서 버전 관리가 필요하다.

4. 저장소 추가 전 측정할 것

DB가 느리다는 이유만으로 Redis를 추가하면 잘못된 쿼리와 인덱스를 숨길 수 있다. 기존 병목을 측정하고 저장소 추가 후 같은 조건으로 다시 측정한다.

5. 운영 비용까지 포함한 선택표

• 백업 파일이 실제로 복원되는가
• 장애와 네트워크 단절 시 애플리케이션이 어떻게 동작하는가
• 접근 권한과 TLS를 저장소별로 관리할 수 있는가
• 버전 업그레이드와 보안 패치 담당자가 있는가
• 데이터 삭제·보존 정책을 모든 복제본에 적용할 수 있는가

정리: PHP 서비스는 관계형 DB를 정본으로 단순하게 시작하고, 측정된 문제를 해결할 명확한 역할이 있을 때 캐시나 문서 저장소를 추가한다.