Racon

1. 전송 방식HTTP/1.1 → 사람이 읽을 수 있는 텍스트 기반 프로토콜HTTP/2 → 네트워크 효율성을 위해 바이너리 프레임 단위로 데이터 전송텍스트 기반은 디버깅이 쉽지만, 성능상 불리합니다. 반면 바이너리 기반은 가볍고 파싱 속도가 빠릅니다.2. 동시성 (멀티플렉싱)HTTP/1.1 → 한 TCP 연결에서 요청/응답이 순차적으로만 처리됩니다.하나의 요청이 느리면 뒤의 요청이 모두 대기해야 하는 HOL(Head Of Line) Blocking 문제가 발생합니다.HTTP/2 → 멀티플렉싱 지원으로 하나의 연결에서도 여러 요청/응답을 병렬로 처리할 수 있습니다.예시:HTTP/1.1 → HTML → (대기) → CSS → (대기) → JSHTTP/2 → HTML, CSS, JS 를 동시에 내려줌3. 헤더..

1. 롤링 배포 (Rolling Deployment)설명 점진적 업데이트: 전체 시스템을 한 번에 교체하지 않고, 일부 인스턴스씩 새 버전으로 바꿔가며 배포 방식: 기존 인스턴스를 하나씩 종료하고, 새 버전을 띄운 뒤 다음 인스턴스로 넘어감 장점 무중단 배포: 일부 인스턴스만 교체하므로 서비스 중단 없음 리소스 효율: 한꺼번에 모든 인스턴스를 업데이트하지 않아도 됨 단점 상태 불일치: 구버전·신버전이 공존하므로 호환성 주의 롤백 어려움: 혼재된 상태에서 문제 원인 파악 및 복구가 복잡 배포 흐름 시간 →ABCD1구 → 신구구구2신구 → 신구구3신신구 → 신구4신신신구 → 신2. 블루-그린 배포 (Blue-Green Deployment)설명 두 환경(Blue/Green)을 운영하여, 한..

📣 Pub/Sub 이란?📌 정의Pub/Sub (Publish / Subscribe)는 메시지 송신자(발행자)와 수신자(구독자)가 직접 연결되지 않고, 중간 매개체(채널)를 통해 메시지를 주고받는 비동기 메시징 모델입니다.📦 Messaging Middleware 사용 장점특징설명비동기 처리송신자/수신자가 동시에 작동하지 않아도 메시지를 처리할 수 있음낮은 결합도발신자/수신자는 서로를 몰라도 메시지를 주고받을 수 있음탄력성한쪽 장애 발생 시 전체 시스템 영향 최소화대표적인 메시징 미들웨어: Kafka, RabbitMQ, ActiveMQ🧠 Redis Pub/Sub 개념항목설명메시지 저장 안됨Queue 저장 없이 실시간으로 전달됨실시간 연결 필요온라인 상태인 Subscriber에게만 전송됨Push 방식메..

🔃 캐싱(Caching)🧠 캐시란?Cache: 자주 사용하는 데이터를 미리 복사해 저장하는 임시 저장소원본 데이터에 대한 접근 횟수를 줄여 성능을 향상Cache의 데이터는 언제든 사라질 수 있음 → 원본이 아님🛠 캐시의 적용 효과네트워크 지연 감소서버 리소스 절약병목 현상 감소📌 원칙: 더 빠르고 값싸게 데이터를 가져올 수 있다면 캐시를 사용한다.🧩 캐싱 관련 용어용어설명Cache Hit캐시에 데이터가 존재하여 바로 반환되는 경우Cache Miss캐시에 데이터가 없어 원본에서 가져와야 하는 경우Eviction Policy캐시 공간 확보를 위해 데이터를 삭제하는 정책캐싱 전략데이터를 언제/어떻게 캐시에 쓰고 읽을지 정하는 방식 (Cache-Aside, Write-Through 등)📚 캐싱 전략1..

🧭 서버에서의 세션 관리 역할Spring Boot는 기본적으로 아래와 같은 세션 흐름을 관리합니다.세션 생성클라이언트 요청 시 세션이 없으면 서버가 새로운 세션 생성응답에 Set-Cookie: JSESSIONID=... 헤더로 세션 ID를 전달세션 이용이후 요청 시 JSESSIONID 쿠키를 기반으로 세션을 조회하여 해당 사용자 정보 접근세션 삭제일정 시간 동안 요청이 없거나, 명시적으로 로그아웃하면 세션 무효화모든 요청에 대해 서버는 쿠키에서 JSESSIONID를 파싱하여 처리합니다.⚙️ 세션 관리를 쉽게 해주는 도구: HttpSession✔️ 특징Java Servlet API에서 제공하는 세션 인터페이스Spring Boot에서도 그대로 사용 가능세션 ID는 UUID로 생성되며, JSESSIONID라..

🌐 Session 개념 및 분산 환경 처리🧾 Session 정의네트워크 상에서 두 개 이상의 통신 장치 간에 유지되는 상호 연결 상태일정 시간 동안 유지되는 정보를 세션이라 함사용 환경에 따라 의미가 달라짐예: 웹 브라우저 웹 서버 간 사용자 로그인 정보 유지🔐 Web 로그인 세션웹에서 사용자 인증 상태를 유지하기 위한 기술브라우저: 쿠키 저장서버: 쿠키에 해당하는 세션 정보를 저장로그아웃하거나 세션이 만료될 때까지 유지🖥️ Web 로그인 과정사용자가 로그인 요청을 보냄서버는 사용자 인증 후 세션 ID를 생성하고 저장생성된 세션 ID는 클라이언트의 쿠키에 포함되어 저장이후 요청 시, 쿠키에 포함된 세션 ID를 통해 인증 처리🔄 분산 환경에서의 세션 처리 이슈문제점서버가 여러 대인 경우, 세션 ..

동시성 제어 방법1. 게시물 컬럼 기반 구현게시물 테이블에 like_count 컬럼을 추가하여 직접 좋아요 수를 관리비관적 락 / 낙관적 락 적용 가능구성조회 시 컬럼만 읽어오면 됨 → 조회 성능 우수쓰기 시 게시물 레코드에 대한 경합 발생하나의 자원(게시물)을 두고 락 대기같은 회원이 하나의 게시물에 중복 좋아요 가능 → 로직 보완 필요2. 테이블 추가 기반 구현별도의 like_table (member_id, post_id)을 만들어 관리낙관적 락 / 비관적 락으로 제어하기 어려울 때 사용구성조회 시 매번 COUNT() 연산 → 조회 병목쓰기 시 경합 없이 insert만 발생 → 성능 우수회원 정보 등 다양한 정보 저장 가능 → 확장성 우수병목 발생 분석비교병목 위치설명컬럼 기반쓰기 병목하나의 레코드를..

동시성 제어 방식: 비관적 락 vs 낙관적 락🔒 비관적 락 (Pessimistic Lock)동시성 제어를 위한 가장 보편적인 방법락을 통한 줄세우기✅ 장점동시성 이슈를 DB에서 강제로 막기 때문에 안전함❌ 단점락을 통한 동시성 제어는 불필요한 대기 상태를 만듦동시성이 빈번하지 않은 쿼리에도 락이 걸려 다른 쿼리가 대기 상태가 됨락 범위가 커질수록 성능 저하 발생 (Connection Pool 고갈 가능성)💡 MySQL에서의 쓰기락 (Exclusive Lock) 예시START TRANSACTION;-- 특정 조건의 Row에 쓰기락을 건다SELECT *FROM postWHERE member_id = 2AND contents = 'v'FOR UPDATE;-- 작업이 끝난 후 커밋COMMIT;FOR UPDA..

MySQL 트랜잭션 테스트 및 락 확인 실습트랜잭션의 동작 방식과 SELECT ... FOR UPDATE 사용 시 어떤 레코드에 락이 걸리는지 확인하는 실습입니다.실습은 두 개의 SQL 클라이언트(또는 터미널)에서 동시에 실행하면서 테스트해야 합니다.✅ 트랜잭션 테스트 절차START TRANSACTION;으로 트랜잭션 시작SELECT ... FOR UPDATE로 쓰기 락 획득다른 세션에서 동일한 쿼리 실행 → 대기 현상 발생 확인COMMIT;으로 트랜잭션 종료 및 락 해제🔍 락 상태 확인 쿼리-- 현재 잡힌 레코드 락 확인SELECT * FROM performance_schema.data_locks WHERE LOCK_TYPE = 'RECORD';-- 트랜잭션 상태 확인SELECT * FROM info..

동시성 제어를 위한 가장 보편적인 방법락(Lock)을 통한 순차 실행 제어는 동시성 이슈를 해결하는 가장 기본적이고 보편적인 방식입니다.중요 ✅ 1: 락의 범위는 최소화해야 한다락이 걸린 동안 다른 트랜잭션은 대기 상태가 되므로, 락 범위가 넓으면 시스템 전체 성능이 저하됩니다.심한 경우 단일 스레드처럼 직렬 처리되는 상황이 발생할 수 있습니다.특히 Connection Pool을 사용하는 경우 락이 길어지면 풀 고갈로 인해 새로운 요청 자체가 블로킹됩니다.MySQL에서 락의 범위를 줄이는 방법MySQL은 트랜잭션의 종료 시점(커밋/롤백)에 락이 해제됩니다.따라서 트랜잭션의 길이 = 락의 유지 시간 입니다.트랜잭션 범위를 최소화하면 락 범위도 자연스럽게 줄어듭니다.예시: S3 업로드 같은 외부 작업은 트랜..