Cloud - 운영 환경 구성 1

Amazon Web Service

Cloud Computing

기존 서버의 방식

• 클라우드 등장 이전에는 흔히 말하는 전산실 등에 컴퓨터를 배치하고 인터넷을 연결하여 서비스를 제공하였음
• 서버가 요청에 대한 수용 능력이 한계에 도달할 경우
  • 같은 공간에 더 많은 컴퓨터를 제공하여 한 대가 해결할 수 있는 요청을 여러 대가 나누는 방식을 사용할 수 있음
  • 또는 컴퓨터 한 대의 성능을 높이는 방식을 사용할 수도 있음
  • 이런 방식들의 문제점
    • 주기적인 관리가 필요함
    • 공간의 한계가 있음
  • 추가적인 서버 증설이 어렵게 되자 일부 거대 기업은 데이터 센터라는 거대한 건물을 세우기 시작했으며, 이때부터 데이터 센터의 유휴 자원을 대여하는 서비스가 등장하기 시작하였고, 서버의 자원과 공간, 및 네트워크 환경을 제공을 빌려 사용하는 클라우드 컴퓨팅이 시작됨

클라우드의 등장

• 데이터 센터에서는 서버의 자원과 공간, 및 네트워크 환경을 제공하며, 이런 환경을 '온프레미스'라고 부름
• 현대의 클라우드 컴퓨팅은 앞서 설명한 데이터 센터와 비슷한 역할을 하지만, 물리적인 컴퓨터가 아닌, 가상 컴퓨터를 대여한다는 점이 다르며, 이는 가상화(Virtualization) 기술의 발전으로부터 비롯되었음
• 최근의 가상화 기술을 사용하는 클라우드 서비스의 장점
  1. 필요할 때마다 컴퓨팅 능력을 유연하게 조절할 수 있음
  2. 고정적인 비용이 들어가는 온프레미스와는 달리 사용한 만큼의 요금만 지불하면 됨
  3. 컴퓨터의 스냅샷("이미지") 을 이용해 다른 컴퓨터로 즉시 이주(migration)가 가능함
• 클라우드 서비스의 단점
  • 운영 환경 자체가 클라우드 제공자에게 종속되어 버리므로, 클라우드 서비스에 문제가 생기면 내가 배포하고 관리하는 환경에도 영향을 미침
    • 운영환경이 특정 클라우드 사업자(vendor)에게 종속된다는 얘기는, 백엔드 구성 자체가 특정 회사의 기술로만 구성해야만 하는 경우가 발생할 수도 있다는 의미
    • AWS와 같은 대표적인 클라우드 사업자가 제공하는 기술을 익히는 것도 중요하지만, 그만큼 이 인프라 자체에 대한 이해가 더욱 중요함
• 클라우드는 모든 것을 서비스화하는 것을 목표로 하며, 대표적인 클라우드 서비스의 형태는 SaaS, IaaS, PaaS가 있음
  • SaaS
    • Software as a Service의 약자
    • 클라우드 제공자가 당장 사용 가능한 소프트웨어를 제공하는 경우 대부분 SaaS에 해당함
  • PaaS
    • Platform as a Service의 약자
    • 클라우드 제공자가 데이터베이스, 개발 플랫폼까지 제공하는 경우 대부분 PaaS에 해당함
  • IaaS
    • Infrastructure as a Service의 약자
    • 클라우드 제공자가 가상 컴퓨터까지 제공하는 경우 대부분 IaaS에 해당함\

---

Deploy

• 배포란 개발한 서비스를 사용자들이 이용 가능하게 하는 일련의 과정
• 회사마다 추가적인 과정이 있을 수 있지만, 기본적으로 4단계를 거쳐서 개발한 서비스를 배포하게 됨
  

1. Development 단계는 각자의 컴퓨터에서 코드를 작성하고 테스트하는 과정
   • 개발 단계이기 때문에 실제 데이터를 이용하지 않고 더미 데이터를 이용해서 테스트 함
2. Integration 단계는 각자의 컴퓨터에서 작성한 코드를 합치는 과정
   • 내가 작성한 코드가 다른 코드를 침범해서 오류를 일으키지 않는지, 코드 간에 conflict가 있지는 않은지 확인하는 과정을 거침
3. Staging 단계에서는 실제 출시 단계인 Production 단계와 가장 유사한 환경에서 테스트를 진행함
   • 실제 데이터를 복사해서 문제가 있지 않은지 등 다양한 환경에서 테스트를 진행함
   • 서비스와 관련된 부서 혹은 인원의 확인 과정을 거침
   • 예를 들면 작성된 코드가 마케팅팀 혹은 디자인팀이 예상했던 결과인지 확인을 거치는 과정
4. Production 단계는 개발된 서비스를 출시하는 단계
   • 사용자가 접속할 수 있는 Production 환경에서 코드를 구동하고 서비스를 제공함
   • 실제 데이터를 가지고 서비스가 운영되기 때문에 문제가 생기면 안 되는 단계
     

• Development 환경과 Production 환경은 서로 다를 수가 있음

  • 개발부터 배포까지 모든 것을 통제할 수 있는 상황이라면, 크게 걱정 없이 Production 환경을 구성할 수 있겠지만, 여러 명이 함께 작업하는 프로젝트라면 jdk 버전도 제각각일 수 있고, 인증 정보나 데이터베이스 등에 접근하기 위해 사용하는 엔드포인트도 제각각일 것으로, 이처럼 Development 환경과 Production 환경은 서로 다를 수가 있음
  • 배포에서는, 환경의 차이를 이해하고 환경 설정을 코드와 분리하는 것이 중요함
    

• 작성한 코드가 다른 환경에서 정상 작동할 수 있게 하려면, 설정을 환경 변수(environment variable; envvars나 env라고도 불림)에 저장해야 함

• 환경 변수는 코드 변경 없이 배포 때마다 쉽게 변경할 수 있으며, 설정 파일과 달리, 잘못해서 코드 저장소에 올라갈 가능성도 낮음

• 애플리케이션의 모든 설정이 정상적으로 코드 바깥으로 분리되어 있는지 확인할 수 있는 간단한 방법은 어떠한 인증정보도 유출시키지 않고 코드가 지금 당장 오픈 소스가 될 수 있는지 확인하는 것

  
  

• 작성한 코드가 다른 환경에서 정상 작동할 수 있게 하는 방법

  • 절대경로 대신 상대경로를 사용함
  • 환경에 따라 포트를 분기할 수 있도록 환경변수를 설정함
  • Docker와 같은 개발 환경 자체를 통일시키는 솔루션을 사용함

---

EC2

• 아마존 웹 서비스에서 제공하는 클라우드 컴퓨팅 서비스

• 클라우드 컴퓨팅은 인터넷(클라우드)을 통해 서버, 스토리지, 데이터베이스 등의 컴퓨팅 서비스를 제공하는 서비스로, 아마존에서 가상의 컴퓨터를 한 대 빌리는 것과 같음

  
  

• Amazon EC2(Elastic Compute Cloud)

  • AWS에서 제공하는 Elastic Compute Cloud 서비스 앞에 붙은 Elastic이라는 단어는 사용한 만큼비용을 지불하기 때문에 '탄력적인'이라는 의미
  • Elastic은 비용적인 부분뿐만이 아니라 필요에 따라 성능, 용량을 자유롭게 조절할 수 있다는 의미도 가지고 있음
  • EC2 서비스는 AWS에서 비용, 성능, 용량 면에서 탄력적인 클라우드 컴퓨터를 제공하는 서비스라고 할 수 있음

EC2 사용의 이점

1. 구성하는 데 필요한 시간이 짧음
2. AMI를 통해서 필요한 용도에 따라 다양한 운영체제에 대한 선택이 가능함
   • EC2에서는 AMI라는 다양한 템플릿을 제공하고 있어서 필요에 따라 손쉽게 운영체제를 선택하고 구성할 수 있음
     • AMI는 소프트웨어 구성이 기재된 템플릿
     • 이미지 종류로는 단순히 운영체제(윈도우, 우분투 리눅스 등)만 깔려있는 템플릿을 선택할 수도 있고, 아예 특정 런타임이 설치되어 있는 템플릿이 제공되는 경우도 있음(우분투 + node.js, 윈도우 + JVM 등)
   • 운영체제뿐만이 아니라 CPU와 RAM, 용량까지도 손쉽게 구성할 수 있음
3. EC2는 컴퓨터를 한 대 빌리는 것이므로 컴퓨터로 할 수 있는 모든 일을 할 수 있음
   • 빌린 컴퓨터는 직접 사용하는 컴퓨터와 다르게 아마존이 전 세계에 만들어 놓은 데이터 센터(인프라)에 만들어져 있기 때문에 컴퓨터를 조작하기 위해 네트워크(인터넷)를 통해서 컴퓨터를 제어해야 한다는 차이점이 있을 뿐 일반적인 컴퓨터와 다른 점은 없음
   • 아마존 EC2를 통해서 할 수 있는 가장 기본적인 일은 웹서버를 설치하고 웹 서버를 통해서 사용자가 웹 브라우저를 통해 요청하는 서비스를 제공하는 것
   • 인스턴스는 1대의 컴퓨터를 의미하는 단위이고 AWS에서 컴퓨터를 빌리는 것을 인스턴스를 생성한다고 함
     • Instance는 선택한 AMI를 토대로 구성됨
     • AWS에는 상당히 많은 양의 AMI 세팅이 준비되어 있기 때문에 손쉽게 인스턴스의 운영체제를 구성할 수 있음
     • 세팅되어 있는 AMI 이외에도 필요에 따라 직접 AMI를 구성할 수도 있음
     • AWS EC2 인스턴스를 생성한다는 것은 AMI를 토대로 운영체제, CPU, RAM 혹은 런타임 등이 구성된 컴퓨터를 빌리는 것

RDS

• Relational Database Service의 약자로 AWS에서 제공하는 관계형 데이터베이스 서비스
  

RDS 사용의 이점

• EC2 인스턴스를 사용하면 데이터베이스와 관련해서 자동으로 관리를 담당하는 부분이 매우 적기 때문에, 사용자가 일일이 시간을 투자하여 데이터베이스 엔진의 설치와 버전 관리, 데이터 백업을 해야 함
• 가용성과 내구성이 확보되지 않기 때문에 데이터베이스에 저장된 데이터가 유실되거나 정상적으로 사용하지 못할 확률이 커지며, 후에 필요에 따라 데이터베이스의 규모를 확장하기 어려움

• RDS를 이용하면 데이터베이스 유지 보수와 관련된 일들을 RDS에서 전적으로 자동 관리함

• 사용자가 해야 할 일은 초기 설정을 제외하고 데이터베이스에 저장된 데이터를 관리하는 일 밖에 없기에 큰 편의성을 느낄 수 있음

  
  

• 기타 RDS 이용 시 얻을 수 있는 장점으로 다양한 데이터베이스 엔진 선택지를 제공한다는 점을 들 수 있음

• 회사에서 근무하고 있는 실무자는 회사에 필요한 데이터베이스 엔진을 취사선택하여 이용할 수 있음

• 일반 사용자는 데이터베이스 엔진마다 제공하는 기능이 조금씩 다르기에 필요와 목적에 맞게 데이터베이스 엔진을 선택하여 효율성을 높일 수 있음

---

S3(Simple Storage Service)

• 클라우드 스토리지란 쉽게 말해서 인터넷 공간에 데이터를 저장하는 저장소로, 컴퓨터 부품으로 비유하면 하드디스크의 역할을 하는 서비스
• 구글의 Google Drive, 네이버의 MYBOX, 마이크로소프트의 Onedrive와 같은 서비스가 좋은 예시
• 클라우드 스토리지 서비스의 장점
  • 클라우드 스토리지 서비스는 뛰어난 접근성을 가지고 있음
  • 컴퓨터의 하드디스크에 저장된 파일에 접근하기 위해서는 해당 컴퓨터를 이용해야만 하지만 클라우드 스토리지를 이용하면 웹 환경이라면 언제 어디서나 저장된 파일에 접근할 수 있음
  • 컴퓨터뿐만 아니라 웹에 접속이 가능한 다른 전자기기를 활용하여 클라우드 스토리지에 저장된 데이터에 접속할 수 있음\
• S3는 Simple Storage Service의 약자로 AWS에서 제공하는 클라우드 스토리지 서비스

S3 사용 시 이점

• 높은 확장성
  • 확장성이 높으면 많은 시간과 수고를 들이지 않고 스토리지 규모를 확장/축소할 수 있음
  • S3에서는 스토리지의 용량을 무한히 확장할 수 있으며, 사용한 만큼만 비용을 지불하면 되기 때문에 비용적인 측면에서 매우 효율적
• 강력한 내구성
  • 스토리지의 내구성이 높으면 저장된 파일을 유실할 가능성이 적어지며, S3는 99.999999999%의 내구성을 보장함
• 99.99%의 가용성 보장
  • 가용성이 높으면 스토리지에 저장된 파일들을 정상적으로 사용할 수 있는 시간이 길어짐
  • S3는 연간 99.99%의 스토리지 가용성을 보장하도록 설계가 되어 있으며, 이는 1년 동안 S3에 파일을 저장했을 시, 8.76 시간 동안만 스토리지를 이용하는 데 있어서 장애가 발생한다는 의미
  • 리전이란 AWS에서 클라우드 서비스를 제공하기 위해서 운영하는 물리적인 서버의 위치를 뜻하며, 리전에는 가용 영역이 위치하고 있음
    • 가용 영역(Availability Zone)이란 각 리전 안에 존재하는 데이터 센터(IDC)를 뜻함
    • 가용 영역은 각각 개별적인 위치에 떨어져서 존재함
    • 한 곳의 가용 영역이 재난이나 사고로 인해 가동이 불가능해지더라도 다른 가용 영역에 백업을 해놓은 데이터를 활용하여 문제없이 서버가 가동되게 함
    • 이런 가동 방식 덕분에 AWS에서 제공하는 서비스들은 높은 가용성과 내구성을 보장함
• 다양한 스토리지 클래스를 제공함
  • 저장소를 어떤 목적으로 활용할지에 따라 효율적으로 선택할 수 있는 스토리지 클래스가 달라짐
  • S3 사용자들이 대표적으로 많이 선택하는 스토리지 클래스는 Standard 클래스와 Glacier 클래스로 두 가지가 있음
  • Standard 클래스는 범용적인 목적으로 사용하기 좋으며, 데이터에 빠른 속도로 접근할 수 있고, 데이터 액세스 요청에 대한 처리 속도가 빠름
  • 대신 보관 비용이 높게 발생하기 때문에 데이터를 오래 보관하는 목적으로는 효율적인 선택지가 아님
  • Glacier 클래스는 장기적인 보관 목적으로 스토리지를 사용할 때 효율적
  • 비록 저장된 데이터에 액세스하는 속도는 느리지만, 데이터를 보관하는 비용이 매우 저렴하다는 장점이 있음
  • 이 외에도 Standard-IA, One Zone-IA, S3 Glacier Deep Archive 등등 여러 가지 스토리지 클래스가 존재하여 사용자의 이용 목적에 따라 다양한 스토리지 클래스를 사용할 수 있음
• 정적 웹 사이트 호스팅이 가능함
  • 정적 웹 사이트 호스팅이 무엇인지 알기 위해 '정적' 파일에 대한 이해가 선행되어야 함
    • 정적 파일은 서버의 개입 없이 생성된 파일을 뜻함
    • 반대로 클라이언트가 서버에 요청을 보내면, 서버가 요청에 맞추어 그 자리에서 생성한 파일을 '동적' 파일이라고 부름
  • 웹 호스팅이란 서버의 한 공간을 임대 해주는 서비스를 뜻함
  • S3에서는 버킷이 사용자들이 정적 웹 사이트를 배포할 수 있는 공간을 제공함
    • 버킷이라는 저장 공간에 정적 파일을 업로드하고 버킷을 정적 웹 사이트 호스팅 용도로 구성하면 정적 웹 사이트를 배포할 수 있음

S3의 핵심 개념

버킷

• S3에 저장되는 파일들이 담기는 바구니
• 파일을 저장하는 최상위 디렉터리라고도 설명할 수 있음
• S3에서 저장되는 모든 파일은 버킷 안에 저장되어야 하고, 버킷에는 무한한 양의 파일을 저장할 수 있음
• 각각의 버킷은 이름을 가지고 있는데, 버킷의 이름은 버킷이 속해 있는 리전(버킷이 생성된 지역)에서 유일해야 함
• 버킷 정책을 생성하여 해당 버킷에 대한 다른 유저의 접근 권한을 수정할 수 있음

객체

• 버킷에 담기는 파일을 객체라고 부름
  • S3에서 저장소에 데이터를 저장할 때 키-값 페어 형식으로 데이터를 저장하기 때문에 객체라고 부름
• S3에 저장되는 객체는 파일과 메타데이터로 구성됨
  • 파일의 값에는 실제 데이터를 저장함
  • S3 객체의 값으로써 저장될 수 있는 데이터의 최대 크기는 5TB
  • 파일의 키는 각각의 객체를 고유하게 만들어주는 식별자 역할을 함
  • 파일의 키를 이용하여 원하는 객체를 검색할 수 있음
  • 메타데이터는 객체의 생성일, 크기, 유형과 같은 객체에 대한 정보가 담긴 데이터
  • 모든 객체는 고유한 URL 주소를 가지고 있음
  • URL 주소는 http://[버킷의 이름].S3.amazonaws.com/[객체의 키]의 형태를 띠고, URL 주소를 통해서도 원하는 데이터에 접근할 수 있음

---

3 Tier-Architecture 배포 전략

• 개발한 서비스를 사용자가 이용할 수 있도록 하는 것을 배포라고 함

Client 배포

• AWS에서 제공하는 서비스인 S3라는 서비스를 통해 사용자들에게 Client를 제공할 수 있음
• 로컬 환경에서는 자체 개발 서버(client를 실행하는 서버)를 이용해서 클라이언트 앱을 실행시키는 것이 일반적
• 클라이언트를 위해서 EC2 인스턴스를 사용하지 않고, 클라이언트 앱의 정적 파일 그 자체를 사용하거나 정적 파일로 빌드하여 제공함
• 따라서 S3를 이용해서 클라이언트를 배포함
• AWS에서 제공하는 CDN 서비스인 CloudFront를 통해서 각지의 데이터센터에 데이터를 분산시켜서 저장해 뒀다가 가까운 지역에서 데이터를 주는 방식으로 사용자에게 더 빠르게 서비스를 제공할 수 있음

Server Application 배포

• AWS EC2 서비스를 통해 손쉽게 서버를 구성하고 서비스를 제공할 수 있음
• AWS에서는 Database 특화 서비스인 RDS 서비스를 제공하고 있음
• AWS가 유지 보수 작업을 담당하는 RDS를 이용하여 즉시 데이터베이스를 사용할 수 있음
• RDS 서비스를 이용하여 EC2를 통해 배포된 Server Application의 데이터를 저장, 제공하는 데이터베이스를 배포할 수 있음

DNS

• S3, EC2를 이용해서 배포된 서비스는 IP주소 혹은 AWS에서 제공하는 여러분의 서비스와는 전혀 상관없는 긴 도메인주소를 통해 접근하게 됨
• AWS에서 제공하는 Route 53 서비스를 이용하면 직관적인 도메인 주소를 통해서 서비스에 접근하도록 할 수 있음