[한화시스템 Beyond SW캠프] 19주차 회고
현황
이제 DevOps 프로젝트가 끝나고 최종 프로젝트에 들어갔다.
따라서 아래 두 번째 제목도 학습 → 프로젝트 변경!
일단 그래도 기간 자체가 있기 때문에 집 청소도 하고 인간다운 삶을 살고 있다. 테이프만 뜯은 택배 상자들과 걷고 개지 못해서 산더미 같이 쌓인 빨래들, 수영 다녀와서 마르라고 아무렇게나 펼쳐 놓은 수영 장비들… 모든 것이 눈 앞에서 사라졌다!!!! 그래, 이게 사람 사는 공간이지!!
옆집에 사시는 할머니가 장기간 집을 비운다고 하셔서 기회는 이 때다! 하고 청국장을 끓여 먹고 있다. 행-복~ 냉동실에 있는 거 다 먹고 다시 채운 다음에 또 기회를 노려야지! 프로젝트 외적으로는 행복 지수 높아지는 중~
프로젝트
DevOps 프로젝트 회고
쉴 새 없이 달려온 DevOps 프로젝트가 화요일 발표를 끝으로 마무리됐다.
강사님이 최종 프로젝트의 예고편이라고 생각하고 해보라고 하셨는데, 이게 예고편이면 솔직히 제일 열심히 한 절반의 인원이 탈주하지 않을까? 라는 생각이 들었고, 헬모드를 경험한 팀원들은 변화의 필요성을 강하게 느꼈다.
역할 분담
개인적으로 여기에서 큰 문제가 발생했다고 생각한다. 딜레마이기도 한데, 지금도 뭐가 좋은 것인지 잘 모르겠다.
이번에 우리 팀의 특화 기능으로 채팅과 채팅 추천 기능으로 정해졌는데, 각각에 어느정도 능력치가 있는 인원이 배치됐다. 거기에 추가로 엉망진창 상태인 나 조차 백엔드 개발을 느릿느릿 마치고 DevOps로 빠지면서, 전체 프로젝트에서 기초가 되는 기능들에서 공백이 발생했다. 아무리 기본적인 CRUD라고 하더라도 그 기본이 탄탄해야 위에 장식품을 올릴 수 있는 것인데, 거기서 흔들려버린 것이다.
영원히 고통받는 옆자리 잼씨는 본인 기능에 더해서 내가 개발한 백엔드에 대응하는 프론트엔드를 개발해야 했고 또 더해서 기본 기능들을 담당하는 인원을 지원하느라 많은 스트레스를 받은 것으로 보였고, 결국 정상적으로 개발되지 못한 기본 기능들은 채팅 추천 기능으로 빠졌던 인원이 다시 되돌아와서 하루이틀만에 얼기설기 연결해놓았다.
프로젝트의 채점 기준이 되는 DevOps를 맡아버린 나도 중간에 내려놓고 개발 지원을 할 수 없어서 ‘빨리 끝내고 도와줘야 할 것 같은데…’ 라는 생각이 계속 들면서도 진행 속도가 더딘 DevOps를 초조하게 진행할 수 밖에 없었다.
결과적으로 정해진 스크립트로 진행할 경우 어느정도 시연이 가능한 수준이 되었지만, 일부 인원의 과도한 업무는 반복되면 안될 것으로 보였다. 그렇다고 업무를 반대로 맡기는 일은 있을 수 없고, 절대적인 시간이 필요한 특화 기능을 기본 기능 개발 후로 완전히 미뤄버릴 수도 없다. 도전에는 실패가 따르기 마련이고, 그렇기 때문에 언제 완성될 지 알 수 없기 때문이다.
내가 만든 토큰~ 너를 위해 구웠지~
(내가 만든 쿠키가 노래에서 나온거였네… ㅎ;)
이번에 회원 기능을 구현하면서 이메일 자체 로그인을 구현했다. 이메일 인증을 구현해야 했는데 인증번호를 포함한 이메일을 보내서 인증을 한 후에 인증되었다는 사실을 어떻게 최종 회원가입 요청에서 증명할 수 있을까? 라는 고민을 하게 되었다.
길게 고민하다가 최종 선택은 JWT 토큰이었다. 따지고 보면 로그인 여부 확인과 똑같은 게 아닌가? 라는 생각이었다.
그렇게 정하고 이메일 인증번호가 확인되면 로그인 JWT 토큰과 별개로 새로운 JWT 토큰을 만들어서 클라이언트에 발급했다. 클라이언트는 그 JWT 토큰을 가지고 있다가 회원가입 버튼을 누를 때 헤더에 포함해서 넘겨주고, 백엔드는 토큰에 대한 검증 과정을 거치고 우리가 발급한 만료되지 않은 정상적인 토큰일 경우에 회원가입 절차를 이행하는 것이다.
Swagger로 문서화와 테스트를 진행했기 때문에 Swagger에도 로그인 토큰 외에 추가 토큰을 입력할 수 있도록 설정했고, 매 요청마다 필터를 통과하는 로그인 토큰과 완전히 분리하여 기타 서비스에 지장이 없도록 했다.
성공적으로 구현해서 뿌듯했다~
DevOps
발표 당일날 오전에 만든 아키텍처 구조이다.
모니터링 기능을 추가적으로 제공하기 위해 ELK 스택이나 프로메테우스-그라파나를 생각하고 있었는데 생각보다 시간이 오래 걸려서 마감 전에 간신히 기본 기능만 구성할 수 있었다.
쿠버네티스는 지루했고, 젠킨스는 짱-재미있었다! 로 요약할 수 있을 것 같다.
[이슈 1] Kubernetes Cluster에서 DBMS 배제
그림을 너무 급하게 만들어서 안타깝게도 데이터베이스의 위치가 빠져버렸는데, 데이터베이스는 완전히 외부에 위치한 데이터베이스를 사용했다. 아주 긴 고민이 수반된 결정이었는데, 쿠버네티스 클러스터 안에 DBMS를 포함시키는 것이 타당하게 보이지 않았기 때문이다.
- 단일 컨테이너로 운영하는 경우
DBMS라고 하면 별도의 스토리지 서버가 존재한다고 하면 그 스토리지 서버 위에 직접 DBMS를 설치해서 연결하는 방법이 있을 수 있겠고, 스토리지 서버를 다른 서버에서 마운트해서 사용하는 경우가 있을 것이다. 여기에서 컨테이너 위에 DBMS를 올릴 경우 마운트한 외부 스토리지의 경로를 컨테이너 위에 올라간 DBMS가 볼륨으로 잡아줘야 하는, 두번째 방법과 유사하게 구현될 것이다. 하지만 정해진 요청과 응답만 받으면 되는 DBMS의 통신과 달리 마운트 방식의 경우 세세한 DBMS 내부 작업까지 네트워크를 타고 작업이 이루어지게 되므로 성능적으로 큰 제약이 생기는 것으로 보였다.
- 여러개의 컨테이너로 운영하는 경우
하나의 DBMS 저장 경로를 가지고 다수의 컨테이너가 볼륨으로 잡는 위험천만한 행위는 일단 가능성에서 제외하고, 하나의 Mster DBMS를 두고 읽기의 경우에만 다수의 Slave DBMS를 활용하는 방법이 가능할 것으로 보였다. Replication 방식으로 구현이 가능해 보이는데, 솔직히 이렇게까지 필요할까 싶었다. 어차피 Replication 방식도 Master의 변경사항을 Slave들이 이어받아서 그대로 작업하게 되어서 락을 회피한다는 명분도 희미하고, 우리의 서비스가 락을 회피해야 할 만큼 엄청난 IO가 발생하지도 않는다. 그나마 채팅에서 발생할 가능성이 있지만, 채팅은 MongoDB로 빼버렸다. 그런데 MongoDB는 사실 이번에 처음 사용해봐서 아예 논외로 빼버렸다. 쓰기 작업의 경우에는 그 성능을 이해했지만, 읽기 작업의 경우는 아직 잘 모르기 때문이다!
이런 이유로 인해 DBMS를 쿠버네티스 클러스터에서 배제했다. 나중에 보면 어떨지 모르겠지만 지금 지식으로는 이것이 최선으로 보였다.
[이슈 2] minikube의 Ingerss 비활성화
이건 어제 게시글 쓸 때 작성하긴 했다.
Ubuntu에서 진행한답시고 minikube로 Kubernetes를 구축했는데 기본적으로 Ingress가 설정되지 않아서 클러스터의 ingress가 켜지지가 않는다!!
이건 진짜 상상도 못했어서 인터넷 찾아보고 하다가 쿠버네티스를 사랑하는 어떤 분에게 물어봤었다. 그 분도 같이 한참 헤매다가(쓸데없이 Host Nginx 껐다 켰다 ㅋㅋ) 결국 답을 찾은 것이 minikube addon 설치였다.
[이슈 3] 컨테이너에 .env 파일 주입
제작된 도커 이미지를 DockerHub에 올리고 거기서 그대로 가져와서 클러스터를 구성했기 때문에, 어디에서도 .env파일을 주입할 수 없었다. 오직 쿠버네티스 클러스터 구성 시점에서 주입하는 방법 밖에는… 결국 젠킨스와 마찬가지로 따로 설정 파일을 주입해줬다. 방법은 ConfigMap.
파일 마운트가 생각보다 잘 되지 않아서 이렇게 저렇게 해보는데 구성 한번에 길게는 10분 정도 걸리다 보니 지루했다!
최종 프로젝트
수요일 부터 드디어 최종 프로젝트에 들어갔다.
여기도 이슈가 있는데 이거 블로그가 진짜 너무 길어지는 것 같은데… 적당히 쓰고 도망쳐야겠다…
일단 주제가 마음에 안드는 듯!!
다수결로 공급망 관리를 위한 주문 관리 시스템으로 정했는데, 까보니 너무 재미없는 주제였다.
(난 다른 거 투표함!!!! 난 결백하다!)
뭔가 차별점이나 기술적인 무언가를 곁들일 내용이 아니었다. 그냥 CRUD만 엄청나게 많았다.
다른 기수들 보면 이걸로 그냥 유사 쇼핑몰을 만들었던데… 쇼핑몰도 노잼이지만 이것보다는 재밌을듯… 근데 강사님은 공급망 관리 시스템 구축을 하는 게 맞다고 하니깐…
“이제는 열심히 해보자!” 하면 계속 뭐가 쾅! 내 앞을 막는다…
계획
바쁘게 달려온 DevOps 프로젝트 보다는 시간이 남는 듯 하다.
이제 드디어 복습이나 알고리즘이나 개인 프로젝트 등의 딴짓을 할 여유가 생긴 것 같다.
최종 프로젝트가 노잼으로 결론이 나면 그냥 적당히 딴짓으로 돌리는 게 더 재밌을지도…
아, 그리고 그동안 올리지 못한 학습 내용에 대한 포스팅을 올리기 시작해야 한다. 복습 겸?