Serverless 또는 Kubernetes on AWS

많은 AWS 고객이 폭넓게 지원되는 오픈 소스 기술을 기반으로 표준화합니다. 오픈 소스를 통해 조직은 적절한 기술을 찾고 종속에 따른 위험을 피할 수 있습니다. 오픈 소스 에코시스템에서 잘못된 선택을 하면 추상화와 자체 개발된 통합에 갇힐 수 있습니다. 또한 다양한 오픈 소스 구성 요소가 함께 작동하도록 만드는 책임은 선택한 조직에게 있기도 합니다. 조직에서 오픈 소스 통합을 유지하는 데 너무 많은 시간을 소비하는 것은 흔한 일입니다.

참고:

• 이러한 투자를 할 때는 커뮤니티 출처와 기업 또는 재단의 지원을 고려하세요. 이러한 프로젝트에 대한 투자는 단순히 금전적인 것이 아닙니다. 또한 사용되는 기술에 대한 팀 교육 및 교육에도 투자해야 합니다. 
• 이러한 구성 요소 및 관련 통합에는 일반적으로 업데이트가 필요하기 때문에 이러한 통합 유지 관리 작업으로 인해 기술적인 문제가 발생할 수도 있습니다.
  
• 오픈 소스 구현에 대한 아이디어가 필요하면 AWS 오픈 소스 블로그를 방문하세요.
  

최신 앱 개발 전략을 선택할 때 전략이 다양한 워크로드 패턴을 수용하는 것이 중요합니다. 워크로드 패턴을 이해하면 아키텍처를 더 쉽게 선택할 수 있습니다. 예를 들어 웹 애플리케이션, API 기반 마이크로서비스, 이벤트 기반 애플리케이션, 스트리밍 및 메시징, 데이터 파이프라인, IT 자동화 등이 있습니다. 일부 워크로드는 특정 컴퓨팅 환경에서 다른 유형보다 성능이 더 우수하거나 비용 효율적입니다.

AWS Serverless로 구축할 때 App Runner 및 AWS Batch와 같은 서비스는 주어진 워크로드 유형의 요구 사항을 즉시 지원하도록 설계되었습니다. 이 접근 방식을 사용하는 워크로드는 유연성이 떨어지기는 하지만 구축이 더 쉽고 성능이 향상되거나 비용 효율성이 높아집니다.

Kubernetes는 조직에 필요한 경우 클라우드 및 온프레미스 환경 전반에서 일관성을 제공합니다.

워크로드는 고립되어 있지 않습니다. 워크로드는 데이터베이스, 메시징, 스트리밍, 오케스트레이션 및 기타 서비스와 같은 기술을 통해 지원됩니다. 효과적인 최신 앱 개발 전략을 위해서는 이러한 서비스와의 통합이 필요합니다. 관리형 통합은 기본 인프라 관리만큼이나 운영 오버헤드를 단순화합니다.

AWS Serverless 옵션은 AWS 에코시스템에 긴밀하게 통합되어 있습니다. AWS Lambda는 200개 이상의 다른 서비스에서 이벤트를 구독할 수 있습니다. 예를 들어 AWS Lambda 확장 기능을 사용하면 모니터링, 관찰성, 보안 및 거버넌스 도구와 통합할 수 있습니다. Lambda는 실행 환경에서 지정된 함수를 호출하여 함수 코드가 실행되는 안전하고 격리된 런타임을 제공합니다. 

Kubernetes용 AWS 관리 제품은 관리 제품과 통합됩니다. Kubernetes 자체는 다양한 파트너 에코시스템을 보유하고 있으며, 수많은 다른 기술과의 통합을 제공합니다.

많은 고객이 아이디어를 검증하기 위해 실험을 생성해야 합니다. 이러한 프로토타입은 새로운 애플리케이션을 위한 아이디어일 수도 있고, 실패할 경우 버려질 수도 있습니다. 아이디어를 신속하게 작성, 배포 및 검증할 수 있는 환경을 제공하는 기능은 건강한 환경에 필수적입니다. 이러한 환경은 최신 앱 개발 전략을 개발할 때 간과되는 경우가 많지만 회사 내 혁신 역량이 이에 따라 달라질 수 있습니다. 팀이 신속하게 구축, 테스트 및 반복하는 데 사용할 수 있는 서비스를 사용할 수 있도록 하는 것은 새로운 비즈니스 기회를 발견하는 데 매우 중요합니다.

많은 고객이 애플리케이션을 다른 환경에서 실행할 수 있고 쉽게 마이그레이션하거나 이전할 수 있기를 원합니다. 이들은 클라우드 공급업체를 이전하거나 온프레미스와 클라우드 모두에서 애플리케이션을 실행할 수 있는 선택권을 유지할 수 있기를 원합니다. 여기에는 널리 사용되는 언어 프레임워크 및 개발 시나리오를 지원해야 하는 필요성이 포함되는 경우가 많습니다. 예를 들어 Java 개발자는 Spring 또는 Python을 사용하고 데이터 엔지니어는 PyTorch를 사용하기를 원할 수 있습니다. 최신 개발 앱 접근 방식을 선택하는 것만으로는 충분하지 않습니다. 애플리케이션 이식성을 달성하려면 모범 사례와 아키텍처가 필요합니다. 소프트웨어 아키텍처에서 역량을 구축하고 컴퓨팅 서비스 간에 차별화된 비즈니스 로직을 보다 쉽게 이식할 수 있는 패키징을 구축하는 것이 좋습니다.

일부 기술을 사용하여 구축된 애플리케이션은 일부 컴퓨팅 서비스에서 다른 기술보다 더 효과적으로 실행될 수 있습니다. 일반적으로 컨테이너 서비스는 아키텍처 변경이 필요한 Lambda보다 레거시 애플리케이션에 더 적합한 마이그레이션 대상입니다.

애플리케이션과 자동화 이식성 간에는 분명한 차이가 있어야 합니다. 대부분의 경우 AWS Serverless 또는 AWS Kubernetes 중에서 선택하는 것은 실제로 애플리케이션의 이식 가능 여부와 거의 관련이 없습니다. 대신 인프라 팀과 DevOps 팀이 사용하는 도구가 핵심 요소입니다. AWS에서 Kubernetes 접근 방식을 선택하는 고객은 인프라 및 배포 도구의 이식성을 찾는 경우가 많습니다.

최신 앱 개발에 서버리스 또는 컨테이너 기반 접근 방식을 취할지 결정할 때 조직의 기술은 주요 요소입니다. 서버리스와 컨테이너 모두 DevOps 및 사이트 신뢰성 엔지니어(SRE) 팀에 어느 정도 투자해야 합니다. 애플리케이션을 배포하기 위한 자동화된 파이프라인을 구축하는 것은 대부분의 최신 애플리케이션에서 흔히 볼 수 있습니다.

일부 선택은 관리 수준을 높입니다. 예를 들어, 일부 조직은 Kubernetes 클러스터를 관리하기 위해 강력한 SRE 팀에 투자하기 때문에 Kubernetes 구현을 실행하고 관리할 수 있는 기술과 리소스를 보유하고 있습니다. 이러한 팀은 잦은 클러스터 업그레이드를 처리합니다(예: Kubernetes는 매년 세 번의 주요 릴리스를 제공하며 이전 버전은 더 이상 사용되지 않음).

소규모 스타트업은 여러 역할을 수행하는 인력으로 구성된 소규모 IT 직원을 보유할 수 있는 반면 대기업은 수백 개의 프로덕션 워크로드를 한 번에 지원할 수 있으므로 조직 규모가 핵심 요소입니다.

아키텍처 결정에는 상충되는 부분이 따르는데, 그 중 하나는 종종 비용입니다. 관련 구성 요소의 동적 특성으로 인해 최신 애플리케이션의 비용을 추정하는 데 어려움을 겪는 것이 일반적입니다. 고정된 서버 세트의 비용은 예측하기가 더 쉽지만 비즈니스 가치를 추가하지 않는 경우에도 해당 서버에 대한 비용을 지불해야 합니다.

두 접근 방식 모두 워크로드의 비용 목표를 충족할 수 있는 다양한 수단을 제공합니다. 높은 수준의 접근 방식을 선택할 때는 리소스뿐만 아니라 해당 전략을 수립하고 유지하는 데 드는 노력도 고려해야 합니다. AWS 요금 계산기는 특정 워크로드의 비용을 이해하는 데 유용할 수 있습니다.

AWS Serverless 및 Kubernetes on AWS를 모두 사용하여 구축하면 성능이 뛰어나고 확장 가능하며 탄력적인 워크로드를 구축할 수 있습니다. 필요한 기술 요구 사항을 충족할 수 있습니다. 최고 수준의 추상화를 갖춘 서비스는 AWS 가용 영역 전반의 배치와 환경 확장을 관리하여 성능과 복원력을 개선합니다. 추상화 수준이 낮을수록 워크로드 확장 방식을 더 잘 제어할 수 있습니다. 상충되는 주요한 부분은 비용과 관리 복잡성입니다.