Kubernetes에서 APISIX 배포를 위한 3가지 팁 (2부)
May 7, 2024
클라우드 네이티브 컴퓨팅 시대가 도래하면서 Kubernetes는 컨테이너 오케스트레이션 플랫폼으로 널리 채택되었으며, Apache APISIX는 고성능 클라우드 네이티브 동적 API 게이트웨이로 부상했습니다. Kubernetes에서 Apache APISIX를 배포하는 것은 점점 더 일반화되고 있습니다. 그러나 Kubernetes에서 Apache APISIX를 배포하는 과정이 비교적 간단함에도 불구하고, 여전히 고려해야 할 몇 가지 중요한 문제가 있습니다. 이 시리즈의 글에서는 다음과 같은 주제를 깊이 있게 다룰 예정입니다:
- 배포 방법에 대한 고려 사항
- 헬스 체크, 로깅 및 모니터링
- 커스텀 플러그인 및 설정 처리
이전 글에서는 첫 번째 주제를 다루었습니다. 이번 글에서는 두 번째 주제인 헬스 체크, 로깅 및 모니터링에 대한 고려 사항에 초점을 맞출 것입니다.
헬스 체크
Kubernetes에서 APISIX를 배포할 때, 헬스 체크는 특히 중요합니다. 이는 Kubernetes에서 애플리케이션의 기본 요구 사항을 나타내기 때문입니다. Kubernetes에서는 Liveness 및 Readiness Probe를 구성하여 APISIX 인스턴스의 건강 상태와 가용성을 보장할 수 있습니다.
-
Liveness Probe는 애플리케이션이 실행 중인지 여부를 판단하는 데 사용됩니다. 애플리케이션이 비정상 상태로 판단되면 Kubernetes는 해당 인스턴스를 재시작합니다.
-
Readiness Probe는 애플리케이션이 트래픽을 받을 준비가 되었는지 확인하는 데 사용됩니다. 애플리케이션이 아직 준비되지 않았다면 트래픽을 받지 않습니다. 이는 완전히 시작되지 않았거나 손상된 인스턴스로 트래픽이 전송되는 것을 방지하는 데 도움이 됩니다.
Liveness 및 Readiness Probe를 적절히 구성하면 Kubernetes는 비정상적인 Pod 인스턴스를 자동으로 관리할 수 있습니다. 이는 인스턴스에 문제가 발생했을 때 Kubernetes가 자동으로 재시작하거나 비정상 인스턴스로의 트래픽 전송을 중지함으로써 시스템의 가용성과 안정성을 높일 수 있음을 의미합니다.
YAML 구성 예시:
apiVersion: v1
kind: Deployment
metadata:
name: my-apisix-pod
spec:
containers:
- name: my-apisix-container
image: my-apisix-image
livenessProbe:
httpGet:
path: /healthz
port: 9080
initialDelaySeconds: 15
periodSeconds: 10
readinessProbe:
httpGet:
path: /readyz
port: 9080
initialDelaySeconds: 10
periodSeconds: 5
이 예시는 컨테이너의 Liveness 및 Readiness Probe를 정의합니다. Liveness Probe는 10초마다 /healthz
경로로 HTTP GET 요청을 보내 컨테이너의 건강 상태를 확인합니다. 컨테이너가 응답하지 않거나 200
이 아닌 상태 코드를 반환하면 Kubernetes는 컨테이너가 비정상 상태라고 판단하고 재시작을 시도합니다. Readiness Probe는 비슷하지만 컨테이너가 트래픽을 받을 준비가 되었는지 확인하는 데 사용됩니다.
모니터링
APISIX를 런타임에 모니터링하는 방법은 다양하며, Prometheus와의 통합이 권장되는 접근 방식입니다. 실제로 Prometheus는 현재까지 가장 널리 사용되는 모니터링 컴포넌트입니다.
Prometheus와의 통합은 APISIX 및 APISIX가 프록시하는 서비스의 메트릭을 수집하고 모니터링하는 데 도움이 됩니다. 이러한 메트릭에는 요청률, 오류율, 지연 시간 및 기타 중요한 성능 지표가 포함될 수 있습니다. 이러한 메트릭을 모니터링함으로써 문제를 신속히 식별하고 성능 튜닝 및 문제 해결을 수행할 수 있습니다. 메트릭 및 경고 규칙을 적절히 구성하여 문제가 발생했을 때 신속히 조치를 취할 수 있도록 해야 합니다.
APISIX에서 Prometheus 플러그인을 활성화하는 것은 간단합니다. 먼저 config.yaml
에서 export_uri
를 설정합니다.
plugin_attr:
prometheus:
export_uri: /apisix/metrics
그런 다음 Prometheus에 의해 통계 분석이 필요한 API 또는 서비스에서 플러그인을 활성화합니다.
curl http://127.0.0.1:9180/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
"uri": "/hello",
"plugins": {
"prometheus":{}
},
"upstream": {
...
}
}'
마지막으로, Prometheus 서버는 export_uri
에서 주기적으로 구성을 가져올 수 있습니다.
scrape_configs:
- job_name: "apisix"
scrape_interval: 15s
metrics_path: "/apisix/prometheus/metrics"
static_configs:
- targets: ["127.0.0.1:9091"]
실제 사용에서는 Prometheus도 Thanos와 같은 오픈소스 솔루션을 사용하여 고가용성 방식으로 배포해야 합니다. APISIX와의 통합은 Thanos 사이드카 모드를 사용하여 달성할 수 있습니다.
로깅
APISIX에서 중요한 로그는 크게 두 가지 유형으로 분류됩니다: 트래픽 로그와 감사 로그.
-
트래픽 로그는 APISIX가 리버스 프록시 역할을 할 때 각 요청에 대한 로깅을 의미합니다. 이러한 로그는 요청 트래픽과 반환된 정보, 그리고 APISIX의 내부 운영 로그를 포함하며, 추적 및 문제 해결에 중요합니다. 일반적으로 적절한 로그 레벨과 형식을 설정하여 기록합니다. 실제 시나리오에서는 ELK(Elasticsearch, Logstash, Kibana), Fluentd 또는 Splunk와 같은 중앙 집중식 로깅 시스템에 로그를 출력하는 것을 고려해야 합니다. APISIX는 로그 플러그인을 제공하여 선택할 수 있습니다.
-
감사 로그는 주로 APISIX 구성을 관리할 때 생성되는 로그를 의미합니다. 이는 규정 준수 요구 사항을 충족하는 데 도움이 될 뿐만 아니라 보안 분석에도 사용됩니다. 감사 로그를 분석함으로써 잠재적인 보안 위험과 부적절한 구성 또는 관리 행위를 식별하고, 이에 대응하여 시스템 보안을 강화할 수 있습니다.
오픈소스 APISIX는 Admin API를 제공하여 쉽게 구성을 배포할 수 있지만, 감사 로그와 관련된 구성은 제공하지 않습니다. 일반적으로 사용자는 이러한 로그를 직접 기록하거나 APISIX 엔터프라이즈 버전을 사용해야 합니다.
Kubernetes와 다른 환경 간의 로깅 구성에는 큰 차이가 없습니다. APISIX에서 업스트림 및 관련 정보를 구성할 때 Kubernetes 서비스 디스커버리를 일반적으로 사용한다는 점을 주목할 필요가 있습니다. 이후 문제 해결을 쉽게 하기 위해 로그에 서비스 이름을 기록하는 것이 좋습니다.
결론
헬스 체크 메커니즘을 구성하여 APISIX의 비정상 인스턴스를 감지하면 Kubernetes가 신속히 조치를 취하여 트래픽을 마이그레이션하고 복구를 용이하게 할 수 있습니다. 이를 통해 API 서비스의 연속성과 안정성을 보장할 수 있습니다. APISIX는 또한 Prometheus와 같은 고급 모니터링 도구와의 통합을 지원하여 요청률, 오류율, 지연 시간과 같은 주요 메트릭을 포함한 API 성능 및 안정성을 모니터링할 수 있습니다. 이러한 모니터링 기능을 통해 조직은 잠재적인 문제를 신속히 식별하고, 적시에 성능 튜닝 및 최적화를 수행하여 API 서비스의 효율적인 운영을 보장할 수 있습니다.