일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |
- 기록으로 실력을 쌓자
- 오블완
- 정보처리기사실기 기출문제
- CloudWatch
- minikube
- aws
- AWS EKS
- kotlin
- SRE
- Elasticsearch
- go
- CKA
- 티스토리챌린지
- tucker의 go 언어 프로그래밍
- Java
- AI
- kotlin coroutine
- APM
- golang
- 공부
- Spring
- PETERICA
- Linux
- kotlin querydsl
- MySQL
- 정보처리기사 실기 기출문제
- Kubernetes
- Pinpoint
- CKA 기출문제
- 코틀린 코루틴의 정석
- Today
- Total
목록DevOps (174)
피터의 개발이야기
ㅁ 들어가며 예전 글, 네트워크 레이아웃에서 SSL이란?에서 SSL(Secure Sockets Layer)은 클라이언트와 서버 간의 통신을 보호하는 표준적인 보안 프로토콜이로 서버는 SSL 인증서를 사용하여 신원을 증명한다고 설명한적 있다. 일년에 한번 인증서 교체 시기가 되면 SSL 인증서 개념이 헷갈리는 시기이다. 최근에는 하나의 인증서에 RSA와 ECC를 모두 담아 제공하는 하이브리드 인증서를 알게 되었다. 이 글에서는 하이브리드 인증서가 무엇인지, 그리고 서버(특히 Apache와 Nginx)에서의 인증서 관리 주의점까지 정리해보았다. ㅁ 하이브리드 인증서란? 하이브리드 인증서는 RSA와 ECC(Elliptic Curve Cryptography)라는 두 가지 암호 알고리즘의 공개키가 한 인증서에 ..
ㅁ 들어가며 localStorage와 sessionStorage는 모두 브라우저에 데이터를 저장하는 용도로 쓰지만, 데이터의 생명주기와 공유 범위에서 차이가 크다. 둘 다 HTML5에서 제공하는 Web Storage API로, key-value 형태로 데이터를 저장한다. 오랫동안 유지해야 하거나 여러 탭에서 공유해야 하는 데이터는 localStorage에, 세션(탭/창) 동안만 필요한 데이터는 sessionStorage에 저장한다. 용도에 맞게 적절히 선택해 사용한다. ㅁ 주요 차이점 요약구분localStoragesessionStorage데이터 유지 기간브라우저를 닫아도 유지탭/창을 닫으면 삭제공유 범위같은 도메인 내 모든 탭/창에서 공유탭/창별로 독립, 다른 탭/창과 공유되지 않음삭제 방식직접 삭제 ..
보호되어 있는 글입니다.
[SRE] SRE(Site Reliability Engineering) 목차 ㅁ 들어가며ㅇ [SRE] 실전에서 배우는 SLI: CloudWatch와 Grafana로 신뢰성 확보하기에서는 SRE의 시선에서 SLI를 어떻게 "정의하고, 모니터링하고, 개선"했는지를 제가 경험한 내용을 바탕으로 설명하고자 하였다. “무엇을, 어떻게 모니터링할 것인가?”에 대한 명확한 기준이 없다면, 수많은 지표 속에서 중요한 신호를 놓치기 쉽다. 이 글에서는 SRE와 DevOps 현장에서 널리 활용되는 대표적인 모니터링 방법론인 USE Method, RED Method, Four Golden Signals를 정리하여, 실무에 바로 적용할 수 있는 방법론을 제시하고자 한다. ㅁ USE MethodUSE Method(Utiliz..
[SRE] SRE(Site Reliability Engineering) 목차 ㅁ 들어가며 『The Art of Capacity Planning』(John Allspaw 저)는 SRE(Site Reliability Engineering) 실무에서 "용량 계획(Capacity Planning)"의 핵심 원리와 실전 전략을 체계적으로 다루는 대표적인 참고서 중 하나이다. 용량 계획은 단발성 작업이 아니라, 측정 → 예측 → 배치 → 검증 → 반복의 순환적 과정이다. 이 책은 이론과 실무 경험을 바탕으로, 성장하는 IT 인프라를 효과적으로 관리하고 확장하는 데 필요한 실질적 지침을 제공한다. ㅁ 주요 내용 요약1. 용량 계획의 중요성용량 계획(Capacity Planning)은 단순히 미래의 수요 예측이 아니라..
[SRE] SRE(Site Reliability Engineering) 목차 ㅁ 들어가며ㅇ 지난 글, SRE란 무엇인가? SRE는 단순한 ‘운영’이 아니다에서 다음과 같이 이야기 하였다.SRE는 단순한 운영 역할을 넘어서, 서비스의 신뢰성(Reliability)을 코드와 시스템적으로 보장하는 엔지니어링 문화이다.ㅇ 이번 글에서는 "엔지니어링 문화"란 무엇인지 구체적으로 알아보고, 엔지니어 문화를 바탕으로 SRE의 주요 역할을 정리해 보았다. ㅁ 엔지니어링 문화란?"엔지니어링 문화"는 단순한 기술 스택이나 도구의 사용을 넘어, 조직이 문제를 해결하는 방식과 철학, 협업하는 방식, 그리고 기술적 품질을 유지하는 기준과 태도를 모두 포함하는 개념이다. SRE 맥락에서의 엔지니어링 문화는 특히 중요하며, 아래와..
[SRE] SRE(Site Reliability Engineering) 목차 ㅁ 들어가며 내가 현재 속해 있는 팀인 카카오 i 플랫폼의 Gateway는 방대한 MSA(Microservices Architecture) 환경에서 트래픽을 집약하고, 서비스 간 연결의 허브 역할을 한다. 이런 복잡한 구조에서 서비스 안정성을 확보하고, 효율적인 운영을 위해 SRE(Site Reliability Engineering) 개념의 도입은 필수적입니다. 본 글에서는 SRE의 핵심 개념과, Gateway 서비스에 적합한 SRE 지표 수립 방법을 정리합니다.ㅁ SRE란 무엇인가?SRE는 구글에서 시작된 운영 및 개발 방법론으로, 소프트웨어 엔지니어링 원칙과 자동화를 통해 대규모 시스템의 신뢰성과 안정성을 확보하는 것을 목..
[SRE] SRE(Site Reliability Engineering) 목차 ㅁ 들어가며 SRE는 시스템의 신뢰성(Availability)을 수치로 측정하고 유지하기 위해 SLI(Service Level Indicator)를 정의하고 관리한다.이 글에서는 제가 직접 경험한 CloudWatch 및 Grafana 기반의 모니터링 환경 구축과, 그를 통해 얻은 인사이트와 문제 해결 사례를 공유하고자 한다. 현실적인 운영 상황과 개선 과정을 중심으로, SRE의 시선에서 SLI를 어떻게 "정의하고, 모니터링하고, 개선"했는지를 설명하고자 한다. ㅁ SLI는 무엇이 기준이 되어야 하는가?SRE로 일하면서 가장 먼저 고민한 것은 "우리는 무엇을 측정해야 하는가?"였다.처음에는 AWS CloudWatch에 내장된 ..
[SRE] SRE(Site Reliability Engineering) 목차ㅁ 들어가며ㅇ SRE란 무엇인가? SRE는 단순한 ‘운영’이 아니다에서 서비스의 신뢰성(Reliability)을 코드와 시스템적으로 보장하는 엔지니어링 문화에 대해서 알아보았다. 이번 글에서는 SRE의 판단 기준이자 방향성이며, 실질적인 운영 목표인 SLA, SLO, SLI에 대해서 정리하였다. ㅁ 의료 바이탈 체크와 SRE의 SLA, SLO, SLI드라마나 영화를 보면 응급환자를 케어하는 의사가 먼저 활력징후(vital signs) 리스트를 체크하는 장면을 보곤 한다. 활력징후란, 온도, 맥박, 호흡, 혈압의 수치를 측정한 데이터로, 사람의 몸상태를 수치로 나타낸 것이다. 정확한 진단을 내리기 위해서는 정밀한 검사를 통해 얻은 ..
[SRE] SRE(Site Reliability Engineering) 목차 ㅁ 들어가며“SRE가 정확히 뭐지?”Site Reliability Engineering, 줄여서 SRE는 단순한 운영 역할을 넘어서, 서비스의 신뢰성(Reliability)을 코드와 시스템적으로 보장하는 엔지니어링 문화이다. 구글에서 시작된 개념이지만, 오늘날 대부분의 대규모 플랫폼 서비스 기업들이 SRE 조직을 두고 안정성과 효율성을 동시에 추구하고 있다. ㅁ SRE는 단순한 ‘운영’이 아니다 과거에는 운영(Operation)과 개발(Development)이 분리되어 있었다. 개발자는 코드를 만들고, 운영자는 그것을 배포하고 문제를 해결하는 구조였다. 하지만 이 구조는 다음과 같은 문제를 일으켰다.개발자는 안정성보다 기능에 ..