[Economius, 이코노미어스] 개발 일지

10월 6일에 특화 프로젝트가 끝났다.

그동안 면접도 준비해야 했고 처음 진행하는 멀티 플레이 게임 프로젝트도 해야하고 정신없이 바빴던 것 같다.

최종합격은 결국 못했지만, 프로젝트도 열심히 하면서 최우수상을 수상했고 만족한다!

 

프로젝트를 진행하면서 세 가지가 기억에 남았고 간단하게 기록하려고 한다.

---

1. Web Socket

웹으로 멀티 플레이 게임을 구현해야 했기 때문에 웹 소켓은 우리 프로젝트의 주 기술이었다. 웹 소켓을 통해 게임을 구현하면서 대충만 알았던 웹 소켓을 한 번 정리하고 싶었다.

 

WebSocket?

1. 양방향 통신

하나의 TCP 접속에 전이중 통신 채널을 제공하는 컴퓨터 통신 프로토콜 즉, 서버와 클라이언트가 양방향으로 정보를 주고받는 애플리케이션 계층의 전송 프로토콜이다.

서버와 클라이언트가 양방향 통신 가능 -> 기존 HTTP 통신은 클라이언트의 요청이 있을 때만 서버로부터 응답을 받을 수 있지만, 웹 소켓은 connection이 연결되는 동안 클라이언트가 먼저 요청을 보내지 않아도 서버로부터 응답을 받을 수 있음

 

2. Stateful한 프로토콜

Stateless한 웹 소켓과 다르게 Stateful한 프로토콜이다. 클라이언트와 서버가 요청 때마다 매번 연결되고 끊는 비용이 발생하는 HTTP 통신에 비해, 웹 소켓에서는 한 번 연결되면 같은 연결을 이용해 통신하므로 커넥션 비용을 아낄 수 있다. 하지만 커넥션이 계속 유지되기 때문에 트래픽이 많아진다면 서버에 큰 부하가 발생하여 커넥션 유지 비용은 더 커진다.

 

동작 과정

처음 커넥션을 연결하려 할 때 HTTP 프로토콜의 Upgrade 헤더를 사용하여 웹 소켓 프로토콜로 업그레이드 하기 위한 핸드셰이크를 한다. 핸드셰이크 요청에 대한 응답으로 101 코드가 돌아오고 서버와 클라이언트가 연결된다.

 

 

개발 과정에서 마주한 문제

1. Socket 커넥션 유지

백엔드 신규 개발이 어느 정도 끝나서 프론트 프로젝트를 살펴보다가 socket 커넥션이 끊겼을 때 재연결을 하기 위한 처리가 되어 있지 않은 것을 발견했다.

이에 Promise 객체를 사용하여 connection 상태를 확인하고 연결이 되어 있지 않다면 재연결을 진행한 후 요청을 보내도록 수정하였다. 또한 연결이 끊겼을 때 이벤트를 감지하여 재연결하는 로직도 추가하여 연결이 끊겨 오류가 나는 상황을 최대한 방지하도록 했다.

 

2. Http Upgrade 헤더

나는 EC2 서버에 SSL 인증서를 적용하여 80번 포트로 들어온 요청을 Nginx가 443 포트로 리다이랙트 시키는 HTTPS 통신을 하고 있었다. 이 과정에서

Handshake failed due to invalid Upgrade header: null

위와 같은 에러 로그가 서버에 계속 찍히는 것을 발견했다.

에러가 찍히기는 하지만 정상 동작하고 있어서 무시하려다가 찜찜해서 알아보니 위 동작과정에서 살펴봤던 Upgrade 헤더가 없어 핸드셰이크에 실패했다는 에러였다.

좀 더 알아보니 엔진엑스에서 리버스 프록시를 이용할 때는 헤더 정보까지 전달되지 않기 때문에 명시적으로 Upgrade 헤더를 전달해주어야 하며, Upgrade 헤더를 전달해주는 설정을 한 후 에러는 해결되었다.

 

 

참고하고 싶은 내용

https://yozm.wishket.com/magazine/detail/1911/

https://velog.io/@myway00/Handshake-failed-due-to-invalid-Upgrade-header-null

https://velog.io/@msung99/%EC%9B%B9%EC%86%8C%EC%BC%93%EA%B3%BC-STOMP%EB%A5%BC-%ED%86%B5%ED%95%9C-%EC%8B%A4%EC%8B%9C%EA%B0%84-%ED%86%B5%EC%8B%A0-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

 

2. Synchronized

어느 날 프론트 팀원분이 여러 요청을 동시에 보내야 하는데 응답 결과가 예상한대로 돌아오지 않는다고 말했다. 특정 플레이어의 4가지 보험에 대한 가입 및 해지를 하는 요청과 응답에 관한 내용이었다. 

이 문제는 4가지 보험 가입 및 해지에 대한 요청을 배열에 담아서 한 번만 요청하고 서버가 이를 받아 한번에 처리하면 문제가 없었을 것이다. 하지만 한 개의 요청만 할 수 있는 API밖에 없었고 이를 4 번 동시에 요청하니 멀티스레드로 동작하는 스프링 애플리케이션에서 데이터 동시 접근 문제로 인해 문제가 발생했다.

 

3. ELK 스택

ELK 데이터 파이프라인을 구축했고 키바나를 통해 로그를 모니터링했었다.

게임은 정말.. 힘들었던게 일반 REST API 서버 개발과 운영에서 발생하는 것보다 훨씬 많은 오류가 발생했고 멀티 플레이 게임이었던 만큼 어지럽고 오류 원인과 어떤 플레이어로부터 발생한 오류인지도 파악이 힘들었다. 이러한 오류들을 EC2에 원격으로 접속해서 확인하려니 검색도 안되고 정리도 안되고 보기도 불편했다. ELK 스택을 적용하여 로그를 수집하고 시각화했는데, 로그 파악이 훨씬 편했다.