들어가며이번 1편은 전체 이관 과정 중 이관 전 클러스터의 현재 상태와, 컨트롤플레인 이관 전에 선행해야 할 점검/설정 항목을 다루려고 한다. 해당 클러스터를 구축하고 꽤 시간이 지난 상태였기 때문에 현 상태를 정확히 파악하는 과정이 필수였다. 현재 상태를 모르면 이관 중 발생하는 장애가 기존 이슈인지, 이관으로 유발된 이슈인지 분리하기 어려워지고, 원인 파악이 늦어지면서 절차를 되돌려 여러 방법을 반복 시도하게 되어 시간 리소스 낭비로 이어질 수 있다. 이를 방지하기 위해 기존 상태를 잘 살피고, 이에 따른 전략을 세우고, 그 후에 이관을 실행하려고한다. 실제 승격/복구 디테일은 다음 편들에서 다뤄보겠다.전체 구조점검 당시 클러스터 전체 구조는 아래 차트와 같았다. 클러스터는 마스터 1대와 워커 3대로..

배경 서비스를 운영 중 크레딧 이슈로 인해, 기존 마스터 노드를 무조건 종료해야 하는 상황이 발생했다. 단순히 노드 한 대를 내리는 작업이 아니라 컨트롤플레인 자체를 다른 노드로 이관해야 하는 운영 이벤트였고, 그 여파로 클러스터 API 접근성, stg/prd 도메인 외부 라우팅(80/443 유입 경로), ingress-nginx 서비스 경로(NodePort 포함), cert-manager 기반 TLS 발급/갱신, ArgoCD 자동 동기화(GitOps) 정합성까지 한 번에 정리해야 했다. 이관 직전 기준으로 클러스터는 4개 노드가 모두 Ready였고, 노드 사용률은 CPU 29%, 메모리 63% 수준이었다. 영향 범위는 핵심 6개 네임스페이스(argocd, cert-manager, ingress-ngin..

SSE 레지스트리에서 thread-safe를 잡을 때 흔히 쓰는 조합은 아래다.Map: ConcurrentHashMapList: CopyOnWriteArrayListsend(write): synchronized(emitter) 같은 직렬화이 셋은 전부 “동시 접근이 생겼을 때 중간 상태를 다른 스레드가 보지 못하게” 만들기 위한 장치인데, 각각 안전이 확보되는 순서와 지점이 다르다.0. 큰 그림: thread-safe를 만드는 대표 전략 3가지 ConcurrentHashMap은 주로 락 + CAS를 섞어서 “Map 구조”를 보호한다.CopyOnWriteArrayList는 스냅샷으로 “순회 안전”을 만든다.synchronized(emitter)는 “같은 연결(write)”을 순서대로 보내게 만든다. 1. ..

3편에서는 SSE를 운영 환경에 올렸을 때 겪을 수 있는 문제들을 큰 덩어리로 정리했다. 그중에서도 실제로 가장 자주 헷갈리고, “가끔씩” 터져서 더 골치 아픈 게 동시성(concurrency) 이슈다. 처음에는 단순히 “EmitterRegistry가 JVM 메모리에 있으니까 thread-safe 컬렉션을 써야 한다” 정도로 정리하고 넘어가기 쉽다. 그런데 운영에서 겪는 문제를 보면, 동시성은 생각보다 단순하지 않다. 컬렉션만 thread-safe 하다고 끝나는 게 아니라, 같은 연결에 이벤트를 쓰는 send 자체가 동시에 들어오면서(interleaving) 알림이 끊기거나 유실된 것처럼 보이는 케이스도 충분히 생긴다. 그래서 이번 글에서는 동시성을 하나로 묶지 않고, 두 종류로 분리해서 정리한다.(A)..

1편에서는 Polling/Long Polling/WebSocket/SSE 등 실시간 기법들을 살펴보았고, 알림이라는 요구사항에는 SSE가 잘 맞는다는 결론에 도달했다. 이번 편에서는 Spring Boot에서 SSE 알림을 구독(연결 유지)하고, 서버 이벤트를 알림으로 푸시하는 기본 구현을 정리한려고 한다. 다음 행위들을 통해 알림 기능을 구현한다.구독(Subscribe): 클라이언트가 /subscribe로 연결을 열면 서버는 emitter를 등록하고 연결을 유지한다.전송(Send): 서버에서 알림이 발생하면 해당 사용자 emitter로 이벤트를 푸시한다.정리(Clean-up): 연결이 끊기면 registry에서 emitter를 제거한다.Heartbeat(Ping): 일정 주기로 ping을 보내 연결 유지..

0. 들어가며: 왜 알림 기능을 구현하게 됐나서비스를 만들다 보면 사용자에게 “지금 알려줘야 의미 있는 순간”이 생긴다. 댓글/답글, 결제 결과, 작업 완료, 상태 변화 같은 것들이다. 내가 개발하던 서비스들에서도 비슷한 요구가 반복됐다. 리포트 생성처럼 시간이 걸리는 작업이 끝났을 때 사용자가 다른 화면을 보고 있거 잠시 떠나 있더라도, 완료 소식을 바로 알려 다음 행동(확인/다운로드 등)으로 자연스럽게 이어지게 하고 싶었다. 또 누군가 내 프로젝트에 입찰을 했거나 배송 상태가 바뀌는 것처럼, 서버에서 바뀐 소식이 사용자 화면에도 바로 반영돼야 하는 경우가 많았다.그래서 이번 시리즈에서는 알림을 ‘실시간에 가깝게’ 전달하는 방법을 다룬다. 다만 (1)편에서는 구현 코드로 바로 들어가지 않고, 먼저 실시..

(OCI 프리티어/테넌시 분산 환경에서 Flannel VXLAN Pod↔Pod 통신이 안 됐던 이유와 해결)0 ) 왜 이걸 하게 됐는지 (상황/증상)OCI 프리티어를 최대한 활용하려다 보니, 같은 팀원 3명의 서로 다른 계정/테넌시에서 만든 인스턴스(노드)를 하나의 k3s 클러스터로 묶어야 했다.문제는 테넌시가 갈라지는 순간부터였다.테넌시가 다르면 보통 VCN/서브넷/보안 규칙/라우팅을 한 덩어리로 통제하기 어렵다.그래서 노드 간 연결을 WireGuard(wg0) 로 단일화해서 10.99.0.0/24 대역으로 묶었다.그리고 worker join도 K3S_URL="https://10.99.0.1:6443"로 붙였다.여기까지는 괜찮았다. 노드는 Ready, API도 정상.하지만 처음부터 문제가 터졌다.✅ 증..