ECS에서 메모리 설정은 Task, Container, Application(JVM 등) 3개 레벨로 나뉩니다. 각 레벨이 어떻게 동작하는지 정리합니다. 메모리 설정의 3개 레벨 Task 메모리 (Task에 할당된 전체 메모리) └→ Container 메모리 (프로세스별 할당) └→ Application 메모리 (JVM Heap 등) 레벨 설정 위치 역할 Task 메모리 Task Definition 전체 메모리 한도 Container 메모리 Task Definition > containerDefinitions 컨테이너별 메모리 한도 Application 메모리 JVM 옵션 (-Xmx 등) 애플리케이션 내부 메모리 Application 레벨(JVM 메모리 설정)은 AWS ECS에서 Java + Spring Boot 어플리케이션 메모리 설정 에서 다룹니다. ...

물리 서버, 가상 머신 (VM), 컨테이너. 서버 환경이 어떻게 변해왔는지, 컨테이너 관련 용어들의 관계를 정리합니다. 서버 환경의 변천 물리 서버 → VM → 컨테이너 물리 서버와 VM은 사용자 입장에서 거의 동일합니다. OS 설치하고, Java 설치하고, jar 배포하고. 차이는 하드웨어를 직접 만지느냐, 콘솔에서 클릭하느냐 정도입니다. 패러다임이 바뀌는 건 VM → 컨테이너 구간입니다. 컨테이너의 구조 기존 서버 환경 (물리 서버 / VM) Application (jar) Java (JDK) OS (Linux) ───────────── 물리 서버 / VM 기존 서버 환경은 각 계층을 하나하나 직접 설치합니다. ...

데이터베이스, 데이터웨어하우스, 데이터레이크, 데이터레이크하우스. 비슷해 보이지만 각각 목적과 특성이 다릅니다. 한눈에 비교 구분 데이터베이스 데이터 웨어하우스 데이터 레이크 데이터 레이크하우스 목적 운영/트랜잭션(OLTP) 분석(OLAP) 원시 데이터 저장 분석 + 저장 통합 데이터 형태 구조화 구조화 비구조화/반구조화 모두 지원 스키마 Schema-on-Write Schema-on-Write Schema-on-Read 둘 다 가능 ACID O O X O 쿼리 패턴 단건 읽기/쓰기 대량 집계/분석 배치 처리 대량 집계/분석 실시간성 실시간 준실시간~배치 배치 준실시간~배치 대표 제품 MySQL, PostgreSQL Snowflake, Redshift, BigQuery S3, HDFS Databricks 쉬운 비유 데이터베이스: 매장 POS 시스템. 실시간 거래를 기록합니다. 데이터 웨어하우스: 본사 경영분석실. 정제된 보고서용 데이터를 보관합니다. 데이터 레이크: 창고에 일단 다 쌓아둡니다. 정리는 안 되어 있습니다. 데이터 레이크하우스: 창고에 관리 시스템을 얹었습니다. 저렴하게 저장하고, 체계적으로 관리합니다. 용어 유래 Database: Data + Base(기지) → 데이터를 저장하고 관리하는 기본 시스템 Data Warehouse: Data + Warehouse(창고) → 정리된 물건을 체계적으로 보관 Data Lake: Data + Lake(호수) → 모든 물이 흘러드는 호수 Data Lakehouse: Data + Lake + House (Databricks가 2020년 제안한 신조어) “Data Lake Warehouse"가 아닌 이유? 단순히 둘을 붙여 쓰는 게 아니라, 새로운 패러다임임을 강조하기 위해서입니다. ...

Java package-private 클래스를 Kotlin 테스트 코드에서 접근하려니 생성자 호출이 안 되어 reflection을 써야 했습니다. 왜 이런 문제가 발생할까요? Java와 Kotlin 접근 제어자 비교 Java public: 전체 protected: 상속 + 같은 패키지 (default): 같은 패키지 private: 같은 클래스 Kotlin public: 전체 internal: 같은 모듈 protected: 상속 관계만 private: 같은 클래스 (클래스 멤버) / 같은 파일 (최상위 선언) 핵심 차이 Java Kotlin 캡슐화 단위 패키지 모듈 테스트 접근 같은 패키지 필요 같은 모듈이면 OK package-private 있음 없음 (internal로 대체) protected 상속 + 같은 패키지 상속만 Kotlin의 설계 철학 1. 패키지는 캡슐화 경계가 아니다 // 원래 라이브러리 (example-lib.jar) package com.example.core; class InternalClass { // package-private void sensitiveMethod() { } } // 악의적 사용자 코드 (다른 프로젝트) package com.example.core; // 같은 패키지명 사용 public class Hacker { void access() { new InternalClass(); // package-private인데 접근됨 } } 패키지는 코드 조직화 수단일 뿐, 실제 캡슐화는 컴파일/배포 단위인 모듈에서 이루어져야 합니다. ...

Hugo 블로그에 GitHub Discussions 기반 댓글 시스템 giscus를 적용합니다. 사전 준비 GitHub 공개 저장소 준비 해당 공개 저장소에 Discussions 활성화: Settings → General → Features → Discussions giscus 앱 설치 후 저장소 선택 giscus 설정 https://giscus.app 접속 저장소와 원하는 옵션 선택 생성된 스크립트 코드 복사 Hugo 적용 댓글 파일 생성 <!-- layouts/partials/comment.html --> // 스크립트 코드 설정 파일 수정 # hugo.toml [params] comments = true 정리 giscus는 GitHub Discussions를 댓글로 사용 별도 DB나 서버 불필요 GitHub 로그인으로 댓글 작성

혼동하기 쉬운 블록킹/논블록킹과 동기/비동기 개념을 정리합니다. 개념 정의 블록킹 vs 논블록킹 구분 기준: 제어권을 바로 돌려주는가? 블록킹: 작업 완료까지 제어권을 돌려주지 않음 논블록킹: 작업 요청 후 바로 제어권 반환 카페 주문 비유: 블록킹: 카운터에서 서서 기다림 (다른 일 못함) 논블록킹: 진동벨 받고 자리로 (다른 일 가능) 동기 vs 비동기 구분 기준: 결과를 누가 확인하는가? 동기: 요청한 쪽이 결과를 직접 확인 비동기: 결과가 준비되면 콜백으로 알려줌 카페 주문 비유: 동기: 내가 직접 “제 커피 됐나요?” 확인 비동기: 직원이 “OO번 고객님~” 불러줌 핵심 구분 구분 질문 블록킹 논블록킹 제어권 기다리는 동안 다른 일 할 수 있어? 못함 (멈춤) 가능 (안 멈춤) 구분 질문 동기 비동기 결과 확인 결과를 내가 확인해? 알려줘? 내가 확인 알려줌 C 디바이스 I/O 예제 블록킹 I/O int fd = open("/dev/device", O_RDONLY); char buf[1024]; // 데이터 올 때까지 멈춤 int result = read(fd, buf, 1024); // 여기 도달 = buf 채워짐 보장 printf("읽음: %s", buf); 동작: ...

Apache Kafka의 핵심 개념과 동작 원리를 정리합니다. 아키텍처 Kafka Cluster (여러 Broker의 집합) │ └─ Broker (카프카 서버, 여러 대 가능) │ └─ Topic (메시지 종류) │ ├─ Partition 0 ──┐ ├─ Partition 1 ──┼── Consumer Group A ─┬─ Consumer 1 └─ Partition 2 ──┘ ├─ Consumer 2 │ └─ Consumer 3 │ └──────────── Consumer Group B ─── Consumer 1 구성 요소 Broker: Kafka 서버 (여러 대로 클러스터 구성) Topic: 메시지 종류별 논리적 그룹 Partition: 토픽 내 병렬 처리 단위 Consumer Group: 동일 group.id로 묶인 컨슈머들 설계 시 고려사항 파티션 수 = 최대 병렬 처리 수 파티션 수 ≥ 컨슈머 수 (컨슈머가 더 많으면 일부는 idle) 용어 정리 ← 여기 동작 일반 메시지 큐 Kafka 메시지 보내기 Publish Produce 보내는 주체 Publisher Producer 토픽 구독 Subscribe Subscribe (동일) 메시지 받기 Push (서버가 보냄) Poll (주기적으로 가져감) 받는 주체 Subscriber Consumer 메시지 흐름 Producer ──produce──▶ Kafka Broker ◀──poll── Consumer │ ▼ consume 처리 로직 동작 방식 Producer가 메시지 전송 Broker가 파티션에 메시지 저장 Consumer가 주기적으로 폴링 새 메시지 있으면 가져와서 처리 메시지 관리 Offset 관리 Offset: 파티션 내 메시지 위치 (0부터 시작) Committed Offset: 처리 완료한 마지막 위치 Latest Offset: 파티션의 마지막 메시지 위치 Consumer Lag: Latest - Committed (처리 지연 정도) Commit 전략 // 자동 커밋 (기본값) enable.auto.commit=true auto.commit.interval.ms=5000 // 수동 커밋 consumer.commitSync(); consumer.commitAsync(); 메시지 전달 보장 1. At-most-once 처리 전 commit 장점: 중복 없음 단점: 메시지 유실 가능 2. At-least-once (기본값) 처리 후 commit 장점: 메시지 유실 없음 단점: 중복 처리 가능 중요: 애플리케이션 레벨에서 멱등성 보장 필요 3. Exactly-once 트랜잭션 사용 장점: 중복도 유실도 없음 단점: 성능 오버헤드 메시지 보관 일반 메시지 큐와 달리 Kafka는 consume 후에도 메시지 보관: ...

Spring Boot의 설정 파일 로딩 메커니즘과 외부 라이브러리 사용 시 발생하는 문제를 다룹니다. ConfigData API (Spring Boot 2.4+) Spring Boot 2.4 부터 설정 로딩 방식이 ConfigData API로 변경되었습니다. 주요 변경사항 Spring Cloud Bootstrap Context 대체 (bootstrap.yml → application.yml) 단일 ApplicationContext 사용 spring.config.import 도입 설정 파일 로딩 기본 동작 검색 위치 Spring Boot는 다음 위치에서 설정 파일을 검색합니다 (낮은 → 높은 우선순위): 1. classpath:/application.yml 2. classpath:/config/application.yml 3. file:./application.yml 4. file:./config/application.yml 5. file:./config/*/application.yml 로딩 규칙 다른 경로: 모두 로드 후 병합 같은 classpath 경로: 첫 번째만 사용 Oracle Java 문서: 여러 모듈이 동일한 클래스 로더에 정의되고, 둘 이상의 모듈이 주어진 이름의 리소스를 포함하는 경우, 모듈이 검색되는 순서는 명시되지 않으며 매우 예측할 수 없을 수 있습니다. 우선순위 나중에 로드된 것이 우선: ...

Spring Boot 배포 직후 첫 요청이 느린 이유를 JVM 동작 원리부터 설명합니다. 컴파일러와 인터프리터 컴파일러 언어 (C/C++) 전체 코드를 한번에 기계어로 변환 실행 속도 빠름 플랫폼 종속적 인터프리터 언어 (Python) 코드를 한 줄씩 해석하며 실행 실행 속도 느림 플랫폼 독립적 자바 동작 방식 자바 1990년대 설계 철학 이식성: Write Once, Run Anywhere 안전성: 메모리 보호, 타입 검증 개발 생산성: 자동 메모리 관리 HelloWorld.java (소스코드) → javac (컴파일) → HelloWorld.class (바이트코드) → java (JVM) → 실행 단점 바이트코드 인터프리터 실행으로 성능이 느렸습니다. ...