LINE DEVELOPER DAY 2020에서 복다훈 님이 발표하신 Story that built Sentry as an On-Premise 세션 내용을 옮긴 글입니다.

안녕하세요. LINE Plus UIT 팀 복다훈입니다. 이번 글에서는 Sentry 온 프레미스(On-Premise) 구축기를 공유하겠습니다. LINE에서 왜 Sentry를 사용하게 됐는지 먼저 말씀드리고 클라우드 대신 온 프레미스 방식으로 구축하게 된 이유를 설명한 뒤 마지막으로 어떻게 구축했는지 말씀드리겠습니다.

기존 에러 로그 수집 플랫폼의 문제점

기존에 사용하던 에러 로그 수집 플랫폼은 프런트엔드에 친화적이지 않았습니다. 아래 예시 화면을 보시겠습니다.

위 화면에 보이는 에러는 undefined 값에서 'featureID'라는 프로퍼티에 접근해서 발생한 에러입니다. 릴리스 환경에서는 소스 코드를 압축하고 난독화하기 때문에 정확히 소스의 어느 부분에서 에러가 발생했는지 쉽게 찾을 수 없었습니다. 이런 문제를 해결하기 위해 프런트엔드에서 유용하게 사용할 수 있는 Sentry라는 플랫폼을 찾게 되었습니다.

Sentry 도입

Sentry의 장점에는 여러 가지가 있지만 그중 대표적으로 두 가지를 꼽을 수 있습니다. 먼저 소스 맵과 연동해서 릴리스 환경에서도 아래 오른쪽 그림처럼 소스 코드의 어느 위치에서 에러가 발생했는지 상세하게 파악할 수 있다는 점입니다.

두 번째로 Breadcrumbs 기능을 제공합니다. 이 기능을 이용하면 UI 클릭이나 AJAX 요청과 같이 사용자가 무슨 활동을 하다가 에러가 발생했는지 파악할 수 있습니다. 이런 장점 덕분에 사용자가 불편한 부분을 개선해 달라고 요청했을 때 손쉽게 확인하는 것은 물론, 더 나아가서 버그를 미리 찾아 개선할 수도 있었습니다. 이에 저희는 Sentry를 사용하기로 결정했습니다.

온 프레미스를 선택한 이유

이제 왜 Sentry '온 프레미스'를 선택했는지 말씀드리겠습니다. Sentry는 크게 구독형인 클라우드 버전과 설치형인 온 프레미스 버전으로 나뉩니다.

클라우드 버전은 인프라와 솔루션을 한 번에 제공하기 때문에 개발자들이 편하게 사용할 수 있으며 유지 보수 및 운영에 신경 쓰지 않아도 된다는 장점이 있는데요. 그럼에도 저희가 온 프레미스 방식을 사용하게 된 이유는 다음과 같습니다.

정보 유출 방지

먼저 프로젝트와 관련된 민감한 정보가 외부로 유출되는 것을 막을 수 있습니다. Sentry는 손쉽게 코드를 확인하기 위해서 소스 맵을 서버에 업로드해야 합니다. 이때 클라우드를 사용하면 회사 내부의 코드가 외부로 노출될 수 있는 위험이 있습니다. 또한 DB 접속 암호와 같은 중요한 암호와 알고리즘의 암호화키 혹은 개발자가 예상하지 못한 보안 취약점이 노출될 가능성도 있습니다. 하지만 온 프레미스 버전을 선택하면 내부 인프라를 이용해서 소스 코드 및 기업 자산을 관리하기 때문에 클라우드 버전보다 더 안전하게 사용할 수 있습니다.

비용 절감

클라우드를 사용하면 사용량에 따라 금액을 지불해야 합니다. 아래 그림은 Sentry의 요금표입니다.

위 금액에는 인프라와 운영, 유지 보수 등의 금액이 포함되어 있습니다. 또한 플랜에 따라 지불해야 하는 금액도 달라지는데요. 'Team'이나 'Business'로 갈수록 비싸집니다. 심지어 'Enterprise'는 가격이 나와 있지 않아서 별도로 계약해야만 사용할 수 있습니다. 하지만 온 프레미스로 사용하면 별도의 비용 추가 없이 인프라만 구축하면 되기 때문에 비용을 훨씬 절감할 수 있습니다.

구축 방법

다음으로 Sentry 온 프레미스를 어떻게 구축했는지 설명하겠습니다. LINE에서는 Sentry 온 프레미스를 4단계로 나눠 구축했습니다. 먼저 기존 인프라 구조를 검토하고 문제점을 파악해서 더 나은 방향으로 개선했습니다. 그다음 성능을 측정해서 필요한 각 장비의 사양과 개수를 산정한 뒤 이 데이터를 기반으로 인프라를 구축했고, 마지막으로 각 장비들의 이상 여부를 확인하기 위해 모니터링 시스템을 추가했습니다.

각 단계를 좀 더 자세히 살펴보겠습니다.

기존 인프라 검토 및 구조 개선

먼저 기존 인프라 구조를 검토했습니다. 아래 그림과 같이 기존 구조는 Docker 이미지 안에 웹과 워커, 컨테이너가 함께 있었습니다.

위와 같이 컨테이너가 함께 붙어 있으면 스케일아웃은 불가능하고 스케일업만 가능하기 때문에 예상했던 요청량을 초과했을 때 발 빠르게 대응하기가 쉽지 않았습니다. 이를 해결하기 위해 아래 그림과 같이 각 컨테이너를 분류하고 스케일아웃이 가능한 새로운 구조로 변경했습니다.

다만 이때도 DB는 스케일업만 고려해 설계했는데요. 그 이유를 말씀드리겠습니다. Sentry는 DB로 PostgreSQL을 사용하고 있습니다. PostgreSQL 오픈 소스에서는 샤딩(sharding) 기능을 제공하지 않아 수평 확장이 불가능합니다. 별도 익스텐션을 사용하면 샤딩을 이용할 수 있긴 하지만 추가 비용을 지불해야 하고 안정성도 검증해야 하기 때문에 이용하기 쉽지 않았습니다. 이에 DB는 스케일업만을 고려했고 장애에 대비하기 위해 마스터, 슬레이브 구조로 레플리케이션을 구성했습니다. Nginx와 웹과 워커는 더 많은 요청을 수용할 수 있도록 스케일아웃이 가능한 형태로 구조를 변경했습니다.

성능 측정 및 인프라 개선

이제 요청량에 맞게 각 장비의 개수를 증가시키거나 감소시키면 되는데요. 다음과 같은 고민이 생겼습니다. '추후 트래픽이 증가하면 서버 사양을 어떻게 업그레이드하지?' 이 질문의 답을 찾기 위해 Sentry 인프라 구조에서 각 노드의 성능을 측정했습니다. 성능 측정 도구는 사내에서 개발해 오픈 소스로 제공하고 있는 nGrinder를 사용했습니다. 이를 이용해서 각 장비의 수용 가능한 TPS(Transaction Per Second)를 확인했습니다.

성능을 측정하려면 측정할 대상을 정해야 했는데요. 이를 위해 Sentry의 시퀀스 다이어그램을 그려서 이벤트가 들어왔을 때의 프로세스를 확인했습니다. 

Redis는 사내 인프라에서 제공하는 것을 사용했기 때문에 성능 측정 구간에서 제외하고 웹과 워커, DB를 성능 측정 대상으로 정했습니다.

성능을 측정할 때 웹과 DB와 워커를 다른 방법으로 측정했습니다. 웹과 DB는 가상의 사용자 수를 점차 증가시켜서 요청량이 늘어날 때 CPU 사용량과 부하 평균을 측정하고, CPU 코어 수도 함께 늘려 코어 수와 TPS의 관계를 살펴봤습니다. 워커는 TPS와 CPU 코어 수를 변경해서 이벤트 큐에 잡이 쌓이기 시작하는 시점의 TPS를 확인했습니다. 그 결과 아래와 같은 차트를 구축할 수 있었습니다. 보시는 바와 같이 8코어 CPU부터 기울기가 급격하게 증가했습니다.

8코어 CPU부터는 웹과 워커, DB 모두 거의 선형적으로 증가했습니다. 이에 노드의 CPU 코어 개수는 8개로 정했고 스케일아웃할 때 이 노드의 개수를 증감시키는 방식으로 스케일아웃하기로 결정했습니다.

이렇게 성능 분석한 데이터를 토대로 인프라 구조를 개선했습니다. 앞에서 얻은 정보를 활용해 목표 TPS에 맞는 Nginx와 웹, 워커의 성능과 개수를 정했고 DB 노드 성능을 산정해서 이를 적용했습니다.

이후 Sentry로 전송되는 이벤트 유입량이 변동될 때 이 데이터를 이용해 대응하고 있습니다.

모니터링 시스템 구축

마지막으로 모니터링 시스템을 구축했습니다. 클라우드 버전의 단점 중 하나는 인프라 구조를 외부에서 관리하기 때문에 장비의 상태를 파악하기 힘들다는 점이었습니다. 온 프레미스 버전을 사용하면 개발자의 입맛에 맞는 모니터링 도구를 선택해서 사용할 수 있는데요. Grafana와 Prometheus를 활용해서 모니터링 시스템을 구축했습니다.

CPU와 메모리 사용량, 디스크 사용량 등 하드웨어 상태 지표를 추가했고 이를 시각화해서 지속적으로 모니터링했습니다. 또한 요청 및 응답 상태를 관찰하며 이상 징후를 탐지해 LINE으로 경고 알림을 전송하도록 설정했습니다. 덕분에 장애를 미리 예방하는 효과도 거두고 있습니다.

마치며

마지막으로 다시 한 번 정리해 보겠습니다. Sentry 온 프레미스 버전은 클라우드 버전과 비교해 몇 가지 장점이 있었습니다. 우선 소스 맵이나 다른 자원을 외부로 업로드하지 않기 때문에 클라우드 버전보다 더 안전합니다. 또한 초기 구축 비용을 제외하면 인프라 유지 비용만 발생하기 때문에 비용도 절감할 수 있으며, 마지막으로 인프라 구조의 내부 상태를 확인할 수 있어 가시성을 확보할 수 있습니다.

이러한 장점들 때문에 LINE에서는 Sentry를 온 프레미스 버전으로 구축했고 현재까지 총 34개의 프로젝트에서 사용하고 있습니다. 에러 로그 수집 플랫폼 구축을 고려하고 계시다면 저희의 사례를 참고해 보시는 것도 좋을 것 같습니다. 아래에서 발표 영상도 확인하실 수 있습니다. 이상으로 글을 마치겠습니다.