1줄 요약 : 우리가 맨날 짜는 그 형식
3-Tier Architecture
3-Tier Architecture(3계층 아키텍처)란 애플리케이션을 논리적이고 물리적인 컴퓨팅 계층으로 구성하는 구조입니다.
애플리케이션을 3계층으로 분리해서 책임 소재를 구분하고, 유지보수의 효율성을 올릴 수 있습니다.
다만, 프로젝트의 규모 등을 산정해서 분리하지 않을 경우 오버 엔지니어링이 될 수도 있다는 점에 주의해야 합니다.
계층은 아래와 같이 구분됩니다.
계층 구분
프레젠테이션 계층 Presentation-Tier
쉽게 생각하자면 프레젠테이션 계층은 사용자가 보는 UI 부분입니다.
클라이언트 계층의 특징을 요약 정리해보자면 다음과 같습니다.
- 사용자에게 보여지는 부분입니다.
- 사용자에게서 정보를 수집하는 등 사용자와 직접적으로 상호작용합니다.
일반적으로 프론트엔드 개발을 프레젠테이션 계층으로 볼 수 있습니다.
어플리케이션 계층 Application-Tier
어플리케이션 계층은 한 애플리케이션의 핵심으로, 비즈니스 논리를 사용하여 데이터를 처리합니다.
어떤 데이터는 데이터 계층으로 넘어가 추가, 삭제, 수정되기도 합니다.
어플리케이션 계층의 주요 업무를 보겠습니다.
- 비즈니스 로직을 처리합니다.
- 일반적으로 API를 사용하여 프레젠테이션 계층과 통신합니다.
데이터 계층 Data-Tier
데이터 계층에서는 애플리케이션 처리 정보가 저장 및 관리됩니다.
3계층 통신에서 모든 통신은 어플리케이션 계층을 거쳐야 하므로, 데이터 계층은 프레젠테이션 계층과 직접적으로 통신할 수 없습니다.
- DBMS단에서 쿼리 실행 이후 결과를 반환합니다.
장단점
장점
- 각 계층이 분리되어 있기 때문에 다른 계층에 영향력을 줄일 수 있습니다.
- 이에 따라 장애에 더욱 빠르게 대응할 수 있습니다.
- 필요에 따라 업데이트될 수 있습니다.
- 원하는 부분만 오토 스케일링 (Auto-Scailing) 할 수 있습니다.
따라서 합리적인 비용으로 규모를 확장하거나 축소하게 됩니다.
단점
- 더 많은 관리가 필요하고, 장애 포인트가 추가로 발생합니다.
마무리
3계층 구조는 가장 보편화된 애플리케이션 아키텍처라고 봐도 무방할 것 같습니다.
비유하자면 데이터 계층이 직접 일하는 일꾼이고, 애플리케이션 계층은 일꾼을 적재적소에 쓰고 결과를 정리하는 관리자, 클라이언트 계층은 관리자가 진행한 사업의 결과를 그래프와 수치 등으로 보기 좋게 정리한 보고서 정도 되겠네요.
3줄 요약으로 마무리하도록 하겠습니다.
- 클라이언트 계층: 사용자와 직접적으로 상호작용을 하고, 결과값을 보여주는 부분입니다.
- 어플리케이션 계층: 사용자의 요청을 처리하는 비즈니스 로직 부분입니다.
- 데이터 계층: 데이터를 직접적으로 저장, 수정하는 부분입니다.
항상 틀린 부분에 대한 피드백은 댓글로 받고 있습니다.
오늘도 짧은 글이나마 읽어주셔서 감사합니다.
참고자료
