전체 글
-
이코에코(Eco²) Clean Architecture #3: Auth 버전 분리, 점진적 배포이코에코(Eco²)/Clean Architecture Migration 2025. 12. 31. 03:27
배포 전략: Canary리팩토링된 코드를 바로 배포해 클라이언트로 노출하는 것은 위험. Canary 배포로 일부 트래픽만 새 버전으로 라우팅하여 검증, PR에 부착된 Canary 라벨을 감지해 Canary 태그를 부착한 채로 패키징.┌─────────────────────────────────────────────────────────┐│ Istio VirtualService │├─────────────────────────────────────────────────────────┤│ X-Canary: true → auth-api-canary (version: v2) ││ (default) → auth-api (v..
-
이코에코(Eco²) Clean Architecture #2: Auth Clean Architecture 구현 초안이코에코(Eco²)/Clean Architecture Migration 2025. 12. 31. 03:26
아키텍처 개요계층 구조와 의존성 방향의존성 규칙(Dependency Rule): 모든 의존성은 바깥에서 안쪽으로만 향한다.핵심 원칙 설명:Domain 독립성: 비즈니스 로직이 프레임워크나 DB에 종속되지 않음의존성 역전(DIP): Application이 Port(Interface)를 정의하고, Infrastructure가 구현테스트 용이성: 각 레이어를 Mock으로 대체하여 격리 테스트 가능유연한 교체: Redis → Memcached, PostgreSQL → MongoDB 전환 시 Infrastructure만 변경현재 디렉토리 구조apps/auth/├── main.py # FastAPI 앱 진입점├── setup/│ ├── config/settings...
-
이코에코(Eco²) Clean Architecture #1: Auth 문제사안 도출, 리팩토링 전략이코에코(Eco²)/Clean Architecture Migration 2025. 12. 31. 03:24
기존 구조의 문제점폴더 구조domains/auth/├── tasks/ # 워커│ └── blacklist_relay.py├── database/ # DB 연결/세션├── interfaces/ # 추상화 인터페이스└── services/ # 비즈니스 로직문제 1: God Objectclass AuthService: def __init__( self, session: AsyncSession = Depends(get_db_session), token_service: TokenService = Depends(TokenService), state_store: OAuthStateStore = Depends(OAu..
-
이코에코(Eco²) Clean Architecture #0: Auth 리팩토링.MD이코에코(Eco²)/Clean Architecture Migration 2025. 12. 31. 01:10
작성일: 2025-12-31Opus 4.5와의 문답, 자료조사를 거치며 디벨롭한 문서이며 리팩토링 전 과정의 초안이 됩니다.1. 개요1.1 목표현재 domains/auth/ 구조를 Clean Architecture 원칙에 따라 apps/auth/로 리팩토링합니다.1.2 주요 변경사항항목현재목표루트 경로domains/auth/apps/auth/아키텍처혼합된 레이어드Clean Architecture의존성 방향양방향단방향 (안쪽으로만)ORM 결합Entity = ORM 모델Entity/ORM 분리2. 현재 기능 분석2.1 AuthService 메서드 → Use Case 매핑현재 메서드목표 Use Case타입파일authorize()OAuthAuthorizeInteractorCommandcommands/oauth_..
-
FastAPI Clean ExamplePython 2025. 12. 31. 00:29
참조: ivan-borovets/fastapi-clean-example작성일: 2025-12-30이 프로젝트에서 사용하는 아키텍처 패턴들의 원본 출처와 핵심 개념입니다.Clean Architecture항목내용창시자Robert C. Martin ("Uncle Bob")발표2012년 8월 블로그 → 2017년 책 출간원본The Clean Architecture책Clean Architecture: A Craftsman's Guide to Software Structure and Design (2017)핵심 원칙:의존성 규칙 (Dependency Rule): 의존성은 항상 안쪽(고수준)으로만 향한다독립성: Framework, UI, Database, 외부 에이전시로부터 독립적동심원 구조: Entities → U..
-
이코에코(Eco²) Deployment Strategy: Canary Deployments이코에코(Eco²) 2025. 12. 30. 22:10
2024-12-30 | 리팩토링을 앞두고 안전한 배포 전략 수립 TL;DR문제: 대규모 Clean Architecture 리팩토링을 안전하게 배포해야 함선택지: Rolling Update, Blue-Green, Canary결정: Canary 배포 (헤더 기반)이유: 기존 Istio 인프라 활용, 비용 효율성, 점진적 검증 가능1. 배경1.1 현재 상황도메인 서비스들의 Clean Architecture 리팩토링을 앞두고 있다. Auth 서비스를 시작으로 모든 도메인 서비스에 다음 변경이 예정되어 있다: 디렉토리 구조 전면 개편 (models/ → domain/entities/, services/ → application/commands/ 등) CQRS 패턴 도입 (Command/Query 분리) Re..
-
Blacklist에 Outbox 패턴을 도입하고 잠시 잡담잡담 2025. 12. 30. 18:44
ext-authz의 성능을 극대화하는 방향으로 기존 로그아웃 로직(Redis 직접 조회)을 로컬 캐시 조회로 수행하도록 디벨롭했다.위 작업이 기존의 Persistence Layer(Redis) 직접 접근과 동일하게 수행되려면 로컬 캐시와 레디스 간의 정합성을 맞춰야한다. 절차를 안내하면 아래와 같다.Logout 엔드포인트 호출Auth에서 Redis에 직접 접근해 Blacklist에 JWT 저장Logout Event 발행 (Publisher)RabbitMQ에서 Fanoutext-authz에서 Event 수신 (Subscriber)로컬 캐시 업데이트위 방식으로 Eventual Consistency를 구성하면, 대다수의 케이스에서 정합성이 유지가 된다. 성능은 RPS 기준 1200->1500으로 +25% 상승..
-
이코에코(Eco²) Eventual Consistency #4: Blacklist Relay Worker 구현이코에코(Eco²)/Eventual Consistency 2025. 12. 30. 15:35
1. 전체 디자인1.1 시스템 개요①auth-api → RabbitMQ정상 발행 (99%+)②auth-api → RedisMQ 실패 시 Outbox 적재③Redis → auth-relay1초마다 폴링④auth-relay → RabbitMQOutbox 이벤트 재발행⑤RabbitMQ → ext-authzFanout 브로드캐스트1.2 데이터 흐름단계컴포넌트동작①Redis BlacklistSETEX token:blacklist:{jti} {ttl}②Publisherbasic_publish() 시도③Outbox → Relay실패 시 LPUSH → RPOP → republish④RabbitMQFanout 브로드캐스트⑤ext-authzcache.Store(jti, entry) 2. 주요 컴포넌트2.1 컴포넌트 의존성..