🚨 RIOT API를 이용해서 롤 전적 검색 사이트 만들기 (3) - DB 구축 및 코딩

이번 포스트는 프로젝트 두번째 이슈 파싱한 데이터로 DB구축하기와 일부 세번째 이슈가 포함되어있다. 나는 라벨을 통해 미리 준비해야하는 부분을 Preparations로 개발부분을 feature로 구분하고있다.

---

유명한 리그오브레전드 전적 사이트를 클론코딩하여 프로젝트를 진행해보기로 했다. 혼자서 진행하는만큼 1차적인 목표는 간단히 아래와 같은 과정을 거치기로 했다.

• ✔️ Riot API를 인증
• ✔️ Jackson을 이용해서 Riot API 데이터 파싱
• 🔛 AWS RDS로 DB 설계 및 구축
• 🔛 Spring Boot를 이용해서 MVC 구조 만들기 (with mybatis)
• Vue를 이용해서 프론트를 구축
• EC2로 배포

🚨 RESTFUL Project 🚨 ⇢ RIOT API + Spring Boot + AWS EC2 & RDS

---

AWS RDS (MySQL) 생성

시간이 지나서 이 서비스가 계속 유지될지는 모르겠지만, 당장 몇개월동안은 서비스를 해고싶은마음에 AWS 프리티어를 이용해 DB 및 서버를 구성하기로 했다.

DB는 MySQL 8.0.16 버전을 사용하기로 했다. RDS를 생성하며 프리티어 설정에서 크게 바꾼것은 없고, 단순히 인코딩은 utf-8로 바꾸고 public access 허용과 보안사항에 대해서만 수정했다.

DB 설계

사실 DB를 설계하기에는 지식이 많이 부족하고 경험도 부족하다. 그래서 DB를 설계하기에 앞서서 다음과같은 의문점이 든다.

1. 클라이언트가 정보 요청시 데이터를 RIOT API에서 다이렉트로 제공해줘도 괜찮을까?

2. 다이렉트 제공이 맞다고해도 MVC구조 연습을위해 DB를 사용하고자하는데, 어떤 데이터를 넣어놓는것이 합리적일까?

그래서 OKKY에 질문을 동일하게 올렸다. 민감한 대답인지 내가 너무 두서없이 물어본건지 모르겠지만 답글이 하나도 안달렸다....

일단 제쳐두고 나름대로의 논리를가지고 DB를 약식으로 구성하기로했다. 일단 첫번째로 클라이언트에게 어떤 데이터를 보여줄것인가를 생각해보았다.

위는 웹 페이지에 들어가면 처음으로 맞이할 모습인데, 검색창에 소환사 닉네임을 쳐서 정보를 검색할 수 있는 형식으로 구상했다. 그리고 검색 버튼을 누르게 되면 기본적으로 다음의 정보가 나온다.

• 소환사 아이콘 + 닉네임
• 소환사 티어 + 아이콘
• 소환사 현재 게임 정보
• 소환사 전적 리스트
• 소환사 챔피언 숙련도 정보

그런데 사실 소환사 닉네임을포함해서 위에 나열한 모든것이 언제든지 변할수있는 내용이라서, 즉 실시간으로 데이터가 적용이 되어야하므로 DB에 저장하는것보다 API에서 가져오는것이 합리적이라고 느꼈다.

그러나 언제까지나 연습에 포커싱을 했기때문에 적어도 한가지 테이블에 대해서는 만들기로했다. 그래서 소환사 닉네임을 통해서 API로 부터 얻어온 소환사 정보를 DB에 구축하기로 했다. 로직은 다음과 같다.

1. DB에 암호화된 계정 ID가 존재하는가?
2. 존재하지 않는다면 RIOT API로부터 가져와서 저장하기
3. 만약 계정 닉네임이 변경되어서 정상적으로 검색이 안될경우, 저장된 암호화된 계정 ID를 통해서 변경된 닉네임을 파악하여 DB에 update 시키기

이렇게 사용자 정보에 대한 데이터만 DB에 일단 구축해놓고 나중에 필요시 추가하기로 했다.

코딩 (MVC)

먼저 Spring boot를 이용해서 REST형식으로 데이터를 뿌릴것이기때문에 RestController 밑에서 작업했다. 또한 maven 2.27 버전, jdk 1.8에서 진행했으며, 추가적인 dependency는 기본 jackson과 추가적인 mybatis, junit등을 넣어서 진행했다.

1. findByName

먼저 DB에 클라이언트가 요청한 소환사 정보가 있는지 확인한다.

controller

@GetMapping(value = "/summoner/{name}")
public ResponseEntity<Summoner> summoner(@PathVariable String name) {
    Summoner summoner = new Summoner();

    summoner = summonerService.findByName(name);	// 소환사 정보 조회
    if(summoner != null && !summoner.equals(null)) {
    	return new ResponseEntity<Summoner>(summoner,HttpStatus.OK);
    }
    return new ResponseEntity<Summoner>(HttpStatus.NO_CONTENT);
}

Summoner 객체를 하나 만들어서 소환사 이름을 통해 소환사 정보를 얻어오게 했다. 이후의 로직에는 큰 다른 점이 없어서 생략하고, SummonerMapper.xml에서 작성한 쿼리문을 확인해보자.

mapper

<mapper namespace="com.junho.mapper.SummonerMapper">

  <select id="findByName" resultType="com.junho.dto.Summoner">
    SELECT * FROM USR_INFO WHERE NAME = #{name};
  </select>
  
</mapper>

간단하게 SELECT문을 통해서 정보를 얻어왔다. id는 SummonerMapper.java의 메서드 이름과 맞춰주었고, resultType은 Summoner에 대한 DTO로 설정해주었다.

위에서 언급한바와같이 처음부터 DB에 넣어놓지 않을 생각이다. 따라서 DB에 없으면 주입해줘야하는 로직을 추가했다.

2. insertSummoner

controller

summoner = summonerService.findByName(name);	// 소환사 정보 조회
try {	
	System.out.println(summoner.getName() + " : DB에서 찾음");
	} catch(Exception e) { 	// DB에 없다면 API에서 소환사 정보 가져오기
		SummonerParser summonerParser = new SummonerParser();
		summoner = summonerParser.getJsonData(name);
		summonerService.insertSummoner(summoner);	// 소환사 정보 DB에 추가
	}
   }

findByName 아래에 다음과 같이 추가했다. 먼저 DB에 찾고자하는 정보가 존재하지않는다면 null Point Execption이 발생하는데, 이것을 '잘' 예외처리하는 방법을 몰라서 위와같이 예외를 처리해서 summoner 정보를 RIOT API로부터 가져왔다. (예외처리를 어떻게해야 잘했다고 소문날까요?)

그리고 DB에 다시 추가해주는 로직을 위해서 insertSummoner를 호출했다.

mapper

<insert id="insertSummoner" parameterType="com.junho.dto.Summoner">
  INSERT INTO USR_INFO VALUES(
  	#{accountId},
  	#{profileIconId},
  	#{revisionDate},
  	#{name},
  	#{id},
  	#{puuid},
	#{summonerLevel})
</insert>

findByName과 마찬가지로 같은 셋팅을 하였고, 다른점은 resultType이 없다는 점과 parameter로 넣어준 Summoner 객체를 인식하기위해서 parameterTpye을 Summoner DTO로 설정해주었다.

정리

이번에는 AWS RDS를 만들어서 테이블설계를 해보려고했다. 그런데 문제는 실시간이라는 점에서 혼란이 왔다. 게임의 소환사 아이디 정보도 매번 갱신 및 수정이 될테고, 전적리스트, 숙련도도 마찬가지로 갱신이 될것이다.

그렇다면 모든 데이터 정보를 RIOT API를 의존해야만 할까? 여기서 내가 생각한 방향은 이렇다.

1. 주기적으로 데이터를 받아온다
2. DB에 데이터가 없는 경우 RIOT API에 들어가 데이터를 가져온뒤, DB에 주입한다.
3. 애초에 DB에 들어가는 데이터는 정보를 제공해주는 사람의 가공된 데이터다.

그러나 1번은 비는 시간에 정확한정보를 전달하지 못한다는 점에서 애러사항이 있기때문에 가능성이 낮다고 생각했다. 그리고 3번 같은경우 유의미한 데이터를 만들단계는 아니라고 생각해서 2번을 채택해서 진행했다.

그럼에도 불구하고 여전히 RIOT API에서 다이렉트로 데이터를 받는 것이 정답이라는 느낌을 받는다. 그러나 MVC패턴 공부를 위해서라도 DB를 구축하기로 했기때문에 2번을 밀고 나갔다. 이렇게 또 한번 지식의 한계를 느끼며 더 공부해야겠다는 생각을 가지며 3편을 마무리한다.