*exs4j 테스트에 대한 이야기 *

테스트를 진행하였다. OpenAPI 검색 결과 저장 및 검색 키워드에 대한 인덱스 생성 및 조회 개발 작업을 완료하였다. 러프한 상태의 v1.5 를 달성하긴 했는데 테스트를 해보고자 했다. 분명히 문제가 혹은 불편한 부분이 있을것이라고 생각이 되었다. 테스트는 간단했다. 1 클라이언트가 10000개의 검색을 한후, 해당 검색어에 대한 1일 동안 랜덤으로 요청해서 죽지 않은채, 원하는 시간내에 응답할 수 있는가에 대한 것이었다. 그리고 이 테스트를 통과하면 10, 100 클라이언트 식으로 동시성 테스트를 진행할 예정이었다. 

결과는 참담했다. 

화요일에 시작한 테스트는 아직도 통과하지 못한 상태이다. 몇가지 문제점이 있었는데 나열하면 아래와 같다. 

1. 검색 모드의 필요성

– 이 애기가 무엇이냐 하면 나는 처음에 10000 개의 검색결과 색인을 목표로 하였는데 이상하게 2000여개 밖에 색인이 안되는 문제가 있었다. 왜 이럴까 하며서 계속 트레이스를 한 결과, 검색 키워드가 약간의 중복이 있는 경우, OpenAPI 요청하기 전에 색인된 데이터가 있는지 인덱스에서 검사를 하는데 그 부분에서 계속 걸리는 것이었다. 즉, “아이유 유희열” 이라고 검색을 한후, 다음 키워들가 “유희열 스케치북” 이면 이미 검색했다고 판단되어 “아이유 유희열”의 검색결과를 던져 주는 것이었다. 물론 데이터가 많아 진다면 교집합 관계를 통해서 추려낼수 있지만, 일정한 데이터를 색인만 하는 모드, 색인 + 조회하는 모드, 조회만 하는 모드 이렇게 3가지 모드가 필요할것 같다는 생각이 들었다. 그리고 이 부분은 수정해서 반영한 상태이다. 

*2. 실시간 반영에 대한 문제 *

– 원래 목표는 실시간 색인반영이었다. 사용자가 검색을 하면 OpenAPI에 있는 내용이 검색이 되고 그 내용이 자연스럽게 exs4j에 저장이 되어서 다음에 같은 혹은 비슷한 검색어가 들어왔을때 해당 검색 결과를 리턴해주는것이었다. 때문에 실시간 색인 반영이 중요한 부분중에 하나였는데, 실제로 테스트해 보니 그렇게 잘 되지는 않았다. 방식 자체가 검색을 한 스레드에서 StoringCache 라는 곳에 데이터를 임시 저장하고, 메인 스레드가 루프를 돌면서 MessagQueue 의 내용을 가져와서 저장하고 인덱스에 반영하는 방식이었다. 문제는 이 메인 스레드의 속도에 비해서 MessageQueue에 쌓이는 속도가 더 빠르다는 것이다. 

실시간 반영이 잘 안되는 것은 속도의 문제인데 더 큰 문제는 중복 데이터의 발생 가능성에 대한 부분이다. MessageQueue에 쌓이고 메인 스레드가 처리할 때 까지 약 몇분 혹은 몇초의 시간이 걸리는데 그 사이에 같은 검색어가 들어올때 문제가 생긴다. 인덱스에 반영이 되지 않았기 때문에 OpenAPI에서 데이터를 가져오고 MessagQueue 에 들어가게 되는 문제가 있다. 

이 부분은 현재 고민중이긴 한데, 메인 스레드가 인덱스 처리 속도를 높이거나 혹은 분할해서 처리하는 방법 아니면 반영 예정을 나타내는 자료구조를 두어서 OpenAPI 를 타지않고 메모리에서 결과를 가져와서 보내주는 방식을 생각해 보고 있는 중이다. 

*3. 요청 코드가 너무 많은 경우, 느리다. *

– 검색결과 인덱스와 결과 자체는 requestCode 라는 것을 키값으로 연결되어 있는데, 너무 일반적인 단어의 경우 이미 많이 저장되어 있어서 requestCode가 많이 나오게 되고 이에 따른 검색 결과 조회의 속도가 느려지는 문제를 발견했다. 이 부분은 requestCode의 우선순위를 판별할 수 있는 정책 혹은 알고리즘이 개발 반영되어야 할것 같다. 이러한 문제들이 있어서 일단 이 부분들 부터 개선하고 다음 테스트로 넘어갈 예정이다. 이번주는 약간 멘붕크리 상태였다. 생각보다 검색엔진 비슷한 서버를 만든다는것 자체가 그리 쉽지만은 않다라는 것을 알게되었던 한 주였다.

*앱 개발에 대한 이야기 *

지지난주 애플의 막강 공격에 주저앉은 상태에서 지난주 딴짓만 하다가 서버 작업을 다시 했다. 기존의 OpenAPI 부분을 네이버와 다음에서 가져오는 방식이었는데, 이제는 자체 팀 서버에서 JSON을 통해서 가져오는 방식으로 전환하였다. 불편한 XML 파싱 부분도 없어졌고, JSONKit 라이브러리를 사용하니 훨씬 더 좋아진것 같다. 실제로 XCODE 프로파일링 도구를 통해서 측정한 결과, 메모리 릭 나던 부분을 고치게 되었고, 다음주 주중에 다시 한번 애플의 심사에 도전할 예정이다. 이번이 벌써 4번째인데, 평일에 해야 좀 빨리 될것 같아서 화요일이 지난후에 할 예정이다.