모도리는 공부중

2025년 초의 기록이다. 후일담 부분은 2026년 봄에 같은 에러를 다시 만나면서 보탰다.일주일 만에 켠 서비스에서 로그인이 안 됐다운영 서버에서 로그인이 안 된다는 보고가 들어왔다. 502가 떴는데, 다시 시도하니까 멀쩡하게 됐다고.확인해보니 그 서비스는 일주일 동안 아무 요청도 없던 상태였다.서버 로그를 열어보니 이런 게 찍혀 있었다.fastapi.exceptions.ResponseValidationError: 1 validation errors: {'type': 'get_attribute_error', 'loc': ('response', 'team_roles'), 'msg': 'Error extracting attribute: OperationalError: (pymysql.err.Ope..

2024년 말에 겪은 인시던트의 회고다.운영 DB에 걸어놓은 인덱스가 사라졌다어느 날 운영 DB를 확인하다가 소름 돋는 걸 발견했다. 분명히 걸어놨던 인덱스가 없어져 있었다. 지운 사람은 없다고 한다. 그럼 누가 지웠을까.인덱스는 없어져도 서비스가 죽지는 않는다. 대신 쿼리가 조용히 느려진다. 그래서 더 무섭다. 에러 한 줄 없이 성능만 야금야금 나빠지고 있었던 거다.삽질 1: 언제 사라졌는지부터 추적일단 "언제" 없어졌는지를 알아야 "누가/왜"를 좁힐 수 있을 것 같았다.현재 상태 확인은 간단하다.SHOW INDEX FROM your_table_name;근데 이건 지금 걸려있는 인덱스만 보여주지, 언제 생기고 언제 사라졌는지는 안 알려준다. information_schema.STATISTICS를 조회하..

회사에서 월별 데이터 조회 API가 느리다는 얘기가 계속 나왔다. 짧으면 3~5초, 길면 12~20초.20초면 보는 사람은 이미 새로고침을 눌렀을 시간이다.코드를 열어봤다. 반복문 안에서 쿼리를 날리고 있었다. 그것도 세 겹으로.참고로 아래에서 말하는 "배치"는 구역(zone) 단위로 입고·출고되는 재고 묶음이고, 매일의 재고 이력이 히스토리 테이블에 쌓이는 구조다.쿼리가 몇 번 나가고 있었나기존 코드 구조를 단순화하면 이랬다.for day in all_days: # 한 달 = 30일 반복 # 1) 해당 일자에 active한 배치 조회 active_batches = db.query(Batch)\ .filter(Batch.zone_id == zone.id)\ .filt..