낙숫물이 바위를 뚫듯이.

[K8S] GW/VS/DR을 apply하면 Envoy에는 무슨 일이 생길까?
·
카테고리 없음
개요지난 글에서는 Service Mesh를 타는/타지 않는 경우에 대한 트래픽 흐름을 살펴보았다. Mesh를 타는 흐름 즉, Envoy를 통해 트래픽이 오갈 때 Gateway, Virtual Service, Destination Rule이 주는 영향을 직접 단계별로 살펴보자. 1. 들어가며 : K8S Architecture와 CRD(Gateway, VirtualService, DestinationRule) GW, VS, DR은 내장 리소스가 아니라 istio가 CRD(커스텀 리소스!)로 등록한 것이다. CRD를 등록하는 순간 API Server가 그 타입을 이해하게 되고, 그 뒤로는 내장 리소스(Deployment, Service 등)와 완전히 동일하게 동작한다. CRD kubectl apply 후, ..
[K8S] Service Mesh를 탈 때/타지 않을 때 요청 흐름 비교
·
DevOps/DevOps
개요이 글은 클러스터로 들어온 요청이 앱 컨테이너에 도달하기까지의 전체 경로를 탐색한다. 지난 글에서 사이드카가 어떤 원리로 주입되고 트래픽을 가로채는지 확인했다면, 이번엔 사이드카에 실제 요청이 어떻게 통과하는지를 살펴본다. 1. 환경 준비1.1. 클러스터와 istio이전 글의 k8s-lab 클러스터를 그대로 쓰되, 이번에는 클러스터 밖에서 게이트웨이로 들어가는 경로가 필요하다. 그런데 Kind에서는 이 경로가 기본적으로 막혀있다. 왜 막혀 있는지부터 살펴보자. Kind는 EKS와 달리 Docker 컨테이너가 하나의 노드 역할을 한다. Docker는 컨테이너를 내부 사설 네트워크(Bridge)에 붙이기 때문에, 노드는 172.18.0.2와 같은 브리지 안의 사설 주소를 할당 받는다. [Docker Do..
[K8S] Sidecar (Native, Ambient)
·
DevOps/DevOps
개요이 글은 Istio의 Data Plane, 그중에서도 사이드카에 집중한다. 사이드카가 어떤 원리로 앱 Pod에 주입되고, 어떻게 앱의 트래픽을 가로채 처리하는지를 실제 kind 로컬 클러스터(bobae-labs) 위에서 명령어 레벨로 확인한다. Service Mesh와 Istio의 전체 구조는 이전 글에서 다뤘고, 이 글을 단독으로 읽어도 되도록 필요한 부분만 짧게 복습하고 시작해보자!Service Mesh: 모든 서비스 간 트래픽을 프록시로 한 번 통과시켜, 통신 제어(라우팅·재시도·mTLS·telemetry)를 앱 코드 밖으로 빼내는 구조. 정책을 선언하는 Control Plane과 실제 트래픽을 처리하는 Data Plane으로 나뉜다.Istio: Control Plane은 istiod, Data..
[K8S] Service Mesh와 Istio
·
DevOps/DevOps
개요Service Mesh와 Istio에 대해 이해한다. 1. Service Mesh1.1. Service Mesh가 필요한 이유MSA 환경에서는 서비스가 수십 개로 쪼개지면서, 서비스 간 통신에 필요한 일들 (retry, timeout, 라우팅, mTLS(서비스 간 암호화) 등)을 모두 앱이 각자 코드로 떠안아야 하는 문제가 생긴다. 파편화되는 만큼 Request의 추적이 어렵고 서비스 간의 순환 호출 등의 문제가 발생해 장애 여파가 커지기도 한다. 1.2. Service Mesh를 통해 해결할 수 있는 것핵심은 단순하게 모든 서비스 간 트래픽이 프록시(Envoy)를 한 번 거치게 된다는 것이다. 트래픽이 반드시 지나야 하는 길목이 생기면, 그 길목에서 통신을 제어하고 들여다보는 일이 전부 가능해진다..
[PromQL] PromQL 사용을 위한 필수 기초 & Basic Method 이해하기
·
Monitoring/PromQL & Grafana
들어가며PromQL 작성의 어려움Alert Rule을 설정하거나 Grafana 대시보드를 만들다 보면 "이 쿼리가 정말 내가 모니터링하려는 대상을 정확하게 표현하고 있을까?"라는 고민이 들곤 했다. AI가 PromQL을 꽤 잘 작성해주기는 하지만, 결국 좋은(정확한) 쿼리를 작성하려면 무엇을 관측하려는지 명확히 정의하고, 메트릭의 특성을 이해한 뒤 적절한 함수를 조합하는 것이 중요하다고 느꼈다. 이를 위해서는 먼저 메트릭이 어떤 특성(Counter, Gauge 등)을 가지는지 이해해야 한다. 또한, 같은 메트릭이라도 관측하려는 목적에 따라 쿼리가 달라질 수 있다. ✔ 경험상 아래 세 가지가 PromQL 정확도, 가시화에 도움되었다.메트릭 타입(Metric Type): Counter, Gauge, Hist..
[K8S] Mac Mini(Ubuntu)에 kind 기반 로컬 K8S Cluster 환경 구축하기
·
DevOps/DevOps
개요Ubuntu가 설치된 Mac Mini에 kind 기반 k8s를 구축하는 과정을 소개한다. (들어가며 - Local K8S Cluster 간략 소개)로컬 K8S 도구는 kind를 선택했다. 대표적으로 kind, minikube, kubeads 등이 있는데 해당 글에서 자세히 소개하진 않겠다. [k8s docs] 나는 EKS와 동작이 가까워야 사내 인프라에 대한 학습 효과가 좋다고 판단해서 kind를 선택했다. kind는 노드를 docker 기반으로 띄운다. 1. Network 환경 구성SRE가 된 지 어느덧 1년이 지났다. 그간 K8S 지식·운영에 대해 얼마나 성장했을까 돌이켜보면 부끄럽지만 아직 한참 부족한 점이 많았다. 리더와 이 고민을 공유했을 때 가지고 계신 구형 맥미니에 Ubuntu 서버를 설..
[Redis] 운영환경에서 AWS ElastiCache(Valkey)를 사용할 때 알아야 할 지식: 기본 구조, ClusterMode, MultiAZ, 업그레이드 동작방식
·
DB/In-Memory DB
개요 최근 Redis To Valkey 업그레이드 전환을 주도하면서 실제 작업을 통해 배운 운영 환경에서의 ElastiCache 사용방법에 대해 정리한다. 1. ElastiCache 기본 구조1.1. Shard와 NodeElastiCache를 생성할 때 Cluster Mode로 생성하면, Shard, Node 구성을 선택해야 한다. Shard와 Node(Replicas Per Shard)의 역할은 각각 다음과 같다.1.1.1. Shard데이터를 여러 샤드에 나눠 저장하여 CPU, 메모리 사용량을 분산한다.각 Shard는 데이터에 대한 Slot을 나눠서 가진다.key-value Store인 ElastiCache는 각 key에 대해 Hash Slot을 할당하고, Slot Number를 기준으로 key-val..
[BackEnd] Index를 통해 DB 조회 성능 1.2만배 개선하기
·
Dev/Backend
개요 어느 날부터 리소스를 조회하는 GET 요청에 대해 적게는 20초 많게는 120초까지 조회가 오래 걸리는 현상이 생겼다. 이를 해결하기 위해 했던 작업들과 개선 결과를 정리한다. 1. 간단한 프로젝트 구조 설명사내 배포 플랫폼에 기여하며 인프라 & 개발 업무 경험을 쌓고 있다. 주업무 중 하나는 AWS 리소스 관련 CRUD 개발인데, 프레임워크는 FastAPI를 사용하고 대부분의 요청은 Celery Task를 통해 동작한다. AWS 생성과 같은 요청은 본질적으로 느리고 실패할 수 있는 작업이다. S3 버킷, Redis 클러스터, EC2 인스턴스 등 생성에 수십 초~수 분 소요되며, 특히 Redis의 경우 여러 단계를 순서대로 실행해야 하는 복잡한 워크플로우를 따라야 한다. (ex. Subnet Gr..
[Redis] Redis 운영 지식: redis-cli 명령어 정리
·
DB/In-Memory DB
개요자주 사용하는 redis-cli를 미리 정리해두고, 장애 대응이나 모니터링 상황 시에 활용하자. 1. ElastiCache Endpoints1.1 Connection Endpoints각 엔드포인트의 역할을 잘 이해하고, 특히 클러스터 모드일 때의 접근 방법을 기억하자. 필자의 상황은 클러스터 모드를 활성화하고 샤드 2, 노드 2 구성을 가진 ElastiCache Engine을 하나 준비해두었다. 이와 같이 클러스터 모드가 활성화된 엔진이라면, 위 이미지처럼 Configuration Endpoint를 주로 활용한다. 참고로, 클러스터 모드를 비활성화한 경우는 Primary Endpoint가 생성되고, 해당 엔드포인트를 활용한다. 이와 같이 Shards and nodes 섹션에서 각 노드들의 Endpoi..
[AWS] EC2 EBS와 Instance Storage, Root/Local/Ephemeral
·
DevOps/AWS
개요EC2 관련 작업을 도맡으면서 서버 운영을 위해서는 Storage 개념을 잘 이해하고 있어야 한다는 점을 알게되었다. 운영 관점에서 고려해보니 루트 볼륨, 이퍼머럴 스토리지, 부팅 디스크 등등 여러 용어도 확실히 알아야 겠다 싶어서 이번 포스팅을 통해 정리해보려 한다. 1. EC2 Storage: EBS와 Instance StoreEC2에 연결할 수 있는 스토리지는 크게 다음과 같다. 이 포스팅에서는 EBS, Instance Store를 중점적으로 알아본다. EC2 스토리지 ├── * EBS (Elastic Block Store) │ ├── 루트 볼륨 (부팅용) │ └── 추가 볼륨 (데이터용) │ ├── * Instance Store (Ephemeral / Local Storag..
[회고] 2025년 첫 커리어 1년간 한 일
·
회고 & 후기/회고 & 후기
개요2025년 첫 커리어를 시작하고 SRE로서 회사에 기여한 일들을 정리해본다.(그대로 옮기니까 가독성이 좀 떨어지긴 한데..ㅋㅋ 작업 관련 스레드 링크를 모두 붙였다가 이걸 이미지와 글로 풀어내려니까 어려운 점..) 1) 서비스 캐시 성능 향상 및 인프라 비용 절감을 위한 ElastiCache for Valkey 도입| Problem안정적인 서비스 운영과 성능/비용 최적화를 위해 Valkey로의 전환을 추진| Task사내 플랫폼 ElastiCache 기능 개발 및 출시사내 플랫폼 API 개발boto3 API 검토 및 기존 Redis 워크플로우 기반 Valkey 생성 기능 구현Engine Version 조회 API 리팩토링: Redis 5.x/6.x 지원 중단, Valkey 7.2/8.x 버전 추가Par..
[DevOps] SSH 없이 안전하게 EC2 운영하기: SSM 기반 접근 제어와 전역 정책 설계
·
DevOps/DevOps
개요서비스가 점점 커지면서 개발자의 다양한 PoC 니즈를 충족하기 위해, EC2 Instance Self-Service 기능을 준비했다. 프라이빗 환경에서 서버가 뜰 테지만, 아무래도 서버를 오픈하는 건 여러 위험성이 있기에 작업 전에 테크 스펙을 작성해서 여러가지 인프라/보안 이슈에 대해 검토했다. 그 중에서도 가장 레슨런이 많았던 Session Manager와 SSM Logging에 대해 정리해보려고 한다. 1. EC2 Instance 접근 방식EC2 Instance에 접근하는 다양한 방식이 있다.1.1 EC2 Instance Connect (문서)브라우저 기반 SSH 연결 방식으로, AWS가 일시적인 SSH 퍼블릭 키를 자동 생성하여 60초간 인스턴스 메타데이터에 푸시한다. SSH Client와 다..
[BackEnd] 비동기 테스크 큐와 DI Container (feat. Celery)
·
Dev/Backend
개요 지금 학습 흐름이 아래와 같다.IoC & DIP & DI FrameWork의 DI Container로 여러 의존성 관리싱글톤 패턴 & DI Container 직접 만들어서 사용하기이 흐름에 따라서, 이번에는 DI Container를 직접 구현해서 사용할 때, 비동기 테스크 큐들이 어떤 이점을 누릴 수 있는지 살펴보자. 먼저 비동기 테스크 큐와 파이썬 생태계의 대표적 라이브러리인 Celery를 알아보고,규모가 큰 분산 환경 프로젝트에서 Celery와 같은 비동기 테스크 큐를DI Container에 등록하는 방법과 이점을 살펴볼 것이다. 1. 비동기 테스크 큐1.1 비동기 테스크 큐란?쉽게 말해서 지금 당장 처리하지 않아도 되는 일을, 나중에 따로 처리하게 만드는 시스템이다. 백엔드 서버는 보통 아래와..
[BackEnd] 싱글톤 패턴 & DI Container 직접 만들어서 사용하기
·
Dev/Backend
개요IoC, DI, DIP 알아보기DI Container 구현하고 Framework 이해하기^ 위 글에 이어 DI Container를 직접 구현해서 여러 객체 간의 의존성을 관리하는 것에 대해 더 깊이 이해해보고자 한다. 요즘 가장 많이 쓰는 프레임워크가 FastAPI이기에, 글도 이를 중점적으로 작성해 나갈 것이다. 1. Framework가 여러 의존성을 관리하는 방법 : DependsFastAPI의 의존성 주입은 함수 시그니처를 통한 선언적 의존성 관리와 Depends()가 핵심이다. Depends()는 한마디로 쉽게 "이 함수를 실행해서 결과를 여기에 넣어줘"라고 프레임워크에게 알려주는 도구다.이 Dependency Injection의 핵심 기능인 Depends()를 사용하지 않고 의존 관계를 구현..
[BackEnd] Framework 이해하기 - DI Container로 여러 의존성 관리
·
Dev/Backend
개요이전 글에서 IoC, DI, DIP를 알아보았다. 이제 여기서 확장해서 DI Container와 생명 주기 관리, Web Framework의 원리를 알아보자. 1. Framework프레임워크 본질 중 하나가 IoC다. 일반적으로는 개발자가 직접 코드 흐름을 제어하지만, 프레임워크는 이 흐름을 뒤집는다. (제어의 역전)프레임워크가 애플리케이션 코드를 호출 및 흐름을 제어하고, 개발자는 의존 관계만 정의하는 방식이다. framework라고 하면 DI 패턴을 통해서 여러 자원을 관리할 수 있는데, 이게 바로 IoC를 실현하는 구체적인 방법이다.FastAPI: 함수 인자에 Depends()를 명시한다. FastAPI가 호출 시점에 자동으로 의존성을 주입한다.Spring: @Component, @Service..
cobinding
'분류 전체보기' 카테고리의 글 목록