티스토리 뷰
국내에서 매년 열리는 AWS 행사중 가장 규모가 큰 AWS SUMMIT 2019 두번째 날 행사에 다녀왔습니다.
매년 참석자가 폭증하는 느낌 인데요. 세션 이동중 찍은 사진인데 정말정말 사람이 많았습니다.
엑스포 규모와 이벤트도 거대했구요. 이정도 스케일의 행사를 진행하는 AWS측의 능력도 인정해줘야 할 것 같습니다.
제가 들은 세션중 일부 내용을 공유합니다.
Contents
AWS Lambda 내부 동작 방식 및 활용 방법 살펴보기
컨테이너와 서버리스 기반 CI/CD 파이프라인 구성하기
워크로드에 맞는 클라우드 데이터베이스 찾기
진화하는 CloudFront의 이해와 글로벌 서비스 활용
1. AWS Lambda 내부 동작 방식 및 활용 방법 살펴보기
AWS 김일호 솔루션즈 아키텍트 매니저
람다 주요 장점
사용자 지정 로직으로 다른 aws 서비스 확장
사용자 지정 백엔드 서비스 구축
기존 보유 코드 사용
완전히 자동화된 관리
내장된 내결함성
자동 규모 조정
클라우드 프론트 요청에 대한 응답으로 코드 실행
여러 함수 오케스트레이션
통합된 보안 모델
사용량에 따라 지불
유연한 리소스 모델
고민거리
로드 밸런싱
오토 스케일링
Failures 핸들링
Isolations
람다의 AWS 아키텍쳐
Data Plane
람다 구축시 고려할 사항
Front End Invoke
프론트 엔드의 호출을 모두 관장한다.
Counting Service
사용자가 얼마나 많은 API 요청을 하는지 모니터링하고 제한기능 제공
Worker Manager
실제 컨테이너의 상태를 관리하고 API요청을 가용 가능한 컨테이너로 중계한다.
Worker
고객 함수(코드)가 안전하게 실행되는 실제 Container 환경
완전하게 독립된 안전한 환경
Placement Service
Worker에 샌드박스 구성을 자원 활용률이 높고, 고객 서비스 영향이 없도록 관리
람다의 Failures 핸들링
리전 내부의 다수의 Availability Zone 구성을 통해서 람다 함수 실행에 있어 고가용성을 보장한다.
람다의 Isolations 환경
람다 실행에 있어서 단일 계정과 단일 펑션을 유지하므로 완전하게 독립된 안전한 환경에서 실행된다.
Guest OS 위의 샌드박스를 별도의 독립된 공간으로 구성하는데 cgroups, namespaces, seccomp, iptables & chroot 등의 기술이 사용된다.
람다의 Utilizations
정확히 사용한 시간 만큼만 과금
내부적으로 시스템을 최대한 바쁘게 돌리기 위한 최적화가 되어 있다.
7개의 워커에서 각 60% 씩 활용률을 가지고 있는 것 보다.
4개의 워커에서 각 99% 씩 활용률을 가지고, 3개는 sub로 가지는 컨셉으로 디자인 되어 있음.
람다와 RDS/RDBMS 접근
람다에서 DB 접근시 유의할 점
여러 가용 영역 내 Subnet에 ENI(Elastic Network Interface) 사용
사용 영역 내 레벨의 이벤트 또는 IP 소모 문제를 피할 수 있다.
람다는 VPC 내 ENI(Elastic Network Interface)로 접근
따라서 가용 IP에 따른 확장성의 제약을 고려 해야함
ENI 신규 구성은 시간이 소모됨
Public host name DNS 쿼리를 피할 수록 좋다
비용가 시간이 소모됨
기본적으로 VPC의 Lambda는 인터넷 접근이 불가능함
NAT Gateway(or NAT instance)를 추가하고 Routing Table 구성으로 사용이 가능함
커넥션 관리
람다의 시간에 따른 사용/확장 가능하다.
확장된 다수의 람다가 DB를 접근한다. 간단하게 생각할 문제가 아니다.
커넥션 풀링과 람다 고려사항
람다 실행 후 컨테이너가 사라지는지 인지할 수 없음
커넥션을 명시적으로 닫을 수 없음
커넥션 삭제는 Database TTL에 의지
람다 컨테이너의 생성/삭제를 조정할 수 없음
Idle 커넥션이 많이 생성될 수 있음
여러 람다 함수의 실행은 여러 다른 컨테이너에서 실행될 수 있음
커넥션의 재사용을 보장할 수 없음
커넥션 풀링과 람다 설정
컨테이너당 하나의 커넥션만 사용
커넥션 풀 사이즈 = 1로 설정
핸들러 밖에 글로벌하게 DB 커넥션 객체를 생생해서 재활용 하는 것이 좋은 아이디어
방법 1
Concurrency를 제한한다.
함수에서 스로틀링 설정을 통해서 한개의 DB에 여러개의 람다 펑션의 호출을 제한할 수 있다.
람다의 Concurrency는 계정과 Function 레벨 모두 제한이 가능하다.
방법 2
동적 커넥션 관리 아키텍처
DB에 접근하는 람다의 실행 정보를 저장하는 헬퍼 람다를 만들어서 커넥션에 관한 컨트롤을 할 수 있다.
람다의 트레이싱
기본적으로 AWS 서비스들은 클라우드 와치를 통해 모니터링이 가능하다.
로그와 매트릭정보로 모니터링이 부족한 경우
X-ray를 통해 더 자세히 람다를 모니터링 할 수 있다.
Tip - 람다의 커스텀 런타임 사용
개발자들은 많이 사용되는 코드는 라이브러리로 분리 시킨다.
항상 똑같은 코드를 사용하는데 반복해서 구현할 필요가 없기 때문이다.
람다도 같은 방식으로 접근할 수 있다.
여러개의 람다함수에서 항상 실행되는 코드는 공유 라이브러리와 같이 커스텀 람다 Layer를 사용해서 해결할 수 있다.
커스텀 런타임 만드는 순서
람다 Function 만들고
Layer(공유 람다 함수) 만들고
Function 등록하고
런타임 등록하고
Layer 공유하고
Function을 실행시킨다.
다수의 람다 함수에서 공통으로 사용하는 DB 커넥션 접근 레이어, 정보 암호화 레이어 등과 같은 동작을 Layer로 만들어서 유용하게 사용할 수 있다.
2. 컨테이너와 서버리스 기반 CI/CD 파이프라인 구성하기
AWS 김필중 솔루션즈 아키텍트
AWS 강승욱 솔루션즈 아키텍트
현대의 애플리케이션 개발의 접근
환경 관리 간소화
서버리스 서비스
코드 변경의 영향 최소화
마이크로 서비스 아키텍처
운영 자동화
새로운 서비스 배포 가속화
CI/CD
리소스와 애플리케이션에서 통찰력 얻기
고객과 비즈니스 보호
배포를 위한 릴리즈 프로세스
프로세스에서 CI 와 CD의 범위
CI/CD가 중요한 이유
이른 버그 찾기
빠른 버그 수정
더 빠르게 전달
더 자주 전달
개발 방해 요소 제거
빠른 기술 향상
현대 애플리케이션 배포에서 중요한 요소
지속적 통합
새 코드가 체크인되면 자동으로 새 릴리즈 시작
일관 되고, 반복 가능한 환경에서 코드 빌드 및 테스트
배포 준비가 완료된 아티팩트를 항시 보유
빌드 실패시의 피드백 루프를 최적화
AWS CodePipeLine
빠르고 신뢰할 수 있는 애플리케이션 업데이트를 위한 지속적 전달 서비스
소프트웨어 릴리즈 프로세스 모델링 및 시각화
코드 변경시 마다 빌드, 테스트 배포
타사 도구 및 AWS와 통합 가능
지원하는 소스
최신 소스코드를 가져와 자동으로 릴리즈 수행
브랜치 기준
AWS CodeCommit
Github
오브젝트 또는 폴더 기준
AWS S3 버켓에서 변경사항 발생되면 파이프라인 시작
신규 - ECR
도커 태그 기준으로 파이프라인 시작
지원 트리거
AWS 클라우드 워치 이벤트
스케쥴링, AWS Health 리벤트
WebHooks
도커 허브
Quay
Artifactory
AWS Codebuild
소스 코드를 컴파일 테스트 패키징 하는 환정 관리되는 빌드 서비스
지속적으로 확장 및 여러 빌드 동시 처리
서버리스 형태로 관리할 빌드 서버 없음
사용하는 리소스에서만 분 단위 과금
클라우드 워치 이벤트를 통해 빌드 모니터링
각 빌드는 새로운 도커 컨테이너에서 실행
모든 공식 Codebuild 이미지는 도커와 AWS CLI를 포함한다.
도커 이미지를 사용하여 사용자 요구에 적합한 사용자 지정 빌드 환경 제공
지속적 배포
테스트를 위해 스테이징 환경에 새로운 변경 사항을 자동으로 배포
고객의 사용성에 영향없이 안전하게 프로덕션으로 배포
고객에게 신속하게 제공 : 배포 빈도를 높이고 리드타임과 실패율을 줄임
AWS CodeDeploy
모든 인스턴스와 람다로 코드 배포를 자동화
애플리케이션 업데이트의 복잡성을 처리
애플리케이션 배포중 다운타임 최소화
오류 감지 시 자동 롤백
EC2, 람다, 온프레미스 서버에 배포 가능
Lambda 배포
람다 함수 가중치 별칭을 사용하여 트래픽을 이동
Canary(10분 동안 트래픽의 10%만 이동, 그 후 나머지를 이동) 또는 Linear(매 10분 마다 10% 트래픽씩 이동) 중 선택
유효성 검사 후크로 각 배포의 각 단계에서 테스트가 가능
후크 실패 또는 클라우드 워치 발생시 수 초 내의 빠른 롤백 가능
배포 상태 및 기록을 콘솔, API, SNS 알림, 클라우드 워치 이벤트로 모니터링
ECS Blud/Green 배포
Green 작업을 프로비전하고, 로드벨런서에서 트래픽을 전환
유효성 검사 후크로 배포 각 단계에서 테스트를 수행 가능
후크 실패 또는 클라우드 워치 이벤트 발생시 Blue 작업으로 수초 내의 빠른 롤백 가능
배포 상태 및 기록을 콘솔, API, SNS 알림, 클라우드 워치 이벤트로 모니터링
CodePipeline에서 CodeDeploy-ECS 배포 작업을 사용하거나 젠킨스에서도 사용 가능
배포 과정
100% Prod 트래픽 존재, 로드 밸런서는 Test 트래픽 리스너를 열고 대상그룹 2 생성
V2에 해당하는 Green 작업 프로비저닝
Green 작업이 Prod 트래픽을 받기 전 테스트 엔드포인트에 후크 실행
Green 작업으로 트래픽 전환, 알람 발생시 즉시 롤백
마지막으로 Blue 드레이닝
배포를 위한 컨테이너 이미지 태깅 주의점
배포 중이 아닌 각 컨테이너가 시작될 때 도커 태그가 해석됨
Latest 또는 prod 배포는 스케일 아웃 이벤트 후 프로덕션에 테스트 퇴지 않은 코드가 배포될 수 있음
배포시 고유한 '변경 불가능한' 태그 사용 권장
코드형 인프라
인프라 변경 사항을 반복적이고 예측 가능하게 함
코드 변경과 동일한 도구를 사용하여 인프라 변경 사항 릴리즈
스테이징 환경에서 프로덕션 환경을 복제하여 지속적인 테스트를 가능하게 함
아티팩트 검증(빌드 단계)
유닛 테스트
정적 분석
목업 의존성 및 환경
취약점 이미지 스캔
환경 검증(테스트 단계)
실제 의존성 및 실제 환경에 대한 통합 테스트
부하 테스트
침투 테스트
환경에 미치는 영향을 테스트하기 위한 모니터링
IaC(Infrastructure as Code)
AWS Serverless Application Model(SAM)
AWS에서 서버리스 애플리케이션 구축을 위한 오픈 소스 프레임워크
함수, API, DB, 이벤트 소스 매핑을 표현하는 약식 문법
배포시 SAM 구문을 CloudFormation으로 전환
간단한 SAM 구문으로 다양한 AWS 리소스 생성 가능
AWS Cloud Deployment Kit(CDK)
현재 개발자 미리보기로 서비스 중
타입스크립트로 클라우드 인프라를 정의하는 오픈 소스 프레임워크
AWS 베스트 프랙티스를 기본으로 하는 고수준 리소스 타입("construct")의 라이브러리를 제공(npm)
리소스는 CloudFormation으로 준비됨
예를 들면, 22줄의 CDK 소스 코드로 400줄의 CloudFormation 코드가 생성됨.
3. 워크로드에 맞는 클라우드 데이터베이스 찾기
AWS 박주연 솔루션즈 아키텍트
데이터베이스 역사
최근 들어 목적에 맞는 다양한 DB들이 많이 생겼다.
공통적인 데이터 범주 및 사례
Relational
데이터 무결성 및 트랜잭션 보장, 스키마 보장
기존 워크로드 마이그레이션 ERP 및 CRM, 금융 서비스
Amazon RDS
Key-Value
높은 처리량, 최소 지연 보장, 유연한 확장
실시간 입찰, 온라인 쇼핑, 장바구니, SNS, 제품 카달로그, 고객 환경 정보
Amazon DynamoDB
Document
문서 저장 및 해당 문서의 모든 속성에 대한 빠른 조회
컨텐츠 관리, 모바일, 개인화
Amazon DocumentDB
In-memory
키를 기반으로 마이크로 초 이내의 응답 요구
게임 유저 랭킹, 실시간 분석, 캐싱
Amazon ElastiCache
Graph
데이터 간 신속하고 간편한 관계 구축 및 탐색
사기 탐지, 소셜 네트워킹, 추천 엔진
Amazon Neptune
Time-series
시간에 따른 데이터의 용이한 수집, 저장, 처리
IoT 애플리케이션, 이벤트 기반 추적
Amazon Timestream
Ledger
애플리케이션 내 모든 데이터에 대해 완전하고 변조 불가능한 기록 관리
공급망 관리, 헬스케어, 등록 관리, 재정
Amazon QLDB
AWS 데이터베이스
DB를 운영하는 방법
Self Managed(On-Premise)
RDBMS on AWS EC2
Fully Managed(AWS DBs)
데이터 베이스 운영 방안에 따른 관리 영역
Fully Managed DB는 사용자가 컨트롤해야 하는 영역이 줄어들어, 워크로드에 집중할 수 있다.
DB를 운영하는 데 있어서, 제약 사항이 없다면(개인정보, 사내 정책 등) Fully Managed DB 전환을 고려해볼 수 있다.
Amazon RDS에서의 데이터베이스 관리자 역할 변화
관리적인 요소를 AWS가 가져 가기 때문에, 담당자가 본인의 업무(쿼리 튜닝 등)에 집중 할 수 있다.
Amazon Relational Database Service(RDS)
가장 많이 선호하는 데이터베이스 엔진을 갖춘 관계형 데이터베이스
AWS Aurora
클라우드를 위해 구축된 MySQL 및 PostgreSQL 호환 관계형 데이터베이스
Amazon DynamoDB
어떤 규모에서든 빠르고 유연한 Key-Value NoSQL 데이터베이스
Amazon DocumentDB
빠르고 확장 가능하며 가용성이 뛰어난 MongoDB 호환 데이터베이스
Amazon ElastiCache
Redis 및 Memcached와 호환되는 인 메모리 데이터 스토어 및 캐시
사용 예시
Amazon ElastiCache는 대규모의 실시간 지리 공간 데이터를 빠르게 관리할 수 있도록 인 메모리 데이터 구조 및 연산자를 제공하므로 주행 시간, 주행 거리, 관심 지역 정보와 같은 위치 기반 기능을 가진 애플리케이션에 적용 가능
Amazon Neptune
빠르고 안정적인 완전 관리형 그래프 데이터베이스
데이터간 관계성 증가에 따른 고려
Amazon Timestream - preview 상태
빠르고 확장 가능한 완전관리형 시계열 데이터베이스
시계열 데이터 예시
사용 예시
기본 탑재된 분석 기능을 사용하여 IoT 애플리케이션이나 산업용 장비들이 생성하는 시계열 데이터를 빠르게 분석, 데이터가 증가해도 가능한 한 최소 비용으로 지속적이며 예층 가능한 성능을 유지
Amazon Quantum Ledger Database(QLDB) - preview 상태
완정 관리형 원장 데이터베이스
애플리케이션에서 모든 데이터 변경 기록 추적 및 확인
AWS 데이터베이스로 전환하려면..
데이터를 전환하는 방안
클라우드 전환
AWS SCT(Schema Conversion Tool)
온프레미스 DB를 클라우드로
온프레미스 DW를 클라우드로
마이그레이션
AWS DMS(Database Migration Service)
애플리케이션 무중단 데이터 마이그레이션
복제 인스턴스 생성
원본 및 대상 데이터베이스 연결
복제 대상 스키마/테이블 혹은 데이터베이스 선택
AWS DMS를 통해 테이블 생성, 동기화 진행
전환 결정
데이터 복제
AWS DMS(Database Migration Service)
교차 리전간 읽기 전용 복제본 구축
클라우드 환경에서의 분석 작업 실행
데이터 레이크로 데이터 채우기
AWS 데이터베이스의 다음은..
AWS의 데이터 서비스 포트폴리오
데이터를 활용하여 할수 있는 분석, 예측, 머신러닝 등 Data Lake 영역의 여러가지 서비스를 고려중이다.
4. 진화하는 CloudFront의 이해와 글로벌 서비스 활용
GS 네오텍
CDN(Contents Delivery Network)
왜 필요할까
트래픽은 거리가 멀수록 / 데이터의 양이 많을 수록 전송이 지연됨
대부분의 속도 저하는 Middle Mile 구간에서 발생
진화하는 CloudFront
AWS 고가용성 글로벌 CDN 서비스
Static Contents 캐싱
Dynamic Contents 전송 성능 개선
Contents 보호 : 무료 SSL 및 Custom SSL 지원
Contents 보안/제어 : Signed URL, Signed Cookie
Origin 장애 조치 지원 : Origin Group
S3 업로드 가속 기능
클라우드 프론트의 전세계 배치
AWS Global Backbone
서울 <-> 유럽 데이터 전송 성능 비교
Origin이 서울 리전의 Amazon S3 이고 Client가 Ireland에 있다고 가정한 테스트 결과
10MB 파일이 첫번째 요청에 다운로드 되는 성능을 비교함
AWS Backbone을 거치는 CloudFront 이용시 평균 5초, S3에 다이렉트로 접근시 평균 12.8초 소요
Features
Static Contents Delevery
캐시를 이용해 빠르고 안전한 Static Contents 전송
Dynamic Contents Delivery는?
전체 응답 시간 = DNS Lookup + TCP Connection + Time To First Byte + Contents Download
진화된 CloudFront의 Dynamic Contents Delivery 전송 성능 향상 방법
요청자 - Edge간 연결시 최적화 Edge 연결
Origin과 지속적인 연결 유지
Keep Alive connection을 통한 연결 설정 시간 단축
Edge - Region간 모니터링으로 최적화된 네트워크
Gzip 압축 사용
Compress Objects Automatically 설정 YES
최대 80%속도, 비용 개선
1KB ~ 10MB 크기의 파일 압축
웹 페이지 로딩 속도 개선
콘텐츠 다운로드 시간 단축
데이터 전속 비용 절감
압축 테스트시 반드시 지원 되는 파일 타입으로
Cross-Origin Resource Charing
원본 리소스 쉐어링을 통해 같은 도메인에서 서비스가 가능하게 해줌
Origin Group
Origin 장애 조치 지원
Origin Group 내에 2개의 Origin 설정
SSL 지원
Signed URL, Signed Cookie 사용
배포되는 Contents에 대한 보호 및 세부 제어
Signed URL - 일반 Contents, RTMP 서비스
Signed Cookie - HSL 서비스
CloudFront 활용
CloudFront + s3
가장 손쉬운 구성으로 Static Contents를 제공
Contents File을 S3 버킷에 무제한 업로드
CloudFront + EC2
Dynamic Contents를 제공
CloudFront + Route53
GEO Location을 활용한 Multi CDN 활용 가능
사진에서 보면 멀티 CDN 구성을 통해서 일반적으로는 Global CDN을 중국에서는 China Local CDN을 사용한다.
CloudFront + Lambda@edge
CF와 람다엣지 사용 시나리오
CF에서 img를 요청하고 128X128 이미지가 없을 경우
S3에 해당 이미지를 128X128로 리사이징해서 저장하는 람다 함수를 invoke 한다.
'Experience > 2019' 카테고리의 다른 글
| NHN FORWARD 2019 후기 (0) | 2019.11.28 |
|---|---|
| 우아한 Redis 세미나 후기 (0) | 2019.11.22 |
- Total
- Today
- Yesterday
- vuejs
- 자바
- Spring Boot
- Algorithm
- 시간복잡도
- vuex
- 정렬
- 젠킨스
- Recursion
- IT융합인력양성사업단
- springboot
- AWS
- 스프링부트
- github
- Vue.js
- Wisoft
- 인프런
- Raspberry Pi
- ORM
- 한밭이글스
- 무선통신소프트웨어연구실
- 라즈베리파이
- Java
- RBT
- 알고리즘
- 레드블랙트리
- 순환
- JPA
- 한밭대학교
- Spring
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |