데이터 엔지니어링

1. 문제 소개

• 자료 구조 큐를 이용해야 하는 문제다.

2. 코드

from collections import deque

def set_test_case():
    in_line = input().split(" ")
    n,m = int(in_line[0]),int(in_line[1])

    in_line = input().split(" ")
    pop_list = [int(x) for x in in_line]

    return n,m,pop_list

def pop_simulate(q,v):
    dir= 1 if q.index(v) > len(q)//2 else - 1
    turn=0

    while(True):
        if q[0] == v:
            q.popleft()
            break
            
        else:
            q.rotate(dir)
            turn += 1
    return turn

def solution():
    n,m,pop_list = set_test_case()
    turns = []
    q = deque([i for i in range(1,n+1)])

    #q.rotate(1) # to right
    
    for v in pop_list:
        result = pop_simulate(q,v)
        turns +=[result]
    print(sum(turns))


if __name__=="__main__":
    solution()

3. 코멘트

• pop 할 원소의 위치가 큐 길이의 중앙 값을 기준으로 비교 후에 왼쪽으로 이동시킬 지 , 오른쪽으로 이동시킬 지 방향을 구한다.
• 2초 제한과 50의 테스트케이스 정도는 시뮬레이션 방식으로 통과가 가능할 것 같아, 간단한 시뮬레이션을 구현했다.
• 그 동안 프로젝트 때문에 알고리즘 스터디를 오랜만에 참여했다. 앞으로는 더 열심히 하자. 

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

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

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 실행을 포스팅 해보고 싶다. ( 요즘 회사에서 하고 있는 기술이기도 하다. ) 

2015년쯤 신한 데이터 시스템이라는 곳에서 짧게 첫 직장 생활을 하다 패기와 도전 정신으로 넷마블 인턴십에 지원했다. 당시 너무 오래전 일이라 직급은 기억나지 않지만 ( 아마도 CTO분이셨겠지.. ) 대회의실에 100명이 넘는 모든 인턴을 모아두고 정규직 전환을 뽑는 기준에 대해 얘기했다.  

“우리는 일 잘하는 사람, 머리 좋고 똑똑한 사람을 뽑지 않아요.” 

“함께 일하고 싶은 사람을 뽑을겁니다.”

그리고 기억에 남는 합격자가 있다. 

동료들의 어려움과 기술적 고민을 해결해 주다 본인의 프로젝트를 완료하지 못한 분이었는데 모두의 예상을 깨고 합격했다. 

그것은 단순히 배려와 희생이 아니다.

그런 사람과 일했을 때, 딱딱한 업무가 재밌고 즐거운 분위기가 되거나, 어떤 어려움에 부딪혀도 이겨낼 수 있을 것 같다는 믿음이나 신뢰가 될 수 있다. 

음.. 사실 오늘 쓰고 싶은 얘기는 다음부터다.

얼마 전 내가 리딩하게된 프로젝트 킥오프에 여러 도움을 주시는 다양한 전문가분들이 함께하게 됐다. 

그중에는 aws 인프라 업무를 담당해 주시는 외주 협력사 A님이 있다. 작년에 입사하셔서 우리 회사에 도움을 주시는 분이다

킥 오프 회의가 끝나고, A님이 따로 내게 했던 질문들이 매우 놀랍다.

“그래서..  목표가 000로 수정된 거죠?”

“실제 운영환경은 DEVOPS 계정에서 수행되는 걸까요?”

“제가 다음주에는 일주일 동안 휴가인데 일정을 제가 좀 수정할까요?” —> ‘물론 당연히 그러지 마시라고 했다..’

“팀장님의 00이런 의견이 00런 의미였나요??”

..등등..

심지어 내가 듣고 놓쳤던 회의 내용까지 나에게 상기시켜 줬다..

이런 질문들로 관심과 열정을 보인 A님이 더 고맙고, 함께 오래 일하고 싶은 마음이 드는건 당연하다.

이 글을 읽는 당신도 누군가에게 함께 일하고 싶은 동료로 기억될 수 있으면 좋겠다.

== 비하인드 ==

작년에 EKS 클러스터를 구성하면서 도움을 많이 받았던 동료 K 님이 있다. K님 역시 함께 일하고 싶은 동료였다.

K님을 팀에 모셔 오기 위해 추천도 써봤지만, 최종 면접에서 떨어졌고, 더 좋은 곳으로 가셨다.

A님은 K님과 사수 부사수 관계였다.

역시.. 좋은 사수 밑에는 좋은 부사수가 있나 보다.. 

동료가 나간다. 더 좋은 곳으로 가기에 .. 축하와 응원을 해줬다. 그렇지만 속으로 많이 아쉽다.

가족들과 보내는 시간을 빼면, 직장에서 동료들과 보내는 시간이 그 다음으로 긴데.. 어떻게 보면 가족 같은 느낌이 들 때도 있었다. 

다른 곳에 가서도 계속 볼 동료지만, 앞으로 매일 회사에서 기술적인 고민과 소소한 일상을 나눌 수 없다는 부분에서 슬프다.  

동료가 떠나면 파트에서 주요한 배치 플랫폼을 주로 운영해야 하는 부담감도 있다. 

물론 난 잘 하겠지만.. 

새로운 동료가 언제 올지 모르겠다.. 좋은 분이 오시길 기대해 본다.

1.이슈 내용

• 최근 EMR Cluster 에서 도커 이미지를 이용해 Spark - submit 실행하는 job 을 추가함.
• 테스트 시에는 문제가 되지 않았으나, 새벽 배치에서 장애 발생

2.장애 또는 에러 내용

• Docker inspect command : /usr/bin/docker inspect —format {{.State.ExitCode}} container_iD_appid_…..
• Exit code from docker inspect : 1

3.이슈 원인

• EMR 에서 Scale Out 시 Task 노드를 임의로 할당 받게 된다. (Spot instance 사용 중)
• Task 노드의 커널 아키텍쳐가 이미지 내 빌드된 프로세서 아키텍쳐와 호환이 안될 가능성이 있다.
  • 내가 amd64 아키텍쳐로 빌드를 했는데 실제로 arm64 아키텍쳐의 노드 위에서 실행 될 경우..
• docker inspect 는 실행 전 이미지를 검사하는 단계로 보여진다. 

4.해결방법

• buildx 를 이용하여 멀티 프로세서 아키텍쳐에 맞게 빌드한다.
• 참고로 buildx 를 이용할 때 빌드와 push 만 가능하다.

1. buildx 활성화 및 확인
$ docker buildx version
$ docker buildx ls

2. buildx 초기화 및 빌더 인스턴스 생성
$ docker buildx create --name multi-archi-builder
$ docker buildx use multi-archi-builder


$ docker buildx inpsect --bootstrap 
-- bootstrap 은 초기화 프로세스 플래그

3. build 와 동시에 push 하기
$ docker buildx build --platform linux/arm64,linux/amd64 -t myapp:latest --push .

4. 이미지 확인하기
$ docker manifest inpsect [이미지]:[태그]

5.회고

- 사실 aws 코리아 기술자 분들과 미팅을 하면서,쿠버네티스 환경에서는 꼭 컨테이너 이미지의 멀티 아키텍쳐 빌드가 필요하다는 내용을 팁으로 들었었다. 그때는 잘 끄덕였는데.. 귀로만 흘려들었더니, 새벽 4시에 일어나 장애 대응을 해야 했던 결과를 맞았다.

최근 배치 장애도 잦고, 더 꼼꼼해야 겠다. 그리고 반성하자

[개발자 일상] 두 번의 깨달음

사회 초년생일 때는 야근이 잦았다. 

그때 항상 사무실에 남아 멀리서 나와 야근을 함께 하는 40대 동료 사우가 있었다. (40대 동료라고 하면 놀랄 수 있겠다. 첫 회사는 수평 문화의 회사였다.) 

왜 저 사람은 맨날 집에 늦게 갈까? 매일 야근 할 정도로 일이 많을까? 혹시 아기 보기 싫어서, 늦게 퇴근하는 거 아냐?  정말 별로인 아빠네.. 라고, 속으로 욕했던 기억도 난다. 

이런… 그 사람의 모습을 내가 갖게 됐다…

이상하게 저녁에 업무 집중이 잘 되고, 야근 후에 집에 돌아가면 아이가 자고 있어 몸이 편했다. 왜 아빠들이 늦게 퇴근하는지 깨달은 것 같아..  

애기가 생기면서 주말과 개인 시간이 사실상 소멸했고, 게임은 커녕 공부할 시간도 모자라다보니 집중할 수 있는 시간이 보장된 회사에서 채우게 되고, 그러다 보니 퇴근 시간이 늦어지는 것 같다는 나의 그럴듯한 핑계다.

그렇게 점점 회사에서 보내는 시간이 길어지면서 육아 시간도 줄었다.

너무 더워진 요즘 아기 방의 온도를 체크하러 잠깐 들어갔는데 자고 있는 얼굴을 보다 행복을 느꼈다. 

“아빠”라는 말을 마지막으로 들은 지 꽤 된 것 같다. 휴대폰에는 마지막 아이의 사진이 2주 전이다. 

무엇이 중요한지 깨달았다. 힘들어도 아이와 보내는 시간과 추억이 더 소중할 것 같다. 

주말에는 책을 많이 읽어줘야겠다. 

1.목표 (what & why)

• fast 를 이용해본다
• 유지보수와 확장 가능한 구조의 프로젝트 구조를 만든다.
• 쿠버네티스 기반 컨테이너 서비스로 동작하도록 만든다.
• fast api application   
  • 별도 SMTP 서버로 이메일 전송을 대신할 수 있는 api 서버 구현 ( 상세한 구현 로직은 포함하지 않음. )
  • 인증은 기본 토큰 방식을 사용한다.
• 만드는 목적과 이유
  • 보통 이런 REST API + Application 실행 요구사항은 AWS 람다를 대부분 이용했다. 그리고 이용하면 편하고..
  • AWS 람다는 서버리스기반으로 실행되기 때문에 고정 IP 를 부여하기 힘들다. (서브넷의 CIDR 를 조정하면 될것 같긴 하지만 그렇게는 아무도 안할 것 같다)
  • 화이트 리스트로 등록되어야만 실행을 하게 하는 서비스 들이 있다. 예를 들어 SMTP 서비스 들. 

2.과정 (Step)

• fastapi application 을 작성한다
• Dockerfile 을 작성하고 컨테이너 이미지를 생성한다
• 쿠버네티스 Deployment yaml 을 작성하고, 파드, 서비스를 작성한다.
• 배포와 자동화 스크립트를 만들어본다.
• 사전 준비 과정
  • Docker , 쿠버네티스, 파이썬 개발 환경의 준비가 되어있어야 한다.

3. 방법 (How)

fastapi application 작성한다.

- github  -https://github.com/jaysooo/service-common-api



Dockerfile 을 작성하고 컨테이너 이미지를 생성한다

from python:3.11-alpine

# set env
WORKDIR /usr/src
# source copy
COPY ./app ./app

ENV PYTHONPATH /usr/src/app

# package install
RUN pip install --upgrade pip && pip install --no-cache-dir -r ./app/requirements.txt

EXPOSE 9000

# container execution
CMD python -m uvicorn app.main:app --reload --host=0.0.0.0 --port 9000

이미지 생성과 실행 테스트를 해본다.

#!/bin/bash
echo "[LOG] 01. local deploy.."
IMAGE_NAME=demoapp
IMAGE_VERSION=1.0
TARGET_PORT=9000
#echo ${IMAGE_NAME}:${IMAGE_VERSION}


echo "[LOG] 02. container cleansing.."
docker stop `docker ps | grep -e "${IMAGE_NAME}:${IMAGE_VERSION}" | awk '{print $1}'`
docker rmi -f ${IMG_NAMME}:${IMAGE_VERSION}

echo "[LOG] 03. image build.."
docker build -t ${IMAGE_NAME}:${IMAGE_VERSION} .

echo "[LOG] 04. container run.."
docker run -p ${TARGET_PORT}:${TARGET_PORT} -d ${IMAGE_NAME}:${IMAGE_VERSION}

docker ps | grep -e ${IMAGE_NAME}

친한 선배이자 개발자 동료인 지인이 1일 1글쓰기를 시작 했다며 블로그를 공유해줬다. 그는 교육 강사, 개발자, 또는 회사 대표로서 꾸준히 일한다.

주변 사람에게 선한 영향력을 주고, 그를 보면서 자극을 많이 받아 열심히 노력하게 된다. ( 여기 -> https://www.alghost.co.kr/ )

그래서..   

나 역시 내가 겪는 경험과 생각을 정리하면서, 자유롭게 글을 써보기로 마음먹었다. (마침 창 밖에 빗소리가 내 감성을 채워준다.)

마침 회고할 것이 있다. 가끔 머릿 속 생각을 입밖으로 꺼낼 때가 있다. 그리고 대부분 후회한다.

팀이 하반기 해야 할 일과 방향성을 고민해보고 나눠보는 자리에서, 타부서의 업무지만 우리가 함께 해야 할 것 같아 이야기를 꺼냈다가 싫은 소리를 듣게 됐다.

부서가 담당한 역할과 일이 분명히 구분되있다. 그리고 회사에서는 업무 하나라도 A팀에서 할지 B팀에서 할지.. 담당자들의 보이지 않는 줄다리기를 해야 한다.

난 데이터 엔지니어 입장에서 본다면, 데이터를 수집하는 영역은 우리가 참여해야 할 일이라고 생각했다. 그 데이터는 팀에서 활용 의존도가 높아지고 있다. 우리도 직접 만들면 요청하고 기다리지 않아도 되고, 모두가 좋은거 아닌가 싶었다.

그렇게 오전 회의에서 하지 않아도 될 말을 입 밖으로 꺼내 긁어 부스럼을 만드는 꼴이 됐다. 이런 부분에서 내가 아직 많이 부족하다고 느꼈다. 사실 이전 직장에서도 나의 이런 부분은 고쳐야 한다고 팀장님께서 많이 말씀하셨다. (쉽게 고쳐지지 않지만…)

데이터 엔지니어로서의 나와 빅데이터 플랫폼팀에서 팀원으로서 나의 역할은 같은 것 같지만 다르다. 난 두가지 Role 안에서 신중히 고민하고 의견을 내야 한다.

아직은 R&R 을 따져가며 정치적으로 일하고 싶지 않은 심리가 솔직히 어느정도 있다.

현실적인 것보다 이상적인 것에 더 끌리는 편이다.

내 머릿속 고민의 총량이 있다면, 정치적인 고민보다는 기술적인 고민으로 채우고 싶은 거다.

결론은.. 난 팀장을 하면 안되는 사람이다. 팀원이 피곤해질거니까