기록

[서평] 깃허브 액션으로 구현하는 실전 CI/CD 설계와 운영

12.tka — Sun, 13 Jul 2025 23:20:46 +0900

안녕하세요.

블로그에 글을 써야지 다짐만 하다가, 어느새 1년이 훌쩍 지나버렸네요.

이번에 깃허브 액션 관련 책을 읽을 기회가 생겨, 오랜만에 글을 작성하였습니다.

깃헙 액션, CI/CD 관심 있으셨던 분들께 조금이나마 도움이 되길 바랍니다.

책 구성

책은 기초편, 실전편, 응용편 총 3부로 구성되어 있어요.

개인적으로 기초편 내용만 제대로 익혀도, 대부분의 상황에서 유용한 CI 구축이 가능하다고 느꼈습니다.

물론 실전편과 응용편까지 함께 보면, 기본적인 CI 구성뿐만 아니라 유지 보수가 쉬운 형태로 점차 개선할 수 있을 것 같아요.

또한, 이 책은 단순히 깃허브 액션만 다루는 것이 아니라, CI/CD를 구축한다는 것이 어떤 의미인지에 대해서도 자연스럽게 배울 수 있어 더욱 유용하였습니다.

자세한 목차 내용은 링크 참고 부탁드려요 :)

인상 깊었던 내용

회사 내에서 실용적으로 활용할 수 있는 내용들이 특히 인상 깊었습니다.

1) 필터 설정

특정 경로를 제외하거나, 지정한 브랜치에 해당할 때만 워크플로가 실행되도록 필터링할 수 있습니다.

예를 들어, 에어플로우 DAG 파일을 관리하는 코드에서는 dags/ 폴더 하위 파일이 변경되더라도 워크플로우가 불필요하게 실행되지 않도록 하고 싶을 수 있습니다. 이처럼 변경 감지를 정교하게 제어해야 하는 상황은 실무에서 자주 발생하기 때문에 인상 깊었습니다.

2) concurrency를 통한 자동 취소

동일 풀 리퀘스트에서 동일 워크플로가 여러 개 실행되는 경우 오래된 워크플로는 취소할 수 있습니다. 가장 최근 내용을 제외하고는 큰 의미가 없기 때문에 이를 활용하면 불필요한 실행을 줄이고 워크플로를 훨씬 효율적으로 운영할 수 있습니다.

3) 빠르게 실행하기

CI는 늦어도 10분 이내로 완료해야 한다고 말하고 있습니다. 현재 30분 이상 발생하는 경우가 있는데, 책에 나와있는 병렬 실행을 참고하여 10분 이내로 완료되도록 개선하는 것을 목표로 하고 있습니다. 책에서도 계속 강조하지만 대충 넘어가는 경우를 더 이상 만들지 않으려고 합니다.

4) 브랜치 보호

지정한 규칙에 기반에서 브랜치를 보호하는 기능입니다. 강제로 머지하는 경우를 예방할 수 있는 것이 가장 유익하다고 생각하였습니다.

이외에도 Dependabot 을 활용한 의존성 관리 지원, 깃허브 액션을 통한 자동 머지 기능, 릴리스 노드 자동 생성이 회사 내에서 실용적으로 활용할 수 있는 내용이라고 생각하였습니다.

클라우드는 사용하고 있지 않아서 해당 내용은 간략하게 확인하였는데요. AWS 등의 클라우드 서비스 사용하시는 분들에게는 많은 도움이 될 것 같습니다.

이런 분께 추천합니다

깃허브 액션은 기술적으로 어려운 내용이 아니기 때문에 모든 개발자에게 추천합니다.

초기 설정이 다소 귀찮을 수 있지만, 막상 적용하면 개발 속도가 오히려 상승하기 때문에 꼭 읽어보시고 적용해 보는 것을 추천드립니다.

✍ 한 줄 정리

깃허브 액션을 모르겠다면(알아도) 깃허브 액션으로 구현하는 실전 CI/CD 설계와 운영을 읽어보자 ☺️

[Python] Excel 파일 암호화

12.tka — Sun, 12 Nov 2023 22:05:36 +0900

1. 개요

파이썬을 사용하여 Excel 파일을 생성하거나 편집하는 작업은 많은 분들이 경험해 보셨을 겁니다. 하지만 Excel 파일 암호화를 수행한 적은 얼마나 되시나요? 물론 Excel 응용 프로그램을 통해서는 간단히 암호 설정이 가능하지만, 파이썬 코드를 사용해 이를 수행한 경우는 드물 것입니다. 따라서 이번 글에서는 파이썬 코드로 Excel 파일에 암호를 설정하는 방법에 대해 알아보겠습니다.

2. xlwings

xlwings는 파이썬에서 Excel 파일을 다룰 수 있게 해주는 라이브러리입니다. 이를 활용하면 쉽게 Excel 파일 암호화를 수행할 수 있습니다. (참고)

3. 예시

코드를 작성하기 전에, 우선 xlwings 라이브러리를 설치해야 합니다. 이는 간단히 pip install xlwings 명령어를 통해 수행할 수 있습니다.

3.1 이미 존재하는 엑셀 파일 암호화

import xlwings as xw

book = xw.Book('encryption_test.xlsx')
book.save('encryption_test.xlsx', password='1234')
book.close()

3.2 새로운 엑셀 파일 암호화

import xlwings as xw

book = xw.Book()
book.save('encryption_test.xlsx', password='1234')
book.close()

Ch29. 방해 요소에 대한 대처

12.tka — Sun, 5 Nov 2023 18:48:54 +0900

운영 업무의 부하

복잡한 시스템에서 운영 업무의 부하란 시스템이 제대로 동작하는 상태를 유지하기 위해 반드시 해야만 하는 일들을 의미한다. 복잡한 시스템을 만든 사람이 완벽하지 못한 만큼, 시스템 자체도 완벽할 수 없다. 이런 시스템에서 발생하는 운영 업무들을 관리하고 있다면, 그 시스템을 만든 사람 역시 완벽하지 않다는 점을 항상 기억하자. 운영 부하는 긴급 호출, 티켓, 진행 중인 운영 업무 세 가지로 분류할 수 있다.

긴급 호출

운영 환경에서 발생하는 경고나 장애에 대처하기 위한 것으로, 긴급한 상황이 발생했을 때 생겨난다. 이들은 대부분 단조롭고, 반복적으로 발생하며, 약간은 생각을 해야 한다. 긴급 호출은 그에 상응하는 기대 응답 시간(SLO)이 정해져 있으며, 대부분 분단위로 측정한다.

긴급 호출은 통상 비상 대기 요원들이 전담 관리한다. 즉, 한 사람이 긴급 호출에 응답하고 해당 장애를 관리한다. 우선 비상 대기 엔지니어는 고객 지원 응대, 제품 개발자로의 상향 전파 등의 업무를 수행하기도 한다. 구글은 긴급 호출로 인해 팀이 방해를 받는 경우를 최소화하고 장애를 그냥 방관만 하는 상황이 발생하지 않도록 엔지니어들이 돌아가며 한 명씩 비상 대기 업무를 수행하도록 규정하고 있다.

티켓

고객의 요청에 따라 수행해야 할 업무를 정의한다. 티켓 역시 가대 응답 시간(SLO)를 가지고 있지만 그 응답 시간은 주로 시간, 일 혹은 주 단위로 측정한다.

티켓을 관리하는 방법은 SRE팀에 따라 몇 가지로 나뉜다. 비상 대기 업무 중에 우선 비상 대기 요원이 티켓을 처리할 수도 있고 보조 비상 대기 요원이 티켓을 처리할 수도 있다. 혹은 비상 대기 업무를 수행하지 않는 엔지니어가 티켓을 전담해서 처리하는 팀도 있다. 티켓은 임의의 팀원에게 자동으로 할당되기도 하고, 팀원들이 알아서 티켓이 등록되는 즉시 처리하기도 한다.

진행 중인 운영 업무

팀이 보유한 코드 혹은 플래그의 배포, 갑작스러운 업무에 대한 대응, 빠른 처리를 위한 고객의 요구 사항 등의 활동이 포함되어 있다. 특별한 SLO를 정의하고 있지는 않더라도, 이런 작업은 분명히 방해 요소로 작용한다.

진행 중인 운영 업무 역시 다양한 방법으로 관리된다. 비상 대기 엔지니어가 해당 업무를 수행하기도 하고 어떤 경우는 팀원들에게 필요한 시점에 각 역할을 맡기기도 하며, 비상 대기 엔지니어가 비상 대기 수행 기간이 끝난 후에도 계속해서 해당 업무에 대한 책임을 유지하기도 한다.

방해 요소의 관리 방법을 결정하기 위한 요소들

방해 요소의 기대 응답 시간(SLO), 대부분 나중으로 미뤄놓는 방해 요소의 수, 방해 요소의 심각도 수준, 방해 요소의 빈도, 특정 방해 요소를 처리하기 위해 필요한 사람의 수 등의 지표를 활용해서 방해 요소의 관리 방법을 결정한다.

산만한 주변 환경

엔지니어들은 산만한 주변 환경으로 인해 여러 가지 방식으로 인지적 몰입 상태를 이루지 못한다. 주의가 분산되는 상황을 최소화하기 위해서는 컨텍스트 전환을 최소화해야 한다. 시간을 나누어 쓴다는 것은 각자가 매일 하루의 업무를 프로젝트 업무만 진행할 것인지 아니면 방해 요소를 처리하는 일만 할 것인지를 스스로 알고 있어야 한다는 것을 의미한다.

결론

팀 차원에서 해결할 수 있는 방해 요소는 최대한 해결하는 것이 좋을 것 같다. 하지만 개인적인 차원에서의 방해 요소 해결 방법은 사람마다 너무 다르다고 생각하기에 책 내용은 참고만 하고 자신에게 적합한 방법을 찾아나가는 것이 좋을 것 같다.

Ch27. 대용량 환경에서의 신뢰할 수 있는 제품 출시

12.tka — Sun, 5 Nov 2023 18:28:40 +0900

인터넷 기업의 출시 주기

전통적인 기업들은 새 제품을 출시하는 비율이 상당히 낮다. 반면, 인터넷 기업의 출시 주기는 이와는 현저히 다르다. 제품을 신속하게 출시하는 것이 훨씬 쉬운데, 그 이유는 새로운 기능을 담은 소프트웨어를 고객의 개별 컴퓨터에 설치하는 것이 아니라 우리가 보유한 서버에 새로운 기능을 출시하는 것이기 때문이다.

이처럼 빠른 변화 속도는 능률적인 출시 절차를 정의해야 하는 근본적인 이유와 기회를 제공한다. 매 3년마다 새로운 제품을 출시하는 기업이라면 세밀한 출시 절차 따위는 필요치 않다.

출시 조율 엔지니어링 (LCE)

구글은 제품 출시의 어려움을 타개하기 위해 SRE 조직 내에 새로운 제품이나 기술을 출시하기 위한 기술적인 부분을 수행할 전문 컨설팅팀을 구성했다. 이들은 구글이 원하는 내구성, 확장성 및 신뢰성 표준을 만족할 수 있는 제품을 안정적이고 빠르게 추구할 수 있도록 개발자들을 돕는 업무에 특화되어 있다. (경험의 전파, 교차 기능, 객관성 ...)

LCE는 직접 솔루션을 구현하는 것보다는 기존의 인프라스트럭처를 빌딩 블록처럼 사용할 것을 권한다. 그리고 상당히 깐깐한 승인 절차를 요구하는 제품 소유자들과의 협업을 통해 승인을 위한 요구 사항을 간소화하고 공통적인 경우에 대한 승인을 자동화하기도 한다.

LCE는 서비스의 장애 없이 신속하게 출시하는 역할을 담당하며 출시 도중 장애가 발생하더라도 다른 제품이 영향을 받지 않도록 조치한다. 또한 제품의 시장 출시 시간을 단축하기 위해 장애가 발생할 때마다 이해관계자들에게 적절히 통보하는 역할도 담당한다.

출시 절차 마련하기

구글은 10년 이상 출시 절차를 연마해왔다. 그 시간 동안 구글은 성공적인 출시 절차를 특정 짓는 몇 가지 조건을 확인했다.

경량(lightweight): 개발자들이 접근하기 쉬워야 한다.
견고함(robust): 오류를 명확하게 잡아내야 한다.
주도면밀함(thorough): 중요한 부분은 일관적이고 재현 가능하게 다루어야 한다.
확장성(scalable): 더 많은 출시를 단순화하고 복잡한 출시를 줄여야 한다.
순응성(adaptable): 일반적인 종류의 출시와 새로운 종류의 출시를 모두 잘 지원할 수 있어야 한다.
간결성(simplicity): 기본적인 것들을 완수한다. 모든 우발적 가능성에 대한 계획을 세우지는 않는다.
직접 부딪히기(A high touch approach): 경험이 있는 엔지니어들이 각 출시별로 절차를 최적화하도록 한다.
빠른 공통 경로(fast common paths): 항상 공통적인 패턴을 따르는 출시의 종류를 정의하고 이 종류의 출시를 위한 간소화된 출시 절차를 제공한다.

그리고 문제를 해소하고 다양한 학습을 통해 일관성과 완전함을 갖추기 위해 출시 확인목록을 사용한다. ~~(참고로 구글의 출시 확인목록에 새로운 질문을 추가하기 위해서는 부사장으로부터 승인을 받아야 한다)~~

안정적인 출시를 위한 기법들

1. 점진적이고 단계적인 출시

: 시스템 관리 분야의 격언 중 하나는 "운영 중인 시스템은 절대 바꾸지 마라"다. 모든 변경은 위험을 의미하며 위험은 시스템의 안정성을 확보하기 위해서는 최소화해야 할 요소다. 이와 관련된 예시로는 카나리 배포와 초청 시스템이 있다.

2. 기능 플래그 프레임워크

: 새로운 기능을 0%부터 100%의 사용자들에게 점진적으로 출시하기 위해 디자인된 것이다.

3. 클라이언트 동작의 오용에 대처하기

: 클라이언트 동작의 오용(재시도, 특정 시간 요청 집중 ...)을 대처하기 위해 미리 준비해야 한다.

4. 과부하 시의 동작과 부하 테스트

: 서비스 과부하 관련 테스트는 제품의 안정성은 물론 수용량 계획에 있어서도 가치가 크다.

결론

빠르게 성장하며 제품과 서비스의 변화율이 높은 기업은 출시 조율 엔지니어링 역할을 도입하는 것이 큰 도움이 될 것이라고 말한다. 현재 사내 시스템을 주로 운영하고 있는 나에게는 크게 와닿지는 않는 내용이었다. 배포를 하기 위해서 그렇게 큰 노력이 필요하지 않기 때문이다. 하지만 구글을 비롯해서 전사적으로 운영하는 서비스라면 출시 조율 엔지니어링이 있는 것도 나쁘지 않겠다는 생각이 들었다.

Ch23. 치명적인 상태 관리하기: 신뢰성을 위한 분산에 대한 합의

12.tka — Sun, 29 Oct 2023 17:52:53 +0900

분산 시스템

분산 컴퓨팅 또는 분산 데이터 베이스로 알려져 있다. 하나의 분산 시스템은 서로 다른 머신들에 위치해 있는 독립된 컴포넌트들의 묶음이며 이 묶음은 하나의 공통된 목적을 달성하기 위해 서로 메시지를 주고받는다.

분산에 대한 합의

신뢰할 수 있는 고가용성 시스템을 효과적으로 구축하기 위해 분산에 대한 합의가 필요하다. 분산에 대한 합의 문제는 신뢰할 수 없는 네트워크에 연결된 프로세스의 그룹들이 원하는 수준의 합의점에 도달하는 문제를 다루는 것이다. 예를 들어 분산 시스템의 여러 프로세스들은 분산 록이 발생했든, 아니면 큐의 메시지가 이미 처리되었든지 여부와는 무관하게 설정 중에서 중요한 부분들을 일관되게 확인할 수 있어야 한다. 이는 분산 컴퓨팅 분야에서는 매우 기본적인 개념이다.

CAP 이론

CAP 이론은 분산 시스템은 일관성(Consistency), 가용성(Availability), 분할 허용성(Partition Tolerance) 세 가지 속성 중에서 동시에 두 가지 속성만을 만족시킬 수 있다고 주장한다. 예를 들어, 일관성과 가용성을 모두 만족시키려고 하면, 네트워크 분할에 대한 허용성이 낮아진다. 반대로, 가용성과 분할 허용성을 모두 만족시키려고 하면, 일관성이 낮아질 수 있다.

일관성(Consistency): 모든 노드에서 동시에 같은 데이터를 보여줘야 함
가용성(Availability): 모든 요청이 성공 또는 실패와 상관없이 응답을 받아야 함
분할 허용성(Partition Tolerance): 네트워크 분할이 발생하더라도 시스템이 계속해서 정상적으로 작동해야 함

합의가 필요한 이유

책에서는 분리된 뇌 문제, 사람이 개입해야 하는 장애 조치, 그룹-멤버십 알고리즘의 오류 예시를 통해서 합의가 필요한 이유를 말하고 있다. 결론적으로 말하자면 분산 시스템에서의 합의는 시스템의 일관성, 신뢰성, 안정성을 보장하고, 장애에 대한 허용성을 향상하며, 여러 노드 간의 작업을 효과적으로 동기화하고 조정하는 데 필수적이기 때문에 필요하다고 생각한다.

합의 알고리즘 (Paxos)

Paxos는 제안 -> 제안 전파 -> 제안 수락 혹은 거부 -> 합의 도달 -> 학습 -> 실행 순으로 동작한다.

제안: 제안자는 특정 값을 합의하고자 할 때, 고유한 일련번호와 함께 제안을 만든다. (일련번호는 다른 제안과 구별하기 위해 사용, 높은 일련번호를 가진 제안이 우선)
제안 전파: 제안자는 만들어진 제안을 수락자들에게 보낸다.
제안 수락 혹은 거부: 제안이 수락자에게 도착했을 때, 제안의 일련번호가 수락자가 마지막으로 수락한 제안의 일련번호보다 크다면, 수락자는 제안을 수락한다. 그렇지 않다면, 제안을 거부한다.
합의 도달: 충분한 수의 수락자가 제안을 수락하면, 제안은 합의에 도달한 것으로 간주된다. 충분한 수는 시스템에 따라 다르지만, 일반적으로 수락자의 과반수를 의미한다.

책에서 Paxos 프로토콜은 제안의 일련번호와 그 값의 처리에 대해 동의하는 것뿐이기 때문에 유용하지 않을 수 있다고 나와있다. 하지만 일련번호를 활용해서 메시지의 순서를 보장할 수 있고 일부 노드가 장애 나더라도 나머지 노드를 활용해서 과반수 이상 로직을 정상적으로 수행할 수 있다면 충분히 효율적으로 사용할 수 있는 프로토콜이라고 생각한다.

분산 합의 시스템 모니터링

시스템의 특징에 따라서 모니터링의 핵심 지표는 다를 수 있지만 장애나 문제를 감지하고 적절한 조치를 취하기 위해 모니터링이 필요하다는 사실은 변함이 없다. 리더의 존재 여부, 합의 트랜잭션 횟수, 확인된 제안의 횟수 및 합의된 제안의 횟수 등의 지표를 적절하게 설정해서 모니터링을 꼭 하도록 하자.

Ch22. 연속적 장애 다루기

12.tka — Wed, 18 Oct 2023 20:54:14 +0900

연속적 장애는 정상적인 것처럼 보이는 응답 때문에 시간이 지나면서 장애가 계속해서 가중되는 현상이다. 전체 시스템의 일부에서 장애가 발생했을 때 주로 나타나며, 이로 인해 시스템의 다른 부분에 장애가 발생할 가능성도 늘어나게 된다.

연속적 장애의 원인과 대책

서버 과부하

연속적 장애를 유발하는 가장 일반적인 원인은 과부하다. 예를 들어 한 클러스터에서 과부하가 발생하면 그 서버들이 충돌로 인해 강제로 종료되게 되고 그 여파로 로드밸런싱 컨트롤러가 요청을 다른 클러스터에 보내면 그쪽의 서버들에게 과부하가 발생하고 결국 서비스 전체에 걸친 과부하 장애가 발생한다.

자원의 부족

자원 부족으로 인해서 높은 지연응답과 에러율의 증가 혹은 낮은 품질의 응답을 야기할 수 있다. 이러한 현상이 발생하면 성공적으로 처리된 요청의 비율이 빠르게 낮아지고 클러스터 혹은 전체 서비스에 연속적 장애가 발생하게 된다.

서버 과부하 방지하기

테스트

테스트는 서버의 과부하를 방지하기 위해 반드시 수행해야 할 가장 중요한 사안이다. 실제 환경에서 테스트하지 않으면 정확히 어떤 자원이 부족해지는지, 그리고 자원의 부족이 어떤 영향을 미치는지 예측하기가 어렵다. 그렇기 때문에 실제 환경에서 다양한 케이스를 테스트함으로써 서버 과부하 원인을 파악하고 미리 방지하는 것은 아주 중요하다.

경감된 응답 제공

품질은 낮지만 더 수월하게 연산할 수 있는 결과를 사용자에게 제공한다. 이 전략은 서비스마다 다르게 적용될 수 있기 때문에 상황에 맞게 유연하게 제공하면 된다.

과부하 상태에서 요청을 거부하도록 서비스 구현

프론트 혹은 백엔드에 과부하가 발생하면 최대한 빠르면서도 비용이 적게 드는 방법으로 실패를 처리해야 한다.

수용량 계획 실행

수용량 계획을 제대로 실행하면 연속적 장애의 가능성을 줄일 수 있다. 수용량 계획은 서비스가 어느 수준의 부하에서 장애가 발생하는지를 판단하기 위해 반드시 성능 테스트와 병행되어야 한다. 수용량 계획은 연속적 장애의 발생 가능성을 억제할 수는 있지만, 연속적 장애로부터 시스템을 보호하는 데는 크게 도움이 되지 않는다. 계획된 혹은 예상치 못한 현상으로 인해 인프라 스트럭처의 상당 부분에서 장애가 발생했다면 수용량 계획을 잘 수립했더라도 연속적 장애를 해결하지는 못할 것이다.

부하 제한과 적절한 퇴보 (+재시도)

부하 제한

서버가 과부하 상태에 도달하게 되면 부하 제한을 통해 유입되는 트래픽을 감소시켜 어느 정도의 부하를 덜어낼 수 있다. 그 목적은 서버의 메모리 부족이나 건강 상태 점검 실패, 지연 응답의 극단적 증가 및 기타 과부하에 관련된 증상들이 서버에서 발생하는 것을 방지하고 서버가 최대한 자신의 작업을 계속해서 수행할 수 있도록 유지하는 것이다.

적절한 퇴보

부하 제한의 개념에서 한 걸음 더 나아가 실행해야 할 작업의 양을 감소시키는 방법이다. 일부 애플리케이션의 경우 일부러 응답의 품질을 경감시켜 작업의 양이나 처리에 필요한 시간의 양을 현저히 줄일 수 있다. 예를 들어 검색 애플리케이션은 디스크 상의 전체 데이터베이스가 아닌 메모리 캐싱에 저장된 일부 데이터에 대해서만 검색을 수행한다거나 과부하 시에 비교적 정확도가 떨어지지만 더 빠른 순위 알고리즘을 적용할 수 있다.

재시도

자동 재시도를 수행할 경우 서버 수준에서 재시도에 대한 한계 수치를 책정하는 것이 좋다. 제한 없이 재시도를 계속 수행하게 둔다면 이는 연속적 장애를 유발할 수도 있기 때문이다.

마감기한

마감기한을 설정하지 않거나 혹은 너무 긴 시간을 설정하면 서버가 재시작할 때까지 서버의 자원을 오랫동안 계속해서 소비하게 되는 문제가 단기적으로 발생할 수 있다. 따라서 적절한 마감기한을 설정하는 것이 효율적으로 자원을 사용하는 방법 중 하나이다. 마감기한이 지난 경우 해당 요청은 의미가 없기 때문에 마감기한이 지났는지 잘 전파하는 것도 중요하다.

콜드 캐싱

콜드 캐시를 갖게 되는 경우는 다음과 같다.

새로운 클러스터를 켜는 경우: 완전히 비어있는 캐시와 함께 실행
유지보수 작업 후 클러스터를 서비스에 제공: 캐시의 데이터가 유용하지 않을 수 있는 상태
서비스 재시작: 캐시를 다시 채우는 데 어느 정도의 시간이 필요

만약 캐시가 서비스에 중요한 영향을 미친다면 클러스터의 부하 크기를 천천히 늘려주면서 캐시가 어느 정도 채워진 후 많은 트래픽을 처리하도록 구성하는 방법도 좋다.

연속적 장애 테스트하기

장애가 발생할 때까지 테스트하고 조치

컴포넌트에 장애가 생길 때까지 부하 테스트를 진행하는 방법이다. 부하가 증가하면 대부분의 컴포넌트는 요청을 성공적으로 처리하다가 어느 시점부터 더 이상의 요청을 처리하지 못하게 된다. 이상적인 컴포넌트는 이 시점에서 성공적으로 처리하는 요청의 양이 크게 줄지 않으면서도 부하의 한계를 넘어선 요청에 대해서는 에러 혹은 경감된 결과를 리턴해야 한다.

이러한 테스트를 통해 어느 지점에서 장애가 발생하는 지 확인하고 수용량 계획을 세울 수도 있고 장애를 방지하는 다른 방법에 대해서도 고민해 볼 수 있다.

상대적으로 덜 중요한 백엔드 테스트

상대적으로 덜 중요한 백엔드 테스트에 대한 테스트를 통해 이 백엔드가 사용 불가능한 상태라 하더라도 서비스의 중요한 컴포넌트들이 그에 따른 간섭을 받지 않는지 확인하는 테스트이다.

연속적 장애를 처리하기 위한 즉각적인 대처

자원의 추가 투입

여분의 자원에 태스크를 추가하는 방법이다. 하지만 서비스가 죽음의 소용돌이에 휘말렸다면 자원을 추가한다고 해서 장애로부터 벗어날 수는 없을 것이다.

건강 상태 점검 중지

서비스가 건강 상태가 아닌 경우 건강 상태 점검으로 인해 장애 모드로 들어갈 수 있다. 그렇기 때문에 건강 상태 점검을 일시적으로 중지해서 모든 태스크가 실행될 때까지 시스템이 안정적으로 동작하도록 할 수 있다.

서버의 재시작

서버 재시작으로 장애를 처리하기 전에 연속적 장애의 원인을 먼저 규명해야 한다. 단순히 재시작을 해서 장애를 해결했더라도 원인을 모르면 다음에도 장애가 발생할 수 있기 때문이다. 그리고 콜드캐시 같은 이슈라면 서버의 재시작은 오히려 연속적 장애를 더 크게 만들 수 있기 때문에 재시작으로 장애를 처리하기 위해서는 꼭 원인을 먼저 규명해야 한다.

트래픽의 경감

아래 과정을 통해 부하가 정상적인 수준으로 돌아올 때까지 서버가 실행을 준비하고 필요한 연결을 수립하는 등의 작업을 처리할 여력을 갖게 된다.

장애를 유발하는 기본적인 원인을 처리한다.
충돌이 사라질 만큼 충분히 부하를 경감시킨다. 이때는 적극적이어야 한다. 만일 전체 서비스에서 계속 충돌이 발생한다면 전체 트래픽의 1%만을 처리하도록 조치한다.
대부분의 서버가 양호한 상태가 된다.
점진적으로 서버에 부하를 늘려간다.

이외에도 위에서 언급했던 퇴보 모드로 돌아가기를 포함해서 일괄 작업 부하 배제, 문제 있는 트래픽 배제 등의 방법이 있다.

정리

이번 장에서는 연속적 장애의 원인과 대처 방법에 대해서 알아보았다. 장애이지만 정상적인 것처럼 보이는 응답을 빠르게 파악하는 것이 중요할 것 같고 연속적 장애를 대비하기 위해서 미리 테스트해보고 올바른 수용량 계획을 세우는 것이 중요할 것 같다.

장애가 발생했을 때는 재시작을 바로 하기보다는 원인을 파악한 후 적절한 조치를 취하도록 해야겠다. 그리고 마지막에 서비스가 장애가 발생할 수 있는 수준에 도달하면 사용자의 모든 요청을 완벽하게 처리해 내기보다는 에러를 리턴하거나 혹은 평소 대비 낮은 품질의 결과를 리턴해야 한다고 적혀있는데 이 부분은 어떤 서비스인지에 따라서 다를 것 같다. 사내에 제공하고 있는 서비스는 모든 요청을 완벽하게 처리해야 할 필요도 있기 때문이다.

Ch21. 과부하 처리하기

12.tka — Wed, 11 Oct 2023 09:56:11 +0900

로드밸런싱 정책의 목적은 과부하를 피하기 위함이다. 이번 장에서는 과부하를 처리하는 다양한 방법에 대해서 알아보도록 하자.

경감된 응답 리턴

평상시의 응답보다 정확도가 조금 떨어지거나 혹은 더 적은 데이터를 제공하는 것이다. 이렇게 하면 연산을 수행하기가 더 쉬워진다. 하지만, 과부하가 극심한 경우에는 서비스가 경감된 응답조차도 연산하고 서비스할 수 없을 수도 있다. 이런 상황에서는 에러를 리턴하는 것 외에는 신속하게 대처할 수 있는 방법이 없다. 물론 데이터센터 자체에서 수용량을 넘어서는 트래픽을 전달받지 않도록 하면 해결 되기는 한다.

초당 쿼리 수의 함정

쿼리는 종류에 따라 요구하는 자원이 상당히 다르다. 따라서 초당 쿼리 수를 통해 수용량을 모델링하면 실망스러운 결과를 볼 수 있다.

더 나은 방법은 사용 가능한 자원에 대해 직접적인 수용량을 측정하는 것이다. 우리는 대부분의 경우 단순한 CPU 사용량이 자원 증설에 대한 신호로써 손색이 없다는 점을 알아냈다. 그 이유는 다음과 같다.

메모리에 대한 부하는 본질적으로 CPU 사용률의 증가를 동반한다.
나머지 자원이 CPU보다 먼저 바닥나는 경우는 극히 드물기 때문에 해당 자원을 준비할 여력이 충분하다.

사용자별 제한

전체적인 과부하가 발생하면 서비스가 엉뚱한 행동을 하는 고객에게만 에러 응답을 리턴하고 나머지 고객들은 영향을 받지 않도록 하는 것이 중요하다. 그러기 위해서는 서비스 소유자는 고객의 행위를 고려해서 자신들의 수용량을 준비해야 하며, 서비스 수준 동의에 따라 사용자별 할당량을 정의해야 한다. 참고로 서비스 소유자는 모든 고객들이 자신의 자원을 지속적으로 한계치까지 사용하지 않는다는 사실에 기초해 이 같은 계획을 수립한다.

클라이언트 측에서의 사용량 제한

고객의 자원 소비량이 할당량의 범위를 벗어나면 백엔드 태스크는 신속하게 이후의 요청을 거부해야 한다. 하지만 이러한 요청을 거부하는 것도 비용을 소모하는 작업이다. 따라서 클라이언트 측에서 애초에 요청이 가지 않도록 사용량을 제한하는 것이 더 좋은 방법이다.

중요도

해당 요청이 얼마나 중요한지를 나타내는 값이다.

CRITICAL_PLUS: 가장 중요한 요청을 위한 값으로 이 값을 가진 요청들은 실패 시 사용자에게 직접적인 영향을 미치게 된다.
CRITICAL: 프로덕션 환경에서 전달되는 모든 요청들이 기본적으로 사용하는 값이다. 서비스들은 예상되는 CRITICAL 및 CRITICAL_PLUS 등급의 요청들을 모두 처리하기에 충분한 사용량을 준비해야 한다.
SHEDDABLE_PLUS: 어느 정도 실패가 발생하는 것을 용인할 수 있는 트래픽을 위한 값이다. 실패 시 몇 분이나 몇 시간 후에 다시 재시도하게 되는 일괄 작업을 위한 기본값이다.
SHEDDABLE: 부분적 실패가 자주 발생하거나 간혹 아예 사용이 불가능할 것으로 예상되는 작업들을 위한 값이다.

중요도에 따라 올바르게 대처할 수 있도록 다양한 제어 메커니즘에 중요도를 결합했다.

활용도에 대한 신호들

활용도는 단순히 CPU 사용률을 측정한 것일 수도 있고 예약된 메모리 대비 사용 중인 메모리 비율을 측정하기도 한다. 활용도가 설정된 한계치에 다다르면 요청의 중요도에 따라 이에 대한 처리를 거부하기 시작한다.

재시도 여부 결정하기

구글에서는 재시도 허용 수준을 최대 3회까지로 제한하고 있다고 한다. 그리고 클라이언트별 재시도 한계를 정의해서 특정 비율 안에서만 재시도를 수행하도록 정의하기도 한다. 이에 따라 요청의 증가율이 다르게 나온다.

정리

태스크의 부하를 데이터센터에 상대적으로 균일하게 배분하기 위한 다양한 기법들(클라이언트 측 사용량 제한, 고객별 할당량 등)에 대해서 살펴보았다. 추후에 로드밸런싱을 구현할 일이 생긴다면 19~21장에 배운 내용을 바탕으로 상황에 맞게 적절한 로드밸런서를 구현할 수 있을 것 같다.

Ch20. 데이터센터의 로드밸런싱

12.tka — Wed, 11 Oct 2023 09:56:03 +0900

이번 장에서는 데이터센터 내에서의 로드밸런싱에 대해 알아보도록 하자. 특히 지정된 데이터센터 내에서 쿼리 스트림을 효과적으로 분산 처리하기 위한 알고리즘과 요청이 유입될 때 이를 처리할 수 있는 개별 서버로 라우팅 하는 애플리케이션 수준 정책에 대한 내용을 중점적으로 살펴보자.

양호하지 않은 태스크 구별하기

클라이언트의 요청을 어느 백엔드가 처리할 것인지 결정하기 위해서는 그 전에 백엔드 풀에서 양호하지 않은 태스크를 식별할 필요가 있다.

1. 흐름 제어

활성화된 요청의 개수가 설정된 한계 값을 넘어서면 클아이언트는 백엔드가 양호하지 않은 상태에 있다고 가정하고 더 이상 요청을 전달하지 않는다. 이와 같은 엄청 간단한 흐름 제어는 간단한 형태의 로드밸런싱이라고 보아도 무방하다.

위 방법은 매우 높은 수준의 과부하 상태에서 백엔드 태스크만을 보호할 수 있다. 또한 이 한계값에 도달하기 전에 이미 백엔드가 과부하 상태에 놓이기도 쉽다. 물론 반대의 경우도 가능하다.

2. 레임덕 상태

레임덕 상태는 백엔드 태스크가 포트를 리스닝 중이고 서비스를 제공할 수 있지만 명시적으로 클라이언트에게 요청의 전달을 중단할 것을 요구하는 상태를 말한다.

태스크가 레임덕이라는 다소 어중간한 상태를 갖는 것을 허용함으로써 얻을 수 있는 장점은 셧다운 과정을 깔끔하게 처리하는 것이 쉬워진다는 것이다. 참고로 태스크의 셧다운은 일반적으로 아래 절차를 따른다.

잡 스케줄러가 SIGTERM 신호를 백엔드 태스크에 전달
백엔드 태스크 레임덕 상태로 전환되고 클라이언트들에게 요청을 다른 백엔드 태스크로 전달할 것을 알린다.
백엔드 태스크가 레임덕 상태로 전환되기 전에 처리 중이던 요청들은 정상적으로 실행된다.
클라이언트에 응답을 전달하다 보면 해당 백엔드에 남은 활성화된 요청의 개수는 0으로 줄어든다.
설정된 일정 시간을 기다린 다음, 백엔드 태스크는 깔끔하게 종료되거나 혹은 잡 스케줄러가 태스크를 종료한다.

서브셋을 이용한 연결 풀 제한하기

서브셋은 클라이언트 태스크와 상호작용할 잠재적인 백엔드 태스크들의 풀을 제한하는 것과 관련 있다. 서브셋을 활용하면 하나의 클라이언트가 많은 수의 백엔드 태스크에 연결되거나 혹은 하나의 백엔드 태스크가 많은 수의 클라이언트 태스크들의 연결을 수용할 수 있게 할 수 있다.

적절한 서브셋 선택하기

적절한 서브셋을 선택하려면 각 클라이언트 연결이 얼마나 많은 백엔드 태스크에 연결될 것인지를 선택해야 하며, 선택 알고리즘 역시 구현되어야 한다. 선택 알고리즘은 크게 랜덤 서브셋, 결정적 서브셋이 있다.

랜덤 서브셋

각 클라이언트가 백엔드의 목록을 임의로 섞은 후, 그중에서 접근이 가능하고 양호한 상태의 백엔드를 선택해서 서브셋을 구축하는 방법이다. 한 번 임의로 섞은 후 백엔드를 차례로 선택하는 방법은 고려 대상이 될 백엔드의 수를 명시적으로 제한할 수 있으므로 재시작과 장애 상황을 안정적으로 처리할 수 있다. 그러나 이 전략은 부하가 균등하게 분산되지 않기 때문에 대부분의 경우에 원하는 대로 동작하지 않는다는 것을 경험했다.

랜덤 서브셋을 구현하고 다양한 경우의 수에 대한 테스트를 수행해보니 작은 크기의 서브셋을 사용하면 불균형이 더 심해지는 현상이 발생하였다. 결국 랜덤 서브셋을 이용해 가용한 태스크들을 상대적으로 균형 있게 처리하려면 서브셋의 크기는 대략 75% 정도가 되어야 한다는 결론을 내렸다. 문제는 서브셋을 그 정도로 크게 설정하면 효율이 크게 떨어진다는 점이다. 태스크에 연결되는 클라이언트의 수의 변동폭이 너무 크기 때문에 대용량 환경에서 적절한 랜덤 서브셋을 선택하는 적절한 정책을 수립하기가 어렵다.

결정적 서브셋

결정적 서브넷은 랜덤 서브셋의 제한을 해결하기 위한 해결책이다. 클라이언트 태스크들을 '라운드'로 나누어 사용한다. 이를 통해 각 백엔드는 정확히 하나의 클라이언트에 할당된다.

중요한 것은 백엔드의 목록은 반드시 섞여야 한다는 점이다. 그렇지 않으면 클라이언트가 할당된 연속적인 백엔드 태스크의 그룹에 공교롭게도 현재 사용 가능한 백엔드가 존재하지 않을 수 있다. 각 라운드는 목록을 혼합할 때 각기 다른 시드 값을 사용한다. 그렇지 않으면 백엔드가 실패했을 때 해당 백엔드의 부하는 서브셋에 남아있는 백엔드 중 하나가 부담해야 한다. 만일 서브셋 내의 다른 백엔드마저 실패한다면 그 영향이 더해져 상황이 더 빠르게 악화될 수 있다. 예를 들어 어느 서브셋에 포함된 백엔드 N이 다운된다면, 그에 상응하는 부하가 남은 백엔드로 퍼져나가게 된다. 더 나은 방법은 이 부하를 각 라운드마다 매번 목록을 다르게 뒤섞어 남아있는 백엔드 전체에 부하를 분산하는 방법이다.

로드밸런싱 정책

로드밸런싱 정책은 클라이언트 태스크들이 자신의 서브셋 내에서 요청을 처리할 백엔드를 선택하기 위해 사용하는 메커니즘이다. 로드밸런싱 정책의 복잡성 중 상당 부분은 클라이언트가 각 요청을 어떤 백엔드가 처리할 것인지를 실시간으로 결정해야하는 의사 결정 프로세스가 본질적으로 분산되어 있기 때문에 발생한다.

로드밸런싱 정책은 백엔드의 상태에 대한 어떤 정보도 필요하지 않은 간단한 방법(라운드 로빈)부터 백엔드에 대한 더 자세한 정보를 필요로 하는 방법(최소 부하 라운드 로빈 혹은 가중 라운드 로빈)이 있다.

간단한 라운드 로빈

모든 클라이언트가 동일한 비율로 요청을 보내지 않을 수도 있기 때문에 부하 조정 능력이 떨어진다. 그뿐만 아니라 같은 데이터센터 내의 모든 머신이 완전히 동일하지 않을 수 있기 때문에 같은 요청이 어떤 머신에서는 상당히 다른 양의 작업이 될 수 있다.

최소 부하 라운드 로빈

간단한 라운드 로빈의 대안으로는 각 클라이언트가 서브셋 내의 각 백엔드 태스크와 연결된 활성화된 요청의 개수를 추적하고 가장 적은 수의 활성화된 요청을 처리하고 있는 태스크들만을 대상으로 라운드 로빈을 수행하는 것이다.

최소 부하 정책의 핵심은 부하가 많은 태스크들은 여럭이 있는 태스크들보다 상대적으로 지연응답률이 높기 때문에 부하가 많은 태스크들을 을 제외하는 것이다.

만일 어느 태스크가 심각하게 양호하지 않은 상태라면, 이 태스크는 100%의 확률로 에러를 발생시킬 수도 있다. 이를 통해 낮은 지연응답률을 가질 수 있는데 그 결과 이 태스크는 트래픽을 마치 싱크홀처럼 빨아들이게 된다. 다행인 것은 이 함정은 활성화된 요청을 최근 리턴받은 에러의 개수를 추적하도록 정책을 수정함으로써 상대적으로 쉽게 해결할 수 있다.

가중 라운드 로빈

앞서 설명한 두 가지 라운드 로빈 정책에 비해 백엔드가 제공하는 정보를 의사결정 프로세스에 반영하는 중요한 로드밸런싱 정책이다. 실질적으로 가중 라운드 로빈은 아주 잘 동작하며 최저 및 최고 부하 태스크 사이의 간극을 잘 메워준다.

정리

양호한 태스크를 구별하는 방법을 통해 태스크를 적절하게 관리할 수 있는 방법을 알게 되었고, 로드 밸런싱 정책의 다양한 방법을 알게 되었다.

Ch19. 프론트엔드의 로드밸런싱

12.tka — Wed, 11 Oct 2023 09:55:53 +0900

이번 장에서는 사용자 트래픽을 여러 데이터센터에 조절해서 전달하는 로드밸런싱에 대해 간략하게 알아보도록 하자.

모든 일을 힘으로만 해결할 수는 없는 법

현실적으로 절대 장애가 일어나지 않는 네트워크는 존재하지 않는다. 따라서 장애가 최대한 적게 나도록 구조를 개선해야 하는데 로드밸런싱이 큰 역할을 수행한다. 예를 들어서 특정 요청을 어느 데이터센터에 얼마나 많은 서버들이 처리할 것인지를 결정하기 위해 트래픽 로드밸런싱을 도입하기도 한다. 요청의 종류는 다양하겠지만 검색, 비디오 요청은 아래와 같은 처리가 필요하다.

검색 요청: 요청에 대한 지연응답 시간을 최소화하기 위해 라운드트립 타임(round-trip time, RTT)을 측정해서 가장 가까운 데이터센터로 보내야 한다.
비디오 요청: 지연응답 시간을 희생하더라도 처리량을 극대화하기 위해 현재 가장 사용량이 적은 링크를 통해 전달되어야 한다.

요청의 종류뿐만 아니라 캐시 활용 여부, 네트워크 혼잡 상황 등 대형 시스템을 위한 로드 밸런싱은 결코 직관적이고 정적이지 않다. 위 예시는 이해를 돕기 위해 최대한 단순화한 것이다.

DNS를 이용한 로드밸런싱

클라이언트는 HTTP 요청을 보내기 전에 DNS를 이용해 IP 주소를 먼저 조회한다. 이 DNS 조회 과정에는 DNS 로드밸런싱을 적용한다. 가장 간단한 방법은 DNS 응답에 여러 개의 A 또는 AAAA 레코드를 리턴하여 클라이언트가 임의의 IP 주소를 선택하게 하는 방법이다.

위 예시는 개념적으로는 구현하기 간단해 보이지만 클라이언트의 행동을 넘어서는 수준의 제어는 가능하지 않다는 점과 클라이언트가 가장 가까운 주소를 결정할 수 없다는 문제점이 존재한다. 물론 공인 네임서버의 애니캐스트 주소를 사용하고 DNS 질의가 가장 가까운 주소로 전달된다는 사실을 이용하면 가장 가까운 주소 문제점은 해결할 수 있다.

가상 IP 주소를 이용한 로드밸런싱

가상 IP 주소(Virtual IP Address, VIPs)는 어느 특정 네트워크 인터페이스에 할당되지는 않는다. 다만 여러 장치에 의해 공유될 뿐이다. 하지만 사용자의 입장에서 볼 때, VIP는 보통의 IP 주소일 뿐이다. 이 방법을 이용하면 이론적으로는 상세 구현(특정 VIP 백엔드에 존재하는 머신의 수 등)이나 설비의 유지보수 등을 드러내지 않을 수 있다. 사용자가 알지 못하게 머신을 업그레이드하거나 추가하는 등의 작업이 가능하기 때문이다.

VIP 구현에서 가장 중요한 부분은 네트워크 로드밸런서이다. 밸런서는 패킷을 수신하고 이를 VIP 백엔드의 머신 중 하나에 전달한다. 그런 후 해당 백엔드 머신이 요청에 대한 추가 작업을 수행하게 된다.

밸런서가 백엔드의 어느 머신이 요청을 수신할 것인지를 결정하는 방법은 여러 가지가 있다.

대표적으로 부하가 가장 적은 머신을 선택하는 방법이 있다. 하지만 이 방법은 요청을 반드시 같은 머신이 수신해야 하는 상태가 있는 프로토콜을 사용하게 되면 실용성이 급격히 무너진다. 이 문제를 해결하기 위해서는 어느 머신이 최초의 패킷을 수신했는지를 확인하기 위해 모든 네트워크 연결을 추적해야 한다. 혹은 패킷의 일부를 이용해 연결 ID를 만들고 해당 ID를 이용하여 백엔드를 선택하면 된다. 하지만 연결 ID를 만드는 방법도 단점이 존재하며 최종적으로 구글에서는 패킷 캡슐화 방법을 사용해서 문제점을 해결했다고 한다.

정리

로드밸런서란, 네트워크 트래픽 혹은 애플리케이션의 요청을 여러 서버에 고르게 분산시키는 장치라는 것을 알게 되었다. DNS, 가상 IP 주소 등 다양한 방법을 활용하여 로드밸런싱을 수행할 수 있다는 점도 알게 되었다. 하지만 실무에 바로 적용하기에는 너무 포괄적인 개념과 방법이 나와있어서 아쉬웠다.

Ch18. SRE 조직의 소프트웨어 엔지니어링

12.tka — Wed, 30 Aug 2023 21:20:22 +0900

이번 장에서는 SRE 조직 구성원들이 소프트웨어 엔지니어링을 수행한 이유와 결과에 대해서 알아보도록 하자

SRE 조직의 소프트웨어 엔지니어링 역량이 중요한 이유

구글은 필요로 하는 규모를 감당할 수 있는 서드파티 도구를 찾기 힘들어서 다양한 형태의 소프트웨어 개발이 내부적으로 이루어지고 있다고 한다. 그리고 SRE는 아래와 같은 이유로 인해서 내부 소프트웨어를 개발하기에 아주 적합하다고 한다. (~~결론은 잘해서인 것 같다.)~~

구글만의 프로덕션 환경에 대한 SRE 조직의 폭넓고 깊은 지식
SRE들은 중요한 사안에는 모두 참여하므로 개발할 도구의 목적과 요구사항을 손쉽게 이해

SRE의 가이드 원리 중 하나는 "팀의 규모는 서비스의 성장률과 직접적으로 비례해서는 안 된다"는 것이다. 폭발적으로 성장하는 서비스에도 불구하고 SRE 조직의 규모를 선형적으로 유지하려면 지속적인 자동화 작업과 능률적인 도구, 절차에 대한 개선 노력이 필요하며 일상적인 운영 업무에 비효율성을 초래하는 부분을 전과는 다르게 바라보는 시각이 필요하다고 한다. 서비스의 규모가 커지면 자연스럽게 팀의 규모도 커진다고 생각했었는데 이를 당연하다고 생각하지 않는 것이 새롭게 느껴졌다.

이후로 SRE 조직의 소프트웨어 엔지니어링 중 성공적인 Auxon 사례에 대한 이야기가 이어진다. Auxon에 대한 내용이 궁금하다면 책을 읽어보는 것을 추천한다.

목표 이루기

명확한 메시지로 소통하라
조직의 역량을 평가하라
출시하고 반복하라
자신의 표준을 낮추지 마라

결론

SRE가 주도하는 소프트웨어 프로젝트는 회사가 서비스의 규모에 관계없이 지속 가능한 모델을 개발하는 데 큰 도움이 되었다고 한다. SRE가 개발한 소프트웨어는 비효율적인 절차를 능률적으로 바꾸거나 반복적인 작업을 자동화하는 것들이 대부분이므로 이런 프로젝트들이 늘어난다고 해서 SRE팀들의 규모가 그에 따라 선형적으로 커지는 일도 없다. 궁극적으로 SRE가 시간의 일부를 소프트웨어 개발에 투자하는 것은 회사와 SRE 조직, 그리고 SRE 본인들에게도 큰 수확이 되었다고 한다.

SRE 직군은 아니지만 데이터 엔지니어의 관점에서 데이터 분석가, 데이터 애널리스트 분들의 편의를 높이는 작업을 하는 것도 이번 장에서 말한 내용과 이어진다고 생각한다.