23년도 상반기 회고

Dokkabei97·2023년 6월 16일
0

일상

목록 보기
5/6

1월

팀 이동

기존 검색/Devops팀에서 신기술과 devops를 맡다가 23년도 1월에 팀 이동을 했습니다.

옮긴 팀은 다나와에 수집기로 다나와의 상품 데이터를 수집하는 파트입니다.
해당 파트에 대한 설명은 향후 다나와 기술 블로그에 포스팅 할 예정입니다.

is-deploy 배포

is-deploy가 개발을 완료하면서 사용자가 적은 실제 운영서버에 배포 테스트를 진행에 성공을 하면서 공식적으로 배포를 하였습니다.

그리고 연구소 공지를 통해 사용 방법 교육 진행하였습니다.

is-deploy가 궁금하다면 아래 링크를 확인 해주세요!

2월

네이버 세미나

DEVIEW 2023 Day1 참석 및 워크샵 후기

전 포스팅 링크로 대체하겠습니다.

3월

문서 반자동화 i_hate_paperwork

개요

주간 보고서로 일일 서버의 CPU의 평균 사용량, Memory의 최대 사용량, 디스크 용량을 작성합니다.

수치는 cacti를 통해 확인합니다. 근데 cacti의 수치가 그래프와 함께 이미지 형식으로 제공하기에
드래고 해서 복사하기가 안되어 일일이 직접 적어야 하는 단점이 있는데
8개의 서버를 확인해야 하다 보니 귀찮아서 하루 이틀 미루다 주간 보고서를 작성해야 하는 날에 작성을 한다면 해당 작업만 오전 시간을 전부 다 소비해야 했습니다.

그래서 cacti에 수치를 따와서 구글시트에 해당 수치를 넣어주는 기능을 자동화 하고자 했습니다.

문서 작업이 하기 싫어 프로젝트명도 gitlab에도 i_hate_paperwork로 결정했습니다.

기술 선정

일단 제가 자신 있는 기술인 Java, Kotlin, Go, JavaScript 이렇게 있었습니다.
그중 Go 언어를 선택했는데 그 이유로는 생산성, 실행 환경이 있습니다.

일단 처음에 크롤링을 생각했으나 cacti는 이미지로 수치를 제공하여서 어떻게 할까 고민하다
playwright가 크롤링 할 페이지를 캡처가 가능한 걸 확인하였기에 playwright와 함께 사진에서 텍스트를 추출하는 ocr을 이용하기로 결정했습니다.

개발

cacti의 url 패턴을 확인 후 내가 모니터링할 서버의 id를 확인 후 코드에 때려 박고 모니터링할 날짜를 넣어주면 모니터링할 시간은 고정되어 날짜와 시간을 unix로 바꾸어 들어가게 하였습니다.

그럼 각 8개의 서버에 cpu, memory, data 수치의 사진들을 캡처 후 ocr을 통해 사진에서 텍스트를 뽑게 만들었습니다. 다음 구글 시트에 자동으로 수치를 넣어주게 만들까 했지만 API 키를 받고 사용하면 개발 공수가 늘어나 수치를 출력해 주는 거까지 개발했습니다.

실행시

./i_hate_paperwork 20230629

cpu: [5.68 11.23 21.42 ...]
memory: [32.69 102.52 91.35 ...]
data: [1046.12 1751.61 ...]

와 같이 나오게 개발 했습니다.

물론 cacti에서 수치에 이상한 게 같이 들어가서 i_hate_paperwork를 실행하면 덩달아 이상한 수치를 가져오는 문제가 있었습니다, 그뿐만 아니라 실제로 서버에 문제가 생겨 수치가 높거나 너무 낮을 때는 그래프를 확인해야 하다 보니 실행할 때 값을 하나만 더 넣으면 캡처한 사진을 그대로 남길 수 있는 기능도 만들었습니다.

4월

is-deploy 서비스 확장 및 업데이트 안 준비

서비스 적용까지

처음에 is-deploy 개발자 자동 배포 도구가 만들어지고서 2월까지는 기존 개발자들이 해당 서비스를 왜 사용해야 해? 그냥 기존처럼 SE 팀이 담당하면 되는 거 아닌가?라고 시큰둥 해서 서비스가 내려가나 걱정을 했지만

운영 서비스에 테스트 협조해 준 개발자분부터 저랑 같은 동호회에 속한 친한 동료의 서비스를 필두로 적용되면서
다들 편하다고 해서 다른 파트의 서비스 담당 개발자들도 SE와 이야기해서 적용하기 시작하였습니다.

그렇게 어느덧 6월 기준 다나와의 핵심 서비스들을 전부 적용이 완료되었습니다.

업데이트 안

초기 버전은 기술 검증에 시간이 소유되어서 공수를 낮추고 빠르게 적용하기 위해 UI는 포기한 수준에
일부 보안면에서 취약한 부분이 있어 업데이트 안을 준비했습니다.

보안, 사용자 편의성, UI, is-deploy 관리자(SE/담당 개발자인 저) 편의성, 다양한 환경의 배포 자동화
를 준비해서 5월까지 상당수 구현을 했지만 밑에 6월 회고에 제가 파트 이동이 생겨서 현재는 개발이 멈춘 상태입니다.

5월

AWS 세미나

aws

동기와 함께 AWS 세미나를 갔습니다.

AWS 역시 국제 기업... 진짜 네이버 DEVIEW와 규모가 다르다고 느낀 게 AWS 세미나는 코엑스의 반을 사용해가지고 놀랐습니다.

하여튼 처음에 아침에 코엑스에서 동기 기다리고 있는데 한 분이 저를 뚫어져라 쳐다봐서 저도 봤는데 어디서 본 얼굴인 거 같아 뚫어져라 쳐다보니 그분이 먼저 인사해서 보니깐 저랑 MMA 체육관 같이 다니는 분 진짜 놀랐습니다, '한국 진짜 좁네'라고 생각하고 그렇게 인사하고 헤어진 후 체육관 단톡방에서 다시 이야기 좀 나누었습니다. 그와중에 체육관 감독님은 코엑스에서 스파링 하시라고 ㅋㅋㅋㅋㅋ

그리고 동기와 만나서 각자 듣고 싶은 거 듣고 중간에 is-deploy 개발하면서 협업하고 일부 담당하시는 SE 팀 분도 오셔가지고 같이 만나서 커피를 마시고 이야기하다 다시 듣고 싶은 거 들으러 갔는데
제일 듣고 싶었던 MSA 관련 섹션에 사람이 많이 몰려서 듣는데 실패했습니다 ㅠㅠ 너무 아쉽네요.
그렇게 6시까지 다 듣고 동기와 함께 밥 먹고 술 마시다 동기 집에서 자고 집 갔습니다. ㅋㅋㅋㅋ

코틀린 스터디

팀원들과 코틀린 스터디를 시작했는데.. 아니 사실상 저의 코틀린 강의 했다고 해도 무방할거 같아요.
토요일마다 만나서 스터디 룸 잡아가지고 제가 열심히 명강의를 펼쳤습니다.

그렇게 지금은 강의는 끝나고 다 같이 토이프로젝트를 진행하고 있습니다.

6월

파트 이동

옮긴 파트는 다나와에 분류기로 수집기 파트에서 상품 데이터를 수집 후 해당 데이터를 분류하는 파트입니다.
해당 파트에 대한 설명은 향후 다나와 기술 블로그에 포스팅 할 예정입니다.

i_hate_paperwork 동적 모니터링

이제 파트 이동 후 똑같이 주간 보고서를 작성해야 하는데 파트장님이 이 작업이 너무 귀찮다고 하시다가 얼핏 제가 반자동화한 것을 기억해 우리 파트에도 사용 가능하게 수정해달라고 하셔서 수정하였습니다.

초기 개발에는 수집기 파트에서만 사용하여서 하드코딩으로 서버의 id와 시간을 다 때려 박았는데
다른 파트에서도 모니터링할 id와 시간대를 동적으로 사용할 수 있게 개발하였습니다.

설정은 yml파일을 통해 하게 만들었습니다.

monitor:
	time:
    	# 모니터링할 시간 ./i_hate_paperwork 20230629시
        #start는 전날의 20230628 00:00 end는 20230629 00:00 으로 들어갑니다.
    	start: "00:00"
        end:	"00:00"
    
    # 모니터링할 서버명 그리고 cpu, memory, data의 id (data는 optional)
    server:
    	서버명1:
        	cpu: 1
            memory: 2
       서버명2:
       		cpu: 3
            memory: 4
            data: 5

와 같이 설정 해서 동적으로 수치를 가져오게 만들었습니다.

동적으로 만들면서 map타입을 사용해서 순서 보장이 안되는 부분이 생겨서
순서를 보장해 주면 또 공수가 늘어나는 만큼 그냥 서버명을 키값으로 주어서 아래와 같이 출력되게 변경했습니다.

./i_hate_paperwork 20230629

cpu: [서버명1: 5.68 서버명3: 11.23 서버명2: 21.42 ...]
memory: [서버명1: 32.69 서버명3: 102.52 서버명2: 91.35 ...]
data: [서버명3: 1046.12 서버명2: 1751.61 ...]

다 설정하고 사내 메신저에 팀 단톡방에 공유했는데
바로 제 파트장님이 몇 번 사용하시더니 사진 보는 게 너무 좋다고 하시면서 Go 언어 모르시는데 저한테 바로 코드 좀 보시더니 저한테 물어보면서 살짝 수정해서 사용하시더군요.

역시 개발자는 자동화가 최고인거 같습니다.
좀 더 시간을 짜내어서 is-deploy v2 개발하고서 팀 배포 시스템도 자동화를 해야 할 거 같습니다.

profile
ESTJ 개발자 백엔드와 인프라에 집중하고 있습니다.

0개의 댓글