ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 프로젝트 뒤돌아보기 2 - 전체 설계의 중요성
    프로젝트 - ARchive 2024. 5. 4. 16:06

    주의 - 프로젝트를 하고 나서 느낀 개인적인 의견이 담긴 글이니 정확한 정보가 아닐 수도 있습니다.

     

    지난 편에 이어서 역시 팀 프로젝트를 시작하고 나니 고려했으면 좋았을 것들에 대해서 써보려고 합니다.

    오늘은 더 자세하고 명확한 전체 설계에 관해서 얘기해보려 합니다.


    기존 방식

    기존 시스템 디자인

    백엔드 서비스를 만들기 전에 전체적으로 구상한 시스템 디자인이었습니다.
    설계 문서를 다시 돌아보니 해당 이미지 외에 설명이 없었습니다. 어떤 요소들이 정확하게 무엇을 맡고 어떻게 다른 서비스들과 통신을 할지에 대한 설명이 없었습니다.

    문제점

    1. 각 시스템이 어떤 역할을 맡고 있는지에 대한 설명이 없습니다
    2. 각 서비스 간에 어떻게 통신을 할지 나와 있지 않습니다.
    3. 왜 이 시스템 디자인을 구상한 지에 대한 설명이 없습니다.

    실제 겪은 문제

    1. 알림 서비스와 가운데 있는 핵심 서비스 간에 통신 방식을 변경했습니다. (http -> queue)
    2. 왜 이런 시스템 디자인을 가지고 가야 하는지 매번 다시 생각해야 했습니다.
    3. 각 서비스가 어느 부분까지 맡아야 하는지 그 서비스를 만들 때 생각했습니다.

    개선안

    기존의 간단한 시스템 디자인만 존재했던 설계 문서에 아래와 같은 개선 포인트를 적어보려 합니다.

    서비스 사이의 통신 방식 명시

    1. 4개의 코어 서비스 <-> 알림 서비스, 메시지 큐 이용
      1. 코어 서비스에서 발생하는 다양한 이벤트를 사용자에게 알리기 위해 통신합니다.
    2. 4개의 코어 서비스 <-> 캡슐 스킨 생성 서비스, 메시지 큐 이용
      1. 코어 서비스에서 움직이는 캡슐 스킨 생성 요청을 받으면 해당 작업의 처리를 양도하기 위해 통신합니다.

    서비스의 역할 명시

    1. 코어 서비스 - 사용자가 앱을 사용하면서 전송하는 다양한 API 요청을 받아 처리해서 응답을 반환합니다.
    2. 알림서비스 - 외부로부터 알림 전송 요청을 받아 외부 알림 전송 API를 이용해 요청받은 알림을 사용자에게 전달합니다.
    3. 캡슐 스킨 생성 서비스 - 외부로부터 움직이는 캡슐 스킨 생성 요청을 받아 움직이는 캡슐 스킨을 생성하고 완성된 데이터를 저장합니다

    이런 방식의 시스템 디자인을 구상한 이유

    알림 서비스를 분리한 이유?

    1. 알림 전송은 서비스의 핵심이 아니라고 생각했습니다. 그래서 알림 전송 성공의 여부가 서비스에 영향을 미치지 않았으면 했습니다.

     

    캡슐 스킨 생성 서비스를 분리한 이유?

    1. 움직이는 이미지를 만드는 AI 라이브러리를 사용하는데 핵심 서비스와 언어가 달랐습니다. (Java <-> python)
    2. 움직이는 캡슐 스킨을 생성할 때 시간이 EC2 c5a.large 인스턴스 기준 약 30~50초가량 소요됩니다. 그래서 사용자를 기다리지 않게 하려고 캡슐 스킨 생성 작업을 비동기로 처리하고 나중에 사용자에게 알림을 주는 방식으로 처리 하기 위해 서비스를 분리했습니다.

    개선해보니 시스템 디자인의 요소들이 무엇을 하고 어떻게 통신하는지 더 잘 이해가 됩니다. 또한, 시스템 디자인의 요소들이 어떤 책임이 있는지 파악할 수 있었습니다. 이런 방식으로 시스템을 디자인한 이유를 계속 확인할 수 있어 서비스를 만들 때 왜 이렇게 서비스를 분리해야 하는지에 대한 의문점이 해소되었습니다.

    프로젝트의 핵심 기능 개발은 거의 끝난 지금 다시 돌아보니 설계의 중요성을 참 많이 느끼는 것 같습니다. 이번 프로젝트를 통해서 내가 한 설계의 명확한 이유를 기록하고 설명해야 할 것 같습니다. 또한, 설계에서 각 요소의 책임이나 소통 방식까지 고려해야 할 것 같습니다.

Designed by Tistory.