• 다중화(= 고가용성)
    • DB 서버 2대 중 1대가 고장시 나머지 1대로 서비스의 정지 막을 수 있음

아키텍처(Architecture)

  • 시스템을 만들기 위한 물리 레벨의 조합 = 하드웨어와 미들웨어의 구성
    • 어떤 기능을 가진 서버를 준비하고 어떠한 저장소나 네트워크 기기와 조합할 것인지
  • 아키텍처를 설계 하려면 데이터베이스, 서버, OS, 기타 미들웨어, 저장소, 로드밸런서에 방화벽 같은 네트워크 기기까지 폭넓은 지식 필요
  • 아키텍처는 시스템의 목적과 기능을 표현함
    • 아키텍처를 보면 시스템의 용도, 목적을 추측할 수 있음
  • 아키텍처 설계는 시스템 개발의 초반에 매우 중요한 일
    • 시스템 개발 후반에 변경하기 힘드므로 프로젝트의 성패는 초반에 결정됨

데이터베이스 아키텍처

1. 역사와 개요

1. Stand-alone(~1980년대)

  • 데이터베이스만으로 시스템이 성립하는 가장 간단한 구성
  • DB 서버가 LAN이나 인터넷 등의 네트워크에 접속하지 않고 독립되어 동작하는 구성
  • 미들웨어(DBMS)와 애플리케이션은 같은 DB 서버에서 동작
  • 소규모 작업 환경이나 테스트 환경에 사용

단점

  • 물리적으로 떨어진 장소에서 접근 못함
  • 복수 사용자가 동시에 작업 못함
  • 가용성(Availability)이 낮음
    • 시스템이 서비스 제공시간에 장애 없이 계속 사용 가능한 정도
    • 서버가 1대 여서 장애 생기면 그 시점부터 서비스가 정지됨
  • 확장성(Scalability) 부족
    • 서버가 1대 밖에 없어서 서버를 상위기종으로 교환 or 고성능 부품으로 교환하는 것 이외에 개선 방법이 없음

장점

  • 구축이 매우 간단해 소규모 작업이나 테스트를 빨리 할 수 있음
  • 보안이 매우 높음, 데이터 유출 위험 낮음
    • 네트워크 매개로 침입할 위험이 없음

2. 클라이언트/서버(1990년대~2000년대)

  • 서버 1대에 복수 사용자의 단말이 접속하는 구성
  • C/S or 클라서버 라고도 함
  • 클라이언트와 서버 2개 레이어(계층)으로 2계층 구성이라고도 함
    • 클라이언트 -> 업무 애플리케이션 동작
    • 서버 -> DBMS가 동작
  • 기업이나 조직 내에 닫힌 네트워크(LAN)에서 제한된 용도의 시스템으로 이용

단점

  • 보안 위험
    • 네트워크로 데이터베이스에 접속할 위험성
  • 애플리케이션 관리비용이 많이 듬
    • 개인이 이용하는 PC에 애플리케이션을 설치해 동작하게 함
      -> 네이티브(Native) 애플리케이션

3. Web 3계층(2000년대~현재)

  • 클라서버의 비용절감을 위해 비지니스 로직을 실행하는 애플리케이션을 서버둔 구성
  • 시스템을 3가지 계층의 조합으로 생각하는 모델

구성

  • 웹 서버 계층
    • 클라에서 HTTP 요청을 받아 애플리케이션 계층에 넘기고 그 결과를 클라이언트에 반환
    • 클라이언트 웹 브라우저와 애플리케이션 서버를 연결하는 역할
    • 아파치(Apache), IIS(Internet Information Services)
  • 애플리케이션 계층
    • 비지니스 로직을 구현한 애플리케이션이 동작하는 계층
    • 웹 서버의 요청을 처리하고 필요하면 DB 계층에 접속하여 데이터를 추출 및 가공하여
      웹 서버에 반환
    • 톰캣(Tomcat), 웹로직(WebLogic), 웹스피어(WebSphere)
  • 데이터베이스 계층

장점

  • 사용자 HTTP 요청은 웹 서버 계층에 한정하여 애플리케이션 계층과 데이터베이스 계층의
    보안을 높일 수 있음
  • 애플리케이션 계층에 비지니스 로직을 집중해 애플리케이션 관리비용 낮춤

2. 가용성과 확장성의 확보

  • 아키텍처 설계에서 견고한 시스템 설계를 위해 가용성이 가장 중요함

가용성을 높이는 2가지 전략

  • 심장전략(고품질-소수전략)
    • 시스템을 구성하는 각 컴포넌트의 신뢰성을 높여 장애 발생률 낮게 억제해서 가용성을 높임
      -> 소수정예 노선
  • 신장전략(저품질-다수전략)
    • 시스템을 구성하는 컴포넌트의 여분을 준비 -> 물량작전

클러스터링(Clustering) = 다중화 = 고가용성

  • 신장전략처럼 동일한 기능의 컴포넌트를 복수 개 준비해 한 개의 기능을 실현한 것

단일 장애점(SPOF, Single Point of Failure)

  • 다중화 되어 있지 않아 시스템 전체 서비스의 계속성에 영향을 주는 컴포넌트

DB 서버의 다중화 - 클러스터링

기본적인 다중화

  • DB 서버만 다중화하고 저장소는 하나만 두는 구성
  • DB 서버 2대가 동시에 동작하는 것을 허락할지에 따라 2개로 나뉨
    • Active - Active
    • Active - Standby

단점

  • 서버 부분은 다중화할 수 있으나 저장소 부분은 다중화할 수 없음

Active - Active

  • 클러스터를 구성하는 컴포넌트를 동시에 가동
  • 현재 Oracle은 RAC, DB2는 pureScale로 Active-Active 클러스팅 가능

장점

  • 시스템 다운 시간이 짧음
  • 성능이 좋음

Active - Standby

  • 클러스터를 구성하는 컴포넌트 중 실제 가동하는 것은 Active, 남은 것은 Standby
  • Standby 상태의 DB 서버는 사용되지 않다가 Active DB 서버에 장애 일어나면 사용됨
    • 일정 간격으로 Active DB를 조사하기 위해 통신함 -> heartbeat

Active - Standby의 종류

  • Cold - Standby
    • 평소에 Standby DB 작동 안하다가 Active DB가 다운된 시점에 동작하는 구성
  • Hot - Standby
    • 평소에도 Standby DB가 작동하는 구성, 실제로 동작하는 것은 Active DB 1대뿐
    • 전환 시간은 짧지만 라이선스료가 비쌈
  • 라이선스료의 가격순
    • Active - Active
    • Active - Standby(Hot - Standby)
    • Active - Standby(Cold - Standby)

DB 서버의 다중화 - 리플리케이션(Replication, 복제)

  • DB 서버와 저장소 세트를 복수로 준비하는 것
  • Active 측 저장소의 데이터는 항상 사용자로 부터 갱신됨
  • Standby 측은 Active의 데이터를 최신화(동기화)해야함
  • Active 측 DB 서버에서 갱신된 데이터를 일정 주기로 Standby 측 DB에 써내려 감
  • Standby 측 갱신 주기와 성능 사이에 트레이드오프 관계
    • 갱신을 어느정도 생략하면 성능 향상 가능

성능을 추구하기 위한 다중화 - Shared Nothing

  • Shared Disk
    • 서버가 1대의 디스크를 사용하는 구성
    • DB 서버를 늘려도 무한으로 처리율 향상되지 않음
  • Shared Nothing
  • 아무것도 공유하지 않는 방식
  • 서버와 저장소의 세트를 늘리면 병렬처리 때문에 선형적으로 성능이 향상됨

reference

데이터베이스 첫걸음