2013년 4월 23일부터 다닌 이음소시어스를 퇴사하게 되었습니다. 2년 반 동안 회사에서 한 일을 정리해볼까 합니다. 크게 아래의 4가지 키워드로 요약이 되네요

• Veyron
• AWS
• 이상형오디션
• Golf

Veyron

이음 3.0의 웹, API 서버 개발과 QA를 완료하고 애플 스토어 심사 승인을 기다리는 상태에서 입사를 했습니다. Java Spring framework에 ORM으로 Hibernate을 사용하여 개발이 되어있었습니다. 입사한지 그리 오래 지나지 않아 기다리고 기다리던 애플 스토어 심사 승인이 떨어져서 런칭을 하게 되었습니다. 무사히 사용자의 요청을 잘 처리해주면 행복했겠지만 새 매칭이 들어가는 매일 오후 12시 30분 마다 성능과의 씨름을 하게 되었습니다.

가장 큰 병목이었던 MySQL 스펙업을 가장 먼저 진행했습니다. AWS RDS 스펙 중 그 당시 가장 좋은 스펙으로까지 올리게 되었습니다. 또한 Read Replica를 생성해서 read query를 분산하도록 했습니다. 이 2가지 조치를 통해서 어느 정도 개선이 되었지만 부족했습니다. 코드 레벨에서의 최적화도 진행을 했습니다. 하나의 요청에서 같은 연산을 여러번 하지 않도록 하고 지나치게 복잡한 로직은 단순화하거나 제거하였습니다.

여기까지의 최적화를 통해 서비스가 가능한 상태가 되었습니다만 이음 3.1, 3.2 등 새로운 기능 추가와 소규모 개편 때 종종 성능 이슈가 발생하기도 했습니다. 이럴 때마다 수정을 롤백하고 성능 개선을 해야 할 수 밖에 없었습니다. 개발에만 집중하기에도 힘들 수 밖에 없었고요

그래서 요청이 가장 많은 API 서버만이라도 안정적으로 개발, 운영하기 위해 새로운 개발 환경을 알아보기 시작했습니다. Python Flask, Ruby Sinatra, C Apache Module, Node.js의 4가지 환경에서 로그인 API를 구현하고 비교해보았습니다. Ruby Sinatra와 C Apache Module이 응답속도는 비슷하게 나왔지만 CPU, 메모리 등 리소스 사용률에서 C Apache Module이 월등했습니다. API 서버의 경우 성능 이슈도 있지만 피크 타임에 리소스 사용률이 지나치게 높아서 장비를 여러대 사용하고 그로 인해 비용이 꽤 나오는 문제도 있었습니다. 그런 면에서 볼 때 C Apache Module이 가장 좋은 선택이라고 판단했습니다. NHN에서 6년 반 동안 Apache Module을 개발하고 운영한 경험도 한 몫 하긴 했습니다. 문제가 발생하더라도 금방 금방 해결이 가능하니까요

프로젝트명을 Veyron으로 정하고 개발을 시작했습니다. 성능 이슈가 있고 요청이 많은 무거운 API 부터 개발을 시작해서 차근차근 Veyron으로 옮겨가게 되었습니다. Veyron으로 점점 옮겨가면서 성능 이슈가 말끔히 사라졌습니다. 운영 이슈로 인해 개발에 집중할 수 없는 상황이 없어진 것 만으로도 큰 성과였다고 생각합니다.

C로 API서버를 개발하는 것이 신기했던지 함께 작업한 개발자들이 회사 기술 블로그에 포스팅을 하기도 했습니다. 많은 논란이 있었는데 이 또한 처음 겪어보는 신기한 경험이었습니다. 기슬 불로그 포스팅은 아래와 같습니다.

• 아파치 모듈로 개발된 API 서버, 이음 베이론을 소개합니다.
• C언어로 API 서버 개발, 생각보다 나쁘지 않아요

AWS

NHN 시절에는 회사에서 IDC를 운영했고 조직별로 장비를 할당받아서 서비스를 운영했습니다. 장비 할당과 네트워크 설정 등 서비스를 위한 인프라를 담당하는 조직이 따로 있었습니다. 이음소시어스는 AWS와 KT Ucloud를 사용하고 있었습니다. 이음은 AWS를 사용하고 아임에잇은 KT Ucloud를 사용하고 있었으나 지금은 모두 AWS를 사용하고 있습니다.

제가 입사했을때에는 EC2, RDS, Elastic Beanstalk, Route 53, SES, SNS(모바일 푸시는 미사용) 정도를 사용하고 있었습니다. 퇴사하는 시점에는 EC2, RDS, Route 53, SES, SNS(모바일 푸시 사용), S3, Cloud Front, Elasticsearch Service 등으로 확대되었습니다. 그 사이에 도메인 구매가 가능해지고 요금 할인도 몇 번 있었고 새로운 instace type 추가도 몇 번 있었으며 RDS에 PostgreSQL, Aurora 등이 추가되는 등 많은 변화가 있었습니다.

나날이 발전하는 AWS를 보는 것이 즐겁습니다. 구글과 MS도 더 많이 발전해서 서로 좋은 영향을 주길 바랍니다. 사용자 입장에서는 선택의 폭이 다양해지고 가격도 저렴해지면 더할 나위 없지 않을까 싶습니다.

참고로 12개월 동안 무료로 제공되는 free tier가 있어서 제가 개발하고 운영하는 아이노알바, 렛미닥터 모두 AWS를 사용하고 있습니다. 2개 사이트 모두 도메인 구매 비용 12달러와 매월 Route 53 설정으로 0.5달러가 나가고 있는 것이 전부입니다. 트래픽이 많아지면 더 늘어날 수 있겠네요

AWS 관련한 유용한 링크 몇 개 공유합니다.

• 이음 on AWS
• AWS free tier
• AWS 블로그
• AWS 사용자 그룹

이상형오디션

2013년 10월 경 부터 진행한 프로젝트입니다. 기존의 이음, 아임에잇 보다 가볍게 접근할 수 있는 재미있는 서비스를 지향한 프로젝트였습니다. 개발자, 기획자가 의기투합하여 진행한 재미있는 프로젝트였습니다. 밤샘 심사까지 진행할 정도로 열과 성을 다했지만 거기까지였습니다. 실무진에서는 영어 버전 런칭, 새로운 게임 방식 도입 등 해보고 싶은 것이 많았지만 회사 사정상 서비스를 접어야 해서 아쉬웠습니다.

하나의 서비스를 처음부터 끝까지 구축해본 좋은 경험이었습니다. 이음과 마찬가지로 AWS를 사용했으며 회사 블로그에 한 포스팅을 공유합니다.

• 이상형오디션 on AWS

Golf

이상형오디션에서부터 사용해보기 시작한 Ruby on Rails를 사용해서 이음 API 서버를 개발했습니다. 전세계적인 베스트셀러이자 성능과 안정성, 실용성까지 갖춘 폭스바겐의 대표 브랜드 Golf에서 이름을 따왔습니다. (디젤 파동 때문에 잘못 지은게 아닌가 싶기도 하네요^^;)

Golf를 개발하기 시작한 동기는 Veyron 개발의 귀차니즘과 업무 인수인계를 위함이었습니다. Veyron으로 개발을 해두면 월등한 성능 덕분에 운영 이슈는 없지만 SQL을 직접 작성하고 개발을 해야 하는 것이 불편했습니다. Rails의 ActiveRecord를 써보고 나니 편함과 불편함의 갭이 한없이 커져버렸습니다. ActiveRecord를 사용해서 코드가 단순해지고 이해하기 쉬워지면 인수인계도 그만큼 수월해집니다.

100개 이상의 API를 Rails로 구현하는데 2달, 운영 환경 설정과 성능 개선에 1달 정도의 시간을 사용했습니다. 확실히 Veyron 개발 때 보다 짧은 시간 안에 재밌게 개발을 할 수 있었습니다. 성능 이슈만 잡을 수 있다면 Ruby on Rails도 좋은 선택이라고 생각합니다.

성능 개선을 위해 ruby-prof, rack-mini-profiler, bullet, fasterer, newrelic 등의 도구를 사용했습니다. redis를 cache 용도로 적극 사용하고 비동기 처리가 가능한 부분을 최대한 sidekiq에서 처리하도록 했습니다.

느낀점

NHN 시절에는 Apache Module 이외에는 특별히 관심을 가지지 않았고 그럴 필요도 크게 느끼지 못했습니다. 이직 이후에는 기존 시스템에 대한 이해와 성능 개선을 위해 서버 개발 관련 트렌트를 열심히 좇아보고 공부도 많이 했습니다. 새로운 것들을 배우고 적용해보는 좋은 경험을 했습니다.

이음, 이상형오디션의 서비스와 관련된 모든 부분을 만져보고 개발하고 개선해보았습니다. 아키텍처에 대한 고민도 많이 했습니다. 큰 그림을 그려볼 수 있는 경험이었고 앞으로 개발자로 일하는한 도움이 되리라 생각합니다.

많은 부분을 공부하고 고민도 많이 해서 좋았지만 단점을 꼽자면 시스템에서 부족한 모든 부분을 직접 고민하고 해결해야 하는게 때로는 피곤하기도 했습니다.