악분의 블로그

개요 이 글은 운영 중 접한 ""오류를 어떻게 해결했는지 설명합니다. 영상은 아래 유투브에서 만나볼 수 있습니다. https://youtu.be/OirM_4ro76M 오류 발견 FastAPI로 만든 서비스에서 "signal only works in main thread" 오류가 발생했습니다. 처음 보는 오류여서 열심히 검색을 했습니다. 검색을 종합해보니 직접 예제를 만들어서 정확한 원인을 분석하는게 좋을 것 같았습니다 ChatGPT를 이용하여 예제 생성 어떻게 예제를 만들어볼까 고민하다가 chatgpt이 문득 떠올랐습니다. 긴가민가하는 마음으로 chatgpt에게 도움을 요청하니, 놀랍게도 예제코드를 만들어줬습니다. 예제 코드는 아래와 같습니다. import threading import signal im..

상황 어떤 서비스에서 오류가 발생하여 코드를 살펴봤습니다. uuid를 이용한 로직이 있었는데 uuid 생성을 tiemstamp로 되어 있었습니다. 처음 봤을 떄는 timestamp이기 때문에 아무 문제가 없을 거라고 생각했습니다. 분석 시간을 갖고 생각을 해보니 uuid를 생성하는 시점이 사용자 요청이 올 때입니다. 사용자 요청은 api가 호출되었을 때를 의미합니다. 만약 여러 사용자가 동시에 요청하면, 시간이 같으니 timestamp가 중복되는 상황이 발생할 수 있을 것 같았습니다. 테스트 동시 요청을 테스트하기 위해 부하 테스트를 진행했습니다. 도구는 locust를 사용했습니다. 초당 10 user로 테스트해보니 곧바로 오류가 발생했습니다. 결국, uuid를 timestamp로 설정해서 같은 시각에 ..

개요 쿠버네티스 백엔드 pod가 livenessprobe가 실패하여 pod재부팅이 된 상황을 직면했습니다. 자세히 살펴보니 비동기 로직이 올바르게 구현되어 있지 않아 probe가 실패했습니다. 이 글은 비동기 로직을 수정하기 위해 공부한 내용을 정리했습니다. 영상으로도 만나볼 수 있습니다. 영상: https://youtu.be/hS-6fJJpAgk fastapi 비동기 로직 먼저 fastapi가 어떻게 비동기를 처리하는지 살펴봤습니다. fastapi는 ASGI Framework로 구현된 웹 애플리케이션입니다. 그리고 fastapi를 실행하는 uvicorn은 ASGI Framework를 실행하는 ASGI Server역할을 수행합니다. 이 구조는 WASspring boot와 거의 비슷하다고 느꼈습니다. 구조..

Elasticsearch에서 알 수 없는 이유로 데이터 삽입이 느린 상황을 발견했습니다. Elasticsearch 숙력도가 낮아 어떻게 분석해야할지 몰랐기 때문에 어떤 문제로 속도가 느린지 감이 안왔습니다. 네트워크가 느린건지, 속도가 느린건지 등 어떤 관점에서 분석해야하는지 알 수가 없었죠. 결과론적으로 각 인스턴스 자원(cpu, memory)를 scale up을 해서 지연을 없앴습니다. 컨테이너 로그가 분당 2천만건 이상 Elasticsearch으로 쌓이는 상황이어서, Elasticsearch가 indexing과 데이터를 저장하는 속도가 느린 걸로 판단이 되었습니다. 그렇지만, 앞으로 이런 상황이 나온다면 어떻게 분석을 해서 cpu/memory가 부족한지 판단할지 어려운 것 같습니다.

1월 1일부터 응급실을 가는 등 2022년은 21년에 비해 기억에 남는 추억이 많았던 해였습니다. 2022년 정리 1. 혼자서 업무 처리하는 방법을 경험 2021년 11월 사수가 퇴사하면서 22.12월까지 사수 없이 혼자 일했던 것 같습니다. 기술적으로 어려웠던 상황도 많이 만났지만 혼자서 사람과 대화하면서 일을 해결해야하는 과정이 너무 힘들었습니다. 우스개소리로 갑-을-병-정 관계에서 정의 위치에 있어서 더욱더 힘들었던 것 같습니다. 당시 생각하면 기술이 어려운 것보다는 사람을 만나는게 두려워서 출근하기 싫은 기억이 떠오릅니다. 하지만, 시간이 약이라고 했나요?. 회사를 대표하여 혼자회의에 참여하는 등 경험이 조금씩 쌓이자 두려웠던 마음이 조금씩 사라졌습니다. 그리고 어느새 주변 동료와 갑-을-병 관계..

개요 A팀이 프록시 목적으로 띄운 nginx pod가 취약점이 있어 수정하라고 요구받았습니다. A팀은 nginx pod설정을 고쳐도 권고받은 취약점이 사라지지 않아 저에게 도움을 요청했습니다. 분석 취약점은 405 method not allowd를 에러로 처리하지 않고 그대로 노출시켰다는 것입니다. default 405응답에는 nginx문자이 있었습니다. A팀은 405예외 처리를 했지만 계속 취약점이 발생했습니다. 저는 쿠버네티스라는 환경과 오류응답에 nginx라는 키워드를 보고 nginx ingress controller오류이지 않을 까 생각했습니다. 그래서 먼저 ingress controller가 nginx인지 먼저 확인했습니다. 예상대로 nginx였습니다. 그 다음, nginx ingress con..

오늘 회의를 하다가 컨테이너 로그 수집기준에 대해 잠깐 이야기하는 상황이 있었습니다. 이야기 내용이 매우 흥미로웠습니다. 회의 끝에 가장 중요한 기준은 "유실유무"였습니다. 유실되어도 실시간이 중요하다 유실되면 안되고 신뢰성이 중요하다 컨테이너가 갯수가 기하급수적으로 늘어나면 로그 수집에 장애가 생겨 일부 로그가 수집이 안될 수 있습니다. 물론 장애를 완벽히 고치면 좋겠지만, 인원이 한정되어 있고 다른 업무의 우선순위가 높으면 임시적으로 장애를 고칠 수 밖에 없습니다. 그래서 회의에서 "유실유무"라는 기준이 이야기 나왔습니다. 신뢰성이 중요하다면 아키텍처를 확인하고 완충장치(예: 카프카)를 넣기로 검토하기로 했습니다.

개요 오늘 일을 하다가 우연히 아이디어가 떠올라 불편한 로직을 변경했습니다. docker-compose명령어인 build와 push를 사용하여 행위를 명시적으로 표현할 수 있어. 쉘 스크립트에 비해 의도를 명확하게 했습니다. # 변경 전 /bin/bash deploy.sh # 변경 후 docker-compose build docker-compose push 상세내용 로컬에서 약 40개의 dockerfile을 build하고 push 하는 간단한 쉘 스크립트가 있었습니다. 각 dockerfile이 위치한 경로가 있어 반복문으로 docker build를 수행하는 형태였습니다. TARGETS=" dir1 dir2 dir3 " for target in ${TARGETS}: do docker build -t IMA..