42page

Intro to Cloud Computing

August 8th 2020

Contents

  • Objectives

  • Overview

    • Benefits of Cloud Computing
    • Cloud History
    • Types of Cloud Computing
    • Deployment Models
    • Public Deployment Model
    • Private Deployment Model
    • Hybrid Deployment
    • Major Providers
    • Cost
    • Edge Cases

  • Cloud Computing Fundamentals

    • Characteristics
    • Virtualization

  • AWS Console & Access

    • IAM
    • S3

  • Compute Services

    • Instance Types
    • Auto Provisioning
    • Security Group
    • Elastic IP Address
    • I
  • Databases and Serverless Architecture
  • Resources

Objectives

  • 서비스 제공 업체 차이점 알기
  • Public or Private Deployment 차이점 알기
  • 클라우드 비용 계산
  • AWS 콘솔 이용
  • 클라우드 서비스 이용 위한 인증
  • S3에 파일 저장하기
  • AWS EC2에 Linux VM 띄우기
  • S3에서 데이터를 가져와 EC2 Instance 초기 설정 자동화
  • API Gateway, Lamda, Redis Database를 이용한 간단한 serverless app 만들기

Overview

클라우드 컴퓨팅을 사용하지 않는 경우 on-premise 환경에서 개별 회사가 자체적으로 컴퓨팅 파워나 저장 공간 등을 관리했습니다. 하지만, 클라우드 컴퓨팅이 나온 후 자체적으로 설비를 관리할 때에 얻지 못하는 여러 좋은 점들이 생겨나게 되었습니다.

the Benefits of Cloud Computing

우선 compute, storage를 빠르게 스핀업 할 수 있기 때문에 클라우드 환경에서 소프트웨어를 빠르게 개발할 수 있습니다. 그리고, 비즈니스 환경에 맞게 자동적으로 스케일 업, 다운을 할 수 있습니다. 비용적인 면에서 더 좋을 수 있습니다. 예로 하루에 세 시간만 서비스 작동이 필요하다면 세 시간에 대한 비용만 지불할 수 있습니다. 마지막으로 여러 지역에서 서비스가 제공되기 때문에 이용성 측면에서도 좋습니다.

Cloud History

클라우드 컴퓨팅이 존재하기 전 웹사이트 호스팅을 위해 데이터센테에서 물리적인 서버를 렌트했습니다. 웹사이트는 하나의 서버를 공유하고 각 웹사이트는 서버 내 폴더에 가상의 웹 서버를 가졌습니다. 각 웹사이트는 서버에 어떤한 것을 인스톨 할 수 없었고, 확장성, 탄력성(resiliency)등의 불편함이 존재했습니다.

이후 호스팅 업체는 가상화방식으로 변화했고, 하나의 물리적인 머신에 여러 가상화된 서버를 띄워 개별 고객이 독립적인 가상화된 서버를 사용할 수 있도록 했습니다. 고객은 해당 서버에 OS를 설치하고 서버 설정을 할 수 있게 되었어요.

알다사피 아마존은 amazon.com을 통해 도서를 판매하는 회사였고, 사업이 확대되며 다양한 제품군 판매를 하게 되었습니다. Amazon.com 지원을 위해 인프라도 덩달아 성장하게 되어, 남는 자원을 다른 회사에 렌팅하는 사업을 구상했습니다. 이후 Amazon Web Service를 만들어 Elastic Cloud Compute(EC2), Simple Storage Service(S3)를 런칭합니다.

Types of Cloud Computing

클라우드 컴퓨팅에는 Infrastructure as a Service, Platform as a Service, Software as a Service 이렇게 크게 세 가지 종류가 있습니다.

Infrastructure as a Service (IaaS)

IaaS는 Cloud Infrastructure Services로도 불리며 확장성과 자동화를 갖추고 사용자가 on-premise 컴퓨팅 리소스의 이점을 누릴수 있도록 하는 클라우드 컴퓨팅입니다. 사용자는 IaaS를 통해 리소스에 접근할 수 있으며 컴퓨터를 모니터링 하고, 네트워킹, 데이터, 운영 체제를 다를 수 있습니다.

IaaS 특징

  • 리소스가 서비스로 제공됨.
  • 비용은 사용량에 따라 달라짐.
  • Scalable
  • 여러 유저가 하나의 하드웨어를 공유
  • 사용자가 인프라를 제어 가능
  • Dynamic, flexible

Platform as a Service (PaaS)

일반적인 클라우드 환경의 컴퓨터를 관리하는 것은 간단하지 않습니다. PaaS는 서버나 네트워킹 설정 작업을 대신해 주기 때문에 개발자가 기본 인프라에 대한 걱정 없이 애플리케이션 개발에만 집중할 수 있도록 해줍니다. PaaS는 가상화 기술에 기반을 두고 있어 쉽게 스케일 업, 다운이 가능합니다. 테스트나 배포 관련 서비스를 이용할 수도 있고, 코드로도 플랫폼에 접근할 수 있기에 손쉽게 여러 개발 환경이나 실섭을 배포할 수 있습니다. 웹서비스와 데이터베이스를 쉽게 통합할 수 있어 개발을 좀 더 손쉽게 할 수 있습니다. PaaS로 Heroku를 예로 들 수 있습니다.

PaaS 특징

  • 가상화 기술에 기반해 Scalable 함
  • 개발, 테스트, 배포 관련 다양한 서비스를 제공
  • 여러 유저가 접근 가능
  • 웹서비스, 데이터베이트 Intergration

Software as a service (SaaS)

SaaS는 Google Docs, Google Sheets와 같이 별도의 설치 없이 써드 파티 소프트웨어를 이용할 수 있게 해 줍니다. 사용자는 유지, 관리에 대한 어떠한 부담도 없이 필요시에 제공하는 소프트웨어를 사용할 수 있습니다.

  • 관리 필요 없음. 그냥 사용하면 됨.

Deployment Models

클라우딩 컴퓨터 배포 모델에도 몇 가지 선택지가 있으며, 각 모델은 비용, 보안, 복장성, 유연성 등에서 차이점이 있으니 언제 어떠한 모델을 사용해야 할 지 알고 사용해야 좋겠네요.

Public Deployment Model

가장 일반적인 모델이며 compute, storage, network와 같은 리소스를 공유하기에 비용상 이점이 있습니다. 사용한 만큼만 비용을 지불하면 됩니다.

Private Deployment Model

개별적으로 네트워크 설정이 필요한 공공기관이나 금융업계에서 종종 사용하는 모델입니다. 리소스가 공유되지 않아 인프라 제어에 대한 권한이 더 큽니다.

Hybrid Deployment

Public과 Private의 장점을 합쳐 만든 Deployment 모델입니다. private과 같이 사용할 수 있지만, public으로 전환이 가능해 비용적인 장점도 취할 수 있습니다.

Major Providers

주요 클라우드 프로바이더로 AWS, GCP, Azure가 있습니다. 크게 보면 각 서비스는 비슷하지만 지역적 유효성, 마켓쉐어, 서비스, 가격 등 몇몇 차이점이 존재하기 때문에 차이점을 알아보고 선택해 사용하면 좋을 것 같습니다.

유저와 서버를 가까이 위치 시킬수록 엔드 유저가 빠르게 접속이 가능해집니다. 가낭 넓은 범위를 제공하는 업체를 선택할 수도 있지만, 그 외에 다른 점도 고려해야 할 수도 있습니다. 예로, 중국의 경우 AWS는 별개의 계정으로 본토에서 이용이 가능하도록 서비스를 제공합니다. 반면, GCP는 초고속 해저 케이블을 가지고 있고 홍콩에 서비스를 제공하고 있습니다. 하지만, 중국 본토에서 항상 접근이 가능한 것은 아닙니다.

Cost

AWS Pricing Calculator를 이용하면 견적을 미리 확인해 볼 수 있습니다. 아래의 서버를 예로 견적을 확인해 보아요.

EC2

  • Region: Asia Pacific (Seoul)
  • Instanse type: t2.medium on-demand
  • Storage of instance 250GB

S3

  • S3 standard with 200GB storage per month
  • 각 이미지 당 1MB -> 200,000 put request per month

위 스펙을 pricing calculator를 이용해 견적을 확인해 보면 아래와 같습니다.

Edge Cases

일부 경우는 클라우드 서비스 이용 시 비용이 더 발생할 수 있습니다. GPU 머신러닝을 클라우드 서비스를 이용하면 실제 GPU 서버를 구축하는 것 보다 비용이 더 산출될 수 있습니다. 또다른 경우는 보안이나 규정 문제로 private deployment model을 이용할 때 입니다. 추가로, 클라우드 서비스 자체에서 많은 부분을 관리해 주지만 전문적인 지식을 필요로 하기 때문에 이러한 인력이 없는 경우 좋은 선택이 아닐 수 있습니다.

Fundamentals

Characteristics

클라우드 컴퓨팅에 대한 이해를 높이려면 가상화에 대해 알아야 해요. 가상화를 이용해 공유된 저장 공간, 네트워킹, 컴퓨팅 파워 등을 유저들에게 제공할 수 있기 때문이에요. 이 가상화가 가져오는 특징에 대해서도 살펴봐야 하는데, 크게 아래와 같이 나열해 볼 수 있습니다.

  • Managed Services
  • On-demand Services
  • Scalability
  • Elasticity
  • Security

Virtualization

가상화는 여러 운영체제를 한 대의 서버에서 동작할 수 있게 해 줍니다. 이렇게 여려 OS를 작동할 수 있도록 필요한 소프트웨어를 hypervisor라고 해요. 호스트(물리적 서버)는 설정된 메모리, 디스크, CPU를 각 VM에 할당합니다. 각 VM은 호스트의 리소스를 공유하지만, 다른 VM으로부터 온전히 독립 돼 있고 서로의 존재 또한 인지하지 못 합니다. 클라우드 컴퓨팅 서비스에서 이 가상화가 많은 비중을 차지합니다.

추가로, VM이 거의 사용되지 않거나 대기만 하고 있는 상태가 대부분이라면, 리소스를 아끼기 위해 컨테이너나 Serverless Function을 이용하는 것도 고려해 볼 수 있습니다.

AWS Console & Access

AWS Console을 이용해 서비스 및 접근에 대해 설정할 수 있습니다. AWS의 IAM(Identity and Access Management)을 이용하면 특정 유저에게 특정 EC2 인스턴스나 S3버켓, 또는 S3버켓의 특정 파일에만 접근할 수 있도록 설정할 수 있습니다.

그러면 S3 버켓을 생성하고 IAM에서 Policy를 설정 후 해당 버켓에 접근 가능한 유저를 생성해 보며 기본적인 기능을 익혀 보도록 할게요.

MFA(Multi-Factor Authentication)

IAM을 다루는 이유 중 하나는 보안을 위해서 이기도 한데요, 보안을 위해 추가로 MFA를 설정해 주는 것이 좋습니다. 기존의 username, password 뿐만 아니라 추가로 핸드폰으로 전달되는 일시적인 코드를 입력하는 인증 단계를 추가하는 것이에요.

종종 다른 클라우드 서비스를 사용하는 3rd party 서비스에 접근을 허용해야 하는 일이 생길 수 있어요. 이러한 경우는 MFA를 사용하지 못 하고, 대신 접근 허용 범위를 엄격히 하는 IAM Policy를 설정을 하고, credential도 주기적으로 변경해 주는 것이 좋습니다.

AWS Console 로그인 후 내 보안 자격 증명에서 설정할 수 있습니다.

IAM (Identity and Access Management)

IAM은 AWS의 리소스를 안전하게 관리할 수 있도록 하는 매니징 서비스입니다. IAM이 하는 역할은 크게 인증(Authentication)과 허가(Authorization)입니다. 누가 리소스에 접근할 수 있고, 또 어떠한 작업을 허용할 지 설정할 수 있습니다. 리소스에 대한 접근 권한은 IAM Policy에 의해 주어지는데, Policy는 리소스에 직접 적용될 수도 있고, user 또는 role에 적용될 수도 있습니다. IAM에서 User, group, role 생성에 대한 별도 비용은 없습니다.

IAM USER

IAM User는 AWS 리소스에 접근 가능한 유저 입니다. AWS 콘솔 및 Access Key, Secret Key를 통해 프로그래밍 적으로 접근할 수 있습니다. 유저에는 가능한 최소 법위로 접근 범위를 할당하는 것이 에러나 오용의 가능성을 줄이는 데 도움이 됩니다. User에 대한 Permission은 built-in policy를 사용할 수도 있고 Inine 또는 Custom Policy를 사용할 수도 있습니다.

IAM Policy

IAM Policy는 effect, actions, resources를 포함하고 있습니다. effect의 값은 allow 또는 deny 입니다. action은 리소스에 허용 가능한 액션 리스트이고, resources는 이러한 action이 적용되는 리소스 리스트에요. IAM의 기본값은 모든 action을 Deny하는 것이며, action 허용을 위해서는 새 Policy를 생성해야 합니다. 또한, denied policy를 명시적으로 추가해 주면 이전의 값은 무시하고 해당 action은 deny 됩니다.

IAM Policy는 JSON 문서로 형식화 돼 있어요.

ARN(Amazon Resourse Name)과 같이 Policy를 JSON 파일로 사람이 직접 다루면 실수하기 쉽기 때문에 AWS에서는 쉽게 다룰 수 있는 에디터를 제공합니다.

기본적인 흐름을 파악했으니, AWS Console에서 "Administrator"란 IAM User를 생성하고, 아래 Permission을 추가해 봅시다.

  • IAM Full Access permissions
  • S3 Full Access permissions
  • EC2 Full Access permissions

User를 생성했다면, 로그아웃 후 생성한 유저로 다시 접속해 보고, 접속 시 MFA 절차까지 진행해 보아요.

S3 (Simple Storage Service)

S3는 인터넷 공간에 데이터를 저장하는 서비스입니다. 내구성이 좋다고 하는데, S3에 10,000개의 데이터를 저장했다고 가정 한다면 S3에서 이 중 한 개를 잃어버리기 위해 약 10년이 걸린다고 합니다. region에 따라 데이터를 저장하지만, 다른 zone에도 정기적으로 백업을 한다고 합니다. 파일이나 폴더를 저장할 수도 있고, 파일이나 Static Website를 호스트 할 수도 있으며, DNS Endpoint를 가질 수 있어요.

Compute Services

EC2는 2006년 서비스를 시작으로, AWS의 Compute Service 중 핵심이며, 많이 사용되고 있는 서비스입니다. 그럼, EC2 설정 및 운용과 관련된 아래 내용에 대해 알아보겠습니다.

  • Instance Type
  • Provisioning
  • Security Groups
  • Static IP Address

EC2를 생성하고 중지, 종료하는 방법에 대해서는 AWS 공식 문서에 잘 나타나 있으니 참고해 주세요. 클릭 몇 번으로 손쉽게 컴퓨터 한 대를 생성할 수 있습니다.

Regions and Availability Zones

AWS는 하드웨어를 지역(region)으로 구분해 각 지역에 2 ~ 6개의 데이터센터를 운영하고 있어요. 각 데이터센터를 availability zone이라 하는데, 이 zone은 fiber-optic 케이블로 연결 돼 있습니다.

Instance Types

EC2는 용도에 따라 다양한 종류의 인스턴스 타입이 있습니다. 타입별 CPU, 메모리, storage, 네트워킹 스펙이 다릅니다. 크게 범용(M 시리지), 컴퓨팅 최적화 시리즈(I, D 시리즈), GPU 최적화(G 시리즈), 메모리 최적화(R 시리즈)로 나눌 수 있습니다. 인스턴스 구매 옵션도 여러가지가 있습니다.

  • On-Demand: 필요 시 생성해서 사용하는 방식이며, 초 단위 비용 지불
  • Reserved: 1, 3년 등 기간 약정을 통해 좀 더 저렴한 비용으로 지불
  • Spot: 경매 방식으로 높은 가격을 입찰한 사용자에게 할당
  • Dedicated: 전용 하드웨어에서 인스턴스 제공

또한, 클라우드 환경에서 자동 스케일업은 중요합니다. EC2에서 커스텀 스크립트를 이용해 인스턴스 초기 부팅 시 소프트웨어 설정을 할 수 있습니다.

AWS에서 EC2 인스턴스를 생성하는 과정에서 아래 설정 화면을 보게 됩니다.

아래와 같은 명령어를 추가해 줄 수 있습니다.

#!/bin/bash

yum update -y

amazon-linux-extras install nginx1.12 -y

service nginx start

위 스크립트는 컴퓨터에서 실행 가능한 파일이며, 올바른 실행을 위해 인터프리터 지정을 위해 셔뱅을 추가해 줍니다. 그리고, nginx 웹서버를 설치하는 명령어 입니다.

위 명령어는 인스턴스가 맨 처음 부팅 시 실행이 됩니다.

인스터스를 실행 후 조금 기다린 후 해당 인스턴스의 IP로 접속을 하면 nginx가 정상적으로 설치된 것을 확인할 수 있습니다.

지금은 nginx의 기본적인 웹페이지를 보여주지만, 이후 S3와 연결해 실제 작성한 웹앱을 연결해 보도록 하겠습니다.

Auto Provisioning

클라우드 상 auto scale up과 인스턴스 설정 및 런칭 자동화는 운영 상 중요합니다. 각각의 인스턴스를 직접 설정하려면 휴먼 에러가 발생하기 쉬울거에요. EC2와 같은 클라우드 서비스를 이용하면 인스턴스를 초기 스크립트 설정으로 운영이 가능하도록 해 줍니다.

Security Groups

AWS에서는 Security Group을 설정해 누가, 어떠한 방식으로 리소스에 접근할 수 있는지에 대해 규정할 수 있습니다. Security Group은 인바운드, 아웃바운드 트래픽을 제어할 수 있는 가상의 방화벽 역할을 합니다. 보안 그룹은 EC2 인스턴스 수준에서 적용되기 때문에 네트워크 트래픽에 대한 '허용'만 가능하며, '차단' 기능은 사용할 수 없습니다. 네트워크 서브넷 수준의 흐름을 제어할 수는 없습니다. 차단 정책을 적용하기 위해서는 VPC(Virtual Private Cloud)의 기능인 네트워크 ACL 기능을 이용해야 합니다.

Elastic IP Address

인스턴스의 기본 Public IP 주소는 인스턴스를 재시작 할 때마다 변경이 됩니다. 반면 elastic IP 주소는 퍼블릭이며 인터넷 상에서 접근이 가능한 주소입니다.

우리가 생성한 EC2 인스턴스가 인터넷 세상과 만나기 위해서는 퍼블릭 IP 주소가 필요합니다. AWS의 Elastic IP 주소는 사용을 하지 않고나, 연결된 인스턴스가 운영되지 않으면 요금이 부과됩니다.

생성한 EC2 인스턴스에 엘라스틱 IP 주소를 할당하는 방법은, 아래 AWS 공식 문서를 참고해 주세요.

IAM Role

IAM Role을 생성하면 EC2 인스터스에 특정 자원에 대한 접근 권한을 부여할 수 있습니다. 장기간의 접근 권한이 아니고 일시적인 것이라 IAM user보다 더 보안성이 있습니다. 특정 서비스의 일부 접근에 대한 권한을 설정해 놓고, AWS 서비스 간 커뮤니케이션 시 이용할 수 있습니다.

IAM Role에 대한 세부 개념 및 생성 방법은 아래 링크를 참고해 주세요.

우리는 EC2 인스턴스에 S3에 접근할 수 있는 IAM role을 생성할 수 있고, 해당 인스턴스는 매 15분마다 일시적인 credential 갱신을 요청할 것입니다.

그럼 EC2 인스턴스를 생성하고, IAM Role을 적용해 S3에 인스턴스가 접근한 후 nginx의 기본 앱을 대신하는 다른 정적 앱을 보여주는 방법에 대해 살펴볼게요.

위에서 언급한 AWS 공식 문서에 잘 나와 있지만, EC2에 부여할 IAM Role 생성을 위해 아래 절차를 따를 수 있습니다.

  1. IAM 콘솔로 이동합니다.
  2. Role을 클릭 후 Create Role 버튼을 클릭합니다.
  3. EC2 인스턴스에 부여하기 위해, use case에서 EC2를 선택하고 Next Permissions 버튼을 클릭합니다.

이후 Review Page에서 향후 참조할 Role Name및 Description을 입력해 줍니다. Create Role 버튼을 클릭하면 Role이 생성됩니다.

IAM Policy 생성 후 Role에 추가하기

  1. IAM의 Policy 탭에서 Create Policy 버튼을 클릭합니다.
  2. S3 서비스를 선택합니다.
  3. Actions란에서 원하는 action을 선택해 주면 되는데, 여기서는 ListBucket과 GetObject를 선택했습니다.
  4. Resource란에서 Add ARN을 클릭하고, 접근 허락을 할 S3 버켓 이름을 추가해 줍니다.
  1. 이후 리뷰 후 생성 버튼을 클릭해 Policy를 생성합니다.

그리고 다시 Role로 돌아가서, 앞서 작성한 role을 이름으로 검색 후 선택 후 방금 작성한 Policy를 추가해 줍니다.

EC2 인스턴스에 배포할 웹 페이지 압축파이(zip파일)을 위에서 접근을 허락한 S3 버켓에 추가해 줍니다.

지금까지 원하는 S3 버켓에 접근 가능한 Policy 및 Role을 생성 후, 해당 S3 버켓에 웹앱 파일을 업로드 한 상태입니다. 이제 EC2 인스턴스를 생성 후 init script에서 S3 버켓에서 업로드한 웹페이지를 불러와 nginx 기본 페이지 대신 보여주도록 연결하면 됩니다.

nginx의 새로운 페이지를 설정해 줘도 되지만, 기본 페이지를 대체하도록 하는 명령어 입니다.

   #!/bin/bash

   BUCKET_NAME=<여기에 S3 버켓 이름을 입력해줍니다.>
   yum update -y
   amazon-linux-extras install nginx1.12 -y
   service nginx start
   aws s3 cp s3://${BUCKET_NAME}/web/startbootstrap-sb-admin-2-gh-pages.zip /tmp/
   cd /tmp
   unzip start*
   mv startbootstrap-sb-admin-2-gh-pages html
   rm -rf /usr/share/nginx/html
   mv /tmp/html /usr/share/nginx/

위 명령어를 간단히 살펴보면, 우선 nginx를 설치합니다.

그리고 S3버켓의 web 폴더 내 startbootstrap-sb-admin-2-gh-pages.zip 파일을 tmp 폴더로 복사 및 압축을 풉니다.

마지막으로 /usr/share/nginx/html 폴더의 내용물을 압축을 푼 폴더로 대체합니다.

인스턴스가 작동을 하고 잠시 기다린 뒤 퍼블릭 IP로 접속을 하면, 대체한 웹앱를 확인할 수 있습니다.

Resources

© Chanwhe Kim 2019

Handmade with .