잉여개발자

[시스템 장애] Cron 작업 과부하에 따른 서버 장애 발생

상황서버 CPU나 메모리가 일정 임계선을 넘어 서, 서비스에 장애가 생기는 경우 복구를 위해 서비스 재부팅 + 알림 메일이 오게 설정해두었는데, 3일 연속 자정에 서버가 임계선을 넘어가 재부팅 되었다는 알림 경보 메일을 받게 되어, 3일차에 문제 해결에 들어가게 되었다.(처음 1일 때는 일시적인 현상으로 지켜보면서 모니터링 만 하다가, 2~3일 때 반복적인 발생하는 이슈로 보았음) 문제 파악다른 시간대에는 문제가 없고, 자정에만 문제가 생기는 것으로 보아, 자정에 실행되는 이벤트 들에 문제가 있다고 생각하여 해당 크론들을 파악하게 되었다.(아래 AWS 지표를 볼 때, AWS는 기본 5분 단위로 평균을 집계(옵션 및 추가 비용을 내면 1분마다 집계 가능) 하여 그래프로 나타내준다. 23시 55분 ~ 00시..

셋팅 방법1. 슬랙 워크 스페이스의 앱에 대한 기본 Key 및 옵션 설정다음 링크 참조 2. 최종 Key 획득다음 key들은 프로젝트 내 환경변수로 관리SIGNING SECRET : ... hashSLACK_BOT_TOKEN : xoxb- ... SLACK_APP_TOKEN(=Socket Token) : xapp-... 3. 로컬 프로젝트 생성슬랙 API 에서 공식 지원하는 - Bolt Python 으로 작성 [링크]슬랙 API 사용 중 필요 권한은 1. 에서 계속 추가 설정코드 배포 4. 슬랙 채널에 앱 추가만든 커스텀 앱을 채널에 등록한다. 5. 트러블 슈팅설치할 봇 사용자가 없습니다. : 앱 명을 자꾸 바꾸다가 발생하였었음 추가슬랙에는 Custom 앱 을 만드는 방법 외에, 주어진 extension..

임시 저장 서비스사내에서 임시 저장 서비스를 구현하면서, 어떻게 할 것인가.. 어떤 방법이 좋은가에 대해 고민했던 부분을 공유해보려고 한다. 결과적으로, 설계 당시에 선택한 방법이 가져올 문제점 등에 대해 충분히 고려하지 못해 나중에 수고스러워 지는 부분도 있었던 것도 같고, 다음에 구현하게 될 때 좀더 빠르고 정확하게 할 수 있도록 기록을 남겨 보려 한다. 임시 저장 서비스 기능 요구 사항상태 : 임시 저장, 생성 완료 (발행)임시 저장 데이터 : 생성, 수정, 삭제, 조회 가능완성 데이터 : 생성, 수정, 삭제, 조회 가능데이터 목록 : 임시 저장, 완성 데이터는 같이 조회가능 해야 함중요 : 완성 데이터가 있어도 임시 저장 데이터가 유효 해야 함중요 : 사용자는 하나의 객체에 대해서만 생서/수정 한..

에러 핸들링 구현기 프로젝트를 진행하며 초기 셋팅시, 에러에 대한 핸들링 처리를 통해 서버에 대한 신뢰도와 안정성을 높이는 작업을 진행하였고, 해당 과정에서 최종 정의한 에러 범위에 대한 정의, 정의 간 고려사항, 처리 방법 등에 대해 정리 해보았다. 에러 핸들링 처리는 목적은 다 똑같지만.. 범위나 방법 등에 대해서는 기업마다 팀마다 다를 것이라고 생각한다. 에러 핸들링 이란? 런타임 과정, 혹은 특정 예외 상황에서 발생하는 에러/비정상적인 상황들 (ValidationError, AuthError, ServiceLogicError 등)에 대해 직접 의도된 동작으로 처리 하는 기술 에러 핸들링의 주요 목표는 다음과 같다. - SW의 비정상적인 종료들로 인한 사용자 경험 저해 방지 - 프로그램에 대한 안정..