호에에

IT PICUTRE

• [Network] Longest Prefix Match (LPM) 알고리즘 네트워크에서 패킷이 전송될 때, “이 패킷을 어디로 보낼까?” 를 결정하는 핵심은 라우팅 테이블 조회(Routing Table Lookup) 입니다.이때 가장 중요한 개념 중 하나가 바로 Longest Prefix Match, 즉 가장 긴 접두사 일치입니다.🧠 1. Longest Prefix Match란?**Longest Prefix Match (LPM)**는 IP 라우팅에서 사용되는 기본 규칙으로,패킷의 목적지 IP 주소와 라우팅 테이블의 네트워크 주소를 비교하여, 가장 길게 일치하는 네트워크(프리픽스)를 선택하는 알고리즘입니다.👉 즉, 여러 경로가 일치하더라도 더 구체적인(서브넷 마스크가 긴) 경로를 우선 선택합니다.🌐 2. 예시로 이해하기다음과 같은 라우팅 테이블이 있다고 해봅시다:네트워크넷마.. 2025.10.27
• Azure App Registrations “외부(또는 내부) 애플리케이션이 Azure 리소스에 접근할 때, 인증·보안을 중앙에서 관리하기 위한 Azure AD(Microsoft Entra ID)의 기능” 이라고 보면 됩니다. 🔐 1️⃣ 개념 요약App Registration = Azure AD(Entra ID)에서 애플리케이션의 ‘신원(identity)’을 등록하는 서비스이걸 등록하면 Azure는 그 앱에 대해 다음을 관리합니다: 역할 설명자격 증명(Credentials)Client ID, Secret(비밀번호), Certificate 등 발급 및 관리권한(Permissions)Microsoft Graph, KeyVault, ACR, Storage 등 어떤 리소스 접근 허용할지 지정정책 및 보안 제어MFA, Conditional Acces.. 2025.10.27
• Kubernetes에서 애플리케이션 설정 우선순위 이해하기 목차 ConfigMap, Secret, 그리고 내부 설정 중 무엇이 이길까?Kubernetes에서 애플리케이션을 배포하다 보면,“앱 내부 설정값이 우선일까, ConfigMap/Secret이 우선일까?”라는 의문이 자주 생깁니다.특히 운영 중인 서비스의 환경설정이 기대와 다르게 동작할 때,이 우선순위를 정확히 이해하고 있지 않으면 디버깅이 어렵습니다.이 글에서는 Kubernetes가 실제로 설정값을 어떻게 주입하고,최종적으로 어떤 값이 적용되는지를 프레임워크별로 정리해보겠습니다.1️⃣ Kubernetes는 ‘우선순위’를 결정하지 않는다먼저 중요한 사실 하나:Kubernetes는 단지 환경 변수나 파일 형태로 설정을 주입할 뿐,어떤 값이 “최종적으로 우선”인지는 애플리케이션의 설정 로더가 결정합니다.즉.. 2025.10.23
• Kubernetes ConfigMap & Secret 자동 반영 — Stakater Reloader Kubernetes를 운영하다 보면 ConfigMap이나 Secret을 수정했는데,이를 참조하는 Pod가 자동으로 재시작되지 않아 새로운 설정이 반영되지 않는 경우가 많습니다.이 문제를 해결하기 위해 탄생한 오픈소스 컨트롤러가 바로 Stakater Reloader입니다.👉 GitHub 저장소👉 공식 문서📘 1. Stakater Reloader란?Reloader는 Kubernetes에서 ConfigMap 또는 Secret이 변경되었을 때이를 사용하는 Deployment, StatefulSet, DaemonSet 등의 롤링 업데이트(rolling update) 를 자동으로 트리거해주는 Controller입니다.👉 How it works (공식 문서)이 프로젝트는 오픈소스로 제공되며,라이선스는 Apac.. 2025.10.17
• “Swiper is not defined”와 “Mixed Content” 오류, IIS 웹 서비스를 운영하다 보면 "같은 코드인데 어떤 PC에서는 정상, 어떤 PC에서는 오류"처럼정확한 원인이 헷갈리는 문제가 종종 발생합니다.이번 글은 실제로 AWS ALB + Windows VM(IIS) 환경에서Swiper is not defined 및 Mixed Content 오류가 일부 PC에서만 발생했던 문제를코드 수정 없이 인프라 레벨에서 완벽히 해결한 기록입니다.🧠 1. 증상 요약🧩 콘솔 오류 메시지common.js?v=1745305927:39 Uncaught ReferenceError: Swiper is not defined at Object.TopnavScroll (common.js?v=1745305927:39:9) at Object.init (common.js?v=174530.. 2025.10.17
• 클라우드 계정이 다른 개발 / 운영 환경의 CIDR 범위 설정 규모에 상관없이일반적으로 하나의 서비스를 이용하게되면 보통 하나의계정에 개발,스테이징, 운영 환경을 구축하는게 일반적입니다. 한눈에볼수도 있고 연동시 편한 장점이 있기 때문입니다. 하지만 이번에 개발과 운영의 root 계정을 분리하여 운영하게 되었는데 이때 Best practice 네트워크 CIDR 은 서로 다르게 하는것 입니다. 간단히생각했을때 똑같이 구성해도 계정이 다르기 때문에 별문제가 안되어 보이지만 구분해는게 더 이점이 있습니다. 그에대해 이번 포스팅에서 살펴보겠습니다. 목차 왜 다르게 해야 하나? (step-by-step)VPC 간 연결(피어링/Transit Gateway/VPN/Direct Connect) 대비나중에 dev ↔ prod, shared-services ↔ prod 같은 동일 .. 2025.10.10
• [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