클라우드 시스템을 관리하는 기술

도서 정보

Can't load image — <도서 이미지>

표제/저자사항	클라우드 시스템을 관리하는 기술 / 토머스 리몬첼리,스트래치 체일럽,크리스티나 호건
ISBN 정보	978-89-6848-261-8 [93000]
발행사항	한빛미디어(주), 발행일 : 2015년 02월 25일

소개

사업 목표 : 잘 정의된 사업 목표들은 측정 가능하며, 측정치를 자동으로 수집하여 현황판(dashboard)를 만들 수 있다
이상적인 시스템 구조

SOA(Service-oriented architecture) : 서비스를 구성하는 각 하위 시스템은 그 자체로도 서비스다
IaC(Infrastructure as code) : 코드로 작성된 인프라를 이용해 자동으로 프로덕션 환경을 구축한다

이상적인 릴리스 과정

코드를 체크인하면 자동으로 기능 테스트가 실행된다
기능 테스트를 통과하면 자동으로 패키지 빌드 -> 테스트 환경 구축 -> 통합 테스트를 진행한다
통합 테스트를 통과하면 프로덕션으로 n% 롤아웃한다
장애가 검출되지 않으면 점직적으로 100% 롤아웃 전환한다

이상적인 운영

덜 자주 발동하는 대응책들에 대해 주기적으로, 자동으로 장애를 일으킨다
개발자와 운영자는 별개의 팀이 아니다

분산 세계에서의 설계

분산 시스템의 구성요소들은 자신의 건강을 검진하고 그 결과를 가시화한다
디버깅은 코딩보다 어렵다. 설계를 단순화하는 데 들이는 시간은 운영 시 보상으로 돌아온다
CAP 원리

Consistency, Availability, Partition resistance 모두를 보장하는 분산 시스템은 존재할 수 없다

일관성 : 모든 노드는 특정 시점에 모두 동일한 자료를 본다 -- 연산은 원자적
가용성 : 모든 요청이 성공/실패에 대한 응답을 받는다
분리 저항 : 일부 노드가 분리되더라도 시스템이 작동한다

분리의 예 : 노드들이 두 그룹으로 분리되어 마스터 노드가 2개 이상이 되는 상황

CA 시스템 예 : Oracle, MySQL, PostgreSQL

ACID; Atomicity, Consistency, Isolation, Durability

CP 시스템 예 : Hbase, Redis, Bigtable

BASE; Basically Available Soft-state services with Eventual consistency

AP 시스템 예 : Cassandra, Riak, Dynamo

일부 클라이언트가 이전 버전의 데이터를 응답받는 것을 허용

운영을 위한 설계

대기열 배출 : 종료 전, 기존 요청 대기열은 모두 처리
개별 기능 켜고 끄기 : 임의 시각을 기점으로 기능을 on/off
우아한 강등 : 서비스를 제공할 수 없는 경우, 제한된 서비스를 제공하거나, 임시 정적 응답이라도 제공
접근 제어, 속도 제한 : 사용자별로 API 접근 허용, 사용 비율 제한을 결정하는 ACL(Access control list)을 관리
대형 시스템에서는 개별 모듈 단위로 디버깅 로그를 활성화할 수 있어야 한다
시스템 작동 상황 감시
보안 및 법규 준수 감사

서비스 플랫폼 선택

코로케이션은 클라우드 환경으로 간주되지는 않지만, 서비스를 공급하는 데 유용한 방법의 하나다

코로케이션 : 데이터센터 임차

일찍 시작한다 : 기회비용이 가장 큰 비용이 되는 경우가 많다
고정 수용량은 조직 내에서 처리하고, 초과 분량만 클라우드로 처리하는 것이 비용 효율적

응용 프로그램 구조

3-tier 웹 서비스 : 로드밸런서 + 웹 서버 + DB
4-tier 웹 서비스 : 로드밸런서 + 웹 서버 + 응용 서버 + DB

웹 서버에서 모든 전처리를 수행. 이 구조에서는 웹 서버 ↔ 응용 서버 간 통신은 굳이 최신 프로토콜을 사용하지 않아도 괜찮다

인증서 관리 : 최고의 보안 정책은 모든 달걀을 한 바구니에 담고, 그 바구니를 아주 튼튼하게 만드는 것이다

서비스 계층을 늘리면 외부에 노출되는 잠재적인 보안 취약 면적이 줄어들 수 있다

메시지 버스 시스템 사용 시, 메시지들이 순차적으로 수신되지 않을 수 있음에 유의
SOA best practice

모든 API는 동일한 기저 RPC 프로토콜을 사용한다
모든 서비스를 동일한 방식으로 모니터링할 수 있다
서비스들은 최대한 동일한 기법으로 구현한다; 로드 밸런싱, 코딩 규약 등

강결합 시스템을 SOA로 마이그레이션 할 때, 가장 쉬운 모듈을 찾기보다는 가장 필요한 부분을 찾는 게 맞다

규모 확장

모든 시스템에는 필연적으로 병목 또는 제약이 있다. 하지만 이는 시스템이 목표를 달성하는 능력에 해가 될 때만 문제점이 된다

너무 빨리 바로잡는다면, 절대 나타나지 않을 문제에 노력을 낭비하는 것일 수 있다

AKF scaling cube

x축 > 수평 중복 > 서비스를 복제하여 처리량을 늘린다. 트랜잭션이 독립적으로 처리될 수 있다면, 성능 향상은 복제본 개수에 비례한다

CPU, RAM 증설도 이에 포함

y축 > 기능 또는 서비스 분할 > 시스템의 결합성을 낮춘다 or 요청 종류에 따라 핸들러를 분할한다

전자의 예 : 단일 컴퓨터로 웹 서버, DB 서버 등을 모두 구동하던 상황에서 각각에 개별 머신을 할당
후자의 예 : 중요한 요청에 대해 전용 컴퓨팅 풀로 처리, 검색엔진 요청은 캐시 없는 고지연 머신으로 처리

z축 > lookup-oriented split > 자료를 segment로 분할하고, 각 세그먼트에 전용 자원을 할당

탄력성을 위한 설계 패턴

규모가 큰 시스템에서는 발생 확률이 백만분의 1인 장애가 매일 발생한다
탄력적인 시스템은 장애가 서비스 중단으로 이어지지 않도록 구성요소를 분리한다
같은 공장에서 같은 시기에 만들어진 부품들이 동시에 고장나는 일도 발생할 수 있다
Watchdog timer : 하드웨어 클록 하나가 카운터를 계속 증가하고, 임계값을 넘기면 시스템 재시작 -- 소프트웨어는 연산이 성공할 때마다 카운터를 0으로 초기화
Canary request : 새로운 요청은 사전에 지정된 서버들로 보내고, 적절한 시간 이내에 정상 처리될 때만 다른 서버들로도 요청 전달
로드밸런서 자체도 단일 고장 지점이 될 수 있다