Main Subject
WebAPI ServerASP.NET CoreMain Subject
  • 과제 개요
  • 추가 학습
    • 샤딩 Sharding
    • Scale out / Scale up
    • 로드밸런싱
    • WSL
  • 구현
    • 계정생성
    • 로그인
    • 권한 확인(미들웨어)
    • 공지 등록 및 전송
    • 우편함
    • 출석부
    • 인앱 결제 아이템 지급
    • 강화
    • 던전 스테이지
  • DB 설계
    • MySQL
    • Redis
  • Coding Conventions
  • [회고]
    • 마음가짐
    • 1주차
    • 2주차
    • 3주차
    • 4주차
    • [5주차]
    • 마치며
Powered by GitBook
On this page
  • 무엇을 했나?
  • 구현에서 고민되는 사항
  • 회고
  1. [회고]

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