my name is Jay

다른 곳도 마찬가지겠지만 NHN의 페이지랭크도 다음 단계로 이루어진다.

1. 웹그래프 빌딩
2. 페이지랭크 실행
3. 기타 통계 작업

(뭐 대단한 걸 말해주나보다 싶었을텐데 너무 간단해서 실망했을 듯 하다 ㅎㅎㅎ)

하둡 기반이 아니였던 페이지랭크 모듈을 하둡 기반으로 바꾸면서 1번 단계 이후부터는 모두 자바로 바꾸었지만 1번 단계는 워낙 NHN의 자산의 일종인 링크스팸탐지 휴리스틱이 많이 들어가있었던 상태라 쉽사리 건드릴 수가 없었다. 게다가 웹 그래프 빌딩은 단위 모듈 자체 scalability의 문제가 크게 부각되지 않았던 터라 앞단부터 바꾸기 시작해야한다는 부담은 없었다.

그런데 요즘 1번 작업도 자바로 변경 개발을 시작하였다. 멀쩡히 잘 돌아가는 프로그램, 내가 다시 짜는 건 아니고, 블로그에 몇 문장 적어놓는 것으로는 독자층(이렇게 적어놓고도 너무 읽는 이들이 없어서 가슴이 아프다 ㅠ.ㅠ)에게 정당성을 이해시킬 수 있을 거 같지 않아 그냥 거두절미하고...

솔직히 난 자바 개발 경험이 별로 없다. 오픈마루에서 심심풀이로 C++로 작성된 검색엔진을 자바로 만들어본 게 시작이었고 여기와서 페이지랭크를 자바로 만들고 있으니 1년 남짓 정도 되겠다. 오픈마루에서 작업하며 놀란 건, 엄청난 자바의 생산성과 OOP의 깔끔함! 기존 코드 베이스가 있었지만 3만 라인에 달하는 C++ 검색엔진을 자바로 포팅하는데 걸린 시간은 단 한달... 놀라운 SDK, 이클립스, 자바 문법의 힘을 처음으로 느꼈다. 자바로 그렇게 만들어놓은 소스 코드는 이후 C++ 검색엔진의 리팩토링에 그대로 반영되었다.

그때 테스트한 결과, 알고리즘/데이터구조가 동일한 상태에서 C++ 버전과 자바 버전의 throughput과 response time 모두 C++이 2배 빨랐다. 모든 색인 데이터를 메모리에 올리기 때문에 IO 성능은 관련이 없다. 내가 이때 결론내린 자바 성능의 결함은 strongly typed... 좀더 무식하게 이야기하면 byte array로부터의 데이터 캐스팅이 없기 때문이었다. 무슨 말이냐면...

C에서는 메모리에 올라와있는 byte array로부터 4바이트 integer를 하나 얻어내려면

int a = *(int*)byte_array;
byte_array += sizeof(int);

하면 되지만 자바에서는

int a = ((readByte() & 0xFF) << 24) | ((readByte() & 0xFF) << 16) | ((readByte() & 0xFF) <<  8) |  (readByte() & 0xFF);

이렇게 해야된다. 이러한 차이가 2배의 성능 차이를 내는 것이라고 결론내렸다. 그때 나의 자바 스승님이신 지민아빠께서는 2배 차이면 최고의 결과라고 칭찬해주셨다. 아무 대책없이 짜면 10배 느려진다고...

그런데 두둥... 위에서 이야기한 1번 프로그램의 초기 버전 성능 차이가 정말 10배 났다 -_- IO 성능도 관련있고 자바 특성상 substring 하나 만들기 위해서도 새로운 String 객체를 하나 할당하는 등(C에서는 대충 메모리 영역에 널문자 하나만 찍어놔도 substring이 만들어진다) C에 비교해서는 불필요한 작업이 많긴 하겠지만 그래도 10배까지 차이날 지 몰랐다.

그래서 성능 튜닝을 시작했다. 솔직히 내 바램은 10배에서 2배로 줄이는 건데 얼마나 줄일 수 있을 지 모르겠다. 결과나오면 또 글 쓰겠다.