일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- 노마드코드
- 노개북
- iamport
- 노마드코더
- HTTP
- 경제
- 주식
- Cache
- redis transaction
- redis
- 아임포트
- transaction
- 레일즈
- Python
- 레일즈 캐시
- 사업
- Rails
- trouble shooting
- CU
- 재태크
- API
- restful
- 투자
- django
- Watcha pedia
- Race Condition
- rails cache
- memcached
- 북클럽
- Today
- Total
목록트러블슈팅 (2)
Stay hungry, Stay foolish

현재 운영하고 있는 서비스의 인덱스 페이지가 많이 아팠습니다. 페이지를 렌더링 하는 시간이 프로덕션 기준 7s (로컬에서는 10s 를 넘겼습니다 ㅠㅠ) 를 넘어가는 끔찍한 상태였습니다. 저 정도 로딩 속도면 유저분들 다 도망갔어도 할 말 없습니다... 근본적으로 개선을 하긴 해야겠다 마음먹었습니다. 음.. 근데, 어디가 문제지...? 해결과정 route53, nginx loadbalancer 부터 다 뜯어봐야 하는 건가... 싶어 절망할 뻔했으나 일단 눈에 보이는 것부터 체크하기로 했습니다. 무식하지만 정직하게 체크했습니다. 컴포넌트를 하나씩 빼서 그 부분만 렌더링 시키며 속도를 확인해 보는 방식으로 말이죠. 이런 식으로 컴포넌트를 하나씩 꺼내면서 속도가 유독 느리다 싶은 부분을 확인하다 보니 문제는 비..

내가 재직 중인 회사는 실시간 멘토링 서비스를 위해 Zoom의 thirdparty api를 이용한다. 그중 멘토링 클래스에 참여한 참여자들의 참석시간을 실시간으로 관리하며 내부 admin 및 고객 측에 제공하는 자료로 활용 중인데 해당 참석시간이 찍히지 않는 버그가 생겼고 이를 해결한 과정에 대해 작성해 보고자 한다. 아래 그림은 해당 기능에 관련된 flow 차트이다 위 flow 간 문제를 탐색하는 과정은 데이터가 보이지 않는 View file code에서부터 역산하며 탐색을 진행했다. Flow 간 문제 탐색 과정 1️⃣. DB(registrant) ← Contoller(zoom_webhook) View file에서 보이지 않는 zoom 참석시간의 데이터는 registrant 테이블의 joined_at ..