설계에 정석은 없다 - 비영리 기업을 위한 극한의 비용 최적화

클라우드에 비즈니스를 맞추면 생기는 일

 

클라우드라고 하면 AWS가 바로 언급될 정도로 AWS는 클라우드라는 시장에 아주 막강한 생태계를 만들게 되었습니다. 그래서 저희가 프로젝트를 진행하고 있는 누구나 리포터 LAB도 AWS 기반으로 인프라를 구성하게 되었는데요.

람다는 호출을 기준으로 비용이 계산되기 때문에 고정비용은 크지 않다.

 

저희는 AWS Lambda를 도입하여 웹서버 운영에 드는 고정 비용을 크게 절감할 수 있었습니다. 하지만 AWS 생태계에서 필수적으로 사용해야 하는 인프라들로 인해 매달 200달러 이상의 고정 비용이 발생했고, 이에 인프라 사양을 최소화하는 방향으로 조정하여 비용을 100달러 수준까지 낮출 수 있었습니다.

 

 

이를 통해 초기 스타트업의 평균적인 인프라 비용보다 낮은 수준으로 운영할 수 있게 되었고, 비영리 기업에서도 충분히 감당할 수 있는 수준이라고 판단했습니다. 하지만 이는 저의 성급한 판단이었습니다. 비영리 기업에게 있어 운영 비용은 제가 생각했던 것보다 훨씬 더 중요한 문제였기 때문입니다.

사용하고 있었던 고정 인프라 

• NAT(월 43$ ~ $45)
• RDS(T4.small 50GB 사용시 월 $43 ~ $48)
• ElasticCache(t4g.small 사용시 월 $35.28)
• EC2(t4 small 사용시 $9.65)
• 총 비용: $130.93 ~ $137.93

 

 

벼룩의 간을 빼먹는 인프라 설계(비영리 기업에서 신규 프로덕트를 만들기 어려운 이유)

 

비영리 기업은 영리 기업과 다르게 수익이 난다 해도 공익을 위해서만 활용하여야 합니다. 그래서 보통 잉여금이 많지 않고 흑자가 난다해도 보통 대부분의 비영리 기업이 자본 상황이 넉넉치 않은 이유가 이런 사정이 있기 때문입니다.

 

그 중에서 가장 수익을 많이 낼 수 있는 것 중 하나가 "기부 모금"인데 브레인팰로우는 제품을 만드는 것을 중심으로 운영되는 기업이기 때문에 수익이 크지 않았고 만들어진 제품도 비영리 단체를 대상으로 판매되는 제품이다보니 일반 Saas와 같은 금액으로 측정하기가 쉽지 않았습니다.

 

결론은 기존에 낮다고 생각되는 운영 비용도 비영리 기업의 입장에서는 큰 비용이였고 새로운 프로덕트인 누구나리포터가 안정적인 BM으로 자리 잡을 때까지 팰로우에서 적자를 감수해야 되기 때문에 운영비용을 극한으로 줄여야 하는 것이 관건이였습니다.

 

 

개발에 정답은 없다. 설계도 마찬가지

 

개발자로 일을 하면서 공부하다보면 당연하게 여기는 것들이 있습니다. 예를 들어 "데이터베이스는 내부망에 있어야 안전하지", "내부망과 통신하기 위한 베스천 서버는 필수야", "캐시 서버가 죽지않기 위해서는 마스터와 레플리카 세팅은 필수지" 등 처럼요.

 

하지만 당연하다고 생각되는 것들이 때때로는 당연해지지 않아야 되는 상황들이 일어나고는 합니다. 지금과 같은 상황처럼 말이죠. 때로는 보안과 가용성을 포기하더라도 비용 줄이는 방향을 선택해야 되는 순간이 발생하고 때로는 비용을 더 지출함으로써 안정적으로 서비스를 제공하는 것을 선택해야 되는 순간들이 오게 됩니다.

 

이런 시행착오는 저에게 그동안 잊고 있었던 지속 가능한 소프트웨어의 가치를 다시 되새기게 해주었고 지금까지 제가 기본, 정석 이라고 생각했던 원칙들은 내려놓고 이 프로젝트가 지속 가능하도록 하는 것에 초점을 맞춰 다시 구조를 설계하기로 마음을 먹게 되었습니다.

 

오버, 언더 그 사이: 적정 엔지니어링의 골디락스 지대

AI 챗봇 아키텍처

 

비영리 기업에서는 어느정도의 버그를 감수하고 인프라를 제거하는 방법을 제시해주셨지만 그렇게 진행했을 때 발생할 수 있는 기술부채들이 현재 비영리 기업에 있는 개발 인력만으로 감당하기 어렵다는 생각이 들어 다른 방법들을 모색해보기로 결심했습니다.

 

기존 인프라를 버렸을 때 감당해야 되는 기술부채

• AI가 답변을 생성하기 전에 요청이 무수히 들어오면서 채팅의 응답 순서가 바뀌는 문제
• 제한없는 채팅 요청으로 인하여 AI 서버의 부하가 발생, 최악의 상황에는 AI 서버 자체가 죽음
• 중앙화된 스토리지가 없으면 HTTP Message에 모든 정보가 담기게 되고 이는 개발의 복잡성을 높여 유지보수하기 어려워짐
• 데이터의 의존성으로 인해 서로 다른 서비스가 같이 배포해야 되는 상황들이 빈번하게 발생(배포 파이프라인의 복잡성도 높아짐)
• 추후 락, 분산 트랜잭션, 폴백, 캐싱, 비동기 통신 등의 매커니즘을 구현할 때 전체적인 구조 변경이 발생할 가능성이 높음

 

위의 문제들 중 몇가지는 멀지 않은 미래에 발생할 수 있는 문제였기 때문에 현재 아키텍처에서 인프라의 비용을 낮추는 방향으로 고민하게 되었고 고민을 해결해가는 과정속에 필요하지 않은 인프라들도 제거되어 비용을 크게 줄일 수 있었습니다.

 

AWS 생태계에 벗어나기

많은 기업들이 클라우드 서비스를 활용하면서 가장 많이 비용이 지출하는 서비스 중 하나가 바로 스토리지(RDS, DocumentDB 등)입니다. AWS의 스토리지 서비스는 스케일 업(Scale-Up)을 할 때마다 비용이 2배로 뛰기 때문에 많은 기업들은 데이터베이스의 업스케일링 보다는 스토리지 인프라의 효율을 높이는 방향으로 비용 최적화를 하고는 합니다.

• 슬로우 쿼리 최적화나 인덱스 성능 개선
• 주기적인 데이터 삭제
• Read DB와 Write DB의 분리(사용량이 많은 경우)
• 캐싱 전략을 활용하여 I/O 감소
• 오토 스케일링

하지만 이런 작업을 하기위해서는 높은 연봉을 가진 전문 인력을 필요로 하게 되는데 비영리 기업은 영리 기업과 다르게 이런 인력을 채용하여 유지 하기가 쉽지 않습니다. 그래서 AWS 안에서 비용이 저렴하고 쉽게 관리할 수 있는 RDBMS 서비스를 찾아봤지만 결국 찾지 못해 외부로 눈을 돌렸습니다.

SupaBase

 

SupaBase는 Postgres DB 기반으로 만들어진 플랫폼 서비스로 REST API나 웹 소켓을 활용하여 쉽게 연동할 수 있습니다. 그리고 데이터를 관리할 수 있는 인터페이스도 제공하고 있어 편리하게 관리할 수 있었고 무엇보다 처음에는 무료로 사용할 수 있어 비영리 기업 입장에서도 부담없이 사용할 수 있었습니다.

 

그외에도 팰로우에서 사용하고 있는 Airtable과도 통합이 가능했고 필요한 알림(스토리지, Error 등) 설정들도 인터페이스를 통해 쉽게 설정할 수 있었기 때문에 전문 인력이 없더라도 쉽게 유지보수가 가능했습니다. AWS RDS에서 Supabase로 전환하면서 스토리지 비용은 크게 줄게 되었고 다음은 두번째로 많은 비용을 지출하는 레디스의 비용을 줄일 방법에 대해 모색하게 되었습니다.

 

 

서버리스 + 서버리스

 

AWS 안에서 저렴하게 활용할 수 있는 Cache Server를 찾아보다가 ElasticCache에 Serverles 서비스가 있다는 것을 알게 되었고 저장데이터가 거의 없는 저희 서비스에 적합한 서비스가 될 것 같았습니다.

 

ElasticCache Serverless의 요금 정책

저장된 데이터	USD 0.151 / GB-hour
ElastiCache 처리 장치(ECPU)	USD 0.0041 / million ECPUs

 

현재 누구나리포터 챗봇은 현재 레디스를 채팅 세션 관리와 메시지 전송할 때까지 채팅 정보 캐싱 용도로만 레디스를 사용하고 있었기 때문에 저장된 데이터가 거의 없었고 이는 저희가 서버리스 서비스를 사용했을 때 온디맨드 서비스보다 훨씬 저렴한 비용으로 서비스를 운용할 수 있다는 것을 의미했습니다.

그렇게 캐시 서버가 서버리스로 전환되면서 NAT Gateway(Lambda와 연동)와 Bastion Server(레디스를 접근하기 위한 EC2)의 존재 의 이유는 사라지게 되어 어부지리로 인프라 비용을 크게 절약할 수 있었습니다.

 

람다에서 외부 API를 호출하여야 되기 때문에 외부망과 통신할 수 있는 네트워크 망이 필요했습니다. 하지만 NAT은 많은 비용을 지출을 요구하기 때문에 어쩔 수 없이 NAT 인스턴스를 선택하여 비용을 절약하는 선택을 했었습니다.

 

랩원 분의 활약으로 추가 비용 절약

 

온디맨드 레디스의 전환을 담당하신 종민 님이 ElasticCache Serverless를 살펴보던 와중에 Redis와 동일하게 활용할 수 있는 Valkey를 찾아주셨고 1GB로 기준으로 계산 해봤을 때 Redis는 108.7 USD, Valkey는  72.72 USD 로 거의 30% 저렴하게 활용할 수 있었습니다.

 

총 결과적으로는 35.28 USD에서 3 USD 미만 정도로 인프라 비용을 크게 줄일 수 있었고 이는 비영리 단체에서 기술의 혜택을 누림과 동시에 비용도 줄일 수 있었던 좋은 사례 중 하나로 설명할 수 있을 것입니다.

 

인프라 비용 폭탄 세일 - 130달러에서 7달러로

 

실제 서비스로 운영하다보면 비용이 더 들 수 있겠지만 희망적으로는 한달에 한끼 가격 정도 되는 비용(7$)으로 프로덕트를 운용할 수 있을

만큼 비용을 크게 줄일 수 있었고, 기존에 가지고 있던 기술의 혜택 또한 그대로 누릴 수 있었습니다.

 

그렇지만 이번 결정이 ‘영원히 정답’은 아닐 거라 생각합니다. 지금으로서는 운영 부담을 최소화하고, 필요한 기능을 유지하면서, 비용 역시 낮출 수 있는 최적의 선택이었지만, 언젠가 서비스가 확대되고 보안 규제를 지켜야하는 순간이 온다면 다시 고민해야 할 부분들이 분명 생겨날 것입니다.

 

그럼에도 불구하고, 여러 개발자들의 지식과 경험, 그리고 협업 덕분에 우리는 ‘어떻게든 이 서비스를 지속 가능하게 만들기 위해’ 최적의 설계도를 만들 수 있었고 새로운 문제가 발생하더라도 큰 문제 없이 해결할 수 있을 것입니다.

 

이번 시도는 초기 비용을 극적으로 절약하면서도 핵심 기능을 유지하는 훌륭한 사례가 될 수 었었고, 이것이 앞으로 더 많은 비영리 조직이나 소규모 스타트업들이 효율적으로 서비스를 운영하는 데 작은 참고가 되길 바랍니다. 기술에 ‘정답’은 없습니다, 하지만 지속 가능한 방향으로 끊임없이 피드백을 주고받으며 개선해 나가다보면 우리에게 가장 의미 있는 답을 찾을 수 있을 것입니다.

 

비용 절약을 통해 포기한 것

• AWS Service의 높은 가용성
• Pulbic한 망을 통해 데이터를 관히하면서 취약해진 보안
• 온디맨드 서비스의 빠른 성능
• 외부 플랫폼 서비스의 강한 의존성으로 인해 확장성 제한
• 유동 비용의 증가(고정 비용을 계산하기 어려움)

총정리

• NAT(월 43$ ~ $45) => NAT 제거 0$ NAT 인스턴스로 대체(EC2 T3.nano, Elastic IP 약 7$)
• RDS(T4.small 50GB 사용시 월 $43 ~ $48) => Supabase Free 0$ (Pro 사용시 25$)
• ElasticCache(t4g.small 사용시 월 $35.28) => ElasticCache Serverless Valkey 7$
• EC2(t4 small 사용시 $9.65) => 베스천 서버 제거 0$
• 총 비용: 14$

참고 자료

https://chucoding.tistory.com/154

개발자의 비영리(non-profit) 도메인 이해하기

https://tabletalk.stibee.com/p/109/

💰 비영리 조직은 어떻게 돈을 버나요?