Istio
-
분산 트레이싱 트러블슈팅: NetworkPolicy, Zipkin, OpenTelemetry이코에코(Eco²)/Troubleshooting 2025. 12. 18. 11:48
개요Jaeger UI에서 "No service dependencies found" 메시지가 표시되고, 서비스 간 호출 관계가 보이지 않는 문제를 해결한 과정입니다.문제 증상관찰된 현상앱의 OTEL SDK 트레이스는 Jaeger에 정상 수집됨Istio Ingress Gateway 트레이스도 일부 수집됨하지만 서비스 간 Dependencies가 표시되지 않음각 서비스의 sidecar(Envoy)가 생성한 트레이스가 누락됨Jaeger UI 스크린샷 (문제 상황)Services: auth-api, character-api, chat-api, ...Dependencies: "No service dependencies found"진단 과정1단계: 트레이싱 아키텍처 이해Istio Sidecar(Envoy)는 Zipk..
-
이코에코(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 #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..