ym

현재 구성 요약

1. 공통 요소

   • Hazelcast를 기반으로 한 클러스터링(members, session-mode, backup, async-backup 등).

   • Graceful shutdown 설정과 기본적인 spring.lifecycle.timeout 관리.

   • 공통적으로 infinispan 설정 사용(cache-server와 cache-path는 환경에 따라 다름).

2. application-cache.yml

   • 캐싱 서버에 특화된 설정.

   • cluster.mode가 cache로 설정되어 있으며, 데이터 복제 및 세션 관리를 위해 Hazelcast 사용.

   • 별도의 캐시 경로(/app/ooooo/resource/ooooo/cache_v2)를 사용.

3. application-api.yml

   • API 서버에 특화된 설정.

   • cluster.mode가 api로 설정되어 있으며, default-service-group으로 API 관련 서비스를 지정(예: frontoffice, backoffice 등).

   • Hazelcast 클러스터의 멤버로 포함되어 있고, infinispan 모드가 client로 설정되어 있음.

4. application-core.yml

   • Core 서비스에 특화된 설정.

   • cluster.mode가 service로 설정되어 있으며, default-service-group과 exclude-service-group으로 서비스 범위를 제어.

   • API 서버와 마찬가지로 infinispan을 클라이언트 모드로 사용.

검토 및 개선 사항

1. Hazelcast 클러스터링

• 현재 상태:

  • 클러스터는 명시적으로 설정된 members(IP 주소 목록)를 기반으로 구성.

  • 데이터 복제(backup: 1, async-backup: 2)가 설정되어 있어 장애 복구 및 고가용성을 제공.

• 검토 및 제안:

  1. 클러스터 노드 자동 탐지:

     • members를 수동으로 관리하는 대신 Hazelcast의 Discovery SPI를 사용하여 노드를 자동으로 탐지하도록 구성 가능.

     • 예: AWS, Kubernetes 등의 클라우드 환경에서는 동적 클러스터 관리가 유리.

     hazelcast: network: join: multicast: enabled: false tcp-ip: enabled: true members: - cache-prd-ooooo.internal - core-prd-ooooo.internal

      

  2. 세션 분리:

     • session-mode가 Hazelcast에 종속되어 있으므로, 특정 Feature에서 세션 관리 로직이 필요하다면, 세션 분리를 고려.

     • 예: 특정 서비스(Analytics)가 별도의 세션 관리 방식을 사용하거나 독립적인 클러스터링이 필요할 경우.

2. Infinispan 설정

• 현재 상태:

  • Core 및 API 서버에서 infinispan을 클라이언트 모드로 설정.

  • Cache 서버와 분리하여 API 및 Core 서버가 캐싱 서버에 직접 접근하도록 구성.

• 검토 및 제안:

  1. 캐시 정책 최적화:

     • 캐싱 정책(예: TTL, eviction 정책)을 Feature별로 세분화할 수 있음.

     • 예: Hazelcast 내부의 분산 캐시를 활용하거나 Infinispan 설정을 추가로 세분화.

  2. 분산 캐시 모니터링:

     • 캐시의 적중률(Hit/Miss)을 모니터링하고, 필요 시 Prometheus 및 Grafana를 연동하여 효율성 검증.

3. Feature 별 MSA 지원

• 현재 상태:

  • default-service-group과 exclude-service-group으로 각 서버의 역할과 포함/제외되는 Feature를 제어.

• 검토 및 제안:

  1. Feature 상태를 동적으로 제어:

     • 현재는 yml 파일을 통해 Feature의 포함 여부를 제어하지만, 런타임에서 동적으로 설정을 변경하는 방식도 고려 가능.

     • 예: Spring Profiles 또는 Hazelcast의 분산 맵을 활용하여 Feature 상태를 동적으로 관리.

  2. Feature 간 통신 최적화:

     • 같은 서버 내에서는 직접 호출, 다른 서버 간 통신은 REST API로 처리하는 로직을 간소화하기 위해 서비스 레지스트리를 활용 가능.

     • 서비스 레지스트리를 사용하지 않는 경우, Hazelcast의 분산 이벤트(Pub/Sub)를 활용한 통신도 고려.

4. 환경 변수 관리

• 현재 상태:

  • 모든 설정이 application.yml에 포함되어 있어 각 서버 간 환경 차이를 수동으로 관리.

• 검토 및 제안:

  • Spring Cloud Config 또는 HashiCorp Vault를 도입하여 설정을 중앙화.

  • 이를 통해 환경별(dev, stg, prd) 설정을 효율적으로 관리 가능.

추가 고려 사항

1. 로그 관리

   • 현재 accesslog 설정이 포함되어 있으나, 중앙화된 로깅 시스템(예: ELK Stack)을 추가로 도입하여 통합 로그 관리를 고려.

2. 헬스 체크 및 장애 감지

   • management.endpoint.health 설정을 통해 서비스 상태를 확인 가능하지만, 클러스터 전체의 상태를 모니터링하려면 추가적인 모니터링 도구(예: Prometheus, Hazelcast Management Center)를 사용하는 것이 유리.

결론

현재 구성은 Hazelcast를 기반으로 MSA를 지원하기에 충분히 강력하며, 추가적인 복잡성을 도입하지 않고도 안정적으로 운영할 수 있는 구조입니다. 다만, 확장성과 유지보수를 더욱 개선하려면 다음을 고려할 수 있습니다:

1. Hazelcast의 Discovery SPI를 활용한 동적 클러스터 구성.

2. 분산 캐시 정책 최적화.

3. 런타임에서 Feature 상태를 동적으로 제어하는 기능 추가.

4. Spring Cloud Config를 통한 설정 관리 중앙화.