당신의 웹 서비스 Architecture 는 3-Tier Architecture 가 아닐 수 있다

3-Tier Architecture, 대략 WEB/WAS/DB 가 3 단계로 나뉘는 구나~ 라고만 알고 있는 사람, 여기 붙어라. 😂

성공적으로 웹 서비스를 제공하기 위해서 인프라 환경을 어떻게 설계하는지는 굉장히 중요하다. 클라우드 환경이 대중화되어 가면서 문제 해결 단위의 수많은 웹 서비스 Architecture 가 나오고 있다.
(일반적으로 많이 얘기되는 Architecture 에는 동일 수준에서 비교 될 수 없지만 3-Tier/2-Tier Architecture, Micro Service Architecture, Monolith Architecture 등 등이 있을 것이다.)

Architecture 챕터에서 다루는 첫 번째 글이므로, 웹 서비스 (Client-Server 구조) 설계에서 전통적으로 대중화된 3-Tier Architecture 에 대해서 명확히 알아보자. 새로운 Architecture 를 만나더라도 3-Tier Architecture 를 기준으로 삼고 어떻게 변형되고 무엇을 만족하기 위해 생성되었는지 파악할 수 있을 것이다.

웹 서비스 Architecture 의 기본, 3-Tier Architecture 정확히 알고 가자!

요약/결론

• 3-Tier Architecture 는 논리적/물리적으로 3 단계로 나뉜 구조를 말하며, Presentation Tier - Application Tier - Data Tier 로 구성된다.
• Tier 와 Layer 는 다르다. Tier 는 논리적 분리와 더불어 물리적 분리를 동반할 때 서야 만족된다. 반면 Layer 는 논리적 분리만을 언급한다.

3-Tier Architecture 는 논리적/물리적으로 3 단계로 나뉜 구조를 말하며, Presentation Tier — Application Tier — Data Tier 로 구성된다.

물리적 분리의 범위는 1차적으로는 별도의 OS, 별도의 서버 플랫폼 정도로 생각하면 된다.

3-Tier Architecture

• Presentation Tier
  - 최상층 Tier 로써 사용자와 직접적으로 소통하는 구간
  - 웹 브라우저, 데스크톱 응용 프로그램 등에서 접할 수 있는 UI/GUI 구간 (front-end)
  - HTML, Javascript, CSS 등으로 작성될 수 있다.
  - 정적인 페이지를 처리하는 WEB 서버 (httpd, nginx) 가 주로 해당된다.
• Application Tier
  - 중간 계층으로, Presentation Tier 에서 수집한 정보를 처리하거나 Date Tier 의 정보를 처리하는 구간
  - Business Logic 을 주로 포함한다. (back-end)
  - PHP, Java EE, Python 등으로 작성되며, 동적인 페이지를 처리하는 WAS (Tomcat, Weblogic, JBOSS, NodeJS, Django) 영역이 해당된다.
  - 사용자에 대한 정보의 표현은 Presentation Tier 에서 수행하므로 정적인 페이지의 처리는 담당하지 않는다.
  - Logic Tier, Middle Tier 로도 불린다.
• Data Tier
  - Application Tier 에 의해 처리된 데이터들을 저장하고 관리하는 구간 (back-end)
  - Database Tier 로도 불리며, Database 형태의 DBMS 들이 주로 해당된다. (PostgreSQL, MySQL, MariaDB, Oracle, Cassandra, MongoDB, …)
  - 파일을 다루는 File Storage 또한 Data Tier 에 포함될 수 있다.

3-Tier Architecture 의 장점

3-Tier 의 장점은 단연 각 계층이 논리적/물리적으로 분리되어 있다는 점이다. 다른 계층에 영향을 주지 않고 계층별로 이행해야 하는 역할에 충실할 수 있도록 최적화할 수 있다.

기타 장점은 아래와 같다. (Layer 가 아닌 Tier 로써의 장점 선별)

• 확장성 증가: 각 계층은 독립적으로 scale-in/out 될 수 있다. Data Tier 가 분리되지 않은 1-Tier 구조라면 다른 계층을 유연하게 확장할 수 없을 것이다.
• 보안성 향상: Presentation Tier 와 Data Tier 는 직접적으로 소통할 수 없으며, 중간의 Application Tier 에서 침입/공격 (SQL Injenction 등) 에 대한 처리를 일부 수행할 수 있다.
  Tier 가 분리되어있지 않으면 악성코드 및 감염된 파일이 각 계층별 영향을 줄 수 있다.

단점으로는, Tier 가 늘어날수록 관리/장애 포인트가 늘어나며 비용 또한 늘어날 수 있다. 조직/사업의 상황에 맞는 Tier 를 선택하는 것이 필요할 것이다.

Tier 와 Layer 는 다르다.

Tier 는 논리적 분리와 더불어 물리적 분리를 동반할 때 서야 만족된다. Tier 별 미들웨어 (WEB 서버, WAS 서버, DB 등) 들이 모두 독립적인 서버에 설치되어야 하는 것이다. 반면 Layer 는 논리적 분리만을 언급한다.

예로 핸드폰의 “연락처” 앱을 보자. 연락처 앱은 별도 인터넷과의 통신 없이 앱 자체만으로 실행가능하다. 앱 화면을 구성하는 화면 Layer, 버튼을 눌렀을 때 내부적으로 동작하는 기능 Layer, 연락처 정보를 저장하는 Data Layer 로 나눌 수 있으며 단일 핸드폰에 모두 들어가있으므로, 3-Layer, Single-Tier 구조를 가진다고 볼 수 있다.

우리팀의 웹 서비스는 정말 3-Tier Architecture 인가?

Tier 와 Layer 의 차이에서도 알 수 있듯이, 논리적+물리적으로 각 계층이 분리되어있지 않다면 3-Tier 가 아니라 2-Tier Architecture 가 될 수 도 있다.

보통 웹 서비스 프로젝트를 만들 때, 하나의 프로젝트 안에 front-end/back-end 소스를 통합하여 만드는 경우가 많다. 그러한 프로젝트가 WAS 로 배포되어 서비스된다면 엄밀히는 3-Tier 가 아닐 수 있다. 앞 단에 WEB 서버를 두지만 이 때 WEB 서버는 단지 프록시/기타 역할을 담당하는 것일 수 있다.

실제로도 WAS 에서 모든 처리를 하고, WEB 서버가 특별한 역할을 하지 않는다면 WEB 서버 계층을 활용하지 않는 회사도 있다. (국내 W사) 이러한 경우는 2-Tier 로 보는 것이 맞아 보인다.