KubernetesIstio

Istio - Locality Load Balancing (지역 로드 밸런싱)

목차

참고

Istio - Locality Load Balancing

Istio 의 Locality Load Balance 는 서비스 요청을 지역적으로 분산시키는 기능을 제공합니다.

Locality Load Balance는 서비스 요청이 클러스터 내에서 발생할 때 해당 요청이 가장 가까운 지역의 서비스 인스턴스에 배정되도록 보장합니다. 이를 통해 클라이언트와 서비스 인스턴스 사이의 대기 시간을 줄이고, 네트워크 대역폭을 절약하며, 네트워크 병목 현상을 방지할 수 있습니다.

Locality Load Balance는 Istio의 Envoy 프록시에서 구현됩니다. Envoy는 클러스터 내의 모든 서비스 인스턴스에 대한 위치 정보를 유지 관리하며, 클러스터의 지리적 분포를 파악하여 요청을 지역적으로 분산시킵니다.

Locality Load Balance는 또한 Istio의 트래픽 관리 기능과 통합됩니다. Istio는 트래픽 관리 규칙을 정의하여 특정 서비스 인스턴스가 특정 지역에서만 처리되도록 할 수 있습니다. 이를 통해 서비스의 가용성을 높이고, 서비스 인스턴스 간의 부하를 균형있게 분산시킬 수 있습니다.

모든 AZ 로 istiod 확장

apiVersion: apps/v1
kind: Deployment
metadata:
  name: istiod
  namespace: istio-system
spec:
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: istiod

trafficPolicy 설정

Envoy Proxy에서 Locality Load Balancing을 사용하도록 설정합니다. 이를 위해서는 Istio의 서비스 메쉬 구성에서 trafficPolicy 를 설정합니다. 예를 들어, 다음과 같이 trafficPolicy 를 설정할 수 있습니다:

my-service는 사용자가 지역별로 분류하려는 대상 서비스 이름입니다.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service
spec:
  host: my-service
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        enabled: true

필요한 경우 Envoy Proxy에서 사용할 지역 정보를 정의합니다. 이를 위해 Istio에서는 ServiceEntry를 사용할 수 있습니다. 예를 들어, 다음과 같이 ServiceEntry를 정의할 수 있습니다:

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: us-east
spec:
  hosts:
  - us-east.example.com
  ports:
  - number: 80
    name: http
    protocol: HTTP
  location: MESH_INTERNAL
  resolution: DNS
  endpoints:
  - address: 10.1.2.3

Istio를 사용하여 EKS 클러스터에서 AZ 간 데이터 전송 비용 해결

토폴로지 인식 라우팅이 기본적으로 지원되므로 Istio를 사용하여 동일한 가용 영역 내에서 포드 또는 서비스로 트래픽을 라우팅할 수 있습니다.

cat <<EOF>> destinationrule.yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: zip-lookup-service-local
  # 적용을 위한 namespace
  namespace: octank-travel-ns
spec:
  host: zip-lookup-service-local
  trafficPolicy:
    outlierDetection:
      consecutiveErrors: 7 
      interval: 30s
      baseEjectionTime: 30s
EOF

skcc-dev-mbc-cms-aurora : 1 인스턴스 - db.t3.medium(2 vCPUs 4GB, Storage불명)
skcc-uat-vitality-cms-aurora : 2 인스턴스 - db.t3.medium(2 vCPUs 4GB, Storage불명)
skcc-prd-vitality-cms-aurora : 2 인스턴스 - db.r5.xlarge(2vCPU, 32GB, Storage불명)

DB에서 다음과 같이 암호화/복호화 하고 있습니다.
AES-128 비트 인코딩/디코딩 이용하는거 같네요.

복호화 AES_DECRYPT(unhex(암호화된값),‘암호화 키값’)
암호화 hex(AES_ENCRYPT(암호화할값,‘암호화 키값’)

CMS DEV/UAT RDS: db.t3.medium –> 2vCPU, 4GB, Storage불명, AWS Aurora MySQL(5.7.mysql_aurora.2.07.7)
CMS PRD RDS: db.r5.xlarge –> 2vCPU, 32GB, Storage불명, AWS Aurora MySQL(5.7.mysql_aurora.2.07.7)
암호화: AES-256

Share