기술 지원
문서
로그인
문의하기
코드로서의 인프라: 양날의 검
조아오 코레이아
2023년 6월 27일 - 기술 에반젤리스트
끊임없이 진화하는 기술 환경에서 복잡한 환경을 처리하는 것은 결코 쉬운 일이 아닙니다. 운영 팀의 규모가 커지고 비용이 많이 드는 것부터 하드웨어 및 소프트웨어 표준화를 더욱 엄격하게 적용하는 것까지, 많은 전략이 시험대에 올랐습니다. 자동화와 요즘 유행하는 유행어들은 모두 한 때 각광을 받은 적이 있습니다.
Atlassian은 이미 오래전부터 '코드형 인프라(IaC)'라는 패러다임을 수용하고 있습니다. 이 접근 방식은 확장성이 뛰어나고, 리소스가 적게 필요하며, 소스 제어 및 변경 추적과 같은 다른 도구 및 프로세스와 원활하게 통합되며, 오늘날 디지털 세계에서 끊임없이 증가하는 요구 사항을 관리하는 데 더 효율적인 방법입니다.
그러나 다른 모든 것과 마찬가지로 IaC에도 결함이 없는 것은 아닙니다. 수십 년 동안 인프라 측면을 관리한 경험이 있지만, IaC의 '코드' 부분에서 문제가 발생하는 경우가 많습니다. 버그, 패치, 익스플로잇, 버그 바운티 및 기타 관련 활동의 수를 보면 코딩 능력을 개선할 여지가 있다는 것을 알 수 있습니다.
일화적으로, 서로 다른 소프트웨어 패키지를 성능이나 안정성이 아닌 다른 소프트웨어 패키지와 비교했을 때 다른 패키지나 버전과 마찬가지로 버그가 많기 때문일 수 있습니다.인프라를 코드로 취급하면 필연적으로 인프라 자체에 동일한 버그와 문제가 발생할 수 있습니다. 최근 Azure에서 발생한 사건이 대표적인 사례입니다.
Azure 중단: IaC 사례 연구
며칠 전, Azure에서 발생한 사고로 인해 브라질 남부의 고객에게 영향을 미쳤습니다. 주요 클라우드 공급자인 Azure는 "모든 것이 코드"라는 모토를 따르며 서비스, 서버, 데이터베이스, 엔드포인트, 백업 등의 구성을 코드로 처리할 수 있도록 합니다. 이 철학은 시스템 관리자가 모든 것을 코드로 처리하여 모든 작업을 자동화할 수 있는 고객 대면 클라우드뿐만 아니라 Azure의 관리 측면으로 확장됩니다.
며칠 전 Azure에서 관리 구성 요소의 변경 사항을 테스트하고 있었습니다. 목표는 일부 이전 구성 요소를 최신 구성 요소로 교체하는 것이었는데, 여기에는 일부 NuGet 패키지를 제거하고 새 패키지를 설치하는 작업이 포함되었습니다. NuGet 패키지를 변경하는 과정에서 패키지를 참조하는 코드도 약간 변경해야 했는데, 패키지 이름이 달라지고 일부 호출 규칙이 변경되었습니다. 드롭인 방식으로 대체한 것은 아니었습니다.
변경 사항은 스크립트 작성, 커밋, 검토, 테스트를 거친 다음 가장 높은 권한을 가진 모드의 이름과 유사한 Azure-land의 "Ring 0"이라는 테스트 환경에 배포되었습니다. 링 0에서 모든 것이 순조롭게 진행되면 고객이 볼 수 있는 프로덕션 환경인 링 1로 변경 사항을 롤아웃했습니다.
그러나 링 0은 많은 실험실 또는 테스트 환경과 마찬가지로 동일한 부하, 사용자 기반 또는 복잡한 시스템 상호 작용이 없는 프로덕션 환경의 축소된 버전입니다.
흥미롭게도 Azure 시스템 관리자가 프로덕션 환경에서 수행하는 비교적 일상적인 작업 중 하나는 실제 워크로드나 고객에 영향을 주지 않고 디버깅하기 위해 실행 중인 데이터베이스의 스냅샷을 만드는 것입니다. 실제 프로덕션 데이터베이스와 문제가 없는 실험실 환경에서는 스냅샷을 만들 필요가 없으므로 Ring 0에는 스냅샷이 없었습니다.
NuGet 패키지의 변경 사항 중 하나는 스냅샷을 처리하는 함수가 변경된 것입니다.
내부적으로 Azure는 백그라운드 작업을 실행하여 이전 스냅샷을 주기적으로 삭제합니다. 링 0에는 스냅샷이 없었기 때문에 테스트 단계에서는 스냅샷 삭제를 시도하지 않았습니다. 그러나 스냅샷이 존재했던 프로덕션 환경에서는 NuGet 패키지 변경과 함께 백그라운드 작업이 실행되었고, 한때는 데이터베이스 스냅샷 데이터베이스 제거 호출로 바뀌었습니다. 서버.
느리게 움직이는 자동차가 충돌하는 것처럼, 작업이 실행되면 충분히 오래된 스냅샷이 있는 모든 데이터베이스 서버가 삭제되고 서비스가 연이어 응답하지 않게 됩니다.
Azure 중단의 여파
서버 삭제는 서로 밀접하게 관련된 일련의 이벤트를 트리거했습니다:
- Azure에서는 고객이 직접 삭제된 서버를 복원할 수 없습니다. 이 작업은 Azure의 지원 팀에서 수행해야 합니다.
- 영향을 받은 모든 서버가 동일한 유형의 백업을 가지고 있는 것은 아니었기 때문에 복원 속도에 차이가 발생했습니다. 일부는 동일한 지역(읽기: 데이터 센터)에 저장된 반면, 다른 일부는 지리적으로 중복되어 다른 Azure 지역에 저장되어 있었습니다. 데이터를 복원하기 전에 전송해야 했습니다. 이로 인해 복구 시간이 늘어났습니다.
- 삭제된 데이터베이스 서버에 의존하는 일부 웹 서버가 시작 시 테스트를 실행하여 사용 가능하고 연결 가능한 데이터베이스를 확인하는 것으로 밝혀졌습니다. 이러한 요청은 모든 데이터베이스 서버를 대상으로 이루어졌으며 데이터베이스 서버 복구 프로세스를 방해하는 의도하지 않은 부작용이 발생했습니다. 또한 테스트가 실패하면 웹 서버가 즉시 재시작을 트리거했습니다. 이런 일이 발생했습니다. 그리고 이런 일이 또 발생했습니다. 그리고 또다시 이러한 데이터베이스를 장기간 사용할 수 없게 되었습니다.
- 예방 조치로 테스트가 실패할 때 백오프라는 기술이 사용됩니다. 백오프는 기본적으로 테스트가 시도되었다가 실패하면 다음 재시도까지의 기간이 계속 늘어나는 것을 의미합니다. 이 증가는 선형적이거나 기하급수적일 수 있으며, 이 아이디어는 상대방이 이러한 테스트 요청을 처리하지 않고도 어떤 상황에서든 복구할 수 있도록 충분한 시간을 주는 것입니다. 이 특정 사례의 경우, 일반적으로 몇 초면 완료되는 재시작이 1시간 이상 걸리는 의도치 않은 결과를 초래했습니다.
- 요청이 폭주하는 인프라로 인해 백업 복원이 느려졌습니다.
- 몇 대의 서버가 다시 온라인 상태가 되자마자 고객 트래픽이 폭주하기 시작했습니다.
모든 서버가 다시 온라인 상태가 되려면 모든 서버가 복구될 때까지 모든 트래픽을 중단해야 했습니다. 이 트래픽 피크로 인해 (영향을 받은 Azure 테넌트 고객의 경우) 중단 시간이 다른 경우보다 길어졌습니다.
결과는? 약 10시간의 다운타임, 비즈니스 중단, 수많은 고객 불만이 발생했습니다.
그리고 이 모든 것은 코드 패키지 몇 개를 업데이트하는 것에서 시작되었습니다. 해킹이 아닙니다, 화재나나 다른 위험이 아닙니다.
테이크아웃 및 교훈
프로덕션 환경을 최대한 가깝게 모방할 수 있는 강력한 테스트 환경이 필수적입니다. 정확한 복제본은 달성하기 어렵고, 쉽게 동기화되지 않으며, 유지 관리가 어렵습니다. 그러나 너무 단순한 테스트 환경은 프로덕션 환경이 직면하는 필수 과제를 해결하지 못하기 때문에 본질적으로 쓸모가 없습니다.
효과적인 백업 및 복원 전략은 매우 중요합니다. 백업을 사용할 수 있어야 할 뿐만 아니라 실제 복원 시나리오에서 시험해 보아야 합니다.
인적 오류는 코드 개발에서 끊임없이 발생하는 문제입니다. 매우 복잡한 시스템에서 중요한 상호 작용과 잠재적인 버그를 간과할 수 있는 가능성을 인정해야 합니다. 사실 시스템이 그렇게 복잡하지 않아도 인간이 그 안의 모든 복잡성과 상호작용을 파악할 수 있는 능력이 부족할 수 있습니다. 이러한 상황에서 코딩을 하면 필연적으로 문제가 발생합니다.
클라우드는 혁신적이지만 실패의 위험에서 자유롭지 않습니다. 사람의 실수, 소프트웨어 결함, 하드웨어 결함이 발생할 수 있고 실제로도 발생합니다. 반복적으로 그리고 예기치 않게. 그리고 만약 머피가 결정권을 가지고 있다면최악의 순간에도 발생할 수 있습니다.
다행히도 이 사고는 비교적 짧은 시간 내에 데이터 손실 없이 삭제된 리소스를 복원하는 데 성공한 Azure 지원 및 운영 팀의 끈기를 보여 주었습니다. 특히 코드로 된 대규모 인프라를 관리하는 것은 어렵지만, 서비스의 진정한 척도는 실수 후 얼마나 신속하게 문제에 대응하고 수정하는지에 달려 있다는 점을 강조합니다.
결론적으로, 가능한 한 자동화하여 테스트 환경이 프로덕션 환경과 최대한 가깝게 반영되도록 하는 것이 현명합니다. 이와 같은 인시던트는 장애로 이어지기 전에 환경의 잠재적 취약성을 고려해야 한다는 사실을 일깨워주는 귀중한 알림 역할을 합니다.
사소한 작업부터 자동화하는 것도 중요합니다, 자동 패치 배포 - 자동 패치 배포와 같이 사소한 작업을 먼저 자동화하여 더 높은 수준의 주의가 필요한 복잡한 작업에 집중할 수 있도록 합니다. 이렇게 하면 클라우드가 확장할 수 없는 유일한 리소스(두뇌 능력)를 더 중요한 작업을 위해 확보할 수 있습니다.
