brunch

You can make anything
by writing

C.S.Lewis

by sebatyler Jan 05. 2018

비프로 API 서버 개발기

축구를 좋아하는 개발자로서 축구 스타트업에 조인하여 보낸 6개월 중 가장 큰 일이었던 API 서버 개발을 정리해보려고 한다. 간단히 요약을 해보면 이렇다. 2017년 6월 초에 비프로 컴퍼니에 합류해서 6월 말에 함부르크로 출국을 했고 12월까지 열심히 개발을 하고 3주간의 휴가를 보내게 된다.

기존 API 서버

기존 서버는 python flask로 개발되었고 DB는 mysql과 구글 데이터스토어(NDB)를 사용하고 있었다. 구글 앱엔진의 미국 리전을 통해 서비스하고 있었다.

요구 사항

분석한 축구 경기에 대한 상세 데이터가 NDB에 있었는데 mysql 에 있는 데이터와의 조인이 불편하고 검색을 위해서 인덱스를 생성해야 하는 등 유연하지 못한 문제가 있어서 NDB 데이터를 mysql로 옮길 필요가 있었다. 또한 기존 API 서버 코드도 레거시화되어 리팩토링을 겸해서 다시 개발하는 게 좋겠다는 요구 사항이 있었다.

시행 착오

우선 NDB 데이터를 mysql로 옮기는 코드 개발부터 시작했다. 처음부터 쉽지 않았는데 이는 NDB와 앱엔진의 제약 때문이었다. NDB는 앱엔진 환경에 최적화되어있어서 이 환경을 통해 데이터를 가져오는 것은 빠르지만 로컬 개발 환경이나 컴퓨트엔진에서 데이터를 가져오는 것은 느리다. 그래서 앱엔진에 코드를 올려서 데이터를 옮기려는 시도를 먼저 했다. 앱엔진 요청의 타임아웃은 60초이고 비동기 방식인 태스크큐를 사용하더라도 10분이 최대이다. 처음에 생각한 마이그레이션 방식은 데이터를 한방에 다 옮기는 것이어서 앱엔진을 사용하지 못하고 느리더라도 컴퓨트엔진에 올려서 테스트를 해보았다. 실험을 해보니 대략 3시간 정도면 마이그레이션이 완료될 것 같아서 이쯤에서 데이터 마이그레이션은 준비가 된 것으로 보았다.

다음으로 API 서버를 어떤 언어와 프레임웍을 사용해서 개발할지를 정해야 했다. 기존에 node express 기반으로 살짝 작업이 된 코드가 이미 있어서 ORM으로 sequelize를 붙여서 개발을 시작했다. 개발을 하다 보니 DB 변경을 위한 마이그레이션 기능이 sequelize에는 충분하지 않아서 이 부분만 python django를 사용하고 일부 테이블에 대한 어드민을 붙여보았다. 이 환경에서 몇몇 신규 API 개발을 진행했고 서비스에도 투입이 되었다. 그러나 NDB 마이그레이션과 기존 API를 모두 재개발해서 12월 휴가 전에 서비스에 안정적으로 적용하기는 일정상 쉽지 않아 보였다. python flask 코드를 node express sequelize 코드로 개발하는 것보다 python djanogo 코드로 개발하는 것이 개발 속도도 빠르고 안정적으로 할 수 있겠다는 판단이 들어 python django로 최종 결정을 하게 되었다. 이 결정은 내가 8퍼센트에서 django에 대한 경험을 어느 정도 했기 때문이기도 하고 django의 ORM과 어드민을 좋아하기 때문이기도 하다.

본격 개발

python django 개발 환경을 세팅하면서 제일 중요하게 생각한 점은 테스팅이다. circle CI, codecov를 연동해서 github에 코드를 푸시하고 PR(pull request)를 생성할 때마다 자동으로 테스트 코드를 실행하고 테스트 커버리지를 측정하도록 했다. circle CI, codecov 둘 다 하나의 private repository에 대해서는 공짜로 쓸 수 있어서 매우 고맙게 생각한다. 처음부터 테스팅을 중요하게 생각해서 대부분의 코드에 대해 테스트 코드를 작성하려고 노력해서 95%를 넘는 테스트 커버리지를 달성했으며 서비스 적용 전 QA 기간에 안정적으로 코드 수정을 할 수 있었다.

본격 개발을 달린 기간이 3개월 정도인데 막바지에 이르러서 서비스 적용 계획을 세울 때 NDB 마이그레이션에 변화를 주게 되었다. 기존의 한방에 3시간여를 투입해서 마이그레이션 하는 것보다 경기 단위로 미리 마이그레이션 해두고 웹, 앱이 사용하는 API 서버 도메인만 변경하는 방식이 서비스 중단 시간을 최소화할 수 있는 방식이어서 이 방식을 선택하게 되었다. 마이그레이션 코드를 변경해야 했지만 서비스가 더 중요하기 때문에 감수할 만했다.

QA

12월 초에 개발을 마무리짓고 웹, 앱과 연동을 해서 QA를 진행했다. QA 하면서 발견된 버그를 수정하고 일부 성능이 안 나오는 부분도 개선을 하고 웹, 앱에서 쓰지 않는 API와 쓰지 않는 응답의 데이터를 정리하기도 한 유익한 시간이었다.

서비스 환경 세팅

QA 마무리 후 애플 앱스토어의 심사를 기다리면서 API 서비스를 위한 환경 세팅을 시작했다. flask 기반 코드가 이미 앱엔진에 올라가 있어서 구글 클라우드에 새 프로젝트를 사용하지 않는 이상 앱엔진을 사용할 수 없어서 컨테이너 엔진을 사용해야 할 것 같아 보였다. 다른 후보로 zappa를 활용해서 AWS 람다와 API 게이트웨이를 통한 서버리스 환경을 고려했다. 이 경우 mysql을 RDS로 옮겨야 하는 부담이 있지만 큰 부담은 아니었다. 그것보다는 처음 세팅해보는 것이기에 시간이 얼마나 걸릴지 예측할 수 없는 것이 부담이었다. 컨테이너 엔진의 경우는 node express 코드를 올려봤기 때문에 큰 부담은 없었다. 서비스 세팅에 사용할 수 있는 여유 시간이 하루 정도 있어서 zappa를 활용해보기로 했고 시간이 부족하다 싶으면 그때 컨테이너 엔진으로 선회하기로 했다. 몇 번의 난관이 있었지만 다행히도 zappa를 통한 배포를 무사히 할 수 있었다. 해놓고 보니 서버 운영에 대한 스트레스가 없어진 것 같아서 매우 만족스럽다. 한 가지 아쉬움이라면 RDS 오로라가 아직 mysql 5.7을 지원하지 않아 오로라를 쓰지 못했다는 점이다.

휴가 출발

베니스에서 여행 시작

휴가 직전에 무사히 서비스 적용을 해서 기분 좋게 휴가를 떠날 수 있었다. 12월 18일 오전에 아이폰X를 접수하고 오후 비행기를 타고 베니스를 시작으로 이태리, 포르투갈 여행을 다녔다. 여행 중에도 저녁에 숙소에서 몇 가지 이슈를 해결해서 배포를 하기도 했다. 또한 돌아가서 해야 할 것 같은 일들이 떠올라서 정리를 해두기도 했다.

포르투의 황홀한 야경

맺음말

6월 말에 함부르크에 와서 집 구하는 데에만 2달이 넘게 걸리고 처음 배우는 독일어가 어렵기도 하지만 나름대로 적응을 하고 회사도 독일과 유럽에서 성과를 내고 있어서 즐겁게 생활하고 있다. 여행을 마치고 포르투에서 함부르크로 돌아가는 비행기 안에서 이 글을 마무리 짓는다.