AWS 서버리스로 제로부터 스케일까지

최근 몇 년 동안 클라우드 네이티브 애플리케이션이 많은 기업들이 확장 가능한 애플리케이션을 구축하는 데 사용하는 표준이 되었습니다. 클라우드 기술의 여러 발전 중에서도 서버리스 아키텍처는 혁신적인 접근 방식으로 빛을 발합니다. 현대 애플리케이션 개발에 가장 바람직한 특성은 사용 편의성과 효율성이며, 서버리스 아키텍처는 이를 제공합니다. 이로써 서버리스는 클라우드 제공업체와 소비자 모두에게 게임 체인저가 되었습니다.

이 접근 방식으로 애플리케이션을 구축하려는 기업들을 위해 주요 클라우드 제공업체는 여러 서버리스 솔루션을 제공합니다. 본 글에서는 이 아키텍처의 특징, 이점, 도전 과제와 사용 사례를 탐색하겠습니다. 본 글에서는 개념을 탐구하기 위해 AWS를 예시로 들었지만, 동일한 개념은 모든 주요 클라우드 제공업체에 적용됩니다.

서버리스

서버리스는 서버가 없다는 것을 의미하지 않습니다. 단지 해당 서비스의 기반이 클라우드 제공업체에 의해 관리된다는 것을 의미합니다. 이로써 설계자와 개발자들은 인프라 관리에 대해 걱정하지 않고 애플리케이션을 설계하고 구축할 수 있습니다. 이는 타슈 서비스인 우버를 사용하는 것과 유사합니다: 타슈가 필요할 때 차를 소유하거나 유지할 필요가 없습니다. 우버가 그 모든 것을 처리하고 당신은 타슈를 이용해 목적지에 도착하는 데 집중할 수 있습니다.

서버리스 아키텍처는 많은 이점을 제공하여 많은 사용 사례에 적합하고 매력적으로 만듭니다. 여기에 일부 주요 장점이 있습니다:

자동 스케일링

서버리스 아키텍처의 가장 큰 장점 중 하나는 본질적으로 스케일링을 지원한다는 것입니다. 클라우드 제공업체가 무거운 작업을 처리하여 거의 무한한, 즉시 확장 가능성을 제공합니다. 예를 들어, 서버리스 기술을 사용하여 구축된 앱이 갑자기 인기를 얻는다면, 도구나 서비스가 자동으로 앱의 요구 사항을 충족하기 위해 확장됩니다. 우리는 밤중에 서버나 다른 리소스를 추가해야 하는 일이 없습니다.

혁신에 집중

서버를 관리하는 부담에서 해방되었기 때문에 애플리케이션을 구축하고 앱의 성장을 위한 기능을 추가하는 데 집중할 수 있습니다. 어떤 조직이든 작은, 중소 또는 대규모인 경우에도 이 접근 방식은 진정으로 중요한 사항에 집중하여 비즈니스 성장을 돕습니다.

비용 효율성

전통적인 서버 모델의 경우 미사용 리소스에 대한 비용을 종종 지불하게 되어 미리 구매되고 사용되지 않을 때도 관리됩니다. 서버리스는 사용량에 따라 지불하는 모델로 전환함으로써 이를 변경합니다. 대부분의 경우, 실제로 사용하는 리소스에 대해서만 지불하게 됩니다. 만약 구축한 앱이 즉시 성과를 내지 않는다면, 비용은 최소화되어 연간 전체를 대신한 단일 세션에 대한 비용만 지불하게 됩니다. 앱의 트래픽이 증가함에 따라 비용도 증가할 것입니다.

시장 진입 속도 향상

서버리스 프레임워크를 사용하면 전통적인 서버 모델보다 훨씬 빠르게 애플리케이션을 구축하고 배포할 수 있습니다. 앱이 준비되면 서버리스 리소스를 사용하여 최소한의 노력으로 배포할 수 있습니다. 서버 관리에 시간을 쓰는 대신 개발과 새로운 기능 추가에 집중하여 더 빠른 속도로 제품을 출시할 수 있습니다.

운영 유지 관리 감소

클라우드 제공 업체가 인프라를 관리하기 때문에 사용자는 프로비저닝, 유지 관리, 확장 또는 보안 패치 및 취약점 처리에 대해 걱정할 필요가 없습니다.

서버리스 프레임워크는 유연성을 제공하며 다양한 사용 사례에 적용할 수 있습니다. 웹 애플리케이션을 구축하거나 실시간 데이터를 처리하는 경우, 이러한 사용 사례에 필요한 확장성과 효율성을 제공합니다.

AWS 서버리스를 사용하여 웹 서비스 API 구축하기

이제 서버리스 아키텍처의 이점에 대해 논의했으니, 실용적인 예제를 살펴보겠습니다. 이 섹션에서는 AWS 서버리스 리소스를 사용하여 간단한 백엔드 웹 애플리케이션을 만들 것입니다.AWS 서버리스 리소스를 사용합니다.

위의 백엔드 애플리케이션 설계에는 웹 애플리케이션을 위한 API를 제공하기 위한 세 개의 계층이 포함되어 있습니다. AWS에 배포된 후 API를 통해 소비할 수 있는 게이트웨이 엔드포인트가 제공됩니다. 사용자가 API를 호출하면 요청이 API 게이트웨이를 통해 적절한 람다 함수로 라우팅됩니다. 각 API 요청마다 람다 함수가 트리거되어 DynamoDB에 데이터를 저장하고 검색합니다. 이 설계는 수요가 증가함에 따라 자동으로 확장되는 비용 효율적인 솔루션으로, 최소한의 오버헤드로 API를 구축하기에 이상적인 선택입니다. 이 설계의 구성 요소는 서로 원활하게 통합되어 유연성을 제공합니다.

이 아키텍처에는 컴퓨팅과 저장소 두 가지 주요 구성 요소가 있습니다.

서버리스 컴퓨팅

서버리스 컴퓨팅은 클라우드 네이티브 애플리케이션과 서비스의 구축 및 배포 방식을 변화시켰습니다. 이는 자원을 낭비하지 않으면서 밀리초 수준의 세분화된 실제 사용량 기반 모델을 약속합니다. 단순성과 경제적 이점 덕분에 이 접근 방식은 인기를 얻었으며, 많은 클라우드 제공업체들이 이러한 기능을 지원합니다.

서버리스 컴퓨팅을 사용하는 가장 간단한 방법은 플랫폼에서 필요에 따라 실행할 코드를 제공하는 것입니다. 이 접근 방식은 제한된 시간 동안 함수로 표현된 작은 코드 조각을 실행할 수 있도록 하는 Function-as-a-service (FaaS) 플랫폼의 출현으로 이어졌습니다. 이러한 함수는 HTTP 요청, 스토리지 변경, 메시지 또는 알림과 같은 이벤트에 의해 트리거됩니다. 코드 실행이 완료되면 함수가 호출되고 중지되므로 지속적인 상태를 유지하지 않습니다. 상태를 유지하거나 데이터를 지속적으로 저장하기 위해 DynamoDB와 같은 내구성 있는 저장 기능을 제공하는 서비스를 사용합니다.

AWS Lambda는 수요에 따라 확장할 수 있습니다. 예를 들어, AWS Lambda는 2024년 프라임 데이 동안  1.3 조 건 이상의 호출을 처리했습니다. 이러한 기능은 갑작스러운 트래픽 증가를 처리하는 데 매우 중요합니다.

서버리스 스토리지

서버리스 컴퓨팅 생태계에서 서버리스 스토리지는 소비자가 인프라를 관리할 필요 없이 자동으로 확장되는 클라우드 기반 스토리지 솔루션을 말합니다. 이러한 서비스는 온디맨드 확장성, 높은 가용성 및 사용량에 따른 요금 지불 등 다양한 기능을 제공합니다. 예를 들어, DynamoDB는 키-값 및 문서 데이터 모델을 처리하기 위해 설계된 완전 관리형 서버리스 NoSQL 데이터베이스입니다. 이는 일관된 성능을 요구하는 애플리케이션을 위해 특별히 구축되어 있으며, 단일 밀리초 대기 시간을 제공합니다. 또한 많은 다른 서비스와의 원활한 통합 기능을 제공합니다.

주요 클라우드 제공업체는 S3, ElastiCache, Aurora 등 특정 요구 사항에 맞는 수많은 서버리스 스토리지 옵션을 제공합니다.

다른 사용 사례

이전 섹션에서는 웹 애플리케이션을 위한 백엔드 API를 구축하기 위해 서버리스 아키텍처를 활용하는 방법에 대해 논의했습니다. 서버리스 아키텍처의 혜택을 받을 수 있는 여러 다른 사용 사례가 있습니다. 이러한 사용 사례 중 일부는 다음과 같습니다:

데이터 처리

서버리스 아키텍처를 사용하여 데이터 저장소의 데이터 변경에 따라 서비스를 알리는 또 다른 예를 살펴보겠습니다. 예를 들어, 전자상거래 플랫폼에서 주문이 생성되면 여러 서비스에 알림이 필요하다고 가정해 보겠습니다. AWS 생태계 내에서, 주문은 생성 시 DynamoDB에 저장될 수 있습니다. 다른 서비스에 알리기 위해 이 저장 이벤트를 기반으로 여러 이벤트가 트리거될 수 있습니다.

DynamoDB Streams를 사용하여 Lambda 함수가 해당 이벤트가 발생할 때 호출될 수 있습니다. 그런 다음 이 람다 함수는 변경 이벤트를 SNS(Simple Notification Service)로 푸시할 수 있습니다. SNS는 이러한 이벤트에 관심이 있는 여러 다른 서비스에 알림을 제공하는 알림 서비스 역할을 합니다.

실시간 파일 처리

많은 응용 프로그램에서 사용자는 저장되어야 할 이미지를 업로드하고, 크기 조정을 위해 처리하고, 다른 형식으로 변환하고, 분석해야 하는 이미지를 업로드합니다. 우리는 AWS 서버리스 아키텍처를 사용하여 다음과 같은 방식으로 이 기능을 달성할 수 있습니다. 이미지가 업로드되면 해당 이미지가 Lambda 함수를 호출할 이벤트를 트리거하도록 구성된 S3 버킷으로 푸시됩니다. Lambda 함수는 이미지를 처리하고, DynamoDB에 메타데이터를 저장하고, 크기가 조정된 이미지를 다른 S3 버킷에 저장할 수 있습니다. 이 확장 가능한 아키텍처는 수백만 개의 이미지를 처리하는 데 사용될 수 있으며, 인프라를 관리하거나 수동 개입을 필요로하지 않습니다.

도전과제

서버리스 아키텍처는 많은 이점을 제공하지만, 해결해야 할 특정 도전 과제도 함께 가져옵니다.

콜드 스타트

서버리스 함수가 호출되면, 플랫폼은 코드를 실행하기 위해 새 컨테이너를 만들고 초기화하고 실행해야 합니다. 이 과정은 콜드 스타트라고 불리며 워크플로우에 추가적인 지연을 초래할 수 있습니다. 함수를 따뜻하게 유지하거나 프로비저닝된 동시성을 사용하는 등의 기술을 활용하여 이 지연을 줄일 수 있습니다.

모니터링 및 디버깅

다수의 호출이 발생할 수 있기 때문에 모니터링과 디버깅은 복잡해질 수 있습니다. 많이 사용되는 애플리케이션에서 문제를 식별하고 디버깅하는 것은 도전적일 수 있습니다. 메트릭, 로그 및 경고를 위해 AWS 클라우드워치와 같은 도구를 구성하는 것이 이러한 문제에 대처하기에 매우 권장됩니다.

서버리스 아키텍처는 자동으로 확장되지만, 리소스 구성은 병목 현상을 방지하기 위해 최적화되어야 합니다. 적절한 리소스 할당 및 비용 최적화 전략의 구현이 필수적입니다.

결론

서버리스 아키텍처는 서버리스 컴퓨팅과 스토리지를 바탕으로 하는 클라우드 네이티브 애플리케이션 개발로 나아가는 중요한 한 걸음입니다. 서버리스 아키텍처는 이벤트 기반 워크플로, 데이터 처리, 파일 처리, 대규모 데이터 분석 등 다양한 종류의 애플리케이션에서 많이 사용됩니다. 확장성, 민첩성, 높은 가용성 덕분에 서버리스 아키텍처는 모든 규모의 비즈니스에 신뢰할만한 선택지로 자리 잡았습니다.