Final Project 회고

 

1. 프로젝트 개요

이 프로젝트에서는 마라톤 대회 관리 시스템의 백엔드 부분의 일부분, Lambd-SQS-Lambda의 EDA 추가로 모니터링과 데이터베이스도 공동으로 담당하였고, 특히 REST API를 통해 데이터를 주고받는 부분과 참가자들의 기록을 가져오고 포인트를 저장하는 EDA를 구현하였습니다. 프로젝트의 핵심 목표는 마라톤 대회의 참가자 정보와 그들의 기록을 효율적이고 안정적으로 관리하는 것이었습니다.

2. 주요 도전 과제 및 해결 전략

2.1. 백엔드 REST API 설계

프로젝트.1 이후 REST API를 구현하는 것은 꽤 고난이 있었습니다. 비전공자였던, 저는 프로젝트.1 진행함에 따라가기도 벅차 제대로 이해를 하지 못한 부분이 많았기 때문입니다. 이를 위해 우선 HTTP 메소드와 상태 코드의 의미를 확실히 이해하고, 자원을 나타내는 URI를 설계하는 방법을 공부해 REST API Table 작성 및 ERD 작성을 할 수 있었습니다. 또한, REST API가 상태를 저장하지 않는 Stateless 특성을 적극 활용하여 클라이언트-서버 간의 통신을 간소화하였습니다.

 

2.2. 기록 및 포인트 EDA 구현

참가자의 기록을 실시간으로 가져오고, 그에 따라 포인트를 계산하여 저장하는 EDA를 구현하는 과정에서도 여러 새롭게 알게된 이슈가 있었습니다. Producer Lambda가 Private subnet에 위치한 데이터베이스와 연결하기 위해 Lambda의 Subnet 설정도 같은 Subnet으로 설정해야하는 점과 이렇게 될 경우에 이벤트 채널인 SQS가 외부 서비스이기 때문에 메세지를 보내기 위해서는 SQS의 Endpoint 설정을 해주었습니다.

 

3. 성과 및 배운 점

이번 프로젝트를 통해 칸반보드 활용과 협업의 중요성에 대해 느낄 수 있었고, 백엔드 개발에 대한 실질적인 경험을 쌓을 수 있었습니다. 특히 REST API를 직접 설계하고 구현하면서 웹 서비스의 구조와 원리에 대해 더 깊게 이해할 수 있었습니다. 또한 매번 Public subnet에서 실습했다가 Private subnet에 서버와 DB을 둠으로써 Nat Gateway, Endpoint 고려해야할 점을 배울 수 있었습니다.
기록데이터을 기반으로 포인트 지급하는 로직을 EDA로 구현할 때도 마찬가지로 Private 이슈 해결 과정 새롭게 EventBridge 서비스를 사용함으로써 Lambda와 SQS 서비스에 대해 더 많은 이해를 할 수 있었습니다.

4. 아쉬운 점 및 개선 방향

1. 모니터링 서비스 구성 변경

처음에는 Prometheus와 Grafana를 활용한 모니터링 서비스를 계획했습니다. Prometheus는 오픈소스 모니터링 솔루션으로 강력한 데이터 스크레이핑, 저장, 쿼리 기능을 제공하며, Grafana는 이러한 데이터를 가시화하는 데 최적화되어 있어 원래의 계획이었습니다.

하지만, 특정 이슈로 인해 원래의 계획대로 Prometheus를 사용하는 대신 AWS CloudWatch를 사용하여 모니터링하게 되었습니다. CloudWatch도 매우 효과적인 모니터링 도구이지만, Prometheus의 고급 기능들을 활용하지 못한 것은 아쉽습니다.

 

개선 방향

프로젝트 후반에 Prometheus와 Grafana를 도입하여 원래의 계획대로 시스템 모니터링을 강화하는 것을 고려할 수 있습니다. 또한, 프로젝트 초기 단계에서 사용할 도구와 기술 스택을 결정할 때는 각 도구의 호환성, 필요한 리소스, 프로젝트 요구사항 등을 충분히 고려하여 이러한 상황을 방지하는 것이 중요하다 생각합니다.

 

2. 인프라 IaC 작성 미비

이번 프로젝트에서는 시간의 문제로 인해 DB, Front, Backend에 대한 초기 Iac은 구현했지만 전체 인프라의 Infrastructure as Code (IaC)를 작성하지 못했습니다. 이로 인해 코드로 인프라를 관리하고, 버전 관리와 재사용의 경험을 하지 못해 아쉬웠습니다.

 

개선 방향

프로젝트의 초기 단계부터 IaC를 도입하는 것이 필요하다 생각했습니다. 이를 위해, Terraform 같은 도구를 사용하여 인프라를 코드로 관리할 수 있습니다. 이렇게 하면 인프라 변경사항을 코드로 추적하고, 필요할 때 이전 버전의 인프라로 쉽게 롤백할 수 있으며, 인프라를 재사용하고 공유하기도 편리해지고 IaC를 통해 DevOps 팀의 작업 효율성과 시스템의 안정성을 높일 수 있다는 기대를 할 수 있습니다.

5. 마무리

이번 마라톤 대회 관리 시스템 백엔드 개발 프로젝트를 통해 많은 기술적인 지식뿐만 아니라 프로젝트 관리, 팀 협업 등 많은 경험을 얻었습니다. 특히, REST API 설계와 EDA 구현을 통해 백엔드 시스템의 중요성과 복잡성을 깊이 이해할 수 있었습니다.

아쉬웠던 점들, 예를 들어 처음 구성하려던 모니터링 서비스를 변경하거나 IaC를 완전히 적용하지 못한 점 등은 앞으로의 개발 경험에서 중요한 배움이 될 것이라 생각합니다. 그런 점에서 이번 프로젝트는 개선점과 잠재력을 발견할 수 있는 좋은 기회였습니다.

앞으로는 이번 프로젝트에서 느꼈던 아쉬움을 바탕으로 Prometheus와 Grafana의 도입을 고려하여 모니터링 시스템을 개선하고, Terraform 등을 활용하여 IaC를 적용하여 효율성과 안정성을 높일 계획입니다.

이런 경험들이 앞으로 더 큰 프로젝트에서도 안정적이고 효율적인 시스템을 만드는데 큰 도움이 될 것이라고 확신합니다. 프로젝트를 통해 배운 점들을 잊지 않고, 지속적으로 개선하여 앞으로의 프로젝트에서 더 나은 결과를 만들어내는 개발자가 되겠습니다.