일하기 싫은 퇴물이 왔다.
지금도 추석인데도 애들 와이프 재우고 남은 일 쳐내는 중..
요즘은 그래도 해야할 일거리가 있음에 감사한 수준임.
카톡으로 프리랜서들 종종 연락 온다. 일감 좀 달라고..
다행히 나는 재방문율이 높아서 소개가 좀 되는 편이라 먹고 사는건데,
솔직히 다른 애들은 재방문율 별로 없음.
프리랜서도 자영업의 일종이라 재방문률에 따라 맛집여부가 결정난다.
지금 하는 일도 몇차례 거절했지만 딱 나를 지명해서 해달라는 통에 무리하게 일을 진행 했는데
내가 완성도에서 중요한 부분을 맡고. (프론트,백엔드)
특정 연산 부분(봇 처리)를 외주로 줬는데. 계속 수치 오류를 내는걸 못 잡음..
그래도 10년차라 믿고 맡겼는데, 몇개월의 시간을 더 줬는데 손 놓더라. 커밋한거 보면 알거든
급한데 돈 들어갈 일이 있다고 해서 돈 땡겨서 먼저 줫더니 이런 일이 일어나는건가.
근데 사람이 그렇다 돈 다 받으면. 끝난 것 같고 소홀해지거든. 어느 업계나 똑같음.
어쩌겠나. 내가 수습해야지.
외주 개발이란건 회사에 속해서 하는 일이 아닌 상거래행위임.
소비자가 돈을 집어 넣었으면, 물건이 나와야 됨. 무조건 나와야 됨.
그러니 잘못된 물건이 나온다? 120% 내 잘못인거임.
그렇게 저쪽 파트의 소스코드를 뜯어서 봤는데.
가끔 개발연차가 무색한 코드를 볼 때가 있다. 근데. 그게 정상임.
누구나 시간에 쫒기고 하기 싫은(?) 상태에 놓인 상태에서 정상적인 코드를 바라면 안됨.
그렇게 나는 추석에도 나의 죗값을 치루는 중임.
코드가 MVP나 소규모 유저용도면 그럴 수 있는데, B2C인데 절대 프로덕션에서 사용할 수 없는 코드들이 잔뜩임..ㅠ
간단히 몇가지 예를 들어보겠다.
절대 루프내에서 쿼리를 날리면 절대 안되는데 의식에 흐름에 따라 가끔 루프내에 쿼리가 존재하는 경우가 있다.
한번 콜에 수십번의 쿼리를 추가로 날리고 await으로 기다리기까지 하니까. 당연히느림.
이건 저연차들이 반드시 실수하는 부분인데,
뭐 빠르게 구현해야 하는 상황이니까 리펙토링 못 했거니 하고 이해해야 함.
이해 못한다고해도 어쩔껀데... 결국 내가 해야되는건 변하지 않음 ㅎㅎ
두번째 모든 봇 실행이 매분 0초다.
문제는 매분 0초에 수십개의 봇이 한번에 도니까. DB입장에선 일시적으로 호출이 몰린다. 그러면? 락이 걸려서 더 느려짐.
즉, 봇 실행 계획이 없다. 종류별로 어떤건 10초, 어떤건 15초, 30초, 이런식으로 적절히 분배가 필요하다.
정산이 잘못되는 이유도 위와 같았다. 한번에 몰리니까.
동시성 문제가 걸려서, 실행 중 타임아웃 오류 뿜고 죽고
해당타임에 되야할 정산이 제대로 안되서 시퀀스 이빨이 빠지니까 정산오류가 나는거임.
#스프레딩의 중요성
세번째 외부 API의 IP 호출제한에 대한 대응.
외부 서비스의 API에서 데이터를 끌어와야 하는데, 대부분 RateLimit이 있고 사용량이 늘다보면
주어진 횟수를 초과하게 할 때가 반드시 생김. 특히 방화벽에서 RateLimit이 설정된 경우 IP당 호출을 제한하기도 함.
놀랍게도 리밋이 초과되면 그냥 몇초를 기다렸다가 처리하도록 코딩되어 있었다...
그렇게 큐에 쌓인걸 처리하던 수십개의 봇이 기다리기만 하다가 스턱걸림... ㅋㅋ
그렇게 가끔 풀릴 때 한번에 호출이 되니까
동시성 문제로 레이트리밋 계산이 늦게 되서 IP 1분 차단당하고 그렇게 개판이 된 것.
일단 다른 인스턴스에 프록시 서버를 구성했음.
그 프록시 서버 리스트를 만들고(프록시 풀), 리볼버 권총처럼 한칸씩 회전하며 호출하도록 수정함.
1번 프록시의 레이트리밋을 카운트하다가 다 찰 것 같으면, 2번 프록시를 확인하고. 여유가 있으면 콜.
그러면 2번 프록시를 통해서 트래픽이 나가므로 IP리밋을 피할 수 있다.
이거시 발칸포 원리임.
이거 유지보수도 하청주고 나는 중간 뽀찌만 먹을려고 했는데,
이렇게 주면 x되겠다 싶어서 그냥 내가 다 하는 쪽으로 해야할 듯.
안 그래도 매출 줄어서 한푼이 아쉬운 상황이었는데 오히려 럭키비키된듯?
하.. 위임을 해서 인적 레버리지를 못쓰면 부자가 못 되는데..... 수없이 많이 시도 해봤지만 죄다 실패함.
그동안 정글에서 만난 개발자들은 죄다 뭔가 이상하고 문제해결을 잘 못함.
내가 네임드 회사 출신이었으면 주변이 달랐겠지? 하고 생각도 가끔 듬.
하긴 만족 할만한 잘하는 친구들이 연봉 많이 주는 빅테크에 가만히 있지 여기 있겠나 싶음.
아무튼 정글로 나오면 문제해결을 잘해야한다.
못하면 돈을 못 받거든 ㅋ
오늘의 푸념. 끝~
반복문 안에서 쿼리날리는게 조인보다 더 낫다던 개발자가 생각나네여
보통 그런 경우라면, 그냥 조인될 테이블을 TTL박아서 캐시 해버리고 받아온 결과에서 for문으로 끼워넣기 하는게 나은 선택이 될 때가 있음. 조인 걸릴 테이블은 자세히보면 별로 변하지 않는 경우가 많으면 캐시가 유리함. (이름, 닉네임, 이메일, 레벨 뭐 이정도?) 그래서 DB를 볼 때 업뎃 빈도도 봐야함.
근데 반복문 안에서 쿼리 날리는건, IO 보틀넥 개념이 없는거라.. 걔는 공부 좀 해야함.
근데 진짜 놀랍게도 20년차 개발자임 (구라아님)
어 그거 정상이야.. ㅠ ㅋㅋㅋㅋ 근데 그 정도되면 그 친구의 생존전략에서 배울점이 있음.
근데 왜 정상으로 받아들이는게 낫냐면, 불신하고 미워할수록 팀플레이만 해치고 결국 나의 팀과 내 실적의 손해로 돌아옴. 그냥 그럴 사정이 있었겠지 하고 이해하는게 내가 제일 편해
그럴수도있긴하지 그런데 왜그런지 이해하지 않고 그렇게 경험적인게 문제지 애초에 그런식의 조인쿼리가 문제겠지만
대충 예를 들자면 해시조인이 걸리고 양이너무많고 메모리가 적다면? 메모리랑 하드스왑 하루종일 걸려서 죽어도 처리가안됨 당연히 쿼리튜닝이 필요한 문제지만 배울 의지가없으면 노가다로 빠른걸 찾는거지
외부 API 호출제한 공감 씨게 되네
외부 연계 서비스는 프로덕션 모드에선 대부분 문제를 일으키는 요인 중에 하나지.. ㅠ 고통임.
혹시 텔레그램 강제초대 봇임?
그런건 안함. 왜냐면 주변 지인중에 크몽에서 가리지 않고 일했다가 실제로 영업방해 형사고소들어와서 ㅈ된 주변인 한명 있음.
그래서 뭔가 구린 외주는 안해 ㅎ
나도 거절했는데 다른 아이디로 두번 물어보길래
3개의 사례 모두 좋네. 참고 잘하고 감. 감사요~
Thundering Herd problem 이구먼. 해결책은 random jitter 주는거
반복문 쿼리날리는거 닉네임 중복되는거에 뒤에 숫자 차례대로 붙이는 로직에서 봤는데 이거 정상일까? abc 를 입력하면 abc1 abc2 .. abc3 까지 있으면 3번쿼리 돌고 abc4 가 되던데
like를 쓰던뭘하던 저건 정신병자 쿼리지