개요

---

실제 업무에서는 프로젝트 업무 절차가 어떻게 흘러가는 것일까? 본인은 Devops Cycle 을 전체적으로 한 싸이클 겪으면서 직접 설계부터 구현까지 진행하였고, 이를 통해 프로젝트 진행이 어떤 순서로 흘러가는 지를 체험해볼 수 있었다. 이러한 프로젝트 순서를 공유함을 통해 다른 분들도 프로젝트 진행 시, 참고할 수 있었으면 좋겠다.

프로젝트 진행 흐름

---

프로젝트의 진행 순서를 정리하였다. 완벽히 아래의 흐름을 따르지는 않겠지만 거시적으로 보았을 때에 아래의 진행 순서에 맞춰서 프로젝트를 진행하였다.

🔸 프로젝트 저장소 생성

깃허브에 프로젝트 저장소를 생성하였고 팀원들과 금일 할 업무에 대해서 작성하였다.

🔸 주제 선정

• 선정한 주제
  • 대회 결과 기록 시스템을 주제로 선정하였다.
• 주제 선정 사유
  • 약식으로 배웠던 MSA 을 실제로 직접 구현해볼 수 있다는 점이 좋아 선정하였다.
• 간략한 주제 내용
  • 마라톤 대회 결과를 기록하는 시스템을 구축하는 것이다. 마라톤 주최자는 마라톤 대회를 만들 수 있어야 하고 참가자는 대회에 참가 신청을 할 수 있어야 한다. 또한 마라톤 대회 기록에 따라 점수를 부여하여 랭킹을 표시하여야 한다.

🔸 요구사항 분석

아래와 같이 기능적 요구사항 과 인프라 요구사항 두가지를 요구 받았으며, 이 요구사항들에 대해 DDD 이벤트 스토밍 을 진행하였다.

🔹 주어진 요구사항

• 기능 요구사항

  - 개인 사용자와 대회주최자는 로그인 기능을 통해 토큰을 발급받을 수 있습니다.
  - 인증된 개인 사용자는 자신의 비공식 기록을 입력 및 조회할 수 있습니다.
  - 인증된 개인 사용자는 특정 대회에 참가 신청을 할 수 있습니다.
  - 대회 주최자는 대회 참가자를 조회할 수 있습니다.
  - 대회 주최자는 대회 참가자들에 대한 공식 기록을 입력 및 조회할 수 있습니다.
  - 대회 주최자에 의해 입력된 공식 기록에 따라 해당 참가자의 point 데이터에 점수가 추가됩니다.
      - 예시 : 10km 참가자는 10점, half 참가자는 20점, full 참가자는 42점 추가
  - 개인 사용자는 점수를 확인할 수 있습니다.
      - 예시 : 전체 점수 또는 상위 몇개의 랭킹, 인증된 개인의 개별 점수

• 인프라 요구사항

  - 시스템 전반에 가용성, 내결함성, 확장성, 보안성이 고려된 서비스들이 포함되어야 합니다.
  - 하나 이상의 컴퓨팅 유닛에 대한 CI/CD 파이프라인이 구성되어야합니다.
  - 유저 데이터를 저장하고 있는 유저 데이터베이스는 다른 데이터베이스와 분리되어있어야 합니다.
  - 기록 데이터를 기반으로 사용자별 점수를 기록하는 시스템은 데이터 유실을 막기 위해 느슨하게 결합되어야합니다.
  - 시스템 메트릭 또는 저장된 데이터에 대한 하나 이상의 시각화된 모니터링 시스템이 구축되어야합니다.

🔹 요구사항에 대한 분석

• DDD 이벤트 스토밍
  • DDD 이벤트 스토밍을 진행하여 도메인별로 역할과 흐름을 표시하였다.
    총 4가지의 테이블이 나왔고 기록과 점수 테이블간의 정보 갱신은 느슨한 결합으로 연결이 되어 있어야 함을 표현하였다.
    

🔸ERD 작성

작성한 DDD 이벤트 스토밍을 토대로 ERD 를 작성하였다.
테이블의 분류는 점수, 랭크, 달리기 기록, 사용자, 대회 로 나누었다.

🔸 시스템 환경 및 기술스택 논의

프로젝트에 사용할 시스템 환경과 기술 스택을 아래와 같이 맞추기로 하였다.

• OS : Ubuntu 22.04
• Backend Language : Typescript
• DB : DynamoDB, MySQL
• Framework : Express
• Cloud Provider : AWS
• CI : Git-Action
• IaC : Terraform 1.4.6

🔸 API 문서 작성

요구사항에 맞는 API 문서를 작성하였다. 빠른 인프라 구축을 위해서, 온전히 REST API 규격을 지키지는 않았다.

	CRUD	ENDPOINT	Description	비고
사용자	POST	/signup	회원가입
	POST	/login	로그인
	DELETE	/users	회원 탈퇴	개발 우선순위 낮음
마라톤 대회	GET	/competition	마라톤 대회 리스트 조회
	POST	/competition	마라톤 대회 추가	개발 우선순위 낮음
대회 참가 신청서	POST	/participation	대회 참가 신청
	GET	/participation	대회 참가자 리스트 조회
	DELETE	/participation	대회 참가 신청 취소	개발 우선순위 낮음
대회 기록	POST	/competition/records	대회 기록 입력
	GET	/competition/records	대회 기록 조회
비공식 기록	POST	/records/unofficials	비공식 기록 입력
	GET	/records/unofficials	비공식 기록 조회
기록 점수	POST	/points	기록 점수 추가
	GET	/points	기록 점수 조회
점수 랭킹	GET	/ranks	대회 점수 랭킹 조회

🔸 아키텍쳐 설계

아키텍쳐 설계를 진행하였다.

🔸 요금 계산

설계한 아키텍쳐의 실요금을 추정하여 계산하였다.
비용은 월간 약 17만원 수준이었다. 다만 이는 실습용 인프라 구축이라 트래픽이 많지 않다는 가정을 세워두었다. 실제 트래픽이 많아졌을 때에 발생할 수 있는 비용은 추후 좀 더 고민이 필요할 것이다.

🔸 백엔드 구현

이전까지 설계한 내용을 바탕으로 백엔드 코드를 구현하였다. 도커 파일을 만들어보고 도커 이미지에 환경변수를 넣은 뒤에도 정상적으로 동작하는 지 확인한다. 미리 도커 컴포즈 파일을 생성해놓음으로써 도커 실행 환경을 쉽게 만들어 놓았다. 백엔드에서 사용하는 DB 의 경우 테스트의 용이성 및 비용 절약을 위해 로컬호스트 DB 를 통해 진행하였다.

🔸 인프라 리소스 프로비져닝

AWS 콘솔 을 통해 부분적으로 인프라를 생성한 뒤 정상동작하는 지 테스트하였다. 동작에 문제가 없을 경우 테라폼 을 통해 인프라를 똑같이 만들어보는 방식으로 진행하였다.

🔸 CI / CD

깃헙 액션을 통해 CI/CD 를 진행하였다. 코드가 변경되면 깃헙 액션을 통해 도커 이미지를 생성하여 이미지 저장소에 넣은 뒤, 새로 저장된 이미지를 기존에 운용되던 이미지와 교체하는 방식을 취했다. 저장소의 경우 AWS ECR 을 사용하였으며 CD 의 경우 ECS 테스크 정의 의 이미지주소 명세를 변경함으로써 ECS 에서 자동으로 배포되도록 하였다.

🔸 모니터링

인프라 리소스의 상태를 모니터링하였다. 이를 통해 트래픽에 따른 각 리소스의 부하에 대해 서버가 얼마만큼 대응이 가능한 지 점검하였다.

🔸 프로젝트 문서 정리

프로젝트의 문서를 가다듬고 readme.md 를 정리하면서 프로젝트를 마무리하였다.

후기

---

팀 프로젝트를 할 경우 나만 의견이 다른 상황이 종종 생긴다. 이 때에 내 의견을 어필하는 것이 쉽지가 않다. DB 를 선택하는 기준에 있어서도 팀원들과 나는 의견이 서로 갈렸는데, 나의 경우 자신의 의견을 어필하는 것이 어려웠다. 팀원의 의견이 항상 만장일치가 될 순 없으므로 길게 토론을 해봐도 의견이 좁혀지지 않는다면 그 때에는 누군가가 양보해야 하는 경우가 발생할텐데 나의 경우 개발에 있어서는 이해가 되지 않으면 양보하기는 커녕 반박과 의문을 전달하는 편이다. 이럴 경우 많은 시간이 소모될 여지가 있어 전체 진행에 있어서 딜레이가 될 수 있기에 조율이 필요할텐데 이번의 프로젝트에는 아래와 같이 글로 다시 한번 내 의견을 정리하여 근거와 함께 전달을 해보았다. 글로 정리함으로써 팀원들과의 전체적인 회의시간이 줄어들어 효율적이었고 나의 의견도 온전히 전달할 수 있어서 글로 쓰는 것 또한 좋은 전달 방법이라는 것을 다시 한번 깨달았다.
아래는 내가 이번에 글로 정리한 코멘트이다. NoSQL 대비 SQL 선택 시의 장점에 대해 어필하였다.