AWS 클라우드 기반 CERT 인프라 설계를 위해 3-Tier Architecture 구성에 대해 이해하고, 실제 팀 근두운 프로젝트에서 AWS SecOps 인프라 구축 시 고려해야할 부분이 어떤 것이 있는지를 학습하는 것을 목표로 한다.
3-Tier Architecture는 시스템을 역할에 따라 Presentation Tier, Application Tier, Data Tier 3가지 계층으로 분리된다.
| Tier | 역할 |
|---|---|
| Presentation(Client) | 사용자가 직접 액세스할 수 있게 화면을 보여주고 입력을 받는 계층(WEB) |
| (HTML, CSS, JavaScript, React 등) | |
| Application(Logic) | 서비스 규칙에 따라 요청을 처리하는 계층(WAS) |
| (Java, C++, Python과 같은 백엔드 언어) | |
| Data | 애플리케이션에 필요한 데이터를 저장하고 조회하는 역할(DBMS) |
| (MySQL, Postgres 등) |
일반적으로 플랫폼이나 웹 애플리케이션 서버를 구성할 때, 대부분의 기업/기관에서는 3-Tier Architecture 구성을 기본으로 하고 있다.
여기서 3-Tier는 각 서비스의 실행 환경을 물리적・배포 단위로 분리하는 것을 의미하며, 쇼핑몰과 같은 작은 이커머스 서비스를 예시로 들면, 상품 목록과 조회와 같은 UI・UX를 제공하는 웹 서버, 상품 주문 시 주문이라는 요청을 처리하는 로직을 가진 WAS 서버, 해당 로직 처리를 위해 실제 데이터를 저장하고 조회하는 DB 서버가 각각 물리적으로 분리된 구성을 얘기한다.
3-Tier Architecture 구성
각 서비스 역할별로 계층이 물리적으로 분리되어 있어 유지보수 용이성, 확장성, 보안 강화의 이점이 있어 플랫폼 또는 서비스 설계 시 고려하면 좋은 구성으로, Failure Domain(장애 영역)을 분리할 수도 있어 가용성의 이점도 가진다.
현재 우리 팀 근두운 프로젝트의 인프라 중 Wazuh SIEM을 보면, 하나의 EC2 인스턴스에 Wazuh 서비스의 Manager, Indexer, Dashboard가 함께 구성된 것을 볼 수 있다. 즉, Presentation, Application, Data Tier의 기능을 하나의 EC2가 담당(자원을 공유)하는 것이다.
해당 구성은 1-Tier Architecture로 하나의 물리적인 서버에 3가지의 다른 기능을 함께 구현하는 방식이다. 비용 절감과 구성의 단순함 이라는 이점에 있어서는 소규모 프로젝트에서 적합한 방식일 수도 있지만, 장애가 발생하면 모든 서비스가 마비되는 단일 장애점, 자원 경합으로 인한 속도 지연, 확장성 제한, 보안 취약성 등의 한계가 분명하다.
따라서 팀 근두운 인프라에서 3-Tier Architecture를 적용 할지에 대해 프로젝트 목표를 근거로 고민할 필요가 있다.
하지만, 3-Tier Architecture 구성을 하였다고 해서, 모든 한계가 해결되는 것은 아니다. 3-Tier Architecture는 플랫폼 또는 서비스를 구축할 때의 뼈대가 되는 구성 방식일 뿐이다.
실제로 쇼핑몰 플랫폼을 3-Tier Architecture로 구성 하였다고 해도 사용자가 급증하면, 비즈니스 로직을 처리하는 WAS 서버만 자원의 한계가 발생하는데, 이를 해결하기 위한 방법에서 해당 구성의 이점이 발휘하게 된다.
3-Tier Architecture는 확장성의 이점을 가진다고 앞서 설명 하였는데, 여기서 Vertical Scaling(Scale-up)과 Horizontal Scaling(Scale-out) 2가지의 확장 방식을 활용할 수 있다.
| 구분 | Vertical Scaling(Scale-up) | Horizontal Scaling(Scale-out) |
|---|---|---|
| 특징 | 기존의 서버의 하드웨어 스펙을 더 높은 사양으로 업그레이드 하는 확장 방식 | 서버 하드웨어 스펙을 올리지 않고, 비슷한 성능의 서버를 여러 대 추가하여 부하를 분산하는 확장 방식 |
| (고가용성) | ||
| 한계 | 여전히 단일 장애점을 가지고, 부품 교체 시 서비스 중단이 발생(가용성의 한계) | 서버가 여러 대로 늘어나면 요청을 나누어 전달하고, 필요한 상태와 데이터를 서버 간에 공유하거나 나누어 관리해야 하므로 설계와 운영이 복잡해질 수 있음 |
각 계층의 특성과 병목에 따라 Scale-up과 Scale-out을 선택하거나 병행하는 것이 일반적이다.
Vertical Scaling(Scale-up) 확장 예시
Horizontal Scaling(Scale-out) 확장 예시
Horizontal Scaling 방식으로 서버의 대수를 늘렸다고 해도, 즉시 부하가 분산되는 것은 아니다. 이는 위 확장 방식 비교 표에서 얘기했던, 설계 및 운영의 복잡성에 대한 한계가 드러나는 부분이다.