기본 중의 기본 web was db!!
구조 관련 미팅을 하다보면 정말 다양하게 사용되지만 sa들은 찰떡같이 알아듣는 단어들이 있다.
- web
- was
- db
- frontend
- backend
- web tier
- business tier
- data tier
그럼 이제 줄을 세워보자
| client와 소통용 | 내부 계산 및 로직 처리 | 데이터베이스 |
|---|---|---|
| web | was | db |
| frontend | backend | |
| web tier | business tier | data tier |
위와 같이 간단하게 정리할 수 있다. 보통 인프라쪽 설계관련 미팅 들어가면 위의 단어들로 대부분의 소통이 가능하다.
일반적으로 N-tier의 경우 중간의 was 부분이 여러티어가 되는 경우가 있는데 해당 부분을 감안해서 N-tier라 표현하며, 일반적으로는 3-tier 라고 부르기도 한다. 또는 2 tier도 될 수 있으며 4 tier도 될 수 있는데 Azure에서는 어떻게 구성해 볼 수 있는지 알아보자.
실전 아키텍처!
2 tier architecture
2 tier는 보안적으로 매우 취약한 아키텍처이나, 3 tier의 중요성이 대두되기 전에 한 시대를 풍미한 아키텍처라고 보면된다.
간단히 아키텍처로 보자면 아래와 같다.
보는바와 같이 간단한 구조를 가지고 있다. 트래픽이 들어오면 lb에 의해서 분산되고 분산된 트래픽은 각 vm으로 간다. 이 lb 자리에는 lb말고 Application Gateway 같은 7계층 lb가 들어오기도 한다. 이 vm의 가장 큰 특징은 client에게 html, js, css를 전달하며 만약 client에서 요청이 올 시, 직접 db에 붙어서 처리한다.
이러한 구조가 보안적으로 취약한 이유는, 만약 vm이 공격을 받게 되면 바로 db까지 위험해질 수 있다는 점이다. 하지만 이러한 구조도 단점만 있는 것은 아니다.
장단점을 보자면,
장점
- 구성이 쉽다.
- 빠르게 구축 및 개발이 가능하다.
- 비용이 다른 구조들에 비해 가장 싸다.
단점
- 보안적으로 취약하다.
- web과 was가 분리되지 않아, scaling 관점에서 필요없는 리소스들까지 같이 늘어나기에 자원의 소모가 수반된다.
위와 같은 장단점으로 인해, 아래와 같은 상황에는 여전히 좋다고 생각한다.
- 중요한 데이터가 없고 간단한 정보성 페이지 구축시
- 내부망에서만 사용할 서비스라 보안은 크게 상관없이 적은비용으로 서비스를 제공해야할 때
약간 올드해 보이지만 아직도 이렇게 쓰는 곳, 정말 많다. 지금 우리가 아는 서비스들도 이렇게 구성된 아이들 정말 많을 것이다. 심지어 client쪽에서 was 안거치고 바로 browser -> db로 접근할 수 있게 구성된 사이트들도 셀 수 없다.
3 tier architecture
3 tier는 2 tier와 비교하였을 때, web과 was를 나눠놓은 구조이다.
web과 was가 분리됨으로써 보안이 조금 더 탄탄해졌다는 장점이 있다. was에서는 오로지 business logic 만 처리한다고 보면 된다.
위쪽의 구성도를 조금 더 살을 붙여 보자면 아래와 같다.
web과 was가 분리 되었기 때문에, 보안 쪽을 전부 web 서버 근처로 집중 시킬 수 있고, business logic이 돌아가는 vm들에게는 허용된 port만 열고 사용하는 구조로 hub and spoke 구조로도 많이들 쓴다.
위의 hub and spoke는 보안쪽 리소스가 가격이 생각보다 많이 발생되기에, 많은 기업들이 도메인 이름으로 사이트를 구분해서 트래픽을 라우팅해주고 각각의 business logic들이 각각의 웹을 위해 따로따로 구동되게 설정 또한 가능하다.
장단점을 보자면
장점
- 2 tier와 비교하였을 때, 보안적으로 많이 보안되었다.
- 구조상으로 hub and spoke와 같은 다른 아키텍처 패턴을 접목하기 편하다.
- web과 was의 업데이트가 분리되어 있어 업데이트가 있을시 영향을 덜 수 있다.
단점
- 여전히 was 쪽 scaling 관점에서는 필요없는 리소스들 까지 같이 scale out 되는 부분이 아쉽다.
N tier architecture
위의 3 tier architecture와 크게 다르지 않지만, was 쪽의 계층이 조금 더 세분화 되어 다층으로 구성되어 있는 구조를 말한다.
일반적으로 2 tier, 또는 3 tier architecture를 N tier architecture의 범주 안에 포함되어 있다고 볼 수 있지만, 보통 미팅자리에서는 2 tier면 2tier라고, 3 tier면 3 tier라고 보통 명시를 한다.
N tier라 하면 3 tier의 was 부분이 여러개로 쪼개 졌다고 이해하면 된다.
위의 구성도의 아래쪽 spoke와 같이, 바로 db에 접근해서 처리하는 로직도 있고, event hubs로 비동기로 한번 끊었다가 다른 was vm들이 다른 코드를 가지고 event hubs를 subscribing 해서 처리 후 db로 적재할 수도 있다.
장단점은 3 tier architecture와 비슷하나, 3 tier architecture라고 하면 무조건 tier를 3개로 쪼개야한다는 부담감이 있지만, N tier는 그러한 제한을 두지 않고 was를 최대한 잘 활용하기 위한 architecture라고 보면 된다.
마치며
웬만해서는 3 tier 이상으로 쪼개서 사용하는 것이 정신건강에 이롭다. 나중에 보안이나 다른 부분들이 고려되야 할 때, 2 tier는 너무 고통스럽다.
