분류 전체보기 347

오늘 느낀 것 — 개발보다 더 중요한 것

오늘 회의를 들어가면서 좀 많은 생각이 들었다. 개발만 잘하면 되는 줄 알았는데, 그게 전부가 아니었다.결국 서비스는 '신뢰'로 돌아간다는 걸 느꼈다.같은 팀에서 마이그레이션 이슈가 하나 있었는데, 그게 단순히 기술적인 문제가 아니라일본의 수주가 막히는 상황까지 이어지고 있었다. 회의 분위기도 무겁고,영업 쪽에서는 당연히 화가 날 수밖에 없는 상황이었다.그때 느꼈다. 우리가 만드는 건 그냥 코드가 아니라,회사의 신뢰라는 걸. 개발은 기본이고, 그 위에 책임이 있다개발자는 보통기능이 잘 동작하는가에 집중한다. 근데 오늘 보니까 그게 끝이 아니었다. 문제가 생겼을 때 얼마나 빠르게 대응하는지, 사전에 얼마나 막을 수 있었는지, 그리고 결국 누가 책임지고 해결하는지 이게 훨씬 중요했다.오너쉽이라는 것오늘..

TIL 2026.03.20

DB CPU가 미친듯이 튀었는데, 범인은 DB가 아니었다

1. 갑작스러운 DB CPU 스파이크 평화롭던 중 갑자기 DB CPU가 비정상적으로 치솟는 현상이 모니터링에 포착됨.서서히 오르는 형태가 아니라, 특정 시점에 아주 순간적으로 확 튀어 오르는(Spike) 형태였음. 2. 1차 원인 파악 - DB 쿼리 로그 확인 DB CPU가 튀었으니 당연히 제일 먼저 DB 쿼리 로그를 까봄.확인해 보니 특정 쿼리들이 무더기로 호출되고 있었음. 특히 평소에도 약간 무거웠던(느린) 쿼리들이 다량으로 발생함. 여기서 1차 의문 발생:"대체 왜 갑자기 이 쿼리들이 한 번에 몰렸지?" 단순히 트래픽이 늘어난 거라기엔 패턴이 너무 부자연스러웠음. 3. 2차 원인 파악 — GW(Gateway) 트래픽 분석 원인을 찾기 위해 앞단 GW 로그를 확인함. 특정 시간대에 ..

TIL 2026.03.18

OpenSearch로 느린 API Top 뽑는 방법

왜 했냐서비스 느리다는 얘기 나오면어디가 느린지 바로 못 찾으면 답 없음 로그에서어떤 API가 느린지언제 느린지얼마나 느린지바로 뽑을 수 있어야 함그래서 OpenSearch로 Top N 분석함 오늘 한 거특정 시간대 기준으로 조회request_time 기준 느린 요청 찾기Top 50 정렬URI별 bytes 합으로 트래픽 분석/socket.io/ 같은 노이즈 로그 제외 Discover로그 하나씩 보는 용도→ 디버깅할 때 좋음Visualize통계 보는 용도→ Top N, 평균, 합계 이런거 보기 좋음실무에서는 둘 다 씀 느린 요청 Top 50 뽑기방법 (Discover 기준)시간 필터 설정정렬 기준을 request_time으로 변경내림차순(desc) 정렬러면 느린 요청부터 쭉 나옴

TIL 2026.03.17

Terraform 쓰는 이유

그냥 내부에서 프라이빗 클라우드인 경우 : 물리서버 서버들 위에 가상화 플랫폼을 올림. 예VMware vSphereOpenStack 콘솔에서 생성시 인프라팀이vSphere 접속→ VM 생성→ CPU / RAM 설정→ 네트워크 연결→ IP 할당 하고 개발팀에 서버 전달. Terraform 왜 쓰는지인프라를 코드로 관리하기 위해 사용함 (Infrastructure as Code)서버, 네트워크 같은 인프라를 콘솔에서 수동으로 만드는 대신 코드로 생성 가능API로 인프라를 생성한다는점 ! ( 보통은 외부 aws에 vm 위치됨) ex) VM 생성VPC / Subnet 생성Load Balancer 생성Kubernetes Cluster 생성 Terraform 실행하면 내부적으로 클라우드 API 호출해서 인프..

TIL 2026.03.16

Ansible 쓰는이유

서버 여러 대에 동일한 작업을 해야 할 때 SSH 접속해서 쉘 명령어 하나씩 치는 건 비효율적임 Ansible 사용하면 YAML로 작업 정의해두고 한 번에 여러 서버에 실행 가능! SSH 기반이라 별도 Agent 설치 필요 없음 EX : ansible-playbook install-docker.yml ->여러 서버에 동시에 docker 설치 가능 또 하나 장점은 서버 상태 기반으로 동작한다는 점이미 설치된 패키지는 다시 설치하지 않음그래서 서버 환경을 항상 동일한 상태로 유지하기 쉬움k3s 구축할 때도 서버 초기 설정docker 설치k3s master / worker 설치모니터링 agent 설치 같은 작업을 자동화하기 좋음

TIL 2026.03.16

fcm 알림 흐름 정리

FCM 알림 기능 붙일 때 처음엔 단순히 API에서 바로 Firebase 호출하면 되지 않나 생각했었음.근데 실제 서비스에서는 생각보다 고려할 게 많았음.특히 아래 같은 문제들이 있었음.요청이 몰릴 때 API 응답이 느려질 수 있음FCM 전송 실패를 API 요청 흐름 안에서 바로 처리하면 사용자 응답까지 지연될 수 있음재시도 로직, 실패 로그 추적, 토큰 만료 처리 등을 한 군데서 관리하기 어려움대량 발송이나 비동기 처리 시 안정성이 떨어질 수 있음그래서 BullMQ + Redis + Firebase Admin SDK 조합으로 알림 구조를 분리해서 처리했음. 이번 글에서는FCM 알림이 생성되고, 큐에 적재되고, 워커가 처리하고, 실패 토큰을 정리하는 전체 흐름을 정리해보겠음. 왜 API에서 바로 FC..

TIL 2026.03.11

Docker - ContainerD 차이

유데미 강의보는데 헷갈려서 정리 1) 처음에는 그냥 Docker 하나였다초기에는 컨테이너 = 거의 Docker 였음.Docker 안에는 사실 여러 기능이 다 들어있었음.초기Docker ├ 이미지 빌드 ├ 이미지 다운로드 ├ 컨테이너 실행 ├ 네트워크 ├ 스토리지 └ API 그래서 쿠버네티스도 처음에는Docker를 직접 사용했음. 2) 문제 발생근데 문제가 있었음.Docker는 너무 큰 프로그램이었음.쿠버네티스가 원하는 건 사실 딱 하나였음. 컨테이너 실행 ( 컨테이너 : 프로그램 + 실행환경을 묶어서 바로 실행되는 패키지)컨테이너 하나 실행해줘컨테이너 중지해줘컨테이너 상태 알려줘 근데 Docker 전체를 붙여야 했음.그래서 Kubernetes 팀이 생각함."컨테이너 실행하는 표준 인터페이스 만들자" ..

TIL 2026.03.07

잡담 ) 파티움 하우스 수원 현장 계약 후기

작년 12월 25일 프러포즈 받고드디어 결혼 준비를 시작한다 +.+우리가 생각한 결혼식 조건으론​-일정: 내년 2~3월 토요일 낮-위치: 수원-보증 인원: 100~150명-소규모 웨딩홀 선호-짧은 버진 로드 선호​​원래 주목받는 게 싫고결혼식 싫어싫어 인간이라아예 생략하고 싶었지만 결혼은 둘 만하는 게 아니니ㅠ최대한 작은 홀로 알아보기로 했다​우리가 투어한 곳은1. 플로렌스2. 라온 몽드3. 파티움하우스 수원총 세 곳을 둘러보았고최종 계약은 파티움 하우스로 했다​그래도 방문했던 곳도간략하게 후기를 풀어보겠다​플로렌스​위치는 수원 시청역 10번 출구 앞이라 뚜벅이로 오기 좋다​ ​플로렌스는 돌잔치 전문 업체다 보니결혼식 느낌으로 진행하긴 어렵고정말 정말 작게 결혼하길 원한다면직계가족 웨딩으로 하긴 괜찮을 ..

카테고리 없음 2026.03.05