728x90

전체 글 290

Oracle 아키텍처 해부 — SGA·PGA·백그라운드 프로세스와 RAC의 기반

Oracle아키텍처 해부 — SGA·PGA·백그라운드 프로세스와 RAC의 기반들어가며PostgreSQL은 프로세스 기반, MySQL은 스레드 기반. Oracle은 기본Dedicated Server의 한 세션 = 한 OS 프로세스 모델이면서, 동시에Shared·Threaded·DRCP라는 세 갈래를 OS·버전·워크로드에 따라 골라 쓸 수있는 유일한 상용 DB다. 이 "선택권"이 장점이자 함정이다. 연결 모델 하나바꿨을 뿐인데 OS 인증이 막히기도하고(THREADED_EXECUTION=TRUE), LOB·AQ 같은 기능이 호환되지않기도 한다(Shared Server). 하나의 추상 모델로 모든 것을 설명하는PG·MySQL과 달리, Oracle을 읽을 때는 어떤 연결 모델을 전제로하는지부터 먼저 확인해야 한다..

CS/Database 2026.04.15

MySQL(InnoDB) 아키텍처 해부 — 스레드·버퍼 풀·redo/undo·purge·doublewrite·binlog

MySQL(InnoDB)아키텍처 해부 — 스레드·버퍼 풀·redo/undo·purge·doublewrite·binlog들어가며PostgreSQL은 OS를 믿고 편집기를 얹었다. MySQL InnoDB는 OS를 믿지 않고스토리지 엔진 레이어를 따로 세웠다. 같은 "관계형 DB"라는 이름을 달고있지만, 두 엔진의 내부 철학은 이 한 문장에서 갈라진다. PG가shared_buffers를 두고 나머지 캐싱을 OS page cache에위임하는 쪽이라면, InnoDB는 버퍼 풀·redo·undo·doublewrite·binlog까지전부 자기 손으로 관리한다. 심지어 서버 레이어와스토리지 엔진 레이어를 handlerton이라는가상 테이블 계약으로 나눠 두는 구조다. 이 구조가 머릿속에 없으면innodb_flush_l..

CS/Database 2026.04.15

gRPC Deadline · Cancellation · Context Deep Dive — 5쌍의 레이어가 동시에 서야 한다

gRPCDeadline · Cancellation · Context Deep Dive — 5쌍의 레이어가 동시에 서야한다들어가며"3초 SLA"라고 써놓고 실제 호출은 9초 뒤에 503으로 돌아온다.BANDER에서 이 현상을 처음 봤을 때, 타임아웃 설정을 잘못 읽은 줄 알고application.yml을 뒤졌다.grpc.client.deadline: 5s가 멀쩡히 있었다. 스타트업 로그에도deadline=PT5S가 찍혀 있었다. 그런데 서버 쪽ServerInterceptor에서 꺼내본 호출의 Deadline은null이었고, HTTP/2 HEADERS 프레임을 Wireshark로 덤프해보니grpc-timeout 헤더 자체가 존재하지 않았다. 선언은있는데 wire에는 아무것도 나가지 않은 상태, 전형적인 de..

CS/GRPC 2026.04.15

gRPC Streaming Deep Dive — 4가지 모드는 왜 프로토콜이 하나인가

gRPCStreaming Deep Dive — 4가지 모드는 왜 프로토콜이 하나인가들어가며gRPC 입문서를 펼치면 거의 예외 없이 같은 네 줄이 등장한다. Unary,Server-streaming, Client-streaming, Bidirectional. 네 가지 "모드"라는표현 때문에 처음 보는 개발자는 이걸 네 개의 다른 프로토콜 내지는 네종류의 다른 커넥션처럼 읽는다. 한 줄로 바로잡자면, 네 모드는 한HTTP/2 stream 위에서 "요청 메시지가 1개냐 N개냐" × "응답 메시지가 1개냐N개냐"의 2×2 매트릭스일 뿐이다. 프로토콜은 하나고, wire 포맷도동일하고, HEADERS·DATA·trailer HEADERS라는 프레임 흐름의 대골격도 같다.달라지는 건 .proto의 stream 키워..

CS/GRPC 2026.04.15

PostgreSQL 아키텍처 해부 — Postmaster·백엔드·공유 메모리·WAL writer

PostgreSQL아키텍처 해부 — Postmaster·백엔드·공유 메모리·WAL writer들어가며튜닝 가이드를 따라 shared_buffers를 올렸는데buffers_backend가 줄지 않는다면, 건드린 건 증상이지 구조가아니다. PostgreSQL의 파라미터는 전부 어떤 프로세스·어떤 공유 메모리영역·어떤 백그라운드 루프에 붙는지 정해져 있고, 그 지도가 머릿속에없으면 값만 바꿔가며 헤매게 된다. 반대로 지도가 잡혀 있으면 대부분의파라미터는 "아, 이 루프의 주기를 줄이라는 뜻이구나"로 금방 해석된다.이 글은 PostgreSQL 16/17 기준으로 프로세스 토폴로지 → 연결시퀀스 → 공유 메모리 → 쓰기 경로 3인 1조 → autovacuum → 확장포인트 순서로, 그 지도를 한 번 그려 둔다. ..

CS/Database 2026.04.15

Spring Boot Actuator — Endpoint SPI와 Health·Metrics·Prometheus 내부

SpringBoot Actuator — Endpoint SPI와 Health·Metrics·Prometheus 내부들어가며운영 중인 서비스를 다루다 보면 결국 세 가지 질문으로 되돌아온다. 지금살아 있나, 트래픽을 받을 준비가 됐나, 무슨 일이 일어나고 있나. SpringBoot는 이 세 질문에 답할 수 있는 창구를 Actuator라는이름으로 묶어놓았다. spring-boot-starter-actuator 의존성 한줄이 /actuator 경로를 열고, 그 아래에 health,metrics, prometheus 같은 엔드포인트를걸어둔다. 다만 이 창구는 기본값이 의도적으로 소심하게 잡혀있다. 뭔가 설정해주지 않으면 web에는 health하나밖에 안 보인다.Actuator의 설계 중심은 @Endpoint라는..

CS/Spring 2026.04.14

Spring Boot Externalized Configuration — @ConfigurationProperties 바인딩과 Profile·spring.config.import

SpringBoot Externalized Configuration — @ConfigurationProperties 바인딩과Profile·spring.config.import들어가며9편에서 Environment가 어떻게 조립되는가 —PropertySource 평면 리스트에 누가 먼저 꽂히느냐로우선순위가 결정된다는 이야기를 했다. 이번 편은 그 이야기의 자매편이다.9편이 "조립의 원리"였다면, 이번은 Spring Boot가 실무에서 실제로제공하는 설정 주입 수단 전부를 기능별로 펼쳐 보는 쪽이다.application.yml, application-{profile}.yml,spring.config.import, 생성자 바인딩, Duration단위 파싱, @Validated 기동 검증 — 이름은 다들 들어봤지..

CS/Spring 2026.04.14

Spring Boot AutoConfiguration — @AutoConfiguration과 조건부 조립의 내부

SpringBoot AutoConfiguration — @AutoConfiguration과 조건부 조립의 내부들어가며spring-boot-starter-web을 의존성에 추가하고main을 돌리면, 톰캣이 뜨고,DispatcherServlet이 등록되고, Jackson이MessageConverter에 물리고, 정적 리소스가 매핑되고, 에러페이지가 연결된다. application.yml에spring.datasource.url만 넣으면 HikariCP 커넥션 풀과DataSource, JdbcTemplate,DataSourceTransactionManager까지 조용히 조립된다. 어떤클래스도 @Bean으로 직접 등록한 적이 없다.@SpringBootApplication 한 줄이 이걸 전부 해낸다.그런데 이 "한..

CS/Spring 2026.04.14

Spring Security Testing — @WithMockUser·MockMvc·Reactive 테스트 전략

SpringSecurity Testing — @WithMockUser·MockMvc·Reactive 테스트 전략들어가며Spring Security를 써본 사람은 인증·인가를 한 번쯤 붙여본다. 그런데그걸 테스트로 덮는 순간 두 번째 벽이 생긴다. 로컬에서브라우저로는 멀쩡히 로그인되는 컨트롤러가 @WebMvcTest에서는401이나 403으로 돌아오고, POST 요청은 전부 CSRF로 튕기고,@PreAuthorize를 단위 테스트로 덮었는데 권한 검증이 아예돌지 않는다. 테스트만 통과하면 배포되는 환경에서는 이게 그대로 "가짜안전망"이 된다.Spring Security 6.x / Spring Boot 3.x / Spring Test 6.x 기준으로테스트에서 막히는 지점은 거의 정해져 있다. @WithMock..

CS/Spring 2026.04.14

Spring Security OAuth2 Client — Authorization Code Flow와 ClientRegistration 내부

SpringSecurity OAuth2 Client — Authorization Code Flow와 ClientRegistration내부들어가며바로 앞 글(27편 ResourceServer)이 "이미 발급된 토큰을 받기만 하는 쪽"이었다면, 이번 글은정반대다. 토큰을 발급받아 오는 쪽 — 사용자를 IdP로리다이렉트하고, 돌아온 code를 token endpoint에교환하고, 받은 access_token을 저장해 뒀다가 API 호출할 때붙여 주는 전 과정을 Spring Security가 알아서 해 준다.spring-boot-starter-oauth2-client 하나 추가하면application.yml 여덟 줄로 구글 로그인이 동작한다. 그아래에서 필터 두 개가 리다이렉트를 주고받고,ClientRegist..

CS/Spring 2026.04.14
728x90