2023.07.31 코드스테이츠 78회차. ( 서버리스와 마이크로 서비스 )

서버리스 컴퓨팅

서버리스(Serverless)란 이름에서 알 수 있듯이, 서버를 직접적으로 관리하지 않는 컴퓨팅 방식

존에는 애플리케이션을 배포하려면 하드웨어 서버를 구매해서 구성해야 했지만 서버리스 방식에서는 개발자는 서버 인프라를 직접적으로 구성하고 관리하지 않는다

대신 클라우드 제공 업체(AWS, Azure, Google Cloud 등)가 서버 인프라를 관리하며, 개발자는 함수(Function) 단위로 애플리케이션을 작성한다

이렇게 작성된 함수는 서버리스 제공 업체가 제공하는 서비스를 통해 실행이 되는데 이 방식으로 개발자는 서버 인프라를 직접적으로 구성하고 관리할 필요 없이 빠르고 쉽게 애플리케이션을 개발하고 배포할 수 있다

 

컴퓨팅의 진화 과정

Serverless가 생기게 된 배경은 등장 이전의 애플리케이션 배포 과정을 살펴보면 이해할 수 있습니다.

오래전에는 애플리케이션을 배포하려면 직접 하드웨어 서버를 구매해서 구성했습니다.

이때는 하드웨어와 소프트웨어 둘 다 관리를 해야 했습니다. 하드웨어의 직접적 관리는 이점도 있었지만 서버 관리에 많은 비용을 지불해야 했고 메모리 관리와 같은 불편한 점도 있었습니다.

이런 서버의 하드웨어 관리의 어려움을 해결해 준 것이 AWS 클라우드 컴퓨팅 서비스 EC2였습니다.

이로서 하드웨어 관리의 불안감을 덜 수 있게 되었습니다.

하지만 빌려서 구성한 서버의 소프트웨어도 보안, 업데이트, 백업과 같은 많은 관리 과정이 필요합니다. 이때 이런 서버의 소프트웨어 관리의 어려움을 해결하는 방안으로 Serverless가 등장했습니다.

 

 

 

서버리스의 장점

• 서버 관리 불필요
• 유연한 확장성
• 고가용성
• 유휴 용량 없음

 

서버리스(Serverless)의 등장 배경은 하드웨어의 직접 관리뿐 아니라 서버의 소프트웨어 관리의 어려움을 해결해 주기 위한 것

 

이전에는 빌려서 구성한 서버의 소프트웨어도 보안, 업데이트, 백업과 같은 많은 관리 과정이 필요하였습니다. 서버리스(Serverless) 방식은 이를 해결해 준다

 

서버리스(Serverless)는 마이크로서비스(Microservices)의 특징들을 반영하고 있는데 마이크로서비스와 서버리스(Serverless)는 비슷한 컨셉을 가지고 있다

 

마이크로서비스는 서비스를 Function 단위로 분리하고 각각을 개별적으로 배포하고 관리하는데 이와 비슷하게 서버리스(Serverless)도 Function 단위로 애플리케이션을 작성한다

서버리스(Serverless) 방식은 빠르고 쉽게 애플리케이션을 개발하고 배포할 수 있고 서버 인프라를 직접 구성하고 관리할 필요 없이 서버 인프라를 클라우드 제공 업체가 관리하기 때문에 비용과 시간을 절약할 수 있다

 

 

AWS에서 지원하는 서버리스 컴퓨팅

AWS에서는 다양한 서버리스 서비스를 제공합니다. 함수 서비스인 AWS Lambda, 데이터 처리 서비스인 Amazon Kinesis, 데이터베이스 서비스인 Amazon DynamoDB, 인증 서비스인 AWS Cognito 등이 있습니다. 또한, AWS에서는 서버리스 애플리케이션을 쉽게 만들고 배포할 수 있는 서비스인 AWS Serverless Application Model (SAM)도 제공합니다. 이외에도 AWS Step Functions, AWS Glue, Amazon S3 등 다양한 서비스에서 서버리스 기능을 지원하고 있습니다.

 

 

 

 

마이크로서비스 (MSA : Micro Service Architecture)

마이크로 서비스 아키텍처는 소프트웨어 아키텍처 디자인 패턴 중 하나로, 큰 애플리케이션을 작은 단위의 독립적인 서비스로 분할하여 구성하는 아키텍처이다

 

기존의 모놀리식 아키텍처에서는 전체 애플리케이션을 하나의 큰 덩어리로 개발하고 배포하였지만, 마이크로 서비스 아키텍처에서는 서비스 단위로 개발하고 배포하기 때문에, 개발자들은 더욱 빠르고 유연하게 개발할 수 있다

 

각각의 서비스는 독립적인 데이터베이스와 서버를 가지며, 서로 간의 통신은 API를 통해 이루어집니다. 이로 인해, 개별적인 서비스의 장애가 전체 시스템에 큰 영향을 끼치지 않으며, 서비스 단위로 확장이 가능합니다.

 

마이크로 서비스 아키텍처는 다양한 프로그래밍 언어와 데이터베이스를 혼합해서 사용할 수 있습니다. 이는 각 서비스가 특정 프로그래밍 언어나 데이터베이스에 의존하지 않기 때문에, 개발자들이 좀 더 적합한 툴과 기술을 선택할 수 있도록 도와줍니다.

마이크로 서비스 아키텍처는 최근에 인기가 높아지고 있으며, 클라우드 컴퓨팅과 함께 사용되어 더욱 확장성과 유연성을 제공합니다.

 

마이크로 서비스 아키텍처를 구성하는 방법은 다양합니다. 일반적으로, 각 서비스는 자체 데이터베이스와 서버를 가지며, 서로 다른 프로그래밍 언어와 기술을 사용할 수 있습니다.

 

이러한 구성 방식은 서비스 간의 의존성을 최소화하고, 각 서비스를 독립적으로 배포 및 확장할 수 있도록 합니다. 또한, 서비스 간의 통신을 위해 API 게이트웨이를 사용하면, 서비스 간의 통신 구조를 단순화할 수 있습니다.

 

예를 들어, 전자상거래 회사에서는 다음과 같은 서비스를 구성할 수 있습니다.

• 사용자 관리 서비스: 사용자 정보를 관리하는 서비스
• 상품 관리 서비스: 상품 정보를 관리하는 서비스
• 주문 관리 서비스: 주문 정보를 관리하는 서비스
• 결제 관리 서비스: 결제 정보를 관리하는 서비스
• 배송 관리 서비스: 배송 정보를 관리하는 서비스

각각의 서비스는 독립적으로 개발되며, API 게이트웨이를 통해 서로 통신합니다. 예를 들어, 사용자 관리 서비스에서는 사용자 정보를 제공하고, 상품 관리 서비스에서는 상품 정보를 제공합니다. 주문 관리 서비스에서는 사용자와 상품 정보를 결합하여 주문 정보를 만들고, 결제 관리 서비스에서는 주문 정보를 기반으로 결제 정보를 생성합니다. 마지막으로, 배송 관리 서비스에서는 결제 정보와 주문 정보를 기반으로 배송 정보를 생성합니다.

 

이러한 방식으로 구성된 마이크로 서비스 아키텍처는 유연하고 확장성이 높으며, 개발자들이 서비스 간의 의존성을 최소화하고, 적합한 기술 스택을 선택할 수 있도록 합니다.

 

 

 

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

 

 

• 빠른 개발 및 배포: 각 서비스는 독립적으로 개발 및 배포되므로, 전체 애플리케이션을 하나의 덩어리로 개발하는 것보다 더욱 빠르고 유연한 개발이 가능합니다.
• 확장성: 서비스 단위로 확장이 가능합니다. 각각의 서비스는 독립적인 데이터베이스와 서버를 가지므로, 개별적인 서비스의 장애가 전체 시스템에 큰 영향을 끼치지 않습니다.
• 혼합 가능한 기술 스택: 각 서비스가 특정 프로그래밍 언어나 데이터베이스에 의존하지 않기 때문에, 개발자들이 적합한 툴과 기술을 선택할 수 있습니다.

 

 

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

 

 

• 더 많은 운영 부담: 각각의 서비스는 독립적으로 운영되므로, 모놀리식 아키텍처보다 더 많은 운영 부담이 있습니다.
• 분산 시스템의 복잡성: 서비스 간의 통신은 API를 통해 이루어지므로, 서비스 간의 통신 구조를 잘 설계해야 합니다. 또한, 분산 시스템의 복잡성으로 인해 디버깅이 어려울 수 있습니다.

 

 

 

손쉽게 마이크로 서비스 구성을 지원하는 AWS

 

 

AWS에서 마이크로 서비스 아키텍처를 구축하는 방법은 다음과 같습니다.

1. AWS Lambda를 사용하여 함수 기반 마이크로 서비스를 개발할 수 있습니다. 이를 통해, 서버리스 아키텍처를 구축할 수 있으며, 개발자들은 더욱 빠르게 서비스를 개발할 수 있습니다.
2. Amazon ECS를 사용하여 컨테이너 기반 마이크로 서비스를 배포할 수 있습니다. 이를 통해, 컨테이너화된 서비스를 더욱 쉽게 배포하고 관리할 수 있습니다.
3. Amazon API Gateway를 사용하여 마이크로 서비스의 API를 게이트웨이로 관리할 수 있습니다. 이를 통해, 서비스 간의 통신 구조를 단순화하고, API 관리를 효율적으로 할 수 있습니다.
4. AWS Elastic Beanstalk을 사용하여 마이크로 서비스를 쉽게 배포할 수 있습니다. 이를 통해, 개발자들은 더욱 쉽게 서비스를 배포하고 관리할 수 있습니다.

이러한 AWS의 서비스들을 조합하여 마이크로 서비스 아키텍처를 구축할 수 있으며, AWS의 다양한 기능들을 활용하여 더욱 유연하고 확장성이 높은 서비스를 개발할 수 있습니다.

 

 

 

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

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

다음 특징을 갖는 서비스들의 조합으로 이뤄진 설계를 의미합니다.

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

서비스로서의 컴포넌트화

 

• 컴포넌트: 독립적으로 대체하거나 업그레이드할 수 있는 소프트웨어 단위
• 컴포넌트화: 시스템을 구성 요소(Component)를 나누고 이를 연결하여 구축하는 것
• 컴포넌트화는 어떻게?: 소프트웨어를 여러 서비스로 분리하는 것

 

 

라이브러리 vs 서비스

 

 

 

비즈니스 수행에 따른 구성, 프로젝트가 아니라 제품

 

before: 기술적 계층에 따른 팀 분류

 

• 예) UI 팀, 비즈니스 로직 팀, 데이터베이스팀
• 단순한 변경이 필요한 경우에도 팀 간의 협업 비용이 증가함

 

 

after: 비즈니스 수행 능력(업무 도메인)에 따른 팀 분류

 

• 도메인?
  • 예) 쇼핑몰의 경우 회원/상품/배송이 각각의 도메인이 됩니다.
  • 하나의 온전한 시스템의 단위
• 팀이 하는 일이 하나의 서비스로 나뉨 → 마이크로서비스
  • 이로 인한 장점으로는,
    • 소프트웨어 스택, 데이터베이스 선택, 프로젝트 관리 등이 팀별로 독립적입니다.
  • 이를 달성하기 위해서,
    • 각 팀은 서비스에 대한 책임을 가져야 합니다.
    • 각 서비스는 메시지 버스(통신 인터페이스)를 통해 통신해야 합니다

 

 

조직과 아키텍처의 연관성

 

마이크로서비스로 소프트웨어를 작성할 때는, 소프트웨어 작성에 앞서 팀의 일하는 방식을 보다 독립적으로 만들어 내야 합니다. 혹은 마이크로서비스 아키텍처를 통해, 팀의 일하는 방식이 보다 독립적으로 만들어질 수 있습니다.

 

 

 

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

 

특징

서비스(엔드포인트)는 일을 하게 하고, 통신(파이프라인)은 최대한 단순하게 합니다

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

 

대표적인 방법

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

 

 

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

 

문제점

 

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

"우리 회사는 Java 9와 Oracle만 사용합니다" "간단한 리포트 만드는 서비스가 필요한데, 어려운 프레임워크를 꼭 써야 해?"

문제 해결에 오히려 방해가 될 수 있음!

 

해결책

 

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

 

 

 

장애 방지 설계

(모놀리틱 설계에 비해 불리한 지점)

• 서비스는 언제든지 실패할 가능성이 있습니다.
• 신속하게 장애를 감지하고 가능하면 자동으로 서비스를 복구할 수 있어야 합니다.
  • 예) 아키텍처 요소(데이터베이스가 받는 1초당 요청 수)와 비즈니스 관련(1초당 받는 주문 번호와 같은) 부분을 모두 확인
• 대시보드와 모니터링은 필수적입니다.

 

진화하는 설계

 

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

 

 

 

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

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

 

 

 

 

API Gateway

 

API Gateway는 경로와 엔드포인트로 구성되어 정의된 HTTP 서버를 말합니다. 각 경로는 해당 경로를 처리하는 리소스와 연결되며, 서버리스 아키텍처에서 이러한 핸들러는 FaaS 기능을 종종 사용합니다. 즉, API Gateway는 각 API 요청의 관문 역할을 합니다.

API Gateway는 요청을 수신하면 요청과 일치하는 라우팅 구성을 찾고, 관련된 FaaS 기능을 호출합니다. 일반적으로 API Gateway는 HTTP 요청 매개변수에서 FaaS 기능을 간결한 입력으로 매핑을 허용하거나 전체 HTTP 요청이 일반적으로 JSON 객체로 전달되도록 허용합니다. FaaS 기능은 로직을 실행하고 결과를 API Gateway에 반환하며, 차례로 이 결과를 원래 호출자에게 다시 전달하는 HTTP 응답으로 변환합니다.

Amazon API Gateway는 다른 API Gateway 공급업체와도 유사한 기능을 제공합니다. Amazon의 API Gateway는 사용자가 구성하지만 직접 실행하거나 프로비저닝할 필요는 없습니다.

 

 

 

API Gateway가 중요해진 배경은?

전통적인 모놀리틱 아키텍처 기반의 대용량 서비스가 점점 유지보수의 어려움을 겪으며 마이크로서비스 아키텍처가 기존 모놀리틱 아키텍처의 단점을 보완하는 역할을 합니다. 그 MSA를 구성할 때 접목한 서비스가 API Gateway입니다. API Gateway는 마이크로서비스를 연결하는 중간 다리 역할을 담당하며, MSA에서 핵심적으로 필요한 기능이 되었습니다.

 

 

API Gateway를 사용하는 이유?

 

마이크로서비스의 사용 증가로 인해 API 게이트웨이가 더 많이 사용되고 있습니다. 각 마이크로서비스는 자체 기능을 필요로 하기 때문에 애플리케이션을 느슨하게 결합된 여러 서비스로 분해될 수 있습니다. 한편, 마이크로서비스를 사용하면 애플리케이션의 다양한 기능을 더 쉽게 개발, 배포 및 유지 관리할 수 있지만 고객이 애플리케이션에 빠르고 안전하게 액세스하기가 더 어려워질 수도 있습니다. 이때 API 게이트웨이가 이 문제를 해결할 수 있습니다. 고객이 각 마이크로서비스에 대한 액세스를 개별적으로 요청하는 대신 게이트웨이는 요청에 대한 단일 진입점(entry point)으로, 해당 요청을 적절한 서비스에 연결하고 결과를 수집하여 요청자에게 다시 전달하게 도와줍니다. 이 기능을 라우팅이라고 하며, API Gateway의 주요 기능 중 하나입니다.

API 게이트웨이는 성공적인 API 관리에 필수적입니다. 고객을 서비스와 연결하는 주요 프록시인 게이트웨이는 인증, 메트릭 수집, 입력 유효성 검사 및 응답 변환을 포함한 중요한 관리 및 보안 기능을 지원합니다.

 

종류

 

• Zuul - 넷플릭스 API Gateway
• AWS API Gateway
• Azure API Gateway
• 익스프레스 API Gateway

 

 

 

API Gateway는 어떤 기능들을 할까?

 

• IP 화이트리스팅
  • IP 주소 범위를 제한하거나 화이트리스트에 추가한다. 액세스는 일반적으로 액세스 정책 관리자를 통해 구성된다. 액세스 정책 관리자는 Gateway가 처리하는 방법 및 제한 사항을 사용자에게 표시하는 방법과 함께 제한 사항을 구현할 수 있다. AWS의 API Gateway를 예로 들면, 자원 정책 기능은 사용자가 리소스에 대한 JSON 정책 문서를 할당하고 IAM 그룹, 사용자 또는 역할이 그들에 액세스할 수 있는지 확인할 수 있다.
• 전송 메시지 암호화
  • API Gateway를 통과하는 서비스 간의 메시지를 보호하는 역할을 하며 전송 중인 모든 정보에 공통 표준이 적용되도록 한다. Amazon API Gateway의 경우 적절한 최소 보안 표준을 설정하는 암호화되지 않은 워크로드를 지원하지 않는다.
• 속도 제한
  • 스로틀링 메커니즘을 사용하여 대기열 및 경우에 따라 요청 우선순위를 관리하게 된다. 속도 제한은 요청 우선순에 따라 API에 대한 요청 수를 제한하는 기능이다.  정책 수준으로 구성이 정의되며 모든 요청 및 프로토콜에 적용된다. 속도 제한은 DDOS 공격의 영향을 잠재적으로 제한하기 때문에 보안 기능으로도 간주한다.
• API 구성 및 라우팅
  • API Gateway의 작업은 서비스에서 서비스로 요청을 라우팅하는 것뿐만 아니라 성능과 효율성도 고려한다. API 구성 또는 집계는 서로 다른 서비스로의 쿼리 결과를 단일 응답으로 결합하는 프로세스다. 이것은 대규모 데이터 세트에 이상적이지는 않지만, 요청자에서 서비스까지 이상적인 경로를 제공하는 매우 간단하고 효율적인 방법이다.
• 캐싱
  • TTL이 만료될 때까지 요청이 서비스를 모두 적중할 필요가 없도록 API Gateway 수준에서 캐싱할 수 있다. 캐싱은 대부분의 API Gateway에 공통적인 기본 기능이지만 구성의 세분성은 제품 제공 및 구현에 따라 다르다.
• 로깅 추적
  • 즉시 사용 가능한 로깅 기능을 제공하여 API Gateway를 통과하는 모든 API 트래픽의 추적을 가능하게 하고 Gateway에서 들어오고 나가는 요청, URL, 관점에서 수행하는 방식과 함께 요청되는 매개변수에 대한 지표를 표시한다.
  • Gateway의 다른 모니터링 기능도 중요하다. 예를 들어 AWS Cloudwatch를 사용하여 Rest API 실행과 같은 API Gateway의 지표를 표시한다. 이는 서로 다른 API 간에 비교 지표를 제공할 수 있기 때문에 많은 가치가 있다.
• API 버전 관리
  • 다양한 버전의 API를 처리하는 것은 API Gateway의 중요한 기능이다.
  • API 버전 관리는 소비자와 함께 기존 API에 대한 코드 해독 변경을 방지하는 데 도움이 되는 중요한 전략으로 개발자가 사용자에게 미치는 영향을 최소화하면서 여전히 사용 중인 API의 이전 버전을 천천히 감가상각할 수 있다. 이는 내부 API 사용자에게 중요하지만 실제 개발자와 같이 도메인 소유자에게 직접 액세스할 수 없는 API의 제3자 소비자와 작업할 때는 훨씬 더 중요하다.

 

 

 

 

AWS API Gateway는 어떤 장점이 있을까?

Amazon API Gateway는 트래픽 관리, 권한 부여 및 액세스 제어, 모니터링, API 버전 관리를 비롯해 최대 수십만 건의 동시 API 호출을 수락 및 처리하는 데 관련된 모든 작업을 처리합니다.

• 트래픽 측정
  • API 키 별로 일련의 플랜을 정의하고, 제한과 할당량 한도를 구성할 수 있다.
  • API에 대한 트래픽을 측정하기 때문에 각 API 키에 대한 사용률 데이터를 추출할 수 있다.
• 보안
  • AWS IAM과 Amazon Cognito 같은 AWS 관리 및 보안 도구를 사용해서 API에 대한 액세스 권한을 부여할 수 있다.
  • AWS에서 자체 API를 확인할 때 사용한 것과 동일한 방법론을 사용하여 서명된 API 호출을 확인한다.
  • AWS Lambda 함수로 작성된 사용자 정의 권한 부여자를 사용하여, 수신되는 전달자 토큰을 확인하도록 지원하여 백엔드 코드의 인증 문제를 해결한다.
• 복원력
  • 조절을 통해 트래픽을 관리하므로 트래픽 스파이크가 발생해도 백엔드에서 처리할 수 있다.
  • 매번 백엔드를 호출하지 않도록 API 호출 결과를 캐싱하여 최종 사용자가 경험하는 API 성능 및 지연 시간을 개선할 수 있다.
• 작업모니터링
  • API가 게시되고 사용되면 API Gateway에서 서비스에 대한 호출을 모니터링할 수 있는 지표 대시보드를 제공한다.
  • 대시보드는 Amazon CloudWatch와 통합을 통해 API 호출, 지연 시간 데이터, 오류 발생률 등 백엔드 성능 지표를 제공한다.
  • API의 각 메서드에 대한 상세 지표를 활성화하고 CloudWatch log에 있는 오류, 액세스 또는 디버그 로그로 수신할 수 있다.
• 수명 주기 관리
  • API를 게시한 후에는 이전 버전을 개선하거나 새로운 기능을 추가한 새로운 버전을 구축 및 테스트해야 하는 경우가 많다. API Gateway를 사용하면 여러 API 버전과 각 버전의 여러 스테이지를 동시에 운영할 수 있으므로 새로운 API 버전이 게시된 후에도 기존 애플리케이션에서 이전 버전을 계속 호출할 수 있다.
• 개발자를 위한 설계
  • API를 신속하게 생성하고 API 응답에 대한 정적 콘텐츠를 할당하여 팀 간 개발 노력을 줄이고 애플리케이션 출시 시간을 단축할 수 있습니다.
  • 개발자의 API를 사용하는 팀은 개발자가 백엔드 프로세스를 구축하는 동안 개발을 시작할 수 있다.
• 실시간 양방향 통신
  • 서버를 실행하거나 관리할 필요 없이 채팅 앱, 스트리밍 대시보드 및 알림 같은 실시간의 양방향 통신 애플리케이션을 구축할 수 있다.
  • API Gateway를 사용하면 연결된 사용자 간에 영구 연결이 유지되며 이러한 사용자 간에 메시지를 전송할 수 있다.

 

 

 

AWS Lambda

Lambda는 AWS가 제공하는 서버리스 FaaS 솔루션으로, 함수의 인스턴스를 실행하여 이벤트를 처리합니다.

 

 

FaaS

 

• FaaS는 자체 서버 시스템이나 수명이 긴 서버 애플리케이션을 관리하지 않고 백엔드 코드를 실행하는 것
• FaaS는 런타임(Java, node.js 등)에 대한 사전 준비가 필요하지 않음
• FaaS 기능에는 특히 상태 및 실행 기간과 관련하여 상당한 아키텍처 제한이 있음
• 수평적 확장은 완전 자동이며 탄력적이며 공급자가 관리함
• FaaS의 기능은 일반적으로 공급자가 정의한 이벤트 유형에 의해 트리거됨
  • HTTP 요청에 대한 응답으로 트리거되도록 만들 수 있음

 

 

특징

• 서버를 프로비저닝하거나 관리할 필요 없이 작성한 코드를 백엔드 서비스로써 배포할 수 있게 해 줍니다.
• Lambda 함수를 실행하려면, 애플리케이션 또는 백엔드 서비스의 코드를 작성한 뒤 이벤트 트리거만 정의하면 됩니다.
  • 이벤트 트리거의 대표적인 예: Amazon S3 업로드나 DynamoDB 업데이트, Kinesis 스트리밍, API 게이트웨이 요청
  • 이벤트 주도 아키텍처(Event Driven Architecture)를 구성할 수 있습니다.
• 높은 가용성을 제공합니다.

 

 

AWS Lambda의 단점

24시간 내내 돌아가고 있는 상태가 아니고, 요청이 올 때 AWS가 Lambda를 깨우는 데 시간을 사용하기 때문에 응답의 속도에 차이가 있습니다. 요청이 적을 때는 의미가 없지만 요청이 많을 때는 이 차이가 응답 속도에 영향을 줍니다. 이러한 점 때문에, 어떤 함수가 자주 쓰이는지 파악해서 해당 함수는 잠들지 않고 대기하는 기능을 추가하기도 했습니다. 차이는 미세하지만, 서버가 응답하는 시간이 다소 걸릴 수 있다는 것이 단점으로 지적됩니다.

Q. Lambda에서 Cold Start와 Warm Start의 차이는 무엇인가요? 어떤 때에 Cold/Warm Start가 발생하나요?

또한, 지나치게 AWS에 의존하게 됩니다. 백엔드를 AWS Lambda에 배포했을 때 다른 곳으로 옮기고 싶을 때, 한 서버리스에서 다른 쪽 서버리스로 마이그레이션 하는 것이 쉽지 않습니다. EC2와 같은 서버를 사용할 경우, EC2 내에서 실행되는 WAS 프로그램을 다른 클라우드 사업자의 컴퓨팅 리소스로 옮겨 실행하기만 하면 되지만, 서버리스는 클라우드 사업자의 요구사항에 맞는 코드가 작성되어야만 합니다.

 

AWS Lambda 함수

AWS Lambda에서 실행하는 코드는 'Lambda 함수'로 업로드됩니다. 각 함수에는 이름과 설명, 진입점, 리소스 요구 사항 등 연관된 구성 정보가 포함되어 있습니다. 코드는 Stateless 스타일로 작성되어야 합니다. 즉, 기본 컴퓨팅 인프라에 대한 선호도가 없다고 가정해야 합니다. 로컬 파일 시스템 액세스, 하위 프로세스 및 유사한 아티팩트는 요청 수명 기간 이상 확장될 수 없으며, 모든 지속 상태는 Amazon S3, Amazon DynamoDB, Amazon EFS 또는 다른 인터넷 사용 스토리지 서비스에 저장되어야 합니다.

• Q. Lambda 함수가 Stateless여야 하는 이유가 무엇인가요?
  • A. 함수를 상태 비저장으로 유지하면 AWS Lambda에서 필요한 만큼 함수 사본을 빠르게 시작하여 수신 이벤트 비율에 따라 조정할 수 있습니다. 비록 AWS Lambda의 프로그래밍 모델은 상태 비저장이지만, 코드를 통해 Amazon S3 또는 Amazon DynamoDB 등 다른 웹 서비스를 호출하면 상태 저장 데이터에 액세스할 수 있습니다.

 

 

트리거

트리거는 Lambda 함수를 호출하는 리소스 또는 구성입니다. 트리거에는 이벤트 소스를 제공하는 AWS 서비스가 포함될 수 있습니다.

Lambda와 함께 사용하는 서비스에 따라 호출은 일반적으로 두 가지 방법 중 하나로 작동합니다. 이벤트가 호출을 유도하거나, Lambda가 대기열 또는 데이터 스트림을 폴링하고 대기열 또는 데이터 스트림의 활동에 대한 응답으로 함수를 호출합니다.