JWT vs 세션 기반 인증 방식 비교 및 실무 대응 전략

✅ 인증 방식 개요

🧩 JWT의 구조와 서명 검증 방식

✅ JWT 구성

JWT는 세 부분으로 구성되어 있음:

<Header>.<Payload>.<Signature>

• Header: 토큰 타입과 해싱 알고리즘 정보를 담음 (ex. HS256)
• Payload: 유저 정보와 클레임 (exp, sub 등)을 포함
• Signature: Header + Payload를 서버의 비밀 키로 서명한 값

예시:

// Header
{
  "alg": "HS256",
  "typ": "JWT"
}

// Payload
{
  "sub": "1234567890",
  "name": "John Doe",
  "exp": 1710000000
}

✅ 서명(Signature) 생성 및 검증

서명 생성 방식 (서버):

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

검증 시 (서버):

1. 클라이언트로부터 받은 JWT를 디코딩
2. Header와 Payload를 사용하여 서버의 secret 키로 다시 서명 생성
3. 생성된 서명과 클라이언트가 보낸 Signature가 일치하는지 비교
   • ✅ 일치 → 유효한 토큰
   • ❌ 불일치 → 위변조된 토큰 → 인증 거부

🔐 JWT 사용 시 예상되는 보안 문제와 해결 방안

1. Access Token 탈취 시 대응 불가

• 문제: Access Token이 탈취되면 유효기간 내 누구나 사용할 수 있음
• 해결:
  • Access Token 유효기간을 짧게 설정 (ex. 15분)
  • Refresh Token 도입
  • Redis 기반 블랙리스트로 탈취 토큰 차단 (토큰 감지 로직 필요)

2. Refresh Token 탈취 시 무한 재발급

• 문제: Refresh Token이 탈취되면 공격자가 Access Token을 계속 재발급 가능
• 해결:
  • Rotating Refresh Token 전략 적용 (1회 사용 후 폐기)
  • 재사용 감지 시 탈취로 간주하여 차단
  • IP, User-Agent 바인딩
• ✅ 예시: 구글, 카카오톡 등에서 "평소와 다른 장소에서 로그인되었습니다" 알림 발생

3. 로그아웃 불가 (Stateless 구조의 한계)

• 문제: 서버가 상태를 기억하지 않아 강제 로그아웃 어려움
• 해결:
  • Redis 기반 블랙리스트 구현
  • 로그아웃 시 Access Token을 등록하고 차단

4. 동시 로그인 제어 불가

• 문제: 하나의 계정으로 여러 기기에서 동시 로그인 가능
• 해결:
  • 로그인 시 jti(UUID) 부여 → Redis 저장
  • 요청 시 jti 검증 → 기존 jti 무효화

5. 토큰 크기 증가로 인한 성능 저하

• 문제: JWT는 세션 ID보다 길고, 매 요청마다 전송됨 → 트래픽 증가
• 해결:
  • Payload에 최소한의 정보만 포함 (ex. userId, role)
  • 민감 정보는 포함 금지

✅ 결론: JWT vs Session

• JWT 인증은 서버가 상태를 저장하지 않아 확장성과 분산 시스템에 유리하며, 모바일, API 기반 서비스에 적합합니다.
• 반면 세션 기반 인증은 서버에 상태를 저장하므로, 보안과 통제 측면에서 더 강력한 제어가 가능합니다.
• 실제 서비스에서는 두 방식을 적절히 조합하거나, 서비스 특성에 따라 선택하는 것이 중요합니다.

Redis를 캐시로 사용할 때 가장 많이 하는 고민 중 하나는 다음과 같습니다.

"데이터를 수정해야 할 때, DTO 전체를 Redis에 다시 저장해야 할까? 아니면 변경된 필드만 수정할 수 있을까?"

✅ Redis는 데이터를 어떻게 저장할까?

Redis는 다양한 자료형을 지원합니다. DTO(Data Transfer Object)를 캐시할 때는 주로 두 가지 방식 중 하나를 사용합니다.

1. String 타입에 직렬화된 JSON 형태로 저장

redisTemplate.opsForValue().set("post:123", dto); // JSON 직렬화된 전체 DTO

이 방식은 Redis에 전체 객체를 문자열로 저장하는 방식입니다.
즉, 필드 하나만 바뀌었더라도 Redis에는 전체 값을 덮어써야 합니다.

🔁 업데이트 예시

dto.setTitle("수정된 제목");
redisTemplate.opsForValue().set("post:123", dto); // 전체 덮어쓰기

• ✅ 장점: 사용이 간단하고 빠르게 구현 가능
• ⚠️ 단점: 필드 하나 변경해도 전체 교체 → 네트워크 비용, (de)serialization 비용 증가

2. Hash 타입으로 필드 단위 저장

redisTemplate.opsForHash().put("post:123", "title", "제목");
redisTemplate.opsForHash().put("post:123", "content", "내용");

이 방식은 DTO의 각 필드를 Redis의 Hash 구조에 key-value로 저장합니다.
필드 단위로 접근하거나 수정할 수 있어 필드 하나만 바꿔도 해당 필드만 업데이트하면 됩니다.

🔁 업데이트 예시

redisTemplate.opsForHash().put("post:123", "title", "수정된 제목");

• ✅ 장점: 필드 단위 업데이트 가능 → 성능 효율적
• ⚠️ 단점: 구조 설계 복잡, 객체로 역직렬화 필요

⚖️ 어떤 방식이 더 효율적일까?

🧠 팁: 상황에 따라 선택하자!

✅ 변경이 거의 없는 캐시 (예: 게시글 본문, 작성자 정보)

• String 방식으로 간단하게 처리
• Redis는 메모리 기반이라 전체 교체도 빠름

✅ 자주 바뀌는 필드 (예: 좋아요 수, 댓글 수)

• Hash 방식 사용
• 필드만 업데이트해서 네트워크 비용 최소화

🔚 마무리

Redis는 빠르지만, 데이터 업데이트 전략은 매우 중요합니다.
특히 DTO 캐싱에서 전체 덮어쓰기와 필드 단위 수정은 성능과 코드 복잡도에 큰 영향을 미칩니다.

🚀 변경이 적다면 String으로,
🔁 자주 바뀌면 Hash로 관리하자!

지난번 포스트에서 fetch join이 오히려 성능을 떨어트리는 원인을 찾아봤습니다. 이번 포스트에서는 해당 문제점을 해결하여 실질적인 성능향상을 이뤘던 내용을 정리해보려합니다. 페치조인이 성능을 떨어트린 이유는 아래 포스트 참고 https://velog.io/@junho_99/JPA-Fetch-Join-%EC%BF%BC%EB%A6%AC-%EB%B6%84%EC%84%9D%EC%9C%BC%EB%A1%9C-%EC%84%B1%EB%8A%A5-%EB%B9%84%EA%B5%90

문제를 요약하면

1. 페치조인으로 유저와 해당유저 게시글을 한번에 가져옴
2. DISTINCT + 정렬 + 페이징 등을 페치조인 쿼리와 함께 사용하면 조인으로 늘어난 row에 대한 계산을 진행해야하므로 성능 저하됨
3. 1:N 관계에서의 페치조인은 row를 N개만큼 중복생성함

⚙️ 초기 실험

위의 문제들을 해결한뒤에 페치조인 사용 전 vs 후 성능 비교를 시도했지만, 성능 차이가 거의 없었습니다.

📌 원인

• 팔로우한 유저 수가 1명뿐이었기 때문!
• 이로 인해 쿼리 횟수가 적고, N+1 문제 체감이 어려웠습니다.

📈 실험 조건 확장

✅ 실험 설정

• 테스트 유저(ID=3000050000)가 각각 **200명(211400)**을 팔로우
• 팔로우한 유저마다 게시글 데이터 4개 삽입
• 각 게시글마다 미디어 파일 데이터 2개 삽입

✅ 테스트 환경

• 동시 접속 유저: 약 2만 명
• 각 유저의 팔로잉 수: 200명
• 각 유저당 게시글 수: 4개
• 각 게시글당 미디어파일 수 2개

🚀 본격 성능 실험

1. User + Post 페치조인만 사용

• Post ↔ MediaFile은 Lazy 로딩으로 개별 조회 → N+1 발생
• ✅ 성능 개선 일부 확인

2. User + Post는 페치조인

• Post + MediaFile은 IN 절 기반 일괄 조회
  • MediaFile 조회 시 WHERE post_id IN (...) 사용
  • 중복 row 없이 메모리에서 그룹핑 후 수동 주입
  • ✅ 가장 큰 성능 향상 확인!

3. 모든 관계를 Fetch Join으로 처리

• Post ↔ MediaFile도 Fetch Join
• 데이터가 많아질수록 row 수 폭증 → 정렬 및 페이징 성능 감소

아래의 그래프는 왼쪽부터 쿼리최적화X ----------- 페치조인+IN절 사용 ------- 캐쉬까지 적용

P50, P95, P99 성능지표

페치조인을 사용했을때와 사용하지 않았을때 성능차이가 거의 20~30배가 났습니다.

nGrinder 부하테스트 결과

• 캐쉬까지 적용한 메서드는 시간이 지날수록 캐쉬에 값들이 저장되고 Cache hit 비율이 증가하면서 TPS가 점점 증가하여 400까지 올라갔습니다.

🧠 결론

✅ 최종 전략

• User ↔ Post는 Fetch Join
• Post ↔ MediaFile은 IN 절 기반 조회 + 메모리에서 주입

💡 학습 포인트

• 단순히 "페치조인이 좋다"는 틀렸다!
• 데이터 양, 정렬, 페이징 여부에 따라 최적 전략은 달라진다.
• 직접 부하 테스트하고, 실행 계획(Execution Plan)을 분석하며 얻은 실전 지식입니다. 💪

진행 중인 프로젝트에서 뉴스피드를 불러올 때, 팔로우한 유저들의 게시글과 함께 연관 엔티티인 미디어 파일까지 함께 가져오려고 Fetch Join을 적용해봤습니다.

Hibernate: select distinct p1_0.id,p1_0.content,p1_0.created_at,p1_0.likes,mf1_0.post_id,mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.url,p1_0.modified_at,p1_0.title,p1_0.user_id from post p1_0 left join media_file mf1_0 on p1_0.id=mf1_0.post_id where p1_0.user_id in (select f1_0.following_id from follows f1_0 where f1_0.follower_id=?) order by p1_0.created_at desc
Hibernate: select distinct p1_0.id,p1_0.content,p1_0.created_at,p1_0.likes,mf1_0.post_id,mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.url,p1_0.modified_at,p1_0.title,p1_0.user_id,u1_0.id,u1_0.created_at,u1_0.email,u1_0.follower_count,u1_0.following_count,u1_0.is_celeb,u1_0.modified_at,u1_0.password,u1_0.role,u1_0.username from post p1_0 join users u1_0 on u1_0.id=p1_0.user_id left join media_file mf1_0 on p1_0.id=mf1_0.post_id where u1_0.id in (select f1_0.following_id from follows f1_0 where f1_0.follower_id=?) and u1_0.is_celeb=true order by p1_0.created_at desc
Hibernate: select u1_0.id,u1_0.created_at,u1_0.email,u1_0.follower_count,u1_0.following_count,u1_0.is_celeb,u1_0.modified_at,u1_0.password,u1_0.role,u1_0.username from users u1_0 where u1_0.id=?

이건 페치조인후 쿼리

**Fetching posts without Fetch Join (N+1 risk)*** for user 23561
Hibernate: select p1_0.id,p1_0.content,p1_0.created_at,p1_0.likes,p1_0.modified_at,p1_0.title,p1_0.user_id from post p1_0 where p1_0.user_id in (select f1_0.following_id from follows f1_0 where f1_0.follower_id=?) order by p1_0.created_at desc fetch first ? rows only
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.post_id,mf1_0.url from media_file mf1_0 where mf1_0.post_id=?
Hibernate: select distinct p1_0.id,p1_0.content,p1_0.created_at,p1_0.likes,mf1_0.post_id,mf1_0.id,mf1_0.created_at,mf1_0.modified_at,mf1_0.url,p1_0.modified_at,p1_0.title,p1_0.user_id,u1_0.id,u1_0.created_at,u1_0.email,u1_0.follower_count,u1_0.following_count,u1_0.is_celeb,u1_0.modified_at,u1_0.password,u1_0.role,u1_0.username from post p1_0 join users u1_0 on u1_0.id=p1_0.user_id left join media_file mf1_0 on p1_0.id=mf1_0.post_id where u1_0.id in (select f1_0.following_id from follows f1_0 where f1_0.follower_id=?) and u1_0.is_celeb=true order by p1_0.created_at desc
Hibernate: select u1_0.id,u1_0.created_at,u1_0.email,u1_0.follower_count,u1_0.following_count,u1_0.is_celeb,u1_0.modified_at,u1_0.password,u1_0.role,u1_0.username from users u1_0 where u1_0.id=?

이건 페치조인 안했을때 쿼리

최근 게시물 30개 뽑아와서 각각의 포스트마다 미디어파일을 불러오는 쿼리가 발생했습니다. (N+1문제)

문제는 아래 사진을 보면됩니다. 왼쪽 노란색 그래프: Fetch Join 없이 → N+1 발생

가운데 초록색 그래프: Fetch Join 적용

🙈 예상과 다르게 Fetch Join을 적용했을 때 오히려 더 느려졌습니다.

원인을 파악하고자 PostgreSQL의 EXPLAIN ANALYZE로 직접 쿼리를 뜯어봤습니다.

❗ 결론 먼저

• 정렬/페이징 + Fetch Join 조합은 성능상 불리하거나 비정상적인 결과를 유발할 수 있음 → 특히 1:N 관계에서 JOIN 결과 row 수가 폭증하면서 페이징이 제대로 안 먹히거나, 메모리 낭비 발생

🔥 왜 성능이 저하될까?

1. Fetch Join은 중복 row를 유발

SELECT p FROM Post p
JOIN FETCH p.mediaFiles

1. 하나의 Post가 MediaFile 3개를 갖고 있다면 → Post row가 3배 중복되어 조회됨

2. 이후 ORDER BY 및 LIMIT 30을 걸면 → 실제 Post는 10개일 수 있음 (중복 포함 30개가 기준이 되기 때문)

📌 페이징 기준은 "Post"인데, MediaFile로 인한 중복 row 때문에 정확한 페이징이 불가능

2. 메모리 낭비와 성능 저하

Fetch Join + ORDER BY 조합 시 → 중복 row가 정렬 대상에 포함됨

→ 정렬 처리량 증가

→ 메모리 소비 증가 및 쿼리 실행 시간 지연

결과적으로:

❌ 불안정한 페이징 결과

❌ 느린 응답 시간

✅ 대안 (추천 전략)

💡 참고 코드 예시 (Spring Data JPA)

// Step 1: Post만 페이징
List<Post> posts = postRepository.findByUserIn(userIds, pageable);

// Step 2: Post ID로 MediaFile 일괄 조회
List<MediaFile> mediaFiles = mediaFileRepository.findByPostIdIn(postIds);

⚙️ 실험 조건

• PostgreSQL 17 사용
• Hibernate SQL 로그 기반 쿼리 확인
• 성능 측정 도구: EXPLAIN ANALYZE

1️⃣ 기본 쿼리: post만 조회

SELECT id, content, created_at, ...
FROM post
WHERE user_id IN (
  SELECT following_id FROM follows WHERE follower_id = 23561
)
ORDER BY created_at DESC
LIMIT 30;

📌 결과

• Execution Time: 16.7ms
• Sort Method: top-N heapsort 사용
• 효율적이고 빠름

2️⃣ Fetch Join 방식

SELECT DISTINCT p.id, p.content, m.url
FROM post p
LEFT JOIN media_file m ON p.id = m.post_id
WHERE p.user_id IN (
  SELECT following_id FROM follows WHERE follower_id = 23561
)
ORDER BY p.created_at DESC
LIMIT 30;

📌 결과

• Execution Time: ❌ 30.1ms
• JOIN 결과 row 수 증가 → 11,213 rows
• DISTINCT 처리 비용 발생 (HashAggregate)
• 성능 저하, 메모리 사용 ↑

3️⃣ 최적화 전략: 서브쿼리 방식

SELECT * FROM media_file
WHERE post_id IN (
  SELECT id FROM post
  WHERE user_id IN (1,2,3,4,5)
  ORDER BY created_at DESC
  LIMIT 30
);

📌 결과

• Execution Time: ✅ 17.4ms
• Subquery는 정렬 + LIMIT 정확히 반영
• 외부 쿼리는 Hash Semi Join으로 최적화
• post 30개에만 연결된 media만 조회

📊 성능 비교 요약

✅ 최종 결론

뉴스피드처럼:

• 정렬 (ORDER BY created_at DESC)
• 페이징 (LIMIT 30)
• 연관 데이터 (media_file)

이 함께 필요한 상황에서는:

👉 Fetch Join은 오히려 성능을 악화시킬 수 있습니다. 쿼리 구조와 데이터 양, 조건, 정렬 여부 등을 고려해서 필요한 방식으로 유연하게 접근해야 합니다.

실제 최적화 이후 성능분석은 아래 링크 참고 https://velog.io/@junho_99/Fetch-Join-vs-IN%EC%A0%88-%EC%84%B1%EB%8A%A5-%EB%B9%84%EA%B5%90-%EC%8B%A4%ED%97%98%EA%B8%B0

이번 글에서는 이 둘의 개념과 차이점, 사용 예시까지 정리해보겠습니다.

🧱 파티셔닝(Partitioning)이란?

파티셔닝은 하나의 테이블을 논리적으로 분할하여 여러 개의 파티션(Partition)으로 나누는 방식 DB는 여전히 하나의 인스턴스에서 관리되지만, 테이블이 내부적으로 나뉘어 저장되는 구조

✔️ 예시

위와같은 테이블이 있다고 했을때 이를 수직 파티셔닝과 수평 파티셔닝 두 가지 방법으로 구현할 수 있다.

수직 파티셔닝

수직 파티셔닝은 테이블의 Column을 분할하여 여러 개의 서로 다른 테이블로 나누는 방법이다. 자주 조회하게 되는 칼럼과 잘 조회하지 않는 칼럼을 구분지음으로써 성능을 향상시킬 수 있다.

수평 파티셔닝

데이터베이스에서 테이블의 Row를 분할하여 여러 개의 서로 다른 테이블로 나누는 방법이다.

파티셔닝 범위

1. 범위 분할, Range Partitioning

연속적인 값을 범위를 기준으로 하여 분할 우편 번호, 날짜, 분기 등의 데이터에 적합

2. 목록 분할, List Partitioning

데이터 값이 특정 목록에 포함된 경우 데이터를 분리 나라, 지역 등의 데이터에 적합

3. 해시 분할, Hash Partitioning

Key값 등 특정 Column의 값을 Hashing 하여 분할 균등한 데이터 분할이 가능 범위가 없는 데이터에 적합

4. 합성 분할, Composite Partitioning

위 종류 중 2개 이상을 사용하여 분할

✅ 장점 쿼리 성능 향상 관리 용이 (파티션 단위 백업/삭제 가능) 단일 인스턴스 운영으로 트랜잭션 관리 쉬움

⚠️ 단점 스토리지나 처리 능력은 한 인스턴스에 의존 파티션 설계가 복잡할 수 있음

🪓 샤딩(Sharding)이란?

샤딩(Sharding)은 데이터를 여러 DB 인스턴스(서버)에 분산 저장하는 방식이다. 즉, 단일 테이블을 나누는 것이 아니라, 동일한 스키마를 가진 데이터베이스를 나눠서 운영한다. 어떻게 보면 샤딩은 수평 파티셔닝과 비슷하지만 차이점은 수평 파티셔닝의 경우 동일한 서버에 저장되어 있고, 샤딩은 서로 다른 서버에 분산하여 저장한다는 점이다. 따라서 쿼리 성능 향상뿐만 아니라 부하가 분산되는 효과까지 얻을 수 있다. 즉, 샤딩은 데이터베이스 차원의 수평 확장(scale-out)이다.

수평파티셔닝

샤딩 위처럼 모든 파티션을 같은 DB 서버에 저장하는 수평 파티셔닝과 다르게 샤딩은 각 파티션들을 서로 다른 DB 서버에 저장함으로서 DB서버의 부하를 분산시키는 목적이 있다. 이때 수평분할된 작은 테이블을 샤드(shard)라고하며 규모가 큰 서비스, 데이터가 많이 쌓이는 테이블, 트래픽이 많이 몰리는 경우에 사용한다.

✅ 장점 수평적 확장 가능 (서버 추가로 처리량 증가) 트래픽 및 저장소 분산 대규모 시스템에 유리

⚠️ 단점 트랜잭션 관리가 어려움 (샤드 간 조인, 정합성 문제) 샤딩 키 설계가 매우 중요 (어느 샤드에만 데이터가 주구장창 모이면 오히려 안좋음) 샤드 추가/병합 시 데이터 재분배 필요

참고한 블로그

https://aiday.tistory.com/123 https://velog.io/@yangsijun528/%ED%8C%8C%ED%8B%B0%EC%85%94%EB%8B%9D%EA%B3%BC-%EC%83%A4%EB%94%A9