핀다·문제마이데이터 조회처럼 대량 트래픽이 들어오는 자산관리 서비스에서 동기 API 호출은 스레드 낭비와 높은 레이턴시를 유발한다.
접근이벤트 기반 아키텍처로 서버 간 의존성을 끊는다. 클라이언트는 SSE로 연결을 유지하고 서버 간 통신은 Kafka, 분산 환경 브로드캐스트는 Redis Pub/Sub, 비동기 상태의 동시성 제어는 Redisson 분산 락으로 처리한다.
결과동기 호출이 사라져 스레드를 효율적으로 쓰면서 더 많은 트래픽을 받는 구조가 된다. 대신 시스템 복잡도가 올라가는 트레이드오프가 있다.
핀다·문제AWS RDS의 rds-ca-2019 CA 인증서가 2024년 8월 만료되면 SSL/TLS 검증 실패로 DB 연결이 끊긴다.
접근AWS Health Dashboard와 describe-db-engine-versions CLI로 영향 인스턴스를 식별한다. SupportsCertificateRotationWithoutRestart 속성으로 재시작 필요 여부를 판단한 뒤 콘솔 Modify로 rds-ca-rsa2048-g1 등 새 CA로 교체한다.
결과인증서 업데이트는 콘솔 작업 2~3분, 실제 접속 중단은 8~20초로 끝난다. 신규 인증서는 2061년 또는 2121년까지 유효하고 이후엔 자동 교체를 지원한다.
핀다·문제MySQL 버전 업그레이드 시 클라이언트와 서버의 TLS 버전 합의가 안 되어 접속이 실패한다. 8.0.28부터 TLSv1.0/1.1이 제거됐다.
접근MySQL 5.7과 8.0.28의 지원 TLS 버전을 비교하고 Java/Python 드라이버로 핸드셰이크를 검증한다. `SHOW GLOBAL VARIABLES LIKE 'tls_version'` 으로 서버 지원 범위를 확인한다.
결과구버전 Java/Python 클라이언트에서 `TLSV1_ALERT_PROTOCOL_VERSION` 에러가 재현됐다. LTS 버전을 맞추거나 긴급 시 `useSSL=false` 로 우회한다.
핀다·문제자산/신용관리 서비스에서 MYDATA 의존 호출이 지연되면 의존 서비스로 장애가 전파되고 앱 렌더링이 지연됐다.
접근BFF(Backend For Frontend)로 여신·수신·MYDATA 응답을 클라이언트에 맞춰 합치고, Resilience4J CircuitBreaker로 장애를 격리한다. `failureRateThreshold 20%`, `slidingWindowSize 100`, `minimumNumberOfCalls 10` 으로 설정한다.
결과Pod Up/Down이 사라지고 스레드 효율이 올랐다. 대환대출 오픈 트래픽에 대비한 장애 격리가 확보됐다.
핀다·문제여신관리와 대출비교가 단일 DB에서 JOIN으로 강결합돼, 대출비교 트래픽이 늘면 여신관리까지 부하를 받았다.
접근DDD로 Bounded Context를 나눠 여신·수신·자산·배치 DB를 분리한다. Multi Datasource(CQRS)로 읽기/쓰기를 나누고 외래키를 제거해 QPS·Latency 영향을 줄인다. 빌드는 Maven에서 Gradle로 전환했다.
결과대출비교 DB CPU 워크로드가 약 10% 감소하고 평일 QPS가 약 20% 줄었다.
핀다·문제AWS EKS 기반 MSA가 커지면서 CloudWatch·Elasticsearch·Prometheus가 환경별로 흩어져 중복 설정·운영 비용·장애 대응 지연이 누적됐다.
접근LGTM 스택으로 통합한다. 메트릭은 Mimir + Prometheus Agent의 Remote Write, 로그는 EFK에서 Loki로 전환해 메타데이터 인덱싱, 트레이스는 Tempo + Istio + Spring Cloud Sleuth, 시각화는 Grafana로 단일 대시보드를 구성한다.
결과로그 스토리지 비용이 50% 이상 절감되고, 서비스 토폴로지가 자동 생성돼 RED 지표 기반으로 장애 원인 파악 시간이 줄었다.