View a markdown version of this page

가능하고 실현 가능하면 클라우드 네이티브 관리형 서비스 채택 - AWS 권장 가이드

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

가능하고 실현 가능하면 클라우드 네이티브 관리형 서비스 채택

처음에는 클라우드 서비스를 활용하는 방법을 고려할 경우 팀이 익숙한 인프라 서비스 및 개발 도구를 사용하는 것이 최선의 경로로 보일 수 있습니다. 그러나 클라우드 네이티브 관리형 서비스, 특히 서버리스 옵션을 선택하면 비용, 노력 및 복잡성을 크게 줄일 수 있습니다.

클라우드 네이티브 관리형 서비스는 직원의 시간과 노력이 필요한 많은 차별화되지 않은 IT 태스크를 제거하므로 미션 중심 활동에 해당 시간과 노력을 더 잘 소비할 수 있습니다. 또한 제공업체가 서비스의 기능을 개선하면 솔루션은 효율성, 보안, 복원력, 성능 및 기타 특성의 점진적 개선을 자연스럽게 상속합니다. 예를 들어 완전관리형 데이터베이스 서비스는 기능이 풍부한 관계형 데이터베이스 관리 시스템이지만 데이터베이스가 실행되는 기본 서버와 운영 체제를 프로비저닝하고 관리할 필요가 없습니다. 이를 통해 자체 데이터 센터 또는 클라우드에서 프로비저닝하는 자체 관리형 가상 서버에서 관계형 데이터베이스를 유지 관리할 때 일반적으로 필요한 관리 태스크가 제거됩니다. 다음 다이어그램에서는 이 차이를 보여줍니다.

자체 관리형 및 완전관리형 데이터베이스 서비스의 책임 비교

클라우드 네이티브 관리형 서비스를 유사한 자체 관리형 접근 방식과 비교할 경우 인프라 관리 제거의 이점은 명확합니다. 따라서 구매했거나 맞춤 개발한 애플리케이션이 실행하는 구성 요소를 배포해야 할 때마다 클라우드 네이티브 관리형 서비스를 사용하여 시간과 노력을 줄여야 합니다.

팀이 클라우드에서 솔루션을 빌드, 배포 또는 관리할 책임이 있는 경우 클라우드 네이티브 관리형 서비스를 사용하여 클라우드 제공업체의 차별화된 기능과 혁신을 최대한 활용합니다. 이 전략을 사용하면 이러한 프로젝트에 필요한 시간과 노력을 줄이는 동시에 복원력과 보안을 높이는 방식으로 클라우드 서비스를 선택, 통합 및 배포할 수 있습니다. 성공적인 클라우드 전략을 위해서는 사용자 지정 솔루션을 클라우드로 마이그레이션하거나, 클라우드에서 새 솔루션을 개발하거나, 클라우드에 라이선스 소프트웨어를 배포할 때 이러한 클라우드 네이티브 구성 요소를 채택하는 것이 좋습니다. 클라우드 네이티브 관리형 서비스에 대한 옵션을 평가할 경우 다음 주요 질문을 고려합니다.

  • 교육 미션의 핵심인 기능에 직원의 시간과 노력을 더 집중해야 하나요?

    가상 서버라 하더라도 서버를 관리하려면 시스템 소프트웨어 업그레이드 및 패치를 통해 최신 상태를 유지할 수 있도록 시간과 주의가 필요합니다. 이러한 태스크를 처리하는 관리형 서비스를 사용하면 IT 직원이 조직의 미션에 더 직접적으로 부합하는 활동에 시간을 할애할 수 있습니다. 예를 들어 컨테이너를 배포해야 하는 경우 서버를 구성하고 유지 관리할 필요가 없도록 AWS Fargate와 같은 서버리스 관리형 서비스를 고려합니다. 기본 인프라를 조달, 프로비저닝 및 관리할 필요가 없으므로 대신 새로운 기능을 제공하고, 성능을 최적화하며, 사용자 경험을 개선하는 데 집중할 수 있습니다. 자체 관리형 옵션을 기준으로 관리형 서비스를 평가할 경우 이 이점을 고려합니다.

  • 팀이 클라우드 네이티브 관리형 서비스를 채택하는 데 필요한 노력은 무엇인가요?

    클라우드 네이티브 관리형 서비스를 사용하여 솔루션을 설계하고 구현하는 데는 학습 곡선이 발생할 수 있지만, 솔루션 수명 주기 동안 비용, 시간 및 복잡성을 줄어들기 때문에 이러한 노력을 들일 가치가 충분합니다. 클라우드 컴퓨팅의 온디맨드 종량제 특성으로 인해 클라우드 네이티브 서비스를 사용하면 선결제 투자를 피하면서 보다 민첩한 방식으로 빠르게 반복하고 실험할 수 있습니다. 이를 통해 혁신이 증가하고 프로젝트 타임라인이 단축됩니다. 그러나 이러한 이점을 효과적으로 실현하려면 서비스별 API를 수용하기 위해 코드 리팩터링 및 최적의 사용 패턴에 대한 직원 훈련과 같은 서비스를 채택하고 사용하는 데 필요한 요소를 고려합니다. 서비스가 업계 표준 또는 오픈 소스 API를 사용하더라도 기능 차이 또는 버전 불일치를 처리하도록 애플리케이션을 리팩터링하거나 구성해야 할 수 있습니다.

  • 현재 인프라를 어떻게 배포하고 관리하나요? 해당 제어 수준을 유지 관리해야 하나요?

    베어 메탈 호스트, 가상 머신, 관리형 컨테이너 서비스, 서버리스 제품 등 클라우드에서 인프라를 호스팅하고 관리하는 다양한 방법이 있습니다. 현재 온프레미스 환경에서 가상 머신 또는 컨테이너와 같은 유사한 인프라를 사용하고 있더라도 대체 접근 방식이 특정 워크로드에 적합한지 고려합니다. 예를 들어 가상 머신에서 모든 애플리케이션을 실행하는 대신 애플리케이션을 컨테이너화하고 Amazon Elastic Container Service(Amazon ECS)와 같은 관리형 컨테이너 서비스를 활용하는 것이 좋습니다. 이 경우 리팩터링이 필요할 수 있지만 AWS App2Container와 같은 도구를 사용하여 컨테이너화를 단순화하고 지원할 수 있습니다. 이 단계를 한 단계 더 진행하면 모든 구성 요소에 서버 또는 컨테이너를 배포하는 대신 전체 서버리스 옵션을 고려합니다. 서버리스 기술은 자동 규모 조정, 기본 제공 고가용성, 사용량에 따른 결제 모델을 제공하여 민첩성을 높이고 비용을 최적화합니다. 동시에 서버를 관리하고 용량을 계획하지 않아도 됩니다. AWS Lambda와 같은 서버리스 컴퓨팅 서비스는 서버리스 아키텍처의 핵심입니다. Lambda는 일반적인 프로그래밍 언어를 지원하며, 이를 ㅌ오해 개발자는 인프라를 관리하는 대신 애플리케이션 코드에 집중할 수 있습니다. 각 워크로드에 대한 이러한 옵션을 살펴보고 학습 곡선, 관리 오버헤드, 비용 및 라이선스와 같은 요소를 고려합니다.

  • 라이선스가 부여된 소프트웨어의 인프라를 배포하고 관리해야 하나요?

    독립 소프트웨어 개발 판매 회사(ISV)로부터 라이선스가 부여된 소프트웨어를 배포하고 관리하는 경우 클라우드 인프라를 사용한 온프레미스 배포를 모방하는 것이 논리적인 것처럼 보일 수 있습니다. 예를 들어 온프레미스 가상 머신을 클라우드 호스팅 가상 머신으로 대체하는 방법을 고려할 수 있습니다. 이는 실행 가능한 옵션이지만 아키텍처의 구성 요소를 클라우드 네이티브 관리형 서비스로 바꿀 수 있는지 여부를 고려합니다. 예를 들어 동일한 데이터베이스 엔진을 실행하는 동안 관리 부담을 줄이는 완전관리형 데이터베이스 서비스로 자체 관리형 데이터베이스 서버를 교체할 수 있습니다. 많은 ISV에서 이미 관리형 서비스를 활용하는 클라우드 아키텍처를 사용하고 있으며 배포를 단순화하기 위해 사전 빌드된 템플릿을 제공할 수도 있습니다. 가능하면 클라우드 배포에 대한 규범적 지침과 지원을 제공하는 ISV를 우선해야 합니다. 클라우드에 라이선스가 부여된 소프트웨어를 배포하기 전에 ISV에 문의하여 클라우드 환경 라이선스가 온프레미스 라이선스와 어떻게 다를 수 있는지 파악해야 합니다.

  • 관리형 서비스를 사용하면 벤더 종속이 발생할 수 있다는 점이 우려되나요?

    많은 클라우드 네이티브 관리형 서비스가 일반적인 업계 표준 및 API를 지원하도록 빌드됩니다. 예를 들어 AWS Glue 및 Amazon EMR과 같은 분석 서비스는 Apache Spark 및 Apache Parquet와 같은 업계 표준 처리 및 스토리지 프레임워크를 기반으로 빌드됩니다. AWS Lambda는 기본적으로 Java, Go, Microsoft PowerShell, Node.js, C#, Python 및 Ruby 코드를 지원합니다. Amazon Relational Database Service(Amazon RDS)는 SQL Server, Oracle, PostgreSQL, MySQL 등 여러 버전의 공통 데이터베이스 엔진을 지원합니다. 서비스에 독점 API가 있는 경우 클라우드에 구애받지 않는 공통 프로토콜을 사용하여 네이티브 또는 파트너 솔루션을 통해 API와 상호 작용할 수 있습니다. 예를 들어 Amazon Simple Storage Service(Amazon S3)에는 직접 통합을 위한 서비스별 API가 있지만 AWS Storage Gateway를 사용할 때 Network File System(NFS), Server Message Block(SMB), Internet Small Computer Systems Interface(iSCSI)와 같은 표준 스토리지 프로토콜을 사용하여 상호 작용할 수도 있습니다. 운영 오버헤드를 최대한 줄이면서 요구 사항을 가장 잘 충족하는 클라우드 네이티브 관리형 서비스를 선택하는 데 계속 집중해야 하지만 일반적인 사용 가능한 업계 표준 및 프로토콜을 만들거나 사용하는 서비스를 선호할 수 있습니다.