n-Tier / n-Layered Architecture
3-티어 아키텍처에서는 애플리케이션을 데이터베이스 티어(또는 데이터 티어), 서버 애플리케이션 티어(또는 애플리케이션 티어), 클라이언트 티어로 나눈다. 각 티어에서도 여러개의 레이어로 나눌 수 있는데 이것을 계층형 아키텍처(Layered Architecture)라고도 부른다. Tier는 여러 개의 Layer로 구성할 수 있는데.. 그 둘을 구분하는 가장 큰 차이는 물리적으로 나누어진 계층인지 논리적으로만 나눠진 계층인지의 차이로 보면 된다. (n-Tier와 n-layered Architecture의 차이에 대한 글 참조) 한글로 Tier도 계층, Layered도 계층으로 번역한 글이 많아서 둘을 대충 같은 것으로 보고 작성한 글이 많아서 정확하게 이해하기 어려웠다.
앞선 과제는 node.js 런타임 환경에서, Express를 미들웨어로 해서, router에서 비즈니스 로직과 같은 서버에 설치된 MongoDB 연결까지 모두 처리했었다. 이걸 간단하게 도식하면 아래와 같이 1-Tier이면서 1-layered Architecture가 된다. 1개의 계층에 모든걸 다 때려 넣은 것. 즉 물리적으로도 모두 한 서버에 있으면서, 논리적으로도 구분이 없는 단순한 구성인 것.
계층화(layering)
이때, 계층화의 핵심은 각 계층은 응집도(Cohesion)는 높으면서 다른 계층과는 낮은 결합도(Coupling)를 가지고 있기 위함이라고 한다.
응집도는 모듈 내부의 요소들이 얼마나 밀접하게 관련되어 있는지를 나타내는 정도라고 볼 수 있다. 모듈 내부의 요소들이 서로 관련이 깊고 밀접하게 연결되어 있다면 높은 응집도를 가진다고 말할 수 있는데, 예를 들어, 데이터 저장과 관련된 모듈이 있다면, 이 모듈 내부에서는 데이터를 저장하는 함수, 데이터를 읽는 함수 등과 같이 서로 밀접하게 연관된 함수들이 포함되어야 하는 것이다. 이와 반대로, 데이터 저장, 데이터 조회, 데이터 삭제 등과 같이 서로 다른 기능들이 한 모듈에 묶여있다면, 이 모듈은 낮은 응집도를 가진다고 말할 수 있다.
한편, 결합도는 모듈 간의 상호 의존성을 나타내는 정도이다. 다른 모듈에 의존하는 정도가 낮을수록 결합도가 낮다고 말할 수 있다. 예를 들어, 데이터 조회 모듈이 데이터 저장 모듈에 직접적으로 접근하는 것보다는 데이터 저장 모듈이 제공하는 API를 통해 데이터 조회 모듈이 데이터에 접근하도록 하는 것이 좋다. 이렇게 하면 데이터 저장 모듈의 구현이 변경되더라도 데이터 조회 모듈의 구현에 영향을 덜 주기 때문이다. 따라서, 높은 결합도는 모듈 간의 의존성이 강하고, 변경이 생길 때 다른 모듈에도 영향을 끼칠 가능성이 높다는 것을 의미하는 것이다.
여기서 추가로, 상위 계층은 하위계층을 사용할 수 있지만, 하위계층은 상위계층에 대한 접근이나 내용을 모르는 방향으로 구성해야 한다는 점도 중요하다고 한다.
즉 정리하면, 각 계층은 서로 밀접하게 관련된 기능으로 구성되고, 아래 계층에만 의존하도록 구성하는 것이 핵심인 것.
3계층(layer) 아키텍처
규모가 크기않은 애플리케이션은 3개정도로 계층(layer)을 구성하는 것이 일반적이라고 한다. 3개로 나눠서, 3계층 아키텍처 인데, 이때 계층은 프레젠테이션, 비즈니스 로직, 데이터 엑세스 계층으로 나눈다. 이때, 프레젠테이션 계층은 Controller 컴포넌트, 비즈니스 로직 계층은 Service 컴포넌트, 데이터 엑세스 계층은 Repository 컴포넌트로 구성하는 것이 일반적이다.
이를 적용해서 이번 과제에서 구현한 방식을 도식해보면 아래와 같이 된다.
3개의 Tier로 나눠서(물론 첫번째 티어는.. 프론트 엔드에서 해줘야 하지만), 애플리케이션을 구성했다. 두번째 티어는 AWS EC2에서 동작하고, Controller 모듈/컴포넌트가 있는 Presentation Layer, Service 모듈/컴포넌트가 있는 Business Logic Layer, Repository 모듈/컴포넌트가 있는 Data Access Layer로 3-layered로 나눴다. 세번째 티어인 Database는 mySQL으로 AWS RDS서버와 연결했다.
1차 과제로 간단한 백엔드 API 개발을 통해 기본적인 서버 구현 방법을 익혔다면, 2차 과제에서는 조금더 체계화되어 여러사람과 협업할 수 있는 작업 방식에 대해 조금 맛본 것 같다. 폴더트리까지 같이 비교하면 더 명확해 지는데,
1차 과제는 node.js 환경에서, Express 미들웨어를 사용하고, mongoose를 ODM으로 MongoDB에 연결해 사용한 과제였다면, 2차 과제는 node.js 환경에서, Express 미들웨어를 사용하고, Sequelize을 ORM으로 mySQL에 연결하였고, 이때, 2nd 티어는 AWS EC2에, 3rd 티어는 AWS RDS를 이용한 케이스로 달랐다.
2차 과제를 하면서 실제 서비스를 혼자서 개발하는 것이 아닐 때의 분업을 어떤식으로 하는지에 맛볼 수 있었다. 확장성을 감안한다면 계층을 나누는 설계와 패턴이 꼭 필요하겠지만, 이 패턴이 정답인 것은 아니다. 몇 티어와 몇 레이어로 나눌지는 그 서비스가 얼마나 확장성이 있는지, 수요가 얼마만큼 빠르게 또는 느리게 성장할 것인지에 대한 기획이 치밀하게 이루어진 이후에 결정할 일으로 보인다.
또, 단순히 확장성만 고려할 일만은 아니고, 전체 애플리케이션이 얼마만큼의 리소스를 가지고 개발되고 운영되어야 하는지에 따라 달라질 것이므로, 결국 시장의 상황과 비즈니스 기획과 개발 리소스 및 인프라의 현황을 종합적으로 고려해서 스스로 설득가능하고, 리스크를 감당할 수 있는 정도의 아키텍쳐면 되는 일로 보인다.
추가로 읽어보면 좋을 글
https://herbertograca.com/2017/08/03/layered-architecture/
Layered Architecture
In a layered architecture, the layers can be used in a strict way, where a layer only knows the layer directly beneath it, or in a more flexible approach where a layer can access any layer beneath …
herbertograca.com
https://bkjeon1614.tistory.com/27
3 Tier Architecture(3계층 구조)
3계층 구조(3 Tire Architecture)란 프레젠테이션 로직(클라이언트, 사용자 인터페이스), 비즈니스 로직, 데이터베이스를 각각 다른 플랫폼 상에서 구현한 것이다. 우리가 보편적으로 개발하는 웹프로
bkjeon1614.tistory.com
'daily' 카테고리의 다른 글
| PWM 신호로 Fan 제어해 압력값 세팅하기 (0) | 2023.05.15 |
|---|---|
| 23, 19주차 (0) | 2023.05.11 |
| 23.05.06. Refresh token, Access token (0) | 2023.05.06 |
| 23.05.01. Sequelize findOne에서, 테이블 조인과 이름 변경 (0) | 2023.05.01 |
| 23, 17주차 (0) | 2023.05.01 |