아키텍처 개요

이번 포스팅을 통해 Datawallet 개인 데이터 관리 플랫폼 베타 버전의 새 아키텍처를 살펴 보도록 하겠습니다. 엉성한 스타트업들이 대부분 겪는 일이 저희에게도 발생했습니다. 기업 인사이트 대시보드와 모바일 앱을 갖추어 ICO로 가는 과정을 순탄케 하느라고 다른 기술적인 면을 뒷전으로 밀어 놓았죠. 하지만 저희는 하나의 조직으로서 우선순위를 재조정하여 효율적으로 확장이 가능한 개발자 친화적인 생태계를 구축하는 기술적 토대를 마련하는 데 투자를 집중했습니다.

디지털 대양에서 표류하던 시기는 지났습니다. 이제 저희의 아키텍처는 AWS 내에서 다수의 가용 구역에 걸쳐 있으며, 예비 레이어와 다수의 서비스를 갖추고 있습니다. 아키텍처 서비스는 대부분 논리적으로 다음의 구역으로 구분됩니다:

• 유저 대면 서비스 (API; 앱/웹 사이트를 지원하는 데이터베이스를 비롯한 API 동반 서비스)
• 데이터 분석
• 데이터 처리

본 포스팅의 나머지 부분에서는 각 구역을 개괄적으로 살펴 보겠습니다.

아키텍처 개요

이 그림은 위에서 말씀 드린 세 구역을 나뉜 아키텍처 구조를 보여줍니다.

저희는 서비스를 AWS 상에서 구동하며, RDS, ElastiCache를 비롯한 추가 서비스를 이용하고 있습니다. 지금으로선 멀티 클라우드 이식성을 활용하지는 않고, 아마존의 검증된 인프라를 활용하여 운영 경비를 최소화하고 마음의 안정을 누리고 있습니다.

다음은 저희 시스템에 이용되는 기술 목록입니다:

• Node.js — Datawallet 서비스 대부분을 지원합니다.
• Python — 데이터 조작과 ETL (추출, 변환, 탑재) 작업에 활용됩니다.
• Docker — API 간의 표준화된 구축 전략을 유지하고자 서비스를 컨테이너화합니다.
• PostgreSQL — 앱 데이터 베이스를 지원합니다.
• Amazon Aurora — 관계형 데이터베이스 관리 시스템이 데이터 저장소로 이용됩니다.
• Apache Airflow — 오케스트레이션 도구입니다.
• Redis — 유저 세션을 유지하고, Airflow 워커를 위한 메시지 브로커 역할을 합니다.
• AWS SQS — 저희 플랫폼에 매우 중요한 AWS 큐 서비스입니다.
• AWS S3 — 웹 앱 자산, 유저 업로드 데이터 등 어느 것이라도 저장합니다.

그럼, 아키텍처 각 구역을 살펴 보도록 하겠습니다.

유저 대면 서비스

유저 대면 서비스 아키텍처는 AWS 앱 로드 밸런서 뒤에 위치한 Node.js REST 서비스로 구성됩니다. 밸런서는 앱 데이터베이스와 통신하고, 지불, 회원 가입, CRUD (생성, 읽기, 갱신, 삭제) 작업에 대하여 캐시를 생성합니다. 서비스는 약간 초과 공급된 자동 확장 EC2 클러스터 상에서 구동되어 서비스 요청이 많을 때 컨테이너 수를 빠르게 확장할 수 있습니다.

분석 파이프라인

유저에게 제공되는 주요 서비스 중의 하나는 완전히 안전하고 허가를 얻은 방식으로 데이터에서 인사이트를 추출하는 기능입니다. 현재, 다음의 세 가지 분석을 제공하고 있습니다:

• 소셜 미디어 참여 — 소셜 미디어를 얼마나 이용하는지 보여주는 분석으로, 일별, 주별, 참여 유형에 따른 변화를 상세히 보여주는 그래프가 제공됩니다.
• 성격 특성 — 소셜 미디어 참여 정보에 기반하여 IBM Watson이 분석한 내용입니다.
• 쓰기 패턴 — 유저의 온라인 글쓰기에 대한 인사이트를 제공하는 대화식 단어 구름입니다.

저희는 플러그 앤 플레이 식 오픈 소스 분석 생태계를 마련하여 분석 서비스를 대대적으로 확장할 예정입니다. 이 생태계에서 개발자나 회사가 Datawallet 플랫폼 유저의 구매나 이용 데이터 분석을 제출할 수 있습니다.

이를 위해서 저희는 개발자들이 로컬 데이터에 기반한 분석을 진행하여 시장에 제출할 수 있는 방식을 마련해야 합니다. 현재, 저희는 Docker로 앱을 패키징하여 폐쇄 환경에서 필요할 때마다 구동되도록 하고, 이로써 개발, 제출, 구동이 쉽게 이뤄지도록 하고 있습니다.

위의 다이어그램에서 유저 API 클러스터가 분석 요청을 SQS 큐에 제출하는 방식을 볼 수 있습니다. 워커 노드는 이러한 요청을 수집하고, 필요한 데이터를 질의하며, 컨테이너 내에 볼륨으로 저장된 데이터, 패키지된 분석 내용을 포함한 Docker 이미지를 실행합니다. 그런 다음, 워커 노드는 데이터베이스에 결과를 저장하고, 유저 API 클러스터에 메시지를 전송하여 유저에게 분석이 완료되었음을 알립니다.

데이터 처리 레이어

아키텍처에서 가장 흥미로운 부분 중의 하나가 바로 데이터 처리 레이어입니다. 데이터 처리 레이어는 데이터 풀에서 저장소에 이르기까지 데이터 제공과 보관을 담당하며, 전 처리 서비스와 Apache Airflow 클러스터(데이터 파이프라인 관리)를 비롯한 핵심 요소로 구성됩니다.

데이터 처리 요청이 발생하면 전 처리기가 이를 읽어 내고 각 데이터 입력 파이프라인 큐에 배치됩니다. 파일을 가리키는 메타 데이터, 데이터 출처 API, 입력되어야 하는 데이터 조각 등이 데이터 처리 요청이 될 수 있습니다.

여기서부터 Airflow 마스터 노드가 있어서 데이터 입력 파이프라인 큐에서 데이터 처리 요청을 끌어 내고, 큐 정체 상태, 요청된 API의 병행성 수준을 고려하여 가상 파이프라인에 우선순위를 부여하면 워커 노드가 요청을 실행합니다.

결론

이로써 이번 포스팅을 마치겠습니다. 앞으로 포스팅을 통해서 Airflow 셋업, 블록체인 인프라, 분산 저장 메커니즘 등에 대한 좀더 상세한 내용을 전해드리도록 하겠습니다.

Find the original post as always on the Datawallet Tech Blog.