# SRE

개발환경설정 (2023/06/23)
매번 귀찮아 하면서도 누군가에게는 꼭 필요한 일이 되길 하면서 남겨둡니다. 추가 BAT (문법 강조와 Git 통합 기능의 cat 클론) 링크 : https://github.com/sharkdp/bat 관련 설명 : https://github.com/sharkdp/bat/blob/master/doc/README-ko.md 설치 : Mac bash Ubuntu(using most recent .deb packages) 그외는 Github 참조 추가 Add option to disable line numbers 옵션 : --style=plain batcat 은 line numbers 가 default 로 생성되게 되는데 가끔 그것이 귀찮을때가 있다 그럴때는 아래와 같이 옵션을 추가해주면 됩니다. 기존 bash 추가 위의 BAT가 포함된 .zshrc

고등학교 백엔드 개발자 관점에서 본 제 3회 당근마켓 SRE 밋업 내용과 후기
제 3회 당근마켓 SRE 밋업 2023.6.15 개요 제3회 당근마켓 SRE 밋업의 표를 구한 소마고 백엔드 개발자인 나는 바로 서울 교보타워로 현장체험학습신청서를 쓰고 달려갔다. 솔직히 어려운내용이 많았다. 이해가 되지 않는 내용도 있었다. 그러나 데브옵스 엔지니어가 아닌 백엔드 개발자인 나의 관점에서도 여러가지를 느낄 수 있었던 좋은 경험이였다. 아래는 내가 밋업 내용을 정리한 것이다. 야매로 적은거라 별로 부정확한 내용이 있을 수도 있다. 참고 바란다.. 그리고 맨 아래에는 백엔드 개발자 관점으로 본 나의 후기도 남겨보았다. 1. 당근마켓은 지난 2년간 무엇을 만들었는가? (변정훈) 당근마켓 개발자 플랫폼! Kontrol(개발자 플랫폼) 운영하게된 이유 서비스 개발 && SRE 서비스 개발 → 요청 | 인프라 ←SRE 엔지니어 티켓요청 → SRE 작업(자동화, 스크립트) → 인프라 서비스 개발팀이 추구하는 방향 빠

NAVER D2 정리
💬 찾아보게 된 계기 얼마 전에 기술 블로그를 정리하다가 네이버 기업이 최근에 어떤 문제로 고민하는지 궁금하기도 하고 최근에 어떤 기술을 가지고 코딩을 하는지 궁금해서 찾아보게 됐다. 🛠 NAVER D2 NAVER D2에 게시된 네이버 검색의 SRE 시스템 찾아보게 됐다. 네이버 검색 SRE 시스템은 국내 최대 규모의 트래픽과 데이터를 다루는 대용량 분산 시스템이다. 네이버에서 검색의 SRE 시스템을 도입하게 된 계기는 첫 번째는 스케일이 한 단계씩 커질 때마다 새로운 방법론이 필요했던 것으로 보인다. 두 번째는 예측이 불가능한 일들이 많이 일어나기때문이다. ✔ Site Reliability Engineering(SRE, 사이트 신뢰성 엔지니어) SRE는 사이트 신뢰성 엔지니어
Make a Service Deploy System
Why do need a Deploy Interface? Kubernetes is a very complex system. ex) pod, deployment, svc, secrets, configmap, daemonset, hpa ... Deployment points of interest are all different. Deploy Manifest DockerFile build path list of configurations to use Deploying workloads (Deployment, ReplicaSet, StatefulSet, DaemonSet, CronJob ...) Workfload Resource Spec Serving ports Pod lifecycle, HealthCheck ... Ingress settings for traffic Distinctive Points of

[쎄트렉아이] DevOps 철학과 SRE
🔷 본 시리즈는 쎄트렉아이 기업 프로젝트에 참여하여 학습하거나 실습한 내용들을 기록할 예정입니다. ⚡ DevOps 철학과 SRE 📌 DevOps 🔷 개발과 운영 사이의 간극을 하나의 철학으로 묶은 것 새로운 기능을 만들어서 제품에 적용하는데 집중하는 개발팀 만들어진 제품을 안정적으로 유지하려고 집중하는 운영팀 🔷 DevOps 철학은 개발과 운영의 사일로 현상을 해결하기 위한 방법론이자 하나의 조직문화에 대한 방향성이다. > 💡 DevOps는 'Developers + Operators' 를 가리킨다. 📌 SRE (Site Reliability Engineering) 🔷 제품의 안정적인 운영을 담당함과 동시에 새로운 기능과 운영 개선을 위한 작업을 수행하는 "역할"을 의미한다. Metric & Monitoring: 모니터링 지표와 안정성 목표 관리, 장애 지표

Google SRE Culture - Module 2
어떤 개발팀의 이야기 고객은 카탈로그를 검색하고 카트에 항목을 추가한 다음 구매를 완료한다. 이 온라인 소매업체의 운영 팀은 주요 측정 기준에 대한 리뷰를 매주 회의한다. 최근 리뷰에서 이 팀은 고객이 결제를 클릭하고 상태가 확인된 것으로 돌아올 때까지의 시간이 서서히 증가하고 있음을 발견했다. 이것이 중요한 문제가 아니라는 것을 인식하고 있지만, 해결될 필요가 있었다. 그 팀은 대기 시간 문제를 해결하기 위해 조용히 시간을 보냈다. 시간이 지남에 따라 비즈니스 측면에서 제품 개발 팀은 기능을 계속 강화했다. 개발자들은 새로운 기능을 제공하는 비즈니스 요청을 따라잡기 위해 시간이 지남에 따라 작업을 시작했을 뿐만 아니라 앞서 확인된 작은 지연 시간 버그를 해결하기 위해 노력했다. 제품 팀들은 여전히 개발 속도에 만족하지 않았다. 기본적으로 IT 팀은 비즈니스를 만족시키기 위해 노력을 기울였다. 이들은 비즈니스와 신뢰성 모두의 요구를 충족시키기 위해 어려움을 겪고 있다.

Google SRE Culture - Module 1
서비스의 안정성이나 고객 이탈에 대해 고민해 본 적이 있을까? 개발 팀과 운영 팀 모두 "모든 것이 정상이다."라고 말한다 하지만 최종 사용자와 고객은 그렇지 않기 때문에 문제가 있을 것이다. 프로덕션 소프트웨어를 제작하고 실행하는 데 상당한 시간을 소비한 경우 사소한 업데이트를 배포할 때 고객에게 부정적인 영향을 미칠 수 있다는 불만을 느낀 적이 있을 것이다. 또한 중요한 기능을 위해 다음 릴리즈를 추진해야 하기 때문에 운영 팀이 주문한 프로덕션 프리즈가 정말로 사실에 근거한 것인지에 대해서도 의문을 제기했을 것이다. 이런 상황들이 익숙하게 느껴진다면, 개발 팀과 운영 팀이 우선 순위가 상충되는 경우가 많은 이유가 무엇인지, 그리고 왜 계속 사일로에서 작업하는지 궁금할 것이다. 구글은 수년간 대규모로 시스템을 운영해 왔다. 시간이 지남에 따라 팀과 고객 모두를 위해 기능의 속도와 안정성에 대한 위험의 균형을 맞추기 위해 관행을 표준화했다. 이러한 관행을 지원하는 문화와

SRE는 무엇일까?
SRE가 필요한 이유 개발 과정에는 흔히 개발자와 운영자가 있다. 이 때 둘의 이해관계가 충돌하는데 개발자는 좀 더 빠르게 기능을 출시하는 것을 목표로 하고 운영자는 더욱 안정성있는 운영을 목표로 한다. 이 때 DevOps는 자동화를 통한 비교적 안정적이면서 좀 더 빠른 배포를 목표로하는데 여기서 SRE는 사이트 신뢰성 엔지니어링이라고 해서 전체적인 파이프라인의 신뢰성을 증진시키는 것을 목표로 한다. SRE의 정의 SRE는 구글 엔지니어인 Ben Treynor에 의해 처음 정의된

DevOps란 "정확히" 무엇일까?
DevOps DevOps는 IT산업에서 자주 들을 수 있는 일종의 유행어이다. 상대적으로 새로운 개념일 뿐이지 엄청 새로운 개념은 아니다. 매년 DevOps의 인기는 늘어나고 있고 전세계적으로 성장을 기대하는 분야이다. 하지만 DevOps의 개념을 정확히 정의하기에는 너무 방대한 분야를 다루고 있어서 다른 IT 용어와 비교해서 우리가 이해하기 쉽도록 DevOps의 의미를 좁혀보자 DevOps는 기본적으로 개발과 운영의 합성어이지만 그 경계가 모호하다. 어디까지가 DevOps의 개발이고 어디까지가 DevOps의 운영일까? 그리고 DevOps의 존재 이유는 무엇일까 
AWS에 wireguard VPN 구축하기
AWS VPC위에 VPN 구축하기 회사에 AWS VPC를 구축 중인데, 로컬 환경에서 데이터 레이어에 대한 접근이 필요해졌다. 여러가지 대안책이 생각났는데 다음과 같은 방법들이 생각났다. 1번은 2~4번 다 시도해보고 안 되면 최후의 보루 처럼 적용하기로했다. 2번은 나쁘지 않은 생각 같았는데, 2번은 SSH를 통해서만 접근을 해야 하는게 단점으로 다가왔다. (비개발직군도 접근해야되는 리소스가 있기때문), 이제 남은건 VPN 방식인 3번 4번 이었는데 3번은 비용이 문제였다. 비용은 다음과 같다. 10명이 하루 1시간씩 한달간 사용한다면, (총 사용시간 * 0.1) + (호스트 수 * 호스트 당 하루 시간 * 한 달 * 0.05) + 네트워크 비용 (10130 * 0.1) + (10130 * 0.05) + 네트워크 비용 30 + 15 + 네트워크 비용 = 45$ + @ 이 계산이면, 10명이 하루 3시간씩만 이용해도 150달러가 넘
SRE와 DevOps 비교
SRE 개념 사이트 신뢰성 엔지니어링은 Google 엔지니어링 팀의 Ben Treynor Sloss가 창안한 개념입니다. SRE 팀은 소프트웨어를 툴로 활용하여 시스템을 관리하고, 문제를 해결하고, 운영 태스크를 자동화시키는 목적을 가지는 엔지니어입니다. 목적 및 목표 표준화 및 자동화는 SRE 모델에서 중요한 2가지 구성 요소입니다. 사이트 신뢰성 엔지니어는 운영 태스크를 개선하고 자동화할 방법을 끊임없이 모색해야 합니다. 사이트 신뢰성 엔지니어는 운영 태스크 시간과 프로젝트 작업 시간을 구분합니다. Google의 SRE 모범 사례에 따르면 사이트 신뢰성 엔지니어는 자기 시간의 최대 50%만 운영에 사용할 수 있으며 모니터링을 통해 이 시간을 초과하지 않도록 해야 합니다. SRE는 확장성이 뛰어나고 안정적인 소프트웨어 시스템을 만드는 것이 목표인 운영에 소프트웨어 엔지니어링 측면을 적용하는 분야 운영 및 개발 작업 간의 균형을 유지하는 것이 SRE의 핵심
SRE 란?
SRE SRE란 Site Reliability Engineering의 약자로 조직이 시스템, 서비스 및 제품에서 적절한 수준의 안정성을 달성하도록 지원하는 엔지니어링 분야를 의미한다. SRE는 서비스의 인프라와 운영 관점의 문제를 소프트웨어 엔지니어링 기법을 통해 해결하고자 나온 개념으로, 주요 목표는 확장성과 고가용성을 확보한 소프트웨어를 만드는 것이다. SRE의 특징 Metrics & Monitoring 모니터링 지표를 정의하고, 이 지표를 모니터링 시스템에 올리는 일. 지표를 분석해서 insight를 도출하여 시스템을 개선하거나 안정성을 높이는 것. 서비스에 대한 지표를 SLI(Service Level Indicator)를 정하고, SLI - 기능적인 요구사항이 아닌 응답속도, 가용성, 처리량 등 서비스 수준을 판단할 수 있는 몇가지를 정량적으로 측정할 수 있는 척도. 각 지표에 대한 안정성 목표를

왜 인프라 관리 자동화가 필요한가?
“서비스가 안 되요” 어느 토요일 오전 , 기분좋게 운전을 하며 커피를 사러 가고 있었던 필자에게 한 통의 전화가 왔다. 다급한 목소리로 고객이 전화를 하니 곧바로 모든 마음의 안정과 원래 목적지에서 U턴을 해야했다. 보통 고객들은 ‘서비스가 안 된다’고 말을 하지 ‘Front단에는 오류가 없는데 API 서버와 통신이 느려진것 같이 오류가 발생해요’ 라고 자세하게 불평을 하지 않는다. 커피 메뉴나 햄버거를 개인취향에 맞게 그 어려운 주문을 할 때와는 전혀 딴 사람이다. 그렇다면 그 간단한 ‘서비스가 안 되요’라는 메뉴를 파악하기 위한 것은 모두 운영자의 몫이다. 집으로 돌아가는 시간동안 하늘이 도와서 신호등이 홍해를 가르듯 1초의 오차없이 나를 맞이해 주기를 바랬다. 물론 그 동안에도 고객들은 서로 오류 전파를 하며 불만이 높아지고 있었을 것이다. 집에 도착 후 숨이 가쁘게 노트북을 향해 달라가서 부팅을 했고, 다행히 여유로운 원격접속 프로그램의 사용자수에 포함이 되어 어렵
SRE(Site Reliability Engineering)

AWX
AWX 는 Ansible 프로젝트 관리를 위한 웹 기반 사용자 인터페이스, REST API 및 Task 엔진 제공하는 툴이다. Red Hat Ansible Automation Platform 프로젝트 중에 하나 이며, 오픈소스로 제공하고 있다. AWX 자체는 Ansible 언어를 운영하는 미들웨어의 성격ㅇl다. Playbook이 없다면 할 수 있는 일은 거의 없다. 그래서 중요한 것은 Ansible playbook을 개발하는 것입니다. AWX는 playbook을 관리하고 운영하는 데 필요한 여러 기능을 제공한다. AWX 기능 Ansible Project Management and Host Management Provisioning and Configuration Management

Ansible 앤서블이란?
Configuration Management tools Ansible은 서버의 구성관리 도구이다. 같은 범위의 비교대상은 Puppet, Chef, Saltstack이 대표적이다. Ansible은 IaC (Infrastructure as Code)를 지향하는 자동화 관리 도구로 오픈 소스 기반으로 제작되었다. Ansible을 구동하는 모듈 및 라이브러리는 Python을 기반으로 하며, YAML 포맷을 기반으로 플레이북을 실행시켜서 원하는 자동화를 구현하거나, Ad hoc 모드로 모듈을 실행시켜 상태를 조회해 볼 수 있다. 또한 기존 Chef/Puppet 처럼 기존에 알려진 IaC 솔루션들이 Target Host들에 Agent를 반드시 설치해야 하는 것과 비교해서, Ansible은 SSH를
Zabbix - Ansible 연동
Zabbix Script 등록 Zabbix 5.4 이상부터 ‘Trigger Action’ 에서 ‘Remote Command’ 선택이 활성화 되기 위해서는 Script를 먼저 등록해야 한다. 1.스트립트 등록 1.1 Zabbix > Administration > Scripts 1.2 CREATE ITEM 을 클릭한다 Core-API 에 SSH 접속을 한 후에 Command를 실행한다. ansible-playbook 명령 단위로 스크립트를 준비한다. 참고] 호출한 ansible playbook 1.3 Zab
Zabbix - Slack 연동 # 2.Zabbix item&trigger설정
Zabbix 5.4 설정 1.Administration > General > Macros 2.Administration > Media types > Slack 3.Configuration > Hosts > 모니터링 타겟 Host 클릭 3.1. Items 탭 클릭 후 CREATE ITEM 클릭 
Zabbix Agent 등록
Zabbix Agent를 통한 모니터링은 Active 방식과 Passive 방식으로 나뉘어진다. Active 방식 사전조건으로 agent 설정 파일에서 serverActive의 ip를 지정해주어야 그 ip를 참조해서 데이터를 전송할 수 있다. Agent -> Server로 데이터를 전송하는 방식 (TCP 10051 포트를 이용) Item 구성 시 Zabbix Agent (active)를 선택하면 Active 방식으로 사용 가능 Passive 방식 (Default) 별다른 설정 없이 기본 동작 방식임. Server -> Agent로 데이터를 수집하는 방식 (TCP 10050 포트를 이용) Item 구성 시 Zabbix Agent 를 선택하여 구성 참고: zabbix.com 운영체제 확인

SRE APM Tool - Zabbix
Zabbix를 Ubuntu 환경에 Docker로 설치하기 AWS Ec2를 Ubuntu20.4로 생성한다. zabbix 구성 image들을 다운로드합니다. Zabbix 설치하기 1. Mysql 패스워드 주의 restart 옵션이 없으므로, zabbix 서버 재부팅시 mysql 부터 시작해야 한다. 2. Zabbix java 게이트웨이 3. Zabbix-server-mysql 4. Zabbix-web-nginx 5. Zabbix agent 6. 설치완료 확인 7. inspect 명령어로 Zabbix agent의 IP주소 확인하기 8. Zabbix 설정하기 좌측 메뉴 >