1주차 Troble & Troubleshooting

🚀 기획단계

📌 유니티에도 서버와 클라이언트가 있다. 보통 포톤 클라우드를 서버로 두는데 무료 계정은 20 CCU(Concurrent connected User, 동시접속자)밖에 지원안해준다.

• 20명씩 여러 방을 만드는게 가능한가?

👉 무료 계정은 불가능 / 다만, 20명이 있는 방을 또 나눌 수는 있음

📌 포톤 클라우드는 DB와 연결이 불가능하다. Unity는 DB와 연결이 가능하지만 local이기 때문에 보안상의 이슈가 있다. 따라서 서버에 저장을 해줘야 하는데 우리 프로젝트는 모바일이 유니티가 아니다. 문제는 유니티에서 만든 3D 캐릭터 모델과 애니메이션을 모바일에서도 보여주려고 하는데 3D 모델은 OBJ파일로 저장하여 JSON으로 전환가능하나 애니메이션까지 포함하면 FBX파일로 저장되며 이를 Android(자바 컴파일러)에서 바로 사용할 방법이 없다.

✅ 3D 캐릭터 모델만 사용하는 대신 안드로이드 모션을 추가하기로 했다. => 캐릭터의 애니메이션이 들어가 있는것 처럼 보이기

• 저장은 어떻게 해야할까? Unity에서 만든 파일을 ec2의 s3에 저장해두고 사용하는게 맞나? 파일의 변동사항이 필요한 경우는 어떻게 해야할까?

• 유저의 자율성을 주는게 가능한가?

👉 모바일에서 OBJ파일을 JSON으로 수정할 방향으로 잡고 있다. 이렇게 되면 저장공간에 저장된 OBJ파일의 주소값을 DB에 저장해 두고 있다가 API가 호출될 때, 파일전환을 통해 모바일 화면에 3D 케릭터를 띄울 수 있다.

📌 DB의 부하를 줄일방법

👉 로그아웃 관련 JWT refreshtoken은 Redis를 사용한다.

• 참고: [ Redis가 사랑받는 이유 ]

👉 MSA (MircroService Architecture), spring cloud, eureka 사용

[ 배민 API GATEWAY – spring cloud zuul ]

[ MSA 와 DDD ]

👉 Master, Slave DB

[ DB : Master & Slave 개념에 대해 알아보자 ]

📌 배포 시 유니티, 모바일, 워치가 한꺼번에 중단이 되지 않았으면 한다. 유지보수 및 협업, 특히 아주 작은 수정이 일어나도 전체 서비스를 재기동 해야 하는 단점

👉 MSA (MircroService Architecture) 사용

• 참고:
  [ MSA란?(등장배경, 특징, 장단점) ]
  [ MSA 제대로 이해하기 ]

• 스프링 클라우드: https://spring.io/projects/spring-cloud
  [ 스프링 클라우드 ]
  [ 서비스 디스커버리 Spring Cloud Discovery , eureka ]
  [ Spring Cloud Gateway를 이용한 서비스 라우팅 및 JWT 토큰 검증 ]

• 코드참고: [ Spring Cloud - Eureka, API Gateway ]

📌 MSA 사용시 swagger가 다 다른 주소가 되나?

👉 Spring restDocs와 Swagger UI 조합

• 참고: [MSA 환경에서 API 문서 통합 관리]

📌앱과 유니티에서 accesstoken을 reissue했을 때의 문제점 (다중 디바이스 로그인)

• 만약, 앱과 유니티를 함께 사용할 경우 앱에서 토큰이 만료되어서 새로 발급받는다면 유니티에서는 예전 토큰을 가지고 있으므로 authorization 관련 에러가 뜰텐데

👉클라이언트 타입을 HTTP 헤더에 요청하기

JWT 토큰을 여러 디바이스에서 동시에 로그인하려면, 클라이언트 타입(웹, 모바일, 유니티 등)에 따라 토큰을 생성하고 관리하는 방법을 사용할 수 있습니다.
다음은 이를 구현하는 방법 중 하나입니다:

• 디바이스 정보를 요청에 포함시키기: 로그인 요청 시 클라이언트가 어떤 타입의 디바이스에서 오는지 정보를 함께 보낼 수 있습니다. 예를 들어, HTTP 헤더나 별도의 필드로 이 정보를 추가할 수 있습니다.
• 토큰 생성 시 디바이스 정보 포함하기: JWT 토큰은 일종의 JSON 객체로서 여러 가지 정보(payload)를 담을 수 있습니다. 따라서 서버에서는 로그인 요청 시 받은 디바이스 정보를 이 payload에 포함하여 토큰을 생성합니다.
• 디바이스별로 토큰 저장 및 관리하기: 서버는 각각의 디바이스 타입별로 생성된 JWT 토큰들을 관리해야 합니다. 예를 들어 데이터베이스에 사용자 ID와 함께 해당 ID가 발급한 각각의 장치별 JWT 토큰들을 저장할 수 있습니다.
• 요청 검증 시 디바이스 확인하기: 서버가 요청을 받았을 때 해당 요청의 JWT 토큰과 HTTP Header 혹은 다른 방식으로 전달된 장치정보가 일치하는지 확인합니다.
  위와 같은 방식으로 구현한다면, 동일한 사용자가 다른 장치에서 로그인 할 경우 각각 다른 JWT토큰들을 발급 받게 되며 서버는 이들 갱신 혹은 만료 등 상태관리도 개별적으로 할 수 있게 됩니다.

👉 자세한 사항은 [ 다중 디바이스 동시 로그인과 JWT TOKEN (1) ] 에서 확인한다.

✅ 최종 결정: Sec-Ch-Ua-Platform

📌 유니티와 워치는 서버 간의 통신 시에는 일반적으로 브라우저가 사용되지 않기 때문에 Sec-Ch-UA-Platform과 같은 브라우저 관련 HTTP 헤더는 사용되지 않는다. 그렇다면 웹, 유니티, 모바일, 워치인지 서버에서 확인하는 방법은?

✅ 먼저, http 헤더의 Sec-Ch-Ua-Platform을 읽는다. Linux, Windows, mac OS, Chrome OS 이면 웹이라 판단하고 accesstoken값과 refreshtoken쌍을 발급한다. Android의 경우 모바일이라고 판단하고 accesstoken값과 refreshtoken쌍을 발급한다. null 값이면 unity라고 판단하고 accesstoken값과 refreshtoken쌍을 발급한다. token이 필요없는 워치의 경우 api를 따로 지정하여 apigate에서 filter를 미적용하도록 한다.

• 참고: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-CH-UA-Platform