42일차 마이크로서비스

마이크로서비스 구조와 특징

마이크로서비스는 소프트웨어가 잘 정의된 API를 통해 통신하는 소규모의 독립적인 서비스로 구성되어 있는 경우의 소프트웨어 개발을 위한 아키텍처 및 조직적 접근 방식이며 이러한 서비스는 독립적인 소규모 팀에서 보유한다.

 

모놀리식 아키텍쳐

모놀리식 아키텍처의 경우 모든 프로세스가 긴밀하게 결합되고 단일 서비스로 실행되기때문에 애플리케이션의 한 프로세스에 대한 수요가 급증하면 해당 아키텍처 전체를 확장해야한다. 코드 베이스가 증가하게 되면 모놀리식 애플리케이션의 기능을 추가하거나 개선하기가 복잡해지며 이러한 복잡성으로 인해 실험에 제한을 받고 새로운 아이디어를 구현하기가 어려워진다. 종속 관계를 이루며 긴밀하게 결합된 많은 프로세스로 인해 단일 프로세스의 실패로 인한 영향이 증가함 에 따라 모놀리식 아키텍처는 애플리케이션 가용성에 대한 위험을 가중시킨다.

 

 

 

마이크로서비스 아키텍쳐

애플리케이션이 독립적인 구성 요소로 구축되어 각 애플리케이션 프로세스가 서비스로 실행되며 이러한 서비스는 경량 API를 사용하여 잘 정의된 인터페이스를 통해 통신합니다. 서비스는 비즈니스 기능을 위해 구축되며 서비스마다 한 가지 기능을 수행합니다. 서비스가 독립적으로 실행되기 때문에 애플리케이션의 특정 기능에 대한 수요를 충족하도록 각각의 서비스를 업데이트, 배포 및 확장할 수 있습니다.

 

 

 

마이크로서비스의 특징과 이점

 

자율성

마이크로서비스 아키텍처의 각 구성 요소 서비스는 다른 서비스의 기능에 영향을 주지 않으면서 개발, 배포, 운영하고 확장할 수 있으며 서비스가 해당 코드 또는 구현을 다른 서비스와 공유할 필요는 없다. 개별 구성 요소 간의 통신은 잘 정의된 API를 통해 이루어진다.

 

전문성

각 서비스는 일련의 기능을 위해 설계되며 특정 문제를 해결하는 데 중점을 두며 개발자가 시간이 지남에 따라 서비스에 더 많은 코드를 제공하여 서비스가 복잡해지면 더 작은 서비스로 분할할 수 있다.

 

민첩성

마이크로서비스는 해당 서비스를 소유한 독립적인 소규모 팀 조직을 육성하는 역할을 하며 팀은 충분한 이해를 바탕으로 하는 소규모 컨텍스트 내에서 활동하며 더 독립적이면서 신속하게 업무를 수행할 수 있다. 덕분에 개발 주기 시간이 단축되며 조직의 집계 처리량 측면에서 큰 이점을 누리게 된다.

 

유연한 확장성

마이크로서비스의 경우 각 서비스가 지원하는 애플리케이션 기능의 수요를 충족하도록 해당 서비스를 독립적으로 확장할 수 있으므로 팀은 필요한 인프라의 규모를 적절히 조절하고, 기능의 비용을 정확하게 측정하고, 서비스의 수요가 급증하는 경우에도 가용성을 유지할 수 있다.

 

손쉬운 배포

마이크로서비스는 지속적 통합 및 지속적 전달을 통해 새로운 아이디어를 손쉽게 시험하고 문제가 발생할 경우 간단히 롤백을 할 수 있다.  이처럼 저렴한 실패 비용 덕분에 실험을 진행할 수 있어 더 쉽게 코드를 업데이트하고 새로운 기능의 출시 시간을 앞당길 수 있다.

 

기술적 자유

마이크로서비스 아키텍처는 “모든 규모에 부합하는” 접근 방식을 추구하지 않는다. 팀은 특정한 문제를 해결하는 데 가장 적합한 도구를 자유롭게 선택할 수 있으므로 마이크로서비스를 구축하는 팀은 작업별로 가장 적합한 도구를 선택할 수 있다.

 

재사용 가능한 코드

소프트웨어를 잘 정의된 소규모 모듈로 분할하면 팀이 기능을 여러 용도로 사용할 수 있게 된다. 특정 기능을 위해 구축된 서비스를 다른 기능의 빌딩 블록으로 사용할 수 있다. 이를 통해 개발자가 코드를 처음부터 작성하지 않고도 새 기능을 생성할 수 있어 애플리케이션이 자체적으로 부트스트랩 작업을 생성할 수 있다.

 

복원성

서비스가 독립적이므로 실패에 대한 애플리케이션의 저항성이 증가한다. 모놀리식 아키텍처에서는 단일 구성 요소가 실패하는 경우 전체 애플리케이션이 실패하게 될 수 있다. 마이크로서비스에서는 기능을 저하시키고 전체 애플리케이션을 충돌시키지 않는 방식으로 전체 서비스 실패를 처리한다.

 

https://aws.amazon.com/ko/microservices/ 

 

마이크로서비스 아키텍처의 정의

• 유지보수에 유리하고, 테스트 가능해야 함
• 느슨하게 결합되어야 함
• 독립적으로 배포 가능함
• 비즈니스 역량을 중심으로 구성해야 함
• 작은 팀에 의해 소유됨

 

이러한 특징을 가진 서비스들의 조합으로 이루어진 설계이다.

 

 

서비스로서의 컴포넌트화

 

컴포넌트는 독립적으로 대체하거나 업그레이드 가능한 소프트웨어 단위이며 컴포넌트화 시스템을 구성 요소를 나누고 이를 연결하여 구축하는 것이다. 컴포넌트화 하는 방법은 소프트웨어를 여러 서비스로 분리하면된다.

 

라이브러리 vs. 서비스

	라이브러리로서의 컴포넌트화	서비스로서의 컴포넌트화
특징	라이브러리는 프로그램 내에 링크되어, 메모리상에서 함수를 호출한다.	개별적인 프로세스로 각 프로세스가 HTTP 또는 RPC로 서로 통신한다.
배포 편의성	전체 응용 프로그램을 재배포 해야 함.	서비스 단위로 재배포 가능하다.
컴포넌트간의 결합 (약할수록 이득)	강함	약함
호출 비용 (적을수록 이득)	적음	많음

 

기술적 계층에 따라 팀을 분류하면 프론트엔드팀, 백엔드팀, 데이터팀 이런 식으로 분류하였고 단순한 변경이 필요한 경우에도 팀 간의 협업비용이 높았다.

 

하지만 비지니스 수행 능력(업무 도매인)에 따른 팀 분류를 하면 쇼핑몰의 경우 회원/상품/배송 식으로 분류하였고  각각의  서비스가 도메인이 된다. 하나의 온전한 시스템의 단위로 팀을 나누며 팀이 하는 일은 하나의 서비스로 나뉘어지며 이것을 마이크로서비스라고 부른다.

• 이로 인한 장점으로는,
  • 소프트웨어 스택, 데이터베이스 선택, 프로젝트 관리 등이 팀 별로 독립적이다.
• 이를 달성하기 위해서,
  • 각 팀은 서비스에 대한 책임을 가져야 한다
  • 각 서비스는 메시지 버스(통신 인터페이스)를 통해 통신해야 한다

 

조직과 아키텍처의 연관성

시스템을 설계하는 조직은, 자신의 조직이 가진 커뮤니케이션 구조를 복제하는 아키텍쳐 디자인을 만들어 낸다.

Mevlyn Conway, 1967

따라서 마이크로서비스로 소프트웨어를 작성할 때에는, 소프트웨어 작성에 앞서 팀의 일하는 방식을 보다 독립적으로 만들어내야한다. 혹은 마이크로서비스 아키텍처를 통해, 팀의 일하는 방식이 보다 독립적으로 만들어질 수 있다. (Dev와 Ops가 함께 만들어가야한다)

 

현명한 엔드포인트와 바보 파이프라인

특징

다른 말로 표현하면 "서비스(엔드포인트)는 일을 하게 하고, 통신(파이프라인)은 최대한 단순하게 한다"

• 마이크로서비스에서의 프로세스간 통신은, "현명한 엔드포인트와 바보 파이프라인" 접근 방식을 따름
  • 리눅스 파이프라인의 철학과 흡사
• 서비스와 서비스 사이는 느슨(decoupled)하게, 응집성은 높게

대표적인 방법

1. REST API (HTTP)
2. 메시지 버스를 이용한 메시지 전달 (메시지 큐)

 

분산화 거버넌스, 분산화된 데이터 관리

문제점

 

중앙 집중적인 시스템은 기술을 표준화하는 경향이 있다.

 

예를 들어 우리 회사는 Java 9와 Oracle만 사용하는데 간단한 리포트 만드는 서비스가 필요한데, node.js로 금방하는 걸 Java를 꼭 써야할까? 라는 문제가 생길 수 있고 해결에 오히려 방해가 될 수 있다.

해결책

• 분산화된 시스템
  • 소프트웨어 스택, 데이터베이스 선택, 프로젝트 관리 등이 팀 별로 독립적이다.
    • 데이터에 대한 분산 책임이 따른다.
    • 서비스 데이터베이스 간의 일관성과 트랜잭션 협조가 중요하다.
• 분산화된 응용 프로그램 설계 → 도메인 주도 설계(DDD, Domain-Driven Design)
  • 도메인 경계를 분명하게 해아한다.

 

진화하는 설계

• 컴포넌트 핵심은 컴포넌트가 개별적으로 대체 가능해야 하고, 업그레이드를 할 수 있어야 한다.
• 장점
  • 모놀리스는 작은 변경사항도 응용프로그램 전체의 재배포를 필요로 하지만 마이크로서비스는 변경한 서비스만 배포하면 된다.
  • 프로세스의 간단하고 신속한 출시가 가능하다.
• 단점
  • 기존 서비스에 대한 변경이 이 서비스를 이용하고있는 다른 서비스에 영향을 주는지 여부를 신경써야 한다.

 

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

구분	Level 0 : 전통적인 방식	Level 1 : 기본	Level 2 : 중급	Level 3: 고급
애플리케이션 아키텍쳐	모놀리식	서비스 지향 통합 (Service Oriented Integrations)	서비스 지향 애플리케이션 (Service Oriented Application)	API 중심
데이터베이스	어떤 경우에도 들어맞는 크기의 엔터프라이즈 DB	엔터프라이즈 DB +NoSQL, 경량 DB	폴리그랏(다중 언어 지원) 서비스로서의 DB	Data Lake, 준실 시간 분석
인프라스트럭처	물리적 서버(베어 메탈)	가상화	클라우드	컨테이너
모니터링	인프라스트럭처	애플리케이션과 인프라스트럭처	애플리케이션 퍼포먼스(APM)	APM 및 중앙화된 로그 관리 시스템
개발 프로세스	워터폴	애자일 및 CI	CI & CD	DevOps

 

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

 

서버리스(ServerLess)

웹애플리케이션을 적은 예산, 빠르게, 확장 가능, 관리와 운영은 쉽게, 혼자 구현 및 관리는 불가능하기에 해답으로 나온 것이 서버리스다.

서버리스는 서버가 없는 것이 아닌 서버에 대한 고민이 없는 것 즉, 서버를 따로 관리할 필요가 없어 애플리케이션 구축에만 집중 할 수 있다.

 

서버리스의 등장 배경과정

서버리스가 생기게 된 배경은 등장 이전의 애플리케이션 배포과정을 살펴보면 이해할 수 있다. 오래전에는 애플리케이션을 배포하려면 직접 하드웨어 서버를 구매해서 구성했다. 이때는 하드웨어와 소프트웨어 둘다 관리를 해야해서 하드웨어의 직접적 관리는 이점도 있었지만 서버 관리에 많은 비용을 지불해야 했고 메모리 관리와 같은 불편한 점도 있었다.

이런 서버의 하드웨어 관리의 어려움을 해결해준 것이 AWS 클라우드 컴퓨팅 서비스 EC2 였다. 이로서 하드웨어 관리의 불안감을 덜 수 있게 되었다. 하지만 빌려서 구성한 서버의 소프트웨어도 보안, 업데이트, 백업와 같은 많은 관리 과정이 필요하기에 이런 서버의 소프트웨어 관리의 어려움을 해결하는 방안으로 서버리스가 등장한 것이다.

개발자들이 느끼는 민첩한 애플리케이션 배포 시간의 변화

 

데이터센터에서의 물리 서버에서 가상 서버로 옮길 시에 장점은 활용률 증가, 프로비저닝 속도 증가, 높아진 가동 시간, 재해 복구, 하드웨어 독립성등이 있다.

 

데이터센터에서의 가상 서버에서 클라우드의 가상 서버로 옮기면 장점은 자본 비용에서 운용 비용으로 바뀌며 높은 확장성, 탄력적인 리소스, 빠른 속도와 민첩성, 유지보수 비용 감소, 고가용성과 내결함성등이 있다.

 

단점은 가상 서버 관리, 용량 및 활용률 관리, 워크로드 사이징, 고가용성과 내결함성 관리, 간헐적 작업 시 비싸다 등이 있다.

 

서버리스의 장점

따로 서버 관리가 필요없고 확장성이 유연하며 고가용성, 유휴 용량이 없다.

 

 

• 서버리스의 의미는 무엇인가요?

서버를 직접 관리할 필요가 없다

• 마이크로서비스와 서버리스는 어떤 관계가 있나요? 
  • 서버리스는 마이크로서비스의 어떠한 특징들을 반영하고 있나요?

마이크로서비스는 수많은 서버가 필요하며 그 서버를 하나하나 관리하기에는 부담이 된다. 그에 대한 해결책은 서버리스이며 직접 관리하지않아도 되므로 문제를 해결하여 개발에 집중할 수 있다.

• AWS가 제공하는 서버리스 서비스들엔 어떤 것들이 있나요?

lamba, fargate, s3, api gateway, dynamo DB, RDS proxy, Aurora severless

https://aws.amazon.com/ko/serverless/

• 마이크로서비스는 꼭 서버리스로 구현되어야 하나요?

마이크로 서비스는 모놀리식 아키텍쳐를 서비스마다 나누어서 프로젝트 크기도 작기 때문에 꼭은 아니지만 수많은 서비스의 서버를 관리하기엔 부담이 되기 때문에 굳이 서버리스를 사용하지않을 이유가 없다. 

• 서버리스의 특징 중 하나인 무상태성(Stateless)는 무엇을 의미하나요?

서버리스의 대표적인 구현 방식은 faas이며 함수를 서비스로 제공한다. Faas의 특징 중 하나는 stateless이며 함수가 실행되는 동안에만 자원을 할당하며, 같은 머신에서 실행된다는 보장이 없으므로 함수 실행 시 로컬에서 상태가 유지될 수 없다.

• 서버리스 컴퓨팅의 장단점은 무엇인가요?

장점

• 실제 사용량(함수 호출 횟수)에 대해서만 비용을 청구하므로 경제적이다
• 서버에 신경 쓸 필요가 없으므로 생산성이 향상되어 개발 기간이 단축된다.
• 자동 스케일 업, 다운이 된다.
• 간단한 패키징 및 배포

단점

• Coldstar :  Coldstar는 Lambda가 서버가 항시 요청에 대기하고있지않아 느리다. 프로젝트 규모가 작다면 신경 쓸 정도는 아니지만 규모가 크다면 서버리스는 좋은 선택이 아닐 수가 있다.
• 실행 시간 한계 : 서버리스는 단순 작업(댓글 쓰기, 이메일 보내기 등)에는 적합하지만 긴 시간이 필요한 작업(동영상 업로드, 데이터 백업 등)에는 굉장히 비효율적이다. 서버리스는 함수가 1회 호출 될 때 사용할 수 있는 메모리 및 시간에 제한이 있기 때문이다. 만약 작업이 끝나지 않은채로 해당 시간이 지나면 작업이 완료될때까지 일정 시간마다 계속 함수를 다시 호출하게 된다.
• 클라우드 제공 플랫폼에 종속적
• 디버깅 및 테스트가 불편하다

서버리스 기능은 하나 또는 여러 개의 컨테이너에서 제공된다. 요청이 들어오면 함수는 호출을 처리하기 위해 이미 실행 중인 컨테이너가 있는지 확인하고. 쉬고 있는 컨테이너가 있는 경우 이를 warm 컨테이너라고 한다. 즉시 사용할 수 있는 컨테이너가 없는 경우 함수는 새 컨테이너를 띄우며 이를 cold start 라고 한다.

 

 

출처: https://dev-coco.tistory.com/171 [슬기로운 개발생활😃:티스토리]

https://hoyoung1.github.io/posts/aws/2020-10-04-aws-lambda-cold-start