3-tier Architecture, 4-tier Architecture 구조
N-tier Architecture를 이해하기 전 3-tier, 4-tier Architecture에 대해 이해할 필요성이 있다.
3-tier, 4-tier 뿐만이 아닌 2-tier Architecture도 존재하긴 하지만, 2-tier Architecture는 Monolithic Architecture와 차이점이 거의 없기 때문에 이번 Section에서는 3-tier, 4-tier Architecture만 관찰해보자
Presentation Layer(프리젠테이션 레이어; 표현 계층)
사용자와 직접 상호작용하는 UI(User Interface)를 의미한다.
MVC Pattern와 비교해 봤을 떄 View Layer에 해당하는 계층으로써 User가 직접 볼 수 있는 모든 파일 및 화면들에 대해 관리하는 계층이다.
Presentation Layer에서는 사용자에게 데이터를 표시하고 Server와의 통신을 처리하는 계층이다.
AJAX나 REST API 등을 통해 사용자의 동작을 Server에 보내어 처리하고 이렇게 처리된 데이터를 User가 볼 수 있게 하는 계층인 것이다.
이 계층을 개발하기 위해서 주로 HTML, CSS, JavaScript 등을 활용한다.
Application Layer(Business Layer;애플리케이션 레이어)
Presentation Layer에서 사용자에게 온 데이터나 사용장에게 줘야 할 데이터를 처리하는 계층이다.
MVC Pattern에서 Controller Layer에 해당하는 계층으로써 User로부터 온 데이터를 받아 처리하며, 이렇게 처리한 데이터를 다시 User에게 보내주는 기능들을 관리하는 계층이다.
User로부터 온 데이터를 처리하고 가공하는 Layer로써 사실상 User가 원하는 기능을 실제로 수행하는 계층이라고 이해하면 편하다.
이 계층을 개발하기 위해서 응용 프로그램 개발자들은 Java, Perl, Python 등을 활용하며 Web 개발자들은 JSP, ASP, PHP 등을 활용한다.
Data Layer(Database Layer;데이터 레이어)
Applicatoin Layer에서 처리된 데이터를 실제 DB에 저장하거나 DB에 저장된 데이터를 Application Layer에 전달하는 계층이다.
즉, 데이터를 실제로 저장하고 관리하는 계층이다.
이 계층은 SW 기능(코드)과 가까운 Layer라기 보다는 데이터 관리를 위한 계층으로써 주로 DBMS가 이 Layer에 속한다.
이 계층을 관리하기 위하여 Oracle, MySQL, MariaDB, PostgreSQL, Microsoft SQL Server, MonogDB 등을 활용한다.
Persistence Layer(영속성 레이어)
4-tier에만 존재하는 특수한 Layer
API를 통해 Database Layer와 통신하는 계층으로 SQL Query문을 통해 데이터를 가져오거나 저장시키는 계층이다.
SQL Query문을 활용하기 때문에 Query문이 지원하는 수준으로 데이터를 처리할 수도 있다.
이전에 배웠던 MyBatis나 JPA와 관련된 클래스 및 코드들이 모두 이 Persistence Layer에 들어간다.
(MyBatis나 JPA 자체가 Persistence Frameweork라고 불리는 것을 기억해보자)
3-tier Architecture에서는 SQL Query문을 Business Layer에서 직접 처리하기 때문에 Persistence Layer가 존재하지 않고 Business Layer에서 그 역할을 수행하기 때문에 3계층으로 만들어지는 것이다.
참고로 Persistence Layer를 개발하는 개발자를 Front-end 개발자, Business Layer와 Application Layer를 개발하는 개발자를 Back-end 개발자라고 부른다.
N-tier Architecture란?
3-tier Architecture을 위에서 배웠다.
하지만 3-Teir Architecture에서도 단점은 존재하는데, 바로 코드의 재사용이 어렵다는 점이다.
3-Tier Architecture에서는 DB에 접속 및 조회하고 동시에 User로부터 데이터를 받고 처리하는 부분이 모두 Application Layer에서 진행된다.
따라서 Application Layer가 하나만 존재하는 3-Tier Architecture에서는 코드를 재사용하기 위해서는 사실상 애플리케이션 전체를 재사용해야 하는 것이다.
따라서 개발자들은 생각했다.
Application Layer를 여러 개의 작은 Component들로 나누어 Componenet끼리 데이터를 주고 받는 방식으로 개발을 진행하면 코드의 재사용이 쉬워지지 않을까?
이런 생각으로 나온 Application Architecture가 바로 N-tier Architecture이다.
N-tier Architecture는 3-tier Architecture와는 달리 Application Layer가 여러 개의 컴포넌트(Componenet)들로 구성되어 있다.
그리고 User로부터 오는 데이터를 처리하기 위해 데이터에 적절한 컴포넌트를 선택하고, 선택된 컴포넌트와 연동된 다른 컴포넌트들과의 상호작용을 통해 필요한 기능을 수행한다.
그리고 이 과정에서 생성된 SQL Query문을 통해 DB와 통신하게 되는 것이다.
결국 3-tier나 4-tier Architecture는 전통적인 Client-Server 구조의 Architecture에서 "데이터 처리", "데이터 관리", "데이터 표현" 기능을 물리적 및 논리적으로 완전히 분리해 둔 계층화된 Architectur Pattern이라고 말할 수 있을 것이다.
그리고 N-tier Architecture는 3-tier, 4-tier Architecture를 조금 더 발전시켜 Component끼리 호출을 통해 1개의 기능을 수행할 수 있게 개발함으로써 코드의 재사용성을 높이고 Application Layer의 결합도를 조금이라도 낮추려고 한 Architecture라고 생각하면 될 것이다
개인적으로는 N-tier Architecture라는 것이 새롭게 나온 AA(Application Architecture)라기 보다는 Monolithic Architecture에서 기능을 조금이라도 분리시켜 관리 및 개발을 더 원활하게 수행할 수 있게 만든 발전된 형식의 Monolithic Architecture라고 생각한다.
N-tier Architecture 장점
높은 보안성
Monolithic에서는 1개의 장비에서 DB, Application, 그리고 HTML 파일까지 모든 계층을 담당하였다.모든 계층에서 요구되는 보안 정도는 다른데, 예를들어 HTML 파일은 대부분의 사람이 접근 가능하므로 보안쪽에 그렇게까지 큰 신경을 쓰지 않아도 되지만 DB는 매우 철저한 보안성을 가져야 할 것이다.하지만 Monolithic에서는 1개의 장비에서 모든 보안을 관리해야 하므로 보안 쪽에 과도한 비용을 투자하게 될 것이다.
N-tier Architecture는 계층에 물리적, 논리적으로 완벽히 분리되어 있으므로 각 계층의 장비에 대하여 각 계층에 적합한 보안 수준으로 보안 설계를 할 수 있게 된다.
이는 보안에 대한 Overcost를 방지할 수 있으며 동시에 보안조치에 많은 신경을 써야 하는 Data Layer에 더 많은 자원을 투자할 수 있다는 장점을 가지고 온다.
편리한 관리
N-tier Architecture에서 각 계층은 분리되어 있기 때문에 다른 계층에 최소한의 영향을 주면서 관리가 가능해진다.
이는 유지보수성이 좋다는 의미와 동일하다.
계층이 분리되어 있다는 것은 단순히 코드 상의 수정이 쉽다는 장점만 가지고 오지 않는다.
그렇다면 어느 점에서 관리가 편한지 알아보자
계층에 대한 수정이 쉬움
위에서도 간단히 설명했듯 각 계층은 분리되어 있으므로 다른 계층에 최소한의 영향을 주며 관리가 가능해진다.
즉, 특정 계층에 대한 수정이 필요할 경우 다른 계층에 끼칠 영향을 크게 고려하지 않고 수정을 진행할 수 있다는 점에서 유지보수성이 높으며 에러의 발생 확률을 줄여준다는 장점을 가지고 온다.
(결합도가 낮아지기 때문에 발생하는 장점이라고 생각하면 될 것이다)
쉬운 Scale Up
Scale Up이란 HW의 성능을 올려 Application에 대한 성능을 올리는 방식을 의미한다.
Monolithic에서는 1개의 HW에서 전체 계층을 다루기 때문에 DB 계층에 대해서만 HW 스펙을 올려도 되는 상황에서조차 전체 HW 스펙을 올려야 할 필요성이 존재했다.
하지만 N-tier Architecture에서는 각각의 계층이 물리적으로도 분리되어 있기 때문에 Scale Up이 필요한 계층의 HW에 대해서만 성능을 올려줘도 Application 전체의 성능을 올리는 것과 동일한 효과를 가질 수 있다.
필요한 계층에 대해서만 Scale Up을 진행해주면 되기 때문에 관리가 편하다는 장점과 Scale Up에 드는 비용을 최소화시킬 수 있다는 장점을 동시에 가지고 온다.
쉬운 유지보수
N-tier Architecture는 다른 계층에 영향을 주지 않으므로 유지보수가 쉽다는 장점이 존재한다.
먼저 코드에 대한 유지보수가 쉽다는 점은 위에서 계층에 대한 수정이 쉽다는 점에서 이미 설명했다
N-tier Architecture에서는 각 계층에 대해 물리적으로도 분리되어 있기 때문에 각 계층 장비에서 문제가 발생하였을 경우 문제가 생긴 HW만 관리하면 되고 에러를 확인하기 위해 계층에 대해 탐구하는 과정에서 다른 계층에 큰 영향을 주지 않기 때문에 안정감 있게 고장을 탐구할 수 있게 되는 것이다.
또한 물리적, 논리적으로 계층이 분리되어 있기 때문에 사고가 발생했을 때도 다른 계층까지 문제가 확산되는 리스크를 감소시킬 수 있어 유지보수에 조금 더 안정감이 생기게 되는 것이다.
서버 부하의 감소
Monolithic에서는 모든 로직을 1개의 HW에서 처리하였다.
이 경우 만약 Business Layer에 대한 트래픽만 많을 경우 서버 전체에 부하가 걸리게 되므로 User가 보는 HTML 파일을 로딩하는데에도 오랜 시간이 걸리며 DB에 데이터를 저장 및 추출하는 데에도 오랜 시간이 걸리게 될 것이다.
즉, 1개의 계층에 발생한 트래픽이 다른 계층에도 영향을 주는 것이다.
하지만 N-tier Architecture에서는 모든 계층이 분리되어 있다. 따라서 특정 Layer에 발생한 과도한 트래픽이 다른 계층에까지는 영향을 주지 않는다.
즉, 각각의 Layer는 자신에게 온 트래픽만 처리하면 되기 때문에 서버 부하가 감소하게 된다.
N-tier Architecture 단점
관리 포인트의 증가
N-tier Architecture는 결국 최소 3개의 Layer를 관리해야 하는 것이다.
따라서 관리할 부분이 조금 더 많아진다는 단점을 가지고 온다.
Monolithic에서는 1개의 HW만 관리하면 되었겠지만 N-tier Architecture에서는 DB를 관리할 사람, Application을 관리할 사람, 그리고 User에게 보여줄 View 파일을 관리할 사람 최소 3개의 관리 파트로 나뉘어지는 것이다.
시스템 구축 비용 증가
Monolithic에서는 1개의 HW만 구축하면 바로 Application을 실행시킬 수 있었을 것이다.
하지만 N-tier Architecture에서는 Layer가 나뉘어져 있으며 각 Layer마다 물리적으로도 분리되어 있어야 하기 때문에 시스템의 구축 비용이 증가할 수밖에 없다.
즉, 시스템을 처음 구축해 놓은 이후에는 관리가 매우 편해지겠지만 초기 시스템 구축에는 Monolithic Architecture보다 더욱 많은 비용이 투자 되어야 하는 것이다.
