Micro Service와 Serverless

이번 포스팅에서는 AWS를 적용하는 환경에서 최근 엄청난 열풍을 몰고 있는 마이크로서비스 아키텍처와 서버리스 컴퓨팅은 어떻게 구현하는 것이 좋은지 살펴보도록 하겠습니다.

# 본 포스팅은 개인적으로 또는 회사 차원에서 진행한 TF의 다양한 학습 결과 그리고 Architecting On AWS 교육 등을 통해 습득한 지식을 리마인드하며 공유하는 것임을 알려드립니다.

마이크로서비스 아키텍처는 두가지 관점으로 접근할 수 있는데 그 첫번째는 바로 API 서비스입니다.

API를 정의하고 이를 독립적인 서비스 환경으로 운영하는 애플리케이션을 마이크로 서비스라고합니다.

이미 많은 포스팅에서 마이크로서비스에 대한 가이드를 하곤 했는데, 상세히 살펴보기에 앞서 마이크로서비스를 성공적으로 수행하기 위한 필수 조건을 먼저 살펴보고 넘어가겠습니다.

최근 마이크로서비스 아키텍처를 구축하기 원하는 모 사이트에서 설계작업을 진행중입니다.

마이크로서비스를 자신있게 실현했다라고 표현하기에는 다소 부족함이 있지만, 다양한 API Component들을 비교하고 분석하며 최적의 아키텍처 패턴을 찾아내기 위해 하루하루 최선을 다하고 있습니다.

다만 이렇게 일에 열중하면서 한가지 고민거리가 생겼습니다.

대체 마이크로서비스란 어디까지를 의미하는 것일까?

단순히 API 서비스를 제공하는 서비스의 분리를 의미하는 것일까? 이건 분산 아키텍처와는 별반 다르지 않은것 같고..

MSA를 구성하는 핵심 요소 중 하나인 API Gateway를 적용해야만 하는 것일까?

아니라면 최소한 Scalability를 위한 Managed Container를 적용해야 MSA일까?

아직도 이에 대한 정확한 답변은 제공되지 않고 있으며, 이는 SOA를 추구했던 얼마 되지 않은 과거의 우리 고민과도 별반 다르지 않다는 것을 알 수 있습니다.

그래서 오늘 이시간에는 MSA를 적용하기 위해서는 최소한 무엇을 갖추어야 하는가에 대한 고민을 풀어보도록 하겠습니다.

Step 1. DevOps 바로 조직의 변화

마이크로서비스를 개발하는 개발자, 시스템을 운영하는 운영자, 관리자, SWA, DBA 등등 하나의 프로젝트가 성공적으로 마무리가 되기위해서는 다양한 분야의 전문가들의 집합이 필요합니다.

마이크로서비스 아키텍처를 성공하기 위해서는 이런한 DevOps들의 집합 즉 조직의 개편이 매우 중요한 요소로 자리잡고 있습니다.

마이크로서비스를 개발하는 주요 이유 중 하나인 Agility 확보 측면에서 봤을때 조직의 변화는 마이크로서비스 아키텍처를 성공적으로 달성하는 핵심 포인트라고 할 수 있겠습니다.

지난 3월 클라우드 파운더리 창시자인 Chris Richardson (크리스 리차드슨)은 다음과 같이 말했습니다.

"최소한의 MSA를 운영하는 DevOps 조직은 자동화된 CI/CD 환경과 테스트 자동화 환경을 구축해야만 한다."

한국의 IT 시장은 기존 빅뱅 형식의 차세대급 프로젝트를 전환하는 방식으로 진행되는 경우가 많은데, DevOps 조직을 구축하는 경우 이러한 빅뱅 방식의 전환의 경우 마이크로서비스 단위 별로 애자일한 개발, 운영 단계를 적용하기는 어려움이 있습니다.

예를 들어 이런거죠?

A 금융사에는 IT를 전담하는 B 계열사가 있습니다. 이때 B 계열사는 IT 운영 업무에 특화된 회사로 신규 개발이나, 프로젝트의 경우 C 대기업 IT 서비스 회사에 업무를 맡기게 됩니다.

이때 DevOps 체계를 구축하기 위해서는 B 계열사의 Ops 조직과 C IT 서비스 회사의 Dev 조직의 하나의 프로젝트를 이끌어 나가는 조직으로 만들기 위해서는? 전혀 다른 회사를 하나로 합칠수도 없고 참 참담한 현실이죠..

한국의 IT 조직은 대부분 저렇게 구성되어 있습니다.

따라서 DevOps 조직의 변화를 꾀하기 어려울 경우 최소한 자동화된 CI/CD 환경과 테스팅 환경을 구축하여 이후 마이크로서비스 아키텍처를 운영하는 서로 다른 조직의 협업을 위해 노력해야 할 것입니다.

Step 2. 데이터베이스의 분리

마이크로서비스 아키텍처를 구분하는 기준을 선정하는 것은 사실 매우 중요하지만 매우 난애하고 매우 어려운 부분이라고 볼 수 있습니다.

일반적으로 마이크로서비스를 구분하기 위해서는 업무를 정확히 이해하고 있는 현업의 참여가 중요합니다.

업무 이해도 없이 마이크로서비스를 구분할 경우 단순히 목차의 나열이나, 소스 패키지명을 그 단위로 결정하는 경우가 많은데 대체로 실패한 프로젝트들의 공통점이라고 볼 수 있습니다.

이때 데이터베이스의 분리는 마이크로서비스를 즉 애플리케이션을 분리할 수 있는 기준이 될 수 있을 것입니다. 데이터베이스의 분리가 Agility를 향상 시킨다는 것은 당연한 이유이기도 합니다.

Step 3. 그 밖의 다양한 고려사항

위와 같은 기본 고려사항 이외에도 실제로 논의된 다양한 설계 시 고려사항은 다음과 같습니다.

주요한 몇가지 사항만 살펴보자면, PaaS 기반 API Gateway를 도입할 경우 고려사항, 비용 문제, 다양한 기능문제, 조직의 문제, 유지보수 문제, 성능에 대한 문제 등등 

고려사항은 Component의 선정, 배치, 분석, 설계 모든단계에 걸처 쏟아져 나오고 있는 실정입니다.  

단순히 고려사항을 살펴보다보니 마이크로서비스의 단점만을 언급한 것은 아닌가 싶긴 하지만, 마이크로서비스 아키텍처를 단순히 적용하는 것만으로도 얻을 수 있는 장점은 굉장히 많습니다.

Availability, Scalability, Usability, Flexibility, Composability 등등 다 논할 수 없을 정도로 MSA는 많은 장점을 갖고 있으며, LG CNS의 차기 주요 사업을 이끌어 나가는 아키텍처 중 하나가 될 것이라 확신합니다.

다만 "MSA is not a silver bullet" MSA가 모든 해결책은 아니다. 라는 말을 명심하고 접근한다면 보다 성공적 설계와 프로덕트가 될 수 있지 않을까 생각합니다.

서론은 여기까지 하고 이제 본격적인 마이크로서비스에 대해 살펴보겠습니다.

마이크로서비스를 제공하기 위한 핵심적인 기술은 바로 컨테이너 기술입니다. 컨테이너는 손쉬운 확장과 구성 독립적인 실행 환경과 빠른 기동 속도 등으로 인해 마이크로서비스 아키텍처를 설계하는데 필수적인 요소로 자리잡았습니다.

대표적인 컨테이너 기술이 바로 도커입니다.

1. Amazon ECS (EC2 Container Service)

Amazon ECS는 확장성이 뛰어난 Container Management Platform으로 수천 개의 인스턴스를 기동하고 관리할 수 있으며, 인프라 구축의 복잡성을 간결하게 만들었습니다.

특히 확장성 있는 관리를 위한 컨테이너 서비스를 제공하며, 컨테이너 이미지 저장소로 Amazon Elastic Container Registry (ECR)을 제공합니다.

AWS 환경에서 모놀리식 애플리케이션을 컨테이너 기반 마이크로서비스로 전환하기 위해서는 다음과 같은 절차로 진행됩니다.
1) 모놀리식 애플리케이션을 마이크로서비스로 분리하여 ECR 또는 S3에 저장

---

---

2) ALB를 사용하여 경로기반 분기 후 대상그룹 서비스로 포워딩
3) 서비스는 하위 EC2 기반 ECS의 컨테이너로 로드밸런싱

---

---

4) 구성 단위는 EC2 / Fargate를 선택할 수 있음

5) 추가적으로 AWS App Mesh를 통한 서비스 디스커버리 동작 방식과 연계하여 보다 유연한 구성이 가능함

 

EKS & ECS
그 밖에 EKS 서비스도 존재합니다. EKS는 AWS에서 Kubernetes 기반 컨테이너 오케스트레이션을 구동할 수 있습니다. 이로인해 오픈소스와의 연계가 유연하고 클라우드 플랫폼 마이그레이션에 Lock-In되어 있는 ECS보다 유연하게 접근할 수 있습니다.
ECS는 EC2 오케스트레이션 자체라고 볼 수 있으며, 사용이 편하다는 장점이 있으며, EKS는 K8S 기반으로 복잡하지만 유연한 확장이 가능하다는 장점이 있습니다.

 

Fargate

앞서 살펴본 봐와 같이 AWS는 EC2 기반 & Fargate 기반 컨테이너 서비스를 제공합니다.

Fargate는 완전 관리형 컨테이너 서비스로 클러스터 프로비저닝 및 관리를 자동으로 수행합니다.

2. 서버리스 환경 구현

다음으로 살펴볼 내용은 서버리스 컴퓨팅입니다. 서버리스는 말 그대로 서버를 관리하지 않고 앱과 서비스를 구축하고 실행할 수 있는 환경을 의미합니다.

AWS Lambda

AWS의 대표적인 서버리스 컴퓨팅 서비스인 Lambda는 완전 관리형 컴퓨팅 서비스로 상태 비저장 코드를 실행합니다.
대체로 1회성 용도의 프로그램인 주기적인 Job을 처리하는 Scheduler 역할로 사용하거나, Amazon S3 버킷 또는 DynamoDB 테이블의 데이터 변경, 또는 엣지 로케이션의 CDN에서 Lambda 형태로 처리하곤 합니다.
다만 제한사항으로 최대 15분 길이로 지침을 실행할수 있으며, 15분이 넘어가는 서비스는 컨테이너 기반 또는 EC2 기반으로 구성해야 합니다.
서버리스 컴퓨팅을 적용하면 애플리케이션 개발에 보다 집중할 수 있고 요청 시에만 컴퓨팅 리소스를 사용하여 비용 효율적인 시스템이라고 볼 수 있으며 특히 마이크로서비스 아키텍처와 같이 세분화 된 서비스에 보다 적합합니다.

AWS API Gateway

API Gateway는 마이크로서비스를 정의하는 API를 처리하는 핵심 Component로 단일 접점 역할을 담당하여 외부로 엔드포인트 노출을 차단할 수 있습니다.

API 서비스의 핵심과 답게 다양한 기능을 제공하며 주요 기능은 다음과 같습니다.

---

- 개발자에게 API 키를 생성하여 배포
- CIDR을 활용하여 API에 대한 액세스 승인
- 프라이빗과 통합, Lambda와 통합 기능 지원
- 엔트포인트 노출 방지 역할
- DDoS 및 명령어 주입 공격으로부터 보호
- API Gateway 캐시 기능 제공

---

다음은 API Gateway와 Lambda Function을 활용한 아키텍처 예시입니다.

---

 

---

위와 같이 사용자 자격 증명 관리를 위한 Lambda Function과 핵심 비즈니스 로직을 수행하는 서버리스 컴퓨팅이 함께 동작하는 구성도를 볼 수 있습니다.

 

위와 같이 서버리스 컴퓨팅은 자원 효율 측면에서 비용 절감을 가져다 주며 이점을 갖을 수 있지만 항상 좋은 것은 아닙니다.

http://www.itworld.co.kr/news/116481

서버리스 컴퓨팅의 3대 문제점과 해결 방법

위 뉴스를 인용해서 보자면,

---

"콜드 스타트 비용"

서버리스 시스템과 관련하여 자주 언급되는 사안이다. 서버리스 제공업체는 사용률을 최대화하기 위해 비활성 함수를 완전히 종료하는 방법을 택하는 경우가 종종 있다. 부하가 재개될 때 이 함수의 시작 비용이 응답 시간에 영향을 미치게 된다. 하나의 비즈니스 함수가 상호 연결된 다수의 서버리스 함수로 구성되면 이 영향도 누적될 수 있다.

해결법은 많은 사용자가 핑(ping)을 통해 함수가 활성 상태인지 여부를 확인하는 것이다. 체인으로 연결된 서비스 네트워크에서 이 방법을 효과적으로 적용하려면 서비스 간의 엔드 투 엔드 관계를 파악해서 종속성 체인의 모든 서비스가 활성 상태를 유지하도록 해야 한다. 따라서 비즈니스 트랜잭션의 엔드 투 엔드 추적이 필수적이다.
 

"쓰로틀링"

서버리스 플랫폼에서는 서버리스 함수가 실행하는 동시 요청의 수가 계정과 개별 함수, 두 가지 수준에서 모두 제한되는 경우가 많다. 일단 동시 실행 제한에 도달하면 이후의 사용자 요청은 대기열에 추가되고, 이로 인해 응답 시간이 길어진다. 사실상 무제한인 컴퓨팅 리소스 풀을 쓰로틀링한다는 것이 얼핏 납득이 되지 않을 수 있지만, 쓰로틀링은 무제한 비용 청구가 발생하지 않게 해준다. (용량 비용은 소비한 양에 따라 계산된다는 것을 잊지 말아야 한다.)

해결책은 임계값을 높이는 것이다. 또는 최소한 응답 시간 및 동시 사용 측면의 비함수 요구 사항을 충족하도록 임계값을 설정한다. 이번에도 마찬가지로 정확히 무엇이 쓰로틀링되었는지, 최종 사용자 환경에 쓰로틀링이 어떤 영향을 미쳤는지 정확히 파악하기 위해 엔드 투 엔드 가시성이 필요하다.
 

"컴퓨팅과 무관한 병목 현상"

서버리스 환경의 모든 병목을 제거하면, 함수는 동시 요청을 수에 제한없이 지원한다. 그러나 이렇게 해서 문제가 해결됐다고 생각한다면 착각이다. 실상은 문제의 위치가 바뀐 쪽에 가깝다. 조만간 함수는 어디선가 상태를 지속해야 하는 상황에 처하게 된다. 그 지점이 어디인지에 따라 오히려 문제가 더 커질 수도 있다. 얼마 안 가 데이터를 읽거나 쓰려면 기다려야 하고, 무제한으로 확장된 람다는 모두 데이터 액세스를 기다려야 하고, 이러한 비생산적인 대기 시간에도 비용은 청구된다.

함수가 이와 같이 대기하는 정확한 이유는 영구 저장소에 따라 다르다.

- 클라우드 데이터 스토리지 : 클라우드 데이터 서비스의 탄력성은 계속 높아지는 중이지만, 여전히 동시 읽기 및 쓰기 볼륨을 기반으로 리소스를 구성해야 하는 경우가 많다.

- 전통적인 시스템 : 모든 함수가 연결되어 있으며, 서버리스 기업 사용자의 상당수는 서버리스 함수로 기존 시스템을 래핑한다(메인프레임인 경우도 있고, 일반적인 서버 기반 배포인 경우도 있음). 임계값을 높여서 함수 확장을 허용하기는 쉽지만, 이 경우 쉽게 확장할 수 없는 백엔드에 가해지는 부담 역시 폭증하기 쉽다.

백엔드 시스템이 이론상의 최대 부하를 처리할 수 있도록 보장하려면 함수 쓰로틀과 병행해서 백엔드를 튜닝해야 한다. 이렇게 하면 처음부터 끝까지 원활한 시스템 작동을 보장해 불필요한 비용과 고객 불만을 방지할 수 있다. 경우에 따라 여러 시스템이 여러 위치에서 액세스할 수 있도록 데이터를 복제해야 할 수 있다. (물론 이 경우 데이터 관리 복잡성 증가, 데이터에 비일관성이 발생할 위험이라는 비용이 따라온다.)

이번에도 마찬가지로, 트랜잭션 수준에서 시스템을 통과하는 엔드 투 엔드 흐름을 이해하는 것이 중요하다. 그래야 프로덕션의 병목 지점을 파악해 경보를 보내고 튜닝을 위해 시스템을 종합적으로 분석할 수 있기 때문이다.

---

위와 같은 문제점을 인지하고 최적을 퍼포먼스를 낼 수 있는 환경 구성에 대한 아키 검증은 반드시 필요합니다.

 

AWS Step Functions
AWS Step Functions는 Lambda 밖에서 병렬, 연속, 재시도, 다른 케이스로 요청 등을 하기 위해서 워크플로우 형태로 가시화 하는 기능을 제공합니다.
애플리케이션 기능을 단계별로 실행할 수 있으며, 각 단계를 자동으로 트리거 하고 추적하는 기능을 제공합니다.
각 단계가 실패한 경우 간단한 오류를 파악하고 로깅 제공하여 추가적인 Tracing을 수행할 수 있도록 가이드합니다.

 

이번 포스팅에서는 마이크로서비스와 서버리스 컴퓨팅에 대해 살펴보았습니다.

워낙 내용이 방대하고 넓은 범위라 자세한 포스팅은 제 다른 글들을 참고하시기 바랍니다.