호에에

IT PICUTRE

• [Kafka] Raft 알고리즘 📌 Raft 알고리즘 이해하기 – Kafka KRaft를 중심으로Kafka 4.x부터 ZooKeeper가 사라지고 KRaft(Kafka + Raft) 모드가 기본이 되었습니다.Raft는 분산 시스템에서 합의(consensus)를 이루기 위한 대표적인 알고리즘인데, 리더 선출과 로그 복제를 안정적으로 관리합니다.이번 글에서는 Raft와 관련해 자주 헷갈리는 개념들을 질문/답변 형식으로 정리했습니다. ❓ 브로커가 3개일 때, 리더가 죽으면 투표가 불가능한 것 아닌가?아닙니다.3개 브로커일 때 과반수(Quorum)는 2.리더 1대가 죽더라도 2대가 남으면 서로 투표해서 새로운 리더를 뽑을 수 있습니다.다만 2대가 모두 죽고 1대만 남으면 Quorum(2)을 만족하지 못하므로 선거가 불가능합니다.✅ 정리: .. 2025.09.29
• Kafka Consumer Group 카프카에서 “컨슈머 그룹(Consumer Group)”은 확장성·중복제어·장애복구를 한 번에 해결해 주는 핵심 개념이에요. 그냥 “컨슈머 여러 대”로도 읽을 순 있지만, 그룹이 있어야 운영이 쉬워집니다. 이 글은 왜 그룹이 필요한지 → 내부가 어떻게 돌아가는지 → 실습/운영 팁까지 한 번에 정리합니다.1) 한 문장 요약같은 그룹 안에서는 한 시점에 한 파티션은 한 컨슈머만 읽는다 → 중복 소비 없음 + 병렬 확장 + 자동 장애복구다른 그룹이면 독립 구독(팬아웃) → 같은 메시지를 각 그룹이 의도적으로 각각 읽는다2) 왜 Consumer “Group” 이 필요한가A. 병렬 처리로 처리량 확장토픽을 파티션으로 나누고, 그 파티션들을 그룹 내 여러 컨슈머가 나눠 맡아 읽음컨슈머 수를 늘리면 병렬 처리량↑ (단.. 2025.09.29
• [kafka] 토픽을 파티션으로 나누는 이유 1. 병렬 처리로 성능 향상토픽을 여러 파티션으로 나누면, 여러 Producer가 동시에 다른 파티션에 기록할 수 있고,여러 Consumer가 동시에 다른 파티션에서 읽을 수 있음.즉, 1개의 큰 로그 파일로 처리하는 것보다, 분산된 여러 파티션에 나눠 쓰고 읽는 게 훨씬 빠름.예) 토픽에 1초당 10만 건이 들어와도, 파티션 5개로 나누면 각 파티션당 2만 건씩 처리 가능.2. Consumer Group 기반 병렬 처리카프카는 Consumer Group 단위로 메시지를 읽는데,→ 1개의 파티션은 동시에 1개의 컨슈머만 읽을 수 있음.따라서 파티션 수를 늘리면 Consumer를 더 많이 붙여 병렬 처리 가능.예) 파티션 6개 → 컨슈머 그룹에 6개 컨슈머 붙이면 병렬 처리 x6.3. 확장성과 유연성클러스.. 2025.09.29
• 웹 애플리케이션 보안을 위한 쿠키 & 세션 관리 전략 웹 서비스 운영에서 **쿠키(Cookie)**와 **세션(Session)**은 사용자 경험과 보안을 동시에 책임지는 핵심 요소입니다. 로그인 상태 유지, 사용자 설정 저장, 서비스 연속성 보장 등 편리한 기능 뒤에는 반드시 보안 고려가 따라야 합니다. 이번 글에서는 쿠키와 세션의 원리, 보안 속성, 그리고 운영자가 꼭 챙겨야 할 체크리스트를 정리합니다.1. 쿠키와 세션의 기본 원리쿠키란?쿠키는 서버가 브라우저에 내려주는 작은 데이터 조각입니다. 브라우저는 이를 저장했다가 같은 도메인에 요청을 보낼 때마다 자동으로 포함시킵니다.주요 역할: 사용자 식별, 세션 유지, 환경설정 저장예시: HTTP/1.1 200 OK Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secu.. 2025.09.26
• Docker Hub Rate Limiting 정책과 "authorization failed" 오류 이해하기 컨테이너 이미지를 다루다 보면, docker pull 과정에서 "authorization failed" 또는 429 Too Many Requests 오류를 경험할 수 있습니다. 이는 대체로 Docker Hub의 rate limiting 정책 때문입니다. 이번 글에서는 Docker Hub 공식 문서에 기반하여, 이 정책이 무엇이고 어떤 영향을 주며 어떻게 대응할 수 있는지 정리해 보겠습니다.1. Docker Hub Rate Limiting이란?Docker Hub는 2020년 11월부터 이미지 pull 요청 횟수에 제한(rate limit) 을 두었습니다. 이는 과도한 트래픽으로 인한 서비스 안정성 저하를 방지하고, 유료 플랜 사용자에게 더 나은 품질을 제공하기 위함입니다.공식 문서에 따르면, 6시간 단위로.. 2025.09.25
• ASG + 스팟 인스턴스 + 사설 DNS 자동등록 잘 안쓰이는이유 구성을 해보는데 asg + spot instance 구성은 그렇게 어렵지 않았습니다. 하지만 private DNS 를 ec2 에 연결하면서부터 굉장히 복잡하게 구성이 됩니다. dns cache, spot instance의 부족으로 인하여 다른 인스턴스가 생성되며 다른 subnet 에 생성이 되어 제어하기가 굉장히 까다롭더군요. 생각해보니 대부분의 개발환경에서는 on-demand를 사용하던데 그이유를 좀더 자세히 알아보고자 포스팅합니다. 왜 잘 안 쓰일까?1) 스팟 특성과 개발 생산성의 충돌예고형 중단(2분 전 통지): 개발 중/테스트 중에 인스턴스가 종료되면 워크플로우가 끊깁니다.가용 용량 변동: 특정 타입/AZ에 스팟 용량이 모자라 스케일-아웃이 실패할 수 있음. “개발=빠른 반복”과 상충.비용 .. 2025.09.24
• 퍼센타일 지표(p50, p90)로 보는 성능과 모니터링 웹 서비스나 API를 운영하다 보면 “응답 시간이 평균 200ms” 같은 말을 흔히 합니다. 하지만 **평균값(mean)**만으로는 사용자 경험을 제대로 설명할 수 없습니다. 실제로는 일부 요청이 아주 느릴 수 있고, 그 극단적인 요청들이 서비스 만족도를 크게 떨어뜨리기도 합니다.이때 자주 쓰이는 지표가 바로 **퍼센타일(percentile)**입니다. 그중에서도 가장 많이 언급되는 것이 p50, p90, p95, p99입니다.1. 퍼센타일이란 무엇인가?퍼센타일은 데이터를 정렬했을 때 특정 비율에 해당하는 지점을 말합니다.p50 (50th percentile): 중앙값(median). 절반의 요청이 이 값보다 빠르고, 절반은 더 느립니다.p90 (90th percentile): 요청 중 90%는 이 값보.. 2025.09.24
• isito 와 cilium path 정책 차이 1.패턴 매칭 방식Cilium - 정규식 지원http:path: "/api/v[0-9]+/users/[a-zA-Z0-9-]+" # 정규식path: ".*\\.(jpg|png|gif)$" # 파일 확장자Istio - Glob 패턴만operation: paths: ["/api//users/"] # 와일드카드만정규식 지원하지 않음2. 정책 우선순위 처리Cilium - 순서대로 첫 매칭ingress:rules: http:path: "/admin" # 먼저 매칭되면 허용path: "/admin/.*" # 두 번째 규칙은 무시됨Istio - DENY > ALLOW복수 정책이 있어도 DENY가 우선ALLOW: "/admin"DENY: "/admin/*"결과: DENY 승리3.헤더 및 조건부 매칭Cilium - 정규식.. 2025.09.24
• istio vs cilium 정책 차이 레이어/역할Istio: 서비스 메쉬의 L7(HTTP/gRPC) 중심 접근제어 + mTLS/JWT 인증/인가. AuthorizationPolicy(ALLOW/DENY/CUSTOM/AUDIT), PeerAuthentication(mTLS), RequestAuthentication(JWT)로 앱 레벨 보안/정책을 다룸. Sidecar 모드에선 Envoy 사이드카가, Ambient에선 L4 정책은 ztunnel, L7은 waypoint가 집행한다. IstioCilium: CNI + eBPF 기반 L3/L4(커널 레벨) 정책이 기본. 확장 리소스인 CiliumNetworkPolicy/ClusterwideNetworkPolicy로 L3/L4는 eBPF로, **L7(HTTP/gRPC/Kafka/DNS)**은 노드 로.. 2025.09.24
• Spot 인스턴스를 안정적으로 쓰는 방법: ASG + Capacity-Optimized + Capacity Rebalancing 2편(단점, 무중단, 장점) 공식 문서에서 말하는 한계 & 주의사항AWS 문서 “Capacity Rebalancing in Auto Scaling”에 따르면 다음 같은 고려사항들이 있어요: AWS Documentation 항목 내용Application의 관용성애플리케이션이 Spot 중단/교체에 내성이 있어야 함. 상태 저장(stateful) 작업이나 연결 유지가 중요한 경우, graceful shutdown, 데이터 복제, 리플리카/리스너 종료 처리 등이 필요. AWS DocumentationLaunch Template / 인스턴스 타입 / AZ 다양성Spot 풀(pool)의 여유(capacity)가 많은 타입/AZ들을 여러 개 열어야 재보충(reserve)이 가능. 단일 타입/AZ만 쓰면 그 풀의 여유가 없을 때 복구가 어려움... 2025.09.22
• Spot 인스턴스 안정성 확보: ASG + Capacity-Optimized + Capacity Rebalancing 활용하기 인프라 비용 절감 측면에서 Spot 인스턴스는 매력적입니다. 할인폭이 크지만, 중요한 단점은 “언제든 종료(interruption)”될 수 있다는 것.이 글에서는 Auto Scaling Group(ASG) + Capacity-Optimized 할당 전략 + Capacity Rebalancing 조합을 써서 Spot 인스턴스의 불안정성을 완화하고 높은 가용성을 확보하는 방법을, AWS 문서와 실제 운영 팁 중심으로 설명합니다.주요 컴포넌트 개념 정리 구성 요소 역할 요약Auto Scaling Group (ASG)인스턴스 수(desired capacity)를 자동으로 유지하며, Spot/On-Demand 혼합 가능. 실패/종료 시 보충 가능.Capacity-Optimized Allocation Strateg.. 2025.09.22
• EKS kubectl 연결 오류 해결기: NAT 교체 이후 발생한 함정 운영 중인 AWS EKS 환경에 Kafka 인프라를 추가하던 중, 갑자기 kubectl이 동작하지 않는 상황을 맞았습니다.이번 글에서는 문제 발생 원인과 해결 과정, 그리고 얻은 교훈을 정리했습니다.문제 상황Kafka 서브넷을 추가한 뒤, kubectl이 더 이상 연결되지 않았습니다.$ kubectl get nodesUnable to connect to the server: dial tcp 10.0.11.83:443: i/o timeout이전까지는 정상 작동DNS는 EKS Private IP로 정상 해석VPN도 연결 상태 양호즉, VPN–DNS–보안그룹 모두 정상인데 트래픽이 도달하지 못하는 상황이었습니다.(새로 생성한 kafka는 vpn에서 접속이 정상적으로 동작하고 있음) 진단 과정1. EKS 엔드포.. 2025.09.22