사이드 프로젝트하면서 한 고민 여러가지

마이크로서비스 API 분리 OR 통합?

상황은, Member 엔티티와 Point, Coupon 엔티티가 서로 다른 마이크로서비스에 속해있다. 그런데...

만약 이런 화면이 있다면? 그러니까, Member 정보, Point 정보, Ticket 정보 모두가 필요한 화면이 있을 때 API를 어떻게 구현해야 할지 고민이다. 

1. Member 마이크로서비스에서 Point, Ticket 쪽 서비스에 요청해서 데이터를 가져와 모두 합쳐서 한 번의 API로 리턴
2. 프론트 쪽에서 각각 Member, Point, Ticket 쪽에 3번 조회 요청을 보냄

1번은 Member 마이크로서비스에 Point, Ticket 관련 DTO들을 중복해서 생성해줘야하는 게 번거롭다. 그것 말고는 딱히 단점이 생각이 안 나네. 

2번은 하나의 화면에 있는 정보를 조회하는 건데 API가 세 개로 찢어져있으니까 파악하기도 어렵고 어지러운 느낌이다. 문서화도 어떻게 해야할지 모르겠고. 

 

성능상 이점은? 1번은 한 번의 API 호출로 모든 데이터를 받을 수 있으니까 네트워크 오버헤드가 적을 것이고. 그대신 마이크로서비스간 통신이 필요해서 지연시간이 발생해서 응답시간이 더 느려질 수도 있음. 

2번은 뭐... 그냥 교과서적으로 읊자면 한 서비스 지연이 다른 서비스에 영향을 주지 않고, 독립적이고 뭐시기. 단점은 네트워크 오버헤드. 

 

일단은 그냥 1번 방식으로 구현하긴 했는데. 모르겠다.

 

---

AWS 서버 비용 줄이는 법

아직 사용자 0명인데 저번 달에 무려 비용이 9만원이나 나왔다. 

지금 서버 스펙은:

• EC2 t2.small(메모리 2GB)
• RDS 프리티어 짜리 2개

그런데 EC2가 프리티어가 아니라 t2.small로 업그레이드 한 건데도 메모리 부족하다고 서버가 자꾸 죽어서. 스왑 메모리를 늘렸다. 무서워서 권장량(메모리의 2배)만큼은 못 늘렸고 2GB로 설정했다. 그 이후로 2주 정도 지난 것 같은데 확실히 줄어들긴 했다. 메모리 부족해서 꺼진 적은 없는 것 같다. 

 

RDS는, 사실 2개일 필요도 없기도 하고 그래서 팀원이 EC2에 도커로 설치했다. 이렇게 EC2 하나에 몰빵해도 되나 고민했는데 아직 작은 서비스니까 괜찮을 것 같다. 

 

코드 수준에서도 할 게 있나 고민해봤는데 이펙티브 자바에서 최적화는 웬만하면 하지 말라(기억안남)고 했던게 생각나서 안 하기로 했다. 사실 지금은 기능 구현이 우선이기도 하고. 

 

그리고 프로젝트가 마이크로서비스라서 더 나오는 것도 있다. 사실 난 웬만큼의 대규모 서비스가 아닌 이상 마이크로서비스는 득보다 실이 많다고 생각하는 입장이긴 한데 프로젝트 들어왔을 때 이미 마이크로서비스로 상당히 진행되어 있어서 어쩔 수 없었다. 모놀리틱이면 서버 하나만 띄우면 되는데 마이크로서비스니까 2개(API Gateway, Discovery)가 더 돌고 있으니. 내가 보기엔 배보다 배꼽이 큰 격이다. 그래도 어쩔 수 없지.

 

---

로그 관리

회사에서는 로그 관리를 이렇게 한다.

1. HTTP 요청, 엔드포인트, 요청 바디, 요청 시각, 실행된 쿼리 전문 (+에러도 포함)(입력값 마스킹함)
2. HTTP 요청, 엔드포인트, 지연시간, 응답시간(응답하는데 걸린 시간), 응답코드, 요청 시각

로그 파일이 이렇게 두 가지로 분류해 관리한다. 우리 프로젝트도 이런 식으로 하면 되려나. 더 추가할 건 없나? 

 

그리고 로그 파일 용량도 상당히 디스크 많이 차지해서, 디스크 부족하다고 연락 오면 두 달 지난 로그는 다 지우는데. 이걸 자동으로 해주는 모듈이 있어서 좋긴 하더라(pm2 logrotate).

 

또 뭐있지. 로그 관리 저렇게만 하면 되나 싶다. 검색해보니 우아한형제들도 loki라는 거 쓴다고 하고(뭐가 좋다는 건지 읽어봤는데 하나도 이해 못 함). 운영할 땐 우리도 loki 써봐야겠다고는 생각함.

 

예외 트레이스는 어떻게 할지 고민이다. 운영 환경에서는 아예 제외하는게 일반적이라고는 하던데, 나는 좀 무섭다. 쓸데없는 게 대부분이긴 하지만 그래도 예외 발생 지점을 못 찾으면 어떡하나 싶고. 개발환경에서는 트레이스 다 출력하게 하고, 운영 환경에서 예외가 발생했는데 원인을 찾을 수 없으면 입력값 똑같이 개발환경에 들고 가서 테스트하면 되려나?

https://kim-jong-hyun.tistory.com/112

[Spring] - e.printStackTrace() 보다 StackTraceElement로 로깅하기

이 글 보고 따라해야겠다. 

 

+ 마이크로서비스 환경에서는 각 서버에 분산되어 로그가 찍히니까 같은 요청에서 비롯된 로그인지 식별할 수 없는 문제가 있다. 그래서 sleuth로 하면 된다고 하길래 의존성 추가해봤더니 스프링부트 버전 3부터는 지원이 안 된다고 해서 아래 의존성을 추가했다.

implementation 'io.micrometer:micrometer-tracing-bridge-brave'

이거 하고 yml 파일에 설정 복붙했더니 traceId 뜨더라. 빨리 끝나서 좋다.

 

---

법정동 데이터 어디서 다루지?

지역에 따라 해당 지역에 있는 시설 필터링해야하는 기능이 있는데 모든 법정동을 서버에 저장해두고 프론트에 줘야 할지, 아니면 앱에서 매번 오픈 API 요청해서 조회해올지 고민했고 팀원들과도 상의했다.

 

그래서 개발자인 오빠한테 물어봤더니:

• 데이터는 무조건 서버가 관리하는 게 맞음
• 특히 앱은 하나 수정하면 스토어에서 심사받고 배포하는데까지 시간 걸리고 기존 버전은 아예 수정 불가능
• 비즈니스 로직에서 특정 동은 제외하는 이슈 생기면, 서버의 경우 서버만 업뎃하면 되는데 클라 쪽은 앱, 웹 자체적으로 여러 번 전부 수정해야 함

이 의견을 듣고 납득이 돼서 서버 쪽에서 하기로 결정했다. 

 

그런데 법정동도 주기적으로 바뀌는데, 그걸 서버에 매번 업뎃해줘야하긴 하지만... 그렇게 자주 있는 일도 아니라 괜찮을 것 같다. 이것도 자동화할 수는 없나?