0. Background
초기 스타트업에게는 빠르게 제품을 개발하고 이를 시장에서 검증받는 것이 최우선 과제이지만, 제품이나 서비스가 어느 정도 시장에 안착하게 되면 그 다음부터는 안정적으로 운영하는 것이 점점 더 중요해집니다. 드라마앤컴퍼니도 리멤버를 출시한지 어느덧 2년이 지났고, 이제는 서비스를 검증하는 단계를 지나 확장하는 단계로 접어들었습니다. 따라서 신규 기능 개발도 중요하지만 그에 못지 않게 서비스의 안정성 유지도 개발팀 업무의 큰 비중을 차지하게 되었습니다.
그러면 서비스의 안정성이란 뭘까요? 회사마다, 서비스마다 약간씩 다르겠지만 대부분 아래와 같은 것들이 서비스 안정성의 중요한 요소가 될 것 같습니다.
- 무장애: 장애가 뻥뻥 나서 서비스를 이용하지 못한다면 사용자 경험에 치명적인 영향을 미치게 됩니다.
- 버그의 최소화: 앱을 실행하다가 크래시 나면 좋아할 고객은 아무도 없습니다.
- 빠른 처리 시간: 앱을 켜고 리스트를 불러오는데 10초 동안 동글뱅이가 돌고 있다면 앱을 꺼버릴 확률이 높습니다. 그리고 다신 들어오지 않겠죠. 따라서 앱/서버 등 모든 시스템의 처리 속도 또한 사용자 경험의 중요한 요소입니다. 그에 더해 리멤버는 서비스 특성상 명함의 입력 속도도 굉장히 중요합니다. 명함 이미지를 업로드했는데 하루가 지나도 입력이 안 된다면 답답함을 느낄 겁니다. 따라서 드라마앤컴퍼니는 이를 좀 더 빠르게 단축시키기 위해 여러 프로세스/기술들을 도입하여 개선의 노력을 게을리하지 않고 있습니다.
서비스의 안정성을 높이기 위해서는 아시다시피 여러 가지 방법들이 있습니다. 장애를 방지하기 위해 인프라 측면에서 HA 구성을 한다든지, 혹은 워크로드가 한 곳으로 집중되는 것을 막기 위해 적절한 Load Balancing을 합니다. 버그를 최소화하기 위해서는 Code Inspection Tool을 돌린다거나 혹은 Peer code review와 같은 프로세스적인 접근을 취하기도 합니다.
본 글에서는 이러한 여러 가지 방법 중에서 우리가 안정적인 서비스 운영을 위해 일상적으로 가장 많이 수행하는 활동, 즉 애플리케이션 모니터링 관점에서 이야기를 풀어보고자 합니다.
1. Pain points
드라마앤컴퍼니(이하 드라마) 개발팀도 여느 스타트업과 마찬가지로 개발할 기능은 많고, 시간은 없고, 인력은 부족한 상황에 늘 쫓기고 있었습니다. 그래서 아무리 QA을 열심히 한다해도 앱을 배포하고 나면 늘 이런저런 버그와 문제에 부딪치곤 했습니다. 하지만 모니터링 시스템이 제대로 갖춰져 있지 않다보니 고객의 클레임이 들어와도 사실상 이슈의 원인을 제대로 추적하지 못한 적이 한 두번이 아니었습니다. 그래서 이런 점을 해결하고자 APM(Application Performance Management 혹은 Monitoring)과 Centralized Logging 시스템을 구축하기로 결정하였습니다.
2. Application Performance Management
APM하면 가장 먼저 Jennifer같은 솔루션이 떠오릅니다. 하지만 저희도 최대한 비용을 아껴야 하기에 이런 패키지 솔루션은 배제해 놓고 조사를 시작했습니다. 다행히 요새는 개발과 관련된 SaaS 서비스들이 너무나도 잘 나와있어서 저렴한 비용으로 도입할 수 있는 시대가 되었습니다. APM 분야에서는 AppDynamics나 NewRelic 등 여러 벤더들이 서비스를 제공하고 있더군요. 그런데 리멤버의 Backend 시스템은 Rails로 되어 있어서 사실상 NewRelic 외에는 선택의 여지가 거의 없었습니다.(조사해 본 곳 중에 자바, C# 등의 언어를 지원하는 솔루션은 많은데 Rails는 NewRelic 밖에 없었습니다. 혹시 Rails를 지원하는 다른 APM 솔루션이 있다면 제보 부탁 드립니다.)
그래서 저희는 NewRelic을 도입하기로 하였습니다. 설치도 에이전트 gem만 다운로드하여 번들해주기만 하면 되기 때문에 무척 손쉬웠습니다. 그리고 지금까지 운영해 본 결과 NewRelic의 풍부하고 유용한 기능들에 상당히 만족하고 있습니다. NewRelic에서 제공하는 기능들 중 가장 기본적이면서 유용한 몇 가지만 소개드리고자 합니다.
A. Transaction Response Time Monitoring
APM의 아주 기본적인 기능입니다. NewRelic은 아래 그림과 같이 각 컴포넌트/시스템별로 쪼개서 트랜잭션 수행 시 걸린 시간을 측정합니다.
리멤버 서버 애플리케이션의 경우 모니터링 대상이 되는 컴포넌트들은 아래와 같습니다.
- Middleware: Rails에서 HTTP 요청을 parsing하여 해당 Controller로 라우팅하는 등 Application 코드가 아닌 Rails 자체에서 요청 처리에 걸린 시간
- Ruby: 개발자가 개발한 애플리케이션에서 걸린 시간
- ActiveRecord: ActiveRecord 모델에서 데이터베이스에 쿼리를 전달하고 응답을 받기까지 걸린 시간
- Redis: Redis에 접속하여 명령을 전달하고 응답을 받기까지 걸린 시간
- Web external: 구글, 네이버, 페이스북 등 외부 API를 호출하여 응답을 받기까지 걸린 시간
위 그림에서는 오후 2:30분부터 3시까지 ActiveRecord에서 시간이 오래 걸린 것을 볼 수 있습니다. 따라서 이 때 DB에 뭔가 이슈가 있었는지 확인을 해볼 필요가 있습니다.
Apdex는 시스템의 전반적인 상태를 나타냅니다. 평균 응답 시간의 threshold(App Server 기본값은 0.5초, Browser는 7초)를 설정하여 특정 시간 동안 이 값을 만족시키지 못하면 alert를 발생시키게 됩니다. Apdex는 순수하게 서버에서 요청을 처리한 시간과 사용자의 브라우저 입장에서 걸린 시간 두 가지를 나누어 보여줍니다.
Throughput은 분당 유입되는 요청의 수를 나타냅니다. 따라서, 서버에 어떤 이슈가 발생했을 때 순전히 요청량이 많아져서인지, 아니면 요청량은 변화가 없는데 서버 내부의 문제 때문인지 쉽게 파악할 수 있습니다.
B. Transaction Traces
이것도 APM에서 제공하는 기본 기능입니다. 각 트랜잭션에서 메소드별로 처리 시간을 쪼개 보여줍니다. 따라서 어느 메소드에서 시간이 가장 오래 걸렸는지 쉽게 파악할 수 있고 이를 토대로 애플리케이션 혹은 DB 쿼리 튜닝을 할 수 있습니다. 아마 많은 분들이 익숙하신 기능이라 생각됩니다.
C. Error Traces
에러 추적을 위한 강력한 기능입니다. 아래와 같이 애플리케이션 내에서 예외가 발생하면 트랜잭션의 여러 가지 속성(요청한 사용자 ID, 요청 시간 등)과 함께 스택 트레이스를 보여줍니다.
위 에러는 리멤버 앱에서 저장한 명함을 구글 주소록에 동기화할 때 발생한 에러입니다. 구글 주소록 API는 단시간에 너무 많은 요청이 일어나면 위와 같이 UserRateLimitExceeded와 같은 에러를 리턴하는데 이는 개발이나 테스트 환경에서 일어나기 무척 힘든 에러입니다. APM이 없었다면 아마 발견할 수 없었을 것이고 고객 클레임이 들어왔을 것이 분명합니다. 그러나 꾸준한 모니터링을 통해 위 에러를 발견하고 적절히 수정하여 고객 만족도를 더욱 높일 수 있었습니다.
D. Others
NewRelic은 제 경험상 기능에 대한 업데이트가 빠른 편입니다. 얼마 전에는 NewRelic Insight 모듈(애플리케이션에서 발생하는 이벤트를 분석해주는 도구)을 이용하여 에러를 분석해주는 Error analytics 기능을 추가하였습니다.
물론 단점도 있습니다. 빠르게 업데이트되다 보니 버그도 간혹 생깁니다. 실제로 위의 Error analytics가 추가되고 나서, Background job에서 발생하는 에러가 NewRelic에 잡히지 않는 버그가 있었습니다. 하지만 그에 대한 대응도 빠르게 해주는 편입니다. (버그 리포팅을 했더니 친절하게 응대해주고, 1주일만에 버그 fix한 에이전트를 릴리즈해주었습니다. 이 정도면 괜찮지 않은가요?^^)
3. Conclusion
APM 솔루션을 적절히 사용하고, 이를 바탕으로 일상적인 모니터링 활동을 수행한다면 장애의 징후를 미리 알 수 있고, 인지하지 못했던 버그들도 쉽게 파악하여 사용자 경험을 개선시킬 수 있습니다. 또 각 컴포넌트/메소드 별 처리시간을 분석하고 꾸준히 성능을 튜닝하여 안정적인 시스템을 구축할 수 있습니다.
NewRelic은 위에서 소개한 기능들 외에도 호스트 서버에 대한 모니터링, 분석 및 리포팅, Thread Profiling, 모바일 앱에 대한 APM, 이벤트 분석 등 다양한 기능들을 제공합니다. 자세한 내용은 아래 참고 링크를 참조하시면 되겠습니다.
다음 편에서는 APM과 함께 모니터링에 절대로 빠져서는 안 될 Centralised Logging에 대해 이야기해보도록 하겠습니다.
감사합니다. 스타트업 개발자 분들에게 많은 도움이 될 것 같습니다!
정말 재밌게 잘 읽었습니다. good!
잘 읽었습니당:p
Scout 도 혹시 사용해보셨는지요
아쉽게도 scout는 사용해본 적은 없습니다.^^
앱 개발 배우는 단계의 개발자입니다. 기술 블로그에서 제가 모르는 부분 배워갑니다!