AWS DNA 1기 교육자료 정리

Microservice

• Server
  • EKS
  • ECS
  • Fargate
  • Ec2
• Serverless
  • Lambda

요구사항에 맞게 정의해야함, 우리의 어플리케이션이 컨테이너에 적합한지 안한지, 트렌젝션에 대한 유지를 어떻게 할지에 따라 정의하는 방식이 다름.
Docker images 경량화 정책 정의 필요함 (run command 정합, yum cache clean 등의 작업 진행)
EKS : Controller plane , Data Plain 간 버전 차이는 문서의 요구사항에 따라 일부 달라도 상관은 없음. (Worker Node 업그레이드에 따른 일시 중단이 있을 수 있음)

• Master, Etcd는 AWS의 SLA 로 보장됨
• 외부 kubectl 로 작업을 진행 할경우 Default NLB Domain으로 접근이 가능함 (Private 로 별도 설정 가능함)
• DataPlane : Control plane의 API로부터 Kubelet내에 Pod 생성되며 Worker Node가 생성죔(어떤 Worker Node로 한걸지 선택이 가능함)
• 전삼 감사에 대한 작업으로 EC2 ssh 접근은 차단하고 EKS 내 Docker 컨테이너만 관리 할 수 있는 방향으로 진행

AWS CDK : AWS 서비스 생성시 해당 서비스 개발을 편하게 하기위한 kit 제겅*

• 작업후 CloudFormation으로 변환되어 작업이 진행됨
• 작업속도가 굉장히 빠른게 장점(POC나 개발 테스트에 유용함)
• 해당 리소스의 이름을 상세하게 정의할 수 없음

Code Pipeline

• Code Commit
• Code Build
• Third-Party Tooling
• CodeDeploy

VPC 운영

VPC

• VPC 기본 5개
• secoundry CIDR 최대 4개
• Subnet 최대 200개
• 고정 IP는 최대 5개

Bastion host 보다는 System Manager를 사용하는 형태로 운영하는 방식이 있음

• 기본 VPC의 IP 대역대는 초기 설정이 중요함( 사업이 커지는 경우 IP 가 겹치면 Peering등 묹베가 많이 생김)
• IP Address 는 기본적으로 상세한 정보보터 참조함(라우팅테이블) Ex:) 172.13.0.0/16 보다 172.31.12.0/24 이 먼저 참조됨. 보다 상세한 정보부터
• NACL 차단이 기본 - 규모가 큰 설정에 좋음
• SG는 허용이 기본 - 상세한 설정에 좋음
• VPC Flow logs : ENI 카드에서 생성되는 로그들을 CloudWatch/ S# 에 적재 및 확인이 가능함. -> 네트워크 장애 파악 및 보안상 로그 기록으로 유용함.
• VPC Traffic Mirroring
  • UDP listener를 기반으로 ENI,NLB 트래픽 카피 가능(트래픽에 대한 상세한 정보를 로깅 및 분석 가능함)
• VPC 밖에 있는 완전 관리형 서비스의 경우는 기본적으로 IP 대역대가 매번 변경됨. (인프라팀에서 확인할 방법이 많지 않음)
  • 기본적으로 각종 VPN 장비 및 벤더에서 자동으로 변경시켜주는 옵션을 제공하고 있음.(Email 노티 또는 API)

NoSQL과 Cache

• DynamoDB
  • RCU, WCU( LSI 는 두번에 1카운트 GSI는 한번에 1카운트)
  • RCU는 4kb 당 과금
  • GSI는 이벤스텅 일관성만 지원하지만 LSI는 최종 일관성과 이벤트성 일관성을 전부 지원함)
• Elasticsearch Service
• Kinesis data stream, Kinesis Firehose
  • firehose http endpoint 지원 - 하지만 인덱스 명은?
• Textract
• ElasticCache
  • Memcached
  • Redis
• Neptune
  • 제플린과 굉장히 흡사함
  • 그레프데이터베이스로 관계도나 추천 서비스에 적합함
  • 정보를 그래프 형태로 표현 하면서 기계 학습에도 활용 가능함

Redshift

• 병렬성 처리 -> redshift스팩트럼 형태로 변경
• vcpu분할 및 그룹핑(슬라이스)
• Redshift 스팩트럼과 함께 사용
• 테라 단위 넘어가는 순간부터는 dw의 성능 우세
• sorting, distribute 확인.
  • ALL : 스팩트럼에 전부 저장(1000만건을 4개에 스팩트럼에 전부 목사
  • Key(Hash) : 1000만건을 4분할 하여 스팩트럼에 균등 저장
    • dist키로 Join과 group, partition에 쓰임(테이블 별로 키는 동일하게 들어가야함)
    • redshift는브로드 케스팅의 최악임
    • 테이블 생성 삭제는 자유롭게(Create table as select가 좋음)
  • Even : Key와동일함(Round-robin) join이나 group by 가 없는경우만 사용 - 최근
  • Auto Diststyle : ALL로 생성 되었다가 스토리지 양이 한계에 갔을때 Even으로 변경처리(리벨런싱, 성능하락 의 주 원인)
• sort ( merger join 성능 우위) ->NestLoop(버블정렬) 상대적으로 안좋음
  • 일반적인 조인인 경우 HASH Join으로 사용함
• diststyle
  • Distribution Key : Partition By, Group By, join 하는 경우 성능 우위를 위하여 테이블 별로 동일한 값이 있을때 해당 컬럼을 잡는게 좋음
  • Sort Key
    • Compound : index의 순서에 따라 조건이 hit 됨
    • Interleaved : 각 Column별로 hit 되나 compound에 비하여 성능이 떨어짐
• compress/de-noma
• sort key
  • zone map사용한 sort하는 경우 블럭 단위로 변경하여 대상 정보를 찾음

Athena

• 쿼리 분석후 해당 쿼리의 자원을 할당함
• 대규모 병렬에는 자원 할당에 따라 성능이 달라지기에 급증하는 트래픽에 무리가 있음
• 위와 같은 이유에 의해 할당 제한이 걸려있음

Redshift & Redshift Spectrum VS BigQuery

• Of Slices -> Of Spectrum Nodes -> Of Connections between S3 AND Spectrum Nodes(의존관계)
• Leader Node - Node# - Spectrum - S3&Catalog
• Athena의 경우 Node 역영이 없음 때문에 Spectrum의 limit이 존재하여 성능 제한이 있음
• Redshift Spectrum은 Node 영역의 비용이 추가적으로 발생함
• Athena와 Redshift&Spectrum과 External Metadata Store 아래 영역의 비용은 같음(Metadata Store, External Compute Engine, External Storage, Extra Source)
• 병렬성의 쿼리에 대하여 큐로 들어와 처리 됨
  • 지정된 리소스와 큐 개수에 따라 동일 쿼리에 대한 엑셀레이터가 동작함
• Redshift RA 타입의 경우도 BigQuery 의 Memory Cache 역할을 하는 엑셀레이터가 존재함
• 병렬성과 스토리지간의 배치그룹의 차이로 중앙 레이턴시 차이가 존재

Aurora Mysql VS RDS Mysql

• Cloud Native
• Cloud Resource 는 통계로 관리하는중
  • IOPS 99% ms
  • GP2 90% ms
• Mysql의 경우는 Storage Engine 에 bin Log와 InnoDB Engine에 Transaction Log 인 Read Log가 남음 이때 Amazon 같은 경우는 고 가용성을 위하여 Log를 동기적으로 복사함
  • Read Replica가 있는 경우 Relation Log 가 또 생김(이것또한 동기적으로 복제를함)
• Aurora 같은 경우 Master Node에서 Node에 한번에 전달하기위해 해당 신호를 Application 계층으로 변경하여 비동기로 하위 Node에 전달함(이떄 전달 받는 타겟은 EBS가 아닌 Application 서버임) - EBS Drive 에 직접 쓰는게 빠르겠으나 Rest Call로 진행함(레이턴시는 낮을지 몰라도 Throughput이 높음)