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

 

 

 

 

 

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

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

---

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

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

---

목적

이번 포스팅의 목적은 Airflow Scheduler를 통해 PodExecutor를 한 것이 아닌,

그전에 Fargate 통한 Pod를 배포를 하면서 경험한 내용과 배운 점을 정리했다.

---

1. Fargate Profile

프로필 추가같은 경우 콘솔이나 eksctl 중에 뭘 사용하든 상관없다.

• 프로필 생성

eksctl create fargateprofile \
    --cluster test \
    --name <name>\
    --namespace airflow\
    --labels app=<app>

• eksctl 명령어로도 잘 생성이 됐나 확인 가능함

eksctl get fargateprofile --cluster test -o json

• 물론 추가하는 과정에서도 에러가 발생했는데,  정책(Policy) 관련한 문제였다
• Amazon EKS pod execution IAM role
• 문서를 읽고 아래처럼 업데이트 했다

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Condition": {
         "ArnLike": {
            "aws:SourceArn": "arn:aws:eks:<region-code>:<account_id>:fargateprofile/<cluster_name>/*"
         }
      },
      "Principal": {
        "Service": "eks-fargate-pods.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

---

2. Fargate 배포

• 먼저 테스트할 yaml을 작성하고 Fargate profile과 매칭에는 labels 사용하도록 한다. 

• 적용

kubectl apply -f test.yaml -n airflow

역시 에러 발생했다. 기대도 안 했다.

LoggingDisabled 도 매우 거슬렸지만, 나중에 혼내주기로 다짐했다

---

이거는 그냥 세부 정보 보다가 확인한 건데

CapacityProvisioned는 적용된 Pod resource를 나타내고 이에 따라 Fargate 비용이 결정된다. 

---

• 아무튼 ImagePullBackOff를 해결하기 위해 ECR Repo의 Permission 부분을 업데이트했다.
  선조들이 다 경험한 내용이라 문서가 잘 남아있더라.. 

Amazon EKS와 관련된 Amazon ECR 문제

• 그리고 다시 적용했지만, 에러가 발생했다.

그러다가 coredns pod가 pending 상태라 동작시켜 보자고 생각했다.

AWS Fargate 시작하기 

위 문서를 보면 Fargate 형태로 배포가 가능하다.

순서는 Profile 생성하고 compute-type이 ec2로 설정된 부분을 변경해 주고 재시작한다 정도이다.

• 전

• 후

해봤자 사실 에러에 변함이 없었다. 

---

여기서 알게 된 사실은

—fargate 옵션 사용하면, kube-system, default 네임스페이스에 해당하는 파드를 미리 파게이트로 올려놓는다는 차이가 있었음

문서에서는 필요시 콘솔이 아닌 eksctl 사용하는 것을 권장하고 있음

eksctl create cluster  —fargate

---

Logging 

• 위에서 발생한 Logging warning 도 아래 문서를 보고 수정했다.
• Fargate Logging 문서

---

3. 원인  파악

해결하기 위해서 맨땅에 헤딩하며 검색을 계속했음. 

그러다가 클라우드 백그라운드가 부족해서 에러 원인을 유추하지 못한다는 생각이 들었고 진행 속도가 더 늦어진다고 생각했음 

그래서 기본적인 개념에 잠깐 시간을 투자했음

 

1. VPC

• 문서에서 Fargate는 Private Subnet이 필요하다는 사실을 확인함

그리고 내가 사용 중인 VPC를 확인했고 2개의 Public Subnet, 2개의 Private Subnet을 사용하고 있었음

• 퍼블릭 서브넷은 인터넷 게이트웨이(igw)로 이어지는 라우팅이 있는 라우팅 테이블과 연결된 서브넷

• 그러나 프라이빗 서브넷의 라우팅 테이블에는 인터넷 게이트웨이로 이어지는 라우팅이 없음

위 사진을 보면

• 1개의 Public subnet,  1개의 Private Subnet 이 동일한 가용영역(2a, 2b)에 배포되고
• 나머지는 두 번째 가용 영역에 배포되는데 대부분 배포에 이 옵션을 사용하는 것이 좋다고 함(문서 피셜)

이렇게 구성하는 경우

• 프라이빗 서브넷의 노드에서 실행되는 Pods로 트래픽을 로드 밸런싱할 수 있는 퍼블릭 서브넷에 로드 밸런서를 배포할 수 있음.
• 당연한 말이지만, 퍼블릭 IPv4 주소는 퍼블릭 서브넷에 배포된 노드에 자동 할당 되지만 프라이빗 서브넷에 배포된 노드에는 할당 X

---

2. 쿠버네티스 컴포넌트

kube-proxy

• 쿠버네티스 네트워크 프락시는 각 노드에서 실행
• 각 노드의 쿠버네티스 API에 정의된 서비스를 반영하며 단순한 TCP, UDP 및 SCTP 스트림 포워딩 또는 라운드 로빈 TCP, UDP 및 SCTP 포워딩을 백엔드 셋에서 수행할 수 있음
• 서비스 클러스트 IP 및 포트는 현재 서비스 프록시에 의해 열린 포트를 지정하는 Docker-links-compatible 환경 변수를 통해 찾을 수 있음
• 이러한 클러스터 IP에 클러스터 DNS를 제공하는 선택적 애드온이 있음
• 유저는 apiserver API로 서비스를 생성하여 프록시를 구성해야 함.

kubernetes api

• Amazon EKS는 클러스터와 통신하는 데 사용되는 관리형 Kubernetes API 서버의 엔드포인트를 생성
• Amazon EKS는 사용자를 대신하여 Amazon Route 53 프라이빗 호스팅 영역을 자동으로 생성한 후 해당 프라이빗 호스팅 영역을 클러스터의 VPC에만 연결

---

3. ECR Endpoint 추가

사실 여기서 감이 왔고 아래 문서를 이해할 수 있었음

EKS private access

AWS ECR이 Private Repo를 사용하고 있고 Fargate도 Private Subnet 위에 올라가고 있었음

ECR Endpoint 생성해서 EKS에서 접근 허용만 해주면 되는 것

• ECR Endpoint 생성
• dkr이 pull과 push 할 수 있는 서비스

• secret 도 하나 추가했음

TOKEN=`aws ecr --region=$REGION get-authorization-token --output text --query authorizationData[].authorizationToken | base64 -d | cut -d: -f2`
kubectl create secret docker-registry airflow \
   --docker-server=https://<accont_id>.dkr.ecr.ap-northeast-2.amazonaws.com \
    --docker-username=AWS --docker-password="<token>" \
    --docker-email="admin@admin.com" \
    --namespace=airflow

• 결과는 감격스럽다 참..

---

4. 마무리 & 다음 편 예고

개념을 잡는 과정에서 해도 똑같이 오류 날 것 같은데..라는 불신이 조금 있었다.

다음 편에 이어서 기능 구현에 초점을 둔 포스팅을 할 예정이다.