티스토리 뷰

국내에서 매년 열리는 AWS 행사중 가장 규모가 큰 AWS SUMMIT 2019 두번째 날 행사에 다녀왔습니다.

매년 참석자가 폭증하는 느낌 인데요. 세션 이동중 찍은 사진인데 정말정말 사람이 많았습니다.

엑스포 규모와 이벤트도 거대했구요. 이정도 스케일의 행사를 진행하는 AWS측의 능력도 인정해줘야 할 것 같습니다.

제가 들은 세션중 일부 내용을 공유합니다.




Contents

  1. AWS Lambda 내부 동작 방식 및 활용 방법 살펴보기

  2. 컨테이너와 서버리스 기반 CI/CD 파이프라인 구성하기

  3. 워크로드에 맞는 클라우드 데이터베이스 찾기

  4. 진화하는 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 배포 작업을 사용하거나 젠킨스에서도 사용 가능

      • 배포 과정

        1. 100% Prod 트래픽 존재, 로드 밸런서는 Test 트래픽 리스너를 열고 대상그룹 2 생성

        2. V2에 해당하는 Green 작업 프로비저닝

        3. Green 작업이 Prod 트래픽을 받기 전 테스트 엔드포인트에 후크 실행

        4. Green 작업으로 트래픽 전환, 알람 발생시 즉시 롤백

        5. 마지막으로 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 한다.

    • 그러면 CF에서는 200 OK와 이미지를 내려준다.








'Experience > 2019' 카테고리의 다른 글

NHN FORWARD 2019 후기  (0) 2019.11.28
우아한 Redis 세미나 후기  (0) 2019.11.22
댓글