프로덕션 환경에서 어떤 ClickHouse 버전을 사용해야 할까요?

먼저, 사람들이 처음에 왜 이런 질문을 하는지부터 살펴보겠습니다. 핵심적인 이유는 두 가지입니다:

1. ClickHouse는 상당히 빠른 속도로 개발되며, 보통 1년에 10개 이상의 안정(stable) 버전이 릴리스됩니다. 이로 인해 선택할 수 있는 릴리스 범위가 매우 넓어져, 결코 단순하게 결정할 수 있는 문제가 아닙니다.
2. 일부 사용자는 자신의 사용 사례에 가장 잘 맞는 버전을 직접 알아보는 데 시간을 쓰고 싶지 않아서, 다른 사람의 조언을 그대로 따르기를 원합니다.

두 번째 이유가 더 근본적이므로, 우선 이 부분부터 다루고 그다음에 다양한 ClickHouse 릴리스 중에서 어떻게 선택할지로 돌아가겠습니다.

어떤 ClickHouse 버전을 추천하나요?

프로덕션 환경에 대한 책임을 피하기 위해 컨설턴트를 고용하거나 잘 알려진 전문가에게 의존하고 싶어질 수 있습니다. 누군가가 추천한 특정 ClickHouse 버전을 설치해 두면, 그 버전에 문제가 생겼을 때 그것은 자신의 잘못이 아니라 그 사람의 잘못이라고 생각하게 됩니다. 이런 사고방식은 큰 함정입니다. 회사의 프로덕션 환경에서 실제로 무슨 일이 일어나는지 외부 사람이 내부 구성원보다 더 잘 알 수는 없습니다.

그렇다면 어떤 ClickHouse 버전으로 업그레이드할지 올바르게 선택하는 방법은 무엇일까요? 또는 첫 번째 ClickHouse 버전을 어떻게 선택해야 할까요? 우선 현실적인 사전 프로덕션(pre-production) 환경을 구축하는 데 투자해야 합니다. 이상적인 상황에서는 완전히 동일한 섀도(shadow) 복사본을 둘 수 있지만, 대부분의 경우 비용이 많이 듭니다.

합리적인 비용으로도 사전 프로덕션 환경의 유사성을 어느 정도 확보하기 위한 핵심 포인트는 다음과 같습니다:

• 사전 프로덕션 환경에서는 프로덕션에서 실행하려는 쿼리와 최대한 비슷한 쿼리 집합을 실행해야 합니다:
  • 정적인 데이터를 둔 읽기 전용 환경으로 두지 마십시오.
  • 대표적인 리포트를 만들지 않고 단순히 데이터만 복사하는 쓰기 전용 환경으로 두지 마십시오.
  • 스키마 마이그레이션을 적용하는 대신 매번 깨끗이 초기화하지 마십시오.
• 실제 프로덕션 데이터와 쿼리의 샘플을 사용하십시오. SELECT 쿼리가 여전히 의미 있는 결과를 반환할 수 있도록, 대표성을 유지하는 샘플을 선택해야 합니다. 데이터가 민감하여 내부 정책상 프로덕션 환경을 벗어날 수 없다면 난독화를 사용하십시오.
• 사전 프로덕션 환경도 프로덕션 환경과 동일한 방식으로 모니터링 및 알림 소프트웨어 대상에 포함되도록 설정하십시오.
• 프로덕션이 여러 데이터센터나 리전에 걸쳐 있다면, 사전 프로덕션도 동일하게 구성하십시오.
• 프로덕션에서 복제(replication), 분산 테이블(distributed table), 계단식 materialized view 같은 복잡한 기능을 사용한다면, 사전 프로덕션에서도 유사하게 설정되어 있도록 해야 합니다.
• 사전 프로덕션에서 프로덕션과 대략 같은 수의 서버 또는 VM을 더 작은 크기로 사용하는 것과, 수는 훨씬 적지만 크기는 동일하게 사용하는 것 사이에는 트레이드오프가 있습니다. 첫 번째 옵션은 네트워크 관련 문제를 더 잘 포착할 수 있는 반면, 두 번째 옵션은 관리가 더 쉽습니다.

두 번째로 투자해야 할 영역은 자동화된 테스트 인프라입니다. 어떤 종류의 쿼리가 한 번 성공적으로 실행되었다고 해서, 앞으로도 계속 성공적으로 실행될 것이라고 가정해서는 안 됩니다. ClickHouse를 모킹한 단위 테스트를 일부 두어도 괜찮지만, 실제 ClickHouse를 대상으로 실행되며 모든 중요한 사용 사례가 여전히 기대대로 동작하는지 확인하는 합리적인 수준의 자동화된 테스트 세트를 제품에 반드시 갖추어야 합니다.

한 단계 더 나아가, 이러한 자동화된 테스트를 ClickHouse의 오픈 소스 테스트 인프라에 기여하는 방법도 있습니다. 이 인프라는 ClickHouse의 일상적인 개발 과정에서 지속적으로 사용됩니다. 실행 방법을 익히고, 이후 이 프레임워크에 테스트를 맞추도록 수정하는 데 추가적인 시간과 노력이 필요하겠지만, 이를 통해 ClickHouse 릴리스가 안정(stable)으로 발표될 때 이미 해당 테스트에 대해 검증이 완료되도록 할 수 있습니다. 이 방식은 문제를 사후에 반복적으로 보고하고, 버그 수정이 구현되고, 백포트되고, 릴리스될 때까지 기다리는 데 드는 시간을 줄여 줍니다. 일부 회사는 이러한 테스트를 인프라에 기여하는 행위를 내부 정책으로 두기도 하는데, Google에서는 이를 Beyonce's Rule이라고 부릅니다.

사전 프로덕션 환경과 테스트 인프라를 갖추었다면, 최적의 버전을 선택하는 일은 비교적 간단합니다:

1. 새로운 ClickHouse 릴리스에 대해 자동화된 테스트를 정기적으로 실행합니다. testing으로 표시된 ClickHouse 릴리스에 대해서도 이를 수행할 수 있지만, 해당 버전으로 다음 단계까지 진행하는 것은 권장되지 않습니다.
2. 테스트를 통과한 ClickHouse 릴리스를 사전 프로덕션에 배포하고, 모든 프로세스가 기대대로 실행되고 있는지 확인합니다.
3. 발견한 모든 문제를 ClickHouse GitHub Issues에 리포트합니다.
4. 심각한 문제가 없었다면, 해당 ClickHouse 릴리스를 프로덕션 환경에 배포해도 안전하다고 볼 수 있습니다. 카나리아 릴리스나 blue-green 배포와 유사한 접근 방식을 자동화한 점진적 릴리스에 투자하면, 프로덕션에서 문제가 발생할 위험을 더욱 줄일 수 있습니다.

위에서 설명한 접근 방식에는 ClickHouse에만 특화된 내용은 없습니다. 프로덕션 환경을 진지하게 다루는 경우, 의존하는 모든 인프라 구성 요소에 대해 이와 같은 방식을 사용합니다.

ClickHouse 릴리스를 선택하는 방법

ClickHouse 패키지 저장소의 내용을 살펴보면 두 종류의 패키지가 있음을 확인할 수 있습니다:

1. stable
2. lts (long-term support)

두 종류 중에서 선택할 때 참고할 수 있는 지침은 다음과 같습니다:

• stable은 기본적으로 권장하는 패키지입니다. 대략 매달 한 번씩 릴리스되므로(그 결과 새로운 기능이 적절한 기간 내에 제공됩니다) 최신 stable 릴리스 3개에 대해 진단 및 버그 수정 백포팅이 지원됩니다.
• lts는 1년에 두 번 릴리스되며 최초 릴리스 이후 1년간 지원됩니다. 다음과 같은 경우 stable 대신 lts를 사용하는 편이 더 적합할 수 있습니다:
  • 회사 내부 정책상 잦은 업그레이드나 LTS가 아닌 소프트웨어 사용이 허용되지 않는 경우
  • ClickHouse를 복잡한 ClickHouse 기능이 필요하지 않은 보조 제품에서 사용하거나, 최신 상태로 유지할 충분한 리소스가 없는 제품에서 사용하는 경우

처음에는 lts가 더 적합하다고 생각하는 많은 팀도, 자사 제품에 중요한 최신 기능 때문에 결국 stable로 전환하는 경우가 자주 있습니다.

팁

ClickHouse를 업그레이드할 때 한 가지 더 기억해야 할 점이 있습니다. ClickHouse는 항상 릴리스 간 호환성을 주의 깊게 유지하려고 하지만, 호환성을 계속 유지하는 것이 합리적이지 않은 경우도 있으며, 일부 사소한 동작이 변경될 수 있습니다. 따라서 업그레이드 전에 changelog를 살펴보고 하위 호환성이 깨지는 변경 사항 관련 안내가 있는지 반드시 확인해야 합니다.