장애 조치: 완벽주의와... 게으름이 우리를 망치고 있습니다

여름에는 구매 활동과 웹 프로젝트 인프라의 변화 강도가 전통적으로 감소한다고 Captain Obvious는 말합니다. IT 전문가라도 가끔 휴가를 떠나는 경우가 있기 때문입니다. 그리고 CTO도요. 재임중인 분들은 더욱 힘들지만 지금은 그게 다가 아닙니다. 그렇기 때문에 여름은 기존 예약 제도에 대해 천천히 생각하고 개선 계획을 세우기에 가장 좋은시기 일 것입니다. 그리고 Yegor Andreev의 경험 관리부서, 그는 회의에서 이렇게 말했습니다. 가동일.

백업 사이트를 구축할 때 빠질 수 있는 몇 가지 함정이 있습니다. 그리고 거기에 빠지는 것은 절대 불가능합니다. 그리고 다른 많은 것들과 마찬가지로 이 모든 것에서 우리를 망치는 것은 완벽주의와... 게으름입니다. 우리는 모든 일, 모든 일, 모든 일을 완벽하게 하려고 노력하지만 완벽하게 할 필요는 없습니다! 특정한 일만 하면 되지만 올바르게 수행하고 완료하여 제대로 작동하도록 하세요.

장애 조치는 일종의 재미나 재미있는 일이 아닙니다. 이는 정확히 한 가지 작업을 수행해야 하는 작업입니다. 가동 중지 시간을 줄여 서비스와 회사의 손실을 줄이는 것입니다. 그리고 모든 예약 방법에서 다음과 같은 맥락에서 생각하는 것이 좋습니다. 돈은 어디에 있습니까?

첫 번째 함정: 크고 안정적인 시스템을 구축하고 중복성을 적용하면 사고 횟수가 줄어듭니다. 이것은 끔찍한 오해입니다. 중복을 하게 되면 사고 건수가 증가할 가능성이 높습니다. 그리고 우리가 모든 일을 올바르게 수행한다면 전체적으로 가동 중지 시간이 줄어들 것입니다. 사고는 더 많이 발생하지만 비용은 더 적게 발생합니다. 예약이란 무엇입니까? - 이것은 시스템의 합병증입니다. 모든 합병증은 나쁩니다. 더 많은 톱니바퀴, 더 많은 기어, 한마디로 더 많은 요소가 있으므로 고장 가능성이 더 높습니다. 그리고 그들은 정말로 깨질 것입니다. 그리고 그들은 더 자주 깨질 것입니다. 간단한 예: PHP와 MySQL이 포함된 웹사이트가 있다고 가정해 보겠습니다. 그리고 긴급히 예약해야합니다.

Shtosh (c) 우리는 두 번째 사이트를 가져와 동일한 시스템을 구축합니다... 복잡성이 두 배로 커집니다. 두 개의 엔터티가 있습니다. 또한 한 사이트에서 다른 사이트로 데이터를 전송하기 위한 특정 논리(즉, 데이터 복제, 정적 데이터 복사 등)를 출시합니다. 따라서 복제 논리는 일반적으로 매우 복잡하므로 시스템의 전체 복잡성은 2배가 아니라 3, 5, 10배 더 커질 수 있습니다.

두 번째 함정: 우리는 매우 크고 복잡한 시스템을 구축할 때 결국 무엇을 얻고 싶은지에 대해 환상을 품습니다. 짜잔: 우리는 가동 중지 시간 없이 작동하고 XNUMX초 만에(또는 더 나은 방법은 즉시) 전환하고 꿈을 실현하기 시작하는 매우 안정적인 시스템을 원합니다. 그러나 여기에도 미묘한 차이가 있습니다. 원하는 전환 시간이 짧을수록 시스템 로직이 더 복잡해집니다. 이 논리를 더 복잡하게 만들수록 시스템이 더 자주 고장날 것입니다. 그리고 매우 불쾌한 상황에 처할 수 있습니다. 우리는 가동 중지 시간을 줄이기 위해 최선을 다하고 있지만 실제로는 모든 것을 더 복잡하게 만들고 있으며 문제가 발생하면 가동 중지 시간이 길어질 수 있습니다. 여기서 당신은 종종 다음과 같은 생각을 하게 됩니다. 음... 예약하지 않는 것이 좋을 것 같습니다. 단독으로 작동하고 이해 가능한 가동 중지 시간이 있으면 더 좋을 것입니다.

어떻게 싸울 수 있습니까? 우리는 우리 자신에게 거짓말을 하는 것을 멈춰야 하고, 지금 여기에 우주선을 건설할 것이라고 스스로 우쭐해지는 것을 멈춰야 합니다. 하지만 프로젝트가 얼마나 오래 지속될 수 있는지 적절하게 이해해야 합니다. 그리고 이 최대 시간 동안 우리는 시스템의 신뢰성을 높이기 위해 실제로 어떤 방법을 사용할 것인지 선택할 것입니다.

물론 인생에서 나온 "W의 이야기"를 할 시간입니다.

첫 번째 예

N시에 있는 Pipe Rolling Plant No. 1의 명함 웹사이트를 상상해 보십시오. 큰 글자로 PIPE ROLLING PLANT No. 1이라고 적혀 있습니다. 바로 아래에는 “우리 파이프는 N에서 가장 둥근 파이프입니다”라는 슬로건이 있습니다. 그리고 아래에는 CEO의 전화번호와 이름이 나와 있습니다. 우리는 예약이 필요하다는 것을 알고 있습니다. 이것은 매우 중요한 것입니다! 그것이 무엇으로 구성되어 있는지 알아 내기 시작합시다. Html-statics - 즉, 총지배인이 실제로 파트너와 목욕탕 테이블에서 일종의 다음 거래에 대해 논의하고 있는 두 장의 사진입니다. 우리는 가동 중지 시간에 대해 생각하기 시작합니다. 생각나는 것은: 더 이상 거기에 XNUMX분 동안 누워 있어야 한다는 것입니다. 그리고 나서 질문이 생깁니다. 우리 사이트에서 일반적으로 얼마나 많은 매출이 있었습니까? 얼마-얼마요? "제로"은(는) 무슨 뜻인가요? 이는 장군이 작년에 같은 테이블에서 목욕탕에 가서 테이블에 앉았던 같은 사람들과 네 가지 거래를 모두 수행했기 때문입니다. 그리고 우리는 사이트가 하루 동안 그대로 유지되더라도 끔찍한 일은 일어나지 않을 것임을 이해합니다.

소개 정보를 바탕으로 이 이야기를 올리는 날이 있습니다. 중복성 계획에 대해 생각해 봅시다. 그리고 이 예에서는 가장 이상적인 중복 구성표를 선택합니다. 즉 중복성을 사용하지 않습니다. 이 모든 것은 연기 휴식 시간을 통해 XNUMX분 안에 모든 관리자에 의해 제기될 수 있습니다. 웹 서버 설치, 파일 추가 – 그게 전부입니다. 작동합니다. 아무것도 주의할 필요가 없고, 어떤 것에 특별한 주의를 기울일 필요도 없습니다. 즉, 예제 XNUMX의 결론은 매우 분명합니다. 예약할 필요가 없는 서비스는 예약할 필요가 없습니다.

예제 XNUMX

회사 블로그: 특별히 훈련받은 사람들이 그곳에서 뉴스를 쓰고, 우리는 이런저런 전시회에 참가했지만 또 다른 신제품을 출시하는 등의 일을 했습니다. 이것이 WordPress가 포함된 표준 PHP, 소규모 데이터베이스 및 약간의 정적이라고 가정해 보겠습니다. 물론, 어떤 상황에서도 누워 있어서는 안 된다는 점을 다시 한 번 생각하게 됩니다. “50분 이내!” 그게 전부입니다. 하지만 좀 더 생각해 보자. 이 블로그는 무엇을 하는 블로그인가요? 사람들은 유기적으로 일부 쿼리를 기반으로 Google의 Yandex에서 왔습니다. 엄청난. 매출이랑 관련이 있나요? 주현절: 그렇지 않아요. 광고 트래픽은 다른 시스템에 있는 기본 사이트로 이동합니다. 예약 계획에 대해 생각해 봅시다. 좋은 의미로는 한두 시간 안에 키워야 하는데, 이에 대비해 준비하면 좋을 것 같습니다. 다른 데이터 센터에서 머신을 가져와 거기에 환경, 즉 웹 서버, PHP, WordPress, MySQL을 롤업하고 그대로 두는 것이 합리적일 것입니다. 모든 것이 손상되었음을 이해하는 순간, 우리는 두 가지 작업을 수행해야 합니다. 즉, mysql 덤프를 XNUMX미터 떨어진 곳에 롤아웃하고 XNUMX분 안에 그곳으로 날아간 다음 백업에서 특정 수의 사진을 롤아웃하는 것입니다. 이것 또한 거기에 있지 않습니다. 왜냐하면 하나님께서는 얼마나 오래 걸릴지 아시기 때문입니다. 따라서 XNUMX분 안에 모든 것이 상승합니다. 복제가 없으면 자동 장애 조치가 가능합니다. 결론: 백업에서 신속하게 롤아웃할 수 있는 것은 백업할 필요가 없습니다.

세 번째 예, 더 복잡함

온라인 매장. 열린 마음을 가진 PhP는 약간 수정되었으며, 견고한 기반을 갖춘 mysql입니다. 꽤 많은 정적(결국 온라인 상점에는 아름다운 HD 이미지와 그 모든 것들이 있습니다), 세션용 Redis, 검색용 Elasticsearch가 있습니다. 우리는 가동 중지 시간에 대해 생각하기 시작합니다. 물론 온라인 상점이 하루 동안 고통없이 누워있을 수는 없다는 것이 분명합니다. 결국, 기간이 길어질수록 우리는 더 많은 돈을 잃게 됩니다. 속도를 높일 가치가 있습니다. 얼마나 많이? 한 시간 동안 누워 있으면 아무도 미치지 않을 것 같아요. 그렇습니다. 우리는 무언가를 잃게 될 것입니다. 그러나 열심히 일하기 시작하면 상황은 더욱 악화될 것입니다. 우리는 시간당 허용되는 가동 중지 시간 체계를 정의합니다.

이 모든 것을 어떻게 예약할 수 있나요? 어쨌든 차가 필요합니다. 한 시간은 아주 짧습니다. Mysql: 여기서는 이미 복제, 실시간 복제가 필요합니다. 한 시간 내에 100GB가 덤프에 추가되지 않을 가능성이 높기 때문입니다. 정적, 사진: 다시 말하지만 한 시간 안에 500GB를 추가할 시간이 없을 수 있습니다. 따라서 사진을 바로 복사하는 것이 좋습니다. Redis: 여기가 흥미로운 부분입니다. Redis에는 세션이 저장됩니다. 그냥 가져와서 묻어둘 수는 없습니다. 이는 별로 좋지 않기 때문에 모든 사용자가 로그아웃되고 장바구니가 비워지는 등의 작업이 수행됩니다. 사람들은 사용자 이름과 비밀번호를 다시 입력해야 하며, 많은 사람들이 이탈하여 구매를 완료하지 못할 수도 있습니다. 이번에도 전환이 감소합니다. 반면에 Redis는 바로 최신 상태이므로 마지막으로 로그인한 사용자도 필요하지 않을 것입니다. 그리고 좋은 절충안은 Redis를 가져와서 어제의 백업에서 복원하거나, 매시간 수행한다면 한 시간 전의 백업에서 복원하는 것입니다. 다행히 백업에서 복원한다는 것은 하나의 파일을 복사하는 것을 의미합니다. 그리고 가장 흥미로운 이야기는 Elasticsearch입니다. 누가 MySQL 복제를 선택했습니까? Elasticsearch 복제를 선택한 사람은 누구입니까? 그리고 그 이후에는 누구에게 정상적으로 작동했습니까? 내 말은 우리 시스템에서 특정 개체를 본다는 것입니다. 유용한 것 같지만 복잡합니다.
동료 엔지니어들이 작업 경험이 없다는 점에서 복잡합니다. 아니면 부정적인 경험이 있습니다. 또는 우리는 이것이 여전히 뉘앙스나 원시성을 지닌 상당히 새로운 기술이라는 것을 알고 있습니다. 우리 생각엔... 젠장, Elastic도 건전한데, 백업에서 복원하는 데도 시간이 오래 걸리네요. 어떻게 해야 할까요? 우리의 경우에는 Elastic이 검색에 사용된다는 것을 이해합니다. 우리 온라인 매장에서는 어떻게 판매하나요? 우리는 마케터에게 가서 사람들이 어디서 왔는지 물어봅니다. 그들은 "Yandex Market의 90%가 제품 카드로 직접 이동합니다."라고 대답합니다. 그리고 그들은 그것을 구매하거나 구매하지 않습니다. 따라서 10%의 사용자가 검색을 필요로 합니다. 특히 서로 다른 영역에 있는 서로 다른 데이터 센터 간에 탄력적인 복제를 유지하는 데는 실제로 많은 차이가 있습니다. 어느 출구인가요? 우리는 예약된 사이트에서 Elastic을 가져와서 아무 것도 하지 않습니다. 문제가 오래 끌면 언젠가는 문제를 제기할 수도 있지만 확실하지는 않습니다. 실제로 결론은 플러스 또는 마이너스와 같습니다. 우리는 돈에 영향을 미치지 않는 서비스를 예약하지 않습니다. 다이어그램을 더 단순하게 유지합니다.

예제 XNUMX, 훨씬 더 어렵습니다.

통합자: 꽃 판매, 택시 부르기, 상품 판매 등 일반적으로 무엇이든 가능합니다. 많은 수의 사용자에게 연중무휴 24시간 작동하는 중요한 기능입니다. 흥미로운 기반, 솔루션, 높은 부하가 있고 가장 중요한 것은 7분 이상 누워 있으면 아프다는 본격적인 흥미로운 스택을 사용합니다. 사람들이 구매하지 않을 뿐만 아니라, 이것이 효과가 없다는 것을 알게 되므로 화를 내고 전혀 돌아오지 않을 수도 있습니다.

좋아요. 53분. 이에 대해 우리는 무엇을 할 것인가? 이 경우 우리는 성인처럼 모든 돈을 사용하여 모든 것을 복제하는 실제 백업 사이트를 구축하고 가능한 한 이 사이트로의 전환을 자동화할 수도 있습니다. 그리고 이 외에도 한 가지 중요한 일을 기억해야 합니다. 실제로 전환 규정을 작성하는 것입니다. 모든 것을 자동화하더라도 규정은 매우 간단할 수 있습니다. 시리즈에서 "이러한 Ansible 스크립트 실행", "Route XNUMX에서 이러저러한 확인란 클릭" 등이 있지만 이는 일종의 정확한 작업 목록이어야 합니다.

그리고 모든 것이 분명해 보입니다. 복제 전환은 간단한 작업입니다. 그렇지 않으면 자동으로 전환됩니다. DNS에서 도메인 이름을 다시 쓰는 것은 동일한 시리즈에서 나온 것입니다. 문제는 그러한 프로젝트가 실패하면 패닉이 시작되고 심지어 가장 강하고 수염이 많은 관리자도 이에 취약할 수 있다는 것입니다. “단말기를 열어라, 이리로 와라, 우리 서버 주소는 아직 이렇다”는 명확한 지시 없이는 소생에 할당된 5분 제한 시간을 맞추기가 어렵다. 게다가 이러한 규정을 사용하면 인프라의 일부 변경 사항을 쉽게 기록하고 이에 따라 규정을 변경할 수 있습니다.
글쎄요, 예약 시스템이 매우 복잡하고 어떤 시점에서 실수를 했다면 백업 사이트를 파괴할 수 있으며 또한 두 사이트 모두에서 데이터를 호박으로 바꿀 수 있습니다. 이는 완전히 슬픈 일이 될 것입니다.

예 XNUMX번, 완전한 하드코어

전 세계 수억 명의 사용자를 보유한 국제 서비스입니다. 모든 시간대가 있고, 최고 속도에서 부하가 높아 전혀 누울 수 없습니다. 잠시 후 - 슬플 것입니다. 무엇을 해야 할까요? 전체 프로그램에 따라 다시 예약하세요. 우리는 이전 예에서 제가 이야기한 모든 것을 수행했으며 그 이상도 수행했습니다. 이상적인 세상이며 우리의 인프라는 IaaC devops의 모든 개념을 따릅니다. 즉, 모든 것이 git에 있으므로 버튼만 누르기만 하면 됩니다.

없어진 물건 있어요? 하나 - 운동. 그들 없이는 불가능합니다. 우리에게는 모든 것이 완벽한 것 같고 일반적으로 모든 것을 통제할 수 있습니다. 버튼을 누르면 모든 일이 일어납니다. 이것이 사실이라 할지라도 – 그리고 우리는 이것이 이런 식으로 일어나지 않는다는 것을 이해합니다 – 우리 시스템은 다른 시스템과 상호 작용합니다. 예를 들어, 이는 Route 53의 DNS, s3 스토리지, 일부 API와의 통합입니다. 우리는 이 추측적인 실험에서 모든 것을 예측할 수는 없습니다. 그리고 실제로 스위치를 당기기 전까지는 스위치가 작동할지 안 할지 알 수 없습니다.

아마 그게 전부일 것입니다. 게으르거나 과용하지 마십시오. 그리고 가동 시간이 당신과 함께할 수 있습니다!

출처 : habr.com