2023.09.11

기술중심으로 입사후 한일 (내가 메인)

막 어려운 것, 아예 못할 것 같은걸 한적은 없는 것 같다..(곧 정체기가 오지 않을까)

 

- 로그성 테이블 (로우데이터 테이블, 포인트 지급 테이블) 개선

서비스 내 장애 요소가 된 테이블. 데이터가 많이 쌓이는 테이블인데 정규화 x 인덱스 잘못 걸린 테이블이라 대시에서 조회시 높은 확률로 계속 log query가 실행되어 db burst balance 가 0이되고... 이런 상태였다.

-  로그성 테이블이 용량이 크더라도 잘 다운로드 되게함

이게 기술적인건가 모르겠는데 일단 안되고 있었으니까.. 기존에는 select 해온 모든 데이터를 메모리에 fetching 한 뒤(...) 응답으로 내려주는 무지막지한 구현이었다. 이렇다보니 아무리 테이블에 인덱스가 잘 걸려있어도 데이터가 크다보면 fetching 하는데 시간이 오래 걸려 timeout 으로 다운로드 실패! stream 하게 db 데이터 조회하도록 api를 다시 만들었다.

- 모든 캠페인 테이블 정규화

출석체크 캠페인(일반, kp, kb, 비밀) 모두 정규화. 날짜 저장을 비트맵으로 한 것은 꽤 좋은 전략이었다 생각한다(많으면 31배 데이터를 축소시킬 수 있으니까). 팀에서는 인정하지 않는 눈치였지만 DBA분이 잘했다하셨으니까..

- db 및 redis 에 필요 이상의 쿼리를 수행하는 레거시 코드 최적화

많으면 요청당 90배.. 레디스에 쿼리하는 상황이었다. 어플리케이션 로직의 버그를 발견해서 수정! 레디스 관련된 api (다른팀에도 관련된) 에 영향을 주고 있었는데 (갑자기 9월 초부터 오후에 요청이 기존의 2배가 됬는데 레디스 latency가 높게나와서 문제가 되었다) 평상시 이상없을 때보다 2배 latency 향상됬다. (200ms -> 100ms) 근데 어플리케이션 레거시 코드 개선으로 latency 개선한 것도 기술 중심으로 한일이 되려나.. 그래도 새 기능을 만드는건 아니고 유지 보수 측면에서는 개선한거니까..

- fiber framework 로 인한 버그 수정

많은 요청을 처리하고 있을 때 데이터 다운로드 혹은 비동기로 저장시 핸들러에서 받아온 값들(header 값, query param, path param 등)이 중간에 바뀌는 버그가 있었다. 쓰고 있던 프레임워크의 특성인 걸로 파악하고 이슈도 찾아보고 관련된 테스트 코드도 작성해서 실제 로컬에서 값이 바뀌는 것을 테스트 해보았다. 재현하기 전까지 production에서만 나던 버그라 찾기 힘들었는데 그래도 어찌저찌 수정할 수 있었다.

- datadog fiber middleware 버그 수정

open source 로 데이터독 middleware를 사용하고 있는데 이것 때문에 graceful shutdown 이 안되고 있던 것을 확인하고 수정했다. 이슈 남겼는데 코멘트 기다리고 있다.. 이것은 해당 middleware가 fiber 의 user context 로 fasthttp request context를 주입하고 있어서 발생했다. user context 기본 값은 background context 로, timeout 이나 deadline이 기본으로 설정되어있어 SIGTERM이 발생하면 종료되는 fasthttp request context와 다르다.

 

대략적으로 한일은 이렇고 해결했던 이슈들 (+ 구현했던 기능들) 에 대해 더 자세히 공부해보려 한다. 

일단 쓰고있는 기술, opensource, architecture 를 정리해보면

 

언어:go,

인프라: db(aws rds), redis(aws elastic cache), docker(인프라 맞나요), kubernetes(istio?),

네트워크:  http, grpc, proxy, ingress, egress? istio?

모니터링: datadog, prometheus

CI: github actions

설계: MSA, DDD, hexagonal

 

이렇게 있다.

 

해왔던 작업에 관련해서 더 깊게 알아야하는 것은

go

- http connection pool 관리 법

- fiber(fasthttp) 에서 context를 재사용하고 있는데 이렇게 하면 성능향상 되는 이유

- embedding, interface 다른언어와 차별되는 go의 특징