Troubleshooting in seconds / Epsagon 를 소개합니다! #Epsagon

분산트레이싱 SaaS 솔루션인 Epsagon 에 대해 소개합니다.
2020.05.19

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

안녕하세요! 클래스메소드 주식회사 의 김태우입니다.

최근에 제가 Epsagon 이라는 서비스에 대해 이야기할 기회가 많아져서, 오늘은 제가 한두달 전에 작성해 두었던 아래의 일본어 블로그를 한국어로 번역해서 포스팅해보려고합니다!

Epsagon 이란?

Epsagon은 Observability(가관측성)을 확보하여 마이크로서비스 아키텍쳐의 트러블슈팅을 수 초만에 해결할 수 있도록 도와주는 분산 트레이싱 모니터링 서비스입니다.

위의 그림에서 Service Map 을 보면 AWS X-Ray 와 비슷한 모양을 하고 있는 것을 볼 수 있는데요, 이 때문에 AWS X-Ray 와 어떤점이 차별화되는지 알기 어려울 지도 모르겠습니다. 하지만, 개인적으로 Epsagon 은 AWS X-Ray 보다도 훨씬 편리한 서비스라고 생각합니다.

본 포스팅에서는 AWS X-Ray 보다 어떤점에서 Epsagon 이 편리하다고 느꼈는지를 정리해보겠습니다.

(참고로 Jaeger 또는 Zipkin 이라는 거의 비슷한 용도로 활용되는 오픈소스 프로젝트도 있지만, SaaS 형태로 제공되는 Epsagon 과는 그 성격이 다르기에 본 포스팅에서는 SaaS 라고 볼 수 있는 AWS X-Ray 와 Epsagon 를 주로 비교합니다)

1. AWS X-Ray 보다 업데이트가 빠르다

예를 들어, Epsagon 은 AWS AppSync 을 가장 빨리 서포트하기 시작한 서비스 로 알려져 있습니다. 본 블로그를 작성하는 시점에서 AWS 는 아직 서포트하지 않는 AWS Step Functions 나 Amazon Kinesis 도 서포트 하고 있습니다.

AWS X-Ray 가 서포트하고 있는 모든 AWS 서비스 리스트는 아래의 페이지를 참고해주세요 :)

AWS X-Ray를 다른 AWS 서비스와 통합

2. 아무것도 설정하지 않아도 디폴트인채로 Service Map 에 보여지는 서비스가 많다

Auto-Tracing 이라고 하는 기능이 있어서, 코드 내부에 몇줄 정도를 적어서 디플로이 해야하는 X-Ray 와는 달리, AWS Integration 용으로 IAM Role 을 CloudFormation 을 통해 작성하는 것만으로도 Service Map 에 표시되는 서비스가 대다수입니다. 이 말은 즉슨, 이미 기존 상용 서비스로 운영중인 서비스라고 할 지라도, 5~10분만에 서비스 전체의 Observability 를 확보할 수 있다는 뜻이기도 합니다.

Step Functions 등의 일부 비동기 서비스의 트레이싱을 위해서는 코드 몇줄을 추가할 필요가 있긴 하지만, 이러한 특수한 경우를 제외하고는 기본적으로 있는 그대로 Service Map 에 표시됩니다.

주의사항
  • Step Functions 에 의해 동작하는 컴퓨팅 서비스를 표시할 지 안 할 지의 구분을 위한 코드이므로, 일단 Service Map 에 표시는 다 됩니다
  • 또한, Step Functions 의 경우, Parallel 은 지원하지 않으므로, Step Functions 의 모든 기능이 지원되는 것은 아닌것에 주의해주세요

3. 주관적이긴 하지만 AWS X-Ray 에 비해 사용하기 편하다

다소 주관적인 생각이지만, AWS X-Ray 에 비해 Epsagon 이 특히 편하고 쉽다고 생각한 기능이 바로 로그를 확인하는 부분입니다. 트러블 슈팅을 위해 결국 "어떤 로그를 확인해야하는가" "어느시점의 로그를 확인해야하는가" 등의 좀 더 거시적인 관점에서의 필터링은 Service Map 을 보면서 진행하고, "구체적으로 어떤 문제인가" 등을 확인하기 위해 로그를 확인하게 되는데, 이 때, Epsagon 의 경우 Service Map 과 동일한 화면에서 즉시 로그를 확인할 수 있어서 매우 신속하고 편리하다고 느꼈습니다.

즉, Epsagon 의 경우 모든 트러블슈팅 플로우가 Service Map 에서 시작하여, 아래와 같은 상세화면도 확인할 수 있지만

여기서 로그까지도 즉시, 쉽게 확인할 수 있다는 점이 굉장히 직관적이고 편리했습니다.

또한, 아래의 그림과 같이 다양한 관점에서의 기능이 이미 준비되어 있어서, 다양한 관점에서의 분석을 통한 빠른 트러블슈팅도 가능하게 해줍니다.

4. AWS 이외의 서비스도 (많이) 서포트 하고 있다

애초에 서버리스 아키텍쳐의 경우 서드파티 SaaS 서비스 등에 의존하는 경우가 많은데요, 이런 경우에는 AWS 가 아닌 다른 서비스를 사용하는 경우도 흔한 패턴입니다. 예를 들어, 유저 인증을 위해 Cognito 가 아닌 Auth0 를 사용하는 식이죠. 그런 경우에는 AWS X-Ray 에서는 확인할 수 없는 트레이스가 Epsagon 에서는 같은 패턴으로 쉽게 확인하실 수가 있습니다. 물론, 하이브리드 클라우드, 멀티 클라우드 같은 경우에도 바로 사용할 수 있는 서비스인만큼 Epsagon 의 확장성은 매우 뛰어나다고 할 수 있습니다. 이것이 가능한 이유는 Epsagon 은 에이전트 설치 없이 동작하는 (Agentless) 서비스이기 때문입니다.

Epsagon 의 외부활동

Epsagon 블로그

Epsagon 에서는 기술블로그를 운영하고 있습니다. 모니터링이나 분산 트레이싱과 관련된 훌륭한 포스팅이 많이 작성되어 있어서 이것들만 쭉 읽어봐도 굉장히 큰 공부가 됩니다. Epsagon 이 아닌 다른 서비스에 대해서도 설명하고 있는 포스팅도 많으므로 관심이 있으신 분들은 꼭 읽어보시면 도움이 될 것 같습니다.

Epsagon Webinar

Epsagon은 정기적으로 Webinar 도 개최하고 있습니다. 저도 몇번정도 참여한 적이 있는데요, 굉장히 유익했습니다! CTO 인 Ran Ribenzaft 는 AWS Serverless Hero 이기도 합니다.

사용요금

연간 플랜

월간 플랜

Epsagon 은 연간플랜과 월간플랜의 두가지 종류의 플랜을 제공하고 있습니다. 이 두가지 플랜 안에서도 월간 트레이싱 수에 따라 요금이 다르게 책정됩니다.

  • 100만 트레이싱까지의 플랜은 연간 플랜의 경우「$99/月」、월간의 경우「$116/月」
  • 500만 트레이싱까지의 플랜은 연간 플랜의 경우「249/月」、월간의 경우「$292/月」
  • 1000만 트레이싱까지의 플랜은 연간 플랜의 경우「449/月」、월간의 경우「$528/月」

무료 체험 플랜도 있어서, 월 10만 트레이싱까지는 계속해서 무료로 이용가능합니다.

... 라고는 하지만, 솔직히 좀 비싸다고 생각이 들지도 모르겠습니다.

하지만, Epsagon 이 제공해주는 Observability 를 확보할 수 있게된 경우에 줄일 수 있는 비용에 대해 생각해보면 그다지 비싸지 않은 금액이 아니라, 오히려 싸다고 느껴질 수도 있습니다. Epsagon 을 통해 Observability 가 확보된다면, Observability 가 확보되지 않았을 때와 비교했을때 어떤 메리트가 있을까요?

바로 고급 엔지니어들의 "시간" 이라는 굉장히 비싼 리소스(비용)를 획기적으로 줄일 수 있게 됩니다.

애초에 Epsagon 의 도입이 필요할 정도로 복잡한 MSA 를 구성할 정도의 팀, 엔지니어라면 상당히 실력있는 엔지니어임에 틀림없습니다. (그렇죠?ㅎㅎ)

그러한 연봉이 높은 실력있는 엔지니어를 여러명 고용했지만, Observability 가 확보되지 않아서 간단한 문제처럼 보이는 트러블슈팅에 시간을 몇시간 ~ 몇일 가량을 소요하게 된다면 굉장히 낭비일 수 밖에 없습니다. 이 때, Epsagon 을 도입함으로서 트러블슈팅을 통한 루트 원인을 파악하는데까지 평균 수 초대로 줄어들게 됩니다.

또한, 서비스를 운영하면서 이슈는 언제나 발생하는 법이므로 이슈가 발생하면 빠르게 해결할 수 있는 능력이 비즈니스의 성장에도 굉장히 중요한 요인이 될 것임을 쉽게 유추할 수 있습니다.

이러한 관점에서 볼 때 저는 Epsagon 의 가격은 굉장히 합리적이라고 생각했습니다.

본 글을 맺으며

마이크로서비스 혹은 서버리스 기술에 굉장히 흥미가 깊은 저로서는, 마이크로서비스나 서버리스로 개발된 서비스를 어떻게 효율적으로 운영해 나갈 수 있을까에 대해 고민하는 시간이 많습니다. 이렇게 고민하다보면, 본질적으로 가장 첫번째로 확보되어야하는 것이 Observability(가관측성) 이라고 생각하였습니다. 이것이 뒷받침되지 않으면 트러블슈팅은 커녕 서비스가 어떻게 돌아가고 있는지조차 파악하기가 굉장히 어려워지기 때문입니다. 하지만, 전통적인 방법론인 메트릭 수집 및 로그 분석 등의 어프로치로는 Observability 의 확보가 어려웠습니다.

이 때, 분산 트레이싱 솔루션을 활용하면 어느정도의 Observability 의 확보는 가능하지만, 그 중에서도 Epsagon 이라는 SaaS 서비스를 도입하면 트러블슈팅까지도 굉장히 효율적이고 빠르게 가능하다는 것을 많은 분들에게 알리고 싶었습니다. (요즘 한창 화두가 되고 있는 DevOps 에 필수적인 서비스죠)

본 포스팅을 읽으시면서 혹시 Epsagon 이 재밌어 보인다고 느끼시지 않았나요?ㅎㅎ Epsagon 에는 Playground 도 준비되어 있으니 이것저것 살펴보시면 좋을것 같습니다.

그럼, 본 포스팅은 여기서 마치도록 하겠습니다. 컨설팅부의 김태우(@twkiiim)였습니다! :D