anby
서비스
통합 자원 관리 SaaS, anby
주요 기능
통합 자원 관리
유/무형의 개념을 자원으로 추상화하여 관리할 수 있는 대상으로 만들고, 이를 기반으로 서비스 사용자로 하여금 타임라인 예약, 웨이팅, 주문 등의 서비스로 이용할 수 있도록 통합 대시보드로 제공합니다.
티켓 관리
서비스 이용자의 예약, 웨이팅, 주문 등의 요청은 티켓 단위로 관리하며, 통합 대시보드를 통해 티켓을 확인할 수 있습니다.
서비스 설명
실제 교내 타 학과의 외주 프로젝트를 기초로, 예약, 웨이팅, 주문 등의 다양한 수요가 실제 세계에 존재합니다. 실제로 smkx 2025에서는 예약과 웨이팅이 동시에 이루어져야 하는 상황이지만 서로 다른 서비스들을 사용하는 불편함을 확인했습니다. 특히 주 타겟으로 삼은 교내 다양한 동아리와 과 학생회 등은 공간 대여 및 물품 대여 사업, 축제 주점 등 관리할 자원이 존재했으나 전산화되지 않는 상황이 다수여서 충분히 서비스의 대상이 될 수 있다고 판단했습니다.
이에 동일한 자원을 두고 여러 서비스를 중복으로 사용해야 하는 불편함을 개선하고자 자원을 통합으로 관리하고, 예약, 웨이팅, 주문 등을 처리할 수 있는 서비스를 제공하여 이러한 불편함을 개선하고자 합니다.
프로젝트 기간
2025.02. - 2025.08. (7개월)
2026.04. - 현재(외주 작업 중)
사용 기술 스택
React + Typescript + NextJs
- 엄격한 타입 관리를 통한 오류 발생 가능성 억제 + 빠른 개발
- AI 친화적인 구성
Go
- 람다 환경에서의 가벼운 런타임 + 빠른 속도
- 엄격한 타입 제한을 통한 오류 발생 가능성 억제
AWS
- 람다 기반의 서버리스 아키텍처를 사용한 노코스트 서버 구축 목적
- auto scailing을 지원하는 람다를 통한 안정적인 서비스 운영
DynamoDB
- AWS 관리형 서비스 + auto scailing에 이점
- 다른 RDS 대비 프리티어 혜택을 통한 유지 비용 낮음
구현 및 기여 내용
Backend
- 관리자 대시보드 RESTful API 엔드포인트 설계 및 기능 구현
- 대규모 트래픽 처리를 고려한 티켓 도메인 데이터 구조 및 DynamoDB 스키마 설계
- DynamoDB 조건부 업데이트와 낙관적 락 기능을 사용 티켓 중복 예약 방지 및 동시성 제어
팀원
프론트 1인
관리자 BE 1인
클라이언트 BE 1인
시스템 아키텍처
사용자 인증/인가
AWS API Gateway에서 Lambda auhorizer를 사용하여 JWT 토큰을 발급 및 검증하여 관리자 API에 대한 인증/인가를 구현했습니다.
람다 기반 서버리스 아키텍처
x86 프로세서 기반보다 arm 프로세서 기반 람다가 동일 퍼포먼스 대비 20% 저렴한 점을 확인하여 arm 프로세서 기반 람다에 Go 기반 서버 코드를 올려 서버리스 서버를 구축했습니다.
SQS를 사용한 안정적인 데이터 처리
람다에서 타임아웃/DB 과부화 등의 상황 발생 시 데이터가 유실될 수 있는 문제점을 SQS를 사용하여 해결하고자 했습니다.
FIFO SQS를 설정하고 메시지가 순차적으로 잘 처리될 수 있도록 보장했습니다.
DynamoDB 주요 구성
ticket은 서비스 별로 상태 변화가 잦게 있기 때문에 각 테이블을 분리하여 사용하도록 했습니다.
resource 테이블에 자원의 모든 내용을 담아 관리할 수 있도록 하였습니다.
project 테이블을 통해 독립된 주문, 예약, 웨이팅 테이블들을 복합적으로 관리 및 처리할 수 있도록 연동 관계를 설정할 수 있게 하였습니다.
Cognito를 사용하여 사용자의 로그인/회원가입을 처리하되, 서버 요청에 대한 보안 처리를 위해 users 테이블에 사용자 정보를 저장하고 관리합니다.
resources - 자원을 관리할 테이블
| 속성 | type | 설명 |
|---|---|---|
| PK | string | projectID#resourceID |
| SK | string | 자원 ID |
| name | string | 자원 이름 |
| type | string | MENU | OPTION | CATEGORY | RESERVATIONTARGET |
| field | string | 자원에 필요한 정보를 직렬화 |
| imageURI | string | presignedURI |
| state | bool | 자원 사용 가능 여부 |
| capacity | int | 자원 수량 |
| used | int | 사용된 자원량 |
| createdAt | datetime | 생성 시각 |
| updatedAt | datetime | 업데이트 시각 |
projects - 프로젝트 정보를 관리할 테이블
프로젝트 정보
프로젝트 연동 관계
| 속성 | type | 설명 |
|---|---|---|
| PK | string | userID#projectID parentProjectID |
| SK | string | INFO childProjectID |
| name | string | 프로젝트 이름 |
| type | string | RESERVATION | ORDER | WAITING META |
| field | string | 프로젝트에 사용되는 정보 직렬화 |
| imageURI | string | presignedURI |
| state | bool | 프로젝트 활성 여부 |
| createdAt | datetime | 생성 시각 |
| updatedAt | datetime | 업데이트 시각 |
| GSI_meta | string | 복합 프로젝트 검색을 위한 GSI |
users - 사용자 정보를 관리할 테이블
| 속성 | type | 설명 |
|---|---|---|
| email(PK) | string | 사용자 email |
| userID | string | 사용자 ID |
| username | string | 사용자 이름 |
| createdAt | datetime | 생성 시각 |
| updatedAt | datetime | 업데이트 시각 |
waiting_tickets - 웨이팅 티켓
| 속성 | type | 설명 |
|---|---|---|
| PK | string | 프로젝트 ID |
| SK | string | 티켓 ID |
| requester | string | 요청자 ID |
| data | string | 요청자 정보를 직렬화 |
| requestedTime | datetime | 티켓 생성 시각 |
| startTime | datetime | 티켓 유효 시작 시각 |
| endTime | datetime | 티켓 유효 종료 시각 |
| expiredTime | datetime | 티켓 파기 시각 |
| state | string | PENDING | ACQUIRE | RELEASED |
| memo | string | 요청 사항 |
order_tickets - 주문 티켓
| 속성 | type | 설명 |
|---|---|---|
| PK | string | 프로젝트 ID |
| SK | string | 티켓 ID |
| requester | string | 요청자 ID |
| data | string | 요청자 정보를 직렬화 |
| requestedTime | datetime | 티켓 생성 시각 |
| startTime | datetime | 티켓 유효 시작 시각 |
| endTime | datetime | 티켓 유효 종료 시각 |
| expiredTime | datetime | 티켓 파기 시각 |
| state | string | PENDING | ACQUIRE | RELEASED |
| memo | string | 주문 요청 사항 |
| OSI | string | 유효 주문 처리를 위한 인증 키 |
reservation_tickets - 예약 티켓
| 속성 | type | 설명 |
|---|---|---|
| PK | string | 프로젝트 ID |
| SK | string | 티켓 ID |
| requester | string | 요청자 ID |
| data | string | 요청자 정보를 직렬화 |
| requestedTime | datetime | 티켓 생성 시각 |
| startTime | datetime | 티켓 유효 시작 시각 |
| endTime | datetime | 티켓 유효 종료 시각 |
| expiredTime | datetime | 티켓 파기 시각 |
| state | string | PENDING | ACQUIRE | RELEASED |
| memo | string | 주문 요청 사항 |
teams - 팀 관리를 위한 테이블
| 속성 | type | 설명 |
|---|---|---|
| PK | string | teamID |
| SK | string | INFO MEMEBER#userID PROJECT#projectID |
| createdAt | datetime | 생성 시각 |
| updatedAt | datetime | 업데이트 시각 |
| name | string | 팀 이름 사용자 이름 프로젝트 이름 |
| owner | string | 프로젝트 오너 userID |
| type | string | - owner | admin | member RESERVATION | ORDER | WAITING |
| GSI_team | string | _ userID - |
| GSI_project | string | - - projectID |
프로젝트 수행 중 부딪힌 문제
중복 예약 문제
예약과 같이 단일 자원에 대해 여러 번의 쓰기 요청이 입력되는 경우, 예약 중복 혹은 예약 덮어쓰기가 진행되는 문제가 발생했습니다. dynamodb는 이러한 문제를 해결하기 위한 기술적 장치가 존재하지 않기 때문에 낙관적 락, 혹은 비관적 락 방식으로 문제를 해결하고자 고민했고, 몇 번의 인터뷰와 예상 시나리오를 가정하여 테스트한 결과 통합 자원 관리 특성 상 동일 자원에 대해 동시적으로 100번 이상의 중복 요청이 들어오진 않는다는 점을 확인하고, 100 단위의 버저닝 방식을 사용한 낙관적 락 방식으로 해당 문제를 해결했습니다.
grafana를 통합 운영 모니터링 구축
AWS 클라우드 환경으로 모든 서비스를 구축했으며, cloudwatch를 통해 운영 오버헤드 없이 모니터링 환경을 쉽게 구성할 수 있었지만, alartm을 여러 개 생성 시 추가 비용이 발생하는 문제가 있었습니다.
Cloudwatch의 메트릭을 받아 람다에서의 함수 실행시간, ddb 오류 발생 여부 등을 시각화하는 대시보드를 구축했습니다.
threshold 이상의 값이 발생 시 실시간으로 개발 팀 discord 채널로 경고 문구를 보내도록 webhook 기반 알림 설정을 하였습니다.
비용 효율 최적화
람다의 컴퓨팅 파워 구성은 메모리 용량을 기준으로 합니다. 메모리 구성을 크게 잡으면 빠르지만 비용이 비효율적이고, 낮게 잡으면 실행 시간이 길어져 비효율이 발생했습니다.
비용 효율을 최적화하기 위해 AWS lambda Power Tuning 오픈소스를 사용해 실제 사용할 더미 데이터셋을 만들고 메모리 구성 별 테스트를 실행했습니다.
테스트 결과 256MB와 512MB 메모리 구성을 사용한 경우 실행 시간이 동일하게 가장 짧게 나타났으나 실행 비용 면에서 256MB 구성이 실행 시간 당 0.0000005$ 저렴하게 사용할 수 있다는 점을 확인했습니다.