시작하며
안녕하세요. Service Reliability 팀에서 SRE(site reliability engineer)로 일하고 있는 천기철입니다. SRE 팀은 사용자에게 안정적이고 신뢰할 수 있는 서비스를 제공하기 위해 끊임없이 노력하고 있습니다. 구체적으로 말씀드리면 SLI(service level indicator)/SLO(service level objective)를 이용해 LINE 메시징 코어 서비스의 품질과 신뢰성을 평가하고 있으며, 수요 예측과 성능 테스트, 자동화, 관찰가능성(observability) 강화 등 다양한 분야를 엔지니어링하기 위한 노력을 기울이고 있습니다. 또한 각 팀이 서로 원활하게 소통하고 협업할 수 있도록 돕는 역할도 담당하고 있습니다.
이번 글은 신뢰성 향상을 위한 SLI/SLO 도입 1편 - 소개와 필요성과 신뢰성 향상을 위한 SLI/SLO 도입 2편 - 플랫폼 적용 사례에 이어서 LINE 앱의 메시지, 채널, 인증 서비스에서 SLI/SLO를 정의해 적용한 후기를 공유해 보려고 합니다.
SLI/SLO를 구현하기 위한 마인드셋
SLI/SLO는 단순히 지표를 정하는 수준을 넘어 ‘서비스를 어떤 관점으로 이해할 것인가’를 다시 정의하는 과정에 가깝습니다. SLI/SLO를 도입하면서 이와 같은 과정을 성공적으로 수행하기 위해 갖춰야 할 마인드셋을 살펴보겠습니다.
서비스 이해 및 탐구
SLI/SLO를 구현하기 위해서 가장 먼저 해야 할 일은 사용자에게 어떤 서비스와 기능을 제공하고 있는지 식별하는 것입니다. 이 과정에서 사용자가 서비스를 이용할 때 겪는 경험의 흐름인 '사용자 여정(user journey)' 목록을 만들 수 있고, '사용자가 어떤 서비스를 많이 이용하는지' 또는 '반드시 필요한 기능은 무엇인지' 등 사용자에게 제공하는 핵심 서비스와 기능을 정의해 '핵심 사용자 여정(critical user journey, 이하 CUJ)'을 식별할 수 있습니다. 또한 이 과정을 통해 서비스가 조직의 비즈니스 목표와 어떻게 연관돼 있는지 이해함으로써 SLO를 조직의 목표와 일치시킬 수 있습니다.
커뮤니케이션 및 협업
SLI/SLO는 다양한 부서와 팀이 함께 협력해 구현하고 관리해야 하는 지표이자 목표입니다. 개인이나 특정 팀에서 정의하고 구현하는 것이 아니라 모든 이해관계자가 함께 목표를 세우고 동의해야 비로소 가치가 생깁니다. 서비스를 가장 잘 이해하고 있는 담당 조직에서 CUJ를 정의해야 하며, 인프라 조직에서는 대규모 지표를 측정하고 관리할 수 있는 인프라 환경을 구현해야 합니다. SRE는 SLI/SLO를 측정할 수 있는 방법 및 도구를 구현해서 SLO를 통해서 서비스의 안정성과 신뢰성을 모니터링하고 관리하는 역할을 담당합니다.
각 조직에서 수행하는 역할을 정리하면 다음과 같습니다.
모든 서비스 관계자가 SLI/SLO의 중요성을 이해한 뒤 이를 달성하기 위한 책임을 나눠 갖는 문화를 조성하는 것이 중요합니다. 그래야만 서비스 운영 과정에서 혹은 신규 서비스나 기능을 출시할 때 사용자가 안정적으로 서비스를 이용하고 있는지 확인하는 지표로써 SLO 를 활용할 수 있습니다.
SLI/SLO 구현 방법
그렇다면 실제로 SLI/SLO를 어떤 단계를 거쳐 구현하는지 살펴보겠습니다.
CUJ 분석
첫 단계는 사용자 경험과 비즈니스 목표를 고려한 핵심 서비스와 기능인 CUJ를 정의하는 것입니다.
사용자에게 제공하고 있는 서비스와 기능을 목록으로 만든 뒤 스스로 아래와 같은 질문을 던지면 CUJ를 구체화할 수 있습니다.
- 사용자가 우리 서비스에서 가장 많이 사용하는 기능은 무엇인지?
- 사용자에게 반드시 제공해야 하는 기능은 무엇인지?
예를 들어 아래 그림과 같이 LINE 앱 서비스의 시작점인 LINE 서비스 가입 기능이나 가장 기본이라고 할 수 있는 메시지를 주고받는 기능 등의 핵심 기능을 정의합니다. 이 외에도 사용자 인증과 암호화와 같은 보안 관점에서 주요한 기능이나 LINE Login이나 프로필 정보 등 LINE 서비스를 활용해 다른 서비스를 이용할 수 있게 해 주는 서비스와 기능도 대상이 될 수 있을 것입니다.
Critical User Journey (CUJ)
Focus on selecting key features and services. Consideration user experience and business objectives
당연히 모든 서비스와 기능이 다 중요하고 모두 안정적으로 제공해야 하겠지만, 이 단계에서 핵심은 그중에서도 가장 핵심 대상만 선별하는 것이며, 이때 중요한 것은 사용자 관점에서 정의해야 한다는 것입니다.
SLI 구현
CUJ를 정의한 다음에는 SLI를 정의합니다.
SLI는 CUJ별로 어떤 지표를 설정하고 측정할 것인지 정의하는 것입니다.
- 어떤 위치에서 측정할 것인가?
- 게이트웨에나 프런트엔드, 백엔드 등 각 CUJ별로 보다 정확하게 측정할 수 있는 위치를 선정합니다.
- 어떤 API를 통해서 측정할 것인가?
- 지표를 복잡하게 계산할 필요가 없도록 각 CUJ별로 대표적인 API를 선정합니다.
다음으로 성공과 실패를 가르는 기준값(SLI criterion)을 정의합니다. 일반적으로 응답 시간과 응답 성공률, 크게 두 가지로 측정하며 각 기준값은 다음과 같이 정의합니다.
- 응답 시간: 전체 요청에 대한 응답 시간의 몇 퍼센타일을 기준으로 삼을 것인지, 그 기준 응답 시간이 얼마 이내여야 성공으로 간주할 것인지 정의합니다.
- 응답 성공률: 측정 시간동안 응답 성공률이 얼마여야 하는지 정의합니다.
예를 들어 '메시지 전송 기능은 99.9 퍼센타일의 요청에 대한 응답 시간을 500ms 미만으로, 전체 요청의 99.999%가 성공 응답을 받는 서비스를 제공하겠다'와 같이 정의합니다.
이 단계의 핵심은 측정 위치와 대상, 성공과 실패를 구분하는 명확한 기준을 정의하는 것입니다. 특히 성공과 실패를 구분하는 기준을 명확하게 정의해야 SLO 달성 여부를 측정할 수 있습니다. 만약 변수가 많아 측정이 불가하거나 성공과 실패를 나누는 기준을 명확하게 정의할 수 없다면 해당 CUJ는 측정에서 제외하는 것도 가능합니다. 측정하기 복잡한 경우에는 SLI를 위한 별도 지표를 만드는 것을 권고합니다.
SLO 타깃 설정
SLI를 정의한 뒤에는 SLO를 정의합니다.
이 단계에서는 '측정하는 기간 동안 SLI 기준에 맞는 신뢰성과 안정성이 보장된 서비스를 제공하겠다'라는 목표를 정의합니다. 예를 들어 아래와 같이 '28일 동안 99.9%, 즉 총 40,320분 중 40,280분 동안 SLI에 정의한 응답 시간과 응답 성공률을 달성하겠다'와 같이 정의합니다.
SLO(Service Level Objective)
The objectives or specific ranges that the service needs to achieve, based on the measured SLIs
이 단계의 핵심은 실제로 지킬 수 있는 현실적인 목표를 설정하는 것입니다. SLO를 너무 높게 설정하면 이를 달성하기 위해 그만큼의 비용을 추가해야 하고, 반면 너무 낮게 설정하면 서비스 질이 낮아져 사용자에게 좋지 않은 경험을 제공할 수 있습니다. 따라서 안정성과 비용 양쪽을 적절히 고려해 설정해야 합니다.
시각화
마지막으로 서비스와 관련된 모든 이해관계자가 현재 SLO 상태를 쉽게 확인할 수 있도록 앞서 정의한 SLI/SLO를 시각화한 대시보드를 구현합니다.
아래 예시와 같이 SLO와 오류 예산(error budget)을 요약해서 볼 수 있는 대시보드를 구현하면 현재 SLO의 전체적인 상태를 한눈에 확인할 수 있습니다. 여기에 각 CUJ별 상세 대시보드까지 구현해 놓으면 보다 상세하게 SLI 지표를 확인할 수 있습니다.
이 단계의 핵심은 대시보드에 너무 많은 정보를 담기보다는 수치나 색을 이용해 단순화해서 전체 상황을 한눈에 빠르게 파악할 수 있도록 제공하는 것입니다. 예를 들어 목표를 안정적으로 달성하고 있는 지표는 초록색으로, 경고해야 할 항목은 주황색으로, 목표 달성에 실패한 항목은 빨간색으로 표현하면 현재 상황을 쉽고 빠르게 파악할 수 있습니다.
SLI/SLO 활용
이제 SLI/SLO를 어떻게 활용하는지 소개하겠습니다.
신뢰성과 안정성을 정량적으로 파악할 수 있는 지표
서비스의 상태를 표현할 때 '느려졌다' 혹은 '안정적이지 않다'라는 표현 대신 정량적 지표로 정의한 SLI를 이용하면 보다 정확하게 표현할 수 있습니다. 예를 들어 아래와 같은 상황에서는 "서비스의 응답 시간이 SLI 기준인 400ms를 초과하고 있어서 사용자가 불편을 겪고 있다"와 같이 표현할 수 있습니다.
또한 아래와 같은 상황에서는 '우리 서비스의 응답 성공률이 99.99% 미만이고 이에 따라 사용자가 서비스 이용에 불편을 겪고 있다'라고 표현할 수 있습니다. 또한 대시보드를 보며 응답 성공률을 달성하지 못한 시간에 어떤 이슈가 있었는지도 파악할 수 있습니다.
이와 같이 정량적인 수치와 이를 시각화한 대시보드를 이용해 서비스의 상태를 보다 명확하게 모니터링하고 분석할 수 있습니다.
리소스 분배 기준으로 활용
SLO를 통해 현재 목표 달성 여부를 확인할 수 있고 오류 예산으로 현재 허용 가능한 장애 시간을 파악할 수 있습니다. 이는 다시 SLO를 달성하기 위해 필요한 예방 및 대응 활동에 투입해야 할 리소스를 산정하는 기준으로 사용할 수 있습니다.
만약 서비스가 SLO를 만족하고 있고 오류 예산도 넉넉하다면 서비스를 안정적으로 운영하고 있다고 판단하고 신규 기능 출시 등에 보다 공격적으로 리소스를 투입할 수 있습니다. 예를 들어 현재 상황이 다음과 같다면 'SLO 99.9% 목표를 초과해 99.98%를 달성하고 있고, 오류 예산도 80% 이상으로 넉넉하기 때문에 안정적이다'라고 판단할 수 있습니다. 이를 기반으로 새로운 기능을 출시하거나 릴리스 사이클을 당기는 데 리소스를 투입할 수 있습니다.
반면 아래와 같이 오류 예산이 10%만 남아 있다면 SLO를 안정적으로 달성하고 서비스 안정성을 높이는 데 리소스를 투입하기로 결정할 수 있습니다.
온콜 대응 시 활용
현재 각 서비스의 온콜(on-call) 체계에는 오류 예산 상태 변화에 따른 알림을 적용해 서비스 상태를 파악하고 이슈에 대응하는 데 활용하고 있습니다. 또한 정기 미팅에서 SLO 상태를 점검하거나 목표를 달성하기 위해 예방 활동을 진행하는 데에도 활용합니다.
다음은 오류 예산 상태 알림 메시지 예시입니다.
마치며
서비스에서 신뢰성과 안정성은 핵심 가치입니다. 또한 사용자의 편의를 높이고 새로운 기능을 제공하는 것 역시 비즈니스에서 매우 중요한 가치입니다. SLO는 정량적인 지표를 통해서 서비스의 신뢰성과 비즈니스의 목표 사이에서 균형을 잡는 데 도움을 줄 수 있다고 믿습니다.
이 글이 SLI/SLO에 관심 있는 분들과 서비스에 도입하려는 분들에게 도움이 되길 바랍니다. 마지막으로 SRE 역할에 대한 제 견해를 정리한 문구를 공유드리며 이만 마치겠습니다. 긴 글 읽어주셔서 감사합니다.
Core tenets of SRE
Focus on providing stability and reliability to our customers
And strive for continuous improvement and innovation.
