서버리스 애플리케이션 구축을 위한 팁 및 리소스

최근 몇 년 동안 서버리스 기술이 빠르게 인기를 얻었지만 여전히 이와 관련된 많은 오해와 두려움이 있습니다. 벤더 종속성, 도구, 비용 관리, 콜드 스타트, 모니터링 및 개발 수명 주기는 서버리스 기술과 관련하여 모두 뜨거운 주제입니다. 이 기사에서는 언급된 주제 중 일부를 살펴보고 초보자가 강력하고 유연하며 비용 효율적인 서버리스 애플리케이션을 만드는 데 도움이 되는 유용한 정보 소스에 대한 팁과 링크를 공유합니다.

서버리스 기술에 대한 오해

많은 사람들이 서버리스 및 서버리스 처리(서비스로서의 기능, FaaS)는 거의 같은 것입니다. 이것은 그 차이가 너무 크지 않고 참신함을 도입할 가치가 있음을 의미합니다. AWS Lambda는 서버리스 전성기의 스타 중 하나이자 서버리스 아키텍처의 가장 인기 있는 요소 중 하나였지만 이 아키텍처는 FaaS 그 이상입니다.

서버리스 기술의 기본 원칙은 인프라 관리 및 확장에 대해 걱정할 필요가 없으며 사용한 만큼만 지불하면 된다는 것입니다. AWS DynamoDB, S3, SNS 또는 SQS, Graphcool, Auth0, Now, Netlify, Firebase 등 많은 서비스가 이러한 기준에 부합합니다. 일반적으로 서버리스는 인프라를 관리하고 확장을 위해 최적화할 필요 없이 클라우드 컴퓨팅의 모든 기능을 사용하는 것을 의미합니다. 이는 또한 인프라 수준의 보안이 더 이상 사용자의 관심사가 아님을 의미하며, 이는 보안 표준 충족의 어려움과 복잡성을 고려할 때 큰 이점입니다. 마지막으로 제공된 인프라를 구입할 필요가 없습니다.

서버리스는 "마음의 상태", 즉 솔루션을 설계할 때의 특정한 사고 방식으로 간주될 수 있습니다. 인프라 유지 관리가 필요한 접근 방식을 피하십시오. 서버리스 접근 방식을 통해 프로젝트에 직접적인 영향을 미치고 사용자에게 이점을 제공하는 작업을 해결하는 데 시간을 할애합니다. 지속 가능한 비즈니스 논리를 생성하고, 사용자 인터페이스를 개발하고, 적응적이고 안정적인 API를 개발합니다.

예를 들어 자유 텍스트 검색 플랫폼을 관리하고 유지하는 것을 피할 수 있다면 그렇게 할 것입니다. 애플리케이션 구축에 대한 이러한 접근 방식은 더 이상 복잡한 인프라 관리에 대해 생각할 필요가 없기 때문에 시장 출시 시간을 크게 단축할 수 있습니다. 인프라 관리의 책임과 비용을 없애고 고객이 필요로 하는 애플리케이션과 서비스 구축에 집중하십시오. Patrick Debois는 이 접근법을 '서비스 풀', 이 용어는 서버리스 커뮤니티에서 채택됩니다. 함수는 (전체 라이브러리 또는 웹 애플리케이션을 배포하는 대신) 배포 가능한 모듈로서 서비스에 대한 링크로 생각해야 합니다. 이것은 애플리케이션에 대한 배포 및 변경 사항을 관리하기 위한 놀라운 세분성을 제공합니다. 이 방법으로 함수를 배포할 수 없는 경우 함수가 너무 많은 작업을 수행하고 리팩터링해야 함을 나타낼 수 있습니다.

일부는 클라우드 애플리케이션을 개발할 때 공급업체에 대한 의존도 때문에 혼란스러워합니다. 서버리스 기술도 마찬가지이며 이는 오해가 아닙니다. 우리의 경험에 따르면 다른 AWS 서비스를 함께 묶는 AWS Lambda의 기능과 결합된 AWS에서 서버리스 애플리케이션을 구축하는 것은 서버리스 아키텍처의 강점 중 일부입니다. 이것은 조합의 결과가 용어의 합 이상일 때 시너지 효과의 좋은 예입니다. 공급업체 종속성을 피하려고 하면 훨씬 더 많은 문제가 발생할 수 있습니다. 컨테이너로 작업할 때 클라우드 공급자 간에 고유한 추상화 계층을 관리하기가 더 쉽습니다. 그러나 서버리스 솔루션의 경우, 특히 처음부터 비용 효율성을 고려한다면 그 노력은 결실을 맺지 못할 것입니다. 벤더가 서비스를 제공하는 방법을 확인하십시오. 일부 특수 서비스는 다른 공급업체와의 통합 지점에 의존하며 즉시 플러그 앤 플레이 연결을 제공할 수 있습니다. 요청을 일부 컨테이너 또는 EC2 인스턴스에 프록시하는 것보다 게이트웨이 API 엔드포인트에서 Lambda 호출을 제공하는 것이 더 쉽습니다. Graphcool은 타사 인증 도구를 사용하는 것보다 쉬운 Auth0으로 손쉬운 구성을 제공합니다.

서버리스 애플리케이션에 적합한 공급업체를 선택하는 것은 아키텍처 결정입니다. 응용 프로그램을 만들 때 언젠가는 서버 관리로 돌아갈 것으로 예상하지 않습니다. 클라우드 공급업체를 선택하는 것은 컨테이너나 데이터베이스 또는 프로그래밍 언어를 사용하는 것과 다르지 않습니다.

고려하다:

• 어떤 서비스가 필요하며 그 이유는 무엇입니까?
• 클라우드 공급자가 제공하는 서비스 및 이를 선택한 FaaS 솔루션과 결합하는 방법.
• 지원되는 프로그래밍 언어(동적 또는 정적 타이핑, 컴파일 또는 해석, 벤치마크, 콜드 스타트 ​​성능, 오픈 소스 생태계 등).
• 보안 요구 사항은 무엇입니까(SLA, 2FA, OAuth, HTTPS, SSL 등).
• CI/CD 및 소프트웨어 개발 주기를 관리하는 방법.
• 어떤 코드형 인프라 솔루션을 활용할 수 있습니까?

기존 애플리케이션을 확장하고 서버리스 기능을 점진적으로 추가하면 사용 가능한 기능이 다소 제한될 수 있습니다. 그러나 거의 모든 서버리스 기술은 애플리케이션 코어와 독립적으로 쉽게 통합할 수 있는 확장을 만들 수 있는 일종의 API(REST 또는 메시지 대기열을 통해)를 제공합니다. 명확한 API, 좋은 문서 및 강력한 커뮤니티가 있는 서비스를 찾으면 잘못될 수 없습니다. 통합의 용이성은 종종 핵심 메트릭이 될 수 있으며 아마도 2015년에 Lambda가 출시된 이후 AWS가 그토록 성공한 주된 이유 중 하나일 것입니다.

서버리스가 좋은 경우

서버리스 기술은 거의 모든 곳에 적용될 수 있습니다. 그러나 이들의 장점은 한 가지 적용 방식에만 국한되지 않습니다. 오늘날 클라우드 컴퓨팅의 진입 장벽은 서버리스 기술 덕분에 매우 낮습니다. 개발자에게 아이디어가 있지만 클라우드 인프라를 관리하고 비용을 최적화하는 방법을 모른다면 이를 수행할 엔지니어를 찾을 필요가 없습니다. 신생 기업이 플랫폼을 구축하고 싶지만 비용이 통제 불능이 될 수 있다는 두려움이 있는 경우 쉽게 서버리스 솔루션으로 전환할 수 있습니다.

비용 절감과 손쉬운 확장으로 인해 서버리스 솔루션은 내부 시스템과 외부 시스템 모두에 동일하게 적용할 수 있으며 수백만 명의 사용자가 있는 웹 애플리케이션까지 적용할 수 있습니다. 계정은 유로가 아니라 센트로 측정됩니다. AWS EC2(t1.micro)의 가장 간단한 인스턴스를 한 달 동안 임대하는 데 아무 작업도 하지 않더라도 €15의 비용이 듭니다(누가 끄는 것을 잊지 않았습니까?!). 이에 비해 동일한 기간 동안 이 수준의 지출에 도달하려면 512MB Lambda를 1초 동안 약 3만 번 실행해야 합니다. 이 기능을 사용하지 않으면 아무 것도 지불하지 않습니다.

서버리스는 주로 이벤트 기반이기 때문에 이전 시스템에 서버리스 인프라를 추가하기가 상당히 쉽습니다. 예를 들어 AWS S3, Lambda 및 Kinesis를 사용하여 API를 통해 데이터를 수신할 수 있는 오래된 소매 시스템에 대한 분석 서비스를 생성할 수 있습니다.

대부분의 서버리스 플랫폼은 여러 언어를 지원합니다. 대부분 Python, JavaScript, C#, Java 및 Go입니다. 일반적으로 모든 언어의 라이브러리 사용에 제한이 없으므로 원하는 오픈 소스 라이브러리를 사용할 수 있습니다. 그러나 함수가 최적으로 수행되고 서버리스 애플리케이션의 엄청난 확장성 이점을 무효화하지 않도록 종속성을 남용하지 않는 것이 좋습니다. 컨테이너에 로드해야 하는 패키지가 많을수록 콜드 스타트 ​​시간이 길어집니다.

콜드 스타트는 컨테이너, 런타임 및 오류 핸들러를 사용하기 전에 먼저 초기화해야 하는 경우입니다. 이로 인해 기능 실행 지연이 최대 3초까지 발생할 수 있으며 이는 참을성 없는 사용자에게는 최선의 선택이 아닙니다. 그러나 몇 분 동안의 유휴 기능 후 첫 번째 호출에서 콜드 스타트가 발생합니다. 그래서 많은 사람들이 이 기능을 정기적으로 핑하여 유휴 상태로 유지함으로써 해결할 수 있는 사소한 성가심이라고 생각합니다. 또는 그들은 이 측면을 완전히 무시합니다.

AWS가 출시되었지만 서버리스 SQL 데이터베이스 서버리스 Aurora그러나 SQL 데이터베이스는 트랜잭션을 수행하기 위해 연결에 의존하기 때문에 이 애플리케이션에 적합하지 않습니다. 이는 AWS Lambda에서 과도한 트래픽으로 빠르게 병목 현상이 될 수 있습니다. 예, 개발자는 지속적으로 Serverless Aurora를 개선하고 있으므로 실험해 보아야 합니다. 하지만 현재 NoSQL 솔루션은 다음과 같습니다. DynamoDB. 그러나이 상황이 곧 바뀔 것이라는 데는 의심의 여지가 없습니다.

이 툴킷은 특히 로컬 테스트 분야에서 많은 제한을 부과합니다. Docker-Lambda, DynamoDB Local 및 LocalStack과 같은 솔루션이 있지만 이러한 솔루션에는 많은 노력과 상당한 양의 구성이 필요합니다. 그러나 이러한 모든 프로젝트는 활발히 개발되고 있으므로 툴킷이 필요한 수준에 도달하는 것은 시간 문제입니다.

서버리스 기술이 개발 주기에 미치는 영향

인프라는 구성일 뿐이므로 셸 스크립트와 같은 스크립트를 사용하여 코드를 정의하고 배포할 수 있습니다. 또는 다음과 같은 코드로 구성 클래스 솔루션에 의지할 수 있습니다. AWS 클라우드 포메이션. 이 서비스가 모든 영역에 대한 구성을 제공하지는 않지만 Lambda 함수로 사용할 특정 리소스를 정의할 수 있습니다. 즉, CloudFormation이 실패한 경우 이 격차를 해소할 자체 리소스(Lambda 함수)를 작성할 수 있습니다. 이렇게 하면 무엇이든 할 수 있으며 AWS 환경 외부에서 종속성을 구성할 수도 있습니다.

모두 구성일 뿐이므로 특히 CloudFormation과 같은 코드형 인프라 솔루션을 사용하는 경우 특정 환경, 지역 및 사용자에 맞게 배포 스크립트를 사용자 지정할 수 있습니다. 예를 들어 리포지토리의 각 분기에 대한 인프라 복사본을 배포하여 개발 중에 완전히 격리된 상태에서 테스트할 수 있습니다. 이것은 코드가 실제 환경에서 적절하게 작동하는지 이해하고자 할 때 개발자를 위한 피드백 속도를 크게 향상시킵니다. 관리자는 실제 사용량에 대해서만 비용을 지불하므로 여러 환경을 배포하는 비용에 대해 걱정할 필요가 없습니다.

DevOps는 개발자가 올바른 구성을 가지고 있는지 확인하기만 하면 되므로 걱정이 덜합니다. 더 이상 인스턴스, 밸런서 또는 보안 그룹을 관리할 필요가 없습니다. 따라서 특히 IAM 구성 및 클라우드 리소스 최적화와 관련하여 인프라를 구성할 수 있는 것이 여전히 중요하지만 NoOps라는 용어가 점점 더 많이 사용됩니다.

Epsagon, Thundra, Dashbird 및 IOPipe와 같은 매우 강력한 모니터링 및 시각화 도구가 있습니다. 이를 통해 서버리스 애플리케이션의 현재 상태를 모니터링하고, 로깅 및 추적을 제공하고, 성능 메트릭 및 아키텍처 병목 현상을 캡처하고, 비용 분석 및 예측을 수행할 수 있습니다. DevOps 엔지니어, 개발자 및 설계자에게 애플리케이션 성능에 대한 포괄적인 보기를 제공할 뿐만 아니라 관리자가 초당 리소스 비용 및 비용 예측을 통해 상황을 실시간으로 모니터링할 수 있습니다. 관리형 인프라로 이를 구성하는 것은 훨씬 더 어렵습니다.

서버리스 애플리케이션 설계는 웹 서버 배포, 가상 머신 또는 컨테이너, 패치 서버, 운영 체제, 인터넷 게이트웨이 등을 관리할 필요가 없기 때문에 훨씬 쉽습니다. 이러한 모든 책임을 추상화함으로써 서버리스 아키텍처는 핵심에 집중할 수 있습니다. 솔루션 비즈니스 및 고객 요구 사항.

툴킷이 더 나을 수 있지만(매일 더 좋아짐) 개발자는 비즈니스 논리를 구현하고 아키텍처 내의 다양한 서비스에 애플리케이션의 복잡성을 가장 잘 분산시키는 데 집중할 수 있습니다. 서버리스 애플리케이션 관리는 이벤트 기반이며 클라우드 공급자에 의해 추상화됩니다(예: SQS, S3 이벤트 또는 DynamoDB 스트림). 따라서 개발자는 특정 이벤트에 응답하는 비즈니스 로직만 작성하면 되며 데이터베이스 및 메시지 대기열을 구현하는 최선의 방법이나 특정 하드웨어 저장소의 데이터를 사용하여 최적의 작업을 구성하는 방법에 대해 걱정할 필요가 없습니다.

모든 개발 프로세스와 마찬가지로 코드를 로컬에서 실행하고 디버깅할 수 있습니다. 단위 테스트는 동일하게 유지됩니다. 맞춤형 스택 구성으로 전체 애플리케이션 인프라를 배포할 수 있는 기능을 통해 개발자는 테스트 비용이나 값비싼 관리 환경에 미치는 영향에 대해 생각하지 않고 중요한 피드백을 신속하게 얻을 수 있습니다.

서버리스 애플리케이션 구축을 위한 도구 및 기술

서버리스 애플리케이션을 구축하는 특정한 방법은 없습니다. 이 작업을 위한 일련의 서비스도 있습니다. AWS는 오늘날 강력한 서버리스 솔루션의 선두주자이지만 Google 클라우드, 시간 и 중포 기지. AWS를 사용하는 경우 애플리케이션 수집에 권장되는 접근 방식은 다음과 같습니다. 서버리스 애플리케이션 모델 (SAM), 특히 C#을 사용하는 경우 Visual Studio에는 훌륭한 도구가 있기 때문입니다. SAM CLI는 Visual Studio에서 수행할 수 있는 모든 작업을 수행할 수 있으므로 다른 IDE 또는 텍스트 편집기로 전환해도 아무 것도 잃지 않습니다. 물론 SAM은 다른 언어에서도 작동합니다.

다른 언어로 작성하는 경우 서버리스 프레임워크는 매우 강력한 YAML 구성 파일로 무엇이든 구성할 수 있는 탁월한 오픈 소스 도구입니다. Serverless Framework도 다양한 클라우드 서비스를 지원하므로 멀티클라우드 솔루션을 찾는 분들께 추천합니다. 필요에 따라 많은 플러그인을 만든 거대한 커뮤니티가 있습니다.

로컬 테스트에는 오픈 소스 도구인 Docker-Lambda, Serverless Local, DynamoDB Local 및 LocalStack이 적합합니다. 서버리스 기술은 이를 위한 도구와 마찬가지로 아직 개발 초기 단계에 있으므로 복잡한 테스트 시나리오를 설정할 때 많은 노력을 기울여야 합니다. 그러나 단순히 환경에 스택을 배포하고 테스트하는 것은 매우 저렴합니다. 그리고 클라우드 환경의 정확한 로컬 복사본을 만들 필요가 없습니다.

AWS Lambda 계층을 사용하여 배포된 패키지의 크기를 줄이고 다운로드 속도를 높이십시오.

특정 작업에 적합한 프로그래밍 언어를 사용하십시오. 다른 언어에는 고유한 장점과 단점이 있습니다. 많은 벤치마크가 있지만 JavaScript, Python 및 C#(.NET Core 2.1+)은 AWS Lambda 성능 측면에서 선두를 달리고 있습니다. AWS Lambda는 최근 Runtime API를 도입하여 원하는 언어와 런타임 환경을 지정할 수 있으므로 실험해 볼 수 있습니다.

배포를 위해 패키지 크기를 작게 유지하십시오. 크기가 작을수록 로드 속도가 빨라집니다. 특히 라이브러리에서 몇 가지 기능을 사용하는 경우 큰 라이브러리를 사용하지 마십시오. JavaScript로 프로그래밍하는 경우 Webpack과 같은 빌드 도구를 사용하여 빌드를 최적화하고 실제로 필요한 항목만 포함하십시오. .NET Core 3.0에는 성능을 개선하고 콜드 스타트에 많은 도움이 되는 QuickJit 및 Tiered Compilation이 있습니다.

이벤트에 대한 서버리스 기능의 의존도는 처음에는 비즈니스 로직을 조정하기 어렵게 만들 수 있습니다. 이와 관련하여 메시지 큐와 상태 시스템은 매우 유용할 수 있습니다. Lambda 함수는 서로를 호출할 수 있지만 응답을 기대하지 않는 경우("실행 후 잊어버림")에만 이 작업을 수행합니다. 다른 함수가 완료될 때까지 대기한 것에 대해 요금이 청구되는 것을 원하지 않습니다. 메시지 큐는 비즈니스 로직의 일부를 분리하고, 애플리케이션 병목 현상을 관리하고, 트랜잭션을 처리(FIFO 큐 사용)하는 데 유용합니다. 나중에 분석하기 위해 실패한 메시지를 추적하는 중단된 메시지 대기열로 AWS Lambda 함수를 SQS 대기열에 할당할 수 있습니다. AWS Step Functions(상태 시스템)는 기능 체인이 필요한 복잡한 프로세스를 관리하는 데 매우 유용합니다. 다른 함수를 호출하는 Lambda 함수 대신 단계 함수는 상태 전환을 조정하고, 함수 간에 데이터를 전달하고, 함수의 전역 상태를 관리할 수 있습니다. 이를 통해 재시도 조건 또는 특정 오류가 발생할 때 수행할 작업을 정의할 수 있습니다. 이는 특정 조건에서 매우 강력한 도구입니다.

결론

최근 몇 년 동안 서버리스 기술은 전례 없는 속도로 발전하고 있습니다. 이 패러다임 전환과 관련된 몇 가지 오해가 있습니다. 인프라를 추상화하고 관리를 확장함으로써 서버리스 솔루션은 단순화된 개발 및 DevOps 프로세스에서 운영 비용의 막대한 절감에 이르기까지 상당한 이점을 제공합니다.
서버리스 접근 방식에 단점이 없는 것은 아니지만 강력한 서버리스 애플리케이션을 구축하거나 서버리스 요소를 기존 아키텍처에 통합하는 데 사용할 수 있는 강력한 디자인 패턴이 있습니다.

출처 : habr.com