[클라우드] 마이크로서비스 아키텍처

http://guruble.com/마이크로서비스microservice-아키텍처-그것이-뭣이-중헌디

마이크로서비스 아키텍처. 그것이 뭣이 중헌디?

정의

• 마이크로서비스
  - 하나의 큰 애플리케이션을 여러 개의 서로 다른 역할을 수행하는 애플리케이션으로 분리했을 때 각 애플리케이션
• 마이크로서비스 아키텍처
  - 마이크로서비스들로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처

 

마이크로서비스 아키텍처는 언제 필요한가?

• 애플리케이션 배포가 1시간 이상 소요
• 강한 커플링
  - 단순 기능 하나 수정에 전체 기능에 대한 QA 필요
  - 단순 버그 수정이 심각한 버그를 만드는 일이 잦아짐
  - 기능으로 나눌 때 수십 개의 마이크로 서비스로 분리 가능

 

마이크로서비스 아키텍처의 장단점

• 장점
  • 효율적인 자원 사용
    - 서비스 특성에 맞게 자원 할당 가능
  • 회사의 조직 문화
    - 서비스를 분리함으로써 다른 서비스에 대한 side effect이 줄고 독립적인 배포가 가능
• 단점
  • 서비스 간 통신에 대한 처리
    - 추가적인 개발
    - 사용자 요청 처리 속도
  • 분산된 데이터베이스의 정합성
    - 트랜잭션 관리가 용이하지 않음
    - 서로 다른 데이터베이스에 대한 정합성이 필요할 수 있음

 

API Gateway

• 필요한 이유
  
  • front UI에서 하나의 페이지를 서로 다른 서비스들이 처리
    - 뉴스 / 광고 / 날씨 등등
  • 1) 클라이언트에서 모든 마이크로서비스의 호스트와 endpoint(IP)를 알아야 함
  • 2) 응답속도가 요청 보내는 서비스의 수에 비례하여 증가
• 역할
  • 서비스로 전달되는 모든 API에 대한 gateway
  • 클라이언트는 서버의 아키텍처에 상관없이 gateway를 통해 요청/응답
    - network의 gateway와 같은 역할
• 동작순서
  • 클라이언트의 요청을 API gateway가 받음
  • API gateway가 해당하는 마이크로서비스에게 각각 요청을 보냄
  • 취합한 내용을 클라이언트에게 응답
• 추가적인 역할
  • 로드밸런서
    - 전체 시스템 부하 분산
  • 캐싱
    - 동일 요청에 대한 불필요 작업 감소
  • 모니터링
• 고려사항
  • 각 마이크로 서비스로 보내는 요청의 선후관계 파악 필요
  • 예외 처리
    - 특정 서비스에 장애가 발생했을 때에 대한 처리 구현이 필요
  • bottle neck이므로 캐싱 활용이 중요

 

이벤트 주도 (Event-driven) 데이터 관리

• 분산된 데이터의 트랜잭션 관리
  • 모놀리식의 단일 데이터베이스에서 트랜잭션 관리 ACID
  • Atomicity(원자성)
    - 하나의 트랜잭션에 포함되는 여러 작업은 반드시 함께 성공/실패
  • Consistency(일관성)
    - 트랜잭션의 결과가 항상 데이터베이스의 유효한 상태를 보장 (constraints, cascading)
  • Isolation(고립성)
    - 각 트랜잭션이 서로 영향을 주지 않고 독립적으로 수행됨을 보장
  • Durability(지속성)
    - commit된 트랜잭션은 어떤 장애상황에서도 유실되지 않고 유지됨을 보장
• 마이크로서비스 아키텍처에서 저장소
  • 마이크로서비스들은 독립적으로 데이터베이스를 관리
  • 이 데이터에 접근하기 위해선 반드시 해당 마이크로서비스의 API를 거쳐야함
  • 데이터베이스의 종류가 서로 다를 수 있음
  • 따라서, ACID 트랜잭션의 장점을 이용할 수 없음
• 분산된 데이터베이스 트랜잭션 관리 이슈
  • 결제만 되고 주문은 실패하는 상황이 발생할 수 있음

http://guruble.com/마이크로서비스microservice-아키텍처-그것이-뭣이-중헌디

• 2단계 커밋 (Two-Phase Commit: 2PC)
  • 분산된 트랜잭션의 원자성 보장을 위해 고안된 프로토콜의 구현체
  • 동작과정
    • 1) 코디네이터 서버에서 트랜잭션 시작과함께 다른 서버에 트랜잭션을 요청
    • 2) 각 서버에서 트랜잭션이 완료되면 코디네티어 서버에 commit할 준비가 완료됨을 알림 (준비 단계 : Prepare phase)
    • 3) 모든 서버 준비가 완료되면 코디네이터 서버에서 각 서버에게 커밋 수행을 요청
    • 4) 하나의 서버에서라도 문제가 발생시 전체 상태를 롤백 (커밋 단계 : Commit Phase)
  • 그러나, NoSQL 및 최근 기술에서 2PC를 지원하지 않음
• Event-driven Architecture
  • 이벤트의 publish/subscribe으로 트랜잭션 처리가 가능하도록 만들어진 아키텍처
  • 단점
    • 복잡함
    • 실패에 따른 트랜잭션 복원 기능을 구현해야함
    • 중복 이벤트를 감지하여 무시하는 기능을 구현해야함
  • 트랜잭션의 원자성을 보장하는 방법
    • 로컬 트랜잭션 이용
    • 트랜잭션 로그 이용
    • 이벤트 소싱

http://guruble.com/마이크로서비스microservice-아키텍처-그것이-뭣이-중헌디

• 이벤트 소싱 (Event sourcing)
  • 객체의 현재 상태를 저장하는 것이 아니라, 상태 변화에 대한 일련의 이벤트를 저장
  • 원자성 보장 / 누락 이벤트 처리를 위해
    
    • 특정 객체의 최신 상태 조회가 가능해야하고
    • 상태에 이르기까지 변화 순서를 알아야 함
  • 예시
    • 전통방식
      - 각 주문정보가 데이터베이스 테이블의 하나의 row
    • 이벤트 소싱
      - 데이터베이스 테이블에 주문정보의 상태 변화 이벤트(생성/결제완료/배송/취소 등)가 저장
  • 메시지 브로커가 없음
    • 이벤트 스토어라는 저장소에 이벤트를 저장
    • 객체 변화에 대한 이벤트 저장/조회가 가능한 API 제공
  • 이벤트 수가 많을수록 성능이 매우 느려질 수 있음
    • 해결방법1 : 특정 시점에 누적정보 스냅샷 저장
    • 해결방법2 : 명령과 질의의 책임 분리(Command Query Responsibility Segregation, CQRS)
      - 이벤트 스토어 : 이벤트를 저장하는 Command를 기록
      - 데이터 스토어 : 이벤트 결과인 객체의 현재 상태에 대한 Query를 수행

http://guruble.com/마이크로서비스microservice-아키텍처-그것이-뭣이-중헌디

http://guruble.com/마이크로서비스microservice-아키텍처-그것이-뭣이-중헌디