백엔드 지식 내용 정리

Jake·2026년 2월 13일
마인드맵백엔드

안녕하세요 백엔드 관련 지식을 경험을 기반하여 정리해보려고 합니다. 위 마인드맵의 모든 양을 다루기에는 경험하지 못한 부분도 있고 비교적 방대하므로 마인드맵을 참고하여 아래 목차 순으로 진행하겠습니다.

(오른쪽에 있는 목차를 클릭하시면 해당 내용으로 이동가능합니다.)

목차

  1. 인터넷
  2. 프로세스와 네트워크
  3. Java 언어
  1. 관계형 데이터베이스
  1. 캐싱

1. 인터넷

인터넷 작동 원리

인터넷 작동 원리
인터넷은 수많은 시스템이 연결된 거대한 분산 네트워크입니다. 사용자가 브라우저에 요청을 입력했을 때 내부적으로 일어나는 전체 흐름은 다음과 같습니다.

  1. 사용자가 구글에 hello 입력
  2. DNS 조회 (IP 주소 획득)
  3. 소켓 생성 및 TCP 3-way Handshake (HTTPS인 경우 이후 TLS Handshake)
  4. HTTP Request 전송
  5. 서버 처리
  6. HTTP Response 반환
  7. TCP 연결 종료 또는 keep-alive 유지

2번에서 브라우저는 IP 주소를 획득하기 위해 매번 네트워크 DNS 요청을 보내지 않습니다. 일반적으로 다음 순서로 확인합니다.

  • 브라우저 내부 DNS 캐시 확인
  • OS DNS 캐시 확인
  • hosts 파일 확인
  • 위에 없을 경우에만 DNS 서버로 네트워크 요청

이 과정을 통해 도메인에 해당하는 IP 주소를 얻습니다.
IP 주소를 얻은 뒤, 브라우저는 먼저 소켓(Socket) 을 생성합니다.

소켓은 네트워크 통신을 위한 인터페이스이며, 이 단계에서는 아직 실제 네트워크 연결이 이루어지지 않습니다.
이후 브라우저가 connect(서버 IP, 포트) 를 호출하면, 그 시점에 커널이 TCP 연결을 생성하기 시작합니다. 이 과정에서 다음과 같은 TCP 3-way Handshake 가 수행됩니다.

  1. SYN (Client → Server)
  2. SYN-ACK (Server → Client)
  3. ACK (Client → Server)

이 handshake가 성공해야 TCP 연결이 성립됩니다. HTTPS의 경우 TCP 연결이 완료된 이후 TLS Handshake가 추가로 진행됩니다.
TCP 연결이 성립되면 브라우저는 HTTP 요청을 생성하고 send() 와 같은 Socket API를 호출합니다. 이때 데이터는 사용자 공간에서 커널 공간으로 전달되며, 커널은 이를 TCP 세그먼트로 분할한 뒤 NIC(Network Interface Card)를 통해 네트워크로 전송합니다.

서버에서는 listen() 상태의 소켓이 연결 요청을 대기하고 있으며, handshake가 완료되면 커널이 해당 연결을 생성합니다. 서버는 연결을 다음 4-tuple로 식별합니다.

(src IP, src port, dst IP, dst port)

이후 연결은 소켓 큐(accept queue)로 전달되고, 애플리케이션이 이를 accept() 하여 HTTP 요청을 처리합니다.
서버는 요청을 처리한 뒤 HTTP Response를 반환합니다. 응답 이후 연결을 종료할지, 유지할지는 HTTP 헤더의 Connection: keep-alive 여부에 따라 결정됩니다. HTTP/1.1에서는 기본적으로 연결을 재사용하며, 필요 시에만 종료합니다

HTTP

HTTP(HyperText Transfer Protocol)는 웹에서 클라이언트와 서버 간 통신을 위한 애플리케이션 계층 프로토콜입니다.

HTTP의 특징
1. Stateless(무상태성)

  • 각 요청은 독립적이며 이전 요청 정보를 유지하지 않음
    상태 유지가 필요하면 쿠키, 세션, JWT 등을 사용
  1. Connectionless(비연결성)
  • 요청-응답 후 연결을 끊음
  • HTTP/1.0의 기본 동작
  • HTTP/1.1부터는 Keep-Alive로 연결 재사용 가능

HTTP 메시지 구조
HTTP 메시지는 요청(Request)과 응답(Response)으로 구분됩니다.

HTTP Request 구조:

Request Line: GET /api/users HTTP/1.1
Headers: Host, User-Agent, Accept, Content-Type 등
Body: (POST, PUT 등에서 사용)

HTTP Response 구조:

Status Line: HTTP/1.1 200 OK
Headers: Content-Type, Content-Length, Set-Cookie 등
Body: 실제 데이터

HTTP 메서드

  • GET: 리소스 조회(멱등성, 안전)
  • POST: 리소스 생성(멱등성 없음)
  • PUT: 리소스 전체 교체(멱등성)
  • PATCH: 리소스 부분 수정(멱등성 없을 수 있음)
  • DELETE: 리소스 삭제(멱등성)
  • HEAD: 헤더만 조회
  • OPTIONS: 지원 메서드 확인(CORS preflight)

HTTP 상태 코드

1xx: 정보성 응답

2xx: 성공

  • 200 OK: 성공
  • 201 Created: 생성 성공
  • 204 No Content: 성공, 본문 없음

3xx: 리다이렉션

  • 301 Moved Permanently: 영구 이동
  • 302 Found: 임시 이동
  • 304 Not Modified: 캐시 사용

4xx: 클라이언트 오류

  • 400 Bad Request: 잘못된 요청
  • 401 Unauthorized: 인증 필요
  • 403 Forbidden: 권한 없음
  • 404 Not Found: 리소스 없음
  • 409 Conflict: 충돌

5xx: 서버 오류

  • 500 Internal Server Error: 서버 오류
  • 502 Bad Gateway: 게이트웨이 오류
  • 503 Service Unavailable: 서비스 불가

HTTP 버전별 특징
HTTP/1.0

  • 요청마다 연결/해제
  • 비효율적

HTTP/1.1

  • Keep-Alive로 연결 재사용
  • 파이프라이닝(순차 처리)
  • 호스팅 지원(가상 호스트)
  • 청크 전송 인코딩

HTTP/2

  • 멀티플렉싱(단일 연결에서 여러 요청 병렬 처리)
  • 헤더 압축(HPACK)
  • 서버 푸시
  • 바이너리 프레이밍

HTTP/3

  • QUIC 기반(UDP)
  • 연결 마이그레이션
  • 더 빠른 핸드셰이크

DNS

DNS(Domain Name System)는 도메인 이름을 IP 주소로 변환하는 분산 계층형 네이밍 시스템입니다.

DNS 조회 과정 (Recursive Query)

  1. 로컬 DNS 캐시 확인
  • 브라우저 캐시 → OS 캐시 → hosts 파일
  1. Recursive DNS 서버(ISP 제공)에 요청
  • 클라이언트는 Recursive Resolver에만 요청
  1. Root DNS 서버 조회
  • TLD 정보 제공
  1. TLD DNS 서버 조회
  • 2차 도메인 권한 서버 정보 제공
  1. Authoritative DNS 서버 조회
  • 최종 IP 주소 반환
  1. 결과 캐싱 및 반환
  • Recursive Resolver가 결과를 캐싱하고 클라이언트에 반환

DNS 캐싱과 TTL

  • TTL(Time To Live): 레코드의 유효 시간
  • 캐싱으로 조회 횟수 감소 및 응답 속도 향상
  • TTL 만료 시 재조회

2. 프로세스와 네트워크

프로세스와 스레드

프로세스란?

프로세스는 실행 중인 프로그램의 인스턴스이며,
운영체제로부터 독립적인 가상 메모리 공간을 할당받는 실행 단위입니다.
즉, 단순한 프로그램 파일(.exe, .jar 등)이 아니라
메모리를 할당받아 실제로 동작 중인 상태가 프로세스입니다.

프로세스의 메모리 구조
프로세스는 OS로부터 가상 메모리(Virtual Memory) 공간을 할당받습니다.
이 가상 메모리는 실제 물리 메모리(RAM)와 디스크(스왑 영역)를 매핑하여 관리됩니다.

가상 메모리란?
각 프로세스는 자기만의 독립적인 주소 공간을 가짐
실제 물리 메모리는 여러 프로세스가 공유

MMU(Memory Management Unit)가 가상 주소 → 물리 주소 변환

메모리가 부족하면 일부 페이지를 디스크(Swap)로 내림 (1차/2차 메모리 혼합 사용) 프로세스는 물리 메모리를 직접 쓰는 것이 아니라 OS가 관리하는 가상 메모리 공간을 통해 간접적으로 사용합니다.

프로세스 메모리 구성

코드 영역(Text)

  • 실행 코드 저장
  • 읽기 전용

데이터 영역(Data)

  • 전역 변수, static 변수
  • 힙(Heap)
  • 동적 메모리 할당 영역

런타임에 크기 변화

  • 스택(Stack)
  • 함수 호출 정보
  • 지역 변수
  • 호출 프레임 저장

프로세스의 특징

독립적인 가상 메모리 공간
다른 프로세스와 기본적으로 메모리 격리
프로세스 간 통신(IPC) 필요
(파이프, 소켓, 공유 메모리, 메시지 큐 등)
컨텍스트 스위칭 비용이 상대적으로 큼

프로세스 상태

  • 생성(New)
  • 준비(Ready)
  • 실행(Running)
  • 대기(Waiting)
  • 종료(Terminated)

스레드란?

스레드는 프로세스 내에서 실행되는 작업의 최소 단위입니다. 하나의 프로세스는 여러 스레드를 가질 수 있으며,
같은 프로세스의 스레드들은 메모리를 공유합니다.

스레드의 메모리 구조

스레드는 다음을 공유합니다:
코드 영역
데이터 영역
힙 영역

하지만 다음은 스레드별로 독립적으로 가집니다:
스택(Stack)
프로그램 카운터(PC)
레지스터 집합

스레드는 메모리 대부분을 공유하지만
실행 흐름에 필요한 최소 상태만 따로 가집니다.

스레드의 특징
프로세스 내 메모리 공유
스레드별 독립 스택
컨텍스트 스위칭 비용이 낮음
동기화 필요 (Race Condition, Deadlock 등)

프로세스 vs 스레드 — 컨텍스트 스위칭 차이

컨텍스트 스위칭이란?
CPU가 한 실행 단위에서 다른 실행 단위로 전환될 때
기존 상태를 저장하고 새로운 상태를 복원하는 과정입니다.

저장/복원되는 정보:

  • 프로그램 카운터(PC)
  • 레지스터 값
  • 스택 포인터
  • CPU 상태

왜 프로세스가 더 비싼가?

주소 공간 전환
프로세스는 서로 다른 가상 메모리 공간을 사용합니다.

프로세스 전환 시:
페이지 테이블 교체
TLB(Translation Lookaside Buffer) flush
메모리 매핑 정보 변경
이 작업이 매우 비용이 큽니다.

캐시 오염(Cache Pollution)
다른 프로세스로 전환되면:
CPU 캐시 내용이 무효화되거나 효율이 떨어짐
새로운 메모리 데이터를 다시 로딩해야 함

왜 스레드는 상대적으로 빠른가?
스레드는 같은 프로세스의 주소 공간을 공유합니다.
따라서:
페이지 테이블 교체 불필요
TLB flush 거의 없음
메모리 매핑 유지

스레드 전환은 레지스터/스택 상태만 바꾸면 되므로 비용이 낮습니다

스레드와 동시성

동시성(Concurrency) vs 병렬성(Parallelism)

동시성:

  • 단일 코어에서 시간 분할로 여러 작업을 번갈아 실행
  • 논리적 동시 실행
  • 예: 단일 코어에서 멀티태스킹

병렬성:

  • 여러 코어에서 실제 동시 실행
  • 물리적 동시 실행
  • 예: 멀티코어에서 병렬 처리

동시성 제어의 필요성
여러 스레드가 공유 자원에 접근할 때 동기화가 필요합니다.

경쟁 조건(Race Condition):

// 스레드 A와 B가 동시에 count++ 실행
int count = 0;
// 스레드 A: count = 0 → 읽음 → 1 → 쓰기
// 스레드 B: count = 0 → 읽음 → 1 → 쓰기
// 결과: count = 1 (기대값: 2)

원자성(Atomicity)이 보장되지 않아 문제가 발생합니다.

동기화 메커니즘
1. 뮤텍스(Mutex)

  • 상호 배제 잠금
  • 한 스레드만 소유
  • 소유한 스레드만 해제 가능
  1. 세마포어(Semaphore)
  • 카운터 기반
  • 여러 스레드가 동시 접근 가능(카운터만큼)
  • P(대기), V(신호) 연산
  1. 모니터(Monitor)
  • 고수준 동기화 구조
  • 뮤텍스 + 조건 변수
  • Java의 synchronized, wait(), notify()
  1. 읽기-쓰기 락(Read-Write Lock)
  • 읽기는 병렬, 쓰기는 배타적
  • 읽기 다수, 쓰기 단독

데드락(Deadlock)
두 개 이상의 스레드가 서로의 자원을 기다리며 무한 대기하는 상태입니다.

데드락 발생 조건(필요 조건):

  1. 상호 배제: 자원이 배타적
  2. 점유 대기: 자원을 보유한 채 대기
  3. 비선점: 자원을 강제로 빼앗을 수 없음
  4. 순환 대기: 순환 형태의 대기 체인

데드락 해결 방법:

  • 예방: 조건 제거(예: 모든 자원을 한 번에 요청)
  • 회피: 은행원 알고리즘
  • 탐지 및 복구: 주기적 탐지 후 복구
  • 무시: 발생 빈도가 낮으면 무시

Thread Pool

  • 스레드 재사용
  • 생성/소멸 비용 절감
  • 리소스 제어 용이

입출력 과정

I/O의 기본 개념
I/O는 CPU와 메모리 외부 장치(디스크, 네트워크 등) 간 데이터 전송입니다.

I/O의 특징:

  • CPU 속도 대비 매우 느림
  • 비동기 처리 필요
  • 블로킹/논블로킹 방식 구분

I/O 모델
1. 동기 블로킹 I/O

  • I/O 완료까지 대기
  • 단순하지만 비효율적
  • 예: read(), write() (블로킹 모드)
  1. 동기 논블로킹 I/O
  • 즉시 반환, 주기적 확인
  • CPU 낭비 가능
  • 예: read() (논블로킹 모드) + 반복 확인
  1. I/O 멀티플렉싱
  • select(), poll(), epoll() 사용
  • 단일 스레드로 다중 I/O 관리
  • 이벤트 기반
  1. 비동기 I/O (AIO)
  • I/O 요청 후 즉시 반환
  • 완료 시 콜백/시그널
  • 예: Linux aio_read(), Windows IOCP

네트워크 기본 개념

TCP/IP 4계층 모델
실제 인터넷에서 사용하는 모델입니다.

  1. 네트워크 인터페이스 계층: 물리/데이터 링크
  2. 인터넷 계층: IP, ICMP
  3. 전송 계층: TCP, UDP
  4. 응용 계층: HTTP, FTP, DNS 등

TCP vs UDP
TCP (Transmission Control Protocol):

  • 연결 지향
  • 신뢰성 보장(순서, 재전송)
  • 흐름 제어, 혼잡 제어
  • 오버헤드 큼
  • 예: HTTP, FTP, 이메일

UDP (User Datagram Protocol):

  • 비연결
  • 신뢰성 없음
  • 오버헤드 작음
  • 예: DNS, 스트리밍, 게임

TCP의 핵심 메커니즘

  1. 3-way Handshake (연결 설정)
Client → Server: SYN (seq=x)Server → Client: SYN-ACK (seq=y, ack=x+1)Client → Server: ACK (seq=x+1, ack=y+1)
  1. 4-way Handshake (연결 종료)
Client → Server: FINServer → Client: ACKServer → Client: FINClient → Server: ACK (TIME_WAIT 상태)
  1. 흐름 제어 (Flow Control)
  • 수신 윈도우 크기로 전송 속도 조절
  • 버퍼 오버플로우 방지
  1. 혼잡 제어 (Congestion Control)
  • Slow Start: 지수적 증가
  • Congestion Avoidance: 선형 증가
  • Fast Retransmit: 중복 ACK 시 재전송
  • Fast Recovery: 빠른 복구

포트(Port)
프로세스를 식별하는 논리적 주소입니다.

포트 범위:

  • Well-known Ports (0-1023): HTTP(80), HTTPS(443), SSH(22)
  • Registered Ports (1024-49151): 애플리케이션 등록
  • Dynamic/Private Ports (49152-65535): 클라이언트 임시 사용

소켓(Socket)
네트워크 통신의 엔드포인트입니다.

소켓 생성 과정:
1. socket(): 소켓 생성
2. bind(): 주소 바인딩(서버)
3. listen(): 연결 대기(서버)
4. accept(): 연결 수락(서버)
5. connect(): 연결 요청(클라이언트)
6. send()/recv(): 데이터 송수신
7. close(): 연결 종료

  1. 블로킹 I/O
  • 한 번에 하나의 연결 처리
  • 단순하지만 확장성 낮음
  1. 멀티프로세스
  • 프로세스당 하나의 연결
  • 안정적이지만 리소스 비용 큼
  1. 멀티스레드
  • 스레드당 하나의 연결
  • 프로세스보다 가볍지만 동시성 제어 필요
  1. I/O 멀티플렉싱
  • select(), poll(), epoll() 사용
  • 단일 스레드로 다중 연결 처리
  • 이벤트 기반
  1. 비동기 I/O
  • 완전 비동기 처리
  • 최고 성능, 복잡도 높음

3. 언어 Java

JVM 구조

JVM의 역할

JVM(Java Virtual Machine)은 Java 바이트코드를 실행하는 가상 머신입니다.

JVM의 주요 기능:
1. 바이트코드 로딩 및 실행
2. 메모리 관리(힙, 스택 등)
3. 가비지 컬렉션
4. 스레드 관리

JVM 구조

  1. 클래스 로더(Class Loader)
  • 로딩: 바이트코드 로드
  • 링킹: 검증, 준비, 해석
  • 초기화: 클래스 변수 초기화
  1. 실행 엔진(Execution Engine)
  • 인터프리터: 바이트코드를 한 줄씩 실행
  • JIT 컴파일러: 자주 사용되는 코드를 네이티브 코드로 컴파일
  • 가비지 컬렉터: 메모리 관리
  1. 런타임 데이터 영역
  • 메서드 영역: 클래스 메타데이터, 상수 풀
  • 힙: 객체 인스턴스
  • 스택: 메서드 호출 정보, 지역 변수
  • PC 레지스터: 현재 실행 중인 명령어 주소
  • 네이티브 메서드 스택: 네이티브 메서드 호출

메모리 관리

힙(Heap) 메모리 구조

힙은 객체 인스턴스가 저장되는 영역입니다.

힙 영역 구분:
1. Young Generation

  • Eden: 새 객체 할당
  • Survivor 0/1: GC 후 살아남은 객체
  1. Old Generation
  • 오래 살아남은 객체
  1. Permanent Generation (Java 8 이전) / Metaspace (Java 8+)
  • 클래스 메타데이터

가비지 컬렉션(GC)

GC의 기본 원리:

  • Reachability: 루트로부터 도달 가능한 객체는 살아있음
  • Mark and Sweep: 도달 가능한 객체를 마킹하고, 마킹되지 않은 객체를 제거

GC 알고리즘:
1. Serial GC: 단일 스레드, 작은 애플리케이션
2. Parallel GC: 멀티스레드, 처리량 중심
3. CMS GC: 낮은 지연 시간 목표(Java 9+ deprecated)
4. G1 GC: 대용량 힙, 일정한 지연 시간 목표
5. ZGC: 매우 낮은 지연 시간(Java 11+)
6. Shenandoah: 낮은 지연 시간(Java 12+)

GC 최적화 전략:

  • 객체 생명주기 최소화
  • 불필요한 참조 제거
  • 적절한 힙 크기 설정
  • GC 알고리즘 선택

스택(Stack) 메모리

스택은 메서드 호출 정보를 저장합니다.

스택 프레임 구성:

  • 지역 변수 배열
  • 피연산자 스택
  • 프레임 데이터(반환 주소, 예외 정보 등)

스택 오버플로우:

  • 재귀 호출이 깊거나 스택 프레임이 많을 때 발생
  • -Xss 옵션으로 스택 크기 조정 가능

객체 지향 프로그래밍

OOP의 4대 원칙

  1. 캡슐화(Encapsulation)
  • 데이터와 메서드를 하나로 묶음
  • 접근 제어자로 내부 구현 숨김
  • 예: private 필드 + public 메서드
  1. 상속(Inheritance)
  • 기존 클래스를 확장
  • 코드 재사용
  • extends 키워드 사용
  1. 다형성(Polymorphism)
  • 하나의 인터페이스로 여러 구현 사용
  • 오버라이딩, 오버로딩
  • 런타임 다형성(동적 바인딩)
  1. 추상화(Abstraction)
  • 핵심만 추출
  • 인터페이스, 추상 클래스 사용

접근 제어자

  • private: 같은 클래스 내부
  • default: 같은 패키지
  • protected: 같은 패키지 + 상속 관계
  • public: 모든 곳

컬렉션 프레임워크

HashMap과 HashSet 동작원리

HashMap 동작 원리

HashMap은 해시 테이블 기반의 키-값 저장 구조입니다.

HashMap의 내부 구조:

// Java 8+ 기준
transient Node<K,V>[] table;  // 버킷 배열
static class Node<K,V> {    
	final int hash;    
	final K key;    
	V value;    
	Node<K,V> next;  // LinkedList 연결
}

해시 함수와 인덱스 계산:

// 해시값 계산
int hash = key.hashCode();
// 인덱스 계산 (비트 연산 사용)
int index = (table.length - 1) & hash;

2의 배수로 리사이즈하는 이유:

  • (n - 1) & hash 연산을 효율적으로 수행
  • n이 2의 배수면 n - 1이 이진수로 111...111 형태
  • 예: 16 - 1 = 15 = 1111(2)
  • & 연산으로 하위 비트만 추출해 모듈로 연산과 동일한 효과
  • % 연산보다 빠름

해시 충돌 처리:
1. Separate Chaining

  • 같은 버킷에 LinkedList로 연결
  • Java 8 이전: 항상 LinkedList
  1. Treeify (Java 8+)
  • 버킷의 노드가 8개 이상이면 Red-Black Tree로 변환
  • 버킷의 노드가 6개 이하로 줄어들면 다시 LinkedList로 변환
  • 이유: 작은 데이터는 LinkedList가 효율적, 큰 데이터는 Tree가 효율적

리사이즈 과정:

// 기본 초기 용량: 16
// 로드 팩터: 0.75 (75% 채워지면 리사이즈)
// 리사이즈: 기존 크기의 2배 (16 → 32 → 64 → ...)

// 리사이즈 시 재해싱
// 기존: index = hash & (16 - 1) = hash & 1111
// 신규: index = hash & (32 - 1) = hash & 11111
// 추가 비트로 인해 인덱스가 변경될 수 있음

HashMap의 성능:

  • 평균 시간 복잡도: O(1)
  • 최악 시간 복잡도: O(log n) - Tree 구조일 때
  • 해시 함수 품질이 성능에 영향

HashMap 사용 시 주의사항:
1. 키 객체는 equals()와 hashCode()를 올바르게 구현
2. 불변 객체를 키로 사용 권장
3. 초기 용량과 로드 팩터 고려

HashSet 동작 원리

HashSet은 HashMap을 기반으로 구현됩니다.

HashSet의 내부 구현:

private transient HashMap<E,Object> map;
private static final Object PRESENT = new Object();

public boolean add(E e) {    
	return map.put(e, PRESENT) == null;
}

HashSet의 특징:

  • 중복 불가 (HashMap의 키 특성 활용)
  • 순서 보장 안 함 (LinkedHashSet은 순서 보장)
  • null 허용
  • HashMap과 동일한 해시 충돌 처리 메커니즘 사용

다른 주요 컬렉션
ArrayList:

  • 동적 배열
  • 인덱스 기반 접근 O(1)
  • 중간 삽입/삭제 O(n)
  • 리사이즈 시 기존 배열의 1.5배 크기로 확장

LinkedList:

  • 이중 연결 리스트
  • 삽입/삭제 O(1) (위치를 알고 있을 때)
  • 검색 O(n)
  • 메모리 오버헤드 큼 (포인터 저장)

TreeMap:

  • Red-Black Tree 기반
  • 키 정렬 보장
  • 검색/삽입/삭제 O(log n)

ConcurrentHashMap:

  • 스레드 안전한 HashMap
  • 세그먼트 기반 잠금 (Java 8 이전)
  • CAS 기반 동기화 (Java 8+)
  • 읽기는 락 없이 수행

동시성 프로그래밍

synchronized

synchronized의 동작:

  • 모니터 락 획득/해제
  • 메서드/블록 단위 동기화
  • 재진입 가능 (같은 스레드가 다시 획득 가능)

synchronized 사용:

// 메서드 동기화
public synchronized void method() { }

// 블록 동기화
synchronized (object) { }

// 정적 메서드 동기화 (클래스 락)
public static synchronized void method() { }

synchronized의 한계:

  • 블로킹 방식
  • 데드락 가능성
  • 성능 오버헤드

예외처리

예외 계층 구조
Throwable
├── Error (시스템 레벨 오류)
│   ├── OutOfMemoryError
│   └── StackOverflowError
└── Exception
	├── RuntimeException (Unchecked Exception)    
	│   ├── NullPointerException    
	│   ├── IllegalArgumentException    
	│   └── IndexOutOfBoundsException    
	└── Checked Exception        
		├── IOException        
		└── SQLException

Checked vs Unchecked Exception

Checked Exception:

  • 컴파일 타임에 체크
  • 반드시 처리해야 함 (try-catch 또는 throws)
  • 예: IOException, SQLException

Unchecked Exception:

  • 런타임에 발생
  • 처리 선택적
  • 예: NullPointerException,IllegalArgumentException

제네릭(Generics)

제네릭의 필요성

타입 안전성:

  • 컴파일 타임에 타입 체크
  • 런타임 ClassCastException 방지

코드 재사용:

  • 타입별로 클래스를 만들 필요 없음

제네릭 사용법

// 클래스 제네릭
class Box<T> {
	private T item;
    public void setItem(T item) { this.item = item; }
    public T getItem() { return item; }
}
    
// 메서드 제네릭
public <T> T getFirst(List<T> list) {
	return list.get(0);
}

// 와일드카드
List<? extends Number>  // 상한 제한
List<? super Integer>   // 하한 제한

타입 소거(Type Erasure)

  • 컴파일 타임에만 존재
  • 런타임에는 제네릭 정보가 사라짐
  • 제한: new T(), instanceof T 불가

람다와 스트림

람다 표현식
함수형 인터페이스:

  • 단일 추상 메서드를 가진 인터페이스
  • @FunctionalInterface 어노테이션
  • 예: Function, Predicate, Consumer, Supplier

스트림 API
스트림의 특징:

  • 선언형 프로그래밍
  • 파이프라인 처리
  • 지연 평가 (Lazy Evaluation)
  • 병렬 처리 지원

스트림 연산:

// 중간 연산 (Lazy)filter(), map(), sorted(), distinct()
// 최종 연산 (Eager)forEach(), collect(), reduce(), count()

스트림 사용 예:
list.stream()
	.filter(x -> x > 10)
    .map(x -> x * 2)
    .sorted()
    .collect(Collectors.toList());

JIT 컴파일

인터프리터 vs JIT:

  • 인터프리터: 즉시 실행, 느림
  • JIT: 자주 사용되는 코드를 네이티브 코드로 컴파일
  • HotSpot: 자주 사용되는 부분(Hot Spot)을 컴파일

최적화 기법:

  • 인라인화
  • 루프 최적화
  • 데드 코드 제거

메모리 튜닝
힙 크기 설정:

  • -Xms: 초기 힙 크기
  • -Xmx: 최대 힙 크기
  • -XX:NewRatio: Young/Old 비율

GC 튜닝:

  • GC 알고리즘 선택
  • GC 로그 분석
  • 메모리 프로파일링

4. 관계형 데이터베이스

트랜잭션

트랜잭션-격리레벨 내용정리 블로그

트랜잭션이란?
트랜잭션은 데이터베이스의 논리적 작업 단위로, 모두 성공하거나 모두 실패해야 합니다(All or Nothing).

트랜잭션의 필요성:

  • 데이터 일관성 보장
  • 동시성 제어
  • 장애 복구

트랜잭션 예시:

-- 계좌 이체 예시
BEGIN TRANSACTION;
	UPDATE Account SET balance = balance - 1000 WHERE id = 1;
	UPDATE Account SET balance = balance + 1000 WHERE id = 2;
COMMIT;
-- 둘 다 성공하거나 둘 다 실패해야 함

트랜잭션 특징 (ACID)

  1. 원자성 (Atomicity)
  • 모두 성공하거나 모두 실패
  • 중간 상태 불허
  • 구현: Undo Log를 통한 롤백
  1. 일관성 (Consistency)
  • 트랜잭션 전후 데이터베이스가 일관된 상태
  • 제약조건, 비즈니스 규칙 준수
  1. 격리성 (Isolation)
  • 동시 실행 트랜잭션이 서로 간섭하지 않음
  • 격리 수준으로 제어
  1. 지속성 (Durability)
  • 커밋된 변경은 영구 저장
  • 구현: Redo Log를 통한 복구

트랜잭션 격리 수준

  1. READ UNCOMMITTED
  • 커밋되지 않은 데이터 읽기 가능
  • Dirty Read 발생
  • 성능은 높지만 일관성 낮음
  1. READ COMMITTED
  • 커밋된 데이터만 읽기
  • Dirty Read 방지
  • Non-Repeatable Read 발생 가능
  • 대부분의 DBMS 기본값
  1. REPEATABLE READ
  • 같은 트랜잭션 내 동일한 읽기 결과 보장
  • Dirty Read, Non-Repeatable Read 방지
  • Phantom Read 발생 가능
  • MySQL InnoDB 기본값
  1. SERIALIZABLE
  • 완전한 직렬화
  • 모든 이상 현상 방지
  • 성능 저하 가능

격리 수준별 발생 가능한 문제:

격리 수준Dirty ReadNon-Repeatable ReadPhantom Read
READ UNCOMMITTED가능가능가능
READ COMMITTED불가능가능가능
REPEATABLE READ불가능불가능가능
SERIALIZABLE불가능불가능불가능

Undo Log와 Redo Log
Redo Log (재실행 로그):

  • 변경 후 상태를 기록
  • 커밋된 변경을 복구
  • 지속성 보장
  • 순차 쓰기로 성능 유리

Redo Log 동작:

1. 트랜잭션이 데이터 변경
2. 변경 내용을 Redo Log에 기록 (WAL: Write-Ahead Logging)
3. 메모리 버퍼에 변경 사항 반영
4. 커밋 시 Redo Log를 디스크에 플러시
5. 장애 발생 시 Redo Log를 재실행하여 복구

Undo Log (취소 로그):

  • 변경 전 상태를 기록
  • 롤백 및 일관된 읽기 지원
  • 원자성 보장

Undo Log 동작:

1. 트랜잭션이 데이터 변경 전 상태를 Undo Log에 기록
2. 데이터 변경 수행
3. 롤백 시 Undo Log를 역순으로 적용하여 원상복구
4. MVCC에서 과거 버전 재구성에 사용

차이점 요약:

구분Redo LogUndo Log
목적복구 (Recovery)롤백 (Rollback)
내용변경 후 상태변경 전 상태
방향순방향 재실행역방향 복원
사용커밋 후 장애 복구롤백, MVCC

Non-Blocking Consistent Read
개념:

  • REPEATABLE READ 또는 READ COMMITTED에서 적용
  • SELECT가 데이터 스냅샷을 읽어 쓰기 작업에 블로킹되지 않음
  • 핵심 기술: MVCC (Multi-Version Concurrency Control)

일관된 읽기 (Consistent Read):

  • 트랜잭션 시작 시점의 스냅샷을 읽음
  • 다른 트랜잭션의 커밋 여부와 무관하게 일관된 결과 제공

MVCC 동작 원리:

1. 각 행에 버전 정보 저장 (트랜잭션 ID, 타임스탬프 등)
2. 트랜잭션 시작 시 Read View 생성
3. 읽기 시 자신보다 이전에 커밋된 버전만 읽음
4. 쓰기 시 새로운 버전 생성
5. Undo Log를 통해 과거 버전 재구성

예시:

-- 트랜잭션 A (시작 시간: T1)
BEGIN;
SELECT * FROM users WHERE id = 1;  -- 결과: name='John'

-- 트랜잭션 B (시작 시간: T2, T1 < T2)
BEGIN;
UPDATE users SET name='Jane' WHERE id = 1;
COMMIT;

-- 트랜잭션 A에서 다시 조회
SELECT * FROM users WHERE id = 1;  -- 결과: name='John' (스냅샷 읽기)
COMMIT;

장점:

  • 읽기 성능 향상 (블로킹 없음)
  • 동시성 향상
  • 일관된 읽기 보장

단점:

  • 버전 관리 오버헤드
  • Undo Log 공간 사용
  • 오래된 버전 정리 필요

데이터 버전과 스냅샷
데이터 버전:

  • 각 행의 여러 버전을 유지
  • 버전 식별: 트랜잭션 ID, 타임스탬프
  • Undo Log로 과거 버전 재구성

데이터 스냅샷:

  • 트랜잭션 시작 시점의 데이터베이스 상태
  • Read View로 관리
  • 트랜잭션 내 일관된 읽기 보장

Read View 구성 요소:

  • creator_trx_id: Read View를 생성한 트랜잭션 ID
  • m_ids: 생성 시점의 활성 트랜잭션 ID 목록
  • min_trx_id: 최소 트랜잭션 ID
  • max_trx_id: 최대 트랜잭션 ID

버전 가시성 판단:

행의 버전이 보이는지 판단:
1. creator_trx_id와 같으면 → 보임 (자신이 생성)
2. min_trx_id보다 작고 m_ids에 없으면 → 보임 (이미 커밋)
3. max_trx_id보다 크면 → 안 보임 (미래)
4. m_ids에 있으면 → 안 보임 (아직 커밋 안 됨)

LOCK

LOCK 내용정리 블로그

락의 필요성
경쟁 조건 (Race Condition):

  • 동시 접근으로 인한 데이터 불일치
  • 예: 잔액 이체 시 동시 업데이트

락의 목적:

  • 동시성 제어
  • 데이터 일관성 보장
  • 동시 실행 트랜잭션 간 충돌 방지

락의 종류

  1. 공유 락 (Shared Lock, S-Lock)
  • 읽기 락
  • 여러 트랜잭션이 동시에 획득 가능
  • 배타 락과 호환되지 않음
  1. 배타 락 (Exclusive Lock, X-Lock)
  • 쓰기 락
  • 한 트랜잭션만 획득 가능
  • 다른 모든 락과 호환되지 않음

락 호환성 매트릭스:

S-LockX-Lock
S-Lock호환비호환
X-Lock비호환비호환

락의 범위 (Lock Granularity)

  1. 행 락 (Row Lock)
  • 특정 행만 잠금
  • 동시성 높음
  • 락 관리 오버헤드 큼
  1. 페이지 락 (Page Lock)
  • 페이지 단위 잠금
  • 행 락과 테이블 락의 중간
  1. 테이블 락 (Table Lock)
  • 전체 테이블 잠금
  • 동시성 낮음
  • 락 관리 오버헤드 작음
  1. 데이터베이스 락 (Database Lock)
  • 전체 데이터베이스 잠금
  • 드물게 사용

데드락 (Deadlock)

데드락 발생 조건:
1. 상호 배제: 자원이 배타적
2. 점유 대기: 자원을 보유한 채 대기
3. 비선점: 자원을 강제로 빼앗을 수 없음
4. 순환 대기: 순환 형태의 대기 체인

데드락 예시:

트랜잭션 A: Row 1 락 획득 → Row 2 락 대기
트랜잭션 B: Row 2 락 획득 → Row 1 락 대기
→ 순환 대기 발생 (데드락)

데드락 처리 기법

  1. 예방 기법 (Deadlock Prevention)
  • 데드락 발생 조건 중 하나를 제거
  • 비효율적일 수 있음
  1. 회피 기법 (Deadlock Avoidance)
  • 자원 할당 전 안전성 검사
  • 은행원 알고리즘 등
  1. 탐지 및 복구 (Deadlock Detection & Recovery)
  • 주기적으로 데드락 탐지
  • 발생 시 한 트랜잭션 롤백
  1. 무시 (Deadlock Ignorance)
  • 발생 빈도가 낮으면 무시
  • 대부분의 DBMS가 사용

락 타임아웃
타임아웃 설정:

  • 락 대기 시간 제한
  • 타임아웃 시 에러 반환 또는 롤백
  • 무한 대기 방지

타임아웃 처리:

-- MySQL 예시
SET innodb_lock_wait_timeout = 50;  -- 50초 대기 후 타임아웃

낙관적 락 vs 비관적 락
비관적 락 (Pessimistic Lock):

  • 충돌을 가정하고 미리 락 획득
  • SELECT ... FOR UPDATE
  • 충돌이 많을 때 유리

낙관적 락 (Optimistic Lock):

  • 락 없이 읽고, 쓰기 시 버전 체크
  • 버전 불일치 시 실패
  • 충돌이 적을 때 유리

낙관적 락 구현:

-- 버전 컬럼 사용
UPDATE users 
SET name = 'John', version = version + 1
WHERE id = 1 AND version = 5;

-- 영향받은 행이 0이면 버전 충돌 (다른 트랜잭션이 먼저 수정)

인덱스와 락

인덱스 락:

  • 인덱스에도 락 적용
  • Next-Key Lock: 인덱스 레코드 + 갭 락
  • Phantom Read 방지

갭 락 (Gap Lock):

  • 인덱스 레코드 사이의 간격 잠금
  • 새로운 행 삽입 방지
  • REPEATABLE READ에서 사용

Next-Key Lock:

  • 레코드 락 + 갭 락
  • 인덱스 범위 스캔 시 적용
  • Phantom Read 방지

락 최적화 전략

  1. 락 범위 최소화
  • 필요한 행만 잠금
  • 트랜잭션 시간 최소화
  1. 인덱스 활용
  • 인덱스로 스캔 범위 축소
  • 락 범위 축소
  1. 일관된 락 순서
  • 데드락 방지
  • 항상 같은 순서로 락 획득
  1. 낙관적 락 고려
  • 충돌이 적을 때 사용
  • 성능 향상
  1. 락 타임아웃 설정
  • 무한 대기 방지
  • 적절한 타임아웃 값 설정

CAP

CAP 이론의 개념
CAP 이론은 분산 시스템에서 다음 세 가지를 동시에 만족할 수 없음을 설명합니다.

C (Consistency) - 일관성:

  • 모든 노드가 동시에 같은 데이터를 봄
  • 강한 일관성

A (Availability) - 가용성:

  • 모든 요청에 응답
  • 일부 노드 장애 시에도 서비스 지속

P (Partition Tolerance) - 분할 허용성:

  • 네트워크 분할 시에도 동작
  • 현실적으로 필수

CAP 정리의 의미
핵심 원리:

  • 분할이 발생하면 C와 A 중 하나를 선택해야 함
  • P는 현실적으로 필수이므로, CP 또는 AP 중 선택

CP 시스템 (Consistency + Partition Tolerance):

  • 일관성 우선
  • 분할 시 가용성 포기
  • 예: 전통적인 RDBMS (분산 환경), MongoDB (강한 일관성 모드)

AP 시스템 (Availability + Partition Tolerance):

  • 가용성 우선
  • 분할 시 일관성 포기 (최종 일관성)
  • 예: Cassandra, DynamoDB, CouchDB

CA 시스템 (Consistency + Availability):

  • 분할이 없는 환경에서만 가능
  • 단일 노드 시스템
  • 현실적으로 분할은 불가피하므로 실제로는 CA 불가

일관성의 종류
강한 일관성 (Strong Consistency):

  • 모든 읽기가 최신 쓰기 결과를 반환
  • CP 시스템의 특징

최종 일관성 (Eventual Consistency):

  • 시간이 지나면 일관된 상태로 수렴
  • AP 시스템의 특징
  • 예: DNS, CDN

약한 일관성 (Weak Consistency):

  • 일관성 보장 없음
  • 거의 사용하지 않음

CAP 이론의 한계
실제 시스템의 복잡성:

  • CAP는 이분법적이지만 실제는 그레이드가 있음
  • 일관성과 가용성의 트레이드오프

CAP 이론의 실제 적용
관계형 데이터베이스:

  • 전통적으로 CP 지향
  • 분산 환경에서 가용성 저하 가능
  • 예: MySQL Cluster, PostgreSQL (동기 복제)

NoSQL 데이터베이스:

  • 대부분 AP 지향
  • 최종 일관성 수용
  • 예: Cassandra, DynamoDB

하이브리드 접근:

  • 상황에 따라 일관성 수준 조정
  • 예: MongoDB (일관성 수준 설정 가능)

CAP 이론과 데이터베이스 선택
CP가 적합한 경우:

  • 금융 거래, 재고 관리 등 정확성 중요
  • 강한 일관성 필요

AP가 적합한 경우:

  • 소셜 미디어, 콘텐츠 배포 등
  • 가용성과 확장성 중요
  • 최종 일관성 허용 가능

실무 고려사항:

  • CAP만으로 선택하지 않음
  • 성능, 확장성, 운영 복잡도 등 종합 고려
  • 마이크로서비스 아키텍처에서 서비스별로 다른 선택 가능

5. 캐싱

캐싱이란?
캐싱은 자주 사용하는 데이터를 빠른 저장소에 보관해 응답 속도를 높이는 기법입니다.

캐싱의 목적:

  • 응답 시간 단축
  • 데이터베이스 부하 감소
  • 네트워크 트래픽 감소
  • 비용 절감

캐싱의 원리:

  • 시간 지역성: 최근 사용한 데이터를 다시 사용할 가능성
  • 공간 지역성: 인접한 데이터를 사용할 가능성

캐시 계층 구조

  1. L1 캐시 (CPU 레지스터)
  • 가장 빠르고 작음
  • CPU 내부
  1. L2/L3 캐시 (CPU 캐시)
  • 메모리보다 빠름
  • CPU와 메모리 사이
  1. 메모리 캐시 (애플리케이션 캐시)
  • 애플리케이션 레벨
  • 예: Redis, Memcached
  1. 디스크 캐시
  • 디스크 I/O 최적화
  • OS 페이지 캐시
  1. 네트워크 캐시 (CDN)
  • 지리적 분산
  • 사용자와 가까운 위치에 콘텐츠 제공

캐시 전략

  1. Cache-Aside (Lazy Loading)
1. 애플리케이션이 캐시 확인
2. 캐시 미스 시 DB 조회
3. DB 결과를 캐시에 저장
4. 결과 반환
  • 장점: 캐시 장애 시에도 동작
  • 단점: 캐시 미스 시 지연
  1. Write-Through
1. 데이터를 캐시와 DB에 동시에 쓰기2. 항상 캐시와 DB 동기화
  • 장점: 일관성 보장
  • 단점: 쓰기 지연 증가
  1. Write-Behind (Write-Back)
1. 데이터를 캐시에만 먼저 쓰기
2. 비동기로 DB에 쓰기
  • 장점: 쓰기 성능 향상
  • 단점: 데이터 손실 위험
  1. Refresh-Ahead
1. 캐시 만료 전에 미리 갱신
2. 사용자 요청 전에 백그라운드 갱신
  • 장점: 캐시 미스 감소
  • 단점: 불필요한 갱신 가능

Redis

Redis(Remote Dictionary Server)는 인메모리 키-값 저장소입니다.

Redis의 특징:

  • 인메모리 저장으로 빠른 속도
  • 다양한 데이터 구조 지원
  • 영속성 옵션 제공
  • 단일 스레드 모델로 원자성 보장

Redis의 주요 용도:

  • 캐싱
  • 세션 저장소
  • 메시지 큐
  • 분산 락

Redis 데이터 구조

  1. String
  • 가장 기본적인 타입
  • 문자열, 숫자, 바이너리 데이터 저장
  • 예: SET key value, GET key
  1. List
  • 순서가 있는 문자열 리스트
  • 양방향 큐로 사용 가능
  • 예: LPUSH, RPUSH, LPOP, RPOP
  1. Set
  • 중복 없는 문자열 집합
  • 집합 연산 지원
  • 예: SADD, SMEMBERS, SINTER
  1. Sorted Set
  • 점수로 정렬된 집합
  • 순위표 구현에 적합
  • 예: ZADD, ZRANGE, ZREVRANGE
  1. Hash
  • 필드-값 쌍의 집합
  • 객체 표현에 적합
  • 예: HSET, HGET, HGETALL
  1. Bitmap
  • 비트 연산 지원
  • 예: 사용자 활동 추적
  1. HyperLogLog
  • 대략적인 카디널리티 계산
  • 메모리 효율적
  • 예: 고유 방문자 수 추정

Redis 영속성

  1. RDB (Redis Database Backup)
  • 특정 시점의 스냅샷 저장
  • 포크된 자식 프로세스로 저장
  • 장점: 빠른 복구, 파일 크기 작음
  • 단점: 마지막 스냅샷 이후 데이터 손실 가능

RDB 설정:

save 900 1      # 900초 동안 1개 이상 변경 시 저장
save 300 10     # 300초 동안 10개 이상 변경 시 저장
save 60 10000   # 60초 동안 10000개 이상 변경 시 저장
  1. AOF (Append Only File)
  • 모든 쓰기 명령을 로그 파일에 기록
  • 장점: 데이터 손실 최소화
  • 단점: 파일 크기 큼, 복구 시간 길 수 있음

AOF 설정:

appendonly yes
appendfsync everysec  # 매초마다 디스크에 동기화
  1. 하이브리드 방식
  • RDB + AOF 동시 사용
  • RDB로 빠른 복구, AOF로 최신 데이터 보장

Redis 메모리 관리
메모리 제한:

maxmemory 2gb
maxmemory-policy allkeys-lru  # LRU 정책으로 키 제거

제거 정책 (Eviction Policy):

  • noeviction: 메모리 초과 시 오류 반환
  • allkeys-lru: 모든 키 중 LRU로 제거
  • volatile-lru: 만료 시간이 있는 키 중 LRU로 제거
  • allkeys-lfu: 모든 키 중 LFU로 제거
  • volatile-lfu: 만료 시간이 있는 키 중 LFU로 제거
  • allkeys-random: 모든 키 중 랜덤 제거
  • volatile-random: 만료 시간이 있는 키 중 랜덤 제거
  • volatile-ttl: 만료 시간이 짧은 키부터 제거

LRU vs LFU:

  • LRU (Least Recently Used): 최근 사용 시간 기준
  • LFU (Least Frequently Used): 사용 빈도 기준

Redis 클러스터링
1. Redis Sentinel

  • 고가용성 제공
  • 마스터-슬레이브 구성
  • 자동 장애 조치
  • 3개 이상의 Sentinel 노드 권장

Sentinel 동작:

1. Sentinel이 마스터와 슬레이브 모니터링
2. 마스터 장애 감지
3. 쿼럼(과반수) 달성 시 장애 조치
4. 슬레이브를 마스터로 승격
5. 클라이언트에 새 마스터 정보 전달
  1. Redis Cluster
  • 수평 확장 지원
  • 샤딩 자동 처리
  • 최소 3개 마스터 노드 필요

Cluster 샤딩:

  • 해시 슬롯(Hash Slot) 방식
  • 16384개의 슬롯을 노드에 분배
  • 키의 CRC16 해시값을 슬롯에 매핑

Cluster 라우팅:

1. 클라이언트가 키의 해시 슬롯 계산
2. 해당 슬롯을 가진 노드로 요청
3. 노드가 다른 노드에 있으면 MOVED 에러와 함께 올바른 노드 정보 반환
4. 클라이언트가 새 노드로 재요청

Redis 분산 락
기본 구현:

-- SET key value NX EX timeoutS
ET lock_key unique_value NX EX 30

문제점:

  • 타임아웃 설정의 어려움
  • 락 해제 시 다른 프로세스가 해제할 수 있음

개선된 구현 (Redlock 알고리즘):

1. 현재 시간 기록
2. N개 Redis 인스턴스에 순차적으로 락 획득 시도
3. 과반수 이상 획득 성공 시 락 획득
4. 락 유효 시간 = TTL - (현재 시간 - 시작 시간) - 클럭 드리프트
5. 락 해제 시 모든 인스턴스에서 해제

주의사항:

  • 클럭 동기화 필요
  • 네트워크 지연 고려
  • 락 갱신 메커니즘 필요

Redis 트랜잭션

MULTI/EXEC:
MULTISET key1 value1SET key2 value2EXEC
  • 원자성 보장
  • 롤백 없음 (명령 실행 중 오류 발생 시 계속 진행)
  • 다른 클라이언트의 명령과 섞이지 않음

WATCH:

  • 낙관적 락 구현
  • WATCH한 키가 변경되면 EXEC 실패

CDN

CDN(Content Delivery Network)은 지리적으로 분산된 서버 네트워크로, 사용자와 가까운 위치에서 콘텐츠를 제공합니다.

CDN의 목적:

  • 지연 시간 감소
  • 대역폭 비용 절감
  • 원본 서버 부하 감소
  • 가용성 향상

CDN의 동작 원리:

1. 사용자가 웹사이트 요청
2. DNS가 사용자와 가장 가까운 CDN 엣지 서버 반환
3. 엣지 서버가 캐시 확인
4. 캐시 히트 시 즉시 제공
5. 캐시 미스 시 원본 서버에서 가져와 캐시 후 제공

CDN 아키텍처

  1. 엣지 서버 (Edge Server)
  • 사용자와 가장 가까운 서버
  • 콘텐츠 캐싱 및 제공
  • 전 세계에 분산 배치
  1. 오리진 서버 (Origin Server)
  • 원본 콘텐츠를 저장하는 서버
  • 엣지 서버의 소스
  1. 중간 계층 (Mid-tier)
  • 대규모 CDN에서 사용
  • 엣지와 오리진 사이의 중간 캐시

CDN 캐싱 전략

  1. 정적 콘텐츠 캐싱:
  • 이미지, CSS, JavaScript 등
  • TTL(Time To Live) 설정
  • 예: 24시간, 1주일 등
  1. 동적 콘텐츠 캐싱:
  • API 응답 등
  • 짧은 TTL 또는 조건부 캐싱
  • 예: 5분, 1시간
  1. 캐시 키 전략:
  • URL 기반
  • 쿼리 파라미터 포함 여부 결정
  • 예: ?v=1.0 버전 파라미터

CDN 캐시 무효화

  1. TTL 기반:
  • 자동 만료
  • 설정된 시간 후 자동 갱신
  1. 수동 무효화:
  • CDN 제공업체 API 사용
  • 특정 URL 또는 경로 무효화
  • 즉시 반영
  1. 버전 관리:
  • 파일명에 버전 포함
  • 예: style.v2.css
  • 자동 무효화 효과
  1. 캐시 버스팅:
  • 쿼리 파라미터 사용
  • 예: ?v=timestamp
  • 캐시 히트율 저하 가능

CDN 사용 사례

  1. 정적 웹사이트:
  • HTML, CSS, JavaScript
  • 긴 TTL 설정
  • 높은 캐시 히트율
  1. 미디어 스트리밍:
  • 비디오, 오디오 파일
  • 대용량 파일 최적화
  • 부분 다운로드 지원
  1. API 가속:
  • API 응답 캐싱
  • 짧은 TTL
  • 조건부 캐싱
  1. 소프트웨어 배포:
  • 설치 파일, 업데이트 패키지
  • 글로벌 배포 최적화

CDN vs Redis 비교

구분CDNRedis
용도정적 콘텐츠 배포동적 데이터 캐싱
위치전 세계 분산애플리케이션 서버 근처
데이터 타입파일, 미디어구조화된 데이터
TTL보통 길음 (시간~일)보통 짧음 (초~분)
무효화수동 또는 TTL프로그래밍 방식
비용트래픽 기반메모리 기반

캐싱 전략 통합

다층 캐싱:

사용자 → CDN → 애플리케이션 캐시(Redis) → 데이터베이스

각 계층의 역할:

  • CDN: 정적 콘텐츠, 긴 TTL
  • Redis: 동적 데이터, 짧은 TTL
  • 데이터베이스: 원본 데이터

캐시 일관성:

  • Write-Through: 쓰기 시 모든 계층 갱신
  • Cache-Aside: 읽기 시 계층별로 확인
  • TTL 기반: 자동 만료로 일관성 유지
profile
Jake
이전 포스트

Jenkins-Kaniko 파이프라인 설계 선택 흐름

다음 포스트

빗썸 60조 비트코인 오지급 사건

0개의 댓글