AWS

AWS Certified Data Engineer - Associate - 합격후기

DEA-C01 합격 후기를 쓰러왔다.

AWS Certified Data Engineer - Associate 자격증은 2024년 3월 12일 정식으로 출시되었으며, 취득일은 3월 14일이다.

먼저 DEA 시험은 Beta 시기를 거쳐서 오픈했는데, 그 이전에 https://explore.skillbuilder.aws/learn 에서 강의를 이미 오픈했다. 나는 사실 자격증을 얼른 취득하고 싶어서 조금씩 공부를 해놓고 있었다.

(올서티가 마려웠다.)

https://aws.amazon.com/ko/certification/certified-data-engineer-associate/


공부의 시작은 시험안내서 이다.

https://d1.awsstatic.com/ko_KR/training-and-certification/docs-data-engineer-associate/AWS-Certified-Data-Engineer-Associate_Exam-Guide.pdf

내가 본 안내서에서 중요하다 생각하는 부분이다.

  • 프로그래밍 개념을 적용하면서 데이터를 수집 및 변환하고 데이터 파이프라인을
  • 오케스트레이션합니다. - Glue / Step Function
  • 최적의 데이터 스토어를 선택 및 데이터 모델을 설계하고 데이터 스키마를
    카탈로그화하고 데이터 수명 주기를 관리합니다. - S3 / RDS(PostgresSQL) / RedShift / Dynamodb
  • 데이터 파이프라인을 운영화하고 유지 관리 및 모니터링합니다. 데이터를 분석하고
    데이터 품질을 보장합니다. - Kinesis / Glue
  • 적절한 인증, 권한 부여, 데이터 암호화, 프라이버시 및 거버넌스를 구현하고 로깅을
    사용합니다. 로깅을 활성화합니다. - CloudTrail / lake formation

서론만으로도 데이터엔지니어의 역할이 보인다. 적절한 데이터 스토어(데이터 레이크 / 데이터 웨어하우스 / 데이터베이스등) 에 파이프라인을 통하여 수집 변환 적제를 하는것이 핵심이고, 이과정에서 암호화, 모니터링, 거버넌스틀 통한 제어를 하는것이다.

어떤 시험을 볼때도 안내서가 제일 중요하다. 재대로 안보면 시험에서 어이없게 떨어질수 있다. 테스크 설명을 보면서 AWS의 서비스를 연상할수 있는게 가장 중요한 포인트이다.

그러면 예를 들어서 시험안내서의 1.1 데이터수집에서 <데이터를 수집하는 AWS 서비스의 처리량 및 지연 시간 특성> 에 대해서 이야기 해보겠다. 일반적으로 AWS에서는 데이터를 수집하는 Kinesis 이다. Kinesis 는 보통 Stream 과 Firehose 로 구분된다. 이 두가지를 헷갈리는 사람이 많은데, 나 같은 경우엔 이두가지를 이렇게 나눈다

기능/특징Kinesis Data StreamsKinesis Data Firehose
주요 용도 실시간 데이터 스트리밍 처리 및 분석을 위한 고수준 API 제공. 사용자가 스트림 데이터를 자세히 제어하고 관리할 수 있음.데이터를 실시간으로 수집하고, 변환하여 S3, Redshift, Elasticsearch, Splunk 등의 AWS 서비스로 쉽게 로드.
데이터
스토리지
스트림 내의 데이터는 최대 7일까지 저장 가능. 데이터 보존 기간 사용자 설정 가능.Firehose는 스스로 데이터를 저장하지 않음. 바로 다음 대상으로 전송.
데이터
처리
사용자는 스트림 데이터를 읽고 처리하기 위해 자체 소비자(예: EC2 인스턴스, Lambda 함수)를 관리해야 함.데이터 변환 및 필터링 기능 내장. Lambda를 사용하여 데이터 변환 가능.
대상
서비스
통합
Kinesis Data Streams 자체는 직접적인 데이터 저장 대상을 제공하지 않음. 소비자가 데이터를 읽고 처리한 후 저장소에 저장 필요.S3, Redshift, Elasticsearch 및 Splunk로 데이터를 직접 전송할 수 있음.
관리
편의성
높은 수준의 관리와 모니터링 필요. 사용자가 스트림과 데이터 소비자를 직접 관리.관리가 훨씬 쉬움. AWS가 대부분의 관리 작업을 자동으로 처리.
시작
난이도
설정과 관리에 더 많은 단계와 고려 사항이 있음.설정이 간단하며, 몇 분 내에 데이터 스트리밍 시작 가능.
실시간
처리
거의 실시간으로 데이터 처리 및 분석 가능.거의 실시간으로 데이터를 수집하고 대상 서비스로 전송.
비용데이터 스트림의 샤드 수, PUT 요청 수, 데이터 전송량 등에 따라 비용이 결정됨.전송된 데이터의 양에 따라 비용이 결정됨.

이런형태의 차이점을 이해하고 있으면 이제 두가지 서비스를 고려할때 바로 판단할수 있다. 또한 이 두가지 서비스는 실시간이 아니다. 거의(실시간)이다. 더 실시간으로 처리해야한다면 큐서비스를 사용해야한다.

시험 안내서의 범위는 너무 넓으니 속성으로 공부하고 싶다면 이제 사전테스트를 해야한다.

https://explore.skillbuilder.aws/learn/course/external/view/elearning/18868/exam-prep-official-pretest-aws-certified-data-engineer-associate-dea-c01-korean

나는 사전테스트를 여러차례 풀었고 해체하 듯 하나하나 Docs를 찾아가며 봤다. 예제문제가 훨씬어렵다. 예제문제 85%이상이면 시험을 봐도 좋을거 같다.

나는 다시 AWS의 모든 자격증을 획득했다.

읽어주셔서 감사하고 좋은하루 되시라!

AWS-ALL-Certification-Review

50일간의 챌린지를 끝냈다.

근래의 나는 다시금 내한계를 부수고 성장하는 과정을 거쳤다. 어느 순간부터 일하는것도 너무 쉬웠다.
공부하는건 시험이라는 부담감은 있었지만 공부가 어렵진 않았다.

50일간의 긴 시간이었다. 평균 5일에 1개의 자격증을 취득했다.

2023.12 CKAD: Certified Kubernetes Application Developer
2023.12 AWS Certified cloud practitioner
2023.12 AWS Certified Solutions Architect - Associate
2023.12 AWS Certified Developer – Associate
2023.12 AWS Certified SysOps Administrator – Associate
--------------------------------2024----------------------------------
2024.01 AWS Certified Database - Specialty
2024.01 AWS Certified Security - Specialty
2024.01 AWS Certified Advanced Networking - Specialty
2024.01 AWS Certified Solutions Architect - Professional
2024.01 AWS Certified: SAP on AWS - Specialty
2024.02 AWS Certified DevOps Engineer – Professional

시험응시료만 1,609,128원을 사용했다. 업무와 공부를 병행하는것도 어려웠다. 새벽 2시까지 매일같이 ChatGPT와 공부했다.

먼저 내가 공부한 방법을 설명하겠다. 나는 집중한 시간만 공부한 시간으로 잡았다. 자격증 평균 10시간정도의 공부시간을 가졌다. 공부시간은 스탑워치를 켜고 집중이 깨지면 스탑워치를 멈췄다. 평균 12분정도의 집중을 가질수 있었다.

그리고 공부는 보통은 이해를 하기위해 시험안내서를 읽었다. 공부의 시작과 끝은 시험안내서였다.

https://aws.amazon.com/ko/certification/certified-cloud-practitioner/

자격증 소개 페이지에 시험안내서가 있다. 이 시험안내서를 기반으로 분석한다.

여기 링크를 다보면 시험을 볼준비가 30%정도 완료 된거다. 그러면 이제 어떤 공부를 하냐?
안내서엔 도메인과 서비스가 있다.

태스크 설명 1.1: AWS 클라우드의 이점 정의.
관련 지식:

  • AWS 클라우드 가치 제안
    기술:
    • 규모의 경제에 대한 이해(예: 비용 절감)
    • 글로벌 인프라의 이점 이해(예: 배포 속도, 글로벌 도달 범위)
    • 고가용성, 탄력성 및 민첩성의 장점 이해

도메인은 다음과 같은 설명을 해주는데 그럼 이제 한줄한줄을 가지고 ChatGPT와 이야기를 하며 내가 모르는 키워드를 정리한다.

https://chat.openai.com/share/e84fb046-f996-4938-bd2d-c1526e3ee2fe
잠깐 예를들어서 질문을 한내용을 첨부한다. 내가 사용하는 프롬프트는 주로 자세하게 / 쉽게 / 키워드 추출 / 시험 내용 추천 / 등이다.

물론 나는 이미 한번 시험을 모두 본터라, 그동안 안다뤄본 서비스들을 따라가는 시간이라 좀더 수월함이 있었다.

그래도 나는 갱신의 시간을 가지면서 그동안 못다뤄본 서비스를을 만들어보거나 어떤방식으로 구성된지 확인하는 시간을 거치며 한층더 촘촘한 아키텍처구상력을 가지게 되었다.

올해의 첫 목표는 2달정도 빠르게 끝냈다. 이제 좀 쉬고 다음 목표를 향해 달려보려한다.

이글이 도움이 되면 좋겠다.
읽어줘서 감사하다.

좋은저녁 되시라!

AWS-User-Notifications-Hacking-Detection

아직 이걸 설정 안했다면 반드시 하길 바란다.

우리는 AWS를 다루면 항상 해킹의 위험에 당면한다.
미리 막는다면 너무좋은 일이겠으나, 그렇지 못한경우가 많다.

해킹을 당한다 하여도 문제들을 간단하게 캐치할수 있는 방법이 있다.

보통 AWS계정이 해킹당하면 해커의 니즈는 컴퓨팅 리소스를 사용하여 채굴을 돌리려고 한다. 이 과정에서 EC2를 만들게 되고, EC2의 생성을 모니터링 할수 있는 방법이 있다면, 조기에 해킹을 진압할수 있을 것이다.

이번에 나온AWS User Notifications 서비스가 그 니즈에 완벽하게 부합하다.

이미지 대로 생성하자, 활성화되지 않은 계정의 리전들은 서비스노티도 안되거나 서비스가 런칭되지 않아서 리전에서 제외해야한다. 초기 한국계정으로 선택되지 않은 리전이다.

케이프타운 / 홍콩 / 멜버른 / 자카르타 / 하이데라바드 / 뭄바이 / 밀라노 / 바레인 / 프랑크푸르트 / 바레인 / UAE / 취리히

[af-south-1, ap-east-1, ap-southeast-4, ap-southeast-3, ap-south-2, eu-south-1, eu-south-2, eu-central-2, me-south-1, me-central-1]

리전선택하고 이메일 넣고 생성해 주자

태그기반으로 예외할 인스턴스의 정책이 있다면 좋겠는데 그런정책은 아직없다.
하지만 간단히 활성화된 모든리전의 EC2의 상태변경 노티를 받아볼수 있다는 장점은 어마어마하다.

개인계정이라면 반드시 활성화해서 사용하길 바란다!

좋은하루 되시라!

EKS-NodeLess-08-AWS-Karpenter-topologySpreadConstraints

topologySpreadConstraints 을 사용한 Karpenter 테스트를 진행하겠다.

topologySpreadConstraints 테스트는 Topology Aware Hint 를 예비한 테스트다.

https://aws.amazon.com/ko/blogs/tech/amazon-eks-reduce-cross-az-traffic-costs-with-topology-aware-hints/

참고할 부분이 있다면 이 글을 참고하길 바란다.

간략하게 설명하자면 Kubernetes 에서 Cross Zone Traffic 의 문제로 비용이 막대하게 발생할수 있다. 또한 Cross-AZ로 인하여 약간의 레이턴시가 발생할수도 있기때문에 Topology Aware Hint는 여러 문제점들을 줄여주는 역할을 한다.

조건은 몇가지가 있는데, Service 로 연결되 AZ가 수평적으로 동일하게 노드가 배포되어있고 서비스에

apiVersion: v1
kind: Service
metadata:
  name: service
  annotations:
    service.kubernetes.io/topology-aware-hints: auto

다음과 같은 annotations 붙어있어야 한다.

그럼먼저 우리는 Provisioner가 자동으로 노드를 Deprovisioning 하도록 설정하자.

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: default
spec:
  consolidation:
    enabled: true
  requirements:
    - key: karpenter.k8s.aws/instance-category
      operator: In
      values: [ t, m, c ]
  providerRef:
    name: default
---
apiVersion: karpenter.k8s.aws/v1alpha1
kind: AWSNodeTemplate
metadata:
  name: default
spec:
  subnetSelector:
    karpenter.sh/discovery: "${CLUSTER_NAME}"
  securityGroupSelector:
    karpenter.sh/discovery: "${CLUSTER_NAME}"

consolidation enabled 옵션은 Pod 의 리소스 요구조건에 따라서 Karpenter 가 알아서 노드를 스케줄링한다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: host-spread
spec:
  replicas: 20
  selector:
    matchLabels:
      app: host-spread
  template:
    metadata:
      labels:
        app: host-spread
    spec:
      containers:
      - image: public.ecr.aws/eks-distro/kubernetes/pause:3.2
        name: host-spread
        resources:
          requests:
            cpu: "1"
            memory: 256M
      topologySpreadConstraints:
      - labelSelector:
          matchLabels:
            app: host-spread
        maxSkew: 2
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
      - labelSelector:
          matchLabels:
            app: host-spread
        maxSkew: 5
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule

topologyKey: kubernetes.io/zone maxSkew: 2는 하나의 호스트 즉 노드간 파드의 차이는 maxSkew: 2 를 초과할수 없다. topologyKey: topology.kubernetes.io/zone maxSkew: 5 zone 간 pod의 갯수는 maxSkew: 5 초과 할수 없으므로 하나의 zone에서만 pod가 스케줄링된다면 20개의 replicas 를 요청한다 해도 5개의 pod 만 스케줄링 된다.

AZ별로 제공하는 유형의 인스턴스 페일리가 달라서 특정 유형만 사용하려고 하면 프로비저닝 조건에 걸려서 스케줄링이 쉽지 않다.

karpenter 의 강력함은 테스트중에 확인할수 있는데, 42s 만에 Pod 가 Running 된다. 42초안에 Node도 프로비저닝 된다는 말이다.

2023-05-20T11:03:34.806Z	ERROR	controller.provisioner	Could not schedule pod, incompatible with provisioner "default", no instance type satisfied resources {"cpu":"1","memory":"256M","pods":"1"} and requirements karpenter.k8s.aws/instance-category In [c m t], kubernetes.io/os In [linux], kubernetes.io/arch In [amd64], karpenter.sh/provisioner-name In [default], karpenter.sh/capacity-type In [on-demand], topology.kubernetes.io/zone In [ap-northeast-2a]	{"commit": "d7e22b1-dirty", "pod": "default/host-spread-fbbf7c9d9-x4lfd"}

topologySpreadConstraints 옵션을 테스트하면서 느꼈는데, 여러 요인들로 잘 스케줄링하지 못한다.

두가지 조건에 의해서 pod는 모두다 스케줄링 되지 못하는데, 노드를 스케줄링하지 못해서 걸리기도 한다. 조건은 확실히 걸리긴한다.

k get node --show-labels | grep -v fargate | awk -F"topology.kubernetes.io/" '{print $3}' | sort
zone=ap-northeast-2a
zone=ap-northeast-2a
zone=ap-northeast-2a
zone=ap-northeast-2b
zone=ap-northeast-2b
zone=ap-northeast-2b
zone=ap-northeast-2c

다음과같이 노드가 a 3대 b 3대 c 1대 스케줄링 되면 모두 14개의 pod가 스케줄링된다. C zone때문에 두번째 조건에 걸리기 때문이다. 다양한 조건을 사용하면 이와 같이 균등하게 zone 에 스케줄링 하긴 어려운점이 있다. 적당히 조건을 걸어주면 잘 작동한다.

      - labelSelector:
          matchLabels:
            app: host-spread
        maxSkew: 2
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule

이 조건을 삭제하면 topology.kubernetes.io/zone maxSkew 5 만 남겨서 프로비저닝 해보면 비대칭으로 az 에 node가 프로비저닝 되지만 조건에만 맞는다면 pod를 모두 생성한다.

k get pod
NAME                          READY   STATUS    RESTARTS   AGE
host-spread-dd5f6c569-49ps7   1/1     Running   0          115s
host-spread-dd5f6c569-8772p   1/1     Running   0          115s
host-spread-dd5f6c569-9q2hn   1/1     Running   0          115s
host-spread-dd5f6c569-b68k2   1/1     Running   0          115s
host-spread-dd5f6c569-bfhv5   1/1     Running   0          115s
host-spread-dd5f6c569-bqqz2   1/1     Running   0          116s
host-spread-dd5f6c569-bsp8m   1/1     Running   0          115s
host-spread-dd5f6c569-dh8wx   1/1     Running   0          115s
host-spread-dd5f6c569-ffjdg   1/1     Running   0          115s
host-spread-dd5f6c569-jghmr   1/1     Running   0          115s
host-spread-dd5f6c569-jhbxg   1/1     Running   0          116s
host-spread-dd5f6c569-kf69q   1/1     Running   0          115s
host-spread-dd5f6c569-ksktv   1/1     Running   0          115s
host-spread-dd5f6c569-lbqmv   1/1     Running   0          115s
host-spread-dd5f6c569-mbf2g   1/1     Running   0          116s
host-spread-dd5f6c569-pd92p   1/1     Running   0          115s
host-spread-dd5f6c569-pgphc   1/1     Running   0          115s
host-spread-dd5f6c569-ph59g   1/1     Running   0          115s
host-spread-dd5f6c569-sdp7d   1/1     Running   0          115s
host-spread-dd5f6c569-tf8v9   1/1     Running   0          115s
(user-linuxer@myeks:default) [root@myeks-bastion-EC2 EKS]# k get node --show-labels | grep -v fargate | awk -F"topology.kubernetes.io/" '{print $3}' | sort
zone=ap-northeast-2a
zone=ap-northeast-2a
zone=ap-northeast-2a
zone=ap-northeast-2b
zone=ap-northeast-2b
zone=ap-northeast-2c

AZ 별로 균등하게 node를 프로비저닝 해야하는 방법이 필요하다.

https://github.com/aws/karpenter/issues/2572

일단 테스트한 결과와 git issues 를 보면 karpenter 가 topologySpreadConstraints 에 적절히 대응되지 않는것을 느낄수 있었다. 따라서 minDomains 옵션으로 3개의 zone을 지정도 해보았으나 썩 좋은 결과는 없었다.

따라서 다이나믹하게 Node를 프로비저닝하면서 사용할수는 없을것같고, 미리 Node를 프로비저닝 하는 구성에선 될법한데, 그건 Karpenter 의 패턴은 아니라고 느꼈다.

EKS-NodeLess-07-AWS-Karpenter-CRD

이제 카펜터의 CRD를 정리하고 어떻게 사용해야 하는지 이야기를 해보려고 한다. 거의 끝에 다왔다.

Karpenter Component 를 설명할때 CRD를 설명했었다.

다시 이야기 하자면 provisioners.karpenter.sh - provisioners - / awsnodetemplates.karpenter.k8s.aws -awsnodetemplates - 두가지를 셋팅해야 한다.

먼저 provisioners 를 이야기 해볼까 한다.

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: default
spec:
  requirements:
    - key: karpenter.k8s.aws/instance-category
      operator: In
      values: [c, m, r]
    - key: karpenter.k8s.aws/instance-generation
      operator: Gt
      values: ["2"]
  providerRef:
    name: default

https://karpenter.sh/v0.27.3/concepts/provisioners/

https://github.com/aws/karpenter/tree/main/examples

provisioners 의 사용은 이 두가지 링크를 참고하면 대부분 할수있는데, 간단하게 provisioners를 설명하자면 노드를 만들기 위한 조건을 정의하는거다.

예를 들자면 인스턴스 페밀리 / 인스턴스 CPU 갯수 / 하이퍼바이저 유형 / AZ / kubeletConfiguration 등을 설정할수 있다. 프로비저너는 노드를 생성하고 관리하는데 사용되는 CRD다

https://karpenter.sh/v0.27.5/concepts/node-templates/

apiVersion: karpenter.k8s.aws/v1alpha1
kind: AWSNodeTemplate
metadata:
  name: default
spec:
  subnetSelector:
    karpenter.sh/discovery: "${CLUSTER_NAME}"
  securityGroupSelector:
    karpenter.sh/discovery: "${CLUSTER_NAME}"

awsnodetemplates 은 필수 요소들이 있다. 그것이 Subnet / SecurityGroup 다.
서브넷 셀렉터는 subnet-id 혹은 서브넷에 연결된 특정 태그로 동작한다.
보안그룹또한 ID혹은 특정 태그다.

awsnodetemplates은 ami / userdata ebs 등들을 컨트롤하려 원하는 노드의 OS를 선택할수도 있다.