HighLoad++, Evgeniy Kuzovlev(EcommPay IT): 100000분의 다운타임 비용이 $XNUMX인 경우 취해야 할 조치

모두가 개발 및 테스트, 직원 교육, 동기 부여 프로세스에 대해 이야기하지만 XNUMX분의 서비스 중단 시간에 막대한 비용이 소요되는 경우 이러한 프로세스로는 충분하지 않습니다. 엄격한 SLA에 따라 금융거래를 할 경우 어떻게 해야 하나요? 개발과 테스트를 방정식에서 제외하여 시스템의 안정성과 내결함성을 높이는 방법은 무엇입니까?

다음 HighLoad++ 컨퍼런스는 6년 7월 2020일과 XNUMX일에 상트페테르부르크에서 개최됩니다. 세부정보 및 티켓 링크. 9월 18일 00:2018. HighLoad++ 모스크바 XNUMX, 델리 + 콜카타 홀. 논문과 제출.

Evgeniy Kuzovlev(이하 – EC): - 친구들, 안녕! 내 이름은 Kuzovlev Evgeniy입니다. 저는 EcommPay 회사 출신이고 특정 부서는 회사 그룹의 IT 부서인 EcommPay IT입니다. 그리고 오늘 우리는 가동 중지 시간을 피하는 방법, 피할 수 없는 경우 결과를 최소화하는 방법에 대해 이야기하겠습니다. 주제는 다음과 같습니다: "100분의 다운타임 비용이 $000인 경우 어떻게 해야 합니까?" 앞으로 우리의 숫자는 비슷할 것입니다.

EmmPay IT는 무엇을 합니까?

우리는 누구입니까? 나는 왜 여기 당신 앞에 서 있습니까? 왜 내가 여기서 당신에게 말할 권리가 있습니까? 여기서는 무엇에 대해 더 자세히 이야기할까요?

EcommPay 그룹은 국제 인수자입니다. 우리는 러시아, 유럽, 동남아시아(전 세계) 등 전 세계에서 결제를 처리합니다. 우리는 총 9개의 사무실과 500명의 직원을 보유하고 있으며 그 중 약 절반 미만이 IT 전문가입니다. 우리가 하는 모든 일, 우리가 돈을 버는 모든 일은 우리 스스로 한 것입니다.

우리는 모든 제품을 직접 작성했습니다(대형 IT 제품 라인에는 약 16개의 서로 다른 구성 요소가 있습니다). 우리는 스스로 글을 쓰고, 스스로를 발전시킵니다. 그리고 현재 우리는 하루에 약 백만 건의 거래를 수행하고 있습니다(아마도 수백만 건이라고 말하는 것이 올바른 표현일 것입니다). 우리는 꽤 젊은 회사입니다. 이제 겨우 XNUMX년밖에 되지 않았습니다.

6년 전 두 사람이 함께 사업을 시작했을 때는 정말 스타트업이었습니다. 그들은 하나의 아이디어(아이디어 외에는 아무것도 없었음)로 뭉쳤고, 우리는 달렸습니다. 다른 스타트업과 마찬가지로 우리는 더 빠르게 달렸습니다. 우리에게는 품질보다 속도가 더 중요했습니다.

어느 시점에서 우리는 멈추었습니다. 우리는 더 이상 그 속도와 품질로는 살 수 없다는 것을 깨달았고 먼저 품질에 집중해야 했습니다. 이 순간 우리는 정확하고 확장 가능하며 신뢰할 수 있는 새로운 플랫폼을 작성하기로 결정했습니다. 그들은 이 플랫폼을 작성하기 시작했지만(투자, 개발 개발, 테스트 시작) 어느 시점에서 개발과 테스트로는 우리가 새로운 수준의 서비스 품질에 도달할 수 없다는 것을 깨달았습니다.

새로운 제품을 만들어 생산에 투입하지만 여전히 어딘가에서 문제가 발생할 수 있습니다. 그리고 오늘 우리는 새로운 품질 수준에 도달하는 방법(우리가 이를 수행한 방법, 경험에 대해)에 대해 이야기하고 개발 및 테스트를 방정식에서 제외할 것입니다. 우리는 운영에 무엇이 가능한지, 즉 어떤 운영이 스스로 할 수 있는지, 품질에 영향을 미치기 위해 테스트에 무엇을 제공할 수 있는지에 대해 이야기할 것입니다.

가동 중지 시간. 작전의 계명.

항상 가장 중요한 초석인 오늘 실제로 이야기할 내용은 가동 중지 시간입니다. 끔찍한 말입니다. 가동 중지 시간이 있으면 모든 것이 우리에게 좋지 않습니다. 우리는 그것을 올리기 위해 달리고 있고 관리자는 서버를 잡고 있습니다. 그들이 그 노래에서 말하는 것처럼 그것이 떨어지지 않는 것을 신은 금합니다. 이것이 오늘 우리가 이야기할 내용입니다.

우리가 접근 방식을 바꾸기 시작했을 때 우리는 4계명을 만들었습니다. 슬라이드에 제시했습니다.

이 계명은 매우 간단합니다.

• 문제를 신속하게 식별하십시오.
• 더 빨리 제거하십시오.
• 이유를 이해하도록 도와주세요(나중에 개발자용).
• 그리고 접근방식을 표준화하세요.

두 번째 사항에 주목하고 싶습니다. 우리는 문제를 해결하는 것이 아니라 제거하는 것입니다. 결정하는 것은 부차적입니다. 우리에게 가장 중요한 것은 사용자가 이 문제로부터 보호된다는 것입니다. 그것은 고립된 환경에 존재하지만 이 환경은 그것과 어떤 접촉도 하지 않을 것입니다. 실제로 우리는 이 네 가지 문제 그룹(일부는 더 자세히, 일부는 덜 자세하게)을 살펴보고 우리가 사용하는 것과 솔루션에 대한 관련 경험을 알려줄 것입니다.

문제 해결: 이러한 문제는 언제 발생하며 어떻게 해야 합니까?

그러나 우리는 순서대로 시작할 것입니다. 2 번 항목부터 시작하겠습니다. 문제를 빨리 제거하는 방법은 무엇입니까? 문제가 있습니다. 문제를 해결해야 합니다. “이 문제에 대해 어떻게 해야 합니까?” - 주요 질문. 그리고 문제 해결 방법을 생각하기 시작했을 때 문제 해결을 위해 따라야 하는 몇 가지 요구 사항을 스스로 개발했습니다.

이러한 요구 사항을 공식화하기 위해 우리는 "언제 문제가 발생합니까?"라는 질문을 스스로에게 물어보기로 결정했습니다. 그리고 문제는 네 가지 경우에 발생합니다.

• 하드웨어 오류.
• 외부 서비스가 실패했습니다.
• 소프트웨어 버전 변경(동일 배포)
• 폭발적인 부하 증가.

처음 두 가지에 대해서는 이야기하지 않겠습니다. 하드웨어 오작동은 아주 간단하게 해결할 수 있습니다. 모든 것을 복제해야 합니다. 디스크인 경우 디스크를 RAID로 조립해야 하고, 서버인 경우 서버를 복제해야 하며, 네트워크 인프라가 있는 경우 네트워크 인프라의 두 번째 복사본을 제공해야 합니다. 그것을 복제하십시오. 그리고 문제가 발생하면 예비 전력으로 전환됩니다. 여기서는 더 이상 말하기가 어렵습니다.

두 번째는 외부 서비스의 실패이다. 대부분의 경우 시스템은 전혀 문제가 되지 않지만 우리에게는 그렇지 않습니다. 우리는 결제를 처리하기 때문에 사용자(카드 데이터를 입력하는 사람)와 은행, 결제 시스템(Visa, MasterCard, Mira 등) 사이에 있는 통합자입니다. 우리의 외부 서비스(결제 시스템, 은행)는 실패하는 경향이 있습니다. 당사나 귀하(귀하가 그러한 서비스를 갖고 있는 경우)는 이에 영향을 미칠 수 없습니다.

그러면 무엇을 해야 할까요? 여기에는 두 가지 옵션이 있습니다. 첫째, 가능하다면 어떤 방식으로든 이 서비스를 복제해야 합니다. 예를 들어, 가능하다면 트래픽을 한 서비스에서 다른 서비스로 전송합니다. 예를 들어 카드는 Sberbank를 통해 처리되었으며 Sberbank에는 문제가 있습니다. 트래픽을 [조건부로] Raiffeisen으로 전송합니다. 두 번째로 우리가 할 수 있는 일은 외부 서비스의 실패를 매우 빠르게 알아차리는 것입니다. 따라서 보고서의 다음 부분에서 응답 속도에 대해 이야기하겠습니다.

실제로 이 네 가지 중 특히 소프트웨어 버전 변경에 영향을 미칠 수 있습니다. 즉, 배포 상황과 부하가 폭발적으로 증가하는 상황을 개선할 수 있는 조치를 취하는 것입니다. 사실, 그게 우리가 한 일이에요. 여기서도 작은 메모를 하나...

이 네 가지 문제 중 일부는 클라우드가 있으면 즉시 해결됩니다. Microsoft Azhur, Ozone 클라우드에 있거나 Yandex 또는 Mail의 클라우드를 사용하는 경우 적어도 하드웨어 오작동이 문제가 되고 하드웨어 오작동과 관련하여 모든 것이 즉시 문제가 되지 않습니다.

우리는 조금 특이한 회사입니다. 여기에서는 모두가 "Kubernets", 클라우드에 대해 이야기하고 있습니다. "Kubernets"도 클라우드도 없습니다. 하지만 우리는 많은 데이터 센터에 하드웨어 랙을 보유하고 있으며 우리는 이 하드웨어에 의존하여 생활해야 하며 모든 것에 대한 책임을 져야 합니다. 그러므로 우리는 이러한 맥락에서 이야기할 것입니다. 그래서 문제에 대해. 처음 두 개는 괄호에서 꺼냈습니다.

소프트웨어 버전을 변경합니다. 기지

우리 개발자는 프로덕션에 액세스할 수 없습니다. 왜 그런 겁니까? 우리는 PCI DSS 인증을 받았으며 개발자는 단순히 "제품"에 들어갈 권리가 없습니다. 그게 다야, 기간. 조금도. 따라서 개발 책임은 개발이 릴리스를 위해 빌드를 제출하는 순간 종료됩니다.

우리에게 많은 도움이 되는 두 번째 기반은 문서화되지 않은 고유한 지식이 없다는 것입니다. 나는 그것이 당신에게도 동일하기를 바랍니다. 그렇지 않으면 문제가 생기기 때문입니다. 이 고유하고 문서화되지 않은 지식이 적절한 시점에 적절한 장소에 존재하지 않으면 문제가 발생합니다. 특정 구성 요소를 배포하는 방법을 아는 사람이 한 명 있다고 가정해 보겠습니다. 그 사람은 거기에 없고, 휴가 중이거나 아프기 때문에 문제가 있습니다.

그리고 우리가 도달한 세 번째 기초입니다. 우리는 고통, 피, 눈물을 통해 이 문제에 도달했습니다. 비록 오류가 없더라도 우리의 빌드에는 오류가 있다는 결론에 도달했습니다. 우리는 이것을 스스로 결정했습니다. 무언가를 배포할 때, 프로덕션에 넣을 때 오류가 있는 빌드가 발생합니다. 우리는 시스템이 충족해야 하는 요구 사항을 구성했습니다.

소프트웨어 버전 변경 요구 사항

세 가지 요구 사항이 있습니다.

• 신속하게 배포를 롤백해야 합니다.
• 배포 실패로 인한 영향을 최소화해야 합니다.
• 그리고 동시에 신속하게 배포할 수 있어야 합니다.
  바로 그 순서에요! 왜? 우선 새 버전을 배포할 때 속도는 중요하지 않지만, 문제가 발생하면 신속하게 롤백하고 영향을 최소화하는 것이 중요하기 때문입니다. 그러나 프로덕션에 일련의 버전이 있고 오류가 있는 것으로 밝혀진 경우(갑자기 배포는 없었지만 오류가 있음) 후속 배포 속도가 중요합니다. 이러한 요구를 충족하기 위해 우리는 무엇을 했습니까? 우리는 다음 방법론을 사용했습니다.

  
  
  꽤 잘 알려져 있지만 우리는 그것을 발명한 적이 없습니다. 이것이 Blue/Green 배포입니다. 그것은 무엇입니까? 애플리케이션이 설치된 각 서버 그룹에 대한 사본이 있어야 합니다. 복사본은 "웜"입니다. 트래픽이 없지만 언제든지 이 트래픽이 이 복사본으로 전송될 수 있습니다. 이 사본에는 이전 버전이 포함되어 있습니다. 그리고 배포 시 코드를 비활성 복사본으로 롤아웃합니다. 그런 다음 트래픽의 일부(또는 전체)를 새 버전으로 전환합니다. 따라서 이전 버전에서 새 버전으로 트래픽 흐름을 변경하려면 한 가지 작업만 수행하면 됩니다. 업스트림에서 밸런서를 변경하고 한 업스트림에서 다른 업스트림으로 방향을 변경해야 합니다. 이는 매우 편리하며 빠른 전환 및 빠른 롤백 문제를 해결합니다.

  여기서 두 번째 질문에 대한 해결책은 최소화입니다. 트래픽의 일부만 새 라인, 새 코드가 있는 라인(예: 2%)으로 보낼 수 있습니다. 그리고 이 2%는 100%가 아닙니다! 실패한 배포로 인해 트래픽이 100% 손실되면 무서운 일이고, 트래픽이 2% 손실되면 불쾌한 일이지만 두렵지는 않습니다. 더욱이, 어떤 경우에는 (전혀는 아니지만) 동일한 사용자가 F5 키를 누르면 다른 작업 버전으로 이동하기 때문에 사용자는 이를 알아차리지 못할 가능성이 높습니다.

  블루/그린 배포. 라우팅

  그러나 모든 것이 그렇게 단순하지는 않습니다. "블루/그린 배포"... 모든 구성 요소는 세 그룹으로 나눌 수 있습니다.

  • 이것은 프런트엔드(고객이 보는 결제 페이지)입니다.
  • 처리 코어;
  • 결제 시스템(은행, MasterCard, Visa...) 작업용 어댑터.

  그리고 여기에는 뉘앙스가 있습니다. 뉘앙스는 라인 간 라우팅에 있습니다. 트래픽을 100% 전환하면 이러한 문제가 발생하지 않습니다. 하지만 2%를 전환하고 싶다면 "어떻게 해야 할까요?"라는 질문을 하기 시작합니다. 가장 간단한 것은 간단합니다. nginx에서 무작위 선택으로 라운드 로빈을 설정할 수 있으며 왼쪽에는 2%, 오른쪽에는 98%가 있습니다. 그러나 이것이 항상 적합한 것은 아닙니다.

  예를 들어, 우리의 경우 사용자는 두 개 이상의 요청으로 시스템과 상호 작용합니다. 이는 정상적인 현상입니다. 2, 3, 4, 5개의 요청 - 귀하의 시스템은 동일할 수 있습니다. 그리고 모든 사용자의 요청이 첫 번째 요청이 발생한 동일한 줄로 오는 것이 중요하거나 (두 번째 지점) 모든 사용자의 요청이 전환 후 새 줄로 오는 것이 중요하다면(그는 더 일찍 작업을 시작할 수도 있었습니다. 시스템, 스위치 전) - 이 무작위 배포는 귀하에게 적합하지 않습니다. 그런 다음 다음과 같은 옵션이 있습니다.

  
  
  가장 간단한 첫 번째 옵션은 클라이언트의 기본 매개변수(IP 해시)를 기반으로 합니다. IP가 있고 IP 주소를 기준으로 오른쪽에서 왼쪽으로 나눕니다. 그러면 제가 설명한 두 번째 사례가 도움이 될 것입니다. 배포가 발생했을 때 사용자는 이미 시스템 작업을 시작할 수 있었고 배포 순간부터 모든 요청은 새 줄(예: 동일한 줄)로 이동합니다.

  어떤 이유로 이것이 귀하에게 적합하지 않고 사용자의 초기 초기 요청이 발생한 라인으로 요청을 보내야 하는 경우 두 가지 옵션이 있습니다.
  첫 번째 옵션: 유료 nginx+를 구매할 수 있습니다. 사용자의 초기 요청 시 사용자에게 세션을 할당하고 이를 하나 또는 다른 업스트림에 바인딩하는 고정 세션 메커니즘이 있습니다. 세션 수명 내의 모든 후속 사용자 요청은 세션이 게시된 동일한 업스트림으로 전송됩니다.

  우리는 이미 일반 nginx를 가지고 있었기 때문에 이것은 우리에게 적합하지 않았습니다. nginx+로 전환하는 것은 비용이 많이 든다는 것이 아니라 우리에게 다소 고통스럽고 그다지 옳지 않다는 것입니다. 예를 들어, "Sticks Sessions"는 "Sticks Sessions"가 "Either-or" 기반 라우팅을 허용하지 않는다는 단순한 이유 때문에 우리에게는 작동하지 않았습니다. 예를 들어 IP 주소, IP 주소 및 쿠키 또는 사후 매개변수를 사용하여 "Sticks Sessions"이 수행하는 작업을 지정할 수 있지만 "Either-or"는 더 복잡합니다.

  따라서 우리는 네 번째 옵션을 선택했습니다. 우리는 nginx를 스테로이드로 사용했습니다(이것은 openresty입니다). 이것은 마지막 스크립트 포함을 추가로 지원하는 동일한 nginx입니다. 마지막 스크립트를 작성하고 "open Rest"를 제공하면 사용자 요청이 오면 이 마지막 스크립트가 실행됩니다.

  실제로 우리는 "openresti"를 설정하고 "Or"를 연결하여 6개의 서로 다른 매개변수를 정렬하는 스크립트를 작성했습니다. 하나 또는 다른 매개변수의 존재 여부에 따라 사용자가 한 페이지 또는 다른 페이지, 한 줄 또는 다른 줄을 방문했음을 알 수 있습니다.

  블루/그린 배포. 장점과 단점

  물론 좀 더 간단하게 만드는 것도 가능했을 것입니다(동일한 "고정 세션" 사용). 그러나 우리는 하나의 트랜잭션을 하나의 처리 프레임워크 내에서 사용자뿐만 아니라 우리와 상호 작용한다는 그런 뉘앙스도 가지고 있습니다... 그러나 결제 시스템도 우리와 상호 작용합니다. 거래를 처리한 후(결제 시스템에 요청을 전송하여) 쿨백을 받습니다.
  그리고 우리 회로 내부에서 모든 요청에서 사용자의 IP 주소를 전달할 수 있고 IP 주소를 기반으로 사용자를 나눌 수 있다면 동일한 "Visa"를 말하지 않을 것입니다. "야, 우리는 정말 복고풍 회사입니다. 국제적이어야 합니다(웹 사이트 및 러시아에서)... 추가 필드에 사용자의 IP 주소를 제공하십시오. 귀하의 프로토콜은 표준화되어 있습니다! 그들이 동의하지 않을 것이 분명합니다.

  
  
  따라서 이것은 우리에게 효과가 없었습니다. 우리는 개방형을 수행했습니다. 따라서 라우팅을 사용하면 다음과 같은 결과를 얻을 수 있습니다.

  따라서 Blue/Green 배포에는 앞서 언급한 장점과 단점이 있습니다.

  두 가지 단점:

  • 라우팅에 신경을 써야 합니다.
  • 두 번째 주요 단점은 비용입니다.

  이 동물원 전체를 유지하려면 두 배의 서버가 필요하고, 두 배의 운영 리소스가 필요하며, 두 배의 노력을 기울여야 합니다.

  그건 그렇고, 장점 중에는 이전에 언급하지 않은 것이 하나 더 있습니다. 부하 증가에 대비한 여유 공간이 있다는 것입니다. 로드가 폭발적으로 증가하고 사용자 수가 많은 경우 50~50 분포에 두 번째 줄을 포함하기만 하면 더 많은 서버 보유 문제가 해결될 때까지 클러스터에 즉시 x2 서버가 있게 됩니다.

  빠르게 배포하는 방법은 무엇입니까?

  최소화 및 빠른 롤백 문제를 해결하는 방법에 대해 이야기했지만 "어떻게 빠르게 배포할 수 있습니까?"라는 질문이 남아 있습니다.

  
  
  여기서는 짧고 간단합니다.

  • CD 시스템(지속적 전달)이 있어야 합니다. CD 시스템 없이는 살 수 없습니다. 서버가 하나인 경우 수동으로 배포할 수 있습니다. 물론 우리는 약 XNUMX개의 서버와 XNUMX개의 핸들을 보유하고 있습니다. 단지 배포하기 위해 이 방 크기의 부서를 설치할 수도 있습니다.
  • 배포는 병렬이어야 합니다. 배포가 순차적이라면 모든 것이 좋지 않습니다. 하나의 서버가 일반적이므로 하루 종일 XNUMX개의 서버를 배포하게 됩니다.
  • 다시 말하지만, 가속을 위해 이는 더 이상 필요하지 않을 수 있습니다. 배포하는 동안 일반적으로 프로젝트가 빌드됩니다. 웹 프로젝트가 있고 프런트엔드 부분이 있고(거기서 웹 팩을 만들고 npm을 컴파일하는 등) 이 프로세스는 원칙적으로 수명이 짧습니다(5분). 비판적이다. 예를 들어, 이것이 바로 우리가 그렇게 하지 않는 이유입니다. 우리는 이 5분을 제거하고 아티팩트를 배포합니다.

    유물이란 무엇입니까? 아티팩트는 모든 조립 부품이 이미 완료된 조립 빌드입니다. 우리는 이 아티팩트를 아티팩트 저장소에 저장합니다. 한때 우리는 두 개의 저장소를 사용했습니다(Nexus와 현재는 jFrog Artifactory). 처음에는 Java 애플리케이션에서 이 접근 방식을 실행하기 시작했기 때문에 "Nexus"를 사용했습니다(잘 맞았습니다). 그런 다음 거기에 PHP로 작성된 일부 애플리케이션을 넣습니다. 그리고 “Nexus”는 더 이상 적합하지 않았기 때문에 우리는 거의 모든 것을 인공물로 만들 수 있는 jFrog Artefactory를 선택했습니다. 우리는 이 아티팩트 저장소에 서버용으로 수집한 자체 바이너리 패키지를 저장하는 지점까지 왔습니다.

  폭발적인 부하 증가

  소프트웨어 버전 변경에 대해 이야기했습니다. 다음은 부하가 폭발적으로 증가하는 것입니다. 여기서는 부하의 폭발적인 증가가 옳지 않다는 뜻일 것입니다.

  우리는 새로운 시스템을 작성했습니다. 이는 서비스 지향적이고, 패셔너블하며, 아름답고, 어디에서나 작업자가 있고, 어디에서나 대기열이 있고, 어디에서나 비동기식입니다. 그리고 이러한 시스템에서는 데이터가 다양한 흐름을 통해 흐를 수 있습니다. 첫 번째 트랜잭션에는 1번째, 3번째, 10번째 워커를 사용할 수 있고, 두 번째 트랜잭션인 2번째, 4번째, 5번째 워커를 사용할 수 있습니다. 그리고 오늘은 아침에 처음 세 명의 작업자를 사용하는 데이터 흐름이 있고 저녁에는 극적으로 변화하여 모든 것이 나머지 세 명의 작업자를 사용한다고 가정해 보겠습니다.

  그리고 여기서는 어떻게든 작업자를 확장하고 서비스를 확장해야 하지만 동시에 리소스 팽창을 방지해야 한다는 것이 밝혀졌습니다.

  
  
  우리는 요구 사항을 정의했습니다. 이러한 요구 사항은 매우 간단합니다. 서비스 검색, 매개 변수화가 있어야 합니다. 리소스 감가상각이라는 한 지점을 제외하고는 모든 것이 확장 가능한 시스템을 구축하기 위한 표준입니다. 우리는 서버가 공기를 가열하도록 자원을 상환할 준비가 되어 있지 않다고 말했습니다. 우리는 "Consul"을 선택했고 직원을 관리하는 "Nomad"를 선택했습니다.

  이것이 왜 우리에게 문제가 됩니까? 조금 뒤로 돌아가 보겠습니다. 현재 우리 뒤에는 약 70개의 결제 시스템이 있습니다. 예를 들어 아침에는 트래픽이 Sberbank를 통과한 다음 Sberbank가 중단되어 다른 결제 시스템으로 전환합니다. Sberbank 이전에는 직원이 100명이었는데, 그 이후에는 다른 결제 시스템을 위해 직원을 100명 대폭 늘려야 합니다. 그리고 이 모든 일이 인간의 참여 없이 일어나는 것이 바람직합니다. 인간의 참여가 있다면 엔지니어가 연중무휴 24시간 앉아 있어야 하고 이 작업만 수행해야 하기 때문입니다. 왜냐하면 7개의 시스템이 뒤쳐지면 그러한 실패가 정기적으로 발생하기 때문입니다.

  따라서 우리는 개방형 IP를 보유한 Nomad를 살펴보고 대략 다음과 같은 작업을 수행하는 자체 개발인 Scale-Nomad - ScaleNo를 작성했습니다. 대기열의 증가를 모니터링하고 역학에 따라 작업자 수를 줄이거나 늘립니다. 대기열의. 우리가 그것을 했을 때, 우리는 "어쩌면 오픈 소스로 만들 수 있지 않을까?"라고 생각했습니다. 그런 다음 그들은 그녀를 보았습니다. 그녀는 코펙 두 개만큼 단순했습니다.

  지금까지 우리는 그것을 오픈 소스로 공개하지 않았지만 보고서가 나온 후 갑자기 그런 것이 필요하다는 것을 깨닫고 그것이 필요하다면 내 연락처가 마지막 슬라이드에 있습니다. 나에게 편지를 보내주십시오. 최소 3~5명 이상이면 후원해 드립니다.

  
  
  어떻게 작동하나요? 한번 살펴보자! 앞을 내다보면 왼쪽에는 모니터링 부분이 있습니다. 이는 한 줄이고, 상단은 이벤트 처리 시간, 중간은 트랜잭션 수, 하단은 작업자 수입니다.

  잘 보시면 이 사진에는 결함이 있습니다. 상단 차트에서 차트 중 하나가 45초 만에 충돌했습니다. 결제 시스템 중 하나가 다운되었습니다. 즉시 트래픽이 2분 만에 유입되었고 작업자가 없는 다른 결제 시스템에서 대기열이 커지기 시작했습니다(우리는 리소스를 활용하지 않았습니다. 반대로 리소스를 올바르게 처리했습니다). 우리는 난방을 원하지 않았습니다. 최소한 5-10명의 직원이 있었지만 그들은 대처할 수 없었습니다.

  마지막 그래프에는 "혹"이 표시되는데, 이는 "Skaleno"가 이 양을 두 배로 늘렸다는 의미입니다. 그리고 그래프가 조금 떨어지면 조금 줄였습니다. 작업자 수가 자동으로 변경되었습니다. 이것이 바로 이것이 작동하는 방식입니다. 우리는 두 번째 요점인 "이유를 빨리 제거하는 방법"에 대해 이야기했습니다.

  모니터링. 문제를 빠르게 식별하는 방법은 무엇입니까?

  이제 첫 번째 포인트는 “어떻게 하면 문제를 빨리 식별할 수 있을까?”이다. 모니터링! 우리는 어떤 것들은 빨리 이해해야 합니다. 어떤 내용을 빨리 이해해야 할까요?

  
  
  세개!

  • 우리는 우리 자원의 성능을 빠르게 이해하고 이해해야 합니다.
  • 우리는 장애를 빠르게 이해하고 외부 시스템의 성능을 모니터링해야 합니다.
  • 세 번째 요점은 논리적 오류를 식별하는 것입니다. 이것은 시스템이 작동하고 모든 지표에 따라 모든 것이 정상이지만 뭔가 잘못되었을 때입니다.

  여기서는 그다지 멋진 내용을 말하지 않을 것입니다. 난 캡틴 오비어스가 될 거예요. 우리는 시장에 무엇이 있는지 찾아보았습니다. 우리에겐 '재미있는 동물원'이 있어요. 현재 우리가 가지고 있는 동물원은 다음과 같습니다.

  
  
  우리는 Zabbix를 사용하여 하드웨어를 모니터링하고 서버의 주요 지표를 모니터링합니다. 우리는 데이터베이스에 Okmeter를 사용합니다. 우리는 처음 두 가지에 맞지 않는 다른 모든 지표에 대해 "Grafana"와 "Prometheus"를 사용합니다. 일부는 "Grafana"와 "Prometheus"를 사용하고 일부는 "Influx" 및 Telegraf를 사용하여 "Grafana"를 사용합니다.

  1,5년 전에 우리는 New Relic을 사용하고 싶었습니다. 멋진 점은 모든 것을 할 수 있다는 것입니다. 하지만 그녀가 모든 것을 할 수 있는 만큼 그녀는 너무 비싸다. 서버 규모가 15대 규모로 성장했을 때 한 업체가 찾아와 “내년에 계약을 체결하자”고 말했다. 우리는 가격을 보고 아니오라고 말했습니다. 그렇게 하지 않겠습니다. 이제 우리는 New Relic을 포기하고 New Relic을 모니터링하는 서버가 약 XNUMX개 남았습니다. 가격은 정말 터무니없는 것으로 판명되었습니다.

  그리고 우리가 직접 구현한 도구가 하나 있는데, 바로 Debugger입니다. 처음에는 배거(Bagger)라고 불렀는데, 영어 선생님이 지나가시더니 크게 웃으시더니 이름을 디배거(Debagger)로 바꾸셨어요. 그것은 무엇입니까? 이는 실제로 시스템의 "블랙박스"와 같이 각 구성 요소에 대해 15~30초 내에 구성 요소의 전체 성능에 대한 테스트를 실행하는 도구입니다.

  예를 들어, 외부 페이지(결제 페이지)가 있으면 간단히 열어서 어떻게 보일지 살펴봅니다. 이것이 처리 중이라면 그는 테스트 "트랜잭션"을 보내고 이 "트랜잭션"이 도착하는지 확인합니다. 이것이 결제 시스템과 관련된 것이라면 가능한 한 그에 따라 테스트 요청을 실행하고 모든 것이 괜찮은지 확인합니다.

  모니터링에 중요한 지표는 무엇입니까?

  우리는 주로 무엇을 모니터링합니까? 우리에게 중요한 지표는 무엇입니까?

  
  

  • 전면의 응답 시간 / RPS는 매우 중요한 지표입니다. 그는 즉시 당신에게 문제가 있다고 대답합니다.
  • 모든 대기열에서 처리된 메시지 수입니다.
  • 근로자 수.
  • 기본 정확성 측정항목.

  마지막 요점은 "비즈니스", "비즈니스" 측정 항목입니다. 동일한 것을 모니터링하려면 주요 지표인 하나 또는 두 개의 지표를 정의해야 합니다. 우리의 지표는 처리량입니다(전체 트랜잭션 흐름에 대한 성공적인 트랜잭션 수의 비율). 5-10-15분 간격으로 무언가 변경되면 문제가 있다는 의미입니다(급격하게 변경된 경우).

  우리에게 보이는 모습은 우리 보드 중 하나의 예입니다.

  
  
  왼쪽에는 6개의 그래프가 있습니다. 이는 작업자 수와 대기열의 메시지 수를 나타내는 선에 따른 것입니다. 오른쪽 - RPS, RTS. 아래는 동일한 "비즈니스" 지표입니다. 그리고 "비즈니스" 지표에서 우리는 두 개의 중간 그래프에서 문제가 발생했음을 즉시 확인할 수 있습니다. 이것은 우리 뒤에 서 있는 또 하나의 무너진 시스템일 뿐입니다.

  두 번째로 해야 할 일은 외부 결제 시스템의 몰락을 모니터링하는 것이었습니다. 여기에서는 분산 시스템을 추적할 수 있는 메커니즘, 표준, 패러다임인 OpenTracing을 사용했습니다. 그리고 조금 바뀌었어요. 표준 OpenTracing 패러다임에서는 각 개별 요청에 대한 추적을 구축한다고 말합니다. 우리는 이것이 필요하지 않았기 때문에 요약, 집계 추적으로 포장했습니다. 우리는 뒤에 있는 시스템의 속도를 추적할 수 있는 도구를 만들었습니다.

  
  
  그래프는 결제 시스템 중 하나가 3초 안에 응답하기 시작했음을 보여줍니다. 문제가 있습니다. 게다가 문제가 시작되면 20~30초 간격으로 반응합니다.

  그리고 존재하는 모니터링 오류의 세 번째 클래스는 논리적 모니터링입니다.

  솔직히 말해서 저는 이 슬라이드에 무엇을 그려야 할지 몰랐습니다. 왜냐하면 우리는 우리에게 적합한 것을 시장에서 오랫동안 찾고 있었기 때문입니다. 아무것도 찾지 못했기 때문에 우리가 직접 해야 했습니다.

  
  
  논리적 모니터링이란 무엇을 의미합니까? 글쎄, 상상해보십시오. 자신을 시스템 (예 : Tinder 클론)으로 만듭니다. 당신이 그것을 만들고 시작했습니다. 성공적인 관리자 Vasya Pupkin은 그것을 자신의 전화기에 넣고 거기에있는 소녀를보고 그녀를 좋아합니다 ... 그리고 같은 것은 소녀에게 전달되지 않습니다. 같은 비즈니스 센터의 경비원 Mikhalych에게 전달됩니다. 관리자는 아래층으로 내려가서 "이 경비원 미칼리치가 왜 그 사람에게 그렇게 기분 좋게 미소를 짓는 걸까요?"라고 궁금해합니다.

  그런 상황에서는... 우리에게 이 상황은 조금 다르게 들립니다. 왜냐하면 (내가 쓴) 이것은 간접적으로 금전적 손실로 이어지는 평판 손실이기 때문입니다. 우리의 상황은 정반대입니다. 예를 들어, 거래를 성공적으로 수행했지만 성공하지 못한 경우(또는 그 반대의 경우) 직접적인 금전적 손실을 입을 수 있습니다. 저는 비즈니스 지표를 사용하여 시간이 지남에 따라 성공적인 거래 수를 추적하는 자체 도구를 작성해야 했습니다. 시장에서 아무것도 찾지 못했습니다! 이것이 바로 제가 전달하고 싶었던 아이디어입니다. 이런 종류의 문제를 해결할 수 있는 제품은 시중에 없습니다.

  문제를 빠르게 파악하는 방법에 관한 내용이었습니다.

  배포 이유를 확인하는 방법

  우리가 해결하는 세 번째 문제 그룹은 문제를 식별한 후, 문제를 제거한 후 개발 이유, 테스트 이유를 이해하고 이에 대해 조치를 취하는 것이 좋습니다. 따라서 조사가 필요하고, 로그를 올려야 합니다.

  
  
  로그에 관해 이야기하는 경우(주요 이유는 로그임) 대부분의 로그는 ELK 스택에 있습니다. 거의 모든 사람이 동일합니다. 일부의 경우 ELK에 없을 수도 있지만 기가바이트 단위로 로그를 작성하면 조만간 ELK에 올 것입니다. 우리는 이를 테라바이트 단위로 기록합니다.

  
  
  여기에 문제가 있습니다. 우리는 그것을 고치고, 사용자를 위한 오류를 수정하고, 거기에 무엇이 있는지 파헤치기 시작했고, Kibana에 올라가 거기에 거래 ID를 입력하고 이와 같은 족보를 얻었습니다(많은 것을 보여줍니다). 그리고 이 신발에는 전혀 명확한 것이 없습니다. 왜? 네, 어느 부분이 어느 작업자에 속하는지, 어느 부분이 어느 구성 요소에 속하는지 명확하지 않기 때문입니다. 그리고 그 순간 우리는 추적이 필요하다는 것을 깨달았습니다. 제가 얘기했던 것과 동일한 OpenTracing이었습니다.

  우리는 XNUMX년 전에 이것을 생각하고 시장으로 관심을 돌렸고 거기에는 "Zipkin"과 "Jaeger"라는 두 가지 도구가 있었습니다. "Jager"는 실제로 "Zipkin"의 이념적 후계자이자 이념적 상속자입니다. 집계 방법을 모르고 추적에 로그를 포함하는 방법을 모르고 시간 추적만 한다는 점을 제외하면 Zipkin에서는 모든 것이 좋습니다. 그리고 'Jager'도 이를 지지했습니다.

  우리는 "Jager"를 살펴보았습니다. 애플리케이션을 계측할 수 있고 Api로 작성할 수 있습니다(당시 PHP용 Api 표준은 승인되지 않았습니다. 이는 XNUMX년 전이었지만 지금은 이미 승인되었습니다). 전혀 클라이언트가 아니 었습니다. “좋아요.” 우리는 생각하고 우리의 클라이언트를 작성했습니다. 우리는 무엇을 얻었나요? 대략적인 모습은 다음과 같습니다.

  
  
  Jaeger에서는 각 메시지에 대해 스팬이 생성됩니다. 즉, 사용자가 시스템을 열면 들어오는 요청마다 하나 또는 두 개의 블록이 표시됩니다(1-2-3 - 사용자로부터 들어오는 요청 수, 블록 수). 사용자가 더 쉽게 사용할 수 있도록 로그 및 시간 추적에 태그를 추가했습니다. 따라서 오류가 발생한 경우 애플리케이션은 적절한 오류 태그로 로그를 표시합니다. 오류 태그로 필터링할 수 있으며 오류가 있는 이 블록을 포함하는 범위만 표시됩니다. 범위를 확장하면 다음과 같습니다.

  
  
  범위 내부에는 일련의 추적이 있습니다. 이 경우에는 세 개의 테스트 추적이 있으며 세 번째 추적에서는 오류가 발생했음을 알려줍니다. 동시에 여기에는 시간 추적이 표시됩니다. 상단에는 시간 척도가 있고 이 로그 또는 해당 로그가 기록된 시간 간격을 볼 수 있습니다.

  따라서 우리에게는 모든 일이 순조롭게 진행되었습니다. 우리는 자체 확장 기능을 작성하고 이를 오픈 소스로 공개했습니다. 추적 작업을 하고 싶다면, PHP에서 “Jager”로 작업하고 싶다면 다음과 같이 사용을 환영하는 확장 기능이 있습니다.

  
  
  우리는 이 확장 기능을 가지고 있습니다. 이는 OpenTracing Api용 클라이언트이며 php 확장으로 만들어졌습니다. 즉, 이를 어셈블하고 시스템에 설치해야 합니다. XNUMX년 전과 별 다를 게 없었다. 이제 구성 요소와 유사한 다른 클라이언트가 있습니다. 여기서는 당신에게 달려 있습니다. 작곡가를 사용하여 구성 요소를 펌핑하거나 확장 기능을 사용할 수 있습니다.

  기업 표준

  우리는 세 계명에 관해 이야기했습니다. 넷째 계명은 접근 방식을 표준화하라는 것입니다. 이것은 무엇에 관한 것입니까? 내용은 다음과 같습니다.

  
  
  여기서 '기업'이라는 단어가 왜 나온 걸까요? 우리가 크거나 관료적인 회사이기 때문이 아닙니다. 나는 여기서 “기업”이라는 단어를 사용하고 싶었습니다. 여러분을 포함한 모든 회사, 모든 제품에는 고유한 표준이 있어야 한다는 의미입니다. 우리는 어떤 기준을 갖고 있나요?

  
  

  • 배포 규정이 있습니다. 그 사람 없이는 우리는 아무데도 움직일 수 없습니다. 우리는 일주일에 약 60번 정도 배포합니다. 즉, 거의 지속적으로 배포합니다. 동시에 배포 규정에는 금요일 배포에 대한 금기 사항이 있으며 원칙적으로 배포하지 않습니다.
  • 문서가 필요합니다. RnD 전문가의 손길로 탄생한 부품이라 할지라도 문서가 없으면 단 하나의 새로운 부품도 생산에 들어가지 않습니다. 우리는 배포 지침, 모니터링 맵, 그리고 이 구성 요소의 작동 방식과 문제 해결 방법에 대한 대략적인 설명(프로그래머가 작성할 수 있음)을 요구합니다.
  • 우리는 문제의 원인을 해결하는 것이 아니라 제가 이미 말한 문제를 해결합니다. 문제로부터 사용자를 보호하는 것이 중요합니다.
  • 허가가 있습니다. 예를 들어, 2분 이내에 트래픽의 XNUMX%가 손실된 경우에는 가동 중지 시간으로 간주하지 않습니다. 이는 기본적으로 통계에 포함되지 않습니다. 백분율로 더 많거나 일시적인 경우에는 이미 계산됩니다.
  • 그리고 우리는 항상 사후 분석을 작성합니다. 우리에게 무슨 일이 일어나든, 누군가가 생산 과정에서 비정상적으로 행동한 상황은 사후에 반영될 것입니다. 사후 분석은 자신에게 일어난 일, 상세한 시기, 이를 수정하기 위해 수행한 작업 및 향후 이러한 일이 발생하지 않도록 하기 위해 수행할 작업(필수 블록입니다!)을 기록하는 문서입니다. 이는 필수이며 후속 분석에 필요합니다.

  다운타임이란 무엇입니까?

  
  
  이 모든 것이 무엇으로 이어졌습니까?

  이로 인해 지난 6개월 동안 우리의 안정성 지표는 99,97이었습니다(우리는 안정성에 특정 문제가 있었고 이는 고객이나 우리 모두에게 적합하지 않았습니다). 이것은 그리 많지 않다고 말할 수 있습니다. 예, 우리는 노력해야 할 것이 있습니다. 이 지표 중 약 절반은 우리의 안정성이 아니라 우리 앞에 서서 서비스로 사용되는 웹 애플리케이션 방화벽의 안정성이지만 클라이언트는 이에 대해 신경 쓰지 않습니다.

  우리는 밤에 자는 법을 배웠습니다. 마지막으로! 2개월 전에는 그럴 수 없었습니다. 그리고 그 결과와 함께 이 메모에 대해 한 가지 메모를 하고 싶습니다. 어젯밤 원자로의 제어 시스템에 관한 훌륭한 보고서가 있었습니다. 이 시스템을 작성한 사람들이 제 말을 듣게 된다면 제가 "2%는 다운타임이 아닙니다"라고 했던 말은 잊어주세요. 여러분에게 있어 XNUMX%는 단 XNUMX분이라도 다운타임입니다!

  그게 다야! 당신의 질문.

  
  

  밸런서 및 데이터베이스 마이그레이션 정보

  청중의 질문(이하 – B): – 안녕하세요. 이러한 관리 보고서를 작성해 주셔서 대단히 감사합니다! 밸런서에 관한 짧은 질문입니다. WAF가 있다고 말씀하셨는데요. 즉, 제가 알기로 일종의 외부 밸런서를 사용하고 있는 것으로 알고 있습니다.

  EK: – 아니요, 우리는 서비스를 균형 조정자로 사용합니다. 이 경우 WAF는 독점적으로 DDoS 보호 도구입니다.

  에서 : – 밸런서에 대해 몇 마디 말씀해주실 수 있나요?

  EK: – 이미 말했듯이 이것은 openresty의 서버 그룹입니다. 이제 독점적으로 응답하는 5개의 예비 그룹이 있습니다. 즉, 독점적으로 openresty를 실행하는 서버는 트래픽만 프록시합니다. 따라서 우리가 보유하고 있는 양을 이해하려면 이제 수백 메가비트의 정기적인 트래픽 흐름이 있습니다. 그들은 대처하고 기분이 좋으며 심지어 긴장하지도 않습니다.

  에서 : – 또한 간단한 질문입니다. 블루/그린 배포는 다음과 같습니다. 예를 들어, 데이터베이스 마이그레이션으로 무엇을 합니까?

  EK: - 좋은 질문! Blue/Green 배포에서는 각 회선마다 별도의 대기열이 있습니다. 즉, 작업자에서 작업자로 전송되는 이벤트 대기열에 대해 이야기하는 경우 파란색 선과 녹색 선에 대한 별도의 대기열이 있습니다. 데이터베이스 자체에 대해 이야기하고 있다면 의도적으로 최대한 범위를 좁히고 모든 것을 실제로 대기열로 옮겼으며 데이터베이스에는 트랜잭션 스택만 저장합니다. 그리고 우리의 트랜잭션 스택은 모든 라인에서 동일합니다. 이 맥락에서 데이터베이스를 파란색과 녹색으로 나누지 않습니다. 두 버전의 코드 모두 트랜잭션에서 무슨 일이 일어나고 있는지 알아야 하기 때문입니다.

  친구 여러분, 여러분에게 격려를 드리고자 작은 상품인 책도 준비했습니다. 그리고 나는 최고의 질문으로 상을 받아야 합니다.

  에서 : - 안녕하세요. 신고해 주셔서 감사합니다. 질문은 이것이다. 결제를 모니터링하고 통신하는 서비스를 모니터링합니다... 하지만 어떤 사람이 어떻게든 결제 페이지에 와서 결제를 했고 프로젝트에서 그 사람에게 돈을 적립하도록 모니터링하려면 어떻게 해야 합니까? 즉, 행진곡이 사용 가능하고 콜백을 수락했는지 어떻게 모니터링합니까?

  EK: – 이 경우 "가맹점"은 결제 시스템과 정확히 동일한 외부 서비스입니다. 판매자의 응답 속도를 모니터링합니다.

  데이터베이스 암호화 정보

  에서 : - 안녕하세요. 약간 관련된 질문이 있습니다. PCI DSS에 민감한 데이터가 있습니다. 전송해야 하는 대기열에 PAN을 어떻게 저장하는지 알고 싶었습니다. 암호화를 사용하시나요? 이는 두 번째 질문으로 이어집니다. PCI DSS에 따르면 변경(관리자 해고 등) 시 데이터베이스를 주기적으로 다시 암호화해야 합니다. 이 경우 접근성은 어떻게 되나요?

  
  
  EK: - 멋진 질문이에요! 첫째, PAN을 대기열에 저장하지 않습니다. 우리는 원칙적으로 PAN을 명확한 형식으로 어디에나 저장할 수 있는 권한이 없으므로 특별한 서비스(우리는 "Kademon"이라고 함)를 사용합니다. 이 서비스는 단 한 가지 작업만 수행합니다. 즉, 메시지를 입력으로 받아 전송합니다. 암호화된 메시지를 내보냅니다. 그리고 우리는 이 암호화된 메시지와 함께 모든 것을 저장합니다. 따라서 우리의 키 길이는 XNUMX킬로바이트 미만이므로 이는 심각하고 신뢰할 수 있습니다.

  에서 : – 지금 2KB가 필요합니까?

  EK: - 엊그제 같은데 256이었는데... 그럼 또 어디?!

  따라서 이것이 첫 번째입니다. 둘째, 존재하는 솔루션은 재암호화 절차를 지원합니다. 두 쌍의 "kek"(키)가 있으며, 이는 암호화하는 "데크"를 제공합니다(키는 키이고 dek는 암호화하는 키의 파생물입니다). . 그리고 절차가 시작되면(3개월에서 ±일 정도로 정기적으로 발생) 새로운 "케이크" 쌍을 다운로드하고 데이터를 다시 암호화합니다. 우리는 모든 데이터를 추출하고 새로운 방식으로 암호화하는 별도의 서비스를 보유하고 있습니다. 데이터는 암호화된 키의 식별자 옆에 저장됩니다. 따라서 새 키로 데이터를 암호화하자마자 이전 키를 삭제합니다.

  때로는 수동으로 결제해야 하는 경우도 있습니다.

  에서 : – 즉, 일부 작업에 대한 환불이 이루어진 경우에도 이전 키를 사용하여 암호를 해독합니까?

  EK: - 네.

  에서 : – 그럼 작은 질문 하나 더. 어떤 종류의 실패, 추락 또는 사고가 발생하면 수동으로 트랜잭션을 푸시해야 합니다. 그런 상황이 있습니다.

  EK: - 네, 가끔요.

  에서 : – 이 데이터는 어디서 얻나요? 아니면 이 보관 시설에 직접 가시나요?

  EK: – 아니요, 물론 지원을 위한 인터페이스가 포함된 일종의 백오피스 시스템이 있습니다. 거래가 어떤 상태인지 알 수 없는 경우(예: 결제 시스템이 시간 초과로 응답할 때까지) 선험적으로 알 수 없습니다. 즉, 우리는 완전한 확신을 가지고 최종 상태만 할당합니다. 이 경우 수동 처리를 위해 거래를 특수 상태로 지정합니다. 다음날 아침, 지원팀은 이러한 거래가 결제 시스템에 남아 있다는 정보를 수신하자마자 이 인터페이스에서 수동으로 처리합니다.

  
  
  에서 : – 몇 가지 질문이 있습니다. 그 중 하나는 PCI DSS 영역의 연속입니다. 회로를 어떻게 기록합니까? 이 질문은 개발자가 로그에 무엇이든 넣을 수 있었기 때문입니다! 두 번째 질문: 핫픽스를 어떻게 출시합니까? 데이터베이스에서 핸들을 사용하는 것은 하나의 옵션이지만 무료 핫픽스가 있을 수 있습니다. 절차는 무엇입니까? 그리고 세 번째 질문은 아마도 RTO, RPO와 관련이 있을 것입니다. 가용성은 99,97(거의 XNUMX)이었지만 제가 이해한 바에 따르면 두 번째 데이터 센터, 세 번째 데이터 센터, 다섯 번째 데이터 센터가 있습니다. 이들을 어떻게 동기화하고 복제하며 기타 모든 것을 수행합니까?

  EK: - 첫 번째부터 시작해 보겠습니다. 첫 번째 질문은 로그에 관한 것이었나요? 로그를 작성할 때 모든 민감한 데이터를 마스킹하는 레이어가 있습니다. 그녀는 마스크와 추가 필드를 살펴봅니다. 따라서 우리 로그에는 이미 마스킹된 데이터와 PCI DSS 회로가 나와 있습니다. 이는 테스트 부서에 할당된 일반적인 작업 중 하나입니다. 자신이 작성한 로그를 포함하여 각 작업을 확인해야 하며 이는 개발자가 무언가를 기록하지 않았는지 제어하기 위해 코드 검토 중 일반적인 작업 중 하나입니다. 이에 대한 후속 점검은 정보 보안 부서에서 일주일에 한 번씩 정기적으로 수행됩니다. 마지막 날의 로그를 선택적으로 수집하고 테스트 서버의 특수 스캐너 분석기를 통해 실행하여 모든 것을 확인합니다.
  핫픽스 정보. 이는 배포 규정에 포함되어 있습니다. 핫픽스에 대한 별도의 조항이 있습니다. 우리는 필요할 때 XNUMX시간 내내 핫픽스를 배포한다고 믿습니다. 버전이 조립되자마자, 실행되자마자, 아티팩트가 생기자마자 지원팀의 전화를 받아 시스템 관리자가 근무하고 필요한 순간에 배포합니다.

  "포나인"에 대해. 우리가 지금 가지고 있는 수치는 진정으로 달성되었으며, 우리는 다른 데이터 센터에서 이를 달성하기 위해 노력했습니다. 이제 우리는 두 번째 데이터 센터를 갖게 되었고, 이들 사이에서 라우팅을 시작하고 있으며, 데이터 센터 간 복제 문제는 정말 중요한 질문입니다. 우리는 다른 수단을 사용하여 한 번에 문제를 해결하려고 시도했습니다. 동일한 "타란툴라"를 사용하려고 시도했지만 문제가 해결되지 않았으므로 즉시 말씀 드리겠습니다. 그래서 우리는 "sens"를 수동으로 주문하게 되었습니다. 실제로 우리 시스템의 각 애플리케이션은 데이터 센터 간에 필요한 "변경 완료" 동기화를 비동기식으로 실행합니다.

  에서 : - 두 번째는 받았는데 왜 세 번째는 안 받았나요? 아직 스플릿 브레인을 경험한 사람이 없기 때문에...

  EK: – 하지만 우리는 Split Brain이 없습니다. 각 애플리케이션이 멀티마스터에 의해 구동된다는 사실 때문에 요청이 어느 센터로 왔는지는 중요하지 않습니다. 우리는 데이터 센터 중 하나가 실패하고(우리는 이에 의존함) 사용자 요청 중에 두 번째 데이터 센터로 전환하는 경우 실제로 이 사용자를 잃을 준비가 되어 있습니다. 그러나 이것들은 단위, 절대 단위가 될 것입니다.

  에서 : - 좋은 저녁이에요. 신고해 주셔서 감사합니다. 프로덕션에서 일부 테스트 트랜잭션을 실행하는 디버거에 대해 이야기하셨습니다. 하지만 테스트 거래에 대해 알려주세요! 얼마나 깊이 들어가나요?

  EK: – 전체 구성요소의 전체 주기를 거칩니다. 구성 요소의 경우 테스트 트랜잭션과 생산 트랜잭션 간에 차이가 없습니다. 그러나 논리적인 관점에서 볼 때 이는 테스트 트랜잭션만 실행되는 시스템의 별도 프로젝트일 뿐입니다.

  에서 : -어디서 자르나요? 여기 코어가 보냈습니다...

  EK: – 이 경우 테스트 거래를 위해 "Kor" 뒤에 있습니다... 라우팅과 같은 것이 있습니다. "Kor"는 어떤 결제 시스템으로 보낼지 알고 있습니다. 우리는 단순히 http 신호를 제공하는 가짜 결제 시스템에 보냅니다. 그게 다야.

  에서 : – 귀하의 애플리케이션이 하나의 거대한 단일체로 작성되었는지, 아니면 일부 서비스 또는 마이크로서비스로 분할되었는지 알려주십시오.

  EK: – 물론 우리에게는 단일체가 없으며 서비스 지향 애플리케이션이 있습니다. 우리는 우리 서비스가 단일체로 구성되어 있다고 농담합니다. 그것들은 실제로 꽤 큽니다. 마이크로서비스라고 부르기는 어렵지만 분산된 기계의 작업자가 작동하는 서비스입니다.

  서버의 서비스가 손상된 경우...

  에서 : – 그럼 다음 질문이 있습니다. 단일체라 할지라도 여전히 이러한 인스턴트 서버가 많이 있고 기본적으로 모두 데이터를 처리한다고 말씀하셨습니다. 질문은 다음과 같습니다. “인스턴트 서버 중 하나나 애플리케이션이 손상되는 경우 개별 링크 , 일종의 액세스 제어 기능이 있나요? 그 중 누가 무엇을 할 수 있나요? 어떤 정보를 얻으려면 누구에게 연락해야 합니까?

  
  
  EK: - 네, 물론이죠. 보안 요구 사항은 매우 심각합니다. 첫째, 개방형 데이터 이동이 있으며 포트는 트래픽 이동을 미리 예상하는 포트일 뿐입니다. 구성 요소가 5-4-3-2를 통해 데이터베이스(예: Muskul 사용)와 통신하는 경우 5-4-3-2만 해당 구성 요소에 열려 있으며 다른 포트 및 기타 트래픽 방향은 사용할 수 없습니다. 또한 우리 프로덕션에는 약 10가지의 서로 다른 보안 루프가 있다는 점을 이해해야 합니다. 그리고 애플리케이션이 어떤 식으로든 손상되더라도 공격자는 서버 관리 콘솔에 액세스할 수 없습니다. 이는 다른 네트워크 보안 영역이기 때문입니다.

  에서 : – 그리고 이러한 맥락에서 나에게 더 흥미로운 점은 서비스와 특정 계약을 맺고 있다는 것입니다. 즉, 그들이 무엇을 할 수 있는지, 어떤 "작업"을 통해 서로 연락할 수 있는지... 그리고 일반적인 흐름에서 일부 특정 서비스는 일부 서비스를 요청합니다. 행, 다른 행에는 "작업" 목록이 있습니다. 그들은 정상적인 상황에서 다른 사람에게 의지하지 않는 것 같고, 다른 책임 영역이 있습니다. 그 중 하나가 손상되면 해당 서비스의 "작업"을 방해할 수 있습니까?..

  EK: - 이해합니다. 정상적인 상황에서 다른 서버와의 통신이 전혀 허용된다면 그렇습니다. SLA 계약에 따라 처음 3개의 "작업"만 허용되고 4개의 "작업"은 허용되지 않는지 모니터링하지 않습니다. 원칙적으로 회로에 대한 4단계 보호 시스템이 이미 있으므로 이는 아마도 중복될 것입니다. 우리는 내부 수준보다는 윤곽을 통해 자신을 방어하는 것을 선호합니다.

  Visa, MasterCard 및 Sberbank 작동 방식

  에서 : – 사용자를 한 데이터 센터에서 다른 데이터 센터로 전환하는 것에 대한 요점을 명확히 하고 싶습니다. 내가 아는 한 Visa와 MasterCard는 8583 바이너리 동기 프로토콜을 사용하여 작동하며 거기에 혼합이 있습니다. 그리고 저는 알고 싶었습니다. 이제 전환을 의미합니다. 바로 "Visa"와 "MasterCard"입니까 아니면 결제 시스템 이전입니까, 처리 전입니까?

  EK: - 믹스 전이에요. 우리 믹스는 동일한 데이터 센터에 있습니다.

  에서 : -대략적으로 연결점이 하나쯤 있나요?

  EK: – "Visa" 및 "MasterCard" - 예. 예를 들어 Visa와 MasterCard는 두 번째 믹스 쌍을 얻기 위해 별도의 계약을 체결하기 위해 인프라에 상당히 심각한 투자가 필요하기 때문입니다. 하나의 데이터 센터 내에 예약되어 있지만 Visa와 MasterCard에 연결하기 위한 혼합이 있는 데이터 센터가 죽으면 Visa 및 MasterCard와의 연결이 끊어집니다...

  에서 : – 어떻게 예약할 수 있나요? Visa는 원칙적으로 XNUMX개의 연결만 허용하는 것으로 알고 있습니다!

  EK: – 장비를 직접 공급합니다. 어쨌든 우리는 내부에 완전히 중복된 장비를 받았습니다.

  에서 : – 스탠드는 Connects Orange 제품인가요?..

  EK: - 네.

  에서 : – 하지만 이 경우는 어떻습니까? 데이터 센터가 사라진다면 어떻게 계속 사용할 수 있습니까? 아니면 교통이 그냥 멈추나요?

  EK: - 아니요. 이 경우 트래픽을 다른 채널로 간단히 전환하면 당연히 우리에게는 더 많은 비용이 들고 고객에게는 더 많은 비용이 듭니다. 그러나 트래픽은 Visa, MasterCard에 대한 직접 연결이 아니라 조건부 Sberbank(매우 과장됨)를 통해 전달됩니다.

  Sberbank 직원에게 불쾌감을 주었다면 진심으로 사과드립니다. 그러나 우리 통계에 따르면 러시아 은행 중에서 Sberbank가 가장 자주 하락했습니다. Sberbank에서는 한 달도 지나지 않아 무언가가 떨어지지 않습니다.

  
  
  

  일부 광고 🙂

  우리와 함께있어 주셔서 감사합니다. 우리 기사가 마음에 드십니까? 더 재미있는 콘텐츠를 보고 싶다면? 주문하거나 친구에게 추천하여 우리를 지원하십시오. $4.99부터 시작하는 개발자용 클라우드 VPS, 귀하를 위해 우리가 발명한 고유한 보급형 서버 아날로그: VPS(KVM) E5-2697 v3(6코어) 10GB DDR4 480GB SSD 1Gbps에 대한 전체 진실 또는 서버 공유 방법은? (RAID1 및 RAID10에서 사용 가능, 최대 24개 코어 및 최대 40GB DDR4).

  Dell R730xd는 암스테르담의 Equinix Tier IV 데이터 센터에서 2배 더 저렴합니까? 여기서 만 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199부터 네덜란드에서! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 최저 $99! 에 대해 읽다 인프라 공사를 구축하는 방법. 730페니에 5유로 상당의 Dell R2650xd E4-9000 vXNUMX 서버를 사용하는 클래스?

출처 : habr.com