2022. 12. 19. 23:23ㆍ아키텍처
개인적으로 임베디드 시스템을 다루면서 '제어보드 생산 -> Bring up -> System Management Setting -> 배포 -> 테스트' 과정을 매번 거쳐보았기에 개발자가 서버로 사용할 인프라 인스턴스를 직접 다룬다는 것이 얼마나 힘들고, 귀찮고, 어려운지 경험한바 있습니다. 이런 것들을 누가 대신 다 제공해준다? 솔직히 아주 솔깃합니다. 특히 서비스에 집중을 해야하거나, infra를 On-Premise로 구축할 필요가 없는 경우 더더욱 그러할 것 같습니다. 최근 AWS 기술 스택을 보면서 서버리스 아키텍처라는 용어가 종종 등장합니다. 개념적으로는 참 오래된 개념이지만, HW 기술이 비약적으로 발전하기 전까지는 각광받지 못한 분야기도 합니다.
Serverless라는 용어때문에 혼동이 많은데, 마틴파울러 블로그의 내용을 인용하면 아래와 같습니다.
Serverless architectures are internet based systems where the application development does not use the usual server process. Instead they rely solely on a combination of third-party services, client-side logic, and service hosted remote procedure calls (FaaS).
Serverless Architectures는 '서드파티 서비스', '클라이언트 로직', 'FaaS라고 불리는 서비스 호스팅 원격 프로시저 호출'의 조합에 의존하는 어플리케이션 개발 아키텍처라고 합니다. 이 중에서 클라이언트 로직만 개발자가 개발을 하고 나머지 인프라관련 서비스들은 서드파티 서비스를 제공하는 회사의 솔루션을 사용한다고 이해하였습니다.
일반적으로 서비스를 제공하는 회사들은 서버 인프라이에 대한 프로비저닝, 유지관리, 스케일링 등 일상적인 작업을 처리합니다. 이러한 서비스는 AWS나 Azure와 같이 상호 운용되는 서비스의 에코시스템이거나 Parse 또는 Firebase와 같은 턴키 기능 집합을 제공하려는 단일 서비스의 형태입니다.
주요 특징
첫번째 Serverless 기반 서비스 특징은 웹 어플리케이션과 인프라 사이에서 발생하는 작업에 대한 관리를 잘 해주어야 합니다. AWS에서 SQS와 Lambda를 사용하여 메일 발송 예제를 동작시켜본 경험이 있습니다. JS로 간단하게 SQS에 메일 발생 내용을 생성하면 Lambda에서 소비하는 형태의 예제였습니다. 이 때 Lambda가 기본적으로 실행 시간이 설정 값을 초과하면 재시작하도록 기본 설정이 잡히는데, 이 부분을 간과해서 계속해서 SQS에서 제대로 가져가지 못한 메시지를 중복해서 발송하는 부분이 있었습니다. 이런 간단한 예제에서도 알 수 있듯, 웹 어플리케이션과 인프라 사이에서 발생하는 작업에 대한 관리는 비즈니스 로직을 정상적으로 구동시키는데 매우 중요합니다.
두번째 특징은 요청-응답 주기 제어입니다. 이는 Serverless 컴퓨팅을 구현하는 FaaS 인프라가 주로 이벤트 기반 실행 모델을 채택하고 있기 때문에 나타나는 특성으로 이해했습니다. 기본적으로 요청이 있으면 일반적으로 템플릿 엔진을 사용하여 동적 응답을 구성하는데, 여러 서비스가 연동되어 있을 경우 이벤트 기반 실행 모델에 따른 처리 시간이 길어지기 때문입니다. 그리고 일부 서비스가 장애가 발생할 경우 해당 내용을 어떻게 처리하는지에 따라서 요청-응답 주기가 달라지게 됩니다.
장단점
장점
- 개발자가 인프라에 대해서 고려해야 될 사항이 줄어듭니다.
- 비용적인 측면에서 인스턴스를 사용한만큼 비용을 지불하는 구조를 가져갈 수 있어 비즈니스에 따라 비용 효율적일 수 있습니다.
- 애플리케이션이 더 쉽게 스케일 아웃이 가능합니다.
단점
- 콜드 스타트 비용을 고려해야됩니다. 이벤트 기반으로 동작하기 때문에 백그라운에서 지속적으로 실행되는 구조가 아니다보니, 요청이 발생 시 그제서야 인스턴스를 띄우면서 그에 대한 처리 시간이 증가하는 부분이 발생합니다. 이를 해결하기 위해서는 서비스간 End to End 관계를 파악해서 종속성 혹은 연관성을 띄고 있는 서비스들은 항상 활성상태가 되어있도록 HB 체크 등을 사용해야 합니다.
- 쓰로틀링을 고려해야 합니다. 보통 서비스 제공사들은 무한한 서비스를 제공하지 않습니다. 즉 무한정 스케일업 혹은 아웃이 되는 구조가 아닙니다. 그러므로 최대 임계치를 넘어서는 순간 나머지 요청은 모두 대기열에 들어가게 되는데, 이것이 응답 시간을 길게 만들고 많은 비용이 발생하는 요인이 될 수 있습니다.
- 결국 인프라가 자동으로 셋업되기는 하지만 서비스에 맞게 튜닝이 필요하게 되므로 이에 대해서도 학습이 필요하고, 조직내에서 이를 관리하는 기술 역량이 요구됩니다.
- 인프라 레벨과 무관한 서비스 로직에서의 병목 현상이 있을 수 있습니다.
마치며
AWS 제품의 사용경험과 Serverless FrameWork를 사용해보면서 찾아본 여러 정보를 취합하여 Serverless에 대해서 간략하게 요약하였습니다. 더 깊이 있고 자세한 정보를 알고 싶다면 Mike Roberts가 쓴 Serverless Architecture에 대한 글을 꼭 한번 읽어보면 좋을 것 같습니다. 저도 영어 공부 겸 기회가 된다면 번역 내용을 블로그에 한번 올려보고 싶습니다.
'아키텍처' 카테고리의 다른 글
| [아키텍처] CQRS 패턴 (0) | 2022.12.20 |
|---|---|
| [아키텍처] 스프링 멀티 모듈 설계 - 헥사고날 아키텍처 (0) | 2022.12.14 |
| Event Driven Architecture - 이벤트 드리븐 아키텍처 (0) | 2022.12.07 |