4주차

무엇을 했나?

본과제 진행
WebAPI 서버 만들기(계속)
코드 리뷰 받은 이후 코드 재설계 및 수정
기능 : 던전 스테이지

구현에서 고민되는 사항

코드의 깔끔함과 DB 커넥션의 최소화
- 테이블 마다 서비스를 만들어 놓으면 사용할 때 안헷갈리고 좋을 것 같다는 생각이 들었다. 하지만 여기서 놓친 것이 있었다. 테이블 마다 서비스를 만들어서 DB 커넥션을 맺으면, 1개로도 충분한 DB커넥션이 여러개가 되어 버린다. 그래서 전체적인 성능을 따져 봤을때 매우 별로인 구조였다.
DB 접근 실패에 대한 롤백을 어디까지 할 것이고 어디까지 할 수 있는가?
- 게임 서버에서는 트랜잭션을 사용하지 않는다. 트랜잭션을 사용하는 순간 DB서버의 부하가 너무 커져서 적절하지 못하다. 그래서 DB에 단일 요청을 보내고, 그 요청에 대한 결과를 확인한다. 실패시에는 롤백을 하여 이전에 변경시켰던 값을 다시 되돌리는 로직을 가져야 한다.
- 롤백으로 인한 DB접근 횟수가 많아질텐데 꼭 해야하나? → YES! 안하면 데이터의 불일치가 생길 수 있으니 무조건 해야한다.
- 그렇다면, 롤백을 실패한다면 어떻게 해야하나? → DB에 롤백 쿼리를 재요청할 수 있으나, 1,2초 후에 다시 하는 것이 아니면 큰 의미를 갖지 못한다. 하지만 서버에서 1,2초는 매우 큰 시간이기 때문에 이를 기다릴 수는 없다. 그렇기에 롤백 실패의 경우에는 로그를 찍어주는 식으로 처리하기도 한다.
- 참고로, 어떤 동료한테 들은건데, 웹 분야에서는 트랜젝션을 사용해서 에러 발생에 대한 처리를 해준다고 한다. 그래서 DB 명령 실패할 때마다 롤백을 위한 요청을 다시 보낸다는 것이 충격이었다고 한다.

회고

고민해야할 부분들이 정말 많다
- 위에서 말한 고민되는 사항처럼 두 가지 요인이 서로 상충효과를 주는 경우들이 있다. 상황에 따라 어떤 것에 우선순위를 둘지 정책을 결정해야하고, 그 기준은 명확해야 한다. 이와 관련해 기획문서나 코드에 주석으로 적어놓을 필요가 있다.
구현에 점점 더 욕심이 생긴다.
- 제시된 과제 내용대로만 구현하면 실제 게임에 비해서 너무 간단해서 게임 같지 않은 느낌이 들기도 한다. 그래서 그런 부분들에 조금이지만 살을 붙여보고 싶은 마음어 조금씩 덧붙이기도 했다. 서버너즈워를 플레이 해보면서 그 게임의 클라이언트의 장면에 맞춰서 상상하며 만들어봤다.
DB가 정말 중요하더라!
- DB 가 잘못 설계되면 그 DB와 관련된 거의 모든 코드를 수정해야 한다. 어려운 작업은 아니지만, 시간이 정말 오래 걸리는 작업이었다. 일단 해봐야 뭐가 보일 것 같아서, 기획 단계를 가볍게 여기고 구현을 했던 것 같다. 그리고 구현 중간 중간에 table스키마를 바꾸게 되었더니 시간이 오래 걸렸다. 처음부터 설계를 잘 하는 것이 중요하다.

Previous3주차 Next[5주차]

Last updated 2 years ago

구현에서 고민되는 사항

코드의 깔끔함과 DB 커넥션의 최소화

테이블 마다 서비스를 만들어 놓으면 사용할 때 안헷갈리고 좋을 것 같다는 생각이 들었다. 하지만 여기서 놓친 것이 있었다. 테이블 마다 서비스를 만들어서 DB 커넥션을 맺으면, 1개로도 충분한 DB커넥션이 여러개가 되어 버린다. 그래서 전체적인 성능을 따져 봤을때 매우 별로인 구조였다.

DB 접근 실패에 대한 롤백을 어디까지 할 것이고 어디까지 할 수 있는가?

게임 서버에서는 트랜잭션을 사용하지 않는다. 트랜잭션을 사용하는 순간 DB서버의 부하가 너무 커져서 적절하지 못하다. 그래서 DB에 단일 요청을 보내고, 그 요청에 대한 결과를 확인한다. 실패시에는 롤백을 하여 이전에 변경시켰던 값을 다시 되돌리는 로직을 가져야 한다.
롤백으로 인한 DB접근 횟수가 많아질텐데 꼭 해야하나? → YES! 안하면 데이터의 불일치가 생길 수 있으니 무조건 해야한다.
그렇다면, 롤백을 실패한다면 어떻게 해야하나? → DB에 롤백 쿼리를 재요청할 수 있으나, 1,2초 후에 다시 하는 것이 아니면 큰 의미를 갖지 못한다. 하지만 서버에서 1,2초는 매우 큰 시간이기 때문에 이를 기다릴 수는 없다. 그렇기에 롤백 실패의 경우에는 로그를 찍어주는 식으로 처리하기도 한다.
참고로, 어떤 동료한테 들은건데, 웹 분야에서는 트랜젝션을 사용해서 에러 발생에 대한 처리를 해준다고 한다. 그래서 DB 명령 실패할 때마다 롤백을 위한 요청을 다시 보낸다는 것이 충격이었다고 한다.

회고

고민해야할 부분들이 정말 많다

위에서 말한 고민되는 사항처럼 두 가지 요인이 서로 상충효과를 주는 경우들이 있다. 상황에 따라 어떤 것에 우선순위를 둘지 정책을 결정해야하고, 그 기준은 명확해야 한다. 이와 관련해 기획문서나 코드에 주석으로 적어놓을 필요가 있다.

구현에 점점 더 욕심이 생긴다.

제시된 과제 내용대로만 구현하면 실제 게임에 비해서 너무 간단해서 게임 같지 않은 느낌이 들기도 한다. 그래서 그런 부분들에 조금이지만 살을 붙여보고 싶은 마음어 조금씩 덧붙이기도 했다. 서버너즈워를 플레이 해보면서 그 게임의 클라이언트의 장면에 맞춰서 상상하며 만들어봤다.

DB가 정말 중요하더라!

DB 가 잘못 설계되면 그 DB와 관련된 거의 모든 코드를 수정해야 한다. 어려운 작업은 아니지만, 시간이 정말 오래 걸리는 작업이었다. 일단 해봐야 뭐가 보일 것 같아서, 기획 단계를 가볍게 여기고 구현을 했던 것 같다. 그리고 구현 중간 중간에 table스키마를 바꾸게 되었더니 시간이 오래 걸렸다. 처음부터 설계를 잘 하는 것이 중요하다.