프로젝트 개요

1-1. 프로젝트 소개

벨로가: 기상알람을 활용한 라벨링 데이터 수집 모바일 애플리케이션

데이터 라벨링을 사용자가 지속적으로 참여하게끔 하기 위해 게임화 요소로 기상 알람에 OCR 데이터 라벨링을 수행할 수 있도록 하고 라벨링에 대한 보상으로 포인트를 지급후 해당 포인트는 기프티콘 이벤트 응모에 사용 가능합니다.

1-2. 주요 기능 통신 다이어그램

1-3. 주요 기능

1-4. 개발 환경

• Front-end: React Native Android React
• Back-end: Java Python Spring Boot JPA MySQL Apache Kafka
• DevOps: Docker AWS Kubernetes istio Jenkins zipkin

개발 결과물

2-1. AWS 아키텍처

쿠버네티스를 기반으로 AWS 아키텍처를 설계하고 개발하였습니다. 이 과정에서 쿠버네티스 관리형 서비스인 EKS를 사용하였습니다. 먼저 마이크로서비스들의 인증 인가를 통합적으로 수행하기 위해 앞단에 API Gateway를 두었습니다. 또한 마이크로서비스 간 비동기 통신을 위해 Apache Kafka 관리형 서비스인 MSK를 사용하였습니다. 이외에도 S3, ECR, ElastiCache 등 다양한 AWS 관리형 서비스를 활용하였습니다.

2-2. DDD 도입

2-2-a. 이벤트스토밍을 통한 바운디드 컨텍스트기반 마이크로서비스 도출

DDD의 이벤트스토밍을 통해 바운디드 컨텍스트 단위로 마이크로서비스를 도출하였습니다.

• belloga-auth-service → 스프링으로 구현, JWT 토큰 기반 인증 인가 담당
• belloga-user-service → 스프링 으로 구현, 사용자(기업, 일반, 관리자) 프로필 관리 담당
• belloga-raw-data-service → 스프링 으로 구현, raw data 관련 기능 담당 (기업 사용자의 raw data(OCR, 오디오 등) 업로드, 관리자의 raw data 승인 등)
• belloga-preprocessing → 파이썬 으로 구현, 관리자가 승인한 raw data에 대해 알맞는 전처리 파이프라인 담당
• belloga-labeling-service → 스프링 으로 구현, 데이터 라벨링 수행 담당
• belloga-labeling-vertification-service → 스프링 배치 로 구현, 주기적으로 사용자가 수행한 라벨링에 대해 검증 수행 배치 담당
• belloga-point-service → 스프링 으로 구현, 사용자 보상(포인트, 스탬프, 이벤트 응모 등) 담당
• belloga-firebase-service → 스프링 으로 구현, firebase 관련 비즈니스 응집성 담당(fcm 푸쉬알림)

2-2-b. 애그리거트 패턴 적극 사용

• 애그리거트 내 상세 클래스를 바로 참조하지않고 애그리거트 루트만 참조하였습니다.
• 애그리거트 간의 참조는 객체를 직접 참조하는 대신 기본키(id)를 사용하여 수정이 필요하지 않은 애그리거트를 함께 수정하는 실수를 원천적으로 방지하였습니다.

2-3. 마이크로서비스 가트너 아키텍처

벨로가의 가트너 아키텍처입니다.

클라이언트-마이크로서비스 간 직접 통신 방식이 아닌 API Gateway 패턴을 사용하였고 이를 통해 인증 / 인가를 통합적으로 수행하였습니다.

마이크로서비스들 간 통신을 제어하기 위해 서비스 매시 레이어를 넣었고, 이에 대한 솔루션으로 isito를 사용하였습니다. istio 를 통해 마이크로서비스 간 동기 통신 과정에서 발생할 수 있는 장애 전파문제를 해결하기 위해 circuit breaker를 구현하였습니다.

이벤트 주도 아키텍처를 적극 도입하여 동기통신이 필수적으로 필요한 로직을 제외하고 마이크로서비스 간 통신은 비동기로 설계, 개발하였습니다. 이벤트 브로커 솔루션으로 아파치 카프카를 사용하였습니다.

2-4. 분산 로그 트레이싱 zipkin 도입

마이크로서비스로 설계, 개발함에 따라 사용자로부터의 요청 흐름 중에서 어느 지점에서 장애나 병목 현상이 발생하였는지 점점 추적하기 어려웠고,zipkin을 도입하여 문제를 해결하였습니다. 이 과정에서 Spring Cloud Sleuth 를 사용하였습니다.

2-5. API Gateway 패턴을 활용한 인증 / 인가 구현

JWT를 이용한 사용자 인증 방식으로 구현을 했는데, 이때 각 마이크로서비스가 토큰의 인증/인가를 중복으로 구현한다면 비효울적이라고 생각했습니다.

이에 대한 해결 방안으로 API Gateway를 통한 토큰 검증 패턴을 도입했습니다. 이를 통해 각 마이크로서비스의 API를 이용하기 위해서는 앞단의 API Gateway를 거치도록 설계하였고, API Gateway에서 Lambda Authorizer를 통해 JWT 토큰이 검증되고, 검증된 토큰의 페이로드에 저장되어있는 대칭키로 암호화한 사용자 식별값을 다시 복호화하여 뒷단의 마이크로서비스에 전달되도록 구현했습니다.

2-6. 사가패턴 도입

유저 프로필과 인증 마이크로서비스를 분리한 상황이였습니다. 인증 마이크로서비스에서 사용자 등록이 되었으나 프로필 마이크로서비스 데이터베이스에 반영되지 않아 정합성이 불일치하는 문제가 발생하였고, 사가패턴을 도입하여 해결하였습니다. 인증 서비스에서 유저를 등록한 후 이벤트를 발행합니다. 프로필 서비스에서 이벤트를 받아 처리한 후 그 결과를 다시 비동기로 전달하였습니다. 인증 마이크로서비스는 해당 응답을 받아 알맞는 처리를 하도록 하였습니다.

2-7. 데이터베이스 ERD 및 RDB 구조

• auth service

  

• point service

  

• labeling service

  

• user service

  

• firebase service

  

• labeling verification service

  

• raw data service

  

• 모든 마이크로서비스의 스키마를 합칠경우

  

2-8. 마이크로서비스 API 통합 문서화

마이크로서비스들의 API를 통합 관리하기 위해, 각 마이크로서비스의 API를 Spring REST Docs로 문서화 한뒤, Swagger UI를 통해 통합 관리하였습니다.

2-9. API 서버 CI/CD 파이프라인

Jenkins를 통해 CI/CD 파이프라인을 구축하였습니다. 이때, 각 마이크로서비스 별로 Open API Spec을 추출해 Swagger UI 서버로 전송하여 API 문서 통합을 수행하으며, 도커 이미지를 만들어 ECR에 업로드 후 EKS에서 업로드한 도커 이미지를 받아 Rolling Update를 수행했습니다.

2-10. AWS S3 Presigned URL 기반 미디어 업로드

서비스 설계시, 라벨링을 의뢰하기 위해 업로드하는 데이터가 서버를 거쳐 S3 버킷으로 업로드 되도록 설계하였는데, 라벨링을 의뢰하는 데이터가 벌크데이터라는 점에서 서버에 많은 부하가 발생할것이라고 판단했습니다.

이에 대한 해결 방안으로 서버를 거치지 않고 S3에 다이렉트로 업로드할 수 있는 pre-signed URL을 도입하였고, 이를 통해 벌크데이터가 서버를 거치지 않고 바로 S3버킷으로 업로드 되도록 구현했습니다.

---

This Project is Sponsored by Software Maestro

This work was supported by the Institute of Information & Communications Technology Planning & Evaluation(IITP) grant funded by the Ministry of Science and ICT(MSIT) (IITP-2022-SW Maestro training course).