AWS
실습동영상 : bit.ly/ARCLAB (6.3버젼 으로) 플러그인 설치 요구
AWS홈페이지 : aws.amazon.com
교육사이트 : https://www.aws.training ---> 자격증 정보 및 무료강의 <자신만의 속도로 학습>
AWS Well-Architected 프레임워크 : 5가지 핵심요소를 AWS 백서로 제공 (보안, 안전성, 비용최적화, 성능효율성, 운영우수성) / aws.amazon.com/ko/whitepapers
--> 이제는 Tool로 제공 AWS Well-architected Tool (현재 서울리젼은 제공안됨)
동적 리소스 : Auto-scailing + Cloutwatch + LoadBalance
장애복구 : elastic beanstalk / 도커 빠르게 재배포
비용최적화 ) : 3가지 : AWS caculator (사용전 월비용 추산 가능 - 어떤리전에서 어떤서비스를 사용했을때 가정하여)
각각의 항목, AWS 계정메뉴의 host & billing manager를 통해서 알람 및 확인 가능
AWS host explorer : 최대 13개월동안의 사용 패턴을 (스토리지, 컴퓨팅, AWS서비스) 추적하여, 보고서 제공
+ 추가로 trust advisor 도 이용가능 (스탠다드, advanced버젼) 도 제공
운영측면)
AWS 서비스 실행 및 모니터링 : CloudWatch
AWS 글로벌 인프라
리전 : AWS서비스가 제공되기 위한 인프라의 위치를 지리적 대표 도시명으로 표시한것 (현재시점 21개 리전) / 리전간통신 AWS백본NW인프라 ---> 2개이상의 가용영역(AZ) 구성됨
가용영역(AZ) : 1개 이상의 데이터센터를 클러스터로 묶은 것 --> 결함분리 방식으로 별도의 지역/건물에 위치 (내결함성) / 프라이빗링크로 통해 AZ가 연결됨 ---> 현재 서울리젼에 AZ가 2개 ---> 3개로 늘어났음
※ 스팟인스턴스 : 시장가 (AZ내의 여유 자원 수량에 따라 변동) 부터 입찰하여 최고높은금액으로 사용가능 ----> 따라서 AWS는 최소 2개이상의 AZ을 사용하여 추가 자원필요할때, AZ간 비용 비교하여, 조금더 저렴한 인스턴스를 사용하도록 권고함
엣지로케이션 : 4개의 AWS서비스를 위한 인프라 (목적 : 빠른접근, 방어보안)
1) Route53 (DNS서비스)
2) CloudFront (CDN서비스)
3) Shield (DDOS 공격 방어)
4) WAF (웹방화벽)
[서비스 범위로 구분하자면]
글로벌 서비스 (전세계사용자에게 제공) : Route53
리전 서비스 (리전사용자에게 제공) : RDS, S3(실제 접근은 글로벌이지만, 저장위치가 리전레벨임),
가용영역 서비스 (AZ에 위치하여 제공) : EC2
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
가장간단한 아키텍처
S3 : 계층되지 하는 파일구조, Flat한 구조로 스토리지 제공 (양이 커질때 성능에 영향주지 않음) ---> 내구성정책 : 3개의 가용영역(AZ)에 복제본을 보관 (99.999999999 %) --> 9가 11개 (일레븐나인 퍼센트)
상황에 따른 이벤트 트리거 (데이터 변경, 추가 될때 알람 기능 제공)
사용사례1) 정적웹컨텐츠, 미디어 저장 및 배포 --> 리전선택, S3의 버킷지정(글로벌하게 unique 해야함)
※ 액세스 제어방법 : 공개 (전체 접근 가능) / 특정사용자(ACL) 액세스 정책 --> jason 포멧파일로 작성.. / IAM에 정책에 담아서.....
사용사례2) 정적웹 호스팅
※ 버젼관리 : 계획되지 않는 덮어쓰기, 삭제 사고 대응 가능 (일반적으로 비활성화)
※ CORS 액세스 제어 : 한 도메인에 로드되어 있는 클라이언트 웹 어플리케이션이 다른 도메인에 있는 리소스와 상호 작용하는 방법을 정의함
사용사례3) 대규모 분석용 데이터 저장소 : S3의 데이터를 SQL 셀렉트를 가지고 ---> SQL 문장으로 접근가능
사용사례4) 백업도구로 활용
※ 이슈예상 : 백업의 도구로 사용시 속도문제... ---> 멀티파트 업로딩 기능 (데이터 분할해서 병렬로 처리 후 병합하여 보관)
Transfer Acceleration 방법 : 파일 -----(인터넷망)------> CloudFront(엣지단까지) ----> S3
snowball : 페타 바이트 규모의 (가방크기) 데이터 전송 (물리적전송) / snowmobile : 트럭으로 --> 이동시키고 --> 내부 고속 NW로 넘김
모법사용사례) 한번쓰고 자주 읽어야 하는경우 (자주변경될때는 성능 이슈/ 데이터변경시 블록단위 처리가 아니라 오브젝트 단위로 처리하기 때문)
사용자 많고 컨텐츠 다양 / 계속 데이터셋증가 / 일시적으로 액세스 급증
과금) 사용량에 대한 과금 + 전송에 대한 과금(단, 같은리전내에 EC2, Cloud Front로 전송 할때는 무료 / S3로 수신하는건 무료)
----------------------------------------------------------------------------------------------------------------------------------------------------------
S3 Glacier : S3보다 장기데이터 저장 / S3보다 비용 1/5 저렴 / 검색의 속도가 특히 느림(3~5시간) / 저장소잠금 기능 이용가능(위변조 방지 , WORM ---> S3에도 오브젝트 락 이라는 기능으로 제공하고 있음)
--> 신속검색기능 (5분미만 검색 , 추가 비용사용됨) / 대량검색기능 (대량으로 데이터셋을 검색할수 있음, 단 7시간정도 소요)
----------------------------------------------------------------------------------------------------------------------------------------------------------
S3 스토리지 클래스 (시계열성의 데이터 특성에 따른 비용효율을 가져오기 위해 클래스를 나누었음)
S3 standard(범용) > S3 standard IA(자주X 빠른액세스) > S3 one zone IA(자주X, 재생성가능데이터 / 한곳의 AZ에 저장) > S3 glacier/deep 아카이브 (가장저렴한 스토리지 티어에 보관)
추가 만들어진 클래스 : S3 지능형 계층화 : 시계열성을 띄는 데이터 특성이지만 명확한 주기 측정이 어려운 데이터의 경우 기계학습을 하여 자동으로 계층간 스토리지로 자동 이동 시킴 (또한 S3 어날리스틱 을 이용하여 사용자가 직접 패턴 확인하여 S3클래스간 지정하여 이동 가능)
S3 수명주기 정책 : (데이터의 시계열성을 파악했다면) S3수명주기 정책 사용하면 생성 후 기간을 기준으로 자동으로 다른 스토리지 클래스로 이동 및 삭제
----------------------------------------------------------------------------------------------------------------------------------------------------------
S3 사용방법 :
1) 리전선택 : 고려사항 --> 지역의 데이터 프라이버시 법률 / 거버넌스 의무 / 지연성(접근성 - 가까운 리전선택) / 일부 서비스는 모든 리전에서 제공안함 / 비용효율성(리전내 AZ의 수에 따라도 달라질수 있음 / 대량 구축해서 서비스 하는것이 더 저렴)
----------------------------------------------------------------------------------------------------------------------------------------------------------
실습 1) 정적 웹 호스팅
실습 2) EC2(APP) --- RDS 연결
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
EC2 : AMI 이미지 사용 (구하는 방법 : ①사전구축된 AMI (32개정도 이미지를 AWS가 제공) / ② Marketplace (비용발생가능) / ③ 자체생성
사용자데이터 이용 (인스턴스 기동시에 쉘스크립트 사용 / 최초 1회만)
인스턴스의 메타데이터 : mac, IP 정보등이 기록되어 있음 (EC2 인스턴스의 메타데이터에 질의 해서 정보를 받을수 있다)
예) AMI로 EC2를 구동하면, 일단 EC2가 실행이 되면서 metadata를 만들어 내고 --> 여기에 질의를 해서 사용자데이터로 가져와, 스크립트가 실행되서 구동되는 EC2의 hostname으로 지정하는 방법 등으로 활용가능)
- EBS 스토리지 : NW으로 연결되는 스토리지 (블록수준 스토리지를 제공)
장점 ) IOPS가 좋다 (354000 IOPS) / 내구성 정책 : (99.999% five-nine % -----> AZ 내에 미러링되서 복제됨 (여러개 복제 사본존재) ---> S3보다 내구성이 낮으므로 EBS의 데이터를 스냅샷해서 S3에 저장 권장) / scale up-down 가능
종류 ) 범용SSD : 1GiB당 3 IOPS <--- 만약 15 IOPS를 요구하는 APP있을 경우 -----> 5G 이상을 제공할 수 있어야함
프로비져닝IOPS SSD : 용량(GiB)에 따른 변화되는 IOPS가 아니라, 용량에 관계없이 사용자가 지정한 IOPS로 사용가능 (max 35400 IOPS 까지)
그외 처리량 최적화 HDD / 콜드HDD 가 있음
※ 단, 스토리지쪽의 IOPS 수치 뿐 아니라 EC2 가 연결된 물리적인 I/O 채널의 IOPS도 함께 확보되야 함!!! ( 즉 EBS 최적화 인스턴스를 함께 선택해야함)
- 인스턴스 스토리지 : DAS / 휘발성 스토리지 --> 이유는 인스턴스가 terminate되고 다시 생성, 또는 stop, start 되면, 해당 인스턴는 같은 HW에서 만들어지지 않기 때문에 DAS연결의 같은 인스턴스 스토리지를 연결할 수 없다
※ EBS와 / 인스턴스 스토리지는 다름
----------------------------------------------------------------------------------------------------------------------------------------------------------
EFS 및 FSx : 각각 리눅스 NFSv4 / 윈도우 NTFS
※ NFSv4.1 까지 지원 (v4 : 파일단위 lock / v4.1 : 파일단위보다 더 작은 lock : 차이점은 : 좀더 동시접근성을 높힌것)
----------------------------------------------------------------------------------------------------------------------------------------------------------
EC2 naming 방법 : 패밀리네임-세대번호.인스턴스 크기 : 예) t2.large / c5.xlarge / p3.2xlarge
인스턴스 유형 결정 : 효율적/비용절감적/EBS최적화된 유형을 결정필요
- t 패밀리 : 범용적/웹사이트,APP (순간 bursting 제공 : 크레딧(안쓰고 남는용량)을 모와서(시간당 모이는 크레딧) 모아둔 크레딧 만큼 일시적 부하 급증 처리) / EBS전용(인스턴스 스토리지를 제공하지 않음)
- C 패밀리 : 컴퓨팅집약적 / EBS전용 - 인스턴스크기에 따라 EBS대역폭이 달라짐
- r 패밀리 : 메모리집약적 / EBS전용 -
- p 패밀리 : GPU제공 / 꽤비쌈
- h 패밀리 : 높은 디스크 처리량 / 인스턴스 스토리지 제공
※ EC2 인스턴스가 stop/start 될때 : 인스턴스 스토리지 바뀜 / EC2 물리 HW 바뀜 / EC2 인스턴스 IP변경 (EIP로 고정가능)
----------------------------------------------------------------------------------------------------------------------------------------------------------
EC2 요금옵션 : ①②③
①온디맨드 : (Amazon 리눅스, Ubuntu 는 초단위 과금 / 나머지 시간당과금)
②예약 : 약정, 미리 지불 (1년단위 선결재/ 부분결재/ 후결재 등...) / 온디맨드 대비 70% 까지 할인 가능 / 특정시간 (반복된 주기 범위만 약정가능)
※ 환불 불가능하지만 마켓플레이스에서 팔 수 있음, 단 다른 패밀리로 변경은 가능(높은 금액으로, 컨버터블RI)
③스팟 : 미사용 EC2 구매 (가격변동, 입찰) / 온디맨드 대비 85% 까지 사용가능 / 단, 입찰가가 다른 시장가보다 낮아지면 AWS가 회수 됨. 회수되기 2분전에 공지, polling해서 이벤트 notice받아야함. 공지는 하이퍼바이져단에 알려주는 거기 때문에...
--> 스팟블록 기능 : 1-6시간 까지 블록(회수 차단) 할 수 있음, 단 가격은 조금 올라간 상태에서 과금
--> 하이버네이션 기능 : (작업 그대로를 저장 --> 이어서 작업 가능한 개념) ---> 시장가가 높아져 뺏기더라도, 나중에 입찰 받아서 이어 작업 가능
----------------------------------------------------------------------------------------------------------------------------------------------------------
EC2 전용옵션 :
① 전용호스트 : single tenant HW 사용가능 (HW독점)
② 전용인스턴스 : 인스턴스 stop, start 하면, 리전 > 특정 AZ내에 미사용인 HW를 찾아 single로 인스턴스 올린 후, 다른 인스턴스가 못들어오게 막는다 (HW독점은 하지 않는다) --> 규정준수, 라이센스 사용 요구 충족에 도움
----------------------------------------------------------------------------------------------------------------------------------------------------------
EC2 인스턴스 추적
태그 할당
아키텍처 고려사항)
- 클러스터 배치 그룹 : 동일한 AZ에 인스턴스 그룹 : 짧은 지연 보장
- 분산배치 그룹 : 여러 가용영역을 포괄 : 가용성보장
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
DB 계층 추가
고려할 사항) 확장성 / 스토리지 용량 / 객체크기유형(구조화된 테이블/ key-value등..) / 내구성
-관계형
-비관계형 (분산, 수평 확장가능) - 기존 cassandra, redis, mongodb
① 관계형 : RDS, Redshift(DW용)
② 비관계형 : DynamoDB(NoSQL), Elasticcache(인메모리), Neptune(그래프DB : 추천 컨텐츠 서비스시 사용하는 DB)
※ 일반관리형 DB : 규모조정, 고가용성, 데이터백업, DB패치, 설치, OS패치까지 모두 AWS가 관리해줌
AWS Aurora : MYSQL 처리량 최대5배 / PostgresSQL 처리량 최대3배 / 3개 AZ내에 6개의 복제본으로 내구성 보장 / MYSQL과 PostgresSQL 호환성 제공
----> 서버 리스 아키텍처로 활용 가능 (사용량에 따라 노드 늘려주고 줄여주고 함) / 데이터 볼륨은 up/down이나 EC2의 패밀리 변경 조정등은 모니터링을 통해서 해줘야함)
AWS DynamoDB : 완전관리형 비관계형 DB 서비스 (테이블 만들고 auto 설정 후 아무것도 안해도 됨) 예) DB볼륨 늘려주고, 볼륨늘리고 파티션분산(데이터밸런싱), 인스턴스 정의 등을 안해도 됨) / 10ms 미만 응답시간 보장
- 글로벌 테이블 기능 제공 : 다른 리전에 다양한 복제본 제공 - 비동기적 복제본 제공 (리전넘어로 해외로, 마이그레이션이 됨)
- 일관성옵션 : 최종일관성 (commit을 하면 순서, 차례로 복제본에 변경사항을 적용 --> 따라서 변경사항이 전체 복제본에 완전히 동기화 되기 전에 아직 적용되기 이전에 복제본쪽으로 읽기를 요청하면 commit 전의 데이터로 나갈 수 있음)
- 강력한일관성 : commit을 수행하고, 모든 복제본에 변경사항이 적용될때까지, commit은 완료되지 않고, 해당 데이터에 접근 안됨X, 성능은 떨어짐)
RDS의 DB 액세스 제어 : 일반적인제어와 동일) DBA관리계정을 통해 사용자만들고, 권한을 부여 + IAM을 통해 서비스 접근 제한 설정 가능
DB 저장시 암호화 / 전송에 대한 암호화 (SSL제공) / 이벤트 알림을 제공 받을 수 있음
DynamoDB의 액세스 제어 : 더 상세히 조정 가능, DB테이블 항목, 속성까지 액세스 권한 부여 가능
DB 저장시 암호화 / 전송에 대한 암호화 (SSL제공) / 이벤트 알림을 제공 받을 수 있음
AWS DMS 기능 (DB migration Service) : 관계형DB의 데이터 --> AWS환경의 RDS로 옮겨올때, 또는 그 반대로 AWS환경의 RDS --> on-premiss의 관계형 DB로 옮겨갈때 지원함
※ snowball이 포함되어 있음 (벌크로 크게 한번 옮긴 후에 ---> CDC처럼 추가 데이터 변경사항을 맞춰준다)
AWS schema Conversion Tool : 이기종 DB로 데이터 conversion 해준다 (100% 로 넘겨주지 않음, 70% 정도는 별도의 추가작업이 넘길수 있다 ---> 추가작업이 필요한것은 레포팅해준다)
※ AWS Migration playbook : AWS 자체 마이그레이션 노하우 정리한 문서 (SCT를 돌리고, DMS로 데이터를 넘긴 다음, playbook으로 보면서....)
AWS Well-Architected 프레임워크 : 5가지 핵심요소를 AWS 백서로 제공 (보안, 안전성, 비용최적화, 성능효율성, 운영우수성) / aws.amazon.com/ko/whitepapers
--> 이제는 Tool로 제공 AWS Well-architected Tool (현재 서울리젼은 제공안됨)
동적 리소스 : Auto-scailing + Cloutwatch + LoadBalance
장애복구 : elastic beanstalk / 도커 빠르게 재배포
비용최적화 ) : 3가지 : AWS caculator (사용전 월비용 추산 가능 - 어떤리전에서 어떤서비스를 사용했을때 가정하여)
각각의 항목, AWS 계정메뉴의 host & billing manager를 통해서 알람 및 확인 가능
AWS host explorer : 최대 13개월동안의 사용 패턴을 (스토리지, 컴퓨팅, AWS서비스) 추적하여, 보고서 제공
+ 추가로 trust advisor 도 이용가능 (스탠다드, advanced버젼) 도 제공
운영측면)
AWS 서비스 실행 및 모니터링 : CloudWatch
AWS 글로벌 인프라
리전 : AWS서비스가 제공되기 위한 인프라의 위치를 지리적 대표 도시명으로 표시한것 (현재시점 21개 리전) / 리전간통신 AWS백본NW인프라 ---> 2개이상의 가용영역(AZ) 구성됨
가용영역(AZ) : 1개 이상의 데이터센터를 클러스터로 묶은 것 --> 결함분리 방식으로 별도의 지역/건물에 위치 (내결함성) / 프라이빗링크로 통해 AZ가 연결됨 ---> 현재 서울리젼에 AZ가 2개 ---> 3개로 늘어났음
※ 스팟인스턴스 : 시장가 (AZ내의 여유 자원 수량에 따라 변동) 부터 입찰하여 최고높은금액으로 사용가능 ----> 따라서 AWS는 최소 2개이상의 AZ을 사용하여 추가 자원필요할때, AZ간 비용 비교하여, 조금더 저렴한 인스턴스를 사용하도록 권고함
엣지로케이션 : 4개의 AWS서비스를 위한 인프라 (목적 : 빠른접근, 방어보안)
1) Route53 (DNS서비스)
2) CloudFront (CDN서비스)
3) Shield (DDOS 공격 방어)
4) WAF (웹방화벽)
[서비스 범위로 구분하자면]
글로벌 서비스 (전세계사용자에게 제공) : Route53
리전 서비스 (리전사용자에게 제공) : RDS, S3(실제 접근은 글로벌이지만, 저장위치가 리전레벨임),
가용영역 서비스 (AZ에 위치하여 제공) : EC2
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
가장간단한 아키텍처
S3 : 계층되지 하는 파일구조, Flat한 구조로 스토리지 제공 (양이 커질때 성능에 영향주지 않음) ---> 내구성정책 : 3개의 가용영역(AZ)에 복제본을 보관 (99.999999999 %) --> 9가 11개 (일레븐나인 퍼센트)
상황에 따른 이벤트 트리거 (데이터 변경, 추가 될때 알람 기능 제공)
사용사례1) 정적웹컨텐츠, 미디어 저장 및 배포 --> 리전선택, S3의 버킷지정(글로벌하게 unique 해야함)
※ 액세스 제어방법 : 공개 (전체 접근 가능) / 특정사용자(ACL) 액세스 정책 --> jason 포멧파일로 작성.. / IAM에 정책에 담아서.....
사용사례2) 정적웹 호스팅
※ 버젼관리 : 계획되지 않는 덮어쓰기, 삭제 사고 대응 가능 (일반적으로 비활성화)
※ CORS 액세스 제어 : 한 도메인에 로드되어 있는 클라이언트 웹 어플리케이션이 다른 도메인에 있는 리소스와 상호 작용하는 방법을 정의함
사용사례3) 대규모 분석용 데이터 저장소 : S3의 데이터를 SQL 셀렉트를 가지고 ---> SQL 문장으로 접근가능
사용사례4) 백업도구로 활용
※ 이슈예상 : 백업의 도구로 사용시 속도문제... ---> 멀티파트 업로딩 기능 (데이터 분할해서 병렬로 처리 후 병합하여 보관)
Transfer Acceleration 방법 : 파일 -----(인터넷망)------> CloudFront(엣지단까지) ----> S3
snowball : 페타 바이트 규모의 (가방크기) 데이터 전송 (물리적전송) / snowmobile : 트럭으로 --> 이동시키고 --> 내부 고속 NW로 넘김
모법사용사례) 한번쓰고 자주 읽어야 하는경우 (자주변경될때는 성능 이슈/ 데이터변경시 블록단위 처리가 아니라 오브젝트 단위로 처리하기 때문)
사용자 많고 컨텐츠 다양 / 계속 데이터셋증가 / 일시적으로 액세스 급증
과금) 사용량에 대한 과금 + 전송에 대한 과금(단, 같은리전내에 EC2, Cloud Front로 전송 할때는 무료 / S3로 수신하는건 무료)
----------------------------------------------------------------------------------------------------------------------------------------------------------
S3 Glacier : S3보다 장기데이터 저장 / S3보다 비용 1/5 저렴 / 검색의 속도가 특히 느림(3~5시간) / 저장소잠금 기능 이용가능(위변조 방지 , WORM ---> S3에도 오브젝트 락 이라는 기능으로 제공하고 있음)
--> 신속검색기능 (5분미만 검색 , 추가 비용사용됨) / 대량검색기능 (대량으로 데이터셋을 검색할수 있음, 단 7시간정도 소요)
----------------------------------------------------------------------------------------------------------------------------------------------------------
S3 스토리지 클래스 (시계열성의 데이터 특성에 따른 비용효율을 가져오기 위해 클래스를 나누었음)
S3 standard(범용) > S3 standard IA(자주X 빠른액세스) > S3 one zone IA(자주X, 재생성가능데이터 / 한곳의 AZ에 저장) > S3 glacier/deep 아카이브 (가장저렴한 스토리지 티어에 보관)
추가 만들어진 클래스 : S3 지능형 계층화 : 시계열성을 띄는 데이터 특성이지만 명확한 주기 측정이 어려운 데이터의 경우 기계학습을 하여 자동으로 계층간 스토리지로 자동 이동 시킴 (또한 S3 어날리스틱 을 이용하여 사용자가 직접 패턴 확인하여 S3클래스간 지정하여 이동 가능)
S3 수명주기 정책 : (데이터의 시계열성을 파악했다면) S3 수명주기 정책 사용하면 생성 후 기간을 기준으로 자동으로 다른 스토리지 클래스로 이동 및 삭제
----------------------------------------------------------------------------------------------------------------------------------------------------------
S3 사용방법 :
1) 리전선택 : 고려사항 --> 지역의 데이터 프라이버시 법률 / 거버넌스 의무 / 지연성(접근성 - 가까운 리전선택) / 일부 서비스는 모든 리전에서 제공안함 / 비용효율성(리전내 AZ의 수에 따라도 달라질수 있음 / 대량 구축해서 서비스 하는것이 더 저렴)
----------------------------------------------------------------------------------------------------------------------------------------------------------
실습 1) 정적 웹 호스팅 -- > S3버킷 만들고 > web hosting enable > index.html파일 upload > 올린파일 mark public
실습 2) EC2(APP) --- RDS 연결
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
EC2 : AMI 이미지 사용 (구하는 방법 : ①사전구축된 AMI (32개정도 이미지를 AWS가 제공) / ② Marketplace (비용발생가능) / ③ 자체생성
사용자데이터 이용 (인스턴스 기동시에 쉘스크립트 사용 / 최초 1회만)
인스턴스의 메타데이터 : mac, IP 정보등이 기록되어 있음 (EC2 인스턴스의 메타데이터에 질의 해서 정보를 받을수 있다) ---> 169.254.169.254 (AWS등의 클라우드에서 인스턴스 metadata를 제공하기 위한 내부주소로 활용함
예) AMI로 EC2를 구동하면, 일단 EC2가 실행이 되면서 metadata를 만들어 내고 --> 여기에 질의를 해서 사용자데이터로 가져와, 스크립트가 실행되서 구동되는 EC2의 hostname으로 지정하는 방법 등으로 활용가능)
- EBS 스토리지 : NW으로 연결되는 스토리지 (블록수준 스토리지를 제공)
장점 ) IOPS가 좋다 (354000 IOPS) / 내구성 정책 : (99.999% five-nine % -----> AZ 내에 미러링되서 복제됨 (여러개 복제 사본존재) ---> S3보다 내구성이 낮으므로 EBS의 데이터를 스냅샷해서 S3에 저장 권장) / scale up-down 가능
종류 ) 범용SSD : 1GiB당 3 IOPS <--- 만약 15 IOPS를 요구하는 APP있을 경우 -----> 5G 이상을 제공할 수 있어야함
프로비져닝IOPS SSD : 용량(GiB)에 따른 변화되는 IOPS가 아니라, 용량에 관계없이 사용자가 지정한 IOPS로 사용가능 (max 35400 IOPS 까지)
그외 처리량 최적화 HDD / 콜드HDD 가 있음
※ 단, 스토리지쪽의 IOPS 수치 뿐 아니라 EC2 가 연결된 물리적인 I/O 채널의 IOPS도 함께 확보되야 함!!! ( 즉 EBS 최적화 인스턴스를 함께 선택해야함)
- 인스턴스 스토리지 : DAS / 휘발성 스토리지 --> 이유는 인스턴스가 terminate되고 다시 생성, 또는 stop, start 되면, 해당 인스턴는 같은 HW에서 만들어지지 않기 때문에 DAS연결의 같은 인스턴스 스토리지를 연결할 수 없다
※ EBS와 / 인스턴스 스토리지는 다름
- EBS 최적화 인스턴스 : EBS I/O <----> 인스턴스의 다른트래픽과 경합최소화하기 위해 인스턴스가 EBS전용 데이터폭을 제공 (EC2생성될때 최적화를 시킬수 있는 옵션 있음)
※ EBS기반 EC2인스턴스에서(아직까지는 linux EC2) : EC2 최대절전모드 가능 ---> 인메모리, 프라이빗IP, Elastic IP를 그대로 유지하여 해당 요금만 과금되고, EC2는 미과금)
----------------------------------------------------------------------------------------------------------------------------------------------------------
EFS 및 FSx : 각각 리눅스 NFSv4 / 윈도우 NTFS
※ NFSv4.1 까지 지원 (v4 : 파일단위 lock / v4.1 : 파일단위보다 더 작은 lock : 차이점은 : 좀더 동시접근성을 높힌것)
※ EFS : 리전, VPC내에서 마운트 가능 (단, 같은 account) --> EFS에서 단 1개의 파일시스템만 export함
FSx : AZ내에서만 마운트 가능 (종류 : FSx for Windows File Server / FSx for Lustre (고성능 HPC환경) --> S3에 연계(복사)가능)
----------------------------------------------------------------------------------------------------------------------------------------------------------
EC2 naming 방법 : 패밀리네임-세대번호.인스턴스 크기 : 예) t2.large / c5.xlarge / p3.2xlarge
인스턴스 유형 결정 : 효율적/비용절감적/EBS최적화된 유형을 결정필요
- t 패밀리 : 범용적/웹사이트,APP (순간 bursting 제공 : 크레딧(안쓰고 남는용량)을 모와서(시간당 모이는 크레딧) 모아둔 크레딧 만큼 일시적 부하 급증 처리) / EBS전용(인스턴스 스토리지를 제공하지 않음)
- C 패밀리 : 컴퓨팅집약적 / EBS전용 - 인스턴스크기에 따라 EBS대역폭이 달라짐
- r 패밀리 : 메모리집약적 / EBS전용 -
- p 패밀리 : GPU제공 / 꽤비쌈
- h 패밀리 : 높은 디스크 처리량 / 인스턴스 스토리지 제공
※ EC2 인스턴스가 stop/start 될때 : 인스턴스 스토리지 바뀜 / EC2 물리 HW 바뀜 / EC2 인스턴스 IP변경 (EIP로 고정가능)
----------------------------------------------------------------------------------------------------------------------------------------------------------
EC2 요금옵션 : ①②③
①온디맨드 : (Amazon 리눅스, Ubuntu 는 초단위 과금 / 나머지 시간당과금)
②예약 : 약정, 미리 지불 (1년단위 선결재/ 부분결재/ 후결재 등...) / 온디맨드 대비 70% 까지 할인 가능 / 특정시간 (반복된 주기 범위만 약정가능)
※ 환불 불가능하지만 마켓플레이스에서 팔 수 있음, 단 다른 패밀리로 변경은 가능(높은 금액으로, 컨버터블RI)
③스팟 : 미사용 EC2 구매 (가격변동, 입찰) / 온디맨드 대비 85% 까지 사용가능 / 단, 입찰가가 다른 시장가보다 낮아지면 AWS가 회수 됨. 회수되기 2분전에 공지, polling해서 이벤트 notice받아야함. 공지는 하이퍼바이져단에 알려주는 거기 때문에...
--> 스팟블록 기능 : 1-6시간 까지 블록(회수 차단) 할 수 있음, 단 가격은 조금 올라간 상태에서 과금
--> 하이버네이션 기능 : (작업 그대로를 저장 --> 이어서 작업 가능한 개념) ---> 시장가가 높아져 뺏기더라도, 나중에 입찰 받아서 이어 작업 가능
----------------------------------------------------------------------------------------------------------------------------------------------------------
EC2 전용옵션 :
① 전용호스트 : single tenant HW 사용가능 (HW독점) ---> 장점 : EC2 자체 소켓당, 코어당 라이센스를 사용하여 비용 절약 가능, 법적규제준수 가능
② 전용인스턴스 : 인스턴스 stop, start 하면, 리전 > 특정 AZ내에 미사용인 HW를 찾아 single로 인스턴스 올린 후, 다른 인스턴스가 못들어오게 막는다 (HW독점은 하지 않는다) --> 규정준수, 라이센스 사용 요구 충족에 도움
※ AWS license manager : 온프레미스 서버의 SW의 라이센스를 손쉽게 관리 ---> EC2를 시작할때 사용자 지정 라이센스 규칙을 생성 --> 허용범위 이상의 라이센스 위반 제한 또는 다른서버에 단기적으로 라이선스 재 할당
----------------------------------------------------------------------------------------------------------------------------------------------------------
EC2 인스턴스 추적
태그 할당
아키텍처 고려사항)
- 클러스터 배치 그룹 : 동일한 AZ에 인스턴스 그룹 : 짧은 지연 보장
- 분산배치 그룹 : 여러 가용영역을 포괄 : 가용성보장
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
DB 계층 추가
고려할 사항) 확장성 / 스토리지 용량 / 객체크기유형(구조화된 테이블/ key-value등..) / 내구성
-관계형
-비관계형 (분산, 수평 확장가능) - 기존 cassandra, redis, mongodb
① 관계형 : RDS, Redshift(DW용)
② 비관계형 : DynamoDB(NoSQL), Elastic cache(인메모리), Neptune(그래프DB : 추천 컨텐츠 서비스시 사용하는 DB)
※ RDS DB사용방법
1. EC2에 직접설치
2. AWS RDS를 사용 ( 사용가능 DB : Aurora, MySQL, MariaDB, PostgreSQL, Oracle, MS SQL) ---> 다중-AZ 배포 설정가능 / Read Replica 필요할 경우 Reader Endpoint 사용하면 됨.
3. Amazon Aurora
※ 관리형 DB 서비스 : Amazon Aurora ????
※ 완전관리형 DB 서비스 : Amazon RDS / Amazon DynamoDB / Amazon DocumentDB / Amazon neptune / Amazon QLDB / Amazon Timestream
※ 일반관리형 DB : 규모조정, 고가용성, 데이터백업, DB패치, 설치, OS패치까지 모두 AWS가 관리해줌
AWS Aurora : MYSQL 처리량 최대5배 / PostgresSQL 처리량 최대3배 / 3개 AZ내에 6개의 복제본으로 내구성 보장 / MYSQL과 PostgresSQL 호환성 제공
----> 서버 리스 아키텍처로 활용 가능 (사용량에 따라 노드 늘려주고 줄여주고 함) / 데이터 볼륨은 up/down이나 EC2의 패밀리 변경 조정등은 모니터링을 통해서 해줘야함)
AWS DynamoDB : 완전관리형 비관계형 DB 서비스 (테이블 만들고 auto 설정 후 아무것도 안해도 됨) 예) DB볼륨 늘려주고, 볼륨늘리고 파티션분산(데이터밸런싱), 인스턴스 정의 등을 안해도 됨) / 10ms 미만 응답시간 보장 / 자동3방향 복제
- 글로벌 테이블 기능 제공 : 다른 리전에 다양한 복제본 제공 - 비동기적 복제본 제공 (리전넘어로 해외로, 마이그레이션이 됨)
- 최종일관성옵션 : 최종일관성 (commit을 하면 순서, 차례로 복제본에 변경사항을 적용 --> 따라서 변경사항이 전체 복제본에 완전히 동기화 되기 전에 아직 적용되기 이전에 복제본쪽으로 읽기를 요청하면 commit 전의 데이터로 나갈 수 있음)
- 강력한일관성 : commit을 수행하고, 모든 복제본에 변경사항이 적용될때까지, commit은 완료되지 않고, 해당 데이터에 접근 안됨X, 성능은 떨어짐)
RDS의 DB 액세스 제어 : 일반적인제어와 동일) DBA관리계정을 통해 사용자만들고, 권한을 부여 + IAM을 통해 서비스 접근 제한 설정 가능
DB 저장시 암호화 / 전송에 대한 암호화 (SSL제공) / 이벤트 알림을 제공 받을 수 있음
DynamoDB의 액세스 제어 : 더 상세히 조정 가능, DB테이블 항목, 속성까지 액세스 권한 부여 가능
DB 저장시 암호화 / 전송에 대한 암호화 (SSL제공) / 이벤트 알림을 제공 받을 수 있음
AWS DMS 기능 (DB migration Service) : push모델, 관계형DB의 데이터 --> AWS환경의 RDS로 옮겨올때, 또는 그 반대로 AWS환경의 RDS --> on-premiss의 관계형 DB로 옮겨갈때 지원함
※ snowball Edge 디바이스 가 포함되어 있음(snowball edge사용위해 agent설치필요한 리눅스 호스트 필요, DB와 동일 NW여야함) (벌크로 크게 한번 옮긴 후에 ---> CDC처럼 추가 데이터 변경사항을 맞춰준다)
AWS schema Conversion Tool : 이기종 DB로 데이터 conversion 해준다 (100% 로 넘겨주지 않음, 70% 정도는 별도의 추가작업이 넘길수 있다 ---> 추가작업이 필요한것은 레포팅해준다)
※ AWS Migration playbook : AWS 자체 마이그레이션 노하우 정리한 문서 (SCT를 돌리고, DMS로 데이터를 넘긴 다음, playbook으로 보면서....)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
아래설명은 AWS aurora인지, AWS RDS내에서 Aurora를 말하는것인지 아직 모르겠다.
※ AWS RDS 서비스와 다르게 multi-AZ를 지원하지 않고, Read replica를 failover에 사용한다. --> 기존 RDS는 Computer와 Storage를 단일 VM내에 지녔지만, AWS aurora는 분리되어 있기때문이고, DNS차원에서 연결을 승격된 Read Replica로 바로 틀수 있다.
--->따라서 Aurora에선 Storage의 Multi AZ는 있으나 Instance의 Multi AZ는 RR을 하나이상 만들어 다는 것으로 대체되었다고 보면 된다.
AWS aurora와 AWS RDS for aurora 의 차이점는 무엇일까?????? https://www.stratoscale.com/blog/dbaas/aurora-vs-rds/
Amazon RDS
Amazon RDS (Relational Database Service)를 사용하면 클라우드에서 관계형 데이터베이스를 손쉽게 설정, 작동 및 확장 할 수 있습니다.
비용 효율적이고 크기 조정이 가능한 용량을 제공하는 동시에 시간이 많이 걸리는 데이터베이스 관리 작업을 관리하므로 응용 프로그램과 비즈니스에 집중할 수 있습니다.
Amazon RDS는 Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle 및 Microsoft SQL Server 등 선택할 수있는 여섯 가지 익숙한 데이터베이스 엔진을 제공합니다.
Amazon Aurora
Amazon Aurora는 관계형 데이터베이스 엔진입니다. 이 솔루션은 단순하고 비용 효율적인 방식으로 하이 엔드 상용 데이터베이스의 속도와 안정성을 제공하도록 설계되었습니다.
Aurora는 MySQL 5.6과 호환되도록 설계되었으며 동일한 하드웨어에서 실행되는 표준 MySQL의 처리량의 5 배를 제공합니다.
DBA는 최종 사용자에게 성능에 영향을 미치지 않으면 서 데이터를 실시간으로 AWS S3에 지속적으로 백업하므로 백업 저장 디스크 계획시 시간을 절약 할 수 있습니다.
따라서 백업 창과 자동화 된 백업 스크립트가 필요하지 않습니다. Aurora는 멀티 AZ의 6 개 스토리지 노드에 데이터를 복제하여 클라이언트 애플리케이션에 대한 가용성 영향없이 전체 AZ 또는 2 개의 스토리지 노드의 손실을 견딜 수 있습니다.
●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●
●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●
2일차
실습3. 가상사설 클라우드 생성 : VPC간 서로 연동하여 APP와 DB연동하기
① VPC 생성과 public subnet을 만들어 Internet에 연결될수 있도록 Routing table과 IGW 연결하기
VPC 생성 > public subnet (IP자동할당) / private subent 생성 > IGW 생성 > IGW를 VPC에 연결 > public route table 생성 (기본은 VPC대역 - locally 내부통신만 허용) --> "0.0.0.0/0 - IGW" 추가 > Public route table에서 subnet assoicate (Public 서브넷 등록)
※ 보안그룹생성 (APP-SG, 모든 HTTP 트래픽 허락), DB-SG는 기생성되어 있음(APP-SG 리스트 허락)
생성한 VPC에 EC2 생성 (APP용, APP-SG추가, IAM role(inventory-App-Role), User data 등록
※ VPC에서 DNS hostname enable 설정해야 -- 생성되는 인스턴스에 DNS도메인을 할당한다
② VPC 간에 peer 연결하기 (VPC간 APP-DB 연동)
peer connection 생성 (요청VPC : ①번에서 만든 VPC / lab에 이미 생성된 shared VPC(RDS 위치함)
> 만들어진 Peer에서 (Action탭) Accept request를 수행하여 생성한 peer의 통신을 허락함
> 각각 VPC의 subnet의 route table 에 peer 연결하는 룰 등록, 신규VPC의 public 라우팅테이블 : (신규VPC IP대역 - peer장치) / sharedVPC의 private 라우팅테이블 : (sharedVPC IP대역 - peer장치)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
VPC
1개 계정에서 1개 리전당 : 최대 5개 VPC 생성가능 (리전마다 달라서, 확장요청 가능하다고는함)
※ CIDR : /34는 네트워크대역아닌 host로 지정할때
서브넷 : 사용하지 못하는 IP 5개 존재 : 0, 255, 1, 2, 3 번은 예약되어 있음 (※ MS Azure의 경우는 Vnet의 subnet의 IP는 처음3개, 마지막1개 --> 4개 IP는 사용 불가 )
※ 서브넷은 1개의 AZ에 존재함 / VPC는 여러 AZ에 걸쳐질수 있음
라우팅테이블 : VPC를 생성하면 기본 라우팅 테이블 생성됨 ---> (룰 : VPC IP 대역 - locally ) VPC 내부에서만 패킷이 돌게끔
IGW 와 연결할 경우, 해당 Subnet의 퍼블릭 라우팅 테이블에 룰 추가----> (룰 : 0.0.0.0/0 - igw-id)
※ 각 subnet 별로 라우팅테이블로 관리하는 것을 권고함
NAT GW : 프라이빗 서브넷 인스턴스가 ---> 아웃바운드로 인터넷에 연결되게 하기 위해서 (인바운드 트래픽은 차단됨)
NAT GW 와 연결할 경우, 해당 Subnet의 프라이빗 라우팅 테이블에 룰 추가----> (룰 : 0.0.0.0/0 - nat-id) ---> private 인스턴스가 "public subnet의 NAT GW" 에 연결되고 ---> 이렇게 되면 public subnet의 IGW를 통해 외부로 인터넷 연결됨
Subnet 권장사항)
- 더 큰 크기의 서브넷 고려 (/24이상)
- private subnet을 좀더 크게 할당
- 서브넷에 사용 가능한 IP 부족할 경우, subnet 확장 불가
- 잘 모를 경우 ---> 각 가용영역당 public, private 각각 1개씩 생성
----------------------------------------------------------------------------------------------------------------------------------------------------------
탄력적 네트워크 인터페이스 (ENI) : 인스턴스에 장착할 수 있는 가상네트워크 인터페이스 (한번 만들어 놓으면 동일한 AZ안에서 EC2간 인스턴스간에 분리, 연결 가능) --> 인스턴스의 기본 primary nic은 제거 불가, ENI는 추가로 붙여야함 (ENI와 인스턴스가 동일한 AZ에 존재해야함, 따라서 DR은 불가)
새 인스턴스로 이동하더라도 ---> 프라이빗IP주소, 탄력적IP주소, MAC주소 를 유지 할 수 있음.
탄력적 IP주소 : 리전당 5개 허용 . public 한 고정IP를 제공해줌. pluggable하게 여러 EC2에 붙일 수 있음 (현재, IPv6지원X, VPN연결일 경우는 IGW통해 AWS들어오는게 아니라 가상 프라이빗 GW(VGW) 를 통해 들어오기 때문데 EIP 사용X)
BYOIP : 사용은 무료, 탄력적IP와 달리 고객은 BYOIP로 가져온 분리된 IP 주소에 수수료 지불X 안함.
----------------------------------------------------------------------------------------------------------------------------------------------------------
클라우드 보안
①보안그룹 : default 값 (모든 인바운드 차단, 모든 아웃바운드 허용)
※ 허용 대상을 IP, IP대역 뿐만 아니라, 인바운드규칙을 보안그룹으로 지정가능 ---> 보안그룹 체인 가능 (웹티어 --> 어플레키이션 --> DB )
②네트워크ACL : 서브넷 경계의 방화벽 (보안그룹보다 범위가 큼) / default값 (모든 인바운드, 아웃바운드 허용됨)
--> 이것까지 지정하면 관리적인 측면 늘어나느것 고려...
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
고가용성 NW
VGW : VPC와 다른 NW 사이에 private 연결을 설정할 수 있는 AWS측에 있는 VPN집선장치 (VPN) ※ IPsec연결을 지원함
AWS HW VPN(1개의 VGW)에서는 장애 대비 VGW에 2개의 endpoint(기본값) 유지하고 ( 1:1이 아닌 다수의 고객GW와의 연결을 허락함 --> 다수 VPN연결일때 라우팅을 정적 또는 동적(BGP피어링이용한 경로간 가중치) 사용가능
※ EC2를 이용한 SW적인 VPN을 연결을 생성할 수 있지만, AWS 유지관리 안함, marketplace에서 선택가능
AWS Direct Connect (DX) : 1~10Gbps의 전용 프라이빗 네트워크 연결을 제공 (거리에 따라 요금) / 대용량 데이터, NW성능예측가능 ※ 대용량일경우 인터넷서비스공급자(ISP)에게 지불해야 하는금액을 금액을 절약 또는 대역폭증가에 따른 비용지불할 필요없음
아키텍처 : DX로케이션이라는 곳 까지, AWS VPC에서는 VGW로 연결 / 온프레미스에서는 Direct connect (DX파트너가 연결해줌) 로 연결
※ 이중화 : 하나는 DX / 하나는 VPN GW를 이용하여 VPN 으로 이중화
- VPC 피어링 : 다른 리전간의 VPC와도 peering 가능 / 서로 다른 계정의 VPC와 연결 가능
요청과 승인을 양쪽에서 각각 해주어야 연결됨. (피어링을 통한 VPC간의 NW은 전송요금이 부과됨)
(VPC 당 생성가능한 peering 연결수 제한 없음 / 피어VPC가 ---> 피어링되는다른VPC에 접근권한없음(전이적관계지원X) / 동일한 2개의 VPC사이에서 2개이상의 피어링 연결안됨X /
VPC 피어링 조건 : 2개의 VPC에 동일한 NW범위가 중복되지 않아야함
- VPC peer 엔드포인트 : VPC와 다른 리전의 AWS 서비스와 바로 연결 (다른리전의 백업 및 복구 할때 : VPC와 외부S3 연결하는데 이용)
---> AWS Transit Gateway : 5000개 VPC와 온프레미스 환경에 연결 가능, 관리편이성 -> 복수개의 VPC 피어링 할때 설정 불편함(피어랑 요청/승인 + 라우팅테이블등의 설정)
모든 VPC의 라우팅 테이블에 --> Transit GW로 연결설정하고, Transit GW의 라우팅 테이블에만 각각 VPC의 연결 룰을 만들어 한 곳에서 관리
VPC의 엔드포인트 : AWS NW을 벗어나지 않고, VPC와 <-----> 동일 리전의 다른 AWS서비스간에 프라이빗 연결을 가능하게 한다. (이때, VPN, NAT, 방화벽프록시등을 사용할 필요 없음) --> VPC에서 제공하는게 아니라 아래의 각각의 서비스가 엔드포인트를 가지고 있는것임
즉, EC2인스턴스가 프라이빗주소로 ---> 동일리전의 AWS서비스와 통신 가능 (인터넷우회, VPN, DX통과할 필요없음)
단, 인터넷을 벗어날 필요가 없지만, 동일한 리전에 위치해야함 / 현재 AWS에서는 S3와 DynamoDB연결을 위한 VPC 엔드포인트만 지원
① 인터페이스 엔드포인트 : 서비스로 향하는 트래픽의 진입점 역할을 하며, 프라이빗주소가 할당되어 있음 (ELB API, Cloudwatch log등)
② 게이트웨이 엔드포인트 : 라우팅테이블에 지정된 라우팅의 대상이 되는 GW로, AWS서비스의 트래픽에 사용됨 (S3, DynamoDB)
예) s3.amazone.com S3의 DNS을 고객사데이터 센터에서 VPN을 통해 ELB로 redirection 하면, S3버킷으로 가는 요청이 인터넷 공유하지 않고, VPN 또는 DX(전용선)을 통해 S3에 전송됨
( 데이터센터 --> VPN -> ELB -> 프록시팜(S3 트래픽을 VPC엔드포인트로 리다이렉트함) -> S3엔드포인트 )
AWS기반의 로드밸런스 (ELB) : 내외부 위치가능 / DNS이름이 부여됨 / cloud watch로 지표 전송가능 / ASG활용하여 용량 추가 가능
※ connection Draining 기능 : 분산되는 로드의 처리가 노드에서 완전히 처리되기 전까지 인스턴스를 제외시키는것 중지 (서비스영향을 없게한다)
- Application LB : HTTP, HTTPS
- Network LB : TCP
- Classic LB (legacy)
----------------------------------------------------------------------------------------------------------------------------------------------------------
가용성 확보 방법)
- EC2를 각각 분리된 AZ에 위치
- 인바운드 Public 트래픽을 ELB통해서
- 내부 인바운드 private 트래픽도 다른 ELB를 통해서
- 아웃바운드 트랙픽은 ELB를 통하지 않고, IGW로 바로 내보냄
Amazon Route53 : DNS 서비스 (도메인주소 ---> IP전환)
※ 서로다른 리전을 이중화하여 한쪽을 standby로 사용할 경우, route53도 주기적으로 VPC를 주기적으로 응답 체크 후에 이상감지하면 다른 리전의 standby로 route53의 포인터를 옮긴다.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
실습4
① Application LB 생성
ALB이름 / ALB 위치할 VPC 지정 / ALB가 작동해야할 subnet 2개 지정(여기서는 public) / ALB의 보안그룹 생성(HTTP, HTTPS) / 라우팅지정 : Target Group 이름, Health 체크 설정, Target Group의 Target 선택(아직 없기때문에 skip)
② Auto Scailing Group 생성
②-1 Launch Config(시작구성) 설정 : 인스턴스AMI, 타입, LC이름, IAM롤, User-data, APP-보안그룹(HTTP 허락) 지정
②-2 Auto Scailing 세부 정보 구성 : Auto 그룹 이름 / 그룹크기(인스턴스개수) / 대상 VPC / 인스턴스가 생성될 subnet 2개 지정( private1,2)
/ 세부정보에서 Auto Scailing 그룹의 인스턴스를 ALB에 연동--> ALB가 관리하는 Targete Group 선택 > keep this group at its initial size (항상 2개 유지정책) 선택 / 생성되는 인스턴스의 key-value값 tag 지정
③ Auto Scailing Group에 의해 생성되는 EC2인스턴스의 SG 수정
APP-SG와 DB-SG의 인바운드 룰의 허용 대상을 ALB의 트래픽으로 수정 (-sg로 검색하면 나옴)
※ 미리 생성되어 있던 RDS의 고가용성 확보
modify 탭 들어가서 > Mutil-AZ 지정 / storage type 변경(provioned IOPS스토리지로) / 인스턴스타입 변경
---> 인스턴스 크기가 아닌 타입이 변경되는 경우, 다운타임이 요구됨 (Apply immediately 를 선택할 경우)
※ 생성된 APP 인스턴스 (private subnet에 위치) 에 NAT GW 연결하여 outbound 패킷 보내기
NAT 생성 > public subnet 1개 선택 > NEW EIP 생성 > route table 생성 (private route table 만들어서, 0.0.0.0/0 - NAT와 연결) 후에, route table을 private subnet과 associate
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
IAM (인증과 인가의 기능, 무료)
권한부여 방법 : 정책 (json타입, AWS서비스에 대한 액세서만 제어)
- 정책 종류 : 리소스 기반(서비스에서 부여한 정책, 예) S3에서 public하게 open할건지말지 결정)
자격증명 기반 (사용자에게 부여한 정책)
※ 정책은 AWS에서 만든것을 사용할수 있고, custumize 해서 사용할수도...
권한평가 방법 : 명시적거부 우선 체크 --(아니요)--> 명시적 허용체크 --(예)--> 허용
IAM Group: Group간 사용자 이동 가능하지만, Group들 사이에 중첩은 안됨
IAM 역할 : 사용자, group간에 연결되지 않고, 필요한 권한을 사용자 또는 서비스에 위임 할 때 사용가능 (임시권한부여) --> 자원의 모든 권한이 있는 사용자가 IAM역할을 만들고, 다른 사용자가 요청했을때 IAM역할을 권한을 주어 임시로 사용가능하게 할 수 있다
즉, 다른계정의 자원관리 시, 해당 계정의 자격증명을 받고 관리해야 하지만, 다른계정의 IAM역할을 받아버리면 자격증명을 거치지 않아도 됨.
AWS STS : on프레미스의 앱에서 사용하는 자격증명데이터가 ---> on프레미스앱과 AWS서비스가 연동되는 서비스일때, AWS내에서 자격증명을 할수 있도록, 임시자격증명인 토큰을 생성하여 부여 할수 있다 (임시자격증명)
SAML : LDAP으로 사용하여 자격증명할 경우, 사용되는 자격증명인 SAML 어센셜을 그대로 접근시에도 사용가능
Amazon Cognito :
조직에 몇개의 AWS계정이 필요하는가?
: 개발계정, 테스트계정, 프로덕션계정 / 또는 다중VPC에 하나의 계정 등
AWS Organizations : 여러계정의 과금을 하나로 모을 수 있음 / 하나로 통하면 계정도 사용자처럼 그룹화 하고, 관리 (정책화, 제한) 할 수 있음
※ 이러한 작업은 서로다른 권한을 갖는 사용자의 각각의 서비스를 연동하려 할때 필요한것들일것 같다.
----------------------------------------------------------------------------------------------------------------------------------------------------------
AWS 계정루트 사용자 : AWS를 모든 서비스를 사용 가능 (사용한만큼 과금의 주체)
IAM 사용자 : AWS 계정내에서 사용자 ( 각 사용자는 자체 자격증명을 갖는다 / 기본값(권한못음), AWS관리콘솔조차도 권한을 부여받아야함)
연동사용자
IAM 역할
자격증명공급자(IdP)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
모니터링
cost explorer : 어디에서 비용을 지출하고 있는지 파악 (보고서생성, 13개월데이터, 예측제공, 지출패턴제공)
Amazon CloudWatch : 리소스 지표 수집, 추적 ---> 경보생성, 알람전송도 가능
CloudWatch Logs : CloudWatch Agent(EC2내에 설치)를 통해서 ---> AWS서비스가 아닌 고객의 APP에 대한 로그파일을 수집하고 측정
이벤트 : 콘솔로그인, Auto Scailing 상태 변경, EC2인스턴스 상태변경등의 이벤트 실시간 제공
CloudTrail : 계정내에 모든 API 호출 파악 (누가 언제 무엇을 호출 하였는지..) ---> S3에 로그 저장 (오브젝트Lock(WORM 기능)으로 데이터 위변조 방지)
VPC Flow Log : VPC 트래픽 흐름 세부 정보 캡쳐 가능 (VPC, 서브넷, ENI 기준으로 활성화하여 파악 가능)
Auto Scailing : 단순히 확장, 축소 뿐 아니라 ---> LB와 자동 연계시켜 launch 시킬 수 있음
또한 예측가능한 워크로드(특정시간대, 사용률)에 연동 하는것 뿐만 아니라, 기계학습기반으로 과거 사용률 바탕으로 적절한 trigger 레벨을 지정할 수 있다
구매옵션 : 온디맨드, 예약, 스팟을 섞어서 사용할 수 있다 (예:스팟입찰에 실패할 경우, 온디맨드로 사용가능함)
※ 중요하지 않는 인스턴스의 경우에도 (min, max값을 1로 설정하여 죽을때는 자동 기동되도록 할수 있다.)
※ 2개 이상의 측정치가 존재할 경우 : 2개가 다 만족할 경우, 각각의 경우로 스케일아웃하는것이 아니라 둘 중 더 크게 늘어나는 수치로 선택된다.
※ 쿨타임 : 스케일 아웃, 인의 기준치가 좁아서 핑퐁 칠수 있으니, 일정시간동안 조작을 막는 쿨타임
수명주기후크 : stateless한 AP가 적합하나, 꼭 state 정보가 필요한 AP을 사용할 경우, 수명주기 후크를 사용할 경우 이전에 상태 정보를 DynamoDB에 저장하고, 스케일인되면, 다시 dynamoDB에 가져와 작업을 처리 할수 있다
----------------------------------------------------------------------------------------------------------------------------------------------------------
DB규모 조정
-Read작업(select중심)은 Read replica에서 (복제본 사이에 데이터는 비동기식) / 복제본 개수는 aurora 15개 지원, 나머지는 5개 지원
-DML작업은 Master노드에서
지원가능한DB : Aurora, MySQL, MariaDB, PostSQL에서만 제공
※ AWS RDS솔루션은 가동중단없이 수직적으로 확장가능 (단, DB내 자체에 대해서만! / RDS가 존재하는 인스턴스의 변경(확장)은 다운타임 필요)
다중 AZ 배포 옵션 이용하여 DB생성했으면 ---> standby (지연시간 조금) 로 넘기면, 인스턴스 타입 바뀌더라도 다운타임없이 가능하다고 함)
RDS 인스턴스의 변경 --> DB instance stop/start 발생 : 5분소요
RDS 물리스토리지 변경 --> DB instance stop/start 발생 : 14분소요 (실제 데이터에 따로 가변될수 있을듯)
Multi AZ 로 변경 --> No stop/start : 8분소요 (이것또한 가변될수 있을듯 / LAB환경 기준
DB샤딩 : 큰볼륨에 테이블이 있으면 --> 데이터를 청크로 분할 하여 각각의 DB(Amazon RDS)에 분산시킴 (논리적인것을 ---> 여러논리적인 엔진으로 분산) / ※ 파티셔닝은 논리적인 파티션을 여러 물리적인 위치로 분산
DynamoDB : 완전관리형 DB (auto scailing만 활성시켜놓으면) / 10ms 이내 응답시간 보장 / 사용된 용량만 지불할수 있다
DynamoDB 조정용량 : 프로비져닝해서 확보할수도 있음, WCU(write capacity unit) 단위로 확보
--> 또한 여러 파티션으로 분산시켜놨는데, 특정파티션에 writing이 몰려서 해당 파티션의 프로비져닝된 WCU(write capacity unit)을 초과해 버릴 경우, 다른 1개의 파티션의 남는 WCU 용량을 제공 (자동으로)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
IAM (인증과 인가의 기능, 무료)
권한부여 방법 : 정책 (json타입, AWS서비스에 대한 액세서만 제어) ---> 이러한 policy는 AWS policy generator로 Jason 파일로 자동변환해줌
- 정책 종류 : 리소스 기반(서비스에서 부여한 정책, 예) S3에서 public하게 open할건지말지 결정)
자격증명 기반 (사용자에게 부여한 정책)
※ 정책은 AWS에서 만든것을 사용할수 있고, custumize 해서 사용할수도...
권한평가 방법 : 명시적거부 우선 체크 --(아니요)--> 명시적 허용체크 --(예)--> 허용
IAM Group: Group간 사용자 이동 가능하지만, Group들 사이에 중첩은 안됨 (Group에 리소스들 정책 적용하고, IAM 사용자를 group에 넣는다
IAM 역할 : 사용자, group간에 연결되지 않고, 필요한 권한을 사용자 또는 서비스에 위임 할 때 사용가능 (임시권한부여) --> 자원의 모든 권한이 있는 사용자가 IAM역할을 만들고, 다른 사용자가 요청했을때 IAM역할을 권한을 주어 임시로 사용가능하게 할 수 있다
즉, 다른계정의 자원관리 시, 해당 계정의 자격증명을 받고 관리해야 하지만, AWS 다른계정의 IAM역할을 받아버리면 자격증명을 거치지 않아도 됨.
AWS STS : on프레미스의 앱에서 사용하는 자격증명데이터가 ---> on프레미스앱과 AWS서비스가 연동되는 서비스일때, AWS내에서 자격증명을 할수 있도록, 임시자격증명인 토큰을 생성하여 부여 할수 있다 (임시자격증명)
SAML : LDAP으로 사용하여 자격증명할 경우, 사용되는 자격증명인 SAML 어센셜을 그대로 접근시에도 사용가능
Amazon Cognito : auth인증처럼 다른어플리케이션 인증으로 AWS 서비스에 접근하게 해주는것인가???
조직에 몇개의 AWS계정이 필요하는가?
: 개발계정, 테스트계정, 프로덕션계정 / 또는 다중VPC에 하나의 계정 등
AWS Organizations : 여러계정의 과금을 하나로 모을 수 있음 / 하나로 통하면 계정도 사용자처럼 그룹화 하고, 관리 (정책화, 제한) 할 수 있음
※ 이러한 작업은 서로다른 권한을 갖는 사용자의 각각의 서비스를 연동하려 할때 필요한것들일것 같다.
----------------------------------------------------------------------------------------------------------------------------------------------------------
AWS 계정루트 사용자 : AWS를 모든 서비스를 사용 가능 (사용한만큼 과금의 주체)
IAM 사용자 : AWS계정이 아니라 AWS 계정내에서 사용자 ( 각 사용자는 자체 자격증명을 갖는다 / 기본값(권한없음), AWS관리콘솔조차도 권한을 부여받아야함)
연동사용자
IAM 역할
자격증명공급자(IdP)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
모니터링
cost explorer : 어디에서 비용을 지출하고 있는지 파악 (보고서생성, 13개월데이터, 예측제공, 지출패턴제공)
Amazon CloudWatch : 리소스 지표 수집, 추적 ---> 경보생성, 알람전송도 가능
CloudWatch Logs : CloudWatch Agent(EC2내에 설치)를 통해서 ---> AWS서비스가 아닌 고객의 APP에 대한 로그파일을 수집하고 측정
이벤트 : 콘솔로그인, Auto Scailing 상태 변경, EC2인스턴스 상태변경등의 이벤트 실시간 제공
CloudTrail : 계정내에 모든 API 호출 파악 (누가 언제 무엇을 호출 하였는지..) ---> S3에 로그 저장 (오브젝트Lock(WORM 기능)으로 데이터 위변조 방지)
VPC Flow Log : VPC 트래픽 흐름 세부 정보 캡쳐 가능 (VPC, 서브넷, ENI 기준으로 활성화하여 파악 가능)
Auto Scailing : 단순히 확장, 축소 뿐 아니라 ---> LB와 자동 연계시켜 launch 시킬 수 있음
또한 예측가능한 워크로드(특정시간대, 사용률)에 연동 하는것 뿐만 아니라, 기계학습기반으로 과거 사용률 바탕으로 적절한 trigger 레벨을 지정할 수 있다
구매옵션 : 온디맨드, 예약, 스팟을 섞어서 사용할 수 있다 (예:스팟입찰에 실패할 경우, 온디맨드로 사용가능함)
※ 중요하지 않는 인스턴스의 경우에도 (min, max값을 1로 설정하여 죽을때는 자동 기동되도록 할수 있다.)
※ 2개 이상의 측정치가 존재할 경우 : 2개가 다 만족할 경우, 각각의 경우로 스케일아웃하는것이 아니라 둘 중 더 크게 늘어나는 수치로 선택된다.
※ 쿨타임 : 스케일 아웃, 인의 기준치가 좁아서 핑퐁 칠수 있으니, 일정시간동안 조작을 막는 쿨타임
수명주기후크 : stateless한 AP가 적합하나, 꼭 state 정보가 필요한 AP을 사용할 경우, 수명주기 후크를 사용할 경우 이전에 상태 정보를 DynamoDB에 저장하고, 스케일인되면, 다시 dynamoDB에 가져와 작업을 처리 할수 있다
----------------------------------------------------------------------------------------------------------------------------------------------------------
DB규모 조정
-Read작업(select중심)은 Read replica에서 (복제본 사이에 데이터는 비동기식) / 복제본 개수는 aurora 15개 지원, 나머지는 5개 지원
-DML작업은 Master노드에서
지원가능한DB : Aurora, MySQL, MariaDB, PostSQL에서만 제공
※ AWS RDS솔루션은 가동중단없이 수직적으로 확장가능 (단, DB내 자체에 대해서만! / RDS가 존재하는 인스턴스의 변경(확장)은 다운타임 필요)
다중 AZ 배포 옵션 이용하여 DB생성했으면 ---> standby (지연시간 조금) 로 넘기면, 인스턴스 타입 바뀌더라도 다운타임없이 가능하다고 함)
RDS 인스턴스의 변경 --> DB instance stop/start 발생 : 5분소요
RDS 물리스토리지 변경 --> DB instance stop/start 발생 : 14분소요 (실제 데이터에 따로 가변될수 있을듯)
Multi AZ 로 변경 --> No stop/start : 8분소요 (이것또한 가변될수 있을듯 / LAB환경 기준
DB샤딩 : 큰볼륨에 테이블이 있으면 --> 데이터를 청크로 분할 하여 각각의 DB(Amazon RDS)에 분산시킴 (논리적인것을 ---> 여러논리적인 엔진으로 분산) / ※ 파티셔닝은 논리적인 파티션을 여러 물리적인 위치로 분산
DynamoDB : 완전관리형 DB (auto scailing만 활성시켜놓으면) / 10ms 이내 응답시간 보장 / 사용된 용량만 지불할수 있다
DynamoDB 조정용량 : 프로비져닝해서 확보할수도 있음, WCU(write capacity unit) 단위로 확보
--> 또한 여러 파티션으로 분산시켜놨는데, 특정파티션에 writing이 몰려서 해당 파티션의 프로비져닝된 WCU(write capacity unit)을 초과해 버릴 경우, 다른 1개의 파티션의 남는 WCU 용량을 제공 (자동으로)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●
●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●
3일차
자동화
Lab환경에서 CloudFormation 에서 Templete 탭에서 view Desingener 툴 버튼을 선택하면 visual하게 설계도를 확인가능함
※ 구글에서 AWS cloudformation sample 치면 나오기도 함
CloudFormation : 인프라 자동화 툴 (Jason과 YAML 형식으로 구성)
템플릿 ----> AWS CloudFormation 엔진 -----> 아키첵처 스택 (AWS에서 실행 가능한 코드로 변환되고 배포됨)
AWS quick Start : 이미 만들어진 템플릿을 제공 (AWS 솔루션즈 아키텍트가 구축한 것, 무료배포됨, 모범사례기초) / 예를들어, 블록체인영역, DB영역, 분석 등의 사례별로 분류되어 있음
(CloudFormation 템플릿과 + 관련 스크립트)
AWS systems Manager : 자동화된 구성, 대규모 시스템의 지속저 관리가 가능 (EC2의 대규모 시스템 업데이트 등, 온프레미스에서도 활요가능)
원래는 EC2메뉴에 있었는데 ---> 독립적인 서비스로 빠지는 중임
기능) 명령실행 (태그단위 가능)
유지관리 기간 지정 (원하는 시간대, 그리고 반복적으로)
패치관리
상태관리자 (진행중인 작업에 모니터링 및 CloudWatch에 연동 가능함)
AWS OpsWorks : CloudFormation는 AWS의 어떤 서비스를 쓸것인지를 설계하는 것이고, OpsWork는 EC2내에 패키지, 디렉토리 구조등을 세세히 설정할때 사용
(기존 chef, puppet 라이센스를 가죠와서 사용 가능하며, 또는 OpsWorks 자체의 라이센스 사용가능)
다음 트리거 단계에서 스크립트를 실행한다)
Setup (새인스턴스가 성공적으로 부팅된 후 실행되는 시점) / Configure / Deploy / Underploy / Shutdown
※ AWS CloudFormation을 사용하여, 인프라를 구축하고 ----> AWS OpsWorks 사용하여 어플리케이션을 배포한다는 개념
AWS Elastic Beanstalk : 간단한 설정 하면, 사용자 어플리케이션에 필요한 스택을 제공
사용자 코드만을 Beanstalk에 올리면 (코드의 몇가지 설명을 포함한) ---> 모든 필요한 요소를 프로비져닝함 (ELB, AutoScailing, 로그 모니터링 까지 모두 포함)
※ Cloud Former (아직 베터) : 현재 만들어진 AWS 서비스를 -----> Cloud Formation Templete으로 만들어줌
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
캐싱
① AWS의 캐싱
Amazon CloudFront : AWS 글로벌 CDN 서비스 (다중계층캐시 : Resional edge cache > edge location 을 거쳐 전파 되지않고, 사용자가 우리 Region 과 가깝다면, Resion cache에서 바로 delivery 가능) / 보안계층제공(shield + WAF)
구성방법)
S3버킷 또는 HTTP 엔드포인트 준비 > CloudFront 의 배포를 생성 (위치를 알려주는) > 사용자의 요청이 올수 있도록 DNS 할당 > 배포가 전체 엣지 로케이션에 전달됨
컨텐츠만료 : TTL (기본값 24시간....) / 객체이름변경(이름변경) / 객체무효화(강제로 비워버리는것)
S3의 컨텐츠가 CloudFront로 캐싱되는 데이터는 과금되지 않음 <----> NW의 연결의 AWS의 내부 백본망으로 이동함 (공중망이 아님)
(따라서 정적컨텐츠, 동적컨텐츠 모두 CloudFront를 이용해서 서비스 한다면, 보안측면, 속도측면에서 유리)
CloudFront사용시 DDos완화의 예)
사용자 ---> Route53 ---> AWS WAF ----> CloudFront ---> VPC ---> ELB(public) ----> 웹APP(EC2, private NW)
② 웹계층의 캐싱
세션관리 ELB : 세션관리가 캐싱과 관련이 없어 보이지만 ---> 실제로 세션은 상태관리를 하지 않기 때문에, 세션마다 요청에 대한 자격증명을 동반,,,----> 요구사항 증가로 인한 지연이 발생 할수 있음
따라서) 세션관리는 인증, 액세서 제어를 관리함 ---> 방법 : 고정세션 또는 분산캐시의 사용 / 또는 상태정보 저장을 위해 DynamoDB 를 일시적으로 사용
③ 데이터베이스의 캐싱
Amazon Dynamodb accelerator : 10ms 미만의 일관된 지연시간 보장 / 완전관리형 / DynamoDB와 API호환 > AP코드 변경 불필요
웹에서의 상태정보를 관리하기 위해 DynamoDB를 쓸수 있다고 웹계층 캐싱에서 설명했는데 이를 ----> Dynamodb accelerator를 사용
Amazon Elastic cache : 인메모리 데이터 스토어를 웹APP에 제공 (memcache, redis 용도와 비슷)
용도) 인메모리 데이터 스토어에 검색 기능을 지원하여 ----> 이곳 캐시에서 데이터를 찾을 수 없을때, 비교적 느린 기반의 데이터베이스를 참조
작동방법) 각각의 캐시노드들로 구성된 클러스터 단위로 ElasticCache 존재 (각 캐시노드에 고유DNS, 포트존재 / 완전관리형 서비스)
memcached 사용하는 Elastic cache가 있고(최대20개노드) --- Redis 사용하는 Elastic cache가 있음(최대90개노드) : 다중 AZ 의 고가용성, 모든 노드에 걸쳐 데이터 분할 되어 있음, 관리적요소 불필요
- 연속쓰기 전략 : 데이터가 DB에 작성될때마다 ---> 캐시에 데이터를 추가, 업데이트 (캐시의 최신성유지 되지만, 2번쓰기 작업이 수행되는형태임)
- 레이지 접근방식 : 필요할때만 데이터를 캐시에 로드 하는 캐싱 전략 / APP --- Elastic Cache --- DB 사이에 위치 시켜서 : APP은 먼저 Elastic cache에 요청, 존재하면 캐시적중, 캐시미스면 데이터 스토어에서 가져와 캐시작성함
(노드 확장, 장애발생으로 노드 교체시, 해당 노드에 모든 데이터가 포함되지 않음, 데이터 추가 업데이트 전까지 계속 누락된 상태를 해결하기 위한 방식)
---> 단, 캐시 미스의 패널티(지연)가 존재하고, 캐시 미스가 발생할때만 업데이트 함으로, 캐시에 오래된 데이터가 존재 할수 있으므로(공간차지), ---> 연속쓰기 및 TTL 추가 전략 사용
TTL 추가전략 : 각각의 쓰기에 TTL값을 추가 하여 오래된 데이터로 채워지는것을 방지한다.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
결합해제된 아키텍처 구축 (일부 실패가 전체 실패로 발생 방지)
- ELB 사용
- Amazon Simple Queue Service (SOS) : 메세지 대기열 서비스 / 메세지 처리 및 삭제 전까지 저장 (이것또한 요청자의 신호로 동작, 무조건저장) / 발신자 --- 수신자사이의 버퍼역할
장점) 비동기처리-각단계신속응답 / 메시지가 대기열에 남아 - 실패단계에서 쉽게 복구
유형 ) 표준대기열 : 최소 1회전송, 최선정렬 (때때로 사본 중복처리, 순서제어 따로 설정 필요)
FIFO대기열 : 정확히 1번 처리됨 (초당3000건지원, 이제부터 서울리전 사용가능)
※ Auto scailing과 결합시 트래픽 크기에 따라 EC2 인스턴스 수 확장, 축소 가능
※ 가시성 제한 : 수신자가 메시지를 가져간 후 일정 시간동안 메세지 제거 하지 않음 (단, 중복 처리 되지 않도록 가시성제한시간 조정 필요)
※ 단 256kb 이하의 메세지만 가능
Amazon SQS 예제)
웹앱티어 -----> 주문메세지 발생 -----> 고객주문대기열 ----> 앱티어에서 고객주문서 valid 체크 ----> 체크 검증 후 DB에 저장 (RDS master)
: 웹앱티어 <----> 앱티어 사이의 주문서 동기화를 할 필요가 없다
Amazon SQS 수명주기)
생산자 (주문서 생성) ----> 대기열 (메시지 대기) <------> polling으로 소비자가 땡겨옴 (소비자에게 주문서를 처리할동안 대기열의 사본 동일 다른 소비자가 메시지 처리 못하도록 메세지를 lock건다(가시성제한)
(주문서 처리가 완료되면 소비자의 요청의 의해 대기열의 메시지를 삭제함)
Amazon Simple Notification Service (SNS) : 게시자 --- 주제 ----구독자 (게시자가 토픽을 등록하면 등록된 구독자에게 PUSH 해줌) / 아직 서울리전 지원안함 / 잘못된 메세지 회수 없음, 재시도가능, 주문,전달보장은 못함
구독유형) 이메일, HTTP/HTTPS, SMS, SQS대기열, Lambda
사용목적) APPlication 경보, 푸시 이메일, 문자메세지, 모바일푸시알림
Amazon Simple Notification Service (SNS) 사용예 )
모바일에서 이미지 업로드 (S3버킷) ---> S3의 알림기능으로 ---> Amazon SNS로 전달 되고, SNS은 지정된 구독자(여기서는 SQS대기열)에게 PUSH 함 ---> 대기열을 통해 Application에 전달하여 이미지 가공 (이때 auto scail과 연계가능) ---> 가공된 컨텐츠 S3에 제공 ---> S3의 컨텐츠 CloudFront 에 배포
< 위 과정에서, 이미지는 실제 단계별로 전달되지 않고, 이미지의 URL위치 (endpoint만 전달)만 전달함 >
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
마이크로서비스, 서버리스
컨테이너서비스 : 반복사용가능, 독립형실행환경, VM보다 빠른 처리
Amazon Elastic Container 서비스 (ECS) : 도커 컨테이너 실행을 조정, 노드플릿 유지관리, 확장
Amazon Elastic Container Registry (ECS) : 도커 이미지 레지스트리
클러스터 : ECS 배포전에 클러스터 사전 구성 필요 (컨테이너가 어떤 인프라에 실행되야 하는지 : 수동 EC2기반 / AWS가 자동으로 구성해주는 Fargate
※ ECS기반 마이크로서비스 아키텍처로 서비스 단위 분리 배포
※ EKS (쿠버네티스) 서비스도 존재함
AWS Fargate (완전관리형 컨테이너 서비스) : 클러스터 프로비저닝, 관리 / 실행시간 환경관리/ 규모조정
서버리스 : 서버관리하지 않고 앱과 서비스를 구축하고 실행
AWS Lambda : 완전관리형 컴퓨팅 서비스 (※ 과거 Lambda는 5분이상의 컴퓨팅 파워는 제공 못했지만, 현재는 15분을 늘어남) / 엣지에서 실행가능 (단 여기는 Node.js만 지원) / 1000개까지 병렬수행 가능
Node,js, Java, Python, C#등 기반으로 AWS Lambda 함수를 등록
2가지 형테) 특정일정의 스케쥴에 맞춰서
AWS서비스와 연계해서 특정 이벤트일때 수행
AWS API Gateway : 엔트포인트 노출방지, 공격보호 / AWS Lambda와 긴밀하게 통합
AWS Step Functions : Application 기능 단계별 실행 > 각단계를 자동으로 트리거 하고 추적 > 단계실패할경우 오류파악 및 로깅
즉, 출력을 결정하기 위해 이전 조건을 의존하는 일련의 작동조건을 가진 객체임
※ API GW통한 Lambda의 제어가 다양 할때 사용(병렬처리 / 연속 / 조건에 따라 재시도, 다른경우 분기)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
실습6. AWS관리형 서비스로 서비리스 아키텍처 구현
재고 내역 파일을 업로드 한 후 ---> 재고파악을 하고 재고를 채워놓기 위한 일련의 서버리스 아키텍처링
S3에 재고파일을 업로드 하면 --> DynamoDB 에 데이터 업로드 --> 업로드된 내용에 대한 재고체크 > SMS 재고 없을 경우 notice
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
RTO/RPO 및 백업 복구 설정
-고가용성 구조
-백업
-재해복구
스토리지 중복
S3 : 리전내의 --> 3개의 AZ에 복제사본 (99.99999999%) + 교차 리전 복제 활성화 (복제사본 + 비동기화유지)
Glacier : 여러 가용영역에 복제됨, (아카이브 압축성 파일이기 때문에 직접 접근은 안됨 ---> S3에 풀었다가 이용해야함)
EBS : 가용영역안에서 중복 복제사본 (99.999%) + EBS의 스냅샷사본을 S3에 저장
Snowball : AWS 의 대량의 데이터를 따로 소산하여 On-premiss로 보관 (아직 snowball은 서울리전에서 지원X)
EFS : 파일 sync 기능 (인터넷, DX연결통해서)
컴퓨팅 백업
AMI 이미지 + CloudFormation 또는 ECR + CloudFormation을 이용하여 빠른 복구
NW 재해복구
Route53의 record set을 만들면 주 사이트에 health체크를 하다가 / 문제발생 파악되면 --> 다른 리전으로 확보해 놓은 예비 사이트로 트래픽을 보내준다.
ELB : 로드밸런싱, 상태확인, 장애조치
교차 영역 로드밸런싱 활성화 하면, target host 개수에 맞는 로드밸런스를 수행함.
(기본값 : 가용영역단위로 묶어 나누어 로드밸런싱 ----> Target host 개수로 나누어 로드밸런싱 처리 하지 않음. 가용영역단위로 로드밸런싱한다.---> 가용영역내 target이 장애로 줄어들면 해당 가용영역의 host에 부하 집중 될 수 있다.
VPC : VPN으로 온프레미스 연결하여, 온프레미스 장애시 AWS로 재해 복구를 이용할 수 있다 (또는 하이브리드 형태로 유지한다면, AWS Direct connect 가 빠름)
데이터배이스 백업 및 중복
RDS : 스냅샷 (별도리전저장) / 읽기전용 replica 사용 / 자동백업보존(자동설정일 경우 35일만 유지)
DynamoDB : 글로벌테이블 지원 --> 일관성은 비동기적으로 좀 떨어지지만 리전에 걸쳐 생성 / 전체 테이블 몇초안에 복구 / 최대 35일동안 지속적 테이블백업, 다중리전, 다중마스터 테이블
신속한 복구
CloudFormation, Beanstalk, OpsWorks
스토리지 Gateway : 온프레미스의 저장볼륨을 AWS에 연결 / 온프레미스내에 AWS Storage Gateway VM(SW 어플라이언스 형태로, 데이터센터내 호스트제공해주면 거기에 구성)을 만들고
---> VM내에 볼륨스토리지에 iscsi로 고객데이터를 백업받고, ---> VM내에 업로드 버퍼를 통해 SSL 암호화를 시켜, ---> AWS Storage Gateway에 전달한다.
파일럿 라이트 : 주사이트에 서버와 DB를 운영, ---> DR에는 보조DB로 미러링, 복제 유지하고, 서버는 미리 구성해놓고, 실행되지 않는 상태로 유지 하는 기능 (비용은 조금 있음)
※ 매우 비용효율적
완전동작 저용량 스탠바이 : 주사이트에 서버와 DB를 운영, ---> DR에는 보조DB로 미러링, 복제 유지하고, 서버는 사용하되, 굉장히 저용량으로 유지 ---> 실제 사용시 Auto Scailing 으로 확장
※ 비용절감, 언제라도 서비스 일부 처리 가능
다중사이트 액티브-액티브 : 주사이트, DR사이트 똑같이 유지 (데이터는 미러 복제)
※ 언제라도 모든 프로덕션 로드 처리 가능
- 파일럿 라이트 / 완전동작 저용량 스탠바이 / 다중사이트 액티브-액티브 모두, 사이트 사이에 Route53이 트랙픽 라우팅을 해준다. 파일럿라이트와 완전동작 저용량 스탠바이트 --> 주사이트 장애시 보조사이트로 redirect하고, 다중사이트 액티브-액티브는 ---> 양쪽으로 로드밸런싱을 유지한다
※ 유의점 : 단순하게 시작하고, SW라이센스 문제 확인, 테스트