전체 글
-
이코에코(Eco) ext-authz 추가 테스트: Redis 병렬 연결 활성화 (vCPU 2, io-threads 2)이코에코(Eco²)/Auth Offloading (ext-authz) 2025. 12. 17. 04:32
추가 테스트: Redis io-threads 활성화Client 1 ──┐Client 2 ──┼──→ [ Command Queue ] ──→ [ Main Thread ] ──→ 순차 실행Client 3 ──┘ (FIFO) (싱글 스레드) 앞서 ext-authz 성능 튜닝에서 Redis 싱글 스레드의 한계를 언급했다.Redis 6.0+부터 io-threads를 지원하므로, I/O 병렬화로 성능 개선이 가능한지 테스트했다.그렇다고 Command Queue가 병렬로 쌓이진 않는다. 명령 실행은 단일 스레드에서 순차실행이 되는 걸 유의하고 진행하자.io-threads가 CPU 경합없이 동작하더라도 네트워크/직렬화 병목까지만 완화가 가능하다. 테스트 환경Redis 노드t3.medi..
-
튜닝하다 진이 빠진 채로 잡담잡담 2025. 12. 16. 10:09
이제 어느덧 이코에코가 어엿한 클라우드 네이티브라고 부를 수 있을만큼 성장했다.작성일 기준으로 Observability가 grafana, prometheus 밖에 없는 게 아쉽지만..분산 백엔드 / 인프라를 이만큼까지 직접 구축해 본 사람도 드문 걸 알기에 나름의 자부심이 있다.물론 틈틈이 구축한 분도 많겠지만.. GitOps, K8s, 좀 심하다 싶으면 노드별 분리까지 하는 분들을 간간히 보긴 했다.그렇지만 Istio에, 성능 높인다고 Go 서버까지 따로 개발한 분은 아마 잘 없을 거다. 역시 문제는 '이게 얼마나 잘 어필이 되느냐'다..스트레스 테스트와 고도화를 진행하며 성능 지표를 추출할 최소한의 Observability와 프로세스는 만들어뒀으니 내보일 건 많을 수 있겠다..만 서류 통과가 최대 ..
-
이코에코(Eco²) ext-authz 성능 튜닝: Redis PoolSize, HPA이코에코(Eco²)/Auth Offloading (ext-authz) 2025. 12. 15. 20:30
이코에코(Eco²) ext-authz: Stress Test 에서 밝혔듯 ext-authz의 주된 병목은 Redis PoolSize와 cpu-limits다.당시 Redis PoolSize는 10으로 users:2000, ramp-ups:200 지점부터 점진적으로 부하가 나타나다가,users:2500, ramp-ups:250부터 본격적으로 avg latency 증가, RPS 42로 급감하며 포화상태를 보였다.Eco² 클러스터 Redis 구성 현황ubuntu@k8s-master:~$ kubectl get pods -n redis -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED..
-
이코에코(Eco²) ext-authz: AuthN/AuthZ 검증 엔진 Stress Test이코에코(Eco²)/Auth Offloading (ext-authz) 2025. 12. 14. 15:29
ext-authz 서버 개발기에서 이코에코 서비스 API(GET)로 ext-authz의 대략적인 성능을 테스트했다.당시 유저수 200명->1000명으로 증가하도록 테스트해도 서비스 API의 RPS가 250-280선에서 증가하지 않아, ext-authz 서버가 부하를 온전히 받지 못했다. 서비스 API(GET)엔 도메인별 DB 조회 로직이 포함된만큼 변수가 많았기에, ext-authz 서버의 임계 성능을 알아보고자 더미 엔드포인트(/api/v1/character/ping)를 만들고 AuthN/AuthZ 검증 필터를 통과하도록 구성했다.주요 리소스 스펙이코에코 클러스터 내 ext-authz 부하 테스트에 영향을 받는 리소스들의 스펙은 아래와 같다.EC2 인스턴스k8s-api-charactert3.small2..
-
이코에코(Eco²) Auth Offloading: 도메인 공통 모듈 제거이코에코(Eco²)/Auth Offloading (ext-authz) 2025. 12. 13. 17:17
지난 포스팅에 더해 Auth Offloading을 이어서 작성하겠다.Auth Offloading이 필요했던 이유와 가능해진 배경, 의사결정 과정, 구현, 부하 테스트까지를 다뤘다면이 글에선 Auth Offloading으로 얻을 수 있던 소소한 개선과 한계를 서술한다. 기존 구조의 문제점domains/├── _shared/│ └── security/ # 공통 모듈│ ├── jwt.py # TokenPayload, extract_token_payload│ └── dependencies.py # build_access_token_dependency├── scan/│ └── api/dependencies.py → import from _shared/s..
-
이코에코(Eco²) Auth Offloading: ext-authz 서버 개발기 (Go, gRPC)이코에코(Eco²) 2025. 12. 13. 17:13
이코에코(Eco²) Service Mesh #2: gRPC 마이그레이션에서 언급된 Auth Offloading을 진행했다.이 과정을 이해하려면 먼저 백엔드/인프라 고도화 전의 Auth, '공모전 당시 클러스터는 어떻게 동작하고 있었나.'를 알아야 한다.Eco² v1.0.0 Auth기존 방식은 Auth의 공통 모듈을 전 도메인 서버에 심어 검증 로직과 유저 정보 추출을 수행토록 했다. 선택한 근거는 아래와 같다.1) Istio 전 이코에코 클러스터엔 Ingress GW가 없어 세밀한 라우팅이 불가능했다. (API 접근 전, Auth 서버 우선 라우팅)2) 모든 도메인 서버가 AuthN/AuthZ를 공통 모듈에서 끌어오고 있었다.당시는 빠른 API 기능 개발이 주요했기에 도메인 간 독립성을 일부 포기하더라도..
-
이코에코(Eco²) Service Mesh #2: 내부 통신을 위한 gRPC 마이그레이션이코에코(Eco²)/Kubernetes Cluster+GitOps+Service Mesh 2025. 12. 12. 04:04
동기식 HTTP 통신의 한계와 아키텍처 전환의 필요성지난 포스팅에서 다룬 Scan API 성능 분석 결과, LLM 파이프라인 중 Answer Model(GPT 5.1)이 주된 병목임을 확인했다. 하지만 LLM 모델의 병목은 API를 호출하는 입장에선 접근할 수 없다. 선택 가능한 방향인 서비스 간 통신의 효율성을 확보하는 게 최선이다.현재 이코에코는 Scan -> Character -> Scan으로 이어지는 동기식 HTTP/1.1 호출 구조를 가지고 있다. 트래픽 증가 시 HTTP Connection Overhead와 JSON 직렬화 비용은 무시할 수 없는 Latency 요인이 되며, 진행 중인 Auth-Offloading(Envoy ext_authz) 도입을 위해서도 내부 통신 인터페이스의 표준화(gR..
-
이코에코(Eco²) Service Mesh #1: Istio Sidecar 마이그레이션이코에코(Eco²)/Kubernetes Cluster+GitOps+Service Mesh 2025. 12. 8. 12:26
공모전을 마치고, 프론트 측에서 웹앱에서 앱 배포로 전환하고자 React에서 React Native로 이관하려했다.현재 이코에코의 Auth는 JWT를 쿠키에 담아 인증 로직을 진행하기에 브라우저 보안 모델에 의존하는 형태다.프론트 측에서 React Native로 전환하기 전에, Auth를 쿠키 대신 헤더에 담아 전송하는 방식으로 리팩토링을 진행할 계획이었다.Scan API의 성능 측정에서 밝혔듯, 도메인별 컴퓨팅 리소스가 부하에도 넉넉한 상태라 Auth 리팩토링에 맞춰 이전에 고려했던 Istio 도입을 진행해봐도 무리가 없다는 판단이 섰다. 클러스터 + API 개발기 때 Auth의 공통 모듈에 꽤 골머리를 앓았기도 해서 이 역할을 분리해 위임할 피쳐가 필요했다. Istio란 무엇이고, 왜 도입하나Isti..