아키텍쳐란
시스템을 만들기 위한 물리 레벨의 조합
간단하게 시스템의 목적과 기능을 나타낸다.
아키텍쳐는 돈과도 밀접한 관련이 있다. 고기능의 아키텍쳐를 무리하게 선택하면 예산초과로 실패할 수 있으면 반대로 너무 기능이 떨어지는 아키텍쳐를 선택하여 실패하는 경우도 있다.
데이터베이스의 아키텍쳐
데이터베이스 아키텍쳐의 역사는 3가지로 나누어서 볼 수 있다.
Stand-alone, 클라이언트/서버, Web 3계층
Stand-alone은 데이터베이스가 LAN같은 네트워크에 접속하지 않고 독립되어 동작하는 아키텍쳐
이러한 Stand-alone은 네트워크가 연결되어 있지 않아 물리적으로 떨어진 장소에선 접근할 수 없고 서버를 이용할 수 없기 때문에 복수의 사용자가 작업할 수 없다. 또한 1대의 데이터베이스의 문제가 생기면 그 시점부터 서비스가 정지하기 때문에 가용성이 낮다. 마지막으로 성능이 나빠질 경우 상위 기종의 데이터베이스로 변경하는 방법밖에 없기 때문에 확장성 또한 낮다. 반대로 Stand-alone의 장점으로는 물리적으로 떨어진 곳에서는 접근할 수 없기에 보안이 뛰어나다는 장점이 있고 구축이 간단하여 혼자 노트북을 사용해서도 만들 수 있다는 장점이 있다.
클라이언트/서버는 이러한 Stand-alone의 물리적으로 떨어진 곳에선 접근할 수 없고, 복수 사용자가 동시 작업을 할 수 없다는 단점을 극복하기 위해 데이터베이스를 네트워크에 연결하여 데이터베이스 서버 1대에 복수 사용자가 접속하는 구성으로 만들었다. 이 구성은 주로 기업이나 조직내에 닫힌 LAN으로 이용했는데 매우 정요한 정보를 축적하고 있다보니 외부의 접속을 허용할 수 없기 때문이다. 클라이언트/서버는 2가지 문제점으로 "인터넷에서 데이터베이스에 직접 접속하는 위험"과 "불특정 다수의 사용자가 사용할 시 관리비용이 많이 드는 점"이 있다.
다수의 사용자의 환경에 대응하여 애플리케이션을 만들고 그에 따른 장애 대응이나 버전 관리를 해야하기 때문의 비현실적인 비용이 필요해진다.
Web 3계층은 클라이언트/서버의 단점을 보완하여 애플리케이션 비용을 절감하고자 제시되었다.
웹 서버 계층, 애플리케이션 계층, 데이터베이스 계층 이렇게 3계층을 이루고 있다. 이 웹 3계층에서 웹 서버는 클라이언트로 부터 접속 요청을 받아서 애플리케이션 계층으로 넘긴 후 그 결과를 다시 클라리언트에 반환한다. 이렇게 사용자가 직접적인 요청을 받는 역할을 웹 서버로 한정시켜 보안을 높히고 애플리케이션에 로직을 집중하여 관리 비용을 낮추는 장점이 있다.
가용성과 확장성의 확보
가용성을 높이는 전략은 심장전략과 신장전략으로 두가지가 있다.
심장전략은 시스템을 구성하는 컴포넌트의 신뢰성을 높여 장애 발생률을 낮추는 방법이며, 신장전략은 컴포넌트가 망가지면 바로 대체 여분을 준비하는 방법이다.
현재는 이 두가지 방법 중 "신장전략"을 주로 선택하고 있다.
신장전략처럼 동일한 기능의 컴포넌트를 병렬화 하는 것을 클러스터링이라고 부르는데, 이러한 클러스터 구성으로 시스템의 가동률을 높히고 여유도를 확보하여 장애 발생률을 낮출 수 있다.
DB서버의 다중화-클러스터링
데이터베이스는 다른 서버들과 달리 다중화가 어려운 컴포넌트로 인식되었는데 데이터베이스는 다른 서버와 다르게 데이터를 장기간 보존해야하기 때문이다. 때문에 서버의 메모리나 로컬 저장소에서는 이런 조건을 충족하지 못하여 DB서버의 아키텍쳐는 저장소와 묶어서 생각해야한다.
가장 기본적인 다중화는 서버를 다중화 하고 저장소는 늘리지 않는 것이다. 서버를 늘려 안정성을 확보하지만 저장소는 그대로 두어 정합성을 신경쓰지 않아도 되는 방법이다. 이러한 다중화는 두가지로 나눌 수 있는데 Active-Active와 Active-standby이다. Active-Active는 두 서버가 항상 활성화 되어 있어 하나의 서버가 멈추어도 다른 서버가 동작하고 있어 시스템이 정지하는 상황을 막을 수 있다. 또한 두 서버가 동시에 가동하기 때문에 성능이 향상 된다. Active-standby는 반대로 하나의 서버만 활성화 되어 있고 활성화된 서버가 멈추면 다른 서버가 장애를 인식하고 활성화되는 방식이다. 이런 Active-standby는 또 두가지로 나눌 수 있는데 hot-standby와 cold-standby이다. hot-standby는 평소에 StandBy가 작동하고 있어 장애를 대응하고 활성화 하는 시간이 빠르다. cold-standby는 활성화된 서버가 멈춘 시점에 작동하기 때문에 장애 대응이 느리다. 이런 3가지 구성은 Active-Active, hot-standby, cold-standby 순으로 가격이 비싸다.
DB서버의 다중화-리플리케이션
리플리케이션은 서버만 다중화하는 것이 아닌 저장소도 다중화하는 구성이다. 이러한 구성은 데이터서버 전체가 지진 같은 상황으로 붕괴되는 상황을 대응하기 위한 구성이다.
이런 리플리케이션은 활성화된 데이터는 사용자로부터 갱신되지만 standby 데이터는 동기화 시에만 갱신되기 때문에 동기화를 1일 1회 한다고 하면 최대 1일분의 데이터가 소실될 수 있다.
때문에 리플리케이션은 어떤주기로 갱신할 것인지에 따라 성능의 트레이드 오프가 생긴다.
리플리케이션 구성은 자식, 손자, 증손자 세트를 만들 수 있다. 이런 구성을 피라미드형이라고 부른다. 피라미드형 구성은 데이터가 오래되도 참조만 하는 되는 처리를 손자나 증손자에서 맡아 부모에 걸리는 부하를 줄일 수 있다.
성능을 추구하기 위한 다중화 - Shared Nothing
Shared Nothing은 문자 그대로 아무것도 공유하지 않는다는 의미로 자원을 분리하는 방식이다.
이런 구성은 서버와 저장소 세트를 늘리면 병렬처리되기 때문에 성능이 향상된다. Shared Nothing은 비용대비 성능이 좋지만 결국 각각의 서버와 저장소가 서로 공유하지 않기 때문에 A라는 데이터베이스가 멈출 경우 다른 데이터베이스에서 이를 접근하거나 이어받을 수 없다는 단점이 있다.
