[0503] 마이크로서비스 - 마이크로서비스 구조와 특징

• 마이크로서비스 아키텍처의 정의
  • 유지보수에 유리하고, 테스트가 가능해야 함
  • 느슨하게 결합되어야 함
  • 독립적으로 배포 가능함
  • 비즈니스 역량을 중심으로 구성해야 함
  • 작은 팀에 의해 소유됨
• 서비스로서의 컴포넌트화
  • 컴포넌트: 독립적으로 대체하거나 업그레이드 가능한 소프트웨어 단위
  • 컴포넌트화: 시스템을 구성 요소(Component)로 나누고 이를 연결하여 구축하는 것
  • 컴포넌트화는 어떻게? → 소프트웨어를 여러 서비스로 분리하는 것
• 라이브러리 vs 서비스

• 비즈니스 수행에 따른 구성, 프로젝트가 아닌 제품
  • before: 기술적 계층에 따른 팀 분류
    • 예) UI팀, 비즈니스 로직팀, 데이터베이스팀 등
    • 단순한 변경이 필요한 경우에도 팀 간의 협업 비용이 증가함

• after: 비즈니스 수행 능력(업무 도메인)에 따른 팀 분류
  • 도메인
    • 하나의 온전한 시스템 단위
    • 예) 쇼핑몰의 경우, 회원/상품/배송이 각각의 도메인이 됨
  • 팀이 하는 일이 하나의 서비스로 나뉨 → 마이크로서비스
    • 장점: 소프트웨어 스택, 데이터베이스 스택, 프로젝트 관리 등이 팀 별로 독립적임
    • 이를 달성하기 위해 각 팀은 서비스에 대한 책임을 가져야 하며, 각 서비스는 메시지 버스(통신 인터페이스)를 통해 통신해야 함

• 조직과 아키텍처의 연관성
  • 마이크로서비스로 소프트웨어를 작성할 때에는, 소프트웨어 작성에 앞서 팀의 일하는 방식을 보다 독립적으로 만들어내야 함
  • 마이크로서비스 아키텍처를 통해 팀의 일하는 방식이 보다 독립적으로 만들어질 수 있음
• 현명한 엔드포인트와 바보 파이프라인
  • 특징
    • 서비스(엔드포인트)는 일을 하게 하고, 통신(파이프라인)은 최대한 단순하게 함
    • 마이크로서비스에서의 프로세스 간 통신은 해당 접근 방식을 따름
    • 서비스와 서비스 사이는 느슨(decoupled)하게, 응집성은 높게
  • 대표적인 방법
    • REST API(HTTP)
    • 메시지 버스를 이용한 메시지 전달(메시지 큐)
• 분산화 거버넌스, 분산화된 데이터 관리
  • 문제점
    • 중앙 집중적인 시스템은 기술을 표준화하는 경향이 있음
    • 예) node.js로는 간단하게 만들 수 있는 것을 굳이 Java를 이용해서 만드는 경우
  • 해결책
    • 분산화된 시스템
      • 소프트웨어 스택, 데이터베이스 스택, 프로젝트 관리 등 팀 별로 독립적으로 구성
        • 데이터에 대한 분산 책임이 따름
        • 서비스 데이터베이스 간의 일관성이 중요 → 트랜잭션 협조가 중요
    • 분산화된 응용 프로그램 설계 → 도메인 주도 설계(DDD, Domain-Driven Design)
      • 도메인 경계를 분명하게 설정
• 장애 방지 설계(모놀리틱 설계에 비해 불리한 지점)
  • 서비스는 언제든지 실패할 가능성이 있음
  • 신속하게 장애를 감지하고 가능하면 자동으로 서비스를 복구할 수 있어야 함
    • 예) 아키텍처 요소(데이터베이스가 받는 1초당 요청 수)와 비즈니스 관련(1초당 받는 주문 번호 등) 부분을 모두 확인
  • 대시보드와 모니터링은 필수적임
• 진화하는 설계
  • 컴포넌트 핵심: 컴포넌트가 개별적으로 대체 가능해야 하고, 업그레이드를 할 숭 ㅣㅆ어야 함
  • 장점
    • 모놀리스: 작은 변경 사항도 응용 프로그램 전체의 재배포를 필요로 함
    • 마이크로서비스: 변경한 서비스만 다시 배포하면 됨
    • 간단하고 신속한 출시 프로세스
  • 단점
    • 기존 서비스에 대한 변경이 이 서비스를 이용하고 있는 다른 서비스에 영향을 주는지 여부를 신경 써야 함

---

마이크로서비스 아키텍처 구현 단계

---

•  

• 항상 모든 경우에 마이크로서비스 아키텍처가 필요한 것은 아님
• 성숙도 모델 중 어떠한 방식을 Level 3로 전환한다고 해서 더 나은 서비스가 되는 것은 아님
• 무작정 마이크로서비스 아키텍처를 도입하기 전에 다음을 이해한 후에 도입해야 함
  • 각 단계에 있어서 해당 방식이 갖는 장단점
  • 기존(Legacy) 시스템의 작동 방식
  • 현재 시점의 요구사항

---

서버리스

---

• 웹 애플리케이션을 적은 예산, 빠르게, 확장 가능, 관리와 운영은 쉽게, 혼자 할 수 있을까?
• 이에 대한 해결책은 “서버리스”
• 정의: 서버가 없는 것이 아니라 서버에 대한 고민을 안 하는 것
  • 따라서 애플리케이션 구축 자체에만 집중하는 것이 가능
• 등장 배경
  • 과거에는 애플리케이션을 배포하기 위해 직접 하드웨어 서버를 구매해서 구성함
  • 하드웨어와 소프트웨어 둘 다 관리해야했고, 서버 관리 비용과 메모리 관리 등 단점 존재
  • 하드웨어 관리의 어려움을 해결해 준 것이 AWS 클라우드 컴퓨팅 서비스인 EC2
  • 하드웨어 관리의 불안감을 덜 수 있게 되었으나, 빌려서 구성한 서버의 소프트웨어도 보안, 업데이트, 백업과 같은 많은 관리 과정이 필요함
  • 이런 서버의 소프트웨어 관리의 어려움을 해결하는 방안으로 등장한 것이 Serverless
• 서버리스 - 클라우드 컴퓨팅의 진화
  • 데이터 센터에서의 물리적 서버 → 가상 서버(AWS EC2)
    • 활용률 증가, 프로비저닝 속도 증가, 높아진 가동 시간, 재해 복구, 하드웨어 독립성
  • → 컨테이너(AWS ECS) → 서버리스(AWS Lambda)
    • 자본 비용 → 운용 비용, 높은 확장성, 탄력적인 리소스, 빠른 속도와 민첩성, 유지보수 비용 감소, 고가용성과 내결함성
    • 단점: 가상 서버 관리, 용량 및 활용률 관리, 워크로드 사이징, 고가용성과 내결함성 관리, 간헐적 작업시 비쌈
• 장점
  • 서버 관리 불필요
  • 유연한 확장성
  • 고가용성
  • 유휴 용량 없음