데이터 엔지니어링

지난 주 이제는 정말 가족같이 편해져버린 오래된 지인들과 일본여행을 다녀왔다.

그리고 여행에서 “엔저니까..” 라는 이유로 함께 구매한 키보드 세개를 기념샷으로 올려봤다.

9월 부터 열심히 달렸던 프로젝트가 11월 13일에 쉼표를 찍었다. 마침표가 아니라 쉼표다. 주말에도 공부하고, 열심히 일했던 것 같다. 마지막 발표가 있던 주말에는 새벽 3시까지 보고서 PT를 수정했다.

고생했던 순간들을 이 블로그에 남겨서 티도 내고 싶지만.. 빅데이터 워크로드를 쿠버네티스로 이전했던 주제의 후기를 남기고 싶다. (혹시 누군가에게는 도움이 될 것 같다.)

나는 관리형 쿠버네티스 eks위에 emr on eks, airflow on eks 를 구축했는데, 아직까지는 만족 스럽다.

보름정도 지나서 airflow의 한 차례 첫 장애를 맞았지만 해결할 수 있었다.

나의 경우처럼 회사에서 망분리 환경이나 제한된 aws 역할을 갖고 있고, 운영중인 서비스별로 CI/CD 구성이 덜 되있다고 한다면 더 효과를 볼 수 있을지도 모른다. 쿠버네티스의 알려진 장점도 분명이 있다. 하지만 나의 경우에는 결과적으로 각 서버에 터미널로 접속할 일이 줄었고, 워크로드에 따라 스케일 인/아웃, 그리고 서비스 버저닝과 롤백 등의 여러 이점들이 작업시간을 단축해줬다. 앞으로 신규 서비스나 오픈소스를 서버에 올릴 때 EC2를 발급받지 않아도 되고 말이다. 특히 고성능 오토스케일러인 카펜터(karpenter)는 정말 필수적으로 함께 사용해야 한다. Spot,on-demand 인스턴스를 할당할때 놀라운 성능을 보여준다.

단점은 단축된 작업시간이 쿠버네티스 운영과 공부, 트러블 슈팅으로 쓰다보니 아직은 도입 전과 후의 고생의 총양이 같다고 할 수있다. 쿠버네티스 버전 업그레이드 시 데이터 플레인쪽의 수동 업그레이드 작업은 덤이다.

데브옵스 조직이 많이 생겨나고 있는 시대에 데이터 엔지니어가 쿠버네티스 운영 경험이 필요할까? 싶다. 그래도 뭐.. 알아두고 익혀둬서 나쁠 건 없다. 아직은 재미있어서 같이 하고 있다.

앞으로는 짧은 시간동안 몰입했던 여러 기술들을 정리하고 기술 페이지 쪽에 하나하나 포스팅 해보려고 한다.

가족들과 프로젝트 진행에 큰 도움을 준 협력사분들과 부사수에게 감사하다.

앞으로는 적당히 바쁘고 싶다.

kubectl 명령어 정리 배경

• 자주 쓰는 것들을 정리해둔 내용인데, 혹시 누군가에게 도움이 될까봐 올려둔다.
• 개인적인 팁은 kubectl 을 k 라는 alias 로 설정해서 쓰면 편하다
• 쿠버네티스 리소스 관리 유틸리티인 k9s 를 쓰면 더 편리 할 수 있다. (  URL - https://k9scli.io/ )

kubectl 명령어 모음

# 네임스페이스 생성
$ kubectl create namespace argocd

# 네임스페이스 를 지정하여 yaml 적용하기
$ kubectl apply -n argocd -f argo-cd.yaml



# 포트 포워드 터널링
$ kubectl port-forward svc/서비스이름 [로컬 포트 : 서비스 포트]

$ kubectl port-forward svc/argocd-server -n argocd 8080:80
$ kubectl port-forward --namespace=ingress-nginx service/ingress-nginx-controller 8080:80


# 이벤트 및 파드 로깅
$kubectl get events

$kubectl get ing

$kubectl get svc,pod,ing


# 애플리케이션 로깅
$ kubectl logs -n [네임스페이스] deployment.apps/파드이름
$ kubectl logs -n airflow deployment.apps/airflow-webserver

# 서비스 어카운트 정보 
$ kubectl get sa
$ kubectl get sa -n kube-system
$ kubectl describe sa [] -n []


# yaml 형식으로 출력하기
$kubectl get sa ebs-csi-controller-sa -n kube-system -o yaml >> sa.yaml

$ kubectl get po -A
# A 옵션을 주면 네임스페이스 전체에 있는 파드가 다 뜬다.


# 파드 서비스 진입
$ kubectl exec [파드이름] /bin/sh
$ kubectl exec [파드이름] -it -- bash
# ssh 진입
$ kubectl exec bdp-web-7849b96cf5-2xzlq -n airflow -it -- bash


# watch를 이용한 모니터링
$ watch -d kubectl get deploy, svc, pods

kubectl alias 설정

$echo "alias k='/home/ec2-user/bin/kubectl'" >> ~/.bash_profile

$ source ~/.bash_profile

1.목표 (What & Why)

• 지난 번 포스팅에 이어 쿠버네티스 기반 서비스로 동작하도록 구성해본다
• 쿠버네티스 클러스터, kubectl 을 통한 통신이 준비되어있어야 한다.
• 순수 애플리케이션 Deploy → 도커 기반의 컨테이너 Deploy → 쿠버네티스 기반 Pod Deploy 를 통해 컨테이너 오케스트레이션을 조금은 이해해본다.

2.과정 (Step)

• 쿠버네티스 deployment yaml 을 작성한다.
• Pod 를 배포하고 동작을 확인한다.
• replica 수를 조정하여 Pod scaling 을 확인해본다.

3.방법 (How)

• Deployment 를 생성한다.

$ vi deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: common-api-deployment
  labels:
    app: fastapi

spec:
  replicas: 1
  selector:
    matchLabels:
      app: fastapi
  
  template:
    metadata:
      labels:
        app: fastapi
    spec:
      containers:
      - name: containers
        ports:
        - containerPort: 9000
        image: AWS 계정.dkr.ecr.ap-northeast-2.amazonaws.com/demoapp:latest

• kubectl 로 deployment 를 생성한다. 

$ kubectl apply -f deployment.yaml

• watch 를 통해 Pod, Node, Deployment를 모니터링 할 수 있다.

watch -d kubectl get pod,deploy,node

• replicas를 수정한다.

• 서비스를 확인한다.

4. 정리 (summary) 

• 컨테이너 기술을 이용한다는 건, 의존성과 애플리케이션을 패키징해서 어디서 수행하던 프로그램의 실행과 결과를 보장하게 한다는 것이다.
• 철학적으로는 격리된 서비스의 실행환경을 만드는 것이고, MSA 를 지향하는 요즘 트렌드에 방향성이 같은 기술이라고 생각한다.
• 쿠버네티스는 좀 더 나아가서 컨테이너의 무중단 배포, 고가용성 보장과 노드 스케일링, 보안 등의 기능 지원으로 컨테이너 기술의 힘을 더 강하게 해준다. -> 컨테이너 오케스트레이션 이라고 한다.
• 쿠버네티스는 공부할 것이 많다.
• 다음에는 시간이 될 지 모르겠지만, emr on eks 의 구성과 karpenter 기반의 spark workload 실행을 포스팅 해보고 싶다. ( 요즘 회사에서 하고 있는 기술이기도 하다. )