producer — 메시지를 topic에 보내는 주체쇼핑몰 주문 API가 주문 이벤트를 orders topic에 넣는다(장 02). 이때 "메시지를 topic에 보내는 주체"가 producer다. 애플리케이션에 내장되는 클라이언트로, producer.send(...) 한 줄로 메시지를 쏜다.이 글은 producer가 뭔지부터 시작해, 실제 설정과 코드로 어떻게 쓰는지, acks·idempotent producer로 신뢰성을 어떻게 확보하는지까지 다룬다.producer란 — topic에 메시지를 보내는 클라이언트producer는 앱에 내장되는 클라이언트 라이브러리다. 별도 서버가 아니라, 주문 API·배치 잡·로그 수집기 같은 앱 프로세스 안에서 동작한다.Java producer 기본 코드// 1. 설정P..
topic과 partition — 메시지를 어디에, 어떻게 쌓을 것인가쇼핑몰에서 주문이 들어온다. 이 주문 데이터를 어디에 쌓을까? Kafka에선 topic이라는 곳에 넣는다. "주문" topic, "클릭 로그" topic, "결제" topic처럼 용도별로 topic을 나눠 메시지를 분류한다. 그런데 주문이 초당 수만 건씩 쏟아지면 topic 하나로는 감당이 안 된다 — 그래서 topic을 여러 조각으로 쪼개는데, 그 조각이 partition이다.이 글은 Kafka를 처음 접하는 사람이 topic과 partition을 "확" 이해하도록, 기초부터 차근차근 쌓아 올린다. topic이 뭔지, 어떻게 쓰이는지부터 시작해 partition이 왜 필요한지, key가 뭔 역할을 하는지, 그리고 "partition ..
Kafka는 큐가 아니다 — 영속적 분산 로그가 만든 모든 차이Kafka를 처음 배우는 사람 대부분은 "메시지 큐"라는 설명을 듣고 RabbitMQ처럼 생각한다. 그래서 "소비했는데 왜 데이터가 남지?", "왜 메시지 순서가 섞이지?" 같은 오해에 빠진다. 이 오해의 뿌리는 단 하나다 — Kafka는 소비하면 사라지는 큐가 아니라, 영속적이고 파티션 내 순서가 보장되는 분산 로그다. 이 하나의 차이가 Kafka의 모든 설계(복제, 컨슈머 그룹, retention, 전달 의미론)를 설명한다.이 글은 그 핵심 추상 — partition = append-only log — 을 중심으로 Kafka가 무엇인지, 왜 그렇게 설계됐는지, 그리고 왜 "빠르다"는 평가가 마법이 아니라 설계의 결과인지를 다룬다. rete..
메일은 한 번에 가지 않는다 — 인터넷 서비스의 역할 분담메일을 보냈다. 바로 도착할까? 아니다. 메일은 송신자 → 송신 서버(MTA) → 수신 서버(MTA) → 메일함(MDA) → 수신자(MUA) 의 다단계 흐름을 거친다. 어디쯤 걸려 지연되는지 알려면 이 흐름을 알아야 한다. 단일 "메일 서버"라는 말이 감추는 것이 바로 이 분업이다.서버의 주된 용도가 바로 이 서비스들이다 — 웹, 이름 해석(DNS), 메일, 파일 공유, 데이터베이스. 각각 고유한 프로토콜·포트·패키지·설정 파일을 갖는다. 이 글은 그 매핑과, 서비스가 "설치했는데 외부 접속이 안 될 때"의 3단계 진단을 다룬다.서비스는 역할별 부서다 — 포트가 내선 번호다서버는 하나의 회사, 각 서비스는 부서이자 안내 데스크다. 각 부서에 고유 ..
설정은 다 맞는데 403이 난다 — 9할은 SELinux다httpd 설정을 다 맞췄다. 파일도 /var/www/html에 넣었다. 그런데 브라우저에서 403 Forbidden. Apache 설정만 뒤지다 한참을 헤맨다 — 그런데 진짜 원인은 SELinux인 경우가 압도적으로 많다. 파일을 cp/mv로 옮기면 보안 레이블(컨텍스트)이 잘못되어 SELinux가 접근을 막는 것이다.리눅스 보안은 다층 방어(defense in depth)다. 전통 권한(DAC) 위에 강제 접근 제어(SELinux), 네트워크 검문(firewalld), 인증(PAM)이 올려져 있고, 각 층이 독립적으로 통과돼야 접근이 허용된다. 이 장을 모르면 "설정 다 맞는데 왜 안 되지?"의 원인을 못 찾고, 방화벽·인증 정책도 못 짠다. ..
DNS를 바꾸려고 resolv.conf를 고쳤다가 사라졌다 — 네트워크 관리DNS 서버를 바꾸려고 /etc/resolv.conf를 직접 편집했다. 잘 되는 듯했는데 재부팅하니 원래대로 돌아갔다. 왜? Rocky 10에선 NetworkManager가 /etc/resolv.conf를 자동 관리한다. 직접 편집하면 덮어쓴다. DNS 변경은 nmcli로 해야 한다.이런 함정이 네트워크 관리엔 많다. 서버의 대부분은 네트워크로 통신하고, IP 설정·포트 점검·DNS 오류·라우팅 문제는 운영 일상이다. 이 글은 컴퓨터가 서로 통신하는 세 가지 기반 — 서로를 식별할 주소(IP), 데이터를 전달할 경로(라우팅), 이름을 주소로 바꿀 DNS — 과, Rocky 10이 이걸 NetworkManager로 관리하는 방식을 ..
Archive
producer — 메시지를 topic에 보내는 주체쇼핑몰 주문 API가 주문 이벤트를 orders topic에 넣는다(장 02). 이때 "메시지를 topic에 보내는 주체"가 producer다. 애플리케이션에 내장되는 클라이언트로, producer.send(...) 한 줄로 메시지를 쏜다.이 글은 producer가 뭔지부터 시작해, 실제 설정과 코드로 어떻게 쓰는지, acks·idempotent producer로 신뢰성을 어떻게 확보하는지까지 다룬다.producer란 — topic에 메시지를 보내는 클라이언트producer는 앱에 내장되는 클라이언트 라이브러리다. 별도 서버가 아니라, 주문 API·배치 잡·로그 수집기 같은 앱 프로세스 안에서 동작한다.Java producer 기본 코드// 1. 설정P..
topic과 partition — 메시지를 어디에, 어떻게 쌓을 것인가쇼핑몰에서 주문이 들어온다. 이 주문 데이터를 어디에 쌓을까? Kafka에선 topic이라는 곳에 넣는다. "주문" topic, "클릭 로그" topic, "결제" topic처럼 용도별로 topic을 나눠 메시지를 분류한다. 그런데 주문이 초당 수만 건씩 쏟아지면 topic 하나로는 감당이 안 된다 — 그래서 topic을 여러 조각으로 쪼개는데, 그 조각이 partition이다.이 글은 Kafka를 처음 접하는 사람이 topic과 partition을 "확" 이해하도록, 기초부터 차근차근 쌓아 올린다. topic이 뭔지, 어떻게 쓰이는지부터 시작해 partition이 왜 필요한지, key가 뭔 역할을 하는지, 그리고 "partition ..
Kafka는 큐가 아니다 — 영속적 분산 로그가 만든 모든 차이Kafka를 처음 배우는 사람 대부분은 "메시지 큐"라는 설명을 듣고 RabbitMQ처럼 생각한다. 그래서 "소비했는데 왜 데이터가 남지?", "왜 메시지 순서가 섞이지?" 같은 오해에 빠진다. 이 오해의 뿌리는 단 하나다 — Kafka는 소비하면 사라지는 큐가 아니라, 영속적이고 파티션 내 순서가 보장되는 분산 로그다. 이 하나의 차이가 Kafka의 모든 설계(복제, 컨슈머 그룹, retention, 전달 의미론)를 설명한다.이 글은 그 핵심 추상 — partition = append-only log — 을 중심으로 Kafka가 무엇인지, 왜 그렇게 설계됐는지, 그리고 왜 "빠르다"는 평가가 마법이 아니라 설계의 결과인지를 다룬다. rete..
메일은 한 번에 가지 않는다 — 인터넷 서비스의 역할 분담메일을 보냈다. 바로 도착할까? 아니다. 메일은 송신자 → 송신 서버(MTA) → 수신 서버(MTA) → 메일함(MDA) → 수신자(MUA) 의 다단계 흐름을 거친다. 어디쯤 걸려 지연되는지 알려면 이 흐름을 알아야 한다. 단일 "메일 서버"라는 말이 감추는 것이 바로 이 분업이다.서버의 주된 용도가 바로 이 서비스들이다 — 웹, 이름 해석(DNS), 메일, 파일 공유, 데이터베이스. 각각 고유한 프로토콜·포트·패키지·설정 파일을 갖는다. 이 글은 그 매핑과, 서비스가 "설치했는데 외부 접속이 안 될 때"의 3단계 진단을 다룬다.서비스는 역할별 부서다 — 포트가 내선 번호다서버는 하나의 회사, 각 서비스는 부서이자 안내 데스크다. 각 부서에 고유 ..
설정은 다 맞는데 403이 난다 — 9할은 SELinux다httpd 설정을 다 맞췄다. 파일도 /var/www/html에 넣었다. 그런데 브라우저에서 403 Forbidden. Apache 설정만 뒤지다 한참을 헤맨다 — 그런데 진짜 원인은 SELinux인 경우가 압도적으로 많다. 파일을 cp/mv로 옮기면 보안 레이블(컨텍스트)이 잘못되어 SELinux가 접근을 막는 것이다.리눅스 보안은 다층 방어(defense in depth)다. 전통 권한(DAC) 위에 강제 접근 제어(SELinux), 네트워크 검문(firewalld), 인증(PAM)이 올려져 있고, 각 층이 독립적으로 통과돼야 접근이 허용된다. 이 장을 모르면 "설정 다 맞는데 왜 안 되지?"의 원인을 못 찾고, 방화벽·인증 정책도 못 짠다. ..
DNS를 바꾸려고 resolv.conf를 고쳤다가 사라졌다 — 네트워크 관리DNS 서버를 바꾸려고 /etc/resolv.conf를 직접 편집했다. 잘 되는 듯했는데 재부팅하니 원래대로 돌아갔다. 왜? Rocky 10에선 NetworkManager가 /etc/resolv.conf를 자동 관리한다. 직접 편집하면 덮어쓴다. DNS 변경은 nmcli로 해야 한다.이런 함정이 네트워크 관리엔 많다. 서버의 대부분은 네트워크로 통신하고, IP 설정·포트 점검·DNS 오류·라우팅 문제는 운영 일상이다. 이 글은 컴퓨터가 서로 통신하는 세 가지 기반 — 서로를 식별할 주소(IP), 데이터를 전달할 경로(라우팅), 이름을 주소로 바꿀 DNS — 과, Rocky 10이 이걸 NetworkManager로 관리하는 방식을 ..
wall
방문 흔적을 남겨주세요. 질문이나 인사 모두 환영합니다.
