DevOps 25

2025 DevOps의 본질과 최신 트렌드

정명훈 (구글 클라우드)IT에서의 효율성IT에서 효율성을 얻을 수 있는 최고의 방법은 무엇일까? 반복과 재사용이다. 아날로그 현실 세계와 달리 디지털 기반의 IT 세계에서는 동일한 결과물을 만드는 것이 매우 쉽다. 친구나 동료가 말한 목소리를 기억하고 전달하는 아날로그 방식은 내용을 빼먹기도 하지만, 디지털로 남겨지는 스마트폰 녹음은 10년이 지나도 그대로 전달할 수 있다. 한 번 녹음된 디지털 음성은 10개를 복제하던 100개를 복제하던 품질이 그대로 유지된다.  IT 발전의 역사는 반복과 재사용을 통한 효율화의 역사이다. 어떻게 하면 하드웨어 또는 소프트웨어를 모듈 단위로 만들어 재사용할 수 있게 고민한다. 함수를 통해서, 컴포넌트를 통해서 그리고 API를 통해서 소프트웨어를 재사용한다. 인텔과 AM..

SRE #6 - 운영에서 반복적인 노가다 Toil

SRE #6-운영에서 반복적인 노가다 Toil조대협 (http://bcho.tistory.com)ToilToil의 사전적인 뜻은 “노역"이라는 뜻을 가지고 있는데, 비속어를 사용해서 표현하자면 운영 업무에서의 “노가다" 정도로 이해하면 된다. Toil 에 대한 정의를 잘 이해해야 하는데, Toil은 일종의 반복적인 쓸모없는 작업 정도로 정의할 수 있다.경비 처리나, 회의, 주간 업무 보고서 작성과 같은 어드민 작업은 Toil에 해당하지 않는다. Toil은 운영상에 발생하는 반복적인 메뉴얼 작업인데, 다음과 같은 몇가지 특징으로 정의할 수 있다.메뉴얼 작업이고 반복적이어야함Toil의 가장 큰 특징은 사람이 직접 수행하는 메뉴얼 작업이라는 것이다. 그리고 어쩌다 한번이 아니라 지속적으로 발생하는 반복적인 작..

SRE #5 - Error budget

SRE #5 - Error budget 조대협 (http://bcho.tistory.com) SLI와 SLO에 대한 개념을 이해 했으면 다음은 Error budget에 대한 개념을 이해해야 한다.Error budget은 단순하게 생각하면Error budget = [100% - availability target] 와 같다. 예를 들어 설명하면, 한달에 SLO가 99.999%를 목표치로 설정했다면, 한달간 SLO는 0.001%의 다운 타임을 허용하게되고, 이 0.001%가 Error budget이된다. 위의 표는 가용성에 따라서, 허용되는 장애 시간을 정리해놓은 표이다.앞의 예제에서 99.999% 가용률을 목표로 봤을 때 허용되는 장애시간은, 0.001%로 다운 타임은 한달에 25.9 초만 허용된다. 그러..

Azure Devops - 스크럼 테스크 관리, 빌드, 소스코드 리파지토리, 테스트툴

Azure Devops 조대협 (http://bcho.tistory.com) 페이스북 타임라인을 보다가. “Azure Devop가 나왔는데. JIRA 따위는 꺼져버려.." 라는 말이 있어서 몬가 궁금해서 살펴봤는데 이거 정말 물건이다. MS가 요즘 많이 변하하고 있다고 들었는데, 정말 잘 만든 제품인듯 Devops라고 해서 Monitoring,Logging쪽 제품으로 생각했는데, Task management, 부하 테스트, git repo & 빌드, 빌드 파이프라인, 웹테스트 툴 등이 들어있는데, 전반적으로 정말 좋은듯. 예전 IBM의 Jazz 플랫폼과 컨셉은 비슷한데, UI나 기능이나 반응 속도나 압권이고 거기다가 일부 플랜은 무료다!! 나 같은 개인 개발자(집에서는)에게는 딱이 아닐까 싶다. 대충 후..

ALM 2019.05.15

SRE #4-예제로 보는 SLI/SLO 정의 방법

SRE #4-예제로 살펴보는 SLI/SLO 정의 방법조대협 (http://bcho.tistory.com) 앞에서 SRE의 주요 지표인 SLO/SLI의 개념에 대해서 설명하였는데, 그러면 실제 서비스에서는 어떻게 SLO/SLI를 정의하는지에 대해서 알아본다.SLI는 사용자 스토리당 3~5개 정도가 적당하다. 사용자 스토리는 로그인, 검색, 상품 상세 정보와 같이 하나의 기능을 의미한다고 보면된다. 아래 그림과 같은 간단한 게임 서비스가 있다고 가정하자. 이 서비스는 웹사이트를 가지고 있고, 그리고 앱을 통해서 접근이 가능한데, 내부적으로 API 서비스를 통해서 서비스가 된다. 내부 서비스에는 사용자 랭킹(Rank ), 사용자 프로파일 (User profiles) 등의 서비스가 있다. 이 서비스에서 "사용자..

SRE #2-SRE는 어떻게 일하는가?

SRE는 어떻게 일하는가? 조대협 (http://bcho.tistory.com) 이글은 앞의 글 "SRE/DEOPS의 개념과 SRE는 무엇을 하는가?" (https://bcho.tistory.com/1325) 와 연결된 글입니다.How SRE does Devops?그럼 SRE들은 이런한 일들을 어떤 방법으로 수행할까? 앞에서 SRE가 해야 하는 일에 대해서 설명하면서 각각에 대해서 일부를 언급했지만, 다시 SRE가 해야하는 일을 하기 위해서는 어떻게(How) 해야 하는지에 대해서 다시 정리해보자.SRE는 앞에서 언급한 다섯가지 일을 하기 위해서 아래와 같이 다섯 가지 방법을 사용한다. (참고 : 구글 NEXT 발표자료 https://drive.google.com/file/d/1iOMaYIwlUBiGoG2..

SRE - #1 SRE/DEVOPS의 개념과 SRE는 무엇을하는가?

Site Reliability Engineering(SRE)#1 SRE/DEVOPS의 개념조대협 (http://bcho.tistory.com)배경Devops는 운영팀과 개발팀을 하나의 팀으로 묶어놓고 전체적인 개발 사이클을 빠르게 하고자 하는 조직 구조이자 문화이다. 이 Devops라는 컨셉이 소개된지는 오래되었지만, Devops의 개념 자체는 명확하지만 이 Devops를 어떻게 실전에 적용할것인 가는 여전히 어려운 문제였다.(예전에 정리한 Devops에 대한 개념들 1 , 2) 예전 직장들에 있을때 Devops의 개념이 소개되었고 좋은 개념이라는 것은 이해하고 있었지만, 여전히 운영팀은 필요하였고, 그 역할이 크게 바뀌지 않았다. 심지어 Devops를 하는 기업들도 보면 기존 개발팀/운영팀이 있는데, ..

구글의 Devops 운영 모델 SRE (Site Reliability Engineering)

SRE는 구글의 Devops의 프랙티스 로 구글의 서비스에 대한 배경과 철학을 읽을 수 있다.SRE의 기본 사상중의 하나는 서비스의 안정성이 완벽할 수 없으며, (아니 완벽하지 않게 만들며) 장애를 허용하는 모델이다.고 가용/고 성능 시스템을 만들기 위해서는 그만큼 많은 개발에 대한 노력이 소요되는데, 이로 인해서 기능 개발에 대한 속도가 느려지기 때문에, 사용자가 납득할만한 수준의 가용성을 제공하되 개발의 속도를 유지하는 철학이다.배경을 살펴보면 구글은 모바일을 기반으로 한 B2C 서비스를 주력으로 하기 때문에, 서비스가 99.999%의 가용성을 제공하더라도, 스마트폰과 통신망 자체가 그정도의 안정성을 제공하지 않기 때문에, 백앤드 서비스가 높은 가용성을 제공하더라도 사용자가 느끼는 가용성은 그 정도 ..

Zipkin을 이용한 MSA 환경에서 분산 트렌젝션의 추적 #1

Zipkin을 이용한 MSA 환경에서 분산 트렌젝션의 추적 #1조대협 (http://bcho.tistory.com) 개념분산 트렌젝션이랑 여러개의 서비스를 걸쳐서 이루어 지는 트렌젝션을 추적하는 기능을 정의한다.마이크로 서비스 아키텍쳐 (이하 MSA)와 같은 구조에서는 하나의 HTTP 호출이 내부적으로 여러개의 서비스를 거쳐서 일어나게 되는데, 그러면 어느 구간에서 병목이 생기는지 추적하기가 어려워진다.아래 그림을 보면 클라이언트가 Service A를 호출하고, Service A 가 Service B,D 를, Service B가 Service C를 호출한다. 이렇게 트렌젝션이 여러 컴포넌트의 조합을 통해서 발생하기 때문에 Jennifer와 같은 전통적인 APM (Application Performance..