[아키텍처] 2-tier/3-tier 개념 타파하기

## 목차

1) 2-tier

2) 3-tier

3) 2-tier와 3-tier의 비교와 필요성

 

 

 

#1 2-tier

먼저 아키텍처 계층에 대해서 말씀드리겠습니다.

계층(Tier : 컴포넌트들의 물리적인 분리)을 나눈다는 것은 층(Layer : 컴포넌트들의 논리적인 분리)을 세부적으로 나누어 최종적으로 사용자에세 보이기까지 몇단계를 둘것인가를 설정하는 것입니다. 최근 대부분의 웹개발은 3계층으로 구성되어 있습니다. 정말 간단한 웹개발이라면 2계층도 고려하지만 기본적으로 3계층으로 구성하는 것을 추천합니다.

 

2-tier 아키텍처는 client - server 아키텍처의 가장 기본적인 형태입니다.

클라이언트 사이드에 프레젠테이션/비즈니스 로직을 작성하고, 서버 사이드에는 데이터 관리/데이터베이스가 위치합니다. 즉, 클라이언트가 직접 DB 서버에 접근하여 데이터를 가져옵니다.

 

file server, DBMS server 등 서버와 클라이언트로 구성된 단순 분산 처리 방식입니다.

2-tier 아키텍처는 단순하고 직관적이며 구현하기 쉽지만 클라이언트와 서버 간의 강력한 결합으로 유지보수가 어려울 수 있습니다.

 

정리하자면,

 

1. 클라이언트 계층(Clioent Tier) :

• 사용자 인터페이스(UI)와 사용자 인터페이스를 통해 사용자 가 제공하는 입력을 처리합니다.
• 사용자가 요청한 데이터를 서버로 전송하고 서버로부터 받은 데이터를 표시합니다. 

2. 서버 계층(Server Tier) :

• 데이터베이스나 파일 시스템과 같은 데이터 저장소에 접근하여 데이터를 검색, 추가, 수정, 삭제 합니다.
• 클라이언트의 요청을 처리하고 데이터를 조작한 후 응답을 반환합니다.

이미지 출처 : https://minhee0327.gitbook.io/mini-til/undefined/02.-1-tier-2tier-3tier

 

 

 

#2 3-tier

3-tier 아키텍처는 더 많은 계층을 추가하여 2-tier 아키텍처의 단점을 극복하려는 시도로 등장했습니다.

 

그리고 3-tier는 클라이언트가 웹 애플리케이션 서버(Web Server -> WAS)를 경유하여 DB에 접근하고 직접 데이터 관리 역할을 Server가 하지 않으며 DB 서버를 별도로 구성합니다.

 

클라이언트 사이드에 프레젠테이션 로직을 작성하고, 서버 사이드에 비즈니스 로직과 데이터베이스가 위치합니다.

 

클라이언트가 미들웨어로 메세지를 주고 받으면서 데이터베이스에 저장하여 사용하는 형태이고, 결과 값을 클라이언트가약속된 메세지 형태로 받을 수 있는 양방향 프로그래밍입니다.

 

3-tier 아키텍처는 비즈니스 로직과 데이터 관리를 분리함으로써 시스템의 유연성과 확장성을 향상시킵니다. 또한, 각 계층이 서로 독립적으로 개발되고 유지보수되기 때문에 시스템의 확장과 변경이 쉽습니다. 그러나 3-tier 아키테처는 구현과 관리가 더 복잡하며 추가적인 오버헤드(어떤 처리를 하기 위해 들어가는 간접적인 처리 시간 · 메모리 등)가 발생할 수 있습니다.

 

1. 프레젠테이션 계층(Presentation Layer or Client Tier) : 

• 사용자 인터페이스(UI)와 사용자 입력을 처리합니다.
• 사용자와 상호작용하고 요청을 전달하여 비즈니스 로직이나 데이터를 요청합니다.

2. 비즈니스 계층(Business Layer or Application Tier) :

• 비즈니스 로직을 구현하고 처리합니다.
• 클라이언트로부터 요청을 받아들이고 이를 처리하기 위해 데이터베이스와 통신합니다.
• 데이터의 유효성 검사, 계산, 처리 등을 담당합니다.

3. 데이터 계층(Data Layer or Data Tier) :

• 데이터베이스 또는 다른 데이터 저장소에 접근하여 데이터를 관리합니다.
• 데이터베이스 서버와 직접 통신하고 데이터를 검색, 추가, 수정, 삭제합니다.

 

이미지 출처 : https://minhee0327.gitbook.io/mini-til/undefined/02.-1-tier-2tier-3tier

 

 

 

 

#3 2-tier와 3-tier의 비교와 필요성

성능	2-tier	3-tier
개발 편의성	4GL 툴 등을 사용하여 작성이 용이함	보통 프레젠테이션 로직(주로 4GL로 개발)과 비즈니스/데이터 접근 로직(주로 C/C++, COBOL 사용)을 별도로 작성하므로 2-tier에비해 개발이 복잡함
확장성	좋지 않음	이기종 H/W 증설 또는 이기종 데이터베이스가 구축되어도 데이터 적합성을 보장할 수 있어 확장성이 뛰어남
유지보수	수정시 모든 로직이 클라이언트에 존재하여 클라이언트의 로직을 모두 수정하거나 재개발 해야 하는 불편함	각 계층이 독립적인 구조로 되어 있어 로직을 다양하게 수정 및 보안이 가능함. 그리고 비즈니스 로직을 모듈화하여 클라이언트/서버 환경과 웹환경에서 동시 사용이 가능함
성능	동시 사용자 수가 증가 함에 따라 성능이 급격히 저하 됨	동시 사용자 수가 증가해도 일정한 응답속도와 처리량을 보장 함, 그러나 추가적인 오버헤드가 발생 할 수 있음
자원 활용	H/W 자원(CPU, 메모리 등)과 데이터베이스 자원을 비효율적으로 사용 함	미들웨어에서 부하 분산, 큐잉 매커니즘을 통해 효율적으로 자원 활용 함
시스템 관리	모니터링 및 관리가 용이하지 못함	처리되고 있는 어플리케이션 정보, 프로그램별 처리 건수 등 다양한 모니터링이 가능하여 관리 및 모니터링이 용이 함
비용	개발 비용이 비교적 저렴함	개발 비용이 비교적 비쌈(미들웨어 및 하드웨어 도입 등)