첫 번째 요점: 아키텍처 독립성
모든 아키텍처는 특정 비즈니스 요구 사항을 충족하기 위해 만들어집니다. 비즈니스 요구 사항을 충족하면서 운영 차원의 아키텍처 관리에 대한 비기능적 요구 사항을 동시에 충족할 수 있습니까? 그렇다면 우리는 이런 구조가 운비에 유리하다고 생각할 이유가 있다.
운영 차원의 관점에서 필요한 아키텍처 독립성은 독립 배포, 독립 테스트, 구성 요소 및 기술 디커플링의 네 가지 측면을 포함합니다.
독립 배포
소스 코드를 가리키며 배포, 업그레이드, 확장 등을 할 수 있습니다. 관리 요구 사항에 따라 운영 및 유지 관리가 용이하며 지리적 분포를 구분하여 구성할 수 있습니다. 서비스 간의 상호 호출은 인터페이스 요청을 통해 이루어지며, 배포 독립도 운영 차원의 독립을 위한 전제 조건입니다.
독립 테스트
운영 유지 보수는 몇 가지 편리한 테스트 사례나 도구를 통해 비즈니스 아키텍처 또는 서비스의 가용성을 검증할 수 있습니다. 이러한 기능을 갖춘 비즈니스 아키텍처 또는 서비스를 통해 개발자나 테스터의 참여 없이 운영 및 유지 관리를 독립적으로 온라인 상태로 전환할 수 있습니다.
부품 사양
즉, 동일한 회사 내에서 관련 기술에 대한 프레임워크 지원이 잘 이루어지므로 서로 다른 개발 팀이 서로 다른 기술 스택이나 구성 요소를 사용하지 못하도록 하여 사내 기술 아키텍처를 통제할 수 없게 됩니다.
이러한 접근 방식은 운영 및 유지 관리 객체의 무질서한 증가를 제한하고 운영 환경에 대한 운영 및 유지 관리를 유지할 수 있습니다. 동시에, 운영 및 유지 보수는 표준 구성 요소를 중심으로 더 효율적이고 효율적인 건설 작업에 더 많은 에너지를 집중할 수 있습니다.
기술 탈착
서비스 간의 상호 의존성을 줄이는 것과 구성 파일에 대한 코드 의존도를 줄이는 것을 의미합니다. 마이크로서비스, 독립 배포, 독립 테스트, 구성 요소의 기초이기도 합니다.
두 번째 요점: 친숙한 배포
DevOps 는 개발, 테스트, 운영 및 유지 보수의 모든 기술 측면을 처음부터 끝까지 열어 신속한 배포 및 가치 제공을 위한 지속적인 제공 기술 관행에 대해 많은 지면을 가지고 있습니다. 배치는 일상적인 운영 및 유지 보수 작업에서 매우 중요한 부분이며 계획 작업에 속하며 반복도가 높기 때문에 효율성을 높여야 한다는 것을 알 수 있습니다.
효율적이고 신뢰할 수 있는 배포 기능을 실현하려면 배포 및 운영 단계에 대한 종합적인 운영 및 유지 관리 제어를 보장하기 위한 종합적인 계획이 필요합니다. 배포 선호도와 관련된 내용은 다음과 같은 5 가지 위도가 있습니다.
CMDB 구성
운영 및 유지 관리 부서는 각 구축 작업을 수행하기 전에 전체 작업 로드와 잠재적 위험을 더 잘 이해하고 평가할 수 있도록 애플리케이션과 아키텍처 및 비즈니스 간의 관계를 명확하게 파악해야 합니다.
지적 클라우드 자동화 운영 및 유지 보수 플랫폼에서는 비즈니스 관계, 클러스터 관리, 운영 상태, 중요도 수준, 아키텍처 계층 등의 구성 정보를 CMDB 구성 관리 데이터베이스에서 운영 차원의 관리 객체로 관리하는 데 익숙합니다. 이런 관리 방식의 장점은 분명하다. 운영 및 유지 보수 객체에 대한 구성 정보를 중앙에서 저장하면 향후 운영, 모니터링 및 알림 자동화 기능 구축을 위한 광범위한 구성 데이터 지원 및 의사 결정 지원이 제공됩니다.
환경 구성
운영 및 유지 보수 표준화가 낮은 기업에서 배포 전달 효율성을 저해하는 원죄 중 하나는 환경구성이며, 이는 컨테이너화 기술이 주로 해결하고자 하는 운영 및 유지 관리의 문제점 중 하나입니다.
Tencent 의 운영 및 유지 보수 실습에서는 환경 및 운영 및 유지 보수 작업과 관련된 리소스 집합을 열거하여 자동 초기화 도구와 결합하여 개발, 테스트 및 생산의 세 가지 주요 환경을 표준화합니다.
의존성 관리
라이브러리 및 운영 환경에 대한 애플리케이션 소프트웨어 종속성 관리를 해결합니다. 클라우드를 짜는 실무 경험에서 라이브러리 파일 또는 환경에 의존하는 구성을 하나로 패키지화하여 스크립트를 앞뒤로 실행하여 패키지 관리를 통해 다양한 환경에서 애플리케이션 배포 문제를 해결합니다. 업계에는 비교적 가벼운 컨테이너화 배송 방식이 있어 좋은 선택이다.
배포 모드
지속적인 제공의 원칙은 신뢰할 수 있고 반복 가능한 전달 경로를 구축하는 것을 의미하며, 이를 바탕으로 애플리케이션 배포를 강력하게 계획하고 있습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 성공명언) Docker 의 Build, Ship, Run 과 같은 업계 내 많은 사례를 참조할 수 있습니다. 예를 들어, 직조 클라우드에 대한 설명 구성, 프로세스 표준화를 통한 원클릭 배포 등이 있습니다.
자체 테스트를 게시하다
자체 테스트 게시는 다음 두 부분으로 구성됩니다.
응용 프로그램에 대한 경량 테스트
출판/변경 내용의 교정.
서로 다른 운영 및 유지 관리 시나리오의 요구를 충족하기 위해 이 두 가지 기능을 구축합니다. 예를 들어 증분 게시의 경우 운영자는 변경 파일 MD5 를 빠르게 얻거나 관련 프로세스와 포트를 비교하는 구성 정보를 확인하여 각 게시 변경 사항의 신뢰성을 보장할 수 있습니다.
마찬가지로 경량 테스트는 출시 시 서비스 가용성 테스트의 요구 사항을 충족하기 위한 것입니다. 이 단계에서는 서비스의 연결을 감지하고 일부 백본 테스트 사용 사례를 실행할 수 있습니다.
회색 온라인
"일상적인 운영 유지 보수 36 계" 에는 되돌릴 수 없는 삭제 또는 수정에 대해 가능한 한 집행을 연기하거나 늦추는 말이 있다. 이것이 바로 그레이스케일의 사상이다. 사용자, 시간, 서버 등의 위도에서 회색조를 막론하고 온라인 운영의 위험을 최소화하고자 합니다. 비즈니스 아키텍처는 그레이스케일 게시를 지원하여 응용 프로그램 배포 중 위험을 줄이고 운영 및 유지 보수에 더욱 친숙합니다.
세 번째 요점: 조작성
운비의 마음속에서 가장 이상적인 마이크로서비스 아키텍처는 분명 운유지가 강한 그런 것이다. (윌리엄 셰익스피어, 윈스턴, 희망명언) 조작성이 없는 응용이나 구조는 운비팀에 욕설을 줄 뿐만 아니라 그들의 직업 발전을 깊이 해치고 있다. 운영성이 없는 구조를 유지하는 것은 근본적으로 운비원의 생명을 낭비하는 것이기 때문이다. (윌리엄 셰익스피어, 윈스턴, 운영명언) (윌리엄 셰익스피어, 운영명언)
운영 사양 및 관리 사양에 따라 운영 가능성은 다음 7 가지로 요약할 수 있습니다.
구조관리
마이크로서비스 아키텍처 관리에서 Dell 은 독립적으로 배포할 수 있도록 구성 관리에서 애플리케이션 바이너리를 분리할 것을 제안했습니다.
독립 실행형 애플리케이션 구성의 경우 다음과 같은 세 가지 관리 방법이 있습니다.
파일 모드
구성 항목 모드
분산 구성 센터 모드.
편폭의 제한으로, 우리는 위의 세 가지 방법의 장단점을 토론하지 않는다. 기업마다 가장 적합한 구성 관리 방법을 선택할 수 있습니다. 핵심은 모든 비즈니스에서 일관된 시나리오를 사용해야 운영 유지 관리가 구성 관리 도구와 시스템을 구축할 수 있다는 것입니다.
버전 관리
DevOps, 연속 제공의 8 가지 원칙 중 하나인 "모든 것을 버전 관리 하에 배치". 운수 대상의 경우 관리를 잘하려면 반드시 명확하게 묘사할 수 있어야 한다.
소스 코드 관리의 요구 사항과 마찬가지로, 운영 서비스는 운영 시스템이 자동화 작업을 완료할 때 운영 객체와 버전을 정확하게 선택할 수 있도록 패키지, 구성, 스크립트 등과 같은 일상적인 운영 객체를 스크립팅해야 합니다.
표준조작
일상적인 운영 및 유지 보수에는 많은 반복적 인 작업이 있습니다. 린 (Lean) 사고의 관점에서 볼 때 학습 비용, 무가치한 운영, 불필요한 스크립트/도구, 인위적인 실행의 위험 등 큰 낭비가 있습니다.
파일 전송, 원격 실행, 애플리케이션 시작 및 중지와 같은 기업 내에서 일관된 운영 기준을 형성할 수 있는 경우 표준화, 중앙 집중화, 원클릭 운영으로 운영 효율성과 품질이 크게 향상됩니다.
프로세스 관리
애플리케이션 설치 경로, 디렉토리 구조, 사양 프로세스 이름, 사양 포트 번호, 시작 및 종료 모드, 모니터링 체계 등이 포함됩니다. , 프로세스 관리의 범주에 속합니다. 프로세스 관리에 대한 글로벌 계획을 잘 세우면 자동화된 운영 및 유지 보수 수준을 크게 향상시키고 예상치 못한 작업의 발생을 줄일 수 있습니다.
공간 관리
디스크 공간 사용 관리를 잘하는 것은 비즈니스 데이터를 질서 있게 저장하고 예상치 못한 작업의 발생을 줄이는 효과적인 수단이다.
백업 전략, 스토리지 시나리오, 용량 경고, 정리 전략 등 미리 계획을 세워야 합니다. , 효과적인 도구를 보완하여 이러한 작업들이 더 이상 운영에 지장을 주지 않도록 한다.
로그 관리
로그 사양의 구현 및 실행에는 R&D 의 긴밀한 협조가 필요하며, 실제로 얻은 경험과 이상적인 운영 차원의 로그 사양에는 다음과 같은 요구 사항이 포함되어야 합니다.
업무 데이터는 로그에서 분리됩니다.
로그는 비즈니스 논리와 분리되어 있습니다.
통합 로그 형식
반환 코드와 주석이 매우 명확하다
가용 업무 척도 (요청 수량/성공률/지연)
주요 이벤트 정의
출력 수준
관리 시나리오 (백업 시간, 압축 백업 등). ) 을 참조하십시오
이러한 조건에 대한 로그 사양을 구현할 수 있는 경우 개발, 운영 및 유지 관리를 통해 모니터링 및 분석 기능이 향상됩니다.
중앙 집중식 제어
운영 및 유지 보수 작업은 원래 변경 사항 게시, 모니터링 분석, 문제 해결, 프로젝트 지원, 흐린 관리 등과 같은 여러 부분으로 쉽게 나뉩니다. Dell 은 모든 업무 정보를 연결하고 전달할 수 있는 원스톱 운영 및 유지 관리 플랫폼을 구축하여 고립된 정보 또는 수동 정보 전달로 인한 운영 위험을 제거하고 전체 운영 및 유지 관리의 효율성과 품질을 향상시킬 것을 촉구합니다.
네 번째 요점: 내결함성과 재해 복구
텐센트 기술 운영 (운영 유지) 의 네 가지 책임: 품질, 효율성, 비용, 안전 품질은 보증의 1 위이다. 아키텍처 관점에서 볼 때 운영 및 유지 보수에 이상적인 고가용성 아키텍처 설계에는 다음 사항이 포함되어야 합니다.
로드 밸런싱
소프트웨어든 하드웨어든 균형 잡힌 솔루션이든, 운영 차원의 관점에서 우리는 항상 비즈니스 아키텍처가 무상태형, 라우팅 주소 지정 인텔리전스, 클러스터 내결함성이 자동으로 실현되기를 원합니다.
텐센트 라우팅 소프트웨어의 여러 해 동안 소프트웨어 로드 밸런싱 방안이 광범위하게 적용되어 비즈니스 아키텍처의 고가용성 실현에 큰 기여를 했습니다.
스케줄링 가능성
모바일 인터넷 시대에 스케줄링성은 재해 복구 내결함성이 매우 중요한 운영 수단이다. 업무에 즉시 해결할 수 없는 장애가 발생할 경우 사용자 또는 서비스를 예외 영역에서 전출하는 것은 대량 운영 관행에서 여러 차례 시도하는 기술이자 텐센트 QQ 및 위챗 보증 플랫폼의 서비스 품질을 보장하는 핵심 운영 능력 중 하나입니다.
도메인 이름, VIP, 액세스 게이트웨이 등의 기술과 결합하여 아키텍처 지원 스케줄링 기능, 운영 및 유지 관리 수단 강화, 다양한 장애 시나리오에 보다 침착하게 대처할 수 있는 능력 제공
다른 곳에서 살다
오프사이트 다중 활동은 데이터 고가용성 요구 사항이자 스케줄링 가능한 전제 조건입니다. 업무 시나리오에 따라 기술 실현 수단에는 제한이 없다.
텐센트의 사회실천은 주효군 선생님의 문장' 2 억 QQ 사용자 뒤의 아키텍처 설계와 효율적인 운영' 을 참고할 수 있다.
마스터-슬레이브 전환
마스터-슬레이브 전환은 데이터베이스의 고가용성 스키마에서 가장 일반적인 재해 복구 시나리오입니다. 비즈니스 논리에서 읽기 및 쓰기 분리, 지능형 라우팅과 결합, 무인 마스터-슬레이브 전환 자동화를 통해 DBA 에 아키텍처 설계를 위한 최고의 선물이라는 것은 의심의 여지가 없습니다.
유연한 가용성
"안정화 후 최적화" 는 텐센트 대량 운영 아이디어 중 하나이며, 비즈니스 아키텍처의 고가용성 설계를 위한 방향을 제시합니다.
업무량이 급증하는 상황에서 어떻게 업무 가용성을 극대화할 수 있습니까? 이것은 건축 계획 설계에서 피할 수 없는 문제이다. 유연한 스위치나 내장 논리를 지능적으로 설정하여 초과 요청을 자동으로 거부하면 백엔드 서비스가 중요한 순간에 눈사태가 발생하지 않고 비즈니스 아키텍처의 고가용성을 보장할 수 있습니다.
다섯 번째 요점: 품질 관리
업무 품질을 보장하고 향상시키는 것은 운영 유지 노력의 목표이며, 모니터링 능력은 우리가 목표를 달성하는 중요한 기술 수단이다. 운영 및 유지 보수 부서는 이 아키텍처가 품질 모니터링을 위한 편리함과 데이터 지원을 제공하기를 희망하며, 요구 사항은 다음과 같습니다.
표시기 측정
각 아키텍처는 지표로 측정할 수 있어야 하며, 우리는 하나의 유일한 지표로 측정하는 것이 가장 좋기를 바랍니다. 날로 완벽해지는 업무 입체 모니터링의 경우 모니터링 지표의 수가 두 배로 증가할 것이다. 따라서 아키텍처에는 하나의 지표 측정만 있기를 바랍니다.
기본 모니터링
네트워크, 전용 라인, 호스트, 시스템의 저수준 지표 기능을 나타냅니다. 이러한 모니터링 지점은 대부분 비침입적이어서 데이터를 쉽게 수집할 수 있다.
자동 운영 및 유지 보수 기능이 건전한 기업에서는 기본 모니터링에서 생성되는 대부분의 경보 데이터가 수렴됩니다. 이와 동시에 이 모니터링 데이터는 상위 수준 비즈니스 모니터링에 대한 데이터 지원 및 의사 결정 기반을 제공하거나 상위 계층 애플리케이션 시나리오에 더 가까운 비즈니스 모니터링 데이터 (예: 용량, 다차원 지표 등) 로 패키지화됩니다.
구성 요소 모니터링
텐센트는 개발 프레임워크, 라우팅 서비스, 미들웨어를 구성 요소라고 부르는 데 익숙하다. 이 모니터링은 기본 모니터링과 비즈니스 모니터링 사이에 있습니다. 운영 및 유지 보수는 종종 구성 요소에 모니터링 논리를 포함시키기를 원합니다. 구성 요소의 보급을 통해 구성 요소 모니터링의 적용 범위를 높이고 데이터를 얻는 데 드는 비용이 적당합니다. 라우팅 구성 요소 모니터링을 사용하는 경우 운영 서비스는 각 라우팅 서비스에 대한 요청 양, 지연 등의 상태 및 품질 지표를 얻을 수 있습니다.
업무 감시
비즈니스 모니터링은 사전 모니터링과 수동 모니터링으로 나눌 수 있으며 침입과 우회를 통해 수행할 수 있습니다. 이러한 모니터링 방안은 코딩 및 아키텍처와 관련된 개발 협력이 필요하다.
일반적으로 업무 모니터링에 대한 척도는 요청 수량, 성공률 및 지연이라는 세 가지 척도로 요약할 수 있습니다. 로그 모니터링, 흐름 데이터 모니터링, 웨이브 측정 등 여러 가지 방법을 구현할 수 있습니다. 업무 모니터링은 높은 수준의 모니터링으로, 종종 업무 문제를 직접 피드백할 수 있다. 그러나 문제의 근본 원인을 심층적으로 분석하려면 반환 코드 정의, 로그 프로토콜 등과 같은 필요한 운영 및 유지 관리 모니터링 관리 사양을 결합해야 합니다. 비즈니스 아키텍처를 설계할 때는 운영 및 유지 관리 모니터링 관리의 필요성을 미리 고려해야 하며, 범위는 전역적으로 계획해야 합니다.
전체 링크 모니터링
인프라, 구성 요소 및 비즈니스 모니터링 도구는 포인트 모니터링에 더 중점을 둡니다. 분산 아키텍처의 비즈니스 시나리오에서는 서비스 요청 링크 모니터링을 고려해야 합니다.
고유한 트랜잭션 ID 또는 RPC 호출 관계를 기반으로 기술 수단을 통해 호출 관계 체인을 복원한 다음 모델 또는 이벤트를 통해 모니터링 경고를 트리거하여 서비스 링크의 상태와 품질을 피드백합니다. 이러한 모니터링은 모니터링의 고급 애플리케이션이며 비즈니스 아키텍처를 계획할 때 사전 계획 및 코드 포함이 필요합니다. 。
품질 평가
모니터링 기능의 향상과 품질 최적화에는 폐쇄 루프 관리가 필요하며, 평가는 좋은 수단입니다. 모니터링 범위, 종합 지표, 이벤트 관리 메커니즘에서 보고 평가 점수에 이르기까지 운영 및 개발은 지속적인 피드백을 위한 품질 관리 폐쇄 루프를 구축하여 비즈니스 구조를 지속적으로 진화시키고 개선할 수 있습니다.
여섯 번째 요점: 성능 비용
텐센트에서는 모든 기술 운영자들이 합리적인 업무 운영 비용을 보장하는 중요한 기능을 담당하고 있습니다. 이를 위해서는 애플리케이션 처리량 성능, 비즈니스 용량 계획 및 운영 비용을 관리하는 적절한 방법이 있어야 합니다.
처리량 성능
DevOps 지속적 제공 방법론에서 테스트 단계의 비기능 요구 사항 테스트의 가장 중요한 점은 온라인 적용 후 비즈니스 역량의 건강을 보장하기 위한 아키텍처 처리 성능에 대한 스트레스 테스트입니다.
텐센트의 실천에서 성능 스트레스 테스트는 테스트 단계에만 국한되지 않는다. 라우팅 구성 요소의 기능과 결합하여 서비스 모듈 및 서비스 세트의 실제 요청을 테스트하여 서비스 역량 모델의 기준을 설정합니다. 또한 측면에서 데이터를 제공하여 비즈니스 아키텍처의 처리량 성능이 비용 평가 요구 사항을 충족하는지 여부를 입증하고, 서비스 간 성능 데이터 비교를 활용하여 아키텍처 성능의 지속적인 개선을 촉진합니다.
용량 계획
영어 단어 "capacity" 는 애플리케이션 성능, 서비스 기능 및 총 서비스 요청으로 번역될 수 있습니다. 운영 능력 계획은 애플리케이션 성능 규정 준수를 전제로 전체 서비스 요청에 따라 합리적인 서비스 능력 계획을 수행하는 것을 말합니다.
생산비
운영비용 절감은 회사에게 현금 흐름에 대한 투자를 줄이는 것이며, 기업에 대한 가치는 품질과 효율성 향상에 못지않다.
텐센트는 소셜 네트워킹, UGC, 클라우드 컴퓨팅, 게임, 비디오 등 리치 미디어 서비스에 주력하고 있습니다. 또한 매년 소비되는 대역폭, 장비 등 운영 비용 금액은 엄청납니다. 운영 유지 보수 최적화 운영 비용에는 종종 제품 기능 및 비즈니스 아키텍처 최적화가 포함됩니다. 따라서 이상적인 운영 및 유지 관리 비즈니스 아키텍처 설계에는 충분한 비용 인식이 필요합니다.
요약
이 글은 순전히 내가 운비 차원에서 마이크로서비스 아키텍처 설계에 대해 약간 서투른 견해이다. 운영 및 유지 보수 가치를 극대화하고, 비즈니스 품질, 효율성 및 비용의 전반적인 향상을 보장하기 위해, 비즈니스 아키텍처라는 단단한 뼈를 씹어야 합니다.
운영 담당자는 아키텍처에 대해 잘 알고 있어야 하며, DevOps 정신에 의해 제창된 다양한 각도에서 비즈니스 아키텍처에 대한 조언이나 요구를 제시할 수 있어야 합니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 운영명언) 개발 및 운영 유지 관리가 함께 작동하여 최적의 비즈니스 아키텍처를 지속적으로 최적화합니다.