인식한 상황#

탄소 배출을 줄이는 관점에서 서비스 개발을 진행하던 중, Local Test를 통해 메모리 과다 사용 문제가 발견했다.

(탄소 배출은 너무 어려운 주제다…)

초기에는 주제에 맞게 탄소 소비를 줄이기 위해서 모든 로직을 클라이언트 측에 구현하였으나, 이는 전력 소비가 증가하고 클라이언트의 부담이 커지는 문제를 발생했다. 또한, 전반적인 성능 저하가 발생하는 문제를 확인했다.

해결 과정#

이 문제를 해결하기 위해 우리 팀은 서버와 클라이언트 간의 리소스 사용 시간과 전력 소비를 측정하고 비교하기로 결정했습니다. 특히, 알림 전송과 팔로우(Follow) 기능에 따른 데이터베이스 수정 두 가지 주요 기능에 초점을 맞춰서 분석해 봤다.

Spring으로 간단하게 Logic을 만들어 서버를 배포하고, 측정된 실행 시간은 다음과 같았다.

• 클라이언트(핸드폰) 측
  • 알림 전송 시간: 2021 ms
  • 팔로우 기능(데이터베이스 수정) 시간: 700 ms
• 서버 측
  • 알림 전송 시간: 1103 ms
  • 팔로우 기능 시간: 130 ms

그 뒤, 컴퓨터 구조 강의 중 배운 전력량에 있어서 다음과 같이 w/s를 계산해 보니 아래 결과를 뽑아냈다.

• 서버: 0.028 w/s
• 클라이언트: 0.007 w/s

이를 바탕으로 팀은 사용성과 탄소량 최적화의 균형을 맞추기 위해 필요할 때만 활성화되는 FaaS를 도입하기로 결정하고 내부 로직을 전부 갈아치웠다. Flutter로 작성한 로직을 Java Script로 변경하고 Firebase의 Cloud Function 기능을 통해 REST API를 개발했다. 또한, Trigger 기능을 통해 Cloud Storage에 최소한의 접근을 하도록 했다.

결과#

약 17시간 동안 로직을 모두 수정해야 했지만, 모두 같이 Discord를 통해 밤을 새우며 작업하다 보니 기능을 개발할 수 있었습니다. 전반적인 서비스의 성능과 반응 속도를 향상할 수 있었으며 탄소 배출 감소라는 SDGs의 목표도 맞출 수 있었고, 이 부분에서 점수를 많이 받은 걸로 생각된다. (언제 한번 전 세계 100등 안에 들어보겠어…)

하지만 사용자 기기의 수명까지 고려하지 못한 점이 아쉽다. 결국 소모품인 기기까지 고려하여 탄소 배출을 계산했으면 더 좋았을 거 같다.