[잔소리 프로젝트] 🤔 현재 경험하고 있는 애로사항과 앞으로의 방향성

---

 

시작 전, 잔소리 프로젝트 간략 소개

(간략 소개) 잔소리 프로젝트는 구글 애드센스의 수익 관련 통계 보고서의 복잡한 인터페이스와 수동으로 보고서 옵션을 설정 후 관리해야 하는 불편성을 개선하기 위해 시작된 작은 프로젝트 입니다. 물론 해당 프로젝트가 모든 것을 자동화하지는 못하지만, 처음 한 번만 간단하게 설정해두면, 나머지는 알아서 최신 보고서 데이터를 자동화하여 받아볼 수 있는 것이 차별점 입니다. 

 

(개발 기간) 개발 기간은 2024.07.09 ~ 2024.08.05 로 약 1달 가량 진행이 되었고, 개인 사정으로 지연된 시간을 제외한다면 실제 개발 기간은 3주 정도 작업을 한듯 합니다. 

비고) 약 1주 정도 크론 작업이 정상적으로 동작하는지 보기위해 테스트 배포 기간(why? 메일 알림을 등록하는 간격이 최소 1주 단위이므로 해당 기간에 맞췄습니다)을 거쳐, 현재는 24.08.17 기준으로 실제 프로덕션에서 사용하기 위한 배포 문제를 경험하고 있습니다. 따라서 이에 대해 정리해보며 어떤 문제로 인해 지연이 되고 있는지 고찰해보는 시가능ㄹ 가지는 것이 현 포스트의 목적입니다.

 

(타겟 사용자) 타겟팅한 사용자는 구글 애드센스를 사용하는 사용자 입니다. 다만, 현재는 유튜브 부분에 대한 정보를 제공하지 않는 점, 지원하는 보고서 옵션이 제한적입니다. 이는 서비스를 운영해가면서 점차 필요한 데이터를 보완하고 추가해 나갈 생각입니다.

 

(프로젝트 목적) 해당 프로젝트의 목적은 결국 애드센스 수익을  보다 쉽게 관리할 수 있는 환경을 구축하는 것입니다. 애드센스 보고서 관리의 사용성을 높이며, 직관적인 인터페이스에 기반하여 추가적으로 메일링 서비스를 통해 보고서 알림을 자동화하고 있으며, 이를 기반으로 사용자가 일일이 보고서를 취합하고 관리해야 하는 문제를 최대한 줄이는 것을 목표로 합니다.

마치 소개한 내용만 보면 거창한 느낌이 들지만, 실상은 메일링 서비스가 중점이고, 제공되는 서비스도 현재까지는 많이 미흡한 작은 프로젝트 입니다. 언제나 확장 가능성이 풍부하다고 생각되는 만큼, 지속적으로 관심을 가지며 발전시켜 나갈 수 있다고 봅니다.

 

사이트 접속 시 보이는 모달 입니다. 그 외 사이트 전반적으로 디자인이 딱딱한 느낌이라 모던한 느낌으로 변경할 필요성을 느끼고 있습니다.

 

해당 포스트 작성 이유

이번 포스트를 작성하게 된 계기는 배포와 관련해서 며칠 간 애로사항을 경험하고 있고, 이에 대해서 정리해보면서 무엇을 놓치고 있는가를 돌이켜보이기 위해서 입니다. 따라서 현재 어떤 방식으로 배포를 진행하고 있는지, 어떤 문제가 발생하여 배포 지연이 되고 있는지 정리해보면서 놓치고 있는 부분이 무엇일지 점검해보고자 합니다.

 

배포방식

현재 프로젝트의 배포 방식은 구글의 Cloud Run 을 사용하여 프로젝트를 도커 이미지로 빌드 후 컨테이너 배포하는 것입니다. 이 방식의 장점은 컨테이너 인스턴스를 최소 0 개 부터 지정한 최대 개수 만큼 자동으로 확장 및 축소 됨에 따라 과도하게 몰릴 수 있는 트래픽을 효율적으로 처리할 수 있다는 장점이 있습니다.

 

물론 위 장점은 다른 방식에서도 지원하는 기능입니다. 제가 해당 방식을 선택한 핵심 이유는 활성화 인스턴스를 최소 0으로 지정해두면, 사용자가 웹 사이트를 이용하지 않는 경우에는 중지된 상태로 있기 때문에, 유휴 리소스에 대한 비용을 절감할 수 있다는 점이었습니다.  프로젝트 자체적인 특성이 사용자로 하여금 사이트에 상주하도록 하는 것이 목적이 아니므로 굳이 상시 가동하여 리소스를 사용할 필요성이 없기 때문입니다.

 

현재 경험하고 있는 문제와 고려해야 할 점

지금 배포와 관련해서 며칠 간 계속 고통을 받고 있습니다. 사실 다른 방식을 적용하면, 벌써 배포하고도 끝났겠지만, 해당 문제를 꼭 해결하고 싶어서 지금도 발을 동동 거리고 있습니다.

 

5432 포트가 이미 활성화 중 이라는데,, 

 

현재 Cloud Run 배포는 NextJS 를 올리는 용도이고, 데이터베이스는 별도의 Cloud SQL 이라는 서비스를 이용해서 사용중입니다. 다만, Cloud SQL 을 Cloud Run 과 연동하기 위해서는 SQL Auth Proxy 를 설정하는 과정이 필요했고, 데이터베이스 중에서도 Prisma 와 같은 DB 맵핑 라이브러리를 사용한다면, 일반적인 프록시 설정이 아니라 Unix 소켓과 별도의 커텍터 라이브러리를 사용하여 연동해주어야 합니다.

Unix 소켓이란?

동일한 호스트(로컬 머신) 내에서 실행되는 프로세스 간 통신(IPC, Inter-Process Communication)을 위해 사용하는 통신 방식 중 하나입니다. Unix 소켓은 일반적인 네트워크 소켓과 유사하지만, 네트워크를 통해 다른 호스트와 통신하는 대신, 로컬 시스템 내에서만 동작

 

여기서,  Unix 소켓과 클라우드 커넥터를 설정해서 Cloud Run 과 Cloud SQL 간에 연동 까지는 성공했으나, 문제는 프로젝트 이미지를 빌드하는 과정에서 5432 포트가 이미 활성화 중이라는 문제가 발생하면서 이미지 빌드가 실패한다는 점입니다.

 

해당 문제는 결국 5432 포트가 이미 활성화된 상태라서 발생하는 것인데, 지금 생각해보면 이미지를 빌드하는 과정 중에 굳이 데이터베이스 연결이 필요한가? 라는 의문이 들었습니다. 따라서 이미지가 빌드될 때는 데이터베이스 연결 로직이 활성화되지 않도록 해봄으로써 해당 문제를 개선해봐야 할 것 같습니다.

 

다만 추가적으로 고려해야 하는 부분은 보통 이미지 빌드 시 해당 문제가 발생하지 않는 것이 일반적이라는데, 어딘가 제가 잘못 작성한 로직이 문제가 되고 있는 것이 분명한 만큼 이에 대한 디버깅도 병행해봐야 할 것 같다는 점입니다.

 

인스턴스가 0 개로 축소될 때 로컬 크론은 어떻게?

앞서 Cloud Run의 경우 인스턴스를 0개 에서 필요에 따라 그 이상의 개수를 자유롭게 활성화하면서 트래픽을 효율적으로 분산 처리하는 것이 장점이라 하였습니다.

 

다만, 위 방식으로 인스턴스의 확장과 축소 시 최소 0으로 인스턴스를 지정한다면, 프로젝트에서 사용하고 있는 로컬의 크론이 동작하지 않습니다(컴퓨터가 꺼진 상태니까요).

 

이 문제는 프로젝트 초창기 부터 고민하고 있던 사항인데, 찾아보니 GCP 에서 제공하는 Cloud 스케줄러를 이용해 일정한 시간 간격으로 Cloud Run 에 HTTP 요청을 보내고, 해당 요청을 받은 인스턴스를 일정 시간 활성화하는 방식으로 개선할 수 있을 것으로 보입니다.

 

최대한 비용을 절감하고, 사용자로 하여금 지속적인 서비스의 제공을 보장하는 방식으로 이 문제를 개선해 나가볼까 합니다.

 

일단 계속 해보는 것으로

앞서 경험하고 있는 애로 사항이 핵심적인 것이라 나머지는 해보고 나서 정리해봐야 할 듯 합니다. 일단 DB 부터 정상적으로 동작해야 Cloud 스케줄러를 사용하든 뭐든 가능할 것이니, 시급한 문제부터 처리하는 것이 맞는 것 같습니다.

 

오늘은 이렇게 현재 경험하고 있는 문제와 방향성에 대해서 고민하고 정리해보는 시간을 가져보았는데, 확실히 글로 정리하고 나니 생각이 명확해 지고, 앞으로 어떻게 문제를 개선해나갈 것인지 방향성이 잡히는 것 같습니다. 일단 생각난 방향대로 조치해보며, 그 과정 속에서 배운 것들을 정리해 나가며 부족한 부분을 계속 보완해 나가야 겠습니다.

 

영영가 있는 글은 아니지만, 해당 포스트를 참고해주셔서 감사하며, 이만 글을 줄여봅니다.