마이크로 서비스의 정의
다음 특징을 갖는 서비스들의 조합으로 이뤄진 설계
- 유지보수에 유리하고, 테스트 가능해야 함
- 느슨하게 결합되어야 함
- 독립적으로 배포 가능함
- 비즈니스 역량을 중심으로 구성해야 함
- 작은 팀에 의해 소유됨
반댓말 모놀리식 서비스
기존 기술적 계층에 따른 팀 분류
이런식으로 기술적 계층에 따라 팀을 분류하면 작은 변경에도 협업이 필요하기 때문에 협업비용이 증가하게됨
비즈니스 수행 능력(업무 도메인, 서비스)에 따른 팀 분류
팀이 하는 일이 하나의 서비스로 나뉘어짐 → 마이크로서비스
- 소프트웨어 스택, 데이터베이스 선택, 프로젝트 관리 등이 팀 별로 독립적이다.
전제조건
- 각 팀은 서비스에 대한 책임을 가져야 한다
- 각 서비스는 메시지 버스(통신 인터페이스)를 통해 통신해야 한다
컴포넌트 핵심: 컴포넌트가 개별적으로 대체 가능해야 하고, 업그레이드를 할 수 있어야 한다.
마이크로 서비스의 장단점
장점
- 모놀리스식은 작은 변경 사항도 응용 프로그램 전체의 재배포를 필요로 합니다.마이크로서비스는 변경한 서비스만 다시 배포하면 됩니다.
- 신속하게 개별 프로세스를 업그레이드 가능
단점
- 기존 서비스에 대한 변경이 이 서비스를 이용하고있는 다른 서비스에 영향을 주는지 여부를 신경써야 한다. (모놀리식->마이크로서비스로 이전하기)
- 서비스별 나누고 각각 배포하기는 복잡해지기 때문에 배포자동화가 필수적
마이크로서비스 아키텍처 구현 단계
서버리스
서버리스의 의미
serverless != noserver
serverless라고 하면 뜻 그대로 봤을때는 백엔드에 서버가 없다는 소리 인가 싶겠지만, 서버리스는 서버는 존재하지만 서버를 직접 관리하지 않는 경우를 뜻합니다. (추상화된 서버)
애플리케이션을 빌드하거나 실행할 수 있는 클라우드 네이티브 개발 모델
관리는 누가하나?
- aws lambda, google cloud funtions 등 플랫폼이 있음. (스케일링포함)
따라서 웹 애플리케이션 구축에만 집중하면 되게끔 할 수 있음.
서버리스를 사용하는 이유
- 요청이 없으면 서버 유지 비용을 지불 할 필요가 없음.
- 서버와 관련된 유지 보수를 신경 안써도됨.
- 사용 규모와 관련되서 신경을 쓸 필요가 없어짐.
서버리스 컴퓨팅 장단점
서버리스 장점
1. 서버관리가 필요 없기에 (풀스택) 제품을 빠르게 출시가능
2. 서버를 사용할때만 금액이 나오기 때문에 비용 절약가능(특수한 경우 제외)
서버리스 단점
1. 상시 대기중인 서버가 아니기 때문에 상시대기중인 서버 보다는 느릴 수 밖에없다. (cold상태로 대기중이기 때문)
2. 서버 제공자에 너무 의존 하게됨
-> aws lambda에 백엔드를 배포 했다면 마이그레이션이 쉽지 않다(서버리스로 작업시 애플리케이션 구조가 바뀜)
- 마이그레이션 : 다른 플랫폼으로 이동
마이크로서비스와 서버리스의 관계
- AWS기반에서 소규모 개발팀이 마이크로서비스를 구현하기에 가장 적합한 아키텍처 중 하나가 서버리스 아키텍처를 가진 형태라고 생각합니다. (반드시 이용할 필요없는 없음) 서버리스 방식으로 구현시 서버관리 인원을 줄일 수 있기 때문. 추가로, Stateless한 서비스의 경우 FaaS는 최적의도구
참고 : https://zdnet.co.kr/view/?no=20160614172904
서버리스의 특징 중 하나인 무상태성(Stateless)는 무엇을 의미 하는지?
- 일반적으로 말하는 서버리스는 FaaS라고 생각하면됨
그 중 무상태성을 가지는건 FaaS
FaaS는 함수가 실행 되는 중에만 자원을 할당하고 무상태성을 가지기 때문
서버리스 종류
FaaS, BaaS 의 특징
FaaS
- 함수를 실행시켜주는 서비스
- 함수는 클라우드 사업자가 제공하는 컨테이너에 담김
- 함수 실행이 끝나면, 컨테이너는 사라짐 (꾸준히 반복적으로 호출 되는것이 아니라면)
- 서버리스이므로, 자신의 코드에만 책임을 지면 됨
- 대표적으로, AWS Lambda
BaaS
- 서버 기술을 몰라도, 서버에 걸맞은 기술을 제공해주는 서비스
- API를 이용해 사용 가능
- 주요 기능 FaaS도 포함, DB제공(DBaaS), 파일스토리지, 컨테이너 실행환경, 메시지(이벤트)관리 도구
질문
q1) 마이크로서비스를 구성할 때, 데이터베이스를 꼭 분리해야 하나요? 데이터가 한 곳에 모여있지 않고 중복되어도 괜찮은가요? 모범 사례를 알아보고, 이유를 함께 적어주세요.
마이크로서비스를 구성한다고 하면 데이터베이스는 분리를 하는것이 맞다. 왜냐하면 데이터베이스를 한곳에서 관리하기엔 어떤 서비스의 경우 동기화된 데이터가 필요하고 어떤 서비스는 비동기화 데이터가 필요 할 수 있다. 또 서비스의 트래픽이 커짐에 따라 한곳에서 관리하다가 문제가 발생시 서비스 전체 장애가 발생 할 수 있기 때문에 따라서 규모가 있는 서비스라면 DB까지 서비스별로 분리해서 사용하는 것이 좋다. 하지만 여러 데이터베이스를 두고 사용한다면 분산 트랜잭션 이슈가 생길 수 있지만 결과적 일관성만 유지(Eventual Consistency)하는 방법으로 처리하면 된다.
결과적 일관성을 만들기 위한 방법으로는 트랜잭션 분리와 메시징 시스템 활용(메시지 큐, aws SQS, Apache Kafga)을 이용하는 방법이 있습니다.
모범사례로 배달의 민족 초창기 16년까지는 서비스는 분리 했지만 고성능 루비DB에다 모든 데이터를 관리하는 방식을 사용했다고 합니다. 그러다 하나의 서비스(리뷰)가 에러가 났는데 DB가 이어져 있다보니 다른 서비스까지 마비되는 사건 이후 마이크로 서비스로 이전을 결심하고 서비스별로 DB를 조금씩 분리하여 19년 11월에 완전한 마이크로 서비스를 완성했다고 합니다.
데이터가 한곳에 모여있지 않고 중복되어도 괜찮은가?
제 생각에는 데이터가 많이 중복 된다면 하나의 서비스로 운영하거나 결이 다른 서비스라면 불가피하게 데이터의 복제와 중복 허용이 필요합니다.
q2)여러 도메인을 가지고 있는 서비스에서, 하나의 서비스에서는 성공했지만 연관된 다른 서비스에서 실패하는 “부분 실패”의 경우 어떻게 처리해야 하나요? 음식 주문에서 결제에는 성공했지만, 주문에는 실패하는 경우를 예를 들어 설명하세요.
원래 MSA의 기본 패턴은 서비스A(주문결제)가 라고 생각하면 성공하고 연관된 서비스B(라이더스서비스)가 실패 할경우 서비스A는 응답을 못받고 응답 대기를 하게되는데 이러한 패턴을 극복한게 Circuit breaker패턴이다. a와 b 사이 서킷 브레이커를 두고 b서비스가 응답이 없다면 b 호출을 강제로 끊고 fallback 메소드를 실행 시켜 클라이언트에 주문이 실패 하였다고 전달 할 수 있음. Circuit breaker 사용함으로써 MSA를 이용할 때 서비스 간에 끼치는 영향을 최소화 할 수 있게됌
호용님 발표)
Q1)
마이크로서비스 설계 원칙
서비스별로 데이터베이스를 갖도록 설계
각 저장소 서비스별로 분산해야하고 반드시 API를 통해 접근해야함
불가피하게 데이터의 복제와 중복 허용이 필요
분산된 데이터베이스에서 발생할 수 있는 이슈 : 분산 트랜잭션 이슈
분산 트랜잭션 : 네트워크에 존재하는 2개 이상의 시스템사이에서 발생하는 트랜잭션
하나의 트랜잭션이 두 개의 시스템에서 연달아 발생한다면?
- 주문과 결제라는 서로 다른 서비스
- 데이터 일관성 유지가 매우 중요
해결법
데이터 일관성 유지 방법 : 결과적 일관성만 유지한다 (Eventual Consistency)
결과적 일관성(Eventual Consistency) : 어느 시점에서는 데이터가 서로 다를수 있지만 결국에는 모든 시스템이 최신 데이터를 가질 수 있도록 적용
결과적 일관성을 만들기 위한 방법
1. 트랜잭션 분리와 메시징 시스템 활용(메시지 큐, aws SQS, Apache Kafga)
바로 직접적으로 보내는게 아닌 중간에 메시지 버퍼를 두고 결과적으로 일관성을 맞추는 방식
CAP이론 : 시스템은 CAP 중 두가지 속성만 가질 수 있다
일관성, 가용성, 분할 허용성
마이크로서비스는 AP를 가지고 일관성은 결과적 일관성을 가짐
Q2)
부분 실패가 전체 실패로 이어지지 않게끔 하는게 중요함
해결책
네트워크 타임아웃
회로 차단기 패턴 : 타임아웃이 오면 서킷브레이커에서 바로 돌려주는 방식
정민 발표)
Q1)
마이크로 서비스는 분리하는게 기본적이긴 하지만 꼭 분리 하지 않아도 될 수 도 있겠다
shared datebase라는 패턴으로 마이크로서비스를 구현 해볼 수 있음
장점과 단점이 존재
장점
1. 서비스 중단 없이 지속적인 데이터 백업이 가능
2. 이벤트를 담는 메시지 브로커가 고장나도 데이터가 손실되진 않음
3. 데이터 관계가 매우 명확함 (쿼리는 복잡해질수 있어도 속도는 빠름)
4. 데이터 교환에 있어 네트워크를 사용할 필요x
단점
1. 스키마 변동이 매우 어려워짐 데이터 설계상 변화가 생겼을 때 유연하게 대처 불가
2. 수평확장이 힘들어짐
3. 하나의 서비스가 데이터베이스에 접근하고 있을 때 다른 서비스에서 접근이 불가능
이러한 단점이 있긴하지만 서비스가 적고 이용자수가 많지 않다면 고려해볼만 패턴
Q2)
부분 실패에 해결하는 방법
1. 결제 성공을 롤백하고 주문이 불가능하다는 메시지 클라이언트 전달
2. 결제 성공은 그대로 두고 주문이 가능해질때까지 클라이언트 대기시킴
API 디자인과 프로세스 간 통신
동기/비동기
| 서비스 | 작업 |
|---|---|
| 동기화 | 요청/응답 |
| 비동기회 | 비동기화 요청/응답 단방향 알림(푸시 알림) |
HTTP는 동기인가? 비동기인가?
- 네트워크 지연에 따라 즉시 응답이 오지 않아 비동기 인가 싶지만 통신하는 두 컴퓨터는 모두 켜져 있어야 하고 클라이언트는 바로 응답 받기를 기대하기 때문에 동기적이라 할 수 있다.
REST
REST는 HTTP로 소통하는 프로세스 간 통신 규약입니다. REST API는 웹에서 사용되는 데이터나 자원(Resource)을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식입니다.
REST 장단점
장점
- 포스트맨, curl 등의 도구를 사용해 간편하게 테스트가 가능합니다.
- 요청/응답 통신을 직접 지원합니다.
- 시스템 아키텍처가 단순합니다.
단점
- 요청/응답만 지원합니다.
- 메시지를 주고받기 위해서는 클라이언트와 서버 프로세스가 둘 다 실행 중이어야만 합니다.
- 요청 한 번으로 여러 리소스를 조회하기 어렵습니다.
- 메소드만으로는 한번의 요청을 통해 이루어지는 다양한 작업들을 대표하기 어렵습니다.
메시지 브로커를 이용한 비동기식 통신
메시지 브로커가 필요한 이유
- 강하게 결합된 시스템에서의 단점은 서로 연결되어 있는 시스템 중 한 곳에서 장애가 발생했을 때 그 장애가 연결된 다른 시스템들에 영향이 가는것이다
예시로 서버1이 서버2에 데이터를 보냈을때 서버2가 어떤 이유로 장애 상황이 발생한다면 서버1에서 보낸 데이터가 서버2에 DB로 들어가지 못하고 유실되는 상황이 발생함 만약 중간에 메시지 브로커가 있다면 서버2에 일시적 장애가 발생하더라도 복구 기간 동안 메시지 브로커가 메시지를 보관해두고 있다가 보내주기 때문에 데이터 유실이 일어나지 않음
메시지 브로커 특징
- 프로그램 간 직접 연결 없음 : less dependency, fault tolerant
- 메시지 브로커에 있는 메시지는 소비자(수신자)가 꺼낼 때까지 안전하게 보관됨
- 통신이 이벤트에 의해 구동 될 수 있음
:큐의 상태에 따라 프로그램을 제어 할 수 있음 - 확장 용이 (메시지 브로커는 여러 큐를 만들거나, 수평적으로 확장하여 메시지 부하 증가 처리가능
메시지 브로커 선택의 기준
- 프로그래밍 언어 지원 여부
- 메시징 표준 지원 여부
- 메시지 순서 보장 여부
- 전달 보장 여부: 어떤 종류의 전달을 보장하는가?
- 영속성: 브로커가 고장나도 문제가 없도록 메시지가 디스크에 저장되는가?
- 내구성: 소비자가 메시지 브로커에 다시 접속할 경우, 접속이 중단된 시간에 전달된 메시지를 받을 수 -있는가?
- 확장성
- 지연 시간
질문2
Q3) 메시지 서비스로는 대표적으로 Apache Kafka와 Amazon SQS, Amazon Kinesis가 있습니다. 각각은 어떤 차이가 있나요?
Amazon SQS 특징
SQS는 Queue 기반으로한 애플리케이션을 쉽게 분리하고 확장할 수 있도록 지원하는 완전 관리형 메시지 대기열 서비스
Amazon SQS의 장단점
장점
- 메시지를 안정적 전달가능(메시지의 복사본 여러 개가 다중 가용 영역 전체에 중복으로 저장되므로 필요할 때 언제든 사용할 수 있습니다.)
- 확장 용이하고 신뢰성이 높다
단점
- Text메시지만 지원
- point to point형태 (하나의 메시지를 다수의 컨슈머에 전달 불가)
Amazon Kinesis 특징
kinesis는 여러 소스에서 실시간 데이터 톤을 수집하고 처리하는 Data Stream 기반 데이터 송/수신 시스템
장점
- 대용량 로그, 데이터 수집/분석등 대규모 데이터 처리에 안정적이다.
- 완전관리형으로 사용자는 인프라를 관리할 필요가 없음
단점
- kafka에 비하면 처리량이 느림
Apache Kafka 특징
Apache Kafka는 이벤트 스트림을 쓰고 읽을 수 있는 오픈 소스 된 이벤트 스트리밍 플랫폼입니다. 실시간 데이터를 분석하고 데이터 통합하는데 유용함
장점
- 성능이 Kinesis에 비해 뛰어남 (높은 처리량)
- 무료 오픈 소스
단점
- Java만 지원함
- 조금더 고급 기술 수준을 필요로함
결론
완벽하게 관리 가능한 메시지 대기열 서비스 필요하면 SQS 반면 실시간 데이터가 요구 사항이라면 Apache Kafka, Amazon Kinesis가 최선의 선택입니다.
Q4) 웹 서비스에서 메시지 브로커(메시지 큐)를 이용해 비동기적인 방법이 활용되는 사례를 하나 이상 찾아보고, 어떻게 활용되는지 설명하세요.
활용되는 사례에 대한 예시로 배달의 민족이 어떻게 마이크로 서비스로 이전했는가에 대해 찾아 보았고 좋은 예시가 있어서 가져왔습니다.
배달의민족이 점점 성장함에 따라 트래픽에 의한 서버 장애가 계속해서 일어나고 마이크로서비스로의 이전을 결심하고 기존에 하나로 되어있던 루비DB에서 하나 하나 개별DB로 떼어내 가고 있었는데
(초창기의 배민은 모놀리식 시스템은 분리 되어있었지만 DB가 통합된 형태였음)
배민이 마이크로서비스로 이전할때 겪은 가장 큰 문제들중 하나인 주문DB를 어떻게 분리했는가에 대해서 입니다.
우선 기존 주문시스템에서는 API기반으로 기본적인 서비스 외에 연계 서비스들이 다 동기화 방식이다 보니 리뷰 푸시알림 시스템에서 장애가 발생했는데 주문시스템에 영향이 가는것을 보고 메시지 브로커를 활용한 아키텍처를 새롭게 추가 하였습니다. 라이프 사이클을 aws.sns로 이벤트를 저장하고 aws.sqs에서 필요한 이벤트를 호출하여 전달하는 이벤트 기반 데이터 전달 방식으로 구성하여 도중에 서버가 끊겨도 다른 시스템이 영향이 가지 않고 다시 연결되면 데이터를 보내 주게끔 만들어내고 이후 다른 주문데이터가 필요한 새로운 서비스 확장도 굉장히 편하게 확장 하는데 성공 했다고 합니다.
