[WebDevCurriculum] 서버 아키텍쳐 패턴

개요

MSA 개념과 MSA 설계를 위해 필요한 여러 기능, 도구들에 대해 이해한다.

Checklist

• 마이크로서비스 아키텍쳐란 무엇일까요?

프로그램은 각각 독립적이고 느슨한 관계의 MicroService들이 모여 하나의 체계를 이룬 개념으로 보는 설계 방법론이다.

※ 마이크로서비스 아키텍쳐 이전의 형태는 Monolithic Architecture 이다.

즉 application 하나가 부모입장에서 종속된 모든 service를 제공하는 방식이 아닌, 독립적인 microservices들이 모여 하나의 체계를 이룬 개념으로 보는 것이다.

이때 microservices들은 독립적으로 배포할 수 있으며, 하나의 프로그램에 통합하는 build 과정을 거치지 않고도 기존 service들을 update할 수 있다.

• 마이크로서비스 아키텍쳐는 어떤 장점을 가지고 있을까요?

모든 기능들이 한 부모요소에 종속될 경우 구조 자체는 단순하고, 전통적인 방법이기 때문에 개발환경이 익숙할 수 있다.

그러나 규모가 큰 환경을 유지보수를 한다면, 시간과 비용을 훨씬 더 많이 소모하거나 관리 자체가 불가능해질 수 있다.

마이크로서비스는 이러한 단점을 보완하기 위해 고안된 방법론이며, 대표적인 장점은 아래 3가지와 같다.

→ 변경점을 적용해야 할 부분만 반영하면 되기 때문에 유지보수가 더 수월하다.
→ 체계적으로 시스템 및 파일관리가 가능하다.
→ 유지관리가 더 잘되기 때문에, 서비스의 신뢰도가 더 좋다.

microservice로 이루어진 application 환경에서는 각각의 독립적인 배포가 가능하기 때문에, 서비스 관리가 용이해지고 그만큼 업데이트가 용이할 수 있다.

• 어떤 식으로 서비스를 구성할 수 있을까요?

하나의 application을 독립적인 service들로 구성한다.

각각의 microservices는 마치 레고와 같이 재사용이 가능하고, 특히 현대 IT분야에서 각광받는 클라우드나 Container와 부합하는 점이 많아 좋은 평가를 받고 있다.

• 많은 마이크로서비스들을 복잡하게 연결할 경우 관리상에 어떤 난점이 생길 수 있을까요?

관리할 services들이 늘어난다면 그만큼 관리해야할 절대량이 늘어나고 비용도 같이 소모될 수 밖에 없다.

이 상황에서 microservices들이 복잡한 연결관계를 가지고 있다면, 이는 곧 서로 종속관계를 가져 하나의 services 만 고려할 수 없고 다른 부분까지 생각해야 하는 문제가 생긴다.

• 서버리스 아키텍쳐란 무엇일까요?

서버(인프라)를 따로 구축하거나 관리할 필요없이 application과 service 운영에만 집중할 수 있는 설계 형태를 일컫는다.

개발자는 서버운영 및 관리를 별도로 하지 않고, 오직 기능개발 및 수행여부 등 개발과정에 집중할 수 있게 된다.

단, BaaS(백엔드플랫폼 제공 서비스)나 FaaS(기능 제공 서비스)에 의존하고 여기에 비용지불까지 해야하므로 service 플랫폼을 잘 선택해서 사용해야 한다.

• 어떤 식으로 서비스를 구성할 수 있을까요? 어떤 장점을 가지고 있을까요?

BaaS

Backend as a Service.

DB 및 Social service 등 백엔드 관련(데이터 저장 및 추출 등) 기능(API)을 제공하여, 별도의 server 개발을 하지 않고도 백엔드 구축을 할 수 있다.

이러한 서비스들은 정적인 용량에 대한 비용 지불이 아닌, 유동적인 사용량에 근거하여 비용을 지불한다.

가장 대표적인 플랫폼으로 Firebase가 있다.

BaaS의 장점과 단점

Firebase와 같은 백엔드 시스템이(데이터를 저장하고 이를 활용할 수 있는 공간) 이미 구축되어 있는 상태라면, 별도의 서버구축비용이 들지 않고 사용비용만 지불하면 된다.

또한 서버구축에 대한 개발비용도 들지 않으므로 효율적일 수 있고, 일정 용량까지는 무료이므로 학습용/연습용으로 유용하게 사용할 수 있다.

그러나 이러한 백엔드 작업을 Client side에서 진행하는 형태이어서, 사용자가 직접 백엔드(데이터) 처리를 해야하는 경우가 생겨 불편해질 수 있다.

특히 백엔드단에서의 변화가 이루어진다면, 이를 사용하는 모든 로직을 수정해야 하는 번거로움이 생긴다.

FaaS

Function as a Service.

프로젝트를 여러 개의 함수로 쪼개서 분산된 컴퓨팅 환경(가상환경)에 등록한 후, 이 함수들이 실행하는 만큼 비용을 내는 플랫폼을 일컫는다.

말 그대로 하나의 기능을 제공한다는 개념이다.

이때 기능이란, 우리가 클라우드 컴퓨팅 환경에 등록한 함수를 의미한다.

FaaS는 클라우드 환경에 사용자가 등록한 함수에 대한 API를 제공하고, 해당 함수가 실행될 때마다 비용을 지불하는 형태로 진행된다.

FaaS의 장점과 단점

따로 서버를 구축하지 않아도 된다는 점에서 BaaS와 유사하지만, BaaS는 하나의 저장소(所)나 플랫폼이 아닌 함수(API)를 제공하며 해당 함수가 호출될 경우에만 실행이 된다는 특징이 있다.

특히 자체적으로 로그분석 및 실시간 모니터링 시스템을 적용하여, 특정 함수 호출 시 알람을 발생하게 하는 등 추가적인 기능도 연동할 수 있다.

다만 FaaS는 처리시간에 한계가 있어, 웹소켓같이(특히 게임에서 지속적인 데이터 누적이 일어나는 환경) 지속적인 데이터 전송이 이루어지는 곳에서는 적합하지 않다.

또한 FaaS 업체에서 제공하는 함수를 사용하다보니, local system을 이용할 수 없다는 단점이 발생한다.

이 경우 업체에서 제공하는 DB나 해당 system을 사용해야 할 것이고, 그만큼 추가적인 비용지불이 발생하게 된다.

• AWS Lambda는 어떤 서비스일까요? 이러한 서비스는 어떤 특징을 가지고, 어디에 쓰일 수 있을까요?

AWS에서 제공하는 FaaS의 일종이다.

즉 application 및 mobile app의 백엔드를 별도 구축없이 빠르게 구현할 수 있는 서비스이다.

AWS Lambda 관련 자료

• API Gateway는 어떤 서비스인가요? 어떤 설정을 할 수 있을까요?

Microservice의 경계 외부(최후방)에서 오는 API호출을 제어하고, 각 servcies에게 메시지를 보내는 서비스이다.

서비스 메쉬는 무엇이고 이러한 난점을 어떻게 해결하려는 시도일까요?

Microservice의 경계 내부(네트워크)에서의 트래픽을 관리하는 서비스이다.

참조개념

• Monolithic Architecture

하나의 서비스 안에 모든 모듈과 기능이 종속되어 있다는 개념이다.

각각의 모듈들은 다른 역할을 하지만, 결국 서비스의 최종 배포에 초점을 맞추었기 때문에 각 모듈의 기능과 요소보다는 최종적인 결과물에 관심을 둔다.

Microservice Architecture에 비해 배포과정이 단순할 수는 있지만, 내부적인 구조를 세세하게 유지하는 방법론이 아니어서 규모가 커지면 걷잡을 수 없이 복잡해질 수 있다.

또한 기본적으로 CI/CD가 불가능하기 때문에, 새로운 기술 및 규칙을 적용해야 한다면 모든 코드를 전면적으로 수정해야할 위험이 높다.

• Microservcies architecture _ Inner Architecture

내부 서비스에 대해 여러 개의 microservice로 분할하는 개념이다.

예를 들어 쇼핑몰에서 주문하기, 카트에 넣기를 같은 서비스로 볼 것인지 다른 microservice로 분리할 것인지는 해당 시스템에 따라 달라진다.

내부적인 microservice들을 구성하는데 중요한 점은 DB의 정합성이다.

비즈니스 트랜잭션들이 여러 DB에 걸쳐있을 수 있고, 동시다발적으로 요청이 올 수 있기 때문에 microservice 마다 가지는 DB의 정합성(일관성)을 유지하는 것이 필요하다.

사실 기업마다 정의하기가 어렵고, 경계가 모호한 부분이 많아 Inner microservice를 구성하는 것이 쉽지 않다.

• Microservcies architecture _ Outer Architecture

Microservices의 영역은 아래 그림에서 Inner Architecture를 제외한 부분이다.

이를 6가지 구획으로 정의하면 다음과 같다.
→ External Gateway
→ Service Mesh
→ Container Management
→ Backing Services
→ Telemetry
→ CI/CD Automation

API Gateway

이 중 API Gateway는 외부적인 서비스 요청(호출)에 대해 내부구조를 드러내지 않고 처리하기 위한 요소이다.

server 최앞단(User Interface level)에 위치하여, 모든 API를 받고 각 service(AWS Cloud환경 혹은 Container)들에게 routing하여 메시지를 전달한다.

사용자 인증, 정책관리 등의 역할을 담당한다.

Service Mesh

Microservices 구성 요소 간 네트워킹을 제어하는 역할을 한다.

service discovery, service routing, 트래픽 관리 등을 담당하는 요소가 있어야 하며, 결국 서비스의 트래픽을 내부적으로(네트워크 단에서) 통제한다.

• Warm / Cool Start

AWS Lambda는 아래와 같은 과정을 통해 동작한다.

→ Lambda 코드작성 및 배포
→ container로 해당 파일 다운로드 및 적재
※ Bootstrap, code를 컴파일하여 container에 load하는 과정
→ 코드 실행

AWS lambda가 Run하는 과정은 적재된 코드를 실행시켜 이에 대한 결과를 출력하는 것이다.

이때 WARM START는 이미 Container에 코드가 적재되어 따뜻한 상태로, 바로 Run(즉시 실행)할 수 있는 상태를 의미한다.

반면 COLD START는 코드를 적재하기 위해 Lambda 실행환경을 구성하고, 코드 초기화 및 호출(라우팅)하는 예열과정을 필요로 할 때를 일컫는다.

말 그대로 실행시킬 코드가 없기 때문에 추운 상태 - Lambda가 유휴상태이거나, 갑자기 많은 함수가 호출되는 등 - 으로 인해 COLD START가 발생한다.

기본적으로 WARM START와 COLD START는 실행속도에서 10배 이상의 차이를 보이기 때문에(WARM START가 훨씬 빠르다), 항상 예열상태를 유지하고 있는 것이 성능면에서 중요하다.

정리

0. why

• application 설계 방법에 microservices를 적용하는 이유에 대해 이해한다.
• 프로젝트 규모가 커졌을때 microservices가 왜 유지관리가 용이한지 생각해본다.

1. what

• MSA 개념에 대해 이해한다.
• MSA 설계를 위해 필요한 여러 기능, 도구들에 대해 학습한다.
• TDD개념과 연결하면서 이해해보도록 한다.

2. how

• 이미 진행된, 납기일이 중요한 프로젝트에서 MSA를 어떤 방향으로 적용하는게 좋을지 고민해본다.
• MSA는 inner, outer에 따라 그 종류가 나뉘어져 있는데 이를 어떻게 활용할 수 있을지 생각해본다.

3. 참조링크

microservices architecture
https://gruuuuu.github.io/cloud/architecture-microservice/

serverless architecture
https://velopert.com/3543

serverless architecture - AWS 공식 사이트
https://aws.amazon.com/ko/lambda/serverless-architectures-learn-more/

AWS lambda
https://velopert.com/3546

FaaS 관련 자료
https://delightwook.tistory.com/41

WAS lambda와 COLD START/WARM START
https://velog.io/@milkcoke/Lambda-Cold-start

AWS API Gateway - AWS 공식 사이트
https://aws.amazon.com/ko/api-gateway/

Lambda / API Gateway 활용 예시
https://velog.io/@dragontiger/%ED%8C%8C%EC%9D%B4%EC%8D%ACAWS-LambdaAWS-API-Gateway-%ED%85%94%EB%A0%88%EA%B7%B8%EB%9E%A8-%EB%B4%87-%EA%B0%9C%EB%B0%9C-%EB%B0%B0%ED%8F%AC%EA%B9%8C%EC%A7%80

★★★ MSA 정확히 이해하기
https://velog.io/@tedigom/MSA-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-2-MSA-Outer-Architecure

★★ MSA - API Gateway
https://velog.io/@tedigom/MSA-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-3API-Gateway-nvk2kf0zbj

★★ MSA - Service Mesh
https://velog.io/@tedigom/MSA-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-4Service-Mesh-f8k317qn1b

service mesh 추가 개념
https://daddyprogrammer.org/post/13700/service-mesh/