기록

운영 업무의 부하 복잡한 시스템에서 운영 업무의 부하란 시스템이 제대로 동작하는 상태를 유지하기 위해 반드시 해야만 하는 일들을 의미한다. 복잡한 시스템을 만든 사람이 완벽하지 못한 만큼, 시스템 자체도 완벽할 수 없다. 이런 시스템에서 발생하는 운영 업무들을 관리하고 있다면, 그 시스템을 만든 사람 역시 완벽하지 않다는 점을 항상 기억하자. 운영 부하는 긴급 호출, 티켓, 진행 중인 운영 업무 세 가지로 분류할 수 있다. 긴급 호출 운영 환경에서 발생하는 경고나 장애에 대처하기 위한 것으로, 긴급한 상황이 발생했을 때 생겨난다. 이들은 대부분 단조롭고, 반복적으로 발생하며, 약간은 생각을 해야 한다. 긴급 호출은 그에 상응하는 기대 응답 시간(SLO)이 정해져 있으며, 대부분 분단위로 측정한다. 긴급 ..

인터넷 기업의 출시 주기 전통적인 기업들은 새 제품을 출시하는 비율이 상당히 낮다. 반면, 인터넷 기업의 출시 주기는 이와는 현저히 다르다. 제품을 신속하게 출시하는 것이 훨씬 쉬운데, 그 이유는 새로운 기능을 담은 소프트웨어를 고객의 개별 컴퓨터에 설치하는 것이 아니라 우리가 보유한 서버에 새로운 기능을 출시하는 것이기 때문이다. 이처럼 빠른 변화 속도는 능률적인 출시 절차를 정의해야 하는 근본적인 이유와 기회를 제공한다. 매 3년마다 새로운 제품을 출시하는 기업이라면 세밀한 출시 절차 따위는 필요치 않다. 출시 조율 엔지니어링 (LCE) 구글은 제품 출시의 어려움을 타개하기 위해 SRE 조직 내에 새로운 제품이나 기술을 출시하기 위한 기술적인 부분을 수행할 전문 컨설팅팀을 구성했다. 이들은 구글이 원..

분산 시스템 분산 컴퓨팅 또는 분산 데이터 베이스로 알려져 있다. 하나의 분산 시스템은 서로 다른 머신들에 위치해 있는 독립된 컴포넌트들의 묶음이며 이 묶음은 하나의 공통된 목적을 달성하기 위해 서로 메시지를 주고받는다. 분산에 대한 합의 신뢰할 수 있는 고가용성 시스템을 효과적으로 구축하기 위해 분산에 대한 합의가 필요하다. 분산에 대한 합의 문제는 신뢰할 수 없는 네트워크에 연결된 프로세스의 그룹들이 원하는 수준의 합의점에 도달하는 문제를 다루는 것이다. 예를 들어 분산 시스템의 여러 프로세스들은 분산 록이 발생했든, 아니면 큐의 메시지가 이미 처리되었든지 여부와는 무관하게 설정 중에서 중요한 부분들을 일관되게 확인할 수 있어야 한다. 이는 분산 컴퓨팅 분야에서는 매우 기본적인 개념이다. CAP 이론..

연속적 장애는 정상적인 것처럼 보이는 응답 때문에 시간이 지나면서 장애가 계속해서 가중되는 현상이다. 전체 시스템의 일부에서 장애가 발생했을 때 주로 나타나며, 이로 인해 시스템의 다른 부분에 장애가 발생할 가능성도 늘어나게 된다. 연속적 장애의 원인과 대책 서버 과부하 연속적 장애를 유발하는 가장 일반적인 원인은 과부하다. 예를 들어 한 클러스터에서 과부하가 발생하면 그 서버들이 충돌로 인해 강제로 종료되게 되고 그 여파로 로드밸런싱 컨트롤러가 요청을 다른 클러스터에 보내면 그쪽의 서버들에게 과부하가 발생하고 결국 서비스 전체에 걸친 과부하 장애가 발생한다. 자원의 부족 자원 부족으로 인해서 높은 지연응답과 에러율의 증가 혹은 낮은 품질의 응답을 야기할 수 있다. 이러한 현상이 발생하면 성공적으로 처리..

로드밸런싱 정책의 목적은 과부하를 피하기 위함이다. 이번 장에서는 과부하를 처리하는 다양한 방법에 대해서 알아보도록 하자. 경감된 응답 리턴 평상시의 응답보다 정확도가 조금 떨어지거나 혹은 더 적은 데이터를 제공하는 것이다. 이렇게 하면 연산을 수행하기가 더 쉬워진다. 하지만, 과부하가 극심한 경우에는 서비스가 경감된 응답조차도 연산하고 서비스할 수 없을 수도 있다. 이런 상황에서는 에러를 리턴하는 것 외에는 신속하게 대처할 수 있는 방법이 없다. 물론 데이터센터 자체에서 수용량을 넘어서는 트래픽을 전달받지 않도록 하면 해결 되기는 한다. 초당 쿼리 수의 함정 쿼리는 종류에 따라 요구하는 자원이 상당히 다르다. 따라서 초당 쿼리 수를 통해 수용량을 모델링하면 실망스러운 결과를 볼 수 있다. 더 나은 방법..

이번 장에서는 데이터센터 내에서의 로드밸런싱에 대해 알아보도록 하자. 특히 지정된 데이터센터 내에서 쿼리 스트림을 효과적으로 분산 처리하기 위한 알고리즘과 요청이 유입될 때 이를 처리할 수 있는 개별 서버로 라우팅 하는 애플리케이션 수준 정책에 대한 내용을 중점적으로 살펴보자. 양호하지 않은 태스크 구별하기 클라이언트의 요청을 어느 백엔드가 처리할 것인지 결정하기 위해서는 그 전에 백엔드 풀에서 양호하지 않은 태스크를 식별할 필요가 있다. 1. 흐름 제어 활성화된 요청의 개수가 설정된 한계 값을 넘어서면 클아이언트는 백엔드가 양호하지 않은 상태에 있다고 가정하고 더 이상 요청을 전달하지 않는다. 이와 같은 엄청 간단한 흐름 제어는 간단한 형태의 로드밸런싱이라고 보아도 무방하다. 위 방법은 매우 높은 수준..

이번 장에서는 사용자 트래픽을 여러 데이터센터에 조절해서 전달하는 로드밸런싱에 대해 간략하게 알아보도록 하자. 모든 일을 힘으로만 해결할 수는 없는 법 현실적으로 절대 장애가 일어나지 않는 네트워크는 존재하지 않는다. 따라서 장애가 최대한 적게 나도록 구조를 개선해야 하는데 로드밸런싱이 큰 역할을 수행한다. 예를 들어서 특정 요청을 어느 데이터센터에 얼마나 많은 서버들이 처리할 것인지를 결정하기 위해 트래픽 로드밸런싱을 도입하기도 한다. 요청의 종류는 다양하겠지만 검색, 비디오 요청은 아래와 같은 처리가 필요하다. 검색 요청: 요청에 대한 지연응답 시간을 최소화하기 위해 라운드트립 타임(round-trip time, RTT)을 측정해서 가장 가까운 데이터센터로 보내야 한다. 비디오 요청: 지연응답 시간을..

이번 장에서는 SRE 조직 구성원들이 소프트웨어 엔지니어링을 수행한 이유와 결과에 대해서 알아보도록 하자 SRE 조직의 소프트웨어 엔지니어링 역량이 중요한 이유 구글은 필요로 하는 규모를 감당할 수 있는 서드파티 도구를 찾기 힘들어서 다양한 형태의 소프트웨어 개발이 내부적으로 이루어지고 있다고 한다. 그리고 SRE는 아래와 같은 이유로 인해서 내부 소프트웨어를 개발하기에 아주 적합하다고 한다. (결론은 잘해서인 것 같다.) 구글만의 프로덕션 환경에 대한 SRE 조직의 폭넓고 깊은 지식 SRE들은 중요한 사안에는 모두 참여하므로 개발할 도구의 목적과 요구사항을 손쉽게 이해 SRE의 가이드 원리 중 하나는 "팀의 규모는 서비스의 성장률과 직접적으로 비례해서는 안 된다"는 것이다. 폭발적으로 성장하는 서비스에..

이번 장에서는 소프트웨어 테스트 종류에 대해서 알아보고, 테스트의 목적이 무엇인지에 대해서 생각해보는 시간을 가져보도록 하자. 소프트웨어 테스트의 종류 소프트웨어 테스트는 전통적인 테스트와 프로덕션 테스트로 분류할 수 있다. 소프트웨어를 개발하는 동안 소프트웨어가 올바른 동작을 수행하는지 여부를 평가하는 전통적인 테스트가 조금 더 일반적인 편이다. 프로덕션 테스트는 실제 동작하는 웹 서비스에 대해 배포된 소프트웨어 시스템이 올바르게 동작 중인지를 판단하는 테스트다. 전통적인 테스트 전통적인 테스트에는 단위, 통합, 시스템 테스트가 존재한다. 단위 테스트 가장 작으면서도 간단한 소프트웨어 테스트 기법이다. 소프트웨어의 특정 단위, 예를 들면 클래스나 함수 등을 테스트하여 이 단위들로 구성된 전체 소프트웨어..

지속적으로 신뢰성을 개선하는 것은 기준을 명확히 하고 절차를 추적할 수 있을 때만 가능하다. 이를 위해 구글에서는 '아우터레이터'라고 부르는 서비스 중단 현상 추적 도구를 사용한다. 이번 장에서는 아우터레이터를 통해 시스템 중단 추적에 대해서 알아보도록 하자. 1. 에스컬레이터 구글에서는 SRE를 위한 모든 알림은 사람이 알림의 수신을 확인했는지 여부를 추적하는 중앙 응답 시스템을 공유하고 있다. 설정된 시간이 지나도 아무도 수신을 확인하지 않으면 시스템은 설정된 다음 단계로 알림을 격상한다. '에스컬레이터'라고 부르는 이 시스템은 비상 대기 엔지니어에게 전달된 이메일의 복사본을 수신하는 투명한 도구로 기획된 것이다. 이 기능 덕분에 사용자의 반응이 없어도 에스컬레이터가 손쉽게 기존의 업무 흐름에 통합될..