사용자가 늘어난다. 어쩌지..?

근래 고민

매일메일의 구독자 분들이 계속해서 늘어나고 있다. 이 상황 속에서 나의 관심사는 "어떻게 하면 AWS 비용을 줄이고, 이미 쓰고 있는 자원을 최대한 활용하여 늘어나는 사용자를 감당할 수 있을까?"이다. 매일메일 팀의 모티베이션은 구독자분들에게 가치를 전달함으로 얻을 수 있는 뿌듯함, 사용자가 있는 서비스를 운영하면서 얻을 수 있는 값진 경험들이다. 이러한 모티베이션을 AWS 인프라 비용이 뛰어넘는 순간에는 팀원들마다 생각이 달라지게 될 수 있다. 이는 팀의 존속을 위협할 수 있다. 또한, 서비스가 안정적이지 않으면 구독자분들이 이탈하니 근본적인 모티베이션이 흔들릴 수 있게 된다.

 

AWS 비용과 관련하여

비용 청구서를 확인해 보면 VPC이 비싸다. 더욱 알아볼 필요는 있지만, 우리 팀 케이스는 RDS에 퍼블릭 IPv4를 할당하여 지불해야 하는 비용으로 알고 있다. 쿼리로 처리할 수 있는 간단한 작업은 프록시 점프를 사용하여 대체 가능하다. 하지만, 재전송 로직과 같이 복잡한 일들은 로컬에서 RDS를 안전하게 연결한 뒤에 수행하고 있다. 이것이 프록시 점프로 가능한지 확인해야 한다. 만약 존재하지 않는다면, 이 부분을 해결할 수 있는 대안을 마련해야 할 수 있다. 해당 비용을 절감하면, 절감한 비용으로 새로운 서버를 사용하여 더욱 안정적인 시스템을 구축할 수 있을 것으로 기대한다. 가령, 글로벌 캐시 계층을 구축하거나 로그 관리나 메트릭 모니터링 등 가시성에 지금보다 투자할 수 있다.

 

AWS에서 비영리 단체를 대상으로 100만 크레딧을 주는 것을 본 적이 있다. 지원받은 선례가 많아 우리 팀도 받을 수 있을 것으로 생각된다. 하지만, 그것이 지금인가?라고 했을 때는 조금 고민되는 지점들이 존재한다. 우선 100만이라는 지원금의 사용 기간이 제한된다면 현재 사용량으로는 100만 크레딧을 모두 소진할 수 없다. 또한, 이를 굳이 전부 사용했는데.. 지원금을 모두 소진한 순간, 비즈니스 모델이 없는 우리 서비스는 유지 비용을 감당할 수 없다. (따라서, 우선 보류하고 좀 더 알아보자.)

 

눈에 띄게 비용이 늘어난서비스는 SES이다. 현재는 한달에 대략적으로 14만 건의 메일을 전송하는데, 지금보다 더욱 늘어날 가능성이 높다. 비용 절감하기 위해서는 불필요한 메일을 보내지는 않는 방식을 생각해 볼 수 있다. 가령, 구독 해지가 아닌 차단을 한 사용자, 오랫동안 메일을 확인하지 않은 사용자, 불필요하게 계속 인증 이메일을 발송하는 사용자를 필터링해 볼 수 있을 것이다.

 

인프라 구조와 관련하여

 

기존 서버에서는 한 곳에서 API를 위한 요청과 벌크성 메일 전송을 처리한다. 사용자가 과거에 비해 많아진 현재와 더욱 많아질 미래에 기존 레거시 인프라 구조는 이제 유효하지 않은 기술적 의사결정일 수 있다. 만약 위와 같이 API와 메일 전송과 관련된 서버를 분리하면, 서비스 확장성과 가용성을 높일 수 있을 것이라 생각했다. 

 

언젠가는 위와 같이 분산 시스템 구조를 채택하겠지만, 그것이 지금인가? 에 대해서도 역시 고민되는 지점이다. 위 구조를 제안한 근거는 오전 7-8시 사이 메일 전송을 수행하는 기간에 로드 밸런서로 들어오는 API 요청에 대한 지표가 유일하다. 해당 시간대에 대한 정확한 시스템 메트릭을 수집하더라도 어느 정도로 리소스가 부족하거나 지연이 발생해야 분리의 근거가 되는가?를 판단하기 위한 경험과 실력이 부족하다. 따라서, 이 근거가 미약하지는 않은가?에 대해 좋은 질문들을 리스트업 하고 주변 지인에게 물어봐야겠다고 생각했다.

 

성능과 관련된 액션 플랜

성능과 관련해 개선해야 할 부분들을 간단하게 메모한다. 이외에도 더욱 많지만.. 오늘은 이정도만 작성해봐야겠다.

 

• OOM 구간 점검 및 개선
  • 메모리 사용량과 관련된 불안 요소들이 존재한다. 로컬 캐시를 사용하거나, 전체 구독자를 순회하는 등 불필요한 객체를 메모리에 올리는 코드를 개선해 보자.
  • JVM 메모리 지표를 정확하게 수집할 필요가 있는지 고민해보자.
  • OOM이 발생하면 어떻게 해결할 것인가
• 로그 구간 점검 및 필요한 로그만 사용
  • 불필요하게 로그를 쓰지 말자. 파일 쓰기 비용을 줄이고, 스토리지 공간을 확보하기 위해서이다.
  • 추가로 우리 서비스는 플로우가 복잡하지 않아 사용자의 요청을 트레이싱할 필요는 없다고 생각한다.
  • 데이터베이스 백업 상황 시 유실될 수 있는 데이터들을 어떻게 우아하게 해결할 수 있는지 추가 학습이 필요하다. 

• 테이블 점검 및 필요시 개선
  • subscribe_question 테이블 대상 쿼리를 점검하자. 해당 테이블은 데이터가 하루에 7000건씩 쌓이며, 현재 21만 건이 존재한다.
  • temporal_subscribe 테이블 데이터 삭제 주기를 검토하자. 해당 테이블은 과거 데이터가 불필요하게 적재된다. 과거에는 회원 가입 도중 이탈자를 파악하기 위해서 사용했으나 최근에는 사용되지 않는 것으로 판단된다.