지난 2주간 꽤 많은 일이 있었다.
기억이 휘발되기 전에 2주가 조금 지난 지금 시간을 내어 회고를 작성해본다.
지난주에 목표했던 것 처럼 신규 인원들이 새로운 작업환경에 익숙해지기 위한 2주가 되었던 것 같다.
그와 같이 동아리 내 조직 개편이 이뤄지면서 꽤나 바쁜 2주가 되었다.
개강총회도 있었고, 다양한 행사들도 있었지만 본 글에서 코인 마이그레이션 외적인 일은 다루지 않겠다. (3월 회고에 쓸까 싶다.)
지난주에 이어 초록스터디를 통해 신규 인원들의 온보딩을 진행했다. 기획했던 총 4주차의 커리큘럼을 완수하면서 팀원들이 코드리뷰 문화에 어느정도 익숙해진 모습을 볼 수 있었다.
3주차 Core 미션이 다소 쉽게 다가왔다는 후기가 많았다. 이 기간동안 학습을 보완하는 인원들이 많았고 4주차 버퍼기간을 다르게 활용해야할 필요가 느껴졌다.
3주간 미션을 진행하며 완성한 프로젝트를 배포해보는 경험 또한 중요하다고 생각이 들어 마지막 주차 미션을 프로젝트 배포 미션으로 변경했다.
아무래도 다들 처음 접하는 내용이다보니 A to Z로 따라할 수 있게끔 실습 강의 및 영상을 제공했다.
🎥 Youtube - AWS로 서비스 배포하기
예전부터 이런 교육영상을 찍어서 온보딩을 자동화하고싶다는 생각을 했었는데 이 영상이 그 첫걸음이 될 것 같다는 기대감이 생긴다.
참여한 인원들 중 블로그에 후기를 남겨준 인원들도 있어 교육의 보람이 많이 느껴졌다.
코인 마이그레이션 작업에 대한 온보딩을 진행했다.
팀원과 전반, 후반을 나누어 온보딩을 진행했다.
온보딩 준비해줘서 고마워.. 🥹
마이그레이션을 왜 진행하기 시작했는가부터 인수테스트 작성 방법, 프로젝트에서 사용되고있는 기술스택, 코드 컨벤션, 리뷰 방법 등에 대한 온보딩을 진행했다.
참고자료
📚 Github Wiki, 💬 Github Discussion에 대한 설명도 함께 진행했다.
현재 구성되어있는 인프라에 대한 온보딩도 진행했다.
현재 코인 프로젝트는 위와 같은 환경으로 인프라가 구성되어있다.
github로 작업하고 jenkins로 빌드하여 빌드 산출물이 production 서버에 구성되기까지의 과정, 그 사이에서 S3, CloudFront를 활용한 이미지 관리, presigned URL 방식 등에 대한 온보딩을 진행했다.
많은 내용을 하루만에 주입해서 온보딩 참여 인원들이 꽤나 힘들어보이긴했다. 영상으로 남겨서 복습할 수 있도록 제공하는 방향을 생각해봐야겠다.
지난번에 최대한 간단한 CRUD 기능만 있는 API를 온보딩 이슈로 등록해뒀다.
총 7명의 인원에게 온보딩 이슈를 하나씩 할당하여 인수테스트 작성방식, PR 작성 및 리뷰 방식에 대해 익숙해질 수 있는 시간을 줬다.
KOIN 마이그레이션은 기능단위로 PR을 올리고 Merge하며 작업을 진행하고있다.
예를들어 GET /lands라는 API를 만들었다면 기존 애플리케이션과 완전히 동일하게 동작해야만 한다.
8081 포트로 새로운 WAS를 구동시켜서 완성한 path에 대해서만 마이그레이션된 코드를 사용할 수 있도록 구성하면 될 것이다.
nginx location 블록은 정규식의 형태로 문자열을 매핑한다. 이를 활용하여 특정 path에 대해서 8081 포트로 리다이렉트되도록 구성해봤다.
(짧은 지식이라 우선은 다음과 같이 구성했으나 더 좋은 방법이 있을 수도 있다.)
location ~ ^(/tracks|/dept|/versions/|/swagger-ui/|/v3/api-docs|/semesters) {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_pass http://localhost:8081;
}
위처럼 특정 path들에 대해서 마이그레이션된 API를 사용하도록 구성하여 stage환경에서 클라이언트와 잘 동작하는지 확인하는 방향으로 마이그레이션을 진행하고있다.
대략적인 도식을 그려보자면 다음과 같다.
구체적인 작업 과정에 대해서는 팀원이 작성해준 글을 참고하고있다.
참고자료: 특정 API path 배포 방법 (온보딩용)
팀 내 인프라 담당 인원과 논의하여 Datadog을 사용해보기로 했다.
APM, 로깅, 모니터링 등 다양한 기능을 제공해주는 툴로 유료 서비스이지만 학생플랜을 활용하여 2년간 무료로 사용해볼 수 있다.
아직 동아리원 누구도 성능 측정, 로깅 등에 대한 이해도가 충분하지 못한 상황이기 때문에 프로메테우스, 그라파나와 같은 매트릭 측정 오픈소스를 제대로 활용하기 어렵다는 생각이 들었다. Datadog을 경험해보면서 어떤 정보를 수집했을 때 효과적이였는지 알고난 뒤 프로메테우스, 그라파나와 같은 오픈소스 무료 매트릭 분석 툴을 사용해보면 좋겠다는 생각에 Datadog을 선제적으로 도입해보기로했다.
정말 고맙게도 인프라 담당 팀원이 서비스 환경에 Datadog을 구성하고 이를 온보딩하기 위한 세미나를 진행해줬다.
정말 다양한 정보를 확인해볼 수 있어서 꽤나 유용한 툴이라고 생각되었다.
더욱 다양한 방면으로 활용해볼 수 있도록 연구해보면 좋을 것 같다.
🎥 Youtube - [BackEnd] Datadog 세미나
팀원중 한명이 짜온 로직 중 사용자 회원가입이 완료되면 슬랙을 발송하는 로직이 있었다.
슬랙 발송 로직까지 하나의 트랜잭션으로 묶여있는 바람에 사용자가 회원가입 및 이메일 발송을 정상적으로 진행해도 슬랙 발송이 실패하면 사용자가 서비스에서 오류를 받아버리는 상황이 있었다.
슬랙 발송은 동아리 내에서 모니터링하기 위한 용도이고, 회원가입은 사용자가 수행하는 로직이다.
모니터링을 위한 로직이 실패했다고 프로덕션에 영향을 미치게 되는 이 현상이 비정상적이라는 생각이 들었고 Spring Evnet와 Tx Propagation을 도입하여 별개의 Transaction에서 슬랙 알림발송 로직이 동작하도록 구성해달라고 팀원에게 제안했다.
팀원이 잘 적용해준 덕분에 마이그레이션 하면서 조금 더 안정적인 서비스를 구성할 수 있게 되었다.
현업에서 신규 기술을 도입하고 싶을 때 세미나를 주최하여 팀원들의 이해도를 맞춘 뒤 해당 기술을 적극적으로 도입할 수 있는 환경을 만들어 둔다는 이야기를 들었었다.
동아리 또한 여러명이 함께 작업하는 조직이고 팀원 각자의 이해도가 다르기 때문에 이러한 세미나가 필요하다는 생각이 들었다.
시간, 공간적으로 제약이 있다면 discussion도 좋은 선택지인것 같다.
인원이 많아지면서 PR 작성 속도가 조금씩 늘어나고있다.
이번 학기중으로 마이그레이션을 모두 완료할 수 있으면 좋겠다.
회고를 하면서 몇가지 개선해야할 부분들도 보여 기록해두고자 한다.
이번 회고를 작성하면서 인프라 구조도를 그려봣는데 생각보다 개선해야할 부분이 많이 보였다.
마이그레이션 방식 또한 수정이 필요했다.
기존 코드의 swagger에 작성되어있는 응답값과 실제 응답값이 다른 현상이 있었다.
기존 swagger에 명세된 내용을 신뢰할 수 없게 되었다. 실제로 API를 호출해보고 결과값을 확인해보며 마이그레이션 작업을 진행해야겠다.
이렇게 보니까 2주동안 되게 많이했네 ㄷㄷ