<div id="readability-page-1" class="page"><article><div><h2 id="시작하며">시작하며</h2>
안녕하세요. SRE(site reliability engineering, 사이트 안정성 엔지니어링) 업무를 맡고 있는 Enablement Engineering 팀 어다희, Service Reliability 팀 천기철입니다.
저희 두 팀은 Service Engineering 실에 속해 있으며, LINE 앱에서 제공하는 서비스의 품질 향상 및 가용성 확보를 위한 기술 활동을 수행합니다. 보다 구체적으로는 메시징 서비스와 미디어 플랫폼 등 LINE 앱 서비스에 대한 SRE을 담당하고 있습니다. 이를 위해 서비스 출시 및 이벤트에 필요한 기술적인 요소를 확인하고 그에 맞는 솔루션을 제공하며, 개발 조직이 개발과 운영에 더욱 집중할 수 있도록 불안 요소를 제거하고 단순 반복 작업을 줄이기 위한 기술 지원 및 자동화 작업을 수행합니다. 또한 수요 예측과 성능 개선, 관찰가능성(observability) 강화, 사고 대응과 같은 다양한 분야에서 엔지니어링 측면에서 노력을 기울이며, 서비스의 신뢰성을 한층 더 높이기 위해 노력합니다.
저희는 이와 같은 경험을 기반으로 '신뢰성(reliability) 향상을 위한 SLI/SLO 도입'을 주제로 세 편의 글을 연재하려고 합니다. 이번 글은 그 시작으로, SLO(service level objective)와 SLI(service level indicator)를 처음 들어보신 분들을 위해 이게 무엇이고 왜 필요한지 배경을 설명하는 것으로 가볍게 시작해 보겠습니다.
<h2 id="SRE의-역할">SRE의 역할</h2>
SRE는 고객에게 서비스의 '안정성'과 '신뢰성'을 제공하는 데 필요한 모든 엔지니어링 업무를 수행합니다. 조금 더 구체적으로 말씀드리면 성능 개선 및 자동화를 위한 코드 작성과 시스템 모니터링, 장애 대응 등을 수행해 서비스의 안정성을 유지하면서 변화를 최대한 수용해 신뢰도 높은 서비스를 제공하는 것을 목표로 합니다.
여기서 '신뢰성'이라는 단어가 다소 추상적인 단어인데요. 아래와 같이 신뢰와 관련된 어떤 긍정적인 단어로 해석해도 틀리지 않습니다.&nbsp;
<ul><li>빠른 서비스를 제공한다.</li><li>안정적인 서비스를 제공한다.</li><li>안전한 서비스를 제공한다.</li></ul>
이는 결국 사용자가 믿고 쓸 수 있는 서비스를 제공한다는 의미입니다. 즉, 신뢰성은 서비스를 제공하는 쪽의 모니터링 결과로 결정되는 것이 아니라 사용자가 결정하는 것입니다.
따라서 SRE는 사용자가 서비스를 어떻게 느끼고 있는지 데이터를 기준으로 표현할 수 있어야 합니다. 예를 들어 '서비스가 느리다' 또는 '서비스가 불안정하다'라는 정성적인 표현보다는 '메시지 전송 API의 응답 속도가 1초 이상으로 느려지고 있어 사용자가 불편을 겪고 있다'와 같이 정량적으로 표현할 수 있어야 하며, 이를 위해서는 기준과 등급, 케이스별 계획 등이 필요합니다.&nbsp;
여기서 등장하는 개념이 SLI와 SLO와 SLA(service level agreement)입니다. LINE 앱 역시 사용자에게 보다 더 신뢰할 수 있는 서비스를 제공하기 위해 SLI와 SLO를 도입했습니다.
<h2 id="신뢰성은-어떻게-측정하나요?">신뢰성은 어떻게 측정하나요?</h2>
위에서 간단히 언급했지만 신뢰성을 어떻게 정량적으로 측정할 수 있을까요?
동영상 서비스를 예시로 설명해 보겠습니다. 사용자가 해당 서비스를 사용하면서 가장 중요하게 생각하는 점은 영상 시작에 오랜 시간이 걸리지 않고, 중간에 끊김 없이 잘 재생되는 것입니다. 여기서 동영상이 출력되기까지 걸리는 시간인 대기 시간(latency)이 SLI, 즉 지표가 됩니다. 그리고 이 지표의 목표치가 바로 SLO입니다. 또한 보통 구독 서비스의 경우 사용자와 기업 간의 계약이기 때문에 이와 같은 지표와 관련해 기준을 명시하고 해당 기준을 어길 경우에 대한 보상 등을 명시하는데요. 이 내용이 SLA입니다.
이해하기 쉽도록 아주 간단하고 단적인 예시로 설명했는데요. 각 개념을 조금 더 자세히 살펴보겠습니다.
<h3 id="사용자-여정(user-journey)">사용자 여정(user journey)</h3>
SLI와 SLO, SLA를 이해하려면 먼저 사용자 여정 이라는 개념을 살펴봐야 합니다. 사용자 여정이란 사용자가 서비스를 사용하는 과정 혹은 흐름을 정의한 것으로, 앞서 동영상 서비스 예시에서는 '사용자가 서비스에서 동영상을 재생하기 위해 거치는 과정'을 사용자 여정이라고 부릅니다. 메시징 서비스에서는 '사용자가 메시지를 전송하기 위해 거치는 흐름'이나 '친구를 추가할 때 거치는 과정' 등이 그 예가 될 것입니다.
사용자 여정 중 핵심 기능 및 서비스에 대한 여정을 '핵심 사용자 여정(critical user journey, 이하 CUJ)'이라고 부릅니다. SLI와 SLO를 도입하는 것은 서비스 주요 기능에 대한 CUJ를 정의하고 각 사용자 여정별로 사용하는 API를 찾는 게 그 시작점입니다.
<h3 id="SLI,-SLO,-SLA">SLI, SLO, SLA</h3>
아래는 SLI와 SLO, SLA의 개념을 정리한 표입니다.
<table><tbody><tr><th>구분</th><td>SLI(service level indicator)</td><td>SLO(service level objective)</td><td>SLA(service level aggrement)</td></tr><tr><th>설명</th><td>
<ul><li>사용자 관점에서 서비스의 안정성을 판단할 수 있는 정량적으로 측정한 값</li><li>대기 시간(latency), 가용성(availabiliity), 처리량(throughput) 등</li></ul>
</td><td>
<ul><li>측정된 SLI를 통해 사용자의 기대를 충족시키기 위해 서비스가 달성해야 하는 목푯값 혹은 목표 범위</li></ul>
</td><td>
<ul><li>SLO를 기반으로 한 서비스 공급자와 고객 간의 사업 계약(무료 서비스에서는 사용하지 않음)</li></ul>
</td></tr><tr><th>예시</th><td>
<ul><li>지난 1분간 동영상 재생 요청 중 95퍼센타일의 대기 시간이 300ms 미만이다.</li><li>지난 1분간 영상 목록 조회 요청의 가용성이 99.9% 이상이다(상태 코드 기준 2XX와 3XX).</li></ul>
</td><td>
<ul><li>지난 1개월의 동영상 재생 SLI가 99.9%를 충족한다.</li><li>지난 1개월의 영상 목록 조회 SLI가 99.9%를 충족한다.</li></ul>
</td><td>
<ul><li>동영상 서비스는 매달 99.8%의 작동 시간을 유지한다.</li><li>IT 지원 팀은 고객의 이메일 지원 요청을 1시간 이내에 확인하고 응답한다.</li><li>동영상 재생 불가와 같은 중요 문제는 4시간 이내에 해결한다.</li></ul>
</td></tr></tbody></table>
SLI/SLO의 예시를 조금 더 자세히 정의하면 아래와 같습니다. 글자 색에 따라 Event(이벤트), Success Criterion(성공 조건), Where and How(API 및 측정 방법), Measurement window(측정 주기)를 의미합니다. CUJ를 구체화하지 않았기 때문에 일반적인 예시로 작성한 점 참고 부탁드립니다.
&lt;예 1. 대기 시간 기반 SLI/SLO&gt;
<table><tbody><tr><th>SLI Type</th><td>
<ul><li>Latency</li></ul>
</td></tr><tr><th>SLI Specification</th><td>
<ul><li>Proportion of HTTP GET requests for /api001 that send their entire response within 300ms measured at the Gateway Log.</li></ul>
<ul><li><math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mfrac><mrow><mi>H</mi><mi>T</mi><mi>T</mi><mi>P</mi><mtext>&nbsp;</mtext><mi>G</mi><mi>E</mi><mi>T</mi><mtext>&nbsp;</mtext><mi>s</mi><mi>u</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>f</mi><mi>u</mi><mi>l</mi><mtext>&nbsp;</mtext><mi>r</mi><mi>e</mi><mi>q</mi><mi>u</mi><mi>e</mi><mi>s</mi><mi>t</mi><mi>s</mi></mrow><mrow><mi>H</mi><mi>T</mi><mi>T</mi><mi>P</mi><mtext>&nbsp;</mtext><mi>G</mi><mi>E</mi><mi>T</mi><mtext>&nbsp;</mtext><mi>r</mi><mi>e</mi><mi>q</mi><mi>u</mi><mi>e</mi><mi>s</mi><mi>t</mi><mi>s</mi></mrow></mfrac><mtext>&nbsp;</mtext><mo>×</mo><mn>100</mn><mi mathvariant="normal">%</mi></mrow><annotation encoding="application/x-tex">\frac { HTTP\ GET\ successful\ requests}{ HTTP\ GET\ requests}\ \times 100\%</annotation></semantics></math></li></ul>
</td></tr><tr><th>SLI Implementations</th><td>
<ul><li>HTTP Method: GET</li><li>API: /api001</li><li>Criterion response within 300ms</li><li>Where &amp; How: Gateway Log</li></ul>
</td></tr><tr><th>SLO</th><td>
<ul><li>99.9% of api001 in the past 28-days rolling window served successfully</li></ul>
</td></tr></tbody></table>
&lt;예 2. 가용성 기반 SLI/SLO &gt;
<table><tbody><tr><th>SLI Type</th><td>
<ul><li>Availability</li></ul>
</td></tr><tr><th>SLI Specification</th><td>
<ul><li>Proportion of HTTP POST requests for /api002 that have 2XX, 3XX or 4XX (exclude 429) status measured at the Gateway Log.</li><li><math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mfrac><mrow><mtext>&nbsp;</mtext><mi>H</mi><mi>T</mi><mi>T</mi><mi>P</mi><mtext>&nbsp;</mtext><mi>P</mi><mi>O</mi><mi>S</mi><mi>T</mi><mtext>&nbsp;</mtext><mi>s</mi><mi>u</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>f</mi><mi>u</mi><mi>l</mi><mtext>&nbsp;</mtext><mi>r</mi><mi>e</mi><mi>q</mi><mi>u</mi><mi>e</mi><mi>s</mi><mi>t</mi><mi>s</mi></mrow><mrow><mtext>&nbsp;</mtext><mi>H</mi><mi>T</mi><mi>T</mi><mi>P</mi><mtext>&nbsp;</mtext><mi>P</mi><mi>O</mi><mi>S</mi><mi>T</mi><mtext>&nbsp;</mtext><mi>r</mi><mi>e</mi><mi>q</mi><mi>u</mi><mi>e</mi><mi>s</mi><mi>t</mi><mi>s</mi></mrow></mfrac><mtext>&nbsp;</mtext><mo>×</mo><mn>100</mn><mi mathvariant="normal">%</mi></mrow><annotation encoding="application/x-tex">\frac {\ HTTP\ POST\ successful\ requests}{\ HTTP\ POST\ requests}\ \times 100\%</annotation></semantics></math></li></ul>
</td></tr><tr><th>SLI Implementations</th><td>
<ul><li>HTTP Method: POST</li><li>API: /api002</li><li>Criterion: response code. 2XX, 3XX or 4XX (exclude 429) status</li><li>Where &amp; How: Gateway Log</li></ul>
</td></tr><tr><th>SLO</th><td>
<ul><li>99.9% of api002 in the past 28-days rolling window served successfully</li></ul>
</td></tr></tbody></table>
아래는 SLI/SLO를 기반으로 신뢰성을 측정하는 흐름을 정리한 것입니다.
<img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/5042567b7bc641a4aa857e6bdf79d769.png?updatedAt=1739853211000" width="1000" height="auto" alt="">
SLI/SLO를 정의하고 측정하는 원칙은 아래와 같습니다.
<ul><li>사용자의 관점에서 바라볼 것 : 중요한 것은 어떤 값을 측정할 수 있는지가 아니라 사용자가 중요하게 생각하는 것이 무엇인지 찾아내는 것입니다.</li><li>최대한 단순할 것 : SLI를 복잡하게 집계하면 시스템 성능 상태를 명확히 반영하지 못하므로 최대한 단순해야 합니다.</li><li>가능한 적은 수의 SLO를 설정 : 시스템의 특성을 잘 확인할 수 있는 최소한의 SLO를 선택하는 것이 중요합니다.</li><li>목표 설정 : 기대치를 설정하되, 100%와 같은 지나친 목표를 설정하지 않아야 합니다.</li><li>지속적인 개발 및 개선 : 처음부터 완벽하게 설정하는 것은 불가능하므로 지속적으로 확인하고 개선해야 합니다.</li></ul>
<h3 id="오류-예산(error-budget)">오류 예산(error budget)</h3>
위와 같이 SLI를 측정하고 SLO를 정의해 목표를 세웠다면 이를 달성하지 못했을 때 어떻게 할 것인지, 즉 리스크와 오류를 관리할 필요가 있습니다.
여기서 등장하는 개념이 바로 '오류 예산(error budget)'입니다. 오류 예산이란 SLO를 기준으로 계산된 장애 또는 서비스 안정성 저하를 어디까지 허용할 수 있는지 정의한 값입니다. 예를 들어, 한 달 기준 SLO를 99.9%로 설정했다면 0.1%의 오류를 허용한 것입니다. 수식으로 계산하면 40.32분의 오류를 허용하는 것입니다.
<math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mfrac><mstyle mathsize="0.9em"><mn>99.9</mn><mi mathvariant="normal">%</mi><mo>↑</mo></mstyle><mstyle mathsize="0.9em"><mi>m</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>h</mi></mstyle></mfrac><mo>=</mo><mfrac><mstyle mathsize="0.9em"><mn>0.1</mn><mi mathvariant="normal">%</mi><mo>↓</mo></mstyle><mstyle mathsize="0.9em"><mi>m</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>h</mi></mstyle></mfrac><mo>=</mo><mn>0.001</mn><mo>×</mo><mfrac><mstyle mathsize="0.9em"><mn>28</mn><mi>d</mi><mi>a</mi><mi>y</mi></mstyle><mstyle mathsize="0.9em"><mi>m</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>h</mi></mstyle></mfrac><mo>×</mo><mfrac><mstyle mathsize="0.9em"><mn>24</mn><mi>h</mi><mi>o</mi><mi>u</mi><mi>r</mi></mstyle><mstyle mathsize="0.9em"><mi>d</mi><mi>a</mi><mi>y</mi></mstyle></mfrac><mo>×</mo><mfrac><mstyle mathsize="0.9em"><mn>60</mn><mi>m</mi><mi>i</mi><mi>n</mi></mstyle><mstyle mathsize="0.9em"><mi>h</mi><mi>o</mi><mi>u</mi><mi>r</mi></mstyle></mfrac><mo>=</mo><mfrac><mstyle mathsize="0.9em"><mn>40.32</mn><mi>m</mi><mi>i</mi><mi>n</mi></mstyle><mstyle mathsize="0.9em"><mi>m</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>h</mi></mstyle></mfrac></mrow><annotation encoding="application/x-tex">\frac {\small 99.9\%↑}{\small month} = \frac {\small 0.1\%↓}{\small month} = 0.001 \times \frac {\small 28 day}{\small month} \times \frac {\small 24 hour}{\small day} \times \frac {\small 60 min}{\small hour} = \frac {\small 40.32 min}{\small month}</annotation></semantics></math>
아래와 같이 SLO를 높게 설정할수록 자연스럽게 오류 허용 시간이 낮아집니다(아래 모든 계산은 한 달 기준입니다). 다만 목표를 마냥 높게 설정하는 게 좋은 것은 아닙니다. Google에서는 99.9%를 99.99%로 만들기 위해서, 99.99%를 99.999%로 만들기 위해서는 기존 대비 10배의 노력을 해야 한다고 설명합니다(<a href="https://www.coursera.org/learn/site-reliability-engineering-slos#modules" target="_blank">참고</a>). 그러므로 각 서비스의 특성과 상황에 맞게 적절히 설정하는 것이 중요합니다.
<ul><li>99.9% = 중단 시간(down time) 40분 → 사람이 무언가 잘못됨을 감지하고 모니터링해서 근본 원인을 찾아 수정</li><li>99.99% = 중단 시간 4분 → 사람이 감지하고 해결하기엔 짧은 시간으로 시스템이 감지하고 자가 치유할 수 있도록 설계</li><li>99.999% = 중단 시간 24초 → 사람이 감지할 수 없고 시스템으로만 감지할 수 있는 시간</li></ul>
오류 예산을 사용했을 때의 장점은 개발 팀과 SRE 팀이 '서비스의 신뢰성', 즉 서비스가 잘 운영되고 있는가에 대해 '같은 언어'로 이야기할 수 있다는 것입니다. 또한 오류 예산을 사용하면 개발 팀이 자체적으로 리스크를 관리할 수 있습니다. 신규 기능 추가와 서비스의 안정성 중 어느 것에 더 초점을 맞출지 오류 예산의 상태를 보고 개발 팀에서 결정할 수 있는 것인데요. 만약 현재 오류 예산을 초과해 서비스가 안정적이지 못하다면 모든 신규 기능 개발 또는 릴리스를 멈추고 안정성에 중점을 둬야 할 것입니다. 반대로 오류 예산을 초과하지 않았다면 신규 기능 개발에 중점을 둘 수 있습니다.
참고로 오류 예산에서 이야기하는 오류에는 애플리케이션뿐 아니라 네트워크나 스토리지 등에서 발생하는 다양한 오류가 모두 포함되며, 이는 서비스별로 다르기 때문에 각 서비스의 특성에 맞게 정의해야 합니다.

SLI/SLO를 정의하고 구현했다면 이제 사용자가 서비스에 대해 느끼는 신뢰성을 정량적으로 판단할 수 있는 준비가 된 것입니다. 그렇다면 SRE로서 SLI/SLO를 실제 운영 업무에 어떻게 활용할 수 있을까요?
먼저 서비스와 관련된 다양한 이해관계자들이 'SLI'와 'SLO', '오류 예산'을 이용해 함께 신뢰성을 평가할 수 있습니다. 정량적인 지표를 통해 신뢰성에 대해 같은 언어로 이야기하는 것이 가능합니다.
다음으로 정기 회의를 통해서 SLI/SLO 상태를 함께 모니터링하고, 리뷰 및 회고를 통해 신뢰성을 관리할 수 있습니다. 주간 또는 월간 미팅에서 지표의 변화를 공유하고, 어떤 원인이나 이슈로 변화했는지 확인한 뒤 이를 개선하기 위한 방법을 정의할 수 있습니다.
또한 오류 예산을 이용해 알림 체계를 구축함으로써 각 서비스의 온콜(on-call) 또는 서비스 운영 담당자에게 단계별 경고를 전달해 이에 대응할 수 있도록 만들 수 있습니다.&nbsp;
마지막으로 SLO 및 오류 예산 상태에 따른 대응 및 리소스 활용 정책을 정의할 수 있습니다. 예를 들어 오류 예산에 여유가 있는 경우 새로운 기능 출시 및 짧은 배포 주기 전략을 선택하고, 반대의 경우 신뢰성을 회복하기 위해 안정성 향상 활동에 리소스를 집중 투입하는 결정의 판단 기준이 될 수 있습니다.
이와 같이 활용할 수 있는 SLI/SLO는 조직과 비즈니스의 상황에 따라 조정이 필요할 수 있습니다. 따라서 관련 대시보드와 지표를 지속적으로 모니터링하고 관리해야 합니다.
<h2 id="마치며">마치며</h2>
이 글이 SRE가 어떤 역할을 하는지 궁금하셨던 분들이나 SLI/SLO의 개념이 손에 잘 잡히지 않았던 분들에게 도움이 되면 좋겠습니다. 이후 2편과 3편에서는 LINE 앱 서비스에 적용해 측정하고 구현한 사례를 소개할 예정인데요. 2편에서는 플랫폼, 3편에서는 애플리케이션 사례를 소개하겠습니다. 많은 기대와 관심을 부탁드리며 이만 마치겠습니다. 감사합니다.&nbsp;</div></article></div>

LINE ENGINEERING

시작하며
안녕하세요. SRE(site reliability engineering, 사이트 안정성 엔지니어링) 업무를 맡고 있는 Enablement Engineering 팀 어다희,...

신뢰성 향상을 위한 SLI/SLO 도입 1편 - 소개와 필요성

댓글