반응형

시간은 훅훅 빨리가고, 6주동안 내가 한 게 괜찮은 수준인것인지에 대한 확신이 그닥 없다.


벌써 절반이 넘게 지났네. 한국 돌아갈 날도 머지않았다.



1. Neo4j


지난 번까지 열심히 하던 박스그리기는 로그가 점점 복잡해지면서 도저히 확장성이 똥이라는 게 자명해졌다.
애초부터 아무리 생각해도 에바쎄바였는데 왜 저렇게 하라고 한건지... 도무지 이해할수가 없다.
여튼 그래서 Neo4j 라는 Graph Database를 사용하기로 했다.

Are you familiar with it? 라고 물어보는데... 음 DB수업은 들었지만 써본 거라고는 SQLite 가 전부라서 처음 들어보는 DB가 익숙할 리가 없다.
처음 들어봤지만 일단 배워서 해보겠다고 했다. 뭐 구글 찾다보면 다 방법이 있겠거니... 싶었다.

Neo4j 처음 배우는 데 한세월, Cypher query language 배우는 데 한 세월, DB server를 돌리기 위해 컴퓨터에 세팅하는 데 한세월... 
원래 이런 건 처음 세팅할 때 밑도끝도 없는 오류가 펼쳐지는 법이지.. 

각종 버전문제와 호환성 문제, 포트 개방 문제 등등으로 서버를 켜고 돌리는 데만 한참 삽질했다.

어쨌든 Neo4j  서버 돌리는 데까지 성공!

그리고 나서는, 처음에 파싱해뒀던 데이터들을 다 Class 로 만들어서 DB에 삽입하고, 필요한 속성들 위주로 Categorize를 해서 노드를 더 삽입했다.

그렇게 완성된 디비는 아래 모습처럼 예쁘고 귀여운 동그라미들로 나타난다.




음 먼저 제일 작은 회색 동그라미가 Line을 의미하는데, 간단하게 그냥 로그파일의 각 라인의 정보가 파싱되어서 Class 형태로 들어가있다.

그리고 그 라인들 중에서 같은 Serial Number를 가지는 애들은 빨간 동그라미인 Serial 밑에 연결시켜주었다. 즉 빨간 동그라미에 연결되어 있는 회색 동그라미들은 모두 같은 Serial 안에서 처리되는 Line 들이라고 볼 수 있다.


또한, 한 Serial 내에서 처리되는 Line들의 Component를 Time-based 로 추적해보면, 노란색 동그라미로 나타나는 Trace Graph 를 그릴 수 있다.

예를 들어, 시리얼 241 밑에 11개의 라인이 있는데, 이 11개의 라인은 그 위에 보이는 4개의 컴포넌트 사이를 왔다갔다 하며 처리되는 것을 알 수 있다.


이렇게 그린 노란 동그라미들은 각각 Trace 라고 불리고, 같은 Trace를 가지는 Serial들은 파란 동그라미인 Pattern 으로 묶인다. 

즉, 같은 패턴 아래에 있는 시리얼들은 같은 Trace를 가진다고 볼 수 있다. 





각 라인을 Serial 아니라 address 를 기준으로 분류할 수도 있다.


위 그림에서는, 초록색 동그라미가 address 를 나타내며, 하나의 address에 매우 많은 line 들이 관여하는 것을 볼 수 있다. 또, 이 line들은 앞서 말한 것 처럼 같은 serial 로 묶일 수 있다. 즉 위 예시에서는 하나의 주소에 관여하는 Serial이 총 4개가 있다는 것을 알 수 있다.


해당 주소에서 무슨 일이 일어나고 있는지는 주소의 Trace를 통해 알 수 있다. 하지만 해당 주소에 관여하는 Serial이 많아질 수록, 처리되는 것이 많아지도 보면, 노란 Trace 그래프가 해바라기처럼 엄청 많은 화살표를 가지게 된다.. 


마찬가지로, address 역시 같은 패턴의 trace를 가지는 address 들을 Pattern으로 묶어줄 수 있다.



아, 그리고 trace의 화살표를 클릭하면 일치하는 패턴의 trace들을 기준으로 계산한 average cycle을 알 수 있다.

즉 이 패턴에서는 component --> component가 넘어갈 때 평균적으로 3cycle 정도가 걸려야 하는데, 애는 좀 많이 걸린다 싶은 애를 detecting 할 수 있고, 이걸 오류 검출에 활용할 수 있다.


2. Dockerize

여기까지 했을 때 일단 주간 세미나 반응이 매우 좋았다.

화면에 연결해서 위 그래프를 보여주고 설명을 했는데 다들 마음에 들어하는 것 같았다.
그렇지만 여기까지 오기 위한 일련의 과정들이 은근 복잡하다.

  1. neo4j DB 서버를 켜야 한다. (이를 위한 세팅은 기본!)
  2. Debug.out 을 Python script 를 통해 돌려서 neo4j DB에 노드와 관계들을 삽입해야한다.
이 두가지 작업들을 보다 쉽게(=아무생각없이) 할 수 있게 Dockerize를 하면 좋을 것 같다고 하여, 도커를 통해 저 두가지 작업을 한번에 처리해주는 도커 이미지를 만들었다.

도커도 처음 써보는 거라서 처음 감 잡는데 하루는 걸렸던 것 같다.

그러고 나서 돌려 보니, 음 잘 되긴 하는데 시간이 엄청엄청엄청엄청 오래 걸린다.
26메가 짜리 debug.out을 파싱해서 삽입하려면 대략 1시간은 걸리는 것 같았다.

3. CSV format

속도를 높이기 위해 문제를 찾아보니, 파이썬 스크립트에서 neo4j python driver를 통해 직접 노드를 한개씩 삽입하는데 이게 시간이 어마무시하게 걸리는 것 같았다. (당연)
따라서 파이썬에서는 csv 형태로 출력을 해 주고, 도커에서 이 완성된 csv 를 그대로 읽어와 db로 불러오면 시간이 훨씬 절약될 수 있다는 글을 보았다.

그래서 파이썬 스크립트를 다시 열심히 ^-^ 수정해서 csv 형태로 출력하게 바꿔주었다.

놀랍게도(당연하게도) 이렇게 하니 26메가 짜리 debug.out 을 처리해서 디비에 넣는데 10초정도? 가 걸리는 것 같다.

여기까지 다시 도커 작업을 수행하였다.


디비 구축 시간을 1.5시간 --> 10초 정도로 줄였고, 주간 세미나 때 다시 발표를 했는데 반응이 엄청 좋았다.

도대체 그정도 magnitude의 시간단축이 어떻게 되는거냐고 엄청 신기해하고 많이 칭찬받았다.


한국에 있었을 때는 10초면 되는 걸 1시간 넘게 걸리는 멍청한 코드로 짰었네? 라고 하셨을 것 같은데....여기선 Awesome, Perfect 온갖 칭찬이 다 나온다ㅋㅋㅋ

한국에서는 항상 연구를 하면서도 눈치보게 되고, 하려던 말도 열번 스무번 고민하다가 속으로 삼키게 되고, 주워온 자식이 된 것만 같은 차별 속에서 참 많이 속상했었는데. 

과하다 싶을 정도로 칭찬해주고 해맑게 같이 기뻐해주는 사람들이랑 일하는게 너무 신난당 헿

반응형