ShortURL

https://shorturl.bombs.kr

단축 URL 생성 및 리다이렉션 서비스입니다.

목차

• 사용 기술
• 주요 기능
• 아키텍처
• 요청 흐름
• 실행,배포 방법
• tl;pr(Too Long;Please Read)
  • 학습 성과
  • 백엔드 컨벤션
  • 단축 URL 생성 전략
  • Redis 캐시 구성과 전략
  • 리다이렉션을 302로 하는 이유
  • 계층형 리버스 프록시 구조로 설계한 이유

사용 기술

목차로

컴포넌트	기술	비고
Backend		Java 21, Spring Boot 3, Spring Data JPA, Flyway
Frontend		React 19, Nginx
Cache		DB 부하 감소와 빠른 응답을 위해 Redis 사용
Database		트랜잭셔널 마이그레이션을 위해 PostgreSQL 사용
Gateway		경로에 따라 요청을 프록시하기 위해 Nginx 사용
Infrastructure		환경 일관성과 유지보수용이성, 리소스 격리를 위해 Docker를 사용 OCI free tier 이용

항목	비고
인스턴스	OCI VM.Standard.E2.1.Micro
CPU	1/8 OCPU (8인스턴스가 공유하는 1코어)
RAM	1GB
Swap	2GiB

주요 기능

목차로

• 단축 URL 생성: URL을 입력하면 같은 목적지를 향하는 짧은 URL을 만들어줍니다. 같은 URL에 대해 여러 단축 URL을 생성할 수 있습니다.

• URL 리다이렉션: 단축 URL로 들어오는 GET 요청을 원본 URL로 리다이렉트합니다.

• 단축 URL 모아보기: Google/Naver OAuth2를 통해 회원으로 로그인하면 생성했던 단축 URL을 모아볼 수 있습니다.

아키텍처

목차로

각 노드의 역할

1. 리버스 프록시 서버: 브라우저의 HTTPS 요청을 복호화하여 게이트웨이 서버로 프록시합니다. 소스는 별도의 reposiory 에 있습니다.
2. 게이트웨이 서버: 요청 경로에 따라 요청을 내부 서버로 프록시합니다.
3. 프론트엔드 서버: React로 구성된 브라우저에게 정적 파일을 제공합니다.
4. 백엔드 서버: 게이트웨이 서버로부터 요청을 프록시받고 이를 처리합니다.

요청 흐름

목차로

단축 URL 생성

1. 브라우저는 게이트웨이를 통해 프론트엔드에 요청하여 응답을 받고 화면을 렌더링합니다.
2. 브라우저는 사용자 입력값을 받아 {frontendUrl}/api로 POST /api/shorten 요청을 보내고, 이는 게이트웨이에 의해 백엔드로 프록시됩니다.
3. 백엔드는 요청을 전달받고 단축URL의 경로가 될 ID를 생성하고 그 ID를 Unique Key로 하여 DB에 저장을 시도합니다.
4. 저장에 성공하면 생성된 ID 앞에 baseUrl을 붙여 단축URL을 완성하고 응답을 보냅니다.
5. 브라우저는 응답 받은 shortenedUrl을 사용자에게 보여줍니다.

단축 URL 조회

1. 사용자가 브라우저에서 단축 URL로 접속함으로써 게이트웨이를 거쳐 Backend로 GET /{Base62EncodedKey} 요청을 보냅니다.
2. Backend에서는 먼저 Redis 캐시에서 해당 값을 찾고, Cache Miss의 경우 DB를 조회합니다.
3. 만약 DB에서 값을 찾았다면 해당 값을 Redis에 캐싱하고, 원본 URL을 향해 302 Found 상태 코드로 리다이렉트합니다.
4. 만약 DB에도 찾는 값이 없다면 404 Not Found 상태 코드로 응답합니다.
5. 브라우저는 응답에 따라 원본 URL로 접속하거나 404 페이지를 띄웁니다.

실행, 배포 방법

목차로

개발(로컬)환경

호스트를 향하는 도메인이 있을 것을 전제로 프로젝트가 구성되어 있습니다. hosts 파일을 적절히 수정하시는 것을 권장합니다. compose.dev.yml에 해당 내용이 있습니다.

.env.example을 참고하여 .env.development를 작성한 후 다음 명령을 실행합니다.

docker compose -f compose.yml -f compose.dev.yml --env-file .env.development up -d --build

backend는 recompile시 핫리로드됩니다. (바인드마운트+springBootDevtools+bootRun)
frontend는 파일 저장시 핫리로드됩니다. (바인드마운트+next dev)

배포환경

이 repository에는 리버스프록시 서버가 포함되어있지 않습니다. 이걸 배포하려면 gateway의 설정을 적절히 변경하거나 리버스프록시 서버를 구성하여야 합니다.

운영 환경값은 .env.production 파일로 배포하지 않습니다. GitHub Actions의 Variables와 Secrets에 등록하고, Compose는 배포 시점의 환경변수에서 값을 읽습니다.

GitHub Actions Variables에 등록할 값:

• SPRING_PROFILES_ACTIVE
• SPRING_KAFKA_BOOTSTRAP_SERVERS
• APP_SHORTEN_BASE_URL
• APP_FRONTEND_URL
• APP_ROOT_DOMAIN
• APP_COOKIE_DOMAIN
• APP_LOG_LEVEL
• TOSS_PAYMENTS_CLIENT_KEY
• TOSS_PAYMENTS_WEBHOOK_PAYMENT_VERIFICATION_ENABLED
• BILLING_PRO_FREE_START_ENABLED
• BILLING_PRO_FREE_START_DURATION_DAYS
• BILLING_RECURRING_ENABLED
• BILLING_RECURRING_CRON
• NGINX_BACKEND_HOST
• NGINX_FRONTEND_HOST
• NEXT_PUBLIC_SITE_URL
• TZ

GitHub Actions Secrets에 등록할 값:

• SPRING_DATASOURCE_URL
• SPRING_DATASOURCE_USERNAME
• SPRING_DATASOURCE_PASSWORD
• JWT_SECRET
• VISITOR_KEY_SECRET
• SPRING_OAUTH_GOOGLE_CLIENT_ID
• SPRING_OAUTH_GOOGLE_CLIENT_SECRET
• SPRING_OAUTH_NAVER_CLIENT_ID
• SPRING_OAUTH_NAVER_CLIENT_SECRET
• TOSS_PAYMENTS_SECRET_KEY
• TOSS_PAYMENTS_WEBHOOK_SECRET
• BILLING_ENCRYPTION_KEY
• HOST_ARM1
• HOST_AMD1
• SSH_KEY

DB 서비스를 포함해 운영 Compose를 실행할 때는 다음 값도 필요합니다. compose.arm2.yml로 DB 서버를 별도 배포하는 경우에도 동일하게 등록합니다.

• POSTGRES_USER
• POSTGRES_PASSWORD
• POSTGRES_DB
• HOST_ARM2

수동으로 운영 Compose를 실행해야 하는 경우에도 .env.production 파일을 만들지 않고, 위 목록의 필수 값을 쉘 환경변수로 주입한 뒤 실행합니다. 필수 값이 빠지면 Compose가 시작 전에 실패합니다.

local > export SPRING_DATASOURCE_URL=...
local > export SPRING_DATASOURCE_USERNAME=...
local > export SPRING_DATASOURCE_PASSWORD=...
local > export NEXT_PUBLIC_SITE_URL=https://linkpado.com
local > export NGINX_BACKEND_HOST=pado.cc
local > export NGINX_FRONTEND_HOST=linkpado.com
local > export ...
local > docker compose -f compose.yml -f compose.prod.yml build
local > docker compose -f compose.yml -f compose.prod.yml push

remote > export SPRING_DATASOURCE_URL=...
remote > export SPRING_DATASOURCE_USERNAME=...
remote > export SPRING_DATASOURCE_PASSWORD=...
remote > export NEXT_PUBLIC_SITE_URL=https://linkpado.com
remote > export NGINX_BACKEND_HOST=pado.cc
remote > export NGINX_FRONTEND_HOST=linkpado.com
remote > export ...
remote > docker compose -f compose.yml -f compose.prod.yml pull
remote > docker compose -f compose.yml -f compose.prod.yml up -d --no-build

tl;pr (Too Long; Please Read)

학습 성과

목차로

영역	사용 기술	성과 및 경험
애플리케이션	Spring Boot 3	Java 21을 활용한 백엔드 환경 구축 @Transactional의 프록시 동작 원리를 이해하고 낙관적 락의 재시도 절차 구현
인증/인가	Spring Security, JWT, OAuth2	Google/Naver OAuth2를 이용한 소셜 로그인 구현 JWT 도입을 통한 Stateless한 인증 시스템 구축
인프라/네트워크	Docker, Nginx, OCI	계층형 네트워크 구조 설계로 보안성 높은 인프라 구축 Rate limit을 적용하여 트래픽 안정성 확립
캐시	Redis	서비스 특성을 고려한 전략적 캐시 도입으로 성능 향상
테스트	JUnit	결함을 조기발견하고 안정적 리팩토링 환경 조성

백엔드 컨벤션

목차로

컨벤션에 대해 backend/README.md에 상세한 내용이 있습니다.

단축 URL 생성 전략

목차로

7자리 Base58 문자셋의 문자열

단축 URL의 경로는 123456789abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ의 문자열 중 SecureRandom으로 무작위 자릿수를 뽑은 문자 7개로 구성된 문자열입니다.

이 방식을 선택함으로써 아래 문제들을 해결했습니다.

1. 쉽고 짧으면서, 많아야 한다.

   • 단축 URL은 사람이 직접 타이핑하기 쉬워야합니다. 비슷하게 생긴 O와 0, I와 L, 타이핑하기 불편한 특수문자가 포함되지 않은 Base58 문자셋을 사용했습니다.
   • 주소를 짧게 하기 위해 7자리만 사용하더라도 58진법으로 충분히 많은 경우의 수를 가질 수 있습니다. /

2. 예측할 수 없어야 한다.

   • 순차가 아닌 랜덤이기에 예측하기 매우 어려워 보안에 유리합니다.

3. 동시성 문제

   • 랜덤한 값을 생성 후 일단 저장을 시도하고, 중복이면 @Retryable을 통해 5회까지 재시도하는 낙관적 방식이기 때문에, Race Condition이나 Deadlock에서 비교적 자유롭습니다.
   • 분산환경에서도 각 서버간의 복잡한 동기화 과정이 필요없어 분산환경 친화적입니다.

4. 확장성
   그럴 일이 없겠지만, 경로에 쓸 id가 고갈되는 경우 id를 단 한 자리만 더 늘려도 엄청난 확장성을 가집니다.

Redis 캐시 구성에 따른 성능 향상과 캐시 전략

목차로

단축 URL 서비스는 쓰기 작업보다 읽기 작업이 훨씬 많습니다. 또한 최근에 생성 또는 조회된 URL일 수록 다시 조회될 확률이 높습니다. 따라서 매번 RDB에서 데이터를 쿼리해오는 것보다, 메모리 기반 캐싱을 활용해 응답 속도를 낮추고 DB의 IO 병목을 방지하려는 목적으로 redis 캐시를 구성하였습니다.

응답속도(P95, P99) 개선

30RPS 응답시간	캐시 없음	캐시 구축 후	개선율
p(95)	262.51ms	44.04ms	약 83% 개선
p(99)	1.05s	68.07ms	약 93% 개선
평균	65.92ms	8.32ms	약 87% 개선

부하테스트는 k6으로 진행하였으며, RPS는 요청 실패율 0%를 유지하는 최고 부하를 기준으로 했습니다.

• 단축URL을 캐시에서 읽을 때는 Look aside 전략을 사용합니다. 먼저 Redis를 조회 후, 찾지 못했다면 DB에서 읽어 Redis에 갱신합니다.

• 단축URL을 캐시에 쓸 때는 Write around 전략을 사용합니다. 첫 단축URL 조회시에 캐시에 올립니다. 생성만 해놓고 사용하지 않는 단축URL이 캐시를 낭비시키는 것을 방지합니다.

• 단축URL을 캐시에서 제거할 때는 TTL(Time To Live) + LRU(Least Recently Used) 전략을 사용합니다. 캐시의 기본적인 수명을 잡고, 조회될 때마다 수명을 갱신합니다. 그리고 캐시가 가득 찼을 때는 마지막 조회가 오래된 순으로 캐시에서 제거합니다.

리다이렉션을 301이 아닌 302로 하는 이유

목차로

301 Moved Permanently로 리다이렉트하면 브라우저가 그 리다이렉션을 캐싱합니다. 이후에는 같은 요청을 반복할 때, 서버를 거치지 않고 캐싱된 리다이렉션 목적지로 갑니다. 그리고 이건 조회수나 지역 등 방문 데이터 집계에 차질을 줍니다.

302 Found로 리다이렉트하면 브라우저는 캐싱없이 항상 이 서버에 요청을 보냅니다. 301과 같은 문제가 생기지 않습니다. 이 서비스는 추후 회원에게 방문 데이터를 제공할 예정이기에 301이 아닌 302를 사용합니다.

계층형 리버스 프록시 구조로 설계한 이유

목차로

사용자의 요청이 백엔드 서버로 도달하기까지 리버스프록시-게이트웨이-백엔드서버 를 거치는 계층형 구조를 설계하였습니다. 이 구조는 아래와 같은 특징을 지닙니다.

• 공격표면 최소화: 외부 네트워크와 맞닿는 지점을 최전방의 리버스 프록시 서버만으로 최소화합니다. WAS와 DB 등은 프라이빗 네트워크에 격리하여 보안 위협을 최소화했습니다.
• 인프라 확장성·유연성: 서버를 수평확장하려 할 경우, weight 등 게이트웨이 설정만으로 로드밸런싱을 할 수 있게 됩니다. split_clients 등 설정을 통해 카나리 배포 등 유연한 활용이 가능해집니다.
• SSL 종단점 일원화: SSL 인증서 관리와 HTTPS 복호화를 최전방의 리버스 프록시 서버가 전담하게 함으로써 내부 서버들은 SSL 설정과 복호화 연산이 불필요해집니다.
• CORS 해결: 브라우저 입장에서 모든 요청과 응답이 동일한 origin과 이루어지도록 만듭니다.

참조

목차로

• 유튜브의 Video ID 생성 방식