3 계층 구조 (3 Tier Architecture / 3 티어 아키텍처) 란, 어떤 플랫폼을 3 계층으로 나누어 별도의 논리적/물리적인 장치에 구축 및 운영하는 형태를 말합니다. 예를 들어, 웹 서버를 운영하는 경우 서버 한대에 한꺼번에 모든 기능들을 구축하는 것이 아니라 데이터를 저장하고 읽는 데이터 계층, 데이터를 처리하는 어플리케이션 계층, 그리고 데이터를 표현해주는 클라이언트 (프레젠테이션) 계층 과 같이 3 계층으로 나누어 각각의 기능을 별도의 논리적/물리적인 장치에서 운영할 수 있습니다. 또는 2 계층, 혹은 4 계층 이상으로 나누어 운영을 할 수도 있으며 이 경우 다층 구조 (Multi-tier Architecture 또는 n-tier Architecture) 라고도 표현 할 수 있습니다.
일반적으로는 3 계층 구조를 널리 사용하기에 본 포스트 에서는 3계층 구조를 바탕으로 먼저 다음과 같은 각 계층을 통해 설명해보겠습니다.
– 프레젠테이션 계층 (Presentation Tier)
프레젠테이션 계층은 말 그대로 사용자가 직접 마주하게되는 계층을 의미합니다. 따라서 주로 사용자 인터페이스를 지원하며 (예> 인터넷 브라우저), 이 계층은 GUI 또는 프론트엔드 (front-end) 라고도 부릅니다. 그러므로 이 계층에서는 사용자 인터페이스와 관계 없는 데이터를 처리하는 로직 등은 포함하지 않습니다. 본 예시 에서는 주로 웹 서버를 뜻하고 있습니다. 주로 HTML, Javascript, CSS, 사진 자료 등이 이 계층에 해당 됩니다.
– 어플리케이션 계층 (Application Tier)
이 계층에서는 요청되는 정보를 어떠한 규칙을 바탕으로 처리하고 가공하는 것들을 담당합니다. (동적인 데이터를 제공) 비즈니스 로직 (Business Logic) 계층 또는 트랜잭션 (Transaction) 계층 이라고도 합니다. 첫 번째 계층 또는 클라이언트 계층에서 이 계층을 바라 보기에는 서버처럼 동작하고 (응답), 세 번째 계층의 프로그램에 대해서는 마치 클라이언트처럼 행동합니다 (요청). 따라서 이 계층은 미들웨어 (Middleware) 또는 백엔드 (back-end) 라고도 불립니다. 이 계층에서는 프레젠테이션 코드 (예> HTML, CSS) 나 데이터 관리를 위한 코드는 포함하지 않습니다. 주로 PHP, Java 등이 이 계층에 해당됩니다.
– 데이터 계층 (Data Tier)
데이터 계층은 데이터베이스와 데이터베이스에 접근하여 데이터를 읽거나 쓰는 것을 관리하는 것을 포함합니다. 따라서 주로 DBMS (Database Management System) 이 이 계층에 해당됩니다. 데이터 계층 또한 백엔드 (back-end) 라고도 부릅니다. 주로 MySQL, MongoDB 등이 이 계층에 해당됩니다.
1. 1계층 구조
하나의 물리적인 컴퓨터 또는 서버에 3가지의 다른 기능을 함께 구현한 방식입니다. 따라서 물리적인 장비를 새로운 장비로 변경하고자 하는 경우, 모든 구성을 함께 새로 변경해야 합니다.
2. 2계층 구조
클라이언트 계층과 데이터 계층의 물리적인 컴퓨터 또는 서버로 구분하여 클라이언트 계층 에서의 변경이나 데이터베이스의 변경 시 서로 영향을 받지 않습니다.
3. 3계층 구조
클라이언트 계층, 어플리케이션 계층, 데이터 계층의 컴퓨터 또는 서버들을 모두 물리적으로 구분하여 구성한 경우입니다. 이에 각각의 계층에서 변화가 일어나더라도 서로 영향을 받지 않고 독립적으로 운영됩니다.
4. 또 다른 형태의 3계층 구조
개발, 테스트, 그리고 라이브 형태로 구성한 3계층 구조입니다. 위와 같은 구조에서는 실제 서비스를 하기 이전, 개발 단계에서 여러 서비스나 기능들을 구현해보고 테스트 서버 (Staging) 단계에서 내부 테스트를 충분히 거친 다음 이상이 없을 경우 라이브 서버로 이전 (Migration) 하여 서비스를 할 수 있습니다. 이와 같은 구성의 경우, 각각의 단계가 서로 백업을 해주는 구성을 할 수 있을 뿐 만 아니라 각 기능/서비스를 테스트를 거치고 업데이트를 할 수 있는 버전 관리 구성도 가능하게 됩니다.
5. 3 계층 구조를 사용하는 이유 및 장점 그리고 단점
– 장점
각 계층을 담당하는 팀들을 구성하여 업무 분담이 가능해지므로 업무 효율성이 증가할 수 있습니다. 또한 서로 다른 물리적인 (혹은 논리적인) 서버들을 구성 하므로 리스크를 어느 정도 완화할 수 있습니다. (이중화, 백업 구성 등 가능). 또한 여러 대의 서버로 나누어서 각 계층이 동작 하므로 서버의 부하를 줄여줄 수도 있으며, 경우에 따라 부하가 발생하는 특정 계층의 서버에 대해서만 합리적인 스케일업 (Scale up : 서버의 성능 업그레이드) 를 고려할 수 있습니다.
– 단점
1 계층 으로만 사용하는 것 대비 관리 포인트가 그만큼 많이 늘어나며 장애가 발생하는 포인트또한 함께 늘어난다는 것을 의미 합니다. 따라서 비용이 그만큼 많이 발생하게 되므로 서비스 규모 및 사용자 증가에 따라 계층 구조를 설계 및 고려해야 합니다.
#Steven