[우테코/줍줍] 5차 스프린트 회고

1. 개발 일지
   • 설정 파일 관리
   • 운영/개발 완전 분리
   • DB 설정 변경
   • 톰캣 설정 변경하기 (feat. 부하 테스트)
2. 있었던 이야기
   • 첫 릴리즈와 회식
   • 독서 모임
   • 앞으로의 계획

 

---

1. 개발 일지 🔮

 

💜 설정 파일 관리

 기존에는 profile별로 yml을 분리해서 관리하고 있었다. 헌데 지난번 레벨3 인터뷰 때 yml은 profile별로 파일을 분리하지 않아도 되는데 왜 분리해서 쓰는지에 대한 질문을 받았다. 솔직히 말하자면 하나로 관리할 수 있다는 사실을 몰랐기에 그런건데.. 이번 기회에 하나로 쓰는 방법을 학습해보고자 적용해보았다.

 

 사용법은 간단하다. 그저 '---'를 추가해주면 된다. 헌데 지금은 줍줍 설정 파일에 많은 값이 들어있지 않지만 많은 설정 값들이 profile마다 바뀌어야한다면? 오히려 파일을 분리하는게 보기 편할 것 같다는 생각이 들었다.

 

 

💜 운영/개발 완전 분리

 기존에는 운영과 개발이 겹쳐있는 부분이 있었다. 줍줍을 활용하기 위해서는 슬랙 워크스페이스에 앱을 추가해야 하는데 이 앱을 운영과 개발이 함께 쓰고 있었다. 여태까지는 프로젝트가 계속 개발중이었지만 릴리즈를 코 앞에 두고 분리를 해야겠다는 생각이 들어 앱을 완전히 분리시켰다. 

 

 앱을 새로 설정해주면서 생각했는데 슬랙은 앱을 설정하는 과정이 너무 복잡하다. 줍줍 릴리즈 2.0.0 때는 어떤 워크스페이스든 앱을 추가만 하면 서비스를 이용할 수 있게 해주는 것이 목표이다. (우테코 기간 내에는 힘들겠지만ㅜ.ㅜ) 헌데 이 꼭 추가해야만하는 앱을 만드는 과정은 사용자가 직접 해야만 한다. 과정이 복잡해서 사용자가 힘들어하지 않을까... 어떻게 이 과정을 생략하거나 간략화할 수 있을까? 에 대한 고민이 생겼다.

 

 

💜 DB 설정 변경

관련 포스팅: DATETIME vs TIMESTAMP

[MySQL] DATETIME vs TIMESTAMP

 

 슬랙 채널에서 메시지가 작성되면 줍줍의 백엔드 API가 호출되며 DB에 메시지 데이터를 저장한다. 메시지 작성 날짜는 MySQL의 TIMESTAMP 형식으로 저장되는데 문제가 생겼다. 1초 안에 여러번의 메시지가 저장된다면? 예를 들어 5개의 메시지가 순서대로 작성되었다고 가정한다면 DB에는 아래와 같이 저장될 것이다.

 

+---+---------------------+
|id | posted_date         |
+---+---------------------+
| 1 | 2022-09-25 17:55:09 |
| 2 | 2022-09-25 17:55:09 |
| 3 | 2022-09-25 17:55:09 |
| 4 | 2022-09-25 17:55:09 |
| 5 | 2022-09-25 17:55:09 |
+---+---------------------+

 

 posted_date를 기준으로 정렬하여 메시지를 조회하면 어떤 순서로 올까? 이상적인 순서는 1, 2, 3, 4, 5이다. 하지만 실제로는 1, 2, 5, 3, 4 이런 식으로 랜덤한 순서로 온다. posted_date 값이 모두 같기 때문에 정렬 순서가 의도와는 다르게 나오는 것이다. 해결 방법은 간단하다. milliseconds 까지 함께 저장하면 된다. TIMESTAMP 타입을 TIMESTAMP(6) 타입으로 바꿔 6자리의 milliseconds를 저장하게 만들었다.

 

 

💜 톰캣 설정 변경하기 (feat. 부하 테스트)

톰캣의 아래 설정을 바꾸며 최적의 값을 설정하는 미션을 받았다.

• max-connections: 서버가 요청을 처리할 수 있는 Connection의 수
• accept-count: 추가적인 Connection을 대기
• threads.max: 동시 요청을 처리할 수 있는 Thread의 개수

 

이를 이해하기 위해 가장 먼저 Thread에 대해 공부해보았다. 이 때 공부한 내용들은 링크로 대체한다.

• Thread 이해하기
• 동시성 vs 병렬성
• Thread Pool 이해하기

 

그 후에는 최적의 값을 찾기 위해 부하 테스트를 진행해보아야겠다는 생각을 했다.

(부하테스트를 하는 방법: https://github.com/woowacourse-teams/2022-pickpick/wiki/Apache-JMeter-가이드)

GitHub - woowacourse-teams/2022-pickpick: 🐹 사라지는 Slack 메시지, 우리가 주워줄게!

 

여러번 테스트를 진행하며 결과값을 구글 스프레드 시트로 정리해보았다. 스레드의 처리량이 적절한가, TPS 그래프가 요동치지 않는가, 오류가 너무 자주 발생하지 않는가, 평균 응답 시간이 너무 느리지 않은가의 기준을 두고 적절한 값을 선택했다.

 

 

---

2. 있었던 이야기 🐹

 

🧡 첫 릴리즈와 회식

 

 이번 스프린트 때 줍줍 서비스를 실제 사용할 수 있도록 오픈을 했다. 릴리즈 직후에도 뒤늦게 발견된 오류들을 핫픽스 쳐야했지만..😂 어떻게든 해냈다. 줍줍의 첫 릴리즈 1.0.0을 기념하며 회식 자리를 가졌다. 잠실에서 유명하다는 별미곱창을 갔는데 정말 비싸고(😢) 정말 맛있었다😋 팀원들이랑 이런 저런 이야기를 하며 아이스크림도 먹고 2차도 가고 네컷 사진도 찍고~~~ 이렇게 마음 편히 있던건 오랜만이라 최고의 하루였다. 👍

 

 

🧡 독서 모임

 이번 스프린트 때 따로 스터디는 없지만 독서 모임을 2개 들었다. 하나는 토비의 스프링, 하나는 Real MySQL을 읽고 있다. 토비의 스프링은 사실 우테코 레벨2 까지만 해도 금지도서였어서 많이 어려울거란 생각이 들었는데 전혀 아니었다. (아직 초반 부분을 읽고 있어서 이렇게 생각하는걸지도 ㅎ...) 스프링이 어떤 과정을 거쳐 발전해오게 되었는지에 대해 이해하게 되었다. 다만 TDD나 객체지향에 대한 것 등에 대한 이야기도 많다보니 여러가지 개념을 알고 있는 사람이 읽어야 더 많은 것이 와닿을 것 같다는 생각이 들었다.

 

 Real MySQL은 사실 아직 잘 모르겠다. DB에 대해 쿼리문만 작성해왔지 어떤 식으로 만들어졌는지에 대해 공부해본 적이 없어서 생소한 개념들이 너무 많다. 😭 완전히 이해하려면 몇 번은 더 읽어야할 것 같다. 이런 것이 있고 어떤 방식을 사용하는지 대충의 흐름이라도 알아두면 나중에 완전히 이해할 날이 올 것이라고 믿고 있다.

 

 

🧡 앞으로의 계획

제일 중요한건 테스트. 테스트 개선이 시급하다🙃 테스트 케이스도 추가해야 하고 fixture도 개선해야하고 제일 시급한건 테스트 속도가 너무 느리다. 안그래도 느린 빌드 과정이 테스트 때문에 더 길어지고 있다. 중요 순위에서 조금씩 밀리면서 다음 스프린트로 넘어가다보니 테스트 개선이 거대한 하나의 태스크로 찾아왔다. 😥

 

 현재 LogBack을 사용하고 있는데 Log4j 2로 전환하고 싶다는 생각도 하고 있다. 성능이 더 좋다는 이야기는 들었는데 구체적으로 차이점에 대해서 찾아보고 어떤 것을 적용할지 고민해보아야겠다.