저희 플라워로드 서비스는 전동 킥보드 공유서비스 시스템입니다. 개발 초기에 backend 를 어떻게 구성할지 많은 고민을 하게 되었습니다. 제가 시스템을 설계할때만해도 국내에는 전동 킥보드 공유 서비스를 하는 업체가 전혀 없고, dockless 공유 서비스(kakao T Bike같은..) 조차도 없어서 참고 할만한 대상을 찾기 위해 여기저기 많은 시스템 아키텍처를 검토 했었습니다.
처음에는 타다, Uber같은 자동차 공유 서비스의 아키텍처를 많이 검토 했었는데 결정적으로 저희 시스템과는 다른점이 있었습니다. 바로 실시간성이죠. 자동차는 계속 움직임이 있고, 이 움직임을 실시간으로 표시를 해야하지만 저희 스쿠터의 경우 그냥 정지되어 있는 스쿠터만 보여주면 되는 거였죠.
그래도, 이런 공유 서비스업체들과 쿠팡, 배민과 같은 서비스에서 사용되는 기술들도 검토를 해보고 지금과 같은 시스템을 구축하게 되었습니다.
얼마 안되는 resource로(사실...저 혼자라는...쿨럭...) 구성된 아키텍처 이지만 꽤 많은 기술들이 사용되고 있고, 기술들의 대부분의 AWS에서 운영되고 있습니다.
AWS를 사용하게 된 이유는 일단 infra구축에 들어가는 시간을 최대한 절약하기 위해서 입니다. 지원하는 tool, plugin들이나 reference들이 다양해서 서비스를 구축하는 시간을 매우 많이 절약해 줍니다. 이는 설계 당시 빠르게 서비스를 시장에 배포해야하는 요구조건을 만족시키기에 충분했습니다. 물론 AWS 사용중 잘못 구성하거나 사용상에 실수로 인해서 요금폭탄이 발생하기도 하지만 이는 대부분 support center에 메일을 보내서 잘 설명을 하면 실수에 의한 요금은 모두 환불 혹은 credit로 처리되기도 했습니다.
위에 설명한것 처럼 대부분의 서비스는 AWS에서 구동되고 있습니다. 다양한 서비스들을 위한 infra구축에 시간을 많이 투자 하지 않고도 여러 service/tech들을 이용할 수 있었고 이는 좀더 개발에 집중할 수 있도록 해주었습니다. 이는 설계 검토 초기에 빠르게 서비스를 시작할 수 있는 기반이 된다고 판단하고 이를 선택하게 되었습니다.
이미지 process를 위한 vision service를 사용하고 있습니다. AWS에서도 이와 비슷한 서비스를 제공하고 있기는 하지만 여러 기술 blog나 이용 사례를 살펴 봤을때 google의 vision이 정확도가 가장 높다고 해서 채용하게 되었습니다.
Spring Boot같이 다양한 방면에서 많이 사용되고 있는 framework가 검토되었지만, 시스템을 구성할때에 대부분의 서비스가 serverless환경에서 동작하도록 구성했고, 이는 AWS Lambda를 이용하도록 설계를 했기 때문에 cold boot 속도가 가장 빠른 node js를 선택하게 되었습니다. 이것 외에도 npm을 활용한 다양한 3rd party module를 활용할 수 있어서 서비스 개발에 좀더 집중 할 수 있었습니다.
저희 서비스는 테스트를 위한 서버환경과 실제 고객님에게 서비스를 제공하는 서비스 환경 둘로 나뉘어져 있습니다. 수많은 AWS, Google cloud의 서비스들을 일일이 console을 통해서 설정 및 관리를 할 수 없기에 사용하게 되었습니다. 이를 이용함으로 또 하나의 장점은 서버 계정의 이전이 매우 수월해 졌고, 환경을 구성할 때 자주 발생하는 human error가 없어지다보니 안정적인 시스템 구성/이전/추가등이 가능했습니다.
terraform과는 별도로 AWS의 Lambda와 gateway를 구성할때에 편리하게 이용하기 위해 사용되었습니다. terraform이 있는데 serverless를 왜 사용하는가 라는 의구심이 들수 있는데 terraform은 전체 AWS 서비스들의 구성을 담당(vpc, db, codepipeline 등)하고 serverless는 codepipeline 에서 실행되어 각각의 lambda들을 deploy하기 위해 사용됩니다. 수많은 lambda를 기능별/카테고리별로 구분하고, 이를 각각의 독립된 serverless(yml)를 이용해서 deploy하기 때문에 자동화된 deploy+기능별/카테고리별 묶음 deploy + 독립된 deploy를 구성할 수 있었습니다.
IoT의 통신을 위해서 개발된 잘 알려진 network protocol입니다. 전동킥보드나 다른 IoT기기들의 데이터를 수집하기 위해서 사용됩니다. MQTT는 기본적으로 message queue의 기술 카테고리에 해당하기 때문에 즉각적인 반응은 보장하지 않아서 IoT의 즉각적인 제어를 위해서 사용되지는 않고 있습니다.
client에서 실시간성이 필요한 데이터의 전달을 위해서 사용되고 있습니다. HTTP protocol을 이용한 REST API는 양방향 통신이 아니기 때문에 client와 실시간 interaction이 필요한 부분에서 어려움을 격다가 이를 시범적으로 사용하게 되었습니다. 이 글이 아닌 다음글 정도에서 다루게 될것 같은데 WebSocket외에도 실시간 통신을 위해 gRPC도 검토 및 시범 사용되고 있습니다.
Web based의 관리 시스템을 구현/구성하기 위해서 사용되고 있습니다. 잘 구성되어 있는 dashboard의 예제 platform이 있어서 이를 활용해서 빠르게 구현하기 위해 선택했습니다. 실제 사용자(고객)를 위해서 구현/구성되는 부분은 없고, 회사 내부적으로 전체 전동 킥보드들의 관제 및 관리를 위한 web app의 구현을 위해서 선택되었습니다.
Architecture를 검토, 구성하는 초기에 가급적이면 모든 서비스를 AWS내에서 운영하도록 구성해왔습니다. 이는 빠르게 구성해서 서비스를 시작할 수 있도록 하자는 의도에서 진행 되었고, 목표에 맞게 예상보다 빠르게 서비스를 delivery할 수 있었습니다.
아주 다양하고 많은 AWS service를 사용하고 있습니다. 이 글에서는 사용중인 service들에 대해서 간략하게 설명을 하고 사용중인 모든 서비스들의 architecture 구성에 대한 내용은 여기서 다루지는 않고 다른 포스팅에서( 플라워로드 AWS Architecture ) 좀더 자세하게 다룰 예정입니다.
AWS service들 중 외부 network로 부터 보호되어야 할 service들을 위해서 구성되었습니다. 사실 단순하게 VPC를 사용한다 라고 하기에는 구성되어 있는 내용이 좀 많아서 기회가 있다면 다름 포스팅에서 상세하게 다루고, 여기서는 간단하게 어떤 서비스들이 포함되어 있는지 나열만 하겠습니다. ECS, Aurora RDS, DynamoDB, ElastiCache, Backend, ECS, 고정 IP, Network Load Balancer, IoT Core, 특정 Lambda들을 위해서 구성되었습니다. 물론 나열된것 이외에도 EKS같이 몇몇 service들이 있으나 상세한 내용은 다음기회에 다루겠습니다.