굿닥의 테크스택에 관하여 – 1 – 서버 스택편

굿닥은 현재 웹과 모바일앱 두종류의 플랫폼 환경에서 서비스를 제공하고 있으며, 이와 더불어 신규로 모바일 애플리케이션을 개발하고 있습니다.

굿닥은 현재 전체적인 엔지니어링 컬처를 변화시키고 있으며, 이를위한 여러가지 작업들도 비즈니스 요구사항과 더불어 진행하고 있습니다. 이에 대해서 한번 정리하고, 스타트업에서 어떻게 속도와 비용문제를 해결하기 위한 노력을 하고있는지에 대한 내용을 공유하고자 합니다.

이미 스타트업 중에서도 굿닥에 비해 훨씬 선진화된 개발/CI환경을 구축해 계신곳이 많은 것으로 알고 있습니다만, 속도가 항상 중시되는 상황에서 적은 개발인력으로 나름대로 많은 고민을 해가고 있습니다.

이번 글에서는 굿닥서비스의 뼈대가 되고 중추가 되는 서버스택과 관련한 내용을 먼저 공유하고자 합니다.

 

ServerStack

굿닥의 서비스는 크게 두가지 환경에서 운영/개발 되고 있으며, 현재는 모두 클라우드 기반의 환경을 적용하고 있습니다.

기본적으로 고가용성과 비용을 적절히 타협하기 위한 노력들을 하고 있으며, 선진기술에 대해서도 적극적으로 도입하려는 개발조직에서 만들어 지고 있습니다.

굿닥 서비스 테크스택

굿닥 서비스 의 경우는 현재 개발조직 구성원이 기반을 다져온 환경은 아닙니다. 그래서 선택의 이유는 정확히 모르는 부분들이 있습니다. 나름대로 합리적인 서버스택을 구성해 왔으나 여러 부분에서의 이슈들이 존재하고 있고, 이를 개선하기 위한 노력을 점진적으로 수행해 나가고 있습니다.

Vultr Cloud 기반 구성

굿닥 서버 환경은 Vultr이라는 저렴한 VPS 클라우드에서 구동되고 있습니다. Nginx가 로드밸런서 역할을 담당하고, Api/Web Server역할을 수행하는 instance가 api요청에 대한 응답을 수행하도록 구성되어 있습니다. SPOF( single point of failure)을 제거하기 위해 Api서버는 이중화 되어있으나, DB의 경우는 현재 MHA를 통한 고가용성을 유지하기 위한 방안을 검토 중에 있습니다.

Vultr을 통한 시스템 운용을 함에 있어 가장 큰 단점은 장애 대응이 원활하지 않다는 점입니다. 최근 굿닥의 경우 하드웨어/네트워크 이슈로 인한 장애상황을 꽤 잦은 빈도로 맞이하면서, 정확한 장애원인파악이나 보상등이 이루어 지지 않고 기대수준만큼의 즉각적인 조치도 일어나지 않았습니다. 경우에 따라서는 콘솔환경에 대한 접속도 이루어지지 않아 아무 조치도 할 수 없는 상황도 맞이한 적이 있어 고가용성 환경으로 구축하는데에 많은 어려움이 존재합니다.

Ruby on Rails

굿닥의 기본적인 인프라는 Ruby on Rails를 기반으로 구현되어 있습니다. 최근에는 각광받는 프레임워크는 아니지만 생산성 측면에서는 매우 우수한 환경이라고 생각합니다. 현재 굿닥은 Unicorn + Rails로 구성이 되어 있고, 배포는 Capistrano를 사용하여 다중서버(4대)로 배포합니다.  만일 백엔드 개발자가 어느정도 프론트페이지의 개발을 진행해야 한다면 다른 프레임워크에 비해 매우 효율적인 환경이 될 수 있습니다. 현재 굿닥은 웹-프론트 개발파트를 따로 구성하고 있어, 그 장점을 십분 활용하고 있지는 못하고 있습니다.

 

Maria DB

DB에 대해서는 별다른 코멘트 요소가 없으며, 병원,이벤트,회원등의 메타정보를 저장하기 위한 목적으로 활용되고 있습니다. 마스터 슬레이브 구조로 구축되어 있으나 SPOF에 대한 무결성을 보장하기위한 MHA를 구성하고 별도의 환경에 이중화를 하는 형태의 개선작업을 7월 중 수행할 계획을 세우고 있습니다.

CDNetworks

이미지 등의 정적파일을 캐시하는 목적으로 CDN을 활용중에 있습니다. 차후 CDN의 이중화도 고려중에 있습니다. 이미지 및 자바스크립트 파일 등이 변경되는 경우 파일서버에서 물리파일을 가져와 CDN에서 저장/반환하도록 구성되어 있습니다.

Apache Spark+Zeppline

Spark은 메모리 기반에서 대용량데이터를 처리할 수 있는 분산처리 환경으로, 통계를 위하여 Zeppline과 연동하여 사용합니다. 현재로서는 서비스 내부의 아주 부분적인 통계지표를 만드는데 활용되고 있으나 점점 그 활용범위를 넓혀 가려고 하고 있습니다.

신규 서비스 테크스택

아직까지 개발과정에 있는 서버스택입니다만, AWS Lambda기반의 서비스 구축사례가 아직까지 국내에는 드문 듯 하여 간략하게 나마 공유를 하려 합니다. 현재 굿닥 개발팀은 AWS환경에 대한 이해도가 높은 상황은 아니지만 비교적 빠르게 도입검토를 마치고 적용을 진행중에 있습니다.

AWS Lambda/API Gateway/Cloudfront

굿닥에서는 현재 신규 서비스를 개발 중에 있으며, 이에 대한 서버스택에 대해 많은 고민을 하였습니다. 최초 서버스택은 Heroku를 통해 Python+Flask 기반의 서비스 아키텍처를 구축하려고 하였으나, Heroku가 기본적으로 미국 Region을 활용하여야 하는점으로 인해 latency가 느린 점이 차후 서비스의 영향도가 있을 듯 하여 최근 각광을 받고 있는 Serverless 환경의 대표주자격인 Lambda기반의 환경을 검토하게 되었습니다.

인프라 설치, 운용, 확장성 고려, 복잡한 배포 및 모니터링 등 많은 관리 업무를 줄이고, 민첩하게 대응하기 위한 환경을 위해 마이크로서비스를 채택하였습니다.

적용을 하면서 일반적인 API Server/RDS 아키텍처와 다른 구성을 적용하다보니, 당연한 것들이 당연하지 않게 되는 점들이 많이 있는 것 같습니다. 기본적으로는 CPU연산시간을 기준으로 과금하는 Lambda의 과금체계로 인해 연산시간을 줄이기 위한 여러가지 기법들을 수행하는 형태의 고민들이 필요하고, 아울러 서버사이드에서의 로지컬한 구현보다, 다수의 처리를 클라이언트에서 구현해야 하는(그래야 비용이 절감되는)이슈들을 많이 만나고 있고, 이를 개발속도와 성능사이에서의 trade-off를 지속적으로 고려하면서 구축해 나가고 있습니다.

AWS DynamoDB

성능과 편의성, 대규모 DB 구축에 필요한 비용 절감. 읽기와 쓰기가 매우 빈번하고 처리 속도가 빨라야 하는 환경, 작은 용량의 데이터가 매우 많은 서비스 특성을 고려하여 dynamoDB를 사용하고 있습니다.

dynamoDB는 NoSql기반의 AWS제품으로 Streams 라는 개념을 통해 DB에 데이터의 변경이 발생할 때에 필요한 event trigger를 수행하도록 구현할 수 있습니다.

AWS s3

수많은 유저의 컨텐츠를 저장하기 위해 저렴하고 견고한 AWS S3를 사용하고있습니다. 현재로서는 이미지를 중심으로 사용자정보를 저장하고 있습니다. 또한 신규 구축중인 AngularJs기반의 어드민 웹사이트의 경우도 s3를 통해 배포하여 배포자동화환경에 한발 더 다가가고 있습니다.

AWS CloudSearch

Cloud Search는 DynamoDB의 데이터를 검색하기 위한 목적으로 사용하며, 최초 ElasticSearch를 고려하다,서비스를 빠르게 구현하고, 우리의 서비스 특성상 문맥을 파악하는 검색보다 키워드방식의 검색이 더 빈번할 것으로 판단되어 도입하였습니다.

향후 고도화 단계에서는 확장성이 있는 ElasticSearch로 점진적으로 변경할 계획입니다.

Redis

Redis는 Memory 기반의 Key/Value Dictionary로 Value에 List/Map/Set 타입의 자료구조도 저장할 수 있는 장점을 가지고 있어 빠른처리가 필요한 부분에 다양한 목적으로 사용할 수 있습니다. 일반적으로는 캐쉬의 목적으로 활용하거나, 굉장히 빈번하게 발생하는 요청을 처리하기 위하여 활용합니다. 그리고 Memcached와 달리 Snapshot을 Disk에 저장할 수 있어, 데이터의 유실가능성이 낮은 장점을 가지고 있습니다.

정리하며..

이번 글에서는 백엔드 테크를 살펴보았는데, 다음 글에서는 프론트엔드 테크스택을 소개하려고 합니다.

테크 중심의 스타트업에 비해 굿닥이 굉장히 선진화된 엔지니어링 컬처를 가지고 있지는 않습니다. 아직까지 기술부채도 다수 존재하는 것도 사실이지만, 이 시스템을 통해 꾸준히 비즈니스를 성장시켜 온만큼 좀 더 안정적이며,  우수한 서버기반이 갖춰진다면 더욱 더 많은 가치들을 사용자에게 전달 해 줄수 있을 것입니다.