마이크로서비스 아키텍처 요소

서비스 디스커버리(Service Discovery)

개념 및 필요성:
마이크로서비스 환경에서는 서비스 인스턴스가 동적으로 늘어나거나 줄어들고, 컨테이너나 VM 재시작 시 IP나 포트가 변경될 수 있습니다. 전통적인 정적 설정(IP, DNS)으로는 유연한 대응이 어렵습니다. 서비스 디스커버리는 이런 동적 변화를 중앙 레지스트리에 반영하고, 다른 서비스가 특정 서비스의 "논리적 이름"만 알고 있으면 동적으로 실제 IP/포트를 얻어올 수 있게 합니다.

기술 요소:

• Eureka(Netflix OSS), Consul(HashiCorp), Zookeeper(Apache) 등이 대표적입니다.
• 각 서비스는 시작 시 자신을 디스커버리 서버에 등록(Register)하고, 주기적으로 Heartbeat를 전송하거나 TTL 기반으로 등록 정보를 갱신(Update)합니다.
• 클라이언트 사이드 로드밸런싱(Ribbon, Spring Cloud LoadBalancer) 또는 서버 사이드 로드밸런싱(Consul+Envoy 등)을 통해 서비스 디스커버리 정보에 기반한 로드분산이 가능합니다.

운영 시 고려사항:

• 고가용성을 위해 서비스 디스커버리 서버를 클러스터링합니다.
• 보안 설정(ACL, TLS) 및 접근 통제, 인증 설정을 고려해야 합니다.

---

서비스 게이트웨이(Service Gateway)

개념 및 역할:
API 게이트웨이는 마이크로서비스 외부(클라이언트)와 내부(서비스) 사이에 위치해 단일 진입점 역할을 합니다. 이를 통해 클라이언트는 마이크로서비스의 복잡한 내부 구조를 알 필요가 없으며, 게이트웨이가 요청을 적절한 서비스로 라우팅하고 부하분산 합니다.

기능 확장:

• 인증/인가 처리: 요청 헤더 토큰 검증, Keycloak 등의 Identity Provider와 연동.
• 로깅, 추적 ID 삽입: 요청마다 추적용 Correlation ID나 Trace ID를 삽입해 이후 Zipkin 같은 트레이싱 도구로 분석.
• 요청 변환 및 스키마 검증: 요청이나 응답을 표준 형식(JSON Schema)에 맞게 변환하거나 검증할 수 있습니다.
• Rate Limiting, Circuit Breaker 적용: 특정 클라이언트나 경로에 대한 호출 빈도를 제한하거나, 특정 백엔드 서비스 장애 시 폴백(Fallback) 처리하는 기능 구현.

운영 시 고려사항:

• 게이트웨이 역시 스케일 아웃이 가능해야 하며, 무중단 배포 전략(Blue-Green, Canary)을 활용할 수 있습니다.
• HTTPS/TLS, WAF(Web Application Firewall) 연동, DDos 방어 등 보안 고려가 필수적입니다.

---

키클록(Keycloak) 서버

역할:
Keycloak은 Authentication(인증)과 Authorization(인가)에 특화된 IAM 솔루션입니다. 애플리케이션 개발자가 직접 OAuth2, OpenID Connect 등의 복잡한 인증 표준을 구현하지 않고, Keycloak을 통해 통합 관리할 수 있습니다.

특징:

• 사용자 계정 관리, 패스워드 정책, 계정 잠금, 패스워드 초기화 등 사용자 Lifecycle 관리를 지원합니다.
• 클라이언트(웹앱, API)마다 권한 범위를 정의하고, Role(역할) 기반 접근 제어(RBAC), Attribute 기반 접근 제어(ABAC)도 가능합니다.
• SSO(Single Sign-On), Social Login, MFA(2단계 인증) 구현이 용이합니다.

운영 시 고려사항:

• Keycloak 역시 고가용성을 위해 클러스터링 및 외부 DB 연동이 필요합니다.
• OIDC 토큰 유효기간, Refresh 토큰 정책, Public/Confidential Client 설정 등을 통해 보안을 강화합니다.

---

비즈니스 서비스 (조직서비스, 라이선싱서비스)

조직 서비스(Organization Service):

• 기업 내 사용자 그룹 관리, 파트너 정보, 조직도 등의 도메인 로직을 담당합니다.
• 독립된 코드베이스, API 명세(Swagger, OpenAPI), 자체적인 데이터 모델을 갖추며, 다른 서비스(예: 라이선싱 서비스)로부터 조직 정보를 참조받을 수 있습니다.

라이선싱 서비스(Licensing Service):

• 소프트웨어 라이선스 발급, 갱신, 유효성 검증 로직 담당.
• 라이선싱 DB에 접근해 고객별 라이선스 상태를 확인하고, 기간 만료 시 알림 또는 제한 등 비즈니스 룰을 구현합니다.

운영 시 고려사항:

• 서비스별 지속적 배포(CI/CD) 파이프라인을 갖추어 변경사항을 신속하고 안전하게 릴리즈합니다.
• 서비스간 통신 패턴(동기 REST, 비동기 메시지 큐)을 선택하고, SLA에 따라 타임아웃, 폴백 전략을 수립합니다.

---

라이선싱 데이터베이스(Licensing DB)

특징 및 고려사항:

• 라이선싱 서비스 전용 DB로, 관계형 DB(MySQL, PostgreSQL)나 NoSQL(MongoDB, DynamoDB) 사용 가능.
• 스키마 변경 시 서비스별 독립적인 배포 및 마이그레이션 전략 필요.
• 백업, 이중화 구성, 주기적 성능 모니터링, 인덱스 튜닝으로 고성능/고가용성 확보.

---

Redis (캐시/세션 저장소)

역할:

• 라이선스 정보 캐싱: 자주 조회되는 라이선스 상태를 Redis에 저장하여 DB 부하 감소.
• 세션 관리: Stateless 마이크로서비스라 하더라도 인증 토큰, 사용자 세션 정보를 Redis에 저장해 빠른 조회 가능.

운영 시 고려사항:

• Redis 클러스터링, Sentinel을 통한 고가용성 구성을 고려하고, TTL(만료 시간) 전략을 통해 캐시를 최신 상태로 유지합니다.
• 장애 발생 시 캐시 미스(Cache Miss)에 대한 성능 영향도를 분석합니다.

---

Zipkin (분산 트레이싱)

역할:

• 마이크로서비스 호출 체인을 시각화합니다. 어떤 요청이 어떤 서비스들을 거쳐 얼마나 시간이 걸렸는지 파악, 병목 구간을 식별.
• Request/Response Latency 분석, SLA 준수 여부 확인, 장애 시 원인 추적에 유용.

운영 시 고려사항:

• 모든 서비스에서 Trace ID를 로깅하고, Zipkin Collector에 전송.
• 샘플링 전략 설정(모든 요청 추적 vs 부분 추적)으로 성능과 관찰성 균형 잡기.

---

Logstash (로그 수집 파이프라인)

역할:

• 각 서비스 컨테이너/호스트에서 발생한 로그(어플리케이션 로그, 액세스 로그)를 수집, 구조화(JSON 파싱, 필터링), Elasticsearch로 전송.
• 로그 포맷을 표준화, 민감정보 마스킹 등 사전 처리하여 분석 품질 개선.

운영 시 고려사항:

• 파이프라인 성능 및 지연 모니터링, 재시도 정책, 데이터 손실 방지(비휘발성 큐) 전략 필요.
• 로그 증가량에 따른 Elasticsearch 스토리지 확장, 인덱스 관리(인덱스 로테이션, 수명 주기 관리) 전략 필요.

---

Elasticsearch (검색 및 분석 엔진)

역할:

• 구조화된 로그, 메트릭, 이벤트 데이터를 색인(Index)하고, 고속 검색과 집계를 지원.
• Kibana, Grafana 등과 연계해 대시보드 작성 가능.

운영 시 고려사항:

• 클러스터링(마스터, 데이터 노드 구분) 및 Shard/Replica 전략 설정.
• ILM(Index Lifecycle Management) 적용해 오래된 로그를 삭제 또는 더 저렴한 스토리지로 이동.
• 적절한 필드 매핑과 인덱스 템플릿 관리로 분석 성능 및 스토리지 비용 최적화.

---

Prometheus (메트릭 수집/모니터링)

역할:

• 각 서비스 및 인프라(노드, 컨테이너, DB)에서 노출하는 메트릭을 정기적으로 수집(Pull)하고 시계열 데이터로 저장.
• 특정 메트릭 임계값 초과 시 Alertmanager 연동으로 경보 발송.

운영 시 고려사항:

• Exporter(노드 익스포터, 애플리케이션 익스포터) 배치로 CPU, 메모리, GC, 응답시간 등 모니터링.
• 장기 저장소 고민: Prometheus의 기본 스토리지는 짧은 기간 보존에 최적화, 장기 보존 시 Thanos, Cortex 등 추가 솔루션 검토.

---

Grafana (시각화 도구)

역할:

• Prometheus나 Elasticsearch, InfluxDB 등 다양한 데이터 소스에 연결해 실시간 대시보드 제공.
• 운영팀이 원하는 지표(CPU 사용률, 요청 응답 시간, 오류율, 트래픽 변화 추세)를 시각적으로 표현해 신속한 의사결정 지원.

운영 시 고려사항:

• 조직 요구사항에 맞는 대시보드 템플릿 구축.
• 권한 관리, 대시보드별 접근 제한, 알람 연동(Slack, 이메일) 설정.

---

Kibana (Elasticsearch 데이터 시각화)

역할:

• Elasticsearch 인덱스의 데이터에 대해 대화형 쿼리, 필터링, 집계를 지원.
• 로그 패턴 분석, 특정 오류 발생 시점 검색, IP/경로별 요청량 패턴 분석 용이.

운영 시 고려사항:

• 인덱스 패턴, 필드 목록 관리.
• Visualize, Dashboard 기능 활용해 실시간 오류 모니터링 대시보드 구성.

---

통합 아키텍처 예시 워크플로우

1. 사용자 요청: 클라이언트는 게이트웨이 URI로 요청 전송. 게이트웨이는 Keycloak 토큰을 검증하고 Service Discovery를 통해 필요한 서비스의 엔드포인트를 찾아 요청 라우팅.

2. 비즈니스 로직 수행: 조직서비스나 라이선싱서비스가 요청 처리. Redis를 조회해 캐싱된 데이터 활용, 라이선싱 DB에서 정보 Fetch.

3. 로그 및 트레이싱: 요청 처리 과정 중 로깅 라이브러리가 로그 출력 -> Logstash가 수집 및 Elasticsearch에 색인. 분산 트레이싱 라이브러리(Brave, OpenTracing 등) 사용 시 Zipkin에 Trace 정보 전송.

4. 모니터링과 대시보드: Prometheus가 주기적으로 서비스 메트릭 스크랩, Grafana 대시보드에서 실시간 모니터링. Kibana로 로그 분석, Zipkin으로 성능 병목 지점 파악.

---

결론

마이크로서비스 아키텍처에서 각 컴포넌트가 수행하는 역할, 상호 작용 방식, 운영 시 고려해야 할 요소들을 명확히 할 수 있습니다. 이들 인프라 요소를 종합적으로 활용하면, 마이크로서비스가 가진 확장성, 유연성, 독립 배포성이라는 장점을 극대화할 수 있으며, 관찰성(Observability) 강화, 빠른 장애 대응, 지속적 개선을 통한 고품질 서비스 제공이 가능해집니다.