Who and Why am I here?
제 소개와 연락처입니다. 각 페이지 맨 아래에 
또는 댓글 한마디 남겨주심 그저 좋아라~ 합니다.
또는 댓글 한마디 남겨주심 그저 좋아라~ 합니다.
My Cluster & its assets
2011년산 노트북(Intel Core i5, 16M) 내에서 동작하는 (Home) Kubernetes Cluster 및 여기서 운용 중인 서비스 링크, 그리고 설명(w/ git repo)입니다. 이 블로그 글에서 다루는 서비스 대부분을 여기서 테스트합니다.
최근 글
목록
Search
Introduction
아래의 golang 공식 SDK를 기준으로 proxy-wasm plugin을 빌드하는 방법과, 추가로 Istio 환경에서 배포 및 테스트하는 방법에 대해 설명한다.
상기 SDK는 다양한 내용을 포함하지만, 여기서 참조한 내용은 다음과 같다.
•
다양한 예제(examples 폴더 내) 중 Helloworld: 주요 기능(REQ/RES header, query string, path, body 변경, 주기적 실행(timer) 등)에 대한 예제 제공. 본 가이드는 주기적으로 로그를 뱉는 helloworld 만을 다루지만, 빌드 방법은 타 예제에 대해서도 동일하다.
•
빌드를 위한 전체 절차: 기본 빌드 방법 및 Makefile 기반한 자동화 및 구체 실행 절차
참고로, 이 SDK는 Proxy-Wasm 자체에 대한 상세 설명도 함께 제공하는데, Proxy-Wasm root 문서보다도 훨씬 더 자세하여 지금껏 보았던 그 어떤 문서보다 났다. 동일 주제를 다루는 Proxy-Wasm overview 작성 시 이를 몰랐다는게 아쉬울 지경.
Proxy-Wasm overview 작성 시 이를 몰랐다는게 아쉬울 지경.Prerequisite
•
golang 설치
•
docker 설치
•
OCI Image repository(e.g. dockerhub)
참고로 SDK의 README 가이드는 envoy 역시 설치를 요구하지만, macOS에 (brew를 통해) 설치되는 envoy는 default WASM runtime인 V8이 빠져있기에 실행이 안되기에 해당 step은 제외하였다. 따라서 테스트는 별도 Istio 기반의 istio-proxy에서 교체하였다. 그러므로 테스트를 위해서는 아래가 필요하다.
•
k8s 환경 내 동작하는 istio-proxy
golang으로 Proxy-Wasm 빌드&테스트 하기
as S/W 엔지니어
Proxy-Wasm
Envoy
WASM
WasmPlugin
Istio
golang
2025/06/13
Introduction
Istio resiliency 기반 장애 대응: overview 앞선 overview에 대한 상세 설명과 대응 방법, 추천 설정이다. 유의 사항으로 모든 추천 설정은 일반적 웹 서비스를 가정한 값이므로 적정 값은 각 서비스에 따라 상당히 달라질 수 있다. 쉽지 않지만 반복적 테스트를 통해 얻기를 강력 추천한다(특히, Circuit Breaker, Rate Limiting).Timeout
Timeout은 최대 응답 지연을 보장함과 동시에, 클라이언트 자원 고갈 문제를 방지하는 fast fail 기법으로, Circuit Breaker와 함께 클라이언트 자원 고갈 문제를 해결하는 주요 수단이다.
대응 문제
•
높은 지연 ( 주요 대응): 클라이언트의 오랜 대기를 방지한다. 최대 응답 지연 보장 효과이다.
주요 대응): 클라이언트의 오랜 대기를 방지한다. 최대 응답 지연 보장 효과이다.•
클라이언트 자원 고갈 ( 주요 대응): 오랜 대기로 인한 자원 고갈 문제를 제거한다. 마이크로서비스의 클라이언트는 받은 요청 처리를 위해 서버를 호출하기 마련이다. 즉, 받은 요청 만큼 서버 호출을 위한 자원 소비량은 늘어난다.
주요 대응): 오랜 대기로 인한 자원 고갈 문제를 제거한다. 마이크로서비스의 클라이언트는 받은 요청 처리를 위해 서버를 호출하기 마련이다. 즉, 받은 요청 만큼 서버 호출을 위한 자원 소비량은 늘어난다.•
연쇄적 장애 ( 부분적 대응): 클라이언트 자원 고갈로 인한 장애로의 발전을 사전에 차단한다. 하지만 서버 자원 고갈로 인한 장애는 해결하지 못하기에 한계가 있다. 서버 자원 고갈 대응안은 Rate Limiting이다.
부분적 대응): 클라이언트 자원 고갈로 인한 장애로의 발전을 사전에 차단한다. 하지만 서버 자원 고갈로 인한 장애는 해결하지 못하기에 한계가 있다. 서버 자원 고갈 대응안은 Rate Limiting이다.유의사항, 설정 방법, 추천 설정
•
호출 대상 API의 latency 고려: 호출 대상 API의 latency을 고려하여 설정하지 않으면 오탐(false positive)로 이어진다. 당연스럽게도 너무 길게 설정하면 설정 자체가 무의미해진다.•
설정 방법: https://istio.io/latest/docs/reference/config/networking/virtual-service/ 의 timeout field 및 예제 참고한다.
•
추천 설정: 호출 대상 API의 latency을 고려하는 것이 가장 중요하다. 참고로, 웹 사용자는 일반적으로 2~3초 내 응답을 기대한다고(AI 피셜). 또한 AWS Lambda function 역시 default timeout은 3초이다.
Retry
Istio resiliency 기반 장애 대응: feature 별 상세
as S/W 엔지니어
Istio
resiliency
timeout
retry
circuit breaker
rate limit
Envoy
outlier detection
회복탄력성
2025/05/24
Introduction
Istio는 다양한 resiliency features, 즉 Timeout, Retry, Circuit Breaker, Rate Limiting을 제공하지만, 이러한 다양성이 오히려 각기 어떤 문제에 대한 해결책인지 구분이 잘 안되는 혼선을 일으키고는 한다. 이는 마치 개발 시 요구사항이 불분명하거나 동일 요구사항에 대한 각기 다른 솔루션이 제시된 상황과 비슷하다. 또한, 잘못된 설정은 시스템 안정성을 직접적으로 위협하는 와중에 설정 자체가 까다롭기까지 하다. 따라서 명확한 이해가 더욱 요구된다.
본 문서는 이에 대한 대응으로, 이해와 함께 구체적 실행 방법을 요약한다.
참조 문서는 Istio, Envoy, Kubernetes 공식 문서 및 AI(주로 Grok, Gemini. Claude는 그림 정도…)이며, AI의 환각 이슈 대응도 함께 하였다(AI 간 cross checking, 타당성, 일관성 중심 검토). 용어는 되도록이면 canonical term을 쓰려고 ‘노력’했다(별도 권위있는 문서는 찾아볼 여유가 없었단게 변명 아닌 변명. 그나마 아래 Google SRE book을 일부 참조했지만 문서 작성 막바지에야 알게 되어서리…).
이외에 실험 기반이 아닌 개인 경험과 및 참조 문서에 의존한 내용임도 밝힌다.
장애 시나리오 예시
용이한 설명을 위해 먼저 장애 시나리오를 상정하였다. 서비스 A와 B(각각 10개 pod, pod 당 10 RPS 처리 가능)가 있을 때, A → B 호출 시 트래픽이 100 RPS에서 200 RPS로 급증(spike)한다고 가정한다. 이때 아래와 같은 순서로 장애가 발생 가능하다.
1.
높은 지연(High Latency): 과부하로 인한 B의 일부 pod 응답 시간이 5초로 증가, A의 대기 시간 증가.
2.
일시적 장애(Transient Failure): B의 pod에서 request queue 포화, 네트워크 혼잡 등으로 일시 또는 간헐적 5XX 오류 발생, A의 요청 실패.
3.
반복적 장애(Persistent/Repeated Failure): B의 특정 pods에서 5xx 오류 지속, B의 가용성 저하.
4.
연쇄적 장애(Cascading Failure)
Istio resiliency 기반 장애 대응: overview
as S/W 엔지니어
Istio
resiliency
retry
timeout
circuit breaker
rate limit
outlier detection
Envoy
회복탄력성
2025/05/20
Introduction
Istio/Envoy custom plugin 제작을 위한 Proxy-Wasm 검토로서, Proxy-Wasm은 Istio/Envoy와 같은 proxy 환경을 위한 WebAssembly(WASM) runtime 개방형 표준 인터페이스이다. Proxy-Wasm은 WASM을 이끄는 Bytecode Alliance와 Envoy 커뮤니티가 주도한다고.
2025.03.01 현재, 공식 spec repo가 stable latest 버전인 v0.2.1 기준 7개월 전에 commit된 것으로 보아(다음 버전은 2개월 전) 현재까지도 잘 지원이 이루어지는 듯 보인다. 이외에 Istio, Envoy 뿐 아니라 NGNIX를 포함한 유명 proxy 제품이 이를 지원 중(ATS, Kong, APISIX 등).
참고로, golang으로 Proxy-Wasm 빌드&테스트 하기는 Proxy-Wasm 개발의 bootstraping을, 아래는 본 문서의 내용을 기반으로 작성한 Proxy-Wasm Istio/Envoy filter으로, 본 문서에서는 구현 예로 언급한다(Rust 기반).
golang으로 Proxy-Wasm 빌드&테스트 하기는 Proxy-Wasm 개발의 bootstraping을, 아래는 본 문서의 내용을 기반으로 작성한 Proxy-Wasm Istio/Envoy filter으로, 본 문서에서는 구현 예로 언급한다(Rust 기반).•
openapi-endpoint-filter: Request path에 대한 OpenAPI 기반 enpoint를 request header 에 주입하여 Istio 메트릭 레이블의 값으로 사용 가능케 하는 plugin.
•
baggage-filter: 지정한 request header의 key, value를 W3C Trace Context의 baggage header의 항목으로 넣는 plugin.
왜 Lua 대신 WASM?
Lua를 쓰면 EnvoyFilter 등을 통해 WASM 보다 빠르고 간편하게 custom logic을 추가 가능하다( 참고). 하지만 아무리 Lua가 빠르게 동작한다 하더라도 script 기반이므로 proxy처럼 성능에 민감한 영역에는 부담이다. AI 피셜 Rust WASM 기준 2~5배 처리량이 떨어진다 하며 지연이나 리소스 overhead 역시 마찬가지. 기능적으로도 그러하여 대표적으로 Lua로는 metric 처리가 불가능하다. 즉, Lua는 ad-hoc 요구가 주 용도란 뜻. 아래 링크에는 WASM으로 처리 가능한 다수의 Envoy의 영역이 기술되어 있다.
Context
•
WASM(WebAssembly): 고성능 실행을 위한 브라우저 및 서버용 portable binary 표준으로, 여러 언어 지원, 운영체제 독립적, sandbox 환경이 특징. 참고로, WASI(WebAssembly System Interface)는 WASM이 OS를 호출 가능하게 하는 표준 인터페이스로 파일시스템, 네트워크, 시스템 호출 등을 지원한다. WASM + WASI가 어찌나도 중요해보이는지, docker의 아버지인 Solomon Hykes는 이거 있음 docker 안만들었고, WASM이 미래라고 하며, 실제 container 대체를 위한 많은 움직임이 있다(e.g. k8s용 WASM - runwasi, krustlet 등)
•
ABI(Application Binary Interface): binary 수준에서의 모듈간 통신을 위한 인터페이스로, 함수 호출, 메모리 정렬, 바이너리 형식 등을 정의. Proxy-Wasm spec은 사실 상 ABI에 대한 spec이다.
Proxy-Wasm overview
as S/W 엔지니어
Istio
Envoy
EnvoyFIlter
WASM
WebAssembly
Rust
Proxy-Wasm
2025/03/03
Introduction
일상이건 일이건 간에 상시 마주치는 질문, “어떻게 하면 최소한의 자원으로 원하는 결과를 얻을 수 있는가?”에 대한 생각으로, 질문에 담긴 두 가지 성질인 효과성과 효율성 간의 관계, 그리고 해결과 해소에 대한 나름의 정리이다. 결론만 말하자면 효과성보다 덜 중요해보이는 효율성이 효과성의 결과물인 ‘해결’보다 더 나은 무엇, 특히 ‘해소’를 이끈다는 거다.
해결(solution)보다 해소(dissolution)
일반적으로는 효과성(원하는 결과의 획득)을 우선 순위에 두고, 그 이후 효율성(’최소’한의 자원 사용)을 따지는게 자연스럽다. 이는 “자원 적게 쓰고 결과를 못 얻는 것과, 결과를 얻되 자원을 많이 쓰는 것 중 무엇이 중요하냐”란 질문을 던져보면 바로 드러난다. 아래와 같은 컴퓨터 과학에서의 유명한 격언도 있고(아래에서, 당연스럽게도, 최적화는 효율화의 동일한 의미의 다른 표현이다)
이는 ‘어떻게 하면 최소한의 자원으로 원하는 결과를 얻을 수 있는가’란 문제의 해결(solution)에 초점을 둔 논리이다. 헌데 만약 문제 자체를 더 이상 ‘문제’가 아닌 것으로 만들 수 있다면? 문제 풀이의 필요 자체를 제거하는 것이 ‘해결’보다 나은 무엇임은 자명하다. 우리는 필요가 없는 일에 애쓰는 걸 가리켜, 전문용어로 ‘삽질한다’라 표현한다.
그리고 바로 이 문제 풀이 필요 자체의 제거를 가리켜, 해소(dissolution)라 표현한다. 내가 아니라 (그 유명한) 비트겐슈타인이 그리 칭했다고 (나의 둘째 교주님이 알려주었다).
첨언하자면, 비트겐슈타인이 후기에 해소를 논하게 된 이유는 전기 시절에 열심히 ‘해결’에 힘을 뽑았더니만 알고보니 ‘해소’되면 굳이 ‘해결’하려고 힘쓰지 않아도 되었음을, 알고보니 죄다 삽질이었음을 깨달아, 그 허탈함을 느껴서 그런거 아닐까 싶다. 모르긴 몰라도.
효율성이 해소를 이끈다
위 논의는 문제 자체를 부정한 듯한 넌센스 또는 괘변으로 보일 수도 있는데 그렇지 않다. ‘문제’에는 그 문제 발생의 원인이 존재하기 마련이고, 해소는 그 원인 또는 메타(meta) 수준에서 문제를 다루는 것으로, 실제로 문제의 근원을 제거하는 것은 현실 세계에서 자주 사용되는 최선의 안이기 때문이다. 참고로, 컴퓨터 과학에서 리펙토링이란 활동은 문제가 되는 코드의 완전 제거, 즉 해소로 마무리되는 경우가 비일비재하다.
이제 문제는 ‘해소’ 방안을 어떻게 떠올릴 수 있느냐로 옮겨가는데, 이는 ‘효율성으로의 집중’이 아닐까 하는게 이 글의 핵심이자 주장이다. 이는 효과성의 한계를 생각해보면 명확하다. 효과성으로의 집중은 문제 자체가 그어논 경계 안에 초점이 머물도록 만든다. 이로 인해 경계 밖의 해결안, 즉 해소는 맹점으로 남기 마련이다(이를 가리켜 언론 비평에서 자주 언급되는 프레이밍(framing) 효과라 칭하는 듯 하다). 반면 효율성으로의 집중은 그 자체가 갖는 열린 속성으로 인해 효과성이 그어논 경계, 프레임 이상을 상상 가능하도록 한다. 효율성 - ‘더 나은 무엇이 없는지?’란 질문에 최종 종착지가 과연 존재하는지조차 의문이다.
🩻
해결보다 해소: 효율성이 해소를 이끈다
自省(Introspection) / 세상살이
효율성
해소
해결
dissolution
효과성
비트겐슈타인
최소작용의 원리
엔트로피 증가의 법칙
자연상수
2025/01/09
Introduction
대용량 메트릭 운용을 위한 Prometheus 호환 제품 비교로 Thanos, Cortex, VictoriaMetrics, Mimir를 중심으로 다룬다. Prometheus는 대용량 처리를 위해 Federation 아키텍처를 제안하나 여러모로 제한이 있기에, 대규모 메트릭 운용에는 일반적으로 Prometheus 호환의 전담 제품을 사용하는 것으로 이해한다.
참고로, alert 기능은 비교 대상에서 제외하였다. 이는 Alert는 선택에 있어 상대적으로 중요하지 않은 요소란 판단과 함께 비교 요소를 줄이기 위함이기도 하다(개인적으로 Grafana의 alert를 쓰고 있다는 것은 숨겨진 이유 ).
).비교 대상 제품
위 링크에 담긴 제품 목록 중 1차 검토를 통과한 제품인 Thanos, Cortex, VictoriaMetrics에 추가로 Mimir를 비교한다. 참고로 위 링크는 제품별 PromQL 호환성 수준 결과로서, PromQL 호환성 수준은 open-source 여부, Github Star 갯수와 함께 1차 검토의 가장 중요한 기준이다.
VictoriaMetrics는 PromQL 호환성이 타 제품이 100%인 반면, 상당히 낮다고 볼 수 있는 74.16%임에도, 높은 Github star 갯수(12.9k)와 단순한 아키텍처, 바이럴이 상당하기에 추가했다. Mimir는 Cortex에서 분가한 프로젝트로서, Cortex의 co-author와 주요 Contributers, 특히 Grafana에서 만든 것이기에 추가했다(metric consumer로서 압도적으로 많이 사용되는 제품은 Grafana이다).
기준에 부합함에도 제외한 제품은 M3인데, Github star 갯수도 상당하고(4.8k), VictoriaMetrics도 역시 타 제품 대비 약점으로 보이는 block storage를 주 저장소로 쓰기에 불공정해보이는 면이 없잖아 있지만, VictoriaMetrics 보다 Github star 갯수가 상당히 적고 아키텍처가 복잡해보인다는 점이 컸다.
이외에 Promscale은 RDB 기반으로 동작하여 PromQL과 SQL 모두를 지원하는 독특한 구조라 함께 다룰만해보이기도 하지만, 문제는 Github star 갯수가 1.3k로 적고 무엇보다도 현재 deprecated되었다고.
Architecture 관점 비교
아래 그림은 최좌측 metric source에서 생성된 metric이 최우측 metric consumer에서 소비되기까지의 과정을 나타낸다. Cortex와 Mimir는 푸른색으로 함께 다루었는데, Mimir는 Cortex에서 분가한 프로젝트이기에 아키텍처 관점에서는 동일하기 때문이다. 초록색은 VictoriaMetrics, 붉은색은 Thanos, 보라색은 Thanos, Cortex, Mimir 공통 컴포넌트에 해당한다.
이외에 앞서 말했듯 alert 관련 component는 제외했다(나아가 alert는 아키텍처 상 read path에 있는 타 컴포넌트와 구조가 동일하거나 더 단순하기에 생략해도 크게 문제될 게 없어 보인다).
VictoriaMetrics, Thanos, Cortex, Mimir의 아키텍처 관점 비교
Prometheus: 대용량 처리 제품 비교
as S/W 엔지니어
Prometheus
Thanos
Cortex
Mimir
VictoriaMetrics
2024/12/29
Load more
카테고리 별 글
목록
Search
as 음악인
13
Load more
as S/W 엔지니어
100
Load more
예술/인문 소감
73
Load more
自省(Introspection) / 세상살이
74
Load more
프로젝트s
92
Load more
방명록 백업