마이크로서비스 아키텍처는 두가지 관점으로 접근할 수 있는데 그 첫번째는 바로 API 서비스입니다.
API를 정의하고 이를 독립적인 서비스 환경으로 운영하는 애플리케이션을 마이크로서비스라고 합니다.
이 마이크로서비스(MSA)를 적용하기 위해서는 다양한 허들이 존재하는데 그 중 조직의 변화와 데이터베이스의 분리에 대해 알아보겠습니다.
Step1. DevOps 조직의 변화
"최소한의 MSA를 운영하는 DevOps 조직은 자동화된 CI/CD 환경과 테스트 자동화 환경을 구축해야만 한다."
- 클라우드 파운더리 창시자
Chris Richardson (크리스 리차드슨)
마이크로서비스를 개발하는 개발자, 시스템을 운영하는 운영자, 관리자, SWA, DBA 등등 하나의 프로젝트가 성공적으로 마무리되기 위해서는 다양한 분야의 전문가들의 집합이 필요합니다. 마이크로서비스 아키텍처를 성공적으로 이루기 위해서는 이러한 DevOps들의 집학 즉 조직의 개편이 매우 중요한 요소로 자리잡고 있습니다.
마이크로서비스를 개발하는 주요 이유 중 하나인 Agility 확보 측면에서 봤을 때 조직의 변화는 마이크로서비스 아키텍처를 성공적으로 달성하는 핵심 포인트라고 할 수 있겠습니다.
Step2. 데이터베이스의 분리
마이크로서비스 아키텍처를 구분하는 기준을 선정하는 것은 사실 매우 중요하지만 매우 난해하고 매우 어려운 부분이라고 볼 수 있습니다. 일반적으로 마이크로서비스를 구분하기 위해서는 업무를 정확히 이해하고 있는 현업의 참여가 중요합니다. 업무 이해도 없이 마이크로서비스를 구분할 경우 단순히 목차의 나열이나 소스 패키지명을 그 단위로 결정하는 경우가 많은데 대체로 실패한 프로젝트들의 공통점이라고 볼 수 있습니다. 이 때 데이터베이스의 분리는 마이크로서비스, 즉 애플리케이션을 분리할 수 있는 기준이 될 수 있을 것입니다. 데이터베이스의 분리가 Agility를 향상시킨다는 것은 당연한 이유이기도 합니다.
Serverless
서버리스는 말 그대로 서버를 관리하지 않고 앱과 서비스를 구축하고 실행할 수 있는 환경을 의미합니다.
AWS Lambda의 경우 대표적인 서버리스 컴퓨팅 서비스로 상태 비저장 코드를 실행합니다. 대체로 1회성 용도의 프로그램인 주기적인 Job을 처리하는 Scheduler 역할로 사용하거나 Amazon S3 버킷 또는 DynamoDB 테이블의 데이터 변경 또는 엣지 로케이션의 CDN에서 Lambda 형태로 처리하곤 합니다. 다만 제한사항으로 최대 15분 길이로 지침을 실행할 수 있으며 15분이 넘어가는 서비스는 컨테이너 기반 또는 EC2 기반으로 구성해야 합니다. 서버리스 컴퓨팅을 적용하면 애플리케이션 개발에 몰입할 수 있고 요청 시에만 컴퓨팅 리소스를 사용하여 비용 효율적인 시스템이라고 볼 수 있으며 특히 마이크로서비스 아키텍처와 같이 세분화된 서비스에 보다 적합합니다.
AWS API Gateway는 마이크로서비스를 정의하는 API를 처리하는 핵심 Component로 단일 접점 역할을 담당하여 외부로 엔드포인트 노출을 차단할 수 있습니다. API 서비스의 핵심 답게 다양한 기능을 제공하며 주요 기능은 다음과 같습니다.
- 개발자에게 API 키를 생성하여 배포
- CIDR을 활용하여 API에 대한 액세스 승인
- 프라이빗과 통합, Lambda와 통합 기능 지원
- 엔드포인트 노출 방지 역할
- DDoS 및 명령어 주입 공격으로부터 보호
- API Gateway 캐시 기능 제공
다음은 API Gateway와 Lambda Function을 활용한 아키텍처 예시입니다.
위와 같이 서버리스 컴퓨팅은 자원 효율 측면에서 비용 절감을 가져다 주며 이점을 가질 수 있지만 항상 좋은 것은 아닙니다. 아래와 같은 단점들도 존재합니다.
콜드 스타트 비용
서버리스 시스템과 관련하여 자주 언급되는 사안입니다. 서버리스 제공업체는 사용률을 최대화하기 위해 비활성 함수를 완전히 종료하는 방법을 택하는 경우가 종종 있습니다. 부하가 재개될 때 이 함수의 시작 비용이 응답 시간에 영향을 미치게 되는데 하나의 비즈니스 함수가 상호 연결된 다수의 서버리스 함수로 구성되면 이러한 영향도 누적될 수 있습니다.
해결법은 많은 사용자가 핑(ping)을 통해 함수가 활성 상태인지 여부를 확인하는 것입니다. 체인으로 연결된 서비스 네트워크에서 이 방법을 효과적으로 적용하려면 서비스 간의 엔드 투 엔드 관계를 파악해서 종속성 체인의 모든 서비스가 활성 상태를 유지하도록 해야 합니다. 따라서 비즈니스 트랜잭션의 엔드 투 엔드 추적이 필수적입니다.
쓰로틀링
서버리스 플랫폼에서는 서버리스 함수가 실행하는 동시 요청의 수가 계정과 개별 함수, 두 가지 수준에서 모두 제한되는 경우가 많습니다. 일단 동시 실행 제한에 도달하면 이후의 사용자 요청은 대기열에 추가되고, 이로 인해 응답 시간이 길어집니다. 사실상 무제한인 컴퓨팅 리소스 풀을 쓰로틀링한다는 것이 얼핏 납득이 되지 않을 수 있지만, 쓰로틀링은 무제한 비용 청구가 발생하지 않게 해줍니다. (용량 비용은 소비한 양에 따라 계산된다는 것을 잊지 말아야 한다.)
해결책은 임계값을 높이는 것입니다. 또는 최소한 응답 시간 및 동시 사용 측면의 비함수 요구 사항을 충족하도록 임계값을 설정합니다. 이번에도 마찬가지로 정확히 무엇이 쓰로틀링되었는지, 최종 사용자 환경에 쓰로틀링이 어떤 영향을 미쳤는지 정확히 파악하기 위해 엔드 투 엔드 가시성이 필요합니다.
컴퓨팅과 무관한 병목 현상
서버리스 환경의 모든 병목을 제거하면 함수는 동시 요청을 수에 제한없이 지원한다. 그러나 이렇게 해서 문제가 해결됐다고 생각한다면 착각입니다. 실상은 문제의 위치가 바뀐 쪽에 가깝습니다. 조만간 함수는 어디선가 상태를 지속해야 하는 상황에 처하게 되며 그 지점이 어디인지에 따라 오히려 문제가 더 커질 수도 있습니다 얼마 안 가 데이터를 읽거나 쓰려면 기다려야 하고 무제한으로 확장된 람다는 모두 데이터 액세스를 기다려야 하고 이러한 비생산적인 대기 시간에도 비용은 청구됩니다.
함수가 이와 같이 대기하는 정확한 이유는 영구 저장소에 따라 다릅니다.
클라우드 데이터 스토리지: 클라우드 데이터 서비스의 탄력성은 계속 높아지는 중이지만 여전히 동시 읽기 및 쓰기 볼륨을 기반으로 리소스를 구성해야 하는 경우가 많습니다.
전통적인 시스템: 모든 함수가 연결되어 있으며 서버리스 기업 사용자의 상당수는 서버리스 함수로 기존 시스템을 래핑합니다.(메인프레임인 경우도 있고 일반적인 서버 기반 배포인 경우도 있다.) 임계값을 높여서 함수 확장을 허용하기는 쉽지만 이 경우 쉽게 확장할 수 없는 백엔드에 가해지는 부담 역시 폭증하기 쉽습니다.
이번에도 마찬가지로 트랜잭션 수준에서 시스템을 통과하는 엔드 투 엔드 흐름을 이해하는 것이 중요합니다. 그래야 프로덕션의 병목 지점을 파악해 경보를 보내고 튜닝을 위해 시스템을 종합적으로 분석할 수 있기 때문입니다.
