Top

데브옵스 DevOps [아키텍트를 위한 첫 번째 데브옵스 지침서]

  • 원서명DevOps: A Software Architect's Perspective (ISBN 9780134049847)
  • 지은이렌 베스(Len Bass), 잉고 웨버(Ingo Weber), 리밍 쭈(Liming Zhu)
  • 옮긴이김영기, 박득형
  • ISBN : 9788960778887
  • 33,000원
  • 2016년 07월 29일 펴냄 (절판)
  • 페이퍼백 | 480쪽 | 188*235mm
  • 시리즈 : 소프트웨어 아키텍처

판매처

  • 현재 이 도서는 구매할 수 없습니다.

책 소개

요약

이 책은 데브옵스 분야를 소개하고 소프트웨어 개발에서 무시되어온 다양한 문제들에 대한 해결책을 다룬다. 데브옵스의 목표를 이루기 위해 소프트웨어 아키텍트가 내려야 하는 결정들을 살펴보고, 다른 데브옵스 참여자들이 아키텍트의 작업에 미치는 영향을 설명한다. 또한, 데브옵스를 더욱 효율적으로 적용하는데 필요한 조직적, 기술적, 운영적 맥락과 더불어 데브옵스가 적용되는 실제 연구 사례도 포함하고 있다. 이 책은 데브옵스의 전반적인 개요 이해뿐만 아니라 실질적인 적용에도 많은 도움이 될 것이다.

이 책에서 다루는 내용

■ 데브옵스가 시스템 아키텍처와 IT 역할 모두에서 상당한 변화를 필요로 하는 이유

■ 가상화와 클라우드 기술이 데브옵스 실천방법을 가능하게 하는 방법

■ 데브옵스로의 운영과 서비스 수명주기의 통합

■ 데브옵스 실천방법이 잘 작동하는 새로운 시스템의 설계

■ 데브옵스와 애자일 방법론 및 TDD의 통합

■ 오류 감지, 업그레이드 계획, 그리고 다른 핵심 이슈들의 처리

■ 데브옵스의 독립 배포 모델에서 발생하는 일관성 문제 관리

■ 데브옵스와 보안 통제, 역할, 그리고 감사의 통합

■ 데브옵스 적용, 확산, 그리고 측정을 위한 비즈니스 계획의 준비

이 책의 대상 독자

이 책의 주된 독자는 “프로젝트 또는 조직에 데브옵스 실천 방법을 적용해야 하는가?”라는 질문을 이미 받았거나 앞으로 받을 소프트웨어 아키텍트다. 하지만 아키텍트에게 묻는 대신, 이 책은 다음과 같이 말할 것이다. 다른 책들처럼 이 책 또한 새로운 독자 범주를 찾고자 한다. 소프트웨어 아키텍처의 사례에 대해 더 많은 사항을 배우고 싶어하는 학생들은 이 책에서 관심 있는 자료를 발견할 수 있다. 데브옵스 주제에 대해 조사하고자 하는 연구자들은 중요한 배경 자료를 찾을 수 있다. 그러나 주된 대상 독자는 실무 아키텍트다.

이 책의 구성

데브옵스의 배경에 대해 살펴보면서 이 책을 시작한다. 1부는 데브옵스의 목표와 데브옵스가 해결하고자 하는 문제에 대해 연구한다. 애자일 방법론과 데브옵스 실천 방법의 관계뿐만 아니라, 조직적, 문화적인 문제도 다룬다.
2장에서는 클라우드에 대해 살펴본다. 데브옵스 사례들은 플랫폼으로서의 클라우드(cloud as a platform)가 성장함에 따라 증가했다. 이론적으로 이 둘은 분리가 가능하지만, 실제로는 가상화와 클라우드는 데브옵스 사례에 대한 중요한 지원자다.
1부의 마지막 장인 3장에서는 정보기술 인프라 라이브러리(ITIL)의 프리즘을 통해 운영에 대해 살펴본다. ITIL은 운영 그룹의 가장 중요한 기능에 대한 조직 시스템이다. 데브옵스 사례를 포함하는 운영의 모든 사항뿐 아니라, 운영 그룹의 일부 책임에 대한 이해는 중요한 배경을 제공한다. 특히 역할과 책임에 대한 이해는 중요한 사항이다.
2부에서는 배포 파이프라인(deployment pipeline)을 설명한다. 4장에서 마이크로서비스 아키텍처 스타일(microservice architectural style)을 살펴보는 것으로 2부를 시작한다. 데브옵스 실천 방법을 적용하기 위해 마이크로서비스 스타일로 시스템의 아키텍처를 구성하는 것은 필수적이지는 않지만, 마이크로서비스 아키텍처 스타일은 데브옵스의 동기가 되는 많은 문제를 해결하기 위해 고안됐다.
5장에서는 빌드와 테스트 프로세스, 그리고 도구 체인을 빠르게 살펴본다. 이러한 것들에 대한 이해가 중요하긴 하지만, 초점을 두지는 않는다. 생산 환경으로 시스템을 배치하는 데 사용되는 다양한 환경과 이러한 환경에서 수행하는 다양한 종류의 테스트를 다룬다. 데브옵스에서 사용되는 많은 도구가 빌드와 테스트 프로세스에서 사용되기 때문에 이러한 도구의 이해와 통제 방법을 알아본다.
배포에 대해 알아보면서 2부를 마친다. 데브옵스의 목표 중 하나는 배포의 속도를 높이는 것이다. 이러한 목표를 달성하기 위해 사용되는 기법은 각각의 배포 팀에게 그들의 코드가 준비되었을 때 독립적으로 배포하도록 허용하는 것이다. 독립 배포(Independent deployment)는 일관성에 많은 문제를 가져온다. 다양한 배포 모델, 생산 환경에서 시스템의 구별되는 버전들의 동시관리, 에러 발생 시의 롤백, 그리고 생산 환경에 시스템의 실제 배치와 관련해 다뤄야 하는 다른 주제들에 대해 알아본다.
2부는 배포 사례들에 대한 기능적인 관점을 제시한다. 그러나 다른 시스템과 마찬가지로, 이것은 흔히 설계와 시스템의 승인을 통제하는 품질에 대한 관점이다. 3부에서는 횡단 관심사(crosscutting concerns)에 중점을 둔다. 3부는 7장에서 모니터링과 라이브 테스팅에 대해 논의함으로써 시작된다. 현대적인 소프트웨어 테스팅 실천 방법은 시스템이 생산 환경으로 배치될 때 끝나지 않는다. 먼저 문제를 감지하기 위해 광범위하게 모니터링되고, 그 후 시스템이 생산 환경으로 배치된 후에 다양한 형태로 계속 테스팅된다.
8장에서 다루는 보안은 또 다른 횡단 관심이다. 조직 전반과 특정 시스템 전반을 포괄하는 환경에 존재하는 다양한 보안 통제 유형을 제시한다. 또한 보안의 성취와 관련된 다양한 역할과 이러한 역할이 보안 감사 시 어떻게 평가되는가를 알아본다.
보안이 품질의 유일한 관심 대상은 아니다. 9장에서는 데브옵스와 관련된 실천 방법과 또다른 품질들을 논의한다. 배포 파이프라인의 성능, 신뢰성, 변경 용이성 등의 주제를 다룬다.
3부의 마지막인 10장에서는 비즈니스 고려사항에 대해 알아본다. 데브옵스처럼 폭넓은 실천 방법은 관리자의 지원 없이는 적용될 수 없다. 비즈니스 계획은 이러한 지원을 획득하는 일반적인 수단이다. 데브옵스 적용을 위한 비즈니스 계획의 요소를 제시하고, 인수, 롤아웃(rollout), 그리고 측정이 진행되는 방법을 알아본다.
4부에서는 3개의 사례연구를 제시한다. 데브옵스 실천 방법을 구현한 조직들은 일부 비결을 알려준다. 11장은 비즈니스 지속성에 대한 목표를 위해 두 개의 데이터 센터를 유지하는 방법을 설명한다. 12장은 지속적인 배포 파이프라인에 대한 세부 사항을 설명한다. 그리고 13장은 조직이 마이크로서비스 아키텍처로 이전하는 방법을 설명한다.
5부에서 미래를 추측하며 마무리한다. 14장은 우리의 연구를 설명하고 연구가 어떻게 운영을 일련의 프로세스로 보는 것에 기반하는지를 논의한다. 15장은 향후 3~5년 동안 데브옵스 관점에서 어떻게 발전될 것인가에 대해 예측한다.

저자/역자 소개

지은이의 말

우리는 몇 년 동안 운영에서의 문제를 조사해 왔으며, 본질적으로 데브옵스 운동(DevOps movement)을 추적하고 있다. 데브옵스는 가트너의 과장 광고 곡선(Gartner Hype Curve)에 나타나고 있으며, 견고한 비즈니스적인 존재 이유를 갖고 있다. 우리는 IT 관리자 측면(예를 들어 소설, 『The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win』)과 프로젝트 관리자 측면(예를 들어 Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation)에서 논의를 발견할 수 있었다. 추가적으로 문화적인 변화와 조직 단위들 간의 장벽을 해체하는 것의 의미에 대한 수많은 자료들이 있다.
우리를 좌절시키는 것은 소프트웨어 아키텍트 측면의 자료가 아주 조금밖에 없다는 것이다. 운영자를 최상위 이해당사자로서 다루고, 그들의 요구사항을 듣는 것은 확실히 중요하다. 운영과 프로젝트 관리를 지원하는 도구를 이용하는 것 또한 중요하다. 그러나 우리는 이해당사자의 관리와 도구의 사용보다 중요한 것이 있다는 강한 느낌을 갖고 있다.
실제로 중요한 것이 있고, 바로 그것이 이 책에서 채우고자 하는 간격이다. 데브옵스는 디자인, 프로세스, 도구, 조직 구조 사이의 매혹적인 상호작용을 나타낸다. 우리는 두 가지 주요 질문에 대답하려고 한다. 데브옵스 목표를 달성하기 위해 아키텍트로서 해야하는 기술적인 결정들은 무엇인가? 데브옵스 공간에서 다른 액터들에게 영향을 미치는 것이 나에게는 어떤 영향을 미치는가?
이에 대한 대답은, 데브옵스 목표 달성은 당신의 시스템 아키텍처의 기본적인 변화들을 포함할 수 있다는 것이며, 당신 시스템을 생산 환경으로 보내고, 생산 환경에서 지원하기 위해서는 역할과 책임에서도 변화가 요구된다는 것이다.
소프트웨어 아키텍트가 그들이 설계하고 구축하는 시스템을 위해 비즈니스 환경과 목표를 이해해야 하는 것처럼 데브옵스를 이해하기 위해서는 기술적인 상황과 운영 상황은 물론, 조직적인 상황과 비즈니스 상황을 이해해야 한다.

지은이 소개

렌 베스(Len Bass)

호주 국립 정보통신기술 연구소(NICTA)의 수석 연구원이다. 카네기 멜론 대학의 소프트웨어 공학 연구소(SEI)에서 25년 동안 근무한 후 2011년 NICTA에 합류했다. 컴퓨터 과학 및 소프트웨어 엔지니어링의 다양한 주제에 대해 여러 종류의 책과 다양한 논문은 물론, 소프트웨어 아키텍처와 관련해 수상한 두 권의 책 『Software Architecture in Practice, Third Edition』 (애디슨 웨슬리, 2013)과 『Documenting Software Architectures: Views and Beyond, Second Edition』 (애디슨 웨슬리, 2011)의 저자다. 소프트웨어 개발과 연구에 50년 이상의 경험이 있으며, 운영체제, 데이터베이스 관리 시스템, 사용자 인터페이스 소프트웨어, 소프트웨어 아키텍처, 생산 라인 시스템, 컴퓨터 운영에 대한 많은 논문들을 작성했다. 과학적인 분석, 임베디드 시스템, 정보 및 금융 시스템 등 여러 도메인에서 작업과 컨설팅을 해왔다.

잉고 웨버(Ingo Weber)

뉴 사우스 웨일즈(UNSW) 대학의 CSE에서 수석 보조 강사이며, 호주 시드니에 있는 NICTA의 소프트웨어 시스템 연구 그룹의 선임 연구원이다. NICTA 이전에 UNSW와 독일 카를스루에 SAP에서 근무했다. 연구 분야는 클라우드 컴퓨팅, 데브옵스, 비즈니스 프로세스 관리, 인공지능(AI) 등이다. 60편 이상의 상호 심사 논문을 발표했으며, 권위 있는 여러 과학 저널과 컨퍼런스에서 리뷰어나 프로그램 위원회 회원을 역임했다. 박사학위를 보유하고 있으며, 카를스루에 대학을 졸업했고, 애머스트의 메사추세츠 대학에서 석사학위를 받았다.

리밍 쭈(Liming Zhu)

NICTA의 연구 그룹 리더이자 수석 연구원이다. 뉴 사우스 웨일즈 대학(UNSW)과 시드니 대학 모두에서 공동 지위를 유지하고 있다. 림밍은 80편 이상의 상호 심사 논문을 발표했다. UNSW에서 소프트웨어 엔지니어링 박사학위를 취득하기 전 소프트웨어 산업에서 다양한 기술을 리드하는 위치에서 일했다. 호주 표준 IT-015(시스템 및 소프트웨어 공학)의 위원회 멤버이며, ISO/SC7에 기여하고 있다. 림밍의 연구 분야는 소프트웨어 아키텍처와 신뢰성 시스템을 포함한다.

옮긴이의 말

소프트웨어와 관련된 모든 분야가 빠르게 변하고 있다. 개발 언어부터 프로세스 개발, 조직과 문화 모두가 원하든 원하지 않든 빠르게 변화한다. 이러한 변화는 단순히 소프트웨어 아키텍트가 제품을 개발하는 것 이상을 요구한다. 또한 운영자는 소프트웨어를 관리하고 시스템을 운영하기 위해서 소프트웨어 전반에 대해 더 많이 알아야 한다. 이와 같은 상황에서 데브옵스(DevOps)의 도입은 필연적인 결과인지도 모른다. 데브옵스는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 의미한다. 데브옵스는 소프트웨어 개발과 운영 조직 간의 협력을 통해 소프트웨어 제품과 서비스를 빠른 시간에 개발하고 배포하는 것을 목적으로 하고 있다. 이 책은 데브옵스에 관한 사항을 기초부터 사례까지 전반적인 내용을 포함하고 있어, 데브옵스에 관심 있는 사람이라면 누구에게나 좋은 참고서가 될 것이라 생각한다. 이 책을 통해 데브옵스에 대해 품었던 많은 궁금증이 해소되기를 바란다. - 김영기

데브옵스를 처음 접했을 때, 이렇게 파격적인 시스템이 과연 실현 가능한 것인지, 그리고 개발자들이 이처럼 파괴적이기까지 한 업무 방식을 수용할 수 있을지 의구심이 들었다. 애자일 개발에서는 대부분 개발 자체에 집중하는 것에 무게가 실리는 반면, 데브옵스는 소비자가 필요로 하는 소프트웨어를 빠르게 전달하는 방법에 관심을 두고 있다. 전통적인 조직에서는 개발자가 고객으로부터 직접 요구 사항을 수집하는 것이 거의 불가능하며, 공정과 도구를 관리하는 별도의 조직이 있어 개발자가 원하는 공정과 도구를 적용하기 어렵다. 개발이 지속적으로 진행되면 자동화된 테스트 시스템이 필요해지고, 개발자에게 고객의 피드백을 빠르고 정확하게 전달할 수 있는 시스템이 더욱 절실해진다. 잘 설계된 공정과 준비된 도구는 애자일 개발에 날개를 달아줄 것이며, 더 나아가 개발 팀과 고객이 직접 소통을 한다면 더 좋은 소프트웨어를 더 빨리 개발할 수 있을 것이다. 이미 애자일 방법론을 통해 프로젝트를 수행함에도 불구하고 생산성이나 고객 만족도에 문제가 있다고 느낀다면 이 책을 통해 데브옵스의 도입을 고려해 볼 수 있다. - 박득형

옮긴이 소개

김영기

15년 이상 SE 업무를 담당하고 있으며, 정적 분석 및 구조 분석 등 소프트웨어 품질 개선 작업을 해오고 있다. 사업부 소프트웨어 교육 강사로도 활동 중이며, 현재 삼성전자 네트워크 사업부에서 소프트웨어 개발 인프라와 구조 분석을 담당하고 있다. 개발자 역량 강화와 개발 조직 구성에 관심이 많으며, 시스템 관리, 데이터베이스, 테스트와 애자일 등 소프트웨어 관련 다수의 인증을 보유하고 있다.

박득형

KAIST에서 통신 및 네트워크 분야로 박사학위를 취득한 후 벤처기업에서 네트워크 프로세서 및 임베디드 프로세서를 개발했다. 이후 삼성전자에서 운영체제 커널부터 애플리케이션까지 다양한 영역에서 개발 업무를 담당했고, 개발 인프라 및 프로세스 관리, 애자일(Agile)방법론 등 SE 분야의 경력이 있다.

목차

목차
  • 1부. 배경 지식
  • 1장. 데브옵스란?
    • 1.1 소개
    • 1.2 왜 데브옵스인가?
    • 1.3 데브옵스 관점
    • 1.4 데브옵스와 애자일
    • 1.5 팀 구성
    • 1.6 조정
    • 1.7 장벽/장애물
    • 1.8 요약
    • 1.9 더 읽을거리

  • 2장. 플랫폼으로서의 클라우드
    • 2.1 소개
    • 2.2 클라우드의 기능
    • 2.3 고유한 클라우드 기능에 대한 데브옵스 결과
    • 2.4 요약
    • 2.5 더 읽을거리

  • 3장. 운영
    • 3.1 소개
    • 3.2 운영 서비스
    • 3.3 서비스 운영 기능
    • 3.4 지속적인 서비스 개선
    • 3.5 운영과 데브옵스
    • 3.6 요약
    • 3.7 더 읽을거리

  • 2부. 배포 파이프라인
  • 4장. 전반적인 아키텍처
    • 4.1 데브옵스 사례는 구조적인 변경을 필요로 하는가?
    • 4.2 전반적인 아키텍처 구조
    • 4.3 마이크로서비스 아키텍처에 대한 품질 논의
    • 4.4 아마존(Amazon)의 팀에 대한 규칙
    • 4.5 기존 시스템에 마이크로서비스 적용
    • 4.6 요약
    • 4.7 더 읽을거리

  • 5장. 구축과 테스팅
    • 5.1 소개
    • 5.2 배포 파이프라인을 통한 시스템 이동
    • 5.3 횡단 측면
    • 5.4 개발과 사전 커밋 테스팅
    • 5.5 빌드와 통합 테스팅
    • 5.6 UAT/스테이징 테스팅/성능 테스팅
    • 5.7 생산
    • 5.8 사고
    • 5.9 요약
    • 5.10 더 읽을거리

  • 6장. 배포
    • 6.1 소개
    • 6.2 배포 관리 전략
    • 6.3 Logical Consistency
    • 6.4 패키징
    • 6.5 다양한 환경에 배포
    • 6.6 부분적인 배포
    • 6.7 롤백
    • 6.8 도구
    • 6.9 요약
    • 6.10 더 읽을거리

  • 3부. 횡단 관심 사항
  • 7장. 모니터링
    • 7.1 소개
    • 7.2 모니터링의 대상
    • 7.3 모니터링 방법
    • 7.4 모니터링 구성 변경 시기
    • 7.5 모니터링 데이터 해석
    • 7.6 도전 사항
    • 7.7 도구
    • 7.8 모니터링 데이터에서 이상 상태 진단 (Platformer.com 사례)
    • 7.9 요약
    • 7.10 더 읽을거리

  • 8장. 보안과 보안 감사
    • 8.1 보안이란?
    • 8.2 위협
    • 8.3 보호돼야 하는 자원
    • 8.4 보안 역할과 활동
    • 8.5 계정 관리
    • 8.6 접근 제어
    • 8.7 감지, 감사, 서비스 거부
    • 8.8 개발
    • 8.9 감사
    • 8.10 애플리케이션 설계 고려 사항
    • 8.11 배포 파이프라인 설계 고려 사항
    • 8.12 요약
    • 8.13 더 읽을거리

  • 9장. 품질 속성
    • 9.1 소개
    • 9.2 반복성
    • 9.3 성능
    • 9.4 신뢰성
    • 9.5 복구 가능성
    • 9.6 상호 운용성
    • 9.7 테스트 용이성
    • 9.8 변경 용이성
    • 9.9 요약
    • 9.10 더 읽을거리

  • 10장. 비즈니스 고려 사항
    • 10.1 소개
    • 10.2 비즈니스 사례
    • 10.3 데브옵스 사례에 대한 측정과 규정 준수
    • 10.4 개발과 운영 사이의 상호작용점
    • 10.5 요약
    • 10.6 더 읽을거리

  • 4부. 사례연구
  • 11장. 다중 데이터센터 지원
    • 11.1 소개
    • 11.2 현재 상태
    • 11.3 비즈니스 로직과 웹 계층
    • 11.4 데이터베이스 계층
    • 11.5 기타 인프라스트럭처 도구
    • 11.6 데이터센터 전환
    • 11.7 테스팅
    • 11.8 요약
    • 11.9 더 읽을거리

  • 12장. 대규모 엔터프라이즈를 위한 지속적인 배포 파이프라인 구현
    • 12.1 소개
    • 12.2 조직 환경
    • 12.3 지속적인 배포 파이프라인
    • 12.4 CD 파이프라인 기반에 보안 사항을 추가해 이미지 굽기
    • 12.5 고급 개념
    • 12.6 요약
    • 12.7 더 읽을거리

  • 13장. 마이크로서비스로의 이전
    • 13.1 애틀라시안 소개
    • 13.2 마이크로서비스 배포를 위한 플랫폼 구축
    • 13.3 BlobStore: 마이크로서비스 예제
    • 13.4 개발 프로세스
    • 13.5 BlobStore 진화
    • 13.6 요약
    • 13.7 더 읽은 거리

  • 5부. 미래로의 이동
  • 14장. 프로세스로서의 운영
    • 14.1 소개
    • 14.2 동기 부여와 개요
    • 14.3 오프라인 액티비티
    • 14.4 온라인 액티비티
    • 14.5 에러 진단
    • 14.6 모니터링
    • 14.7 요약
    • 14.8 더 읽을거리

  • 15장. 데브옵스의 미래
    • 15.1 소개
    • 15.2 조직적인 이슈
    • 15.3 프로세스 이슈
    • 15.4 기술 문제
    • 15.5 에러 보고와 복구는 어떻게 하는가?
    • 15.6 맺음말
    • 15.7 더 읽을거리

도서 오류 신고

도서 오류 신고

에이콘출판사에 관심을 가져 주셔서 고맙습니다. 도서의 오탈자 정보를 알려주시면 다음 개정판 인쇄 시 반영하겠습니다.

오탈자 정보는 다음과 같이 입력해 주시면 됩니다.

(예시) p.100 아래에서 3행 : '몇일'동안 -> 며칠동안

정오표

정오표

2016. 8. 22 수정 사항

[p.32: 그림 1.1 '빌드']
지속적인 통한 지원
->
지속적인 통합 지원

2016. 9. 6 수정 사항

[p.197: 4행]
7장에서 는
->
7장에서는

[p.199: 4~5행]
효과적이 않다.
->
효과적이지 않다.

[p.322: 첫 행]
여유(redundancy)을
->
여유(redundancy)를

[p.323: 1행]
북미 대륙을 반대편에 위치하고 있지만
->
북미 대륙의 양 쪽 끝에 위치하고 있지만