Quick Overview with ChatGPT 🤖 포스트그레SQL은 유연성과 확장성 덕분에 현대 애플리케이션에서 널리 사용되지만, 대규모 성능을 유지하려면 전략이 필요합니다. 멀티 테넌트 환경에서 데이터베이스 샤딩, 성능 관리 및 고가용성을 위한 CI/CD 프로세스 및 WAL 설정 등 다양한 인프라 설계가 요구됩니다. 적절한 솔루션을 사용하면 복제와 성능 모니터링을 돕고 최적화된 파티셔닝 키 설계를 지원해 포스트그레SQL 애플리케이션의 성능과 복잡성을 관리할 수 있습니다. |
포스트그레SQL(PostgreSQL)은 유연함, 확장의 용이함, 탄탄한 개발자 커뮤니티와 같은 여러 이유로 현대 앱의 RDBMS로 광범위하게 사용되며, 기업이 새로운 기능을 신속하게 배포할 수 있도록 해줍니다. 포스트그레SQL은 비용과 유연함을 이유로 선호되는 경우가 많지만, 대규모에서 성능을 유지하기 위해서는 구체적인 전략이 필요합니다.
이번 포스팅에서는 1부에 이어, 확장 가능한 시스템을 구축하기 위한 몇 가지 접근 방식을 살펴보겠습니다.
✔️포스트그레 SQL 도입 가속화를 위한 팁 –1 부
멀티 테넌트 포스트그레SQL 데이터베이스 관리하기
모든 아키텍처가 그렇듯이, 포스트그레SQL 데이터베이스 샤딩을 시작하기에 앞서 통제 측면에서 계획해야 하는 몇 가지 요소가 있습니다. 클라이언트와 각각의 샤드 매핑(예를 들어 ClientID=123을 쿼리할 데이터베이스), 현재의 데이터베이스 스키마 버전을 찾고 성능을 로깅하는 중앙 데이터베이스가 있다면 유용할 것입니다. 이 중앙 데이터베이스를 통해 업데이트된 데이터베이스 배포든 비즈니스를 위한 보고를 위해서든 모든 샤드에 대해 쿼리를 실행할 수 있어야 합니다. 애플리케이션 특성에 따라 REST API 또는 직접 데이터 연결을 통해 클라이언트에 분석을 위한 데이터 액세스 권한을 제공해야 할 수도 있습니다. 외부 액세스에 대해서도 고려해야 합니다.
중요한 것은 코드와 워크로드 변경이 장시간에 걸쳐 데이터베이스의 성능에 미치는 영향을 파악하는 것입니다. 이런 데이터베이스 변경에 대해서는 툴과 관련한 몇 가지 필수적인 고려 사항이 있습니다.
CI/CD 툴이 데이터베이스 코드 및 변경을 지원하는지 확인합니다.
변경 사항이 성능에 미치는 영향을 파악하기 위해 대표적인 데이터 집합과 함께 유효한 테스트, QA, UAT 환경이 필요합니다.
모든 변경 사항이 성능에 미치는 영향을 확인하기 위해 이러한 모든 환경에 관찰가능성 툴이 있어야 합니다.
예컨대 데이터베이스 호출이 5밀리초에서 15밀리초로 변경되는 것은 사소할 수 있지만, 이 변경이 수천, 또는 수백만 회의 호출에서 발생한다면 애플리케이션의 전반적인 성능에 큰 영향을 미칠 수 있습니다. 그리고 많은 기업이 포스트그레SQL에서 이런 데이터베이스 호출을 추적하는 방법을 알아내는 데 어려움을 겪습니다.
SQL 서버(SQL Server), 오라클과 같은 플랫폼을 다룬 경험이 있는 DBA라면 견고한 성능 추적 서브시스템에 익숙할 것입니다. 포스트그레SQL은 성숙한 플랫폼이지만, 앞서 언급한 상용 데이터베이스에 있는 고급 메타데이터 수집 기능을 전부 갖추고 있지는 않습니다. 전체적인 성능을 파악하기 위해서는 OS 및 데이터베이스 성능 데이터를 모두 수집하고 이 데이터를 상호 연계해야 합니다.
거의 모든 CI/CD(Continuous Integration and Continuous Delivery)는 최소한의 다운타임으로 애플리케이션 코드의 변경 사항을 배포할 수 있습니다. 그러나 데이터베이스 스키마 변경은 일반적으로 CI/CD 패턴에 포함되지 않습니다. 데이터베이스의 상태 유지(STATEFUL) 특성 때문이든 단순히 복잡성 때문이든 테이블, 뷰, 저장 프로시저와 같은 데이터베이스 객체에 대한 변경 사항은 CI/CD 프로세스에 포함되어야 합니다.
데이터베이스에 대한 스키마 변경의 경우 데이터 크기의 변경을 피하기 위한 신중한 사전 계획이 필요합니다. 데이터베이스 CI/CD에서 가장 중요한 패턴은 데이터베이스 객체 변경이 “첨가물”이어야 한다는 것입니다. 예를 들어 열 추가는 쉽지만, 키 테이블에서 열 삭제는 계획하기가 더 까다로울 수 있습니다.
이런 고객 대면 데이터베이스에서 또 다른 중요한 고려 사항은 데이터 내구도와 업타임에 대한 SLA(Service Level Agreement)입니다. 포스트그레SQL은 고가용성과 데이터 보호를 위한 솔루션을 지원하지만 매니지드 클라우드 서비스에서 포스트그레SQL을 사용 중이든 자체 클러스터링 솔루션을 구축하든 관계없이 원한다면 고가용성 인프라를 활용할 수 있습니다. 성능 역시 SLA에서 핵심적인 요소입니다. 고객은 시스템에 액세스할 수 없는 이유가 서버 다운인지 CPU 사용률이 100%인지에 대해서는 관심이 없기 때문입니다. 이는 데이터베이스 성능 관리가 가용성의 핵심적 구성요소라는 사실을 잘 보여줍니다.
멀티 테넌시 관리의 어려운 문제
모든 테넌트가 원활하게 공존하도록 하는 것은 멀티 테넌트 데이터베이스 환경을 관리할 때 어려운 과제 중 하나입니다. 초점을 맞춰야 하는 2가지 주된 문제는 더 넓은 범위의 인프라 문제인 “시끄러운 이웃(noisy neighbor)” 문제와, 특정 데이터베이스 성능 문제인 핫스팟입니다. 이 두 가지 조건의 특성을 살펴보겠습니다.
애저, AWS와 같은 클라우드 제공업체가 사용해온 방법은 일관적인 성능을 보장하기 위한 견고한 경계를 두는 것입니다. 각 워크로드는 자체 VM에서 실행되므로 사용량이 많은 데이터베이스 하나가 다른 데이터베이스의 성능에 영향을 미칠 수 없습니다. VM 사용에는 많은 오버헤드가 따르는데, 샤드를 컨테이너 또는 포드에 배치하는 방식으로 비슷한 격리 효과를 얻을 수 있습니다. 워크로드 격리는 다른 샤드를 보호해서 이른바 시끄러운 이웃 문제를 해소하지만, 성능과 관련한 우려 사항은 이것이 전부가 아닙니다.
“시끄러운 이웃”과 핫스팟
시끄러운 이웃 문제는 일반적으로 각 고객이 데이터베이스를 보유하고 있지만 공유 인프라에서 사용량이 많은 하나의 데이터베이스가 다른 데이터베이스에서 사용 가능한 하드웨어 리소스에 영향을 미칠 수 있는 모델에서 발생합니다. 멀티 테넌트 데이터베이스에서 또 다른 일반적인 성능 문제는 핫스팟입니다. 이 문제는 하나의 데이터베이스 내에 사용량이 매우 많은 하나 이상의 고객이 있는 경우 발생합니다. A 고객의 판매 트랜잭션이 B 고객보다 100배 더 많은 상황을 생각해 보십시오. A 고객 테이블의 행 사용량이 훨씬 더 많을 것입니다.
시끄러운 이웃 문제는 프로세스 격리 수준을 높이거나 부가적인 하드웨어를 사용해서 신속하게 해결할 수 있습니다. 반면 핫스팟은 해결하기가 더 까다롭습니다. 이 문제를 해결하려면 부가적인 하드웨어 리소스(단기적인 해결책), 또는 새로운 데이터 파티션이 필요합니다(데이터 크기의 복잡한 변경).
이상적인 방법은 데이터가 샤드에 고르게 분산되도록 데이터 분산 전략을 설계해서 핫스팟 문제 위험을 최소화하는 것입니다. 데이터베이스에서 핫스팟 문제가 자주 발생한다고 가정해 봅시다. 이 경우 사용량이 많은(hot) 영역이 여러 샤드에 걸쳐 더 고르게 분산되도록 애플리케이션의 샤딩/파티셔닝 키를 재검토하는 것이 좋습니다.
분산 데이터베이스 솔루션을 위한 인프라 설계는 성능을 유지하기 위한 중요한 기초 단계입니다. 워크로드 격리는 좋지만 가상 머신과 같은 기존 접근 방식을 사용할 경우 쿠버네티스와 같은 컨테이너 기반 솔루션이 제공하는 밀도를 달성할 수 없으므로 더 많은 비용이 듭니다. VM에는 각 VM에 대한 바이너리와 커널의 전체 복사본이 필요합니다. 반면 컨테이너 기반 솔루션은 커널과 라이브러리를 코어 운영체제와 공유하면서 격리 및 리소스 거버넌스를 제공하여 컨테이너 단위로 CPU와 메모리를 관리합니다.
앞으로 보유하게 될 데이터의 볼륨뿐만 아니라(이것도 중요하지만) 스토리지 성능도 고려하는 것이 중요합니다. 여기에는 초당 I/O 연산(IOPS), 스토리지 대역폭과 같은 지표에 대한 시야가 포함됩니다. 적절한 모니터링 및 리소스 거버넌스가 없으면 이 같은 부분에서 과부하가 발생할 수 있습니다.
고가용성과 백업
멀티 테넌트 데이터베이스 솔루션 관리에서 중요한 측면 중 하나는 데이터 업타임과 가용성에 대한 가용성 SLA을 충족하는 것입니다. 여기서 업타임은 인프라 및 데이터베이스 수준 솔루션을 사용한 고가용성과 재해 복구 솔루션의 결합에 따른 결과입니다. 이 플랫폼은 VM웨어나 하이퍼-V(Hyper-V)와 같은 하이퍼바이저든 쿠버네티스와 같은 컨테이너 플랫폼이든 고가용성 솔루션을 제공할 수 있으며, 장애가 발생한 컨테이너는 이를 통해 재시작됩니다. 그러나 포스트그레SQL은 데이터센터 장애 또는 하이퍼바이저 장애로부터 보호하기 위해 트랜잭션 로그 복제를 사용해 예비 컴퓨팅 인스턴스로 로그를 스트리밍해서 고가용성과 재해 복구를 제공합니다. 포스트그레SQL 복제의 복잡성 중 하나는 몇 가지 고려해야 할 점이 있는 로그 선행 기입(write-ahead logging, WAL)에 대한 종속성입니다.
트랜잭션 로그와 복제
구체적으로, 포스트그레SQL에는 wal_ keep_settings라는 설정이 있습니다. 이는 예비 복제 타겟이 높은 트랜잭션 볼륨으로 인해 뒤처지지 않도록 하기 위해 디스크에 유지할 부가적인 트랜잭션 로그 파일의 수입니다. 이 설정을 통해 주 데이터베이스의 업타임 유지와(디스크 공간 부족으로 인한 장애가 발생하지 않도록 함) 로그 파일을 복제 타겟으로 스트리밍하는 데 따르는 네트워크 지연 및 오버헤드 처리 간의 균형을 맞출 수 있습니다. 이 설정은 예비 타겟의 네트워크 지연과 디스크 성능에 크게 의존합니다. 네트워크 지연이 낮고 디스크가 빠를수록 예비 인스턴스에서 트랜잭션이 재생되는 속도도 더 빨라집니다.
거의 모든 관계형 데이터베이스가 그렇듯이 포스트그레SQL은 비동기 방법을 사용하여 데이터 파일에 데이터를 씁니다. 데이터 레코드가 업데이트, 삽입 또는 삭제되면 첫 번째 단계는 해당 변경을 메모리에 쓰는 것입니다. 그러나 변경 사항이 디스크의 트랜잭션 로그 파일에 기록될 때까지는 “커밋됨”으로 알려지므로 변경 확인은 되지 않습니다. 이 트랜잭션 로그의 물리적인 쓰기는 서버 장애 상황에서 디스크의 데이터 파일에 변경 사항을 “재생”할 수 있게 해줍니다. 포스트그레SQL은 이 트랜잭션 로그 파일을 다른 서버로 복제해서 재해 복구를 제공하고 이 데이터를 스트리밍합니다. WAL은 이 데이터 보호와 성능, 두 가지 모두의 관리에서 중요한 역할을 합니다. WAL 주변의 복잡성은 서드파티 복제 툴이 SLA를 충족하는 데 도움이 될 수 있는 이유 중 하나입니다.
결론
내외부 고객을 위한 서비스형 소프트웨어 애플리케이션을 관리하기는 까다롭습니다. 고강도의 포스트그레SQL 워크로드를 위한 인프라 비용의 균형을 맞추면서 분산 시스템에서 데이터베이스 성능의 복잡성을 관리하는 것은 최상급 사이트 안정성 엔지니어에게도 어려운 일입니다.
이런 과제를 극복하기 위해 퀘스트는 최상의 포스트그레SQL 애플리케이션을 제공하는 데 필요한 툴을 제공합니다. 쉐어플렉스(SharePlex)는 복제 프로세스를 간소화하는 데 도움이 되며, 포그라이트(Foglight)는 데이터베이스 성능 문제와 변경 및 운영체제 메트릭에 대한 심층적인 인사이트를 제공하여 모든 데이터베이스에서 전문가가 될 수 있게 해줍니다. 샤딩 체계를 구축하거나 핫스팟을 최소화할 방법을 모색 중이라면 어윈 데이터 모델러(erwin Data Modeler)를 사용해서 최적의 성능을 내도록 파티셔닝 키와 데이터베이스 스키마를 설계할 수 있습니다.
본 백서 원문은 퀘스트소프트웨어 홈페이지에서 다운로드할 수 있습니다.
포스트그레SQL 도입 및 데이터베이스 관리에 어려움을 겪고 계시거나 쉐어플렉스, 포그라이트, 어윈 데이터 모델러에 대해 궁금한 점이 있으시면 언제든 퀘스트소프트웨어코리아로 문의주시기 바랍니다. 😀
Quick Overview with ChatGPT 🤖
포스트그레SQL은 유연성과 확장성 덕분에 현대 애플리케이션에서 널리 사용되지만, 대규모 성능을 유지하려면 전략이 필요합니다. 멀티 테넌트 환경에서 데이터베이스 샤딩, 성능 관리 및 고가용성을 위한 CI/CD 프로세스 및 WAL 설정 등 다양한 인프라 설계가 요구됩니다. 적절한 솔루션을 사용하면 복제와 성능 모니터링을 돕고 최적화된 파티셔닝 키 설계를 지원해 포스트그레SQL 애플리케이션의 성능과 복잡성을 관리할 수 있습니다.
포스트그레SQL(PostgreSQL)은 유연함, 확장의 용이함, 탄탄한 개발자 커뮤니티와 같은 여러 이유로 현대 앱의 RDBMS로 광범위하게 사용되며, 기업이 새로운 기능을 신속하게 배포할 수 있도록 해줍니다. 포스트그레SQL은 비용과 유연함을 이유로 선호되는 경우가 많지만, 대규모에서 성능을 유지하기 위해서는 구체적인 전략이 필요합니다.
이번 포스팅에서는 1부에 이어, 확장 가능한 시스템을 구축하기 위한 몇 가지 접근 방식을 살펴보겠습니다.
✔️포스트그레 SQL 도입 가속화를 위한 팁 –1 부
멀티 테넌트 포스트그레SQL 데이터베이스 관리하기
모든 아키텍처가 그렇듯이, 포스트그레SQL 데이터베이스 샤딩을 시작하기에 앞서 통제 측면에서 계획해야 하는 몇 가지 요소가 있습니다. 클라이언트와 각각의 샤드 매핑(예를 들어 ClientID=123을 쿼리할 데이터베이스), 현재의 데이터베이스 스키마 버전을 찾고 성능을 로깅하는 중앙 데이터베이스가 있다면 유용할 것입니다. 이 중앙 데이터베이스를 통해 업데이트된 데이터베이스 배포든 비즈니스를 위한 보고를 위해서든 모든 샤드에 대해 쿼리를 실행할 수 있어야 합니다. 애플리케이션 특성에 따라 REST API 또는 직접 데이터 연결을 통해 클라이언트에 분석을 위한 데이터 액세스 권한을 제공해야 할 수도 있습니다. 외부 액세스에 대해서도 고려해야 합니다.
중요한 것은 코드와 워크로드 변경이 장시간에 걸쳐 데이터베이스의 성능에 미치는 영향을 파악하는 것입니다. 이런 데이터베이스 변경에 대해서는 툴과 관련한 몇 가지 필수적인 고려 사항이 있습니다.
CI/CD 툴이 데이터베이스 코드 및 변경을 지원하는지 확인합니다.
변경 사항이 성능에 미치는 영향을 파악하기 위해 대표적인 데이터 집합과 함께 유효한 테스트, QA, UAT 환경이 필요합니다.
모든 변경 사항이 성능에 미치는 영향을 확인하기 위해 이러한 모든 환경에 관찰가능성 툴이 있어야 합니다.
예컨대 데이터베이스 호출이 5밀리초에서 15밀리초로 변경되는 것은 사소할 수 있지만, 이 변경이 수천, 또는 수백만 회의 호출에서 발생한다면 애플리케이션의 전반적인 성능에 큰 영향을 미칠 수 있습니다. 그리고 많은 기업이 포스트그레SQL에서 이런 데이터베이스 호출을 추적하는 방법을 알아내는 데 어려움을 겪습니다.
SQL 서버(SQL Server), 오라클과 같은 플랫폼을 다룬 경험이 있는 DBA라면 견고한 성능 추적 서브시스템에 익숙할 것입니다. 포스트그레SQL은 성숙한 플랫폼이지만, 앞서 언급한 상용 데이터베이스에 있는 고급 메타데이터 수집 기능을 전부 갖추고 있지는 않습니다. 전체적인 성능을 파악하기 위해서는 OS 및 데이터베이스 성능 데이터를 모두 수집하고 이 데이터를 상호 연계해야 합니다.
거의 모든 CI/CD(Continuous Integration and Continuous Delivery)는 최소한의 다운타임으로 애플리케이션 코드의 변경 사항을 배포할 수 있습니다. 그러나 데이터베이스 스키마 변경은 일반적으로 CI/CD 패턴에 포함되지 않습니다. 데이터베이스의 상태 유지(STATEFUL) 특성 때문이든 단순히 복잡성 때문이든 테이블, 뷰, 저장 프로시저와 같은 데이터베이스 객체에 대한 변경 사항은 CI/CD 프로세스에 포함되어야 합니다.
데이터베이스에 대한 스키마 변경의 경우 데이터 크기의 변경을 피하기 위한 신중한 사전 계획이 필요합니다. 데이터베이스 CI/CD에서 가장 중요한 패턴은 데이터베이스 객체 변경이 “첨가물”이어야 한다는 것입니다. 예를 들어 열 추가는 쉽지만, 키 테이블에서 열 삭제는 계획하기가 더 까다로울 수 있습니다.
이런 고객 대면 데이터베이스에서 또 다른 중요한 고려 사항은 데이터 내구도와 업타임에 대한 SLA(Service Level Agreement)입니다. 포스트그레SQL은 고가용성과 데이터 보호를 위한 솔루션을 지원하지만 매니지드 클라우드 서비스에서 포스트그레SQL을 사용 중이든 자체 클러스터링 솔루션을 구축하든 관계없이 원한다면 고가용성 인프라를 활용할 수 있습니다. 성능 역시 SLA에서 핵심적인 요소입니다. 고객은 시스템에 액세스할 수 없는 이유가 서버 다운인지 CPU 사용률이 100%인지에 대해서는 관심이 없기 때문입니다. 이는 데이터베이스 성능 관리가 가용성의 핵심적 구성요소라는 사실을 잘 보여줍니다.
멀티 테넌시 관리의 어려운 문제
모든 테넌트가 원활하게 공존하도록 하는 것은 멀티 테넌트 데이터베이스 환경을 관리할 때 어려운 과제 중 하나입니다. 초점을 맞춰야 하는 2가지 주된 문제는 더 넓은 범위의 인프라 문제인 “시끄러운 이웃(noisy neighbor)” 문제와, 특정 데이터베이스 성능 문제인 핫스팟입니다. 이 두 가지 조건의 특성을 살펴보겠습니다.
애저, AWS와 같은 클라우드 제공업체가 사용해온 방법은 일관적인 성능을 보장하기 위한 견고한 경계를 두는 것입니다. 각 워크로드는 자체 VM에서 실행되므로 사용량이 많은 데이터베이스 하나가 다른 데이터베이스의 성능에 영향을 미칠 수 없습니다. VM 사용에는 많은 오버헤드가 따르는데, 샤드를 컨테이너 또는 포드에 배치하는 방식으로 비슷한 격리 효과를 얻을 수 있습니다. 워크로드 격리는 다른 샤드를 보호해서 이른바 시끄러운 이웃 문제를 해소하지만, 성능과 관련한 우려 사항은 이것이 전부가 아닙니다.
“시끄러운 이웃”과 핫스팟
시끄러운 이웃 문제는 일반적으로 각 고객이 데이터베이스를 보유하고 있지만 공유 인프라에서 사용량이 많은 하나의 데이터베이스가 다른 데이터베이스에서 사용 가능한 하드웨어 리소스에 영향을 미칠 수 있는 모델에서 발생합니다. 멀티 테넌트 데이터베이스에서 또 다른 일반적인 성능 문제는 핫스팟입니다. 이 문제는 하나의 데이터베이스 내에 사용량이 매우 많은 하나 이상의 고객이 있는 경우 발생합니다. A 고객의 판매 트랜잭션이 B 고객보다 100배 더 많은 상황을 생각해 보십시오. A 고객 테이블의 행 사용량이 훨씬 더 많을 것입니다.
시끄러운 이웃 문제는 프로세스 격리 수준을 높이거나 부가적인 하드웨어를 사용해서 신속하게 해결할 수 있습니다. 반면 핫스팟은 해결하기가 더 까다롭습니다. 이 문제를 해결하려면 부가적인 하드웨어 리소스(단기적인 해결책), 또는 새로운 데이터 파티션이 필요합니다(데이터 크기의 복잡한 변경).
이상적인 방법은 데이터가 샤드에 고르게 분산되도록 데이터 분산 전략을 설계해서 핫스팟 문제 위험을 최소화하는 것입니다. 데이터베이스에서 핫스팟 문제가 자주 발생한다고 가정해 봅시다. 이 경우 사용량이 많은(hot) 영역이 여러 샤드에 걸쳐 더 고르게 분산되도록 애플리케이션의 샤딩/파티셔닝 키를 재검토하는 것이 좋습니다.
분산 데이터베이스 솔루션을 위한 인프라 설계는 성능을 유지하기 위한 중요한 기초 단계입니다. 워크로드 격리는 좋지만 가상 머신과 같은 기존 접근 방식을 사용할 경우 쿠버네티스와 같은 컨테이너 기반 솔루션이 제공하는 밀도를 달성할 수 없으므로 더 많은 비용이 듭니다. VM에는 각 VM에 대한 바이너리와 커널의 전체 복사본이 필요합니다. 반면 컨테이너 기반 솔루션은 커널과 라이브러리를 코어 운영체제와 공유하면서 격리 및 리소스 거버넌스를 제공하여 컨테이너 단위로 CPU와 메모리를 관리합니다.
앞으로 보유하게 될 데이터의 볼륨뿐만 아니라(이것도 중요하지만) 스토리지 성능도 고려하는 것이 중요합니다. 여기에는 초당 I/O 연산(IOPS), 스토리지 대역폭과 같은 지표에 대한 시야가 포함됩니다. 적절한 모니터링 및 리소스 거버넌스가 없으면 이 같은 부분에서 과부하가 발생할 수 있습니다.
고가용성과 백업
멀티 테넌트 데이터베이스 솔루션 관리에서 중요한 측면 중 하나는 데이터 업타임과 가용성에 대한 가용성 SLA을 충족하는 것입니다. 여기서 업타임은 인프라 및 데이터베이스 수준 솔루션을 사용한 고가용성과 재해 복구 솔루션의 결합에 따른 결과입니다. 이 플랫폼은 VM웨어나 하이퍼-V(Hyper-V)와 같은 하이퍼바이저든 쿠버네티스와 같은 컨테이너 플랫폼이든 고가용성 솔루션을 제공할 수 있으며, 장애가 발생한 컨테이너는 이를 통해 재시작됩니다. 그러나 포스트그레SQL은 데이터센터 장애 또는 하이퍼바이저 장애로부터 보호하기 위해 트랜잭션 로그 복제를 사용해 예비 컴퓨팅 인스턴스로 로그를 스트리밍해서 고가용성과 재해 복구를 제공합니다. 포스트그레SQL 복제의 복잡성 중 하나는 몇 가지 고려해야 할 점이 있는 로그 선행 기입(write-ahead logging, WAL)에 대한 종속성입니다.
트랜잭션 로그와 복제
구체적으로, 포스트그레SQL에는 wal_ keep_settings라는 설정이 있습니다. 이는 예비 복제 타겟이 높은 트랜잭션 볼륨으로 인해 뒤처지지 않도록 하기 위해 디스크에 유지할 부가적인 트랜잭션 로그 파일의 수입니다. 이 설정을 통해 주 데이터베이스의 업타임 유지와(디스크 공간 부족으로 인한 장애가 발생하지 않도록 함) 로그 파일을 복제 타겟으로 스트리밍하는 데 따르는 네트워크 지연 및 오버헤드 처리 간의 균형을 맞출 수 있습니다. 이 설정은 예비 타겟의 네트워크 지연과 디스크 성능에 크게 의존합니다. 네트워크 지연이 낮고 디스크가 빠를수록 예비 인스턴스에서 트랜잭션이 재생되는 속도도 더 빨라집니다.
거의 모든 관계형 데이터베이스가 그렇듯이 포스트그레SQL은 비동기 방법을 사용하여 데이터 파일에 데이터를 씁니다. 데이터 레코드가 업데이트, 삽입 또는 삭제되면 첫 번째 단계는 해당 변경을 메모리에 쓰는 것입니다. 그러나 변경 사항이 디스크의 트랜잭션 로그 파일에 기록될 때까지는 “커밋됨”으로 알려지므로 변경 확인은 되지 않습니다. 이 트랜잭션 로그의 물리적인 쓰기는 서버 장애 상황에서 디스크의 데이터 파일에 변경 사항을 “재생”할 수 있게 해줍니다. 포스트그레SQL은 이 트랜잭션 로그 파일을 다른 서버로 복제해서 재해 복구를 제공하고 이 데이터를 스트리밍합니다. WAL은 이 데이터 보호와 성능, 두 가지 모두의 관리에서 중요한 역할을 합니다. WAL 주변의 복잡성은 서드파티 복제 툴이 SLA를 충족하는 데 도움이 될 수 있는 이유 중 하나입니다.
결론
내외부 고객을 위한 서비스형 소프트웨어 애플리케이션을 관리하기는 까다롭습니다. 고강도의 포스트그레SQL 워크로드를 위한 인프라 비용의 균형을 맞추면서 분산 시스템에서 데이터베이스 성능의 복잡성을 관리하는 것은 최상급 사이트 안정성 엔지니어에게도 어려운 일입니다.
이런 과제를 극복하기 위해 퀘스트는 최상의 포스트그레SQL 애플리케이션을 제공하는 데 필요한 툴을 제공합니다. 쉐어플렉스(SharePlex)는 복제 프로세스를 간소화하는 데 도움이 되며, 포그라이트(Foglight)는 데이터베이스 성능 문제와 변경 및 운영체제 메트릭에 대한 심층적인 인사이트를 제공하여 모든 데이터베이스에서 전문가가 될 수 있게 해줍니다. 샤딩 체계를 구축하거나 핫스팟을 최소화할 방법을 모색 중이라면 어윈 데이터 모델러(erwin Data Modeler)를 사용해서 최적의 성능을 내도록 파티셔닝 키와 데이터베이스 스키마를 설계할 수 있습니다.
본 백서 원문은 퀘스트소프트웨어 홈페이지에서 다운로드할 수 있습니다.
포스트그레SQL 도입 및 데이터베이스 관리에 어려움을 겪고 계시거나 쉐어플렉스, 포그라이트, 어윈 데이터 모델러에 대해 궁금한 점이 있으시면 언제든 퀘스트소프트웨어코리아로 문의주시기 바랍니다. 😀