3. 데이터베이스 아키텍처

데이터베이스 아키텍처 역사

1. stand-alone        (~1980년대)
2. 클라이언트/서버  (1990년대~2000년대)
3. Web 3계층         (2000년대~)

1. stand-alone

DB 서버가 네트워크에 접속하지 않고 독립되어 동작하는 구성임.
DBMS와 소프트웨어가 같은 DB 서버에서 동작함.
사용자는 설치 장소로 물리적으로 접근해야 사용가능함.

단점

1. 물리적으로 떨어진 장소에서 접근 x
2. 복수 사용자가 동시 작업 x
3. 가용성이 크게 떨어짐. (1대밖에 없기 때문에 하나라도 정지하면 가용 못함, 장애 복구 어려움)
4. 확장성이 매우 떨어짐. (성능 개선 수단이 매우 부족함을 의미. 더 성능 좋은 서버로 교체하는 방법밖에 없음)

장점

1. 구축이 간단함.
2. 보안이 매우 좋음. (네트워크 침입이 불가능하기 때문에 물리적 접근을 제외하고 유출 위험이 거의 없음)

2. 클라이언트/서버

2계층 구성이라고도 부름.
네트워크 연결로 서버 1대에 복수 사용자 단말이 접근 가능함.
서버에서 DBMS가 동작하고, 클라이언트에서 업무 애플리케이션이 동작하는 분업 체제로의 전환을 의미하기도 함.

보안을 위해 주로 기업 또는 조직 내의 닫힌 네트워크(LAN)에서 이용됨. 즉, 외부 네트워크는 접속이 불가능.

단점

1. 인터넷을 통해 데이터베이스 접속이 가능하기 때문에 보안 위험이 증가함.

2. 불특정 다수 사용자가 사용하는 클라이언트 애플리케이션 관리 비용이 증가함.

   지금은 웹 브라우저로 동일하게 동작하지만 이 시대는 PC에 애플리케이션*을 따로 설치해 동작했음. 즉 비즈니스 로직이 수정되면 모든 PC에서 애플리케이션을 재설치해야함..
   (*이 때 PC에 설치되는 애플리케이션을 네티이브 애플리케이션이라 불렀으며 현재 스마트폰에 설치되는 애플리케이션의 시초같은 격임)

장점

1. 복수 사용자가 어느정도 물리적으로 떨어진 장소에서 접속이 가능함.

3. Web 3계층

클라이언트/서버 구조에서 클라이언트 애플리케이션 관리 비용의 문제로, 비즈니스 로직을 실행하는 애플리케이션을 서버에서 관리할 필요성이 대두됨.
이를 통해 생긴 게 Web 3계층임.

웹 서버
(웹) 애플리케이션 서버
DB 서버

3 계층으로 구성됨.

1. 웹 서버는 클라이언트의 접속 요청을 받아 애플리케이션 서버로 HTTP 요청을 보냄.
2. 웹 애플리케이션 서버는 HTTP 요청을 받아 비즈니스 로직을 수행하고 DB 서버에 데이터를 요청함.
3. DB 서버가 데이터를 반환하면 웹 애플리케이션 서버에서 가공 후 반환함.

장점

1. 사용자의 직접적인 접속 요청을 웹 서버에서 받아 처리하기 때문에 애플리케이션, DB계층의 보안이 유지됨.
2. 애플리케이션 계층에 비즈니스 로직을 집중시켜 관리 비용이 낮아짐.