AWS Summit 2019 Seoul

AWS Summit 2019 에서 참석했던 세션 요약입니다.

마이크로 서비스 에서 데이터 베이스

  • 데이터 베이스는 여전히 성장 중
    • 오라클 디비를 아마존 DynamoDB로 옮기는 사례 증가
  • 그러나 모노리틱 시대는 끝났다
  • 시대의 변화를 위한 아마존 서비스들
    • 오로라 포스트그리 SQL : 비용및 빠를 구조
    • 다이나모 디비 : 큰용량
    • 아마존 엘라스틱케쉬 : 빠른 응답
  • 반복적인 유지보수 해결책
    • 앱을 작은 조각 - 조각간 통신 개발환경 구축 - 데이터 베이스도 분산
    • 요구사항 ; 글로벌, 페타이상의 크기, 수억 리퀘스트, 다양한 플랫폼(웹, 모바일 등)
  • 데이터 모델에 따른 서비스
    • 기존 관계형 모델은 정확하지만 복잡(파이넨스) : Aurora
    • 키-벨류 모델은 빠르고 확장성(쇼핑몰) : DynamoDB
    • Document모델(문서 관리) : DocumentDB
    • 인메모리 모델은 엄청 빠른 속도 확장성: 엘라스틱 케시
    • 그래프 모델은 복잡하고 방대한 설계 : 아마존 넵튠
    • 타임시리즈 모델 : 아마존 타임스트림
    • Ledger는 절대 변경불가 모델(블럭체인) : 아마존 QLDB
  • 사례
    • AirBnB
      • 검색이력 : 아마존 다이나모 디비
      • 세션 :엘라스틱케시
      • 관계형디비 : 오로라 MySQL
    • 버라이즌
      • 관계형디비 : 포스트그리
      • GDPR대응을 위해 지역 분산: 다이나모 디비
      • 캐시 : 엘라스틱 케시
    • 삼성
      • 수억명의 사용자 정보를 보관 : 카산드라 쓰다가 다이나모 디비로 넘어감
      • 관계형 : 오로라
      • 소셜 관계 : 넵튠
      • 엘라스틱케쉬
    • 롯데
      • 상품 이미지나 메타데이타 : 다이나모 디비
      • 카달로그 : 리스트 빠른 응답 엘라스티 케시
      • S3기반 데이타 레이크 : 레드 시프트
      • 사용자 : 오로라 MySql
  • 마이크로 서비스 구현 사례
    • 마이크로 서비스 데이터 베이스 : 롯데 B2
      • RDB : 전통의 강자, 많은 숙련자, 무결성
      • NoSQL : 자유로운 스키마, 진입이 꺼려짐(무결성x, 개발자 부족 등)
      • 과연 RDB는 좋을까?
        • 정규화 맞추기 어려움 - 튜닝 - 프로시져,펑션으로 대체 - 무한 반복(비용 증가)
        • 익숙할 뿐 편리한 건 아니야
      • RDB(Monorithic)에서 비지니스(MSA)중심으로 전환
        • 오픈소스 들의 관리 어려움, 부담
        • HA구성 어려움
      • 멀티 데이터 스토어 기준
        • 관리형 서비스 중심
        • 목적에 맞게 분리 - 고객용 비고객용 구분
        • 서비스 중심 아키텍처(아키텍처 중심이 아님) - MSA
      • 핫,웜,콜드 데이터 기준 분류
        • 낮은 레이턴시, 잦은 스키마 변경 : 다이나모
        • Data Lake : S3, Redshift
      • 데이터 파이프라인 구축
        • 대고객(Tier-0), 백오피스업무(Tier-1)
        • Glue, ETL, Firehose, S3 를 엮어서?
      • 다이나모 디비
        • RCU, WCU 조절로 성능 설정 좋음
      • 동기 비동기 구분
        • 동기처리는 DDB Stream - Lambda
        • 비동기는 Kinesis Firehose
      • Full text 검색
        • DynamoDB Stream + Lamda로 ElasticSearch에 넣어서 처리
      • 다량의 데이터 인은 DynamoDB- Firehose(버퍼)- RDB 또는 DynamoDB Stream-kinesis client(분산) 으로 처리
      • 비동기는 Glue활용 (크롤러로 카달로그 생성, 카달로그에서 딕셔너리 정보 추출)
      • 배치기능은 지양하고 싶었지만, 아래 방식으로 처리
        • 클라우드 와치 이벤트 활용 - 람다 호출
        • 데이터 레이크의 Athena(Presto Query)로 추출 - 결과는 S3에 적재
        • 비즈니스 로직이 많은 경우엔 람다 적극활용(이벤트가 람다 호출) - 다이나모디비를 메시지 브로커로 하여 멱등성 관리(장애 처리)
      • ETL : 잘 못들음..
      • 결론 : 데이터 “베이스”가 아니라 저장소로 변경
        • 서비스 중심 사고
        • 동기화 개념 ETL은 Data stream process template 적용(ETL지양)
        • 용도에 따른 분리
        • 스트림데이터(줄을 서서 처리가 오래 걸림) 의 병렬처리 고민
        • 키네시스 파이어호스의 500개 인입 제한은 다른 메시지 브로커 사용
        • Athena 빈도 증가 - EMR 등 비용 절감

AWS에서 Kubernetes 실행하기

  • EKS 아키텍처, 글로발 고객 사례(Fidelity, Snapchat, State Street), 데모
  • EKS 아키텍처 : AWS 의 관리형 서비스
    • Tenets : 서비스를 만드는 원칙
      • EKS는 대규모 회사용 작업부하를 실행하는 플랫폼
      • EKS는 순수 쿠버의 업스트림의 경험을 유지(파편화 하지 않겠다?)
      • 다른 AWS와 매끄럽게(복잡하지 않고 쉽게) 연결
      • Kube오픈 소스에 적극적으로 기여
    • 아키텍처 - 잘 아는 그림
      • kubectl - EKS - 워커노드(VPC/EC2)
      • EKS 컨트롤 플레인
        • 고성능 고가용성, 단일 테넌트 인프라
        • 순수 AWS서비스
        • NLB로드 밸런싱
        • 컨트롤 플레인 로그(신서비스 출시)
          • API Server, Audit, Controller manager 등 모니터링
      • 데이터 플레인
        • 다양한 인스턴스(p2, p3.gpu, i3.metal, c5(스냅쳇), 스팟)
        • AI/ML용 EKS AMI 제공
        • EKS AMI 빌드 스크립트
      • 교차계정(cross account) ENI
        • 멀티 VPC로 구축 - 프라이빗 액세스로 VPC간 통신 지원
      • EKS와 함께 구성한 K8S 컴포넌트
        • 사진
        • 칼리코 네트워크 정책
        • 공유하는 스토리지 요구사항 - EFS, EBS
      • 필요한 구성
        • AWS Secret Manager, KMS, IAM을 이용
        • K8S의 RBAC을 연동
      • 네트워크 제어
        • VPC SG과 Subnet NACL과 Pod레벨의 네트워크 세그먼테이션 등과 연계
      • EKS 네트워크 레이어
        • 3개의 IP주소 계층
          • K8S 클러스터 - Pod - AWS VPC
        • VPC의 CNI에서는 AWS IP를 할당
          • ENI가 팟에 할당 - ENI를 CNI 플러긴이 외부와 연결
          • 주의 : 인스턴스 타입별로 붙일 수 있는 ENI갯수가 정해져 있음
      • CICD
        • AWS 코드 시리즈 - Helm과 연계
        • 사진
        • 람다를 통해 배포된 ECR을 EKS에 배포
        • 파라미터 저장소(AWS System Manager)에서 token을 관리
      • 가시화/모니터링
        • CloudWatch의 매트릭스, 로그, 클라우드 트레일과 EKS의 HPA등과 연계
        • EFK(Elastisearch - flunted- kibana)
      • EKS 로드맵을 참고하세요
  • 활용사례
    • 요약
    • 사례1- 스냅챗
      • 엄청난 인기로 초거대한 모노리틱 서비스가 됨
      • 마이크로 서비스를 구현하고자 함 - Kube로 가길 결정 - 관리의 용이성을 위해 관리형 서비스 선택
      • 7500 vCPU 를 쓸정도로 크게 만듦
    • 사례2 - State Street (미국 유명 은행)
      • 무제한의 컨시스턴시와 트랜젝션을 감당하는 데이터베이스를 구축하고자 함
      • EKS의 확장성을 활용 - 1초에 수백만 쿼리 달성
    • 사례3 - Fidelity(금융회사)
      • 수천개의 애플리케이션과 8백개의 DevOps팀
      • 비용대비 효과를 추구
      • 클라우드 파운드리를 해보려 했지만, 결국 컨테이너 기반으로 선택
      • 사진의 동그라미가 데브옵스 조직
        • EKS 어드민(아래) : EKS 관리, 권한, 백업, DR등
        • DevOps(맨 왼쪽) : 어플리케이션을 개발 배포
        • SRE(맨 오른쪽) : 서비스 안정화 - 로그/메트릭/KPI 지표 관리
      • 플렛폼 체계 (자체 운영 기준을 세움)
        • 네임스페이스 로 나누어 관리(관리용, 애플리케이션용)
        • 사진
        • AWS IAM role을 EKS RBAC과 연계
        • 자체적으로 EKS매니저 도구를 만들어서 부트스트랩핑으로 관리 구축
          • ADM그룹, Helm등
      • 모니터링
        • 이벤트를 4가지로 분류
          • 인프라(EC2, Network)
          • 매니지먼트(관리형 서비스의 이벤트)
          • 이벤트 - Kube의 이벤트
          • 애플리케이션
        • 클러스터 구축시 함께 구축(설정)

MongoDB Atlas

  • 고객들이 원하는 데이터베이스
    • 쉽고
    • 플렉시블
    • 빠르고
    • versatile(다양한 쿼리, 데이터 지원)
    • 시장에서 원하는 특징
      • json : 프론트엔드 - 백엔드 - 데이터베이스 간 동일한 포맷(Or mapping이 필요 없음)
      • 데이터가 커지면 테이블을 수정할 수 없음(거의 불가능)
      • 다양한 값을 받다보면 유연하게 바꾸기 힘듦
      • 불필요한 조인과 분리가 없어짐
      • 그러나, json의 경우 인덱싱이 어려움 - 확정적이지 않고 파싱이 어려움
      • 몽고디비는 이 부분에 대해서 선도
    • 데이터를 효과적으로 저장하는 방법
      • 미션 크리티컬 한 것은 - 오라클이 대부분 장악
        • 비싸다, 스케일 아웃이 어렵다(논리적으로 쪼개둔 것을 각각 확대하기가 어려움)
      • 몽고디비는 레플리카로 HA지원
        • 3개 이상의 복제
      • 샤딩이란 아키텍처로 분산 저장 - 스케일러블
      • 동일한 클러스터를 서로 간섭없이 운영/분석 - 워크로드 아이솔레이션
      • 글로벌 비즈니스 시 로컬리티 - 거버넌스(GDPR), 지연(레이턴시) 특성을 고려
  • 해답은 몽고디비 아틀라스
    • 관리형 서비스
    • 타임투 마켓, 비즈니스 모델에 집중 - 매니지드 서비스가 유리 (자체 운영/개발 시 눈에 보이지 않는 비용)
    • 6가지 특성(장점)
      • 사진
      • 셀프 서비스, 엘라스틱 스케일링
      • 고가용성, 높은 보안 인증
      • 엔터프라이즈 지원 - SLA, LDAP
      • 모니터링 도구, 서드파티가 부족한 NoSQL - 100여가지 매트릭을 실시간으로 제공
      • 백업 - 콜드/핫, 시점 두 가지 다 지원 (모든 백업을 클라우드 스냅샷으로 변경예정 - 2019 06)
      • Stitch: 서버리스 플랫폼 서비스, Firebase와 비슷 - 단순한 API를 위한 서버리스I, 일부 보호된 데이터만 프론트로 제공
    • 아마존 호환
      • 16개 리전 지원
    • 글로벌 클러스터
      • 국가, 지역별 정부의 데이터 정책이 다름
      • 리드 클러스터는 다른 지역에 배치하는 등, 글로벌 분산
      • 멀티 리전 레플리케이션 구성(HA 구성 가능) : ex)도쿄는 컨텐츠, 서울은 페이먼트
        • Electable node
          • primary가 될 수 있는 노드
        • Read only node
          • 레이턴시 해결을 위한 노드
        • Analytic node
    • 실시간 모니터링
      • 지금 던진 쿼리의 영향 파악
      • hottest collection
      • slowest operation
    • 파인 그래인드 모니터링 & 경고
      • 100가지 이상의 매트릭
    • 성능 어드바이저
      • 권장사항을 제공해 줌
      • 성능향상, 비용 절감 도움
    • 보안 : 고객전용 VPC
      • VPC peering 제공
  • 고객사례
    • 뱅크샐러드
  • 향후 몽고디비 처럼 Object Storage를 쿼리할 수 있는 서비스 출시 예정
  • AWS DocumentDB보다 나은점?
    • API만 에뮬레이팅 한 것보다 낫다
    • 차이점과 기능은 부스에서…

EKS통한 차량 공유서비스 ‘타다’ 구축기

  • 여러 세션에서 많이 뵌 분… VCNC GitHub.io/ditto
    • 비트윈 개발자
    • 실시간 호출, 예약 서비스 제공
  • 아키텍처 / EKS 사용 경험(kops -> EKS 경험)
  • 기술 선택 배경
    • 빠른 시장 변화
    • 짧은 초기개발 시간(4개월만에 개발)
    • 기존 기술(비트윈)의 반면 교사
      • HBase + Haeinsa
      • RPC/메시징, 로그 수집 : 인하우스 프레임워크(자체개발)
      • 덜 중요한 문제에 시간 낭비, 낡기 쉬움(지속적 개선이 안됨)
    • 흔하고 성숙된 기술을 선택
      • MySQL, Spring Boot, Redis
      • gRPC, Kuber, Kotlin
      • AWS 관리형 서비스: 오로라, 엘라스티서치, 클라우드와치 등
    • 느리고 복잡합 패포 해결
      • 기존 : 많은 서비스, 다양한 기술 스택 -> Ansible + Packer -> 작은 서비스는 묶어서 배포하기 위해 수작업 필요, 서비스간 영향
      • 개선 : 기술 스택 통일, 컨테이너, 컨테이너 오케스트레이션(kuber)
  • 타다의 서비스 구성
    • 클라이언트 : 고객 / 드라이버 2가지 앱
    • 백앤드 : API서버 + 오로라 MySQL
    • 실시간 이벤트 처리 : gRPC 서버 - Redis (publish-subscriber 패턴)
      • 클라이언트 -(이벤트 구독)-> gRPC 서버
      • gRPC서버는 Redis의 토픽 구독
      • API서버나 각종 워커가 Redis로 이벤트 퍼블리시
    • gRPC 특징 - 오픈소스, 다양한 언어지원, HTTP/2 기반, 적은 데이터 전송량, 스트리밍 지원
    • 위치수집 : 드라이버 앱이 주기적으로 위치수집 서버에 GPS정보 전송 - Kinesis Stream에 넣음(Kinesis가 죽지 않는 한 데이터가 저장됨) - 트래커 서버가 읽어 오로라 MySQL기반 DB에 저장 (Kinesis를 중간에 둠으로써 샤딩, Stateful한 데이터를 동일한 컨슈머에 전달하는 특성)
      • 중간에 부정확한 GPS 보정기능을 넣어 효율적인 처리
    • 차량 호출 : API 서버에 요청, API서버는 SQS에 요청을 쌓음(매칭되는 동안 클라이언트에게 응답을 해주기 위해) - 디스패처 서버에서 트래커디비와 메인 디비를 조회해서 매칭
    • 사용자 행동 로그 수집 : 로그백의 Kinesis appender가 Kinesis stream에 넣음 - Firehose가 이를 가져가서 S3에 저장, 아테나? CloudWatch logs insight?(잘 못봄?) 가 분석
    • 이런 서비스 서버들은 쿠버에서 동작하고, 아마존 관리형 서비스와 연결
      • 서버간에는 직접 통신하지 않음
  • 타다의 EKS 활용
    • 미국리전에만 출시 - 한국에 출시되기 까지 kops로 구축
    • 서울리전에 출시되자마자 마이그레이션
    • 쿠버네티스의 구성 설명
      • 마스터노드와 워커노드(kublet이 pod관리)
    • 마스터 노드는 HA를 유지해야 함 - EKS가 해결
    • 워커노드는 EKS최적화 AMI가 있음, autoscaling group 활용
    • ECS와 유사
    • 기본설정
      • AWS IAM기반 kube api서버 인증
      • ENI기반 네트워킹 플러그인(CNI?)
        • 참고: 노드당 ENI 갯수 제한있음(C5=25개)
    • 마이그레이션 절차
      • 기존 서버 클러스터와 EKS의 서버 클러스터를 함께 띄움
      • Route53의 weighted routing으로 기존 클러스터에서 서서히 옮겨옴
      • Kube 뿐아니라 RDS와 Redis도 AZ 두개로 동작 -> EKS 도 동일한 AZ(별도의 subnet)으로 생성
        • helm(패키지 매니저)의 차트로 그대로 생성
          • 기반서비스(nginx, fluentd)
          • 이후 서버, 프론트엔드 설치
      • 각 클러스터는 NLB로 맞이함, Route53에서 가중치를 두고 NLB로 분배
        • 100% 옮긴 후 기존 클러스터 제거
        • 그러나 DNS캐쉬를 대응하기 위해 NLB는 남겨두고 NLB의 대상을 새 클러스터로 수정
        • 기존 클러스터는 테라폼이었음 - 간단하게 종료
      • 상용환경을 위한 서비스
        • Ingress controller
          • 내부 서비스를 외부로 노출시켜 줌
          • (인터페이스라)실제 설치를 해야 동작을 함
          • Nginx Ingress controller 또는 AWS ALB Ingress controller
            • aws : 인그래스 1개당 ALB 1개 생성, gRPC 미지원
            • nginx : nginx 서버 기반, gRPC지원, 외부 로드밸런서 필요
        • 로드밸런서
          • Classic ELB (HTTP)
          • Classic ELB (TCP)
          • ALB : HTTP/2 지원하지만 gRPC미지원
          • NLB : TLS termination지원하지만, HTTP/2, gRPC 미지원 - nginx에서 TLS처리 (인증서 사야됨)
          • 그래서
            • NLB + nginx
            • nginx gRPC모듈
            • nginx에서 TLS 처리
        • 모니터링, 로깅
          • 컨테이너 사라지면 로그 삭제, 용량 커져도 곤란
          • fluentd : 로컬에 저장된 로그파일을 클라우드 와치 록스로 전달 - CloudWatch logs insight로 분석
          • EC2의 CloudWatch 매트릭은 의미 없음 - 프로메테우스 솔루션 사용
        • kube2iam 사용
          • 팟마다 다른 iam 프로파일을 사용하기 위함
      • VCNC 기술 블로그 : engineering.vcnc.co.kr