축제 주점 결제 서비스 배포 회고

서론

기존에 만든 원격 주문 서비스에 학교 축제 주점을 입점시켜 원격 주문을 할 수 있게 했다. 도입하기로 결정된 이후 채 한 달도 안되는 시간 밖에 없었다. 기간은 22일 저녁부터 24일 새벽까지 서비스를 제공 했었다.

정산 이슈

사실 우리의 꿈은 모든 주점에 서비스를 도입하는 것 이었다. 하지만 PG사에서 제공하는 월 정산 한도는 1천만원이었다. 4~5천만원의 예측치에 한참 모자라는 금액이었다.

보증 보험을 통해서 한도를 늘릴 수 있었지만, 심사에서 통과한다는 보장이 없었다. 또한 만에 하나 떨어진다면 몇 개월에 걸쳐 정산을 받고, 주점측에 미리 정산을 해줘야 해서 몇천의 현금이 필요했다.

현실적으로 해결 불가능한 상황이라 판단했고, 수준에 맞게 입점 주점 개수를 줄이기로 했다. 최종적으로 7개의 주점과 계약을 맺었다.

운영 이슈

기존 카페 환경과 다른 환경에서 서비스를 운영하다 보니, 여러 이슈가 발생했다.

네트워크 이슈

네트워크 오류가 발생했다. 주점의 위치가 학교 운동장이다보니 안정적인 네트워크 환경을 제공하기 어려웠다. 주점에서 개인 휴대폰으로 핫스팟을 사용했다. 그러다보니 문제가 발생했다.

18시에 주점이 오픈하는데, 많은 사람들이 데이터를 사용하려고 하니 네트워크가 불안정해졌다. 이 불안정한 네트워크 때문에 주문을 받을 수 없는 상황이 발생했다. 항상 안정적인 네트워크 환경에서만 서비스를 운영하다 보니 간과한 부분이었다.

군대에서 태풍 피항으로 부대에 많은 배가 정박했을 때 데이터가 안터지는 경험이 있었는데, 그때의 경험을 잊고 있었다. 프론트에 네트워크가 불안정하다는 메시지를 띄워주는 기능을 추가하거나 이런 문제가 발생할 수 있다는걸 미리 가이드라인에 추가했으면 혼선이 줄었을 것 같다.

화면 이슈

사진에 보이는 것처럼 포장/매장이 사랑/매장으로 작성하지 않은게 보이는 문제가 발생했다. 간혹 1~2명의 사용자가 이런 문제를 겪었다. 코드를 봐도, DB를 봐도 전혀 작성하지 않은 것이었다.

당시에는 문제 원인조차 짐작하지 못했다. 우리가 만든 코드가 문제라고 생각한게 원인을 찾지 못한 이유였다.

이유는 자동 번역 문제였다. 왠지 모르게 한글 -> 한글을 자동 번역하는 경우가 있었다. 빨리 찾아서 가이드라인에 추가했으면 더 좋았을 것 같다.

[에러를 재현한 화면]

개발적 아쉬움

시간 관계상 단순 스케일 업 방식으로 트래픽에 대비를 했다. 부하 테스트를 하거나 로드 밸런싱을 도입하지 않아 비용 최적화를 하지 못했다. 유저 쪽은 t4g.small -> m4g.xlarge로 변경했고, DB는 db.t4g.micro -> db.m4g.xlarge로 변경했다. 최대 cpu 사용량이 5%를 넘지 않았다. 엄청난 낭비였다.

최대 TPS는 30이었고, 이 마저도 빠르게 줄어나갔다. 주점당 40개 이상의 테이블이 있었으니, 7주점 * 40테이블 * 4명 = 약 2,800명 + 메뉴 구경 인원이 동시 접속을 할 것이라 예측했었다. 하지만 테이블의 모든 인원이 주문을 하지 않고 1~2명만 주문을 하다보니, 예상보다 트래픽이 적었다. 덕분에 TPS 100, 1000이 얼마나 큰 수인지 체감할 수 있었다.