전체 글
-
이코에코(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) 당시는 빠른 API 기능 개발이 주요했기에 도메인 간 독립성을 일부 포기하더라도 서버 구현에 있어 간편한 방식을 택했다.MSA임에도 공통 모듈에 묶이는 ..
-
이코에코(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..
-
이코에코(Eco²) Scan API 성능 측정 및 시각화이코에코(Eco²) 2025. 12. 8. 04:36
공모전 수상 후 한 2-3일 간은 편히 쉬었다. 32일 골방 개발 + 이틀간 본선 쪽잠 작업의 반동이 꽤 크게 왔다.이력서를 업데이트하고 관련 포지션에 이리저리 지원한 후, '구축한 모니터링이 아깝다.'는 생각에 성능 테스트를 진행해 봤다.import osfrom locust import HttpUser, task, betweenclass ScanUser(HttpUser): # 사용자 간 대기 시간 (0.1~0.5초 랜덤 딜레이) -> 매우 공격적인 부하 wait_time = between(0.1, 0.5) @task def scan_classify(self): # 테스트용 이미지 (재활용 마크가 있는 이미지) payload = { "im..
-
이코에코(Eco²) 2025 새싹톤 우수상 수상 후일담잡담 2025. 12. 3. 11:00
이코에코(Eco²)가 2025 새싹톤 우수상에 선정됐다.10월 30일 즘부터 시작했으니 한 달간 Cluade/GPT와 골방 작업을 이어와서 체력과 몰골..이 말이 아니었다.대부분의 시간은 API 개발보단 K8s 클러스터 + Gitops 구축 및 개발에 소요했다.25년은 클라우드 스토리지 / 네트워크가 주스택이었던 만큼 코드 기반 인프라 역량을 내세우고 싶던 면이 컸다.본선에서도 배포 환경에서 개선/테스트가 발표 직전까지 진행됐기에 배포 파이프라인은 쓰임을 다한 편이다.FastAPI 기반 백엔드 API는 얇디얇아서 API 측면에선 도메인별 서비스를 분리한 점 외에는 딱히 내세울 지점은 없었다.GPT 5.1 Codex가 없었으면 이런 방식으로 구성하긴 힘들었겠지만, 파이썬/FastAPI 코드를 읽을 수 있고..