Who and Why am I here?
제 소개와 연락처입니다. 각 페이지 맨 아래에 
또는 댓글 한마디 남겨주심 그저 좋아라~ 합니다.
또는 댓글 한마디 남겨주심 그저 좋아라~ 합니다.
My Cluster & its assets
2011년산 노트북(Intel Core i5, 16M) 내에서 동작하는 (Home) Kubernetes Cluster 및 여기서 운용 중인 서비스 링크, 그리고 설명(w/ git repo)입니다. 이 블로그 글에서 다루는 서비스 대부분을 여기서 테스트합니다.
최근 글
Search
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 등).
참고로, 다음은 본 문서의 내용을 기반으로 작성한 Proxy-Wasm Istio/Envoy filter으로, 본 문서에서는 구현 예로 언급한다. WASM 적용 방법 역시 아래 링크에 기술되어 있다.
•
path-template-filter: Request path에 대한 OpenAPI 기반 path template을 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이다.
•
Envoy는 비동기 이벤트 기반 아키텍처: 근거는 공식 아키텍처 문서, libevent 사용 코드로서, 현대의 proxy 중 이 모델을 안쓰는 proxy가 있을까 싶다(자체 경량 thread를 쓰는 golang만 예외인 줄 알았더니만 찾아보니 꽤 많다. 경량 thread가 의미있게 뜨는 중인 듯). runtime 아키텍처를 이해하기 위한 context로서, 일정 갯수(e.g. CPU core 갯수)의 worker thread가 만들어진다는 의미이다. 참고로, 공식 문서는 Envoy (란 특정 제품) 를 직접 언급한다.
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
공부법 핵심: 대칭화, 모듈화, 순서화 에서도 잠시 언급했듯이 나의 (농담삼아) 나의 두 번째 교주님으로 ‘모시는’ 박문호 박사의 ‘철학’이다. 이 분을 만나는 주된 미디어는 유튜브 및 팟캐스트라 이렇게 글로 남기고파도 쉽지 않았는데, 오히려 몇몇 인터뷰에서 그의 생각이 잘 정리되어있음을 발견했다.제목에 ‘철학’이란 용어를 넣었는데 그가 이 제목을 보면 식겁해할지도 모르겠다. 그는 철학이란 학문에 대해 상당히 비판적인 입장이기 때문이다. 그럼에도 이렇게 제목을 단 이유는 내가 찾은 용어 중 그나마 본문의 주제를 담는 최선의 선택이기 때문이다.
아래 4개 링크는 해당 인터뷰 원문이고 이어지는 것이 내게 깊게 파고든 부분의 모음이다.
자연 과학에 관하여
•
자연과학 전공자가 역사, 철학 등 인문학을 파고드는 사례는 많이 보아왔다. 하지만 인문학 전공자가 양자역학을 공부하겠다고 나서는 것은 보지 못했다.
•
자연과학을 모르는 것은 비극적 희극이다. 제한된 인식 내에서 살아가는 것. 인간의 특성은 매니아 기질이다. 사람은 누구나 어떤 것에 특별한 관심을 가지고 그것에 집중하는 속성이 있다. 그런 성질을 이해하고 인정하지 않으면 오히려 그것을 깨뜨리기 힘들다. 매니아 기질을 컨트롤 하지 않으면 좁은 세계관에 갖히기 쉽다. 인식의 틀을 부수고 새로운 것을 받아들일 수 있는 것이 자연과학적 사고이다.
•
Q. 자연과학을 모르고 사는 사람이 스스로 충분히 행복하다면? A. 말하자면 천년 전의 인간과 다를 바 없이 사는 것이다. 그들도 행복했을 것이다.
•
Q. 자연과학 도그마는 옳은 것인가? 좋은 것인가? A. 효과적인 것이다.
•
사실상 자연을 가장 빨리 만나는 방법은 서울의 빌딩에서 석회암, 대리석을 보는 것이라고 할 수 있죠.
박문호 박사의 ‘철학’
自省(Introspection) / 세상살이
박문호
자연과학
2024/12/07
Load more
카테고리 별 글
Search
as 음악인
13
Load more
as S/W 엔지니어
100
Load more
예술/인문 소감
73
Load more
自省(Introspection) / 세상살이
73
Load more
프로젝트s
92
Load more
방명록 백업