회사에서 에이전트로 개발을 하는데(Obviously.. 요즘 에이전트 없이 개발하는 사람도 있어?) 고루틴을 쓸 때 변수를 캡쳐해서 쓰도록 코드를 짜더라.그 이유가 궁금해서 에이전트랑 대화하다가 배운 내용을 정리하면 좋을 것 같아서 짧게 정리해봤다클로저(Closure)란?클로저는 자신이 정의된 렉시컬 스코프(lexical scope, 다른 말로 정적 스코프(static scope))에 있는 식별자들을 잡아두는 함수클로저는 '값' 아니라 '변수' 자체를 참조. 즉, 같은 변수를 여러 번 갱신하면, 그 변수를 캡처한 모든 클로저는 갱신된 값을 보게 됨package mainimport "fmt"func main() { x := 0 fn := func() { fmt.Println(x) } x = 42..

~Go 프로파일링 적용 시리즈 - 배치 서버 ver.~[1] 배치 서버 OOM 분석을 위한 메트릭 설계와 프로파일링 전략[2] Prometheus 라이브러리를 활용한 Go 메트릭 구현[3] Prometheus 대시보드를 활용한 메트릭 분석 가이드🟨 OOM 발생 시나리오 분석OOM 발생 원인을 찾기 위해 다음 시나리오를 고려해볼 수 있습니다.▫️ 시나리오 1 : 순간적인 메모리 급증아주 짧은 순간에 발생하는 메모리 급증 시나리오입니다. 평소에는 메모리 사용량이 낮다가, 특정 순간에 시스템이 감당할 수 없을 만큼 한꺼번에 많은 메모리를 OS에 요청할 때 발생합니다. 예를 들어, 특정 작업을 위해 수백 개의 고루틴을 띄우는 순간이 있습니다.Prometheus는 보통 수 초~ 수십초(scrape interva..

보호되어 있는 글입니다.

~Go 프로파일링 적용 시리즈 - 배치 서버 ver.~[1] 배치 서버 OOM 분석을 위한 메트릭 설계와 프로파일링 전략[2] Prometheus 라이브러리를 활용한 Go 메트릭 구현[3] Prometheus 대시보드를 활용한 메트릭 분석 가이드🟨 이 시리즈를 연재하게 된 계기회사에서 운영 중인 배치성 서버에서 간헐적인 OOM(Out of Memory) Killed 현상이 발생하기 시작했다. 이 서버는 NFT 컬렉션 정보 수집, 메타데이터 수집, 토큰 가격/거래량 추적, 게임 라이브 데이터 수집 등 다양한 배치 작업을 주기적으로 수행하는 핵심 인프라였기 때문에, OOM으로 인한 서비스 중단은 전체 데이터 파이프라인에 치명적인 영향을 미칠 수 있는 상황이었다. 문제의 원인을 신속하게 파악하고 해결할 필요..

~Go Context 시리즈~[1] Context에 관한 고찰 - 1 : Context 란[2] Context에 관한 고찰 - 2 : Context의 중요성과 고루틴 누수[3] Context에 관한 고찰 - 3 : Graceful Shutdown의 미학이전 시리즈에서 우리는 Context가 무엇이고 Context를 이용해 개별 작업의 생명 주기를 어떻게 제어해야 좀비 고루틴을 방지할 수 있는지 살펴보았다. 이제 마지막으로, Context가 애플리케이션 전체의 생명주기를 어떻게 관장하며 ~우아한 종료~ 라는 현대 서버 애플리케이션의 필수 덕목을 구현하는지 살펴보려고 한다. 우아한 종료는 단순히 서버를 끄는 행위를 넘어, 시스템의 안정성과 데이터의 정합성을 보장하는 섬세한 오케스트라 지휘와 같다. 그리고 그..

~Go Context 시리즈~[1] Context에 관한 고찰 - 1 : Context 란[2] Context에 관한 고찰 - 2 : Context의 중요성과 고루틴 누수[3] Context에 관한 고찰 - 3 : Graceful Shutdown의 미학Context가 중요한 이유Context의 중요성을 간과하고 context.Background()를 남발하는 코드는 당장에는 문제없이 동작하는 것처럼 보일 수 있다. 이는 마치 브레이크 없는 자동차로 텅 빈 직선 도로를 달리는 것과 같은데, 장애물이 나타나거나(에러 발생), 교차로에서 멈춰야 하거나(요청 취소), 주차해야 할 때(서버 종료) 비로소 재앙이 시작된다...후후... (그나저나 AI 비유법 기깔난다..ㅋㅋㅋㅋ 다시 돌리려다가 웃겨서 그냥 가져옴)..