[AWS] 20/01/30 AWS 세미나 참석

1월 30일 삼성역 AWS 101 Hands on Lab

 

• AWS 행사 및 교육 일정 정보

입문 - 기본 - 심화 과정으로 이루어지는데, 오늘 들을 세미나는 '입문'과정이다.

AWS 세미나 종류

• 100 lvl : console조차 처음 접하는 사람에게 적합. (오늘 들을 세미나)
• 200 lvl : 서비스중에 하나를 잡아서 알려줌
• 300 lvl : 실제 실무에 적용할 수 있는 코드가 포함되어있는 강의.

 

AWS

간단히 말해서 전세계 지역에 있는 datacenter를 이용해서 서비스가 가능하다

가용영역: dataCenter가 집합되어있는 클러스트. 여러개의 데이터센터(두개이상)로 이루어져있다.

전세계적으로 전용 backbone망이 구성되어있어서 빠르게 서비스가 가능하다.

+ Free tier 세개를 묶어서 클러스트 구성 ㅋㅋ..

 

AWS 서비스 종류

온프레미스 아키텍처를 클라우드로 바로 옮기는것이 아니라, 클라우드에 최적화된 아키텍처를 구성하는것이 중요하다.

 

시작하기

 

실습할때, 반드시 생성했던 인스턴스를 중단하거나 삭제하는것이 중요하다. 또한 FreeTier에 해당하는 서비스인지 확인하고 사용한다.

 

아래에는 무료서비스

 

오늘 실습할것들

 

설정은 브라우저에 저장된다.

실습 단계

 

최종 구성도

최소한의 가용성을 확보하는 아키텍처라고 볼 수 있다.

서버가 2대기 때문에, 부하가 분산이 되야한다. 로드밸런서가 그 역할을 한다.

화살표는 오토스케일링을 의미함. 오토스케일링의 역할은 부하가 많아졌을때 서버를 능동적으로 늘리는 역할을 한다.

70%일때 6대까지 늘리거나 - 60%이하면 2대로 줄일 수 있다.! 

 

가용영역은 a, b, c 소문자로 표시한다.

VPC: Private Cloud. 가용영역은 VPC안에 들어있다. 가용영역은 여러개의 데이터 센터로 되어있다.

가용영역이 나누어져 있으면 latency가 발생하지 않을까? => 아니다. 고속 네트워크로 연결되어있기 때문에 걱정 안해도 된다.

 

가용영역은 여러개의 서브넷으로 구성되어있다.( 가용영역은 물리적으로 떨어져 있음. 우리는 가용영역에 따라 여러개의 서브넷을 구성할것이다. 서브넷으로 논리적으로 나누어져 있다는것을 기억하자. 각자가 논리적으로 나누어진독립적인 네트워크 망이라고 볼 수 있다.)

프라이빗 서브넷으로 서비스를 구성하는것을 추천한다. 왜냐하면 오픈되어있으면 공격이 들어오기 때문.

외부에 들어오는 모든 트래픽은 로드밸런서를 타게 된다.

 

퍼블릿서브넷, 프라이빗 서브넷 구분 방법: 인터넷 게이트웨이. 인터넷 게이트웨이가 붙어있으면 퍼블릭, 안붙어있으면 프라이빗이다.

 

VPC는 내부아이피로 설정한다.

CIDR에 따라 설정할 수 있는 IP의 개수가 다르다.

CIDR를 임의로 설정하지 말고, AWS의 권고사항을 따르는것이 좋다.

 

VPC나의 네트워크 영역. = 한 RG에 5개까지 가능 

내부아이피 주소를 지정할때 주소가 중복하지 않게 주의한다.

최대 5개까지 가능하지만 보통은 프로덕트 VPC하나 테스트 VPC 하나 둬서 사용한다. 분리된 네트워크라고 볼 수 있음. 분리하는 이유는 문제가 커지지 않게 하는것임. 최대한 안정성있게 가기위해서. 

 

실습 시작

1) VPC 생성

기본 VPC가 생성되어있다.

Default VPC는 다 열려있다. 빠르게 쓸수있게 하기 위함임. 그래서 실제 서비스에는 새로 VPC를 만드는것을 추천한다.

Default VPC를 지워도 되지만, Default VPC를 참조하는 서비스가 있으면 다시 만들어야 할 수 도 있다. 그냥 무시하고 두는게 좋다. 과금되는게 아니기 때문에.

VPC는 과금되지 않음

 

내부아이피 범위 지정

 

VPC만 있어서는 서버를 올릴 수가 없다.

서브넷을 생성하자.

VPC는 서브넷에 종속된다. 잘못만들면 지우고 다시 만들어야 한다. 한 서브넷에 다 때려넣지 말자. 서버를 죽이고 새로 만들어야 한다. 처음부터 서브넷을 잘 만들어야 함.

 

서울에 있는 가용영역 a

+ 2c에 하나 더 만들자.

그러면 VPC에 가용영역이 다른 서브넷 두개가 만들어졌다!

 

지금까지 하면 내부에서만 통신이 된다.

인터넷 게이트웨이가 수동으로 만들어야 외부로 통신이 가능하다!

 

 

인터넷 게이트웨이가 붙어있으면 public이고 안붙어있으면 private이다.

 

 VPC에 인터넷게이트웨이를 붙인다.

그냥 장비만 붙인것임. 서브넷들이 못갖다 쓴다. 바로 외부랑 통신이 되는게 아니라, 라우팅테이블을 설정해줘야 한다.

A랑 C랑 통신하기 위해서는 기본적으로는 된다. 하지만 통신이 안되게 하고싶으면 ? 라우팅 테이블을 컨트롤 해야한다. ㅇㅇ 니가 아는 그 라우팅 테이블. static하게 설정해줘야 함.

 

 

10.0.0.0으로 가는 패킷은 로컬로 간다 - 라는 의미 현재는 내부망으로만 통신이 가능함.

 

적용하면 모든 트래픽은 인터넷게이트웨이를 통하도록 함.

 

라우팅 테이블이랑 서브넷 연결

=> 명시적이 된다.

 

 

보안그룹 생성

보안그룹이란?

온프레미스라면 iptables를 통해 IP대역을 blocking하겠지. AWS에서는 보안그룹을 통해서 한다..

대상 IP, PORT를 Control하는 일종의 방화벽이라고 한다.

EC2에 꼭 붙어있어야 한다.

 

*최대한 영어로 적는게 좋다. cli컨트롤할때 인코딩 문제 있어.

=> discription을 최대한 잘 적어주는게 좋다.

VPC에 적용하자.

 

whiteList에 적요이된다.

모든 들어오는 패킷에 대해 80포트, 22포트를 허용한다. 모든 IP에 적용함.

시큐리티 그룹이 있어야 웹서버가 생성이 가능하다!

 

웹서버 생성

 

1)운영체제 선택

Amazone Linux는 Amazone에서 CentOS기반으로 커스텀 한것

 

MarketPlace를 이용하면 목록에 없는 OS를 선택 할 수도 있다. OS이미지라고 할 수 있음.

 

PUblic IP를 할당

 

EC2 인스턴스가 처음 뜰때 실행할 수 있는 스크립트를 넣을 수 있다. yaml패키지를 업데이트 한다던지. 코드를 땡겨온다던지.

 

웹서버가 설정되는 스크립트..와....너무편해....

but 부팅시간에 영향이 감. 너무 많이 넣으면 부팅이 느려진다.. 오토스케일링으로 서버 늘릴때 부팅이 느려져서 오류가 날 수도 있음.. 적당히 하자.

 

5) 태그추가

나중에 서버가 많아지면 태그를 잘 추가 해야 클라우드를 잘 관리 할 수 있다.

Name은 예약어. console List에 Value가 노출된다. 

Tag로 cli에서 필터를 걸 수 있다... 너무편해...... 비용확인 할 때도 태그를 기준으로 확인 할 수 있음

 

6) 보안그룹 설정

이미 만들어놓은 보안그룹을 활용하면 편하다.

 

7) 서버 내로 접속 할 수 있는 방법?!

console에서 js로 접근 할 수 있는 방법이 생겨따.

서버에 접속할 때 keyPair로 접속하자.

+ 꼭 키파일을 다운로드 해야합니다. 키관리 잘해야해요...

 

터미널에 접속

브라우저에서도 접속이 가능하다. public 서브넷에만 붙을 수 있음.

 

 

private에 접속할때는 VPN을 직접 사용해도 됨.

could train? 이라는 콘솔 접속내역 로깅시스템이 있다고 함.

 

퍼블릭 IP에 접속하면 확인 할 수 있다.

 

메모리에 있는것은 이미지로 뜨지 않는다! 서버를 중지하면 메모리가 clear된다. but 웹서버에는 유의미한 메모리가 음슴. 굳이 stop안해도 된다캄.

 

백업할때 꼭! 재부팅 안함을 체크해야 한다. 진짜 큰일난다....

종료시 삭제 => 

이미지 스탭샷 => OS까지.

EBS 스냅샷 => Storage만 백엽

 

웹서버1의 이미지를 떠서 웹서버2에 붙여넣기 하자. 

이미지를 복사해서 서브넷에 넣기

+ OS만 설치하는거라서 네트워크 설정같은건 새로 해야한다. 기억하자. 현재 OS만 복사!

 

로드밸런서

서브넷을 어디에 위치시켜야 할지도 설정해야 한다.

 

로드밸런서 종류

ALB : 기능이 훨씬 많다. L7 로드밸런서. 람다.. path기반, port기반 분산 가능...

ALB를 쓰면 path에 따라서 다른 웹서버를 탈 수 있다는 말이다! 와. 조으다조으다.

=> 컨테이너 쓰거나 웹서버 쓸때 사용. 추천한다.

 

NLB : TCP기반에 강하다. 네트워크에 대한 고부하가 걸릴때는 NLB가 탁월하다. publicIP를 로드밸런서에 붙일 수도 있음.

특수한 경우에 사용

 

로드밸런서 장점

로드밸런스가 모든 트래픽을 먼저 받는다! 쓸데없는 공격.. 같은 트래픽을 다 먼저 받고 버려준다.

 

HTTPS를 사용할 수도 있는데, 인증서를 로드밸런서에 등록하고 암복호화를 로드밸런서가 하면 로드밸런서 와 서버의 통신은 80포트로 통신 할 수 있다.

 

아웃바운드만 과금된다. 인바운드는 과금안됨. 물론 가용영역이 다른 내부 인스턴스가 통신하는건 비용이 나올 수 있음.

하나만 선택하면 하나만 부하분산된다. 주의

 

EC2 헬스체크 설정. 서버가 정상적인지 아닌지 체크한다. AutoHealing가능. 

 

롤링배포: 두개의 서버를 사용. 서버하나를 떼고 서버하나에 먼저 배포함 -> 테스트해서 정상적인지 확인 -> 

 

로드밸런서 > 모니터링 에서 400에러나, 500에러 현황을 볼 수 있다. 편함.

 

optional 가이드

CloudWatch Monitoring

 

알람에 대한 주제를 만들고, 이 주제를 구독하고 있는 사람들한테 알람을 준다.

알람을 받을 그룹을 생성 할 수 있다.

 

 

AutoScailng

특정 메트릭에 따라 인스턴스를 시작 또는 종료가 가능하다.

로드밸런서로 쓰는게 편하다.

 

자동으로 생성할 인스턴스가 사용할 AMI 설정 등.. 하지만 AMI를 매일 업데이트 할 수는 없쟈나!

=> 이미지 자동화 할 수 있다.

* 기존 인스턴스랑 전반적으로 동일한것을 생성하는것이 좋다.

 

CloudWatch => Default로 5분동안 현재 인스턴스들의 메트릭을 체크하는데 사용하면 촘촘하게 체크함. 과금요소

 

 

서버에는 형상관리되는 코드만 있는것이 좋다. 날아가도 코드만 받으면 되니깐.

 

CloudWatch 에서 리소스들을 모니터링 할 수 있음

 

정적 웹 호스팅 기능

=> S3 Storage에 설치. 인스턴스를 만드는거보다 저렴함. HTML이랑 js만 되어있는 회사사이트 보여주기 적합..

 

 

S3는 글로벌서비스이다. Region이 음슴. S3버킷은 컨택스트패스?

 

 

버켓의 내용을 Access 할 수 있는 대상을 설정 할 수 있다.

 

버전관리도 가능하다. => 과금 발생

정적 웹 사이트 호스팅

서버 액세스 로깅 => 누가 접근하는지 로깅

스태틱 웹 호스팅 => 에러페이지도 설정 가능함.

그래서 나온 사이트를 도메인에 연결하면 따란 회사사이트 완성

정적 웹페이지의 저장 비용은 얼마 안나온다.

이벤트 페이지 만드는것도 괜찮다. 하나의 활용 예는, 단순 이벤트 페이지에 대한 서버 부하를 줄일 수 있음! 좋다.