기록

안녕하세요.블로그에 글을 써야지 다짐만 하다가, 어느새 1년이 훌쩍 지나버렸네요.이번에 깃허브 액션 관련 책을 읽을 기회가 생겨, 오랜만에 글을 작성하였습니다.깃헙 액션, CI/CD 관심 있으셨던 분들께 조금이나마 도움이 되길 바랍니다.📚 책 구성책은 기초편, 실전편, 응용편 총 3부로 구성되어 있어요.개인적으로 기초편 내용만 제대로 익혀도, 대부분의 상황에서 유용한 CI 구축이 가능하다고 느꼈습니다. 물론 실전편과 응용편까지 함께 보면, 기본적인 CI 구성뿐만 아니라 유지 보수가 쉬운 형태로 점차 개선할 수 있을 것 같아요. 또한, 이 책은 단순히 깃허브 액션만 다루는 것이 아니라, CI/CD를 구축한다는 것이 어떤 의미인지에 대해서도 자연스럽게 배울 수 있어 더욱 유용하였습니다. 자세한 목차 내용은..

1. 개요 파이썬을 사용하여 Excel 파일을 생성하거나 편집하는 작업은 많은 분들이 경험해 보셨을 겁니다. 하지만 Excel 파일 암호화를 수행한 적은 얼마나 되시나요? 물론 Excel 응용 프로그램을 통해서는 간단히 암호 설정이 가능하지만, 파이썬 코드를 사용해 이를 수행한 경우는 드물 것입니다. 따라서 이번 글에서는 파이썬 코드로 Excel 파일에 암호를 설정하는 방법에 대해 알아보겠습니다. 2. xlwings xlwings는 파이썬에서 Excel 파일을 다룰 수 있게 해주는 라이브러리입니다. 이를 활용하면 쉽게 Excel 파일 암호화를 수행할 수 있습니다. (참고) 3. 예시 코드를 작성하기 전에, 우선 xlwings 라이브러리를 설치해야 합니다. 이는 간단히 pip install xlwings ..

운영 업무의 부하 복잡한 시스템에서 운영 업무의 부하란 시스템이 제대로 동작하는 상태를 유지하기 위해 반드시 해야만 하는 일들을 의미한다. 복잡한 시스템을 만든 사람이 완벽하지 못한 만큼, 시스템 자체도 완벽할 수 없다. 이런 시스템에서 발생하는 운영 업무들을 관리하고 있다면, 그 시스템을 만든 사람 역시 완벽하지 않다는 점을 항상 기억하자. 운영 부하는 긴급 호출, 티켓, 진행 중인 운영 업무 세 가지로 분류할 수 있다. 긴급 호출 운영 환경에서 발생하는 경고나 장애에 대처하기 위한 것으로, 긴급한 상황이 발생했을 때 생겨난다. 이들은 대부분 단조롭고, 반복적으로 발생하며, 약간은 생각을 해야 한다. 긴급 호출은 그에 상응하는 기대 응답 시간(SLO)이 정해져 있으며, 대부분 분단위로 측정한다. 긴급 ..

인터넷 기업의 출시 주기 전통적인 기업들은 새 제품을 출시하는 비율이 상당히 낮다. 반면, 인터넷 기업의 출시 주기는 이와는 현저히 다르다. 제품을 신속하게 출시하는 것이 훨씬 쉬운데, 그 이유는 새로운 기능을 담은 소프트웨어를 고객의 개별 컴퓨터에 설치하는 것이 아니라 우리가 보유한 서버에 새로운 기능을 출시하는 것이기 때문이다. 이처럼 빠른 변화 속도는 능률적인 출시 절차를 정의해야 하는 근본적인 이유와 기회를 제공한다. 매 3년마다 새로운 제품을 출시하는 기업이라면 세밀한 출시 절차 따위는 필요치 않다. 출시 조율 엔지니어링 (LCE) 구글은 제품 출시의 어려움을 타개하기 위해 SRE 조직 내에 새로운 제품이나 기술을 출시하기 위한 기술적인 부분을 수행할 전문 컨설팅팀을 구성했다. 이들은 구글이 원..

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

연속적 장애는 정상적인 것처럼 보이는 응답 때문에 시간이 지나면서 장애가 계속해서 가중되는 현상이다. 전체 시스템의 일부에서 장애가 발생했을 때 주로 나타나며, 이로 인해 시스템의 다른 부분에 장애가 발생할 가능성도 늘어나게 된다. 연속적 장애의 원인과 대책 서버 과부하 연속적 장애를 유발하는 가장 일반적인 원인은 과부하다. 예를 들어 한 클러스터에서 과부하가 발생하면 그 서버들이 충돌로 인해 강제로 종료되게 되고 그 여파로 로드밸런싱 컨트롤러가 요청을 다른 클러스터에 보내면 그쪽의 서버들에게 과부하가 발생하고 결국 서비스 전체에 걸친 과부하 장애가 발생한다. 자원의 부족 자원 부족으로 인해서 높은 지연응답과 에러율의 증가 혹은 낮은 품질의 응답을 야기할 수 있다. 이러한 현상이 발생하면 성공적으로 처리..

로드밸런싱 정책의 목적은 과부하를 피하기 위함이다. 이번 장에서는 과부하를 처리하는 다양한 방법에 대해서 알아보도록 하자. 경감된 응답 리턴 평상시의 응답보다 정확도가 조금 떨어지거나 혹은 더 적은 데이터를 제공하는 것이다. 이렇게 하면 연산을 수행하기가 더 쉬워진다. 하지만, 과부하가 극심한 경우에는 서비스가 경감된 응답조차도 연산하고 서비스할 수 없을 수도 있다. 이런 상황에서는 에러를 리턴하는 것 외에는 신속하게 대처할 수 있는 방법이 없다. 물론 데이터센터 자체에서 수용량을 넘어서는 트래픽을 전달받지 않도록 하면 해결 되기는 한다. 초당 쿼리 수의 함정 쿼리는 종류에 따라 요구하는 자원이 상당히 다르다. 따라서 초당 쿼리 수를 통해 수용량을 모델링하면 실망스러운 결과를 볼 수 있다. 더 나은 방법..

이번 장에서는 데이터센터 내에서의 로드밸런싱에 대해 알아보도록 하자. 특히 지정된 데이터센터 내에서 쿼리 스트림을 효과적으로 분산 처리하기 위한 알고리즘과 요청이 유입될 때 이를 처리할 수 있는 개별 서버로 라우팅 하는 애플리케이션 수준 정책에 대한 내용을 중점적으로 살펴보자. 양호하지 않은 태스크 구별하기 클라이언트의 요청을 어느 백엔드가 처리할 것인지 결정하기 위해서는 그 전에 백엔드 풀에서 양호하지 않은 태스크를 식별할 필요가 있다. 1. 흐름 제어 활성화된 요청의 개수가 설정된 한계 값을 넘어서면 클아이언트는 백엔드가 양호하지 않은 상태에 있다고 가정하고 더 이상 요청을 전달하지 않는다. 이와 같은 엄청 간단한 흐름 제어는 간단한 형태의 로드밸런싱이라고 보아도 무방하다. 위 방법은 매우 높은 수준..

이번 장에서는 사용자 트래픽을 여러 데이터센터에 조절해서 전달하는 로드밸런싱에 대해 간략하게 알아보도록 하자. 모든 일을 힘으로만 해결할 수는 없는 법 현실적으로 절대 장애가 일어나지 않는 네트워크는 존재하지 않는다. 따라서 장애가 최대한 적게 나도록 구조를 개선해야 하는데 로드밸런싱이 큰 역할을 수행한다. 예를 들어서 특정 요청을 어느 데이터센터에 얼마나 많은 서버들이 처리할 것인지를 결정하기 위해 트래픽 로드밸런싱을 도입하기도 한다. 요청의 종류는 다양하겠지만 검색, 비디오 요청은 아래와 같은 처리가 필요하다. 검색 요청: 요청에 대한 지연응답 시간을 최소화하기 위해 라운드트립 타임(round-trip time, RTT)을 측정해서 가장 가까운 데이터센터로 보내야 한다. 비디오 요청: 지연응답 시간을..

이번 장에서는 SRE 조직 구성원들이 소프트웨어 엔지니어링을 수행한 이유와 결과에 대해서 알아보도록 하자 SRE 조직의 소프트웨어 엔지니어링 역량이 중요한 이유 구글은 필요로 하는 규모를 감당할 수 있는 서드파티 도구를 찾기 힘들어서 다양한 형태의 소프트웨어 개발이 내부적으로 이루어지고 있다고 한다. 그리고 SRE는 아래와 같은 이유로 인해서 내부 소프트웨어를 개발하기에 아주 적합하다고 한다. (결론은 잘해서인 것 같다.) 구글만의 프로덕션 환경에 대한 SRE 조직의 폭넓고 깊은 지식 SRE들은 중요한 사안에는 모두 참여하므로 개발할 도구의 목적과 요구사항을 손쉽게 이해 SRE의 가이드 원리 중 하나는 "팀의 규모는 서비스의 성장률과 직접적으로 비례해서는 안 된다"는 것이다. 폭발적으로 성장하는 서비스에..