기록

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

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

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

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

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

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

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

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

이번 장에서는 긴급 대응이 필요했던 몇 가지 사례를 소개하고 있다. 1. 사례 1 - 사전 테스트 구글은 재난과 긴급 상황에 대한 사전적 테스트 접근법을 취하고 있다. SRE들은 시스템에 장애를 일으킨 후 이로 인해 시스템이 어떻게 실패하는지를 지켜본 다음, 그 현상이 반복해서 발생하지 않도록 신뢰성을 향상시킬 수 있는 변경 사항을 적용한다. 대부분의 경우 장애는 계획에 따라 제어가 가능하며 대상 시스템과 그에 의존하는 시스템들은 대체로 예상했던 대로 동작한다. 하지만 예상과 실제 결과가 어긋날 때가 있다. 사전 테스트에 포함되지 않은 내용으로 인해 테스트 수행 시 장애가 발생한 경우를 생각해보자. 장애가 발생한 이유가 무엇일까? 아마도 실제 환경에 존재하는 다양한 의존 관계에 대해서 고려하지 못했기 때..

이번 장에서는 장애 조치의 일반적인 과정에 대해 알아보도록 하자. 1. 이론 장애 조치 방법은 가설 연역 방법이라고 생각하면 된다. 장애의 잠재적 원인에 대해 가설을 세우고 가설을 시험하는 과정을 반복하기 때문이다. 가설을 검증하는 방법은 크게 두 가지가 존재한다. 관찰한 시스템의 상태를 이론과 비교하여 정황들이 들어맞는지 확인 시스템을 고쳐보고 그 결과를 다시 관찰 둘 중 어떤 방법을 사용하든, 근본 원인이 발견될 때까지 계속해서 테스트를 수행하고 원인이 발견되면 장애 재발을 방지하기 위해 그에 대한 조치를 수행한 후 포스트 모텀 문서를 작성한다. 2. 통상적인 문제 비효율적인 장애 조치 세션은 장애 등급 선정, 분석 및 진단 단계에 영향을 미친다. 이들 중 대부분은 시스템에 대한 깊은 이해가 부족해서..