본문으로 건너뛰기
피드

NHN클라우드, 티베로 액티브 클러스터로 공공 클라우드 고가용성 DB 공략

backend 약 5분
vote
0
댓글
북마크

NHN클라우드가 티맥스티베로의 고가용성 DB 클러스터링 솔루션 TAC를 자사 클라우드에서 제공한다. 온프레미스에서 주로 쓰이던 액티브-액티브 DB 클러스터링을 클라우드 환경에 맞게 최적화해 공공·기업 고객의 무중단 운영과 재해복구 수요를 겨냥한다.

  • 1

    NHN클라우드는 티맥스티베로의 TAC를 민간존과 공공존 모두에 제공함

  • 2

    TAC는 여러 DB 서버가 동시에 활성 상태로 동일 작업을 처리하는 액티브-액티브 클러스터링 솔루션임

  • 3

    액티브-스탠바이보다 자원 활용도와 장애 대응 안정성이 높지만, 고성능 공유 저장소와 네트워크 구성이 필요해 클라우드 구현 난도가 높음

  • 4

    클릭 몇 번으로 신규 노드를 추가하고 스케일아웃할 수 있어 초기 물리 장비 구축 비용을 줄일 수 있음

  • NHN클라우드가 티맥스티베로의 고가용성 DB 클러스터링 솔루션을 클라우드에서 제공함

    • 대상 솔루션은 티베로 액티브 클러스터(Tibero Active Cluster, TAC)임
    • 민간존과 공공존 모두에 제공해 공공·기업 시장을 같이 노림
  • TAC의 핵심은 액티브-액티브 DB 클러스터링임

    • 여러 대의 데이터베이스 서버가 모두 활성화된 상태에서 동일한 작업을 동시에 처리함
    • 특정 서버에 장애가 발생해도 데이터 안정성과 서비스 연속성을 유지할 수 있음
  • 액티브-스탠바이와 비교하면 장단점이 뚜렷함

    • 액티브-스탠바이는 주 서버가 일하고 대기 서버가 장애 시 넘어받는 방식에 가까움
    • 액티브-액티브는 복수 서버가 동시에 일을 처리해서 자원 활용도가 높고 장애 대응도 더 안정적임
    • 대신 고성능 공유 저장소와 네트워크 구성이 필수라 클라우드 환경에서 구현 난도가 높다고 평가됨

중요

> 이 건의 포인트는 “DB를 클라우드에 올렸다”가 아니라, 구현 난도가 높은 액티브-액티브 DB 구성을 국산 클라우드 상품으로 제공한다는 데 있음.

  • NHN클라우드는 지난 3월 티맥스티베로와 국산 기술 기반 AI 인프라 구축 업무협약을 맺은 뒤 TAC를 최적화함

    • TAC의 고성능 공유 저장소와 전용 네트워크 인터페이스를 NHN클라우드 환경에 맞게 조정함
    • 온프레미스에서 주로 쓰이던 TAC를 클라우드 기반으로 제공할 수 있는 구조를 마련했다는 설명임
  • 고객 입장에서는 확장성과 비용 구조가 달라짐

    • 시스템 증설이 필요할 때 클릭 몇 번으로 신규 노드를 추가할 수 있음
    • 트래픽 증가에도 스케일아웃 방식으로 대응 가능함
    • 초기 물리 장비 구축 비용 없이 필요한 만큼 서버를 증설하거나 반납할 수 있음
  • 공공기관 타깃이 특히 중요함

    • 최근 공공 클라우드 전환과 함께 재해복구(DR) 체계 구축 필요성이 커지고 있음
    • NHN클라우드 기반 TAC를 쓰면 서비스 무중단 운영뿐 아니라 향후 DR 체계까지 고려한 인프라 설계가 가능하다는 메시지임
  • 양사 모두 얻는 게 있음

    • NHN클라우드는 안정성과 확장성을 앞세워 공공·기업 인프라 경쟁력을 강화할 수 있음
    • 티맥스티베로는 TAC와 클라우드 DB 서비스 아울디비(OwlDB)의 확산 기반을 넓힐 수 있음
    • 양사는 앞으로 AI 인프라와 데이터 플랫폼까지 협력 범위를 넓히겠다고 밝힘

기술 맥락

  • 이 기사에서 기술적으로 중요한 선택은 온프레미스 중심이던 액티브-액티브 DB 클러스터링을 클라우드 상품으로 제공하는 거예요. 공공·기업 시스템은 장애가 나도 멈추면 안 되는 업무가 많아서 DB 계층의 고가용성이 전체 서비스 신뢰도를 좌우하거든요.

  • 액티브-액티브 구성이 어려운 이유는 여러 DB 서버가 동시에 같은 데이터를 다루기 때문이에요. 저장소와 네트워크 지연, 동기화, 장애 감지, 트랜잭션 일관성이 다 맞아야 해요. 그래서 단순 VM 여러 대 띄우는 것과는 난도가 달라요.

  • NHN클라우드가 공유 저장소와 전용 네트워크 인터페이스를 최적화했다는 대목이 핵심이에요. TAC 같은 DB 클러스터는 인프라 레이어가 받쳐주지 않으면 성능이나 안정성이 바로 흔들리기 때문이에요.

  • 공공기관 입장에서는 초기 장비 구매 없이 노드를 늘리고 줄일 수 있다는 점도 중요해요. 하지만 더 큰 포인트는 재해복구와 무중단 운영을 클라우드 설계 단계에서 같이 가져갈 수 있다는 거예요. 클라우드 전환이 단순 이전이 아니라 운영 안정성 재설계가 되는 셈이에요.

공공 클라우드에서 DB 고가용성은 ‘있으면 좋은 기능’이 아니라 사업 수주 조건에 가까워지는 중임. 국산 클라우드와 국산 DBMS가 액티브-액티브 구성을 클라우드 상품으로 묶는 건 외산 의존도를 줄이려는 흐름과도 맞닿아 있다.

댓글

댓글

댓글을 불러오는 중...

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 기반 대규모 코드 마이그레이션의 꽤 강한 신호탄임.