읽기 전용 데이터(Read-mostly data)

데이터베이스 확장성 패턴 중 하나인 read-mostly 데이터의 특성과 GitLab 개발에서의 모범 사례를 설명합니다.

이 문서는 Database Scalability Working Group 에서 제시한 read-mostly 패턴을 설명합니다. read-mostly 데이터의 특성을 살펴보고, GitLab 개발에서 이 컨텍스트를 다룰 때 참고할 모범 사례를 제안합니다. read-mostly 데이터의 특성 # 이름에서 알 수 있듯 read-mostly 데이터는 업데이트보다 읽기가 훨씬 잦은 데이터를 말합니다. 업데이트, 삽입, 삭제로 이 데이터를 쓰는 일은 읽는 일에 비하면 매우 드뭅니다. 또한 여기에서 말하는 read-mostly 데이터는 대체로 크기가 작은 데이터셋입니다. 대용량 데이터셋도 "한 번 쓰고 자주 읽는" 특성을 가질 때가 많지만 여기에서는 다루지 않습니다. 예시: 라이선스 데이터 # 대표적인 예시로 GitLab의 라이선스 데이터를 들 수 있습니다. GitLab 인스턴스는 엔터프라이즈 기능을 사용하기 위한 라이선스를 가질 수 있습니다. 이 라이선스 데이터는 인스턴스 전체 단위로 보관되며, 일반적으로 관련 레코드가 몇 건에 지나지 않습니다. 이 정보는 licenses 라는 아주 작은 테이블에 저장됩니다. 이 데이터는 다음과 같이 앞서 설명한 특성을 따르므로 read-mostly 데이터로 봅니다. 드문 쓰기 : 라이선스 데이터는 라이선스를 삽입한 뒤 쓰기가 거의 발생하지 않습니다. 잦은 읽기 : 엔터프라이즈 기능을 사용할 수 있는지 확인하기 위해 라이선스 데이터를 매우 자주 읽습니다. 작은 크기 : 이 데이터셋은 매우 작습니다. GitLab.com에는 레코드가 5건이며 전체 관계 크기가 50 kB 미만입니다. 대규모 환경에서 read-mostly 데이터가 미치는 영향 # 이 데이터셋은 작고 매우 자주 읽히므로, 데이터가 거의 항상 데이터베이스 캐시나 데이터베이스 디스크 캐시에 있다고 볼 수 있습니다. 따라서 read-mostly 데이터에서 문제가 되는 것은 대개 데이터베이스 I/O 부담이 아닙니다. 어차피 디스크에서 데이터를 읽지 않기 때문입니다. 다만 읽기 빈도가 높다는 점을 고려하면 데이터베이스 CPU 부하와 데이터베이스 컨텍스트 전환 측면에서 부담이 생길 수 있습니다. 또한 이런 고빈도 쿼리는 데이터베이스 스택 전체를 거칩니다. 데이터베이스 연결 다중화 컴포넌트와 로드 밸런서에도 부담을 줍니다. 애플리케이션 역시 데이터를 가져오는 쿼리를 준비해 보내고, 결과를 역직렬화하고, 수집한 정보를 표현할 새 객체를 할당하는 작업을 모두 높은 빈도로 반복하면서 자원을 소모합니다. 앞의 라이선스 데이터 예시에서는 라이선스 데이터를 읽는 쿼리가 쿼리 빈도 측면에서 두드러진다는 점이 확인되었습니다 . 실제로 피크 시간대에 클러스터에서 초당 약 6,000건(QPS)의 쿼리가 발생했습니다. 당시 클러스터 규모에서는 각 복제본에서 약 1,000 QPS, 피크 시간대 기본 노드에서 400 QPS 미만이 관측되었습니다. 이 차이는 순수 읽기 전용 트랜잭션에 복제본을 우선 사용하는 읽기 확장용 데이터베이스 로드 밸런싱 으로 설명됩니다. 당시 데이터베이스 기본 노드의