소프트웨어 아키텍처의 계층과 장단점

https://www.educative.io/path/scalability-system-design

계층이 뭘까?

계층은 애플리케이션 혹은 서비스를 구성하는 컴포넌트들의 논리적인 분리이다. 여기서 말하는 분리는 코드레벨이 아니라 물리적인 위치의 분리이다. 논리적인 분리인데 어째서 물리적인 분리인지 헷갈린다.
분리의 단위가 되는 컴포넌트는 다음과 같다.

• DataBase
• Backend application server
• User Interface
• Messaging
• Caching

위의 나열된 컴포넌트들이 몇 개로 쪼개져 있는지에 따라 여러가지 애플리케이션 모델이 나눠지는데
각 모델의 장단점을 빠르게 알아보자.

Single-Tier Applications

User Interface, DataBase, Backend Business Logic이 같은 시스템에 있는 애플리케이션이다.
종류로는 MS Office나 한컴 오피스, PC Game, Gimp 같은 앱이 있다.

하나의 시스템(하드웨어)에 다 때려박은 이 애플리케이션은 latency가 없다.
네트워크가 연결이 되든 안되는 상관이 없이 사용자 컴퓨터 안에서 데이터도 저장하고, 비즈니스 로직도 실행되고, 상태도 유지하고 혼자 다해먹기 때문에 성능이 일관되게 좋다. 그렇기 때문에 사용자 컴퓨터 사양이 메롱이라면 일관되게 성능이 안좋다.

또한 정보가 사용자의 컴퓨터에 저장되고 그 정보는 네트워크를 타지 않기 때문에 높은 수준의 보안이 보장된다.

그런데 버그가 있을 경우 아주 곤란해진다. 제조사에서 버그를 패치한 버전을 내고 그것을 사용자가 직접 다운로드 받지 않으면
아무리 잘 패치된 버전이 출시가 된다고 해도 적용할 방법이 없다. 또한 비즈니스 로직까지 같이 배포가 되기 때문에 기업비밀이 노출될 수 있다.
마지막으로는 장비빨을 많이 받는다. 예를들어 최 고 급 사양의 하이엔드 컴퓨터에서는 0.1초만에 실행되는 애플리케이션이 성능이 떨어지는 컴퓨터에서는 10초가 걸리는 등 사용자 경험이 들쑥날쑥 하다.

Two-Tier Applications

client와 server를 분리 하면 Two-Tier Application이다.
single-tier에서 데이터 관리부분을 떼서 서버로 가져온 것인데,
지속적으로 네트워킹을 하는 것이 아니라 상태를 유지 혹은 변경을 위한 호출만 간간히 하기 때문에
적은 비용으로 데이터를 관리 할 수 있게 된다. 물론 네트워킹을 하기 때문에 latency는 발생하지만 심각하지 않기 때문에 괜찮다. 데이터를 관리하게 된다면 버그를 수정이 조금 더 쉬워진다는 장점이 있다.

Three-Tier Applications

User Interface, Backend Business Logic, DataBase 이 세가지 컴포넌트가 각기 다른 위치에 존재하는 애플리케이션이다. two-tier 애플리케이션에서 Business Logic부분을 서버로 가져온 것이다.
서버로 가져오게 되면 code나 Business Logic의 보안을 유지할 수 있다.

N-Tier Applications

3개 이상의 컴포넌트가 분리되어 있는 애플리케이션이다.
기존의 UI, Backend, DB 말고 다음의 컴포넌트들이 있을 수 있다.

• cache
• message queue
• load balancer
• search server
• component
• ...

3개도 많은데 계층을 더 쪼개서 사용을 하는 이유는 단일 책임 원칙 과 관심사의 분리 라는 두가지 규칙을 지키기 위해서다.
이 두가지의 규칙을 지키면 철저한 분업이 가능하다. 또한 확장 및 문제 해결 시에도 정확한 진단이 가능하다.

단일 책임 원칙

single responsibility principle
데이터 저장, 애플리케이션 로직 실행, 시스템에 동일한 메시지 전송 보장 등 개별적 컴포넌트 각각에 단 하나의 책임만 부여하는 원칙이다.
이 원칙을 지키면 응집도가 높아지고 하나의 책임에만 집중하기 때문에 유지보수가 용이해진다.

관심사의 분리

seperation of concerns
당장 맡은 일만 열심히 하라는 말이다. 관심사의 분리는 결합도를 느슨하게 만들어준다. 이 원칙은 tier level 혹은 code level에서도 동일하게 적용된다. 이를 통해 재사용 가능하고 확장성 있는 코드 혹은 애플리케이션을 만들 수 있다.