<div id="readability-page-1" class="page"><article><div><h2 id="시작하며">시작하며</h2>
<p>안녕하세요. Service Reliability 팀에서 SRE(site reliability engineer)로 일하고 있는 천기철입니다. SRE 팀은 사용자에게 안정적이고 신뢰할 수 있는 서비스를 제공하기 위해 끊임없이 노력하고 있습니다. 구체적으로 말씀드리면 SLI(service level indicator)/SLO(service level objective)를 이용해 LINE 메시징 코어 서비스의 품질과 신뢰성을 평가하고 있으며, 수요 예측과 성능 테스트, 자동화, 관찰가능성(observability) 강화 등 다양한 분야를 엔지니어링하기 위한 노력을 기울이고 있습니다. 또한 각 팀이 서로 원활하게 소통하고 협업할 수 있도록 돕는 역할도 담당하고 있습니다.</p>
<p>이번 글은 <a href="https://techblog.lycorp.co.jp/ko/sli-and-slo-for-improving-reliability-1" target="_blank">신뢰성 향상을 위한 SLI/SLO 도입 1편 - 소개와 필요성</a>과 <a href="https://techblog.lycorp.co.jp/ko/sli-and-slo-for-improving-reliability-2" target="_blank">신뢰성 향상을 위한 SLI/SLO 도입 2편 - 플랫폼 적용 사례</a>에 이어서 LINE 앱의 메시지, 채널, 인증 서비스에서 SLI/SLO를 정의해 적용한 후기를 공유해 보려고 합니다.</p>

<p>SLI/SLO는 단순히 지표를 정하는 수준을 넘어 ‘서비스를 어떤 관점으로 이해할 것인가’를 다시 정의하는 과정에 가깝습니다. SLI/SLO를 도입하면서 이와 같은 과정을 성공적으로 수행하기 위해 갖춰야 할 마인드셋을 살펴보겠습니다.</p>
<h3 id="서비스 이해 및 탐구">서비스 이해 및 탐구</h3>
<p>SLI/SLO를 구현하기 위해서 가장 먼저 해야 할 일은 사용자에게 어떤 서비스와 기능을 제공하고 있는지 식별하는 것입니다. 이 과정에서 사용자가 서비스를 이용할 때 겪는 경험의 흐름인 '사용자 여정(user journey)' 목록을 만들 수 있고, '사용자가 어떤 서비스를 많이 이용하는지' 또는 '반드시 필요한 기능은 무엇인지' 등 사용자에게 제공하는 핵심 서비스와 기능을 정의해 '핵심 사용자 여정(critical user journey, 이하 CUJ)'을 식별할 수 있습니다. 또한 이 과정을 통해 서비스가 조직의 비즈니스 목표와 어떻게 연관돼 있는지 이해함으로써 SLO를 조직의 목표와 일치시킬 수 있습니다.</p>
<h3 id="커뮤니케이션 및 협업">커뮤니케이션 및 협업</h3>
<p>SLI/SLO는 다양한 부서와 팀이 함께 협력해 구현하고 관리해야 하는 지표이자 목표입니다. 개인이나 특정 팀에서 정의하고 구현하는 것이 아니라 모든 이해관계자가 함께 목표를 세우고 동의해야 비로소 가치가 생깁니다. 서비스를 가장 잘 이해하고 있는 담당 조직에서 CUJ를 정의해야 하며, 인프라 조직에서는 대규모 지표를 측정하고 관리할 수 있는 인프라 환경을 구현해야 합니다. SRE는 SLI/SLO를 측정할 수 있는 방법 및 도구를 구현해서 SLO를 통해서 서비스의 안정성과 신뢰성을 모니터링하고 관리하는 역할을 담당합니다.</p>
<p>각 조직에서 수행하는 역할을 정리하면 다음과 같습니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/87dd3f47701e4e5f8abacffb9304ebb6.png?updatedAt=1776384745000" width="1000" height="auto" alt="각 조직에서 수행하는 역할"></p>
<p>모든 서비스 관계자가 SLI/SLO의 중요성을 이해한 뒤 이를 달성하기 위한 책임을 나눠 갖는 문화를 조성하는 것이 중요합니다. 그래야만 서비스 운영 과정에서 혹은 신규 서비스나 기능을 출시할 때 사용자가 안정적으로 서비스를 이용하고 있는지 확인하는 지표로써 SLO를 활용할 수 있습니다.</p>
<h2 id="SLI/SLO 구현 방법">SLI/SLO 구현 방법</h2>
<p>그렇다면 실제로 SLI/SLO를 어떤 단계를 거쳐 구현하는지 살펴보겠습니다.</p>
<h3 id="CUJ 분석">CUJ 분석</h3>
<p>첫 단계는 사용자 경험과 비즈니스 목표를 고려한 핵심 서비스와 기능인 CUJ를 정의하는 것입니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/1c0c4b1d5e934d8e9fba40d85c2b5699.png?updatedAt=1776384763000" width="1000" height="auto" alt="SLI/SLO 구현 4단계 중 CUJ 분석 단계"></p>
<p>사용자에게 제공하고 있는 서비스와 기능을 목록으로 만든 뒤 스스로 아래와 같은 질문을 던지면 CUJ를 구체화할 수 있습니다.</p>
<ul><li>사용자가 우리 서비스에서 가장 많이 사용하는 기능은 무엇인지?</li><li>사용자에게 반드시 제공해야 하는 기능은 무엇인지?</li></ul>
<p>예를 들어 아래 그림과 같이 LINE 앱 서비스의 시작점인 LINE 서비스 가입 기능이나 가장 기본이라고 할 수 있는 메시지를 주고받는 기능 등의 핵심 기능을 정의합니다. 이 외에도 사용자 인증과 암호화와 같은 보안 관점에서 주요한 기능이나 LINE Login이나 프로필 정보 등 LINE 서비스를 활용해 다른 서비스를 이용할 수 있게 해 주는 서비스와 기능도 대상이 될 수 있을 것입니다.</p>
<p>Critical User Journey (CUJ)<br>Focus on selecting <strong>key features and services</strong>. Consideration <strong>user experience</strong><strong> and business objectives</strong></p>
<p><strong><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/1c088693f3f04c559550e1ae396445f0.png?updatedAt=1776385043000" width="1000" height="auto" alt="LINE 앱 서비스 CUJ"></strong></p>
<p>당연히 모든 서비스와 기능이 다 중요하고 모두 안정적으로 제공해야 하겠지만, 이 단계에서 핵심은 그중에서도 가장 핵심 대상만 선별하는 것이며, 이때 중요한 것은 사용자 관점에서 정의해야 한다는 것입니다.</p>
<h3 id="SLI 구현">SLI 구현</h3>
<p>CUJ를 정의한 다음에는 SLI를 정의합니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/6549b92195cd4d42b04d9c88aa5c1994.png?updatedAt=1776385094000" width="1000" height="auto" alt="SLI/SLO 구현 4단계 중 SLI 구현 단계"></p>
<p>SLI는 CUJ별로 어떤 지표를 설정하고 측정할 것인지 정의하는 것입니다.</p>
<ul><li>어떤 위치에서 측정할 것인가?
<ul><li>게이트웨이나 프런트엔드, 백엔드 등 각 CUJ별로 보다 정확하게 측정할 수 있는 위치를 선정합니다.</li></ul>
</li><li>어떤 API를 통해서 측정할 것인가?
<ul><li>지표를 복잡하게 계산할 필요가 없도록 각 CUJ별로 대표적인 API를 선정합니다.</li></ul>
</li></ul>
<p>다음으로 성공과 실패를 가르는 기준값(SLI criterion)을 정의합니다. 일반적으로 응답 시간과 응답 성공률, 크게 두 가지로 측정하며 각 기준값은 다음과 같이 정의합니다.</p>
<ul><li>응답 시간: 전체 요청에 대한 응답 시간의 몇 퍼센타일을 기준으로 삼을 것인지, 그 기준 응답 시간이 얼마 이내여야 성공으로 간주할 것인지 정의합니다.</li><li>응답 성공률: 측정 시간 동안 응답 성공률이 얼마여야 하는지 정의합니다.</li></ul>
<p>예를 들어 '메시지 전송 기능은 99.9 퍼센타일의 요청에 대한 응답 시간을 500ms 미만으로, 전체 요청의 99.999%가 성공 응답을 받는 서비스를 제공하겠다'와 같이 정의합니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/0228a23372144186a521ccbea9dec177.png?updatedAt=1776385126000" width="1000" height="auto" alt="SLI 정의 예시"></p>
<p>이 단계의 핵심은 측정 위치와 대상, 성공과 실패를 구분하는 명확한 기준을 정의하는 것입니다. 특히 성공과 실패를 구분하는 기준을 명확하게 정의해야 SLO 달성 여부를 측정할 수 있습니다. 만약 변수가 많아 측정이 불가하거나 성공과 실패를 나누는 기준을 명확하게 정의할 수 없다면 해당 CUJ는 측정에서 제외하는 것도 가능합니다. 측정하기 복잡한 경우에는 SLI를 위한 별도 지표를 만드는 것을 권고합니다.</p>
<h3 id="SLO 타깃 설정">SLO 타깃 설정</h3>
<p>SLI를 정의한 뒤에는 SLO를 정의합니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/d186c4e9bcc64c35a756c4a8d107a0aa.png?updatedAt=1776385150000" width="1000" height="auto" alt="SLI/SLO 구현 4단계 중 SLO 타깃 설정 단계"></p>
<p>이 단계에서는 '측정하는 기간 동안 SLI 기준에 맞는 신뢰성과 안정성이 보장된 서비스를 제공하겠다'라는 목표를 정의합니다. 예를 들어 아래와 같이 '28일 동안 99.9%, 즉 총 40,320분 중 40,280분 동안 SLI에 정의한 응답 시간과 응답 성공률을 달성하겠다'와 같이 정의합니다.</p>
<p>SLO(Service Level Objective)</p>
<p>The objectives or specific ranges that the service needs to achieve, based on the measured SLIs</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/5d23bf325fc1453f87885718a7260b37.png?updatedAt=1776385189000" width="1000" height="auto" alt="SLO 타깃 설정 예시"></p>
<p>이 단계의 핵심은 실제로 지킬 수 있는 현실적인 목표를 설정하는 것입니다. SLO를 너무 높게 설정하면 이를 달성하기 위해 그만큼의 비용을 추가해야 하고, 반면 너무 낮게 설정하면 서비스 질이 낮아져 사용자에게 좋지 않은 경험을 제공할 수 있습니다. 따라서 안정성과 비용 양쪽을 적절히 고려해 설정해야 합니다.</p>
<h3 id="시각화">시각화</h3>
<p>마지막으로 서비스와 관련된 모든 이해관계자가 현재 SLO 상태를 쉽게 확인할 수 있도록 앞서 정의한 SLI/SLO를 시각화한 대시보드를 구현합니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/2e066baabd2a42bc93d766af2daebd5b.png?updatedAt=1776385226000" width="1000" height="auto" alt="SLI/SLO 구현 4단계 중 시각화 단계"></p>
<p>아래 예시와 같이 SLO와 오류 예산(error budget)을 요약해서 볼 수 있는 대시보드를 구현하면 현재 SLO의 전체적인 상태를 한눈에 확인할 수 있습니다. 여기에 각 CUJ별 상세 대시보드까지 구현해 놓으면 보다 상세하게 SLI 지표를 확인할 수 있습니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/d9139102f7d94bdaa3af32f08a100eac.png?updatedAt=1776385282000" width="1000" height="auto" alt="시각화 예시"></p>
<p>이 단계의 핵심은 대시보드에 너무 많은 정보를 담기보다는 수치나 색을 이용해 단순화해서 전체 상황을 한눈에 빠르게 파악할 수 있도록 제공하는 것입니다. 예를 들어 목표를 안정적으로 달성하고 있는 지표는 초록색으로, 경고해야 할 항목은 주황색으로, 목표 달성에 실패한 항목은 빨간색으로 표현하면 현재 상황을 쉽고 빠르게 파악할 수 있습니다.</p>
<h2 id="SLI/SLO 활용">SLI/SLO 활용</h2>
<p>이제 SLI/SLO를 어떻게 활용하는지 소개하겠습니다.</p>
<h3 id="신뢰성과 안정성을 정량적으로 파악할 수 있는 지표">신뢰성과 안정성을 정량적으로 파악할 수 있는 지표</h3>
<p>서비스의 상태를 표현할 때 '느려졌다' 혹은 '안정적이지 않다'라는 표현 대신 정량적 지표로 정의한 SLI를 이용하면 보다 정확하게 표현할 수 있습니다. 예를 들어 아래와 같은 상황에서는 "서비스의 응답 시간이 SLI 기준인 400ms를 초과하고 있어서 사용자가 불편을 겪고 있다"와 같이 표현할 수 있습니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/1550d3fe925e4c62847bd977a648a937.png?updatedAt=1776385359000" width="584" height="340" alt="서비스의 응답 시간이 SLI 기준인 400ms를 초과하고 있는 그래프"></p>
<p>또한 아래와 같은 상황에서는 '우리 서비스의 응답 성공률이 99.99% 미만이고 이에 따라 사용자가 서비스 이용에 불편을 겪고 있다'라고 표현할 수 있습니다. 또한 대시보드를 보며 응답 성공률을 달성하지 못한 시간에 어떤 이슈가 있었는지도 파악할 수 있습니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/4ff378e17e584a6092e2d7075b6b0aba.png?updatedAt=1776385406000" width="584" height="342" alt="서비스의 응답 성공률이 99.99% 미만인 상황의 그래프"></p>
<p>이와 같이 정량적인 수치와 이를 시각화한 대시보드를 이용해 서비스의 상태를 보다 명확하게 모니터링하고 분석할 수 있습니다.</p>
<h3 id="리소스 분배 기준으로 활용&nbsp;">리소스 분배 기준으로 활용</h3>
<p>SLO를 통해 현재 목표 달성 여부를 확인할 수 있고 오류 예산으로 현재 허용 가능한 장애 시간을 파악할 수 있습니다. 이는 다시 SLO를 달성하기 위해 필요한 예방 및 대응 활동에 투입해야 할 리소스를 산정하는 기준으로 사용할 수 있습니다.</p>
<p>만약 서비스가 SLO를 만족하고 있고 오류 예산도 넉넉하다면 서비스를 안정적으로 운영하고 있다고 판단하고 신규 기능 출시 등에 보다 공격적으로 리소스를 투입할 수 있습니다. 예를 들어 현재 상황이 다음과 같다면 'SLO 99.9% 목표를 초과해 99.98%를 달성하고 있고, 오류 예산도 80% 이상으로 넉넉하기 때문에 안정적이다'라고 판단할 수 있습니다. 이를 기반으로 새로운 기능을 출시하거나 릴리스 사이클을 당기는 데 리소스를 투입할 수 있습니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/1af0e3fb9dcb4ce3b27e728032225791.png?updatedAt=1776385448000" width="472" height="244" alt="SLO 99.98%, 오류 예산 80%인 대시보드 예시"></p>
<p>반면 아래와 같이 오류 예산이 10%만 남아 있다면 SLO를 안정적으로 달성하고 서비스 안정성을 높이는 데 리소스를 투입하기로 결정할 수 있습니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/674b139516bf4e54a4f659b8cccf23cd.png?updatedAt=1776385493000" width="466" height="244" alt="SLO는 99.98%이지만 오류 예산은 10%인 대시보드 예시"></p>
<h3 id="온콜 대응 시 활용">온콜 대응 시 활용</h3>
<p>현재 각 서비스의 온콜(on-call) 체계에는 오류 예산 상태 변화에 따른 알림을 적용해 서비스 상태를 파악하고 이슈에 대응하는 데 활용하고 있습니다. 또한 정기 미팅에서 SLO 상태를 점검하거나 목표를 달성하기 위해 예방 활동을 진행하는 데에도 활용합니다.</p>
<p>다음은 오류 예산 상태 알림 메시지 예시입니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/85f2a41b302144669feab612ce72c7fc.png?updatedAt=1776386781000" width="800" height="auto" alt="오류 예산 상태 알림 메시지 예시1"></p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/cab8ac4cf7824652bb7cc18b0d691f73.png?updatedAt=1776386820000" width="800" height="auto" alt="오류 예산 상태 알림 메시지 예시2"></p>
<h2 id="마치며">마치며</h2>
<p>서비스에서 신뢰성과 안정성은 핵심 가치입니다. 또한 사용자의 편의를 높이고 새로운 기능을 제공하는 것 역시 비즈니스에서 매우 중요한 가치입니다. SLO는 정량적인 지표를 통해서 서비스의 신뢰성과 비즈니스의 목표 사이에서 균형을 잡는 데 도움을 줄 수 있다고 믿습니다.</p>
<figure><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/175eaea2c9d649cfac55c2bd4ee8384a.png?updatedAt=1776386877000" width="1000" height="auto" alt="SLO를 이용해 서비스 신뢰성과 비즈니스 목표 사이에서 균형 잡기">
<figcaption><strong>SLOs help balance service reliability with business demands</strong></figcaption>
</figure>
<p>이 글이 SLI/SLO에 관심 있는 분들과 서비스에 도입하려는 분들에게 도움이 되길 바랍니다. 마지막으로 SRE 역할에 대한 제 견해를 정리한 문구를 공유드리며 이만 마치겠습니다. 긴 글 읽어주셔서 감사합니다.</p>
<p><strong>Core tenets of SRE</strong></p>
<p>Focus on providing <strong>stability</strong> and <strong>reliability</strong> to our <strong>customers</strong> <br>And strive for continuous <strong>improvement</strong> and <strong>innovation</strong>.</p></div></article></div>

LINE ENGINEERING

시작하며안녕하세요. Service Reliability 팀에서 SRE(site reliability engineer)로 일하고 있는 천기철입니다. SRE 팀은 사용자에게 안정적이고...

신뢰성 향상을 위한 SLO/SLI 도입 3편 - 서비스 적용 사례

댓글