시연 동영상입니다. https://vimeo.com/manage/videos/873085666
- URL Shortner 서비스를 구현했습니다.
- 프론트엔드와 백엔드 모두 구현했습니다.
- Shortening key 알고리즘은 Base62, Short UUID, Adler Hashing을 사용했습니다.
- 추가적인 팀 미션으로 배포를 진행했습니다.
- 개인 미션으로 Redis를 활용한 캐싱을 구현했습니다.
- 개인 미션으로 Docker를 이용한 배포를 진행했습니다.(도커 네트워크 활용)
- URL 입력폼 제공 및 결과 출력
리액트로 구현했습니다. (링크)
- URL Shortening Key는 8 Character 이내로 생성
base62 방식으로 인코딩 완료
- 단축된 URL 요청시 원래 URL로 리다이렉트
상태코드 301(MOVE_PERMANENTLY)
- 단축된 URL에 대한 요청 수 정보저장
MySQL 이외에 Redis를 활용하여 캐싱했습니다.
- Shortening Key를 생성하는 알고리즘 2개 이상 제공하며 애플리케이션 실행중 동적으로 변경 가능
추가적으로 8글자 이내의 UUID, Adler 알고리즘을 사용하였습니다.
Redis는 서버가 다운될 것에 대비해 어느 정도 데이터를 백업해두는 기능을 갖고 있습니다.
하지만 완벽한 백업이 아니기 때문에 Redis에서 사용하는 캐싱 데이터는
다음의 조건을 만족하는 데이터에 사용하면 좋다고 생각합니다.
- 캐싱 했을 때의 성능(속도) 향상
- 손실되어도 괜찮은 데이터
URL Shortener서버는 Redis를 두 가지 용도로 사용 중 입니다.
- 리다이렉션으로 보낼 원본 url을 빠르게 찾기 위해
- 인코딩된 url의 총 click 수를 빠르게 저장하고 조회하기 위해
1️⃣
인코딩된 shortening key에 매핑되는 원본 URL은 자주 변경되지 않습니다.
그래서 RDB 저장소까지 가서 읽기를 수행할 필요가 없고 캐시 저장소를 통해
빠르게 요청을 처리하면 좋을 거 같다고 생각했습니다.
2️⃣
클릭 수(API요청 횟수)에 관한 업데이트는 1차적으로 Redis에만 진행되도록 했습니다.
그 이유는 클릭 수는 손실되어도 타격이 큰 데이터가 아니라는 생각을 했습니다.
물론 선착순 당첨 이벤트와 같이 특수한 상황에서 클릭수의 경우 정확도가 중요하겠고
마케팅 데이터로 활용할 클릭수는 어느 정도 의미가 있겠지만,
현재는 그런 특수한 상황이 아니라 배제했습니다.
3️⃣
속도나 동시성을 어느 정도 고려해주는게 좋다는 생각을 해서 Redis를 활용했습니다.
Redis는 싱글 스레드 방식으로 작동하기 때문에 동시에 여러 스레드가 접근할 경우
순차적으로 요청을 처리하게 되어 데이터 정합성을 보장하고
인메모리 데이터베이스라 속도 또한 보장하기 때문입니다.
4️⃣
1차적으로 Redis에서 업데이트된 클릭수는
매일 새벽 3시(트래픽이 가장 적게 몰릴것 같읕 시간)에
MySQL로 데이터를 업데이트 합니다. 이때 처리하는 방법은
@Scheduled(스프링 스케줄러)를 사용하였습니다.
5️⃣
클릭수에 관한 데이터를 다루는 방법으로,
Redis 서버가 다운 될 것을 고려해 MySQL에도 클릭수를 저장할까 생각했지만,
클릭수가 크게 중요한 데이터가 아니고 서비스의 본질은
긴 URL을 줄이는 것과 빠르게 원본 URL을 찾아주는 거라 생각해 배제했습니다.
6️⃣
Redis에 계속해서 캐시 데이터를 두게 되면 메모리 낭비가 심할거라 생각해
최근에 클릭한 데이터들에는 만료시간을 연장하는 알고리즘을 적용할까 생각했지만,
구현할 시간이 없어 패스했습니다!