“Kubernetes는 대기 시간을 10배 늘렸습니다”: 이에 대한 책임은 누구에게 있습니까?

메모. 번역: 유럽 회사 Adevinta에서 수석 소프트웨어 엔지니어 직책을 맡고 있는 Galo Navarro가 작성한 이 기사는 인프라 운영 분야에 대한 흥미롭고 유익한 "조사"입니다. 저자가 맨 처음에 설명하는 이유로 원래 제목은 번역에서 약간 확장되었습니다.

저자의 메모: 이 게시물인 것 같습니다 끌린 예상보다 훨씬 더 많은 관심을 받고 있습니다. 아직도 기사 제목이 오해를 불러일으키고 일부 독자들이 안타까워하고 있다는 화난 댓글을 많이 받습니다. 나는 무슨 일이 일어나고 있는지 이유를 이해하므로 전체 음모를 망칠 위험에도 불구하고이 기사의 내용을 즉시 알려 드리고 싶습니다. 팀이 Kubernetes로 마이그레이션하면서 제가 본 흥미로운 점은 문제가 발생할 때마다(예: 마이그레이션 후 대기 시간 증가) 가장 먼저 비난받는 것은 Kubernetes이지만 오케스트레이터는 실제로는 그렇지 않다는 것입니다. 탓하다. 이 기사에서는 그러한 사례 중 하나에 대해 설명합니다. 그 이름은 우리 개발자 중 한 사람의 감탄사를 반복합니다(나중에 Kubernetes가 그것과 아무 관련이 없다는 것을 알게 될 것입니다). 여기에서는 Kubernetes에 대한 놀라운 사실을 발견할 수 없지만 복잡한 시스템에 대한 몇 가지 좋은 교훈을 기대할 수 있습니다.

몇 주 전에 우리 팀은 단일 마이크로서비스를 CI/CD, Kubernetes 기반 런타임, 메트릭 및 기타 기능이 포함된 핵심 플랫폼으로 마이그레이션하고 있었습니다. 이러한 이전은 시험적인 성격을 띠었습니다. 우리는 이를 기반으로 향후 몇 달 내에 약 150개의 서비스를 추가로 이전할 계획이었습니다. 이들 모두는 스페인 최대 규모의 온라인 플랫폼(Infojobs, Fotocasa 등)의 운영을 담당하고 있습니다.

애플리케이션을 Kubernetes에 배포하고 일부 트래픽을 애플리케이션으로 리디렉션한 후 놀라운 일이 우리를 기다리고 있었습니다. 지연 (숨어 있음) Kubernetes의 요청은 EC10보다 2배 더 높았습니다. 일반적으로 이 문제에 대한 해결책을 찾거나 마이크로서비스(및 전체 프로젝트)의 마이그레이션을 포기해야 했습니다.

EC2보다 Kubernetes에서 지연 시간이 훨씬 더 긴 이유는 무엇입니까?

병목 현상을 찾기 위해 전체 요청 경로를 따라 지표를 수집했습니다. 우리의 아키텍처는 간단합니다. API 게이트웨이(Zuul)는 요청을 EC2 또는 Kubernetes의 마이크로서비스 인스턴스로 프록시합니다. Kubernetes에서는 NGINX Ingress Controller를 사용하고 백엔드는 다음과 같은 일반 객체입니다. 전개 Spring 플랫폼에서 JVM 애플리케이션을 사용합니다.

                                  EC2
                            +---------------+
                            |  +---------+  |
                            |  |         |  |
                       +-------> BACKEND |  |
                       |    |  |         |  |
                       |    |  +---------+  |                   
                       |    +---------------+
             +------+  |
Public       |      |  |
      -------> ZUUL +--+
traffic      |      |  |              Kubernetes
             +------+  |    +-----------------------------+
                       |    |  +-------+      +---------+ |
                       |    |  |       |  xx  |         | |
                       +-------> NGINX +------> BACKEND | |
                            |  |       |  xx  |         | |
                            |  +-------+      +---------+ |
                            +-----------------------------+

문제는 백엔드의 초기 지연 시간과 관련된 것 같습니다(그래프에서 문제 영역을 "xx"로 표시했습니다). EC2에서는 애플리케이션 응답에 약 20ms가 걸렸습니다. Kubernetes에서는 대기 시간이 100~200ms로 늘어났습니다.

우리는 런타임 변경과 관련된 가능성이 있는 용의자를 신속하게 기각했습니다. JVM 버전은 동일하게 유지됩니다. 컨테이너화 문제도 이와 아무 관련이 없습니다. 애플리케이션은 이미 EC2의 컨테이너에서 성공적으로 실행되고 있었습니다. 로드 중이신가요? 그러나 초당 1개의 요청에서도 높은 지연 시간이 관찰되었습니다. 가비지 수집을 위한 일시 중지도 무시될 수 있습니다.

Kubernetes 관리자 중 한 명은 과거에 DNS 쿼리로 인해 비슷한 문제가 발생했기 때문에 애플리케이션에 외부 종속성이 있는지 궁금해했습니다.

가설 1: DNS 이름 확인

각 요청에 대해 우리 애플리케이션은 다음과 같은 도메인에서 AWS Elasticsearch 인스턴스에 1~3회 액세스합니다. elastic.spain.adevinta.com. 컨테이너 내부 껍질이 있다, 도메인 검색이 실제로 오랜 시간이 걸리는지 확인할 수 있습니다.

컨테이너의 DNS 쿼리:

[root@be-851c76f696-alf8z /]# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 22 msec
;; Query time: 22 msec
;; Query time: 29 msec
;; Query time: 21 msec
;; Query time: 28 msec
;; Query time: 43 msec
;; Query time: 39 msec

애플리케이션이 실행 중인 EC2 인스턴스 중 하나의 유사한 요청:

bash-4.4# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 77 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec

조회에 약 30ms가 소요된 점을 고려하면 Elasticsearch에 액세스할 때 DNS 확인이 실제로 지연 시간 증가에 기여하고 있음이 분명해졌습니다.

그러나 이는 다음 두 가지 이유로 이상했습니다.

1. 우리는 이미 높은 지연 시간 없이 AWS 리소스와 상호 작용하는 수많은 Kubernetes 애플리케이션을 보유하고 있습니다. 이유가 무엇이든, 그것은 특히 이 사건과 관련이 있습니다.
2. 우리는 JVM이 메모리 내 DNS 캐싱을 수행한다는 것을 알고 있습니다. 이미지에서 TTL 값은 다음과 같이 기록됩니다. $JAVA_HOME/jre/lib/security/java.security 10초로 설정합니다. networkaddress.cache.ttl = 10. 즉, JVM은 모든 DNS 쿼리를 10초 동안 캐시해야 합니다.

첫 번째 가설을 확인하기 위해 잠시 DNS 호출을 중단하고 문제가 해결되었는지 확인하기로 결정했습니다. 먼저, 도메인 이름이 아닌 IP 주소를 통해 Elasticsearch와 직접 통신하도록 애플리케이션을 재구성하기로 결정했습니다. 이를 위해서는 코드 변경과 새로운 배포가 필요하므로 간단히 도메인을 IP 주소에 매핑했습니다. /etc/hosts:

34.55.5.111 elastic.spain.adevinta.com

이제 컨테이너는 거의 즉시 IP를 수신했습니다. 이로 인해 약간의 개선이 이루어졌으나 예상 대기 시간 수준에 약간 더 가까워졌습니다. DNS 확인에 오랜 시간이 걸렸지만 실제 이유는 여전히 파악되지 않았습니다.

네트워크를 통한 진단

우리는 다음을 사용하여 컨테이너의 트래픽을 분석하기로 결정했습니다. tcpdump네트워크에서 정확히 무슨 일이 일어나고 있는지 확인하려면 다음을 수행하세요.

[root@be-851c76f696-alf8z /]# tcpdump -leni any -w capture.pcap

그런 다음 여러 요청을 보내고 해당 캡처를 다운로드했습니다(kubectl cp my-service:/capture.pcap capture.pcap) 추가 분석을 위해 와이어 샤크.

DNS 쿼리에는 의심스러운 점이 하나도 없었습니다(나중에 설명할 한 가지 작은 사항을 제외하고). 그러나 우리 서비스가 각 요청을 처리하는 방식에는 특정한 이상한 점이 있었습니다. 다음은 응답이 시작되기 전에 요청이 수락되는 것을 보여주는 캡처 스크린샷입니다.

패키지 번호는 첫 번째 열에 표시됩니다. 명확성을 위해 다양한 TCP 흐름을 색상으로 구분했습니다.

패킷 328로 시작하는 녹색 스트림은 클라이언트(172.17.22.150)가 컨테이너(172.17.36.147)에 대한 TCP 연결을 설정한 방법을 보여줍니다. 초기 핸드셰이크(328-330) 후 패키지 331이 가져왔습니다. HTTP GET /v1/.. — 당사 서비스에 대한 수신 요청. 전체 프로세스에는 1ms가 걸렸습니다.

회색 스트림(패킷 339)은 우리 서비스가 Elasticsearch 인스턴스에 HTTP 요청을 보냈음을 보여줍니다(기존 연결을 사용하고 있기 때문에 TCP 핸드셰이크가 없습니다). 18ms가 걸렸습니다.

지금까지는 모든 것이 괜찮으며 시간은 대략 예상되는 지연(클라이언트에서 측정할 때 20-30ms)과 일치합니다.

그러나 파란색 섹션에는 86ms가 걸립니다. 무슨 일이 일어나고 있는 걸까요? 패킷 333을 통해 우리 서비스는 다음에게 HTTP GET 요청을 보냈습니다. /latest/meta-data/iam/security-credentials, 그리고 그 직후에 동일한 TCP 연결을 통해 또 다른 GET 요청이 /latest/meta-data/iam/security-credentials/arn:...

우리는 추적 전반에 걸쳐 모든 요청에서 이것이 반복된다는 것을 발견했습니다. 실제로 컨테이너에서는 DNS 확인이 약간 느립니다(이 현상에 대한 설명은 매우 흥미롭지만 별도의 기사를 위해 저장하겠습니다). 긴 지연의 원인은 각 요청에 대한 AWS 인스턴스 메타데이터 서비스 호출 때문인 것으로 밝혀졌습니다.

가설 2: AWS에 대한 불필요한 호출

두 끝점 모두에 속함 AWS 인스턴스 메타데이터 API. 우리 마이크로서비스는 Elasticsearch를 실행하는 동안 이 서비스를 사용합니다. 두 호출 모두 기본 인증 프로세스의 일부입니다. 첫 번째 요청에서 액세스되는 엔드포인트는 인스턴스와 연결된 IAM 역할을 발급합니다.

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
arn:aws:iam::<account_id>:role/some_role

두 번째 요청은 두 번째 엔드포인트에 이 인스턴스에 대한 임시 권한을 요청합니다.

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/arn:aws:iam::<account_id>:role/some_role`
{
    "Code" : "Success",
    "LastUpdated" : "2012-04-26T16:39:16Z",
    "Type" : "AWS-HMAC",
    "AccessKeyId" : "ASIAIOSFODNN7EXAMPLE",
    "SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "Token" : "token",
    "Expiration" : "2017-05-17T15:09:54Z"
}

클라이언트는 짧은 기간 동안 이를 사용할 수 있으며 정기적으로 새 인증서를 받아야 합니다(인증서를 사용하기 전에). Expiration). 모델은 간단합니다. AWS는 보안상의 이유로 임시 키를 자주 교체하지만 클라이언트는 새 인증서 획득과 관련된 성능 저하를 보상하기 위해 몇 분 동안 임시 키를 캐시할 수 있습니다.

AWS Java SDK는 이 프로세스를 구성하는 책임을 맡아야 하지만 어떤 이유로 이런 일이 발생하지 않습니다.

GitHub에서 문제를 검색한 후 문제를 발견했습니다. #1921. 그녀는 우리가 더 깊이 파고들어야 할 방향을 결정하는 데 도움을 주었습니다.

AWS SDK는 다음 조건 중 하나가 발생하면 인증서를 업데이트합니다.

• 만료일 (Expiration)에 빠지다 EXPIRATION_THRESHOLD, 15분으로 하드코딩되었습니다.
• 마지막 인증서 갱신 시도 이후 다음보다 더 많은 시간이 경과했습니다. REFRESH_THRESHOLD, 60분 동안 하드코딩되었습니다.

우리가 받은 인증서의 실제 만료 날짜를 확인하기 위해 컨테이너와 EC2 인스턴스 모두에서 위의 cURL 명령을 실행했습니다. 컨테이너로부터 받은 인증서의 유효 기간은 정확히 15분으로 훨씬 짧은 것으로 나타났습니다.

이제 모든 것이 명확해졌습니다. 첫 번째 요청에 대해 우리 서비스는 임시 인증서를 받았습니다. 15분 이상 유효하지 않았기 때문에 AWS SDK는 후속 요청 시 이를 업데이트하기로 결정했습니다. 그리고 이것은 모든 요청에서 발생했습니다.

인증서 유효기간이 짧아진 이유는 무엇입니까?

AWS 인스턴스 메타데이터는 Kubernetes가 아닌 EC2 인스턴스와 작동하도록 설계되었습니다. 반면에 우리는 애플리케이션 인터페이스를 변경하고 싶지 않았습니다. 이를 위해 우리는 키암 - 각 Kubernetes 노드의 에이전트를 사용하여 사용자(클러스터에 애플리케이션을 배포하는 엔지니어)가 마치 EC2 인스턴스인 것처럼 포드의 컨테이너에 IAM 역할을 할당할 수 있게 해주는 도구입니다. KIAM은 AWS 인스턴스 메타데이터 서비스에 대한 호출을 가로채서 이전에 AWS로부터 수신한 캐시에서 이를 처리합니다. 응용 프로그램의 관점에서는 아무것도 변경되지 않습니다.

KIAM은 포드에 단기 인증서를 제공합니다. 포드의 평균 수명이 EC2 인스턴스보다 짧다는 점을 고려하면 이는 의미가 있습니다. 인증서의 기본 유효 기간 같은 15분.

결과적으로 두 기본값을 서로 겹쳐 놓으면 문제가 발생합니다. 애플리케이션에 제공된 각 인증서는 15분 후에 만료됩니다. 그러나 AWS Java SDK는 만료 날짜까지 15분 미만 남은 인증서를 강제로 갱신합니다.

결과적으로 임시 인증서는 각 요청마다 강제로 갱신되어야 하며, 이로 인해 AWS API에 대한 몇 번의 호출이 수반되고 지연 시간이 크게 증가합니다. AWS Java SDK에서 우리는 발견했습니다. 기능 요청, 유사한 문제를 언급합니다.

해결책은 간단하다는 것이 밝혀졌습니다. 우리는 유효 기간이 더 긴 인증서를 요청하도록 KIAM을 재구성했습니다. 이런 일이 발생하자 AWS 메타데이터 서비스의 참여 없이 요청이 흐르기 시작했고 지연 시간은 EC2보다 훨씬 낮은 수준으로 떨어졌습니다.

조사 결과

마이그레이션 경험에 따르면 문제의 가장 일반적인 원인 중 하나는 Kubernetes나 플랫폼의 다른 요소의 버그가 아닙니다. 또한 우리가 이식하는 마이크로서비스의 근본적인 결함을 해결하지 않습니다. 단순히 서로 다른 요소를 합치기 때문에 문제가 발생하는 경우가 많습니다.

우리는 이전에 서로 상호작용한 적이 없는 복잡한 시스템을 혼합하여 더 큰 단일 시스템을 형성할 것으로 기대합니다. 아아, 요소가 많을수록 오류의 여지가 많아지고 엔트로피도 높아집니다.

우리의 경우 긴 지연 시간은 Kubernetes, KIAM, AWS Java SDK 또는 마이크로서비스의 버그나 잘못된 결정으로 인한 것이 아닙니다. 이는 KIAM과 AWS Java SDK의 두 가지 독립적인 기본 설정을 결합한 결과였습니다. 개별적으로 살펴보면 두 매개변수, 즉 AWS Java SDK의 활성 인증서 갱신 정책과 KAIM의 짧은 인증서 유효 기간이 모두 의미가 있습니다. 하지만 합치면 결과를 예측할 수 없게 됩니다. 두 개의 독립적이고 논리적인 솔루션을 결합할 때 의미가 있을 필요는 없습니다.

번역가의 추신

AWS IAM을 Kubernetes와 통합하기 위한 KIAM 유틸리티의 아키텍처에 대해 자세히 알아볼 수 있습니다. 이 기사 제작자로부터.

우리 블로그에서도 읽어보세요:

• «프로덕션에서의 Kubernetes 실패에 대한 3가지 이야기: 반친화성, 우아한 종료, 웹훅";
• «Kubernetes의 Pod 우선순위가 Grafana Labs의 가동 중지 시간을 초래한 방법";
• «쿠버네티스 운영의 재미있는 시스템 버그 6가지 [및 해당 솔루션]";
• «SRE 일상생활에 대한 6가지 실용적인 이야기".

출처 : habr.com