[BE / 문제 정리] 개선해야 할 문제점 정리

[Tae-Hyeon]

현재 당장 고치기는 힘들지만 인지하고 넘어가야 할 문제점들을 정리합니다.

[Tae-Hyeon]

소켓 인증 문제

• 유저에 대한 소켓 인증을 연결 후 메세지에 인증 토큰을 보내서 인증을 하는데, 보안적으로나, 연결이 무조건 이루어져야 하고, 단순 소켓 연결만 했을 경우 이 소켓 연결이 유효한 사람인지 판단을 못합니다.
• 단순히 소켓을 누군가 많이 연결한다면 이를 막을 수단이 없습니다.
• 소켓 인증에 대한 이슈
  • https://velog.io/@tlatldms/Socket-%EC%9D%B8%EC%A6%9D-with-API-Gateway-Refresh-JWT
• 소켓 + STOMP + 인증
  • https://velog.io/@tlatldms/Spring-Boot-STOMP-JWT-Socket-%EC%9D%B8%EC%A6%9D%ED%95%98%EA%B8%B0

[Tae-Hyeon]

로드 밸런싱

• 스프링 클라우드 넷플릭스 유레카 (서비스 디스커버리)
• 현재 사용하고 있는 로드 밸런싱 방식은 라운드로빈 방식입니다.
  • 라운드 로빈에 따라 단순히 연결만 순서대로 분배할 뿐이라서 어느 서버에 트래픽이 과도할 경우에도 해당 서버에 연결을 하게 되는 문제가 발생합니다.
• 로드 밸런싱 방식을 따로 설정할 수 없는 문제가 있습니다.
• 로드 밸런싱 알고리즘 기본 종류
  • https://its-fusion-blog.tistory.com/50
• 소켓 연결의 경우 게이트웨이를 거치지 않고 직접 연결하는 것이 좋고, 로드 밸런싱을 위한 연결을 관리해줄 서버가 따로 있는 것이 좋다고 합니다.

[Tae-Hyeon]

로비 서버 웹 소켓 기능 관련 이슈

• 개인적으로 웹 소켓만을 사용하여 발생하는 문제가 있습니다.
• Failover
  • 연결이 끊겼을 경우 복구할 수단이 따로 구현하거나, 재연결 밖에 없습니다.
• Broadcasting
  • 서버 내의 특정 방에 브로드캐스팅 할 경우 직접 구현해줘야 하며, 동기화를 맞춰줘야합니다.
  • 직접 구현하기 때문에 오히려 비효율 적인 처리를 하게 됩니다.
• Pub/Sub 알고리즘
  • 현재 Pub/Sub 알고리즘은 RabbitMQ를 하여 fanout하게 전체 서버로 메세지를 전송하고, 메세지의 내용을 토대로 Key 값을 검색하여 해당사항이 있을 경우에 이벤트를 처리합니다.
    • topic 큐이긴 하지만 결론적으로 방마다의 고유한 id로 분배하는 것이 아니라 하나의 topic을 사용하기 때문에 fanout이랑 다를 게 없습니다.
    • 이렇기 때문에 전체적으로 Key를 통한 조회가 들어가게 되어 메모리 누수와, 서버 트래픽이 증가합니다.
    • STOMP를 사용한 Pub/Sub은 특정 id를 통해 RabbitMQ의 큐를 동적으로 생성, 삭제하고, 원하는 서버에서만 해당 큐를 Subscribe 하여 사용하기 때문에 필요 없는 작업을 하지 않아도 됩니다
• Spring Cloud Stream을 이용하면 해결이 가능할 것 같다.
  • https://www.baeldung.com/spring-cloud-stream

[Tae-Hyeon]

결제 서버

• 충전, 게임 구매 로그 관련
  • 충전과 게임 구매 로그가 따로 나뉘어져 있습니다.
  • Billing 시스템을 만들고 로그를 쉽게 관리하기 위해서는 로그의 통합이 필요합니다.
  • 로그의 기본적인 내용인 비슷하기 때문에 통합하기에는 오래 걸리지 않을 것 같습니다.
• Billing 시스템 개발
  • 유저의 잔액을 확인하거나, 구매 기록을 확인하는 부분을 위해 Billing 시스템을 분리하여 개발할 필요가 있습니다.
• 예외 처리
  • 결제 서버에서 예외 처리를 모두 throw를 던지고, ExceptionHandler를 통해 받아 처리하고 있습니다.
  • 단순한 예외 상황의 경우 Error Response를 직접 return하는 것에 비해 10%정도의 속도 차이가 있습니다.
  • 꼭 throw가 필요한 상황에서만 던지도록 처리할 필요가 있습니다.

잠금에 따른 속도 저하

• 금액이 변동되는 사항을 따로 기록하고 일괄적으로 적용하면 잠금이 필요하지 않다?
• 로그를 쌓는 식으로 한다면 어떻게 할 것인가?
  • Redis에 구매에 대한 기록을 추가시키고 MySQL에 마이그레이션
  • 파일 I/O를 통해 저장하고 일정 시간마다 일괄 저장
    • Batch, Buffer식 파일 입출력
• 주문과 결제 로직을 분리 하는 방법도 있다.
  • 소프트웨어를 구매하는 것이기 때문에 굳이 나눌 필요를 못느꼈지만, 나눠서 처리하면 잠금보다 빠르면서 순서도 맞춰줄 수 있을 것 같다.

[Tae-Hyeon]

상태 관리 서버

• 상태 관리를 Redis를 이용해 하고 있는데, 이를 통합적으로 관리해 줄 서버가 필요합니다.
  • 분산 락을 통해 동시성 처리를 해주었지만, 서버를 통해 처리할 필요가 있습니다.
  • 방식은 Socket 과 TCP를 이용하는 방법이 있습니다.
    • Spring Integration을 통해 쉽게 구현이 가능합니다.
    • 내부적으로 Netty, NIO와 Socket을 사용합니다.

[Tae-Hyeon]

swagger 적용 및 통합