일단 문제점은
Kakao api를 호출 할 수 있는 쿼터 수를 넘지도 않았는데 tooManyRequest 429 에러가 발생했습니다
당연히 쿼터수 문제일 줄 알고 확인해봤지만 아니였습니다
api를 호출하는 쓰레드는 유저당 5개씩 동시에 2 유저가 사용합니다.
즉 10개의 쓰레드가 api를 호출하게 되는데
초당 거의 20개의 요청을 후두두둑 쏟아내니까 카카오측에서 DDOS 공격으로 인식해서 그런거 같습니다
요청에 약간의 ms 단위 딜레이를 주니 정상적으로 잘 작동합니다.
단 문제는 모든 로직을 처음부터 동작시켜야 하기 때문에
원래같으면 서비스에 접속하신 순서대로 Location 기능이 제공되어야 하지만 재부팅으로 인해 다 날아가버려서 순서가 의미가 없어져 버렸습니다... ㅈㅅ합니다
현재 딱히 요청하실 필요 없이 자동으로 모든 유저에 대한 작업이 수행중에 있으며 순서는 아마도 스트라바 가입일자 같습니다? 왜그런진 모름ㅋㅋ
암튼 벌써 3분 정도 완료되신거로 확인됩니다. 서비스를 이용중이신 유저분들이 '61명' 씩이나 되는만큼 하루만에는 절대 불가능합니다 재송합니다
근데 이건 제가 뭘 어케 할수있는 부분이 아니라서... 카톡한테 일단 쿼터 늘려달라고 하긴했습니다.
아무튼 나중에 천천히 한번 들어가보세요 되있을지도?
Location 기능 외의 다른 기능들은 정상적으로 제공되고 있습니다.
사용해주셔서 정말 매우 감사합니다. 많은 공부가 되고있습니다
해당 댓글은 삭제되었습니다.
pulling 이라는 말씀이신가요. 제가 좁밥이라 잘 이해를 잘못하겠네요. 혹시 설명해주실수 있으신가요? 천천히 상황 제 설명드리자면 kakao api를 요청하기위해선 개발자 계정의 개인토큰을 헤더에 담아서 보내야 합니다 각 개발자 계정당 하루에 api 요청할 수 있는 횟수가 10만회로 제한되어 있습니다. 방법으로 계정 여러개 돌려막기도 생각해봤는데 이건 영부 밴 때린 다고 하더라고요
자바 webClient get Request로 하는거 맞습니다. 이게 수백건 수준이 아니라 라이드 하나당 거의 50번 조회 하는데 1초에 하나의 라이드를 처리하고 하나의 라이드를 처리하는 쓰레드가 동시에 10개 동작중이라서 이론상 1초에 500번 요청을 무제한적으로 쏟아내서 차단하는게 아닌가 하고 의심중입니다
동시 요청 충분히 가능성있어보이네요. 원래같으면 로컬에서는 이렇게 동시에 2명의 유저를 처리해본적이 없어서 api 요청의 리턴이 오기전에 또 요청 보낸적이 없었지만 2명의 유저를 동시 작업하면서 10개의 쓰레드가 돌아가다보면 충분히 한순간에 두개 이상의 쓰레드가 동시 요청을 보내고 이때문에 429가 뜰수도 있겠네요 429가 동시 요청때문에 발생할 수도 있다는건 생각을 못했네요 감사합니다
뭔말인지 모르겠으니 일단 젠킨스 서버 닫겠습니다 - dc App
걍대충 외부 api 호출좀 천천히 하니까 된다 입니다
아 개씨발 또 쿼터만 처 날리고 DB 저장 안됐네 니미
executorSevice로 멀티쓰레드를 구현하다보니 메인쓰레드 외에서 CompletableFutuere에서 최종 결과를 DB에 저장합니다. 이게 시발 로컬에서는 어찌저찌 인텔리제이 디버거 브레이크포인트 걸고 파악이 되는데 EC2에서 돌려버리니까 오류 로그도 안떠버려서 뭐가 문제인지 모르겠네요
걍 지랄말고 로컬에서 먼저 테스트 돌리고 배포할걸
아 쪽팔린데 ㅋㅋ;;;;;; 그래도 좋은 기회 같으니 갤로그에 깃헙 남기겠습니다
남겼습니다
간략히 설명드리자면 service 패키지의 userService.addUser()의 마지막 mapping()에서 api를 호출하는 작업이 시작됩니다
paralleLocationMapper라는 클래스는 Async가 적용되어 있으며 config상 2개의 쓰레드만이 동시에 작동합니다. getLocation() 메소드는 paralleLocationMapper 내부 exexutorSercice를 이용해서 10개의 쓰레드풀을 가지고있고요 각 Aysnc 쓰레드 당 5개의 exexutorSercice 쓰레드를 배정받아 사용합니다
async 쓰레드의 경우 config 패키지에 컨피그 클래스가 있고 executorService 쓰레드는 paralleLocationMapper 내부에 정의된 설정이 끝입니다
13개이긴 한데 실질적으로 애플리케이션에서 사용하는건 10개입니다.
해당 댓글은 삭제되었습니다.
webClient 쓰지말라는 말씀이신가요? kakaoApiClient 이친구가 Bean으로 등록되서 사용되니까 webClient도 10개의 쓰레드에서 공유하게 될 거고 하나의 API요청 Connection이 종료되기도 전에 한번 더 요청해서 문제가 발생할 수 있다 이런걸까요? WebClient가 Json to Object라던지 비동기 요청, 예외처리 등 좋은 점이 많았는데 쫌 아쉬울 수 있겠네요. 감사합니다.
그렇긴 하네요 항상 저것도 어떻게 보면 커넥션도 리소스의 일종 이라고 생각하면 릴리즈도 확실히 처리했어야 하네요 특히나 이렇게 여러 쓰레드에서 공유되는 자원이면 더
ㅋㅋㅋㅋㅋㅋㅋㅋ 아 씨 그거는 저도 생각은 하고있긴 했습니다 너무 대놓고 코..드상에 하드코딩 되있고 깃헙에도 이렇게 퍼블릭돌려버리면 노출되서 그것도 문제고요 감사합니다
ㅋㅋ 죄송합니다 사실 Rest에 대한 이해도가 낮을 시점에 만들던 프로젝트라서 컨트롤러 리턴규격같은것도 너무 막무가내로 만들어져 있네요 ㅋㅋ 중요한 부분이라는거 인지했습니다 감사합니다
얼핏 보니까 전통적인 하나의 공통된 webClient에서 메소드마다 HttpConnection 처럼 커넥션 객체를 생성해서 사용할 수 있는건가? 더 안전해보이긴 하네요
해당 댓글은 삭제되었습니다.
멀티쓰레드가 정말 어려운거 같습니다 디버깅도 힘들고 명심하겠습니다
사실 멀티스레드 도입한것도 이런 동시성 문제, 비동기 Future 처리 같은거 연습해볼라고 해본거라서 나름대로 좋은경험이었던거 같기는 한데 확실히 위험하기는 하네요
아 저렇게 외부 api쓰는 로직은 쓰레드 처리를 잘 안한다 이거군요 알겠습니다
수요일에 어처피 추첨하니까 그때 끼워서 하나 드리겠습니다 피드백 감사합니다
감사합니다 선생님 인사이트를 쫌 얻어가는것 같습니다 내일새벽 패치는 꼭 성공시키겠습니다