25-03-19

📌 Daily Report

https://github.com/ssginc-be/DOKI/issues/126

📌 프로젝트 상황

안타깝게도 내 체력이 의지에 안 따라주는 것 같다.

모니터를 못 쳐다보겠을 정도로 편두통에 안구건조증에 묵직한 피로에 뭔지 모를 붕 뜬 느낌까지 들어서 거의 눈 감은채로 병원에 갔다.

텍스트만 보면 뭔가 생색내는거 같은데 저게 다 종합세트로 오니까 억지로 모니터 보면서 작업해도 한 70%는 멍때릴 것 같을 정도로 힘들었다.

그래서 수액 2종류 섞어 맞고 진통제도 처방받았는데, 좀 비싼게 흠이지만 기적같이 지옥에서 살아나왔다; 솔직히 기대 안했는데 무슨 미래 수명 땡겨온줄 ㅋㅋㅋ

상태가 호전돼서 다행이지만 내심 짜증이 난다.

아니 왜 체력이 협조를 안해주지?

내가 얼마나 아침에도 낮에도 저녁에도 새벽에도 개발하고 싶은데? 지금 할게 얼마나 많은데?

📌 무의미한 synchronized

예약 동시성 TDD가 드디어 마무리 되었다. 테스트는 10000명의 정원을 가진 엔트리에 대하여 50000개의 동시 예약 시도를 걸었는데, 값이 크다보니 환경 세팅도 들어가서 생각보다 까다롭더라. 일단 다음의 설정들이 필요했다.

---

1. MySQL의 max-connections 늘리기 (-> 클라이언트 접속해서 설정)
2. JVM heap memory 늘리기 (-> gradle 파일에서 설정 [레퍼런스])
3. hikari max-pool 및 timeout 늘리기 (-> yml에서 설정)

---

하단은 별다른 처리 없이 서비스에 @Transactional만 붙인 테스트의 결과이다.

그리고 이건 서비스에 synchronized 키워드를 추가한 테스트의 결과이다.

결과가 더 안좋음 ㅋㅋㅋㅋㅋㅋ

synchronized에 대한 보완책과 그 보완책의 한계점은 여기서 잘 설명해주었다.

결론적으로, 현재 상황에 필요한 조건을 단기간의 개발 일정에 만족하려면 Pessimistic Lock이 좋을 것 같다.

마지막으로, 이건 Pessimistic Lock을 적용한 결과이다.

📌 API Gateway의 편리한 uri 설정

현재 API Gateway의 라우팅은 이런식으로 설정되어 있다.

spring:
    gateway:
      routes:
        ############## RESERVE-SERVICE ##############
        ######## [reserve-service] REST APIs ########
        - id: reserve-service
          uri: http://localhost:9091 # 2) localhost:9000 말고 여기로 보내줌
          predicates: # 1) 여기로 접속 시도하면
            - Path=/v2/reserve/**

        ############## COMMON-SERVICE ###############
        ##### [common-service] Public Endpoints #####
        - id: common-service
          uri: http://localhost:9093
          predicates:
            - Path=/, /auth/**, /search, /store, /noti/**, /v1/auth/**, /v1/auth/**, /v1/store/**
          filters:
            - PublicFilter
        ###### [common-service] Member Endpoints #####
        - id: common-service
          uri: http://localhost:9093
          predicates:
            - Path=/member/**, /reserve/**, /v1/member/**, /v1/reserve/**
          filters:
            - MemberAuthFilter
        ###### [common-service] Manager Endpoints #####
        - id: common-service
          uri: http://localhost:9093
          predicates:
            - Path=/store/reserve/**
          filters:
            - ManagerAuthFilter
        ###### [common-service] Admin Endpoints #####
        - id: common-service
          uri: http://localhost:9093
          predicates:
            - Path=/store/registration
          filters:
            - AdminAuthFilter
        ########### static files ##############
        - id: common-service
          uri: http://localhost:9093
          predicates:
            - Path=/css/**, /js/**, /icon/**, /img/**

이러한 설정의 문제라면, 추후 포트가 바뀌면 사이드 이펙트 걸릴 확률이 높다는 점이다.

물론 테스트 과정에서 다 걸리겠지만 유지보수하기 보통 귀찮은게 아니다.

그럼 어떻게 하느냐? 사실 API Gateway는 Service Discovery에 등록된 서비스명으로 uri를 작성하는 것을 지원한다.

예를 들어, 이런식으로 수정할 수 있다.

spring:
    gateway:
      routes:
        ############## RESERVE-SERVICE ##############
        ######## [reserve-service] REST APIs ########
        - id: reserve-service
          uri: lb://RESERVE-SERVICE # 2) localhost:9000 말고 여기로 보내줌
          predicates: # 1) 여기로 접속 시도하면
            - Path=/v2/reserve/**

        ############## COMMON-SERVICE ###############
        ##### [common-service] Public Endpoints #####
        - id: common-service
          uri: lb://COMMON-SERVICE
          predicates:
            - Path=/, /auth/**, /search, /store, /noti/**, /v1/auth/**, /v1/auth/**, /v1/store/**

그래서 이번 프로젝트에서 Nginx 안쓰냐고 마르고 닳도록 들었는데, 쓸 필요를 못느끼겠다.

📌 latest 하지 않은 latest

1.0.0-beta.6을 릴리즈한 후, https 설정 때문에 먼저 http 쪽에 이상이 없는지 확인하려 했다.

근데 404가 떴다. ㅇㄴ

처음에는 docker network 환경을 의심했다. 라우팅 uri를 그냥 localhost라고 써놨으니...

아마 compose 스크립트를 조정해주면 될 것이라고 생각했다. 하지만 저 많은 route를 다 어떻게? 라는 의문이 들었다.

이를 알아보기 위해 이곳저곳 레퍼를 찾아봤는데, 결국엔 그냥 누가 깃허브에 올려놓은 코드에서 해답을 얻었다.

문법이 좀 특이하더라.

😉 응 전부 다 처음부터 다시 써

근데 그대로 적용하고 배포했을때 게이트웨이가 터져있길래 로컬에서 compose up으로 로그를 살펴보았다.

predicates가... 왜 날라간거지;?

(참고로 저게 locale을 따라가서 IDEA에선 한국어 로그를 띄워줌. 귀엽다 ㅋㅋ)

결국 이런식으로 노가다해주니까 터지진 않았다.

하지만 이 노가다를 쓰느니 그냥 로컬에서도 lb://~ 가 나은데 로컬 스크립트를 교체하는게 낫겠다.

그리고 얘도 테스트하니까 여전히 404였다.

services:
    api-gateway:
        environment:
            eureka.client.serviceUrl.defaultZone: http://service-discovery:8761/eureka
            SPRING_CLOUD_GATEWAY_ROUTES[0]_URI: lb://RESERVE-SERVICE
            SPRING_CLOUD_GATEWAY_ROUTES[0]_PREDICATES[0]: Path=/v2/reserve/**
            SPRING_CLOUD_GATEWAY_ROUTES[1]_URI: lb://COMMON-SERVICE
            SPRING_CLOUD_GATEWAY_ROUTES[1]_PREDICATES[0]: Path=/
            SPRING_CLOUD_GATEWAY_ROUTES[1]_PREDICATES[1]: Path=/auth/**
            SPRING_CLOUD_GATEWAY_ROUTES[1]_PREDICATES[2]: Path=/search
            SPRING_CLOUD_GATEWAY_ROUTES[1]_PREDICATES[3]: Path=/store
            SPRING_CLOUD_GATEWAY_ROUTES[1]_PREDICATES[4]: Path=/noti/**
            SPRING_CLOUD_GATEWAY_ROUTES[1]_PREDICATES[5]: Path=/v1/auth/**
            SPRING_CLOUD_GATEWAY_ROUTES[1]_PREDICATES[6]: Path=/v1/store/**
            SPRING_CLOUD_GATEWAY_ROUTES[2]_URI: lb://COMMON-SERVICE
            SPRING_CLOUD_GATEWAY_ROUTES[2]_PREDICATES[0]: Path=/member/**
            SPRING_CLOUD_GATEWAY_ROUTES[2]_PREDICATES[1]: Path=/reserve/**
            SPRING_CLOUD_GATEWAY_ROUTES[2]_PREDICATES[2]: Path=/v1/member/**
            SPRING_CLOUD_GATEWAY_ROUTES[2]_PREDICATES[3]: Path=/v1/reserve/**
            SPRING_CLOUD_GATEWAY_ROUTES[3]_URI: lb://COMMON-SERVICE
            SPRING_CLOUD_GATEWAY_ROUTES[3]_PREDICATES[0]: Path=/store/reserve/**
            SPRING_CLOUD_GATEWAY_ROUTES[4]_URI: lb://COMMON-SERVICE
            SPRING_CLOUD_GATEWAY_ROUTES[4]_PREDICATES[0]: Path=/store/registration
            SPRING_CLOUD_GATEWAY_ROUTES[5]_URI: lb://COMMON-SERVICE
            SPRING_CLOUD_GATEWAY_ROUTES[5]_PREDICATES[0]: Path=/css/**
            SPRING_CLOUD_GATEWAY_ROUTES[5]_PREDICATES[1]: Path=/js/**
            SPRING_CLOUD_GATEWAY_ROUTES[5]_PREDICATES[2]: Path=/icon/**
            SPRING_CLOUD_GATEWAY_ROUTES[5]_PREDICATES[3]: Path=/img/**

🙄 대체 뭐가 문제야

결국 9093번 포트 인바운드를 열어서 까봤는데, common-service 자체가 404였다.

...라우팅은 먹혔던 것이다.

404가 뜬다는 것은 타임리프 템플릿이 없다는건데 이게 CORS로 터졌을리도 없고 진짜 파일이 컨테이너 볼륨에 없을리도 없고

곰곰히 생각하다가 현재 배포된 이미지가 개발 초기 버전에서 업뎃이 안된걸수도 있겠다는 의심이 빡 들었다.

그리고 이 레퍼런스에서 똑같은 말을 하고 있다.

Best practice is generally to be explicit in your docker run and similar commands: use a unique tag for every image build (like a date stamp, source control commit ID, or build number), use that specific version/build number when you’re deploying, and don’t rely on things like the latest tag.

The trick here is that if you docker run someimage:latest, Docker first starts by looking at its local list of images. If it already has something with that exact name and tag, it just runs it; if not, it will implicitly docker pull first. This extends to higher-level orchestration systems too (you have to go fairly far out of your way to get Kubernetes to force it to reload an image, for example).

아. 뭔가 예전부터 컨테이너 버전 나눠야 하지 않나 하고 신경쓰였던게 시간 없어서 넘어갔는데 스노우볼이 되어서 돌아옴

수동 배포해보니까 서비스 잘 뜨더라.

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

그래서 수동 배포 스크립트를 급하게 만들까 말까 하다가, 그냥 CI를 1차적으로 고치기로 했다.

이상적인건 내가 요즘 자꾸 gradle에서 프로젝트 버전업을 까먹으니까 이걸 틀어막는거랑

옥토킷으로 커밋 파싱해서 자동으로 CI에 변경된 버전 반영하는건데...

시간이 없으니 릴리즈마다 CI를 같이 수정해주기로 하고, 버전 들어가는 부분을 따로 변수화해서 1차라고 칭하겠다.

그나저나 이거때문에 오늘 ELB 세팅 못함. 실화냐?