AWS

 

 

💡 왜 다들 AWS를 사용하는걸까?

→ AWS 이전, 우리는 온 프레미스 (On- Premise) 방식을 사용했습니다. 이는 전산실에 컴퓨터를 배치하는 방식이었는데, 
    인터넷 사용자가 늘어나고, 프로그램이 많아진 지금 이 방식으로는 인력과 비용이 방대하여 관리하기가 힘들죠.
    이를 위해 AWS 가 나왔습니다. AWS 는 가상화 방식으로, 실제로 서버를 전산실에 배치하는 방식이 아니기 때문에 사용자 수에
    따라서 유연하게 리소스를 늘리고 줄일 수 있습니다. 또한, 트래픽에 대한 대응도 빠르죠.
    무엇보다 이로 인해 비용문제에서 많이 절감됩니다. 모든 것을 편리하게 구축해주며, 수요에 따라 공급해주기 때문에 필요없는 비용 

    이 들지 않는다는 것이죠. 이러한 장점은 개발자와 기업에게 긍정적으로 다가왔습니다. 우리가 AWS를 사용할 수 밖에 없는 이유죠.

 

 

아마존 웹 서비스(AWS) : 아마존 자사의 노하우를 살려 제공하고있는 클라우드 컴퓨팅 서비스

* 서비스를 조합하여 모든 애플리케이션과 인프라 구축이 가능, 인프라를 일괄로 빌릴 수 있게 됐으며, 필요에 따라 소프트웨어까지 빌릴 수 있다.

 

 

클라우드 컴퓨팅

전산실에 컴퓨터를 배치하고 요청을 수용해주는 것은 주기적인 관리가 필요하여 이를 위해 막대한 인력과 비용이 필요하다.

클라우드 컴퓨팅은 데이터 센터와 비슷한 역할을 하지만, 물리적인 컴퓨터가 아닌 가상 컴퓨터를 대여한다.

클라우드는 모든 것을 서비스화 하는 것을 목표로 하며, 대표적으로 SaaS IaaS PaaS 세가지의 클라우드 서비스 형태를 띈다.

클라우드 환경의 단점으로, 운영 환경 자체가 클라우드 제공자에게 종속되어버려 클라우드 서비스에 문제가 생길경우 배포하고 관리하는 환경에도 영향이 미친다.

 

1) EC2(Elastic Compute Cloud) : AWS에서 제공하는 클라우드 컴퓨팅 서비스

(원격으로 제어 가능한 가상의 컴퓨터 한 대 빌리기)

 

장점

구성하는데 필요한 시간이 짧다. (몇 번의 클릭만으로 PC 구성이 가능하다)

AMI를 통해 다양한 운영체제에 대한 선택이 가능하다. (CPU, RAM, 용량까지도 구성 가능)

1개의 인스턴스를 생성하는 것으로, 컴퓨터가 할 수 있는 모든일을 할 수 있다.(사용자가 웹 브라우저를 통해 요청하는 서비스 제공)

 

*AMI : 소프트웨어 구성이 기재된 템플릿

운영체제(윈도우, 우분투 리눅스 ,,,)만 설치된 템플릿 or 특정 런타임이 (우분투 +node.js, 윈도우 + JVM)이 설치되어 있는 템플릿 등을 제공

 

AWS EC2 인스턴스를 생성하기 위해 AMI를 선택, 

선택한 AMI를 토대로 구성이되며 손쉽게 운영체제를 구성할 수 있다. (세팅 이외에 직접 AMI를 구성하는 것도 가능하다)

 

 

 

 

2) RDS(Relational Database Service) : AWS에서 제공하는 관계형 데이터 베이스 서비스

EC2 인스턴스에 데이터베이스를 설치하여 데이터를 관리하는 것은 자동으로 관리를 담당하는 부분이 매우 적다.

사용자가 시간을 투자하여 데이터베이스 엔진의 설치, 버전 관리, 데이터 백업이 필요하다.

또한, 가용성과 내구성이 확보되지 않아, 저장된 데이터가 유실되거나 정상적으로 사용하지 못할 확률도 있으며 규모를 확장하기 어렵다.

 

그에 비해 RDS는 데이터베이스 유지 보수와 관련된 모든 일을 RDS에서 전적으로 자동관리한다.

사용자는 초기 설정을 제외하고 데이터베이스에 저장된 데이터를 관리하는 일만 하면 되기 때문에 큰 편의성을 갖는다.

또한, 다양한 데이터베이스 엔진 선택지를 제공하여, 필요와 목적에 맞게 엔진 선택이 가능하다.

(oracle, amazon aurora, sql server, my sql, maria db, postgre sql..)

 

 

 

3) S3 (Simple Storage Service): AWS에서 제공하는 클라우드 스토리지 서비스

클라우드 스토리지 : 인터넷 공간에 데이터를 저장하는 저장소 (= 하드디스크의 역할)

 

 

💡 S3로 프론트 배포하기

 

1) 버킷 만들기 → AWS 에서 S3로 들어간 후,  주황색 버킷만들기 클릭

 

2) 버킷 이름과, 지역을 설정 (지역 = 서울) 후, 퍼블릭 설정
    → 모든 액세스 차단 혹은 ACL 이용을 하는 것이 보안에 좋지만, 작은 프로젝트라면 3번째를 추천합니다.

    → 암호화 과정도 보안을 위해 서버는 활성화를 켜두는 것이 좋지만, 작은 프로젝트 혹은 테스트를 할 경우 비활성화를 추천합니다.

(버킷만들기 완료)

3) 만들어진 버킷에 들어가 업로드 합니다.
  ✩ 이때, AWS를 통해 서버도 EC2로 만들었다면 프론트에서 .env  파일을 생성하여 서버주소를 추가합니다. (배포시 정확한 연결을 위함)

 

 

build 후, 빌드 된 디렉토리를 업로드 합니다. → 전체 파일이 아닌, 파일 안에 빌드된 폴더를 업로드 합니다.(폴더 자체X 개별 O)

초록색으로 헤더가 변하면 성공적으로 업로드 되었음을 알 수 있습니다.

 

 

 

다시 버킷으로 들어가 속성 탭에서 주소를 클릭했을 때 올바르게 접근이 가능하다면 배포 완료입니다.

✩ 배포가 잘 되지 않을때,
1) 버킷 정책 수정

2) 브라우저 캐시 삭제 
를 시도해보세요.

 

 

장점

데이터를 무한히 저장 가능하다 (확장성이 높으면 스토리지 규모를 쉽게 확대/축소 할 수 있다.)

내구성이 높아 저장한 파일을 유실할 가능성이 적다 (99.9999999999% 의 내구성 보장)

99.99%의 가용성 보장 (스토리지에 저장된 파일을 사용할 수 있는 시간이 길다)

다양한 스토리지 클래스 제공

(standard 클래스: 범용적인 목적, 빠르게 데이터에 접근/처리, 오래 데이터를 보관하는 목적 X(비싸다))

(Glacier 클래스: 장기적인 보관 목적, 데이터에 접근하는 속도는 느리지만 보관 비용이 저렴)

정적 웹 사이트 호스팅이 가능하다.

정적파일: 서버의 개입 없이 생성된 파일 (요청에 맞춰 서버가 생성한 파일 = 동적파일)

웹 호스팅: 서버의 한 공간을 빌려줘 웹 사이트의 배포, 운영을 가능하게 만드는 서비스

>> S3에서는 버킷을 통해 정적 웹 사이트 호스팅을 한다.

 

- 버킷 : S3에 저장되는 파일들이 담기는 바구니 (파일을 저장하는 최상위 디렉터리)

1)무한히 많은 파일 저장 가능

2) 버킷의 이름은 각 리전에서 고유해야한다.

3) 버킷의 정책을 생성하여 액세스 권한 부여 가능

 

객체: 버킷에 담기는 파일 (키- 값 페어 형식으로 저장소에 데이터가 저장되기 때문)

1) 값에는 실제 데이터를 저장 (최대 5TB)

2) 키는 객체를 고유하게 만드는 식별자 역할을 한다.

3) 객체는 파일과 메타데이터로 구성 (메타데이터: 객체의 생성일, 크기, 유형과 같은 객체의 정보를 담은 데이터)

4) 모든 객체는 고유한 URL 주소를 갖음 ( 주소를 통해 객체 접근 가능 )

5) URL 주소 형식: http:// [버킷의 이름].S3.amazonaws.com/[객체의 키]

 

 

 

4) Deploy Strategy : 배포전략

Client 배포 : AWS 의 S3를 통해 Client를 제공할 수 있다. (클라이언트 앱을 정적 파일로 빌드하여 제공)

*빌드: 불필요한 데이터를 없애고, 통합/ 압축 하여 배포하기 최적화된 상태를 만드는 것.

           웹 앱은 배포가능한 정적파일의 형태여야함.

  (빌드 전과 비교하여, 데이터의 용량이 줄어들고 웹 사이트 로딩 속도가 빨라진다.)

 

AWS에서 제공하는 CDN 서비스인 CloudFront를 통해 각 데이터 센터에 데이터를 분산시켜 저장해 뒀다가 가까운 지역에서 데이터를 주는 방식으로 더 빠르게 사용자에게 서비스 제공이 가능하다.

 

Server Application 배포 : AWS의 EC2를 통해 서버를 구성하고 서비스 제공이 가능하다.

                                           AWS의 RDS 서비스를 이용하여, EC2를 통해 배포된 Server Application의 데이터를 저장, 제공하는

                                           데이터 베이스를 배포할 수 있다.

 

 

DNS 접근 : S3, EC2를 이용해 배포한 서비스는 현 IP 주소 or AWS에서 제공하는 서비스와 관련없는 긴 도메인 주소를 통해 접근

                  (직관적이지 않은 주소)

                   AWS의 서비스인 Route53을 이용하면 직관적인 도메인 주소 이용 가능.

 

 

 

 

5) Deploy : 배포

 

Development :  1) Local 환경에서 코드를 작성, 테스트 

                           2) 실제 데이터가 아닌 더미 데이터 사용

                           3) 변경사항이 있어도 문제가 되지 않음

 

Integration :      1) 각자의 환경에서 개발된 (작성된 코드) 부분을 취합

                           2) 코드 간에 conflict가 있는지 확인, 작성한 코드가 다른 코드에 문제를 발생시키는 지 확인

 

Staging :            1) 실제 출시 단계인 Production 단계와 가장 유사한 환경에서 테스트

                           2) 복제된 실제 데이터를 이용하여 테스트

                           3) 모든 관계자들이 확인(검증)하는 과정을 거침.

 

Production :      1)  사용자가 접속할 수 있는 환경에서 코드를 구동하고 서비스 제공

                           2) 실제 데이터를 사용, 문제가 발생되지 않아야 함.

 

 

env (작성한 코드가 다른 환경에서 정상 작동할 수 있게 설정을 환경변수에 저장)

* 환경변수는 코드 변경 없이 배포 때마다 쉽게 변경이 가능하다

 

1) 절대경로 대신 상대경로를 사용

2) 환경에 따라 포트를 분기할 수 있도록 환경변수 설정

3) Docker와 같은 개발 환경 자체를 통일 시키는 솔루션 사용