[클라우드] 9. MSA (MicroService Architecture)

IT 운영의 3대 과제

• IT 운영 조직의 최대 관심사
  • 운영 시스템의 장애, 성능, 변경 대응 (+ 보안, 규제)
  • 세 가지 이슈를 제대로 해결 못하면? 조직의 IT 예산 급증

 

 

IT 운영의 3대 과제 - 장애

• 시스템을 구성하는 모든 요소 중 장애로부터 자유로운 요소는 없음
• 장애로 인한 피해를 줄이는 방법은 장애 대응 역량!
• 대응 역량은 대응 가능한 환경 구축, 시스템 구조 설계, 운영 방식 등 포함

 

IT 운영의 3대 과제 - 성능

• 어느 시스템이나 구축 후 오픈 초기에는 적절한 수준의 성능 제공
• 하지만! 발전하는 조직일 수록 시스템 성능 문제에 빨리 부딪힘
  • 사용자와 데이터가 빠르게 늘어나기 때문
• 대체로 자원을 최적화하는 방식으로 문제를 해결하지만… 어느 순간부터 한계에 부딪히게 됨

 

IT 운영의 3대 과제 - 변경 지연

• 시스템이 복잡해 질 수록 비즈니스 변경에 따른 SW 변경 대응이 늦어지는 경향이 있음
• 변경 대응 지연 보다 더 큰 문제는 때로는 변경 자체가 불가능! 비즈니스 확장을 방해!
• 업무 규모가/시스템 규모가 클수록 변경 시간은 지수적으로 지연

 

복잡도

• 핵심 이슈를 해결하기 위한 활동이 활발할 수록 시스템 복잡도도 증가
• 복잡한 시스템은 다시 장애, 성능 저하, 변경 지연의 또 다른 이유
• 시스템 구조 관점에서 낮은 복잡도를 유지하도록 설계하는 것이 해답
• 모든 문제를 해결할 수는 없지만, 적어도 신속한 대응 역량 제공

• IT 서비스를 제공하는 조직의 시스템은 매우 거대
  • 모 금융사의 경우, 배포에만 두 시간 이상이 걸릴 정도로 엄청난 규모
• 어떤 컴포넌트에 한 줄만 변경해도, 전체를 다시 배포
  • 지속적으로 추가/변경하는 방식으로 시스템을 운영

 

 

 

구조적인 대응

• 기업은 급변하는 비즈니스 환경에 대응하기 위해 다양한 전략을 마련
• 조직의 변화를 통한 경쟁력 확보는 무엇보다 중요한 전략 요소
   • 기존 팀의 분할/병합, 새로운 팀의 추가, 팀 규모 확대 등 조직 역량 강화

구조적인 대응 - eBay

• 사용자와 물품 등록 건수의 증가에 따라, 아키텍처를 지속적으로 개선
  • 각 아키텍처 버전 별로 감당할 수 있는 사용자와 물품 등록 건수가 있음
• 구조 뿐만 아니라 DBMS, 심지어 프로그래밍 조차도 과감하게 변경

 

모델링 기술 흐름

 

Computing 환경 변화 및 기술 발전          OOAD →  CBD → SOA → MSA

OOAD (Object Oriented Analysis and Design; 객체 기반 분석 및 모델링)

CBD (Component Based Development; 컴포넌트 기반 개발)

SOA (Service Oriented Architecture; 서비스 지향 아키텍처)

 

 

마이크로서비스

• 현재 국내에서 개발되어 운영되는 대부분의 시스템은?
  • 무늬만 컴포넌트 기반, 일체식 배포 구조를 갖고 있음
  • 일체식 컨테이너와 통합 DB는 운영 중 성능, 배포, 실패 등 여러 문제

 

• CBD는 업무를 담을 모듈을 설계할 때 컴포넌트 단위로 설계하려는 것
• SOA와 MSA는 업무 컴포넌트를 배포하고 제공할 때 구조를 결정하는 방법
• 잘 설계된 컴포넌트를 마이크로서비스 형식으로 구성하여 배포하고 제공

 

배포 = '유지보수를 하기 위한 요구'
우리가 컴포넌트를 나눠서 만들면 개발이 분리된다. 예를들어 '깃'을 유지한다고 하면 특정 디렉토리의 파일들이 컴포넌트라 했을때 각각의 팀이 해당 디렉토리에서만 구성을 한다면 다른 팀들과 충돌이 날 일이 없다. 하지만 배포할 때는 어차피 일체형으로 배포가 될 테니까 이제 서비스(SOA)별로 배포를 하겠다. 라는 개념이 나온거고 마이크로 서비스는 그 서비스들 조차 쪼개서 배포하겠다는 의미
결국은 컴포넌트를 잘 설계하면 마이크로 서비스 형태로 자연스럽게 구성하여 배포할 수 있는것

 

 

모놀리식 아키텍처 vs 마이크로서비스 아키텍처

• RESTful 아키텍처  →  마이크로서비스 아키텍처 x

 

 

MSA 예시 - Netflix

• 2008년, 넷플릭스 → Big Java, Big Oracle

• 2008년부터 2015년까지 7년 동안 →  Cloud-Native

• 현재 MSA

Netflix는 처음 너무 큰 데이터베이스, 너무 큰 작업 프로그램으로 시작했기에 오류나 장애가 생기면 박해질 수밖에 없는 구조였다. 그래서 7년에 걸쳐 AWS를 사용한 클라우드 네이티브로 전환하였다.
∴ 처음 설계가 매우 중요

 

MSA 예시 - 아마존

부분 부분들을 하나의 서비스로 나눈 구조로 만들기 시작 
카카오톡 같은 경우도 친구 리스트가 나오고 프로필도 있고 광고도 있고 이런것들이 다 마이크로 서비스에 해당

 

 

 

마이크로서비스 주요 특성

• 각 마이크로서비스는 단일 역량을 담당
  • 비지니스와 관련될 수도 있고, 제3자와의 연계(예: 외부 시스템)와 같은 공유 기술 역량일 수도 있음
• 자신의 데이터 저장소가 있는 경우 데이터 자장소에 대한 Ownership을 갖음
  • 서비스 간 결합력 줄이고, 다른 서비스의 임의 접근 제한
• 일련의 메시지와 동작을 자율적으로 구성하고 협업하는 것을 책임
  • 마이크로서비스를 연결하는 메시징 메커니즘이나 다른 SW가 하는 것 X

 

마이크로서비스 기반 통신 흐름

육각형으로 되어있는 것들이 마이크로 서비스이다. (독자적인 데이터베이스도 가지고 있는 모습)
각각의 기능을 명확하게 분리하는게 중요!

 

 

마이크로서비스 기본 속성

• 각 마이크로서비스는 독립적으로 배포 가능
  • 그렇지 않으면 여전히 모놀리식
• 마이크로서비스는 교체 가능
  • 자연스럽게 마이크로서비스의 크기를 제한
  • 서비스의 책임 또는 역할을 이해하기 쉽게 만듦

 

마이크로서비스 핵심 원칙

 

자율성 (Autonomy)

• 각 서비스는 다른 서비스와 독립적으로 변경되고 운영
• 느슨한 결합 (= 의존성 ↓)
  • 명확하게 정의된 인터페이스를 통해 협업
  • 메시징 시스템을 통해 각 마이크로서비스는 협업하는 다른 마이크로서비스의 내부 구현과 독립적으로 유지
• 독립적으로 배포 가능
  • 서비스는 여러 팀에 의해 종종 동시에 배포됨
  • 엄격한 규칙에 따라 강제로 배포하거나 배포를 조율하면 위험하고 불안정함
  • 이상적인 배포는 소규모 서비스로 만들어 신속하게 자주 작게 출시하는 것

    느슨하게 결합된 서비스 (Loosely-coupled Services)

   

 

회복성 (Resilience)

• 마이크로서비스는 장애를 격리하는 자연스러운 매커니즘
• 마이크로서비스를 독립적으로 배포하면?
• 애플리케이션 또는 인프라의 장애는 시스템의 일부에만 영향을 미침
• 새로운 기능을 위험한 빅뱅 (big bang) 방식으로 출시하는 것 보다 작은 기능으로 배포하는 것이 시스템을 점진적으로 변화시키는 데 도움

투명성 (Transparency)

• 가장 중요한 것은 언제 장애가 발생했는지 아는 것
• 마이크로서비스 애플리케이션은 시스템 하나가 아니라 다른 팀이 개발했을 수도 있는 여러 서비스에 의존하고 상호작용
• 시스템이 어느 지점에서나 투명하고 관찰 가능해야 문제를 관찰하고 진단할 수 있음

자동화 (Automation)

• 마이크로서비스는 단일 애플리케이션을 개발하는 것보다 훨씬 복잡한 아키텍처를 가짐
• 자동화를 도입하고 서비스 간 일관된 인프라를 만들면 부가적인 복잡성을 관리하기 위한 비용을 획기적으로 줄일 수 있음
• 즉, 정확한 배포와 운영을 보장하려면 자동화를 적용해야 함
• DevOps, Infrastructure as Code (IaC)

동기화 (Alignment)

• 개발팀의 노력을 올바른 방향으로 동기화 하는 것이 매우 중요
• 서비스가 비즈니스 컨셉과 일치하도록 노력하면 궁극적으로 팀도 같은 생각으로 동기화(?)

 

 

SOA vs. MSA

그래서 우리가 이제 '마이크로 서비스를 만든다'를 특별하게 생각할 것이냐?
아니다 기존에 만들었던 구조를 그대로 '분리' 했을 뿐  →  레이어로 생각을 했느냐 vs 서비스 레벨로 생각을 했느냐

 

 

마이크로서비스를 선택해야 하는가?

• 기술의 혼재성으로 인하여 (Heterogeneity) → 마이크로서비스를 선택
• 시스템의 복잡성이 커지면서 개발의 마찰도 증가
  • 소프트웨어 개발의 목적은 긍정적인 비즈니스 영향력을 전달하는 데 소요되는 시간을 최소화하는 것
•  마이크로서비스는 마찰과 위험을 줄여줌
  • 개발할 때 의존성을 격리시키고 최소화함
  • 개발자가 전체 시스템보다는 응집된 개별 구성요소에 대해 추론할 수 있음
  • 작은 독립적인 변경을 지속적으로 전달할 수 있음

 

 

 

마이크로서비스 적용 시 문제점

• 마이크로서비스의 범위를 정하고 식별하는데 대상 도메인에 대한 상당한 지식 필요
  
  
• 서비스 간의 올바른 경계와 계약을 식별하는 것이 어렵고, 한번 정한 후 변경하는 데 많은 시간 소요
   
• 마이크로서비스는 분산 시스템으로 시스템의 상태, 일관성, 네트워크 신뢰성에 대해 다른 가정을 전제해야 함
  
  
•  시스템 구성요소를 여러 네트워크에 분산하고 혼재된 기술의 수가 늘어나면 마이크로서비스에는 새로운 형태의 장애 발생
   
• 정상 상태에서는 무엇이 발생해야 하는지 이해하고 검증하는 것이 더욱 더 어려움

설계 상의 어려움

• 서비스가 자율적이 되려면 전체적으로는 느슨하게 연결되고 개별적으로는 기능 요소들이 높은 응집도를 가지도록 설계해야 함
• 이는 점진적으로 진화하는 과정
• 서비스 범위는 시간이 지남에 따라 변화 할 수 있음
• 기본 서비스에서 새로운 기능을 떼어내거나 제거할지를 선택해야 함
•  즉, 서비스 간의 경계는 느슨한 결합에서 가장 중요
  • 잘못되면 서비스는 변화에 저항하게 되고, 전체적으로 애플리케이션의 순응성과 유연성이 떨어짐

마이크로서비스 범위 정의의 어려움

• 각 마이크로서비스는 단일 역량을 담당
  • 이런 역량을 도출하는 것은 애플리케이션에 대한 비즈니스 도메인 지식을 요구
  • 대상 도메인에 대한 부적절한 이해는 나쁜 디자인을 선택하게 만듦
  • 마이크로서비스 애플리케이션에서는 모놀리식 애플리케이션 내의 모듈에 비해 서비스 경계가 더욱 견고
  • 즉, 범위가 잘못되면 후속 공정 비용이 증가할 가능성 높아짐

기존에 모놀리식으로 만들던 서비스는 어떻게 보면 디스크 용량이 부족하다던가 메모리가 부족하다던가 명확하게 알 수 가 있었지만 마이크로 서비스는 다 분리가 되기 때문에 장애에 대한 연관관계를 찾아내기가 쉽지 않다.
즉, 'MSA로 만든다' 라는 얘기는 다양한 변수들을 갖고 가겠다는 소리도 된다.

 

 

마이크로서비스 범위

부정확한 서비스 범위 결정으로 인하여 서비스 경계가 복잡 → Refactoring 비용 상승

 

 

 

 

서비스 간 계약 유지

• 각 마이크로서비스는 다른 서비스와 독립적으로 구현
  
  
• 각 마이크로서비스는 계약 (Contract)를 노출
  • 서비스가 수신하고 응답하기를 기대하는 메시지를 정의
  • 계약 → 객체지향 디자인에서의 인터페이스와 같은 것
  
  
• 좋은 계약
  • 완전성: 상호작용의 완전한 범위를 정의
  • 충분성: 필요 이상의 정보를 제거해 메시지 소비자가 적절한 범위에서 메시지를 구성할 수 있게 함
  • 예측성: 모든 구현의 실제 행동을 정확하게 반영

 

마이크로서비스 = 분산 시스템

• 마이크로서비스 애플리케이션을 설계하는 것 = 분산 시스템을 설계하는 것
  
  
• 분산 시스템 설계 시 자주 하는 오해
  • 네트워크를 신뢰할 수 있다
  • 대기 시간이 없다
  • 대역폭이 무한하다
  • 전송 비용이 없다
  
  
• 하지만, 기존 비 분산 시스템에서의 가정은 부적절
• 즉, 애플리케이션 간 상태에 대한 대기시간, 신뢰성, 일관성을 고려해야 함
  
  

 

운영 상의 도전 과제

 

애플리케이션이 운영 중이라면 생각해 볼 문제들

• 문제가 발생해서 사용자의 주문이 제출되지 않으면 어디에서 오류가 발생했는지 어떻게 결정할 것인가?
  
  
• 주문에 영향을 주지 않고 새로운 서비스를 어떻게 배포할 것인가?
  
  
• 어떤 서비스가 호출돼야 했는지를 어떻게 알 것인가?
  
  
• 어떤 동작이 여러 서비스에 걸쳐 올바르게 작동하는지 어떻게 테스트할 것인가?
  
  
• 서비스를 사용할 수 없으면 무슨 일이 발생하는가?

마이크로 서비스로 가면서 테스트가 어려워진다. 전체 서비스가 다 각각의 서비스로 완전히 무결하다라고 가정하고 테스트하면 상관이없지만..
내가 만약 API콜을 했다면 그거에 영향받는 서비스들이 여러개 있을 것이다. 근데 어디서 장애가 발생할지 모르는데 내가 어떻게 테스트할 것인가? 어느 API콜을? 어떤 데이터를? 어떻게 테스트할 것인가? 생각해야 할 것이다. 내가 쓸 수 있는 인풋은 API밖에 없기 때문!
즉, API로 내 프로그램들 내 서비스들에 대한 테스트 커버리지가 얼마가 되는지가 중요!!

 

운영 상의 도전 과제 - 장애 가능성

 

 

 

 

 

정리 - 1 서비스의 자율적 구성이 중요

REST API를 쓰면되는데 메세지 큐 (MQ)를 왜 MSA에 쓰려고 하느냐? 
● 비동기 작업 처리: 긴 시간이 걸리는 작업(ex 메일,알림 발송등)을 비동기적으로 처리할 수 있다.
● 서비스 간 통신의 느슨한 결합: 서비스 간의 의존성↓ 하나의 서비스가 중단되더라도 다른 서비스에 영향 x

 

정리 - 2 서비스의 외부 노출

사용자가 쓸 서비스들만 노출하면 된다. 사용자에게 노출되는 서비스는 REST API를 통해 노출된다. 즉, 외부와의 통신은 독립적으로 이루어져야 하며 영향을 최소화 해야함

내부 서비스 간의 통신은 내가 REST API를 쓰든 gRPC든 Socket이든 자유롭게 써도 되는것

 

 

정리 - 3 분산 시스템 개념

중간에 장애가 발생했을 때 어떻게 리커버리(복구)할 것인지, 중간에 있는 디펜던시(의존성)를 어떻게 줄일 것인지 등 다양한 이슈를 고려해야 한다.

● 서비스 독립성: 각 서비스를 독립된 컨테이너나 VM으로 배포하여 독립성을 유지, 장애 시 영향을 최소화
● 장애 대비: 시스템 설계 시 장애에 대비하여 빠르게 복구할 수 있는 메커니즘을 포함해야함
● 로드 밸런싱: 로드 밸런서를 사용하여 사용자 요청을 여러 인스턴스에 고르게 분배
● 이벤트 큐: 비동기 작업 처리를 위해 이벤트 큐를 사용하여 서비스 간의 유연성을 높임