바이비트 API 실시간 데이터 수집 - 한계 돌파 계획안 및 데몬 제작안

그누보드 그 게시판을 사용해서 바이비트 API 값을 저장할려고 한다. 일단 글쓰기 폼에 해당 필요한 값을 자동으로 넣 할거다. 그리고 그걸 저장하면 해당 값이 저장이 되겠지. 여기서 해당 그누보드 테이블에 저장이 돌 뿐 아니라. 업데이트 스킨을 통해서 내가 원하는 다린 디비 테이블에 넣을거야. 여기서 부터 하나의 기준을 중심으로 발생되는 문제점을 구조적으로 해결해 놓고 출발할 생각이야. 구조를 먼제 세우는게 우선이고 그 구조의 문제점을 먼저 해결해야지 무조건 적으로 코딩질하면 나중에 바벨탑 꼴이되거든. ---------------------------------------------------------------------------------------------- A. 바이비트 문제점 * 우선 이 부분부터 말해야 이후 그누부드를 사용할려는 이유와 해당 문제점 그리고 문제점을 해결하는 방향이 잡힐거야 * 바이비트 API 값을 현재 데몬이 가져다 디비 테이블에 넣고 있어. 2마리가. * 그런데 왜 굳이 게시판을 쓸려고 하느냐의 궁금증을 문제적 시점으로 설명을 할거야 ---------------------------------------------------------------------------------------------- 1. 바이비트는 5초당 600콜이라는 가이드라인을 주지 2. 그리고 이전에 우리 서버의 데이블 구조를 먼저 말하지 3. 일단 매번 거래소에 구걸하는게 가. 싫다. 나. 힘들다 다. 이후 분리된 구걸의 라인들이 유지/관리를 힘들게 한다. 4. 그래서 플랫폼 테이블을 구성햇다. 가. 하나의 원 테이블에 실시간으로 데이터를 때려 박는다. 나. 이 테이블은 덮어쓰기 테이블이다. 다. 데이터 휘발 일지라도 플랫폼 테이블로 이하 다른 어디서든 서버내 데이터는 구걸 없이 이 테이블에서 가져다 쓰면 된다. 라. 거래소의 자잘한 변경이라던가 변심으로 인한 무제들도 각각의 이하 파일들이 아닌 플렛폼 자체로 해결이 되는 관리/유지에 장점이 있다. 마. 이하 작업데 뭐든 편의성 및 다양한 장점이 있다. ---------------------------------------------------------------------------------------------- 1. 모든 문제가 있지만 여기서 부터 문제가 발생을 한다. 2. 어짜피 존재하는 문제 처음부터 불어지니 편하기도 하지만 우선 해결을 해야지 3. 처음에 말한 5초 600콜이라는 부분도 이어지는 문제 4. 원 테이블 구조다 보니 9개의 주소에서 테이터를 가져와야 해 5. 9개 데몬으로 각각 가져오나 1개의 데몬이 9개 주소를 불러오나 같은 문제니까. 6. 1개의 데몬이 9개의 주소로 수십게의 심볼을 가져다 데이터를 박아대지 7. 첫번째 문제점 8. 주소와 심볼을 속도 문제로 병렬식으로 해서 묶어서 바이비트에 던져 9. 요청하고 가져오는 속도는 빨라 그러나 문제는 콜 수라는거야 10. 데이터를 수집하는데 이건 유적지 데이터가 아니라 매매 거래소 데이터라 실실간이 필요하지. 11. 그걸 1심볼 X 1주소가 아니면 콜 수가 기하급수적으로 상승해 12. 이론상 30심볼 X 9주소면 한방 270콜이고 50심볼이면 450콜 60종목이면 540콜이야 ---------------------------------------------------------------------------------------------- 1. 이게 5초 600콜이면 5초컷 기준이면 속도 싸움인데, 5초가 넘어가면 콜 싸움이야 2. 시작하자마자 590콜 때리고 5초 후 때리나, 시작 후 1년 후에 650콜 때리냐는 650콜이 차단이거든 3. 즉 5초컷이 넘으면 무조건 콜 싸움이라는거지. 4. 이론상 무지 많은 종목을 따나 최대 60종목이야. 5. 또한 5초컷 이하는 속도 싸움이라. 데몬을 2개로 나누었어. 6. 빠르게 박는 데몬 : 덮어쓰기 테이블 구조 활용 기존 테이블에 동일 심볼 덮어 쓰기 / 4주소 X 7심볼 7. 천천히 박는 데몬 : 대략 30종목 천천히 5초컷 (5초컷이나 10초컷이나 단위 당 600콜이라 5초컷 유지) 8. 일단 이게 다 잡아먹어 600콜 물론 이게 아니더라도 이론상 60종목은 넘지 못하지. 9. 그리고 매매라는 특성상 중요 코인은 속도 수집 싸움이거든. 10. 즉 비트코인 처럼 중요 코인 빠르게 박기 11. 메이저 급 알트 코인 천천히 박기 12. 여기까지는 유지 되는데 이후 다른 알트는 포기해야 할 구조야 ---------------------------------------------------------------------------------------------- 1. 그래서 상환과 환경 구조를 고려해서 구조를 틀어버리기로 햇지. 2. 바이비트는 주는년, 나는 받는 놈 : 인정하고 가야지 3. 5초 600콜 구조를 뒤틀어서 받아야지 4. 5초 컷이니까 / 즉 5초 구조 중복 막으면 되거든 5. 즉 중요코인, 메이저 코인은 5초 이내 속도 싸움 정리하고 나머지 알트는 환경에 맞춰 최소 1분~최대5분 수집으로 하기로 결정 6. 이 이유는 바이비트가 때리는 한방 600콜이 아니라 한 IP당 한방 600콜이라 수십 마리 데몬이 각각 한 종목 X 한주소를 때려도 차단이라는거야. 7. 그래서 5초컷 기준으로 5초 때리고 다음 5초 기다린것이 때리고 다음 5초 즉 10초 기다린 것이 때리는 순차 방식으로 때려야 한다로 결정을 햇지. ---------------------------------------------------------------------------------------------- 1. 문제는 저렇게 때린다는게 데몬에 안 맞아. 2. 데몬은 일단 때리고 수집하고 다음 쉬는 타임을 정하는 방식이지. 불로 바꿀 수도 있어. 3. 기본 적으로 일단 때리고 쉰다는 때리고 쉬는 타임이 박아대는 시간까지 여러 조건으로 동일하지가 않이 시간이 늘어지거나 당겨져서 여러 타격 지점의 시간이 중복으로 어느 순간 차단이라는거야. 4. 그럼 데몬을 시간에 맞춰 때려야지. 5. 그건 때리는 시간을 내가 데이터 공수 시간, 여분, 시간 안정 시간 등 다 계산하고 시간을 지정하고 때린다야. 이건 데몬의 본질에서 벗어나 이건 그냥 크론이야. 6. 그리고 해당 모든 것들이 다 불안한 구조야. 언제 문제를 일으킬지 모르거든. ---------------------------------------------------------------------------------------------- 1. 타이밍이 핵심인데 이도 어렵고, 데몬 구조 자체도 문제인데 이것도 힘들고 기타 다 문제가 발생해거든 이걸 해결하느 것 자체도 어렵고 해결도 안된다는 구조절 결함이고 이건 하나 틀어지면 연쇄 문제 발생 구조고. 2. 그래서 결론은 스크립트 파일을 사용하기로 한거야. 3. 특정 시간에 데몬이 때려서 해당 데이터를 넣는다면 스크립트 파일만 구성하고 그 타격을 데몬이든 크론이든 하면 된다. 이거지. ---------------------------------------------------------------------------------------------- 더 위에서 더 넓게 분류하면, 그냥 수집 방식 자체를 바꾸자야 데몬이 아닌 스크립트 파일. 즉 수집 환경을 세계관으로 보면 하위 최상위 구조를 데몬이 아닌 스크립트도 있다로 구조를 틀어서 새로운 공간에서 새로운 방식으로 작업을 하자지. ---------------------------------------------------------------------------------------------- 이제 여기서 기술적인 자문이 필요한거지. 스크립트 파일로 75개 컬럼을 만들고 넣는다. 그럼 다음으로 이걸 데몬이나 크론이 때려줘야 하나 아니면 자체 스케쥴러로 박을 수 있나. ---------------------------------------------------------------------------------------------- PHP는 요청-응답 구조 - 웹 요청이 없으면 실행 자체가 안 됨: 이것 자체부터가 자동이 아니라는 거잖아. 이건 그냥 뭐든 열어줘야지 그럼 두가지야 나 또는 데몬 맞지 그럼 시작점이 바뀌는 거지 데몬이 일단 시작점에 있고 데몬 작업 방식으로 분기되는거야. 스크립트 파일을 데몬이 열어주든 때리든 해당 스크립트 파일은 존재해야 하는거고 방식은 글쓰기 버튼 처럼 클릭이냐 / 그냥 호출로 때래냐 이거지. ---------------------------------------------------------------------------------------------- 그래서 여기서 포인트가 나오는거야 그 스크립트 페이지를 그누보드로 사용한다는거지. 별도 스크립트가 필요없거든 그누보드 스킨으로 수동 글쓰기 방식을 사용하는데 그 작성을 데몬이 하는거지. 그럼 스크립트라는게 필요가 없지. 그냥 게시판 글쓰기야. 이것도 글쓰기가 아니라 글 수정이지. 그냥 게시판에 코인 종목을 생성하면 새로운 코인 종목이 만들어지고 시간 단위로 수정을 하면 데이터 갱신이 되는거지. 그 글 수정을 위에서 말한 5분으로 중복을 피해서 컷하면, 5초 컷 속도 싸움 외 5초컷 밖의 콜 싸움에서 연장선으로 이어 가거든 잡 알트코인 수집을 5분으로 해도 상관 없으니까. 이제 구성이되는거지. 1. 빨리 박는 구멍 2. 천천히 박는 구멍 3. 느긋하게 다양한 코인을 박아대는 구멍 ---------------------------------------------------------------------------------------------- 이제 여기부터 게시판을 어떻게 세팅할거냐는 디테일 문제야. 그 전에 이 구상이 가능하냐는 거지. 가능한가. 그럼 이제 구상에서 구조로 넘어가고 그 구조는 기획을 해야하는거야. 여기서 가능성을 확인하고 가야하는데 페이지가 스스로 스케쥴러 되느냐하는거야 스스로 특정 시간에 트리거로 타격을 할 수 있나. 그래 그럼 이제 "그럼 데몬이네" 이게 아니라 다양하게 찾아보고 가야지. ---------------------------------------------------------------------------------------------- 그러데 결론은 동적인 타격기로는 데몬이 핵심이야.