1편에서 “DispatcherServlet이 front controller로 모든 요청을 받아 분배한다”, “요청당 스레드 1개를 쓴다”고 선언만 했습니다. 이번 편에서는 그 안을 해부합니다. DispatcherServlet 내부가 어떻게 동작하는지, 그리고 “요청당 스레드 1개”가 정확히 무슨 의미이고 왜 그게 메모리/동시성의 갈림길인지를 다룹니다....
인프라를 다루다 보면 애플리케이션은 “컨테이너 안에서 도는 검은 상자”처럼 보일 때가 많습니다. GET /orders/42 요청 하나가 들어오면 그 안에서 무슨 일이 벌어지는지, 왜 요청이 몰리면 스레드와 메모리가 같이 올라가는지 설명하려면 결국 그 상자를 열어봐야 합니다. 먼저 요청 한 건이 Spring Boot 앱을 통과하는 경로를 계층별로 그려...
1편에서 요청이 Controller -> Service -> Repository를 거쳐 처리되고, 이들이 “전부 빈(Bean)으로 힙에 상주한다”고 했습니다. 그런데 빈이 정확히 뭐고, 왜 우리는 이 객체들을 직접 new로 만들지 않을까요? 이 글은 Spring의 가장 근본적인 질문 - “Spring은 대체 무슨 일을 해주는가”에 답합니다...
앞선 Amazon Athena & Glue Data Catalog 글에서 일반 Glue 테이블(S3 + Glue Catalog)을 기준으로 쿼리 흐름과 권한을 정리하고, 이어 Apache Iceberg 테이블 포맷 글에서 Iceberg 자체의 구조와 동작 원리를 살펴봤습니다. 그 Iceberg를 AWS가 관리형으로 감싼 Amazon S3 Tab...
앞선 Amazon Athena & Glue Data Catalog 글에서는 일반 Glue 테이블(S3 + Parquet 파일 + Glue Catalog)을 기준으로 쿼리 흐름과 권한을 정리했습니다. 그런데 다음 편에서 다룰 S3 Tables는 “관리형 Iceberg 레이크하우스”입니다. 즉 S3 Tables를 제대로 이해하려면 그 바탕에 깔린 ...
앞선 AWS 데이터 분석 스택 Overview에서 분석 스택의 큰 그림과, 쿼리 한 번이 엔진과 메타스토어, 저장소를 지나는 흐름을 살펴봤습니다. 그 중심에 있는 두 구성요소, Amazon Athena와 AWS Glue Data Catalog를 자세히 알아봅니다. 이 둘은 한 쌍으로 움직입니다. Athena는 SQL을 실행하는 엔진이고, Glue D...
데이터 레이크나 레이크하우스에 쌓인 대규모 데이터를 SQL로 빠르게 조회하는 일의 중심에는 분산 SQL 엔진이 있습니다. Amazon Athena가 데이터를 옮기지 않고도 여러 소스를 한 쿼리로 조인하고 빠르게 응답하는 것도, 그 바탕에 분산 SQL 엔진이 있기 때문입니다. SQL 엔진이 무엇이고, 단일 노드 엔진과 분산 SQL 엔진(Trino/Pre...
S3 버킷에는 로그, 이벤트, 각종 추출 데이터가 끊임없이 쌓입니다. 그런데 막상 “이 데이터를 SQL로 한 번 들여다보자”고 하면, 어디서부터 손대야 할지 막막할 때가 많습니다. 별도 DB로 적재(ETL)해야 하나? 권한은 어디서 거나? 카탈로그는 또 뭔가? AWS는 이 “S3에 쌓인 데이터를 분석하는 일”을 여러 서비스의 조합으로 풉니다. Ath...
데이터 분석 스택을 다루다 보면 데이터 웨어하우스(Data Warehouse), 데이터 레이크(Data Lake), 레이크하우스(Data Lakehouse) 라는 용어가 자주 등장합니다. 셋 다 “데이터를 모아 분석한다”는 점은 같지만, 어디에 어떻게 저장하고 언제 스키마를 적용하느냐가 다릅니다. 이 차이를 모르면, 어떤 저장 방식을 택해야 하는지, ...
데이터 웨어하우스, 데이터 레이크, 레이크하우스는 나란히 놓고 고르는 세 가지 선택지처럼 소개되곤 합니다. 실제로는 각각 직전 방식이 부딪힌 한계를 풀면서 순서대로 등장했고, 그 순서를 모르면 왜 레이크하우스가 파일 위에 굳이 테이블 계층을 다시 얹는지 설명되지 않습니다. 변천사를 시간 축으로 따라가며 각 단계가 어떤 운영 문제를 풀려 했는지 정리합니...