Software Architectural Pattern
Software Architectural Pattern는 다양한 런타임 단위로 작동하는 components를 목적에 맞게 구성하는 방법론을 말한다. 일반적으로 해결하고자하는 문제에 적절한 Software Architectural Pattern을 사용하게 되면 여러가지 이점이 있다. 1. 시간과 자원을 아낄 수 있다. 2.개발, 유지보수, 확장성을 갖춘 체계적으로 시스템을 구성할 수 있다. 3. 구성원들이 시스템을 더 잘 이해하여 follow에 어려움이 적다. 하지만 초기에 적절한 패턴을 사용하더라도 시스템은 계속 변화하야 특정 시점이 되면 다른 패턴으로 변경해야할 필요성이 있을 수 있다. 이런 경우에도 이미 다른 곳에서 migration한 전례가 있을 가능성이 높다. 이를 참고하여 System에 적절한 best practice를 follow하면된다.
Multi-Tier Architecture
Multi-Tier Architecture는 물리적, 논리적으로 시스템 계층을 나눈 것이다. 물리적 분리는 개발, 업그레이드, 확장의 측면으로 계층을 나눈것이고 논리적 분리는 책임 범위에 따라 나눈 것이다. 종종 Multi-Tier와 Multi-Layer를 혼동하기도 하는데 Multi-Layer는 단일 애플리케이션 안에서 여러 논리적 계층이나 모듈로 나눈것을 말한다. 이렇게 나누더라도 여전히 하나의 애플리케이션, Tier에 불과하다.
Multi-Tier Architecture의 여러 이점을 취하기 위해선 몇가지 제한사항이 존재한다. 첫번째로는 인접한 계층과 짝을 이루는 애플리케이션은 클라이언트-서버 모델의 관계로 통신을 해야한다. 두번째로는 계층을 뛰어넘는 통신을 할 수 없다는 점이다. 이로서 coupling을 느슨하게 할 수 있다.
Multi-Tier Architecture중 가장 흔하게 사용하는 방식은 3-Tier Architecture이다. Presentation-Logical-Data로 총 3단계로 나누어진다. 이 방식은 Online Store, News Website, Streaming Service에 걸쳐 다양하게 사용된다. 또한 수평확장에 용이하다는 장점이 있다.
하지만 Logical Tier에만 functionality, feature가 존재하기 때문에 코드가 무거워져 고성능 머신을 필요로한다. Java, C#을 사용한다면 garbage collection이 더욱 자주 일어나 애플리케이션이 느려질 수 있다. 수직적 확장의 비용 또한 무시할 수 없다.
코드가 무거워지게되면 복잡성으로 인해 개발, 유지보수에 어려움이 생기고 merge conflict가 더 자주 생기는 문제도 발생할 것이다. 논리적으로 코드베이스를 모듈단위로 분리할 수 있지만 모듈간의 의존성으로 인해 한계에 부딪힐 것이다. 결론적으로 3-Tier Architecture는 확장성이 제한된다.
3-Tier Architecture는 Monolithic Architecture라고도 불리기도 한다. 코드베이스가 작고 복잡하지않고 팀의 규모가 작을때는 좋은 방법이 될 수 있다.
Multi-Tier Architecture에는 3-Tier Architecture외에 다른 방법도 존재한다.
2-tier는 presentation tier와 logical tier를 합쳐 logical tier의 overhead를 제거하였다. 따라서 유저에게 빠른 네이티브 앱 경험을 선사할 수 있다. 대표적으로 문서, 이미지, 음악 편집 툴이 이에 해당한다.
4-tier는 Presentation tier 와 logical tier 사이에 API/Caching/Security Tier를 추가한 것을 말한다. 이 계층에는 API Gateway와 같은것이 포함될 수 있다.
MSA(Micro Services Architecture)
Monolithic Architecture의 functionality, feature의 중앙집중화로 가져오는 단점을 해결하기위해 MSA를 사용한다. 비지니스 로직을 독립적/느슨한 커플링을 가진 서비스로 나누고 각 서비스를 작은 팀단위로 관리하게 만드는 방법이다. 자연스레 코드베이스가 줄어들어 개발 효율성, 성능이 증가하고 느슨한 커플링으로 인해 수평확장성이 증가한다.
MSA를 구성할때 주의사항이 존재한다.
1. 각 서비스는 단일 책임만을 가져야한다. 이를 SRP(Single Responsibility Principle)이라고 한다.
2. 서비스단위로 DB를 분리해야한다.
MSA를 도입하는 것이 항상 옳은 것은 아니다. MSA는 시스템의 복잡성을 낮추기 위한 것이지만 규모가 작을때는 오히려 복잡성을 증가시킬 수도 있다. 따라서 초기에는 Monolithic Architecture가 좋은 방법이 될것이다.
Event Driven Architecture
Event는 fact, change에 대한 immutable statement를 의미한다. Event Driven Architecture는 message broker를 활용하여 서비스간의 연결을 하기때문에 서비스간의 coupling을 약화시킬 수 있다. 이 방식을 사용하면 확장성을 높일 수 있고 다양한 서비스를 쉽게 추가할 수 있다. 또한 데이터를 분석하거나 패턴을 분석을 실시간으로 수행할 수 있다.
Event sourcing pattern이 자주 사용된다. 이 pattern을 사용하면 일련의 event를 통해 상태를 구할 수 있어 DB를 필요로 하지 않는다. 하지만 event는 immutable하기때문에 update를 하기 위해선 과거의 event를 상쇄할 새로운 event를 추가해야한다.
CQRS(Command Query Responsibility Segregation)는 read와 write를 하는 DB를 분리하는 것을 말한다. write 전용 DB에 변경이 감지되면 message broker를 통해 변경사항을 read 전용 DB에 전달한다. 이 방식을 사용하면 MSA에서 서로 다른 DB에 존재하는 테이블을 합쳐서 사용하기 용이하다.
