마이크로서비스 정리

1. 아키텍쳐 구성의 변화

• 보통 회사에 가면 있는 팀 (기능 조직)
  • 프론트엔드 팀
  • 백엔드 팀
  • 데이터 팀
    • 프론트(클라이언트) <-> 백엔드(서버)  HTTP로 통신 (ALB)
    • 백엔드(클라이언트) <-> 데이터팀(서버)  TCP로 통신 (NLB)
• 각 티어는 API로 서로 통신함
  • 기본적으로 클라이언트-서버 아키텍처
• 3-Tier 아키텍처
  • Presentation Tier (프론트엔드) [alb endpoint, api.hello.click]
  • Logic Tier (백엔드)
  • Data Tier (데이터) [nlb endpoint]
• Full Stack 애플리케이션 구성도

그림 1-2

 

출처 : https://blog.lgcns.com/1278

• 모놀리틱 VS 마이크로서비스
  • 모놀리틱
    • 모든 기능들을 하나의 애플리케이션(프로세서)안에 넣고 multiple servers로 스케일링(ALB)을 한다.
    • 모놀리식은 기존에 많이 쓰이는 전형적인 '애플리케이션 구조'이다.
    • 모노리식에서 모든 비즈니스 로직들이 결합을 도와 의존성을 강하게 가진다.
    • 그렇기 때문에 각 로직들간의 호출이 빠르고, 시스템 메모리 및 리소스 사용이 좀 더 효율적으로 이루어진다는 장점을 가지게 된다.
    • 하지만 하나로 결홥된 여러 로직 중 하나의 로직만을 업데이트하고자 할 때, 기존의 서비스에 로직을 추가하는 방식으로 이루어지므로 다른 로직이 영향을 받게되고, 고려해야할 사항들이 많아지게 된다.
  • 마이크로서비스
    • 하나의 기능을 하는 서비스를 각각 별도의 프로세스로 분리시켜놓는다. 스케일링을 할 때 각각의 서비스를 복제해서 넣는다.
    • 하나의 함수에 여러가지 기능을 넣는게 아닌 하나의 기능을 하는 함수로 잘게 쪼개서 조합을 시킨다 라고 보면 된다.
    • 각 로직을 독립적인 작은 서비스 단위로 배포 및 업데이트를 진행하도록 구성되어 있으며, 이들은 느슨한 결합(Loosely coupied)로 연결되어있다.
    • 장점
      • 개별 서비스를 소규모의 모듈로 구성이 가능하다.
      • 개별 서비스들도 다양하게 구현이 되기 때문에 장애에 강해진다.
      • 각각의 서비스가 다른 언어, 프레임워크 등을 선택하여 배포하는 것이 가능하기 때문에 기술에 대해 빠른 적용이 가능하다.
    • 단점
      • 여러 서비스로 나누고 각각 배포를 진행해야기 때문에 배포가 복잡하여 자동화가 필수적이다
      • 각각의 서비스를 배포하기 위한 환경을 다 따로 구축해주어야 하기 때문에 시스템의 메모리 소요가 상대적으로 높아진다.
• 아키텍처 구성의 변화에 따른 조직의 변화
  • 비즈니스 수행 능력(업부 도메인)에 따른 팀 분류 (목적조직) [아키텍쳐에 따라서 조직이 분류된다]
    • 카카오메이커스 팀
    • 카카오쇼핑 팀
    • 카카오헤어샵 팀
  • 각 팀에는 프론트/백/데이터가 한꺼번에 존재함
    • 각 팀 인프라를 조율하고 서비스를 연결해주는 조직도 별도로 존재하게 됨 --> DevOps가 하는 일.
  • 마이크로서비스 아키텍처(MSA)로의 진화

그림 2-2. 별도로 각각의 기능들과 조직이 있다

그림 1-2에서 카카오 메이커스,쇼핑,이모티콘이 합쳐 있다면, 

그림 2-2에서는 카카오메이커스 하나, 쇼핑 하나, 이모티콘 하나처럼 따로따로 분리되어있다.

 -> 별도의 팀이 각각의 스택을 가지게 된다

 

• 서버리스(Serverless)
  • EC2와 같이, 빌려서 구성한 서버의 소프트웨어도 보안, 업데이트, 백업과 같은 많은 관리 과정이 필요하고, 이러한 어려움을 해결하기 위해 서버리스가 등장하게 되었다.
  • 서버리스는 서버가 없다는 것이 아니라, 별도의 서버를 구축할 필요 없이 애플리케이션의 개발과 배포를 지원하는 클라우드 컴퓨팅 서비스를 의미한다.
  • 서버리스 컴퓨팅은 Function단위로 제공하는 FaaS(Function as a Service)로 정의 하여 code단위로 클라우드에 올리면 그 뒤에 따라오는 런타임 환경은 사용자가 신경 쓸 필요가 없다.
  • 애플리케이션을 빌드하거나 실행할 수 있는 클라우드 네이티브 개발 모델
  • 애플리케이션의 스케일링을 클라우드 제공 업체가 관리
    • 가용성을 제공하기 위해 수평확장된 서버가 요청을 대신 수행하는 것이 가능
• 서버리스와 마이크로서비스 연관성
  • 서버리스 컴퓨팅은 마이크로 서비스 구조의 개발을 구성하기 위해 매우 적합한 형태
  • Fuction 단위로 구성하고 각각 독립적인 API 형태로 구성하여 배포하면 마이크로 서비스 형태의 애플리케이션이 될 수 있기 때문(모든 마이크로서비스가 function은 아님)
• 서버리스의 특징 중 하나인 무상태성은 무엇을 의미하는가?
  • 서버리스의 아키텍쳐는 크게 두가지로 나누어 진다.
    • Faas(Function as a Service)
    • BaaS(Backend as a Service)
  • 일반적으로 서버리스는 FaaS를 가리킨다.
• FaaS
  • 프로그램을 함수 단위로 클라우드에 배포하고, 이벤트가 발생하면 함수가 실행되는 방법이다.
  • 사용자는 함수가 실행된 횟수 및 시간에 따른 비용만을 지불한다.
  • 이때 요청이 들어오면 이벤트를 발생시킨다. -> 특정주기로 발생시키거나 직접 호출하는 것도 가능
• FaaS 정리
  1. 함수를 실행시켜주는 서비스
  2. 함수는 클라우드 사업자가 제공하는 컨테이너에 담김
  3. 함수 실행이 끝나면, 컨데이너는 사라짐(꾸준히 반복적으로 호출되는 것이 아니라면)
  4. 서버리스이므로, 자신의 코드에만 책임을 지면됨
  5. 대표적으로 AWS Lambda 
  6. 특징
     • stateless : FaaS는 함수가 실행되는 동안에만 자원을 할당한다. 또한 함수가 항상 같은 곳에서 실행된다는 보장또한 없으므로, 함수 실행 시 로컬에서 어떠한 상태가 유지될 수 없음
     • ephemeral : 특정이벤트가 발생했을 때만 컨테이너로 배포가 되고, 끝나면 자원이 회수되므로 일시적으로만 배포된다고 할 수 있다.
• BaaS(Backend as Service)
  • 서버 기술을 몰라도 서버에 걸맞은 기술을 제공해주는 서비스
  • API를 이용해 사용할 수 있음
  • 주요기능
    • FaaS도 여기에 포함
    • 데이터베이스 제공(DBaaS) -> mongodb atlas, AWS dynamoDB,ElephantSQL
    • 파일 스토리지 -> S3
    • 컨테이너 실행환경 -> ECS
    • 메시지(이벤트)관리도구 -> AWS SNS, SQS

 

 

 

 

 

 

출처

- https://blog.lgcns.com/1278

블록을 조립하듯 앱을 조립하는 '마이크로서비스' ①

- https://blog.naver.com/dktmrorl/221863498991

[IT정보] 모놀리식 아키텍쳐(Monolithic Architecture, MA) 개념

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

마이크로서비스란 무엇입니까? | AWS