구글링을 조금만 해보면 알겠지만, 이론적으로 잘 정리되어 있는 글들이 정말 많다.
나는 좀 더 내 방식에 맞게 정리하기 위해 이 글을 쓴다.
[ 3-Tier Architecture를 쓰는 이유 ]
- 실제 서비스를 배포할 목적일 시, 각 계층에 대한 업무 분담이 및 동시에 개발이 가능해진다.(back-end, front-end, DB가 동시에 개발이 가능). 더 짧은 시간을 소요하여 서비스를 개발할 수 있는 장점이 있다.
- 여러 대의 서버로 나누어 각 계층이 동작하므로 서버의 부하를 줄여준다.
[ 구조 ]
- Presentation Tier : 사용자가 서비스 접속 시, 직접 접근할 수 있는 계층(ex. 보통 사용자가 자주 접하는 홈페이지 등의 Front-end 요소)
- Logic Tier : 비즈니스 로직이 실행되는 계층 (ex. 보통 Back-end )
- Data Tier : Data를 갖고 있는 계층 (ex. 보통 DB)
[ 이해를 위한 비유 ]
위는 이론적 설명에 대한 내용인데, 딱히 와닿지 않을 수 있다. 쉽게 맥도날드에 비유해보자.
맥도날드를 가면 키오스크, 음식을 만드는 직원, 음식 재료를 넣어놓는 냉동고가 있다. 위 3-Tier architecture에 비유를 해보면,
키오스크 = Presentation Tier, 음식 만드는 직원 = Logic Tier, 냉동고 = Data Tier다.
사용자가 키오스크(Presentation)에서 터치를 통해 햄버거 세트를 주문하면, 직원이 이 요청을 받고 햄버거 만드는 과정(Logic)을 수행한다. 이때 필요한 재료들은 냉동고(Data)에서 꺼낸다.
주문 받고, 냉동고에서 재료 꺼내고 요리하는 위 과정을 직원 한명이 모두 담당하면 업무 효율이 당연히 떨어진다. 때문에 3계층으로 나누어 서비스를 개발한다.
More info)
- Tier : 컴포넌트들의 물리적인 분리 | Layer : 컴포넌트들의 논리적인 분리
- N-Tier Architecture : 3-Tier와 유사하지만 큰 서비스에서 비즈니스 로직을 분산하다보니 어플리케이션 서버의 수가 늘어나서 개별 계층으로 표시한다.