분류 전체보기432

• 

  시스템의 속마음을 읽는 기술: o11y(관측 가능성) 완벽 가이드 안녕하세요! 오늘은 현대 IT 시스템 운영의 필수 개념인 o11y(Observability, 관측 가능성)에 대해 깊이 있게 다뤄보려고 합니다.0. o11y가 도대체 뭐야?먼저 용어부터 정리해 보죠. o11y는 Observability라는 단어의 'O'와 'y' 사이에 11글자가 있다는 의미에서 온 줄임말입니다. (Accessibility를 a11y라고 부르는 것과 같은 이치죠!)단순한 모니터링이 "서버가 죽었니?"라고 묻는 것이라면, o11y는 "서버가 왜 느려졌고, 내부에서 어떤 일이 벌어지고 있니?"라는 질문에 답할 수 있는 상태를 만드는 것을 의미합니다.1. 데이터의 원자: 이벤트(Event)와 카운터(Counter)모든 관측 데이터는 가장 밑바닥의 두 원자 단위에서 시작됩니다.이벤트 (Event.. 프로그래밍공부(Programming Study)/DevOps-Cloud Native 2026. 1. 25.

• 

  현대 고성능 서버의 데이터 전송 메커니즘: epoll부터 TCP BBR까지 대규모 트래픽을 처리하는 백엔드 시스템을 설계할 때 가장 큰 적은 '불필요한 CPU 소모'와 '기다림'입니다. 초당 수만 건 이상의 연결(C10K)을 처리하기 위해 시스템 레벨에서 어떤 최적화 기술들이 맞물려 돌아가는지, 데이터의 흐름을 따라 정리해 봅니다.1. 연결 관리의 효율화: epoll서버가 수만 개의 소켓(File Descriptor, FD)을 관리할 때, 가장 먼저 마주하는 병목은 "어느 소켓에 데이터가 들어왔는가?"를 확인하는 작업입니다.기존 방식(select/poll): 데이터가 왔는지 확인하기 위해 모든 FD를 순회()합니다. 연결이 늘어날수록 CPU 사용량이 선형적으로 증가합니다.epoll: 운영체제 커널이 '이벤트가 발생한 FD 목록'을 별도로 관리합니다. 서버는 이 목록만 확인()하.. 프로그래밍공부(Programming Study)/CS-운영체제(OS) 2026. 1. 18.

• 써드파티 API 장애 대응: DevOps 엔지니어 가이드 서비스 장애의 원인은 크게 애플리케이션 로직 문제, 리소스 과점유, 그리고 외부 의존 서비스 장애로 나눌 수 있다. 이 글에서는 이 중에서도 의존성 있는 서비스(써드파티 API) 장애에 한정하여 다룬다.특히 외부 API 장애가 내부 시스템으로 전파되는 구조를 살펴보고, 이를 막기 위해 DevOps 엔지니어가 고려해야 할 설계 포인트와 운영 대응 방안을 중심으로 정리한다.1) 장애가 서버까지 번지는 구조써드파티 API가 느려지거나 에러를 반환하면, 우리 시스템의 호출 큐/스레드풀이 고갈되고, 전체 서비스 지연·500 에러로 이어질 수 있다.이 문제를 해결하려면 “외부 장애가 내부로 전파되지 않도록 보호막을 설계”하는 것이 핵심이다.2) 장애 전파 방지 핵심 설계개념 1: 타임아웃과 일관된 요청 제한정의AP.. 프로그래밍공부(Programming Study)/DevOps-Cloud Native 2025. 12. 31.

• 

  AWS EKS에서 팀별 비용 분리하기 컴퓨트부터 트래픽까지, “정산 가능한 구조”로 만드는 방법하나의 EKS 클러스터를 여러 팀이 함께 쓰기 시작하면, 어느 순간 반드시 이런 질문이 나온다.“우리 팀이 실제로 얼마나 쓰고 있는 거지?”“네트워크 비용은 왜 이렇게 많이 나오지?”“이걸 근거로 비용 정산을 해도 되는 건가?”EKS는 분명 강력하지만, 비용 관점에서는 기본적으로 ‘팀 단위’를 전혀 모른다.그래서 비용 분리는 기능 하나로 해결되는 문제가 아니라,계측 방식 + 구조 설계 + 운영 규칙이 함께 맞물려야 한다.이 글에서는 AWS가 공식적으로 제공하는 메커니즘을 기준으로,EKS에서 컴퓨트 + 네트워크 비용을 팀별로 나누는 현실적인 방법을 정리한다.1. EKS에서 비용이 실제로 발생하는 위치부터 이해하기EKS 자체는 관리형 컨트롤 플레인 비.. 프로그래밍공부(Programming Study)/DevOps-Cloud Native 2025. 12. 30.

• 

  EKS Blue/Green 업그레이드에서 Stateful 서비스를 바라보는 올바른 기준 EKS 버전을 Blue/Green 방식으로 업그레이드할 때, 가장 먼저 던져야 할 질문은 이것이다.“이 서비스의 상태(state)는 어디에 존재하는가?”Stateful 여부는 단순히 StatefulSet을 쓰느냐의 문제가 아니다.데이터가 어디에 있고, 누가 진실(Source of Truth)을 가지고 있느냐에 따라 난이도와 전략이 완전히 달라진다.실무에서는 stateful 서비스를 아래 세 가지로 나누는 것이 가장 명확하다.1. Pod 내부에 상태가 존재하는 서비스 (Pod-local state)개념상태가 컨테이너 또는 Pod에 연결된 파일 시스템에만 존재하는 경우다.대표적인 예는 다음과 같다.로컬 디스크(EBS RWO)에 직접 데이터 저장StatefulSet + PVC자체 DB, embedded DB단.. 프로그래밍공부(Programming Study)/DevOps-Cloud Native 2025. 12. 30.

• 

  이창호의 부득탐승(不得貪勝) 지난 2025년 10월 추석 연휴에 이창호 선생님의 『부득탐승』을 읽었다. 조훈현 선생님의 『고수의 생각법』을 정리한 흐름에서 자연스럽게 이어진 독서였다.바둑을 좋아하다 보니 조훈현, 이창호, 이세돌 선생님의 글에 꾸준히 관심을 갖게 된다. 『부득탐승』은 2015~2017년 군 복무 시절, 바둑을 처음 배우며 여러 번 읽었던 책이다. 언젠가 한 번은 정리해두고 싶다고 생각해왔고, 이번에 그 기록을 남기게 되었다.아래는 『이창호의 부득탐승』을 읽으며 정리한 내용이다.「지금 이기지 않아도 괜찮다. 다만, 흐름을 망치지는 말자.」이창호의 부득탐승: 이기려 들수록 멀어지는 것들에 대하여— 이창호가 말하는 승부의 태도이창호“승리를 탐하면 얻지 못한다.”위기십결 가운데 가장 역설적으로 들리는 말이 바로 부득탐승(不.. 독서(Reading)/오늘의 책(Today's book) 2025. 12. 29.

• 

  시스템 성능 엔지니어링 1장 소개 – 시스템 성능의 개념 (Brendan Gregg) 이 글은 브렌던 그렉(Brendan Gregg)의시스템 성능 엔지니어링(Systems Performance, Second Edition)을 읽으며핵심 내용을 정리하고, 이해를 돕기 위해 일부 설명을 덧붙인 글입니다.들어가며시스템 성능 엔지니어링(Systems Performance Engineering)은 단순히“느린 시스템을 빠르게 만드는 기술”이 아니다.그보다 더 근본적으로는, 시스템이 어떻게 동작하는지를 이해하고,문제가 발생했을 때 어디를, 어떤 관점(perspective)에서 바라봐야 하는지에 대한 학문이다.‘1장 소개(Introduction)’에서는시스템 성능(System Performance)이 무엇인지누가 성능을 책임지는지그리고 어떤 관점과 도구(tool)로 성능 문제에 접근해야 하는지를전체적.. 독서(Reading)/시스템 성능 엔지니어링 2025. 12. 28.

• 

  조훈현, 고수의 생각법 2023년 출간 당시 읽고는 한동안 잊고 있었던 책이었지만, 2025년 9월부터 10월까지 다시 읽으며 많은 생각을 하게 되었다.바둑을 좋아해 조훈현, 이창호, 이세돌 선생님의 글을 함께 읽고 있다.그 사유의 결은 서로 닿아 있으면서도 조금씩 달랐다.아래는 『조훈현, 고수의 생각법』을 읽으며 정리한 내용이다.다음 글에서는 이창호 선생님의 『부득탐승』을 읽으며 정리한 내용을 이어서 적을 예정이다. 「고수는 더 많이 아는 사람이 아니라, 더 오래 생각하고 더 멀리 보는 사람이다」고수의 생각법: 이기는 기술이 아니라 살아가는 태도에 대하여바둑은 승패가 분명한 게임이지만, 조훈현이 말하는 바둑은 단순한 승부의 세계가 아니다. 그의 말 속에는 사고하는 법, 선택하는 법, 버티는 법, 그리고 사람으로 살아가는 방식.. 독서(Reading)/오늘의 책(Today's book) 2025. 12. 27.

• 

  HashiCorp Vault로 시작하는 현대 시크릿 관리 가시다님께서 진행하신 CI/CD 스터디 추가 실습 내용을 기반으로 작성했다.CI/CD 스터디에서 HashiCorp Vault를 이용해 시크릿 관리와 Kubernetes 연동을 실습했다.이 글에서는 그때 정리한 내용을 바탕으로 다음 내용을 한 번에 훑어본다.왜 이제는 “시크릿 관리 도구”가 필수인지HashiCorp Vault가 무엇을 해결해 주는지Kind 기반 Kubernetes에 Vault를 설치하는 방법KV 시크릿 엔진으로 정적 시크릿을 저장하는 기본 흐름Vault Agent + Sidecar 패턴으로 애플리케이션과 Vault를 자연스럽게 붙이는 방법1. 시크릿과 현대 인프라: 왜 이제는 그냥 .env로는 안 되는가1-1. 시크릿(Secret)이란?시크릿은 “노출되면 안 되는 모든 정보”라고 보면 된다.. 스터디(Study)/CI·CD Study 2025. 11. 29.

• 

  Jenkins · Argo CD · Keycloak · OpenLDAP로 Kubernetes SSO + RBAC 구성하기 [부록 실습] 가시다님께서 진행하신 CI/CD 스터디 추가 실습 내용을 기반으로 작성했다.이번 글에서는 단일 kind 클러스터 위에 Jenkins, Argo CD, Keycloak, OpenLDAP를 올리고, OIDC와 LDAP을 활용해 SSO와 RBAC를 통합하는 과정을 단계별로 정리한다. 1. 기본 실습 환경 구성1-1. kind 클러스터 생성 (myk8s)# kind k8s 배포kind create cluster --name myk8s --image kindest/node:v1.32.8 --config - 1-2. Ingress-Nginx 배포# 노드 라벨 확인kubectl get node myk8s-control-plane -o jsonpath={.metadata.labels} | jq# ... "ingress.. 스터디(Study)/CI·CD Study 2025. 11. 22.

• 

  예제로 배우는 Argo CD 5장: Argo CD로 쿠버네티스 클러스터 부트스트랩 가시다님께서 진행하신 CI/CD 스터디 6주차 주제인 Argo CD를 활용한 멀티 클러스터 부트스트랩 실습 내용을 기반으로 작성하였다. 이번 글에서는 예제로 배우는 Argo CD 5장을 따라가며, 로컬 kind 환경에서 mgmt/dev/prd 클러스터를 구성하고, Argo CD·App of Apps 패턴·ApplicationSet을 활용해 멀티 클러스터 GitOps 부트스트랩 과정을 단계별로 정리한다.기술 요구 사항이번 장에서 사용하는 도구/환경은 아래와 같다.로컬 환경DockerkubectlkindHelmargocd CLI유틸리티jq, yqkrew + kubectl-neat (k neat)k9s (선택)openssl, curlGitGitHub (또는 개인 Git 서버)브라우저Argo CD UI 접속용※.. 스터디(Study)/CI·CD Study 2025. 11. 22.

• 

  웹 엔지니어가 알아야 할 인프라의 기본-1장 Chapter 1. 웹 서비스에서 인프라의 역할시스템 신뢰성(Reliability)과 보안(Security)은 인프라 설계에서 가장 중요한 축이다.단일 관점으로 접근하면 놓치는 요소가 생기기 때문에, 여러 모델을 함께 검토하며 확인하는 것이 도움이 된다.요소별 가동률을 단계적으로 보는 이유시스템 전체의 가용성을 평가할 때는 사용자 → 서버까지의 물리적 경로를 순서대로 추적하는 방식이 가장 누락이 적다.사용자의 단말기, 브라우저, 전파 환경, 이동통신사 네트워크, 데이터 센터의 회선, 라우터, 방화벽, 스위치, 서버, 디스크, 애플리케이션까지 일련의 흐름 중 어느 한 구간만 문제가 생겨도 서비스는 정상 동작하지 않는다.경로를 순차적으로 나열해보면 병목과 장애 지점을 체계적으로 확인할 수 있다.RASIS와 .. 독서(Reading) 2025. 11. 19.