목록분류 전체보기 (56)
Chapter 8 - Release EngineeringSummary릴리즈 엔지니어의 역할릴리즈 엔지니어는 소프트웨어 엔지니어 및 사이트 SRE와 협력하여 소프트웨어의 빌드, 테스트, 패키징, 배포 등 릴리즈에 필요한 모든 단계를 정의한다. 이를 통해 개발 팀이 기능 개발에 집중할 수 있도록 지원하며, 일관되고 반복 가능한 릴리즈 프로세스를 보장한다.릴리즈 엔지니어링의 철학자기 주도 서비스 모델 : 릴리즈 프로세스는 자동화를 통해 엔지니어의 개입을 최소화하여 문제 발생하지 않는 이상 엔지니어가 개입할 필요가 없다빠른 릴리즈 주기밀폐된 빌드 : 빌드 프로세스의 결과물은 항상 동일해야 하기에 버전 관리를 통해 일관성을 유지한다원리와 절차의 강제 : 프로젝트 릴리즈 시 엄격한 관리 작업을 통해 문제가 발생했을..
Chapter 7 - The Evolution of Automation at Google📌Summary자동화의 필요성: 시스템 규모가 커지고 복잡해짐에 따라 수동 작업은 비효율적이며 휴먼 에러의 발생률이 높아진다. 자동화를 통해 일관성을 유지하고 운영의 신뢰성을 향상시킴자동화 사례: 클러스터 턴업 자동화를 통해 새로운 클러스터를 설정하는데 드는 시간을 줄이고 이를 통해 낮은 지연 시간을 가지는 클러스터를 구축할 수 있게 되었음. 클러스터 턴업 자동화가 더욱 발전하여 Borg가 되었고, 현재의 Kubernetes의 근간이 된 것 같다.실패 용인: 구글에서 진행한 자동화의 실패 사례를 설명해줌. 디스크삭제 프로세스 디버깅 중 스크립트가 운영 중이던 거의 모든 서버에 디스크삭제를 진행. 다행히(?) 소수의 ..
Chapter 5 - Eliminating Toil📌Summary삽질(Toil)의 정의프로덕션 서비스 운영과 직접적으로 연관이 존재수작업을 동반함자동화된 작업을 실행하기 위해 수작업으로 스크립트를 실행하는 것 또한 포함된다반복적임자동화가 가능함인간의 판단에 의해 실행되어야 한다면 삽질로 분류되지 않는다사후 대처가 필요함미리 처리할 수 있는 업무가 아니고 업무를 방해하며, 사후에 처리하게 되는 일이다지속적인 가치가 결여되어 있음특정 작업을 수행했음에도 서비스가 계속 같은 상태로 남아있는 경우서비스의 성장에 비례하여 증가함위의 조건들을 만족하는 업무들은 삽질이라고 정의한다.삽질이 줄어들면 좋은 이유삽질은 엔지니어의 시간을 소모하고, 자동화와 효율성을 저해하기에 삽질을 줄이거나 제거함으로써 엔지니어는 더 가..

LogQLLogQL은 Log Stream Selector를 통해 동작한다. Log Stream Selector는 ,로 분리된 여러 쌍의 Key-Value 형태로 명시된다. 여러 쌍의 Key-Value 데이터들을 { } 로 감싸서 Stream Selector를 구분하게 된다. Grafana에서 제공하는 intro-to-mltp 프로젝트에서 Builder를 통해 label을 선택하게 되면 아래쪽에 Log Stream Selector를 확인할 수 있다.{level="error", beast="beholder"} 위 예제의 Log Stream Selector는 모든 Log Stream들 중에서 명시된 Key-Value의 label들을 가지는 스트림들만 쿼리 결과에 포함시키게 된다. LogQL은 이외에도 여러 연..
Chapter 3 - Embracing Risk📌 SummarySRE 조직에서는 완벽한 가용성을 목표로 삼기보다는 비즈니스 목표와 사용자 기대치를 고려하여 적절한 수준의 신뢰성을 유지하는 것이 핵심이다. 모든 시스템의 가용성을 100%로 설정하려 하면 과도한 운영 비용이 발생할 수 있으며, 이는 불필요한 경우가 많다. 가용성 목표치를 100%로 맞추기 위해 더 많은 노력을 기울이는 대신, 일정 수준의 다운타임을 허용함으로써 운영 비용 절감과 새로운 기능 개발의 균형을 맞추려 한다. 서비스의 위험 수용도(Risk Tolerance) 를 정의할 때는, 해당 서비스의 기능과 시장 내 위치를 고려해야 하며, 소비자 대상 서비스인지 인프라스트럭처 서비스인지에 따라 차이가 발생한다. 예를 들어, 유튜브와 같은 소..

Project Architecture Diagram아래의 아키텍처는 Grafana에서 제공하는 intro-to-mltp라는 프로젝트의 아키텍처로, 본 글은 Grafana의 Loki, Grafana, Tempo, Mimir를 통해 해당 프로젝트에서 발생하는 에러의 원인을 파악하는 것을 목적으로 한다.Loki로그는 어디서든 발생할 수 있기 때문에 로그에서 특정한 내용을 찾으려고 할 때 다소 어려움이 존재할 수 있다. 또한 시스템의 가동 시간이 길어지고 사용량이 많아질 수록 기록이 방대해지면서 저장 공간의 필요성도 커지고 있다. 또한, 방대한 양의 로그를 어떤 식으로 결합하고 의미있는 방식으로 집계할지에 대한 고민이 필요하다.이에 더해, 영구적이지 않은 저장소에서 정보를 추출하는 것은 불확실성을 내포하고 있기..

Observability란?인체는 서로 다른 기능을 수행하는 여러 시스템으로 구성되어 있다. 소화계, 호흡계, 신경계, 근육 등 모든 시스템이 모여 하나의 인체를 형성한다.이중 하나 이상의 시스템이 제대로 동작하지 않을 때, 우리는 원인 모를 질병에 시달리거나 기력을 상실할 것이다. 이를 해결하기 위해 우리는 인체의 전문가 즉, 의사를 찾아간다. 의사는 인체의 체온, 혈압, 산소 수치 등과 같은 신체 지표를 우선 측정한다. 해당 진찰을 통해 우리의 신체 지표 중 이상이 발생한 부분을 발견하고 원인을 파악하기 위해 다양한 검진을 진행할 수 있다. 이를 통해 의사는 우리 인체 내부에서 무슨 일이 발생하는지 어디서 발생하는 지를 더 자세히 알아볼 수 있다. 또한, 이를 통해 의사는 문제를 해결하고 동일한 문제..

Chapter 1 - Introduction📌 Summary시스템의 복잡도와 트래픽이 증가할수록 서비스 관리의 어려움이 커지며, 운영팀과 개발팀 간의 상이한 목표로 인해 갈등이 자주 발생한다. Google은 이를 해결하기 위해 운영을 코드로 해결하는 엔지니어링 접근법을 도입했고, 이를 SRE(Site Reliability Engineering) 라고 명명했다. SRE의 도입으로 인해 제품 개발팀과 SRE팀 간의 손쉬운 업무 전환이 가능해져, 개발팀과 운영팀의 분리에서 발생하는 갈등이 완화되었다. 또한, SRE팀은 반복적인 운영 작업을 자동화하고 혁신적인 운영 방식으로 전환하는 역할을 수행한다.SRE팀은 개발팀의 목표인 빠른 개발 속도와 운영팀의 목표인 서비스 안정성 사이의 균형을 맞추기 위해 SLO(S..

buffers와 cached 영역커널은 디스크로부터 데이터를 읽거나 사용자의 데이터를 디스크에 저장한다. 하지만 디스크는 매우 느리고 I/O에 상당한 시간이 소요되기 때문에 커널은 디스크에 대한 요청을 빠르게 하기 위해 메모리의 일부를 디스크 요청에 대한 캐싱 영역으로 할당한다. 이때 커널이 디스크 캐싱을 위해 할당한 영역을 buffers와 cached라고 부른다.커널이 읽어야 할 데이터가 파일의 내용이라면 커널은 bio 구조체를 생성하고 해당 구조체에 Page Cache 용도로 할당한 메모리 영역을 연결해준다. bio 구조체는 디바이스 드라이버와 통신하여 디스크로부터 데이터를 읽어 Page Cache에 파일의 내용을 채운다. super_block, inode_block처럼 파일의 내용이 아닌 파일 시스..

top 명령어로 확인하는 프로세스 정보리눅스 환경에서 사용하는 top 명령어는 주로 동작하고 있는 프로세스의 정보를 손쉽게 확인하여 리눅스 시스템의 상태를 전반적으로 빠르게 확인할 수 있는 명령어다. top 명령어를 사용하게 되면 프로세스의 상태가 여러 수치들과 함께 화면에 표현되는데 이 수치들이 각각 어떤 의미를 가지고 있는지 알아보도록 하자.각 수치가 의미하는 정보현재 서버의 시간과 서버의 구동 시간이 표시된다.사용자가 몇 명이나 로그인해 있는지, 시스템의 Load Average는 어느 정도인지 보여준다.Load Average란 현재 시스템이 얼마나 많이 동작하고 있는지 보여주고 있는 지표로 해당 수치가 높으면 높을 수록 서버가 열심히 일하고 있다는 것을 의미한다.현재 시스템에서 구동 중인 프로세스의..