효율적인 대규모 크롤링 시스템 운영을 위한 Fargate on EKS 적용하기 - 3편

효율적인 시스템 운영을 위한 Fargate on EKS 적용하기 - 3편

본 글은 시스템 환경 개선을 위해 Fargate on EKS 적용하여 주니어 입장에서 멘땅에 헤딩하며 구축한 과정의 이야기다.

---

다음과 같은 분들이 읽으면 좋습니다.

• EKS를 사용해보고자 하는 엔지니어 입문자
• 피드백을 남기고 싶은 고수분들
• 지나가는 행인

---

들어가기 전에 알면 좋은 것

VPC Peering 

• VPC 피어링은 Amazon Web Service에서 제공하는 가상 프라이빗 클라우드(VPC) 간의 네트워크 연결 기술

• VPC 끼리는 논리적으로 분리되어 있는데, VPC 피어링 연결은 두 VPC 간에 트래픽을 라우팅 하는 연결
• 사용자의 자체  VPC , 다른 AWS 계정 VPC와 VPC, 다른 리전 VPC 사이 피어링 연결을 만들 수 있음

---

1. Fargate 와 Nat Gateway

Fargate형태로 배포된 Crawler는 Private Subnet에 올라가 있고 RDS는 Public Subnet 위에 올라가 있음

따라서 Nat Gateway를 생성함

왜 Nat Gateway를 사용했는가?

• Public Subnet에 있는 인스턴스 들은 IGW(Internet Gateway)를 통해 인터넷에 연결이 가능함
• 하지만 Private Subnet은 인터넷에 대한 경로가 없다

따라서 

•  B 가용영역에서 Public Subnet은 NAT Gateway를 포함하고, Private Subnet의 인스턴스는 Public의 NAT Gateway경로를 통해 인터넷에 연결시킴
• NAT Gateway는 Elastic IP 주소를 소스 IP 주소로 사용해 IGW로 트래픽을 전송함 

[Cloud] NAT Gateway(Feat. Subent, VPC, Elastic IP)

결과는 잘 된다.

---

2. Dag와 Git-sync(Feat. AWS CodeCommit)

첫 어리석은 시도는 컨테이너에 직접 Dag 작성 및 실행 테스트였다.

일반적으로 Git-sync를 한다던가, 볼륨 마운트, S3를 사용하는 사실은 알았지만 빨리 결과를 보고 싶어서 해당 과정에서 삽질한 내용과 깨달은 점을 정리했다.

---

명령어 :  dag import error 확인

airflow dags list-import-errors

---

명령어  : 실행한 dag 목록 확인

airflow dags list-runs -d dag_test2

---

명령어 : 인스턴스 테스트

airflow tasks test <dag_id> <task_id> <execution time>

---

이슈

ERROR 403, 이미지 못 찾음 -> secrets 업데이트함

 image_pull_secrets=[k8s.V1LocalObjectReference("mysecret")],

---

ERROR 403, Pod 관련 권한 부족 -> Role 추가해서 binding 시킴 (ex, pods/logs)

HTTP response body: b'{"kind":"Status","apiVersion":"v1","metadata":{},
"status":"Failure","message":"pods \\"start-pod2-cyrr77xh\\" is forbidden: 
User \\"system:serviceaccount:airflow:default\\" 
cannot get resource \\"pods/log\\" in API group \\"\\" in the namespace \\"airflow\\"","reason":
"Forbidden",
"details":{"name":"start-pod2-cyrr77xh","kind":"pods"},"code":403}\n'

결과는 잘 돈다.

---

Executor와 Worker

다른 분들의 글을 조금 더 자세히 읽었더라면..이라고 생각하게 되는 순간이었다.

worker pod를 위한 image를 설정은 안 하고 계속 발생하는 에러를 보고 헛짓 거리를 많이 했다.

,"reason":"Invalid","details":{"name":"dag-test-task-test-53062b3674c94bbebdf7a19933253b52","kind":"Pod","causes":[{"reason":"FieldValueRequired","message":"Required value","field":"spec.containers[0].image"}]},"code":422}

 

keunhui park님의 Kubernetes 위에서 Airflow 사용하기/

즉, Worker Pod가 생성되고 -> Worker Pod가 KubernetesOperator 구동하면, 그에 해당하는 pod가 생성되는 것

결국, worker Pod를 위한 image도 필요하다..

 

그제야 밑에 라인 블로그에서 작성한 도식이 눈에 들어왔음

사실 이 정도면

옆에서 일하는 사수한테 뒤통수 냅다 맞아도 이상할 게 없다. (현실은 사수가 없다)

하지만 또 무지렁이라는 걸 증명하듯이, Cfg 파일에 냅다 경로를 박아 넣었고

뭔가 잘못됨을 또 느꼈다

Dag 'dag_test2' could not be found; either it does not exist or it failed to parse.

 

모두 삭제 꿀팁 ㅋㅋ

kubectl delete pods -l dag_id=<dag_id> -n airflow

---

결론적으로 알게 된 것은

• Kubernetes Executor를 사용하는 Scheduler pod, Executor가 생성한 worker pod 모두 동일한 Dag 파일에 접근할 수 있어야 한다는 것
• 스케줄러는 Dag 구문 분석하고 워커가 실행할 작업을 예약
• 워커는 Dag 실행

따라서 일반적으로 아래 2가지 방법을 쓴다.

1. 볼륨 공유 : S3, 별도 볼륨 마운트
2. Dag 동기화 : Git-sync

 

Dag를 알고 있는 녀석은?(K8sExecutor & K8sPodOperator)

---

3. Git-sync(Feat. CodeCommit)

사이드카 형태로 Git-repo의 Dag를 주기적(60초) Pull 해서 싱크를 맞춤

Git Repo의 Dag 파일을 주기적으로 Pull 해야 하기 때문에, InitContainer 보다는 일반적인 사이드카 컨테이너를 사용하기로 함

---

Git-sync image

• 아래에서 버전 골라 골라

GitHub - kubernetes/k8s.io: Code and configuration to manage Kubernetes project infrastructure, including various *.k8s.io sites

---

Git-Repo

• 나는 AWS CodeCommit을 사용했다. 
• 별다른 이유는 없었고 AWS Native 한 걸 선호한다는 요구가..

 

CodeCommit HTTPS 자격 증명서

• 코드커밋 자격증명서 설정 - 공식문서
• Repo를 만들었으면, 위에 문서에서 3단계 따라 했음

 

HTTPS 자격증명서 Secret 등록

echo -n '<your_username>' | base64
echo -n '<your_password>' | base64

~~~

apiVersion: v1
kind: Secret
metadata:
  name: codecommit-creds
  namespace: airflow
type: Opaque
data:
  username: <your_base64_encoded_username>
  password: <your_base64_encoded_password>

---

IRSA 인증

• 원래는 IRSA 인증을 하려고 했지만, 권한 설정을 잘못해서 그런가 자꾸 권한 오류가.. 나중에는 변경 예정임

IRSA 인증이란?

• ServiceAccount를 사용해서 Pod 권한을 IAM Role로 제어할 수 있도록 하는 인증 방식
• kimdragon님의 블로그를 보면 이해가 쉽다. >>>  kimdragon님의 IRSA란

---

배포

containers:
- name: git-sync
  ...
  envFrom:
  - configMapRef:
      name: git-sync-config
  env:
  - name: GIT_SYNC_USERNAME
    valueFrom:
      secretKeyRef:
        name: codecommit-creds
        key: username
  - name: GIT_SYNC_PASSWORD
    valueFrom:
      secretKeyRef:
        name: codecommit-creds
        key: password
  ...

 

---

결과는 동기화가 잘되고 있다. 무야호

---

4. 마무리 & 다음 편 예고

체감은 산을 하나씩 넘는 느낌이었다. 이번 과정에서는 Airflow Executor의 동작 원리를 자세히 알아봤고 다음 편에 이어서 기능 구현에 초점을 둔 포스팅을 이어갈 예정이다.