텔레콤의 카우치베이스: 메가폰, 러시아

이고르 코발추크는 러시아 최대 통신 회사 중 하나인 MegaFon의 배포 관리자입니다. 그의 통신 분야 경력은 10년이 넘습니다. Egor의 팀은 러시아의 11개 시간대에 걸친 여러 비즈니스 시스템과 애플리케이션을 개발, 통합 및 모니터링하는 업무를 담당하고 있습니다.

텔레콤의 카우치베이스: 메가폰, 러시아

디지털 트랜스포메이션은 크고 작은 기업의 글로벌 트렌드입니다. 기업이 현대 고객의 요구에 적응하는 것은 필수적입니다. 고객은 업계 리더(Google, Amazon, Netflix)가 제공하는 고가용성 및 실시간 시스템에 익숙하며 모든 시장 참여자에게 동일한 경험을 요구합니다.

러시아 통신사들은 이러한 추세에 전적으로 영향을 받고 있습니다. 고객 친화적인 새로운 기능을 출시해야 합니다. 빠른 그리고 규모 쉽게. 우리는 대응해야 합니다. 빠르게 경쟁사의 움직임에 대응해야 합니다. 이 모든 기능을 제공하면서도 증가하는 IT 지출 비용(인프라, 데이터 센터, 숙련된 인력)을 관리해야 합니다. 바로 이때 인메모리 캐시 및 NoSQL 데이터베이스와 같은 새로운 기술이 유용하게 활용됩니다.

메가폰에서 인메모리 데이터베이스를 사용하는 다음 두 가지 사용 사례를 설명하겠습니다:

• 간단한 캐싱캐시는 데이터베이스 및 애플리케이션 이벤트뿐만 아니라 일정에 따라 채워지고 업데이트됩니다.
• 쓰기-스루 캐싱캐시의 변경 사항이 메인 데이터베이스로 전파됩니다(예: Oracle 데이터베이스가 Couchbase DCP 스트림에서 업데이트를 받음).

첫 번째 접근 방식은 가입자의 라이프사이클에 대한 의사결정 시스템에서 사용됩니다. 단일 애플리케이션이 여러 요소를 분석하여 결정을 내리고 변경 사항을 여러 시스템(오라클 데이터베이스 포함)으로 전송합니다. 이러한 애플리케이션의 예로는 선불 요금제 계정의 잠금 및 잠금 해제가 있습니다. 선불 금액이 모두 소진되면 계정이 잠기고 고객이 다시 충전할 때까지 서비스가 제공되지 않습니다. 계정이 재충전되면 가능한 한 빨리 서비스를 다시 활성화해야 합니다. 카우치베이스 사용 덕분에 서비스 복원 시간이 90초에서 30초로 단축되었지만 아직 개선의 여지가 남아 있습니다. 기본 데이터베이스에 전송되는 유일한 업데이트는 계정 상태 변경뿐입니다(아래 그림 1 참조).

그림 1: MegaFon 빠른 계정 상태 업데이트 프로세스

디지털 혁신 노력의 일환으로 Couchbase Server를 선택한 이유는 무엇일까요? 우리의 성능 요구 사항을 살펴보고 Couchbase가 이를 얼마나 잘 충족하는지 알아보겠습니다.

NoSQL 데이터베이스 성능 요구 사항

• 처리량: 초당 최대 200,000건의 요청을 처리합니다.
• 평균 지연 시간(50%), 단일 클러스터: 5ms 이내.
• 최대 지연 시간(99%), 단일 클러스터: 15ms 이내.
• 최대 삽입 처리량: 초당 500MB.
• 최대 삽입 작업 횟수: 초당 100,000회.
• 최대 업데이트 처리량: 초당 500MB.
• 최대 업데이트 작업 수: 초당 100,000회.
• 최대 읽기 처리량: 초당 500MB.
• 최대 읽기 작업 횟수: 초당 100,000회

고성능 키-값 데이터 액세스

Couchbase Server의 핵심은 분산 키-값(KV) 데이터베이스입니다. KV 스토리지는 임의의 정보(값)와 함께 고유 식별자(키)를 저장하는 간단한 데이터 관리 방식입니다. 값은 바이너리 객체(BLOB/blob) 또는 JSON 문서일 수 있습니다. KV 구현의 단순성(특히 관계형 데이터베이스와 비교할 때)으로 인해 데이터 액세스는 최소한의 지연 시간으로 제공됩니다. 저희 배포에서는 네트워크 지연 시간이 Couchbase 클러스터에서 KV 작업을 완료하는 데 걸리는 시간보다 2~3배 더 높은 경우가 많습니다.

유연한 데이터 형식(JSON)

JSON(JavaScript 객체 표기법)은 Couchbase에서 선호하는 데이터 저장 형식입니다. 이 형식은 기본 유형(부울, 숫자, 문자열)과 복합 유형(배열, 목록, 사전) 데이터 유형을 모두 지원합니다.

JSON 문서의 데이터 스키마는 변화하는 애플리케이션 요구사항에 따라 쉽게 변경할 수 있습니다. 추가 문서 필드를 통해 다양한 스키마 버전을 추적할 수 있어 원활한 애플리케이션 업그레이드와 이전 버전과의 호환성을 보장합니다.

고가용성

Couchbase Sever는 데이터의 고가용성(HA)을 지원하기 위한 몇 가지 기능을 제공합니다. 클러스터 내 데이터 복제 (단일 클러스터 내의 여러 서버에 여러 데이터 복사본을 배포)는 정기적인 서버 유지보수 또는 예기치 않은 서버 장애 시에도 데이터 100%를 계속 사용할 수 있게 해줍니다.

그림 2: Couchbase 클러스터 내 복제

데이터베이스 변경 프로토콜(DCP)은 Couchbase의 또 다른 중요한 HA 구성 요소입니다. 이 고성능 스트리밍 프로토콜은 데이터 변경 사항을 내부 및 외부 소비자에게 전달합니다. SQL 쿼리, 전체 텍스트 검색(FTS) 인덱스, 데이터 센터 간 복제(XDCR, 클러스터 간 복제 프로토콜) 및 기타 서비스에 사용되는 글로벌 보조 인덱스(GSI)를 유지 관리하는 역할을 담당합니다.

양방향(클러스터 간) 복제

애플리케이션과 장비를 이중화하는 것은 업계에서 오랫동안 모범 사례로 여겨져 왔습니다. 이상적으로는 분산 데이터베이스 는 연결 문제가 발생할 경우 애플리케이션이 자동으로 다른 클러스터로 전환되는 액티브-액티브(AA) 아키텍처를 사용하여 배포되며, 문제가 있는 노드 간 전환이 자동으로 발생하는 모드입니다. 카우치베이스 서버는 AA 시나리오를 활성화하기 위해 양방향 XDCR을 지원합니다. 그러나 다중 클러스터 배포에서 데이터의 최종적인 일관성은 특정 비즈니스 애플리케이션의 경우 허용되지 않을 수 있습니다.

저희 환경에서는 데이터 센터가 100km 이상 떨어져 있는 경우 데이터 충돌 해결이 어렵다는 것을 알게 되었습니다. 카우치베이스는 리비전 기반과 타임스탬프 기반의 두 가지 충돌 해결 메커니즘을 제공합니다. 네트워크 지연 시간으로 인해 두 가지 메커니즘 모두 전체 AA 시나리오(모든 클러스터에서 쓰기와 읽기가 발생할 수 있는 경우)에서 허용 가능한 데이터 일관성을 제공할 수 없었습니다. 그 결과, 모든 변경(쓰기)이 단일 클러스터에서 이루어지고 다른 데이터센터에 변경 사항을 전파하는 아키텍처를 구현했습니다. 애플리케이션은 어느 데이터 센터에서든 데이터를 읽을 수 있습니다.

수평 스케일링

수평 확장(새 서버를 추가하여 클러스터 리소스를 늘리는 것)은 NoSQL 데이터베이스의 큰 판매 포인트입니다. Couchbase Server의 중요한 기능은 다양한 클러스터 부하(KV 작업, SQL 쿼리, 데이터 인덱싱 등)를 독립적으로 확장할 수 있는 기능으로, Couchbase에서는 이를 "다차원 확장, MDS"라고 부릅니다(아래 그림 3 참조). Couchbase 클러스터의 모든 노드는 단일 서비스 또는 여러 서비스를 실행할 수 있으며, 노드가 기존 클러스터에 추가될 때 선택이 이루어집니다.

그림 3: 카우치베이스 다차원 스케일링(MDS)

정보 보안 요구 사항

카우치베이스의 보안 기능도 주요한 이유는 아니었지만 이 시스템을 선택한 또 다른 이유였습니다. 개인 식별 정보(PII)가 캐시에 저장될 수 있기 때문에 당사는 준거법을 준수해야 합니다. 데이터 플랫폼이 필요한 보안 기능을 제공하지 않는 경우, 규정을 준수하기 위해 추가 하드웨어를 구매해야 할 수도 있습니다.

카우치베이스 서버 엔터프라이즈 에디션(EE)은 트래픽 암호화, 데이터 암호화, 역할 기반 액세스 제어(RBAC)를 지원합니다. 이를 통해 Cisco ASA와 같은 네트워크 보안 하드웨어를 절약할 수 있습니다.

손쉬운 업그레이드

카우치베이스 서버는 여러 가지 업그레이드 옵션을 제공합니다. 온라인 업그레이드 옵션을 사용하면 API 이전 버전과의 호환성으로 인해 성능 및 기능에 미치는 영향을 최소화하면서 애플리케이션이 클러스터에서 계속 작동할 수 있습니다. 클러스터 노드가 업그레이드되는 동안 클러스터는 호환 모드에서 계속 작동하며, 모든 노드가 업그레이드를 완료하면 새 버전의 기능이 활성화됩니다.

추가 기능

서버 그룹 인식(랙 인식, 가용 영역)

Couchbase에서는 개별 서버를 특정 서버 그룹에 할당할 수 있습니다. 이 기능은 클라우드 서비스 가용 영역(AZ)과 유사합니다. 서버 그룹을 사용하면 활성 데이터 및 복제본의 배포 알고리즘을 통해 전체 서버 그룹이 오프라인 상태일 때에도 완전한 데이터 가용성을 보장합니다.

통신사에서는 이를 통해 데이터센터의 여러 장비실에 완전히 복제된 데이터세트를 보관할 수 있습니다. 전체 장비실(카우치베이스 서버 그룹에 매핑된)이 오프라인 상태가 되더라도 애플리케이션은 다른 장비실에 있는 전체 데이터세트로 계속 작업할 수 있습니다.

그림 4: Couchbase 서버 그룹

백업 및 복원

Couchbase는 여러 백업 및 복구 도구를 제공하며, cbbackupmgr은 EE에서만 사용할 수 있습니다. 백업은 전체, 차등, 누적의 세 가지 방식으로 수행할 수 있습니다. 이러한 백업 모드를 올바르게 조합하면 디스크 공간을 절약하고 시스템 리소스 사용을 최적화할 수 있습니다.

그림 5: 카우치베이스 백업 결합

카우치베이스 대 몽고DB

사용 가능한 경쟁 기술 중에서 NoSQL 데이터베이스를 선택하는 것은 어려울 수 있습니다. [적어도 Linux OS를 사용하면 더 쉽습니다. 시스템 관리자가 가장 잘 아는 Linux 배포판이 가장 좋습니다.] 아래 표에는 또 다른 인기 있는 NoSQL 플랫폼인 MongoDB 대신 Couchbase 기술을 선택하게 된 몇 가지 중요한 차이점이 요약되어 있습니다.

아키텍처와 기능이 서로 다른 두 프로젝트를 비교하는 것은 분명 어려운 일입니다. 유지 관리가 용이하고 변화하는 비즈니스 요구사항에 빠르게 적응할 수 있는 시스템을 갖추는 것이 중요했습니다.

전반적으로 Couchbase는 MegaFon의 사용 사례와 지속적으로 진화하는 하이브리드 아키텍처를 위해 더 유연하고 유지 관리 및 구성이 용이합니다.

지금까지의 카우치베이스 여정

다음은 프로덕션 카우치베이스 클러스터와 그 부하에서 얻은 몇 가지 간단한 통계입니다:

• 이 클러스터는 8천만 명 이상의 가입자의 데이터를 처리합니다. 이 숫자에는 휴대폰, LTE 라우터, SIM 카드가 내장된 여러 소비자 디바이스 등이 포함됩니다.
• 고객 데이터가 포함된 3억 8천만 개의 JSON 문서
• 3.5TB 디스크 스토리지(활성 데이터 세트, 복제본은 포함되지 않음)
• 3TB RAM
• 초당 50,000번의 작업, 지속적(아래 그림 6 참조)
• 전체 메시지 흐름을 처리하는 50개의 마이크로서비스

그림 6: 카우치베이스 프로덕션 부하

이 전환 프로젝트는 Couchbase Server 버전 3.x에서 시작되었습니다. 처음에는 모든 애플리케이션이 안정적으로 작동했습니다. 하지만 Couchbase 뷰 사용에 의존하는 새로운 애플리케이션 기능을 추가하면서 뷰의 예측할 수 없는 동작에 문제가 발생하기 시작했습니다. [뷰는 맵/축소 인덱싱 및 쿼리 메커니즘입니다. 글로벌 보조 인덱스 및 N1QL 쿼리를 위해 단계적으로 폐지되고 있습니다.] 노드의 보기 업데이트 프로세스가 가끔 중단되어 애플리케이션이 이 노드에서 보기 데이터를 수신하지 못하는 경우가 있었습니다. KV 작업은 계속 정상적으로 수행됩니다.

이 문제는 데이터 가용성에 영향을 미치는 노드를 다시 시작하면 해결할 수 있습니다. 임시 해결 방법으로(Couchbase Server 버전 4.x로 업그레이드할 계획이었으나), Couchbase 기술 지원팀은 다음과 같은 버전별 문서화되지 않은 명령을 사용하여 보기 업데이트 프로세스만 다시 시작하도록 제안했습니다:

카우치베이스 서버 버전 3.x에서 발생한 또 다른 문제는 압축 프로세스가 주기적으로 종료되는 것이었습니다. 모니터링 알람을 받으면 프로세스를 수동으로 다시 시작해야 했습니다. 이 두 가지 프로덕션 문제는 운영팀과 개발팀 모두에게 골치 아픈 문제였습니다.

프로덕션 애플리케이션에 미치는 영향을 최소화해야 했기 때문에 전체 업그레이드 프로세스는 약 2주 정도 걸렸고, Couchbase 기술 지원팀의 권유에 따라 Couchbase Server 버전 4.x로 업그레이드하기로 결정했습니다. 업그레이드 단계는 매우 간단하지만 노드 제거, 재조정, 노드 업그레이드, 클러스터에 노드 추가 및 또 다른 재조정을 포함한 롤링 온라인 업그레이드에는 2시간 이상이 소요됩니다. 저희는 추가 노드를 도입하여 Couchbase 스왑 리밸런싱을 활용함으로써 이 프로세스를 최적화할 수 있었습니다. 이 경우 데이터가 제거되는 노드에서 추가되는 노드로 직접 복사되므로 리밸런싱 속도가 크게 빨라집니다. 이를 통해 노드당 업그레이드 시간이 30분으로 단축되었습니다.

프로덕션 Couchbase 클러스터를 업그레이드할 때는 모든 노드에서 이전 버전의 기능만 사용할 수 있는 호환 모드에서 클러스터가 작동한다는 점을 염두에 두어야 합니다. 이렇게 하면 원활하고 간편하게 업그레이드할 수 있습니다. 단점은 업그레이드된 버전의 새로운 기능 및 수정 사항(N1QL 인덱스 및 쿼리, 전체 텍스트 검색 등)은 클러스터의 모든 노드가 업그레이드된 경우에만 사용할 수 있다는 것입니다.

4.x 버전으로의 초기 업그레이드에서는 압축 문제만 해결되었습니다. 보기 문제는 자주 발생하지는 않았지만 여전히 남아 있었습니다. 이 문제는 카우치베이스 서버 버전 4.6.4에서만 완전히 해결되었습니다.

또한 Couchbase 기술 지원팀으로부터 뷰 기능이 더 이상 개선되지 않고 사용 중단될 예정이라는 통보를 받았습니다. 글로벌 보조 인덱스(GSI) 및 N1QL("니켈"로 발음, Couchbase SQL 구현) 쿼리는 훨씬 더 확장성이 뛰어난 뷰의 대안입니다. 인덱스 및 쿼리 로드는 데이터 노드에 묶이지 않고 독립적으로 확장할 수 있습니다(아래 그림 7 참조):

그림 7: 다양한 노드의 카우치베이스 서비스

Couchbase Server 4.6.4로 업그레이드하면서 중요한 프로덕션 문제를 모두 해결했습니다. 하지만 Couchbase Server 5.1의 새로운 기능과 개선 사항으로 인해 또 한 번의 업그레이드 주기를 완료해야 했습니다. 새로운 GSI 엔진을 통해 이제 인덱스가 디스크와 메모리 공간을 약 1.5배 덜 차지하므로 데이터 볼륨 증가에 도움이 됩니다. 안타깝게도 버전 5.1에서는 데이터 스토리지(인메모리 또는 온디스크)에 대한 개선 사항은 제공되지 않습니다. 데이터 압축은 버전 5.5에 추가되었습니다.

결론

전반적으로 Couchbase Server는 성숙한 고성능 데이터 플랫폼임이 입증되었습니다. 메가폰 하이브리드 아키텍처의 일부인 카우치베이스 클러스터는 장비 다운타임이나 서버의 광범위한 구성 변경 없이 모든 생산 부하에 쉽게 적응할 수 있습니다. 이는 일반적으로 인건비 절감과 고객 만족으로 이어집니다.

이 글의 원본은 러시아의 인기 협업 IT 블로그인 하브라하브르에 게시되었습니다: https://habr.com/ru/post/436762/