Release 의 모든 것 (10장)

Release 의 모든 것 (10장) 의 내용 중, 인상적이었던 부분을 발췌 및 요약합니다.

제어 평면

제어 평면은 운영 부하를 성공적으로 수행하기 위해 이면에서 작동하는 모든 소프트웨어와 서비스를 포괄하는 용어다.

적합도 평가

제어 평면의 모든 요소는 선택 사양이다. 제어 평면이 정교해질수록 구현과 운영 비용이 더 들어간다.
제어 평면의 구성 요소가 운영 비용을 지속적으로 발생시키므로 전담 인력에 드는 고정비와 배치 속도 향상, 사고 복구 등에 드는 변동비 간에 절충점을 찾아야 한다.

사람의 실수가 아닌 시스템 장애

어떤 차이나 이상 현상이 발생했으면 그것으로 배울 수 있다. 항상 확인하고, 위기 일발의 상황을 어떻게 알아차렸으며 해를 막는데 어떻게 도움이 됐는지를 살펴봐라

자동화 진행 속도

자동화에는 판단 능력이 없다. 자동화가 진행되면 인간이 개입하기엔 늦을 만큼 빠르게 문제가 번지긴 한다.
반복 작업과 빠른 응답 같이 인간이 잘못하는 일에 자동화를 사용하고, 더 높은 수준에서 인식하는 일과 같이 자동화가 잘 하지 못하는 일에 인간을 활용해야 한다.

플랫폼과 생태계

모니터링 팀이 해야 하는 일은 모니터링이 아니다. 다른 사람들이 직접 모니터링을 할 수 있게 만들어준다. 이는 책임의 전환이다.
고객 중심 모델의 측면에서 모니터링 팀이 모니터를 구현하는 것은 아니다. 플랫폼 팀의 목표는 고객을 지원하는 것이다.

운영 수준 개발 환경

개발 서버는 대부분의 경우, 빈민굴이다. 잘 구성된 깔끔한 가상 머신에서 개발하는 것이 아니라 온갖 코드가 붙어있는 지저분한 개발 환경인 것이다.
개발 플랫폼은 소프트웨어 제작을 위한 운영 환경이다.

실사용자 모니터링

사용자가 좋은 경험을 하고 있는지 직접 측정해야 하며 이를 실사용자 모니터링 (RUM) 이라고 한다.
데이터독과 같은 서비스를 사용하는 것이 부담스럽다면 오픈 소스를 사용할 수 있다. 오픈 소스는 월 서비스 사용료를 아낄 수 있지만 눈에 보이지 않는 인건비와 인프라의 형태로 비용이 발생한다.

경제적 가치

소프트웨어는 경제적 가치 창출이 목적이다. 예를 들어, 수익 창출 서비스에서 예외가 발생한다면 이는 곧 경제적 손실이다.
대기열의 길이가 길어진다면 이는 매출에 영향을 미칠 것이다. 비용도 운영에서 발생하고, 운영하기 어려운 소프트웨어일수록 사람의 시간(인건비)을 더 많이 빼았는다.
성능을 개선하거나, 대기열을 줄이거나, 병목 현상을 예방하는 것이 곧 매출의 향상이다.

파편화의 위험

조직마다 다른 시각이 필요하다. CEO 에게 다량의 CPU 사용량 그래프가 어떤 의미를 가질까? 마케팅 조직에게는?
회사의 그룹마다 선호하는 대시보드가 있을 것이고, 확인하고 싶어하는 지표가 다를 것이다.

로그와 통계

로그 수집기는 푸시 모드와 풀 모드가 있다. 푸시 모드는 중앙 시스템에 각 인스턴스가 로그를 밀어 넣어주는 것이고, 풀 모드는 중앙 시스템의 수집기가 호스트의 로그를 복사하는 것이다.
이 모드에서는 각 서비스가 로그를 로컬 파일에 남기기만 하면 된다. 로그를 수집한 이후에는 분석을 통해서 유의미한 패턴을 찾아야 한다.

수집 대상 측정값 선정

시스템의 어떤 측정값이 문제가 될지 알기 어렵다. 추측이 틀릴 가능성이 높기 때문이고, 미래의 문제가 오늘 드러나지 않기 때문이다. 유용할 수 있는 측정값은 다음과 같다.

• 트래픽 측정값 : 페이지 요청, 총 페이지 요청, 트랜잭션 수
• 유형별 비즈니스 거래 : 처리된 거래 수, 중단된 거래 수, 전환율
• 사용자 : 인구 통계 또는 분류, 기술 통계
• 자원 풀 상태 : 사용 상태, 총 자원 수(작업 스레드 풀 등), 체크아웃된 자원
• 데이터 베이스 연결 상태 : 발생한 SQLException 수, 쿼리 수, 쿼리에 대한 평균 응답 시간
• 데이터 소비 : 존재하는 엔티티 또는 행 수, 메모리 및 디스크 공간
• 통합 포인트 상태 : 회로 차단기 상태, 시간 초과 수, 요청 수
• 캐시 상태 : 캐시에 있는 항목, 캐시에서 사용하는 메모리, 캐시 적중률

이처럼 중간 규모의 시스템에도 측정값이 수백 가지일 수 있다. 이 측정값의 허용 오차나 임계치를 설정하고 위험 신호와 정상 신호를 구분하자.

구성 서비스

구성 서비스는 코드로 구축된 것이고, 확장 가능하지만 탄력적이지 않다.
노드를 추가하는 경우, 클러스터가 새 노드를 수락하거나 기존 노드가 제거됐다는 것을 알기 위해서 관리자의 작업이 필요할 수도 있다. 구성 서비스는 네트워크의 취약점을 가지고 있다. 구성 서비스와 관련된 지침은 다음과 같다.

• 구성 서비스가 없어도 인스턴스가 시작될 수 있어야 한다.
• 구성을 얻을 수 없어도 인스턴스의 작동이 중지되어서는 안된다.
• 클러스터에서 분리된 구성 노드 때문에 전체 시스템이 종료될 가능성이 있는지 확인해야 한다.
• 여러 지역에 복제본을 만들어두어야 한다.

프로비저닝과 배치 서비스

배치 도구는 푸시와 풀 방식으로 구분된다. 푸시는 중앙 서버가 대상 서버의 스크립트를 실행하는 방식이고, 풀 기반은 기기에서 구성 서비스에 접속해서 자신의 역할을 확인한다. 풀 기반 도구는 특히 탄력적 확장과 함께 잘 작동한다.
카나리 배치는 신규 빌드를 작은 인스턴스에 먼저 배포해서 문제를 테스트할 수 있는 방법이다.

명령과 제어

변경된 구성을 모두 적용한 뒤, 인스턴스를 재시작하는 것보다 인스턴스의 기능을 제어하는 것이 효율적일 수도 있다.

제어 항목

제어 항목의 예시는 다음과 같다.

• 회로 차단기의 재설정
• 연결 풀 크기와 제한 시간을 조정
• 특정 외부 연동을 비활성화
• 구성을 다시 읽는다

모든 서비스가 제어를 필요로 하지는 않지만, 좋은 출발점이 될 수 있다.

명령 전달 방법

제어를 노출하더라도 HTTP 를 통해 관리용 API 호출 이상의 방법을 적용해 볼 수 있다. 명령 대기열을 사용해서, 모든 인스턴스가 수신 대기하는 공유 메시지 대기열을 고려해보자.
명령 대기열을 사용하면 도그파일이 발생할 수 있기에 각각의 인스턴스마다 지연 시간을 추가해서 조금씩 분산되도록 하자. 그룹으로 나누는 것도 좋다.

플랫폼 제품

솔루션을 직접 조립하는 것보다 플랫폼을 구축하는 것이 편리할 수도 있다. 오픈 소스 플랫폼과 솔루션을 적극적으로 받아들여보자.