[Tech] 투덥 그래프 데이터베이스 도입기 (2편)
어떤 서비스를 선택할 것인가?
참고) 투미유 팀은 이렇게 개발합니다.
투미유 팀이 신규 서비스를 기획하고 개발해가는 과정 자체는 여느 조직의 개발 과정과 크게 다르지 않습니다. 먼저 서비스 도입 목적을 기준으로 기획-개발 간 미팅을 진행하며 기획 파트 내용과 운영 과정에서의 퍼포먼스 요구 조건을 조율합니다. 이후 DEV 팀 내부 미팅을 통해 앞서 조율된 사항들을 정리하고 신규 서비스 도입을 위한 리서치 방향을 잡아나갑니다.
1편에서는 투미유 팀이 어떤 목적으로 그래프 데이터베이스 도입을 생각하게 되었는지 설명드렸는데요. 이번 편에서는 도입 결정만큼이나 어려웠던 서비스 선택 과정에 대해 이야기해보고자 합니다.
도입을 위한 테스트 당시에는 가능 여부만을 빠르게 살펴보기 위해 가장 많이 쓰이고 있는 Neo4j를 사용해 테스트를 진행했었지만, 실제 서비스 적용에 있어서는 (Neo4j를 포함해) 현재 존재하는 서비스들을 더욱 면밀히 분석해 봄으로써 우리 서비스에 가장 잘 어울리는 서비스를 찾는 과정이 필요하다고 생각했습니다.
적용 가능 서비스에 대한 리서치
당시 그래프 데이터베이스와 관련해 저희 팀이 가진 정보가 많지 않았기 때문에 추가적으로 어떤 서비스가 더 존재하는지, 서비스별 특성은 무엇인지에 대한 리서치를 진행했습니다. 그 결과 다음과 같은 결과를 얻을 수 있었습니다.
※ 아래 표는 도입 당시 시점을 기준으로 작성된 것으로써 현재의 내용과는 다소 차이가 있을 수 있습니다.
※ Neptune도 이제는 Cypher를 지원한다고 합니다.
리서치를 진행하며 각각의 서비스가 가진 다양한 특징들을 확인할 수 있었습니다. 이를 바탕으로 최종 서비스 선택을 위한 7가지 기준을 설정했고, 각 기준은 중요도에 따라 우선순위를 구분함으로써 최선의 서비스 선택을 위해 노력했습니다.
서비스 선택 기준 7가지 및 최종 선택
7가지 서비스 선택 기준(중요도)
(1) 지원 플랫폼 (필수)
(2) 쿼리 언어의 직관성 (높음)
(3) 서비스 사용률 및 관련 정보량 (중간)
(4) 관리 용이성 (중간)
(5) 기능 제한 (낮음)
(6) 보조 도구 (낮음)
(7) 비용 ( - )
※ 우선순위 높은 순
(1) 지원 플랫폼 (필수)
- 투덥 서버 구조가 마이크로 서비스가 아니었기 때문에 사용하고 있는 플랫폼에 대한 지원 여부가 중요했으며, Nodejs(Javascript)를 지원하지 않으면 사용할 수 없었기에 필수 조건이 됨.
- 대부분의 서비스가 Nodejs(Javascript)는 지원하고 있던 상황이었음.
(2) 쿼리 언어의 직관성 (높음)
- 도입 여부 테스트에 사용했던 Neo4j의 Cypher 쿼리의 경우, 처음 접했음에도 직관성으로 인해 초기 테스트 시에 사용된 기본적 쿼리들은 큰 어려움 없이 작성이 가능했음. 특히, 새로운 기술로 서비스를 구현해야 했기 때문에 직관성 높은 쿼리 언어가 초기에 발생할 수 있는 러닝 커브를 많이 줄여줄 것이라 판단함.
- Cypher, Gremlin이 그래프 데이터베이스를 위한 쿼리 언어였고 실제로 보기에도 그래프 데이터베이스의 데이터 구조를 따라 쿼리할 수 있었기에 2가지를 지원하는 서비스면 좋을 것이라 판단함.
(3) 서비스 사용률 및 관련 정보량 (중간)
- 서비스 구축 및 운영 작업을 진행하다 보면 다양한 이슈를 맞닥뜨리게 되는데, 이때 정보가 많을수록 이슈에 대응하기 좋고 원활한 대처가 가능하게 됨. 따라서 사용률이 높거나 별도의 커뮤니티 공간을 제공하고 관리하는 서비스인지 살펴봄.
- Neo4j가 홈페이지 내 별도의 커뮤니티 공간을 제공하고 있었으며 검색 엔진에서 검색했을 때에도 많은 정보가 나오는 것으로 확인되어 정보량에 있어서는 가장 좋다고 느껴졌음. 그리고 Azure CosmosDB가 그다음으로 많은 검색 결과가 나온다는 것을 알 수 있었음.
- 그 외 다른 서비스들에 대한 정보는 공식 문서를 제외하고는 많은 양이 검색되지 않았음.
(4) 관리 용이성 (중간)
- 백엔드 대부분이 AWS를 기반으로 이루어져 있어 같은 AWS의 서비스를 사용하는 것이 모든 서비스를 함께 모니터링 할 수 있고 익숙한 AWS Console을 통해 관리할 수 있어서 유리할 것이라 판단함.
- AWS Neptune 서비스 자체의 관련 정보량은 적지만 기존 백엔드를 AWS 기반으로 구축하며 쌓인 경험과 Neptune이 사용 중인 Gremlin QL은 QL에 한정해서 정보량을 따진다면 Cypher에 비해서 더 많은 정보가 검색되었기에 Neptune의 낮은 정보량을 어느 정도 상쇄 가능할 것이라 판단함.
(5) 기능 제한 (낮음)
- 기능 제한이 있는 경우 대부분 핵심 기능은 제공하고 확장성이나 관리적인 부분에서 편의를 제공해주는 부분을 제한하는 경우가 많았는데, 반드시 필요하다고 생각되는 부분은 없었고 추후 확장이 필요해지는 시기에는 서비스 규모 만큼이나 회사도 성장해 있을 것이기에 Enterprise도 고려해 볼 수 있을거라 생각되어 우선 순위를 낮게 설정함.
(6) 보조 도구 (낮음)
- 편의성 높은 보조 도구(데이터 시각화 지원 및 높은 접근성 등)는 개발 편의성을 높여주겠지만 구축된 뒤의 서비스에 미치는 영향은 크지 않으므로 우선순위를 낮게 설정함.
(7) 비용 ( - )
- 과금 방식이 조금씩 달라 정확한 비교가 어려웠음. 간략히 살펴봤을 때 Enterprise를 제외하고는 비용적으로 큰 차이가 나지는 않을 것이라 생각되어 선택 기준에서는 제외함.
최종 선택 : Neptune
최종 후보로는 Cypher와 Gremlin을 사용하는 Neo4j와 AWS Neptune 2가지가 남게 되었습니다. 이 둘을 놓고 비교한 결과, 정보량 부분을 관리 용이성 부분이 상쇄할 수 있다고 판단했고 보조 도구의 경우 우선순위가 상대적으로 낮다는 점을 감안하여 최종적으로 Neptune을 선택하게 되었습니다.
Neptune 도입 과정에서 발생한 문제점
개발을 목적으로 AWS Neptune을 본격적으로 다루기 시작하면서 예상치 못한 문제들을 겪게 되었습니다. 당시 저희 팀이 마주한 문제는 크게 4가지로 정리할 수 있습니다.
Neptune 도입으로 인해 발생한 4가지 문제
1) 보조 도구는 Python인데 Javascript Driver와 사용법이 다른 쿼리가 존재하는 문제
2) 데이터 시각화의 문제
3) 시각화 결과 내 인터랙션 불가 문제
4) 보조 도구의 접근성 및 안정성 문제
1) 보조 도구는 Python인데 Javascript Driver와 사용법이 다른 쿼리가 존재하는 문제
- 테스트 후 실제 코드에 적용할 때 에러가 발생함.
- 문제가 되는 쿼리를 정확히 알기 전까지는 쿼리 내 어떤 부분이 문제인지 파악하는 것 자체부터 어려움이 존재함.
- 문서에 명확하게 명시되지 않은 부분들이 있었고, 여러 플랫폼 중 Javascript에 대한 제한이 가장 많았음.
2) 데이터 시각화의 문제
AWS Neptune에서 시각화 결과를 얻기 위해서는 셀 상단에 키워드 및 내가 보고 싶은 요소를 인자로 입력해야 했습니다- 도입 초기, 서비스에 익숙하지 않은 상태에서 직관적 확인이 어렵다는 점은 큰 장애 요인이 됨.
- 별도의 키워드를 넣어야 시각화가 동작하는 점이 불편했음.
→ 결괏값이 Node, Relationship의 형태라면 항상 시각화를 제공하는 Neo4j Browser와 달리 AWS Neptune이 제공하는 Graph Notebook은 쿼리 실행 셀에 Magic-Keyword를 입력해야만 시각화가 제공되고 시각화할 부분까지 미리 파라미터로 넣어줘야 해서 사용이 불편했음.
3) 시각화 결과 내 인터랙션 불가 문제
- Neo4j의 Browser는 시각화 된 정보 상에서 인터랙션을 제공하여 특정 요소를 지우거나 특정 요소를 중심으로 시각화를 확장하는 등의 처리가 가능하여 데이터 탐색과 확인이 용이한데 반해, Graph Notebook의 시각화는 인터랙션이 제공되지 않는 래스터 이미지와 같은 형태로 시각화를 통해 이상 데이터를 발견하거나 추가적인 데이터가 필요할 때 재쿼리를 해야만 했으므로 불편했음.
① : AWS Neptune의 시각화 결과 화면 (작업 당시 스크린샷이 남아있지 않아 웹 상에서 이미지 참조함. 출처 : https://dev.classmethod.jp/articles/gremlin-query-results-visualisation-using-neptune-workbench/)
② : Neo4j Browser의 시각화 결과 화면 (각 데이터 노드를 바로 클릭하여 사용할 수 있는 인터랙션 기능을 제공함. 출처 : https://ganister.eu/blog/neo4j-browser-for-functional-visual-validation)
4) 보조 도구의 접근성 및 안정성 문제
- Neo4j Browser의 경우 로컬 응용프로그램을 제공하며 Web Browser를 통해서도 접속 가능한데 비해, AWS Neptune의 경우 Private-Network을 사용하고 있기 때문에 Console에서 유료로 제공하는 Python Notebook을 사용하거나 EC2 인스턴스를 통한 SSH 터널링 등을 통해야만 외부에서 접속이 가능하다는 점이 불편했음.
- 새로고침을 하더라도 연결이 되지 않아 다시 접속해야 하는 경우가 빈번했음.
- Jupyter Notebook의 특성상 무거운 쿼리로 인해 시스템 부하가 걸리는 경우 Stop이 쉽지 않고, DB 제어에 어려움이 존재함.
도입 초기, 그래프 데이터베이스에 대한 이해도가 낮은 상황에서 데이터의 명확한 확인이 어렵다는 문제는 개발 진행을 더디게 만들었습니다. 또한, 약한 시각화는 데이터가 다르게 들어있음으로 인해 발생하는 에러를 찾기 어렵게 만들었으며, 보조 도구의 잦은 끊김과 에러는 '지금 내가 보고 있는 결과가 정확하지 않을 것'이라는 불신을 만들어내기도 했죠. 결과적으로 개발 기간은 기간대로 늘어나고, 생산성은 또 갈수록 낮아지는 악순환이 반복되고 있었습니다.
서비스 변경 : Neptune → Neo4j
이에 AWS Neptune 사용을 이어가는 것은 매우 비효율적이라고 판단했습니다. 이전의 선택이 잘못됐음을 빠르게 인정했고 우리가 처한 상황에 맞춰 시스템 구축을 보다 용이하게 할 서비스가 무엇일지 고민했습니다. 앞선 경험들을 통해 최초 생각했던 우선순위 중 관리 용이성에 비해 보조 도구의 영향력이 더욱 크다는 사실을 알 수 있었고 이를 감안해 Neo4j로의 서비스 변경을 결정하게 되었습니다.
Cloud 방식의 Neo4j의 선택 이유
Neo4j의 경우, 2가지 형태(Self-Hosted 및 Cloud)로 서비스되고 있었습니다.
Self-Hosted vs Cloud 비교
● 개발에서 가장 힘든 부분은 개발 환경을 구축하는 일이라고 생각하기 때문에 도입 초기에는 Cloud 방식이 더욱 적절하다고 생각됨.
● Self에 비해 Cloud에서 제한되는 요소들이 더 많긴 했음. 제한요소 중 필요하다고 생각되었던 부분은 apoc lib.의 full 버전의 ttl 지정이었는데, 이 부분은 Date 기반의 쿼리를 cron 처리로 대체 가능했고, 그 외 다른 부분들은 굳이 필요하지 않다고 판단함.
이러한 이유로 Cloud 방식의 Neo4j-Aura를 통해 본격적인 서비스 구축을 시작하게 되었습니다. 이를 기반으로 실제 시스템을 구성했고 각 부분의 기능들을 구체적으로 구현해 나갔습니다.
(3편에서 계속됩니다.)
