이 문서에는 엔지니어가 수백만 명의 사용자가 액세스하는 대규모 서비스로 작업하는 데 도움이 되는 몇 가지 일반적인 패턴이 포함되어 있습니다.

저자의 경험에 따르면 이는 완전한 목록은 아니지만 실제로는 효과적인 조언. 그럼 시작해 보겠습니다.

지원을 받아 번역됨 Mail.ru 클라우드 솔루션.

첫 번째 수준

아래에 나열된 조치는 구현하기가 비교적 간단하지만 영향력이 높습니다. 이전에 시도해 본 적이 없다면 상당한 개선 사항에 놀랄 것입니다.

코드형 인프라

조언의 첫 번째 부분은 인프라를 코드로 구현하는 것입니다. 이는 전체 인프라를 배포하기 위한 프로그래밍 방식이 있어야 함을 의미합니다. 복잡해 보이지만 실제로는 다음 코드에 대해 이야기하고 있습니다.

100개의 가상 머신 배포

우분투와 함께

각각 2GB RAM

그들은 다음과 같은 코드를 갖게 될 것입니다

이 매개변수를 사용하면

버전 제어를 사용하면 인프라 변경 사항을 추적하고 신속하게 되돌릴 수 있습니다.

내 안의 현대주의자는 Kubernetes/Docker를 사용하여 위의 모든 작업을 수행할 수 있다고 말하며 그의 말이 맞습니다.

또한 Chef, Puppet 또는 Terraform을 사용하여 자동화를 제공할 수 있습니다.

지속적인 통합 및 제공

확장 가능한 서비스를 만들려면 각 끌어오기 요청에 대한 빌드 및 테스트 파이프라인을 보유하는 것이 중요합니다. 테스트가 매우 간단하더라도 최소한 배포하는 코드가 컴파일되는지 확인합니다.

이 단계에서 매번 다음 질문에 대답합니다. 내 어셈블리가 컴파일되고 테스트를 통과합니까? 유효합니까? 이는 낮은 기준처럼 보일 수 있지만 많은 문제를 해결합니다.

이 진드기를 보는 것보다 더 아름다운 것은 없습니다

이 기술의 경우 Github, CircleCI 또는 Jenkins를 평가할 수 있습니다.

로드 밸런서

따라서 로드 밸런서를 실행하여 트래픽을 리디렉션하고 모든 노드에 동일한 로드를 보장하거나 장애가 발생한 경우 서비스가 계속되도록 하려고 합니다.

로드 밸런서는 일반적으로 트래픽을 효과적으로 분산시킵니다. 가장 좋은 방법은 단일 실패 지점이 없도록 균형을 맞추는 것입니다.

일반적으로 로드 밸런서는 사용하는 클라우드에 구성됩니다.

요청에 대한 RayID, 상관 ID 또는 UUID

다음과 같은 메시지와 함께 애플리케이션 오류가 발생한 적이 있습니까? "뭔가 잘못됐어. 이 ID를 저장하고 지원팀에 보내세요."?

고유 식별자, 상관 ID, RayID 또는 기타 변형은 수명 주기 전반에 걸쳐 요청을 추적할 수 있는 고유 식별자입니다. 이를 통해 로그의 전체 요청 경로를 추적할 수 있습니다.

사용자가 시스템 A에 요청한 후 A가 B에 연락하고 B는 C에 연락하여 이를 X에 저장한 다음 요청을 A에 반환합니다.

가상 머신에 원격으로 연결하여 요청 경로를 추적하고 어떤 호출이 발생했는지 수동으로 연관시키려고 한다면 정말 정신이 없을 것입니다. 고유 식별자가 있으면 생활이 훨씬 쉬워집니다. 이는 서비스가 성장함에 따라 시간을 절약하기 위해 할 수 있는 가장 간단한 방법 중 하나입니다.

중급

여기에 있는 조언은 이전 조언보다 더 복잡하지만 올바른 도구를 사용하면 작업이 더 쉬워지고 중소기업에도 투자 수익을 얻을 수 있습니다.

중앙 집중식 로깅

축하해요! 100개의 가상 머신을 배포했습니다. 다음날 CEO가 찾아와 서비스 테스트 중 오류가 발생했다고 항의했다. 위에서 설명한 해당 ID를 보고하지만 충돌을 일으킨 컴퓨터를 찾으려면 100개 컴퓨터의 로그를 조사해야 합니다. 그리고 내일 발표 전에 찾아야 해요.

재미있는 모험처럼 들리겠지만 모든 잡지를 한 곳에서 검색할 수 있는지 확인하는 것이 가장 좋습니다. ELK 스택에 내장된 기능을 사용하여 로그를 중앙 집중화하는 문제를 해결했습니다. 검색 가능한 로그 수집을 지원합니다. 이는 특정 저널을 찾는 문제를 해결하는 데 큰 도움이 될 것입니다. 보너스로 차트나 기타 재미있는 것들을 만들 수 있습니다.

ELK 스택 기능

모니터링 에이전트

이제 서비스가 실행되고 있으므로 원활하게 실행되는지 확인해야 합니다. 이를 수행하는 가장 좋은 방법은 여러 개를 실행하는 것입니다. 자치령 대표, 병렬로 작동하여 작동하고 기본 작업이 수행되는지 확인합니다.

이 시점에서 다음 사항을 확인하세요. 실행 중인 빌드가 기분이 좋고 잘 작동합니다..

중소 규모 프로젝트의 경우 API 모니터링 및 문서화를 위해 Postman을 권장합니다. 그러나 일반적으로 가동 중단이 발생한 시기를 알 수 있고 적시에 알림을 받을 수 있는 방법이 있는지 확인하고 싶을 뿐입니다.

부하에 따른 자동 확장

매우 간단합니다. 요청을 처리하는 VM이 있고 메모리 사용량이 80%에 가까워지면 리소스를 늘리거나 클러스터에 VM을 더 추가할 수 있습니다. 이러한 작업의 자동 실행은 부하 시 탄성 전력 변화에 탁월합니다. 하지만 지출 금액에 대해 항상 주의를 기울이고 합리적인 한도를 설정해야 합니다.

대부분의 클라우드 서비스에서는 더 많은 서버 또는 더 강력한 서버를 사용하여 자동 확장되도록 구성할 수 있습니다.

실험 시스템

업데이트를 안전하게 출시하는 좋은 방법은 1%의 사용자를 대상으로 한 시간 동안 무언가를 테스트하는 것입니다. 물론 여러분은 그러한 메커니즘이 실제로 작동하는 것을 보았습니다. 예를 들어, Facebook은 사용자가 변화를 어떻게 인식하는지 확인하기 위해 청중의 일부를 다른 색상으로 표시하거나 글꼴 크기를 변경합니다. 이를 A/B 테스트라고 합니다.

새로운 기능을 출시하는 것조차 실험으로 시작한 다음 출시 방법을 결정할 수 있습니다. 또한 서비스 성능 저하를 일으키는 기능을 기반으로 즉시 구성을 "기억"하거나 변경할 수 있는 기능도 제공됩니다.

고급 수준

구현하기 매우 어려운 팁은 다음과 같습니다. 아마도 조금 더 많은 리소스가 필요할 것이므로 중소기업에서는 이를 관리하는 데 어려움을 겪을 것입니다.

블루-그린 배포

이것이 바로 제가 "얼랭(Erlang)" 전개 방식이라고 부르는 것입니다. Erlang은 전화 회사가 등장하면서 널리 사용되었습니다. 소프트스위치는 전화 통화를 라우팅하는 데 사용되기 시작했습니다. 이 스위치에 있는 소프트웨어의 주요 목적은 시스템 업그레이드 중에 통화가 중단되지 않도록 하는 것이었습니다. Erlang에는 이전 모듈을 충돌시키지 않고 새 모듈을 로드하는 좋은 방법이 있습니다.

이 단계는 로드 밸런서의 존재 여부에 따라 달라집니다. 소프트웨어 버전 N이 있고 버전 N+1을 배포하려고 한다고 가정해 보겠습니다.

당신 수 있었다 서비스를 중지하고 사용자에게 적합한 시간에 다음 버전을 출시하고 가동 중지 시간을 얻으세요. 하지만 당신이 가지고 있다고 가정 정말로 엄격한 SLA 조건. 따라서 SLA 99,99%는 오프라인으로 전환할 수 있음을 의미합니다. 만 연간 52분씩.

이러한 지표를 실제로 달성하려면 동시에 두 가지 배포가 필요합니다.

지금 있는 것(N);
다음 버전(N+1).

회귀를 적극적으로 모니터링하는 동안 트래픽의 일부를 새 버전(N+1)으로 리디렉션하도록 로드 밸런서에 지시합니다.

여기에는 잘 작동하는 녹색 N 배포가 있습니다. 이 배포의 다음 버전으로 이동하려고 합니다.

먼저 N+1 배포가 적은 양의 트래픽에서 작동하는지 확인하기 위해 아주 작은 테스트를 보냅니다.

마지막으로 배포가 완료될 때까지 최종적으로 실행하는 일련의 자동화된 검사가 있습니다. 만약 너라면 매우 매우 조심하세요. 회귀가 잘못된 경우 빠른 롤백을 위해 N 배포를 영원히 저장할 수도 있습니다.

더욱 고급 수준으로 이동하려면 청록색 배포의 모든 항목이 자동으로 실행되도록 하세요.

이상 탐지 및 자동 완화

중앙 집중식 로깅과 우수한 로그 수집을 고려하면 이미 더 높은 목표를 설정할 수 있습니다. 예를 들어, 오류를 사전에 예측합니다. 기능은 모니터와 로그에서 추적되고 다양한 다이어그램이 작성되며 무엇이 잘못될지 미리 예측할 수 있습니다.

이상이 감지되면 서비스가 제공하는 몇 가지 단서를 조사하기 시작합니다. 예를 들어, CPU 로드가 급증하면 하드 드라이브에 오류가 발생했다는 의미일 수 있고, 요청이 급증하면 확장이 필요하다는 의미일 수 있습니다. 이러한 종류의 통계 데이터를 통해 서비스를 능동적으로 만들 수 있습니다.

이러한 통찰력을 통해 모든 차원으로 확장하고 시스템, 데이터베이스, 연결 및 기타 리소스의 특성을 사전 및 사후 대응적으로 변경할 수 있습니다.

그게 다야!

이 우선순위 목록은 클라우드 서비스를 높이는 경우 많은 문제를 줄여줄 것입니다.

원본 기사의 저자는 독자들에게 의견을 남기고 변경하도록 요청합니다. 기사는 오픈 소스로 배포되며 작성자의 풀 요청 Github에서 수락.

주제에 대해 읽을 내용:

출처 : habr.com

클라우드 서비스가 있을 때 숙면을 취하는 방법: 기본 아키텍처 팁