문질문질

클라이언트의 요청을 대신해서 서버에 전달하고,서버의 응답을 클라이언트에게 다시 전달하는 중개 서버 기능설명보안내부 IP 숨기기, 방화벽 역할캐싱자주 조회되는 리소스를 저장하여 응답 속도 향상로깅/감사누가 어떤 사이트에 접속했는지 기록 가능트래픽 제어제한된 대역폭 사용, 연결 제한IP 우회지역 제한 컨텐츠 접근 (VPN 역할 유사)로드 밸런싱여러 서버로 요청 분산 처리 (주로 Reverse Proxy) 1. Forward Proxy (정방향 프록시)클라이언트 쪽에 위치.클라이언트가 외부 서버에 접근할 때 프록시를 통해 우회.주로 보안, IP 차단 우회, 캐싱, 로깅에 사용.2. Reverse Proxy (역방향 프록시)서버 쪽에 위치.클라이언트는 서버의 실제 위치를 모르고, 프록시가 대신 응답.주로 로드 ..

동시 실행되는 여러 트랜잭션 간 데이터 충돌을 얼마나 방지할 것인지 결정하는 기준격리 수준이 높을수록 정합성은 높아지지만, 동시성 처리 능력과 성능은 떨어질 수 있다 특징 및 사용 상황격리 수준특징상황Read UncommittedDirty Read 허용, 빠름데이터 정합성이 크게 중요하지 않은 읽기 전용 로그, 통계용 쿼리 등Read CommittedDirty Read 방지일반적인 비즈니스 트랜잭션에서 사용 적합Repeatable ReadNon-Repeatable Read 방지정확한 값 유지가 중요한 계산Serializable모든 현상 방지, 느림가장 높은 데이터 정합성이 필요한 경우, 또는 경쟁 조건(race condition)을 엄격히 막아야 할 때 장점 및 Spring @Transactional o..

인덱싱 :데이터를 빠르게 찾고 정렬하기 위한 기술 트리 인덱스란?데이터를 트리 구조로 구성한 인덱스, 데이터가 정렬된 상태로 유지되며, 탐색(Search), 삽입(Insert), 삭제(Delete) 같은 연산을 빠르게 수행대부분의 관계형 데이터베이스(RDBMS)에서 사용되며, 데이터의 범위 검색, 정렬된 출력, 빠른 키 기반 검색에 유리 B-Tree 인덱스 구조균형 이진 트리를 확장한 구조로, 하나의 노드에 여러 개의 키와 자식 노드를 포함 트리의 모든 리프 노드는 같은 깊이노드는 key 값과 함께 자식 노드를 가리키는 포인터를 가지고 있음삽입과 삭제 시 트리가 자동으로 균형을 맞춤 검색할 때 범위를 반씩 줄여가며 O(log n) 시간 B+Tree 인덱스 구조B-Tree를 개선한 구조로, 실제 데이터를 ..

관계형 데이터베이스(PostgreSQL, MySQL ...)를 비동기 / 논블로킹 방식으로 사용하는 기술로 매우 심플함기존 Spring은 JPA + JDBC 조합의 블로킹이어서 WebFlux에 활용하기에 부적합 JPA vs R2DBC항목JPA (JDBC)R2DBC처리 방식동기, 블로킹비동기, 논블로킹스레드 낭비OXWebFlux와 궁합❌ 나쁨✅ 좋음Lazy 로딩, 더티체킹있음없음SQL 제어추상화직접 작성퍼포먼스 제어제한적내가 직접 가능 JPA와 다른 점 (R2DBC 특징)영속성 컨텍스트 없음 → 더티체킹, 자동 저장 XLazy 로딩 없음 → JOIN 직접 써야 함연관관계 자동 매핑 없음 → 객체 관계 대신 SQL 중심SQL 직접 작성해야 함 → 유연하지만, 코드도 많아짐String sql = """ ..

Spring WebFlux는 비동기(Async), 논블로킹(Non-blocking) 기반의 웹 프레임워크로, Spring 5부터 도입동시성이 높은 환경에서 적은 리소스로 많은 요청을 처리 왜? MVC와 WebFlux항목 Spring MVCSpring WebFlux처리 방식동기, 블로킹비동기, 논블로킹스레드 모델요청당 스레드 1개이벤트 루프 기반 (Netty 등)데이터 흐름객체 기반리액티브 스트림 (Mono, Flux)적합한 상황CPU 중심, 트래픽 적음I/O 중심, 동시성 많음 언제? 도입 배경 외부 API 여러 개를 병렬로 호출할 때실시간 데이터 처리 (SSE, WebSocket 등)대용량 파일 처리나 스트리밍이 필요할 때느린 외부 시스템과의 연동이 많은 서비스 어떻게? MVC → WebFlux 전환..

모든 컬럼이 인덱스 안에 포함되어 있어서, 테이블을 따로 읽지 않아도 되는 인덱스 Explain 시 Using index 또는 Index Only Scan 표시됨 장점속도 향상: 테이블 접근(IO) 생략 → 더 빠른 처리랜덤 I/O 감소: 특히 하드디스크 환경에서 효과적실행 계획 최적화: 불필요한 테이블 조회 줄임 주의 상황(느려지는 경우)인덱스 컬럼이 너무 많을 때, B-Tree 탐색 비용 증가선두 컬럼을 건너띄는 조건절일 때, 인덱스 효율 감소조회 row 수가 너무 많을 때, 풀스캔 보다 느림 접근 전략자주 쓰는 조회 쿼리에만 적용 (모든 쿼리 남발하지 말 것)인덱스 크기 고려 (너무 많은 컬럼을 포함하지 말 것)EXPLAIN으로 실행 계획 확인 (실제 효용성 확인 할 것)조건 컬럼 순서 고려 (복합..

! 파티셔닝 (Partitioning)테이블 내 row를 내부에서 특정 기준 별로 분류하여 활용하는 방식ex) 주문 데이터의 조회 시 2022년 이전, 이후로 분류 현 시점에서 주문 테이블에 접근 시 2022년 이후 row만 활용하기 등 ! 샤딩 (Sharding)데이터베이스 자체를 나눠서 여러 서버에 분산하는 방식ex) DB 에 있는 테이블을 각각 DB1, DB2, DB3에 나눠서 저장 구분 파티셔닝 (Partitioning)샤딩 (Sharding)나누는 대상테이블 내부 (로우 단위)DB 인스턴스 전체저장 위치같은 DB 서버다른 DB 서버들목적쿼리 최적화데이터/트래픽 분산구현 난이도낮음 (DB 설정)높음 (앱/인프라 설정) 작은 규모 + 성능 개선 -> 파티셔닝대규모 트래픽 + 수평 확장 -> 샤딩

!비관락장애 가능성을 항상 염두에 두고 선제적으로 방어, 오류 시 즉시 중단 !낙관락시스템은 정상 작동한다고 가정하고, 오류 발생 시 사후 대응으로 계속 운영 항목 비관락 낙관락특징- 강한 제약과 방어- 트랜잭션/락 기반- 에러 즉시 중단- 제약 조건 완화- 비동기, 재시도, 보상- 오류 발생 후 처리장점- 데이터 정합성 보장- 오류 확산 방지 - 예측 가능한 동작- 높은 처리량과 성능- 가용성 유지- 유연한 설계 가능단점- 처리량 저하- 불필요한 차단 발생 가능 - 사용자 경험 저하 우려- 장애 감지 지연 가능- 복구 로직 복잡- 데이터 충돌 가능성 존재 비관락 (=정확성)데이터 정합성이 우선 = 금융, 결제, 의료 등 정확성경합 조건 가능성이 높음 = 자원 잠금 필요(동일 데이터 ..

Thread-safe 하고, 성능도 고려된 HashMap1) 키-값 삽입, 조회, 삭제 2) 조건부 연산 (putIfAbsent, computeIfAbsent, merge)3) 병렬 루프 처리 (forEach, reduce) * Thread-safe: 멀티스레드 환경에서 코드나 객체가 동시에 접근돼도 문제가 발생하지 않도록 설계된 상태 ? 왜 ConcurrentHashMap 은 Thread-safe 할까 ?내부 구조 및 동시성 제어 기법1. CAS (Compare-And-Swap) + Synchronized 최소화 (Java 8 이후)Java 8부터는 Segment 대신 버킷 단위 락 + CAS 연산을 도입해 더 세밀한 락 제어가 가능해졌습니다.CAS 연산: 특정 조건이 만족될 때만 값을 변경하는 락 ..

Kafka 특성Kafka는 단순한 메시지 큐가 아니라, 고성능 이벤트 스트리밍 플랫폼로그 기반 저장소: 메시지가 삭제되지 않고 디스크에 유지되어, 과거 데이터를 재처리할 수 있습니다.비동기 Pub/Sub 모델: 생산자와 소비자가 직접 연결되지 않아 느슨한 결합 구조를 유지합니다.수평 확장성: 파티션 단위로 데이터를 분산 저장하며, 고성능 처리에 적합합니다.복수 구독자 허용: 하나의 이벤트를 여러 시스템이 동시에 처리할 수 있습니다.재처리 가능성: 오프셋 관리만 잘하면 과거 이벤트를 반복 소비할 수 있습니다. REST API와 Kafka의 차이점두 방식은 모두 모듈 간 통신에 사용되지만, 근본적으로 지향하는 구조와 사용 방식이 다릅니다. Rest apiKafka통신 방식요청/응답 (동기)이벤트 스트리밍 (..