안녕하세요! 제 이름은 Vadim Madison이고 Avito 시스템 플랫폼 개발을 이끌고 있습니다. 회사 내에서 모놀리식 아키텍처에서 마이크로서비스 아키텍처로 전환하는 방법이 여러 번 언급되었습니다. 이제 마이크로서비스를 최대한 활용하고 그 속에서 길을 잃지 않도록 인프라를 어떻게 변화시켰는지 공유할 시간입니다. 여기에서 PaaS가 어떻게 도움이 되는지, 배포를 단순화하고 마이크로서비스 생성을 클릭 한 번으로 줄이는 방법을 읽어보세요. 아래에 제가 쓴 모든 내용이 Avito에서 완전히 구현되는 것은 아니며, 그 중 일부는 플랫폼을 개발하는 방법입니다.

(그리고 이 기사 마지막 부분에서는 마이크로서비스 아키텍처 전문가 Chris Richardson의 XNUMX일간 세미나에 참석할 수 있는 기회에 대해 이야기하겠습니다.)

우리가 마이크로서비스에 도달한 방법

Avito는 세계에서 가장 큰 기밀 사이트 중 하나이며 매일 15만 개 이상의 새로운 광고가 게시됩니다. 우리 백엔드는 초당 20만 개가 넘는 요청을 받아들입니다. 현재 수백 개의 마이크로서비스가 있습니다.

우리는 수년 동안 마이크로서비스 아키텍처를 구축해 왔습니다. 정확히 어떻게 - 우리 동료들이 자세히 말한 RIT++ 2017 섹션에서. CodeFest 2017에서(참조: 비디오), Sergey Orlov와 Mikhail Prokopchuk은 마이크로서비스로의 전환이 필요한 이유와 여기에서 Kubernetes의 역할을 자세히 설명했습니다. 이제 우리는 그러한 아키텍처에 내재된 확장 비용을 최소화하기 위해 최선을 다하고 있습니다.

처음에 우리는 마이크로서비스를 개발하고 출시하는 데 포괄적으로 도움이 되는 생태계를 만들지 않았습니다. 그들은 합리적인 오픈 소스 솔루션을 모아서 집에서 출시하고 개발자를 초대하여 이를 처리했습니다. 그 결과 그는 XNUMX곳(대시보드, 내부 서비스)을 방문했고, 그 후 코드를 예전 방식으로 단일체로 잘라내려는 열망이 더욱 강해졌습니다. 아래 다이어그램의 녹색은 개발자가 자신의 손으로 어떤 식으로든 수행하는 작업을 나타내고 노란색은 자동화를 나타냅니다.

이제 PaaS CLI 유틸리티에서 하나의 명령으로 새 서비스가 생성되고, 두 개의 명령으로 새 데이터베이스가 추가되어 Stage에 배포됩니다.

'마이크로서비스 단편화' 시대를 극복하는 방법

모놀리식 아키텍처에서는 제품 변경의 일관성을 위해 개발자가 이웃에서 무슨 일이 일어나고 있는지 파악해야 했습니다. 새로운 아키텍처를 작업할 때 서비스 컨텍스트는 더 이상 서로 의존하지 않습니다.

또한 마이크로서비스 아키텍처가 효과적이려면 다음과 같은 많은 프로세스를 구축해야 합니다.

• 로깅;
• 요청 추적(Jaeger);
• 오류 집계(Sentry);
• Kubernetes의 상태, 메시지, 이벤트(이벤트 스트림 처리);
• 레이스 제한/서킷 브레이커(Hystrix를 사용할 수 있음);
• 서비스 연결 제어(Netramesh 사용)
• 모니터링(Grafana);
• 조립(TeamCity);
• 통신 및 알림(Slack, 이메일);
• 작업 추적; (지라)
• 문서 준비.

시스템의 무결성을 잃지 않고 확장에 따른 효율성을 유지하기 위해 우리는 Avito의 마이크로서비스 구성을 재고했습니다.

마이크로서비스를 관리하는 방법

다음은 많은 Avito 마이크로서비스 간에 통합된 "당사자 정책"을 구현하는 데 도움이 됩니다.

• 인프라를 여러 계층으로 나누는 것;
• PaaS(Platform as a Service) 개념;
• 마이크로서비스에서 일어나는 모든 일을 모니터링합니다.

인프라 추상화 계층에는 세 개의 계층이 포함됩니다. 위에서 아래로 가자.

A. 상단 - 서비스 메시. 처음에 Istio를 사용해 보았지만 너무 많은 리소스를 사용하여 볼륨에 비해 비용이 많이 드는 것으로 나타났습니다. 따라서 건축 팀 Alexander Lukyanchenko의 수석 엔지니어는 자신만의 솔루션을 개발했습니다. 네트라메시 (오픈 소스에서 사용 가능) 현재 프로덕션에서 사용하고 있으며 Istio보다 몇 배 더 적은 리소스를 소비합니다(그러나 Istio가 자랑할 수 있는 모든 작업을 수행하지는 않습니다).
B. 중간 - Kubernetes. 우리는 여기에 마이크로서비스를 배포하고 운영합니다.
C. 하단 - 베어메탈. 우리는 클라우드나 OpenStack 같은 것을 사용하지 않고 전적으로 베어메탈에 의존합니다.

모든 레이어는 PaaS로 결합됩니다. 그리고 이 플랫폼은 세 부분으로 구성됩니다.

I. 발전기, CLI 유틸리티를 통해 제어됩니다. 개발자가 올바른 방식으로 최소한의 노력으로 마이크로서비스를 만들 수 있도록 돕는 것은 바로 그녀입니다.

II. 통합 수집기 공통 대시보드를 통해 모든 도구를 제어할 수 있습니다.

III. 저장. 중요한 작업에 대한 트리거를 자동으로 설정하는 스케줄러와 연결됩니다. 이러한 시스템 덕분에 누군가가 Jira에서 작업 설정을 잊어버렸다고 해서 단 하나의 작업도 놓치지 않습니다. 이를 위해 Atlas라는 내부 도구를 사용합니다.

Avito의 마이크로서비스 구현은 개발 및 릴리스의 각 단계에서 마이크로서비스에 대한 제어를 단순화하는 단일 체계에 따라 수행됩니다.

표준 마이크로서비스 개발 파이프라인은 어떻게 작동하나요?

일반적으로 마이크로서비스 생성 체인은 다음과 같습니다.

CLI 푸시 → 지속적인 통합 → 굽기 → 배포 → 인공 테스트 → 카나리아 테스트 → 스퀴즈 테스트 → 생산 → 유지 관리.

정확히 이 순서대로 살펴보겠습니다.

CLI 푸시

• 마이크로서비스 생성.
우리는 모든 개발자에게 마이크로서비스 수행 방법을 가르치기 위해 오랫동안 노력했습니다. 여기에는 Confluence에 자세한 지침을 작성하는 것이 포함되었습니다. 그러나 계획이 변경되고 보완되었습니다. 그 결과 여정 초기에 병목 현상이 나타났습니다. 마이크로서비스를 시작하는 데 훨씬 더 많은 시간이 걸렸고 여전히 생성 중에 문제가 자주 발생했습니다.

결국 우리는 마이크로서비스를 생성할 때 기본 단계를 자동화하는 간단한 CLI 유틸리티를 구축했습니다. 실제로 이는 첫 번째 git push를 대체합니다. 그녀가 정확히 하는 일은 다음과 같습니다.

— "마법사" 모드에서 단계별로 템플릿에 따라 서비스를 생성합니다. Avito 백엔드에는 PHP, Golang 및 Python과 같은 주요 프로그래밍 언어에 대한 템플릿이 있습니다.

- 한 번에 하나의 명령으로 특정 시스템에 로컬 개발 환경을 배포합니다. - Minikube가 시작되고 Helm 차트가 자동으로 생성되어 로컬 kubernetes에서 시작됩니다.

— 필요한 데이터베이스를 연결합니다. 개발자는 로컬, 스테이지, 프로덕션 등 필요한 데이터베이스에 액세스하기 위해 IP, 로그인 및 비밀번호를 알 필요가 없습니다. 또한 데이터베이스는 내결함성 구성과 균형 조정을 통해 즉시 배포됩니다.

— 라이브 어셈블리 자체를 수행합니다. 개발자가 자신의 IDE를 통해 마이크로서비스에서 무언가를 수정했다고 가정해 보겠습니다. 유틸리티는 파일 시스템의 변경 사항을 확인하고 이를 기반으로 애플리케이션(Golang용)을 다시 빌드하고 다시 시작합니다. PHP의 경우 큐브 내부에 디렉터리를 전달하기만 하면 실시간 다시 로드가 "자동으로" 수행됩니다.

— 자동 테스트를 생성합니다. 공백 형태이지만 사용하기에 매우 적합합니다.

• 마이크로서비스 배포.

마이크로서비스를 배포하는 것은 우리에게 약간의 귀찮은 일이었습니다. 다음이 필요했습니다.

I. 도커파일.

II. 구성.
III. Helm 차트는 그 자체로 복잡하며 다음을 포함합니다.

- 차트 자체
— 템플릿;
— 다양한 환경을 고려한 특정 값.

Kubernetes 매니페스트를 재작업하는 수고를 덜어 이제 자동으로 생성됩니다. 그러나 가장 중요한 것은 배포를 최대한 단순화했다는 것입니다. 이제부터 Dockerfile이 있고 개발자는 하나의 짧은 app.toml 파일에 전체 구성을 작성합니다.

네, app.toml 자체에서는 잠시 동안 할 일이 없습니다. 발생시킬 서비스 복사본의 위치와 수(개발 서버, 준비 단계, 프로덕션 단계)를 지정하고 해당 종속성을 표시합니다. [engine] 블록에서 줄 크기 = "small"을 확인하세요. 이는 Kubernetes를 통해 서비스에 할당되는 한도입니다.

그런 다음 구성에 따라 필요한 모든 Helm 차트가 자동으로 생성되고 데이터베이스에 대한 연결이 생성됩니다.

• 기본 검증. 이러한 검사도 자동화됩니다.
추적해야 할 사항:
— Dockerfile이 있습니까?
— app.toml이 있습니까?
— 사용 가능한 문서가 있나요?
— 종속성이 올바른가요?
— 경고 규칙이 설정되었는지 여부.
마지막으로, 서비스 소유자는 모니터링할 제품 측정항목을 직접 결정합니다.

• 문서 준비.
여전히 문제가 있는 영역입니다. 가장 명백한 것처럼 보이지만 동시에 "자주 잊혀지는" 기록이기도 하므로 체인의 취약한 연결고리이기도 합니다.
각 마이크로서비스에 대한 문서가 필요합니다. 여기에는 다음 블록이 포함됩니다.

I. 서비스에 대한 간략한 설명. 말 그대로 이 기능이 무엇인지, 왜 필요한지에 대한 몇 문장입니다.

II. 아키텍처 다이어그램 링크. 예를 들어 캐싱을 위해 Redis를 사용하는지, 지속 모드에서 기본 데이터 저장소로 사용하는지 등을 한눈에 쉽게 이해하는 것이 중요합니다. 현재 Avito에서는 Confluence에 대한 링크입니다.

III. 런북. 서비스 시작과 서비스 처리의 복잡성에 대한 간단한 안내서입니다.

IV. 자주하는 질문, 동료가 서비스 작업 시 직면할 수 있는 문제를 예상하는 것이 좋습니다.

V. API 엔드포인트에 대한 설명. 갑자기 목적지를 지정하지 않으면 귀하와 관련된 마이크로서비스를 담당하는 동료가 그에 대한 비용을 거의 확실히 지불할 것입니다. 이제 이를 위해 Swagger와 Brief라는 솔루션을 사용합니다.

XNUMX. 라벨. 또는 해당 서비스가 속한 회사의 제품, 기능 또는 구조적 부서를 표시하는 표식입니다. 예를 들어 동료가 일주일 전에 동일한 사업부에 출시한 기능을 제거하고 있는지 여부 등을 빠르게 이해하는 데 도움이 됩니다.

Ⅶ. 서비스 소유자 또는 소유자. 대부분의 경우 PaaS를 사용하여 자동으로 결정할 수 있지만, 안전을 위해 개발자가 수동으로 지정해야 합니다.

마지막으로, 코드 검토와 유사하게 문서를 검토하는 것이 좋습니다.

지속적인 통합

• 저장소를 준비 중입니다.
• TeamCity에서 파이프라인을 생성합니다.
• 권한 설정.
• 서비스 소유자를 검색합니다. 여기에는 PaaS의 수동 표시와 최소한의 자동화라는 하이브리드 체계가 있습니다. 지원을 위해 서비스가 다른 개발 팀으로 이전되거나, 예를 들어 서비스 개발자가 그만둔 경우 완전 자동 체계는 실패합니다.
• Atlas에 서비스 등록 (위 참조). 모든 소유자와 종속성을 포함합니다.
• 마이그레이션을 확인 중입니다. 우리는 그 중 잠재적으로 위험한 것이 있는지 확인합니다. 예를 들어, 그 중 하나에서 다른 서비스 버전 간의 데이터 스키마 호환성을 깨뜨릴 수 있는 변경 테이블이나 기타 항목이 나타납니다. 그런 다음 마이그레이션이 수행되지 않고 구독에 배치됩니다. PaaS는 사용이 안전할 때 서비스 소유자에게 신호를 보내야 합니다.

빵 굽기

다음 단계는 배포 전 서비스 패키징입니다.

• 애플리케이션을 구축합니다. 고전에 따르면 - Docker 이미지에서.
• 서비스 자체 및 관련 리소스에 대한 Helm 차트 생성 데이터베이스 및 캐시를 포함합니다. CLI 푸시 단계에서 생성된 app.toml 구성에 따라 자동으로 생성됩니다.
• 관리자가 포트를 열 수 있는 티켓 만들기 (필요한 경우).
• 단위 테스트 실행 및 코드 적용 범위 계산. 코드 적용 범위가 지정된 임계값보다 낮으면 서비스가 더 이상 배포되지 않을 가능성이 높습니다. 허용 가능한 수준에 도달하면 서비스에 "비관적" 계수가 할당됩니다. 그런 다음 시간이 지나도 지표가 개선되지 않으면 개발자는 테스트 측면에서 진전이 없다는 알림을 받게 됩니다( 이에 대해 뭔가 조치를 취해야 합니다).
• 메모리 및 CPU 제한 고려. 우리는 주로 Golang으로 마이크로서비스를 작성하고 Kubernetes에서 실행합니다. 따라서 Golang 언어의 특성과 관련된 한 가지 미묘함: 기본적으로 시작 시 GOMAXPROCS 변수를 명시적으로 설정하지 않은 경우 시스템의 모든 코어가 사용되며 이러한 서비스가 동일한 시스템에서 여러 개 시작되면 시작됩니다. 자원을 놓고 경쟁하며 서로 간섭합니다. 아래 그래프는 경합 없이 리소스 경쟁 모드에서 애플리케이션을 실행할 경우 실행 시간이 어떻게 변하는 지 보여줍니다. (그래프 출처는 여기에).

실행 시간은 적을수록 좋습니다. 최대: 643ms, 최소: 42ms. 사진은 클릭 가능합니다.

수술 시간은 적을수록 좋습니다. 최대: 14091ns, 최소: 151ns. 사진은 클릭 가능합니다.

어셈블리 준비 단계에서 이 변수를 명시적으로 설정하거나 라이브러리를 사용할 수 있습니다. 자동 최대 프로시저 Uber 직원들로부터요.

배포

• 규칙을 확인합니다. 의도한 환경에 서비스 어셈블리 제공을 시작하기 전에 다음 사항을 확인해야 합니다.
- API 엔드포인트.
— API 엔드포인트 응답이 스키마를 준수합니다.
— 로그 형식.
— 서비스 요청에 대한 헤더 설정(현재는 netramesh에 의해 수행됨)
— 이벤트 버스에 메시지를 보낼 때 소유자 토큰을 설정합니다. 이는 버스 전체의 서비스 연결을 추적하는 데 필요합니다. 서비스 연결을 증가시키지 않는 멱등성 데이터(좋은 점)와 서비스 연결을 강화하는 비즈니스 데이터(매우 나쁜 점)를 모두 버스로 보낼 수 있습니다. 그리고 이 연결성이 문제가 되는 시점에 누가 버스를 쓰고 읽는지 이해하면 서비스를 적절하게 분리하는 데 도움이 됩니다.

아직 Avito에는 컨벤션이 많지 않지만 풀은 확장되고 있습니다. 팀이 이해하고 이해할 수 있는 형태로 그러한 계약이 더 많이 제공될수록 마이크로서비스 간의 일관성을 유지하는 것이 더 쉬워집니다.

합성 테스트

• 폐쇄 루프 테스트. 이를 위해 우리는 이제 오픈 소스를 사용하고 있습니다. Hoverfly.io. 먼저 서비스의 실제 로드를 기록한 다음 폐쇄 루프에서 이를 에뮬레이트합니다.

• 스트레스 테스트. 우리는 모든 서비스를 최적의 성능으로 제공하려고 노력합니다. 그리고 각 서비스의 모든 버전은 로드 테스트를 거쳐야 합니다. 이를 통해 우리는 서비스의 현재 성능과 동일한 서비스의 이전 버전과의 차이점을 이해할 수 있습니다. 서비스 업데이트 후 성능이 XNUMX배 감소했다면 이는 소유자에게 분명한 신호입니다. 코드를 자세히 살펴보고 상황을 수정해야 합니다.
예를 들어 우리는 수집된 데이터를 사용하여 Auto Scaling을 올바르게 구현하고 결국 서비스의 확장성을 전반적으로 이해합니다.

부하 테스트 중에 리소스 소비가 설정된 한도를 충족하는지 확인합니다. 그리고 우리는 주로 극단적인 것에 초점을 맞춥니다.

a) 총 부하를 살펴봅니다.
- 너무 작음 - 부하가 갑자기 여러 번 떨어지면 무언가가 전혀 작동하지 않을 가능성이 높습니다.
- 너무 크면 최적화가 필요합니다.

b) RPS에 따른 컷오프를 살펴봅니다.
여기서는 현재 버전과 이전 버전의 차이와 총 수량을 살펴보겠습니다. 예를 들어, 서비스가 100rps를 생성한다면 서비스가 제대로 작성되지 않았거나 이것이 특이성이지만 어쨌든 이는 서비스를 매우 면밀히 살펴봐야 하는 이유입니다.
반대로 RPS가 너무 많으면 일종의 버그가 있어서 일부 엔드포인트가 페이로드 실행을 중지했지만 다른 엔드포인트는 단순히 트리거되었을 수 있습니다. return true;

카나리아 테스트

합성 테스트를 통과한 후 소수의 사용자를 대상으로 마이크로서비스를 테스트합니다. 우리는 서비스의 대상 고객 중 0,1% 미만의 작은 부분부터 신중하게 시작합니다. 이 단계에서는 가능한 한 빨리 서비스의 문제를 보여줄 수 있도록 올바른 기술 및 제품 지표가 모니터링에 포함되는 것이 매우 중요합니다. 카나리아 테스트의 최소 시간은 5분이고, 기본 테스트 시간은 2시간입니다. 복잡한 서비스의 경우 시간을 수동으로 설정합니다.
우리는 분석합니다 :
— 언어별 측정항목, 특히 php-fpm 작업자;
— Sentry의 오류;
- 응답 상태
- 응답 시간, 정확하고 평균적인 응답 시간;
- 지연 시간;
— 예외, 처리 및 처리되지 않음
— 제품 지표.

압착 테스트

스퀴즈 테스트는 "스퀴징" 테스트라고도 합니다. 이 기술의 이름은 Netflix에 도입되었습니다. 그 본질은 먼저 하나의 인스턴스를 실패 지점까지 실제 트래픽으로 채우고 제한을 설정하는 것입니다. 그런 다음 다른 인스턴스를 추가하고 이 쌍을 다시 최대값까지 로드합니다. 첫 번째 "압착"으로 천장과 델타를 볼 수 있습니다. 그래서 우리는 한 번에 하나의 인스턴스를 연결하고 변화 패턴을 계산합니다.
"압착"을 통한 테스트 데이터는 공통 메트릭 데이터베이스로 흘러 들어가 인공 로드 결과를 강화하거나 "합성"을 대체할 수도 있습니다.

생산

• 확장. 서비스를 프로덕션 환경으로 출시할 때 규모가 어떻게 확장되는지 모니터링합니다. 경험상 CPU 표시기만 모니터링하는 것은 효과적이지 않습니다. 순수한 형태의 RPS 벤치마킹을 사용한 자동 크기 조정은 작동하지만 온라인 스트리밍과 같은 특정 서비스에만 해당됩니다. 따라서 먼저 애플리케이션별 제품 지표를 살펴보겠습니다.

결과적으로 우리는 확장 시 다음을 분석합니다.
- CPU 및 RAM 표시기,
— 대기열에 있는 요청 수
- 응답 시간,
— 축적된 과거 데이터를 기반으로 예측합니다.

서비스를 확장할 때 체인의 첫 번째 서비스를 확장하지 않고 액세스하는 서비스가 로드 시 실패하지 않도록 종속성을 모니터링하는 것도 중요합니다. 전체 서비스 풀에 대해 허용 가능한 로드를 설정하기 위해 "가장 가까운" 종속 서비스의 기록 데이터(CPU 및 RAM 표시기 조합과 앱별 측정항목을 기반으로 함)를 살펴보고 이를 기록 데이터와 비교합니다. 초기화 서비스 등 "종속성 체인" 전반에 걸쳐 위에서 아래로 진행됩니다.

Обслуживание

마이크로서비스가 작동되면 트리거를 연결할 수 있습니다.

트리거가 발생하는 일반적인 상황은 다음과 같습니다.
— 잠재적으로 위험한 마이그레이션이 감지되었습니다.
— 보안 업데이트가 출시되었습니다.
— 서비스 자체가 오랫동안 업데이트되지 않았습니다.
— 서비스 부하가 눈에 띄게 감소했거나 일부 제품 지표가 정상 범위를 벗어났습니다.
— 서비스가 더 이상 새로운 플랫폼 요구 사항을 충족하지 않습니다.

일부 트리거는 운영 안정성을 담당하고, 일부는 시스템 유지 관리의 기능으로, 예를 들어 일부 서비스가 오랫동안 배포되지 않았고 해당 기본 이미지가 보안 검사를 통과하지 못했습니다.

계기반

간단히 말해서 대시보드는 전체 PaaS의 제어판입니다.

• 테스트 범위, 이미지 수, 프로덕션 사본 수, 버전 등에 대한 데이터가 포함된 서비스에 대한 단일 정보 지점입니다.
• 서비스 및 라벨(사업부 소속 표시, 제품 기능 등)별로 데이터를 필터링하는 도구입니다.
• 추적, 로깅, 모니터링을 위한 인프라 도구와 통합하기 위한 도구입니다.
• 단일 지점의 서비스 문서입니다.
• 서비스 전체의 모든 이벤트를 단일 관점에서 볼 수 있습니다.

전체로

PaaS를 도입하기 전에 새로운 개발자는 Kubernetes, Helm, 내부 TeamCity 기능, 내결함성 방식으로 데이터베이스 및 캐시에 대한 연결 설정 등 프로덕션에서 마이크로서비스를 시작하는 데 필요한 모든 도구를 이해하는 데 몇 주를 보낼 수 있었습니다. 빠른 시작을 읽고 서비스 자체를 만드는 데 몇 시간이 걸립니다.

저는 HighLoad++ 2018에서 이 주제에 대한 보고서를 제출했습니다. 시청하실 수 있습니다. 비디오 и 발표.

끝까지 읽어주신 분들을 위한 보너스 트랙

Avito에서는 개발자를 대상으로 XNUMX일간의 내부 교육을 조직하고 있습니다. 크리스 리처드슨, 마이크로서비스 아키텍처 전문가입니다. 이 게시물을 읽는 독자 중 한 분에게 참여할 기회를 드리고 싶습니다. 여기에 교육프로그램이 게시되었습니다.

훈련은 5월 7일부터 XNUMX일까지 모스크바에서 진행된다. 이는 완전히 채워지는 근무일입니다. 점심 및 교육은 사무실에서 진행되며, 선정된 참가자는 교통비와 숙박비를 직접 지불합니다.

참가신청을 할 수 있습니다 이 구글폼으로. 귀하로부터 - 교육에 참석해야 하는 이유에 대한 질문에 대한 답변과 귀하에게 연락하는 방법에 대한 정보입니다. Chris가 교육에 참석할 참가자를 직접 선택하므로 영어로 대답하세요.
이 게시물 업데이트와 개발자용 소셜 네트워크 Avito(AvitoTech in Фейсбуке, Vkontakte, 트위터) 늦어도 19월 XNUMX일까지.

출처 : habr.com