참고
계층화된 아키텍쳐(Layered Architecture)
NOTE
계층(Layer) 단위로 분리하여 계층마다 특정 역할을 수행하도록 구성된 아키텍쳐를 의미한다.
N-계층에 따라서 다음과 같이 구분하여 관리한다.
각 계층은 논리/물리 적으로 분리되어 구성된다.
•
2계층 아키텍쳐
◦
프레젠테이션 레이어 - 데이터 레이어
•
3계층 아키텍쳐
◦
프레젠테이션 레이어 - 애플리케이션 레이어 - 데이터 레이어
•
4계층 아키텍쳐
◦
프레젠테이션 레이어 - 비즈니스 레이어 - 퍼시턴스 레이어 - 데이터베이스 레이어
•
n계층 아키텍쳐
◦
다중 계층 아키텍쳐라고도 하며 N계층 아키텍쳐는 둘 이상의 계층을 갖는 애플리케이션 아키텍쳐를 의미한다.
◦
일반적으로 생각하는 4계층에서 더 나아가서 5계층으로도 구성할 수 있고 상황에 따라 Tier를 나눈다.
4-Tier로 바라보는 계층 별 레이어 흐름
NOTE
해당 데이터의 흐름은 4-Tier 아키텍쳐로 구성하여 각각의 레이어에서 기능에 맞게 처리를 하여서 데이터를 통신하는 과정을 표현했다!
4계층에서 데이터 흐름
설명은 4계층으로 하지만 사실 3계층으로 많이배운다.
표현 계층(Presentation Layer) : Controller
•
해당 계층은 애플리케이션으로 들어오는 ‘요청’과 ‘응답’을 반환해주는 계층이다.
•
클라이언트로 받은 JSON/XML 형태의 데이터 구조 요청에 대해서 해당 처리 이후 반환을 해주는 역할을 수행한다.
•
비즈니스 로직이 포함되지는 않음
비즈니스 계층(Bsiness Layer) : Service
•
해당 계층은 비즈니스 로직을 처리하는 게층이다.
•
클라이언트로 전달받은 데이터에 대한 비즈니스 로직을 처리하여 영속성 계층으로 전달하는 역할을 수행한다.
•
확장성을 위하여 인터페이스와 구현체를 구분하여 사용이 된다.
영속성 계층(Persistence Layer) : Repository, DAO
•
해당 계층은 데이터베이스에 접근하여 데이터를 가져오며 데이터에 대한 영속성을 유지하는 게층이다.
데이터베이스 계층(Database Layer) : DB
•
데이터베이스 자체를 의미하는 게층이다!
3계층 아키텍쳐의 장점
NOTE
3계층 아키텍쳐의 주요 장점은 기능의 논리적 및 물리적 분리다!
•
기능적 요구 사항에 가장 적합한 별도의 운영체제와 서버 플랫폼에서 실행 될수 있다.
◦
ex) 웹 서버, 애플리케이션 서버, 데이터베이스 서버
•
각 계층이 하나 이상의 전용 서버 하드웨어 또는 가상 서버에서 실행되므로, 다른 계층에 영향을 주지 않고도 각 계층의 서비스를 커스텀 정의하고 최적화할 수 있다.
•
기타 장점(단일 && 2계층)과 비교하는 경우 다음의 장점이 있다.
◦
빠른 개발
▪
각 계층이 서로 다른팀에서 동시에 개발이 가능해진다.
◦
개선된 확장성
▪
필요에 따라 어느 계층이든 다른 계층과 독립적으로 확장할 수 있다.
◦
개선된 신뢰성
▪
한 계층의 가동 중단은 다른 계층의 가용성 또는 성능에 별로 영향을 미치지 않는다.
◦
개선된 보안
▪
각 계층이 직접적인 통신이 안되므로, 내부 방화벽이 동작해서 SQL 인젝션과 같은 공격을 방지 할 수 있다.
웹 개발의 3계층 애플리케이션
NOTE
웹 개발에서 계층은 서로 다른 이름을 갖지만 유사한 기능을 수행한다.
Spring에서 자주보는 구조
•
웹 서버
◦
프레젠테이션 계층이며 사용자 인터페이스 제공
◦
HTML / CSS / Javascript
•
애플리케이션 서버
◦
사용자 입력을 처리하는데 사용되는 비즈니스 논리를 수용하는 계층
◦
Python, Ruby, Spring 등의 프레임워크를 사용한다.
•
데이터베이스 서버
◦
데이터베이스인 MySQL, Oracle 등을 사용한다.
마이크로서비스 아키텍쳐
NOTE
하나의 큰 애플리케이션을 여러 개의 다른 역할을 수행하는 애플리케이션으로 분리한 아키텍쳐를 말한다!
멀티티어 아키텍쳐 접근 방식은 점차 진화하고 있다.
모놀리틱 아키텍쳐
NOTE
모놀리틱 아키텍쳐
•
이러한 경우 서비스가 지속적으로 성장하고 규모가 커질 때 한계에 부딪힌다.
•
개발자가 적을떈 상관없지만, 개발자가 많아지고 서비스의 복잡도가 증가하면 코드 관리가 어려워진다.
•
이로인해 배포 시간의 증가, 부분적 스케일 아웃의 어려움, 안전성 감소 등 여러가지의 문제점이 생긴다.
마이크로서비스 아키텍쳐
NOTE
마이크로서비스 아키텍쳐 (위에서는 4개의 서비스로 구성됨)
장점
•
각 서비스와 데이터베이스가 분리되어 있다.
•
서비스가 개별적으로 독립적인 단위의 애플리케이션이기 때문에 변경이 용이하고, 다른 서비스에 미치는 영향이 적다.
•
서비스의 특성에 따라 메모리 사용이나, CPU 사용이 많은 경우 그에 맞게 자원을 할당하여 스케일 아웃할 수 있다.
•
서비스가 분리되기에 코드 베이스가 작아져서 빌드/테스트가 쉬워진다.
단점
•
모놀리틱에 비해 서비스 간의 통신에 대한 처리가 추가적으로 필요하다.
•
수 많은 서비스를 배포하고 관리하는데 어려움이 생긴다.
이벤트 기반 아키텍쳐
NOTE
이벤트 기반 아키텍쳐는 2PC 없이도 분산 데이터베이스의 트랜잭션 문제를 해결하기 위해서 고안된 아키텍쳐이다!
이벤트 기반 아키텍쳐 (복잡버전)
이벤트 기반 아키텍쳐 (심플버전)
이벤트를 수신/발행 하면서 분리된 DB간의 트랜잭션을 관리할 수 있다!
•
마이크로서비스 아키텍쳐에서 고려해야 가장 어려운 부분은 분산된 데이터베이스의 트랜잭션을 어떻게 관리하는가 이다.
•
분산된 데이터베이스 또는 시스템들이 이벤트의 발행(publish) 및 구독(subscribe)을 통해 트랜잭션이나 연산 처리를 할 수 있음!
분산된 데이터베이스에서 트랜잭션 관리 이슈
NOTE
분산된 DB의 트랙잭션을 보기 전에, 모놀리틱 아키텍쳐에서 트랜잭션의 관리를 알아보자!
•
일반적으로 단일 데이터베이스는 트랜잭션의 안정성을 ACID 속성이라고 한다.
◦
Actomicity(원자성)
◦
Consistency(일관성)
◦
Isolation(고립성)
◦
Durability(지속성)
•
다양한 종류의 데이터 저장소
주문 서비스(실패) - 결제 서비스(성공)가 분리된 구조
이 경우 결제만되고 주문은 안되는 상황이 발생할 수 있다.
◦
마이크로서비스는 각 서비스별로 DB를 다르게 선택하므로 ACID 트랜잭션의 장점을 이용할 수 없다.
◦
이 경우 주로 발생하는 문제는 데이터의 정합성 이슈이다.
•
2단계 커밋(Two-Phase Commit : 2PC)
◦
트랜잭션의 원자성을 보장하기 위해 고안된 프로토콜
◦
자세히는 몰라도되고 가장 큰 문제가 대부분의 최신 기술들과 NoSQL이 이걸 지원안해줌..
이벤트 기반 아키텍쳐의 동작 방식
NOTE
1.
Message 생성 (Publisher/Subscribe)
•
이벤트가 생성되면 Subscriber(수신자)에게 전달된다.
•
이벤트는 반복되어 전달되지 않으며 ,수신자는 송신자의 정보를 알 필요가 없다.
2.
EventSource
•
Event Processor에게 이벤트를 전달하는 역할을 한다.
•
Event Source는 1개 이상일 수 있으며, 1개 이상의 Event Processor에게 전달된다.
3.
Event Processor
•
수신된 이벤트에 따라 여러 Action을 수행한다.
•
단일 이벤트에 타임스탬프를 추가하거나, 파생 이벤트를 만든다.
4.
Event Consumer
•
이벤트에 대한 처리를 한다.