빗썸 테크 아카데미 (BE 심화 과정) - 2주 2일차

donchanee·2022년 4월 19일

msa

빗썸 테크 아카데미 (BE 심화 과정)

목록 보기

6/10

Microservice Architecture

소프트웨어 모듈화

큰 문제를 해결하기 위해 작은 단위로 나누어 개발하는 방법
서비스 기능의 확장, 수정, 테스트, 재사용 관리
모듈 설계 조건
- 모듈마다 독립적 기능을 가져야 함
- 독립적 컴파일, 빌드, 실행이 가능해야함 (컴파일만 가능해도 된다)
- 한 모듈에서 다른 모듈을 호출할 수 있어야 한다

모듈화를 하면

캡슐화가 가능해짐
추상화가 가능해짐
독립성을 가짐

서로 다른 모듈끼리 낮은 결합도 및 모듈 내부의 높은 응집도를 가짐

모듈이 많아지면 많아질수록, 개발하고 관리하는 비용이 늘어남

고로 적절한 수의 모듈 분리가 필요하다.

Service Oriented Architecture (SOA)

얼마 전까지는 SOA가 정답인줄.. 하지만 살짝 옛 것이 된 개념

분산 컴퓨팅 환경에서 개발 환경에 상관없이 동일한 서비스가 동작해야한다는 목적이 있고,

플랫폼에 비종속적이며 서비스 유지보수가 용이해야한다는 것이 요구조건이다.

이것을 맞추기 위해 나온 것이 SOA이다.

SOA는 3-tier로 이루어져 있는 독자적인 서비스들이 통합되어 비즈니스 프로세스를 형성하도록 하는 설계 방법론이다.

서비스가 어디있는지 알아야 하기 때문에 서비스 위치 투명성과, 독립적 및 약결합이라는 특징

하지만, DB가 하나로 연결되어 있는 단점과 이를 현대화 시킨게 MSA이다.

Microservice Architecture

어찌보면 SOA와 비슷하다. Service APP 별로 최적화된 언어 및 저장소가 가능하다.

서비스 별로 독립적인 기능과 용량 확장 (Scale-up, Scale-down)이 가능하고,

독립적인 배포도 가능하다. 또한 서로 내부 API를 통해서 통신해야하는 아키텍쳐이다.

흥하게 된 배경은,

업부 조직 구성이 바뀌게 된 배경이 있다. 역할별로 팀 구성에서 목적별로 팀 구성으로 바뀌게 되었다.

목적별로 사람을 모아서 작은 서비스를 만드는 것이 추세이다.

빠른 개발, 빠른 실험 문화가 확산되기 시작하면서 빠르게 시장에서 실험하는 것을 목표로 하다보니 목표에 가장 빠르게 도달할 수 있는 방법론을 선택하게 됨

도구를 취사선택하다보니, DB도 따로 만들어 따로 쓰게 되고 개발 생명 주기도 빨라지게 됨

빨리 만들어서 빨리 폐기하는 것이 자연스러운 흐름

Polyglot - 다른 언어 혼용

Monoliths vs Microservice

모놀리스는 2-tier / 3-tier로 표현되던 거대한 일체형 APP

하나 빌드하는데 2시간씩 걸리는 등의 단점이 있는게 모놀리스

새로운 요구사항이 추가될 수록 배포 부담이 늘어났고, 특정 개발 언어와 DB에 종속적이었다.

이런 것을 취사선택 할 수 없고, 처음 선구자가 정해놓은 스펙을 따라야 하는게 별로였다.

그런 이유로 마이크로서비스 형태가 등장하게 됨

마이크로서비스의 단점은 수많은 내부 서비스 Call이 발생을 하고,

트랜잭션 관리의 난이도가 상승하며, 데이터 무결성을 보장하기 위한 난이도가 올라간다.

고로 트러블슈팅 시 숙련된 개발자의 역량이 요구됨

MSA 설계 원칙

단일 책임 원칙
- 관심사의 분리
- 명확한 모듈 경계 설정
마이크로서비스는 자율적
- 독립적 배포
- 독립적 실행
- 독립적 확장/축소

MSA 설계 시, 너무 많은 내부 서비스 Call을 안하도록 고려해야한다.

또한, 순환참조나 동기적 의존관계가 없는지도 유의해야 한다.

동시에, 트랜젝션 범위가 너무 많은 서비스에 여기저기 있지는 않는지도 고려해야하고,

마이크로한지, 모놀리식화 되지 않았는지

또한 분리 시 유의미하게 독립시켜야 할 이유가 있는지 등을 고려해야 한다.

MSA 통신 패턴

HATEOAS

Rest API 제약 조건 (stateless, cacheable, layered, Uniform Interface) 중 유니폼 인터페이스 만족 여부
URI는 리소스를 식별할 수 있어야 함

Netflix OSS

Eureka
Microservice APP의 주소록이다.
각 MicroService APP은 유레카의 클라이언트 (데몬 같은 형태로 각 앱에 설치)
스프링의 어노테이션만 등록하면 완료되도록 현재는 구성되어 있음
아직 종종 사용이 된다
Zuul
API 게이트웨이의 초창기 구현체이다.
Endpoint가 여러개로 흩어져 있을텐데, 각 앱의 내부 도메인을 감추면서 관리된 주소를 받아 내부 서비스로 전달해주는 라우터 역할을 함
필터를 적용할 수 있다. (프리 필터, 포스트 필터 등)
Hystrix (중요)
MSA의 취약점 중 하나를 극복하기 위한 소프트웨어
장애 상황에서 사용할 수 있는데, 4개의 디펜던시에 대해 하나로 묶어서 응답을 주는데
4개 모두 정상반응을 해야 응답을 제대로 줄 수 있음
그러나, 그 중 하나가 죽으면 유저 리퀘스트는 정상적인 응답을 할 수가 없음 (500을 받아버려서)
이 경우에, 전체 응답이 500이 나버리게 된다.
만약 이게 자주 쓰이는 API면, 이 죽은 디펜던시 때문에 전체가 죽어버리게 됨
즉, 장애가 전파됨
이를 히스트릭스로 어떻게 해결을 했느냐?
각 리퀘스트들이 디펜던시를 직접 호출했었는데, 그 사이에 중간 콜백 스택을 둬서 주식의 서킷브레이커와 비슷하게 실패가 중첩될 경우 Fault를 끊어버리는 개념
실패가 N번 이상 쌓이면 해당 디펜던시에 요청을 하지 않도록 막아버림
일정 간격으로 시도하다가 계속 안되면 미리 막고, 만약 정상상태로 돌아오면 다시 원래대로 응답을 보내줌
실패하는 서비스를 잠시 멈춰두는데 목적이 있음