Project : RainMind 개발일지 - 1 [기술 스택 선정과 개요]
포트폴리오 겸 개발내공 쌓을 겸 작은 프로젝트를 하나 해보기로 했다.
이름은 RainMind, 비가 오는 것을(rain) 알려주겠다는(mind) 뜻이다.
내가 학교 다니면서 비가 오는지 안오는지를 신경쓰지 않는지라 수업 갈때는 비가 안왔다가 올때 비가 내려서 편의점에서 돈을 주고 우산을 사거나 비를 맞고 오는 경우가 많았다.
그래서 이번 프로젝트를 해보면서 기상청 openAPI를 이용하여 사용자 요청 시 현재 강수 정보 및 풍속을 알려주고, 사용자가 일정을 등록하는 기능을 추가하여 현 시각 외에 미래의 다른 일정에서도 날씨 정보가 궁금하면 그 정보를 동일하게 띄워보는 기능을 구현하고 테스트 코드를 작성해보고자 한다.
요구 조건
- 지금 당장 서울대 지역의 현재 날씨(일정 임박 시) => 초단기실황조회 정보 사용
- 같은 날의 미래 일정 시각에서의 날씨 미리보기(사용자 요청 시) => 단기예보조회(현재로부터 3일치 예측날씨) 정보 사용
초단기실황조회 : DB나 Redis에 저장할 필요 없이, API 쏴서 바로 본다. 어차피 조회하는 순간 그 정보는 과거의 정보가 되고, 다시 꺼내보지도 않을 것이니까.
(사용 정보 : RN1 = 1시간 강수량(mm), PTY = 강수형태(0 = 없음, 1 = 비, 2 = 진눈깨비, 3 = 눈, 5 = 빗방울, 6 = 빗방울 눈날림, 7 = 눈날림), WSD = 풍속(m/s))
단기예보조회 : 사용자 요청 시, DB에서 저장한 것을 꺼내오도록 한다.
왜냐하면, 기상청 홈페이지가 다운되거나 Redis TTL이 만료되면 해당 정보는 유효하지 않는다. 무엇보다 날씨 예측은 시시각각 빠르게 변화하기 때문에 데이터를 캐싱해도 짧은 시간 내에 그것은 별로 쓸모가 없어질 확률이 높다.
속도 관점에서 캐싱이 좀 더 빠르긴 하지만, 어차피 많아봐야 3일간의 1시간 간격 예측데이터 일 것이므로 DB에 저장되는 정보는 수십개 수준에서 그칠 것이므로 DB 접근도 굉장히 빠른 편일것. 스키마 설계만 잘 해보자
(사용 정보 : POP = 강수 확률(%), PTY = 강수형태(0 = 없음, 1 = 비, 2 = 진눈깨비, 3 = 눈, 4 = 소나기), PCP = 1시간 강수량(mm), SKY = 하늘 상태(1 = 맑음, 3 = 구름 많음, 4 = 흐림), WSD = 풍속(m/s))
스택 선택
MySQL : 가장 표준적이다. NoSQL의 경우 유연한 데이터 저장에 효과적이라고 듣긴했지만 써보지도 않았고, 무엇보다 이번 프로젝트에서는 유저의 정보, 해당 유저의 일정 등을 정확하게(무결성) 저장해야 하기 때문에 데이터 간의 관계와 무결성을 잘 표현하는 관계형 DB를 선택.
Redis : 날씨정보 저장 자체에는 캐싱 효과가 거의 없지만, 알림 큐 관련해서 유용하게 쓰인다고 하는데 현재 이거 관련 내용은 잘 몰라서 이건 좀 더 알아봐야 할듯. 그리고 소소하게 user가 로그아웃 시 사용했던 토큰을 캐싱해서, 해당 토큰이 다시 접근해오면 요청을 차단하는 보안 이슈에도 사용할 수 있을듯.
설계
DB 스키마 : user, user 일정 정보, location, 단기예보 저장 테이블 / index 제약은 설계 확정 시 추후 업로드. 검색속도 향상을 위한 index 도입 검토
API : user login, logout, 초단기실황조회 api, 일정추가, 일정삭제