카오스 엔지니어링: 고의적인 파괴의 기술. 2 부

메모. 번역: 이 기사는 IT 시스템 장애의 결과를 완화하기 위한 실험의 중요성을 간단하고 명확하게 설명하기 위해 시작한 AWS 기술 전도사 Adrian Hornsby의 훌륭한 기사 시리즈에 이어집니다.

“계획을 준비하지 못하면 실패할 계획을 세웁니다.” - 벤자민 프랭클린

В 첫 번째 부분 이 기사 시리즈에서는 카오스 엔지니어링의 개념을 소개하고 이것이 생산 실패로 이어지기 전에 시스템의 결함을 찾아 수정하는 데 어떻게 도움이 되는지 설명했습니다. 또한 카오스 엔지니어링이 조직 내에서 긍정적인 문화적 변화를 촉진하는 방법에 대해서도 논의했습니다.

XNUMX부 말미에는 “시스템에 오류를 도입하는 도구와 방법”에 대해 이야기하겠다고 약속했습니다. 아아, 내 머리에는 이와 관련하여 자체 계획이 있었고 이 기사에서는 카오스 엔지니어링에 참여하려는 사람들 사이에서 발생하는 가장 인기 있는 질문에 답하려고 노력할 것입니다. 무엇을 먼저 깰까요?

좋은 질문입니다! 하지만 그는 이 판다에게 별로 신경을 쓰지 않는 것 같은데...

혼돈의 팬더를 건드리지 마세요!

짧은 대답: 요청 경로를 따라 중요한 서비스를 대상으로 합니다.

더 길지만 더 명확한 답변: 혼돈 실험을 어디서 시작해야 하는지 이해하려면 다음 세 가지 영역에 주의를 기울이십시오.

1. 봐요 충돌 기록 패턴을 식별하고;
2. 결정하다 중요한 종속성;
3. 소위를 사용하십시오 과신 효과.

웃긴데 이 부분은 그냥 쉽게 부를 수도 있겠네요 "자기 발견과 깨달음을 향한 여정". 여기서 우리는 멋진 악기를 가지고 "연주"를 시작할 것입니다.

1. 답은 과거에 있다

기억하신다면, 첫 번째 부분에서 오류 수정(COE) 개념을 소개했습니다. 이는 기술, 프로세스 또는 조직의 실수와 같은 실수를 분석하여 원인을 이해하고 예방하는 방법입니다. 앞으로 재발. 일반적으로 여기서부터 시작해야 합니다.

“현재를 이해하려면 과거를 알아야 합니다.” — 칼 세이건

실패 기록을 살펴보고 COE 또는 사후 분석에서 태그를 지정하고 분류하세요. 종종 문제를 일으키는 일반적인 패턴을 식별하고 각 COE에 대해 다음 질문을 자문해 보십시오.

"이것을 예측하고 결함 주입으로 예방할 수 있었을까요?"

나는 경력 초기에 한 번의 실패를 기억합니다. 몇 가지 간단한 혼돈 실험을 수행했다면 쉽게 예방할 수 있었을 것입니다.

정상적인 조건에서 백엔드 인스턴스는 상태 확인에 응답합니다. 로드 밸런서(ELB)). ELB는 이러한 검사를 사용하여 요청을 정상 인스턴스로 리디렉션합니다. 인스턴스가 "비정상"인 것으로 확인되면 ELB는 해당 인스턴스에 대한 요청 전송을 중단합니다. 어느 날 성공적인 마케팅 캠페인 이후 트래픽 양이 증가하고 백엔드가 평소보다 상태 확인에 더 느리게 응답하기 시작했습니다. 이번 건강검진은 이렇게 했다고 해야되나 깊은즉, 종속성 상태가 확인되었습니다.

그러나 한동안은 모든 것이 괜찮았습니다.

그런 다음 이미 스트레스가 많은 상황에서 인스턴스 중 하나가 중요하지 않은 일반 ETL cron 작업을 실행하기 시작했습니다. 높은 트래픽과 cronjob의 조합으로 CPU 사용률이 거의 100%에 이르렀습니다. CPU 과부하로 인해 상태 확인에 대한 응답 속도가 더욱 느려져서 ELB는 인스턴스에 성능 문제가 있다고 판단했습니다. 예상한 대로 밸런서가 트래픽 분산을 중단했고, 이로 인해 그룹의 나머지 인스턴스에 대한 로드가 증가했습니다.

갑자기 다른 모든 인스턴스도 상태 확인에 실패하기 시작했습니다.

새 인스턴스를 시작하려면 패키지를 다운로드하고 설치해야 했으며 ELB가 자동 확장 그룹에서 패키지를 하나씩 비활성화하는 데 걸리는 시간보다 훨씬 오래 걸렸습니다. 곧 전체 프로세스가 임계점에 도달하고 애플리케이션이 충돌한 것이 분명합니다.

그런 다음 우리는 다음 사항을 영원히 이해했습니다.

• 새 인스턴스를 생성할 때 소프트웨어를 설치하는 데 시간이 오래 걸리므로 불변 접근 방식을 선호하는 것이 좋습니다. 골든 AMI.
• 복잡한 상황에서는 상태 확인 및 ELB에 대한 응답이 우선시되어야 합니다. 마지막으로 원하는 것은 나머지 인스턴스의 수명을 복잡하게 만드는 것입니다.
• 상태 확인의 로컬 캐싱은 (몇 초 동안이라도) 많은 도움이 됩니다.
• 어려운 상황에서는 cron 작업 및 기타 중요하지 않은 프로세스를 실행하지 마십시오. 가장 중요한 작업을 위해 리소스를 절약하십시오.
• 자동 확장 시 더 작은 인스턴스를 사용하세요. 10개의 작은 표본 그룹이 4개의 큰 표본 그룹보다 낫습니다. 하나의 인스턴스가 실패하면 첫 번째 경우에는 트래픽의 10%가 9개 지점에 분산되고, 두 번째 경우에는 트래픽의 25%가 XNUMX개 지점에 분산됩니다.

따라서, 이것이 예견되었으므로 문제를 도입함으로써 예방할 수 있었습니까?

Да, 그리고 여러 가지 방법으로.

첫째, 다음과 같은 도구를 사용하여 높은 CPU 사용량을 시뮬레이션합니다. stress-ng 또는 cpuburn:

❯ stress-ng --matrix 1 -t 60s

스트레스

둘째, 인스턴스에 과부하를 가하여 wrk 및 기타 유사한 유틸리티:

❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health

실험은 상대적으로 간단하지만 실제 실패로 인한 스트레스를 겪지 않고도 생각해볼 수 있는 좋은 자료를 제공할 수 있습니다.

하지만 거기서 멈추지 마세요. 테스트 환경에서 충돌을 재현해보고 "라는 질문에 대한 답을 확인해보세요.이를 예측하고 결함을 도입하여 예방할 수 있었습니까?" 이것은 가정을 테스트하기 위한 카오스 실험 내의 미니 카오스 실험이지만 실패로 시작됩니다.

꿈이었나요, 아니면 실제로 일어났나요?

그러니 실패의 역사를 연구하고, 분석하세요. EOC, 태그를 지정하고 "히트 반경"(더 정확하게는 영향을 받는 고객 수)을 기준으로 분류한 다음 패턴을 찾습니다. 문제를 도입함으로써 이를 예측하고 예방할 수 있었는지 스스로에게 물어보십시오. 답을 확인하세요.

그런 다음 범위가 가장 큰 가장 일반적인 패턴으로 전환합니다.

2. 종속성 맵 구축

잠시 시간을 내어 지원서에 대해 생각해 보세요. 종속성에 대한 명확한 지도가 있나요? 실패할 경우 어떤 영향을 미칠지 알고 있나요?

애플리케이션 코드에 익숙하지 않거나 규모가 너무 커지면 코드의 기능과 종속성이 무엇인지 이해하기 어려울 수 있습니다. 이러한 종속성과 애플리케이션 및 사용자에 대한 가능한 영향을 이해하는 것은 카오스 엔지니어링을 시작할 위치를 아는 데 중요합니다. 시작점은 영향 반경이 가장 큰 구성 요소입니다.

종속성을 식별하고 문서화하는 것을 "종속성 맵 작성» (종속성 매핑). 이는 일반적으로 코드 프로파일링 도구를 사용하여 대규모 코드 베이스가 있는 애플리케이션에서 수행됩니다. (코드 프로파일링) 및 계측 (수단). 네트워크 트래픽을 모니터링하여 지도를 구축할 수도 있습니다.

그러나 모든 종속성이 동일한 것은 아닙니다(이로 인해 프로세스가 더욱 복잡해집니다). 일부 비판적인, 다른 - 중고등 학년 (적어도 이론적으로는 중요하지 않은 것으로 간주되는 종속성 문제로 인해 충돌이 자주 발생하기 때문에).

중요한 종속성이 없으면 서비스가 작동할 수 없습니다. 중요하지 않은 종속성 "해서는 안된다.» 추락 시 서비스에 영향을 미치기 위해. 종속성을 이해하려면 애플리케이션에서 사용하는 API를 명확하게 이해해야 합니다. 이는 보이는 것보다 훨씬 더 어려울 수 있습니다. 적어도 대규모 애플리케이션의 경우에는 그렇습니다.

모든 API를 살펴보는 것부터 시작하세요. 가장 하이라이트 중요하고 중요한. 가져가다 зависимости 코드 저장소에서 확인해 보세요. 연결 로그, 다음 보기 문서 (물론 존재하는 경우 - 그렇지 않은 경우에는 여전히о더 큰 문제). 도구를 사용하여 프로파일링 및 추적, 외부 통화를 필터링합니다.

다음과 같은 프로그램을 사용할 수 있습니다. netstat - 시스템의 모든 네트워크 연결(활성 소켓) 목록을 표시하는 명령줄 유틸리티입니다. 예를 들어 현재 연결을 모두 나열하려면 다음을 입력합니다.

❯ netstat -a | more 

AWS에서는 다음을 사용할 수 있습니다. 흐름 로그 (흐름 로그) VPC는 ​​VPC의 네트워크 인터페이스로 들어오고 나가는 IP 트래픽에 대한 정보를 수집할 수 있는 방법입니다. 이러한 로그는 다른 작업에도 도움이 될 수 있습니다. 예를 들어 특정 트래픽이 인스턴스에 도달하지 못하는 이유에 대한 질문에 대한 답을 찾는 것입니다.

당신은 또한 사용할 수 있습니다 AWS 엑스레이. X-Ray를 사용하면 상세하고 "궁극적인" 결과를 얻을 수 있습니다. (끝으로 종료) 애플리케이션을 통해 이동하는 요청에 대한 개요를 제공하고 애플리케이션의 기본 구성 요소에 대한 맵을 구축합니다. 종속성을 식별해야 하는 경우 매우 편리합니다.

AWS X-Ray 콘솔

네트워크 종속성 맵은 부분적인 솔루션일 뿐입니다. 예, 어떤 애플리케이션과 어떤 애플리케이션이 통신하는지 표시하지만 다른 종속성이 있습니다.

많은 애플리케이션이 DNS를 사용하여 종속 항목에 연결하는 반면, 다른 애플리케이션은 서비스 검색을 사용하거나 구성 파일에 하드 코딩된 IP 주소(예: /etc/hosts).

예를 들어 다음을 만들 수 있습니다. DNS 블랙홀 를 통해 iptables 무엇이 깨지는지 살펴보세요. 이렇게 하려면 다음 명령을 입력하십시오.

❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"

DNS 블랙홀

경우 /etc/hosts 또는 기타 구성 파일을 사용하면 전혀 알지 못하는 IP 주소를 찾을 수 있습니다(예, 불행히도 이런 일도 발생합니다). 다시 구조에 올 수 있습니다 iptables. 당신이 발견했다고 가정 해 봅시다 8.8.8.8 그리고 이것이 Google의 공개 DNS 서버 주소인지도 모릅니다. 사용하여 iptables 다음 명령을 사용하여 이 주소로 들어오고 나가는 트래픽을 차단할 수 있습니다.

❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"

접근 폐쇄

첫 번째 규칙은 Google의 공개 DNS에서 모든 패킷을 삭제합니다. ping 작동하지만 패킷이 반환되지 않습니다. 두 번째 규칙은 시스템에서 Google의 공개 DNS로 향하는 모든 패킷을 삭제합니다. ping 우리는 얻는다. 조작은 허용되지.

참고: 이 특별한 경우에는 다음을 사용하는 것이 좋습니다. whois 8.8.8.8, 그러나 이것은 단지 예일 뿐입니다.

TCP와 UDP를 사용하는 모든 것이 실제로 IP에 의존하기 때문에 우리는 토끼 구멍을 더 깊이 파고들 수 있습니다. 대부분의 경우 IP는 ARP에 연결됩니다. 방화벽을 잊지 마세요...

빨간약을 먹으면 이상한 나라에 남게 되고, 토끼굴이 얼마나 깊은지 보여주겠다."

좀 더 급진적인 접근 방식은 분리 자동차를 하나씩 하나씩 살펴보고 무엇이 고장 났는지 살펴보세요... "혼돈의 원숭이"가 되어보세요. 물론 많은 프로덕션 시스템은 이러한 무차별 대입 공격을 위해 설계되지 않았지만 적어도 테스트 환경에서는 시도해 볼 수 있습니다.

종속성 맵을 구축하는 것은 매우 오랜 시간이 걸리는 작업인 경우가 많습니다. 저는 최근 수백 개의 마이크로서비스와 명령에 대한 종속성 맵을 반자동으로 생성하는 도구를 개발하는 데 거의 2년을 보낸 클라이언트와 이야기를 나눴습니다.

그러나 그 결과는 매우 흥미롭고 유용합니다. 시스템, 종속성 및 운영에 대해 많은 것을 배우게 됩니다. 다시 한 번 인내심을 가지십시오. 가장 중요한 것은 여행 자체입니다.

3. 과신을 조심하라

“무엇을 꿈꾸는 자는 그것을 믿느니라.” — 데모스테네스

들어본 적 있나요? 과신 효과?

Wikipedia에 따르면, 과신 효과는 "자신의 행동과 결정에 대한 개인의 확신이 그러한 판단의 객관적인 정확성보다 훨씬 더 큰 인지적 편견"입니다. 특히 자신감 수준이 상대적으로 높을 때 더욱 그렇습니다.

본능과 경험을 바탕으로..

내 경험에 따르면 이러한 왜곡은 카오스 엔지니어링을 어디서 시작해야 하는지에 대한 훌륭한 힌트입니다.

과신한 운영자를 조심하세요.

찰리: "이건 XNUMX년 동안 한 번도 무너지지 않았어. 다 괜찮아!"
충돌: "잠깐만요... 금방 갈게요!"

과신으로 인한 편견은 그것에 영향을 미치는 다양한 요인으로 인해 교활하고 심지어 위험한 것입니다. 팀원들이 기술에 심혈을 기울였거나 기술을 '수정'하는 데 많은 시간을 소비한 경우에는 특히 그렇습니다.

합산

카오스 엔지니어링의 출발점을 찾는 것은 항상 예상보다 더 많은 결과를 가져오며, 너무 빨리 일을 깨기 시작하는 팀은 (카오스-)의 더 글로벌하고 흥미로운 본질을 망각합니다.공학 - 창의적인 응용 과학적 방법 и 경험적 증거 (소프트웨어) 시스템의 설계, 개발, 운영, 유지 관리 및 개선을 위해.

이것으로 두 번째 부분을 마칩니다. 리뷰를 작성하거나, 의견을 공유하거나, 박수를 보내주세요. 중급. 다음 부분에서 나는 정말로 시스템에 오류를 도입하기 위한 도구와 방법을 고려할 것입니다. 까지!

번역가의 추신

블로그에서도 읽어보세요.

• «카오스 엔지니어링: 고의적인 파괴의 기술. 1 부";
• «Kubernetes에서 고가용성을 제공하는 방법";
• «모니터링 및 Kubernetes(리뷰 및 동영상 보고)";
• «Kubernetes에서 kube-proxy 및 노드 가용성 실험".

출처 : habr.com