본문으로 건너뛰기
피드

NHN클라우드, 티베로 TAC로 액티브-액티브 DB 클러스터 제공

backend 약 5분
vote
0
댓글
북마크

NHN클라우드가 티맥스티베로의 고가용성 DB 클러스터링 솔루션 티베로 액티브 클러스터(TAC)를 자사 클라우드에서 제공하기 시작했다. 여러 DB 서버가 동시에 동작하는 액티브-액티브 구조를 클라우드에 올려, 장애 대응과 재해복구(DR)를 같이 노리는 흐름이다.

  • 1

    TAC는 여러 데이터베이스 서버를 하나의 시스템처럼 묶는 고가용성 DB 클러스터링 솔루션

  • 2

    NHN클라우드는 공유 저장소와 전용 네트워크 인터페이스를 자사 인프라에 맞춰 최적화

  • 3

    민간존과 공공존 모두 제공되며 공공기관의 재해복구 수요를 겨냥

  • 4

    물리 장비 증설 없이 서버 노드를 추가해 트래픽 증가에 대응 가능

  • NHN클라우드가 티맥스티베로의 고가용성 데이터베이스(DB) 클러스터링 솔루션 ‘티베로 액티브 클러스터(TAC)’를 자사 클라우드에서 제공하기 시작함

    • TAC는 여러 대의 DB 서버를 하나의 시스템처럼 묶어 운영하는 솔루션
    • 이번 발표의 핵심은 이 구조를 클라우드 환경에 맞게 최적화해 정식 제공한다는 점임
  • 포인트는 액티브-액티브(Active-Active) 구조임

    • 여러 DB 서버가 동시에 활성화된 상태로 같은 작업을 처리하는 방식
    • 장애가 나도 대기 서버를 깨우는 게 아니라 이미 동작 중인 다른 노드가 이어받을 수 있음
    • 일정 주기로 예비 서버를 세워두는 액티브-스탠바이(Active-Standby) 방식보다 서비스 연속성과 데이터 손실 방어 측면에서 더 공격적인 구조임

중요

> 이번 건은 단순히 DB 상품 하나 추가한 게 아니라, 구현 난도가 높은 액티브-액티브 DB 구성을 국내 클라우드 환경에서 제공한다는 쪽에 의미가 있음.

  • NHN클라우드와 티맥스티베로는 TAC의 공유 저장소와 전용 네트워크 인터페이스를 NHN클라우드 인프라에 맞춰 손봤다고 밝힘

    • 두 회사는 올해 3월 국산 기술 기반 AI 인프라 협력을 맺은 뒤 이 최적화 작업을 진행해 왔다고 함
    • 액티브-액티브 DB는 저장소, 네트워크, 노드 간 동기화가 맞물려야 해서 그냥 VM 몇 대 띄운다고 되는 구성이 아님
  • 고객 입장에서는 물리 장비를 먼저 사두지 않고도 필요한 시점에 DB 서버 노드를 늘릴 수 있다는 게 장점임

    • 트래픽이 늘면 스케일 아웃 방식으로 대응 가능
    • 초기 장비 투자 부담을 줄이고, 필요한 만큼 자원을 늘리는 클라우드식 운영에 가까워짐
  • 제공 범위는 민간존과 공공존 모두임

    • 특히 공공기관 쪽은 최근 재해복구(DR) 체계 구축 요구가 커지고 있음
    • NHN클라우드는 고가용성 인프라와 DR 환경을 같이 설계할 수 있도록 지원하겠다는 입장
  • 업계 배경도 꽤 명확함. AI 확산과 데이터 활용 증가로 서비스 중단을 참아줄 수 있는 시간이 점점 짧아지고 있음

    • 예전에는 ‘장애 나면 복구하면 되지’에 가까웠다면, 이제는 장애 중에도 서비스가 계속 굴러가야 하는 쪽으로 기대치가 올라감
    • 그래서 고가용성(HA)과 재해복구(DR)를 따로 보는 게 아니라 아키텍처 설계 단계에서 같이 묶어 보는 수요가 늘고 있음

기술 맥락

  • 이번 선택의 핵심은 DB 고가용성을 클라우드 인프라 레벨에서 풀어보겠다는 거예요. 액티브-액티브 DB는 여러 노드가 동시에 살아 있어야 하니까, 단순 백업이나 대기 서버 구성보다 저장소와 네트워크 조건이 훨씬 까다롭거든요.

  • NHN클라우드가 공유 저장소와 전용 네트워크 인터페이스를 최적화했다고 강조한 이유도 여기에 있어요. DB 노드들이 같은 데이터를 안정적으로 바라보고, 장애 상황에서도 상태가 꼬이지 않게 하려면 인프라 쪽 지연 시간과 연결 안정성이 꽤 중요해요.

  • 공공존까지 제공한다는 점도 그냥 영업 문구로 보기 어렵습니다. 공공기관은 국산 기술, 망 분리, 재해복구 같은 요구가 강하게 붙는 경우가 많아서 외산 매니지드 DB 하나로 끝내기 어려운 케이스가 있거든요.

  • 개발팀이나 인프라팀 입장에서는 이게 바로 앱 성능을 올려주는 뉴스라기보다는, 장애 대응 설계를 어디까지 클라우드 서비스로 넘길 수 있느냐의 문제에 가까워요. 특히 DB가 병목이거나 단일 장애점이 되는 시스템에서는 이런 선택지가 생기는 것 자체가 의미가 있어요.

국산 DBMS와 국내 클라우드 조합으로 액티브-액티브 DB를 클라우드에서 제공한다는 점이 포인트다. 공공·금융처럼 장애 허용 시간이 짧은 곳에서는 ‘국산 스택으로 어디까지 버틸 수 있나’가 꽤 현실적인 선택지가 될 수 있다.

댓글

댓글

댓글을 불러오는 중...

backend

클릭하우스가 PgBouncer 처리량을 4배로 끌어올린 방법

ClickHouse Managed Postgres 팀은 단일 스레드인 PgBouncer를 여러 프로세스로 띄우고 `so_reuseport`와 피어링(peering)을 조합해 16 vCPU 머신을 제대로 쓰게 만들었다. 동일한 AWS 환경에서 단일 프로세스는 약 8.7만 TPS 근처에서 막혔지만, 16개 프로세스 구성은 약 33.6만 TPS까지 올라갔다.

backend

SQLite 쓸 거면 STRICT 테이블을 기본값으로 보자는 주장

SQLite의 STRICT 테이블은 INTEGER 컬럼에 문자열이 들어가는 식의 타입 실수를 막아주는 기능이다. 글쓴이는 SQLite 특유의 유연한 타입 시스템보다, 실수는 빨리 터뜨리는 쪽이 실무에서 낫다고 주장한다. 다만 기존 테이블을 바로 STRICT로 바꾸기 어렵고, SQLite 3.37.0 이상에서만 쓸 수 있다는 제약도 있다.

backend

왜 아직도 Lisp를 배워볼 만한가

Lisp는 괄호가 많은 이상한 언어처럼 보이지만, 핵심은 문법이 아니라 언어 자체를 확장할 수 있다는 점에 있음. 매크로, 코드-데이터 동일성, REPL 중심 개발이 합쳐지면 프로그램을 '작성'한다기보다 살아 있는 시스템을 계속 진화시키는 방식으로 개발하게 됨.

backend

EDB 포스트그레스 AI, 포레스터 멀티모델 데이터 플랫폼 리더 선정

EDB의 AI 데이터 플랫폼 EDB 포스트그레스 AI가 2026년 2분기 포레스터 웨이브 멀티모델 데이터 플랫폼 보고서에서 리더로 선정됐음. 트랜잭션, 분석, AI 워크로드를 하나의 플랫폼에서 다루는 흐름이 강해지는 가운데, EDB는 전략과 현재 제공 기능 모두에서 높은 평가를 받았다고 밝힘.

backend

Bun, Zig에서 Rust로 갈아탔다: 11일짜리 초대형 런타임 포팅 실험

Bun 팀이 53만 줄이 넘는 Zig 코드베이스를 Rust로 기계적으로 포팅했고, Bun v1.4.0부터 Rust 기반으로 전환될 예정임. 핵심 이유는 성능보다 안정성이었고, use-after-free, double-free, 메모리 누수 같은 문제를 컴파일러와 타입 시스템으로 더 빨리 잡기 위해서였음. Claude Code 워크플로 64개를 병렬로 돌려 11일 만에 전 플랫폼 테스트 통과까지 밀어붙인 사례라, LLM 기반 대규모 코드 마이그레이션의 꽤 강한 신호탄임.