안녕하세요~
서버를 디자인하다 2편입니다.
지난 1편에서는 큰 그림을 통해 포괄적인 설명을 했다면 오늘은 한 단계 내려가겠습니다.
그 중 데이터 저장원리에 대해서 설명해드리고자 합니다.
폴로닉스 - 종합적으로 약 60~70개 정도 되었던 것 같음
비트렉스 - 종합적으로 약 200개 가까이 되었던 것 같음
빗썸 - 종합적인 수집이 가능한 API(6개)
코인원 - 종합적인 수집이 가능한 API(4개)
코빗 - 종합적인 수집이 불가능한 API(4개)
[코빗 개별 데이블에는 다음과 같이 insert]
다음과 같은 방법을 통해 새로 코인이 상장될 경우 constants table에 status 한개만 추가해주면 끝
list = select korbit item (key, name) = (btc_krw, 비트코인....)
String[] url = new String[list.size()];
for (item : list) :
url[count] = "https://korbiturl..." + item.key;
-- Request URL
위와 같은 방법을 통해 매 5초마다 200+@개의 실시간 코인데이터를 수집합니다.
서버 사양은 4Core에 8GB Memory
초기에 쓰레드를 제대로 관리하지 못했을 때 누수되는 현상 발생이 있었습니다.
현재는 프로세스 4개를 활용하면서도 Free Memory가 (2719 + 711) 총 3분의 1 이상입니다.
프로세스 1은 웹서버
프로세스 2는 가상화폐 사이트 데이터마이닝
프로세스 3은 증권사이트 데이터마이닝
프로세스 4는 가상화폐 사이트 빅데이터 솔루션
Swapcached 발생률이 0입니다.
Swapcached 발생률은 Commit_AS라는 메모리 안정성에 대한 지표를 누적시켜 결국 서버를 뻗어버리게 만듭니다.
많은 데이터를 수집하고 활용하는 경우 쏟아지는 쓰레드를 전부 모니터링 할 수 없기 때문에 쓰레드로부터 누수되는 메모리가 발생될거라 추측하는 소스에 대해 안정적인 코딩을 해야합니다.
짤짤이라는 사이트의 서비스를 위해 정말 많은 기능들이 background에서 움직이고 있는 것입니다.
오픈소스 SMS 솔루션 중 나기오스라는 것이 있습니다.
UI는 그닥이지만 기능이 어마어마합니다.
특히, Thread나 Context Switching을 직관적으로 모니터링 할 수 있는것이 장점입니다.
나기오스를 잘 사용할줄만 알아도 서버를 아주 안정적인 cost로 운영할 수 있습니다.
다음 스토리에 3편 이어가겠습니다^^
