hackerton :: shorturl "해줘"

https://github.com/Kernel360/hackerthon1-doitfor

GitHub - Kernel360/hackerthon1-doitfor: shortURL을 만들어주는 서비스입니다.

개요

최소한의 기술적 완성도를 가진 결과물을 단시간에 만들어 자신의 기술력을 파악, 빠른 학습의 대한 경험을 습득

프로젝트를 진행하며 코드의 품질과 기술적 협업 등을 이해하자.

 

프로젝트 목적, 목표

사용자가 원하는 url을 줄여 짧게 만든 url을 제공해준다 !

 

플랫폼 목표

- 1일 1억건 (100M / 24H / 3600s, 초당 약 1천개)을 감내 할 수 있을 정도의 로직을 구성한다.
- 해시 생성 후 해시 충돌 회피 전략 구성을 고려한다.
- 플랫폼을 다분할로 운영 할 시 PK값 유일성을 보장하는 방안을 고려한다.
- 배포서비스를 구축한다.

주요기능

사용자가 요청한 http, https url을 짧게 가공하여 제공한다.

 

기술스택 및 선정 사유

- 타임리프 : jsp에서 사용 가능한 jstl을 주로 사용하여 생소한 타임리프를 써보고 싶었고, 배포편리를 위해 jar 사용을 위하여 사용 결정

- 스프링부트 2.8 : 스프링부트 3.0부터는 스프링프레임워크가 6.0으로 업데이트되므로 협업하는 팀원들에게 친숙한 2.8을 사용

- 스프링JPA : 평소 mybatis만 사용해서 이번 기회에 jpa 입문을 위해 사용하기로 결정.

- MYSQL5.7 : 짧은 개발 시간내 db를 설정하는 시간 투자를 줄이고자 낮은 버전 사용.
                       최신버전은 root계정의 password가 랜덤하게 생성되어 이를 찾는 과정 필요.

- gradle : maven을 주로 사용해보았기 때문에 새로 사용해보는 gradle 사용 결정

- 구름IO : aws ec2를 알기 전, 입문으로 사용. 

- sha-256 : 해싱알고리즘은 무수히 많으나, 가장 대중적인 알고리즘을 사용하기로 결정.

대중적인 기술스택 사용의 최대 장점은 이슈가 발생시 해결방안을 보다 빠르게 찾을 수 있습니다.

 

기여도

1)기여 한 부분

- 구름IO를 이용한 서버, DB 구축

- 성능테스트 방향 가이드 작성

- 배포정책 작성

- 개발 단계를 나누어 목표 설정 (알파 : 최소기능 수행, 베타 : 알고리즘 로직 개선, 사용자 사용성 개선)

 

2)노력한 점

- 클라우드 서버, 도커라는 개념이 생소하여 이의 대한 이해를 위해 학습하고 프로젝트에 적용

- 맨토님의 맨토링을 들은 후 해싱 알고리즘을 어떻게 적용 할 것인가? 의 대한 토의

 

3)성과

- 목표에 비해 퀄리티는 떨어졌으나 시연 성공

- 코드를 개선하여 이론상 준비가 되었다 판단되면 서비스 오픈까지 고려 할 수 있음.

 

 

회고

1)진행소감

- 설계시 생성 된 단축url 값에 대한 보존 정책 미흡으로 개발 방향 방황

- 컴퓨터 과학지식과 비즈니스 플랫폼 수준으로 목표를 올리면 매우 다양한 방면으로 고민하고 알아야 할 지식이 많아야 함을 느낌. 단순히는 db에 insert,select 하는 과정으로 끝나고 관점에 따라 db조차 필요없이 간단히 구현 가능하지만 비즈니스 플랫폼을 목표로 관점을 바꾸면 고민해야 할 부분이 엄청나게 많았음 (통신비용을 줄이기 위해 select insert 과정을 insert 과정만으로 줄이기, db에 저장되는 데이터의 무결성 보장을 위해 완전 무결한 id 생성을 하는 방법, 비회원 회원 각각 url 저장하는 로직 분리 등)

- 프로젝트 시연 전 사용자 테스트를 통해 미흡한 부분을 처리했어야 했으나 로직 고민으로 시간을 다 보내 이 부분을 놓침.

 

2)배우고 싶은 점

- 해싱 알고리즘과 twitter snowflake 또는 해싱 + salt를 통해 db를 해시테이블로 구축했을 때 변환된 url을 split하여도 완전무결성한 id를 만들고 url을 보존하는 방법 (URL 보존 정책에 따라 저장 관리가 달라질 것이라 생각듭니다.)

ID	CONVERT_URL	ORG_URL	REGIST_DT	UPDATE_DT
생성된 완전무결 ID	해싱된 URL	원본 URL	등록일	수정일

- 완전 무결성한 짧은 url 보존이 불가능 할 경우, 해시 충돌이 발생하였을 때 회피하는 방법론 및 프로그램에 적용하는 방법

- 해싱 알고리즘 종류별 아키텍트 관점에서 장점, 단점 이해

 

3)추가하고 싶은 점

- 사용자가 요청시 url의 앞단을 확인하여 누락되어있으면 추가해주는 작업

- 사용자가 요청시 원본 url의 대한 validation 기능 보강 (너무 긴 문자의 경우 부정확)

- 동일 주소에 대해 지속적 url 단축 요청시, 키 생성 및 데이터 등록 과정에서 충돌이 발생 할 경우 이의 대한 재귀처리 및 재시도, 실패의 대한 예외처리 및 안내 view 처리

- db의 축적된 데이터가 많을 때, 특정 도메인을 포함한 url 요청시 도메인과 querystring을 분리하여 각자 해싱, 저장하여 조회 속도 개선 (ex : www.naver.com/asdf  요청이 왔을 시, naver.com 과 asdf 를 각자 해싱하여 각 필드에 저장)

- 실제 서비스와 유사한 환경을 구축 후 nGrinder 같은 테스트 툴로 성능 테스트 진행