프로덕션에서는 어떤 ClickHouse 버전을 사용해야 하나요?

이 페이지에서는 프로덕션에서 어떤 ClickHouse 버전을 사용해야 하는지에 대한 지침을 제공합니다

우선, 사람들이 왜 이런 질문을 하는지부터 살펴보겠습니다. 핵심적인 이유는 두 가지입니다.

1. ClickHouse는 매우 빠른 속도로 개발되며, 보통 1년에 10개가 넘는 안정 릴리스가 나옵니다. 즉, 선택 가능한 릴리스가 매우 많기 때문에 쉽게 결정할 수 있는 문제가 아닙니다.
2. 일부 사용자는 자신의 사용 사례에 가장 적합한 버전을 직접 판단하는 데 시간을 쓰기보다, 다른 사람의 조언을 따르기를 원합니다.

두 번째 이유가 더 본질적이므로, 먼저 이 부분부터 살펴본 뒤 다양한 ClickHouse 릴리스를 어떻게 선택할지 다시 이야기하겠습니다.

​

어떤 ClickHouse 버전을 권장합니까?

프로덕션 환경에 대한 책임을 덜기 위해 컨설턴트를 고용하거나 이름이 알려진 전문가의 의견을 믿고 싶을 수 있습니다. 다른 누군가가 추천한 특정 ClickHouse 버전을 설치한 뒤 문제가 생기면, 내 책임이 아니라 그 사람 책임이라고 여기게 됩니다. 하지만 이런 사고방식은 큰 함정입니다. 회사의 프로덕션 환경에서 실제로 무슨 일이 일어나고 있는지는 외부인보다 내부에서 더 잘 압니다.

그렇다면 업그레이드할 ClickHouse 버전은 어떻게 올바르게 선택해야 할까요? 또는 처음 도입할 ClickHouse 버전은 어떻게 선택해야 할까요? 무엇보다 먼저 현실적인 프리프로덕션 환경을 구축하는 데 투자해야 합니다. 이상적으로는 완전히 동일한 섀도 복제본일 수 있겠지만, 보통은 비용이 많이 듭니다.

비용을 지나치게 높이지 않으면서도 프리프로덕션 환경의 현실성을 충분히 확보하려면 다음 사항이 중요합니다:

• 프리프로덕션 환경에서는 프로덕션에서 실행할 예정인 것과 최대한 유사한 쿼리 집합을 실행해야 합니다:
  • 고정된 데이터만 둔 읽기 전용 환경으로 만들지 마십시오.
  • 일반적인 보고서는 만들지 않고 데이터만 복사하는 쓰기 전용 환경으로 만들지 마십시오.
  • 스키마 마이그레이션을 적용하는 대신 데이터를 모두 지우지 마십시오.
• 실제 프로덕션 데이터와 쿼리의 샘플을 사용하십시오. 대표성이 유지되면서 SELECT 쿼리가 합리적인 결과를 반환할 수 있는 샘플을 선택해 보십시오. 데이터가 민감하고 내부 정책상 프로덕션 환경 밖으로 반출할 수 없다면 난독화를 사용하십시오.
• 프리프로덕션 환경도 프로덕션 환경과 동일한 방식으로 모니터링 및 알림 소프트웨어의 적용을 받도록 하십시오.
• 프로덕션이 여러 데이터센터나 리전에 걸쳐 있다면 프리프로덕션 환경도 동일하게 구성하십시오.
• 프로덕션에서 복제, 분산 테이블, 연쇄형 materialized view 같은 복잡한 기능을 사용한다면, 프리프로덕션 환경에서도 비슷하게 구성되어 있는지 확인하십시오.
• 프리프로덕션 환경을 프로덕션과 비슷한 수의 서버 또는 VM으로 구성하되 더 작은 사양을 사용할지, 아니면 훨씬 적은 수로 구성하되 동일한 사양을 사용할지에는 절충이 필요합니다. 전자는 추가적인 네트워크 관련 문제를 포착할 수 있고, 후자는 관리가 더 쉽습니다.

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

여기서 한 걸음 더 나아가면, 이러한 자동화 테스트를 ClickHouse의 오픈 소스 테스트 인프라에 기여할 수도 있습니다. 이 인프라는 ClickHouse의 일상적인 개발 과정에서 지속적으로 사용됩니다. 실행 방법을 익히고, 이어서 테스트를 이 프레임워크에 맞게 조정하는 데에는 분명 추가 시간과 노력이 들겠지만, 그만한 가치가 있습니다. 이렇게 하면 ClickHouse 릴리스가 안정 버전으로 발표될 때 이미 해당 테스트를 통과했는지 확인할 수 있고, 문제가 발생한 뒤에야 이슈를 반복해서 보고하고 버그 수정이 구현되고 백포트되어 릴리스되기를 기다리느라 시간을 낭비하는 일을 줄일 수 있습니다. 일부 회사는 이를 내부 정책으로 운영하며, 인프라를 사용하는 대가로 이러한 테스트 기여를 요구하기도 합니다(Google에서는 Beyonce’s Rule이라고 부릅니다).

프리프로덕션 환경과 테스트 인프라를 마련했다면, 최적의 버전을 선택하는 과정은 간단합니다:

1. 새로운 ClickHouse 릴리스에 대해 자동화 테스트를 정기적으로 실행하십시오. testing으로 표시된 ClickHouse 릴리스에 대해서도 실행할 수는 있지만, 그 상태로 다음 단계까지 진행하는 것은 권장되지 않습니다.
2. 테스트를 통과한 ClickHouse 릴리스를 프리프로덕션 환경에 배포하고, 모든 프로세스가 기대한 대로 실행되는지 확인하십시오.
3. 발견한 문제를 ClickHouse GitHub Issues에 보고하십시오.
4. 중대한 문제가 없다면 ClickHouse 릴리스를 프로덕션 환경에 배포하기 시작해도 안전합니다. canary releases 또는 green-blue deployments와 비슷한 접근 방식을 구현하는 점진적 릴리스 자동화에 투자하면 프로덕션에서의 문제 위험을 더 줄일 수 있습니다.

이미 눈치채셨겠지만, 위에서 설명한 접근 방식에는 ClickHouse에만 해당하는 특별한 내용이 없습니다. 프로덕션 환경을 진지하게 다루는 사람들은 자신이 의존하는 모든 인프라 구성 요소에 대해 이런 방식으로 운영합니다.

​

ClickHouse 릴리스 중 무엇을 선택해야 할까요?

ClickHouse 패키지 리포지토리의 내용을 보면 두 가지 종류의 패키지가 있습니다.

1. stable
2. lts (장기 지원)

다음은 둘 중 하나를 선택할 때 참고할 수 있는 가이드입니다.

• stable은 기본적으로 권장하는 패키지 유형입니다. 대체로 매월 릴리스되므로 새로운 기능을 비교적 빠르게 사용할 수 있으며, 최신 stable 릴리스 3개에 대해서는 진단과 버그 수정 백포트가 지원됩니다.
• lts는 연 2회 릴리스되며, 최초 릴리스 후 1년 동안 지원됩니다. 다음과 같은 경우에는 stable보다 lts가 더 적합할 수 있습니다.
  • 회사 내부 정책상 잦은 업그레이드나 LTS가 아닌 소프트웨어 사용이 허용되지 않는 경우
  • ClickHouse를 보조적인 제품에서 사용하고 있고, 해당 제품이 복잡한 ClickHouse 기능을 필요로 하지 않거나 최신 상태로 유지할 만큼 충분한 리소스가 없는 경우

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

---

ClickHouse를 업그레이드할 때 한 가지 더 유의할 점이 있습니다. 릴리스 간 호환성은 항상 면밀히 살피고 있지만, 경우에 따라 이를 계속 유지하는 것이 합리적이지 않아 일부 사소한 세부 사항이 바뀔 수 있습니다. 따라서 업그레이드하기 전에 changelog를 확인하여 하위 호환되지 않는 변경 사항에 관한 참고 사항이 있는지 반드시 확인하십시오.