이 시리즈의 글들은 AWS Skill Builder의 교육 내용을 모방하고 있음을 밝힙니다.
Ⅰ. 클라우드 컴퓨팅
1. 클라이언트-서버 모델
컴퓨팅에서 클라이언트는 사람이 컴퓨터 서버에 요청을 보내기 위해 상호 작용하는 웹 브라우저 또는 데스크톱 애플리케이션일 수 있다. 서버는 일종의 가상 서버인 Amazon Elastic Cloud(Amazon EC2)와 같은 서비스일 수 있다.
2. 클라우드 컴퓨팅 배포 모델
1) 클라우드 기반 배포
- 애플리케이션의 모든 부분을 클라우드에서 실행한다.
- 외부 데이터센터에서 소프트웨어를 호스팅하고 관리한다.
- 신속한 개발, 관리, 배포가 가능하다.
2) 온프레미스 배포
- 온프레미스란, 로컬 장치에 직접 설치, 실행되는 소프트웨어 유형을 의미한다.
- 클라우드 컴퓨팅이 아닌 자체적으로 관리하는 환경에서 소프트웨어를 실행하고 유지 관리하는 방식이다.
- 보안 요구 사항이 엄격한 산업이나 규제에 따라 데이터를 내부에 유지해야 하는 경우 유용할 수 있으며 커스터마이징에 유리하다.
- 비용과 작업시간이 많이 소요되고, 확장성과 유연성이 많이 떨어질 수 밖에 없다.
3) 하이브리드 배포
- 온프레미스 환경과 클라우드 환경을 결합하여 소프트웨어, 애플리케이션 또는 시스템을 배포하는 방식이다.
- 일반적으로 중요한 데이터나 엄격한 보안이 요구되는 부분을 온프레미스에서 처리하고, 자주 변경되는 요소나 확장성이 필요한 부분을 클라우드에서 처리한다.
- 보안성과 확장성, 비용 효율성까지 모두 추구할 수 있는 조화로운 방식이다.
3. 클라우드 컴퓨팅의 이점
1) 선행 비용을 가변 비용으로 대체
선행 비용은 데이터 센터, 물리적 서버 등 미리 투자를 해야 사용할 수 있는 리소스를 사용하는 경우에 발생한다. 가변 비용의 경우 어떻게 사용할지 결정하기도 전에 데이터 센터와 서버에 대규모로 투자하는 대신, 사용하는 컴퓨팅 리소스에 대해서만 비용을 지불한다.
2) 데이터 센터 운영 및 유지 관리에 비용 투자 불필요
데이터 센터에서 컴퓨팅하려면 인프라 및 서버 관리에 더 많은 비용과 시간을 소비해야 하는 경우가 만핟. 클라우드 컴퓨팅의 이점은 이러한 작업에 신경을 덜 쓰고 애플리케이션과 고객에 더 집중할 수 있다.
3) 용량 추적 불필요
클라우드 컴퓨팅에서는 애플리케이션을 배포하기 전에 필요한 인프라의 용량을 예측할 필요가 없다. 예를 들어 EC2 인스턴스를 시작하고 사용한 컴퓨팅 시간에 대해서만 비용을 지불할 수 있다. 사용하지 않는 리소스 때문에 비용을 지불하거나 제한된 용량을 사용해야하는 대신 필요한 용량만 사용할 수 있다. 또한 수요에 따라 확장 또는 축소할 수 있다.
4) 규모의 경제로 얻게 되는 이점
클라우드 컴퓨팅을 사용하면 인프라를 소유할 때보다 가변 비용이 낮아진다. 클라우드에서 수 많은 고객의 사용량이 누적될 수 있으므로 AWS와 같은 공급자는 더 높은 수준의 규모의 경제를 달성할 수 있다. 이 같은 규모의 경제는 곧 종량 과금제를 통한 요금 감소로 이어진다.
5) 속도 및 민첩성 향상
클라우드 컴퓨팅의 유연성 덕분에 애플리케이션을 더욱 쉽게 개발하고 배포할 수 있다. 이를 통해 실험과 혁신에 더 많은 시간을 투자할 수 있다. 데이터 센터에서 컴퓨팅을 수행할 경우, 필요한 새 리소스를 확보하는 데 몇 주가 걸릴 수도 있다. 이에 비해 클라우드 컴퓨팅을 사용하면 몇 분 만에 새로운 리소스에 액세스할 수 있다.
6) 몇 분만에 전 세계 배포
사용자는 AWS 클라우드의 글로벌 입지를 활용하여 전 세계 고객에게 신속하게 애플리케이션을 배포하는 동시에 짧은 지연 시간을 제공할 수 있다. 즉, 다른 지역에 위치한 고객도 지연 시간을 최소화하면서 애플리케이션에 액세스할 수 있다.
Ⅱ. Amazon Elastic Compute Cloud
1. AWS EC2 개념
온프레미스 리소스를 사용할 경우, 하드웨어를 구매해야하고, 서버가 준비될 때까지 기다려야 하고, 데이터 센터에 서버를 설치해야하고, 그 외에 필요한 모든 구성을 직접 준비해야 한다. 이에 비해 EC2 인스턴스를 사용할 경우 AWS 클라우드에서 가상 서버를 사용하여 애플리케이션을 실행할 수 있다. 단 몇 분 안에 EC2 인스턴스를 프로비저닝(컴퓨터 시스템이나 리소스를 사용 가능한 상태로 설정하고 제공하는 과정)할 수 있으며, 워크로드(컴퓨팅 시스템에서 수행되는 작업의 단위)가 완료됐다면, 언제든지 인스턴스 사용을 중지할 수 있다. 따라서 필요한 서버 용량만큼만, 또 사용한 시간만큼만 비용을 지불할 수 있어 비용 절감에도 도움이 될 수 있다.
2. AWS EC2 인스턴스 유형
AWS EC2 인스턴스는 유형에 따라 다양한 작업에 최적화된다. 인스턴스 유형을 선택할 때는 워크로드 및 애플리케이션의 구체적 요구 사항을 고려한다. 여기에는 컴퓨팅, 메모리, 또는 스토리지 기능에 대한 요구 사항이 포함될 수 있다.
1) 범용 인스턴스
범용 인스턴스는 컴퓨팅, 메모리, 네트워킹, 리소스를 균형있게 제공한다.
- 애플리케이션 서버
- 게임 서버
- 엔터프라이즈 애플리케이션용 백엔드 서버
- 중소 규모 데이터베이스
컴퓨팅, 메모리, 네트워킹에 필요한 리소스가 거의 동일한 애플리케이션이 있다고 해보자. 애플리케이션에 어느 한 리소스 영역에 대한 최적화가 필요하지 않기 때문에 이러한 경우엔 범용 인스턴스에서 애플리케이션을 실행하는 것이 좋을 것이다.
2) 컴퓨팅 최적화 인스턴스
컴퓨팅 최적화 인스턴스는 고성능 프로세서를 활용하는 컴퓨팅 집약적인 애플리케이션에 적합하다. 범용 인스턴스와 마찬가지로 컴퓨팅 최적화 인스턴스는 웹 서버, 애플리케이션 서버, 게임 서버와 같은 워크로드에 사용될 수 있다.
하지만, 컴퓨팅 최적화 애플리케이션은 고성능 웹서버, 컴퓨팅 집약적 애플리케이션 서버 및 게임 전용 서버에 적합하다는 점이 다르다. 또한 컴퓨팅 최적화 인스턴스를 단일 그룹에서 많은 트랜잭션을 처리해야 하는 일괄 처리 워크로드에 사용할 수도 있다.
3) 메모리 최적화 인스턴스
메모리 최적화 인스턴스는 메모리에서 대규모 데이터 세트를 처리하는 워크로드를 위한 빠른 성능을 제공하기 위해 설계되었다. 컴퓨팅에서 메모리는 임시 저장 영역이다. 여기에는 중앙처리장치(CPU)가 작업을 완료하는 데 필요한 모든 데이터와 명령이 들어 있다. 컴퓨터 프로그램이나 애플리케이션은 스토리지에서 메모리로 로드된 후 실행된다. 이 사전 로드 프로세스 덕분에 CPU가 컴퓨터 프로그램에 직접 액세스할 수 있다.
애플리케이션을 실행하기 전에 많은 데이터를 미리 로드해야 하는 워크로드가 있다고 해보자. 고성능 데이터베이스일 수도 있고 방대한 양의 비정형 데이터의 실시간 처리가 필요한 워크로드일 수도 있다. 이러한 유형의 사용 사례에서는 메모리 최적화 인스턴스 사용을 고려해야 한다. 메모리 최적화 인스턴스를 사용하면 많은 메모리가 필요한 워크로드를 실행하고 뛰어난 성능을 얻을 수 있다.
4) 액셀러레이티드 컴퓨팅 인스턴스
액셀러레이티드 컴퓨팅 인스턴스는 하드웨어 액셀러레이터 또는 코프로세서를 사용하여 일부 기능을 CPU에서 실행되는 소프트웨어에서보다 더 효율적으로 수행한다. 이러한 기능의 예로는 부동 소수점 수 계산, 그래픽 처리, 데이터 패턴 일치 등이 있다.
컴퓨팅에서 하드웨어 액셀러레이터는 데이터 처리를 가속화할 수 있는 구성 요소이다. 액셀러레이티드 컴퓨팅 인스턴스는 그래픽 애플리케이션, 게임 스트리밍, 애플리케이션 스트리밍과 같은 워크로드에 적합하다.
5) 스토리지 최적화 인스턴스
스토리지 최적화 인스턴스는 로컬 스토리지의 대규모 데이터 세트에 대한 순차적 읽기 및 쓰기 액세스가 많이 필요한 워크로드를 위해 설계되었다. 스토리지 최적화 인스턴스에 적합한 워크로드의 예로는 분산 파일 시스템(여러 컴퓨터에 데이터를 분산하여 저장 및 액세스할 수 있는 파일 시스템), 데이터 웨어하우징 애플리케이션(대규모의 데이터를 수집, 통합, 저장 및 분석하기 위해 사용되는 소프트웨어 애플리케이션), 고빈도 온라인 트랜잭션 처리(OLTP) 시스템 등이 있다.
컴퓨팅에서 IOPS(초당 입출력 작업 수)라는 용어는 스토리지 디바이스의 성능을 측정하는 지표이다. IOPS는 디바이스가 1초 내에 수행할 수 있는 입력 또는 출력 작업의 수를 나타내는데, 스토리지 최적화 인스턴스는 지연 시간이 짧은 임의 IOPS를 애플리케이션에 제공하도록 설계되었다.
입력 작업은 데이터베이스에 입력되는 레코드와 같이 시스템에 투입되는 데이터라고 생각할 수 있다. 출력 작업은 서버에서 생성된 데이터이다. 출력의 예로는 데이터베이스의 레코드에 대해 수행되는 분석을 들 수 있다. IOPS 요구 사항이 높은 애플리케이션이 있는 경우 스토리지 최적화 인스턴스는 이러한 종류의 사용 사례에 다른 인스턴스 유형보다 나은 성능을 제공할 수 있다.
※ 메모리와 스토리지의 차이
스토리지는 데이터를 영구적으로 저장하는데 사용되는 것으로 디스크 드라이브, SSD 등이 이에 해당한다. 전원이 꺼져도 데이터가 유지되는 특성이 있다. 주로, 파일이나 데이터베이스, 애플리케이션 등이 스토리지에 저장된다.
반면, 메모리는 일시적인 저장공간으로 실행 중인 프로그램이나 데이터, 명령 등을 로드하여 빠른 액세스를 제공한다. 전원이 꺼지면 모든 데이터가 소실되는 특성이 있다.
메모리는 스토리지에 비해 매우 빠르다. SSD가 디스크 드라이브보다는 빠르지만, 메모리에 비해서는 매우 느린 편이다. 대신 메모리의 용량은 비교적 작은 편이고, 스토리지의 용량은 이와 비교도 안 될 정도로 매우 크다.
3. Amazon EC2 요금
Amazon EC2에서는 사용한 컴퓨팅 시간에 대해서만 비용을 지불한다. Amazon EC2는 사용 사례에 따라 다양한 요금 옵션을 제공한다. 예를 들어 사용 사례가 중단을 견딜 수 있는 경우 스팟 인스턴스로 비용을 절감할 수 있다. 또한 예약 인스턴스로 사전 약정을 하고 최소 사용 수준을 고정하여 비용을 절약할 수도 있다.
1) 온디맨드
온디맨드 인스턴스는 중단할 수 없는 불규칙한 단기 워크로드가 있는 애플리케이션에 적합하다. 선결제 비용이나 최소 약정은 적용되지 않는다. 인스턴스는 중지될 때까지 계속 실행되며, 사용한 컴퓨팅 시간에 대해 비용을 지불한다.
온디맨드 인스턴스의 사용 사례에는 애플리케이션 개발 및 테스트와 예측할 수 없는 사용 패턴이 있는 애플리케이션 실행이 포함된다. 온디맨드 인스턴스는 1년 이상 지속되는 워크로드에는 권장하지 않는다. 이러한 워크로드에는 예약 인스턴스를 사용하는게 비용 절감 효과가 더 크기 때문이다.
2) Amazon EC2 Saving Plans
AWS는 Amazon EC2를 비롯한 여러 컴퓨팅 서비스에 대한 Savings Plans를 제공한다. Amazon EC2 Savings Plans를 사용하면 1년 또는 3년 동안 일정한 컴퓨팅 사용량을 약정하여 컴퓨팅 비용을 절감할 수 있다. 이 기간 약정을 통해 온디맨드 요금에 비해 최대 72%까지 비용을 절감할 수 있다.
약정 사용량까지는 할인된 Savings Plan 요금이 청구된다. 약정을 초과한 사용량에 대해서는 일반 온디맨드 요금이 부과된다.
AWS Cost Explorer라는 도구가 있는데, 이는 시간 경과에 따라 AWS 비용 및 사용량을 시각화, 이해 및 관리할 수 있는 도구이다. Savings Plans 옵션을 고려하고 있는 경우, AWS Cost Explorer를 통해 지난 7일, 30일 또는 60일 동안의 Amazon EC2 사용량을 분석할 수 있다. AWS Cost Explorer는 Savings Plans를 위한 맞춤형 권장 사항도 제공한다. 이러한 권장 사항은 이전 Amazon EC2 사용량과 1년 또는 3년 Savings Plan의 시간당 약정 금액을 기준으로 월별 Amazon EC2 비용을 얼마나 절감할 수 있는지 예상한다.
3) 예약 인스턴스
예약 인스턴스는 계정에서 온디맨드 인스턴스를 사용할 때 적용되는 결제 할인 옵션이다. 표준 예약 및 컨버터블 예약 인스턴스는 1년 또는 3년 약정으로, 정기 예약 인스턴스는 1년 약정으로 구입할 수 있다. 3년 약정 옵션을 통해 더 많은 비용을 절감할 수도 있다. 참고로 표준 예약은 인스턴스 유형이 고정되는 대신 높은 할인율을 제공 받을 수 있고, 컨버터블 예약은 인스턴스 유형을 자유롭게 변경할 수 있는 대신 할인율이 낮다.
예약 인스턴스 약정 기간이 끝나도 중단 없이 Amazon EC2 인스턴스를 계속 사용할 수 있지만, 인스턴스를 종료하거 새로운 예약 인스턴스를 구입하기 전까지는 온디맨드 요금이 부과된다.
4) 스팟 인스턴스
스팟 인스턴스는 시작 및 종료 시간이 자유롭거나 중단을 견딜 수 있는 워크로드에 적합하다. 스팟 인스턴스는 미사용 Amazon EC2 컴퓨팅 용량을 사용하며 온디맨드 요금의 최대 90%까지 비용을 절감할 수 있다.
필요에 따라 시작 및 중지할 수 있는 백그라운드 처리 작업(예: 고객 설문 조사 데이터 처리 작업)이 있다고 가정해 보자. 전반적인 비즈니스 운영에는 영향을 주지 않고 처리 작업을 시작하고 중지하려고 한다. 스팟 요청을 하고 Amazon EC2 용량을 사용할 수 있는 경우 스팟 인스턴스가 시작된다. 하지만 스팟 요청을 했는데 Amazon EC2 용량을 사용할 수 없다면 용량을 사용할 수 있을 때까지 요청이 성공하지 못한다. 용량을 사용할 수 없으므로 백그라운드 처리 작업의 시작이 지연될 수 있다.
스팟 인스턴스를 시작한 후 용량을 더 이상 사용할 수 없거나 스팟 인스턴스에 대한 수요가 늘면 인스턴스가 중단될 수 있습니다. 이 경우 백그라운드 처리 작업에는 문제가 없을 수도 있다. 하지만 앞에서 예로 든 애플리케이션 개발 및 테스트에서는 예기치 않은 중단을 방지하는 것이 좋기 때문에 상황에 맞는 EC2 인스턴스 유형을 선택해야 한다.
5) 전용 호스트
전용 호스트는 사용자 전용의 Amazon EC2 인스턴스 용량을 갖춘 물리적 서버이다.
고객이 특정 소프트웨어 라이선스 정책에 따라 라이선스를 서버 단위로 구매해야 할 때, 전용 호스트를 사용하여 해당 라이선스 정책을 준수할 수 있다. 또한 고객이 보안 및 규정 준수 요구 사항을 충족하기 위해 인스턴스를 공유하지 않고 단일 호스트에 배치할 필요가 있을 때, 전용 호스트를 사용할 수도 있다. 마찬가지로 온디맨드 방식과 예약 방식이 존재한다. 지금까지 다룬 모든 Amazon EC2 옵션 중 전용 호스트가 가장 비용이 많이 든다.
4. Amazon EC2 Auto Scaling
확장성을 위해서는 필요한 리소스만으로 시작하고 확장 및 축소를 통해 수요 변화에 자동으로 대응하도록 아키텍처를 설계해야 한다. 그 결과, 사용한 리소스에 대해서만 비용을 지불한다. 컴퓨팅 용량 부족 때문에 고객의 요구 사항을 충족할 수 없을지 걱정하지 않아도 된다. 이러한 조정 프로세스를 자동으로 실행해주는 AWS의 서비스가 바로 Amazon EC2 Auto Scaling이다.
잘 로드되지 않고 빈번히 시간 초과되는 웹 사이트에 액세스하려고 한 적이 있다면 이 웹 사이트가 처리할 수 있는 것보다 많은 요청을 수신한 것일 수 있다.
Amazon EC2 Auto Scaling을 사용하면 변화하는 애플리케이션 수요에 따라 Amazon EC2 인스턴스를 자동으로 추가하거나 제거할 수 있다. 필요에 따라 인스턴스를 자동으로 조정하여 애플리케이션 가용성을 효과적으로 유지할 수 있는 것이다.
Amazon EC2 Auto Scaling에서는 동적 조정과 예측 조정이라는 두 가지 접근 방식을 사용할 수 있다. 먼저, 동적 조정은 수요 변화에 대응한다. 또한 예측 조정은 예측된 수요에 따라 적절한 수의 Amazon EC2 인스턴스를 자동으로 예약한다. 이 둘을 함께 사용할 경우 더 빠른 조정이 가능하다.
클라우드에서는 컴퓨팅 파워(계산 작업의 능력 또는 성능)가 프로그래밍 방식의 리소스이므로 더 유연한 조정 방식을 사용할 수 있다. Amazon EC2 Auto Scaling을 애플리케이션에 추가하면 필요할 때 새 인스턴스를 애플리케이션에 추가했다가 더 이상 필요하지 않으면 종료할 수 있다.
Amazon EC2 인스턴스에서 애플리케이션을 시작할 준비를 하고 있다고 하자. Auto Scaling 그룹의 크기를 구성할 때 최소 Amazon EC2 인스턴스 수를 1로 설정할 수 있다. 즉, 하나 이상의 Amazon EC2 인스턴스가 항상 실행 중이어야 한다.
Auto Scaling 그룹을 생성할 때 최소 Amazon EC2 인스턴스 수를 설정할 수 있다. 최소 용량은 Auto Scaling 그룹을 생성한 직후 시작되는 Amazon EC2 인스턴스의 수이다. 이 예에서 Auto Scaling 그룹의 최소 용량은 Amazon EC2 인스턴스 1개이다.
그런 다음 애플리케이션을 실행하려면 최소 하나의 Amazon EC2 인스턴스만 필요하더라도 희망 용량을 Amazon EC2 인스턴스 두 개로 설정할 수 있다.
Auto Scaling 그룹에서 최대 용량을 설정할 수도 있다. 예를 들어 수요 증가에 대응하여 확장하도록 Auto Scaling 그룹을 구성하되, Amazon EC2 인스턴스 수를 최대 4개로 제한할 수 있다.
Amazon EC2 Auto Scaling은 Amazon EC2 인스턴스를 사용하므로 사용하는 인스턴스에 대해서만 비용을 지불하면 된다. 이는 비용을 줄이면서도 최상의 고객 경험을 제공하는 비용 효율적인 아키텍처를 제공하기 위한 서비스이다.
5. Elastic Load Balancing을 이용한 트래픽 리다이렉션
Elastic Load Balancing은 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스와 같은 여러 리소스에 자동으로 분산하는 AWS 서비스이다.
로드 밸런서는 Auto Scaling 그룹으로 들어오는 모든 웹 트래픽의 단일 접점 역할을 한다. 즉, 들어오는 트래픽의 양에 맞춰 Amazon EC2 인스턴스를 추가하거나 제거하므로 이러한 요청이 로드 밸런서로 먼저 라우팅(패킷이 출발지에서 목적지로 전달되는 경로를 결정하는 과정)된다. 그런 다음 요청을 처리할 여러 리소스로 분산된다. 예를 들어 Amazon EC2 인스턴스가 여러 개인 경우 Elastic Load Balancing은 워크로드를 여러 인스턴스에 분산하므로 어느 한 인스턴스가 대량으로 워크로드를 처리할 필요가 없게 된다.
Elastic Load Balancing과 Amazon EC2 Auto Scaling은 별도의 서비스이지만 서로 연동하여 Amazon EC2에서 실행되는 애플리케이션이 뛰어난 성능과 가용성을 제공하도록 돕는다.
아래는 Elastic Load Balancing이 어떻게 작동하는지 보여주는 예이다. 고객 몇 명이 커피숍에 들어왔고 주문할 준비가 되었다고 가정해보자.
계산대가 몇 개만 열려 있다면 이는 서비스가 필요한 고객의 수요와 일치한다. 커피숍에서 고객이 없는 계산대를 열어 둘 가능성은 적다. 이 예시에서의 계산대를 Amazon EC2 인스턴스로 생각할 수 있을 것이다.
반면, 수요가 증가하면 어떻게 될까? 고객의 수가 증가함에 따라 커피숍은 고객을 수용하기 위해 더 많은 계산대를 열어야 한다. 다이어그램에서 Auto Scaling 그룹이 이를 나타내고 있다.
또한 커피숍 직원이 고객을 가장 적합한 계산대로 안내하여 주문이 열려 있는 계산대에 균등하게 분배될 수 있도록 한다. 이 커피숍 직원을 로드 밸런서로 생각할 수 있겠다.
이 시리즈의 글들은 AWS Skill Builder의 교육 내용을 모방하고 있으며, 이미지는 AWS Skill Builder에서 가져온 것입니다. 넷제로 해커톤을 준비하는 과정에서 수료해야 하는 교육 내용이기에 블로그에 정리해 둔 것입니다. 문제 시 삭제하겠습니다.
>> AWS Skill Builder
