[SRE Certificate] SRE(Site Reliability Engineering) 도대체 그게 뭔데?

어느덧 인턴 입사 3주차의 반이 지났다.

Site Reliability Engineering (SRE) Foundation 자격증 정보

이 글에서 언급했듯이 3주차 월요일부터는 매일 LinkedIn Training을 들으면서 매니저와 매일 15-30분씩 이야기하는 시간을 갖고있다. 아무래도 나는 인턴이고 SRE 분야에 있어 완죠니 뉴비이기 때문에 매니저가 매일 강의 내용을 복습하고, 또 왜 이 분야가 필요한지에 대해 설명하는 시간이 굉장히 즐겁다.

 

전체 강의의 반 정도를 들은 결과, SRE의 마인드셋은 SWE/SDE와는 굉장히 달라야 한다는 사실을 깨달아가는 중이다. 뇌피셜이지만 지금 이 수업들은 computer science를 공부하는 사람으로서 가지고 있는 마인드셋을 SRE 마인드셋으로 업데이트 할 수 있는 기회인 것 같다.

---

Site Reliability Engineering이란?

아래 꼭지들은 단순히 강의 내용을 구글 번역에 돌린 것들이다.

• SRE is a discipline that incorporates aspects of software engineering and applies them to infrastructure and operations problems
• SRE는 소프트웨어 엔지니어링 측면을 통합하고 이를 인프라 및 운영 문제에 적용하는 분야입니다.

1. SRE spend 50% of their time doing “ops” related work such as issue resolution, on-call, and manual interventions. SRE는 문제 해결, 대기 중, 수동 개입 등 "운영" 관련 작업에 시간의 50%를 소비합니다.
2. SRE spend 50% of their time on development tasks such as a new features, scaling or automation. SRE는 새로운 기능, 확장 또는 자동화와 같은 개발 작업에 50%의 시간을 소비합니다.
   1. in the area of Service Reliability 서비스 신뢰성 분야에서
   2. development, testing purpose 개발, 테스트 목적으로
   3. X functional features O reliability features X 기능적 특징, O 신뢰성 특징
   4. how make service scale effectively X 기능적 특징, O 신뢰성 특징

• Monitoring, alerting and automation are a large part of SRE. 모니터링, 경고 및 자동화는 SRE의 큰 부분입니다.
  • a wide range of multiple tools, make it easier to monitoring. 다양한 도구를 통해 모니터링이 더욱 쉬워집니다.
  • fix things quickly, prevent happening again. 신속하게 문제를 해결하고 재발 방지

Bullet points들로 된 내용에서도 알 수 있듯이, Google에서 Site Reliability Engineering 이라는 새로운 개념을 만든 이유도 약간은 이해가 간다. 누군가가 새로운 서비스를 만들고 런칭하고 나면 “운영”에 있어서 엄청난 수고가 들어간다는 사실을, 서비스가 커지고 세계적으로 트래픽이 생겨나고, 서버가 클라우드/온프레미스/하이브리드를 넘어서 Distributed Cloud로 다양화 되면서 SRE의 임무가 점점 늘어났던 것 같다. 

---

 

책을 더 읽어봐야 확실히 할 수 있겠지만 일단 지금까지 강의를 들으면서 요런 생각이 들었달까? 내가 일하는 회사도 세계적으로 서비스를 제공하고, 거대 기업들의 Application Delivery Service를 제공하다보니 SRE도 그 중요도가 올라가고 있는 것 같다. 현재 3강까지 들은 지금, 중요한 키워드들을 정리해 보고 싶다.

 

SLO(Service Level Objectives)

“Before getting into the technical details of a SLO, it is important to start the conversation from your customers’ point of view: what promises are you trying to uphold?” "SLO의 기술적인 세부 사항을 알아보기 전에 고객의 관점에서 대화를 시작하는 것이 중요합니다. 어떤 약속을 지키려고 합니까?”

• SLO is a goal for how well a product or service should operate
• SLO’s are tightly related to the user experience — if SLO’s are being met then the user will be happy
• Setting and measuring SLO is a key aspect of the SRE role - monitor compliance SLO through Service Level indicators(how do we perform)
• the most widely tracked SLO is availability = how available is your service to users?
• Products and services could (and should) have several SLO’s

SLO’s are about making the user experience better

• SLO는 제품이나 서비스가 얼마나 잘 작동해야 하는지에 대한 목표입니다.
• SLO는 사용자 경험과 밀접한 관련이 있습니다. SLO가 충족되면 사용자는 만족할 것입니다.
• SLO 설정 및 측정은 SRE 역할의 핵심입니다. - 서비스 수준 지표를 통해 규정 준수 SLO를 모니터링합니다(수행 방법).
• 가장 널리 추적되는 SLO는 가용성입니다. = 사용자에게 서비스가 얼마나 제공됩니까?
• 제품 및 서비스에는 여러 SLO가 있을 수 있으며 있어야 합니다.

SLO는 사용자 경험을 개선하는 것입니다.

Example: SLO’s & Error Budgets

• We decide that 99.9% of web requests(www…) per month should be successful — this is a SLO
• If there are 1 million web requests in a particular month, then up to 1,000 of those are allowed to fail — this is an Error Budget
• Failure to hit an SLO must have consequences — if more than 1,000 web requests fail in a month then some remediation work must take place — this is an Error Budgeting policies

예: SLO 및 오류 예산

• 매월 웹 요청(www…)의 99.9%가 성공해야 한다고 결정합니다. 이것이 SLO입니다.
• 특정 달에 100만 개의 웹 요청이 있는 경우 최대 1,000개의 요청이 실패하도록 허용됩니다. 이는 오류 예산입니다.
• SLO에 도달하지 못하면 결과가 발생해야 합니다. 한 달에 1,000개 이상의 웹 요청이 실패하면 일부 수정 작업이 수행되어야 합니다. 이것이 바로 오류 예산 책정 정책입니다.

---

SLA(Service Level Agreement)

• contractual, very public
• range of SLOs — if you consistently meet, you are satisfying SLA
• SLA contractual with your users and customers, we strive to meet those
• SLO focus on aspects of service delivery itself. We want service to met SLO
• SRE make sure comply with those SLOs

SLA(서비스 수준 계약)

• 계약적, 매우 공개적
• SLO 범위 - 지속적으로 충족하면 SLA를 충족하는 것입니다.
• 귀하의 사용자 및 고객과 SLA 계약을 맺고 이를 충족하기 위해 노력합니다.
• SLO는 서비스 제공 자체의 측면에 중점을 둡니다. SLO에 맞는 서비스를 원한다
• SRE는 해당 SLO를 준수해야 합니다.

---

SLI(Service Level Indicators)

SLI’s are ways for engineers to communicate quantitative data about systems.

SLI는 엔지니어가 시스템에 대한 정량적 데이터를 전달하는 방법입니다.

SLI Measurement

While many numbers can function as an SLI, it is generally recommended to treat SLI as the ratio of two numbers; the number of good events divided by the total number of events;

- e.g, number of successful web request / total requests (success rate)

Many indicator metrics are naturally gathered on their server side, using a monitoring system such as Prometheus, or with periodic log analysis — for instance, HTTP 500 responses a fraction of all requests

Some SLI may also need client-side data collection, because not measuring behavior at the client can miss a range of problems that affect users but don’t affect server-side metrics

 

많은 숫자가 SLI로 작동할 수 있지만 일반적으로 SLI를 두 숫자의 비율로 처리하는 것이 좋습니다. 양호한 이벤트 수를 총 이벤트 수로 나눈 값입니다.
- 예: 성공한 웹 요청 수/총 요청 수(성공률)
많은 지표 지표는 Prometheus와 같은 모니터링 시스템이나 주기적인 로그 분석을 사용하여 서버 측에서 자연스럽게 수집됩니다. 예를 들어 HTTP 500은 전체 요청의 일부만 응답합니다.
일부 SLI에는 클라이언트 측 데이터 수집이 필요할 수도 있습니다. 클라이언트에서 동작을 측정하지 않으면 사용자에게 영향을 주지만 서버 측 측정항목에는 영향을 주지 않는 다양한 문제를 놓칠 수 있기 때문입니다.

---

What is toil

Work is Toil if it is:

• Manual 수동
• Repetitive 반복적
• Automatable 자동화 가능
• Tactical 전술적
• No enduring Value 지속적인 가치 없음
• Linear Scaling 선형적 스케일링

We need to do something about toil 

---

Monitoring

is the use of a hardware or software component to monitor system resources and performance of a computer system

컴퓨터 시스템의 시스템 리소스와 성능을 모니터링하기 위해 하드웨어 또는 소프트웨어 구성 요소를 사용하는 것입니다.

 

 

Observability

make sure health of our service is there

우리 서비스의 상태가 양호한지 확인하세요

Monitoring & Obeservability

- Distributed, complex services running at scale with unpredictable users and variable throughput means there are millions of different ways that things can go wrong
- But we can’t anticipate them all (monitoring myth)
- Externalizing all the outputs of a service allows us to infer the internal state of that service (observable)

- 예측할 수 없는 사용자와 가변적인 처리량으로 대규모로 실행되는 분산된 복잡한 서비스는 문제가 발생할 수 있는 방법이 수백만 가지에 달함을 의미합니다.
- 하지만 모두 예상할 수는 없다 (모니터링 신화)
- 서비스의 모든 출력을 외부화하면 해당 서비스의 내부 상태를 추론할 수 있습니다 (관찰 가능).

 

Monitoring is a verb: something we perform against our applications and systems to determine their state. From basic fitness tests and whether they are up or down, to more proactive performance health checks. We monitor applications to detect problems and anomalies
모니터링은 동사입니다. 애플리케이션과 시스템의 상태를 확인하기 위해 수행하는 작업입니다. 기본적인 체력 테스트와 상승 또는 하락 여부부터 보다 적극적인 성능 상태 점검까지. 문제와 이상 현상을 감지하기 위해 애플리케이션을 모니터링합니다.

Observability, as a noun, is a property of a system, it’s a measure of how well internal states of a system can be inferred from knowledge of its external outputs. Therefore, if our IT systems don’t adequately externalize their state, then even the best monitoring can fall short.
명사로서의 관찰가능성은 시스템의 속성이며, 외부 출력에 대한 지식을 통해 시스템의 내부 상태를 얼마나 잘 추론할 수 있는지를 측정하는 것입니다. 따라서 IT 시스템이 상태를 적절하게 외부화하지 않으면 최고의 모니터링도 부족할 수 있습니다.

Draw some conclusions, as to what a healthy service look like, using a combination of factors
여러 요소의 조합을 사용하여 건전한 서비스의 모습에 대한 몇 가지 결론을 도출합니다.

Observability = Better Alerting

---

SLOs SLIs & Observability

• SLOs are from a user perspective and help identify what is important SLO는 사용자 관점에서 이루어지며 중요한 것이 무엇인지 식별하는 데 도움이 됩니다.
  • 90% of users should complete the full payment transaction in less than one elapsed minute. 90%의 사용자가 1분 이내에 전체 결제 거래를 완료해야 합니다.
• SLIs give detail on how we are currently performing SLI는 현재 우리가 어떻게 수행하고 있는지에 대한 세부정보를 제공합니다.
  • 98% users in a month complete a payment transaction in less than one minute 한 달간 98%의 사용자가 1분 이내에 결제 거래를 완료합니다.
• Observability gives use the normal state of the service 관찰 가능성을 통해 서비스의 정상적인 상태를 사용할 수 있습니다.
  • 38 seconds is the “normal” time it takes users to complete a payment transaction when all monitors are healthy 38초는 모든 모니터가 정상일 때 사용자가 결제 거래를 완료하는 데 걸리는 "정상" 시간입니다.

---

구글 번역이 완벽하진 않지만 그래도 영어로 약간 감이 오지 않을 때 돌려보면 또 이해에 도움이 되곤 한다. SLO, SLA, SLI, Toil, Monitoring & Observability 가 강의 초반에 중요한 키워드인 것 같다. 매니저랑 이 강의를 듣고서 매일 대화하는 시간에 팀장님이 매번 "너는 어떻게 생각해?"라고 물으시면 그래도 들은 내용을 기반으로 느낀점이나 궁금한 질문을 던지곤 하는데 팀장님이 자기의 경험+회사에 기대하는 바를 섞어서 굉장히 잘 설명해 주신다. 고개 끄덕 끄덕 거리면서 주루루룩 적고 있는 내 자신을 발견하면 재밌달까....

 

아무래도 강의 초반에서 가장 중요한 부분은 가장 마지막에 쓴 SLOs SLIs & Observability 요 부분이 제일 중요하지 싶다. 저 상관 관계들을 아는 것?!

 

그리고 SRE 분야를 알게 되면 알게 될수록 그 중요성이 점점 더해질 것 같단 생각이 든다. 기술의 홍수 속에서 0부터 100까지 하나의 환경에서 모든걸 다 새롭게 만들지 않으니까. 새로운 기술이 있으면 내가 가진 솔루션에 라이센스를 가져오고 통합시키고 또 서버를 확장하고 줄이고 하는 것들이 모두 저 SLO, SLI가 기준이 되어 가이드라인을 제공하니 말이다. 개념적인 이야기를 하느라 어찌 보면 한 귀로 듣고 한 귀로 흘려 버릴 수도 있는 이야기들이지만 그래도 매니저랑 얘기한 덕분에 좀 더 머릿속에 오래 남아 있는 것 같다. 남은 챕터들도 얼른 열심히 끝내서 시험 쳐야지~!