[클라우드] 10. Public Cloud (AWS, Azure, GCP)

 

퍼블릭 클라우드

• 클라우드 플랫폼
  • Amazon Web Services (AWS)
  • MS Azure
  • Google Cloud
  • NHN Cloud (오픈스택 기반)

 

퍼블릭 클라우드 선택 시 고려사항

• 신뢰도
  • 믿을 수 있는 클라우드 플랫폼? → 보안, 서비스 종류 및 실제 고객의 피드백 참고
• 안정성 평가
  • 정기 릴리즈, 가용성, 성능, 로드 밸런싱 등 확인 필요
• 규모의 경제
  • 사내 인프라와 클라우드 리소스를 활용했을 때의 비용 비교
• 표준화된 서비스
  • 클라우드 플랫폼이 비용 효율을 가져다 줄 수 있는 서비스 묶음, 리소스 제공하는가?
• 유연성 평가
  • 현재 수준에 필요한 기능 이상의 서비스를 고려 (제품의 향후 로드맵)

 

Amazon Web Services (AWS)

• 클라우드 플랫폼 중 가장 오래됨
   
• 그 만큼 신뢰 그리고 안정성 측면에서 높은 평가를 받고 있음
  
  
•  Amazon은 전자 상거래 솔루션으로 시작했기 때문에, 엔터프라이즈를 위한 클라우드 컴퓨팅 플랫폼 개발에 장점을 가짐
  
  
• 전세계 22개의 리전(지역), 14개의 가용 영역, 114개 엣지 로케이션 보유
     • 많을수록 좋은 이유는 서비스 성능과 가용성에 영향을 받지 않고 글로벌에 데이터를 빠르게 전달할 수 있음
   
• 모든 운영체제를 지원하며, 가용성, 안정성, 성능, 서비스의 수 측면에서 최고의 IaaS 플랫폼으로 평가
   
• 제공하는 모든 서비스를 다 합치면 약 18,000개 정도
  • 개발자/관리 도구, 머신러닝 및 예측분석, 데이터베이스 및 스토리지 솔루션, 비즈니스 생산성 도구,
  애플리케이션 통합, 컴퓨팅 자원 등

 

Microsoft Azure

• 윈도우 기반 서비스를 하는 고객들이 많이 찾는 플랫폼
  • 윈도우도 있지만 Linux 친화성도 갖고 있음
  
  
• .NET, Java, PHP, Node.js, Python을 포함하여 다양한 언어를 지원하는 서버 앱 제공하는 면이 강점 (PaaS 계열 강세)
   
• 전 세계 54개 리전을 가지고 있으며, 최신 기술을 배포하고 생산성을 높이기 위한 서비스를 제공
   
• 구성 및 운영이 쉽다는 장점도 있음
   
• 주요 서비스
  • 빅데이터 및 예측 분석, 게임 및 애플리케이션 개발, 확장이 용이한 데이터 웨어하우징, 블록체인, 데브옵스, IoT 통합 등의 서비스에 강점을 가짐

 

Google Cloud

• AWS나 Azure 보다 나중에 출시된 플랫폼
• 나중에 출시되긴 하였으나 명확한 강점이 있음
  • 괌에서 시작해 호주, 남태평양, 아시아, 일본 및 미국 본토의 서버와 연결되는 해저 케이블 시스템을 갖춘 선구자
•  데이터센터가 빠르게 추가되고 있으며, 데이터가 중요한 비즈니스의 경우 Google Cloud가 적합할 수 있음
• 예측 및 실시간 분석과 더불어 최첨단 스토리지 및 컴퓨팅 옵션 제공

 

 

 

퍼블릭 클라우드 선택

• AWS
  • 다양한 서비스
• MS Azure
  • On-Premise 시스템과의 통합 용이
• Google Cloud
  • AI 예측 및 실시간 분석
• 하지만! 비즈니스의 성격이나 활용 서비스의 다양성으로 정해진 답은 없다
  • 많은 사람들이 정리된 표 (decision tree?)를 원하나 아무도 만들지 않음

 

 

많이 쓰는 클라우드: AWS

• 세계 각지에 배치된 데이터센터와 데이터센터 내의 서버, 스토리지, 소프트웨어 등 IT 리소스를 AWS 관리 콘솔을 통해 직접 선택하여 생성하고 설정하는 것이 핵심!
  
  
• Cloud Service Provider (CSP) vs. Managed Service Provider (MSP)
  • CSP
     • 클라우드 인프라를 제공하는 업체
  • MSP
     • CSP가 제공한 인프라를 바탕으로 클라우드 아키텍처를 설계하고 관리 및 운영을 돕는 업체

 

 

AWS 서비스

• Amazon EC2 (Elastic Cloud computing)                       → VM
• Amazon RDS (Relational Database Services)              → RDBMS
• Amazon S3 (Simple Storage Service)                           → obj. storage
• Amazon Lambda                                                            → server less computing
• Amazon Cognito                                                             → 사용자 인증 및 관리
• Amazon Glacier                                                              → 저비용 장기 스토리지
• Amazon SNS (Simple Notification Service)                     → 알림 서비스
• Amazon VPC (Virtual Private Cloud)                              → 네트워크
• Amazon Auto-scaling                                                       → 자동 확장
• Amazon IAM (Identity and Access Management)          → 사용자 및 권한 관리
• Amazon SQS (Simple Queue Service)                           → 메시지 대기열 서비스
• Amazon ElastiCache                                                       → 인메모리 캐시
• Web Application Firewall                                                 → 웹 애플리케이션 방화벽

 

AWS 클라우드 제품

• IT 리소스 제품군
  • 컴퓨팅 (서버)
     • EC2 (Elastic Compute Cloud), ECS (… Container Service), EKS (… Kubernetes …)
  • 스토리지
     • S3 (Simple Storage Service), EBS (… Block Store)
  • 데이터베이스
     • RDS (Relational DB Service), DynamoDB (NoSQL DB)
  • 네트워크
     • VPC (Virtual Private Cloud)
• 시스템 개발 및 운영에 필수적인 제품군
  • 개발자 도구
     • Cloud9 (IDE), CodeCommit, CodeBuild, CodeDeploy, CodePipeline
  • 분석
     • Athena (S3 분석), Redshift (데이터 웨어하우징)
  • 관리 도구
     • CloudWatch, Billing and Cost Management
  • 보안
     • IAM (Identity and Access Management), Cognito (로그인 관리)
  • 비즈니스 애플리케이션 및 최신 기술
     • Rekognition (영상), Textract (텍스트), Transcribe (음성)

 

IAM 사용자

• 루트 사용자
  • 모든 IT 리소스 조작 가능, 해지를 포함한 AWS 계정의 계약 변경 및 결제 정보 변경 등도 가능
  • 탈취되면? 끝!
• IAM 사용자
  • 일반적인 작업을 수행하는 사용자 (개인이나 역할별로 최소한의 권한)

 

 

이용 요금

• 클라우드 활용의 장점은 이용한 만큼 비용을 지불
  • IT 리소스 특성에 따라 요금 산출 방식이나 체계가 다름

요금 관리

• 클라우드 활용의 단점은 쓰면 비용을 지불
  • 잘못된 설정 / 불필요한 설정
  • 테스트용으로 잠깐 쓰려고 만든 VM (+ GPU)
  • 테스트용으로 잠깐 만든 S3, RDS, …
  • 이 모든 것이 비용 청구서로 돌아올 수 있음

 

 

AWS 연결 환경

• 사설 인프라와 달리 일반 사용자도 운영자도 클라우드 밖에 위치
   
• 기업 내 시스템 및 서버와 AWS 내 시스템 및 서버 간 연동?
  • 통신 사업자 등이 제공하는 전용선을 쓸 수도…
  • 하지만, 기본적으로는 VPN over 인터넷
   
• 시스템 관리자 vs. 일반 사용자
  • 구체적인 보안 정책
  • 누가 어느 리소스에 접근할 수 있는가? 권한은?

원래는 기존의 root 에 대해서는 권한을 설정할 필요도 없었고 그렇게 썼었다. 루트 사용자 = 서비스 접근 가능 이었기에,,
하지만 이제는 다 외부에 있으니까 어떤 사용자가 어디를 접근할 수 있고 이런 부분들에 대해서 모든 것들을 명시할 필요가 생기게 되었다.

 

 

 

클라우드 아키텍처 구성

• 항상 준비를 하고 나서 서비스 사용
  • 클라우드 특성 상 언제든 서비스 사용 가능
  • 어떤 시스템이나 서비스를 구현할 것이고 무슨 기능이 필요한지 사전에 계획하고, 이용할 것을 추천

ex) 웅진회사 구조

 

데이터센터의 위치

• 클라우드 서비스를 이용할 때 어느 리전(Region)의 IT 리소스를 사용할 것인지 결정해야 함
  • 따로 설정 안 하면, 기본적으로 미국으로 설정됨
  
  
• 국내 사용자를 대상으로 애플리케이션 서비스를 제공한다면?
  • 해외 서버를 이용할 필요가 없으므로, 아시아 태평양 (서울)이 적절
  • 다만, 지역별로 요금이 다소 차이가 있다는 점을 인지할 필요 있음
  
  
• 백업을 고려한다면?
  • 재해 복구 등 대규모 재해가 발생해도 시스템을 계속 사용할 수 있도록 백업 시스템을 다른 리전에 설치
  • 하지만, 리전에 따라 클라우드에 저장된 데이터에 관한 법률적 규제 등의 문제가 있을 수 있음을 주의

 

 

Amazon EC2

• 소규모 서버부터 대규모 고성능까지 필요에 따라 선택 가능
  • AWS를 이용할 때, 사실 상 EC2 가상 서버 생성부터 시작한다면 생각하면 됨
• OS, CPU 수량, 메모리 용량, 디스크 용량 등을 파악하고 어떤 유형의 가상머신으로 선택할지 결정

자신의 애플리케이션의 특성을 잘 파악하여 그 특성에 맞게 어떤 유형으로 선택할지 결정하는 것이 중요

 

 

Amazon Machine Image (AMI)

• 서버를 생성할 때 첫 번째 단계로 OS 이미지 선택

 

Amazon Linux 2

• AWS의 Linux 운영체제 (RHEL 기반)
  • 클라우드 및 앤터프라이즈 애플리케이션을 개발하고 실행할 수 있도록 보안에 중점을 둔 안전적인 고성능
  실행 환경을 제공
  
  
•  성능 최적화
  • EC2 기능에 대한 지원을 포함하여 향상된 성능을 제공하도록 튜닝
  • 즉, AWS의 각종 서비스들과 상성이 좋음
  
  
•  안정적인 장기 지원
  • 개발자, IT 관리자는 주요 소프트웨어 패키지의 최신 버전에 액세스하면서 예측 가능한 장기 지원 (LTS)
  릴리스를 받을 수 있음 (+ 기술 지원)
  
  
•  개발자 생산성 향상
  • On-premise 개발 및 테스트를 위한 가상 머신 및 컨테이너 이미지 제공
  • 프로덕션 환경에서 사용되는 것과 동일한 환경 구축, 테스트 및 통합 수행

 

 

스토리지 서비스

• Amazon EBS (Elastic Block Store)
  • 데이터베이스처럼 응답 속도에 민감하다면, 블록 스토리지 서비스
  • 오브젝트 스토리지 서비스는 읽기 쓰기 속도가 상대적으로 느림
  
  
•  Amazon S3 (Simple Storage Service)
  • 데이터를 파일 단위로 저장/검색/삭제하는 저장소
  • ‘오브젝트 스토리지’라고도 불림
  
  
•  Amazon S3 Glacier (= 빙하)
  • 빈번하게 읽을 필요가 없는 장기 보존용 데이터 저장소
  • 구 디지털 정보의 저장 및 자기 테이프의 대체품으로 이용

 

서버 전용 스토리지

• Amazon EC2와 함께 이용하는 스토리지, Amazon EBS
  • 볼륨 유형 → SSD vs. HDD?

Amazon EBS 볼륨 가이드

IOPS (초당 입출력 작업 수) vs Throughput (처리량)

 

 

Amazon S3

• 다양한 용도로 이용할 수 있는 소규모부터 대규모에 이르는 확장성, 고가용성, 저비용을
  실현하는 객체 스토리지 서비스
• 객체 – Object, 저장된 데이터 하나 하나를 객체라 명명
• 버킷 – Bucket, 연관된 객체들을 그룹핑한 최상위 디렉토리버킷 단위로 지역 지정, 일괄적으로 인증 및 접속 제한 가능

 

 

AWS VPC

• Virtual Private Cloud
  • 프라이빗 클라우드를 퍼블릭 클라우드 상에서 구현하는 가상 네트워크 서비스
  • VPC 내 가상 서버 및 네트워크 장비는 프라이빗 IP 주소를 할당

아마 대부분 퍼블릭 클라우드를 쓰면 디폴트 네트워크를 쓰고서 크게 건드리지 않는 경향이 있는데 우리가 정말 제대로 서비스 하겠다고 한다면 당연히 분리를 해야한다. 외부로 노출되는 부분들, 내부에서 센시티브한 데이터들을 다루고 있는 부분들 등등 이런 부분들을 다 분리해줘야 나중에 공격자에 의해서 프론트엔드가 터졌다, 털렸다!
하지만 내부에 있는 데이터들을 안전하게 지켰다. 가 될 수 있는것
프라이빗 서브넷, 퍼블릭 서브넷들도 나누게 될 거고 이과정에서 서로 다른 프라이빗 네트워크가 있으니까 통신하려면 라우팅이 필요하기 때문에 중간에 네트워크 장비도 생기고 웹으로 인터넷으로 나가야하니까 게이트웨이가 존재하게되고 게이트웨이는 NAT가 설정되어 있어야 하고 등등

 

Q. 퍼블릭 서브넷 B를 /20 대신 /16으로 설정했다면 네트워크 트러블 슈팅의 시작이 될 수 있다. 왜그럴까?
A.
퍼블릭 서브넷 B는 이제 172.31.0.0/16이다. 이는 172.31.0.0부터 172.31.255.255까지의 IP 주소를 포함하며 /16 서브넷 마스크는 약 65,536개의 IP 주소를 포함하게된다.
 퍼블릭 서브넷 B가 /16 서브넷 마스크를 사용한다면 인스턴스들은 172.31.0.0/16 범위 내의 모든 IP 주소를 자신의 서브넷으로 인식한다.이 경우, 퍼블릭 서브넷 B의 인스턴스가 프라이빗 서브넷 A(172.31.0.0/20)의 인스턴스와 통신하려고 하면, 해당 패킷을 같은 서브넷 내에 있다고 생각하고(실제는 분리되어 있는 상황) 직접 ARP를 통해 전달하려고 시도하게 된다 (문제발생). 
 하지만 프라이빗 서브넷 A의 인스턴스들은 여전히 /20 서브넷 마스크를 사용한다. 이는 172.31.0.0부터 172.31.15.255까지의 IP 주소만을 같은 서브넷으로 인식한다.따라서 프라이빗 서브넷 A의 인스턴스들은 퍼블릭 서브넷 B의 /16 서브넷 마스크 설정을 인지하지 못하고, 퍼블릭 서브넷 B로부터 온 패킷을 외부 네트워크에서 온 패킷으로 판단되어 처리하려고 할 것이다.
즉, 패킷이 퍼블릭 서브넷 B의 인스턴스로부터 프라이빗 서브넷 A의 인스턴스로 전달될 수는 있지만, 프라이빗 서브넷 A의 인스턴스는 응답 패킷을 라우터를 통해 퍼블릭 서브넷 B로 보내지 않고, 외부로 보내야 한다고 판단할 것이다. 이로 인해 응답 패킷이 퍼블릭 서브넷 B로 돌아가지 못하게 된다. 결과적으로, 퍼블릭 서브넷 B의 인스턴스는 자신이 보낸 패킷에 대한 응답을 받지 못하게 되는것!

※ ARP(Address Resolution Protocol): 네트워크 장비들이 서로의 MAC 주소를 알기 위해 사용하는 프로토콜

 

Elastic IP

• Public IP vs. Elastic IP

Public IP → AWS는 인스턴스가 실행될 때마다 자동으로 퍼블릭 IP를 할당한다.
기본적으로 EC2 인스턴스에 할당되며, 인스턴스를 종료하거나 중지할 때마다 새로운 퍼블릭 IP가 할당될 수 있다. 이는 고정된 IP가 아니므로 특정 인스턴스에 지속적으로 연결하기 어렵다.

Elastic IP → 사용자가 명시적으로 할당하고 관리하는 고정 IP 주소이다.
Elastic IP는 AWS 계정에 고정된 IP 주소로, 특정 인스턴스에 연결하면 해당 인스턴스가 종료되거나 중지되더라도 IP 주소가 변하지 않는다. 사용자가 필요에 따라 인스턴스 간에 IP를 자유롭게 재할당할 수 있다.

 

 

 

데이터베이스 서비스

• Amazon RDS
  • 관계형 데이터베이스 서비스 (RDBMS)
  • MySQL, PostgresSQL, Oracle Database, Microsoft SQL Server 등 지원
  
  
• Amazon Aurrora
  • 클라우드 환경에 최적화된 데이터베이스
  • MySQL, PostgresSQL과 호환되면서 높은 성능과 가용성 등 제공
  
  
• Amazon DynamoDB
  • NoSQL 서비스
  • 빠르고 확장성이 우수, 낮은 레이턴시 제공 MySQL in EC2 vs. Amazon RDS vs. Amazon Aurrora
  
  
• MySQL in EC2 vs. Amazon RDS vs. Amazon Aurrora 
• Amazon RDS - MySQL
  • EC2에서 수동으로 데이터베이스를 구축한 것처럼 동작
  • EBS 스토리지는 프로비저닝된 인스턴스에 연결
  • 인스턴스에 생성되기 때문에 I/O 대역폭 및 IOPS로 인해 성능 제한
  
  
• Amazon Aurrora - MySQL
  • 소스 커스터마이징하여 AWS에 최적화
  • RDS에서 사용하는 EBS 대신 NVMe SSD 드라이브 위에 구축
  • 빠른 로컬 성능 및 재해 복수를 위해 여러 지역에 데이터를 복제
  • 컴퓨팅 및 스토리지 작업을 분리하여 I/O 병목현상 줄임

같은 MySQL 기반의 서비스를 쓰더라도 RDS를 쓸때랑 Aurrora를 쓸 때랑 조금씩 다르더라,, 결국 DB마다 특징에 맞춰서 사용해야한다.

 

 

 

AWS vs. OpenStack

• AWS Management Console → Horizon
• EC2 → Nova
• ECS / EKS → Magnum, Kubernetes
• EBS → Cinder
• S3 → Swift
• VPC → Neutron
• Elastic IP → Floating IP
• RDS → Trove
• IAM → Keystone
• CloudWatch → Ceilometer
• CloudFoundation → Heat