컴퓨팅 아키텍처 선택 - 성능 효율성 원칙

컴퓨팅 아키텍처 선택

특정 워크로드에 대한 최적의 컴퓨팅 선택은 애플리케이션 설계, 사용량 패턴 및 구성 설정에 따라 다를 수 있습니다. 아키텍처는 다양한 컴포넌트에 대해 서로 다른 컴퓨팅 옵션을 사용하고 다양한 기능을 활성화하여 성능을 개선할 수 있습니다. 아키텍처에 대해 잘못된 컴퓨팅 옵션을 선택하면 성능 효율성 저하로 이어질 수 있습니다.

사용 가능한 컴퓨팅 옵션 평가: 사용 가능한 컴퓨팅 관련 옵션의 성능 특성을 파악합니다. 인스턴스, 컨테이너 및 함수의 작동 방식과 이러한 컴퓨팅 기능이 워크로드에 제공하는 장단점을 확인합니다.

AWS에서는 세 가지 형식의 컴퓨팅 기능(인스턴스, 컨테이너, 함수)이 제공됩니다.

인스턴스

인스턴스는 가상화된 서버이기 때문에 버튼을 누르거나 API를 호출하는 방법으로 기능을 변경할 수 있습니다. 클라우드에서는 리소스를 한번 결정하면 그대로 고정되는 것이 아니므로 다양한 서버 유형을 시험해 볼 수 있습니다. AWS에서는 이러한 가상 서버 인스턴스를 다양한 제품군과 크기로 제공하며 SSD(Solid-State Drive)와 GPU(그래픽 처리 장치)를 비롯한 매우 다양한 기능을 제공합니다.

Amazon Elastic Compute Cloud(Amazon EC2) 가상 서버 인스턴스는 다양한 패밀리와 크기로 제공됩니다. 이러한 인스턴스는 SSD(Solid-State Drive) 및 GPU(그래픽 처리 장치)를 비롯하여 다양한 기능을 제공합니다. EC2 인스턴스를 시작할 때 지정하는 인스턴스 유형에 따라 인스턴스에 사용되는 호스트 컴퓨터의 하드웨어가 결정됩니다. 각 인스턴스 유형은 서로 다른 컴퓨팅, 메모리 및 스토리지 기능을 제공합니다. 인스턴스 유형은 이러한 기능에 따라 인스턴스 패밀리로 그룹화됩니다.

데이터를 사용해 워크로드에 가장 적합한 EC2 인스턴스 유형을 선택해야 하고, 네트워킹 및 스토리지 옵션이 정확한지 확인해야 하며, 워크로드 성능을 개선할 수 있는 운영 체제 설정을 고려해야 합니다.

컨테이너

컨테이너는 애플리케이션 및 종속성을 리소스가 격리된 프로세스에서 실행할 수 있는 운영 체제 가상화 방식입니다.

AWS에서 컨테이너를 실행할 때는 두 가지를 선택할 수 있습니다. 첫째, 서버를 관리할지 여부를 선택합니다. AWS Fargate 는 컨테이너용 서버리스 컴퓨팅입니다. 컴퓨팅 환경의 설치, 구성 및 관리를 제어해야 한다면 Amazon EC2를 사용할 수 있습니다. 둘째, 사용할 컨테이너 오케스트레이터를 선택합니다. Amazon Elastic Container Service(ECS) 또는 Amazon Elastic Kubernetes Service(EKS)를 선택할 수 있습니다.

Amazon Elastic Container Service(Amazon ECS) 는 AWS Fargate를 사용하여 EC2 인스턴스 또는 서버리스 인스턴스의 클러스터에서 컨테이너를 자동으로 실행하고 관리할 수 있는 완전관리형 컨테이너 오케스트레이션 서비스입니다. Amazon ECS는 Amazon Route 53, Secrets Manager, AWS Identity and Access Management(IAM) 및 Amazon CloudWatch와 같은 다른 서비스와 기본적으로 통합됩니다.

Amazon Elastic Kubernetes Service(Amazon EKS) 는 완전관리형 Kubernetes 서비스입니다. AWS Fargate를 사용하여 EKS 클러스터를 실행하도록 선택하면 서버 프로비저닝 및 관리할 필요가 없습니다. EKS는 Amazon CloudWatch, Auto Scaling Groups, AWS Identity and Access Management(IAM) 및 Amazon Virtual Private Cloud(VPC)와 같은 서비스와 긴밀하게 통합됩니다.

컨테이너 사용 시에는 데이터를 사용하여 EC2 또는 AWS Fargate 인스턴스 유형을 선택하는 것처럼 데이터에 따라 워크로드에 적절한 타입을 선택해야 합니다. 메모리, CPU, 테넌시 구성 등의 컨테이너 구성 옵션도 고려해야 합니다. 컨테이너 서비스 간 네트워크 접근을 활성화하려면 서비스 통신 방식을 표준화하는 AWS App Mesh와 같은 서비스 메시를 사용하는 것이 좋습니다. 서비스 메시는 종합적인 가시성을 제공하고 애플리케이션의 고가용성을 보장합니다.

함수

기능은 실행하려는 코드에서 실행 환경을 추상화합니다. 예를 들어, AWS Lambda를 이용하면 인스턴스를 실행하지 않고도 코드를 실행할 수 있습니다.

여러분은 AWS Lambda 를 사용하면 관리 작업 없이 모든 유형의 애플리케이션 또는 백엔드 서비스에 대한 코드를 실행할 수 있습니다. 코드를 업로드하기만 하면 AWS Lambda가 해당 코드를 실행하고 확장하는 데 필요한 모든 것을 관리합니다. 코드가 기타 AWS 서비스에서 자동으로 트리거되도록 설정할 수 있습니다. 코드는 직접 호출할 수도 있고 Amazon API Gateway에서 사용할 수도 있습니다.

Amazon API Gateway 는 어떤 규모에서든 개발자가 API를 쉽게 생성, 게시, 유지 관리, 모니터링 및 보호할 수 있게 하는 완전관리형 서비스입니다. Lambda 함수의 “프런트 도어” 역할을 하는 API를 생성할 수 있습니다. API Gateway는 트래픽 관리, 권한 부여 및 접근 제어, 모니터링 및 API 버전 관리를 비롯하여 최대 수십만 건의 동시 API 호출을 수락하고 처리하는 데 관련된 모든 작업을 처리합니다.

AWS Lambda를 통해 최적의 성능을 제공하려면 함수에 사용할 메모리의 양을 선택하십시오. 그러면 해당 메모리에 비례하는 CPU 성능과 기타 리소스가 할당됩니다. 예를 들어 256MB 메모리를 선택하면 128MB 메모리를 요청할 때에 비해 약 2배의 CPU 파워가 Lambda 함수에 할당됩니다. 각 함수를 실행할 수 있는 시간(최대 900초)을 제어할 수도 있습니다.

사용 가능한 컴퓨팅 구성 옵션 파악: 다양한 옵션을 통해 워크로드를 보완할 수 있는 방식과 시스템에 가장 적합한 구성 옵션을 파악합니다. 이러한 옵션의 예로는 인스턴스 패밀리, 크기, 기능(GPU, I/O), 함수 크기, 컨테이너 인스턴스, 단일/다중 테넌시 등이 있습니다.

인스턴스 패밀리 및 유형을 선택할 때는 워크로드 요구 사항을 충족하는 데 사용할 수 있는 구성 옵션도 고려해야 합니다.

  • GPU(그래픽 처리 장치) GPGPU(GPU의 범용 컴퓨팅) 기능을 사용하는 경우 개발 프로세스에서 CUDA와 같은 플랫폼을 활용함으로써 GPU가 제공하는 높은 병렬 처리 수준 이점이 적용되는 애플리케이션을 빌드할 수 있습니다. 워크로드에 3D 렌더링 또는 비디오 압축 기능이 필요한 경우 GPU를 사용하면 하드웨어 가속 계산 및 인코딩이 가능하므로 워크로드의 효율성을 더욱 높일 수 있습니다.

  • FPGA(Field Programmable Gate Array) FPGA를 사용하면 매우 까다로운 워크로드에 사용자 지정 하드웨어 가속 실행 기능을 사용함으로써 워크로드를 최적화할 수 있습니다. C, Go 등의 지원되는 일반 프로그래밍 언어나 Verilog, VHDL 등의 하드웨어 중심 언어를 활용해 알고리즘을 정의할 수 있습니다.

  • AWS Inferentia(Inf1) Inf1 인스턴스는 기계 학습 추론 애플리케이션을 지원하도록 구축되었습니다. Inf1 인스턴스를 사용하는 고객은 이미지 인식, 음성 인식, 자연어 처리, 개인화 및 사기 탐지와 같은 대규모 기계 학습 추론 애플리케이션을 실행할 수 있습니다. TensorFlow, PyTorch 또는 MXNet과 같은 주요 기계 학습 프레임워크 중 하나에서 모델을 구축하고 P3 또는 P3dn과 같은 GPU 인스턴스를 사용하여 모델을 훈련할 수 있습니다. 요구 사항을 충족하도록 기계 학습 모델을 훈련한 후에는 Inferentia 칩의 기계 학습 추론 성능을 최적화하는 컴파일러, 런타임 및 프로파일링 도구로 구성된 특수 SDK(소프트웨어 개발 키트)인 AWS Neuron을 사용하여 Inf1 인스턴스에 모델을 배포할 수 있습니다.

  • 버스트 가능 인스턴스 패밀리 버스트 가능 인스턴스는 적절한 기준 성능을 제공하는 동시에 워크로드에 필요한 더 높은 성능으로 버스트할 수 있는 기능을 제공하도록 설계되어 있습니다. 전체 CPU를 자주/일관되게 사용하지는 않지만 가끔씩 버스트해야 하는 워크로드에는 이러한 인스턴스를 사용해야 합니다. 이러한 인스턴스는 웹 서버, 개발자 환경, 소형 데이터베이스 등의 범용 워크로드에 적합합니다. 이러한 인스턴스는 인스턴스가 적절한 성능을 제공해야 할 때 사용할 수 있는 CPU 크레딧을 제공합니다. 크레딧은 인스턴스에서 필요하지 않으면 누적됩니다.

  • 고급 컴퓨팅 기능 — Amazon EC2에서는 C-상태/P-상태 레지스터 관리, 프로세서 터보 부스트 제어 등의 고급 컴퓨팅 기능을 제공합니다. 또한 보조 프로세서에 접근할 수 있으므로 AES-NI를 통해 암호화 작업을 오프로드하거나 AVX 확장을 통해 고급 계산을 수행할 수 있습니다.

유효 AWS Nitro System 은 전용 하드웨어와 경량 하이퍼바이저가 결합된 시스템으로, 혁신을 가속화하고 보안을 개선합니다. 사용 가능한 경우 AWS Nitro Systems를 활용하여 호스트 하드웨어의 컴퓨팅 및 메모리 리소스를 완전히 사용할 수 있습니다. 또한 전용 니트로 카드를 사용하여 고속 네트워킹, 고속 EBS 및 I/O 가속화를 지원할 수 있습니다.

컴퓨팅 관련 지표 수집: 컴퓨팅 시스템 성능을 가장 효율적으로 파악하는 방법 중 하나는 다양한 리소스의 실제 사용률을 기록하고 추적하는 것입니다. 이 데이터를 사용하면 리소스 요구 사항을 보다 정확하게 파악할 수 있습니다.

마이크로서비스 아키텍처에서 실행되는 것과 같은 워크로드에서는 지표, 로그 및 이벤트 형식의 데이터가 대량으로 생성될 수 있습니다. 이렇게 생성된 데이터를 기존 모니터링 및 관찰 서비스로 관리할 수 있는지 확인하십시오. Amazon CloudWatch를 사용하면 AWS 및 온프레미스 서버에서 실행되는 모든 AWS 리소스, 애플리케이션 및 서비스의 단일 플랫폼에서 이러한 데이터를 수집, 접근 및 상호 연관할 수 있으므로 시스템 전반의 가시성을 손쉽게 확보하고 문제를 신속하게 해결할 수 있습니다.

적절하게 크기를 조정하여 필요한 구성 확인: 워크로드의 다양한 성능 특성, 그리고 이러한 특성과 메모리/네트워크/CPU 사용량 간의 관계를 분석합니다. 이 데이터를 사용하면 워크로드 프로필에 가장 적합한 리소스를 선택할 수 있습니다. 예를 들어 데이터베이스와 같은 메모리 집약적 워크로드는 r-패밀리 인스턴스로 처리하는 것이 가장 좋습니다. 하지만 버스트 워크로드의 경우 탄력적인 컨테이너 시스템을 사용하는 것이 더 유리할 수 있습니다.

사용 가능한 리소스 탄력성 사용: 클라우드는 수요 변화에 맞춰 다양한 메커니즘을 통해 리소스를 동적으로 확장 또는 축소할 수 있는 유연성을 제공합니다. 컴퓨팅 관련 지표를 함께 활용하는 경우 워크로드가 변화에 자동으로 대응하여 목표를 달성하는 데 가장 적합한 리소스 세트를 활용할 수 있습니다.

수요에 가장 적합한 리소스를 공급하면 워크로드의 비용을 최대한 낮출 수 있습니다. 하지만 그와 동시에 프로비저닝 시간과 개별 리소스 장애를 고려해 리소스를 충분히 공급할 수 있는 계획도 마련해야 합니다. 수요는 고정되어 있을 수도 있고 변경될 수도 있으므로, 관리상의 부담을 방지하고 관리 작업에서 비용이 너무 많이 발생하지 않도록 하려면 적절한 지표와 자동화 기능이 필요합니다.

AWS에서는 다양한 접근 방식을 사용하여 수요와 공급을 일치시킬 수 있습니다. 비용 최적화 원칙 백서에서는 다음과 같은 접근 방식을 사용하여 비용을 절감하는 방법을 설명합니다.

  • 수요 기반 방식

  • 버퍼 기반 방식

  • 시간 기반 방식

워크로드 배포에서 확장 및 축소 이벤트를 모두 처리할 수 있는지 확인해야 합니다. 축소 이벤트에 대한 테스트 시나리오를 생성하여 워크로드가 예상대로 작동하는지 확인하십시오.

지표를 기준으로 컴퓨팅 요구 사항 재평가: 시스템 수준 지표를 사용하여 시간별 워크로드 동작 및 요구 사항을 파악합니다. 사용 가능한 리소스를 이러한 요구 사항과 비교해 워크로드 요구를 평가한 다음, 워크로드 프로필에 가장 적합하도록 컴퓨팅 환경을 변경합니다. 예를 들어 시스템을 계속 사용하다 보면 초기 예상보다 메모리가 더 많이 사용될 수 있습니다. 이 경우 다른 인스턴스 패밀리나 크기로 전환하면 성능과 효율성이 모두 개선될 수 있습니다.