1. 주문/결제 도입
- 포트원을 활용한 PG(나이스페이먼츠, 페이팔) 결제
- 주문 시스템 구축
- 부분환불, 전체환불
- 주문 완료시 포트원 웹훅을 통한 후처리: 상품지급
- 정기구독: 결제수단 등록 및 정기 결제예약
- 구독에 따른 상품 사용량 및 권한 할당
2. ChatGPT + Google Vision AI + AWS Rekognition 을 이용한 URL 분석
- URL 을 입력하면 해당 URL 의 title 과 meta tag를 기반으로 ChatGPT 에 업종/업태를 분석요청
- 입력된 URL 의 웹페이지를 스크린샷 찍은후, AWS Rekognition 으로 스크린샷과 파비콘의 색상 코드 분석
- Google Vision AI 로 스크린샷에 있는 텍스트 분석
- 웹페이지내에 있는 이미지 링크를 모두 저장
- 분석결과로 업종/업태, 웹사이트에 어울리는 색상 추천, 웹사이트내 이미지와 텍스트를 투어내 지정
3. 테마 제공 및 CMS 편집기
- 누구나 자신만의 스페이스를 소유할 수 있고 소유한 스페이스내 모듈을 편집할 수 있는 기능 제공
4. 랜딩 7~8번 변경
- 랜딩 페이지가 약 7~8번이 완전히 변경되어 랜딩 페이지에서 사용할 API 개발
5. 라이브 투어 기능 개발
- 스페이스에 접속시 접속자를 호스트와 게스트로 분류
- 접속자는 모두 웹소켓에 접속하여 호스트의 메시지를 구독
- 게스트는 호스트의 이동경로, 모듈오픈 메시지를 웹소켓을 통해 전달 받고 이 메시지에 따라 호스트가 하는 행동을 동일하게 따라하게 된다. 호스트가 이동하면 모든 게스트들도 자동으로 같이 이동하고, 모듈을 오픈하면 같이 오픈된다. 호스트의 얼굴과 음성은 Zoom 의 화상채팅 기능을 이용해 노출된다.
- 호스트가 게스트를 데리고 다니면서 스페이스를 가이드해준다. 모듈에 있는 컨텐츠에 대한 설명도 해주고 적절한 동선으로 이끌고 다니면서 공간에 대한 설명도 해준다.
- 웹소켓은 Spring Websocket, STOMP 를 이용해서 만들었다.
6. 마켓플레이스
- 사용자가 스페이스를 소유하기 위해선 마켓플레이스에서 엘리펙스에서 제공하는 스페이스를 구매해야한다.(현재는 무료로 풀림)
- 사용자가 구매할 수 있는 스페이스 목록을 마켓플레이스 형태로 노출한다. 쿠팡이나 11번가 같은 쇼핑몰의 상품 목록 페이지와 같다고 생각하면 된다
- 각 상품은 프로모션을 적용할 수 있다.
- 프로모션은 정액할인, 정률할인, 기간할인 을 적용할 수 있다.
- 엘리펙스에서 발급한 라이센스 코드를 통해서 상품을 무료로 구매할 수 있다.
7. 티켓
- 특정 스페이스는 티켓을 구매해야만 입장할 수 있다.
- 스페이스에 입장할 때 해당 스페이스가 티켓이 필요한 공간인지 아닌지 여부를 검사 후, 티켓이 필요하다면 접속한 사용자가 티켓을 소지(구독)하고 있는지 여부를 검사한다. 티켓을 구독하고 있지 않다면 비즈니스 예외코드를 리턴해 프론트에서 해당 예외코드를 받을시 얼럿 노출과 함께 리다이렉트한다.
- 티켓은 기존 상품과 상이한 정보가 많아 별도의 티켓 테이블을 따로 생성했고 각 티켓에 상품코드를 FK 로 갖고 있도록 처리
8. 운영플랜
- 사용자가 스페이스를 구매할 때 함께 구매해야 하는 상품 중 운영플랜이라는 것이 있다
- 무료 운영플랜은 한달간 스페이스에 접속할 수 있는 접속자 수 제한, 모듈에 업로드할 수 있는 컨텐츠의 용량 제한등 이용할 수 있는 트래픽, 용량등에 제한이 있다.
- 각 운영플랜은 하나의 상품이며 운영플랜 속에 또다른 상품이 번들 형태로 존재한다.
- 예를들어 접속자 한달 허용 5000명 이라는 것도 하나의 상품이다.
- 무료 운영 플랜 상품에는 접속자허용 상품, 화상채팅 허용 상품, 워터마크 제거 상품 등이 포함돼있다.
상품테이블에는 번들상품인지 아닌지 여부가 있어서 번들 상품인 경우 해당 상품의 번들 상품을 별도의 테이블에 저장하여 찾아내도록 설계했다. 이렇게 설계한 이유는 추후 번들내 포함된 개별 상품도 운영플랜이 아닌 별개의 상품으로 판매할 수 있도록 하기 위함이다.
9. XMPP Protocol 을 이용한 채팅 기능 개발
- 기존에 Sendbird 채팅서비스를 이용하고 있었는데 월결제 비용이 부담돼서 채팅 서비스를 in-housing 하기로 결정했다.
- 채팅서비스를 웹소켓을 이용해서 직접 한땀한땀 만들기 보다는 채팅 서비스 프로토콜인 XMPP 를 활용하기로 결정.
- XMPP 프로토콜을 이용한 Openfire 를 사용하여 채팅 기능 개발
- 하지만 Zoom 화상채팅 기능을 이용하면서 Zoom 에 텍스트채팅기능도 포함되어있어 Zoom 채팅기능 이용하기로 결정.
서비스를 개발/운영하면서 발생했던 기억에 남는 장애
- 모든 서비스가 AWS EKS 환경에 올라가 있었는데 특이하게도 개발과 운영환경이 분리되어 있지 않았다.
개발환경에서 JMeter 를 이용하여 스트레스 테스트를 하고 있는데 운영 환경이 영향을 받았다. 이에 K8s 환경을 살펴보던 중, K8s 버전이 상당히 구버전임을 확인하고 나름 준비를 하고 레퍼런스를 확인하여 버전업을 진행했다가 K8s 에 올라가있던 모든 서비스가 일제히 장애가 발생했다. 회사 동료가 우선은 각각의 서비스를 개별 EC2 에 구성하고, Route 53 의 도메인의 주소를 모두 변경하여 1차적으로 급한불을 끄는데까지 약 4시간 정도 소요됐다.
K8s 환경을 이용하기 위해 Rancher 를 사용했는데 Rancher 도 고장이 나버렸다. K8s 커맨드에 익숙치 않아 레퍼런스를 참고하여 우선 기존 설정 yml 파일을 백업했고, EKS Cluster 와 Rancher 를 아예 새롭게 구성한 후, 백업한 yml 로 기존 deployment, service, ingress 등을 복구했다. 운영 환경을 전체 복구하는데 꼬박 만 이틀정도의 시간이 소요됐다.
- 기존에 특정 데이터를 S3에 업로드하다가 실패하면 이전까지 업로드했던 모든 파일을 삭제하는 로직이 있었다.
코드 작성자의 의도는 S3 에 트랜잭션을 걸듯이 파일 업로드 중 실패시 남는 쓰레기 파일을 지우기 위함이였을것이다.
그런데 이 코드에 버그가 있어 디렉토리를 통째로 지워버리는 무서운 사건이 발생했다.
갑자기 접속이 제대로 되지 않는 스페이스가 하나둘 생기더니 시간이 지날수록 접속되지 않는 스페이스가 점점 늘어났다.
이유를 몰라 어리둥절해하고 있었는데 회사동료분이 문제의 원인을 찾으셨다.
하지만 이때는 이미 상당히 많은양의 데이터가 S3에서 삭제된 상황이였다.
데이터를 복구할 수 있는지 여부를 파악하기 위해 S3 레퍼런스를 확인하던 중, S3 는 파일을 삭제하더라도 물리적으로 삭제하는게 아닌
삭제 마커를 저장해서 화면에서만 노출되지 않는다는 사실을 파악. 삭제 마커를 제거하면 지워진 파일이 원복된다는 사실을 확인했다.
복구할 수 있다는 사실을 직접 알게 됐을때 안도의한숨을 내쉬었고 삭제된 파일이 너무 많고 디렉토리 구조도 복잡하여 S3 콘솔에서 직접 복구하기는 거의 불가능에 가까워 삭제마커를 병렬로 제거하는 프로그램을 개발해서 자동으로 삭제하도록 처리했는데 지워진 파일이 얼마나 많았는지 4명이 동시에 이 병렬 프로그램을 수행했음에도 모든파일을 복구하는데 3시간 이상이 소요됐다.