『클라우드 시스템을 관리하는...

클라우드 시스템을 관리하는 기술 :클라우드 관리자가 알아야 할 웹 규모 분산 시스템 설계와 운영

초판발행 2016년 02월 25일

지은이 토머스 리몬첼리, 스트래터 체일럽, 크리스티나 호건 / 옮긴이 류광 / 펴낸이 김태헌

펴낸곳 한빛미디어 (주) / 주소 서울시 마포구 양화로 7길 83 한빛미디어(주) IT출판부

전화 02 – 325 – 5544 / 팩스 02 – 336 – 7124등록 1999년 6월 24일 제10 – 1779호 / ISBN 978-89-6848-261-8 93000

총괄 전태호 / 책임편집 김창수 / 기획 이복연

디자인 표지 강은영, 조판 이경숙

영업 김형진, 김진불, 조유미 / 마케팅 박상용, 송경석, 서은옥, 변지영 / 제작 박성우

이 책에 대한 의견이나 오탈자 및 잘못된 내용에 대한 수정 정보는 한빛미디어(주)의 홈페이지나 아래 이메일로

알려주십시오. 잘못된 책은 구입하신 서점에서 교환해드립니다. 책값은 뒤표지에 표시되어 있습니다.

한빛미디어 홈페이지 www.hanbit.co.kr / 이메일 [email protected]

THE PRACTICE OF CLOUD SYSTEM ADMINISTRATION: DESIGNING AND OPERATING

LARGE DISTRIBUTED SYSTEM, VOLUME 2 by THOMAS A. LIMONCELLI, STRATA R. CHALUP,

CHRISTINA J. HOGAN.

Authorized translation from the English language edition, entitled THE PRACTICE OF CLOUD

SYSTEM ADMINISTRATION: DESIGNING AND OPERATING LARGE DISTRIBUTED

SYSTEM, VOLUME 2, 1st edition by THOMAS A. LIMONCELLI, STRATA R. CHALUP,

CHRISTINA J. HOGAN, ISBN 978-0321943187, published by Pearson Education, Inc, publishing

as Addison-Wesley Professional, Copyright © 2015.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any

means, electronic or mechanical, including photocopying, recording or by any information storage

retrieval system, without permission from Pearson Education, Inc. KOREAN language edition

published by HANBIT MEDIA INC., Copyright © 2016.

이 책의 저작권은 오라일리와 한빛미디어 (주)에 있습니다.

저작권법에 의해 보호를 받는 저작물이므로 무단 복제 및 무단 전재를 금합니다.

지금 하지 않으면 할 수 없는 일이 있습니다.

책으로 펴내고 싶은 아이디어나 원고를 메일 ( [email protected] ) 로 보내주세요.

한빛미디어(주)는 여러분의 소중한 경험과 지식을 기다리고 있습니다.

4

지은이 토머스 A. 리몬첼리Thomas A. Limoncelli

국제적으로 유명한 저자이자 강연자, 시스템 관리자이다. Google NYC에서 7년간 재직하면서 구

글 블로그 검색(Google Blog Search )이나 Ganeti 같은 프로젝트들과 구글 내부의 여러 전사

적 IT 서비스들을 위한 SRE (사이트 신뢰성 기술자)로 일했다. 현재 그는 ServerFault.com과

StackOverflow.com의 모회사인 Stack Exchange, Inc.에서 SRE로 일하고 있다. 1987년

Drew University 재학 중에 처음으로 유급 시스템 관리 일을 한 그는 이후 AT&T/Lucent Bell

Labs를 비롯한 크고 작은 회사들에서 일했다. 유명 저서로는 Time Management for System

Administrators (O’Reilly )와 The Practice of System and Network Administration

제2판(Addison-Wesley ) 등이 있다. 여가 시간에는 풀뿌리 운동(grassroots activism )에도

참여하는데, 그의 노력은 주(state )와 미국 전체 수준에서 알려졌다. 현재 미국 뉴저지에서 살고

있다.

지은이 스트래터 R. 체일럽Strata R. Chalup

수년간 복잡한 IT 프로젝트들을 지휘, 관리하면서 프로젝트 관리자에서 운영 책임자에 이르기까

지 다양한 역할을 수행했다. 스트래터는 팀 관리와 협동에 관한 수많은 글을 썼으며, 자신의 관리

능력을 BayLISA와 SAGE를 비롯한 여러 자원봉사 단체들에 적용했다. 1983년 그녀는 보스턴

의 MIT에서 VAX Ultrix와 Unisys UNIX의 관리를 시작했으며, 닷컴 시절에는 실리콘 밸리에서

iPlanet과 Palm 같은 고객사들을 위해 인터넷 서비스를 구축했다. 2007년에는 톰(토머스 A. 리

몬첼리)과 크리스티나와 함께 The Practice of System and Network Administration 제2판

(Addison-Wesley )을 저술했다. 취미로는 Arduino와 여러 2차원 CAD/CAM 장치들을 비롯

한 새로운 기술들을 배우는 것과 원예전문가(master gardener )가 되는 것을 들 수 있다. 현재 미

국 캘리포니아의 산타클라라 카운티에 살고 있다.

지은이·옮긴이 소개

5

지은이 크리스티나 J. 호건Christina J. Hogan

실리콘 밸리와 이탈리아, 스위스에서 20년 간 시스템 관리와 네트워크 관리를 수행한 경력이 있

다. 그녀는 작은 신생기업은 물론 중간 크기의 기술 기업과 다국적 대기업들에서 경험을 쌓았

다. 크리스티나는 수년간 보안 컨설턴트로 일했는데, 고객사로는 eBay, Silicon Graphics,

SystemExperts 등이 있다. 2005년에 그녀와 톰은 저서 The Practice of System and

Network Administration (Addison-Wesley )으로 SAGE Outstanding Achievement

Award를 공동 수상했다. 그녀는 수학 학사 학위와 컴퓨터 과학 석사 학위, 항공공학 박사 학위를

가지고 있으며, 법학 과정도 졸업했다. 또한 그녀는 6년간 포뮬러 1 레이싱 팀에서 공기역학자로 일

했으며, 1988년 체스 올림피아드에 아일랜드 대표로 참가했다. 현재 스위스에서 살고 있다.

옮긴이 류광

옮긴이 류광은 1996년부터 활동해 온 프로그래밍 서적 전문 번역가로, Game Programming

Gems 시리즈와 컴퓨터 프로그래밍의 예술(The Art of Computer Programming ) 제1~4A권,

UNIX 고급 프로그래밍(Advanced Programming in UNIX Environment ) 제2판과 제3판,

Effective Modern C++을 포함해 60여 권의 다양한 IT 전문서를 번역했다. 번역과 프로그래밍 외

에 소프트웨어 문서화에도 많은 관심이 있으며, 수많은 오픈소스 프로젝트들의 표준 문서 형식으로

쓰이는 DocBook의 국내 사용자 모임인 닥북 한국(http://docbook.kr )의 일원이다. 현재 번

역서 정보 사이트 occam’s Razor (http://occamsrazr.net )와 게임 개발 및 개발서 관련 사

이트 GpgStudy (http://www.gpgstudy.com )를 운영하고 있다.

6

C++의 창시자 비야네 스트롭스트룹Bjarne Stroustrup은 자신의 저서 Programming - Principles

and Practice Using C++(번역서는 (C++로 배우는)프로그래밍의 원리와 실제, 류광 옮김)에서

“우리 문명은 소프트웨어를 바탕으로 돌아간다”라고 말했습니다. 현재 그러한 소프트웨어의 상당

부분은 최종 사용자와는 떨어져 있는 ‘구름’, 즉 클라우드 시스템 안에서 돌아가고 있으며, 점점 더

많은 소프트웨어와 자료가 점점 더 빨리 구름 안으로 이주할 것입니다. 그런 만큼 클라우드 시스템

을 개발하고 관리, 운영하는 사람은 단지 자신의 조직의 이익을 위해 일하는 사람이 아니라, 어쩌면

문명의 유지와 발전에 큰 몫을 담당하는 사람일 것입니다. 저자들도 아마 그런 자부심을 가지고 이

책을 저술했으리라 짐작합니다. 나중에 독자가 ‘맺음말(p.533 )’을 그런 자부심과 자신감을 느끼면

서 읽을 수 있게 된다면 더 바랄 것이 없겠습니다.

독자가 본문을 거쳐서 맺음말에 무사히 도달하고 그 뒤의 부록들까지 충실하게 읽으려면 번역

품질에 문제가 없어야 할 텐데, 어떨지 모르겠습니다. 항상 그렇지만 번역과 교정을 마치고 옮긴이

의 말을 쓸 때에는 번역과 교정에 좀 더 많은 시간을 들일 수 있었다면 하는 아쉬움을 느낍니다. 특

히 이 책은 통상적인 소프트웨어 개발이나 프로그래밍 이외의 여러 분야(경영학, 산업공학, 공공안

전 등등)에서 쓰이는 용어들이 많이 등장해서 번역하기가 쉽지 않았습니다. 가능하면 해당 분야에

서 흔히 쓰이는 용어를 존중하되, 전체적인 어법과 잘 맞지 않거나 다른 분야의 용어와 충돌하는 등

그대로 가져다 쓰기가 좀 곤란할 때에는 기존 용어의 조어법을 참고해서 새로운 용어를 만들기도 했

습니다. 부연 설명이 필요한 경우에는 역주를 추가하기도 했지만 충분치는 않을 것입니다. 부족한

부분은 제 홈페이지 occam’s Razor (http://occamsrazr.net/ )의 ‘번역서 정보’ 페이지에서

접근할 수 있는 이 책 페이지를 통해서 함께 논의했으면 합니다.

감사 인사로 옮긴이의 말을 마무리하겠습니다. 제게 번역을 맡겨 주신 최현우 님과 번역 및 교

정 과정을 매끄럽게 이끌어 주신 이복연 님 고맙습니다. 그리고 조판을 맡아주신 이경숙 님을 비롯

한, 출판 전과정에서 제가 미처 알지 못하는 여러 작업을 충실히 수행해서 이 책의 출판을 현실로 만

든 모든 관련자 분께 감사 인사 올립니다. 마지막으로, 최종 결과물만 봐서는 상상하기 힘든 황당한

오타와 오역을 수없이 잡아 준 아내 오현숙에게 감사와 사랑의 마음을 전합니다.

_ 류광

옮긴이의 말

7

다음 중 참인 문장은 무엇인가?

1. 신뢰성이 아주 높은 시스템은 싸고 신뢰성 없는(unreliable ) 구성요소들로 만들어진다.

2. 구글Google이 수십억의 사용자에 맞게 규모를 변화시키는 데 사용하는 기법들은 수백 명의

사용자를 감당하는 시스템의 규모 변화(scaling )에 사용할 수 있는 기법들과 동일한 패턴

을 따른다.

3. 어떤 절차가 위험할수록 그 절차를 자주 수행해야 한다.

4. 가장 중요한 소프트웨어 기능 중에는 사용자가 결코 보지 못하는 것들도 있다.

5. 무작위로 컴퓨터를 선택해서 전원을 꺼야 한다.

6. 6개월 이내에 공개될 페이스북Facebook의 모든 기능의 코드가 독자의 브라우저 안에 이미 들

어 있을 가능성이 크다.

7. 하루에 소프트웨어를 여러 번 갱신하는 데에는 사람의 노력이 거의 필요하지 않다.

8. 호출대기 중이라고 해서 반드시 스트레스를 받거나 일이 힘들어야 하는 것은 아니다.

9. 기계(컴퓨터)가 작동 중인지를 사람이 감시할 필요는 없다.

10. 실험과 증거가 관여하는 과학적 원리들을 이용해서 운영과 관리를 수행하는 것이 가능하다.

11. 구글은 좀비들이 쳐들어왔을 때의 대응 방안에 관한 예행연습을 수행한 적이 있다.

이 문장들은 모두 참이다. 이 책을 다 읽고 나면 왜 그런지 알게 될 것이다.

이 책은 대규모 클라우드 기반 서비스, 즉 수백만 또는 수십억의 사용자들을 위한 인터넷 기반

서비스의 구축과 운영에 관한 책이다. 해당 기법들을 채용하는 기업들이 매일같이 늘어난다는 점에

서, 이 책은 모든 사람을 위한 책이라 할 수 있다.

이 책의 대상 독자는 시스템 관리자(system administrator )들과 그들을 관리하는 관리자

(manager )들이다. 독자가 컴퓨터 과학에 대한 배경 지식을 갖추고 있다고 가정하지는 않지만,

UNIX/Linux 시스템 관리와 네트워킹에 관한 경험이 있고 운영 시스템 개념들에 익숙하다고 가정

한다.

서문

8

이 책의 초점은 클라우드 기반 서비스의 사용법이 아니라, 그런 클라우드를 구성하는 서비스들

을 구축하고 운영하는 방법이다.

클라우드 서비스는 항상 사용 가능해야(가용성) 하고 빨라야(속도) 하며 안전해야(보안) 한

다. 클라우드 규모에서 이들을 모두 달성하는 것은 공학적으로 대단히 어려운 일이다. 따라서 클라

우드 규모 서비스는 전형적인 전사적(enterprise ) 서비스와는 다른 방식으로 설계해야 한다. 가용

성이 중요한 것은, 인터넷이 24×7 (하루 24시간, 주 7일)로 열려 있고 모든 시간대에 사용자들이

있기 때문이다. 속도가 중요한 것은, 서비스가 느리면 사용자들이 짜증을 내며, 결과적으로 더 빠른

경쟁 서비스에 밀려나기 때문이다. 보안이 중요한 것은, 우리는 다른 사람들의 자료를 관리하며, 따

라서 다른 사람의 자료를 보호할 의무가 있기(법적으로나 도의적으로나) 때문이다.

이러한 요구사항들은 서로 맞물려 있다. 가용성의 정의로 볼 때, 안전하지 않은 사이트는 가용

성이 없는 것이다. 그리고 빠르지 않은 사이트는 가용성이 충분치 않은 것이다. 속도의 정의로 볼

때, 가동이 중단된 사이트는 빠르지 않은 것이다.

클라우드 규모 서비스들 중 일반 사용자들의 눈에 가장 잘 띄는 것은 웹사이트이다. 그러나 인

터넷으로 접근하긴 하지만 웹 브라우저로 접근하는 것이 아닌, 보이지 않는 인터넷 기반 서비스들의

거대한 생태계가 존재한다. 예를 들어 스마트폰 앱들은 API 호출을 통해서 클라우드 기반 서비스들

에 접근한다.

이 책의 나머지 부분에서는 ‘클라우드 컴퓨팅’ 대신 ‘분산 컴퓨팅’이라는 용어를 주로 사용한다.

클라우드 컴퓨팅cloud computing은 사용하는 사람마다 그 뜻이 다른 마케팅 용어이다. 반면 분산 컴퓨

팅(distributed computing )은 한 대가 아니라 여러 대의 기계들을 이용해서 응용 프로그램과

서비스를 제공하는 구조(architecture )를 뜻한다.

이 책은 시기를 타지 않는 근본적인 원리(principle )들과 관행(practice; 실천 사항)들을 다

룬다. 따라서 특정 제품이나 기술을 사용하라고 독자에게 권하지는 않는다. 가장 인기 있는 다섯 가

지 웹 서버나 NoSQL 데이터베이스, 지속적 구축 시스템을 독자에게 추천할 수도 있겠지만, 그러

면 출판되는 순간 이 책은 구식이 되어버린다. 대신 이 책은 그런 제품이나 시스템을 선택할 때 독자

9

가 반드시 살펴봐야 할 품질들을 논의한다. 이러한 접근방식은 시간이 흘러서 기술들이 변해도 독자

가 이 업계에서 여전히 준비된 전문가로 남게 하기 위한 것이다. 물론 요점을 설명하는 과정에서 특

정 기술이나 제품들을 언급하긴 하지만, 그런 제품들과 서비스들을 우리 저자들이 특별히 보증하는

것은 아니다.

이 책은 종종 이상주의적인 태도를 취하는데, 이는 의도적인 것이다. 이 책은 독자가 추구해야

할 더 나은 상황을 제시한다. 이 책에서 우리 저자들은 기준을 높이고자 했다.

이 책의 구성

이 책은 크게 두 부(part )로 이루어져 있다. 제1부는 ‘설계’이고 제2부는 ‘운영’이다.

제1부는 크고 복잡한 클라우드 기반 분산 컴퓨팅 시스템의 설계에 관한 우리 저자들의 생각을

담고 있다. ‘소개’ 장 다음의 제1장부터는 최하층에서부터 최상층까지 설계의 각 요소를 차례로 살펴

본다. 이 책에서는 분산 시스템을 컴퓨터 과학자가 아니라 시스템 관리자의 관점에서 다룬다. 시스

템을 운영하려면 그 내부를 반드시 이해해야 한다.

제2부는 그러한 시스템을 운영하는 방법을 설명한다. 처음 몇 장(chapter )들은 가장 근본적인

주제들을 다루고, 그 이후의 장들은 좀 더 내밀한 기술적 활동들을 파고든다. 마지막 장들에서는 그

때까지 다룬 모든 것을 통합하는 고수준 계획 수립과 전략을 논의한다.

제2부 다음에는 운영팀을 위한 평가 체계, 분산 시스템의 역사(저자들의 의견이 강하게 반영

된), 본문에 언급된 문서 양식들, 추천 읽을거리, 참고문헌들이 나온다.

특히, 이번 책에서 운영팀 평가 체계를 소개하게 되어서 아주 기쁘다. 이 체계는 독자가 스스로

자신의 운영을 평가하고 개선점을 찾는 데 사용할 수 있는 일련의 질문들로 이루어져 있다. 평가 질

문들과 ‘징표’ 제안들은 부록 A에 있다. 제20장은 이 체계의 활용 설명서에 해당한다.

10

제1부 설계: 시스템 만들기

제1장 분산 세계에서의 설계 ·······분산 시스템 설계의 개요.

제2장 운영을 위한 설계 ············매끄러운 운영을 위해 소프트웨어가 갖추어야 할 기능들.

제3장 서비스 플랫폼 선택 ··········물리적 기계와 가상 기계, 사설 클라우드와 공용 클라우드.

제4장 응용 프로그램 구조 ·········· 웹 응용 프로그램이나 기타 응용 프로그램의 작성을 위한

구축 요소들.

제5장 규모 변화를 위한 설계 패턴 ···서비스의 성장을 위한 구축 요소들.

제6장 탄력성을 위한 설계 패턴 ······고장을 견디는 시스템의 작성을 위한 구축 요소들.

제2부 운영: 시스템 실행하기

제7장 분산 세계에서의 운영 ········분산 시스템 실행의 개요.

제8장 개발운영 문화 ··············개발운영 문화 및 그 역사와 관행의 소개.

제9장 서비스 인도: 구축 국면 ·······실무 운영을 위해 서비스를 구축하고 준비하는 방법.

제10장 서비스 인도: 배치 국면 ······서비스를 검사, 승인하고 실무에 투입하는 방법.

제11장 활성 서비스의 업그레이드 ···가동 중단 없이 서비스를 업그레이드하는 방법.

제12장 자동화 ···················도구 작성과 운영 작업 자동화.

제13장 설계 문서 ·················설계와 의도를 문서를 통해 의사소통하는 방법.

제14장 호출대기 ··················예외 상황 다루기.

제15장 재난 대비 ················· 계획 수립과 연습을 통해서 시스템을 더 강하게 만드는

방법.

제16장 감시의 기초 ···············감시 기술과 전략.

제17장 감시 시스템의 구조와 관행 ··감시의 구성요소와 관행.

제18장 수용량 계획 수립 ··········· 추가 자원이 필요해지기 전에 자원들을 마련하고 제공하

는 방법.

11

제19장 KPI 작성 ·················측정과 반영을 통한 과학적인 행동 추동.

제20장 탁월한 운영 ···············지속적인 개선을 위한 전략들.

맺음말 ··························남은 이야기 몇 가지.

제3부 부록

부록 A: 평가

부록 B: 분산 컴퓨팅과 클라우드의 기원과 미래

부록 C: 규모 변화 관련 용어 및 개념

부록 D: 문서 양식과 예제 문서

부록 E: 읽을거리 추천

참고문헌

찾아보기

감사의 글

이 분야의 공동체와 전 세계의 여러 사람의 도움과 피드백이 없었다면 이 책이 나오지 못했을

것이다. 이 책은 ‘개발운영(DevOps )’ 공동체의 후한 도움을 받았다.

우선, 우리 저자들의 배우자들과 가족들에 감사하고자 한다. 이 책은 Christine Polk,

Mike Chalup, 그리고 Eliot과 Joanna Lear의 사랑과 인내 덕분에 탄생했다.

만일 우리가 더 멀리 내다볼 수 있었다면, 그것은 우리가 거인들의 어깨에 서 있었기 때

문이다. 몇몇 장들은 특정 인물들의 지원과 조언에 크게 의존했다. 제1장은 John Looney와

Cian Synnott, 제5장은 Marty Abbott과 Michael Fisher, 제9장은 Damon Edwards, Alex

Honor, Jez Humble, 제15장은 John Allspaw, 제15장은 Brent Chapman, 제16장과 제17

장은 Caskey Dickson과 Theo Schlossnagle, 제18장은 Arun Kejariwal과 Bruce Yan, 제

19장은 Benjamin Treynor Sloss, 제20장과 부록 A는 Geoff Halprin의 도움을 받았다.

12

‘전략적인’ 영감과 격려를 제공한 Gene Kim에게 감사한다. 수십 명의 사람이 우리를 도

왔다. 실제 사례들을 제공한 사람들도 있고 책 전체 또는 일부를 검토해준 사람들도 있다. 그

모든 분께 감사하는 유일하게 공평한 방법은 그분들의 이름을 알파벳순으로 나열하고, 혹시

라도 빼먹었다면 사과하는 것이리라. Thomas Baden, George Beech, Raymond Blum,

Kyle Brandt, Mark Burgess, Nick Craver, Geoff Dalgas, Robert P. J. Day, Patrick

Debois, Bill Duane, Paul Evans, David Fullerton, Tom Geller, Peter Grace,

Elizabeth Hamon Reid, Jim Hickstein, Zachary Hueras, Matt Jones, Jennifer Joy,

Jimmy Kaplowitz, Daniel V. Klein, Steven Levine, Cory Lueninghoener, Shane

Madden, Jim Maurer, Stephen McHenry, Dinah McNutt, Scott Hazen Mueller,

Steve Murawski, Mohit Muthanna, Lenny Rachitsky, Amy Rich, Adele Shakal,

Bart Silverstrim, Josh Simon, Joel Spolsky, Desiree Sylvester, Win Treese, Todd

Underwood, Nicole Forsgren Velasquez, Dave Zwieback에게 감사한다.

마지막으로, Addison-Wesley의 모든 분께 감사한다. 특히 Addison-Wesley와 작업

하는 내내 우리를 올바른 방향으로 이끌어준 Debra Williams Cauley와 초안들을 편집하고

훨씬 나은 원고를 만들어 준 Michael Thurston, 우리가 당황해서 허둥댈 때에도 침착하게 상

황을 조정하고 우리를 보조한 Kim Boedigheimer, LaTeX 마법사 Lori Hughes, 제품 관리

자 Julie Nahil, 조판자 Jill Hobbs, 그리고 우리의 모든 특별한 요청을 참아준 John Fuller와

Mark Taub에게 감사한다.

13

CONTENTS

지은이·옮긴이 소개 ......................................................................................................... 4

옮긴이의 말 ..................................................................................................................... 6

서문 ................................................................................................................................ 7

소개 33

사업 목표 ........................................................................................................................ 33

이상적인 시스템 구조 ........................................................................................................ 34

이상적인 릴리스 과정 ........................................................................................................ 35

이상적인 운영 .................................................................................................................. 38

PART I 설계: 시스템 만들기

CHAPTER 1 분산 세계에서의 설계 43

1.1 대규모 시스템의 가시성 .............................................................................................. 45

1.2 단순함의 중요성 ........................................................................................................ 46

1.3 조합 ........................................................................................................................ 46

1.3.1 부하 분산기와 다수의 뒷단 복제본들 ................................................................... 47

1.3.2 서버와 다수의 뒷단들 ....................................................................................... 49

1.3.3 서버 트리 ....................................................................................................... 52

1.4 상태의 분산 .............................................................................................................. 54

1.5 CAP 원리 ................................................................................................................ 57

1.5.1 일관성 ........................................................................................................... 58

1.5.2 가용성 ........................................................................................................... 58

1.5.3 분리 저항 ....................................................................................................... 59

14

CONTENTS

1.6 느슨히 결합된 시스템 ................................................................................................. 62

1.7 속도 ........................................................................................................................ 64

1.8 요약 ........................................................................................................................ 68

연습문제 ......................................................................................................................... 69

CHAPTER 2 운영을 위한 설계 71

2.1 운영상의 요구사항 ..................................................................................................... 72

2.1.1 구성 ............................................................................................................... 73

2.1.2 시동과 종료 .................................................................................................... 75

2.1.3 대기열 배출 .................................................................................................... 76

2.1.4 소프트웨어 업그레이드 ..................................................................................... 77

2.1.5 백업과 복구 .................................................................................................... 77

2.1.6 중복성(redundancy) ....................................................................................... 78

2.1.7 복제된 데이터베이스 ........................................................................................ 79

2.1.8 즉석 교체 ....................................................................................................... 80

2.1.9 개별 기능 켜고 끄기 ......................................................................................... 81

2.1.10 우아한 강등 .................................................................................................. 82

2.1.11 접근 제어와 속도 제한 .................................................................................... 83

2.1.12 자료 도입 제어 .............................................................................................. 84

2.1.13 감시 ............................................................................................................. 85

2.1.14 감사 ............................................................................................................. 85

2.1.15 디버깅 계장(instrumentation) ......................................................................... 86

2.1.16 예외 수집 ..................................................................................................... 87

2.1.17 운영을 위한 문서화 ........................................................................................ 88

2.2 운영을 위한 설계의 구현 .............................................................................................. 89

2.2.1 기능을 처음부터 구축 ....................................................................................... 89

15

2.2.2 필요성을 발견한 후 개발팀에 요청 ...................................................................... 89

2.2.3 운영팀이 기능을 직접 작성 ................................................................................ 91

2.2.4 서드파티 공급업체와 협력 ................................................................................. 92

2.3 모형의 개선 ............................................................................................................... 93

2.4 요약 ........................................................................................................................ 94

연습문제 ......................................................................................................................... 94

CHAPTER 3 서비스 플랫폼 선택 95

3.1 서비스 추상 수준 ....................................................................................................... 96

3.1.1 IaaS(서비스로서의 기반구조) ............................................................................. 97

3.1.2 PaaS(서비스로서의 플랫폼) .............................................................................. 99

3.1.3 SaaS(서비스로서의 소프트웨어) ...................................................................... 100

3.2 기계의 종류 ............................................................................................................ 102

3.2.1 물리적 기계 .................................................................................................. 102

3.2.2 가상 기계 ..................................................................................................... 102

3.2.3 컨테이너 ...................................................................................................... 106

3.3 자원 공유 수준 ........................................................................................................ 109

3.3.1 법규 준수 ..................................................................................................... 110

3.3.2 개인정보 ...................................................................................................... 110

3.3.3 비용 ............................................................................................................. 111

3.3.4 제어권 .......................................................................................................... 111

3.4 코로케이션 ............................................................................................................. 112

3.5 선택 전략 ............................................................................................................... 113

3.6 요약 ...................................................................................................................... 116

연습문제 ....................................................................................................................... 117

16

CONTENTS

CHAPTER 4 응용 프로그램 구조 119

4.1 단일 기계 웹 서버 .................................................................................................... 120

4.2 3층 웹 서비스 ......................................................................................................... 122

4.2.1 부하 분산기의 종류 ........................................................................................ 123

4.2.2 부하 분산 방법 .............................................................................................. 125

4.2.3 공유 상태가 있는 부하 분산 ............................................................................. 126

4.2.4 사용자 신원 .................................................................................................. 127

4.2.5 규모 변화 ..................................................................................................... 128

4.3 4층 웹 서비스 ......................................................................................................... 129

4.3.1 앞단 ............................................................................................................. 130

4.3.2 응용 프로그램 서버 ........................................................................................ 132

4.3.3 구성 옵션 ..................................................................................................... 132

4.4 역 프록시 서비스 ..................................................................................................... 133

4.5 클라우드 규모 서비스 ............................................................................................... 134

4.5.1 전역 부하 분산기 ........................................................................................... 135

4.5.2 전역 부하 분산 방법 ....................................................................................... 135

4.5.3 사용자 고유 자료에 근거한 전역 부하 분산 ........................................................ 136

4.5.4 내부 기간망 .................................................................................................. 136

4.6 메시지 버스 구조 ..................................................................................................... 139

4.6.1 메시지 버스의 설계 ........................................................................................ 141

4.6.2 메시지 버스의 신뢰성 ..................................................................................... 141

4.6.3 예제 1: 링크 단축 사이트 ................................................................................ 142

4.6.4 예제 2: 직원 인적자원 자료 갱신 ...................................................................... 145

4.7 서비스 지향 구조 ..................................................................................................... 146

4.7.1 유연성 ......................................................................................................... 146

4.7.2 지원 ............................................................................................................. 147

4.7.3 모범 관행 ..................................................................................................... 147

17

4.8 요약 ...................................................................................................................... 148

연습문제 ....................................................................................................................... 149

CHAPTER 5 규모 변화를 위한 설계 패턴 151

5.1 일반 전략 ............................................................................................................... 152

5.1.1 병목 식별 ..................................................................................................... 153

5.1.2 구성요소들의 재공학 ...................................................................................... 153

5.1.3 결과의 측정 .................................................................................................. 154

5.1.4 능동적 대처 .................................................................................................. 154

5.2 규모 확장 ............................................................................................................... 155

5.3 AKF 규모 변화 입방체 .............................................................................................. 156

5.3.1 x축: 수평 중복 ............................................................................................... 157

5.3.2 y축: 기능 또는 서비스별 분할 .......................................................................... 158

5.3.3 z축: 조회 지향적 분할 ..................................................................................... 160

5.3.4 조합 ............................................................................................................. 162

5.4 캐싱 ...................................................................................................................... 162

5.4.1 캐시 효율성 .................................................................................................. 163

5.4.2 캐시 위치 ..................................................................................................... 164

5.4.3 캐시 영속성 .................................................................................................. 165

5.4.4 캐시 교체 알고리즘 ........................................................................................ 166

5.4.5 캐시 항목 무효화 ........................................................................................... 167

5.4.6 캐시 크기 ..................................................................................................... 168

5.5 자료 파편화 ............................................................................................................ 169

5.6 스레드 적용 ............................................................................................................ 172

5.7 대기열 적용 ............................................................................................................ 173

5.7.1 장점 ............................................................................................................. 174

5.7.2 변형들 ......................................................................................................... 174

18

5.8 CDN ..................................................................................................................... 175

5.9 요약 ...................................................................................................................... 177

연습문제 ....................................................................................................................... 178

CHAPTER 6 탄력성을 위한 설계 패턴 179

6.1 하드웨어 탄력성보다 중요한 소프트웨어 탄력성 ............................................................. 181

6.2 모든 것은 결국에는 고장난다 ..................................................................................... 182

6.2.1 분산 시스템의 MTBF ..................................................................................... 182

6.2.2 전통적인 접근방식 ......................................................................................... 183

6.2.3 분산 컴퓨팅 접근방식 ..................................................................................... 184

6.3 예비 수용량을 이용한 탄력성 확보 .............................................................................. 185

6.3.1 예비 수용량 결정 ........................................................................................... 187

6.3.2 부하 공유 대 즉석 예비 ................................................................................... 188

6.4 장애 영역 ............................................................................................................... 189

6.5 소프트웨어 장애 ...................................................................................................... 190

6.5.1 소프트웨어 충돌 ............................................................................................ 190

6.5.2 소프트웨어 멈춤 ............................................................................................ 192

6.5.3 죽음의 질의 .................................................................................................. 193

6.6 물리적 장애 ............................................................................................................ 194

6.6.1 부품과 구성요소 ............................................................................................. 195

6.6.2 기계 ............................................................................................................. 198

6.6.3 부하 분산기 .................................................................................................. 198

6.6.4 랙 ................................................................................................................ 201

6.6.5 데이터센터 .................................................................................................... 202

6.7 과부하 장애 ............................................................................................................ 203

6.7.1 소통량 급증 .................................................................................................. 203

CONTENTS

19

6.7.2 DoS 및 DDoS 공격 ...................................................................................... 205

6.7.3 스크레이핑 공격 ............................................................................................ 206

6.8 사람의 실수 ............................................................................................................ 207

6.9 요약 ...................................................................................................................... 208

연습문제 ....................................................................................................................... 209

PART II 운영: 시스템 실행하기

CHAPTER 7 분산 세계에서의 운영 213

7.1 분산 시스템의 운영 ................................................................................................... 215

7.1.1 SRE팀 대 전통적인 전사적 IT 부서 .................................................................. 215

7.1.2 변화 대 안정성 .............................................................................................. 216

7.1.3 SRE의 정의 .................................................................................................. 218

7.1.4 대규모 운영 .................................................................................................. 220

7.2 서비스의 수명 주기 ................................................................................................... 223

7.2.1 서비스 개시 .................................................................................................. 225

7.2.2 서비스 폐지 .................................................................................................. 228

7.3 운영팀을 위한 조직화 전략 ......................................................................................... 229

7.3.1 팀원의 업무일 구분 ........................................................................................ 232

7.3.2 기타 전략들 ................................................................................................... 235

7.4 가상 사무실 ............................................................................................................ 237

7.4.1 의사소통 메커니즘 ......................................................................................... 237

7.4.2 의사소통 방침 ............................................................................................... 238

7.5 요약 ...................................................................................................................... 238

연습문제 ....................................................................................................................... 240

20

CHAPTER 8 개발운영 문화 241

8.1 개발운영이란? ........................................................................................................ 242

8.1.1 전통적인 접근방식 ......................................................................................... 244

8.1.2 개발운영 접근방식 ......................................................................................... 246

8.2 개발운영의 3대 방법 ................................................................................................. 247

8.2.1 제1 방법: 작업흐름 ........................................................................................ 247

8.2.2 제2 방법: 피드백 개선 ..................................................................................... 248

8.2.3 제3 방법: 끊임없는 실험과 학습 ....................................................................... 249

8.2.4 작은 일괄 단위들이 더 낫다 ............................................................................. 250

8.2.5 전략의 적용 .................................................................................................. 251

8.3 개발운영의 역사 ....................................................................................................... 252

8.3.1 진화 ............................................................................................................. 252

8.3.2 사이트 신뢰성 공학 ........................................................................................ 253

8.4 개발운영의 가치와 원리 ............................................................................................ 254

8.4.1 관계 ............................................................................................................. 254

8.4.2 통합 ............................................................................................................. 254

8.4.3 자동화 ......................................................................................................... 255

8.4.4 지속적인 개선 ................................................................................................ 255

8.4.5 흔한 비기술적 개발운영 관행 ........................................................................... 256

8.4.6 개발운영의 일반적인 기술적 관행들 .................................................................. 257

8.4.7 릴리스 공학과 관련된 개발운영의 관행들 ........................................................... 259

8.5 개발운영으로의 전환 ................................................................................................. 260

8.5.1 첫걸음 ......................................................................................................... 260

8.5.2 사업 수준에서의 개발운영 ............................................................................... 261

8.6 애자일과 지속적 인도 ............................................................................................... 262

8.6.1 애자일이란 무엇인가? .................................................................................... 262

8.6.2 지속적 인도란 무엇인가? ................................................................................ 263

CONTENTS

21

8.7 요약 ...................................................................................................................... 266

연습문제 ....................................................................................................................... 267

CHAPTER 9 서비스 인도: 구축 국면 269

9.1 서비스 인도 전략 ..................................................................................................... 271

9.1.1 패턴: 현대적인 개발운영 방법론 ....................................................................... 271

9.1.2 반反패턴(안티패턴): 폭포수 방법론 .................................................................... 273

9.2 품질의 선순환 ......................................................................................................... 274

9.3 구축 국면의 단계들 ................................................................................................... 277

9.3.1 개발 ............................................................................................................. 277

9.3.2 커밋 ............................................................................................................. 278

9.3.3 구축 ............................................................................................................. 279

9.3.4 패키지 ......................................................................................................... 280

9.3.5 등록 ............................................................................................................. 280

9.4 구축 콘솔 ............................................................................................................... 281

9.5 지속적 통합 ............................................................................................................. 282

9.6 작업 이전 인터페이스로서의 패키지 ............................................................................ 284

9.7 요약 ...................................................................................................................... 285

연습문제 ....................................................................................................................... 286

CHAPTER 10 서비스 인도: 배치 국면 287

10.1 배치 국면의 단계들 ................................................................................................ 288

10.1.1 승격 ........................................................................................................... 288

10.1.2 설치 ........................................................................................................... 289

10.1.3 구성 ........................................................................................................... 289

22

10.2 검사와 승인 .......................................................................................................... 291

10.2.1 검사 ........................................................................................................... 292

10.2.2 승인 ........................................................................................................... 294

10.3 운영 콘솔 ............................................................................................................. 294

10.4 기반구조 자동화 전략 ............................................................................................. 295

10.4.1 물리적 기계 마련 ......................................................................................... 295

10.4.2 가상 기계 마련 ............................................................................................. 296

10.4.3 운영 체제와 서비스 설치 ............................................................................... 296

10.5 지속적 인도 .......................................................................................................... 299

10.6 코드로서의 기반구조 .............................................................................................. 300

10.7 기타 플랫폼 서비스들 ............................................................................................. 300

10.8 요약 .................................................................................................................... 301

연습문제 ....................................................................................................................... 302

CHAPTER 11 활성 서비스의 업그레이드 303

11.1 서비스 중단 후 업그레이드 ...................................................................................... 303

11.2 순회식 업그레이드 ................................................................................................. 304

11.3 카나리아 공정 ....................................................................................................... 306

11.4 국면별 롤아웃 ....................................................................................................... 308

11.5 비례식 차단 .......................................................................................................... 309

11.6 청록 배치 ............................................................................................................. 309

11.7 기능 켜고 끄기 ...................................................................................................... 310

11.8 활성 스키마 변경 ................................................................................................... 313

11.9 활성 코드 변경 ...................................................................................................... 316

11.10 지속적 배치 ........................................................................................................ 317

11.11 코드 투입 실패의 처리 .......................................................................................... 320

CONTENTS

23

11.12 릴리스 원자성 ..................................................................................................... 321

11.13 요약 ................................................................................................................. 322

연습문제 ....................................................................................................................... 323

CHAPTER 12 자동화 325

12.1 자동화 접근방식들 ................................................................................................. 326

12.1.1 잔여물 원리를 따르는 자동화 접근방식 ............................................................ 327

12.1.2 보충 원리를 따르는 자동화 접근방식 ............................................................... 329

12.1.3 상보성 원리를 따르는 자동화 접근방식 ............................................................ 330

12.1.4 시스템 관리자를 위한 자동화 ......................................................................... 331

12.1.5 경험에서 얻은 교훈들 ................................................................................... 332

12.2 도구 구축 대 자동화 ............................................................................................... 333

12.2.1 예: 자동차 제조 ............................................................................................ 334

12.2.2 예: 컴퓨터 구성 ............................................................................................ 334

12.2.3 예: 계정 생성 ............................................................................................... 335

12.2.4 도구는 좋다, 자동화는 더 좋다 ....................................................................... 335

12.3 자동화의 목표 ....................................................................................................... 336

12.4 자동화 작성 .......................................................................................................... 339

12.4.1 자동화 작성 시간 마련 .................................................................................. 340

12.4.2 고역 줄이기 ................................................................................................ 341

12.4.3 첫 번째 자동화 대상 선정 .............................................................................. 342

12.5 자동화 방법 .......................................................................................................... 342

12.6 언어 도구들 .......................................................................................................... 343

12.6.1 셸 스크립팅 언어 ......................................................................................... 343

12.6.2 스크립팅 언어 ............................................................................................. 344

12.6.3 컴파일식 언어 ............................................................................................. 345

12.6.4 구성 관리용 언어 ......................................................................................... 346

24

12.7 소프트웨어 공학 도구들과 기법들 ............................................................................. 348

12.7.1 문제점 추적 시스템 ...................................................................................... 349

12.7.2 버전 관리 시스템 ......................................................................................... 351

12.7.3 소프트웨어 패키지 작성 ................................................................................ 352

12.7.4 스타일 지침 ................................................................................................ 353

12.7.5 TDD .......................................................................................................... 355

12.7.6 코드 검토 ................................................................................................... 356

12.7.7 딱 필요한 만큼의 코드를 작성 ........................................................................ 357

12.8 다중 입주 시스템 ................................................................................................... 358

12.9 요약 .................................................................................................................... 360

연습문제 ....................................................................................................................... 361

CHAPTER 13 설계 문서 363

13.1 설계 문서의 개요 ................................................................................................... 363

13.1.1 변경과 그 논거의 문서화 ............................................................................... 364

13.1.2 과거 의사결정들을 보관하는 문서화 ................................................................ 365

13.2 설계 문서의 구성 ................................................................................................... 365

13.3 문서 양식 ............................................................................................................. 368

13.4 문서 보관소 .......................................................................................................... 369

13.5 설계 문서 검토의 작업흐름 ...................................................................................... 369

13.5.1 검토자와 승인자 .......................................................................................... 370

13.5.2 결재 ........................................................................................................... 371

13.6 설계 문서 표준의 채용 ............................................................................................ 372

13.7 요약 .................................................................................................................... 373

연습문제 ....................................................................................................................... 374

CONTENTS

25

CHAPTER 14 호출대기 375

14.1 호출대기의 설계 .................................................................................................... 376

14.1.1 SLA로 시작 ................................................................................................ 376

14.1.2 호출대기 명단 ............................................................................................. 377

14.1.3 당직대기 .................................................................................................... 378

14.1.4 호출대기 일정 설계 ...................................................................................... 379

14.1.5 호출대기 일정표 .......................................................................................... 382

14.1.6 호출대기의 빈도 ........................................................................................... 383

14.1.7 통지의 종류 ................................................................................................ 383

14.1.8 근무 시간 외 유지보수 조정 ........................................................................... 386

14.2 호출대기 수행 ....................................................................................................... 386

14.2.1 교대근무 전 임무 ......................................................................................... 386

14.2.2 정규 호출대기 임무 ...................................................................................... 387

14.2.3 경보 처리 임무 ............................................................................................ 388

14.2.4 관찰, 지향, 결정, 실행: OODA 루프 ................................................................ 390

14.2.5 호출대기 각본 ............................................................................................. 390

14.2.6 서드파티 상부 보고 ...................................................................................... 391

14.2.7 교대근무 마감 임무 ...................................................................................... 392

14.3 다음 호출대기 교대근무까지의 작업 .......................................................................... 393

14.3.1 장기적 해결책 ............................................................................................. 393

14.3.2 사후 분석 ................................................................................................... 394

14.4 주기적인 경보 검토 ................................................................................................ 398

14.5 경보 줄이기 .......................................................................................................... 399

14.6 요약 .................................................................................................................... 400

연습문제 ....................................................................................................................... 401

26

CHAPTER 15 재난 대비 403

15.1 사고방식 .............................................................................................................. 404

15.1.1 반취약 시스템 ............................................................................................. 405

15.1.2 위험 줄이기 ................................................................................................ 406

15.2 개인 훈련: 불운의 바퀴 ........................................................................................... 408

15.3 팀 훈련: 소방 훈련 ................................................................................................. 410

15.3.1 서비스 검사 ................................................................................................. 411

15.3.2 무작위 검사 ................................................................................................. 412

15.4 조직 훈련: 게임 데이/DiRT ...................................................................................... 413

15.4.1 첫걸음 ....................................................................................................... 414

15.4.2 범위 확장 ................................................................................................... 415

15.4.3 계획과 구현 ................................................................................................ 416

15.4.4 DiRT 검사의 예 ........................................................................................... 419

15.5 사고지휘체계 ........................................................................................................ 423

15.5.1 작동 방식: 공공 안전 분야 ............................................................................. 424

15.5.2 작동 방식: IT 운영 분야 ................................................................................. 425

15.5.3 사고 대응 활동 계획서 .................................................................................. 426

15.5.4 모범 관행 ................................................................................................... 427

15.5.5 사고지휘체계의 예 ....................................................................................... 428

15.6 요약 .................................................................................................................... 429

연습문제 ....................................................................................................................... 430

CONTENTS

27

CHAPTER 16 감시의 기초 431

16.1 개요 .................................................................................................................... 432

16.1.1 감시의 용도 ................................................................................................. 434

16.1.2 서비스 관리 ................................................................................................ 434

16.2 감시 정보의 소비자 ................................................................................................ 435

16.3 감시 대상 ............................................................................................................. 437

16.4 감시 자료의 유지 ................................................................................................... 439

16.5 메타 감시 ............................................................................................................. 441

16.6 로그 .................................................................................................................... 442

16.6.1 접근방식 .................................................................................................... 443

16.6.2 타임스탬프 ................................................................................................. 443

16.7 요약 .................................................................................................................... 444

연습문제 ....................................................................................................................... 445

CHAPTER 17 감시 시스템의 구조와 관행 447

17.1 감지 및 측정 ......................................................................................................... 448

17.1.1 블랙박스 측정 대 화이트박스 측정 .................................................................. 449

17.1.2 직접 측정 대 합성 측정 ................................................................................. 450

17.1.3 속도 측정 대 능력 측정 ................................................................................. 450

17.1.4 계측치 측정 대 카운터 측정 ........................................................................... 451

17.2 수집 .................................................................................................................... 453

17.2.1 밀기 대 당기기 ............................................................................................ 453

17.2.2 프로토콜 선택 ............................................................................................. 454

17.2.3 서버 자체 측정 대 에이전트 대 주기적 점검 ..................................................... 455

17.2.4 중앙 수집기 대 지역별 수집기 ........................................................................ 456

28

17.3 분석 및 계산 ......................................................................................................... 456

17.4 경보 및 상부 보고 구성요소 ..................................................................................... 458

17.4.1 경보, 상부 보고, 확인 .................................................................................... 459

17.4.2 소음 대 금지 ................................................................................................ 460

17.5 시각화 ................................................................................................................. 462

17.5.1 백분위수 .................................................................................................... 463

17.5.2 스택 랭킹 ................................................................................................... 465

17.5.3 히스토그램 ................................................................................................. 466

17.6 저장 .................................................................................................................... 467

17.7 구성 .................................................................................................................... 468

17.8 요약 .................................................................................................................... 469

연습문제 ....................................................................................................................... 470

CHAPTER 18 수용량 계획 수립 471

18.1 표준 수용량 계획 수립 ............................................................................................ 472

18.1.1 현재 사용량 ................................................................................................ 474

18.1.2 정상 성장 ................................................................................................... 476

18.1.3 계획된 성장 ................................................................................................ 476

18.1.4 여유분 ....................................................................................................... 476

18.1.5 탄력성 ....................................................................................................... 477

18.1.6 시간표 ....................................................................................................... 478

18.2 고급 수용량 계획 수립 ............................................................................................ 478

18.2.1 1차 자원의 식별 .......................................................................................... 479

18.2.2 수용량 한계 파악 ......................................................................................... 480

18.2.3 핵심 동인 식별 ............................................................................................ 481

18.2.4 참여도 측정 ................................................................................................ 482

CONTENTS

29

18.2.5 자료의 분석 ................................................................................................. 482

18.2.6 핵심지표 감시 ............................................................................................. 489

18.2.7 수용량 계획 수립의 위임 ............................................................................... 490

18.3 자원 회귀 ............................................................................................................. 490

18.4 새 서비스 개시 ...................................................................................................... 491

18.5 조달 시간 줄이기 ................................................................................................... 494

18.6 요약 .................................................................................................................... 495

연습문제 ....................................................................................................................... 496

CHAPTER 19 KPI 작성 497

19.1 KPI란 무엇인가? ................................................................................................... 498

19.2 KPI 작성 ............................................................................................................. 500

19.2.1 단계 1: 이상적 상황을 상상한다 ..................................................................... 500

19.2.2 단계 2: 이상과의 거리를 재는 방법을 고안한다 ................................................. 501

19.2.3 단계 3: 사람들의 행동 변화를 예상한다 ........................................................... 501

19.2.4 단계 4: 수정하고 선택한다 ............................................................................ 502

19.2.5 단계 5: KPI를 배치한다 ................................................................................ 503

19.3 KPI의 예: 가상 기계 할당 ........................................................................................ 504

19.3.1 첫 번째 패스 ............................................................................................... 505

19.3.2 두 번째 패스 ............................................................................................... 506

19.3.3 KPI의 평가 ................................................................................................. 508

19.4 사례 연구: 구글 오류 예산 ........................................................................................ 509

19.4.1 목표 대립 ................................................................................................... 509

19.4.2 통합된 목표 ................................................................................................. 510

19.4.3 모두의 이익 ................................................................................................ 510

19.5 요약 .................................................................................................................... 512

연습문제 ....................................................................................................................... 513

30

CHAPTER 20 탁월한 운영 515

20.1 탁월한 운영은 어떤 모습인가? ................................................................................. 516

20.2 훌륭함을 측정하는 방법 .......................................................................................... 517

20.3 평가 방법론 .......................................................................................................... 518

20.3.1 주요 운영 책무 ............................................................................................ 518

20.3.2 평가 수준 ................................................................................................... 520

20.3.3 평가를 위한 질문과 징표 ............................................................................... 522

20.4 서비스 평가 .......................................................................................................... 523

20.4.1 평가 대상 식별 ............................................................................................. 523

20.4.2 각 서비스의 평가 ......................................................................................... 524

20.4.3 서비스 간 결과 비교 ..................................................................................... 525

20.4.4 결과에 기초한 행동 ...................................................................................... 526

20.4.5 평가와 프로젝트 계획 수립의 빈도 .................................................................. 526

20.5 조직 차원의 평가 ................................................................................................... 527

20.6 개선 수준 ............................................................................................................. 528

20.7 평가 체계의 도입과 적용 ......................................................................................... 529

20.8 요약 .................................................................................................................... 530

연습문제 ....................................................................................................................... 531

맺음말 533

CONTENTS

31

PART III 부록

APPENDIX A 평가 539

A.1 정규 과제 ............................................................................................................... 540

A.2 비상 대응 ............................................................................................................... 543

A.3 감시와 측정 ............................................................................................................ 545

A.4 수용량 계획 수립 ..................................................................................................... 548

A.5 변경 관리 ............................................................................................................... 550

A.6 신제품 도입 및 제거 ................................................................................................. 552

A.7 서비스 배치 및 폐지 ................................................................................................. 554

A.8 성능과 효율성 ......................................................................................................... 556

A.9 서비스 인도: 구축 국면 .............................................................................................. 559

A.10 서비스 인도: 배치 국면 ........................................................................................... 561

A.11 고역 줄이기 .......................................................................................................... 563

A.12 재난 대비 ............................................................................................................. 565

APPENDIX B 분산 컴퓨팅과 클라우드의 기원과 미래 569

B.1 웹 이전 시대(1985–1994) ...................................................................................... 570

B.2 제1차 웹 시대: 닷컴 거품(1995–2000) ...................................................................... 573

B.3 닷컴 붕괴 시대(2000–2003) ................................................................................... 579

B.4 제2차 웹 시대(2003–2010) .................................................................................... 585

B.5 클라우드 컴퓨팅 시대(2010~현재) ............................................................................ 590

B.6 결론 ...................................................................................................................... 594

연습문제 ....................................................................................................................... 595

32

APPENDIX C 규모 변화 관련 용어 및 개념 597

C.1 상수, 선형, 지수 규모 변화 ........................................................................................ 597

C.2 대문자 O 표기법 ..................................................................................................... 598

C.3 대문자 O 표기법의 한계 ........................................................................................... 601

APPENDIX D 문서 양식과 예제 문서 605

D.1 설계 문서 양식 ........................................................................................................ 605

D.2 설계 문서의 예 ........................................................................................................ 606

D.3 사후 분석 보고서 양식 .............................................................................................. 608

APPENDIX E 읽을거리 추천 611

참고문헌 ....................................................................................................................... 615

찾아보기 ....................................................................................................................... 626

CONTENTS

331.3 조합

이 책의 목표는 독자가 가능한 최상의 클라우드 규모 서비스를 구축하고 운영하는 데 도움을

주는 것이다. 그럼 우리가 만들고자 하는 이상적인 환경을 살펴보자.

사업 목표

간단히 말해서, 우리가 추구하는 이상적인 환경의 최종 결과는 사업 목표(business

objective; 또는 경영목표, 업무 목표)들을 만족하는 것이다. 좀 따분하게 들리겠지만, 사실

회사 전체가 같은 목표에 전념해서 함께 일한다는 것은 상당히 신나는 일이다.

이를 달성하려면 반드시 사업 목표들을 파악한 후 그로부터 되짚어 나아가서 이상적인 시

스템(우리가 구축해야 하는)에 도달해야 한다.

사업 목표들을 만족하려면 우선 그 목표들이 무엇인지 알아야 하고, 그것들을 달성하는 계

획을 세워야 하고, 그 계획의 수행을 방해하는 걸림돌들을 처리해야 한다.

잘 정의된 사업 목표들은 측정 가능하며, 그런 측정치들을 자동화된 방식으로 수집할 수

있다. 그로부터 현황판(dashboard )을 자동으로 생성하면 모두가 진행(progress ) 정도를

파악할 수 있게 된다. 이러한 투명성은 신뢰도를 높여준다.

다음은 사업 목표의 예 몇 가지이다.

소개

34 1장 분산 세계에서의 설계

● 우리 제품을 웹사이트를 통해서 판매한다.

● 서비스를 99.99%의 시간으로 제공한다.

● 월 x 백만 건의 구매를 처리하고, 매달 10% 성장한다.

● 한 주에 두 번 새 기능을 도입한다.

● 주요 버그들을 24시간 안에 잡는다.

이상적인 환경에서 사업팀과 기술팀은 자신의 사업 목표와 프로젝트 목표를 예측 가능하고 신

뢰성 있게 달성한다. 이 덕분에, 사업팀과 기술팀 둘 다 상대방 팀이 그들의 향후 목표들을 달

성하리라고 믿는다. 그 결과로 팀들은 더 나은 계획을 세우게 된다. 팀들은 외부 의존성들이 실

패하지* 않을 것이라는 믿음이 있기 때문에 좀 더 공격적인 계획을 세울 수 있다. 그러면 더욱

공격적인 계획 수립이 가능해진다. 이러한 접근방식은 회사 전체를 관통하며 진행을 가속화하

는 상향 나선을 만들어냄으로써 모두에게 이득이 된다.

이상적인 시스템 구조

이상적인 서비스는 견고한 시스템 구조(architecture ) 위에 구축된다. 그러한 구조는 오늘날

의 서비스들이 요구하는 조건들을 만족하며, 시스템이 유명해져서 더 많은 소통량을 받게 될

때 시스템의 규모를 성장시키는 방법이 명확하다. 이상적인 구조는 장애(failure; 고장)에 대

한 탄력성(resiliency; 회복력)을 갖추고 있다. 그런 시스템은 장애를 예기치 못한 예외로 취

급하지 않는다. 대신 하드웨어 및 소프트웨어의 장애를 정보기술(information technology,

IT )의 물리학(physics )의 일부로 포용한다. 그 결과로 구조에는 장애를 우회하는 중복

(redundancy ) 및 회복 기능들이 포함된다. 개별 구성요소는 실패해도 시스템은 살아남는다.

서비스를 구성하는 각 하위 시스템은 그 자체로 서비스이다. 모든 하위 시스템은 응용 프

로그래밍 인터페이스(API )를 통해서 프로그래밍할 수 있다. 따라서 전체 시스템은 여러 하

위 서비스가 서로 연결된 하나의 생태계이다. 이를 서비스 지향 구조(service-oriented

architecture, SOA )라고 부른다. 이러한 시스템들은 모두 동일한 바탕 프로토콜을 통해서 통

신하므로, 시스템들의 관리 방식에 통일성이 존재한다. 각 하위 서비스는 다른 서비스들과 느

* 옮긴이_ 이런 문맥에서 어떤 요소가 ‘실패한다’는 것은 소프트웨어 오작동이나 하드웨어 고장 등의 장애가 발생해서 그 요소가 자신에게

주어진 임무를 다하지 못하는 것을 말한다.

351.3 조합

슨하게 결합되어 있기 때문에, 각자 독립적으로 확장, 업그레이드, 대체할 수 있다.

기반구조(infrastructure )의 구성은 전자적인 파일 형태로 서술한다. 이러한 전자

적 서술을 IT 자동화 시스템이 읽어서, 사람의 개입 없이 자동으로 실무 환경(production

environment )을 구축한다. 이러한 자동화 덕분에 전체 기반구조를 다른 장소에서 재생성하

는 것이 가능하다. 소프트웨어 기술자들은 이러한 자동화를 이용해서 개인적으로 사용할 소규

모 버전의 환경을 생성한다. 비슷하게, 품질 및 검사 기술자들은 자동화를 이용해서 시스템 검

사를 위한 환경을 생성한다.

이러한 ‘코드로서의 기반구조(infrastructure as code )’는 그것을 실행하는 기계(컴퓨터)

가 물리적 기계이든 가상 기계(virtual machine )이든, 그리고 그런 기계들이 데이터센터에

있든, 우리가 직접 운영하든, 또는 클라우드 제공자가 제공한 환경에 상주하든 달성 가능하다.

가상 기계들을 사용하는 경우에는 자명한 API를 통해서 새 기계를 손쉽게 배치할 수 있다. 물

리적 기계를 사용한다고 해도, 단순한 쇳덩어리에서 실제로 작동하는 시스템으로의 전체 흐름

을 자동화할 수 있다. 우리가 생각하는 이상적인 세계에서는 자동화 덕분에 물리적 기계와 가

상 기계의 조합을 이용해서 환경을 생성하는 것이 가능하다. 개발자들이 가상 기계들로부터 환

경을 구축할 수도 있다. 실무 환경은 물리적 기계와 가상 기계의 혼합으로 구성될 수 있다. 예

기치 않게 일시적으로 용량(수용량) 추가가 필요한 경우에는 실무 환경을 일정 기간 하나 이상

의 클라우드 제공업체들로 확장해야 할 수도 있다.

이상적인 릴리스 과정

이상적인 환경에서는 개발 단계에서 운영(operation ) 단계로 코드가 매끄럽게 흘러간다.

전통적인 환경(지금 말하는 이상적인 환경이 아닌)에서 그러한 흐름은 다음과 같은 모습이다.

1. 개발자가 코드를 저장소(repository )에 체크인한다.

2. 검사 기술자(test engineer )는 코드에 대해 일단의 검사들을 적용한다.

3. 코드가 모든 검사를 통과했으면, 릴리스 기술자(release engineer )는 소프트웨어의 배

치(deploy )에 쓰일 패키지를 구축한다. 대부분의 파일은 소스 코드 저장소에서 가져오지

만, 일부 파일은 그래픽 부서나 문서화 작성자 같은 다른 출처에서 가져와야 할 수도 있다.

4. 검사 환경을 생성한다. 단, ‘코드로서의 기반구조’ 모형은 적용하지 않는다(그러려면 몇 주

가 걸릴 수 있다).


5. 패키지를 검사 환경에 배치한다.

6. 검사 기술자가 추가 검사들을 수행한다. 여기서 초점은 하위 시스템들 사이의 상호작용

이다.

7. 모든 검사가 성공적이면 코드를 실무 환경에 투입한다.

8. 시스템 관리자는 시스템을 업그레이드하되, 장애가 발생하는지 살펴본다.

9. 장애가 발생했다면 소프트웨어를 이전 상태로 되돌린다(roll back ).

이러한 단계들을 사람이 직접 수행하는 것은 아주 위험하다. 작업에 적합한 사람이 있어야 하

고, 단계들을 매번 같은 방식으로 수행해야 하며, 그 과정에서 실수가 없어야 하고, 모든 과제

를 제시간 안에 끝내야 한다는 조건들이 모두 만족되어야 하기 때문이다.

물론 실수, 버그, 오류는 항상 발생한다. 그 결과로 결함(defect )들이 과정의 다음 단계로

전파된다. 실수가 발견되면 진행의 흐름을 되돌려서, 이전 단계를 담당한 팀원들에게 문제를

알려서 바로잡게 해야 한다. 이는 진행이 멈추어서 시간이 낭비됨을 뜻한다.

위험이 큰 과정에 대한 사람들의 전형적인 반응은 그런 과정을 최대한 피하는 것이다. 그

래서 릴리스를 최대한 줄이려는 유혹에 빠진다. 그 결과로 ‘거대규모 릴리스(mega-release )’

를 한 해에 몇 번만 내놓는 현상이 나타난다.

그러나 그런 거대규모 릴리스는 수많은 변화를 한꺼번에 적용하는 것이므로 사실은 위험

이 더 커진다. 수천 개의 변경 사항들을 동시에 릴리스했을 때 첫 시도에서 모든 것이 제대로

되리라고 확신할 수 있는가? 그럴 수는 없다. 이 때문에 변화를 더욱 꺼리고 두려워하게 된다.

결국에는 변화가 거의 불가능해져서 더 이상의 혁신이 일어나지 않는다.

우리가 말하는 이상적인 환경에서는 그렇지 않다.

이상적인 환경에서는 소프트웨어 구축과 검사, 릴리스, 배치 과정의 모든 수동 단계들을

자동화를 이용해서 제거한다. 자동화는 검사들을 정확하고 일관되게 수행하기 때문에 결함이

다음 단계로 전파되는 일이 없다. 그 결과로 진행의 흐름은 항상 단방향, 즉 전진 방향이다.

이상적인 환경에서는 거대규모 릴리스 대신 미세규모 릴리스(micro-release )를 만든다.

작은 변화들로 이루어진 배치를 자주 수행함으로써 위험도를 낮춘다. 실제로, 하루에 배치를

100번 할 수도 있다.

1. 개발자가 코드를 체크인하면 시스템은 그 사실을 감지하고 일련의 자동화된 검사들을 실행

한다. 그 검사들은 기본적인 코드 기능성을 확인한다.

2. 그 검사들이 통과되었다면 패키지 구축 과정이 실행된다. 이 역시 완전히 자동화된 방식으

371.3 조합

로 진행된다.

3. 새 패키지가 성공적으로 만들어지면 검사 환경 생성 과정이 시작된다. 예전에는 검사 환경

을 구축하려면 한 주 내내 케이블을 연결하고 기계를 설치하는 수고가 필요했다. 그러나 코

드로서의 기반구조 모형에서는 전체 환경을 사람의 개입 없이 빠르게 생성할 수 있다.

4. 검사 환경이 완성되면 일련의 자동화된 검사들을 실행한다.

5. 검사들이 성공적으로 끝나면 새 패키지를 실무 환경으로 롤아웃roll-out한다. 이 롤아웃 역시

자동으로 진행되지만, 체계적이고 조심스럽게 진행된다.

6. 일부 시스템을 먼저 업그레이드해서 장애가 발생하는지 본다. 검사 환경은 실무 환경을 구

축하는 데 쓰이는 것과 동일한 자동화를 통해서 구축되므로, 두 환경 사이의 차이는 아주

적어야 한다.

7. 장애가 없다면 전체 실무 환경이 업그레이드될 때까지 새 패키지를 점점 더 많은 시스템에

롤아웃한다.

이상적인 환경에서는 모든 문제가 실무 환경에 도달하기 전에 검출된다. 즉, 롤아웃은 검사의

형태가 아니다. 실무 환경으로의 롤아웃 도중의 장애는 본질적으로 제거된다. 그런데도 장애가

발생한다면, 이를 아주 심각한 문제로 간주해서 새 릴리스를 실무 환경에 투입하는 것을 멈추

고 먼저 근본 원인을 분석한다. 분석 후에는 이후 이러한 장애를 검출하고 재발을 방지하는 데

필요한 검사들을 추가한다. 이러한 과정 덕분에 시스템은 시간이 지남에 따라 더욱 강해진다.

이러한 자동화 덕분에 기존의 릴리스 공학, 품질 보증, 배치 관련 인력은 기존 회사에서 자

신이 주로 하던 일을 사실상 인식하지 못하게 된다. 수많은 시간의 수고로운 노동(‘고역’)이 사

라지며, 따라서 패키지 작성 시스템과 소프트웨어 품질을 개선하고 배치 공정을 다듬는 데 더

많은 시간을 투여할 수 있다. 다른 말로 하면, 사람들은 자신의 작업 자체를 수행하는 것보다

그 작업이 수행되는 방식을 개선하는 데 더 많은 시간을 사용한다.

서드파티third-party 소프트웨어에도 비슷한 과정이 적용된다. 환경의 모든 시스템을 회사 내

부에서 직접 만들지는 않으며, 해당 소스 코드가 주어지지 않는 경우도 많다. 서드파티 서비스

와 제품의 배치 역시 릴리스와 검사, 배치와 비슷한 패턴을 따른다. 단, 이 제품들과 서비스들

은 외부에서 개발되므로, 약간 다른 과정이 필요하다. 새 릴리스가 나오는 횟수가 상대적으로

적으며, 각각의 새 릴리스에 포함되는 기능을 우리가 원하는 만큼 제어할 수가 없다. 일반적으

로 이런 구성요소들을 검사할 때에는 기능(feature ), 호환성, 통합(integration )과 관련된 검

사들이 필요하다.


이상적인 운영

일단 코드가 실무 환경에 배치되고 나면 운영 목표(operational objective )들이 중요해진다.

운영 감시(monitoring )를 위해, 소프트웨어에 계장(instrumentation )을 위한 코드를 포함

해 둔다. 계장 코드는 내부 API로 요청된 트랜잭션들뿐만 아니라 외부 사용자가 요청한 트랜잭

션들을 처리하는 데 걸린 시간도 수집한다. 또한 메모리 사용량 같은 다른 지표들도 감시한다.

이러한 자료 수집 덕분에, 운영상의 결정을 추측이나 운, 희망이 아니라 자료에 근거해서 내릴

수 있다. 수집된 자료를 수년간 축적하므로, 향후의 수용량 증가 필요성을 예측하는 데 활용할

수도 있다.

측정(measurement )은 내부 문제점을 검출하는 데 쓰인다. 특히 측정은 내부 문제점이

아직 작을 때, 즉 사용자에게 보이는 운영 중단(outage )으로까지 번지기 전에 잡아내는 데 유

효하다. 이상적인 운영에서는 문제점들을 운영 중단으로 이어지기 전에 바로잡는다. 실제 운영

중단은 드물며, 아주 세심하게 조사해야 한다. 문제점이 검출되면 그런 문제점을 식별, 처리해

서 빠르게 해결할 수 있게 하는 과정이 진행된다.

자동화된 시스템은 문제점을 검출해서 호출대기(oncall ) 중인 사람에게 경보(alert )를

보낸다. 호출대기 일정은 순번제(rotation )로 정하되, 각 교대근무(shift )* 기간에 평균적으

로 감당할 수 있는 개수의 경보를 받을 수 있도록 시간을 조율한다. 임의의 주어진 시간에서 주

된 호출대기자는 한 사람이며, 그 사람이 경보를 가장 먼저 받게 된다. 그 사람이 제때 응답하

지 않으면 두 번째 사람에게 경보가 전달된다. 호출대기 일정은 사람들이 휴가, 여가 활동, 개

인 시간을 계획할 수 있을 정도로 충분히 미리 준비한다.

발생할 수 있는 모든 경보를 처리하는 방법을 알려주는 ‘각본(playbook; 대응 매뉴얼)’이

존재한다. 각 종류의 경보마다 문제점과 그것이 업무에 미치는 영향 및 해결책을 기술적으로

서술해서 문서화한다. 각본은 계속 개선된다. 호출대기자는 각본에 따라 문제점을 바로잡는다.

각본의 해결책이 충분치 않음이 드러나면 잘 정의된 상부 보고(escalation ) 절차가 진행된다.

보통의 경우 그 절차에 의해 관련 하위 시스템의 호출대기자에게 문제점이 전달된다. 개발자들

도 호출대기 순번에 참여하므로, 자신들이 구축하는 시스템의 운영상의 애로사항을 이해하게

된다.

* 옮긴이_ 이런 문맥에서 shift는 두 가지 의미로 쓰인다. 예를 들어 하루를 8시간 단위로 나누어서 3교대로 근무한다고 할 때, 여덟 시간

이 지나서 근무자를 교대하는 것을 shift라고 부를 뿐만 아니라 여덟 시간의 근무 기간 또는 그 기간에 하는 일 자체도 shift라고 부른다.

이 번역서에서는 전자를 근무 교대, 후자를 ‘교대근무’로 옮기고, 둘의 구분이 중요하지 않을 때에는 간단히 ‘교대’라고도 한다.

391.3 조합

모든 장애에는 그에 해당하는 대응책(countermeasure )이 존재한다. 수동적으로 발동

(활성화)되는 대응책도 있고 자동으로 발동되는 대응책도 있다. 자주 발동되는 대응책들은 항

상 자동화된다. 감시 시스템은 남용(overuse )을 검출한다. 남용은 더 큰 문제점을 나타낼 수

있기 때문이다. 장애율(고장률)을 줄이고 대응책들을 개선하기 위해, 감시 시스템은 기술자들

이 사용하는 내부 지표 자료를 수집한다.

대응책이 덜 자주 발동될수록, 그것이 다음번에 필요할 때 잘 작동하리라는 확신 역시 낮

아진다. 그래서, 덜 자주 발동되는 대응책들에 대해서는 주기적으로, 그리고 자동으로 해당 장

애를 일으켜서 대응책을 발동시켜본다. 비상시 어떻게 행동해야 할지를 모두가 숙지하도록 학

생들에게 화재 대피 훈련을 시키는 것과 마찬가지로, 이상적인 운영 환경에서는 운영에 관한

‘화재 대피 훈련’을 실시한다. 그러면 팀은 대응책 구현에 관한 경험을 쌓게 되며, 대응책이 잘

작동하리라는 확신이 높아진다. 데이터베이스 장애 조치(failover ) 과정이 예기치 않은 의

존성 때문에 작동하지 않을 수도 있는데, 그런 문제점을 일요일 새벽 4시의 운영 중단 상황에

서 알게 되는 것보다는 월요일 아침 10시의 현장 훈련에서 알게 되는 것이 낫다. 이 역시 반복

(repetition )을 꺼리기보다는 증가함으로써 위험을 줄인다는 원칙에 해당한다. 반복을 통해

서 뭔가에 능숙해지는 것을 전문 용어로 ‘연습(practice )’이라고 부른다. 우리는 “연습이 완벽

함을 만든다”는 점을 굳게 믿는다.*

이상적인 환경은 규모 확장(scaling up )이 자동으로 일어난다. 수용량(capacity )이 더

필요해지면 내부 또는 외부 클라우드 제공자로부터 추가 수용량이 도입된다. 단순히 RAM이나

디스크, CPU를 더 투입하는 것보다 구조를 재정립하는 것이 더 나은 해결책일 수도 있는데,

그런 시점이 되었는지는 현황판을 보고 판단할 수 있다.

규모 축소(scaling down ) 역시 자동적이다. 시스템에 과부하가 걸렸거나 퇴행한

(degraded ) 경우에도 “503—Service Unavailable” 오류로 사용자를 외면하는 일은 결코

없다. 대신 시스템은 자동으로 자원을 덜 사용하는 알고리즘으로 전환한다. 대역폭이 소진되

면 서비스의 저대역폭 버전이 작동해서 그래픽을 덜 표시하거나 좀 더 단순화된 사용자 인터페

이스를 표시한다. 데이터베이스가 깨져도, 서비스의 읽기 전용 버전을 통해서 사용자 대부분을

만족시킨다.

* 옮긴이_ practice는 문맥에 따라 연습, 실천, 관행 등 여러 한국어 단어에 대응된다. 이 번역어에서 주로 쓰이는 것은 ‘관행’이다. 관행

과 연습은 동전의 양면과 같다. 뭔가에 능숙해지기 위해 여러 번 되풀이해서 수행하는 것을 연습이라고 한다면, 자주 되풀이하다보니 능숙

해진 뭔가가 바로 관행이다. 안타깝게도 일상에서(특히 신문 기사에서) 관행은 부정적인 의미로 쓰이는 경우가 많지만, 이 책에서 말하는

관행은 중립적이다. 단지 나쁜 관행과 좋은 관행이 있을 뿐이다. 일상에서 관행이 긍정적인 의미로 쓰이는 경우로 ‘모범 관행’이 있는데, 이

는 최고의 관행(best practice)에 해당한다.


서비스의 각 기능을 개별적으로 활성화 또는 비활성화할 수 있다. 어떤 기능이 부정적인

영향(이를테면 보안 구멍이나 예기치 못한 저성능 등)을 미친다는 점이 판명되면, 다른 소프

트웨어 릴리스를 배치하지 않고 그 기능만 비활성화할 수 있다.

한 기능을 개정(revision )해도, 새 코드 때문에 기존 기능성이 제거되지는 않는다. 새 코

드의 행동을 비활성화면 기존 행동이 다시 드러난다. 이는 새로운 사용자 인터페이스를 롤아웃

할 때 특히나 유용하다. 어떤 릴리스가 기존 사용자 인터페이스와 새 사용자 인터페이스를 모

두 생성한다면, 새 사용자 인터페이스를 사용자별로 활성화할 수 있다. 이를 통해 ‘앞서 해보기

(early access )’ 사용자로부터 의견을 받을 수 있게 된다. 공식 릴리스 날짜부터는 점점 더 큰

사용자 그룹들에 대해 새 기능을 활성화한다. 성능 문제가 발견되면 해당 기능을 손쉽게 이전

버전으로 되돌리거나 완전히 꺼버릴 수 있다.

이상적인 환경에는 운영상의 훌륭한 예방 조처가 존재한다. 마치 이를 닦듯이, 우리는 운

영을 위생적으로 유지하는 데 필요한 일들을 정기적으로 수행한다. 모든 대응책과 과정, 경보

를 처리하는 방법에 대한 깔끔한 문서화를 마련하고 갱신한다. 과민반응 경보도 무시하지 않고

세밀하게 조율한다. 해결되지 않은 버그들의 개수를 최소한으로 유지한다. 운영 중단이 발생하

면 향후 시스템 개선안을 포함한 사후 분석(postmortem ) 보고서를 발행한다. 모든 ‘응급조

치(quick fix )’ 후에는 근본 원인을 분석하고 장기적인 해결책을 구현한다.

가장 중요하게는, 개발자들과 운영자들이 자신들을 서로 구별되는 두 개의 팀으로 생각하

지 않는다. 이들은 단지 커다란 한 팀 안에서 각자 특화된 임무를 수행하는 것일 뿐이다. 한 팀

안에서 다른 사람보다 코드를 더 많이 작성하는 사람이 있는가 하면 다른 사람보다 운영 프로

젝트를 더 많이 수행하는 사람이 있는 것이지, 팀 자체가 실제로 구분된 것은 아니다. 모든 사

람은 가동시간(uptime )을 길게 유지할 책임을 공유한다. 이를 위해 모든 구성원은 호출대기

(호출기를 이용한) 순번제에 참여한다. 운영상의 애로사항을 직접 체험한 개발자는 운영에 영

향을 미치는 코드를 대단히 적극적으로 개선하게 된다. 마찬가지로, 운영자가 개발자와 생산적

으로 협동하기 위해서는 개발 과정을 이해할 필요가 있다.

이상이 우리가 생각하는 이상적인 환경이다. 이 책의 나머지 부분은 이를 만들고 실행하는 방

법을 설명한다.

411.3 조합

설계: 시스템 만들기

Part

I

CHAPTER 1 분산 세계에서의 설계

CHAPTER 2 운영을 위한 설계

CHAPTER 3 서비스 플랫폼 선택

CHAPTER 4 응용 프로그램 구조

CHAPTER 5 규모 변화를 위한 설계 패턴

CHAPTER 6 탄력성을 위한 설계 패턴

Part I

설계: 시스템 만들기

43

소프트웨어를 만드는 방법은 두 가지이다. 하나는 결함이 없음이 명백할

정도로 단순하게 만드는 것이고, 또 하나는 명백한 결함이 드러나지 않을

정도로 복잡하게 만드는 것이다.

- C.A.R. 호어Hoare, 1980년 ACM 튜링상 수상 강연에서

구글 검색(Google Search )은 어떻게 작동할까? 페이스북Facebook 타임라인이 24시간 쉬지 않

고 최신의 상태를 유지하고, 아마존Amazon이 점점 커지는 제품 카탈로그를 제때 스캔해서 이 제

품을 산 사람들이 양말도 샀다는 점을 알려줄 수 있는 비결은 무엇일까?

마법일까? 그렇지 않다. 비결은 분산 컴퓨팅(distributed computing )이다.

이번 장은 분산 컴퓨팅 기술을 사용하는 서비스의 설계에 관여하는 것들을 개괄한다. 모든

대형 웹 사이트는 이번 장에서 말하는 것들을 이용해서 자신의 크기와 규모, 속도, 신뢰성을 유

지한다.

분산 컴퓨팅은 대규모 시스템을 구축하는 데 쓰이는 기술로, 핵심은 주어진 작업을 여러

컴퓨터들이 나누어 수행한다는 것이다. 이는 하나의 서비스를 제공하는 소프트웨어를 한 대의

컴퓨터가 실행하는 전통적인 컴퓨팅 시스템이나 여러 컴퓨터가 하나의 중앙집중적 서비스에

접근하는 클라이언트-서버 컴퓨팅과 대조되는 특징이다. 분산 컴퓨팅에서는 수백, 수천의 기

계가 협동해서 하나의 커다란 서비스를 제공한다.

분산 컴퓨팅과 전통적 컴퓨팅의 차이는 여러 가지이다. 그 차이점들 대부분은 분산 컴퓨팅

시스템 자체의 거대한 크기에서 비롯된 것이다. 분산 컴퓨팅 시스템은 수백, 수천의 컴퓨터로

분산 세계에서의 설계

CHAPTER 1


이루어질 수 있으며, 그것을 사용하는 사용자는 수백만, 처리하는 질의의 수는 수십억 규모일

수 있다.

속도(speed )는 중요하다. 서비스가 빠르고 잘 반응한다는 것은 경쟁에서 유리한 장점이

다. 웹사이트 사용자들은 응답이 약 200ms (밀리초) 이내로 돌아오지 않으면 사이트가 느리다

고 생각한다. 그 시간의 대부분을 네트워크 잠복지연(latency )이 차지하므로, 남은 시간이 그

리 넉넉치 않다. 서비스는 얼마 남지 않은 시간 안에 웹페이지를 조합할 수 있어야 한다.

분산 시스템에서는 장애가 일상다반사이다. 하드웨어 고장은 드물지만, 기계가 수천 대이

면 장애가 더 이상 드물지 않은 일이 된다. 따라서 항상 장애가 발생할 것을 가정하고 그것을

극복할 수 있도록 시스템을 설계해야 하며, 장애를 예상하고 소프트웨어를 구현해야 한다. 분

산 세계에서 장애는 이미 예상된 풍경의 일부이다.

분산 시스템은 크기가 어마어마하기 때문에, 그 운영을 반드시 자동화해야 한다. 수백, 수

천 대의 기계가 관여하는 작업을 사람이 손으로 직접 하는 것은 비현실적이다. 소프트웨어의

준비와 배치, 일상적인 운영, 장애 처리에서 자동화는 필수적인 수단이다.

알아야 할 용어들

서버(server ): 어떠한 기능(function )이나 응용 프로그래밍 인터페이스(API )를 제공하는 소

프트웨어. (서버 하드웨어를 말하는 것이 아님.)

서비스(service ): 여러 개의 서버로 이루어진, 사용자에게 보이는 시스템 또는 제품.

기계(machine ): 가상 또는 물리적 기계.*

QPS: queries per second, 즉 초당 질의 수의 약자. 흔히 초 당 웹페이지 방문 횟수나 API

호출 횟수를 뜻한다.

소통(traffic ): 서버에 전달된 질의나 API 호출, 기타 요청들을 통칭하는 용어.

퍼포먼트(performant ): 시스템의 성능이 설계상의 요구사항들을 준수하는(만족 또는 초과)

상태임을 뜻하거나 그러한 시스템을 가리키는 용어로, “performance”와 “conformant”를 합

쳐서 만든 신조어이다.

응용 프로그래밍 인터페이스(Application Programming Interface, API ): 서버와 서버의 의

사소통을 관장하는 규약(프로토콜).

* 옮긴이_ 간단히 말해서 컴퓨터를 뜻하나, 흔히 보는 데스크톱 컴퓨터뿐만 아니라 모든 ‘계산 가능한’ 디지털 기기를 아우르는 용어이다.

451.1 대규모 시스템의 가시성

1.1 대규모 시스템의 가시성

대형 분산 시스템을 관리하기 위해서는 시스템의 가시성(visibility )을 확보할 필요가 있다. 내

부 상태를 조사하는 것을 내성(introspection; 자기 조사)이라고 부르는데, 대형 시스템의 운

영, 디버깅, 조율, 보수를 위해서는 내성 능력이 꼭 필요하다.

전통적인 시스템에서는 한 사람의 기술자가 모든 핵심 구성요소를 감시하거나 시스템의

문제점을 경험에 근거해서 ‘즉시 알아내는’ 것이 가능했다. 그러나 대형 시스템에서는 그런 수

준의 가시성을 반드시 의도적인 설계(정보를 추출하고 그것을 사람이 볼 수 있게 하는)를 통

해서 확보해야 한다. 사람 한 명이나 팀 하나가 시스템의 모든 부분을 직접 챙기는 것은 불가능

하다.

따라서 분산 시스템에서는 구성요소들이 시스템 안에서 일어난 일을 상세히 말해주는 로

그log들을 풍부하게 기록해야 한다. 그리고 그 기록들을 취합해서 한 곳으로 모으고, 저장하고,

분석해야 한다. 시스템이 아주 높은 수준의 정보를 기록할 수도 있다. 예를 들어 사용자가 제품

을 구매할 때마다 로그를 기록하거나 각각의 웹 질의나 API 호출마다 로그를 기록할 수 있다.

또한 코드의 핵심 부분에서 일어난 모든 함수 호출의 매개변수들 같은 더 낮은 수준의 정보도

기록할 수 있다.

시스템은 측정치(metrics )들을 외부에 제공해야 한다. 특정 API 호출 등 관심의 대상이

되는 사건들의 횟수를 세어야 하며, 그러한 횟수를 시스템 외부에서 볼 수 있게 해야 한다.

많은 경우, 시스템은 내부 상태를 특별한 URL을 통해서 제공한다. 예를 들어 Apache

HTTP 웹 서버에는 ‘서버 상태’ 페이지(http://www.example.com/server-status/ )가

있다.

또한, 종종 분산 시스템의 구성요소들은 자신의 건강을 검진하고 그 결과를 가시화한다.

예를 들어 구성요소가 특정 URL을 통해서 시스템이 새 요청을 받을 준비가 되었음을 뜻하는

문자열 “OK”를 제공한다고 하자. 그 URL이 바이트 O 다음에 바이트 K로 이루어진 출력 이외

의 어떤 것을 돌려주었다면(또는 아무것도 돌려주지 않았다면), 시스템이 아직 새 요청을 받

을 준비가 되지 않은 것이다. 부하 분산기(load balancer )는 이러한 정보를 이용해서 서버가

잘 돌아가고 있으며 소통량을 받을 준비가 되었는지 판단한다. 서버가 아직 시동 중이고 초기

화가 끝나지 않았거나 종료 중이면, 또는 기존 요청들은 처리하고 있지만 새 요청을 받지는 않

을 상황이면, 서버는 부정적인 응답을 보낸다.


1.2 단순함의 중요성

서비스의 요구들을 만족하는 한에서 설계를 최대한 단순하게 유지하는 것이 가능하다. 시스템

은 시간이 흐르면서 점차 성장하고 복잡해진다. 처음부터 복잡한 시스템으로 시작하는 것은 애

초에 불리한 상태로 시작하는 것이라 할 수 있다.

시스템을 경쟁력 있게 운영하려면 운영자의 머릿속에 시스템에 대한 심적心的 모형(mental

model )이 갖추어져 있어야 한다. 시스템을 구축할 때에는 머리 속에서 시스템을 운영해 보면

서 그 심적 모형을 이용해서 시스템의 작동 방식을 추적하며, 시스템이 제대로 돌아가지 않아

서 디버깅할 때에도 그 심적 모형에 의존한다. 시스템이 너무 복잡하면 그 누구도 시스템 전체

를 머릿속으로 이해하지 못하는 상황에 부닥친다.

The Elements of Programming Style (Kernighan & Plauger 1978 )에는 다음과 같은

문구가 나온다.

디버깅은 애초에 코드를 작성하는 것보다 두 배 더 어렵다. 따라서, 만일 여러분이 코드를 최

대한 영리하게 작성했다면, 정의에 의해 여러분은 그 코드를 디버깅할 수 있을 정도로 영리하

지는 못한 것이다.

이는 분산 시스템에서도 참이다. 설계를 단순화하는 데 들인 모든 시간은 시스템 운영 시 거듭

해서 보상으로 돌아온다.

1.3 조합

분산 시스템은 다수의 더 작은 시스템들로 구성된다. 이번 절에서는 다음과 같은 근본적인 조

합 패턴(composition pattern )들을 상세히 살펴본다.

● 부하 분산기와 다수의 뒷단 복제본들

● 서버와 다수의 뒷단들

● 서버 트리

471.3 조합

1.3.1 부하 분산기와 다수의 뒷단 복제본들

첫 조합 패턴은 부하 분산기(load balancer )*를 여러 개의 뒷단 복제들과 결합하는 것이다.

[그림 1.1 ]에서 보듯이, 요청들을 받는 것은 부하 분산기 서버이다. 요청마다 부하 분산기는 하

나의 뒷단(backend )을 선택해서 요청을 전달한다. 뒷단의 응답은 다시 부하 분산기 서버로

오며, 부하 분산기는 그것을 원래의 요청자에게 전달한다.

이러한 뒷단들을 복제본(replica )이라고 부르는데, 이는 이들이 모두 같은 뒷단을 복제한

것들이기 때문이다. 같은 요청에 대해 모든 복제본은 같은 응답을 산출해야 한다.

부하 분산기는 현재 살아 있으며 요청을 받을 준비가 되어 있는 뒷단들을 항상 파악하고 있

어야 한다. 부하 분산기는 초 당 수십 번씩 건강 점검(health check ) 질의를 뒷단들에게 보내

며, 그 점검에 실패한 뒷단들에게는 더 이상 소통 요청을 보내지 않는다. 건강 점검은 반드시

빠르게 처리해야 하는 간단한 질의이다. 건강 점검 질의에 대해 시스템은 자신이 소통 요청을

받아야 하는지의 여부를 돌려주어야 한다.

질의를 전달할 뒷단을 선택하는 과정은 간단한 수도 있고 복잡할 수도 있다. 간단한 방

법은 그냥 뒷단들을 차례로 선택하는 것이다. 이를 흔히 라운드로빈round-robin 방식이라고 부

른다. 그런데 뒷단들의 처리 능력이 다를 수도 있다. 그런 경우에는 비례식 라운드 로빈

(proportional round-robin )을 이용해서 더 강력한 뒷단들을 좀 더 자주 선택할 수도 있

* 옮긴이_ 이 책에서는 다른 문서나 웹에서 흔히 쓰이는 용어인 ‘부하 분산기’를 사용하긴 했지만, 단지 부하를 여러 곳으로 나눌 뿐만 아

니라 그럼으로써 시스템 전체에서 부하의 ‘균형’을 맞춘다는 뜻이 부족하다는 점에서 ‘부하 균형기’라는 용어도 생각해 볼 수 있겠다.

부하 분산기

뒷단2뒷단1 뒷단3

그림 1.1 부하 분산기와 다수의 뒷단 복제본들


다. 좀 더 복잡한 방법으로는 최소 부하(least loaded ) 방식이 있는데, 이 접근방식에서 부하

분산기는 각 뒷단의 부하를 추적해서 항상 부하가 가장 적은 뒷단을 선택한다.

부하가 최소인 뒷단을 선택하는 것이 합리적인 방식처럼 들리겠지만, 이를 순진하게 구현

하면 재앙이 될 수 있다. 뒷단에 과부하가 걸렸을 때 그 증상이 즉시 나타나지 않고 한참 후에

야 나타날 수도 있기 때문이다. 이런 문제의 근본 원인은 시스템의 부하를 정확히 측정하기 어

렵다는 점이다. 부하를 서버가 최근 받은 연결의 수로 측정한다면, 연결 중에는 오래 유지되는

것도 있고 빨리 끝나는 것도 있다는 점을 간과하게 된다. CPU 사용량을 기준으로 측정한다면,

입출력(I/O ) 과부하를 간과할 수 있다. 흔히 쓰이는 측정 방식은 최근 5분간 발생한 부하의

후행 평균(trailing average )을 구하는 것이다. 그러나 후행 평균은 말 그대로 평균이기 때문

에 현재가 아니라 과거를 반영한다는 문제점이 있다. 그래서 일시적인 급격한 부하 증가가 한

동안 평균에 반영되지 않게 된다.

부하 분산기 하나가 열 개의 뒷단 복제본들과 결합해 있다고 하자. 각 뒷단의 부하는 80%

이다. 여기에 새 뒷단 하나를 추가한다. 새로 추가된 뒷단에는 아직 부하가 걸리지 않으며, 따

라서 부하 분산기는 그 뒷단을 최소 부하 뒷단으로 선택한다. 순진한 최소 부하 알고리즘은 모

든 소통 요청을 새 뒷단에 보내고, 다른 열 개의 뒷단에게는 전혀 보내지 않는다. 그러면 새 뒷

단의 부하가 급증해서 소통 요청들에 완전히 매몰된다. 이전에 열 개의 뒷단이 처리하던 소통

량을 하나의 뒷단이 처리할 수는 없는 일이다. 부하를 후행 평균으로 측정하면 일정 시간 동안

기존 뒷단들은 실제보다 높은 부하량을 보고하며, 새 뒷단은 실제보다 낮은 부하를 보고하게

된다.

이러한 방식에서 부하 분산기는 한참 동안 새 기계의 부하가 다른 모든 기계의 부하보

다 낮다고 믿는다. 그런 상황에서는 새 기계에 과부하가 너무 걸려서 충돌(crash ) 및 재시동

(reboot )으로 이어질 수 있다. 또는, 상황을 타개하기 위해 시스템 관리자가 직접 새 기계를

재시동할 수도 있다. 어떤 경우이든, 새 기계가 다시 서비스에 참여하면 같은 과정이 반복된다.

이런 상황을 생각하면 단순한 라운드로빈 방식이 상당히 괜찮아 보인다. 최소 부하 방식을

좀 더 현명하게 구현해서, 같은 컴퓨터에게 연속해서 보내는 요청의 수를 제한할 수도 있다. 이

를 느린 시작(slow start ) 알고리즘이라고 부른다.

491.3 조합

순진한 최소 부하 알고리즘의 문제점

느린 시작 기법을 사용하지 않는 부하 분산기가 문제를 일으킨 사례가 많다. 유명한 사례 하나는

2001년 9월 11일의 9.11 공격 당시 CNN.com 웹 사이트에 생긴 일이다. 너무나 많은 사람이

CNN.com에 접속하려 했기 때문에 뒷단들이 과부하되었다. 한 뒷단이 충돌했으며, 재시동된

후 다시 충돌했다. 이는 순진한 최소 부하 알고리즘 때문에 모든 소통 요청이 그 뒷단으로 몰렸

기 때문이다. 그후 다른 뒷단이 과부하가 걸려서 충돌했다. 이런 식으로 각 뒷단이 한 번에 하나

씩 과부하, 충돌, 재시동 후 다시 과부하(모든 소통량이 몰려서), 충돌하는 과정을 되풀이했다.

결과적으로, 시스템 관리자가 상황을 파악하고 해결하는 동안 서비스가 사실상 사용 불가능한

상태가 되었다. 관련자들의 변명은, 웹이 비교적 새로운 것이라서 9월 11에 발생한 급격한 소통

량 증가 같은 사건을 겪어본 사람이 아무도 없었다는 것이었다.

CNN은 모든 뒷단을 중지한 후 동시에 재시동해서 문제를 해결했다. 그러면 모든 뒷단이 부

하가 하나도 없는 상태로 시작하므로 모두가 같은 양의 소통 요청을 받게 된다.

이후 CNN 팀은 사고 며칠 전에 부하 분산기 소프트웨어의 업그레이드본을 받았지만 미처 설

치하지 못했음을 발견했다. 그 업그레이드본에는 느린 시작 메커니즘이 추가되어 있었다.

1.3.2 서버와 다수의 뒷단들

그다음 조합 패턴은 앞단(frontend ) 서버 하나에 여러 개의 뒷단이 결합하는 형태이다. 요청

을 받은 앞단 서버는 여러 뒷단 서버들에게 질의를 보내고, 뒷단들의 응답을 조합해서 최종적

인 응답을 만든다. 이러한 접근방식은 원래의 질의를 여러 개의 독립적인 질의로 해체하고 그

응답들을 다시 조합해서 최종적인 응답을 만드는 것이 쉬운 경우에 주로 쓰인다.

[그림 1.2 ]의 (a )는 간단한 검색 엔진이 다수의 뒷단들의 도움을 받아서 질의를 처리하는

과정을 보여준다. 앞단 서버가 요청을 받아서 여러 뒷단 서버들에게 질의를 전달한다. 철자 검

사(spell check ) 서버는 앞단이 사용자에게 다른 형태의 철자를 제공하는 데 사용할 수 있는

정보를 담은 응답을 제공한다. 웹 검색 뒷단과 이미지 검색 뒷단은 질의에 관련된 웹 사이트 목

록과 이미지 목록을 담은 응답을 돌려준다. 광고 서버는 질의에 관련된 광고들을 돌려준다. 앞

단은 뒷단들이 제공한 정보를 이용해서 검색 결과 페이지(사용자가 볼)를 구성하는 HTML을

생성한 후 사용자에게 전송한다.


서버

광고 이미지 검색 웹 검색 철자 검사

(a) 단일

서버

광고

(b) 복제

이미지 검색 웹 검색 철자 검사

그림 1.2 이 서비스는 하나의 서버와 다수의 뒷단으로 구성된다.

[그림 1.2 ]의 (b )는 기본적으로 (a )와 같은 구조이되, 뒷단들을 복제해서 부하의 균형을

맞춘다는 점이 다르다. (a )와 같은 원칙이 적용되나, 규모가변적이고 장애 시 좀 더 잘 살아남

는다.

이런 종류의 조합에는 여러 장점이 있다. 뒷단들은 자신의 작업을 병렬로 실행한다. 따라

서 한 뒷단의 처리가 끝나야 다음 질의를 처리할 수 있다는 제약이 없다. 시스템은 느슨하게 결

합된다. 한 종류의 뒷단이 실패한다고 해도, 해당 부분에 기본 정보를 채우거나 그냥 비워 두고

페이지를 구축하면 된다.

또한, 이 패턴에서는 좀 더 정교한 잠복지연 관리가 가능하다. 이 시스템이 결과를 약

200ms 이내에 돌려주어야 한다고 하자. 만일 어떤 이유로 뒷단 중 하나의 처리가 늦어져도 앞

511.3 조합

단은 그 뒷단을 기다릴 필요가 없다. 응답들을 조합해서 HTML을 만들고 그것을 전송하는 데

10ms가 걸린다고 할 때, 190ms가 되면 앞단은 느린 뒷단을 포기하고 자신이 가진 정보로 페

이지를 생성해서 전송하면 된다. 이런 식으로 잠복지연 시간 예산(budget )을 관리하는 능력

은 아주 강력한 효과를 낼 수 있다. 예를 들어 광고 시스템이 느리면, 광고가 없는 검색 결과를

표시하면 된다.

잠깐 정리하고 넘어가자면, ‘앞단’과 ‘뒷단’의 구분은 관점에 따라 달라질 수 있다. 기본적으

로 앞단은 뒷단에게 요청을 보내며, 뒷단은 요청을 처리한 결과로 응답한다. 하나의 서버가 앞

단이자 뒷단으로 작용할 수도 있다. 앞의 예에서 서버는 웹 브라우저의 관점에서 볼 때에는 뒷

단이지만 철자 검사 서버의 관점에서는 앞단이다.

이 패턴에는 다양한 변형이 있다. 각 뒷단을 수용량 증대나 탄력성(resiliency; 회복력)

개선을 위해 복제할 수 있으며, 캐싱을 여러 수준에서 수행할 수 있다.

하나의 질의에서 여러 개의 새로운 질의가 나오는 것을 산개(fan out; 또는 전개)라고 말

한다. 질의는 개별 뒷단들로 산개한다. 그 응답들은 다시 앞단으로 집결(fan in )하며, 앞단은

그것들을 취합해서 최종 결과를 만든다.

모든 집결 상황은 혼잡(congestion, 밀집)* 문제를 일으킬 위험이 있다. 종종 작은 질의

에서 아주 많은 수의 응답이 만들어지기도 한다. 그래서 산개에서는 대역폭이 조금만 소비되지

만 집결 시에는 대역폭이 모자라는 경우가 발생한다. 그러면 네트워크 연결들에서 혼잡이 발생

해서 서버에 과부하가 걸리는 결과로 이어질 수 있다. 질의와 응답의 크기가 일관적이거나 커

다란 응답이 가끔만 발생한다면 네트워크와 서버 용량을 미리 적절하게 잡는 것이 가능하다.

그러나 예기치 않은 큰 응답들이 갑자기 몰리는 현상을 대비해서 설계하기란 어려운 일이다.

그런 돌발 사태 시 더 많은 버퍼 공간을 동적으로 마련해서 사태를 완화하도록 설계된 네트워

크 장비도 있다. 그와 마찬가지로, 뒷단이 질의 처리 비율을 스스로 제한함으로써 그런 상황을

애초에 방지할 수도 있다. 끝으로, 앞단은 새 질의들을 뒷단들에 보내는 속도를 제한하거나, 뒷

단들에게 속도를 늦추라고 통지하거나, 또는 질의들의 범람(flood )을 더 잘 처리하는 비상 대

책(emergency measure )을 구현함으로써 혼잡 문제를 관리할 수 있다. 마지막 옵션은 제5

장에서 논의한다.

* 옮긴이_ 혼잡混雜이라는 단어는 뭔가가 “뒤섞여서 어수선한” 상황을 암시하지만, 이런 문맥에서 말하는 ‘congestion’은 “빽빽하게 몰려

있는” 상황에 더 가깝다. 예를 들어 아직 처리되지 않은 자료나 작업이 빽빽하게, 그러나 ‘질서 정연하게’ 모여 있는 상황도 congestion이라고 부를 수 있다는 점에서, ‘혼잡’보다는 ‘밀집密集’이 더 적합한 용어일 것이다. 그러나 기존 관례나 ‘교통 혼잡’ 같은 일상적인 용례와의

연관성 등을 고려해서 ‘혼잡’이라는 용어를 사용하기로 한다.


1.3.3 서버 트리

또 다른 근본적인 조합 패턴은 서버 트리(server tree )이다. [그림 1.3 ]에서 보듯이, 이 방식

에서는 여러 개의 서버가 하나의 트리를 형성해서 함께 작동한다. 하나의 서버 트리에는 뿌

리(root )에 해당하는 서버 하나와 뿌리 아래의 여러 부모 서버들, 그리고 트리 최하단의 잎

(leaf, 말단) 서버들이 있다. (컴퓨터 과학에서는 트리(나무)를 그릴 때 뿌리를 위에 둔다.)

이 패턴의 전형적인 용도는 전문용어로 총체(corpus; 텍스트 자료의 경우에는 말뭉치)라고

부르는 커다란 자료집합(dataset )에 접근하는 것이다. 자료 총체는 임의의 한 기계가 담을 수

있는 것보다 크다. 따라서 각 잎 서버는 전체의 한 부분을 저장한다. 그런 부분을 파편(shard )

이라고 부른다. 뿌리 서버, 잎 서버

전체 자료집합에 대한 질의를 처리하는 과정은 이렇다. 뿌리는 원래의 질의를 받아서 부모

들에게 전달한다. 부모들은 그 질의를 잎 서버들에게 전달하며, 각 잎은 총체 중 자신이 담당한

부분을 검색해서 그 결과를 부모에 보낸다. 부모는 잎 서버 결과들을 정렬하고 걸러서 뿌리에

넘겨준다. 뿌리는 모든 부모의 결과를 취합해서 최종적인 응답을 생성, 전송한다.

어떤 백과사전에서 조지 워싱턴George Washington이 언급된 횟수를 알고 싶다고 하자. 한 가지

뿌리

부모0

잎0

부모1

잎1

그림 1.3 서버 트리

531.3 조합

방법은 한 사람이 백과사전을 구성하는 모든 권(volume )을 차례로 훑으면서 횟수를 세는 것

이다. 아니면, 각 권을 각자 다른 사람에 배정해서 각자가 병렬로 횟수를 세게 할 수도 있다. 최

종 결과를 더 빨리 얻을 수 있는 방식은 후자일 것이다.

이 패턴의 주된 장점은 큰 자료 총체를 병렬로 검색할 수 있다는 것이다. 잎들이 자신의 파

편을 검색하는 것뿐만 아니라, 부모들이 검색 결과를 정렬하고 등급을 매기는 과정 역시 병렬

로 일어난다.

예를 들어 미국 국회도서관의 모든 책에서 발췌한 텍스트로 이루어진 말뭉치를 생각해보

자. 그 말뭉치를 한 대의 컴퓨터에 담을 수는 없기 때문에 수백, 수천의 잎 기계들에 분산시킨

다고 하자. 잎 컴퓨터들 외에 부모들과 뿌리 서버도 있다. 검색 질의는 우선 뿌리 서버로 간다.

뿌리 서버는 그것을 모든 부모 서버에 전달하며, 부모들은 그 질의를 각자 자신의 잎 노드들에

넘겨준다. 잎 노드들의 응답을 받은 부모는 그것들을 유관성(relevancy )에 따라 정렬하고 등

급을 매긴다.

예를 들어 어떤 잎 서버가 한 책에서 질의의 모든 단어가 포함된 문단을 발견했지만, 다른

어떤 책에서는 질의어들 중 일부만 포함된 문단을 발견할 수도 있다(유관성이 더 낮다). 질의

어들이 여러 문단이나 여러 페이지에 흩어져 있는 책을 발견할 수도 있을 것이다(유관성이 더

욱 낮다). 질의가 상위 결과 50개를 돌려달라는 것이었다고 할 때, 부모는 상위 결과 50개만

추려서 뿌리에 보내고 나머지는 폐기한다. 그러면 뿌리는 각 부모의 결과들을 모두 취합해서

그중 상위 50개를 뽑아서 최종 응답을 구축한다.

이러한 방식에서도 개발자들은 잠복지연 예산을 지키는 방식으로 서버들을 설계할 수 있

다. 만일 완벽한 답보다 빠른 답이 더 중요하다면, 잠복지연 마감 시간이 가까워졌을 때 부모들

과 뿌리는 느린 응답들을 더 기다리지 않고 진행하면 된다.

이 패턴을 여러 가지로 변형할 수 있다. 여분의 서버들을 추가해서 작업량을 분산하고 고

장 난 서버를 교체하는 식의 부하 분산 기법을 도입할 수도 있다. 잎 서버들을 늘려서 각 잎 서

버가 말뭉치의 더 작은 부분을 검색하게 할 수도 있고, 말뭉치의 각 파편을 여러 대의 잎 서버

에 배치함으로써 가용성(availability )을 높일 수도 있다. 각 수준에서의 부모들의 수를 늘리

면 결과의 정렬 및 등급 평가 수용량이 증가한다. 뿌리와 잎 사이에 하나가 아니라 여러 수준의

부모들을 둘 수도 있다. 그러면 트리가 더 높아진다. 그런 추가적인 부모 서버 수준들이 있으면

산개를 더 넓힐 수 있는데, 이는 엄청나게 거대한 말뭉치에서 중요한 요인이다. 부모 서버가 잎

서버에 가해지는 압력을 완화하는 캐싱 기능을 제공할 수도 있다. 이 경우 부모 수준이 많을수


록 캐시 효율성이 좋아진다. 이전 절에서 논의했듯이, 이러한 기법들은 집결과 관련된 혼잡 문

제를 완화하는 데에도 도움이 된다.

1.4 상태의 분산

대형 시스템은 저장하거나 처리해야 할 상태(state )의 양도 큰 경우가 많다. 상태는 데이터베

이스처럼 자주 갱신되는 자료로 구성된다. 반면 자료 총체 또는 말뭉치는 비교적 정적이거나

가끔만(이를테면 새로운 판본이 나올 때에만) 갱신된다. 한 예로, 미합중국 의회 도서관을 검

색하는 시스템은 매주 새로운 말뭉치를 받을 것이다. 반면 이메일 시스템에서는 새로운 자료가

끊임없이 들어오고, 자료가 계속 갱신되고(이를테면 특정 편지를 ‘읽은 상태’로 표시하거나 다

른 폴더로 옮기는 등) 삭제된다.

분산 컴퓨팅 시스템이 상태를 다루는 방법은 여러 가지이다. 그러나 그런 방법들은 모두

어떤 형태로든 복제와 파편화(sharding )를 사용한다. 그런데 복제와 파편화는 일관성, 가용

성, 분리와 관련된 문제점을 일으킨다.

상태를 저장하는 가장 간단한 방법은 [그림 1.4 ]에서처럼 그냥 하나의 기계에 상태를 모두

저장하는 것이다. 안타깝게도 이 방법은 순식간에 한계에 봉착한다. 개별 컴퓨터가 담을 수 있

는 상태의 양에는 한계가 있으며, 만일 그 컴퓨터가 죽으면 시스템은 모든 상태에 접근할 수 없

게 된다. 또한 개별 컴퓨터의 처리 능력은 유한하며, 따라서 동시적인 상태 읽기 및 쓰기 연산

횟수에 상한이 존재한다.

분산 컴퓨팅에서는 전체 상태를 여러 ‘파편’들로 나누어서 여러 대의 컴퓨터에 분산 저장한

다. 이렇게 하면 최대 저장 용량은 오직 사용 가능한 기계의 수로만 한정된다. 또한, 하나의 파

N qps

데이터베이스

상태M개의 객체

그림 1.4 상태를 한 장소에 담기: 분산 컴퓨팅이 아니다.

551.4 상태의 분산

편을 여러 기계에 저장할 수 있으므로, 한 기계가 고장나도 상태에 접근하지 못하게 되는 일이

없다. 각 복제본은 초당 일정 횟수의 질의를 처리할 수 있으므로, 초당 처리할 수 있는 동시적

상태 읽기/쓰기 요청을 늘리고 싶다면 복제본의 수를 더 늘리면 된다. [그림 1.5 ]가 이상의 방

법을 나타낸 것이다. 그림의 예에서 부하 분산기는 초당 N개의 질의를 받아서 세 파편에 분산

한다. 각 파편은 세 개의 복제본으로 이루어져 있다. 따라서 각 복제본 서버는 평균적으로 전체

상태 질의의 9분의 1을 처리한다.

상태 쓰기, 즉 상태 갱신 요청이 들어오면 모든 복제본을 갱신해야 한다. 이 갱신 과정이

진행되는 동안 어떤 클라이언트가 아직 갱신되지 않은 상태 복제본에서 상태를 읽는 일이 발생

할 수도 있다. [그림 1.6 ]은 하나의 쓰기가 아직 갱신되지 않은 캐시의 읽기 때문에 복잡해지는

상황을 보여준다. 이에 대해서는 다음 절에서 좀 더 논의하겠다.

대부분의 간단한 패턴에서, 상태 저장·조회 요청들을 받는 것은 뿌리 서버이다. 뿌리 서

버는 해당 상태가 담긴 파편을 파악해서 그에 해당하는 잎 서버에 요청을 전달한다. 잎 서버의

응답은 트리를 따라 올라와서 뿌리 서버에 도달한다. 이전 절에서 본 서버 트리 패턴과 비슷해

보이지만, 다른 점이 두 가지 있다. 첫째로, 질의는 모든 잎 서버가 아니라 하나의 잎 서버에만

전달된다. 둘째로, 읽기 요청뿐만 아니라 갱신(쓰기) 요청이 들어올 수도 있다. 하나의 상태

파편이 여러 복제본에 저장되어 있으면 갱신이 좀 더 복잡하다. 하나의 파편을 갱신하려면 그

에 해당하는 모든 복제본을 갱신해야 한다. 이를 위해 뿌리 서버가 모든 잎 서버를 갱신하게 할

수도 있고, 잎 서버들이 서로 의사소통하면서 갱신들을 진행하게 할 수도 있다.

shard0

state

shard0

state

shard0

state

shard0

state

shard0

state

shard0

state

N qps

N/3 qps

파편당 복제본 3개

분산기

파편0

상태

파편1

상태

파편2

상태

그림 1.5 상태를 다수의 복제본으로 이루어진 여러 파편으로 분산한다.


상태

뒷단0 캐시

앞단0 앞단1 앞단2

분산기

읽기

쓰기

그림 1.6 캐싱된 자료를 이용해서 상태를 갱신하면 일관되지 않은 뷰가 생길 수 있다.

이 패턴의 한 변형으로, 대량의 자료를 전송할 때 좀 더 적합한 것이 있다. 이 변형에서 뿌

리 서버는 자료 자체가 아니라 자료를 얻는 방법에 관한 정보를 알려준다. 요청자는 그 정보를

이용해서 해당 자료원(data source )에게 직접 자료를 요청한다.

예를 들어 수 페타바이트(1페타바이트는 약 1,000테라바이트)의 자료가 수천 대의 기

계에 분산된 분산 파일 시스템을 생각해보자. 각 파일은 기가바이트 크기의 토막(chunk )들

로 나누어져 있다. 각 토막은 중복성을 위해 여러 대의 기계에 저장된다. 이러한 방식에서는

하나의 기계에 담을 수 있는 것보다 더 큰 파일을 생성하는 것도 가능하다. 주 서버(master

server )는 파일들의 목록을 관리하고 파일의 토막들이 있는 장소를 식별한다. UNIX 파일 시

스템에 익숙한 독자라면, 주 서버는 i-노드(inode )들, 즉 파일당 자료 블록들의 목록들을 저

장하고, 다른 기계들은 실제 자료 블록들을 저장한다고 생각하면 이해가 쉬울 것이다. 파일 시

스템 연산 요청은 주 서버로 전달되며, 주 서버는 i-노드 비슷한 정보를 이용해서 그 연산에 관

련된 개별 기계를 찾아낸다.

571.5 CAP 원리

커다란 읽기 연산 요청이 하나 들어왔다고 하자. 주 서버는 해당 읽기 중 몇 테라바이트는

한 컴퓨터에 저장되어 있고 나머지 몇 테라바이트는 다른 컴퓨터에 저장되어 있음을 파악한다.

이때 주 서버가 두 컴퓨터에서 자료를 읽어서 요청자에게 돌려줄 수도 있지만, 커다란 자료 토

막을 받고 넘겨주다 보면 주 서버가 금세 과부하될 수 있다. 대신 주 서버는 자료가 있는 컴퓨

터들의 목록을 요청자에게 돌려주고, 요청자는 그 목록을 이용해서 해당 기계들에 직접 접촉한

다. 이 경우 주 서버는 대량 자료 전송의 중간자(middle man ) 역할을 하는 것이 아니다. 이

러한 상황이 [그림 1.7 ]에 나와 있다.

클라이언트1

일꾼1

주 서버

일꾼2 일꾼3

클라이언트0

일꾼0

그림 1.7 이 주 서버는 클라이언트에 대한 응답을 다른 서버들에 위임한다.

1.5 CAP 원리

CAP는 Consistency (일관성), Availability (가용성), Partition resistance (분리 저항)를

뜻한다. CAP 원리란, 일관성과 가용성, 그리고 분리에 대한 저항을 모두 보장하는 분산 시스

템은 구축하는 것이 불가능하다는 것이다. 둘 중 임의의 하나나 둘은 달성할 수 있지만, 셋을

동시에 달성할 수는 없다. 그런 시스템을 사용할 때에는 무엇이 보장되고 무엇이 보장되지 않

는지를 반드시 파악해야 한다.


1.5.1 일관성

일관성은 모든 노드가 같은 시점(time )에서 같은 자료를 본다는 뜻이다. 일관성을 보장하는

시스템에서는, 다수의 복제본에 대해 갱신이 진행되는 도중 모든 사용자는 비록 각자 다른 복

제본에서 자료를 읽는다고 해도 모두 같은 시점에서 동일하게 갱신된 자료를 보게 된다. 일관

성을 보장하지 않는 시스템이라고 해도 결과적 일관성(eventual consistency )을 보장할 수

는 있다. 예를 들어 어느 정도 시간이 지나면 임의의 갱신이 모든 복제본에 전파된다는 점을 보

장하는 것이 가능하다. 물론 그 시간에 도달하기 전에는, 어떤 질의는 새 자료를 담은 응답을

받지만 어떤 질의는 오래된, 갱신되지 않은 자료를 담은 응답을 받을 수 있다.

완벽한 일관성이 항상 중요한 것은 아니다. 어떤 소셜 네트워크가 긍정적인 행동을

한 독자에게 명성치 점수를 보상으로 제공한다고 상상해 보자. 사용자의 총 명성치 점수

(reputation point )는 사용자의 이름과 함께 항상 표시된다. 명성치 데이터베이스는 북미와

유럽, 아시아의 서버들에 복제되어 있다. 유럽의 한 사용자가 명성치 점수를 받았다고 할 때,

그 변화가 북미와 아시아 복제본에 전파되기까지는 몇 분이 걸린다. 절대적으로 정확한 명성치

가 사용자 이름과 함께 표시되는 것이 그 소셜 네트워크의 필수적인 기능은 아니므로, 몇 분의

지연시간은 용납할 수 있다. 네트워크 혼잡 때문에 수 분이 더 걸리거나 심지어 네트워크 장애

때문에 수 시간이 걸린다고 해도 아주 심각한 사고는 아닐 것이다.

그러나 같은 시스템으로 은행 거래 응용 프로그램을 만든다고 생각해 보자. 북미의 한 사

용자와 유럽의 한 사용자가 미리 짜고 같은 시간에 같은 계정에서 돈을 찾기로 한다. 각 사용자

가 사용하는 ATM은 가장 가까운 데이터베이스 복제본에 질의를 보낸다. 만일 금액이 잔고를

넘지 않는다면 실제로 돈이 인출될 것이다. 그런데 해당 갱신이 너무 늦게 전파되면, 은행이 돈

이 이중으로 빠졌다는 점을 깨닫기도 전에 두 사람은 각자 현찰을 챙겨서 떠날 것이다.1

1.5.2 가용성

가용성이 있다는 것은, 모든 요청이 그 요청의 성공 또는 실패 여부에 관한 응답을 반드시 받게

된다는 뜻이다. 아주 간단히 말하면 가용성은 시스템이 정상적으로 가동 중이라는 뜻이다. 예

1 사실 전 지구적 ATM 시스템은 데이터베이스 일관성을 요구하지 않는다. 불순한 사용자가 네트워크 지연이나 장애를 악용해서 데이터

베이스 일관성을 깨는 것이 가능하기 때문이다. 은행으로서는, ATM 네트워크가 죽었을 때 제한된 양의 금액을 포기하는 쪽이 돈을 못 찾

아서 불만인 고객들을 다루는 쪽보다 비용이 덜 든다. 사기성 거래는 사건이 일어난 후에 처리한다. 일일 인출량 제한 덕분에 큰 금액의 사

기가 방지된다. 초과요금(overage fee)을 산정하는 것이 전 지구적으로 일관된 데이터베이스를 구현하기보다 더 쉽다.

591.5 CAP 원리

를 들어 클라이언트가 항상 접근할 수 있는 자료를 여러 복제본에 저장해 두면, 그 복제본 중

하나만 돌아가도 가용성이 보장된다.

CAP 원리에서 말하는 가용성은 시스템이 장애를 보고하는 능력을 갖추고 있다는 뜻이기

도 하다. 예를 들어 시스템은 자신이 과부하 상태임을 감지하고, 요청자에게 ‘나중에 다시 시도

하세요’라는 뜻의 오류 코드를 보낼 수 있다. 요청자의 관점에서는, 응답을 몇 분이나 몇 시간

동안 기다리다가 포기하고 떠나는 것보다는 즉시 이런 오류 코드를 받는 것이 더 낫다.

1.5.3 분리 저항

분리 저항 또는 분리 내구성(partition tolerance )은 임의의 메시지가 유실되거나 시스템 일

부가 실패해도 시스템이 계속 가동함을 뜻한다. 분리 내구성의 가장 간단한 예는, 어떤 서비스

를 담당하는 기계의 네트워크 연결이 끊겨서(‘분리’) 다른 기계들과 통신하지 못해도 시스템

자체는 계속 운영되는 것이다(그림 1.8 ).

복제본의 예로 돌아가서, 만일 시스템이 읽기 전용이라면 시스템의 분리 내구성을 갖추는

것이 어렵지 않다. 그런 시스템에서는 복제본들이 서로 통신할 필요가 없기 때문이다. 그러나

복제본들이 상태를 담고 있다면 상황이 다르다. 그런 경우 한 복제본을 먼저 갱신하고, 그것을

다른 복제본에 복사해야 한다. 만일 복제본들이 서로 통신할 수 없으면 시스템은 시간이 지나

면 갱신들이 전파될 것임을 보장할 수 없으며, 따라서 시스템 자체가 실패하게 된다.

이제 두 서버가 감독-일꾼* 관계로 작동한다고 하자. 둘 다 상태의 완전한 복사본을 유지

하며, 만일 감독에 장애가 발생하면 일꾼이 감독의 역할을 맡는다. 감독의 장애 여부는 ‘심박

(heartbeat )’에 대한 응답 여부로 판정한다. 심박은 두 서버 사이의 주기적인 건강 점검 질의

를 뜻하는데, 전용(dedicated ) 네트워크를 통해서 주고받는 경우가 많다. 둘 사이의 심박 네

트워크가 분리되면, 비록 원래의 감독이 아직 가동 중일 수도 있지만 그래도 심박 네트워크를

통해서 통신할 수 없는 상황이므로, 일꾼은 자신을 감독으로 격상시킨다. 그러면 시스템에 두

개의 감독이 있는 상황이 되어서 시스템이 실패한다. 이런 상황을 분리된 뇌(split brain )라고

부른다.

* 옮긴이_ 원문은 master-slave(주인-노예)이지만, 좀 더 순화된 용어인 boss-worker에 해당하는 감독-일꾼으로 대체했다. 사실

이 예에서 주로 일하는 것은 일꾼(노예)이 아니라 감독(주인)이라는 점에서 원문 자체에 조금 오해의 소지가 있는데, 아마도 “한 곳에 감독

(주인)이 둘인 모순적인 상황”을 강조하려다 보니 이런 용어를 사용한 것이 아닌가 한다.


복제본4

복제본0

복제본3

복제본1

복제본2

분리

그림 1.8 서로 분리된 노드들

분리에는 몇 가지 특별한 경우가 존재한다. 패킷 소실(packet loss; 또는 패킷 유실)은

CAP 원리가 적용된다는 점에서 시스템의 일시적 분리로 간주된다. 또 다른 특별한 경우는 네

트워크가 완전히 먹통이 되는 것이다. 분리를 가장 잘 견디는 시스템이라도 그런 상황에서는

가동될 수 없다.

앞에서 말했듯이 CAP 원리는 이상의 세 가지 특성 중 임의의 하나나 둘은 달성할 수 있지

만 셋 모두 달성할 수는 없다는 것이다. 2002년에 길버트Gilbert와 린치Lynch는 원래의 추측에 대

한 공식적인 증명을 발표했다. 이에 의해 CAP 원리는 하나의 정리(theorem )가 되었다. 이

를, 두 특성의 달성을 위해 세 번째 특성이 희생하는 것으로 생각해도 될 것이다.

[그림 1.9 ]는 CAP 원리를 삼각형으로 도식화한 것이다. Oracle이나 MySQL,

PostgreSQL 같은 전통적인 관계형 데이터베이스는 CA로 표시되어 있는데, 이는 이들이 일관

성(C )과 가용성(A )을 보장한다는 뜻이다. 이런 데이터베이스 시스템은 트랜잭션과 기타 데

이터베이스 기법들을 이용해서 갱신이 원자적으로 진행됨을 보장한다. 즉, 갱신은 완전히 전

파되거나, 전혀 전파되지 않는다. 따라서 모든 사용자는 같은 시점에서 반드시 같은 상태를 보

게 된다. Hbase, Redis, Bigtable 같은 좀 더 최근의 저장 시스템들은 CP에, 즉 일관성과 분

리 내구성(P )에 초점을 둔다. 분리가 발생했을 때 이런 시스템들은 어떤 사용자는 기존 내용

을 보고 또 어떤 사용자는 새로운 내용을 보는 비일관적 상황을 허용하는 대신, 읽기 전용으로

전환하거나 모든 요청에 응답하지 않음으로써 일관성을 보장한다. 마지막으로, Cassandra나

Riak, Dynamo 같은 시스템들은 AP, 즉 가용성과 분리 내구성에 초점을 둔다. 이들은 비록

611.5 CAP 원리

일부 클라이언트가 예전 자료를 담은 결과를 보는 일이 있더라도 서버가 요청에 항상 응답할

수 있게 만드는 것을 강조한다. 그런 시스템은 각 복제본이 인터넷처럼 신뢰성이 떨어지는 매

체를 통해서 서로 통신하는 전 지구적(global )* 분산 네트워크에 많이 쓰인다.

SQL이나 기타 관계형 데이터베이스는 CAP 삼각형의 해당 변(CA )을 ACID라

는 용어로 서술한다. ACID는 Atomicity (원자성; 트랜잭션은 “전부 아니면 전무”이다),

Consistency (일관성; 각 트랜잭션 이후 데이터베이스는 유효한 상태이다), Isolation (격리

성; 동시적인 트랜잭션들은 직렬로 실행했을 때와 동일한 결과를 낸다), Durability (내구성;

완수된 트랜잭션의 자료는 충돌이나 기타 문제가 발생해도 유실되지 않는다)를 뜻한다. 더 약

한 일관성 모형을 제공하는 데이터베이스들을 흔히 NoSQL이라고 부르는데, 그런 데이터베

이스들은 자신을 BASE라고 표현한다. BASE는 Basically Available Soft-state services

with Eventual consistency (결과적 일관성을 갖춘, 기본적으로 가용인 약 상태 서비스)를

줄인 것이다.

MongoDB, HBase, Redis, MemcacheDB, Bigtable 같은 시스템들

항상 접근 가능하고 가동 가능한 상태를 유지한다

가용성

Voldemort, Riak, Cassandra, CouchDB, Dynamo

같은 시스템들

분리 내구성네트워크 전체가 실패한

경우에만 시스템이 부정확하게 응답한다.

일관성커밋들이

분산 시스템 전체에서 원자적이다

전통적인 관계형 데이터베이스(PostgreSQL, MySQL)와

Vertica, Spanner

그림 1.9 CAP 원리

* 옮긴이_ 흔히 ‘전역’이라고 하지만, 실제로 지구 전체를 의미하는 경우에는 ‘시스템 전역’ 같은 용법과 구분하기 위해 ‘전 지구적’이라는

용어를 사용하기로 한다.


1.6 느슨히 결합된 시스템

우리는 분산 시스템이 고도의 가용성을 제공하고, 오랫동안 지속되고, 장애 없이 진화하고 변

화하길 기대한다. 시스템이 가동, 운영되는 중에 하위 시스템을 통째로 교체하는 일도 흔하다.

이를 달성하기 위해 분산 시스템은 추상 (abstraction )을 이용해서 느슨히 결합된

(loosely coupled ) 시스템을 구축한다. 추상은 각 구성요소가 구현 세부를 숨기는 방식으

로 정의된 인터페이스를 제공함을 뜻한다. 시스템의 각 구성요소가 다른 구성요소의 내부에 관

해 아는 것이 (거의) 없을 때, 그러한 시스템을 가리켜 “느슨히 결합되었다”라고 말한다. 느슨

히 결합된 시스템에서는 한 하위 시스템을 그 하위 시스템과 동일한 추상 인터페이스를 제공하

는 다른 하위 시스템으로 교체할 수 있다. 심지어 구현이 완전히 다르다고 해도 그런 일이 가능

하다.

예를 들어 철자 검사 서비스를 생각해보자. 이 서비스를 적절한 수준으로 추상한다면, 텍

스트를 받아서 철자가 틀린 단어들을 식별하고 틀린 단어마다 그것을 바로잡을만한 대안 단어

들의 목록을 만들어서 돌려주는 서비스라고 서술할 수 있다. 그러나 그냥 “앞단들이 비슷한 단

어들을 질의할 수 있는 어휘 목록(lexicon )에 대한 접근을 제공한다”라고 말하는 것은 잘못된

수준의 추상일 것이다. 만일 철자를 검사하는 전혀 새로운 방식이 고안된다면 철자 검사 서비

스를 사용하는 모든 앞단을 다시 작성해야 한다는 점에서, 후자는 좋은 추상이 아니다. 새 버전

의 철자 검사 서비스가 어휘 목록에 의존하지 않고 기계 학습이라고 하는 인공지능 기법을 적

용한다고 가정하자. 좋은 추상에서는 그 어떤 앞단도 수정할 필요가 없다. 앞단들은 여전히 같

은 종류의 요청을 새 철자 검사 서버에 보내면 된다. 그러나 나쁜 추상을 사용한다면 앞단들을

모두 뜯어고쳐야 한다.

이런 이유와 기타 여러 이유로, 느슨히 결합된 시스템은 시간이 흐름에 따라 진화시키고

변경하기가 쉽다.

철자 검사 서비스의 예를 계속 이어서, 새 철자 검사 서비스의 개시를 준비하는 과정에서

기존 버전과 새 버전을 병렬로 실행할 수도 있다. 그런 경우 철자 검사 시스템의 앞단에 놓인

부하 분산기가 모든 요청을 새 시스템과 기존 시스템 모두에 보내게 할 수도 있다. 사용자에게

는 기존 버전의 결과를 보내되, 새 버전의 결과를 수집하고 그것을 기존 버전의 결과와 비교해

서 품질 관리에 활용하면 좋을 것이다. 초기에는 새 시스템이 기존 시스템만큼 좋은 결과를 내

지 못할 수 있지만, 시간이 지남에 따라 점차 개선되어서 결국에는 기존 시스템보다 더 나은

(측량 가능한 수준으로) 결과를 내게 될 것이며, 그러면 새 시스템을 실무(production )에 투

631.6 느슨히 결합된 시스템

입하면 된다. 신중을 기하려 한다면, 처음에는 모든 질의의 1%만 새 시스템에 보내고, 만일 불

만을 제기하는 사용자가 없다면 좀 더 큰 비율의 질의를 새 시스템에 보내는 방식도 가능할 것

이다. 결국에는 모든 질의를 새 시스템이 처리하는 시점에 도달할 것이며, 그러면 기존 시스템

을 폐기해도 된다.

철자 검사 시스템보다 정밀도와 정확성이 좀 더 높아야 하는 시스템도 있다. 예를 들어 새

시스템이 기존 시스템과 버그 대 버그까지 호환됨을 확인한 후에야 새 시스템을 실무에 투입해

야 한다는 조건이 걸릴 수도 있다. 즉, 새 시스템은 기존 시스템의 기능뿐만 아니라 버그들도

그대로 재현해야 한다. 이 경우 두 시스템 모두에 요청을 보내서 그 결과를 비교하는 기능은 시

스템을 배치하는 운영팀에게 없어서는 안 될 기능이다.

사례 연구: 에뮬레이션 후 개선

Cibernet에서 일할 때 톰*은 기존 시스템을 교체하는 프로젝트에 관여한 적이 있다. 그 시스템

은 금융 시스템이었기 때문에, 새 시스템이 기존 시스템과 버그 대 버그 수준으로 호환됨을 확인

한 후에야 새 시스템을 배치할 수 있었다.

기존 시스템은 웹 이전의 구식 기술로 구축된 것으로, 너무나 복잡해지고 굳어져서 새 기능을

추가하는 것이 불가능했다. 새 시스템은 좀 더 새롭고 나은 기술로 구축되었으며, 설계가 더 깔

끔했기 때문에 새 기능성을 좀 더 쉽게 도입할 수 있었다. 톰이 속한 팀은 두 시스템을 병렬로 실

행해서 결과를 비교했다.

그 시점에서 기술자들이 기존 시스템의 버그를 하나 발견했다. 화폐 단위 변환이 비표준적인

방식으로 실행되어서 변환 결과에 약간의 오차가 있었던 것이다. 두 시스템의 결과를 비교할 수

있게 하려고 개발자들은 그 버그를 역공학(reverse-engineering )해서 새 시스템에서 버그를

에뮬레이션했다.

덕분에 기존 시스템과 새 시스템의 결과가 1센트 단위까지 일치했다. 회사는 새 시스템이 기

존 것과 버그 대 버그 수준으로 호환된다는 점을 좀 더 확신하게 되었으며, 그래서 새 시스템을

주 시스템으로 만들고 기존 시스템을 비활성화시켰다.

그때부터는 새 기능들과 개선들을 시스템에 도입할 수 있었다. 예상했겠지만, 첫 번째 개선은

화폐 단위 변환 버그를 에뮬레이션하는 코드를 제거하는 것이었다.

* 옮긴이_ 저자 중 한 명인 토머스 리몬첼리Thomas A. Limoncelli를 말한다.


1.7 속도

지금까지 대형 분산 시스템의 설계에 관련된 여러 고려사항을 상세히 설명했다. 웹이나 기타

대화식(interactive ) 서비스에서는 한 가지 항목이 가장 중요한데, 바로 속도(speed )이다.

정보를 얻고, 저장하고, 계산하고, 변환하고, 전송하는 데에는 시간이 걸린다. 그 어떤 일도 즉

시 일어나지는 않는다.

대화식 시스템은 반응이 빨라야 한다. 사용자는 약 200ms보다 빠른 것을 ‘즉시’라고 느끼

는 경향이 있다. 또한, 사용자는 느린 것보다는 빠른 것을 선호한다. 50ms 정도의 짧은 지연을

웹 사이트에 인위적으로 추가하자 수익이 급격히 떨어진 사례를 보고한 연구들이 있다. 시간은

총 처리량(throughput; 산출량)이 작업 유입량과 일치하거나 초과해야 하는 일괄식, 비대화

식 시스템에서도 중요하다.

퍼포먼트한 시스템을 설계하는 일반적인 전략은, 하나의 요청을 처리하는 데 걸리는 시간

을 최대한 잘 추정하고, 원형을 구축해서 그 추정치를 검증해 보는 것이다. 만일 추정치가 틀렸

다면 다시 추정 단계로 돌아가서 같은 과정을 반복한다. 다음 반복에서는 적어도 그때까지 배

운 것들을 활용해서 더 나은 결과를 얻을 수 있을 것이다. 시스템을 구축해 나가는 과정에서 만

일 추정치와 원형이 우리가 기대했던 것만큼 좋은 지침을 제공하지 못함을 발견한다면, 설계를

재측정하고 조정하면 된다.

설계 과정의 초반에는 여러 개의 설계를 만들어서 각각의 속도를 추정하고 충분히 빠르지

않은 것들을 제거하는 식으로 진행하는 경우가 많다. 이때 무조건 가장 빠른 설계를 선택하지

는 않는다. 가장 빠른 설계가 충분히 빠른 설계보다 훨씬 비용이 클 수 있기 때문이다.

주어진 설계가 추구할만한 가치가 있는 설계인지 어떻게 판단할까? 원형을 구축하는 데에

는 시간이 오래 걸린다. 몇 가지 간단한 추정 요령들을 이용하면 시간을 크게 줄일 수 있다. 한

가지 요령은, 흔한 트랜잭션 몇 개를 택해서 더 작은 단계들로 분할하고, 각 단계에 걸리는 시

간을 추정하는 것이다.

시간을 가장 많이 잡아먹는 요인 두 가지는 디스크 접근과 네트워크 지연이다.

디스크 접근이 느린 것은 물리적(기계적) 작동이 관여하기 때문이다. 한 블록의 자료를 디

스크에서 읽으려면 읽기 팔(read arm )을 적절한 트랙으로 이동해야 하고, 해당 블록이 읽기

헤드 아래에 올 때까지 플래터platter를 회전해야 한다. 일반적으로 이 과정에 10ms가 걸린다.

같은 양의 정보를 RAM에서 읽는 데에는 0.002ms밖에 걸리지 않는다. 이는 약 5,000배 빠른

속도이다. 읽기 팔과 플래터(스핀들spindle이라고 부른다)는 한 번에 하나의 요청만 처리할 수

651.7 속도

있다. 그러나 일단 읽기 헤드가 적절한 트랙 위에 놓이면, 그때부터는 연속된 다수의 블록을 읽

을 수 있다. 따라서 두 블록이 인접해 있다면 블록 두 개를 읽는 데 걸리는 시간이 블록 하나를

읽는 데 걸리는 시간에 거의 근접한 경우가 많다. SSD (solid-state drive; 고체 상태 드라이

브)에는 기계적으로 회전하는 플래터가 없어서 훨씬 빠르지만 더 비싸다.

네트워크 접근이 느린 근본 이유는 빛의 속도가 유한하기 때문이다. 하나의 패킷이 캘리포

니아에서 네덜란드로 가려면 약 75ms가 걸린다. 그 여행 시간의 약 절반은 빛의 속도 때문이

다. 그리고 각 라우터나 구리선과 광섬유 통신 사이의 변환을 담당하는 전자기기의 처리 시간

과 통신의 양 끝단에서 패킷을 조립하고 해체하는 데 걸리는 시간 등도 지연 시간에 기여한다.

같은 네트워크 구획 안의 두 컴퓨터는 마치 즉각적으로 통신하는 것처럼 보이지만 실제로

는 그렇지 않다. 이 경우에는 시간 척도가 아주 작아서 다른 지연들이 미치는 영향이 더 커진

다. 예를 들어 지역망에서 자료를 전송할 때 첫 바이트는 빠르게 도달하겠지만, 받은 쪽의 프로

그램은 패킷 전체가 도달해야 비로소 자료를 처리할 수 있다.

여러 시스템에서, 실제 계산에 걸리는 시간은 네트워크 지연과 디스크 연산에 비하면 미

미한 수준이다. 따라서 그냥 사용자와 데이터센터 사이의 거리와 필요한 디스크 탐색(disk

seek ) 횟수만 알면 한 트랜잭션에 걸리는 시간을 추정할 수 있는 경우가 많다. 대체로, 그런

식으로 얻은 추정치는 명백히 나쁜 설계들을 걸러내는 목적으로는 충분히 유용하다.

이해를 돕기 위해, 메시지 저장 시스템에서 메시지를 하나 받아서 표시하기까지의 시간이

300ms를 넘지 않아야 한다는 요구 조건이 있는 이메일 시스템을 구축하는 예를 생각해보자.

[그림 1.10 ]은 해결책을 구축하는 데 사용할 몇 가지 시간 근사치들이다.

먼저 트랜잭션을 처음부터 끝까지 따라가보자. 다른 대륙에 있을 수도 있는 어떤 사용자가

웹 브라우저를 통해서 요청을 보낸다. 시스템은 먼저 그 요청을 인증(authentication )한다.

그런 다음 요청된 메시지 텍스트가 저장되어 있는 위치를 데이터베이스 색인을 이용해서 파악

하고, 그 메시지 텍스트를 조회하고, 최종적으로 응답을 서식화(formatting )해서 사용자에게

보낸다.

이제 우리가 제어할 수 없는 항목의 예산을 추정해보자. 캘리포니아에서 유럽으로(또는 그

반대로) 패킷을 보내는 데에는 보통 75ms가 걸리는데, 빛의 속도를 바꾸는 것은 물리적으로

불가능하므로 이 시간을 더 줄일 수는 없다. 요청이 오는 데 그만큼의 시간이 걸리는 것과 마찬

가지로 응답을 보내는 데에도 그만큼의 시간이 걸리므로, 300ms 예산에서 총 150ms를 제해

야 한다. 우리가 제어할 수 없는 항목이 예산의 절반을 차지한 셈이다.


구글의 특별 연구원(Fellow)인 제프 딘Jeff Dean이 널리 알린 이 표는 구축이나 규모 조정 시 도움이 되는 주요 수

치들을 제공한다. 이 표에서 보듯이, 시간 차이가 몇 배 수준이 아니라 10의 몇 거듭제곱배 수준인 옵션들이 존재

한다. 이 수치들은 매년 개선된다. 개정판을 웹에서 찾을 수 있을 것이다.

동작 전형적인 시간

L1 캐시 참조 0.5ns

분기 예측 실패 5ns

L2 캐시 참조 7ns

뮤텍스 잠금/해제 100ns

주 메모리 참조 100ns

1K 개의 바이트들을 Zippy로 압축 10,000ns (0.01ms)

2K 개의 바이트들을 1Gbps 네트워크에서 전송 20,000ns (0.02ms)

1MB의 자료를 메모리에서 순차적으로 읽기 250,000ns (0.25ms)

같은 데이터센터 안에서의 왕복운행(rount trip) 1회 500,000ns (0.5ms)

1MB의 자료를 SSD에서 읽기 1,000,000ns (3ms)

디스크 탐색 10,000,000ns (10ms)

1MB의 자료를 네트워크에서 순차적으로 읽기 10,000,000ns (10ms)

1MB의 자료를 디스크에서 순차적으로 읽기 30,000,000ns (30ms)

패킷을 캘리포니아에서 네덜란드로, 다시 캘리포니아로 전송 150,000,000ns (150ms)

그림 1.10 모든 기술자가 알아야 할 수치들

다음으로 인증에는 얼마만큼의 시간이 필요할까? 인증 시스템을 운영하는 팀에게 문의해

보니 3ms로 잡는 것이 좋겠다고 한다.

자료의 서식화에는 시간이 거의 걸리지 않는다. 다른 추정치에 비하면 새 발의 피이므로

무시해도 된다.

이제 147ms가 남았는데, 이 시간 안에 저장소에서 메시지를 조회해야 한다. 전형적인 색

인 조회에 디스크를 세 번 탐색하고(탐색 1회당 10ms ) 1MB의 정보를 읽어야 한다고 하자.

1MB를 읽는 데 30ms가 소비되므로 총 60ms가 필요하다. 일반적으로 메시지 자체를 읽는 데

에는 디스크 탐색 4회와 정보 2MB 읽기가 필요할 것이다. 그러면 100ms이다. 총합은 160ms

인데, 이는 남아 있는 예산 147ms를 넘는 수치이다.

671.7 속도

수치들의 근거

색인을 읽는 데 디스크 탐색이 3회가 필요하다는 가정은 어디에서 온 것일까? 그런 수치는 기본

적으로 UNIX 파일 시스템의 내부 작동 방식, 즉 한 디렉터리의 파일들을 조회해서 i-노드를 찾

고 i-노드를 이용해서 자료 블록을 찾는 과정에 관한 지식에서 비롯된 것이다. 그래서 시스템이

사용하는 운영 체제의 내부를 이해하는 것이 분산 시스템의 설계와 운영에 꼭 필요하다. UNIX

운영 체제나 UNIX류 운영 체제의 내부는 잘 문서화되어 있으며, 이는 그런 운영 체제들이 다른

운영 체제보다 유리한 점 중 하나이다.

우리의 설계가 요구 사항들의 수치를 만족하지 못한다는 점은 안타깝지만, 대신 재앙을 피

했다는 점은 다행이다. 지금 미리 아는 것이 사고를 당하고야 알게 되는 것보다 낫다.

색인 조회에 60ms나 걸린다는 것은 다소 과한 것 같다. 이를 훨씬 더 개선할 수 있다. 색

인을 RAM에 담아 두면 어떨까? 그것이 가능할까? 잠깐 계산해 보면, 이 정도의 자료를 분산

저장하는 데 충분한 개수의 기계들에 질의를 산개하려면 참조 트리 조회 시 세 수준까지 들어

가야 함을 추정할 수 있다. 트리를 위아래로 훑으려면 패킷을 다섯 번 보내야 하며, 기계들이

모두 같은 데이터센터에 있다면 약 2.5ms가 소비된다. 이제 새로운 총합 150ms + 3ms +

2.5ms + 100ms = 255.5ms는 총예산 300ms보다 작다.

시간에 민감한 다른 요청들도 이런 과정을 통해서 예산을 추정한다. 예를 들어 이메일 메

시지를 전송하는 요청은 읽는 요청보다 드물게 일어나므로, 이메일 메시지 전송에 걸리는 시간

은 핵심적인 요인이 아니라고 간주할 수 있다. 반면 메시지 삭제는 메시지 읽기만큼이나 자주

일어난다. 몇 가지 삭제 방법들에 대해 앞에서와 같은 계산을 반복해서 효율성을 비교해볼 수

있다.

한 가지 삭제 방법은 서버와 접촉해서 저장 시스템과 색인으로부터 메시지를 삭제하는 것

이다. 또는, 저장 시스템이 그냥 메시지가 색인에서 삭제되었다고 표시만 해 두는 방법도 있다.

후자가 훨씬 더 빠르겠지만, 삭제 표시가 된 메시지들을 실제로 제거하고 가끔 색인을 압축(삭

제 표시가 된 색인 항목들을 제거)하는 새로운 구성요소가 필요해진다.

비동기 설계를 이용하면 반응 시간을 더욱 줄일 수 있다. 이 경우, 클라이언트의 요청을 받

은 서버는 요청이 완료될 때까지 기다리지 않고 즉시 제어권을 클라이언트에게 돌려준다. 실

제 작업이 느리게 진행된다고 해도, 사용자는 시스템이 더 빠르게 동작한다고 느끼게 된다. 그

러나 비동기 설계는 구현하기가 더 복잡하다. 한 가지 구현 방법은, 서버가 요청을 받아서 실제


로 작업을 수행하는 대신 요청을 대기열에 담아 두면, 배경에서 다른 프로세스가 그 대기열에

서 요청을 읽어서 실제로 작업을 진행하는 것이다. 또는 그냥 클라이언트가 요청을 보낸 후 나

중에 직접 응답이 왔는지 확인하게 하거나, 스레드 또는 하위 프로세스를 돌려서 응답을 기다

리게 할 수도 있다.

이러한 설계들 모두 사용 가능한 옵션이나, 속도 및 구현 복잡도가 각기 다르다. 속도와 비

용을 추정하고 원형을 만들어서 검증해 보면 이들 중 어떤 것을 구현할 것인지 결정할 수 있을

것이다.

1.8 요약

분산 컴퓨팅은 전통적인 컴퓨터와 여러모로 다르다. 특히 규모가 더 크다. 분산 컴퓨팅 시스템

은 각자 특화된 과제를 수행하는 수많은 컴퓨터로 이루어진다. 서비스들을 복제함으로써 수용

량을 증대할 수 있다. 분산 컴퓨팅에서는 하드웨어 고장을 비상사태나 예외로 간주하지 않고

시스템의 예상된 일부로 간주한다. 따라서 시스템은 장애를 피해서 작동한다.

대형 시스템은 더 작은 부분들을 조합해서 구축한다. 이번 장에서는 부하 분산기와 다수의

뒷단 복제본, 앞단과 다수의 서로 다른 뒷단, 그리고 서버 트리라는 흔히 쓰이는 조합 세 가지

를 이야기했다.

부하 분산기는 소통량을 복제된 여러 시스템들에 배분한다. 앞단과 다수의 서로 다른 뒷단

들의 조합은 서로 다른 뒷단들을 병렬로 활용하는데, 각 뒷단은 각자 다른 과정을 수행한다. 서

버 트리는 트리 구성을 사용하는데, 트리의 각 수준은 각자 다른 역할을 담당한다.

분산 시스템에서 상태는 끊임없이 갱신되는 정보로 이루어진 커다란 데이터베이스일 수도

있고, 시스템이 끊임없이 접근해야 하는 몇몇 핵심적인 비트들일 수도 있다. 어떤 경우이든, 분

산 시스템에서 상태를 관리하는 것은 복잡한 문제이다. CAP 원리에 따르면 일관성과 가용성,

분리 저항을 동시에 보장하는 분산 시스템을 구축하는 것은 불가능하다. 셋 중 많아야 두 개만

달성할 수 있다.

시스템은 시간이 흐름에 따라 진화해야 마땅하다. 그러한 진화가 쉽게 일어나게 하기 위해

구성요소들을 느슨하게 결합한다. 각 구성요소는 자신이 제공하는 서비스의 추상을 체현한다.

이때 추상을 변경하지 않고도 구성요소의 내부를 교체하거나 개선할 수 있도록 체현하는 것이

중요하다. 그러면 새로운 기능의 이점을 취하기 위해 서비스들 사이의 의존관계를 변경해야 하

691.8 요약

는 일이 없다.

분산 시스템을 설계하려면 여러 연산의 실행 시간을 파악해야 한다. 그래야 시간에 민감한

과정들을 해당 잠복지연 예산을 만족하는 방식으로 설계할 수 있다.

연습문제

1. 분산 컴퓨팅이란 무엇인가?

2. 분산 컴퓨팅의 세 가지 주요 조합 패턴을 서술하라.

3. 상태 저장과 관련해서 논의한 세 가지 패턴은 무엇인가?

4. 주 서버가 실제 응답이 아니라 응답을 찾을 수 있는 장소를 돌려주기도 한다. 그런 방법의

장점은 무엇인가?

5. § 1.4에서는 분산 파일 시스템을 설명하면서 수 테라바이트의 자료를 읽는 예를 소개했다.

수 테라바이트의 자료의 기록(쓰기)은 어떤 식으로 일어날까?

6. CAP 원리를 설명하라. (CAP 원리를 좀 더 알고 싶은 독자에게는 “The Part-Time

Parliament”(Lamport & Marzullo 1998 )와 “Paxos Made Simple”(Lamport 2001 )

을 추천한다.)

7. 시스템이 느슨하게 결합되었다는 것이 무슨 뜻인가? 그런 시스템의 장점은 무엇인가?

8. 독자가 경험한, 느슨하게 결합된 시스템의 예와 단단하게 결합된(tightly coupled ) 시

스템의 예를 제시하라. 그 시스템이 느슨하게/단단하게 결합되게 만든 요인은 무엇이었는

가?

9. 한 시스템이 이메일 메시지 조회 같은 요청을 처리하는 데 걸리는 시간을 어떻게 추정할 수

있는가?

10. §1.7에서 이메일 삭제 요청 처리를 위한 설계 세 가지를 제시했다. 세 설계에 대해 하나의

이메일 메시지 삭제 요청을 처리하는 데 걸리는 시간을 각각 추정하라. 우선 필요한 단계

들을 개괄하고, 각 단계를 개별 연산으로 취급해서 추정치를 산출하라.

1515.1 일반 전략

진짜 문제는 규모 변화뿐이다. 그 외의 모든 것은 하위 문제이다.

-오델O’Dell의 공리

시스템의 규모 변화(scaling ) 능력, 즉 규모가변성(scalability )이란 간단히 말해서 시스템이

점점 늘어나는 작업 부하(workload )를 감당할 수 있는 능력이다. 규모가변성은 흔히 초당 트

랜잭션 수나 자료량, 사용자 수로 측정한다. 그러나 시스템의 규모 변화에는 한계가 있으며, 그

한계를 넘어서 시스템을 성장하게 하려면 재설계가 필요하다.

분산 시스템은 성장(growth )이 당연시되므로, 처음부터 규모가변적으로 구축해야 한다.

웹 기반 서비스를 구축하든 일괄 처리식 자료 분석 플랫폼을 구축하든, 목표는 항상 성공적인

서비스를 만드는 것이며, 일반적으로 성공을 위해서는 더 많은 사용자와 활용도, 자료를 끌어

모을 수 있어야 한다.

서비스가 빠르게 작동하고, 규모가 변해도 그 속도를 계속 유지하는 것이 아주 중요하다.

서비스의 규모가 매끄럽게 커지지 않으면, 다시 말해서 사용자가 많아지면서 속도가 너무 느려

지면, 사용자들은 다른 곳으로 가기 마련이다. 구글의 한 실험에 따르면, 검색 결과에 인위적으

로 400ms의 지연을 추가하자 검색을 수행하는 사용자가 0.2~0.6% 정도 감소했다. 이는 수백

만 또는 수십억 달러의 수익 감소를 의미한다.

모순적이게도, 아예 죽은 웹 서비스보다 느린 웹 서비스가 더 짜증스럽다. 웹사이트가 죽

으면 사용자는 그 사실을 즉시 알아채고 경쟁 사이트로 가거나 사이트가 다시 살아날 때까지

다른 일을 한다. 그러나 웹사이트가 느리면 사용자는 그냥 괴롭고 짜증이 날 뿐이다.

규모 변화를 위한 설계 패턴

CHAPTER 05

152 5장 규모 변화를 위한 설계 패턴

규모가변적 시스템이 저절로 구축되지는 않는다. 분산 시스템에 규모가변성이 자동으로

생기는 일은 없다. 초기부터 서비스의 요구사항들을 만족할 수 있는 규모가변성을 염두에 두고

시스템을 설계해야 하며, 또한 이후의 성장을 위한 옵션들을 생성하는 기능들도 반드시 포함해

야 한다. 시스템을 실제로 가동한 후에도, 더 나은 규모가변성을 위해 시스템을 계속해서 최적

화해야 한다.

이전 장들에서는 분산 시스템을 극단적인 크기로 성장시킬 수 있는 여러 기법을 논의했다.

이번 장에서는 그 기법들을 훨씬 더 자세하게 살펴본다. 규모 변화에 관련된 용어들을 검토하

고, 규모 변화 기법들에 깔린 이론을 살펴보고, 규모 변화에 쓰이는 구체적인 기법들을 설명하

겠다. 시스템의 성능과 규모가변성을 서술하는 데 쓰이는 수학 용어들이 부록 C에 나오니 참고

하기 바란다.

5.1 일반 전략

규모가변적 시스템을 구축하는 기본적인 전략은, 처음부터 규모가변성을 염두에 두고 시스템

을 설계하는 것과 향후 추가적인 규모 변화에 방해가 되는 설계 요소들을 피하는 것이다.

초기 요구사항들에는 반드시 원하는 규모에 관한 근사치들을 포함해야 한다. 이를테면 저

장할 자료의 크기, 자료를 처리하는 시스템들의 처리량(throughput ), 서비스가 현재 받는 소

통량, 기대 성장 속도 등을 추정하고, 설계 과정에서 이 모든 요인을 지침으로 삼아야 한다. 이

러한 설계 과정을 §1.7에서 설명했다. 규모 변화 전략

시스템을 운영하다 보면 성능 한계들에 부딪힌다. 추가적인 규모 변화를 가능하게 하는 설

계 요소들이 그때부터 제 몫을 하게 된다.

잠재적인 규모 변화 문제점들을 최선을 다해 예측한다고 해도, 현실적으로 그 문제점들 모

두에 공학적 노력을 기울이지는 못한다. 향후의 잠재적 규모 변화 문제점을 해결하기 위한 추

가적인 설계 및 코딩 노력보다는 오늘 발견한 문제점을 바로잡기 위한 코드 작성이 더 시급하

다. 발생할지 아닐지 알 수 없는 미래의 규모 변화 문제를 방지하기 위해 너무 많은 시간을 소

비하는 것은 소위 섣부른 최적화(premature optimization )에 해당하며, 이는 반드시 피해야

한다.

1535.1 일반 전략

5.1.1 병목 식별

병목(bottleneck )은 시스템에서 혼잡(congestion; 또는 밀집)이 발생하는 지점을 말한다.

자원이 고갈되어서 시스템 성능이 제한되는 지점이 바로 병목이다. 모든 시스템에는 병목이 있

다. 시스템의 성능이 기대 이하일 때 병목을 찾아서 고치면 시스템 성능이 높아질 수 있다. 시

스템이 잘 작동하는 경우에도 병목의 위치를 아는 것은 유용하다. 그러면 향후의 문제점을 예

측하고 방지할 수 있기 때문이다. 성능상의 문제점이 발생할 때까지 인위적으로 부하를 높여

보면(이를테면 검사용 환경에서) 병목을 발견할 수 있다.

규모 변화를 적용할 지점을 결정하는 것은 시스템의 병목을 찾아서 제거하는 문제에 해당

한다. 병목은 아직 처리하지 못한 작업들이 누적되는 지점이다. 병목 지점으로 올라가는 공정

을 최적화하면 누적 속도가 빨라질 뿐이다. 병목 지점에서 올라가는 공정을 최적화하면 그 부

분의 효율성은 증가할 수 있겠지만, 시스템 전체의 처리량은 개선되지 않는다. 따라서 병목 자

체에 초점을 두지 않은 모든 노력은 낭비일 뿐이다.

5.1.2 구성요소들의 재공학

현재 시스템을 조정 또는 조율하는 것으로 해결되는 규모 변화 문제점들도 있다. 예를 들어 캐

시의 크기는 그냥 구성 파일 하나만 조정하면 키울 수 있다. 그러나 그 외의 규모 변화 문제점

들에는 공학적 노력이 필요하다.

시스템의 한 부분을 다시 작성하는 것을 가리켜 재공학(reengineering )*이라고 부른다.

현재의 코드 구조(code structure )나 설계 구조의 원인이 된 이전의 설계상의 결정들 때문에

재공학을 적용하기가 어려운 경우도 있다. 그런 경우 해당 코드를 기능은 같되 재공학을 좀 더

수월하게 적용할 수 있는 내부 구조를 가진 다른 코드로 대체하는 것이 최선일 때가 많다. 기존

코드의 구조를 바꾸는 것, 즉 외부 행동은 그대로 유지하고 내부 구조를 변경하는 것을 가리켜

리팩터링(refactoring )이라고 부른다.

* 옮긴이_ ‘재설계’라는 용어도 있지만, reengineering이 설계에만 국한되는 것은 아니며 무엇보다도 redesign과 구분할 수 없으므로

부적합하다. 재공학은 reverse engineering을 ‘역공학’이라고 부르는 데에서 착안한 용어로, 최고의 선택은 아니겠지만 차악은 될 것

이다.


5.1.3 결과의 측정

규모 변화 해법들은 반드시 증거를 이용해서 평가해야 한다. 여기서 증거란 실제 시스템에서

수집한 자료를 말한다. 주요 수치들을 측정하고, 해법을 적용해 보고, 같은 수치들을 다시 측

정해 보면 그 해법의 효과를 알 수 있다. 효과가 크지 않거나 부정적인 해법은 채용하지 말아야

한다.

예를 들어 성능이 느린 시스템을 조사해 보니 캐시 적중률이 아주 낮게 측정되었다고 하

자. 그렇다면 캐시가 너무 작은 것이 문제일 수 있다. 이 경우 먼저 성능을 측정하고, 캐시 크기

를 변경하고, 다시 성능을 측정해 본다. 캐시 크기를 조정한 후 캐시 적중률이 개선되어도 시스

템 전체의 성능이 크게 나아지지는 않을 수 있거나, 추가로 필요한 RAM의 비용을 정당화할 만

큼 성능 개선이 크지는 않을 수 있다.

변경 이전과 이후에 성능을 측정하지 않으면 그 변경이 실제로 효과적인지 판단할 수 없

다. 측정 없는 변경은 최선의 경우라도 운에 의존하는 시스템 관리로 이어지며, 최악의 경우에

는 ‘아집’에 의한 시스템 관리로 귀결된다. 성급히 해결책을 적용하고 그 후에야 시스템을 측정

하는 우를 범하는 경우가 많은데, 비교의 기준이 없다는 점에서 이는 측정을 아예 하지 않는 것

과 마찬가지로 나쁜 일이다.

과거의 경험이 좋은 정보이자 지침이긴 하지만, 측정과 분석에 의거해서 의사결정을 진행

하는 과학적 공정을 건너뛰고 경험에만 의존하려는 유혹을 떨쳐버려야 한다. 어떤 분산 시스템

이든, 무엇을 하는 것이 좋은지를 임의의 한 사람이 “그냥 알 수 있는” 수준보다 훨씬 크다. 경

험 많은 시스템 관리자의 육감이나 추측보다는 과학적 분석에 시간을 들인 신참의 권고를 우선

시해야 한다. 즉, 자료 수집 메커니즘을 마련하고, 측정을 수행하고, 무엇인 문제인지에 관한

가설을 검증하고, 그것을 바로잡을 수 있는 이론을 시험해 보고, 그 결과를 분석하는 것이 더

중요하다.

5.1.4 능동적 대처

병목은 실제로 문제를 일으키기 전에 바로잡는 것이 최선이다. 이상적으로는, 병목이 문제를

일으키기 직전에 코드를 수정하는 것이 가장 좋다. 문제를 너무 빨리 바로잡는다면, 절대 나타

나지 않을 문제점에 노력(다른 어딘가에 투여했다면 좋았을)을 낭비하는 것일 수 있다. 해결

책의 설계와 구현을 늦게 시작한다면, 해결책을 적용하기 전에 문제가 발생할 것이다. 너무 오

1555.2 규모 확장

래 기다리면 운영팀이 아직 대비가 되지 않은 상태에서 문제점이 돌발할 것이며, 그러면 임시

방편으로 미봉책을 적용할 위험이 있다. 공학적 노력에는 시간이 걸리며, 성급히 진행하면 실

수가 벌어져서 더 많은 문제점이 발생하게 된다. 따라서 너무 일찍도 아니고 너무 늦지도 않은

‘적시’를 찾을 필요가 있다.

모든 시스템에는 병목 또는 제약이 있다. 그 자체는 나쁜 일이 아니다. 제약(constraint )

은 모든 시스템에 필연적으로 존재하는 요인이다. 제약은 가능한 처리 속도나 공정을 통해서

흐를 수 있는 작업량을 규정한다. 현재의 속도가 충분하다면 병목은 문제점이 되지 않는다. 다

른 말로 하면, 제약은 시스템이 목표를 달성하는 능력에 실제로 해가 될 때에만 문제점이다.

실행 중인 시스템의 규모 변화에 가장 좋은 전략은 문제점들을 예측하되, 적절한 해결책을

위해 충분한 시간을 확보할 수 있을 정도로 최대한 일찍 예측하는 것이다. 이를 위해서는 병목

들의 존재를 짐작할 수 있을 정도로 충분한 측정치들을 항상 수집해야 한다. 그리고 측정치들

을 세심하게 분석하면 병목이 언제 문제점이 될지 예측할 수 있어야 한다. 예를 들어 인터넷 대

역폭 소비량을 측정해서 그래프로 그려 보면 인터넷 연결의 용량이 소진될 시점을 어렵지 않게

예측할 수 있다. 대역폭을 더 주문하는 데 6주가 걸린다면, 용량 소진 시점을 적어도 6주 일찍

예측해서 미리 주문해야 할 것이다. 12주 일찍 주문한다면 더 좋다. 그러면 용량 증가 시도가

실패해도 한 번 더 시도할 여유가 있다.

그냥 구성 설정을 변경하는 것으로 즉시 구현할 수 있는 해결책들도 있지만, 몇 주 또는 몇

개월에 걸쳐 주요 시스템을 다시 작성하거나 교체하는 등의 좀 더 복잡한 공학적 노력이 필요

한 해결책들도 있다.

5.2 규모 확장

가장 간단한 시스템 규모 변화 방법은 더 크고 빠른 장비를 사용하는 것이다. 시스템이 너무 느

리게 실행된다면, 더 빠른 CPU 또는 더 많은 CPU와 더 많은 RAM, 더 빠른 디스크, 더 빠른

네트워크 인터페이스 등을 가진 컴퓨터로 시스템을 옮기면 된다. 컴퓨터 전체를 교체하는 대신

기존 컴퓨터의 CPU나 RAM, 디스크 등을 교체 또는 증설할 수도 있다. 시스템의 크기가 커진

다는 점에서, 이런 방식의 규모 변화를 규모 확장(scaling up; 또는 규모 증가)라고 부른다.

잘 작동하기만 한다면 이것이 가장 쉬운 해법이다. 소프트웨어 재설계가 필요하지 않기 때

문이다. 그러나 이런 방식의 규모 변경에는 여러 가지 문제점이 있다.


첫째로, 시스템 크기 증가에는 한계가 있다. 마련할 수 있는 가장 빠르고 가장 크고 가장

강력한 컴퓨터라도 주어진 과제를 감당하기에는 부족할 수 있다. 그 어떤 컴퓨터이든, 한 대의

컴퓨터로는 웹 검색 엔진의 말뭉치 전체를 저장할 수 없거나, CPU 능력이 페타바이트 규모의

자료집합을 처리할 정도가 되지 않거나, 초당 수백만 건의 HTTP 요청에 응답할 수는 없을 수

있다. 현재 시장에 나와 있는 컴퓨터의 능력에는 엄연히 한계가 존재한다.

둘째로, 이 접근방식은 경제적이지 못하다. 두 배 빠른 컴퓨터의 비용은 두 배를 넘는다.

그런 컴퓨터는 그리 많이 팔리지 않으므로 대량생산되지 않는다. 최신 CPU나 디스크 드라이

브, 기타 부품 역시 가격에 프리미엄이 붙는다.

마지막으로, 가장 중요한 것은 규모 확장이 통하지 않는 상황들이 있다는 것이다. 일반적

으로, 더 빠르고 강력한 기계를 산다고 해도 소프트웨어 설계를 변경하지 않으면 추가 비용 대

비 처리량 증가가 별로 좋지 않다. 단일 스레드로 실행되는 소프트웨어는 프로세서가 여럿인

컴퓨터에서 실행한다고 해도 더 빨라지지 않는다. 작업을 모든 프로세서에 분산시키도록 작성

된 소프트웨어라고 해도 일정 개수 이상의 CPU들에서는 자물쇠 경합(lock contention ) 같

은 병목 때문에 성능이 그리 향상되지 않을 수 있다.

마찬가지로, 임의의 한 구성요소의 성능을 향상한다고 해도 시스템 전체의 성능이 반드시

향상되는 것은 아니다. 예를 들어 네트워크 속도가 빨라진다고 해도, 잠복지연이 높을 때 프로

토콜이 잘 작동하지 않는다면 전반적인 처리량은 개선되지 않는다.

부록 B는 이런 문제점들을 좀 더 자세히 살펴보고, 이 문제점들이 분산 컴퓨팅의 발명으로

이어진 역사도 이야기한다.

5.3 AKF 규모 변화 입방체

시스템 전반의 규모 변경을 위한 방법론들은 크게 세 가지로 나뉘는데, 하나는 시스템 전체를

복제하는 것(수평적 중복)이고 또 하나는 시스템을 개별 기능, 서비스, 자원들로 나누는 것(기

능적 분할 또는 서비스 분할), 나머지 하나는 시스템을 개별 조각들로 분할하는 것(조회 분할

또는 공식 분할)이다.

[그림 5.1 ]은 이 세 범주를 각각 x, y, z축으로 도식화한 입방체이다. 창안자인 애봇Abbott

과 키븐Keeven, 피셔Fisher의 이름을 따서, 이 도식을 AKF 규모 변화 입방체(scaling cube )라고

부른다(Abbott & Fisher 2009 ).

1575.3 AKF 규모 변화 입방체

거의 무한대에 가까운 규모

큰 나머지 또는 해시

Z축 —

조회

또는

공식

적 분

할

분할 없음

복제본들을 읽고단일한 노드에 기록

X축 — 수평 중복

하나의, 전일적인 자료구조

서비스 또는 자료 친화도에

의한 분할

분할 없음

시작점

Y축

— 기

능이

나 서

비스

,

자원

에 의

한 분

할

그림 5.1 AKF 규모 변화 입방체. AKF Partners 등록상표.

허락하에 Scalability Rules: 50 Principles for Scaling Web Sites에서 재인용.

5.3.1 x축: 수평 중복

수평 중복(horizontal duplication )은 서비스를 복제함으로써 처리량을 늘린다. 이를 수평

규모 변화(horizontal scaling )나 스케일링 아웃scaling out이라고 부르기도 한다.

이런 종류의 복제는 이전 장들에서 논의했다. 예를 들어 하나의 부하 분산기 뒤에 한 웹 서

버의 여러 복제본을 두는 기법이 수평 규모 변화의 예이다.

여러 구성요소가 공유하는 자원들의 집합을 자원 풀(resource pool )이라고 부른다.

자원을 풀에 추가할 때에는 각 복제본이 같은 트랜잭션을 처리했을 때 동일한 또는 동등한

(equivalent ) 결과를 낼 수 있어야 한다.

자료가 증가하거나 특별한 처리가 필요한 복잡한 트랜잭션들이 증가할 때에는 x축의 규모

가 그리 잘 변화되지 않는다. 각 트랜잭션을 모든 복제본에서 독립적으로 완수할 수 있다면, 성

능 향상은 복제본 개수에 비례한다. 이 경우 규모 변화에 따른 효율성 감소는 전혀 없다.


연습문제

1. 규모 변화란 무엇인가?

2. CPU가 제한 요인인 서비스의 규모를 변화하는 방법으로는 어떤 것들이 있는가?

3. 저장 요구량이 증가하는 서비스의 규모를 변화하는 방법으로는 어떤 것들이 있는가?

4. 하드웨어 가격이 매년 내려가므로, [그림 1.10 ]에 나온 수치들은 이미 구식이 되었다. 최

근 몇 년에 맞게 그 도표를 갱신하라. 조금 변한 항목들은 무엇이고 크게 변한 항목들은 무

엇인가?

5. [그림 1.10 ]의 수치들을 상대적인 비율로 환산해 보라. 예를 들어 주 메모리를 읽는 데 1초

걸린다면, 다른 연산들은 얼마나 걸릴까? 추가 점수를 따고 싶은 독자라면, 그 답들을 달력

이나 태양계 비슷한 형태로 도식화하라.

6. [그림 1.10 ]의 표에 각 항목의 비용을 나타내는 열(column )을 추가하라. 그 비용들을 단

위가 같아지도록 비례시켜야 한다. 이를테면 RAM 1테라바이트의 비용, 디스크 1테라바이

트의 비용, L1 캐시 1테라바이트의 비용 등을 사용할 것. 그리고 비용 대비 성능을 보여주

는 열도 추가하라.

7. 서로 다른 규모 변화 기법들을 서술하는 이론적 모형(이번 장에서 언급한)은 무엇인가?

8. 규모 변화가 필요한 시점이 되었음을 어떻게 알 수 있을까?

9. 실무에서 흔히 쓰이는 규모 변화 기법들은 무엇이고 어떻게 작동하는가? 각각 어떨 때 사

용하는 것이 가장 적합한가?

10. 규모 변화 기법 중 탄력성도 향상하는 것들은 무엇인가?

11. 독자의 환경이 CDN을 활용하는 방식을 서술하라. CDN을 사용하지 않는다면, 어떤 식으

로 사용하면 좋을지 연구하라.

12. 암달의 법칙(Amdahl’s law )을 조사하고, 그것이 AKF 규모 변화 입방체와 어떻게 관련

되는지 설명하라.

1796.1 하드웨어 탄력성보다 중요한 소프트웨어 탄력성

성공은 끝이 아니고 실패는 파멸이 아니다.

중요한 것은 계속하고자 하는 용기이다.

-윈스턴 처칠Winston Churchill

탄력성(resiliency; 회복력)은 시스템이 장애를 건설적으로 처리하는 능력이다. 탄력적인(탄

력성이 있는) 시스템은 장애를 검출해서 피해간다. 비탄력적(탄력성이 없는) 시스템은 오작동

발생 시 쓰러지고 만다. 소프트웨어 기반 탄력성에 관한 이번 장에서는 탄력성을 갖추는 데 흔

히 쓰이는 기법들을 소개한다.

탄력성이 중요한 이유는 아주 간단하다. 다운된 웹사이트에는 아무도 가지 않기 때문이다.

하드웨어 고장은 일상다반사日常茶飯事이다. 세상에서 가장 믿음직하고 비싼 하드웨어를 산다고

해도 어느 정도의 고장은 발생한다. 충분히 큰 시스템에서는 발생 확률이 백만분의 1인 장애가

‘매일’ 발생한다.

전형적인 구글 데이터센터의 경우, 첫해에는 랙 전체의 가동 중단이 5회 정도 일어나고 라

우터에 연결된 기계들의 처리가 멈출 정도로 큰 라우터 고장이 3회 정도 일어난다. 예정된 유

지보수 작업에 의한 네트워크 가동 중단은 8회인데, 그중 절반에서는 30분간 연결들이 무작위

로 끊어진다. 그 동안 모든 디스크의 1~5%가 죽고 각 기계가 적어도 두 번 충돌한다(고장률이

2~4%) (Dean 2009 ).

제2장에서 설명했듯이, 우아한 강등(graceful degradation )이란 장애 상황이나 고부하

상황에서 기능성을 줄임으로써 소프트웨어가 그런 상황을 극복하도록 설계하는 것을 말한다.

탄력성을 위한 설계 패턴

CHAPTER 06

180 6장 탄력성을 위한 설계 패턴


중단(outage ): 서비스가 제공되지 않음을 사용자가 알아챌 수 있을 정도로 서비스에 문제가 있

는 상황.

장애(failure ): 시스템이나 하위 시스템 또는 구성요소가 작동을 멈추는 것.

오작동(malfunction ): ‘장애’와 같은 뜻으로 쓰인다.

서버(server ): 어떠한 기능(function )이나 응용 프로그래밍 인터페이스(API )를 제공하는 소

프트웨어. (서버 하드웨어를 말하는 것이 아님.)


기계(machine ): 가상 또는 물리적 기계.

QPS: queries per second, 즉 초당 질의 수의 약자. 흔히 초 당 웹페이지 방문 횟수나 API

호출 횟수를 뜻한다.

예를 들어 동영상 스트리밍 서비스라면 인터넷 연결들 일부가 다운되었거나 기타 이유로 과부

하가 걸렸을 때 자동으로 동영상 해상도를 낮춤으로써 대역폭을 절약한다. 심층 방어(defense

in depth )라는 전략도 있는데, 이는 설계의 모든 계층에서 장애를 검출하고 그에 대응하게 하

는 것을 뜻한다. 여기서 말하는 장애에는 한 프로세스의 오작동 같은 작은 장애와 데이터센터

전체의 장애 같은 큰 장애가 모두 포함된다.

탄력성을 보장하는 오래된, 그리고 좀 더 전통적인 전략은 장애가 발생할 수 있는 모든 지

점에서 장애 발생 가능성을 줄이는 것이다. 이를테면 최상의 서버들과 최상의 네트워크 장비를

사서 신뢰성이 가장 큰 데이터센터에 넣는다. 이 전략을 사용해도 가동 중단은 여전히 발생하

겠지만, 빈도가 아주 낮아진다. 이 전략은 비용이 가장 큰 전략이다. 또 다른 전략은 의존 관계

를 분석해서 각 시스템이 고품질 부품에 의존하는지 확인하는 것이다. 공급업체들은 제품의 구

성요소의 신뢰성을 계산해서 MTBF (mean time between failure; 평균 무고장 시간) 등급

을 발표한다. 시스템 안의 의존 관계들을 분석해보면 시스템 전체의 MTBF를 예측할 수 있다.

시스템의 MTBF는 MTBF가 가장 낮은 구성요소의 MTBF를 넘지 못한다.

그런 전략은 예측적(predictive )이다. 즉, 시스템의 장애 가능성 또는 신뢰성을 예측할 수

있다.

탄력성이 있는 시스템은 예측적 전략의 한계를 넘어선 지점에서도 가동을 계속한다. 탄력


적인 시스템을 구축할 때에는 장애가 반드시 발생한다는 가정하에서 장애 발생 시 지능적으로

반응함으로써 시스템 전체가 살아남아서 서비스를 계속 제공할 수 있도록 시스템을 설계, 구현

한다. 탄력적 시스템은 더 나은 하드웨어를 갖추어서 장애를 피하거나 장애에 인간의 노력(그

리고 사과)으로 대응하는 수동적인 자세가 아니라 장애를 예상하고 살아남을 수 있는 메커니

즘을 미리 마련하는 능동적인 자세를 취한다.

탄력적 시스템은 구성요소의 장애를 사용자에게 드러나는 서비스 중단과 분리한다. 전통

적인 컴퓨팅에서는 한 구성요소가 실패하면 사용자에게 드러날 정도의 서비스 중단 상황이 벌

어진다. 생존 가능 시스템(survivable system; 또는 지속 가능 시스템)을 구축할 때에는 장애

라는 개념과 중단이라는 개념을 분리한다.

이번 장은 장애를 검출해서 우회하는 시스템을 설계하는 다양한 방법을 논의한다. 그 방법

들은 곧 생존 가능 시스템을 구축하는 방법이다. 이번 장은 그런 기법들을 물리적 고장, 공격,

인간의 실수, 예기치 못한 부하라는 네 가지 범주로 나누어서 소개한다.


신뢰성 있는 시스템을 구축할 때 더 나은 하드웨어를 갖추는 데 주력할 수도 있고 더 나은 소프

트웨어를 갖추는 데 주력할 수도 있다. 더 나은 하드웨어를 갖춘다는 것은 특수 용도의 CPU나

부품, 저장 시스템 등을 마련하는 것을 말한다. 더 나은 소프트웨어를 갖춘다는 것은 장애를 검

출해서 우회할 정도의 지능을 시스템에 추가하는 것을 뜻한다.

여러 가지 이유로, 둘 중 소프트웨어적인 해결책이 더 낫다. 가장 중요한 이유는 소프트웨

어가 더 경제적이라는 것이다. 소프트웨어는 한 번만 작성하면 추가 비용 없이 여러 서비스와

여러 기계에 적용할 수 있다(직접 작성했거나 오픈소스라서 기계별 사용권을 구매할 필요가

없다고 할 때). 또한, 소프트웨어는 말 그대로 하드웨어보다 부드럽다. 즉, 고치거나, 업그레이

드하거나, 교체하기가 더 쉽다. 하드웨어 업그레이드와는 달리 소프트웨어 업그레이드는 자동

화할 수 있다. 결과적으로 소프트웨어는 자주 교체된다. 새 기능이 더 빨리, 그리고 더 자주 시

스템에 도입된다. 실험하기도 쉽다. 소프트웨어는 시간이 지날수록 더 강해진다. 버그가 교정

되고, 드문 극단적 경우(edge case )들이 더 잘 처리된다. 스폴스키Spolsky의 에세이 “Things

You Should Never Do”(Spolsky 2004 )에 여러 예가 나온다.

반면 더 나은 하드웨어를 갖추려면 더 큰 비용이 든다. 초기 구매 가격이 소프트웨어보다


높다. 신뢰성 높은 CPU와 부품, 저장 시스템들은 흔히 쓰이는 일반적인 부품들보다 훨씬 비싸

다. 하드웨어에 주력하는 전략에 비용이 많이 드는 또 다른 이유는 시스템 규모를 키우기 위해

기계를 추가할 때마다 비용을 치러야 한다는 점이다. 하드웨어 업그레이드에는 기계 자체의 비

용뿐만 아니라 설치 인건비, 자본 감가상각, 기존 부품 폐기 비용 같은 추가 비용도 필요하다.

소프트웨어 설계보다 하드웨어 설계에 더 많은 시간이 걸리므로, 하드웨어 업그레이드는 상대

적으로 덜 일어나며, 새로운 시도를 실험하기가 더 어렵다. 하드웨어는 오래될수록 약해지고

고장이 잦아진다.

6.2 모든 것은 결국에는 고장난다

그 어떤 환경이든, 고장과 오작동은 필연적이다. 오작동은 모든 수준에서 발생할 수 있다. 예

를 들어 하드웨어 구성요소 수준(칩과 기타 전자 부품)에서 발생하기도 하고, 장치 수준(하드

드라이브, 메인보드, 네트워크 인터페이스 등)에서 발생하거나 시스템 수준(컴퓨터, 네트워크

장비, 전원 시스템 등)에서 발생하기도 한다. 또한, 오작동은 다양한 규모의 영역에서 발생한

다. 작게는 특정 랙 하나에 전원이 제대로 공급되지 않을 수 있으며, 좀 더 크게는 데이터센터

전체가 외부와 연결이 끊어질 수 있고, 심지어 도시나 지역 전체에 재해가 발생할 수도 있다.

사람 역시 오작동과 고장의 한 원인이다. 단순한 오타에서 심각한 소프트웨어 버그에 이르기까

지, 그리고 실수로 전원선을 발로 차서 플러그가 빠지는 사고에서 고의로 악의적인 공격을 수

행하는 것에 이르기까지 다양한 요인이 존재한다.

6.2.1 분산 시스템의 MTBF

큰 시스템에서는 작은 문제가 확대된다. 대형 시스템에서는 발생 확률이 백만분의 1인 장애가

자주 발생한다. MTBF가 1백만 시간인 하드 드라이브가 1년 동안 고장날 확률은 114분의 1이

다. 그런 하드 디스크가 10만 개이면, 하루 평균 두 개의 하드 드라이브가 고장날 수 있다.

1억 분의 1의 확률로 발동되는 CPU의 버그 때문에 집에서 사용하는 PC가 1년에 한 번 정

도는 충돌할 수 있다. 그런 경우 사용자는 투덜대면서 PC를 다시 부팅할 뿐, 그런 일이 다시 생

기리라고는 생각하지 않을 것이다. 발생 확률이 그 정도로 낮은 버그는 칩 제조사가 미리 검출

하지 못할 수 있다. 그러나 분산 컴퓨팅 시스템에서는 충돌 검출 및 분산 시스템에서 하나의 패

1836.2 모든 것은 결국에는 고장난다

턴으로 인식할 정도로 버그가 자주 발현될 수 있다. 그런 버그를 보고하면 칩 제조사는 아마

그런 버그가 존재한다는 점에 당황하고, 그런 버그를 누군가가 발견했다는 점에 놀라고, 핵심

CPU 설계가 여러 세대의 칩들을 거치는 동안 그 버그를 잡아내지 못했다는 점을 창피해 할 것

이다. 또한, 칩 제조사는 시스템 관리에 관한 책에서 그런 문제를 상세하게 문서화할 권한을 저

자에게 부여하지는 않을 가능성이 크다.

장애들은 모이기 마련이다. 그러다 보면 마치 기계들이 단결해서 사람에게 반항하는 것처

럼 보이기도 한다. 정전이 지나가면 여러 랙의 컴퓨터들이 동시에 재시동하며, 그러면 수십 개

의 디스크를 모두 돌리기에는 전력이 모자라는 상황이 벌어진다. 오래된 납땜 접점이 수축되고

갈라지면서 원인을 알 수 없는 고장이 발생한다. 같은 공장에서 같은 시기에 만들어진 구성요

소들은 수명이 비슷하기 때문에, 갑자기 여러 대의 기계가 동시에 고장나는 일도 발생한다.

이러한 다양한 잠재적 오작동과 장애들에 관한 논의에 겁을 먹고 시스템 관리 분야를 떠나

려는 독자가 없길 바랄 뿐이다!

6.2.2 전통적인 접근방식

전통적인 소프트웨어는 완벽하고 오작동 없는 세계를 가정한다. 그러한 가정하에서 하드웨어

시스템 기술자에게는 절대 실패하지 않는(고장나지 않는) 하드웨어를 공급하라는 불가능한

임무가 주어진다. 그래서 하드웨어가 절대 실패하지 않는 환경을 흉내내는 기술들이 탄생했다.

소프트웨어가 보기에 디스크가 결코 실패하지 않는 것처럼 가장하기 위한 RAID (redundant

array of inexpensive [independent ] disks; 저렴한 또는 독립적인 디스크들의 중복된 배

열) 시스템이 그러한 예이다. 이런 기술을 이용해서 고장으로 가득한 실제 세계의 현실과 격리

한 덕분에, 소프트웨어 개발자는 계속해서 완벽하고 오작동 없는 세계(물론 실재하지 않는)를

가정하고 소프트웨어를 작성할 수 있다.

예를 들어 UNIX 응용 프로그램을 작성할 때에는 파일 읽기와 쓰기가 오류 없이 진행된다

고 가정한다. 그래서 응용 프로그램에서 파일 쓰기 오류를 굳이 점검하지 않는다. 오류를 점

검한다면 오히려 시간 낭비가 될 수 있다. 왜냐하면 자료 블록이 디스크에 바로 기록되는 것

이 아니라 나중에, 심지어는 응용 프로그램이 종료된 후에야 기록될 수도 있기 때문이다. 한편,

Microsoft Word는 자신이 실행되는 컴퓨터가 계속해서 실행될 것이라는 가정하에서 작성되

었다.


과장법 주의

앞의 문단에는 과장된 부분이 두 군데 있다. UNIX의 응용 프로그램 계층은 파일 시스템이 완벽

하다고 가정하지만, 그 바탕 계층들은 디스크가 완벽하다고 가정하지 않는다. Microsoft Word

는 충돌 시에도 사용자의 자료가 소실되지 않도록 일정 주기로 문서를 저장한다. 그러나 충돌 도

중에는 사용자가 문서를 수정할 수 없다.

회사들은 오작동 없는 세계라는 달성 불가능한 가정을 위해 많은 돈을 낭비한다. 신뢰성이

높다고 알려진 CPU나 부품, 저장 시스템은 일반적인 부품보다 훨씬 비싸다. 부록 B에서 이러

한 전통적인 전략의 역사와 이번 장에서 논의하는 분산 컴퓨팅 기법들의 경제적 이득을 상세히

설명한다.

6.2.3 분산 컴퓨팅 접근방식

전통적인 접근방식과는 달리 분산 컴퓨팅은 구성요소들의 장애와 오작동을 포용한다. 분산

컴퓨팅은 오작동이 일어나기 마련이라는 현실적인 접근방식을 취한다. 구글 문서(Google

Docs ) 사용자는 구글에 있는 한 컴퓨터가 고장나도 계속해서 문서를 편집할 수 있게 한다.

그런 경우 다른 컴퓨터가 그 자리를 대신하며, 사용자는 그런 교체가 일어났음을 눈치채지 못

한다.

전통적인 컴퓨팅은 하드웨어를 이용해서 신뢰성을 높이는 데 많은 노력을 들이다가 한계

에 부딪히면 적은 수의 장애들을 ‘정상’으로 받아들이거나 장애를 검출하고 우회하는 지능을 소

프트웨어에 추가한다. 애초에 소프트웨어로 장애를 우회할 수 있다면, 비싼 하드웨어에 돈을

들이는 것은 낭비일 뿐이다.

유명한 범퍼 스티커로 “Eat right. Exercise. Die anyway (잘 먹고 운동하라. 어차피 죽

는다)”라는 것이 있다. 아무리 비싼 하드웨어도 고장나기 마련이라면 애초에 최고의 제품을 구

매할 필요가 없다. 신뢰성을 위한 비용을 이중으로 치를 필요가 있겠는가?

1856.3 예비 수용량을 이용한 탄력성 확보

고장난 메모리나 금반지 삽니다

초창기 구글은 신뢰성 없는 하드웨어를 지능적인 소프트웨어를 이용해서 어느 정도까지나 감당할

수 있는지 시험해 보았다. 이를 위해 구글은 고장난 RAM 칩을 구매해서 활용할 방법을 찾아냈다.

구글은 장애에 대한 탄력성이 높은 소프트웨어들을 실행하는 기계들을 위해 수 테라바이트의

RAM을 구매했다. 한 칩이 고장나면 OS는 주 메모리의 해당 영역을 사용 불가능으로 표시해 둔

후 그 영역을 사용하는 모든 프로세스를 죽였다. 죽은 프로세스는 자동으로 재시작한다. 그 칩이

불량이라는 사실을 기록해 두기 때문에, 이후 OS가 재시동되어도 OS는 그 칩을 사용하지 말아

야 한다는 점을 알게 된다.

이런 방식에서는 칩 하나가 고장난다고 해서 컴퓨터 전체를 수리할 필요가 없다. 메모리 용량

이 가용 한계 이하로 떨어지기 전까지는 컴퓨터를 계속 실행해도 된다.

이런 방법을 도입한 후 구글에 생긴 일을 이해하려면, 고품질 RAM 칩과 보통 품질 RAM 칩의

차이는 검사 통과율뿐임을 알아야 한다. 제조사는 RAM 칩을 만든 후 검사한다. 가장 엄격한 QA

검사를 통과한 칩들은 ‘고품질’ 칩이라는 딱지를 달고 높은 가격으로 판매된다. 표준 QA 검사를

통과한 칩은 보통의 가격으로 판매된다. 표준 QA 검사조차 통과하지 못한 칩들은 폐기된다.

구글의 구매 부서 직원들은 만만찮은 협상가들이다. 이미 구글은 보통 품질 칩들을 구매하고

오작동 문제는 장애를 우회하기 위해 구글이 직접 작성한 소프트웨어를 통해 해결함으로써 많은

돈을 절약한 바 있다. 어느 날 구매 부서는 만일 폐기되는 칩들을 살 수 있으면 어떨까라는 생각

을 하게 되었다. 전에는 그런 요청을 받아본 적이 없는 칩 제조사들은 그런 칩들을 기꺼이 아주

싸게 넘겨주었다.

‘고장난’ RAM 칩들은 구글의 요구를 완벽하게 만족시켰다. 처음부터 작동하지 않은 것들도

있고 얼마 안가 고장나는 것들도 있었지만, 그래도 서비스를 계속해서 돌릴 수 있었다.

결국에는 이런 관행을 끝내긴 했지만, 수년 간 구글은 엄청난 용량의 RAM을 갖춘 서버들을

다른 경쟁사들보다 적은 비용으로 구축할 수 있다. 광고 단가가 몇 센트 수준인 사업에서 수 달

러를 절약한다는 것은 커다란 이득이다!

6.3 예비 수용량을 이용한 탄력성 확보

탄력성을 확보하는 데 쓰이는 일반적인 전략은 각자 독립적으로 실패할 수 있는 수용량 단위들

을 중복해서 마련하는 것이다. 그런 단위들 중 실패하는 것이 있으면 서비스에서 제거한다. 시

스템의 총 수용량은 줄어들겠지만, 그래도 시스템은 여전히 실행될 수 있다. 이런 전략을 위해

2117.1 분산 시스템의 운영

운영: 시스템 실행하기

Part

II


CHAPTER 7 분산 세계에서의 운영

CHAPTER 8 개발운영 문화

CHAPTER 9 서비스 인도: 구축 국면

CHAPTER 10 서비스 인도: 배치 국면

CHAPTER 11 활성 서비스의 업그레이드

CHAPTER 12 자동화

CHAPTER 13 설계 문서

CHAPTER 14 호출대기

CHAPTER 15 재난 대비

CHAPTER 16 감시의 기초

CHAPTER 17 감시 시스템의 구조와 관행

CHAPTER 18 수용량 계획 수립

CHAPTER 19 KPI 작성

CHAPTER 20 탁월한 운영

맺음말

Part II

운영: 시스템 실행하기


경쟁력을 지속적으로 제공하는 근원이

조직의 학습 속도뿐인 시대가 조만간 올 것이다.

-피터 센지Peter Senge

이 책의 제1부에서는 분산 시스템을 구축하는 방법을 논의했다. 제2부에서는 분산 시스템을

실행하는 방법을 논의한다.

시스템을 계속 실행하는 데 필요한 최소한의 작업을 운영(operation )이라고 부른다. 좀

더 구체적으로, 운영은 서비스 수준 협약서(service level agreement, SLA )에 지정된 운영

상의 수치들을 만족 또는 초과하는 방식으로 시스템을 계속 실행하는 데 필요한 작업이다. 운

영에는 서비스 수명 주기의 모든 측면이 포함된다. 즉, 운영은 서비스의 초기 시동과 최종 폐기

사이의 모든 것을 포함한다.

일반적으로 운영 작업은 가용성(availability ), 속도, 성능, 보안, 수용량 계획, 소프

트웨어/하드웨어 업그레이드에 초점을 둔다. 이들 중 하나라도 실패하면 시스템의 신뢰성

(reliability )이 깨지는 결과가 발생한다. 서비스가 느리면 사용자는 서비스가 엉망이라고 간

주한다. 시스템의 보안이 허술하면 외부인이 시스템을 장악할 수 있다. 적절한 수용량 계획이

없으면 과부하가 걸려서 장애를 일으킨다. 업그레이드를 제대로 수행하지 못하면 서비스 가동

이 중단된다. 업그레이드를 아예 하지 않으면 버그들이 수정되지 않은 채로 남는다. 이 모든 활

동은 궁극적으로 시스템의 신뢰성에 영향을 미치므로, 구글은 운영을 사이트 신뢰성 공학(Site

Reliability Engineering, SRE )이라고 부른다. 그리고 다른 여러 회사도 그런 선례를 따랐다.

분산 세계에서의 운영

CHAPTER 07

214 7장 분산 세계에서의 운영

운영은 팀 활동이다. 운영은 한 사람이 하는 것이 아니라 함께 일하는 여러 명의 팀이 수행

한다. 그런 이유로 이번 장의 상당 부분은 운영자들이 개인들의 집합이 아니라 하나의 팀으로

서 일하는 데 도움이 되는 공정(process )과 방침(policy )들을 설명한다. 진행을 느리게 만드

는 관료주의적 미로처럼 보이는 공정들을 사용하는 회사들도 있다. 이번 장에 나오듯이, 그리

고 좀 더 중요하게는 우리 저자들의 개인적인 경험에 따르면, 아주 큰 컴퓨팅 시스템의 실행을

가능하게 하는 것은 바로 좋은 공정들이다. 다른 말로 하면, 공정은 팀이 옳은 일을 거듭 수행

할 수 있게 만드는 요인이다.

이번 장은 먼저 운영 관리에 관한 몇 가지 배경 지식을 짚은 후 운영 서비스 수명주기를 논

의하고, 마지막으로는 전형적인 운영 작업 전략들을 논의한다. 이번 장에서 다루는 모든 주제

를 이후의 장들에서 좀 더 자세히 살펴볼 것이다.


혁신(innovation ): 아직 해보지 않은 일(좋은 일)을 하는 것.

기계(machine ): 가상의 기계 또는 물리적 기계.

호출대기(oncall ): 가동 중단이나 경고 시 최초 대응자가 될 수 있도록 대기하는 것.

서버(server ): 어떠한 기능이나 API를 제공하는 소프트웨어. (서버 하드웨어를 말하는 것이

아님.)


약한 개시(soft launch ): 새 서비스를 공표하지 않고 개시하는 것. 이렇게 하면 입소문이 퍼지

면서 소통량이 느리게 증가하므로, 너무 많은 사람이 보기 전에 운영팀이 문제점을 고치거나 시

스템의 규모를 확장할 여유가 생긴다.

SRE : Site Reliability Engineer (사이트 신뢰성 기술자) 또는 Site Reliability

Engineering (시스템 신뢰성 공학)의 약자. 구글에서 활성 서비스들을 유지보수하는 시스템 관

리자들 또는 그런 관리자들이 하는 일을 일컫는 용어이다.

이해관계자(stakeholder ): 프로젝트의 성공에 이해관계가 걸려 있는 개인 또는 조직.



분산 시스템의 운영을 이해하려면 우선 분산 시스템의 운영이 전통적인 전사적全社的

(enterprise ) IT와 어떻게 다른지부터 이해해야 한다. 또한, 운영팀과 개발팀 사이의 긴장의

근원과 운영 규모 변화를 위한 기본적인 기법들도 이해해야 한다.

7.1.1 SRE팀 대 전통적인 전사적 IT 부서

시스템 관리는 하나의 연속체(continuum )이다. 연속체의 한끝에는 전통적인 데스크톱과

클라이언트-서버 기반구조를 담당하는, 흔히 전사적 IT라고 부르는 전통적인 IT 부서가 있

다. 다른 한끝에는 분산 컴퓨팅 환경(주로 웹사이트나 기타 서비스들과 연관되는)을 담당하는

SRE팀 또는 그에 상응하는 비슷한 부서가 있다. 이것이 다소 거친 일반화일 수 있겠지만, 그래

도 몇 가지 중요한 차이점을 설명하기에는 충분할 것이다.

SRE팀이 전사적 IT 부서와 다른 점은, SRE팀은 서비스 하나 또는 잘 정의된 서비스들의

집합 하나를 제공하는 데 집중하는 경향이 있다는 것이다. 반면 전통적인 전사적 IT 부서(이하

간단히 IT 부서)는 데스크톱 서비스, 백오피스backoffice 서비스, 그리고 그 사이의 모든 것(‘전원

플러그가 있는 모든 것’)을 책임지는 경향이 있다. SRE팀의 주된 고객은 서비스의 제품 관리자

들이지만 IT 부서의 고객들은 최종 사용자들이다. 이는 SRE팀의 활동이 각자 우선순위가 다른

여러 사용자에 좌지우지되기보다는 엄선된 몇몇 사업 수치들에 초점을 두고 수행됨을 뜻한다.

가동시간에 대한 태도에도 차이가 있다. SRE팀은 요구가 많은, 하루 24시간씩 일주일 내

내 가동되어야 하는 서비스를 관리한다. 이 때문에 SRE팀은 가동 중단에 뒤늦게 대응하기보다

는 문제점을 미리 방지하는 데 초점을 두며, 복잡하지만 비개입적인(non-intrusive ) 유지보

수 절차를 수행하는 데 주력한다. 반면 IT 부서에는 예정된 비가동시간(downtime )과 관련해

서 어느 정도의 유연성이 허용되며, SLA는 주로 서비스 중단 시 서비스를 얼마나 빨리 복원할

수 있는지에 초점을 둔다. SRE의 관점에서 비가동시간은 피해야 할 일이며, 서비스가 유지보

수 중이라고 해도 서비스의 가동을 중단해서는 안 된다.

SRE팀은 새 소프트웨어 릴리스나 수용량 추가 때문에 끊임없이 변하는 서비스들을 관리한

다. IT 부서는 그리 자주 업그레이드되지는 않는 서비스들을 운영하는 경향이 있다. IT 부서가

관리하는 서비스들은 외주 개발자들이 구축하는 경우가 많은데, 외주 개발자들은 일단 시스템

이 안정되면 손을 떼고 가버린다.


SRE팀이 관리하는 시스템들은 더 많은 소통량과 더 큰 부하를 처리하기 위해 그 규모가 계

속 변하는 경우가 많다. SRE팀은 전체적인 처리량뿐만 아니라 잠복지연(특정 요청이 처리되

기까지의 시간)도 관리한다. 효율성이 중요한 문제가 되는데, 각 기계에 약간의 낭비가 있어도

기계들이 수백, 수천 대이면 큰 손실로 이어지기 때문이다. 반면 IT 부서가 관리하는 시스템들

은 연간 부하량 증가가 그리 크지 않다고 예상하는 환경에서 구축되는 경우가 많다. 그런 경우

에는 다음번 시스템 교체 시기까지 몇 년 동안의 예상 부하량을 처리할 수 있을 정도로 시스템

을 충분히 크게 구축하는 전략을 사용할 수 있다.

이러한 요구사항들 때문에, SRE팀의 시스템들은 직접 만들거나 오픈소스 또는 기타 서드

파티 구성요소들과 통합된 플랫폼 위에 맞춤형으로 구축한 것인 경향이 있다. ‘기성품’이나 턴

키 시스템이 아닌 것이다. SRE팀의 시스템은 활발하게 관리되지만, IT 부서의 시스템은 초기

인도 상태에서 별로 변하지 않는다. 이러한 차이 때문에 분산 컴퓨팅 시스템 서비스들은 개별

적인 팀이 맞춤형 운영 및 관리 관행들을 통해서 개별적으로 관리하는 것이 가장 좋다.

이러한 여러 차이점이 있지만, 최근에는 IT 부서들도 가동시간 및 규모가변성에 관한 요구

(SRE 환경에서 볼 수 있는)를 받기 시작했다. 그 결과 분산 컴퓨팅의 관리 기법들이 전사적 IT

환경에 빠르게 채용되고 있다.

7.1.2 변화 대 안정성

안전성을 향한 욕구와 변화를 향한 욕구 사이에는 긴장이 존재한다. 대체로 운영팀은 안전성을

선호하지만 개발팀은 변화를 선호한다. 연말 성과 평가 시 각 그룹을 평가하는 방식을 생각해

보자. 개발자는 자신이 작성한 코드가 실무 서비스에 실제로 쓰이게 되면 칭찬을 받는다. 서비

스를 눈에 띄게 변화시키면 다른 어떤 성과보다도 큰 보상을 받게 된다. 그래서 개발자는 새 릴

리스가 실무에 더 자주 투입되길 바란다. 반면 운영팀은 SLA를 잘 준수할수록 보상을 받는데,

SLA의 준수는 대부분 가동시간과 관련이 있다. 그래서 운영팀은 안정성을 우선시한다.

시스템은 기준 안정성에서 시작한다. 이후 시스템이 변하는데, 그럴 때마다 안정성에 악영

향이 미친다. 그러나 일종의 개입을 통해서 시스템이 다시 안정을 찾는다. 이를 변화-불안정성

주기(change-instability cycle )라고 부른다.

모든 소프트웨어 롤아웃은 안정성에 영향을 미친다. 어떤 변경 때문에 버그가 도입될 수 있

으며, 그러한 버그들은 우회책과 새 소프트웨어 릴리스를 통해서 수정된다. 새 버그를 전혀 도

입하지 않는 릴리스라도, 곧 업그레이드할 기계로부터 작업 부하를 다른 곳으로 옮기는 과정 때


문에 안정성이 나빠질 수 있다. 소프트웨어가 아닌 부분의 변경 역시 안정성을 해친다. 네트워

크 변경이 지역 네트워크를 따라 전파되는 동안에는 지역 네트워크의 안정성이 떨어질 수 있다.

안정성을 바라는 운영팀과 변화를 바라는 개발자 사이에 긴장 관계가 존재하므로, 적절한

균형점에 도달할 수 있는 메커니즘이 꼭 필요하다.

한 가지 전략은 새 기능을 추가하는 작업보다는 안정성을 향상하는 작업을 우선시하는 것

이다. 예를 들어 새 기능 요청보다는 버그 수정에 더 높은 우선순위를 둔다. 이러한 접근방식에

서는 주요 릴리스는 여러 새 기능을 도입하되 그다음 몇몇 릴리스는 버그 수정에 초점을 두고,

그런 다음 다시 새로운 주요 릴리스로 시작하는 주기를 반복한다. 기술적 관리의 요구 때문에

새 기능에 초점을 두고 버그 수정을 무시한다면, 시스템이 차츰 불안정해져서 급기야는 통제가

불가능한 상황에 다다를 수 있다.

또 다른 전략은 개발팀과 운영팀의 목표를 일치시키는 것이다. 두 단위 모두 SLA 준수는

물론 시스템의 변화 속도에도 책임을 지게 된다. 둘 다 연말 평가 시 SLA 준수에 관련된 항목

들은 물론 새 기능을 제때 인도하는 데 관련된 항목들을 평가받는다.

두 단위의 목표를 아주 성공적으로 일치시킨 조직들은 개발자들과 운영자들이 하나의 팀

으로 일하도록 조직 구성을 조정했다. 이는 제8장에서 설명하는 개발운영(DevOps ) 운동의

전제이다.

또 다른 전략은 안정성 향상을 위한 시간과 새 기능을 위한 시간의 예산(budget )을 짜두

는 것이다. 일반적으로 소프트웨어 공학 조직들은 소프트웨어 요청의 크기나 그 요청을 완수하

는 데 걸리는 평균 시간을 추정하는 방법을 갖추고 있다. 각각의 새 릴리스에는 일정한 크기 예

산 또는 시간 예산이 있는데, 그 예산을 넘지 않는 한에서 일정 분량의 안정성 향상 작업을 할

당한다. §2.2.2의 끝에 나온 사례 연구는 이러한 접근방식의 한 예이다. 마찬가지로, 안정성 관

련 코드 변경을 전담하는 사람들이 이러한 할당을 수행할 수도 있다.

예산을 SLA에 근거해서 결정할 수도 있다. 매달 시스템의 안정성 하락량을 예측하고, 그것

을 일종의 예산으로 간주한다. 각 롤아웃이 그 예산의 일부를 사용하며, 불안정성 관련 버그 역

시 예산을 소비한다. 개발자는 그러한 불안정성을 유발하는 코드를 개선하는 데 주력함으로써

각 달의 롤아웃 횟수를 최대화할 수 있다. 이로부터 양의(positive ) 피드백 루프가 생긴다. 이

런 방식의 예가 구글의 오류 예산(Error Budget )인데, 이에 대해서는 §19.4에서 좀 더 자세

히 설명한다.


7.1.3 SRE의 정의

구글이 발표한 SRE 핵심 관행(core practice )들은 구글이 내부적으로 10년 이상 실제로 실

천해온 것들이다. 구글 사이트 신뢰성 공학 부사장인 벤자민 트레이너 슬로스Benjamin Treynor Sloss

는 첫 USENIX SREcon (2014 )의 기조연설에서 다음과 같은 원칙 또는 관행들을 나열했다.

사이트 신뢰성 관행

1. 코더coder들만 고용한다.

2. 서비스마다 SLA를 둔다.

3. 성능을 측정하고, SLA를 만족하지 못하는 사항을 보고한다.

4. 오류 예산을 활용하고, 개시(launch )들이 반드시 오류 예산을 지키게 한다.

5. 공통의 직원 풀에서 SRE팀과 개발팀에 인원을 공급한다.

6. 여분의(운영팀의 수용 능력을 넘는) 운영(Ops ) 작업은 개발팀(Dev )으로 흘러가게

한다.

7. SRE 운영 부하가 50%를 넘지 않게 한다.

8. 운영팀의 작업의 5%를 개발팀과 공유한다.

9. 호출대기 팀은 한 장소에 적어도 여덟 명으로 구성하거나, 여러 장소들 각각에 적어도

여섯 명으로 구성한다.

10. 호출대기의 한 교대근무(shift ) 기간에 발생하는 사건이 최대 2회를 넘지 않도록 한다.

11. 모든 사건에 대해 사후 분석(postmortem; 또는 사후 검토)을 수행한다.

12. 사후 분석이 누군가를 비난하는 기회가 되어서는 안 된다. 사람보다는 공정과 기술에

초점을 두어야 한다.

1번 항목은 SRE팀이 반드시 코드를 작성할 수 있어야 한다는 뜻이다. SRE팀의 모든 구성원이

전업 소프트웨어 개발자는 아니라고 해도, 자명하지 않은 문제들을 코드를 작성해서 해결하는

능력은 모든 구성원이 갖추어야 한다. 어떤 과제를 30번 반복한다고 할 때, 사이트 신뢰성 기술

자는 처음 두 번 반복 후 지루해져서 나머지 작업을 자동화로 해결하려 들어야 할 것이다. SRE

팀은 비슷한 수준의 개발자들과 의사소통이 가능할 정도의 소프트웨어 개발 경험을 반드시 갖

추어야 하며, 개발자가 하는 일과 컴퓨터가 할 수 있는/없는 일들을 제대로 알고 있어야 한다.

프로젝트들에 할당되는 기술자들의 수가 고정되어 있다고 할 때, SRE팀과 개발팀을 동일


한 직원 풀에서 충원한다는 것은 SRE팀에 사람이 필요할 때마다 개발팀의 인원이 빠진다는 뜻

이다. 반면 대부분의 기업에서는 시스템 관리자들과 개발자들이 개별적인 예산을 가진 팀들에

서 할당된다. 한 프로젝트에 참여하는 개발자의 수를 최대로 늘리길 원하는 것은 합당한 일이

라 할 수 있다. 새 기능을 작성하는 것은 바로 개발자들이기 때문이다. SRE팀과 개발팀의 인원

을 공통의 풀에서 충원한다면, 개발자들은 좀 더 적은 인원의 SRE팀이 효율적으로 운영할 수

있는 시스템을 만들고자 할 것이다.

운영상의 부담을 최소화하는 코드를 작성하도록 개발자들을 추동하는 또 다른 방법은 여

분의 운영 작업이 개발자들에게 흘러가게 하는 것이다. 이렇게 하면 개발자들이 요령을 피워서

운영 부담을 과도하게 키우는 문제를 억제할 수 있다(그런 부담이 결국에는 개발자 자신에게

돌아올 것이므로). 마찬가지로, 운영 작업의 5%를 수행하게 하면 개발자들은 운영상의 현실적

인 어려움에 신경을 더 쓰게 된다.

SRE팀 내에서 운영 부하를 50%로 제한하면 수작업의 양이 제한된다. 수작업(manual

labor )은 이를테면 그 수작업의 필요성을 제거하는 코드를 작성하는 것에 비해 투자 수익이

낮다. 이에 대해서는 §12.4.2 “고역 줄이기”에서 논의한다.

여러 SRE 실천 사항들은 변화에 대한 요구와 안정성에 대한 요구 사이의 균형점을 찾는 데

관련된 것이다. 이들 중 가장 중요한 것은 구글 SRE팀이 오류 예산이라고 부르는 것인데, 이에

대해서는 §19.4에서 자세히 설명한다.

오류 예산에서 핵심은 SLA이다. 모든 서비스에는 SLA가 있어야 한다. SLA는 시스템이 어

느 정도의 신뢰성을 갖추어야 하는지를 명시한다. SLA는 모든 작업의 측정에 쓰이는 하나의

기준이 된다. SLA는 제16장에서 논의하겠다.

가동 중단이나 기타 주요 SLA 관련 사건이 발생하면 반드시 사후 분석 보고서를 작성해야

한다. 그 보고서는 무엇이 발생했는지 상세히 기술해야 하며, 이후 그런 상황을 방지하는 데 필

요한 분석과 제안도 포함되어야 한다. 이 보고서를 회사 내에서 공유해서 전체 조직이 경험에

서 배울 수 있게 한다. 사후 분석의 초점은 공정과 기술이지 비난 대상을 찾는 것이 아니다. 사

후 분석은 §14.3.2의 주제이다. 모든 SLA 관련 사건에 대응하고 사후 분석 보고서를 작성하는

책임은 당시 호출대기 중인 사람에게 있다.

호출대기가 당면한 문제에 대응하는 방법인 것만은 아니다. 오히려, 미래의 문제를 줄이는

방법이라고 보아야 할 것이다. 따라서 호출대기자들이 버티지 못할 정도로 큰 스트레스를 주는

방식으로 운영해서는 안 되며, 장기적인 문제 해결과 재발 방지를 위한 행동을 끌어낼 수 있어


야 한다. 호출대기 팀은 한 장소에서 적어도 여덟 명 또는 두 장소에서 각각 적어도 여섯 명으

로 이루어진다. 대체로 이 정도 크기는 호출대기자들의 능력 조합에 부족한 점이 없을 정도로

크며, 한편으로는 한 교대근무 동안 가동 중단 사건이 2회 이하로 발생하도록 교대근무 기간을

줄이기에 충분한 정도로 작다. 결과적으로 호출대기자마다 각 사건을 상세히 처리하기에 충분

한 시간이 주어지며, 따라서 필요한 장기적 해결책을 제대로 적용할 수 있다. 호출대기를 이런

식으로 관리하는 것은 제14장의 주제이다.

구글 이외의 회사들도 실제 활성 서비스를 관리하는 시스템 관리자들을 사이트 신뢰성 기

술자(SRE )라고 부르는 관례를 채용했다. 그러나 그 직위가 담당하는 구체적인 실천 사항들은

회사마다 다를 수 있다. 이전 절에서 논의한 것은 구글의 SRE를 정의하는 실천 사항들로, 이들

은 구글의 성공에 핵심적인 역할을 하고 있다.

7.1.4 대규모 운영

분산 컴퓨팅 시스템의 운영은 대규모로 진행된다. 분산 컴퓨팅 시스템에서는 수백, 수천 대의

컴퓨터가 협동적으로 운영된다. 이 때문에 분산 컴퓨팅 시스템의 운영은 전통적인 컴퓨팅 시스

템의 운영과 여러모로 다르다.

수작업에 의한 공정은 규모 변화가 어렵다. 어떤 과제를 수작업으로 처리하는 경우, 만일

과제의 양이 두 배가 되면 인간의 노력도 두 배가 필요해진다. 만일 시스템의 규모가 수천 대의

컴퓨터나 서버, 공정들로 확장된다면, 수작업으로는 그런 규모 확장을 감당할 수 없다. 반면 자

동화는 규모 변화가 쉽다. 한 번 작성한 코드는 몇천 번이라도 재사용할 수 있다. 수많은 기계

나 공정, 서버, 서비스로 이루어진 시스템은 반드시 자동화해야 한다. 이러한 관점은 컴퓨터 할

당, 운영 체제 구성, 소프트웨어 설치, 문제점 감시에 적용된다. 자동화는 ‘하면 좋은 것’이 아니

라 ‘반드시 해야 하는 것’이다. (자동화는 제12장의 주제이다.)

운영을 자동화하면 시스템 관리가 장인의 수공예보다는 공장의 조립 라인과 더 비슷해진

다. 시스템 관리자는 실제로 작업을 하는 사람에서 조립 라인의 로봇들을 관리하는 사람으로

변한다. 자동화 덕분에 제조업 분야의 대량생산 기법들과 운영 관행들을 분산 컴퓨팅에 도입할

수 있다. 예를 들어 실무(production )의 모든 단계에서 측정치들을 수집해서 통계 분석 기법

을 적용함으로써 시스템 처리량을 개선할 수 있다. 지속적 개선(continuous improvement )

같은 제조업 기법들은 개발운영의 ‘3대 방법(Three Ways )’의 토대이다. (§8.2를 보라.)

자동화되지 않은 것들은 크게 세 부류로 나뉜다. 하나는 자동화해야 마땅하지만 아직 자동


화되지 않은 것이고, 또 하나는 자동화할 가치가 없는 것, 마지막은 사람이 수행하는 공정이다.

아직 자동화되지 않은 과제

자동화를 만들고, 검사하고, 배치하는 데에는 시간이 걸린다. 따라서 자동화되길 기다리는 것

들이 항상 존재한다. 모든 것을 자동화할 만큼 시간이 넉넉한 경우는 없으므로, 반드시 우선순

위를 매기고 자동화 방법을 현명하게 선택해야 한다. (§2.2.2와 §12.1.1을 보라.)

아직 자동화되지 않았거나 자동화된 적이 없는 공정의 경우 소위 각본(playbook )이라고

부르는 절차 문서를 만들면 그 공정을 일관적이고 반복 가능하게 정련하는 데 도움이 된다. 좋

은 각본이 있으면 나중에 공정을 자동화하기가 쉬워진다. 뭔가를 자동화할 때 가장 어려운 부

분은 그 공정을 정확히 서술하는 것 자체인 경우가 많다. 각본이 공정을 정확히 서술한다면, 자

동화 코드를 작성하는 것은 비교적 쉬운 일이다.

자동화할 가치가 없는 과제

그리 자주 진행되지 않거나, 자동화하기가 너무 힘들거나, 자주 바뀌어서 자동화가 불가능한

공정은 자동화할 가치가 없다. 자동화는 시간과 노력을 투자하는 일이며, 투자 수익(ROI )의

관점에서 볼 때 자동화가 항상 이득이 되는 것은 아니다.

그렇긴 하지만, 자동화할 가치가 있는 공통의 경우들이 존재한다. 그런 것들을 자동화하면

좀 더 드문 경우(극단적 경우(edge case ) )들이 통합되거나 제거되기도 한다. 공통의 경우를

자동화해서 더 나은 서비스를 제공하면, 극단적 경우에 해당하는 고객이 특별 취급을 요구할

필요성이 갑자기 사라지는 경우가 많다.

공통의 경우를 자동화하는 것의 장점

어떤 회사의 이야기이다. 그 회사는 가상 기계들을 세 가지 방식으로 조달(provisioning )했다.

세 방식 모두 수작업이었으며, 그래서 고객들은 시스템 관리자가 작업을 수행할 여유가 생길 때

까지 며칠씩 기다려야 했다. 서로 다른 세 방식을 처리하는 것이 다소 복잡했기 때문에, 가상 기

계 조달을 자동화하는 프로젝트는 진척이 없었다. 덜 자주 쓰이는 두 방식의 사용자들은 자신들

이 특별한 고객이기 때문에 조달 공정이 달라야 한다고 요구했다. 그들은 아주 중대한, 그러나

일화적인 증거에 기초해서 자신들의 주장을 진지하게 정당화했으며, 아주 강력하고 강압적으로

자신들의 의사를 관철하려 했다. 프로젝트를 진행하기 위해 회사는 가장 흔한 경우를 일단 자동


화하고 다른 두 극단적 경우들은 나중에 자동화하겠다고 약속했다.

이 방법이 애초의 모든 경우를 동시에 자동화하는 것보다 구현하기가 훨씬 쉬웠다. 초기 자동

화 덕분에 조달 시간이 몇 분으로 줄었으며, 시스템 관리자의 개입 없이도 조달이 가능했다. 심

지어 밤이나 주말에도 가상 기계를 조달할 수 있었다. 그러자 놀라운 일이 발생했다. 다른 두 경

우의 사용자들이 자신들의 특별함이 사라졌음을 갑자기 깨달은 것이다! 그들은 자동화된 방법을

받아들였다. 결과적으로 시스템 관리자가 두 극단적 경우를 자동화할 필요가 아예 사라졌으며,

조달 시스템은 복잡하지 않고 관리하기 쉬운 형태로 남았다.

자동화할 수 없는 과제

사람이 관여하는 공정은 자동화가 불가능하다. 이해관계자(고객, 투자자 등)들과의 관계를 유

지한다거나, 더 큰 구매를 위한 경매 공정을 관리하거나, 새 기술을 평가하거나, 팀원들 사이의

호출대기 일정을 조율하는 등은 자동화할 수 없다. 이들을 자동화를 통해서 제거할 수는 없지

만, 좀 더 능률화(streamlining )하는 것은 가능하다.

● 이해관계자들과의 상호작용의 상당 부분을 더 나은 문서화를 통해서 제거할 수 있다. 소개

문서나 사용자 문서, 모범 관행 추천, 스타일 지침 등을 제공하면 이해관계자들이 더 많은

것을 스스로 해결할 수 있다. 만일 독자의 서비스를 다른 여러 서비스나 서비스팀이 사용할

것이라면, 문서화를 제대로 갖추는 것이 더욱 중요해진다. 동영상 강의도 유용하며, 이미

강연 내용이 마련되어 있다면 그냥 녹화하기만 하면 되므로 큰 노력이 들지 않는다.

● 공통적인 요청들을 자급식으로 제출하게 바꾸면 이해관계자들과의 상호작용의 일부를 제

거할 수 있다. 향후의 수용량 요구사항을 고객과 직접 만나서 파악하기보다는, 웹 사용자

인터페이스나 API를 통해서 제출하게 하는 것이 낫다. 예를 들어 수백 개의 다른 팀에게

서비스를 제공한다면, 향후 수용량 요구 파악만으로 프로젝트 관리자의 모든 시간이 소비

될 것이다. 반면 적절한 조달 자동화를 회사의 공급망 관리 시스템과 통합한다면 최소한의

노력으로 문제가 해결될 것이다. 요청 자급식

● 새 기술을 평가하는 데에도 사람의 노력이 많이 소비될 수 있으나, 공통의 경우를 식별한다

면 종단 간(end-to-end ) 공정을 조립 라인 공정으로 변환해서 최적화할 수 있다. 예를 들

어 하드 드라이브를 수천 개 구매할 때에는 새 모델을 가끔씩만, 그리고 상세한 평가를 거

친 후에만 포함시키는 것이 현명하다. 그러한 평가 공정은 표준화, 자동화해야 하며, 이후

분석을 위해 평가 결과도 자동으로 저장해야 한다.

2237.2 서비스의 수명 주기

● 팀 공정을 자동화로 대체하거나 가속할 수 있다. 호출대기 일정을 짜다 보면 주요 휴일을

피하려는 팀원들 사이에서 혼란스럽고 지저분한 협상이 벌어지기 쉽다. 자동화를 이용하면

이를 자급식 시스템(사람들이 각자 가능한 시간을 제출하면 다음 몇 달간의 최적의 일정을

결정해 주는 형태의)으로 바꿀 수 있다. 즉, 자동화는 문제를 더 잘 해결하고 스트레스를

줄여준다.

● 의사소통이나 상태, 공정 추적(process tracking ) 같은 메타 공정(meta-process )의

진행을 온라인 시스템을 통해서 촉진할 수 있다. 팀이 커지면 모든 참여 단위 사이의 상호

작용과 의사소통을 추적하는 것 자체가 하나의 부담으로 작용할 수 있다. 그것을 자동화하

면 팀원마다 수 시간의 수작업을 줄일 수 있다. 예를 들어 자신이 받은 지시사항이 승인 절

차를 거쳐 가는 상황을 각 팀원이 웹 기반 시스템으로 확인할 수 있으면 팀원은 상태 보고

서를 작성할 필요가 없어지며, 그러면 예외 상황과 문제점을 처리하는 데에만 집중할 수 있

다. 어떤 하나의 공정에서 작업이 여러 팀을 오가는 경우, 현황판을 제공하고 작업 이전 시

기를 자동으로 팀들에게 통지하는 시스템을 도입한다면 필요 이상으로 많은 프로젝트 관리

자들을 둘 필요성이 줄어든다.

● 최상의 공정 최적화는 공정을 아예 제거하는 것이다. 제거된 과제는 더 이상 수행하거나 유

지보수할 필요가 없다. 그런 과제에는 버그도 없고 보안 구멍도 없다. 예를 들어 서비스를

제공하는 컴퓨터들에 쓰이는 운영 체제가 세 종류라고 할 때, 그것을 두 종류로 줄이면 많

은 작업이 제거된다. 독자의 서비스를 다른 서비스팀들이 사용한다면, 그리고 새 팀이 추가

될 때마다 긴 승인 절차를 거쳐야 한다면, 특정 종류의 사용자들을 자동으로 승인하도록 승

인 절차를 능률화하는 것이 더 나을 수 있다. 공정 제거

7.2 서비스의 수명 주기

운영은 크게 개시, 유지보수(정규 및 비상), 업그레이드, 폐지로 구성되는 서비스 수명 주기

(service life cycle ) 전체를 책임진다. 수명 주기의 단계들에는 각자 고유한 요구사항들이 존

재하므로, 각 단계를 다른 방식으로 관리하는 전략이 필요하다.

수명 주기의 단계들은 다음과 같다.


● 서비스 개시: 개시(launch )란 서비스를 처음으로 제공하는 것을 말한다. 개시에 의해 서

비스의 수명이 시작되며, 최초의 고객들이 서비스를 사용하기 시작한다. 또한, 개시 이전에

발견하지 못한 문제점들이 드러나고 수정된다. (§7.2.1 )

● 비상 과제(emergency task ) : 예외적인 또는 예기치 않은 사건들을 처리하는 단계이다.

여기에는 가동 중단 처리가 포함되며, 더욱 중요하게는 가동 중단을 유발하는 조건들을 검

출하고 바로잡는 것이 포함된다. (제14장)

● 정상 과제(nonemergency task ) : 정상적으로 작동하는 시스템의 일부로 필요한 모든

수작업을 수행하는 단계이다. 여기에는 주기적인(주간 또는 월간) 유지보수 과제(이를테

면 월별 과금 절차 준비 등)는 물론이고 사용자 요청(이를테면 다른 내부 서비스나 팀이 사

용하는 서비스를 활성화해달라는 요청 등) 처리도 포함된다. (§7.3 )

● 업그레이드: 새 소프트웨어 릴리스와 하드웨어 플랫폼을 배치하는 것을 말한다. 이를 잘 해

낼수록 기업이 새로운 것을 더 적극적으로 시도하고 혁신할 수 있다. 새 소프트웨어 릴리

스를 배치하려면 먼저 그 릴리스를 구축하고 검사해야 한다. 검사에는 개발자가 수행하는

시스템 검사는 물론 운영팀이 수행하는 사용자 인수 검사(user acceptance test, UAT )

도 포함된다. UAT에는 성능 회귀(performance regression; 성능이 의도치 않게 하락

하는 것)가 없는지 확인하는 검사가 포함된다. 또한 보안 문제점을 검출하기 위한 취약성

(vulnerability ) 평가도 수행해야 한다. 새 하드웨어는 반드시 호환성, 성능 회귀, 운영 공

정의 변화 등을 점검하는 하드웨어 자격 검증(hardware qualification )을 거쳐야 한다.

(§10.2 )

● 폐지(decommissioning ) : 서비스를 내리는 것을 말한다. 이는 서비스 개시의 반대이다.

즉, 남아 있는 사용자들을 제거하고, 서비스를 끄고, 관련 서비스 구성들에서 해당 서비스

에 대한 참조를 제거하고, 모든 자원을 반환하고, 기존 자료를 보관하고, 하드웨어들을 재

사용, 판매, 폐기하기 전에 하드웨어들에 남아 있는 모든 자료를 철저히 삭제(erasing 또

는 scrubbing )한다. (§7.2.2 )

● 프로젝트 작업: 전용 자원들의 할당과 계획 수립이 필요할 정도로 큰 규모의 과제들을 수행

하는 것을 말한다. 사실 이것이 서비스 수명 주기의 직접적인 일부는 아니지만, 서비스를

관리하다보면 다른 과제보다 큰 과제를 수행해야 할 일이 생긴다. 이를테면 간헐적이지만

반복되는 고장을 고치는 것, 제품의 미래에 관한 일정과 계획을 이해관계자들과 협의하는

것, 서비스를 새 데이터센터로 옮기는 것, 서비스의 규모를 새로운 방식으로 변화하는 것

등이 있다. (§7.3 )

2418.1 개발운영이란?

개발운영의 반대말은 절망이다.

-진 킴Gene Kim

이번 장은 ‘개발운영(DevOps )’*이라고 부르는 문화 및 관행(practice, 실천 사항) 집합에

관한 것이다. 개발운영 조직에서는 소프트웨어 개발자들과 운영 기술자들이 한 팀을 이루어 일

하면서 웹 사이트나 웹 서비스에 대한 책임을 공유한다. 이는 개발자와 운영자가 개별적으로

일하는, 그리고 종종 목표가 상충하는 조직과는 다른 방식이다. 개발운영은 웹 서비스를 운영

하는 현대적인 방식이라 할 수 있다.

개발운영은 몇 가지 문화 및 자세 변화를 몇 가지 상식적인 공정과 결합한다. 개발운영은

원래 애자일 방법론을 운영에 적용하는 시도에서 시작된 것인데, 진화 과정을 거치면서 신뢰성

있는 서비스를 만들어 낼 수 있는 능률적인 원칙들과 공정들의 집합이 만들어졌다.

부록 B에서 보겠지만, 클라우드 또는 분산 컴퓨팅은 경제적인 하드웨어들의 등장에서 비롯

된 필연적인 결과라 할 수 있다. 비슷하게, 개발운영은 그런 환경에서 운영을 효율적으로 수행

하고자 하는 요구의 필연적인 결과이다.

하드웨어와 소프트웨어가 장애 내구성을 충분한 수준으로 갖추었다면, 남은 문제는 바로

* 옮긴이_ DevOps가 Development와 Operation을 합쳐서 만든 신조어인 것처럼, ‘개발운영’은 개발과 운영을 합쳐서 만든 신조어

이다. 이를 ‘개발 운영’으로 띄어 쓰거나(이를테면 일부 아마존 AWS 한국어 페이지) ‘개발/운영’ 또는 ‘개발·운영’으로 표기하는 예도 있

지만, 이 책에서는 개발과 운영을 매끄럽게 통합한다는 원래의 취지를 살려서 개발과 운영 사이에 아무것도 끼어들지 않는 ‘개발운영’이라

는 표기를 사용한다. 영문 표기 DevOps나 음차 데브옵스 대신 ‘개발운영’을 선택한 데에는, DevOps가 특정 분야, 특정 부류(또는 특정

‘진영’)의 사람들만 사용하는 일종의 ‘등록상표’ 또는 고유명사로 머무르지 않고 좀 더 광범위하고 보편적인 일반명사로 쓰이길 바라는(아마

이 대목에서 agile 대 Agile을 떠올리는 독자도 있을 것이다) 마음이 담겨 있다.

개발운영 문화

CHAPTER 08

242 8장 개발운영 문화

사람이다. 선구적 논문 “Why Do Internet Services Fail, and What Can Be Done about

It?”(Oppenheimer 외 2003 )은 향후 웹 서비스의 성공을 원한다면 운영 측면들을 반드시 개

선해야 한다는 점을 일깨웠다.

우리는 (1 ) 운영자 실수가 세 서비스 중 둘에서 단일 장애 원인으로는 가장 큰 원인이었으며,

(2 ) 운영자 실수를 바로잡는 데 많은 시간이 필요한 경우가 많으며, (3 ) 가장 많이 발생하

는 운영자 실수는 구성 오류이며, (4 ) 직접 작성한 앞단 소프트웨어의 장애가 두드려졌으며,

(5 ) 온라인 검사를 좀 더 상세하게 수행하고 구성요소 장애를 좀 더 철저히 노출, 검출함으로

써 적어도 한 서비스에서는 장애율을 줄일 수 있음을 발견했다.

다른 말로 하면, 이제는 기술의 신뢰성이 충분히 높아져서 그것을 관리하는 데 쓰이는 공

정의 문제점만 남은 상황이 된 것이다. 따라서 우리는 더 나은 관행이 필요하다.

대규모 운영을 개선하는 표준적인 방법은 W. 에드워드 데밍Edwards Deming의 “Shewhart

cycle”(Deming 2000 )이나 “Lean Manufacturing”(Spear & Bowen 1999 )을 적용하는

것이다. 개발운영의 핵심 원리들은 그런 기존 원리들을 웹 시스템 관리에 맞게 적응시킨 것이

라 할 수 있다. 서적 The Phoenix Project (Kim, Behr & Spafford 2013 )는 망해가는 IT 조

직을 개혁하는 과정에서 그런 원리들을 배워나가는 팀에 관한 소설 형태로 이를 설명한다.


개발운영은 문화와 관행들의 조합이다. 시스템 관리자, 소프트웨어 개발자, 웹 운영팀 구성원

들은 모두 개발운영 환경에 기여한다. 개발운영에서 시스템 관리자와 개발자는 서비스와 그 가

용성에 대한 책임을 공유한다. 개발운영은 개발자들과 시스템 관리자 또는 운영자들이 가동시

간에 대한 책임을 공유하게 함으로써 개발자들이 우선시하는 과제들과 시스템 관리자 또는 운

영자들이 우선시하는 과제들을 일치시킨다. 또한, 개발운영은 개발과 검사, 제작에 이르는 다

양한 환경 모두를 소프트웨어 버전 관리 및 제어하에 통합한다.

가장 근본적인 수준에서 개발운영은 사일로(부서 간 장벽)들을 무너뜨리고, 조직의 개발에서

운영으로의 인도(delivery ) 수명 주기를 망치는 병목과 위험 요소를 제거하는 것에 관한 것

이다. 목표는 명세서로 시작해서 고객과 접한 환경에서의 기능 실행으로 이어지는 흐름을 빠

르고도 신뢰성 있게 변화할 수 있게 하는 것이다(Edwards 2012 ).


개발운영은 현재 발전 중인 분야이다. 현재 개발운영은 주로 웹 응용 프로그램과 클라우드

환경에서 실천되지만, 그 영향력이 모든 업계의 모든 부분으로 퍼지고 있다.

개발운영은 운영의 개선에 관한 것이다. 테오 슐로스네이글Theo Schlossnagle은 개발운영이 “세

계의 조작주의(the operationalism of the world )”라고 말했다(Schlossnagle 2011 ).

자신의 사업에서 운영 부분을 더욱 중요시하는 기업이 점점 많아지고 있다. 이는 프로젝트의

총소유비용(TCO )에 관한 관심이 커진 데서, 다시 말해서 초기 구매 비용뿐만 아니라 더 높은

신뢰성과 변화 속도를 달성하고자 하는 압력이 증가하는 데에서 비롯된 것이다. 효율성을 높이

고 새 기능과 혁신을 도입하려면 변화를 가하는 능력이 필요하다. 전통적으로 변화는 잠재적인

불안정 요인으로 간주되었지만, 개발운영은 기반구조(infrastructure ) 변화를 전반적인 안정

성이 증가하는 방식으로 빠르게, 그리고 자주 가할 수 있음을 보여주었다.

개발운영은 직책 이름이 아니다. 즉, ‘개발운영자’를 고용할 수는 없다. 개발운영은 제품 이

름도 아니다. ‘개발운영 소프트웨어’를 살 수는 없다. 개발운영은 개발운영 문화와 관행을 실

천하는 팀과 조직에 붙이는 용어이다. 물론 개발운영의 여러 관행을 돕는 소프트웨어 패키지

는 존재한다. 그러나 구매 후 개발운영 버튼을 누르기만 하면 마법처럼 개발운영을 “소유하

게” 되는 패키지 같은 것은 없다. 아담 제이콥Adam Jacob은 Velocity 2010에서 행한 선구적 강연

“Choose Your Own Adventure”(Jacob 2010 )에서 개발운영이 직책 이름이 아니고 하나

의 문화를 형성하는 포괄적인 운동임을 명확히 했다. 그러한 문화에 관여하는 모든 이는 전체

시스템의 작동 방식을 알고 있으며, 자신들이 실현하는 기본적 사업 가치를 확실히 이해한다.

그 결과로 가용성이 시스템 관리자만의 문제가 아니라 전체 조직의 문제가 된다.

개발운영이 개발자와 시스템 관리자만을 위한 것은 아니다. 데이먼 에드워즈Damon Edwards는

블로그 글 “DevOps is not a technology problem. DevOps is a business problem”

(Edwards 2010 )에서 개발운영이 조직 전체에 걸친 협동과 최적화에 관한 것임을 강조했다.

개발운영은 착안에서 시작해서 고객에까지 도달하는 공정을 돕는 형태로까지 확장된다. 개발

운영은 멋진 새 도구를 활용하는 차원의 문제가 아니다. 사실 소프트웨어에만 관련된 것도 아

니다.

개발운영 환경 창출과 관련된 조직적 변화는 전통적인 소프트웨어 개발 접근방식과 비교

하면 좀 더 이해하기 쉽다. 맞춤형 웹 응용 프로그램이나 클라우드 서비스 기능을 개발할 때 쓰

이는 방법들의 단점들을 극복해 나가면서, 그리고 그런 환경들의 더 높은 가용성에 대한 요구

를 만족하는 과정에서, 개발운영의 접근방식은 계속 진화한다.

244 8장 개발운영 문화

8.1.1 전통적인 접근방식

소매점에서 파는 비닐로 밀봉된 소프트웨어 패키지나 인터넷에서 내려받는 소프트웨어 패키지

의 경우 소프트웨어를 완성해서 발주하면 개발자의 일은 끝난다. 운영상의 사항들은 오직 고

객에게만 직접 영향을 미친다. 개발자는 운영에서 완전히 빠진다. 운영상의 문제점을 버그 보

고서나 개선 요청 형태로 개발자에게 전달하는 정도가 최선의 경우에 해당한다. 그런 경우에도

개발자는 자신의 코드에서 비롯된 운영상의 문제점에 직접 영향을 받지는 않는다.

전통적인 소프트웨어 개발은 소위 폭포수 방법론(waterfall methodology )을 사용한다.

이 경우 요구사항 수집, 설계, 구현, 검사, 검증, 배치(deployment )* 같은 개발 단계들 각각

을 개별적인 팀이 다른 단계들과는 격리된 상태로 수행한다. 각 단계(팀)는 독립적인 인도물

(deliverable )을 만들어서 다음 단계(팀)에 넘겨준다.

이를 ‘폭포수’ 개발이라고 부르는 것은, 이 단계들이 마치 다층 폭포 같은 모습이기 때문이

다(그림 8.1 ). 정보는 물처럼 아래로 흘러내려 간다.

이런 모형에서 주목할 점은, 적어도 설계가 완료될 때까지는 한 시스템의 운영상의 요구사

항들을 파악할 수 없다는 것이다. 사실 제품이 실제로 배치, 실행된 후에야 운영상의 요구사항

들을 파악할 수 있는 경우도 많다. 이 때문에 운영상의 요구사항들을 요구사항 수집 단계에서

고려하지 못하고, 모든 기능이 ‘동결된’ 후에야 고려하게 된다. 결과적으로, 이러한 접근방식에

서는 운영상의 요구사항들을 고려해봤자 너무 늦어서 더 이상 할 수 있는 일이 없는 상황에 도

달한다.

폭포수 방법에서 시스템 관리자는 소프트웨어의 배치에만 관여하며, 따라서 운영과 가동

시간 요구사항 만족은 전적으로 시스템 관리자의 책임이 된다. 시스템 관리자가 자신의 요구를

만족하도록 소프트웨어 개발에 영향을 미칠 가능성은 거의 없다. 사실 소프트웨어 개발자와 직

접 접촉할 가능성이 아예 없는 경우도 많다.

웹에 기초한 사업 모형(business model )을 가진 기업들이나 웹에서 존재감이 두드러진

기업들은 자신만의 맞춤형 소프트웨어를 개발한다. 그런 기업에서는 소프트웨어 개발자와 시

스템 관리자가 같은 회사 직원들이지만, 전통적으로는 그런 경우에도 소프트웨어 개발자와 시

스템 관리자의 상호작용이 거의 없다. 이들은 격리된 ‘사일로’들에서 일한다. 즉, 각 단위는 다

른 단위의 관심사를 알지 못하며, 결과적으로 그 어떤 단위도 ‘큰 그림’을 보지 못한다. 이런 조

* 옮긴이_ 여기서 배치配置는 배포와 설치를 줄인 말이다. 많은 경우 deployment는 소프트웨어 패키지를 특정 위치로 보내고(배포 또

는 배달), 그 위치에서 소프트웨어를 설치함으로써 이루어진다.


직의 구성도에서 단위들은 CEO 수준까지 올라가야 만나게 된다. 소프트웨어 개발자들은 계속

격리된 상태로, 소프트웨어의 실제 용도와 관련된 동기 부여 없이 소프트웨어를 개발한다. 그

리고 시스템 관리자들은 버그투성이 소프트웨어로 높은 가용성(high availability; 고가용성)

요구사항을 만족하느라 고생하게 된다.

이런 상황에서 일반적으로 운영은 임시방편적 해결책을 통해서 개선된다. 즉, 문제점을 근

본적으로 해결하기보다는 우회할 뿐이고, 최적화 역시 제한된 범위로만 수행하게 된다. 이런

접근방식은 운영 효율성, 성과, 가동시간의 향상에 방해가 된다. 더 나은 대안이 아직 나오지

않았던1 시절의 유물인 폭포수 접근방식이 아직도 쓰이는 것은 안타까운 일이다.

요구사항

구현

설계

검증

유지보수

그림 8.1 폭포수 방법론: 정보는 아래로만 흐른다. 이러한 단방향 정보 흐름은 개발운영의 안티테제(반명제)이다.

1 그런데 과연 그랬던가? 폭포수 모형의 ‘시초’로 간주하는 로이스Royce의 1970년 논문은 사실 폭포수 모형을 비판하고 개선안을 제시하

기 위해 그 모형을 소개했다. 그는 이 모형에서 “설계 반복들이 결코 다음 단계로 제한되지 않으며”, 그래서 이 모형이 “위험하고 장애를

일으킨다”고 썼다. 로이스가 대안으로 제시한 방법은 요즘 애자일이라고 부르는 것과 비슷하다. 안타깝게도, 추측건대 논문 전체를 읽지

않은 사람들 때문에 수 세대에 걸쳐 소프트웨어 개발자들이 폭포수 프로젝트로 고생했다(Pfeiffer 2010).

30311.1 서비스 중단 후 업그레이드

쉬운 일들을 수행해봤자 여러분이 더 강해지지 않으며,

뭔가 달성했다는 기분도 느낄 수 없습니다.

-제리 닐슨Jerri Nielsen 박사(의사)

이번 장은 새 릴리스를 실무 환경에 배치하는 문제를 다룬다. 실무 환경 배치는 기타 환경에 릴

리스를 배치하는 것과 성격이 다르다.

새 소프트웨어 릴리스를 이용해서 어떤 환경을 업그레이드하는 공정을 코드 투입(code

push )이라고 부른다. 실무 환경에 코드를 투입한다는 것은 실행 중인 시스템을 수정하는 것인

데, 이는 쉽지 않은 일이다. 마치 고속도로를 시속 90km로 달리는 차의 바퀴를 가는 것과 비

슷하다. 불가능하지는 않지만, 계획을 잘 세워서 세심하게 수행해야 한다.

다행한 일은, 다양한 상황에 맞는 여러 가지 기법들이 존재한다는 것이다. 이번 장에서는

가장 흔히 쓰이는 기법들을 종류별로 소개한다. 그런 다음에는 지속적 배치 같은 모범 관행들

과 기타 실천 사항들을 논의한다.

11.1 서비스 중단 후 업그레이드

서비스를 업그레이드하는 한 가지 방법은 서비스를 내리고(중단하고), 모든 새 시스템에 새

코드를 투입하고, 서비스를 다시 가동하는 것이다. 이 방법의 장점은 구현이 아주 간단하다는

활성 서비스의 업그레이드

CHAPTER 11

304 11장 활성 서비스의 업그레이드

것과 실제 사용자가 새로 업그레이드된 서비스에 접근하기 전에 서비스를 검사해 볼 수 있다는

것이다.

안타깝게도 이 방법에서는 필연적으로 비가동시간(downtime )이 발생하는데, 대부분의

서비스에서는 그러한 비가동시간이 허용되지 않는다. 그러나 예정된 비가동시간을 허용하는

개발 환경이나 시연 환경에는 이 방법을 적용할 수 있다. 서비스 대체

이 기법은 또한 기존 서비스를 완전히 다른 서비스로 대체할 때에도 유용하다. 예비 수용

량이 충분하다면, 서비스 복제본들을 각각 하나씩 중단하고, 업그레이드하고, 다시 시동하면

된다. 이 경우 전역 부하 분산기(GLB )가 소통량을 작동 중인 복제본들에 분산한다. GLB에서

복제본들을 한 번에 하나씩 제거해서 배출하는(drain ) 과정을 대기 중인 모든 요청이 완료될

때까지 반복한다. 그런 다음에는 서비스에 영향을 주지 않고도 복제본을 종료할 수 있다.

구글 블로그 검색 업그레이드

톰이 구글의 ‘블로그 검색’ 서비스의 한 사이트 신뢰성 기술자였던 시절의 이야기이다. 톰은 네

개의 데이터센터에서 고객을 향한 스택을 복제해야 했다. 각 복제본은 서로 독립적이었다. 예비

수용량이 넉넉했기 때문에 한 스택을 중단해도 나머지 세 스택이 전체 소통량 부하를 처리할 수

있었다. 톰은 스택들을 한 번에 하나씩 GLB에서 빼서 배출하고, 업그레이드하고, 점검하고, 다

시 GLB에 추가했다.

한편, 블로그 검색 시스템에는 ‘파이프라인’이라는 부분이 있었다. 파이프라인은 새 블로그 글

들을 훑어서 수집하고, 새 말뭉치를 산출하고, 그 말뭉치를 앞에서 말한 네 개의 고객을 향한 스

택들에 분산했다. 이 파이프라인은 전체 서비스에 아주 중요한 요소였지만, 가동을 중단한다고

해도 고객들이 눈치채지는 못했다. 물론 파이프라인의 비가동시간이 길면 검색 결과의 신선함이

떨어진다. 결론적으로, 파이프라인의 가동시간이 중요하긴 하지만 필수적인 것은 아니며, 그래

서 파이프라인을 업그레이드할 때에는 파이프라인 전체를 중단했다.

구글의 다른 여러 서비스도 이와 비슷한 구조이며, 이와 비슷한 패턴으로 업그레이드된다.

11.2 순회식 업그레이드

순회식 업그레이드(rolling upgrade)는 개별 기계나 서버를 서비스에서 제거하고, 업그레이드

하고, 다시 서비스에 넣는 과정을 시스템의 모든 구성요소가 업그레이드될 때까지 반복하는 것이

30511.2 순회식 업그레이드

다. 즉, 공정은 모든 요소를 순회하면서(roll through) 시스템 전체의 업그레이드를 수행한다.

개별 요소의 중단을 지역 부하 분산기가 감추기 때문에, 서비스 자체는 고객들에게 계속

제공된다. 업그레이드 도중 어떤 고객들은 새 소프트웨어를 접하지만, 그 외의 고객들은 여전

히 기존 소프트웨어를 접한다. 일련의 요청들이 새 기계와 기존 기계로 전달됨에 따라, 새 기능

이 나타났다 사라지는 모습을 보는 고객도 생길 수 있다. 그러나 §4.2.3에서 말한 부하 분산기

의 접착성과 §2.1.9에서 말한 새 기능 배치 켜고 끄기 같은 기타 요인들 때문에, 이런 일이 일

어나는 경우는 드물다.

업그레이드 도중에 수용량이 일시적으로 감소할 수 있다. 서버가 10대일 때, 그중 하나의

서비스를 업그레이드하는 도중에는 수용량이 평소의 90%가 된다. 따라서 이 기법은 수용량이

충분한지 확인한 후에 적용해야 한다.

순회식 업그레이드 공정은 다음과 같이 진행된다. 우선 서버 또는 기계 하나를 배출한다.

좀 더 구체적으로 말하면, 부하 분산기가 그 기계에 요청을 보내지 않도록 재설정하거나, 복제

본이 §2.1.3에서 설명한 ‘레임덕 모드’로 들어가게 한다. 레임덕 모드에서 복제본은 부하 분산

기에게 자신의 건강이 좋지 않다는 ‘거짓’ 보고를 보낸다. 그러면 부하 분산기는 그 복제본에게

요청을 보내지 않는다. 잠시 시간이 지나면 그 복제본에는 아무런 요청도 전달되지 않으며, 기

존에 받은 요청들의 처리도 모두 끝난다. 그때가 되면 서비스를 중단해서 새 릴리스로 업그레

이드한 후 업그레이드가 잘 되었는지 점검하고, 앞의 배출 과정을 역으로 수행한다. 이상의 과

정을 다음 서버 또는 기계에 대해 반복한다.

졸릴 때에는 코드 투입을 피하라

코드 투입은 낮에 하는 것이 최선이다. 낮에는 정신이 말짱하며, 뭔가 잘못되었을 때 도와줄 동

료들도 주변에 많이 있다.

코드 투입을 아주 늦은 밤에 하는 조직들이 많다. 업그레이드를 새벽 세 시에 하는 데 대한 전형

적인 변명은, 업그레이드에는 위험이 따르므로 사용자 노출이 적은 밤에 하는 것이 좋다는 것이다.

그러나 졸린 상태에서 중요한 업그레이드를 수행하는 것이 훨씬 더 위험하다. 아마 이제는 독

자도 동의하겠지만, 이상적으로는 검사를 자동화하고 작은 크기의 일괄 단위들을 사용하는 것이

위험을 줄이는 데 가장 좋은 전략이다.

아니면 주된 서비스 장소에서 동쪽으로 여덟 시간만큼 떨어진 시간대에 있는 팀이 코드 투입

을 수행하게 할 수도 있다. 그러면 고객들은 아직 한밤중이지만 그 팀은 이미 해가 뜬 상태에서

배치를 수행하게 된다.


11.3 카나리아 공정

카나리아 공정(canary process )은 순회식 업그레이드의 한 특별한 형태로, 많은 수의 요소

들을 업그레이드할 때 좀 더 적합하다. 수백, 수천 대의 서버나 기계를 순회식으로 업그레이드

하면 오랜 시간이 걸릴 수 있다. 서버 하나에 10분이 걸린다면 서버 1,000대에는 한 주가 걸린

다. 이는 감당할 수 없는 수준이다. 그렇다고 모든 서버를 동시에 업그레이드하는 것은 너무 위

험하다.

카나리아 공정에서는 일단 아주 적은 수의 복제본들을 업그레이드해서 두드러진 문제점이

발생하지 않는다면 점점 더 많은 수의 기계들을 업그레이드해 나간다. 예전에는 광부들이 카나

리아 새들을 새장에 넣어서 탄광에 들어갔다. 카나리아는 해로운 기체에 사람보다 훨씬 민감하

다. 카나리아가 이상하게 행동하거나 횃대에서 떨어진다면 유독한 기체에 중독될 위험이 있으

므로 빨리 탄광을 빠져나가야 한다.

그와 비슷하게, 카나리아 공정은 적은 수의 기계를 카나리아로 삼아서 업그레이드해 본다.

대체로 문제점은 업그레이드 후 5분에서 10분 사이에 발생한다. 만일 카나리아가 그보다 더 오

래 살아남는다면 더 많은 수의 기계들을 업그레이드해본다. 역시 일정 시간 기다리고 여러 가

지 검사를 수행해서, 결과가 성공적이면 더욱 많은 수의 기계들을 업그레이드한다.

흔히 쓰이는 방식은 다음과 같다: 서버 한 대를 업그레이드한 후, 분당 서버 한 대의 속도

로 서버 수를 늘려나간다. 업그레이드된 서버가 전체 서버의 1%에 도달하면 그때부터는 초당

한 대의 속도로 수를 늘린다. 각 그룹 사이에 지연 시간이 길어질 수도 있다. 그런 경우에는 업

그레이드된 모든 서버에 대해 검증 검사를 수행한다. 일반적으로 이 검사들은 아주 단순한 형

태이다. 보통은 그냥 코드가 충돌하지는 않았는지, 활성 질의들에 대한 응답이 제대로 반환되

는지만 확인한다.

만일 카나리아가 죽으면(즉, 문제점이 발견되면) 공정을 멈춘다. 그런 다음 업그레이드된

서버들을 다시 이전 버전으로 되돌리면 될 것이다. 혹은, 만일 수용량이 넉넉하다면, 문제점을

해결한 새 릴리스가 나올 때까지 서버들을 종료시켜 둘 수도 있다.

카나리아 공정은 검사 공정이 아니다. 카나리아 공정은 하나의 릴리스를 실무 환경에 배치

하되 잘못된 코드 투입을 일찍 검출해서 문제점이 사용자에게까지 드러나게 하지 않는 방법이

다. 검사 공정과 카나리아 공정의 주된 차이점은, 검사 공정에서는 실패가 허용된다는 점이다.

검사 공정이 실패했다는 것은 잘못된 릴리스가 활성 사용자들에게까지 도달하는 사고를 미리

방지했다는 것이다. 좀 더 현학적으로 말하자면, 검사 공정 실패는 결함 있는 릴리스의 검출 성

30711.3 카나리아 공정

공이며, 이는 좋은 일이다.

반면 카나리아 공정의 실패는 진짜 실패이며, 나쁜 일이다. 카나리아가 죽었다는 것은 검

사 공정에서 뭔가 놓친 것이 있다는 뜻이다. 카나리아 공정의 실패는 드문 일이어야 한다. 카나

리아가 실패하면 개발을 멈추고, 무엇이 잘못되었고 이후 같은 실패가 반복되지 않으려면 어떤

검사를 추가해야 하는지에 대해 개발 자원을 투여해야 하기 때문이다. 그런 노력이 완료된 후

에야 새로운 롤아웃을 시작할 수 있다. 카나리아 공정은 나쁜 릴리스를 검출하는 수단이 아니

라, 나쁜 릴리스가 실수로 실무 환경에 배치되는 사고를 대비한 보험이라 할 수 있다.

검사와 카나리아 공정을 섞어서 사용하는 경우가 많은데, 그러면 안 된다. 말은 카나리아

공정이지만 실제로는 활성 사용자들을 대상으로 새 릴리스를 검사하는 것인 경우도 있다. 검사

는 검사 환경에서 해야지, 실제 사용자들을 대상으로 하면 안 된다.

카나리아 공정은 시스템 검사를 대신하는 것이 아니다

우리 필자들은 카나리아 공정을 활성 사용자들에 대해 릴리스를 검사하는 목적으로 사용하는 상

황을 겪어보았다. 한 사례에서는 의도하지 않게 그런 일이 벌어졌다. 이후 큼직한 가동 중단 사

태가 벌어지고서야 그 사실을 깨달았다. 당시 SRE 기술자들은 상세히 검사된 패키지를 받아서,

카나리아 공정을 통해 자신의 실무 환경에 그 패키지를 배치했다. 검사 환경과 활성 환경이 아주

비슷했기 때문에 몇 년간 별문제가 없었다.

그러나 시간이 지나면서 SRE 기술자들이 개발한 여러 도구가 실무 환경에서 쓰이게 되었다.

그 도구들은 개발자의 검사 시스템에서 검사하지 않은 것들이었다. 개발자들은 그 도구들에 대

해 책임을 지지 않았으며, 도구 중 다수를 일시적이거나 임시방편적인 수단으로 간주했다.

공학에는 “임시적인 해결책만큼 영구적인 것도 없다”라는 오래된 격언이 있다. 얼마 지나지

않아 그런 도구들이 점점 늘어나서 하나의 복잡한 자동화 시스템을 형성했다. 그렇지만 그 도구

들이 개발자의 검사 시스템으로 검사하지 않는 것들이라는 사실에는 변함이 없었다. 주요 릴리

스가 나올 때마다 도구들과의 충돌이 일어나서 운영팀은 급히 도구들을 갱신해야 했다. 그러나

이런 문제들은 그다음에 발생한 일에 비하면 사소했다.

하루는 릴리스 하나를 실무 환경에 투입했는데, 투입이 다 끝난 후에야 문제점이 발견되었다.

특정 사용자들에 대한 서비스가 가동을 멈춘 것이었다.

당시 두 환경에 쓰이던 하드웨어들은 해당 커널 구동기(드라이버)와 가상화 기술의 버전들

이 다를 정도로 차이가 컸다. 이 때문에 특정 운영 체제에서 실행되던 가상 기계들이 작동을 멈

추었다.


그 시점에 이르러서야 SRE 기술자들은 환경의 차이가 너무 벌어졌음을 깨달았다. 그들은 주

서비스 릴리스와 커널 버전, 가상화 프레임워크 버전, 그리고 실무 환경에 쓰이는 하드웨어의 특

정 조합을 검사할 수 있도록 시스템 검사 환경을 완전히 개편해야 했다. 또한, 매번 자신이 개발

한 도구들과의 호환성 문제를 고치느라 고생하지 않기 위해, 자신의 도구들을 저장소와 개발 공

정 및 검사 공정에 포함해야 했다.

이처럼 적절한 시스템 개발 환경을 만들고 검사 환경과 실무 환경의 동기화를 유지하는 메커

니즘을 도입하는 데는 수개월의 노력이 필요했다.

11.4 국면별 롤아웃

또 다른 전략은 사용자들을 여러 그룹으로 나누고 그 그룹들을 한 번에 하나씩 업그레이드하는

것이다. ‘국면(phase )’이라고도 부르는 그룹들은 위험에 대한 내구성을 기준으로 구분한다.

예를 들어 페이스북Facebook에는 자사 직원들을 위한 서비스를 제공하는 데에만 쓰이는 클

러스터들이 있다. 그 클러스터들은 가장 먼저 업그레이드되는데, 이는 자사 직원들이야말로 새

릴리스의 열성적인 검사자들이기 때문이다. 시스템 검사는 업무의 일부이다. 그다음에는 소수

의 외부 사용자들에 해당하는 클러스터들을 업그레이드하고, 마지막으로 나머지 클러스터들을

업그레이드한다.

Stack Exchange의 업그레이드 공정은 여러 국면으로 진행된다. Stack Exchange에는

110개 이상의 웹 공동체가 있으며, 여기에 더해 각 공동체에는 공동체 자체에 대한 논의를 위

한 메타 공동체가 있다. 그 모든 공동체는 동일한 소프트웨어를 사용하나, 웹 페이지를 구성하

는 색상과 디자인은 각자 다르다. 업그레이드 국면들은 순서대로 검사 환경, 메타 공동체들, 사

용자 수가 적은 공동체들, 마지막으로 가장 크고 활성화된 공동체들이다. 각 국면은 이전 국면

에서 일정 기간 문제가 발생하지 않으면 자동으로 업그레이드를 시작한다. 업그레이드가 마지

막 국면에 도달했다면, 해당 릴리스는 아주 믿을만한 것이다. 앞쪽 국면들일수록 여러 가지 이

유로 가동 중단에 대한 내구성이 높은데, 수익을 발생하는 단위가 아니라는 사실도 한 가지 이

유이다.

30911.6 청록 배치

11.5 비례식 차단

비례식 차단(proportional shedding )은 기존 서비스와 병렬적으로 새 서비스를 새 기계에

구축하는 배치 기법이다. 그런 다음에는 소통량의 작은 부분을 새 서비스에 보낸다. 그것이 성

공하면 더 큰 부분을 보낸다. 이러한 과정을 모든 소통량이 새 서비스로 갈 때까지 반복한다.

비례식 차단은 한 시스템의 소통량을 다른 시스템으로 보내는 데 사용할 수 있다. 전체 공

정이 완료될 때까지는 기존 클러스터를 종료하지 않는다. 만일 문제점이 발견되면 부하를 다시

기존 클러스터로 보낼 수 있다.

이 기법의 문제점은, 소통량 이전이 완료될 때까지는 두 배의 수용량이 필요하다는 것이

다. 만일 한 대의 기계에서 서비스를 실행한다면, 업그레이드 동안 두 대의 기계를 돌리는 것은

그리 큰 부담이 아니다.

그러나 기계가 1,000대이면 비례식 차단의 비용이 아주 커질 수 있다. 예산상의 문제로 업

그레이드를 위해 1,000대의 예비 기계를 마련하기가 불가능할 수 있다. 그런 경우 한 가지 방

법은, 소통량의 일정 비율이 새 클러스터로 간 후에는 기존 기계들을 새 클러스터에 포함해서

재활용하는 것이다.

11.6 청록 배치

청록 배치(blue-green deployment )는 비례식 차단과 비슷하되 두 배의 자원을 필요로 하지

않는다. 이 방법에서는 같은 기계에 ‘청색’ 환경과 ‘녹색’ 환경이라고 부르는 두 개의 환경을 둔다.

녹색이 현재 활성 환경이고 청색은 아직 쓰이지 않는 환경이다. 두 환경을 같은 기계에 두는 방

법은 다양한데, 가장 간단한 방법은 그냥 둘을 서로 다른 하위 디렉터리에 두고 각각을 같은 웹

서버의 서로 다른 가상 호스트로 사용하는 것이다. 청색 환경은 자원을 아주 조금만 소비한다.

업그레이드 방법은 간단하다. 새 릴리스를 청색 환경에 배치하고, 소통량을 청색 환경으로

돌리면 된다. 그런 다음에는 환경들의 이름을 맞바꾼다. 이 방법에서는 이전 환경으로 돌아가

는 것이 간단하다.

청록 배치는 가동 중단 없이 배치할 수 있도록 설계되지는 않은 응용 프로그램의 비가동시

간을 0으로 만드는 아주 간단한 방법이다. 물론 이 방법은 응용 프로그램을 같은 컴퓨터의 서

로 다른 장소들에 설치할 수 있는 경우에만 적용할 수 있다.

537A.1 정규 과제

부록

Part

III

538 부록 A 평가

APPENDIX A 평가

APPENDIX B 분산 컴퓨팅과 클라우드의 기원과 미래

APPENDIX C 규모 변화 관련 용어 및 개념

APPENDIX D 문서 양식과 예제 문서

APPENDIX E 읽을거리 추천

Part III

부록


이 부록은 여러 운영 책무(operational responsibility )들에 대한 평가 질문들과 징표들을

제공한다. 제20장 “탁월한 운영”은 이 부록의 활용 매뉴얼에 해당한다. 특히 §20.7에 평가 체

계의 도입과 적용에 관한 조언이 있다.

평가 수준들

수준 1 초기/혼돈 임시방편적, 개인의 영웅적인 노력에 의존

수준 2 반복 가능 공정을 반복해서 같은 결과를 얻을 수 있음

수준 3 정의됨 임무들이 정의/확인됨

수준 4 관리됨 측정을 수치적으로 관리함

수준 5 최적화 의도적인 최적화/개선

핵심 운영 책무

페이지 운영 책무 관련 장

540 정규 과제 12, 14

543 비상 대응 6, 14, 15

545 감시와 측정 16, 17, 19

548 수용량 계획 수립 18

550 변경 관리

평가

APPENDIX A

540 부록 A 평가

552 신제품 도입 및 제거

554 서비스 배치 및 폐지

556 성능과 효율성

추가적인 운영 책무

페이지 운영 책무 관련 장

559 서비스 인도: 구축 국면 9

561 서비스 인도: 배치 국면 10, 11

563 고역 줄이기 12

565 재난 대비 15

A.1 정규 과제

정규 과제(regular task, RT ) 운영 책무는 비상이 아닌 보통의 임무들을 처리하는 방식, 즉

조직이 작업을 받아서 대기열에 등록하고, 분산하고, 처리하고, 검증하는 방식에 관한 것이다.

또한, 주기적인 과제들의 일정을 정하고 실행하는 과정도 여기에 포함된다. 모든 서비스에는

어떤 종류이든 보통의, 예정된 또는 예정되지 않은 작업이 존재한다. 대체로 웹 운영팀은 고객

지원 임무를 직접 수행하지 않지만, 팀 간 요청이나 이해관계자의 요청, 그리고 직접적인 고객

지원 팀이 위임한 요청들은 처리해야 한다. 이 주제들은 제12장과 제14장에서 다룬다.

평가를 위한 질문의 예

● 흔하고 주기적인 운영 과제들과 임무들은 무엇인가?

● 흔한 운영 임무들에 대한 각본(대응 매뉴얼)이 있는가?

● 정규 요청들에 대한 SLA는 무엇인가?

● 각본에 새 항목을 추가해야 할 필요성을 어떻게 식별하는가? 새 항목을 추가하거나 기존

항목을 수정하는 사람은 누구인가?

● 사용자의 요청을 어떻게 받고 어떻게 관리하는가?

● 사용자들이 흔히 제출하는 요청들에 대한 각본이 있는가?


● 각본에 없는 사용자 요청이 얼마나 자주 들어오는가?

● 사용자들이 우리의 지원을 받는 방법은 무엇인가?

● 우리의 지원을 받는 방법을 사용자들이 어떻게 알게 되는가?

● 우리가 지원하는/하지 않는 사항들을 사용자들이 어떻게 알게 되는가?

● 지원하지 않는 사항에 대한 지원 요청을 어떻게 처리하는가?

● 정규 지원의 한계(업무 시간, 원격 또는 현장)는 무엇인가? 그러한 한계들을 사용자들이

어떻게 알게 되는가?

● 크기에 따른 범주들을 각자 다른 방식으로 처리하는가? 크기 범주들은 어떻게 결정하는가?

● 만일 이 운영 책무에 대한 기업 표준 관행이 있다면, 그것이 무엇이고 이 서비스가 그 관행

을 얼마나 잘 준수하는가?

수준 1: 초기

● 각본이 없거나 오래되고 쓰이지 않는다.

● 결과들에 일관성이 없다.

● 사람마다 과제를 다른 식으로 수행한다.

● 같은 것을 요청한 두 사용자가 서로 다른 결과를 얻는 경우가 많다.

● 공정들이 문서화되어 있지 않다.

● 팀은 자신이 수행하는 모든 공정을 나열하지 못한다(심지어 개략적으로도).

● 요청들이 유실되거나 무기한 지연된다.

● 조직이 흔한 과제들을 완료하는 데 걸리는 시간을 예측하지 못한다.

● 운영상의 문제가 보고되어도 관심을 받지 못한다.

수준 2: 반복 가능

● 팀이 지원하는 서비스들의 목록이 명확하게 정의되어 있다.

● 종단간(end-to-end ) 공정마다 공정의 모든 단계와 그 의존관계들이 명시되어 있다.

● 종단간 공정마다 각 단계의 처리 절차가 문서화되어 있다.

● 서로 다른 사람들이 같은 과제를 같은 방식으로 수행한다.

● 안타깝게도, 작업흐름에 노력의 중복이 어느 정도 존재한다.

● 안타깝게도, 여러 과제에 쓰이는 정보를 해당 단계들이 각자 다시 생성한다.

542 부록 A 평가

수준 3: 정의됨

● 대부분의 요청에 대해 SLA가 정의되어 있다. 다만, 팀이 그것을 항상 지키지는 않는다.

● 단계마다, 작업을 다음 단계로 넘기기 전에 반드시 만족해야 할 QA (품질보증) 점검목록

이 있다.

● 한 팀의 공정 변경들을 다른 팀들이 미리 알게 된다.

● 여러 단계에 필요한 정보를 한 번만 생성한다.

● 노력의 중복이 없거나 최소한이다.

● 새 수용량을 마련하는 공정이 반복 가능한 공정이다.

수준 4: 관리됨

● 정의된 SLA를 측정한다.

● 모든 단계에 피드백 메커니즘이 있다.

● 결함들과 재작업들을 주기적으로(매주?) 검토한다.

● 사후 분석 보고서를 모두가 볼 수 있도록 공개한다. 보고서 초안은 x시간 이내에 공개하고,

최종 보고서는 y일 이내에 완성한다.

● 경보들에 영향을 받은 팀들이 경보들을 주기적으로 검토한다. 여러 직무를 포괄하는 연합

팀이 경보들을 주기적으로 검토한다.

● 공정 변경을 요청하려면 문제 해결 정도를 측정할 수 있는 자료가 있어야 한다.

● 현황판이 자료를 사업상의 용어로 보고한다(전문 기술 용어가 아니라).

● 모든 ‘장애 조치 절차’에는 ‘마지막으로 적용된 날짜’ 현황판이 있다.

● 추가 수용량을 그에 대한 수요가 발생하기 전에 예측한다.

수준 5: 최적화

● 프로세스를 변경한 후에는 이전/이후 자료를 비교해서 성공 여부를 판정한다.

● 만일 이전/이후 자료로 보았을 때 개선된 것이 없다면, 변경된 공정을 이전으로 되돌린다.

● 수행된 공정 변경들의 출처가 다양하다.

● 최근에, 모든 단계에서 적어도 하나의 공정 변경이 있었다.

● 주기를 한 달로 둔 덕분에 공정의 개선이 원활하다.

● 실제 운영에서 추출한 자료로 만든 ‘가정(what if )’ 시나리오에 기초해서 결정을 내린다.

543A.2 비상 대응

A.2 비상 대응

비상 대응(emergency response, ER; 또는 긴급 대응) 운영 책무는 가동 중단과 재난을 처

리하는 방식에 관한 것이다. 여기에는 가동 중단 도중(대응)과 이후(개선)에 수행하는 기술적

공정 및 비기술적 공정들이 포함되며, 가동 중단을 방지하기 위한 시스템 탄력성 요소들도 포

함된다. 이 주제들은 제6, 14, 15장에서 다룬다.

평가를 위한 질문의 예

● 가동 중단을 어떻게 검출하는가? (자동 감시를 통해서? 사용자의 불평을 통해서?)

● 일반적인 장애 조치 시나리오들과 가동 중단 관련 임무들에 대한 각본이 존재하는가?

● 호출대기 일정표가 있는가?

● 호출대기 일정표를 어떻게 작성하는가?

● 시스템이 지역 수준의 장애(구성요소 고장)를 견디는가?

● 시스템이 전역(지리적) 수준의 장애를 견디는가(데이터센터 교체 등)?

● 팀원들이 지리적으로 분산되어 있는가? (즉, 한 지역이 일정 기간 이상 다른 지역의 업무

를 대신할 수 있는가?)

● 사후 분석 보고서를 작성하는가? 보고서 완성 마감 시간이 있는가?

● 사후 분석 보고서를 위한 표준 양식이 있는가?

● 사후 분석 보고서에 제시된 행동 항목들이 완료되었는지를 나중에 다시 검토하는가?

● 만일 이 운영 책무에 대한 기업 표준 관행이 있다면, 그것이 무엇이고 이 서비스가 그 관행

을 얼마나 잘 준수하는가?

수준 1: 초기

● 가동 중단을 감시 시스템이 아니라 사용자들이 보고한다.

● 호출대기자가 아예 없거나, 같은 사람이 항상 호출대기 중이거나, 모든 사람이 항상 호출대

기 중이다.

● 호출대기 일정을 미리 정해두지 않는다.

● 호출대기 일정을 일정표(calendar ) 형태로 만들어 두지 않는다.

● 다양한 경보에 대해 해야 할 일을 명시한 각본이 없다.

찾아보기626

INDEX

숫 자

1% 검사 312

1차 자원 472, 479

2단계 수신 확인 460

2의 거듭제곱 170

2차 자원 479

30일 활성 사용자 수(30-day actives, 30DA) 481

3층 웹 서비스 122

장점 128


앞단 130

응용 프로그램 서버 132

7일 활성 사용자 수(7-day actives, 7DA) 481

ㄱ

가동 중단 432

가상 기계 102

단점 105

모니터 104

설치 296

입출력 104

자원 공유 105

장점 103

가상 사무실 237

가상화 104

가시성 45

가시화 ☞ 시각화

가용성 57, 213

가정 분석 169

가중 라운드로빈 125

가치 스트림 247, 251

각본 88, 221

감독 서버 140

감독-일꾼 관계 59

감사 226

감시 85, 227, 333, 431

관점 433

대리자 455

대상 437

소비자 435

용도 434

프로토콜 454

감시 시스템

감시 441

구성 정보 468

구조 447

감시 자료

시각화 462

유지 439

감시견 타이머 193

감시와 측정(MM) 운영 책무 518, 545

감옥 107

감지 및 측정 시스템 448

개발운영 241

3대 방법 247

개선 255

관계 254, 260

국면 271

기술적 관행들 257

릴리스 공학 259

비기술적 관행 256

실험과 학습 249

역사 252

자동화 255

작업흐름 247

전환 260

접근방식 246

조직 구성 261

통합 254

피드백 개선 248

DevOps Days 콘퍼런스 252

개발자 호출대기 378

개선 수준 528

개시 224, 225

약한 214, 492

위원회 225

은밀한 313, 492

627찾아보기

자급식 228

점검 목록 226

책임자 227

개시 준비

검토 228

기술자 225

개요 366

개인 훈련 408

개인용 모래상자 273

개인정보 110

개정 번호 366

건강 점검 47, 290

검사

1% 312

단위 279, 355

릴리스 291

배치 국면 292

부하 292, 480

사용자 인수 101, 224, 293

성능 292

시스템 279, 292, 307

연기 266

장애 복구 414

재난 대비 411

재현성 318

진단 266

철자 62

카나리아 공정 306

포괄도 318

A-B 312

TDD (검사 주도적 개발) 355

게임 데이 257

실습 413

격리성 61

결과적 일관성 58

결재 라인 291

결합 인지 시스템 330

경보 233, 376, 383, 434

검토 398

규칙 456, 461

금지 461

로그 398

로그 꼬리표 398

메시지 458

문턱값 93

범람 460

비활성화 461

빈도 380

소음 460

수신 확인 459

심각도 398

원인 398

전달 과정 459

전달 수단 384

줄이기 399

처리 임무 388

키워드 398

현황판 385

경보 및 상부 보고 시스템 448, 458

경영진 지원 372

경향 434

변화 489

계산 결과 캐싱 165

계승 규모 변화 599

계정 관리 300

계측치 측정 451

계층 3 및 계층 4 부하 분산기 124

계층 7 부하 분산기 124

계통적 구획화 161

계획된 성장 473, 476

고객 234, 248

기능성별 구획화 161

티켓 시스템 351

고속 네트워크 카운터 451

고역 236, 326, 341

비상 341

고역 줄이기 341

평가 563

찾아보기628

INDEX

고장 44

구성요소 195

기계 198

네트워크 인터페이스 197

단일 고장 지점 200

데이터센터 202

랙 201

메모리 185

부품 195

선반 201

욕조 고장 곡선 198

전원 공급장치 196

컴퓨터 198

평균 무고장 시간 180

하드 디스크 196

RAM 195

고체 상태 드라이브(SSD) 65

공개키 기반구조 83

공격면 면적 131

공급망 관리 494

공급업체 92

감금 101

서드파티 92

지원 392

공급자 전문 지식 114

공동입주 112

공보관 424

공용 클라우드 109

공유 상태 부하 분산 126

공유 풀 204

공정

메타 223

사람 256

자동화 282

제거 223

종단간 255

최적화 251

카나리아 306

공지 238

공통 운영 책무 518

공통의 경우 221

공평한 대기열 적용 174

공황 191

과부하 장애 203

관계형 데이터베이스 60

관리됨 수준 520

관문 270, 278, 290, 293

관점 433

관행 39

교대근무 38, cf. 호출대기

교대 전 임무 386

마감 보고서 235, 392

준비 점검 목록 386

구글

기계 학습 서비스 100

데이터센터 179

문서 184

블로그 검색 업그레이드 304

스타일 지침 354

애드센스 586

앱스 우아한 강등 82

앱엔진 99

자급식 서비스 개시 228

장애 복구 검사 414

카나리아 요청 194

캘린더 서비스 382

ACL 84

Chubby 311, 412

DiRT 415

Ganeti 338

GFS 587

Omega 75

PageRank 599

PubSub2 141

SRE 모형 253

Thialfi 141

구글 오류 예산 ☞ 오류 예산

구글 지도 139

629찾아보기

지역 업체 목록 85

구내 설치/외부 운영 서비스 115

구독자 140

구름 95

구성 73, 289

감시 시스템 468

개발운영 조직 261

배치 국면 289

설계 문서 365

자동화 컴퓨터 334

저장소 448

전략 290

텍스트 파일 73

파일 버전 관리 352

패키지 299

N + 1 577

N + 2 577

구성 관리(CM) 290, 297, 346

데이터베이스 301

언어 346

구성요소

고장 195

재공학 153

구워진 이미지 297

구축 269

건강 상태 318

도구 333

수동 283

자동화 333

콘솔 281

구축 공정 버전 관리 265

구축 국면 269

개발 277

구축 279

단계들 277

등록 280

지속적 통합 282

커밋 278

패키지 280

평가 559

구획화 160

국면 269, 308

국면별 롤아웃 308

권한 부여 300

규모 598

증가 155

확장 155

규모 변화 151, 597


계승 599

닷컴 붕괴 시대 582

데이터베이스 79

로그 599

상수 598, 599

선형 598, 599

수작업 공정 220

수평 157

웹 이전 시대 572

전략 152

제1차 웹 시대 575


제곱 599

지수 598, 599

클라우드 컴퓨팅 시대 592

탄력성 199

AKF 입방체 156

규모가변성 151, 597

규모의 경제 569, 591

규제 333

극단적 경우 221

근무 시간 외 유지보수 386

근미래 분석 457

근본 원인 분석 396

기계 44, cf. 가상 기계

고장 198

단명, 박명 103

물리적 102

기계 학습 서비스(구글) 100

찾아보기630

INDEX

기능

기능별 분할 158

요청 90

켜고 끄기 81

기대 영향 90

기반구조 자동화 295

기본 방침 83

기술 채무 236

기업 비상 통신 계획 416

기여 조건 분석 396

기하이동평균 473

기호 링크 346

기회비용 114, 333

길버트, S. 60

깁슨, 윌리엄 516

깔대기 140

꼬리표 285, 288

끈적한 연결 126

ㄴ

내구성 61

내부 기간망 136

내성 45

내용 배포 서버 137

내용 전달망 ☞ CDN

네트워크

고속 카운터 451

소프트웨어로 정의되는 593

위상구조 141

인터페이스 고장 197

저장 영역 298

주소 변환 127

지연 64

넷플릭스 105

유인원 군대 412

Aminator 297

녹색 환경 309

느린 시작 알고리즘 48

느슨히 결합된 시스템 62

능동-수동 188

쌍 197

능력 성숙도 모형 ☞ CMM

능력 측정 450

능률화 222

닐슨, 제리 303

ㄷ

다대다 통신 139

다대일 통신 140

다수의 뒷단 49

다양성 435

다중 스레드

단점 173

장점 173

다중 입주 358

Puppet 359

다중 자료 저장소 128

다중 프로세스 174

단기 분석 457

단명 기계 103

단명 컴퓨팅 114

단방향 호출기 385

단순함 46

단위 검사 279, 355

단일 고장 지점 200

단일 기계 웹 서버 120

단일 스레드 단점 172

닷컴 거품 573

닷컴 붕괴 시대

가용성 요구사항 579

규모 변화 582

기술 579

높은 가용성 581

비용 584

시대 579

응용성 584

자료 규모 변화 583

당기기 453

631찾아보기

당직대기 378

대규모 시스템 가시성 45

대규모 운영 220

대기열 173

메시지 140

배출 76

서비스 140

작업 공급 173

대기열 적용 173

공평한 174

장점 174

대문자 O 표기법 598

한계 601

대응 매뉴얼 88

대화방 237

봇 385

데이터베이스

규모 변화 79

데이터베이스 주도적 동적 내용 120

동기화 142

뷰 314

데이터센터 고장 202

도구 구축 333

자동화 333

도구사슬 257

도둑맞은 시간 105

도어, 존 499

도입 제어 84

도킨스, 리처드 597

동적 내용 120

동적 롤백 312

두봉우리 패턴 466

뒷단 47

복제본 47

디버깅 계장 86

디스크 접근 64

딕슨 모형 435

따뜻한 캐시 165

땜질 266

또 다른 눈들 356

ㄹ

라운드로빈 47

가중 125

부하 분산 125

DNS 123

랙

고장 201

국소성 201

다양성 201

랙 범위 복제본 202

레임덕 모드 76, 305

로그(기록) 45, 442

로그 규모 변화 599

로그선형 규모 변화 599

로이스, D. W. W. 245

롤백 320

롤포워드 320

루스벨트, 시어도어 403

루스벨트, 프랭클린 D. 363

리치, 에이미 95

리팩터링 153

린치, N. 60

릴리스 270, 291

검사 291

공학 259

승인 291

승인 절차 294

원자성 321

일자 조정 311

후보 270

링크 단축 사이트 142

ㅁ

마스터-슬레이브 188

막힌 수용량 102

막힌 자원 107

찾아보기632

INDEX

만리방화벽 177

말뭉치 52

맞춤형 운영 216

매클린, 맬컴 109

맥헨리 기법 314

맥헨리, 스티븐 314

맵리듀스 587

멈춤 192

메시지

대기열 140

문자 385

중개자 140

메시지 버스

구조 139

설계 141

신뢰성 141

메시지 수신

보장 141

순서 142

메타 감시 441

메타 공정 223

메타 작업 232

메타자료 433

모바일 앱 590

모형 개선 93

목표

대립 509

통합 510

무정전 전원 장치 75

문서 보관소 369

문서 양식 368, 605

사후 분석 보고서 608

설계 문서 368, 605

문서화 88, 227, cf. 설계 문서

과거 의사결정 365

변경과 그 논거 364

수리의 날 236

문자 메시지 385

문제점

명명 표준 350

추적 시스템 349

물리적 기계 102

클라우드 116

물리적 장애 194

미국 대통령 선거 419

미국 연방재난관리청 424

미달예약, 미달구독 97

미래 보장 357

밀기 453

밀집 51

ㅂ

바로소, L. A. 194, 197, 440, 585, 589

박명 기계 103

반복 가능 수준 520

반취약 404

발동 조건 456

발행 구독 미들웨어 140

발행-구독 서비스 140

발행자 140

방송 140

배출 76

도구 338

배치 269

빈도 276

배치 국면 269, 287

검사 292

구성 289

단계 288

설치 289

승격 288

운영 콘솔 294

평가 561

백분위수 463

백업 77

버그

격리 312

버그 보고 대 기능 요청 349

633찾아보기

소요시간 276

추적 시스템 232

추적기 349

버전

관리 시스템 351

충돌 107

버전 관리

구성 파일 352

구축 공정 265

DVCS 352

VCS 351

버퍼 대량 방출 122

번스타인, 레너드 611

법규 준수 110

베라, 요기 431

벤치마크 98

변경

구간 478

성공률 276

제한 84

변경 관리(CM) 운영 책무 519, 550

변칙 검출 457

변화-불안정성 주기 216

병목 153, 251, 342

보안 301

보유 자원 파악 474

보이드, 존 390

보조 자원 479

보충 원리 326

복구 77

구글 장애 복구 검사 414

도구 338

복구 지향적 컴퓨팅 581

실행 중 78

충돌 76

평균 서비스 복구 시간 276

복제된 데이터베이스 79

복제본 47, 186

갱신 55

그룹 128

IP 주소 135

봇넷 205

부산물 270

부선형 599

부정적 확인 459

부품 고장 195

부하

검사 292, 480

공유 188, 197

분산 방법 125

차단 204

부하 분산기 47, 198

계층 3 및 계층 4 124

계층 7 124

사용 목적 199

이중 128

전역 135


종류 123

탄력성 200

하드웨어 대 소프트웨어 200

분리

내구성 59

저항 57, 59

분리된 뇌 59

분산 버전 관리 시스템 352

분산 상태 54

분산 서비스 거부 공격 205

분산 컴퓨팅 8, 43

기원과 미래 569

분산 해시 테이블 170

분석 cf. 사후 분석

가정 169

근미래 457

근본 원인 396

기여 조건 396

단기 457

수용량 계획 수립 482

찾아보기634

INDEX

시스템 448

실시간 456

원인 396

자료 482

장기 457

전년 대비 440

분석 및 계산 시스템 456

불변식 290

불운의 바퀴 408

블랙리스트 83

블랙박스 107

측정 449

블레이드 서버 295

비가동시간 304

비기능적 요구사항 73

비난 395

비동기 설계 67

비례식 라운드 로빈 47

비례식 차단 309

비목표 366

비상 376

과제 224

사항 229

응급조치 321

통신 계획 416

비상 대응(ER) 운영 책무 518, 543

비용 효과적 캐시 164

비정상 검출 457

비차단 대역폭 202

빌드봇 337

빨간 깃발 563

뿌리 서버 52

삐삐 385

ㅅ

사고 대응 활동 계획서 426

사고지휘관, 사고현장 지휘관 423

사고지휘체계 423

사람 공정 256

사람의 실수 207

사설 클라우드 109

사업 목표 33

사용량별 구획화 161

사용자

가까운 위치 134

고유 자료에 근거한 전역 부하 분산 136

로그인·로그아웃 130

사용자이름 130

신원 127

인수 검사 101, 224, 293

제거 228

사이트 신뢰성 공학(SRE) 213, 253

관행 218

기술자 220

팀 215

핵심 관행 218

사일로 230, 242, 244

사전 점검 207

사후 분석 394

공유 396

목적 394

사후 분석 보고서 219, 233, 395, 459

양식 608

외부용 396

산개 51

산술 평균 463

상관

계수 473, 484

관계 483

상보성 원리 326

상부 보고 191, 390, 434

연쇄 458

상수 규모 변화 598, 599

상태

갱신 요청 55

분산 54

장애 조치 200

상향 위임 434

635찾아보기

상호접속 위치 137

새 기능 도입 311

새 기능 예산 217

새 서비스 개시 491

생존 가능 시스템 181

샤드, 샤딩 52, 54, 169, 170

서드파티

공급업체 92

상부 보고 391

의존물 391

서버 44


감독 140

내용 배포 137

다수의 뒷단 49

단일 기계 120

블레이드 295

뿌리 52

응용 프로그램 130

이미지 175

잎 52

자체 측정 455

주 56

트리 52, 132

서비스 44

3층 122

4층 129

거부 공격 205

구글 기계 학습 100

구글 캘린더 382

구내 설치/외부 운영 115

규모 변화 3층 웹 128

대기열 140

대체 304

발행-구독 140

서비스별 분할 158

설치 296

수명 주기 223

업그레이드 303

이미지 296

잠복지연 593

재난 대비 411

재시작 75

조직 내 공급자 115

중단 303

차별화 313

철자 검사 62

체계 도입 529

추상 수준 96

클라우드 규모 134

평균 복구 시간 276

폐지 224, 228

플랫폼 선택 전략 113

서비스 개시 ☞ 개시

서비스 배치 및 폐지(SDD) 운영 책무 519, 554

서비스 수준

목표(SLT) 434

지표(SLI) 434

협약서(SLA) 213, 376, 434

서비스 인도 269

전략 271

플랫폼 269, 271

흐름 270

서비스 인도 구축 국면 ☞ 구축 국면

서비스 인도 배치 국면 ☞ 배치 국면

서비스 지향 구조(SOA) 146

모범 관행 147

유연성 146

서비스 평가 517

기간 524

대상 식별 523

방법론 518

빈도 526

서비스로서의 기반구조( IaaS) 95

서비스로서의 소프트웨어(SaaS) 95, 100

서비스로서의 플랫폼(PaaS) 95, 99

선반 ☞ 랙

선순환 274

찾아보기636

INDEX

선언적 언어 346

선입선출 173

선적 컨테이너 108

선형 규모 변화 598, 599

섣부른 최적화 152

설계 문서 승인

승인자 370

작업흐름 370

절차 369

설계 문서, 설계서 363

검토 369

검토자 370

구성 365

양식 368, 605

저장소 369

표준 채용 372

설치 289

가상 기계 296

배치 국면 289

서비스 296

설치 전 스크립트 289

설치 후 스크립트 289

운영 체제 296

패키지 280

하드웨어 295

성능

검사 292

측정 154

회귀 224, 292

성능과 효율성(PE) 운영 책무 519, 556

성숙도 520

세션 ID 128

센지, 피터 213

셸 스크립팅 언어 343

소규모 컴퓨팅 시스템 591

소방 훈련 410

소스 저장소 277

소요시간 103

소음 460

소통 44

소프트웨어

기술자 273

멈춤 192

업그레이드 77

장애 190

재시작 191

충돌 190

탄력성 181

소프트웨어 개발 수명 주기(SDLC) 258

소프트웨어 패키지 280, cf. 패키지

작성 352

소프트웨어로 정의되는 네트워크(SDN) 593

소형 언어 344

속도 44, 64

제한 83

측정 450

쇼, 조지 버나드 497

수동 구축 283

수동 중지 318

수렴 편성 290

수리 요청 도구 339

수리 주간 236

수리의 날 236

수용량 226

넘침 115

단위 186

모형 481

예측 487

수용량 계획 수립(CP) 436, 471

운영 책무 519, 548

위임 490

자료 분석 482

수용량 한계 472, 480

파악 480

수작업 공정 219

규모 변화 220

수직 통합 111, 595

수집 시스템 448, 453

637찾아보기

수평 규모 변화 157

수평 중복 157

순번제 230

순회식 업그레이드 304

슐로스네이글, 테오 71, 243

스레드 적용 172

스마트폰 앱 385

스케일링 아웃 157

스크레이핑 공격 206

스크립팅 언어 344

스타일 지침 353

스택 랭킹 465

스폴스키 181, 336

슬로스, 벤자민 트레이너 218, 509

승격 288

승인 227

연쇄 291, 294

작업흐름 370

시각 433

시각화 434

감시 자료 462

시스템 448, 462

시간 근사치 65

시간표 473, 478

시계열 472

시스템 검사 279, 292, 307

시스템 로그 442

시스템 운영 수준 333

신뢰성 213

지역 98

신제품 도입 및 제거(NPI/NPR) 운영 책무 519, 552

신축성 592

신호선 교차 473

실무 환경 건강 318

실무 후보 294

실사용자 감시 433

실시간 분석 456

실패 34

실패 시 개방 83

실패 시 폐쇄 83

실행 실행 실행 죽음 문제 582

실행 중 복구 78

심박 요청 193

심층 방어 180

싱가포르 MAS 86

ㅇ

아마존

역방향 개발 364

EC2 (Amazon Elastic Compute Cloud) 594

Simple Queue Service (SQS) 140

Web Services (AWS) 105

아파치

웹 서버 Prefork 처리 모듈 174

Mesos 75

ZooKeeper 311, 468

안정성

우선 216

향상 217

알렉산더, 크리스토퍼 119

알림 376, 383, cf. 경보

암달의 법칙 178

암호 인증서 131

암호화 131

애봇, M 156, 158

애자일 262

기법 252

동맹 262

방법론 350

선언 262

앨런, 우디 375

야행성 432

약한 개시 214, 492

양방향 호출기 385

양식 ☞ 문서 양식

얼랭 316

얼리 어답터 372

업그레이드 224

찾아보기638

INDEX

구글 블로그 검색 304

서비스 303

소프트웨어 77

순회식 304

활성 서비스 303

업무 목표 33

에이전트 455

엣시 341

여유분 473, 476

역 프록시 133

역량 성숙도 모형 ☞ CMM

역추적 192

연기 검사 266

연습 39, 406

열 지도 524

영선 교차 473

영속적 자료 298

영역 국한 언어 326, 346

예비 수용량 186

예산 지출 시간표 478

예외 87

수집 87

예정된 중지 318

예측 487

예측적 전략 180

오델의 공리 151

오류 보정 부호 195

오류 예산 257

KPI 509

SLA 219

오스카 와일드 447

오작동 180

유발 406

오픈소스 프로젝트 580

올스포, J. 331, 395, 396, 417, 419

완벽하고 오작동 없는 세계 183

외부 공급업체 지원 392

외부용 사후 분석 보고서 396

욕조 고장 곡선 198

우아한 강등 82, 179

운영 213

건강(OH) 436

대규모 220

위생 227

콘솔 294

운영 작업

출처 229

항목 229

운영 조직

범주 516

사정 517

평가 517

운영 책무 518

감시와 측정 518, 545

공통 518

변경 관리(CM) 519, 550

비상 대응(ER) 518, 543

서비스 배치 및 폐지(SDD) 519, 554

성능과 효율성 519, 556

수용량 계획 수립 519, 548

수준 징표 522

신제품 도입 및 제거(NPI/NPR) 519, 552

정규 과제 518, 540

평가 539

평가 수준 520

운영 체제 설치 296

운영상의 기능에 대한 80/20 규칙 91

운영상의 요구사항 72

운영을 위한 문서화 88

운영을 위한 설계 71

구현 89

운영팀

조직화 전략 229

품질 측정 517

원격

감시국 456

손 233

프로시저 호출(RPC) 84

639찾아보기

원그래프 463

원인 분석 396

원자성 61

월간 활성 사용자 수(MAU) 472, 481

웹 이전 시대 570

가동 중단 571


규모 변화 572

기술 571


비용 573

웹 접속 로그 442

위성 137

위키 238, 369

위험 줄이기 406

윌리 웡카 269

유기적 성장 472

유럽 연합 개인정보 보호지침 86, 110

유지(감시 자료) 439

유지보수 460

유휴 수용량 204

육감 317

은밀한 개시 313, 492

음성 통화 385

응급조치 대 장기적 해결책 388

응용 서버 130

응용 프로그래밍 인터페이스 ☞ API

응용 프로그램

구조 119

디버깅 로그 442

로그 442

서버 130

의도적 지연 319

의사소통 메커니즘 237

의존성 226

지옥 107

이동평균 473, 484

수렴·발산 ☞ MACD

이름표 285

이메일 238

경보 메커니즘 384

이미지

생성 자동화 297

서버 175

이상적인 환경 33

이야기꾼 418

이정점 패턴 466

이중 부하 분산기 128

이해관계자 214

인수인계 393

인위적 장애 407

인적자원 자료 갱신 145

인증 300

인증서 관리 131

인지시스템공학 330

인터넷 존재 573

일관성 57, 61

일괄 단위 250

일꾼 스레드 173

일대다 통신 140

읽기 전용 복제본 79

임의 그룹 구획화 162

입출력 과부하 48

잎 서버 52

ㅈ

자급식 요청 222

자기 완결적 랙 201

자기 조사 45

자동화 44, 220, 325

개발운영 255

계정 생성 335

공정 282

교훈 332

기반구조 295

대상 342

도구 구축 333

목표 336

찾아보기640

INDEX

방법 342

보충 원리 329

상보성 원리 330

소프트웨어 공학 도구 348

숨은 비용 333

시스템 관리자 331

원형 343

이미지 생성 297

인간 요소 332

자동차 제조 334

자동화되지 않은 과제 221

잔여물 원리 327

컴퓨터 구성 334

자동화 작성 339

단계 342

언어 343

자료

구획화 방법 161

도입 제어 84

분석 482

증강 84

총체 52

파편화 169

자릿수 601

자원

1차 472, 479

2차 479

경합 105, 319

공유 109

막힌 107

보조 479

인도 시간 478

파악 474

폐기 229

풀 157

해제 229

회귀 490

자율 에이전트 412

작업 이전 284, 393

잔여물 원리 326

잠복지연 44, 98, 125, 216, 435, 464, 590

서비스 593

원숭이 413

코드 250

잠정적 교대근무 마감 보고서 393

잡일 340

장기 분석 457

장기적 해결책 393

장애 44, 180

과부하 203

구글 414

물리적 194

발생 확률 187

상태 있는 200

소프트웨어 190

영역 189

인위적 407

조건 458

조치 200

재고 데이터베이스 475

재공학 153

재난 403

재난 대비

무작위 검사 412

사고방식 404

서비스 개시 227

서비스 검사 411

평가 565

훈련 408

재난의 주인(MoD) 408

재설계 153

재적용 도구 339

저장 시스템 448, 467

저장 영역 네트워크 298

적응적 교체 캐시 166

전개 51

전년 대비 분석 440

전능 431

641찾아보기

전역 부하 분산기 135

POP 138

전원 공급장치 고장 196

전일종사 직원 608

전제 431

전지 431

전처리 작업 부담 600

전통적인 전사적 IT 부서 215

전환률 437

접근 제어 목록 83

접착성 126

정규 과제 운영 책무 518, 540

정규 충돌 191

정규 호출대기 임무 387

정상 과제 224

정상 성장 472, 476

정상 요청 230, 378

정연한 종료 76

정의됨 수준 520

정적 내용 120

정직원 608



규모 변화 575

기술 574


부하 분산기 574

비용 578



규모 변화 588

기술 586


비용 589

제곱 규모 변화 599

제네럴리스트 246

제약 155

제어판 142

제출 전 점검 278

제품 관리 437

제프 딘 66

조달 시간 494

조직

기억 225

부서별 구획화 161

서비스 공급자 115

평가 527

조합 패턴 46

조회 지향적 분할 160

좀비 421

종단간 공정 255

주 서버 56

주 스레드 173

주간 활성 사용자 수 481

주기 시간 270

주행성 432, 464

죽음의 질의 193

줄 머리 차단 172

중단 180

중복성 78, 186

중앙 수집기 456

중앙값 463

즉석 교체 80

가능 장치 81

즉석 대기 188

즉석 예비 188

즉석 장착 가능 장치 81

증강 파일 84

지리 위치 파악 135, 175

지리적 다양성 98

지속 가능 시스템 181

지속적 개선 220

지속적 배치 317

정지 318

지속적 인도(CD) 262, 263, 299

4대 관행 265

8대 원리 264

지속적 통합(CI) 282

찾아보기642

INDEX

지수 규모 변화 598, 599

지수이동평균 473, 487

지식 내장 249

지역 노동법 86

지역 시간대 444

지역별 수집기 456

지연 464

직무 만족도 276

직접 측정 450

직접 편성 290

진단 438

검사 266

질의 119

죽음의 193

집결 51

징표 522

ㅊ

차가운

저장소 99

캐시 165

차수 598

참여도 472, 482

측정 482

창고 규모 컴퓨팅 589

채널 140

채프먼, 브렌트 423

철자 검사 서비스 62

청록 배치 309

청색 환경 309

청취 140

체크아웃 351

체크인 351

초가상화 104

초과예약, 초과구독 97, 186

초기 수준 520

초당 질의 수 44, 83

초선형 599

총소유비용 111, 243, 593

총체 52

최근 미사용 알고리즘 166

최빈값 525

최소 감시 문제 439

최소 부하 125

느린 시작 125

방식 48

최소 사용 빈도 알고리즘 166

최적화 진행 수준 520

추상 62

수준 96

추세 434

변화 489

추적 333

충돌 190

복구 76

충돌 전용 소프트웨어 76

취합기 456

측정 432

감시 518

계측치 451

능력 450

블랙박스 449

빈도 433

서버 455

성능 154

속도 450

운영팀 품질 517

직접 450

참여도 482

카운터 451

합성 450

화이트박스 449

측정치 45, 433, 499

수집 453

MACD 487

ㅋ

카나리아 공정 306

643찾아보기

검사 공정 306

카운터 측정 451

캐시 적중 163

비율 163

실패 163, 602

캐시, 캐싱 162

교체 알고리즘 166

영속성 165

위치 164

적중률 163

크기 168

항목 무효화 167

효율성 163

컨테이너 106

단점 108

장점 107

프로세스 그룹 106

컴파일식 언어 345

컴퓨터 고장 198

코드

검토 시스템(CRS) 356

소요시간 276

잠복지연 250

포괄도 318

코드 승인 91

절차 92

코드 투입 303

실패 320

코드로서의 기반구조 258, 300

코로케이션 112, 175, 580

코어덤프 192

코틀러, 필립 471

쾌속 개발 311, 344

크레이버, 닉 547

클라우드 95

공용 109

기원과 미래 569

물리적 기계 116

사설 109

사용 비용 111

서비스 134

제어권 111

컴퓨팅 8

클라우드 컴퓨팅 시대 590


규모 변화 높은 가용성 592

기술 593

비용 591

클로, 릭 499

클로스 네트워킹 202

ㅌ

타임스탬프 142, 433, 443

탄력성 179, 477

탈렙, 나심 니콜라스 404

테스트 주도 개발 355

테스트, 테스팅 ☞ 검사

텍스트

비교 도구 73

파일 73

텔리스, 마르세우 515

토르발스, 리누스 364

톰슨, 켄 327

통 466

통과 ISP 137

통신

다대다 139

다대일 140

비상 416

일대다 140

통지 383

통합 254

투입 충돌 319

투자수익 111

트리거 456

트웨인, 마크 325

트위터 161

티켓 234, 350

찾아보기644

INDEX

임무 230

임무일 232, 234

팀 훈련 410

팀원 업무일 232

ㅍ

파라수라만, R. 331

파이 그래프 463

파이썬 언어 100

파일 토막 56

파편 52, 54, 170

배출 172

파편화 54, 169

패리티 비트 195

패치 소요시간 276

패키지 352, cf. 소프트웨어 패키지

구성 299

구축 국면 280

등록 282

설치 280

작업 이전 인터페이스 284

저장소 277

패트릭 드부아 252

퍼포먼트 44

페이스북

은밀한 개시 313, 492

Chat 492

Gatekeeper 313

SocialRank 599

페이지 실패 602

편재 431

평가 539

기간 524

방법론 518

평균 463

무고장 시간 180

서비스 복구 시간 276

수리 시간 187

이동 ☞ 이동평균

전력사용지수 589

폐지 224, 228

포드 202

폭포수 방법론 244, 273

폭포식 126

폴러 455

표적화 333

표준 수용량 계획 수립 472

품질 보증(QA) 436

기술자 273

품질 확신 275

품질의 선순환 274

프로그래밍 가능한 VLAN 593

프로세스 감시기 191

프로젝트 작업 224, 230

프로젝트 집중일 232

프로펠러헤즈 569

플래그 뒤집기 81, 310

피드백 루프 92, 248, 251

피셔, M. 158

피츠 목록 329

핀 꽂기 288

ㅎ

하둡 ☞ Hadoop

하드 디스크

고장 196

신뢰성 미신 440

하드웨어

가상 기계 104

설치 295

탄력성 181

하드웨어 부하 분산기 대 소프트웨어 부하 분산기 200

하향 표본화 440

합성 측정 450

해밍 부호 195

해바라기 380

해상도 435

해석식 언어 344

645찾아보기

해시

접두사별 구획화 161

함수 169

핵심 동인 472, 481

핵심성과지표 ☞ KPI

핵심지표 감시 489

향후 수용량 계획 수립 93

혁신 214

현재 사용량 472, 474

형상 관리 290, 297, 346

호스트이름 139

호스팅 공급자 계약 시 질문 사항 112

호어, C. A. R. 43

호출기 385

폭풍 459

호출대기 214, 219, 227, 230, 375, cf. 교대근무

각본 390

개발자 378

도움 요청 389

마감 임무 392

매뉴얼 390

명단 377

빈도 383

설계 376

수행 386

일정 318, 379

일정표 382, 459

임무 386

정규 임무 387

준비 점검 목록 386

추가 수당 381

호출대기일 232, 233

호출대기자 376, 425

후속 작업 380, 389, 393

훈련 377

혼돈 고릴라 412

혼돈 수준 520

혼돈 원숭이 412

혼잡 51

화이트리스트 83

화이트박스 측정 449

확신 275, 410

확장/수축 기법 314

활성 백업 77

활성 사용자 수 472

활성 서비스 업그레이드 303

활성 스키마 변경 313

활성 코드 변경 316

활용 제한 125

회귀 319

분석 473, 483

성능 224, 292

자원 490

직선 484

회복력 179

후속 작업 호출대기 389

후행 평균 48

훈련

개인 408

소방 410

재난 대비 408

팀 410

호출대기 377

히스토그램 466

A

A-B 검사 312

Abbott, M. 156, 158

abstraction ☞ 추상

Abts, D. 202

access control list (ACL) 83

accounting 301

ACID 61

ACL (access control list) 83

Active Directory 301

active users 472

active-passive ☞ 능동-수동

adaptive replacement cache (ARC) 166

AdSense 586

찾아보기646

INDEX

Adya, A. 141

agent 455

aggregator 456

Agile ☞ 애자일

AKF 규모 변화 입방체 156

alarm, alert, alerting ☞ 경보

Alexander, Christopher 119

Allen, Woody 375

Allspaw, J. 331, 395, 396, 417, 419

Amazon ☞ 아마존

Amdahl’s law 178

analysis system 448

ancillary resource 479

Anderson, C. 254

announcement 238

anomaly detection 457

antifragile 404

Apache ☞ 아파치

API (Application Programming Interface) 44

로그 442

application ☞ 응용, 응용 프로그램

approval ☞ 승인

ARC (adaptive replacement cache) 166

artifact 270

assessment ☞ 평가

Atlassian Bamboo 281

atomicity 61, 321

attack surface area 132

auditing 226

augmentation 84

authentication 300

authorization 300

automation ☞ 자동화

autonomous agent 412

availability 57, 213

AWS (Amazon Web Services) 105

B

backend ☞ 뒷단

baked image 297

Barroso, L. A. 194, 197, 440, 585, 589

Baseboard Management Controller (BMC) 295

Basecamp 100

Basically Available Soft-state services with

Eventual consistency (BASE) 61

batch 250

bathtub failure curve 198

Beck, K. 262

Behr, K. 242

Bellovin, S. M. 131

Bernstein, Leonard 611

Berra, Yogi 431

best practice 147

Big O notation ☞ 대문자 O 표기법

Bigtable 60

bimodal 466

bin 466

BIOS 설정 295

bit.ly 142

blacklist 83

blade server 295

blue-green deployment 309

BMC (Baseboard Management Controller) 295

boss-worker 59

Bosun 455

botnet 205

bottleneck 153

Bourne Again Shell (bash) 344

Bourne Shell 344

Bowen, H. K. 242, 247

Boyd, John 390

Brandt, K. 390

broadcasting 140

BSD UNIX 580

BTFS 196

bucket 466

buffer thrashing 122

bug ☞ 버그

647찾아보기

build, building ☞ 구축

buildbot 337

business objective 33

C

c-SOX 86

cache ☞ 캐시

canary process ☞ 카나리아 공정

Candea, G. 76

CAP 원리 57, 164

삼각형 60

capability maturity model (CMM) ☞ CMM

capacity ☞ 수용량

capacity planning (CP) ☞ 수용량 계획 수립

cascade 126

Cassandra 60

causal analysis 396

CCA (contributing conditions analysis) 396

CD (continuous delivery) 262, 299

CDN (content delivery network) 175

URL 175

certificate management 131

CFEngine 290, 340, 346

Chalup, S. R. 280

change ☞ 변경

change management (CM) ☞ 변경 관리

change-instability cycle 216

channel 140

chaos monkey 412

Chapman, Brent 423

chat room ☞ 대화방

check-in 351

Chef 290

chek out 351

Cheswick, W. R. 131

chunk 56

CI (continuous integration) 282

Clidaras, J. 589

cloud ☞ 클라우드

CM (change management) 519, 550

CM (configuration management) 297, 346

CMDB ( configuration management

database) 301

CMM (capability maturity model) 520

다섯 수준 520

CNN.com 웹 사이트 49

code ☞ 코드

cognitive systems engineering (CSE) 330

cold ☞ 차가운

collection system 448

colocation 112, 175

compensatory 326

compiled language 345

complementarity 326

composition pattern 46

confidence 275

configuration ☞ 구성

configur ation management

database (CMDB) 301

configuration package 299

congestion 51

Consistency 57, 61

constant scaling 598

constraint 155

container ☞ 컨테이너

content delivery network (CDN) ☞ CDN

content distribution 137

contention 105

continuous delivery (CD) ☞ 지속적 인도

continuous deployment ☞ 지속적 배치

continuous integration (CI) 220, 282

contributing conditions analysis (CCA) 396

control panel 142

convergent orchestration 290

conversion rate 437

Cooper, G. 141

core driver 472, 481

coredump 192

찾아보기648

INDEX

corpus 52

correlation ☞ 상관

cost-effective 164

counter 451

CP (capacity planning) 436, 471, 519, 548

CPU 경합 105

crash ☞ 충돌

Craver, Nick 547

CRS (code review system) 356

crypto certificate 131

CSE (cognitive systems engineering) 330

customer ☞ 고객

cycle time 270

D

dark launch 492

database ☞ 데이터베이스

Dawkins, Richard 597

DDoS (distributed denial-of-service) 공격 205

Dean, Jeff 66, 194, 585

Debois, Patrick 252

declarative language 346

decomm, decommissioning 224, 228

defense in depth 180

delay 464

Deming, W. Edwards 242

denial-of-service (DoS) 공격 205

dependency ☞ 의존성

deployment ☞ 배치

design document ☞ 설계 문서

DevOps ☞ 개발운영

DHT 170

DHT (distributed hash table) 170

diagnostic ☞ 진단

Dickson model 435

diff 73

direct orchestration 290

DiRT 414

disaster 403

disaster preparedness ☞ 재난 대비

Disaster Recovery Testing (DiRT) 414

distributed computing ☞ 분산 컴퓨팅

distributed denial-of-service (DDoS) 공격 205

distributed hash table (DHT) 170

distributed VCS (DVCS) 352

diurnal 464

diversity 435

DNS (domain name service) 301

라운드로빈 123

Docker 108, 297

documentation ☞ 문서화

Doerr, John 499

domain-specific language (DSL) 326, 346

DoS (denial-of-service) 공격 205

down-sampling 440

downtime 304

draining ☞ 배출

DRBD 321

DSL (domain-specific language) 326, 346

Durability 61

DVCS (distributed VCS) 352

dynamic conten 120

Dynamo 60

E

early adopter 372

ECC (error-correcting code) 195

economies of scale 569

edge case 221

Edwards, Damon 243, 260, 262, 275

elasticity 592

Elements of Programming Style, The 46

EMA (exponential moving average) 473

email ☞ 이메일

emergency ☞ 비상

emergency response (ER) ☞ 비상 대응

EMI 424

encryption 131

649찾아보기

end-of-shift report 235, 392

end-to-end 255

engagement ☞ 참여도

ephemeral machine 103

ER (emergency response) 518, 543

Erlang 언어 316

Error Budgets ☞ 오류 예산

error-correcting code (ECC) 195

escalation ☞ 상부 보고

Etsy 341

EU Data Protection Directive 86

eventual consistency 58

exception ☞ 예외

executive summary 366

expand/contract 314

expected impact 90

expenditures timetable 478

exponential moving average (EMA) 473

exponential scaling 598

F

Facebook ☞ 페이스북

factorial scaling 599

fail closed 83

fail open 83

failover 200

failure ☞ 고장, 장애

fair queueing 174

fan in 51

fan out 51

Farley, D. 264

feature ☞ 기능

feedback loop 248

feeding from a queue 173

Felderman, B. 202

FEMA 424

재난관리교육원(EMI) 424

FIFO ( first in first out) 173

fire drill 410

Fisher, M. 156

Fitts’s list 329

Fix-It Day 236

Fix-It Week 236

FIXME 주석 354

flag fliping 81, 310

forecasting 487

Fox, A. 76

freemium 590

FTE ( fulltime employee) 608

Fulghum, P. 262, 292

funnel 140

future capacity planning 93

future-proofing 357

G

Game Day ☞ 게임 데이

Ganapathi, A. 207

Ganeti 321

gate 270

gauge 451

generalist 246

geolocation 135, 175

GFS (Google File System) 587

Gibson, William 516

Gilbert, S. 60

GLB (global load balancer) 135

Go Continuous Delivery 281

Google ☞ 구글

graceful degradation 82, 179

Great Firewall 177

Gruver, G. 262, 292

H

Hadoop 588

HDFS 196

Hamming code 195

handoff 284

찾아보기650

INDEX

hang 192

hardware ☞ 하드웨어

hash ☞ 해시

Hbase 60

head of line blocking 172

headroom 473

health check 47

heartbeat request 193

heat map 524

histogram 466

Hoare, C. A. R. 43

Hogan, C. 280

Hohpe, G. 142

horizontal duplication 157

horizontal scaling 157

hostname 139

hot spare 188

hot standby 188

hot swap ☞ 즉석 교체

hot-pluggable 81

hot-swappable 81

HP LaserJet 262

HTTP (Hyper-Text Transfer Protocol) 119

HTTP 요청 119

Hudson 281

Humble, J. 262, 264, 275

HVM 104

Hölzle, U. 585, 589

I

IaaS ( Infrastructure as a Service) 95

IAP ( incident action plan) 426

IC ( incident commander) 423

ICS ( incident command system) 423

절차 교육 427

infrastructure as code 258, 300

inhibit 461

innovation 214

installation ☞ 설치

instrumeutation 86

integration 254

Intel OKR 시스템 499

internal backbone 136

internet presence 573

introspection 45

invariant 290

inventory database 475

IP

다중전송 141

단일전송 141

주소 123

Isolation 61

issue ☞ 문제점

IT 고객지원 티켓 시스템 351

J

j-SOX 86

Jacob, Adam 243

jail 107

Java 카운터 452

JCS ( joint cognitive system) 330

Jenkins CI 281

job satisfaction 276

JSON 454

K

Kamp, P.-H. 601

Keevenm, T. 156

Kejariwal, A. 479

Kerberos 301

Kernighan, Brian 46

Kim, Gene 242, 247

Klau, Rick 499

Kotler, Philip 471

KPI (key performance indicator) 437, 497

가상 기계 할당 504

구글 오류 예산 509

651찾아보기

배치 503

선택 502

수정 502

이상 501

작성 500

평가 508

행동 501

SMART 498

Krishnan, Kripa 417, 419

KVM 321

L

L1 캐시 165

label 285

lame-duck mode 76

LAMP 581

Large I nstallation System

Administration (LISA) 252

latency ☞ 잠복지연

Launch Readiness Review (LRR) 228

launch, launching ☞ 개시

LDAP 301

lead time 103, 276

least frequently used (LFU) 166

least loaded ☞ 최소 부하

least recently used (LRU) 166

left-over 326

Letuchy, E. 493

Levy, Steven 419

Limoncelli, T. A. 280, 340, 417, 419

linear scaling 598

link-shortening site 142

Linux 580

LISA ( Large Installation System

Administration) 252

LL 125

load ☞ 부하

load balancer ☞ 부하 분산기

lock-in 101

log 45, 442

logarithmic scaling 599

loglinear scaling 599

look-for 522

lookup-oriented split 160

loosely coupled 62

LRR (Launch Readiness Review) 228

LRU ( least recently used) 166

Lynch, N. 60

M

MACD ( moving average convergence/

divergence) 473

신호 487

신호선 473

측정치 487

machine ☞ 기계

Madrigal 413, 419

main thread 173

maintenance 460

malfunction 180

manual labor 219

many-to-many 139

MapReduce 587

master 140

Master of Disaster (MoD) 408

master server 56

master-slave 59, 188

MAU (monthly active users) 472, 481

McHenry, Stephen 314

McKinley, D. 341

McLean, Malcom 109

MCollective 140

MD5 해시 170

mean time between failure (MTBF) 180, 182

mean time to repair (MTTR) 187

measurement ☞ 측정

median 463

Megiddo, N. 166

찾아보기652

INDEX

notification 383

NPI/NPR 519, 552

O

objectives and key results (OKR) 499

OH (operational health) 436

On-Premises, Externally Run 115

oncall ☞ 호출대기

onduty 378

OODA 루프 390

Open Directory 301

OpenStack 321

OpenTSDB 467

operation ☞ 운영

operational responsibility (OR) ☞ 운영 책무

Oppenheimer, D. L. 207, 242

order 598

order of magnitude 601

organic growth 472

organizational memory 225

outage 180

oversubscription 97, 186

O’Dell’s Axiom 151

P

PaaS (Platform as a Service) 95, 99

pager ☞ 호출기

Parasuraman, R. 331

paravirtualization 104

parity bit 195

partition ☞ 분리

Patterson, D. A. 207, 581

PCI DSS 86

PE (performance and efficiency) 519, 556

people process 256

percentage of code coverage 318

percentile 463

performance ☞ 성능

Memcached 127

message ☞ 메시지

meta-monitoring 441

meta-process 223

meta-work 232

metadata 433

metrics ☞ 측정치

mini-language 344

MM (monitoring and metrics) 518, 545

MoD 408

mode 525

Modha, D. S. 166

monitoring ☞ 감시

monthly active users (MAU) 472, 481

moving average ☞ 이동평균

MTBF (mean time between failure) 180, 182

MTTR (mean time to repair) 187

multicast 141

multitenancy ☞ 다중입주

Myers, D. 141

N

N + 1 구성 577

N + 2 구성 577

N + M 중복성 186

NAK (negative acknowledge) 459

NAT (network address translation) 127

Netflix ☞ 넷플릭스

network ☞ 네트워크

new product introduction and removal

(NPI/NPR) 519, 552

Nielsen, Jerri 303

non-blocking bandwidth 202

non-emergency request 378

non-goal 366

nonemergency task 224

normal growth 472

normal request 230

NoSQL 61

653찾아보기

performant 44

Perl 344

perspective 433

Pfeiffer, T. 245

phase 269, 308

physical machine ☞ 물리적 기계

Piatek, M. 141

Pinheiro, E. 197, 198, 440

pinning 288

PKI 83

planned growth 473

Platform as a Service (PaaS) 95, 99

Plauger, P. 46

playbook 88, 221

PM (product management) 437

pod 202

point of presence (POP) 137

poller 455

post-install script 289

postmortem ☞ 사후 분석

power supply 196

power usage effectiveness (PUE) 589

PowerShell 344

practice 39, 406

pre-check 207

pre-install script 289

pre-submit check 278

premature optimization 152

primary resource 472, 479

private cloud 109

private sand-box 273

process ☞ 공정

product management (PM) 437

production candidate 294

programmable VLAN 593

project work 230

project-focused day 232

promotion 288

Propellerheads 569

proportional round-robin 47

proportional shedding 309

prototype 343

provisional end-of-shift report 393

provisioning 494

public cloud 109

publisher 140

pubsub 140

PUE (power usage effectiveness) 589

pull 453

Puppet 290, 340, 346

Puppet 다중 입주 359

push 453

PV (paravirtualization) 104

Python 100, 344

Q

QPS (queries per second) 44, 83

quadratic scaling 599

quality assurance (QA) ☞ 품질 보증

query 119

query of death 193

queue, queing ☞ 대기열, 대기열 적용

R

RabbitMQ 140

Rachitsky, L. 397

rack ☞ 랙

RAID 183, 196

RAM

고장 195

캐시 166

rapid development 311

real user monitoring (RUM) 433

Recovery-Oriented Computing (ROC) 581

red flag 563

Redis 60, 127

redundancy 78, 186

찾아보기654

INDEX

reengineering 153

refactoring 153

regression ☞ 회귀

regular task (RT) 518, 540

regulating 333

release ☞ 릴리스

reliability ☞ 신뢰성

remote ☞ 원격

replica ☞ 복제본

resiliency 179

resolution 435

resource ☞ 자원

retention 439

return on investment (ROI) 111

reverse proxy 133

revision number 366

Riak 60

Rich, Amy 95

Richard, Dylan 419

Robbins, Jesse 417, 419

ROC (Recovery-Oriented Computing) 581

Rockwood, B 325

roll forward 320

rolling upgrade 304

Roosevelt, Franklin D. 363

Roosevelt, Theodore 403

root cause analysis 396

roster 377

rotation 230

round-robin ☞ 라운드로빈

Royce, D. W. W. 245

RPC (Remote Procedure Call) 84

RSS 피드 281

RT ( regular task) 518, 540

Rubin, A. D. 131

Ruby 344

RUM ( real user monitoring) 433

run run run dead 582

S

SaaS (Software as a Service) 95, 100

Salesforce.com 100

SAN (storage area network) 298

satellite 137

scalability 151, 597

scale ☞ 규모

scaling ☞ 규모 변화

Schlossnagle, Theo 71, 243

Schroeder, B. 198

scraping attack 206

SDD (service deploy and decommission) 519

SDD (service deployment and

decommissioning) 554

SDLC (software development life cycle) 258

SDN (software-defined network) 593

SeaLand 109

segmentation 160

Selenium WebDriver 292

Senge, Peter 213

sensing and measurement system 448

server ☞ 서버

ServerFault.com 160

service ☞ 서비스

service-oriented architecture (SOA)

☞ 서비스 지향 구조

shard, sharding ☞ 파편, 파편화

shared pool 204

Shaw, George Bernard 497

shell scripting language 343

Sheridan, T. B. 331

shift ☞ 교대근무

shipping container 108

short-lived machine 103

signal line crossover 473

silence 460

Simian Army 412

simple n etwork management

protocol (SNMP) 454

655찾아보기

single point of failure (SPOF) 200

Site Reliability Engineering/Engineer (SRE)

☞ 사이트 신뢰성 공학

SLA (service level agreement) 213, 376, 421, 434

SLI (service level indicator) 434

Sloss, Benjamin T. 218, 509

slow start 48

SLT (service level target) 434

SMART 기준 498

smoke test 266

SMS 385

SNMP (s imple network management

protocol) 454

SOA (service-oriented architecture)

☞ 서비스 지향 구조

soft launch 214, 492

software ☞ 소프트웨어

Software as a Service (SaaS) 95, 100

software development life cycle (SDLC) 258

software-defined network (SDN) 593

Solaris Zones 106

solid-state drive (SSD) 65, 593

source repository 277

SOX 86

Spafford, G. 242

spare capacity 186

Spear, S. 242, 247

speed ☞ 속도

split brain 59

SPOF (single point of failure) 200

Spolsky, J. 181, 336

SQS (Simple Queue Service) 140

SRE (Site Reliability Engineering)

☞ 사이트 신뢰성 공학

SSD (solid-state drive) 65, 593

Stack Exchange 166, 281, 293, 308, 547

stack ranking 465

stakeholder 214

state ☞ 상태

static content 120

steal time 105

stickiness 126

sticky connection 126

stolen time 105

storage area network (SAN) 298

storage system 448

story teller 418

stranded capacity 102

stranded resource 107

streamlining 222

style guide 353

sub-linear 599

subscriber 140

super-linear 599

survivable system 181

SWE 273

symbolic link 346

system test 279, 292, 307

T

tag 285

Taleb, Nassim Nicholas 404

targeting 333

TCO ( total cost of ownership) 111, 243, 593

TCP 세션 124

TDD ( test-driven development) 355

TeamCity 281

technical debt 236

Telles, Marcel 515

test, testing ☞ 검사

test-driven development (TDD) 355

third-party ☞ 서드파티

Thompson, Ken 327

Three Ways 247

three-tier 122

threshold 93

ticket ☞ 티켓

time series 472

찾아보기656

INDEX

Varnish HTTP 가속기 601

VCS (version control system) 351

version ☞ 버전

vertical integration 111, 595

virtual machine ☞ 가상 기계

virtuous cycle 274

visibility 45

visualization ☞ 시각화

VMM (virtual machine monitor) 104

W

warehouse-scale computing 589

watchdog timer 193

waterfall methodology 244

WAU (weekly active users) 481

Weber, W.-D. 197, 198, 440

weighted RR 125

what if analysis 169

Wheel of Misfortune 408

whitelist 83

Wickens, C. D. 331

wiki 369

Wilde, Oscar 447

Willis, John 260, 262, 275

Willy Wonka 269

Woolf, B. 142

worker thread 173

workflow 247

X Y Z

X-Forwarded-For 헤더 125

Xen 321

Yan, B. 479

Young, M. 262, 292

zero line crossover 473

ZFS 196

Zones, Solaris 106

time to live (TTL) 167

timestamp 142

timetable 473

TODO 주석 354

toggle 81

toil ☞ 고역

tool building ☞ 도구 구축

toolchain 257

topology 141

Torvolds, Linus 364

total cost of ownership (TCO) 111, 243, 593

traceback 192

tracking 333

traffic 44

trailing average 48

transit ISP 137

trend ☞ 경향, 추세

trigger 456

Tseitlin, A. 413, 419

TTL ( time to live) 167

Tufte, E. R. 466

Tumblr Invisible Touch 295

Turnbull, J. 254, 255

Twain, Mark 325

U V

UAT (user acceptance testing) 101, 224, 293

Ubuntu Upstart 75

undersubscription 97

unicast 141

unit of capacity 186

unit test 279, 355

UPS 75

user ☞ 사용자

user acceptance testing (UAT) 101, 224, 293

username 130

utilization limit 125

Vagrant 297

value stream 247

www.hanbi t .co.kr

이것이 프로그래밍이다!

이것이 안드로이드다

진정한 안드로이드 개발자로 이끌어줍니다.

SDK 5.0 롤리팝 호환!

책만 보고,

동영상 강좌로도 만족하지 못했다면 Daum

카페 '슈퍼드로이드'에서 만나요

cafe.daum.net/superdroid

박성근 저 | 1,164쪽 | 45,000원

이것이 C언어다

세상에 없던 새로운

C언어 입문서 탄생!

삼성, LG에서 펼쳐졌던

전설의 명강의를 풀타임 동영상 강좌로!

이보다 더 확실한 방법은 없다, 칠판강의

전체 동영상 강좌 유투브 전격 공개!

http://goo.gl/tJK3Tu

서현우 저 | 708쪽 | 25,000원

이것이 자바다

가장 중요한 프로그래밍 언어를 하나배워야 한다면, 결론은 자바다!

중급 개발자로 나아가기 위한 람다식,

JavaFX, NIO 수록

자바의 모든 것을 알려주는 인터넷 강의

궁금한 것은 카페에서!

cafe.naver.com/thisisjava

신용권 저 | 1,224쪽 | 30,000원

저자 직강 동영상 제공!

모던 웹을 위한

JavaScript + jQuery 입문

www.hanbi t .co.kr

지금은모던 웹 시대!

HTML5 분야 부동의 1위 도서

HTML5 표준안 확정에 맞춘 완전 개정판의 귀환!

HTML5 권고안과 최신 웹 브라우저 환경 대응

윤인성 저 | 624쪽 | 30,000원

모던 웹 디자인을 위한

HTML5 + CSS3 입문

자바스크립트에서 제이쿼리, 제이쿼리 모바일까지 한 권으로 끝낸다!

시대의 흐름에 맞춰 다시 쓴 자바스크립트 교과서

윤인성 저 | 980쪽 | 32,000원

페이스북, 월마트, 링크드인은 왜

Node.js를 선택했는가?

이 물음에 대한 답은 Node.js가 보여주는 빠른 처리 능력 때문이다.

윤인성 저 | 484쪽 | 25,000원

모던 웹을 위한

Node.js프로그래밍

필요한 것만 배워 바로 현장에서 쓰는 HTML5

순서대로 읽으며 실습할 수 있는 HTML5 자습서

김상형 저 | 700쪽 | 32,000원

HTML5 + CSS3 정복

Hanbit eBook Realtime

DRM free!어떤 디바이스에서도 자유롭게

eBook Oriented!전자책에 꼭 맞는 최적의 내용과 디자인

Hanbit eBook

Realtime 70

김세훈 지음

MFC프로그래밍주식분석 프로그램 만들기

이연복 지음

Hanbit eBook

Realtime 49Hanbit eBook

Realtime 89

자바 개발자를 위한

Vert.x애플리케이션 개발

Hanbit eBook

Realtime 49Hanbit eBook

Realtime 92

모바일/웹 메시징STOMP와 MQTT로 개발하는 IoT

모바일/웹 애플리케이션

제프 메스닐 지음 / 조건희 옮김

Mobile and Web Messaging

Hanbit eBook

Realtime 90

JavaScriptPromiseazu지음 /주우영옮김

www.hanbi t .co.kr /ebook

www.hanbi t .co.kr

전자부품 백과사전 vol.1찰스 플랫 지음 / 배지은 옮김 / 30,000원

취미공학에 필요한 핵심 전자부품을 사전식으로 정리한 안내서.

Zero to Maker: 누구나 메이커가 될 수 있다데이비드 랭 지음 / 장재웅 옮김 / 14,000원

일반인에서 메이커로. 날백수에서 무인 잠

수정 회사 CEO가 된 사나이, 데이비드 랭의 메이커 도전기.

처음 시작하는 센서키모 카르비넨,테로 카르비넨 지음임지순 옮김 / 13,000원

세상을 수치로 읽어내는 부품인 센서를 알려주는 책. 이 책을 통해 자신만의 프로젝트에 다양한 센서를 사용해보자.

프로젝트로 배우는 라즈베리 파이 도날드 노리스 지음 / 임지순 옮김

다양한 실전 프로젝트를 통해 라즈베리 파이를 쉽고 재미있게 배워본다.

Maker Pro 존 베이첼 지음 / 가격미정

메이커라면 반드시 읽어야 할 필수 계발서. 프로 메이커들과의 인터뷰 및 에세이 수록.

Make: 센서 키모 카르비넨, 테로 카르비넨, 빌 발토카리 지음 / 가격미정

필수 전자부품인 센서를 마이크로 컨트롤러 보드에 응용하는 방법을 담았다.

전자부품 백과사전 vol.2 찰스 플랫 지음 / 가격미정

<전자부품 백과사전> 시리즈의 두 번째 도서다.

즐거운 상상이 가득! 2015년 화제의 신간

전자부품 백과사전 vol.1찰스 플랫 지음 / 배지은 옮김 / 30,000원

취미공학에 필요한 핵심 전자부품을 사전식으로 정리한 안내서.

Zero to Maker: 누구나 메이커가 될 수 있다데이비드 랭 지음 / 장재웅 옮김 / 14,000원

일반인에서 메이커로. 날백수에서 무인 잠

수정 회사 CEO가 된 사나이, 데이비드 랭의 메이커 도전기.

처음 시작하는 센서키모 카르비넨,테로 카르비넨 지음임지순 옮김 / 13,000원

세상을 수치로 읽어내는 부품인 센서를 알려주는 책. 이 책을 통해 자신만의 프로젝트에 다양한 센서를 사용해보자.

프로젝트로 배우는 라즈베리 파이 도날드 노리스 지음 / 임지순 옮김

다양한 실전 프로젝트를 통해 라즈베리 파이를 쉽고 재미있게 배워본다.

Maker Pro 존 베이첼 지음 / 가격미정

메이커라면 반드시 읽어야 할 필수 계발서. 프로 메이커들과의 인터뷰 및 에세이 수록.

Make: 센서 키모 카르비넨, 테로 카르비넨, 빌 발토카리 지음 / 가격미정

필수 전자부품인 센서를 마이크로 컨트롤러 보드에 응용하는 방법을 담았다.

전자부품 백과사전 vol.2 찰스 플랫 지음 / 가격미정

<전자부품 백과사전> 시리즈의 두 번째 도서다.

즐거운 상상이 가득! 2015년 화제의 신간

www.hanbi t .co.kr

『클라우드 시스템을 관리하는...

Technology