AWS
클라우드 컴퓨팅
기존 서버 관리 방식의 한계
- 주기적인 유지 관리가 필요함
- 계속 컴퓨터를 추가설치하기에는 공간적인 한계 있음
==> 데이터 센터 등장 및 데이터센터의 유휴자원 대여 서비스 등장 ==> 클라우드 컴퓨팅의 시작
클라우드
전통적 데이터 센터와 비슷한 역할을 하지만,
물리적 컴퓨터가 아닌 가상 컴퓨터를 대여한다는 측면에서 다름
- 가상화 기술을 사용하는 클라우드 서비스의 장점
- 필요 시 컴퓨팅 능력을 유연하게 조절 가능- 고정적 비용이 들어가는 온프레미스와는 달리 사용한 만큼의 요금만 지불하면 됨
- 스냅샷(이미지)를 이용해 다른 컴퓨터로 즉시 이주(migration)이 가능
cf) 온프레미스(on-premise) : 기업의 서버를 클라우드가 아닌 자체적으로 보유한 전산실 서버에서 직접 설치해 운영하는 방식. 클라우드 컴퓨팅 기술이 나오기 전까지의 기업 인프라 구축의 일반적 방식이었음.
- 클라우드 서비스의 단점
- 클라우드 서비스 운영 환경 자체가 클라우드 서비스 제공자(아마존)에 의해 너무 영향 받음
- 클라우드 사업자에 대한 높은 종속성으로 인해 백엔드 구성 자체가 특정 회사의 기술로만 구성해야하는 경우 발생
클라우드 서비스 형태
1. SaaS (Software as a Service)
Vendor가 당장 사용 가능한 소프트웨어를 제공하는 대부분의 경우
2. Paas (Platform as a Service)
Vendor가 데이터베이스, 개발 플랫폼까지 제공하는 대부분의 경우
3. Infrastructure as a Service
Vendor가 가상 컴퓨터까지 제공하는 대부분의 경우
ex) AWS
배포(Deploy)
개발한 서비스를 사용자들이 이용가능하게 하는 일련의 과정
1단계. Development
각자의 컴퓨터에서 코드를 작성하고 테스트 하는 과정
실제 데이터 이용하지 않고 더미데이터 이용해서 테스트함
2단계. Integration
각자 컴퓨터에서 작성한 코드를 합치는 과정
코드 오류 및 코드 간 충돌이 발생하지는 않는지 확인
3단계. Staging
실제 출시 단계인 Production 단계와 가장 유사한 환경에서 테스트 진행
서비스와 관련된 부서의 확인 과정을 거쳐야함
4단계. Production
개발된 서비스를 출시하는 단계
사용자가 접속할 수 있는 Production 환경에서 코드를 구동하고 서비스를 제공함
문제가 생기면 안되는 단계임
배포 환경 설정
- 개발 진행한 환경이 각각 다르므로 그 차이를 이해하고 환경 설정을 코드와 분리하는 것이 중요함
- 작성한 코드가 다른 환경에서 정상작동하게 하려면 설정을 환경변수(envvars나 env)에 저장해야 합니다
- 코드 상의 모든 곳에 절대 경로가 아닌 상대 경로를 사용해야 함
.env등을 이용해 환경변수 설정하기- docker: 모든 개발 환경 자체를 통일시키는 솔루션
AWS - EC2(Elastic Compute Cloud)
AWS에서 제공하는 클라우드 컴퓨팅 서비스
AWS에서 원격으로 제어할 수 있는 가상의 컴퓨터를 한 대 빌리는 것
(Elastic) 비용, 성능, 용량 면에서 탄력적인 클라우드 컴퓨터를 제공하는 서비스
EC2의 특징
1. 구성하는데 필요한 시간이 짧음
- 몇 번의 클릭만으로 PC 구성이 가능함
2. 다양한 운영체제에 대한 선택이 가능함
- AMI라는 템플릿을 통해 다양한 운영체제 중 선택이 가능함
- CPU, RAM, 용량까지도 손쉽게 구성 가능
3. 웹서버 설치하고 웹서버 통해서 사용자가 웹브라우저를 통해 요청하는 서비스를 제공함
4. 인스턴스 = 1대의 컴퓨터
인스턴스 생성한다 = AWS에서 컴퓨터를 빌리는 것
AMI
소프트웨어 구성이 기재된 템플릿 - 패키지 구성이 다양함. 인스턴스는 선택한 AMI를 토대로 구성됨
- 단순히 운영체제(윈도우, 우분투 리눅스 등)만 깔려있는 템플릿
- 특정 런타임이 설치되어 있는 템플릿(우분투 + node,js, 윈도우 + JVM 등)
RDS (Relational Database Service)
AWS에서 제공하는 관계형 데이터베이스 서비스
RDS의 이점 (EC2와 비교)
EC2는 개인소유차량과 비슷 -> 유지보수, 보험처리 등을 모두 운전자가 부담함
RDS는 렌터카 회사에서 차량 대여하는 것과 같음
-> 데이터베이스 유지 보수 관련 일들을 RDS가 전적으로 관리함. 사용자는 초기설정 및 DB에 저장된 데이터를 관리하기만 하면 됨
다양한 데이터베이스 엔진 선택지가 있다는 것도 장점
S3 (Simple Storage Service)
AWS에서 제공하는 클라우드 스토리지 서비스
접근성이 매우 뛰어남
cf) 클라우드 스토리지: 인터넷 공간에 데이터를 저장하는 저장소 (Google Drive, 네이버 MY BOX)
S3의 장점
1. 높은 확장성
데이터를 무한히 저장할 수 있음 -> 효율적인 비용으로 많은 시간과 수고 들이지 않고도 스토리지 규모 확장/축소 가능.
2. 강력한 내구성
내구성이 높다 -> 저장된 파일 유실 가능성이 낮음
S3은 99.9999% 내구성을 보장함
3. 높은 가용성
가용성이 높다 -> 스토리지에 저장된 파일을 정상적으로 사용할 수 있는 시간이 길어짐
S3은 99.99999% 스토리지 가용성을 보장함
cf) 가용영역(Availability Zone) : 각 Region(AWS에서 클라우드 서비스 제공위해 운영하는 물리적인 서버 위치)안에 존재하는 데이터 센터(IDC). 가용 영역 한 곳이 재난이나 사고로 가동이 불가능해지더라도 다른 가용 영역에 백업을 해놓은 데이터를 활용하여 문제없이 서버가 가동되게 함.
4. 다양한 스토리지 클래스 제공
- Standard 클래스 : 범용적 목적으로 사용하기 좋음. 데이터에 빠른 속도로 접근할 수 있고, 데이터 엑세스 요청에 대한 처리속도가 빠름 <-> 높은 비용 때문에 장기보관 목적으로는 효율적이지 않음
- Glacier 클래스 : 데이터 보관비용이 저렴하여 장기 보관 목적으로 효율적임. 바면 데이터 엑세스 속도는 느림
5. 정적 웹 사이트 호스팅 가능
버킷(저장공간)에 정적 파일을 업로드하고 버킷을 정적 웹사이트 호스팅 용도로 구성하여 정적 웹 사이트를 배포할 수 있음
cf) 정적 파일: 서버의 개입없이 생성된 파일 (<-> 동적파일)
cf) 웹 호스팅: 서버의 한 공간을 임대해 주는 서비스
6. 버킷
- 저장되는 파일들이 담기는 바구니(최상위 디렉토리)
- S3에 저장되는 모든 파일은 버킷 안에 저장되어야 함
- 버킷 안에는 무한한 양의 파일을 저장할 수 있음
- 버킷 이름은 각 리전에서 고유(unique)해야함
- 버킷 정책을 생성하여 엑세스 권한 부여 가능
7. 객체
- 버킷에 담기는 파일을 객체라고 함 (데이터 저장 시 키-값 페어 형식으로 데이터를 저장하기 때문)
- 객체는 파일과 메타데이터로 구성됨
- 파일
- 파일 값에는 실제 데이터를 저장함- 객체 값으로 저장될 수있는 최대 크기는 5TB
- 파일의 키는 고유한 식별자 역할을 함
- 메타데이터
- 객체 생성일, 크기, 유형과 같은 객체 정보가 담김
-객체를 설명하는 데이터 - 모든 객체는 고유한 URL 주소를 가짐
- http://[버킷의 이름].S3.amazonaws.com/[객체의 키]
배포 전략
개발한 Client, Server, Database를 어떻게 배포할 것인가?
Client 배포
S3 서비스를 통해 정적 파일로 빌드하여 사용자들에게 Client를 제공할 수 있음
빌드
불필요한 데이터를 없애고 여러갈래로 퍼져있는 데이터들을 통합/압축하여 배포하기 최적화된 상태로 만드는 것
웹 앱은 배포 가능한 정적 파일(static files) 형태로 만들어 줘야 함
cf) React의 경우 npm run build로 정적 파일 형태의 결과물을 만든 후 배포
CloudFront
AWS의 CDN 서비스
각지의 데이터 센터에 데이터를 분산시켜 저재ㅏㅇ해뒀따가 가까운 지역에서 데이터를 주는 방식 -> 더 빠르게 사용자에게 서비스 제공 가능
Server Application 배포
EC2 서비스를 통해 서버 구성 및 서비스 제공함
Database 배포
RDS 서비스 이용
DNS
AWS의 Route 53 서비스 이용하여 길지 않은 직관적인 도메인 주소 만들 수 있음
