TIL 클라우드 (feat. AWS )

💻 1. 클라우드 컴퓨팅

• 과거

클라우드 컴퓨팅(Cloud computing)이 없던 시절에는 서버실이 있었다.
기존보다 더 많은 능력이 필요하면, 컴퓨터를 추가 및 성능을 업그레이드 했다.

• 문제

주기적인 관리 필요 (인력 및 비용 증가)
공간의 한계

• 문제해결

일부 거대 기업들은 데이터센터를 세웠다.
남는 자원들을 대여하는 서비스가 생겼다.

즉 서버의 자원과 공간, 및 네트워크 환경을 빌려 사용하는 클라우드 컴퓨팅 시작
(온프레미스라고 부른다.)

💻 2. 클라우드

• 현재

현재의 클라우드 컴퓨팅은 데이터센터와 비슷한 역할을 하지만,
물리적인 컴퓨터가 아닌 가상 컴퓨터를 대여한다는 점이 다르다.
(클라우드 등장)

• 클라우드 서비스의 장점 (온프레미스와 다른점)

1. 필요할 때마다 컴퓨팅 능력을 유연하게 조절

2. 온프레미스는 고정적인 비용이 들어갔지만, 클라우드는 사용한 만큼 지불

3. 스냅샷을 이용해 다른컴퓨터로 즉시 이주 가능
   (이부분은 잘 와닿지가 않는다. 더 찾아봐야겠다.)

• 클라우드의 단점

운영환경 자체가 제공자에게 종속되어 서비스에 영향을 미침
(AWS 처럼 편리한 기술을 익히는 것도 중요하지만 인프라 자체에 대한 이해도 중요)

실제사례 : AWS 장애에 당황한 고객사…쿠키런 킹덤, LOL 한때 먹통 - 머니투데이

기사내용

• 전세계 클라우드 서비스 시장 점유율 1위인 AWS에서 6시간 장애가 발생

• 쿠킹덤 서버가 있는 AWS 도쿄 리전에서 서버 냉각 시스템에 문제

• 쿠킹덤 외 AWS 서버를 사용하는 '리그오브레전드'도 지난 19일 약 1시간 접속 오류

• 2018년에도 서울 리전에서 84분 간의 서버 장애.
  당시 나이키, 쿠팡, 업비트 등 일반 소비자들이 자주 이용하는 웹사이트들이 마비

• 보통 AWS를 비롯한 클라우드 업체들은 99.99%의 월 가동률을 보장하는 계약조건을 서비스 수준 계약(SLA) 등에 담음. 클라우드 고객들은 이를 믿고 이용량에 따라 월 수천만씩 비용을 내며 서버 관리를 AWS 등 서비스형 인프라(IaaS·Infrastructure as a service) 업체들에 일임
  하지만 클라우드 서비스의 경우 문제가 생기면 직접 복구하기 어렵고 속수무책

• 업계에서는 클라우드 장애가 반복돼도 게임이나 플랫폼·배달·OTT서비스 등에서는 자체 물리적 서버를 구축하는 온프레미스 환경으로 복귀가 어렵다는 입장. 일단 데이터를 이전하기에 비용이 많이 들고 수십·수백만명 규모의 유동적인 글로벌 이용자 접속량을 감당하기에 클라우드 환경이 효율적.

• 클라우드 서비스 종류

1. on Prem : 모든걸 직접 다함
2. IaaS : 재료는 제공받고 요리는 직접 함
3. PaaS : 피자를 집에서 배달시켜먹음
4. SaaS : 피자집에 가서 피자먹기

자세한 내용은 클라우드 구현 모델에 따른 분류 참고

💻 3. Deploy

배포란 개발한 서비스를 사용자들이 이용가능하게 하는 일련의 과정
보통 4단계를 거침

• 1단계. Development (개발)

  • 로컬환경에서 개발 및 테스트
  • 샘플 데이터 이용
  • 변경사항있어도 괜찮음
  • 모든 구성원이 각자의 환경에서 진행

• 2단계. Intergration (통합)

  • 각자환경에서 개발한 부분 취합
  • 코드 간 conflict 없는지 확인

• 3단계. Staging (기능 검증 등)

  • 실제운영단계와 가장 유사한 환경에서 테스트
  • 복제된 실제데이터 이용
  • 모든관계자들이 검증하는 단계 (마케팅, 디자인팀 등)

• 4단계. Production (제품 출시)

  • 개발환경과는 구분된 환경
  • 실제데이터 이용
  • 실제로 서비스가 제공되는 단계
    (문제생기면 안됨)

💻 4. AWS 용어

• AWS(Amazon Web Service) : 아마존 웹사이트에서 제공하는 클라우드 컴퓨팅 서비스

EC2 (서버를 계속 켜두기 위해 대여함)

• Elastic compute Cloud : 사용한 만큼 지불해서 '탄력적인'단어로 네이밍
  즉, AWS에서 비용, 성능, 용량 면에서 탄력적인 클라우드 컴퓨터를 제공하는 서비스
• AWS 에서 원격으로 제어할 수 있는 가상의 컴퓨터를 대여
• AMI(Amazon Machine Image) : 소프트웨어 구성이 기재된 템플릿 (운영체제 및 런타임 선택가능)
• AWS EC2 인스턴스를 생성한다
  = AMI를 토대로 운영체제, CPU, RAM 혹은 런타임이 구성된 컴퓨터를 빌린다.

RDS (데이터베이스 손쉽게 이용)

• Relational Database Service : 관계형 데이터베이스 서비스
• DB를 직접 EC2 인스턴스에 설치해서 사용하면, 확장 및 백업 등을 직접해야함 (자차)
• 유지보수관련 일을 AWS에서 전적으로 관리, 다양한 데이터베이스 엔진 이용가능 (렌터카)

S3 (클라이언트 배포)

• 클라우드 스토리지 : 쉽게 말해 인터넷 공간에 데이터를 저장하는 저장소 (하드디스크 역할)
  예시 : Google Drive, 네이버 MYBOX, 마이크로소프트의 Onedrive 등

• 클라우드 스토리지 장점 : 뛰어난 접근성
  (웹 환경이라면 언제 어디서나 저장된 파일에 접근)

• Simple Storage Service : AWS에서 제공하는 클라우드 스토리지 서비스
• S3 의 장점
  • 확장성 : 데이터를 무한하게 저장 가능 (사용한만큼 지불하면 됨)
  • 내구성 : S3는 99.999999999%의 내구성을 보장
  • 가용성 : S3는 연간 99.99%의 스토리지 가용성을 보장하도록 설계가 되어 있음.
    이는 다른 말로 1년 동안 S3에 파일을 저장했을 시, 8.76시간동안만 스토리지를 이용하는 데 있어서 장애가 발생한다는 뜻 ( 위 기사와 연관해서 생각해보면 좋을 것 같다.)
• 어떻게 이런 내구성과 가용성이 가능할까?

AWS Rigion 지도이다.

• 리전 : AWS에서 클라우드 서비스를 제공하기 위해서 운영하는 물리적인 서버의 위치
  (각 동그라미가 리전이다)
• 가용영역(데이터센터) : 동그라미 안에 숫자는 리전에 위치한 가용영역의 수 이다

재난이나 사고로 가용영역이 사용불가능해지더라도 다른 영역에 백업한 데이터를 활용하여 서버 가동.
-> 높은 가용성과 내구성을 보장

• 이점 : 정적 웹사이트 호스팅이 가능하다
  • 정적 웹 페이지 : 파일 서버에 미리 저장된 파일을 그대로 전달하는 웹 페이지
  • 웹 호스팅 : 서버의 한 공간을 임대
  • 버킷에 정적 웹 페이지를 업로드하고 정적 웹 사이트 호스팅 용도로 구성을 바꾸면, 다른 사용자가 버킷에 저장된 정적 웹 페이지에 접근할 수 있다.
• 버킷 : S3에 저장되는 파일들이 담기는 바구니 (최상위 디렉토리)
  무한한 양의 파일을 저장가능
  각각의 버킷이름은 해당 리전 내에서 고유해야함
  버킷 정책을 생성하여 다른 유저의 접근 제어가능
• 객체 : S3에서 버킷에 담기는 파일을 객체라고 부름
  저장소에 데이터를 저장할 때 키-값 페어 형식으로 데이터를 저장하기 때문
  URL 주소는 http://[버킷의 이름].S3.amazonaws.com/[객체의 키]의 형태를 띄고,
  URL 주소를 통해서도 원하는 데이터에 접근할 수 있음.

(리액트를 build하여 해당 내용을 업로드해서 배포하는 방식으로 실습해봤다)

Route53

• 도메인 서비스
• 기본적인 도메인이 주어지는데, 너무 길고 직관적이지 않아서
  도메인을 구매해서 사용하는 방법이 있다.