서버리스 아키텍처(이하 서버리스)는 클라우드 서비스 제공업체가 관리하는 환경에서 애플리케이션을 개발하고 배포하는 방식입니다. 이는 최근 몇 년간 개발자 사이에서 인기를 끌고 있는데요. 서버리스에서는 클라우드 서비스 제공업체가 서버를 관리해 빠른 배포와 유연성을 제공합니다. 이로써 개발자는 애플리케이션을 더 쉽게 개발하고 관리할 수 있죠. 넷플릭스, 스포티파이 등 인기 서비스는 서버리스로 영상 시청, 음악 추천 기능을 향상하기도 합니다.
서버리스에 장점이 많지만 무조건 이를 도입하는 게 능사는 아닌데요. 서버리스를 불필요하게 도입하면 잘못된 설계로 비용이 과다하게 나올 수 있습니다. 따라서 서버리스를 도입하기에 적절한 상황과 그렇지 않은 상황이 있죠. 그렇다면 언제, 어떤 상황에서 서버리스를 도입하면 좋을까요? 서버리스를 도입할 때 무엇을 유의해야 할까요? 이 글에서는 서버리스 개념과 장점, 서버리스가 필요한 상황을 살펴보고요. 서버리스 가치를 최대한 누리도록 이를 도입할 때 유의 사항과 대처 방안을 알아보겠습니다.
서버리스 개념과 장점
서버리스는 클라우드 서비스 제공업체가 관리하는 환경에서 애플리케이션을 개발하고 배포하는 방식입니다. 여기서는 클라우드 서비스 제공업체가 서버 관 리를 담당하며, 인프라의 확장과 유지보수 업무를 자동 처리합니다. 이로써 개발자는 코드 작성에 집중하며, 애플리케이션 개발에 시간을 더 오래 쓸 수 있습니다. 서버리스 서비스에는 AWS Lambda, Azure Functions, Google Cloud Functions 등이 있습니다.
서버리스는 오늘날 웹 개발의 핵심 기술로 떠올랐는데요. ‘개발자의 서버 관리 부담을 줄여 개발에 주력하도록 지원한다’는 점은 매력적이죠. 확장성, 비용 효율성, 고가용성에도 장점이 있고요. 서버리스의 장점을 자세히 살펴보겠습니다.
- 운영 오버헤드 감소: 개발자가 서버를 설정하고, 유지 보수하며, 관리할 필요가 없습니다. 개발자는 인프라에 신경 쓰는 대신 코드를 작성하고, 비즈니스 로직을 개선하는 데 시간을 더 쓸 수 있습니다.
- 확장성: 애플리케이션에 필요한 컴퓨팅 자원이 수요에 따라 자동으로 조정됩니다. 사용자가 많을 때는 자동으로 확장되고, 사용량이 줄었을 때는 축소됩니다. 이 또한 클라우드 서비스 제공업체가 관리합니다.
- 비용 효율성: 실제 사용한 컴퓨팅 자원에만 비용을 매겨서 합리적입니다. 사용하지 않은 서버 유지 비용은 발생하지 않습니다. 이는 앱 사용자가 적은 초기 스타트업이 사용하기에 좋습니다.
- 고가용성: 클라우드 서비스 제공업체는 다중 지역에 자동화된 복제와 장애 조치를 제공해 높은 가용성을 보장합니다. 이는 애플리케이션 내구성과 신뢰성을 향상하며, 예상치 못한 다운타임을 최소화합니다.
서버리스 도입 상황과 주체
서버리스에 장점이 많다고 언제나 이를 도입해야 하는 건 아닙니다. 서버리스를 도입하는 게 바람직한 상황도 있지만 그렇지 않은 상황도 있죠. 아울러 기업 규모나 목표, 애플리케이션에 따라 서버리스가 적합한 곳도 있고, 부적합한 곳도 있습니다. 그렇다면 언제, 누가 서버리스를 도입하는 게 적절할까요? 하나씩 짚어보겠습니다.
언제 도입할까?
- 예상치 못한 트래픽 증가에 대응할 때: 서버리스는 자동으로 확장되고 축소되며, 요구사항에 맞게 컴퓨팅 자원을 할당합니다. 따라서 애플리케이션이 예상치 못한 트래픽 증가에 대응해야 할 때를 대비해 이를 도입하면 좋습니다.
- 단기 프로젝트 또는 실험적 프로젝트를 수행할 때: 서버리스를 도입하면 서버를 미리 구입하거나 관리할 필요가 없습니다. 따라서 단기 프로젝트, 토이 프로젝트를 수행할 때 활용하기에 적합합니다.
- 빨리 개발, 배포할 때: 서버리스는 클라우드 기반 서비스로 인프라를 관리해 개발자가 애플리케이션 로직에 집중하는 데 도움이 됩니다. 평소보다 더 빨리 개발하고 배포해야 할 때 도입하면 좋습니다.
누가 도입할까?
- 스타트업, 중소기업: 리소스가 부족해 서버를 운영하고 관리하기 어려운 스타트업, 중소기업은 서버리스를 도입하면 비용을 절감하고 개발에 집중할 수 있습니다.
- 인프라 관리·유지 보수 효율화하려는 조직: 서버리스를 도입하면 인프라 관리와 유지 보수 시간, 비용을 줄일 수 있으며, 개발 속도를 높일 수 있습니다.
- 대규모 애플리케이션을 운영하는 기업: 대규모 트래픽을 처리해야 하는 기업은 서버리스를 도입하여 확장성과 유연성을 확보할 수 있습니다.
서버리스 도입 시 유의 사항
서버리스를 도입하려면 서버리스 서비스와 기능, 비용 구조, 성능 제약 사항을 알아야 합니다. 이러한 지식 없이 서버리스를 설계하면 비효율적인 리소스 사용, 높은 비용, 성능 문제가 발생할 수 있죠. 아울러 서버리스를 사용할 때 일어날 잠재 이슈를 미리 파악하고 대응 방안도 준비해야 하는데요. 이 글에서는 AWS Lambda를 중심으로 서버리스 도입 시 유의 사항을 살펴보겠습니다.
콜드 스타트
‘콜드 스타트’란 Lambda가 일정 시간 동안 유휴 상태인 다음 호출될 때 생기는 지연입니다. 새로운 Lambda 인스턴스가 생성될 때 콜드 스타트가 발생하는데요. 특히 이는 트래픽이 증가하고, 함수의 새 버전이 배포되거나, 함수가 너무 오랫동안 유휴 상태일 때 생길 수 있습니다. 콜드 스타트는 실시간 처리에 의존하는 애플리케이션 성능에 큰 영향을 미칠 수 있는데요. 실시간 처리를 요구하는 서비스를 운영한다면, 이 문제를 해결해야 합니다.
Lambda는 콜드 스타트를 해결하도록 Provisioned Concurrency를 제공합니다. Provisioned Concurrency를 활성화하면, Lambda가 실제로 동작할 실행 환경을 초기화(Lambda가 바로 실행되도록 준비)하여 호출에 바로 응답하면서 콜드 스타트를 해결할 수 있습니다. Provisioned Concurrency를 활성화할 때는 CloudWatch의 ConcurrentExecutions 지표를 활용해 ‘Lambda가 최대 몇 개의 동시 요청을 처리하는지’ 파악해야 합니다.
ConcurrentExecutions지표. 출처=AWS
예를 들어, 위 그래프처럼 평균 5 ~ 10개의 동시 요청과 최대 20개의 요청을 처리하는 Lambda가 있다고 가정해 봅시다. 이때 Provisioned Concurrency 단위는 20 ~ 22를 구성하는 게 바람직합니다. 그러나 Provisioned Concurrency를 계속 활성화하면 서버리스 장점 중 하나인 ‘사용량에 따른 비용 지급’ 효과가 낮아질 수 있죠. ‘Lambda를 실행하는 인스턴스를 계속 실행’해야 하기 때문입니다.
이 문제를 해결하려면 Application Auto Scaling을 사용하면 됩니다. 그러면 일정이나 사용률을 기준으로 Provisioned Concurrency를 관리할 수 있죠. 이는 비용을 적정 수준으로 통제하는 데 도움이 됩니다. 이때 부하를 예측할 수 있으면, Scheduled scaling으로 ‘특정 시간에 용량을 늘리거나 줄이는 예약된 작업’을 생성합니다. 부하를 예측할 수 없으면, Target tracking scaling policies를 사용하여 지푯값을 기준으로 Autoscaling을 설정하면 됩니다.
높은 비용
서버리스는 모든 함수 호출에 비용을 부과하기에 주의하지 않으면 높은 비용이 발생할 수 있습니다. 심지어 오류를 발생시키는 함수여도 비용이 부과됩니다. 따라서 불필요한 비용이 생기지 않도록 아키텍처를 잘 구성해야 합니다. 특히 비용을 효과적으로 관리하려면 사용량을 면밀히 모니터링해야 하는데요. AWS Cost Explorer 같은 도구를 사용하면 현재 지출 현황을 정확하게 파악하고, 비용을 최적화할 영역을 찾을 수 있습니다.
그러나 아키텍처를 적절하게 구성하고 모니터링해도 고려할 사항이 더 있는데요. ‘서버리스 모델 비용은 일정 수준 이상 사용하면 전통적인 서버 기반 인프라를 사용할 때보다 더 비싸다’는 점입니다. AWS의 서버리스 데이터베이스인 Aurora Serverless를 사용한다고 가정해 봅시다(실제 AWS 비용은 비용 계산기를 사용하거나 고객센터에 문의하는 걸 권장합니다).
위 이미지는 Aurora Serverless 사용 비용을 책정한 ‘AWS 요금 계산기’ 화면인데요. 아시아 태평양(서울) 리전을 선택하고, Aurora Standard(Aurora MySQL 클러스터 구성 옵션), Aurora Serverless v2(Aurora Serverless 버전), 8 ACU(Aurora 용량 단위), 10 Value(데이터베이스 스토리지 크기) 등을 사양으로 각각 설정했습니다. 참고로 Aurora Serverless의 성능 단위인 8 ACU는 메모리 16GB고요. AWS 요금 계산기로 확인해 보니 Aurora Serverless 월 비용이 약 1,170달러(약 158만원)가 나옵니다.
한편, 서버 호스팅 회사의 임대형 서버로 비슷한 사양을 사용하면 어떨까요? 위 이미지는 KOREAIDC에서 상품별로 임대형 서버 호스팅 비용을 정리한 건데요. 16GB~32GB의 메모리가 장착된 서버 호스팅을 사용하면 월 비용은 10만원 내외입니다. Aurora Serverless 월 비용보다 140만원 이상 더 적죠. 이는 메모리를 중심으로 비교한 결과고요. 실제 비용 대비 성능은 CPU 성능과 예상 트래픽 패턴, 데이터베이스의 성능 요구사항, I/O 작업량, 예비 용량, 백업 비용 등을 종합적으로 고 려해야 합니다.
이처럼 서버리스를 지속해서 많이 사용하면 높은 비용이 발생하는데요. 이때 전통적인 서버 기반 인프라를 구축하는 게 비용 절감에 더 유리할 수 있습니다. 물론 관리 포인트는 그만큼 더 늘어날 수 있죠. 서버리스를 합리적인 비용에 사용하고 싶다면 인력 비용, 사용량 등을 고려해 적절한 운영 계획을 짜야 합니다.
또 Lambda에서는 적절한 메모리를 구성하지 않아도 과도한 비용이 들어갈 수 있는데요. 이를 예방하려면 코드가 최대한 효율적으로 실행되도록 Lambda 함수를 최적화하도록 테스트해야 합니다.
벤더 의존성
아키텍처를 특정 클라우드 서비스 제공업체(예: AWS, Azure, GCP 등)의 서버리스 서비스에 맞추면 다른 클라우드 서비스로 이전하기 어렵습니다. 아울러 개발자는 이러한 업체의 서비스 방식과 기능에 맞춰 서버리스를 사용해야 하기에 제약이 있죠. 이러한 종속에서 자유로워지고 싶다면 오픈소스형 FaaS(Function as a Service)를 이용하는 것도 좋습니다. 단, 오픈소스형 FaaS를 사용하면 이를 구축, 관리하는 인력이 필요합니다.
또 ‘제3자 의존성 관리’도 유의해야 하는데요. 제3자 의존성이란 ‘서버리스 서비스에서 사용하는 외부 라이브러리나 서비스에 종속되는 걸’ 의미합니다. 관련 부작용을 줄이려면 제3자 의존성을 최소화해야 하는데요. 응용 프로그램에 꼭 필요한 서비스(예: 인증을 위해 사용하는 인증 서비스 라이브러리 등)만 사용하고요. 정기 검토를 거쳐 ‘이들이 프로젝트에 계속 필요한지’ 평가해야 합니다. 지속적으로 보안을 개선하고, 기능을 향상하도록 꾸준히 업데이트하는 것도 중요하고요.
참고로 제3자 라이브러리를 사용할 때, ‘그들이 함수에 미치는 영향’도 이해해야 합니다. AWS X-Ray를 사용하면 ‘이러한 의존성이 Lambda 서비스 성능에 어떤 영향을 미치는지’ 모니터링할 수 있는데요. AWS X-Ray는 애플리케이션이 처리하는 요청 데이터를 수집하고, 이 데이터를 필터링한 다음, 분석하는 도구를 제공하는 서비스입니다.
모니터링 복잡성
서버리스에서는 모니터링이 더 복잡합니다. 서버리스 환경에서는 애플리케이션을 구성하는 개별 함수들이 독립적으로 실행되고 관리됩니다. 따라서 서버나 인스턴스 레벨에서 모니터링 방식만으로 충분한 정보를 얻기 어렵습니다. 이에 각 함수의 실행 횟수, 실행 시간, 메모리 사용량, 오류율과 같은 메트릭을 세밀하게 관찰해야 하는데요. 여기에는 AWS CloudWatch 같은 모니터링 도구를 사용할 수 있죠.
위 이미지는 CloudWatch를 사용해 특정 Lambda 함수 오류 패턴과 관련해 알림을 받는 과정을 나타냈습니다. 특정 중요 오류와 관련해 알림을 받으려는 Lambda 함수가 여럿 있는데요. CloudWatch Logs는 이러한 Lambda 함수에서 로그를 캡처합니다. 로그 항목이 필터 패턴(ERROR, CRITICAL, 커스텀 오류 등)과 일치하면 “Error parsing Lambda” 함수를 호출합니다. 이 Error parsing Lambda 함수는 오류가 발생할 때 이메일을 받도록 구독할 수 있는 Amazon SNS 토픽에 메시지를 게시합니다.
한편, 서버리스에서는 함수 간 상호작용과 통신도 중요합니다. 한 함수의 출력이 다른 함수의 입력으로 연결될 때가 많은데요. 시스템의 상태와 성능을 모니터링하려면 이러한 상호작용을 추적하고 이해해야 합니다. 앞서 언급한 AWS X-Ray는 상호작용을 시각화하고 분석하도록 지원합니다. 이는 개발자와 운영팀이 시스템을 더 효과적으로 이해하고 문제를 신속하게 해결하는 데 도움이 되고요.
코드, 데이터 보호
서버리스 서비스를 운영하는 클라우드 서비스 제공업체는 코드 실행에 사용하는 인프라의 보안을 담당합니다. 서버, 네트워킹 장비, 데이터 센터 등이 이에 해당하죠. 한편, 서버리스 사용자는 실행되는 코드와 그 코드가 처리하 는 데이터를 보호해야 하는데요. 구체적인 방법은 아래와 같습니다.
- 서비스 권한 관리: 서버리스 서비스가 수행해야 할 작업에 필요한 권한만 갖도록 AWS IAM을 사용하여 각 서버리스 서비스에 역할을 생성하고, 이 역할에 필요한 최소한의 권한을 할당합니다.
- 서비스 접근 관리: AWS IAM을 사용해 사용자, 그룹, 역할을 정의하고, MFA(다중 인증)를 활성화하여 보안을 강화합니다.
- 엔드포인트 보안: 서버리스 서비스가 내부 또는 외부 서비스와 상호작용하여 API Gateway와 같은 서비스를 사용할 때 접근 제어 목록, 리소스 정책, VPC 엔드포인트를 구성하여 엔드포인트 보안을 강화합니다.
Lambda 사용 시 기타 유의 사항
지금까지 AWS Lambda를 중심으로 서버리스 도입 시 유의 사항을 살펴봤는데요. Lambda 자체를 원활히 사용하기 위해 유념해야 할 점도 짚고 가겠습니다.
Lambda 사용 코드 커짐
Lambda에 사용하는 코드가 커지는 상황을 유의해야 합니다. 이 코드가 커지면 Lambda 호출 시간이 길어지고 함수 코드의 유지 관리가 더 복잡해질 수 있는데요. Lambda를 마이크로서비스 방식으로, 최대한 작은 크기의 함수로 구축하는 게 좋습니다.
단, 마이크로서비스 방식으로 Lambda를 사용하여 다른 서비스와 연동할 때도 주의 사항이 있습니다. 바로 서버리스가 아닌 서비스의 의존성을 최소화하고 분리해야 하죠. 이유는 시스템의 확장성이 떨어져 서버리스의 확장성까지 해칠 수 있기 때문입니다.
런타임 연장, 비용 ↑
Lambda를 동기식 워크플로로 구성하면 런타임이 길어지고 비용도 커집니다. 따라서 이를 비동기식 워크플로로 구성하여 처리 과정을 분리하는 걸 권장합니다. 이는 비용 효율성을 높이고 시스템의 유연성을 향상하는 데 도움이 됩니다.
맺음말
지금까지 서버리스 개념과 장 점, 서버리스가 필요한 상황, 서버리스 도입 시 유의 사항과 대처 방안을 알아봤습니다. 서버리스는 개발자가 인프라를 걱정하지 않고 개발 업무에 집중하는 데 도움이 됩니다. 유연성, 확장성, 비용 효율성 등 이점도 있고요.
다만 서버리스는 전통적인 서버 기반 인프라보다 구축하기에 더 까다로울 수도 있습니다. 서버리스 서비스 내 상호 작용을 고려하며 시스템을 설계해야 하니까요. 그러나 클라우드 환경과 서버리스 서비스를 꾸준히 공부하고, 관련 기술 동향을 파악하면 서버리스 도전 과제에 잘 대응할 수 있습니다.
이 글이 서버리스를 효과적으로 이용하는 데 도움이 되기를 바랍니다.
참고 자료
- AWS의 서버리스
- 프로비저닝된 동시성 구성
- Create estimate: Configure Amazon Aurora MySQL-Compatible
- 서버호스팅
- How to get notified on specific Lambda function error patterns using CloudWatch
- Issues to Avoid When Implementing Serverless Architecture with AWS Lambda
- 인스트루먼트 함수 AWS Lambda
- 5 Serverless Challenges of DevOps Teams and How to Overcome Them