단일 클라우드 - Odnoklassniki의 데이터 센터 수준 OS

알로하 여러분! 제 이름은 Oleg Anastasyev이고 플랫폼 팀의 Odnoklassniki에서 일하고 있습니다. 그리고 나 외에도 Odnoklassniki에는 많은 하드웨어가 작동하고 있습니다. 우리는 500개 이상의 서버와 약 8개의 랙을 갖춘 XNUMX개의 데이터 센터를 보유하고 있습니다. 어느 시점에서 우리는 새로운 관리 시스템을 도입하면 장비를 보다 효율적으로 로드하고, 액세스 관리를 용이하게 하며, 컴퓨팅 리소스의 (재)분배를 자동화하고, 새로운 서비스 출시 속도를 높이고, 대응 속도를 높일 수 있다는 것을 깨달았습니다. 대규모 사고까지.

그 결과는 무엇입니까?

저와 여러 하드웨어 외에도 이 하드웨어를 사용하는 사람들도 있습니다. 데이터 센터에 직접 근무하는 엔지니어; 네트워크 소프트웨어를 설정하는 네트워크 담당자; 인프라 탄력성을 제공하는 관리자 또는 SRE 개발팀은 각각 포털 기능의 일부를 담당합니다. 그들이 만드는 소프트웨어는 다음과 같이 작동합니다.

사용자 요청은 메인 포털 전면에서 모두 수신됩니다. www.ok.ru, 기타 예를 들어 음악 API 전면에 있습니다. 비즈니스 로직을 처리하기 위해 요청을 처리할 때 필요한 특수 마이크로서비스(원 그래프(소셜 연결 그래프), 사용자 캐시(사용자 프로필 캐시) 등)를 호출하는 애플리케이션 서버를 호출합니다.

이러한 각 서비스는 많은 시스템에 배포되며 각 서비스에는 모듈의 기능, 운영 및 기술 개발을 담당하는 담당 개발자가 있습니다. 이러한 모든 서비스는 하드웨어 서버에서 실행되며 최근까지 우리는 서버당 정확히 하나의 작업을 시작했습니다. 즉, 특정 작업에 특화된 서비스였습니다.

왜 그런 겁니까? 이 접근 방식에는 다음과 같은 몇 가지 장점이 있었습니다.

• 안도하는 대량 관리. 작업에 일부 라이브러리와 일부 설정이 필요하다고 가정해 보겠습니다. 그런 다음 서버는 정확히 하나의 특정 그룹에 할당되고, 이 그룹에 대한 cfengine 정책이 설명되거나 이미 설명되었으며, 이 구성은 중앙에서 이 그룹의 모든 서버에 자동으로 롤아웃됩니다.
• 쉽게 한 진단. 중앙 프로세서의 부하 증가를 보고 이 부하가 이 하드웨어 프로세서에서 실행되는 작업에 의해서만 생성될 수 있다는 것을 깨달았다고 가정해 보겠습니다. 비난할 사람을 찾는 작업은 매우 빨리 끝납니다.
• 쉽게 한 모니터링. 서버에 문제가 있으면 모니터에서 이를 보고하므로 책임이 누구에게 있는지 정확히 알 수 있습니다.

여러 복제본으로 구성된 서비스에는 각각 하나씩 여러 서버가 할당됩니다. 그런 다음 서비스에 대한 컴퓨팅 리소스는 매우 간단하게 할당됩니다. 즉, 서비스가 보유한 서버 수, 사용할 수 있는 최대 리소스 양입니다. 여기서 "쉬움"은 사용하기 쉽다는 의미가 아니라 리소스 할당이 수동으로 수행된다는 의미입니다.

이 접근 방식을 통해 우리는 다음을 수행할 수도 있었습니다. 특수 철 구성 이 서버에서 실행 중인 작업에 대해 작업이 많은 양의 데이터를 저장하는 경우 4개의 디스크가 있는 섀시가 있는 38U 서버를 사용합니다. 작업이 순전히 계산적인 것이라면 더 저렴한 1U 서버를 구입할 수 있습니다. 이는 계산적으로 효율적입니다. 무엇보다도 이 접근 방식을 통해 우리는 하나의 친숙한 소셜 네트워크에 필적하는 로드를 가진 XNUMX배 적은 수의 컴퓨터를 사용할 수 있습니다.

가장 비싼 것이 서버라는 전제에서 진행한다면 컴퓨팅 자원 사용의 이러한 효율성은 경제적 효율성도 보장해야 합니다. 오랫동안 하드웨어는 가장 비쌌으며, 우리는 하드웨어 가격을 낮추기 위해 많은 노력을 기울였고, 하드웨어 신뢰성 요구 사항을 줄이기 위한 내결함성 알고리즘을 고안했습니다. 그리고 오늘날 우리는 서버 가격이 결정적인 역할을 하지 않는 단계에 도달했습니다. 최신 외래종을 고려하지 않는다면 랙에 있는 서버의 특정 구성은 중요하지 않습니다. 이제 또 다른 문제가 생겼습니다. 데이터 센터에서 서버가 차지하는 공간, 즉 랙 공간의 가격입니다.

이것이 사실이라는 것을 깨닫고 우리는 랙을 얼마나 효과적으로 사용하고 있는지 계산하기로 결정했습니다.
우리는 경제적으로 타당한 서버 중에서 가장 강력한 서버의 가격을 결정하고, 랙에 배치할 수 있는 서버 수, "서버 11대 = 작업 XNUMX개"라는 기존 모델을 기반으로 해당 서버에서 실행할 작업 수 및 그러한 서버의 양을 계산했습니다. 작업은 장비를 활용할 수 있습니다. 그들은 세고 눈물을 흘렸습니다. 랙 사용 효율은 약 XNUMX%인 것으로 나타났습니다. 결론은 분명합니다. 데이터 센터 사용의 효율성을 높여야 한다는 것입니다. 해결책은 분명한 것 같습니다. 한 서버에서 여러 작업을 동시에 실행해야 합니다. 그러나 여기서부터 어려움이 시작됩니다.

대량 구성은 훨씬 더 복잡해졌습니다. 이제 하나의 그룹을 서버에 할당하는 것이 불가능합니다. 결국, 이제 하나의 서버에서 다양한 명령의 여러 작업을 시작할 수 있습니다. 또한 구성이 다른 응용 프로그램과 충돌할 수도 있습니다. 진단도 더욱 복잡해집니다. 서버에서 CPU 또는 디스크 소비가 증가하면 어떤 작업이 문제를 일으키는지 알 수 없습니다.

그러나 가장 중요한 것은 동일한 시스템에서 실행되는 작업 간에 격리가 없다는 것입니다. 예를 들어 다음은 동일한 서버에서 다른 계산 응용 프로그램이 시작되기 전과 후의 서버 작업의 평균 응답 시간에 대한 그래프입니다. 이는 첫 번째 응용 프로그램과 전혀 관련이 없습니다. 기본 작업의 응답 시간이 크게 증가했습니다.

당연히 컨테이너나 가상 머신에서 작업을 실행해야 합니다. 거의 모든 작업이 하나의 OS(Linux)에서 실행되거나 그에 맞춰 조정되므로 다양한 운영 체제를 지원할 필요가 없습니다. 따라서 가상화는 필요하지 않으며 추가 오버헤드로 인해 컨테이너화보다 효율성이 떨어집니다.

서버에서 직접 작업을 실행하기 위한 컨테이너 구현으로서 Docker는 좋은 후보입니다. 파일 시스템 이미지는 충돌하는 구성 문제를 잘 해결합니다. 이미지가 여러 레이어로 구성될 수 있다는 사실을 통해 공통 부분을 별도의 기본 레이어로 분리하여 인프라에 이미지를 배포하는 데 필요한 데이터 양을 크게 줄일 수 있습니다. 그런 다음 기본(그리고 가장 큰) 레이어가 전체 인프라에 걸쳐 매우 빠르게 캐시되며, 다양한 유형의 애플리케이션과 버전을 제공하기 위해 작은 레이어만 전송하면 됩니다.

또한 Docker의 기성 레지스트리 및 이미지 태깅은 코드 버전 관리 및 프로덕션 환경 전달을 위한 기성 기본 요소를 제공합니다.

다른 유사한 기술과 마찬가지로 Docker는 기본적으로 일정 수준의 컨테이너 격리 기능을 제공합니다. 예를 들어, 메모리 격리 - 각 컨테이너에는 머신 메모리 사용에 대한 제한이 주어지며, 그 이상은 소비하지 않습니다. CPU 사용량을 기준으로 컨테이너를 격리할 수도 있습니다. 그러나 우리에게는 표준 단열만으로는 충분하지 않았습니다. 그러나 아래에서 더 자세히 설명합니다.

서버에서 컨테이너를 직접 실행하는 것은 문제의 일부일 뿐입니다. 다른 부분은 서버에서 컨테이너를 호스팅하는 것과 관련이 있습니다. 어떤 서버에 어떤 컨테이너를 배치할 수 있는지 이해해야 합니다. 컨테이너는 속도를 줄이지 않고 최대한 조밀하게 서버에 배치해야 하기 때문에 이는 쉬운 작업이 아닙니다. 이러한 배치는 내결함성 측면에서도 어려울 수 있습니다. 종종 우리는 동일한 서비스의 복제본을 다른 랙이나 데이터 센터의 다른 룸에 배치하여 랙이나 룸에 장애가 발생하더라도 모든 서비스 복제본이 즉시 손실되지 않도록 하려고 합니다.

8개의 서버와 8~16개의 컨테이너가 있는 경우 컨테이너를 수동으로 배포하는 것은 옵션이 아닙니다.

또한 우리는 개발자가 관리자의 도움 없이 프로덕션 환경에서 서비스를 직접 호스팅할 수 있도록 리소스 할당에 있어 더 많은 독립성을 부여하고 싶었습니다. 동시에 우리는 일부 사소한 서비스가 데이터 센터의 모든 리소스를 소비하지 않도록 제어를 유지하고 싶었습니다.

분명히 이 작업을 자동으로 수행하는 제어 계층이 필요합니다.

그래서 우리는 모든 건축가가 좋아하는 간단하고 이해하기 쉬운 그림, 즉 세 개의 사각형에 도달했습니다.

one-cloud masters는 클라우드 오케스트레이션을 담당하는 장애 조치 클러스터입니다. 개발자는 서비스를 호스팅하는 데 필요한 모든 정보가 포함된 매니페스트를 마스터에 보냅니다. 이를 기반으로 마스터는 선택된 미니언(컨테이너를 실행하도록 설계된 기계)에 명령을 내립니다. 미니언에는 명령을 수신하고 Docker에 명령을 실행하는 에이전트가 있으며 Docker는 Linux 커널을 구성하여 해당 컨테이너를 시작합니다. 명령을 실행하는 것 외에도 에이전트는 미니언 머신과 그 위에서 실행되는 컨테이너의 상태 변화에 대해 지속적으로 마스터에 보고합니다.

자원 할당

이제 많은 미니언에 대한 보다 복잡한 자원 할당 문제를 살펴보겠습니다.

단일 클라우드의 컴퓨팅 리소스는 다음과 같습니다.

• 특정 작업에 소비되는 프로세서 전력량입니다.
• 작업에 사용할 수 있는 메모리 양입니다.
• 네트워크 트래픽. 각 미니언은 대역폭이 제한된 특정 네트워크 인터페이스를 가지고 있으므로 네트워크를 통해 전송하는 데이터의 양을 고려하지 않고 작업을 분산하는 것은 불가능합니다.
• 디스크. 또한 이러한 작업을 위한 공간에는 디스크 유형(HDD 또는 SSD)도 할당됩니다. 디스크는 초당 제한된 수의 요청(IOPS)을 처리할 수 있습니다. 따라서 단일 디스크가 처리할 수 있는 것보다 더 많은 IOPS를 생성하는 작업의 경우 "스핀들", 즉 해당 작업을 위해 독점적으로 예약되어야 하는 디스크 장치도 할당합니다.

그런 다음 사용자 캐시와 같은 일부 서비스의 경우 400개의 프로세서 코어, 2,5TB의 메모리, 양방향 50Gbit/s 트래픽, 6개의 스핀들에 있는 100TB의 HDD 공간과 같은 방식으로 소비된 리소스를 기록할 수 있습니다. 또는 다음과 같이 보다 친숙한 형태로 사용됩니다.

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

사용자 캐시 서비스 리소스는 프로덕션 인프라에서 사용 가능한 모든 리소스의 일부만 소비합니다. 따라서 운영자 오류로 인해 갑자기 사용자 캐시가 할당된 것보다 더 많은 리소스를 소비하지 않는지 확인하고 싶습니다. 즉, 자원을 제한해야 합니다. 하지만 할당량을 무엇에 묶을 수 있습니까?

구성 요소 상호 작용에 대한 매우 단순화된 다이어그램으로 돌아가서 다음과 같이 더 자세한 내용을 포함하여 다시 그려 보겠습니다.

눈길을 끄는 것:

• 웹 프런트엔드와 음악은 동일한 애플리케이션 서버의 격리된 클러스터를 사용합니다.
• 이러한 클러스터가 속한 논리적 계층(프론트, 캐시, 데이터 저장 및 관리 계층)을 구분할 수 있습니다.
• 프런트엔드는 이기종이며 다양한 기능 하위 시스템으로 구성됩니다.
• 캐시는 데이터를 캐시하는 하위 시스템 전체에 분산될 수도 있습니다.

그림을 다시 그려 보겠습니다.

바! 예, 계층 구조가 보입니다! 즉, 리소스를 더 큰 덩어리로 배포할 수 있습니다. 즉, 기능적 하위 시스템(예: 그림의 "음악")에 해당하는 이 계층 구조의 노드에 담당 개발자를 할당하고 동일한 계층 구조 수준에 할당량을 첨부할 수 있습니다. 또한 이 계층 구조를 통해 관리가 용이하도록 서비스를 보다 유연하게 구성할 수 있습니다. 예를 들어, 이것은 매우 큰 서버 그룹이기 때문에 모든 웹을 그림에 group1, group2로 표시된 여러 개의 작은 그룹으로 나눕니다.

추가 줄을 제거하면 그림의 각 노드를 더 단순한 형식으로 작성할 수 있습니다. 그룹1.웹.프론트, api.music.front, 사용자-cache.cache.

이것이 우리가 "계층적 큐"라는 개념을 갖게 된 방법입니다. "group1.web.front"와 같은 이름이 있습니다. 리소스 및 사용자 권한에 대한 할당량이 할당됩니다. DevOps 담당자에게 대기열에 서비스를 보낼 수 있는 권한을 부여하고 해당 직원은 대기열에서 무언가를 시작할 수 있으며 OpsDev 담당자는 관리자 권한을 갖게 되며 이제 대기열을 관리하고 거기에 사람을 할당할 수 있습니다. 이들에게 권한 등을 부여합니다. 이 대기열에서 실행되는 서비스는 대기열의 할당량 내에서 실행됩니다. 대기열의 컴퓨팅 할당량이 모든 서비스를 한 번에 실행하기에 충분하지 않은 경우 순차적으로 실행되어 대기열 자체를 형성합니다.

서비스를 자세히 살펴보겠습니다. 서비스에는 항상 대기열의 이름을 포함하는 정규화된 이름이 있습니다. 그러면 전면 웹 서비스의 이름은 다음과 같습니다. ok-web.group1.web.front. 그리고 액세스하는 애플리케이션 서버 서비스가 호출됩니다. ok-app.group1.web.front. 각 서비스에는 특정 컴퓨터에 배치하는 데 필요한 모든 정보(이 작업이 소비하는 리소스 수, 필요한 구성, 있어야 하는 복제본 수, 이 서비스 오류 처리를 위한 속성)를 지정하는 매니페스트가 있습니다. 그리고 서비스가 머신에 직접 배치되면 해당 인스턴스가 나타납니다. 또한 인스턴스 번호와 서비스 이름으로 명확하게 이름이 지정됩니다. 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

이는 매우 편리합니다. 실행 중인 컨테이너의 이름만 보면 즉시 많은 정보를 알아낼 수 있습니다.

이제 이러한 인스턴스가 실제로 수행하는 작업, 즉 작업을 자세히 살펴보겠습니다.

작업 격리 클래스

OK의 모든 작업(그리고 아마도 모든 곳)은 그룹으로 나눌 수 있습니다.

• 짧은 대기 시간 작업 - prod. 이러한 작업 및 서비스의 경우 응답 지연(대기 시간), 즉 각 요청이 시스템에서 얼마나 빨리 처리되는지가 매우 중요합니다. 작업의 예: 웹 프론트, 캐시, 애플리케이션 서버, OLTP 스토리지 등
• 계산 문제 - 배치. 여기서 각 특정 요청의 처리 속도는 중요하지 않습니다. 그들에게는 이 작업이 특정(장기) 기간(처리량) 동안 얼마나 많은 계산을 수행하는지가 중요합니다. 이는 MapReduce, Hadoop, 기계 학습, 통계의 모든 작업이 될 것입니다.
• 백그라운드 작업 - 유휴. 이러한 작업의 경우 대기 시간이나 처리량은 그다지 중요하지 않습니다. 여기에는 다양한 테스트, 마이그레이션, 재계산 및 한 형식에서 다른 형식으로의 데이터 변환이 포함됩니다. 한편으로는 계산된 것과 비슷하지만, 얼마나 빨리 완료되는지는 우리에게 별로 중요하지 않습니다.

이러한 작업이 중앙 프로세서와 같은 리소스를 어떻게 소비하는지 살펴보겠습니다.

짧은 지연 작업. 이러한 작업은 다음과 유사한 CPU 소비 패턴을 갖습니다.

처리를 위해 사용자의 요청이 수신되면 작업은 사용 가능한 모든 CPU 코어를 사용하기 시작하고 이를 처리하며 응답을 반환하고 다음 요청을 기다린 후 중지됩니다. 다음 요청이 도착했습니다. 다시 우리는 거기에 있던 모든 것을 선택하고 계산한 후 다음 요청을 기다리고 있습니다.

이러한 작업에 대한 최소 대기 시간을 보장하려면 소비하는 최대 리소스를 확보하고 미니언(작업을 실행할 시스템)에 필요한 코어 수를 예약해야 합니다. 그러면 문제에 대한 예약 공식은 다음과 같습니다.

alloc: cpu = 4 (max)

그리고 16개의 코어를 가진 미니언 머신이 있다면 정확히 XNUMX개의 작업을 그 머신에 배치할 수 있습니다. 특히 이러한 작업의 평균 프로세서 소비는 종종 매우 낮다는 점에 주목합니다. 이는 작업이 요청을 기다리는 시간의 상당 부분이 아무것도 수행하지 않기 때문에 분명합니다.

계산 작업. 패턴은 약간 다릅니다.

이러한 작업의 평균 CPU 리소스 소비는 상당히 높습니다. 종종 계산 작업이 특정 시간 내에 완료되기를 원하므로 전체 계산이 허용 가능한 시간 내에 완료되도록 필요한 최소 프로세서 수를 예약해야 합니다. 예약 공식은 다음과 같습니다.

alloc: cpu = [1,*)

"적어도 하나 이상의 여유 코어가 있는 미니언에 배치해 주세요. 그러면 코어가 있는 만큼 모든 것을 집어삼켜버릴 것입니다."

여기서 사용 효율성은 이미 짧은 지연이 있는 작업보다 훨씬 좋습니다. 그러나 하나의 미니언 머신에서 두 가지 유형의 작업을 결합하고 이동 중에 리소스를 배포하면 이득이 훨씬 더 커질 것입니다. 지연 시간이 짧은 작업에 프로세서가 필요한 경우 즉시 이를 수신하고, 리소스가 더 이상 필요하지 않으면 계산 작업으로 전송됩니다. 즉, 다음과 같습니다.

그러나 어떻게해야합니까?

먼저 prod와 해당 할당을 살펴보겠습니다. cpu = 4. XNUMX개의 코어를 예약해야 합니다. Docker 실행에서는 다음 두 가지 방법으로 이를 수행할 수 있습니다.

• 옵션 사용 --cpuset=1-4즉, 머신의 특정 코어 XNUMX개를 작업에 할당합니다.
• 사용 --cpuquota=400_000 --cpuperiod=100_000, 프로세서 시간에 대한 할당량을 할당합니다. 즉, 실시간 100ms마다 작업이 400ms 이하의 프로세서 시간을 소비함을 나타냅니다. 동일한 XNUMX개의 코어가 얻어집니다.

그러나 이들 중 어떤 방법이 적합한가?

cpuset은 꽤 매력적으로 보입니다. 작업에는 XNUMX개의 전용 코어가 있으며 이는 프로세서 캐시가 최대한 효율적으로 작동함을 의미합니다. 여기에는 단점도 있습니다. OS 대신 로드되지 않은 머신 코어 전체에 계산을 분산하는 작업을 수행해야 하며 이는 특히 사소한 작업이 아닙니다. 기계. 테스트 결과 여기에는 할당량이 있는 옵션이 더 적합한 것으로 나타났습니다. 이렇게 하면 운영 체제가 현재 작업을 수행할 코어를 더 자유롭게 선택할 수 있고 프로세서 시간이 더 효율적으로 분산됩니다.

최소 코어 수를 기준으로 Docker에서 예약하는 방법을 알아 보겠습니다. 최대값을 제한할 필요가 없고 최소값만 보장하면 충분하므로 일괄 작업에 대한 할당량은 더 이상 적용되지 않습니다. 그리고 여기에 옵션이 잘 맞습니다 docker run --cpushares.

배치에 최소 하나의 코어에 대한 보증이 필요한 경우 다음을 표시하는 데 동의했습니다. --cpushares=1024, 코어가 두 개 이상 있으면 표시합니다. --cpushares=2048. CPU 공유는 프로세서 시간이 충분하다면 분배를 방해하지 않습니다. 따라서 prod가 현재 1024개의 코어를 모두 사용하지 않는 경우 일괄 작업을 제한하는 것이 없으며 추가 프로세서 시간을 사용할 수 있습니다. 그러나 프로세서가 부족한 상황에서 prod가 코어 2048개를 모두 소비하고 할당량에 도달한 경우 남은 프로세서 시간은 CPU 공유에 비례하여 나누어집니다. 즉, 사용 가능한 코어가 XNUMX개인 상황에서는 하나가 XNUMX개의 CPU 공유가 있는 작업에 제공되고 나머지 두 개는 XNUMX개의 CPU 공유가 있는 작업에 제공됩니다.

그러나 할당량과 공유를 사용하는 것만으로는 충분하지 않습니다. 프로세서 시간을 할당할 때 지연 시간이 짧은 작업이 배치 작업보다 우선순위를 받도록 해야 합니다. 이러한 우선순위가 없으면 프로덕션에서 필요한 순간에 일괄 작업이 프로세서 시간을 모두 차지하게 됩니다. Docker 실행에는 컨테이너 우선순위 지정 옵션이 없지만 Linux CPU 스케줄러 정책이 유용합니다. 당신은 그들에 대해 자세히 읽을 수 있습니다 여기에, 이 기사의 틀 내에서 간략하게 살펴보겠습니다.

• SCHED_OTHER
  기본적으로 Linux 시스템의 모든 일반 사용자 프로세스는 수신합니다.
• SCHED_배치
  리소스 집약적인 프로세스를 위해 설계되었습니다. 프로세서에 작업을 배치하면 소위 활성화 패널티가 도입됩니다. 이러한 작업은 현재 SCHED_OTHER를 사용하는 작업에서 사용 중인 경우 프로세서 리소스를 받을 가능성이 적습니다.
• SCHED_IDLE
  nice -19보다 훨씬 낮은 우선순위를 가진 백그라운드 프로세스입니다. 우리는 오픈 소스 라이브러리를 사용합니다 원니오, 호출하여 컨테이너를 시작할 때 필요한 정책을 설정하기 위해

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

그러나 Java로 프로그래밍하지 않더라도 chrt 명령을 사용하여 동일한 작업을 수행할 수 있습니다.

chrt -i 0 $pid

명확성을 위해 모든 격리 수준을 하나의 표로 요약해 보겠습니다.

절연 등급
할당 예시
Docker 실행 옵션
sched_setscheduler 차트*

자극하다
CPU = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

일괄
CPU = [1, *)
--cpushares=1024
SCHED_배치

유휴
CPU= [2, *)
--cpushares=2048
SCHED_IDLE

*컨테이너 내부에서 chrt를 수행하는 경우 sys_nice 기능이 필요할 수 있습니다. 기본적으로 Docker는 컨테이너를 시작할 때 이 기능을 제거하기 때문입니다.

그러나 작업은 프로세서뿐만 아니라 트래픽도 소비합니다. 이는 프로세서 리소스의 잘못된 할당보다 네트워크 작업의 대기 시간에 더 큰 영향을 미칩니다. 그러므로 우리는 당연히 교통 상황에 대해 정확히 동일한 그림을 얻고 싶어합니다. 즉, prod 작업이 일부 패킷을 네트워크로 보낼 때 최대 속도를 제한합니다(공식 할당: lan=[*,500mbps) ), prod를 사용하면 이 작업을 수행할 수 있습니다. 배치의 경우 최소 처리량만 보장하지만 최대 처리량은 제한하지 않습니다(공식 할당: lan=[10Mbps,*) ) 이 경우 prod 트래픽은 일괄 작업보다 우선순위를 받아야 합니다.
여기서 Docker에는 우리가 사용할 수 있는 기본 요소가 없습니다. 하지만 그게 우리를 도와주러 왔어 리눅스 트래픽 제어. 우리는 징계의 도움으로 원하는 결과를 얻을 수 있었습니다 계층적 공정 서비스 곡선. 이를 통해 우선 순위가 높은 prod와 우선 순위가 낮은 배치/유휴라는 두 가지 트래픽 클래스를 구분합니다. 결과적으로 나가는 트래픽의 구성은 다음과 같습니다.

여기서 1:0은 hsfc 분야의 "루트 qdisc"입니다. 1:1 - 전체 대역폭 제한이 8Gbit/s인 hsfc 하위 클래스이며, 모든 컨테이너의 하위 클래스가 그 아래에 배치됩니다. 1:2 - hsfc 하위 클래스는 아래에서 설명하는 "동적" 제한이 있는 모든 배치 및 유휴 작업에 공통됩니다. 나머지 hsfc 하위 클래스는 해당 매니페스트에 해당하는 제한(450 및 400Mbit/s)을 사용하여 현재 실행 중인 prod 컨테이너를 위한 전용 클래스입니다. 각 hsfc 클래스에는 Linux 커널 버전에 따라 qdisc 대기열 fq 또는 fq_codel이 할당되어 트래픽 버스트 중 패킷 손실을 방지합니다.

일반적으로 TC 분야는 나가는 트래픽에만 우선 순위를 지정하는 역할을 합니다. 그러나 우리는 들어오는 트래픽의 우선순위도 정하고 싶습니다. 결국 일부 일괄 작업은 전체 들어오는 채널을 쉽게 선택할 수 있으며 예를 들어 매핑 및 축소를 위한 대량의 입력 데이터 일괄 처리를 수신할 수 있습니다. 이를 위해 우리는 모듈을 사용합니다 ifb이는 각 네트워크 인터페이스에 대한 ifbX 가상 인터페이스를 생성하고 인터페이스에서 들어오는 트래픽을 ifbX의 나가는 트래픽으로 리디렉션합니다. 또한 ifbX의 경우 모든 동일한 원칙이 나가는 트래픽을 제어하기 위해 작동하며 hsfc 구성은 매우 유사합니다.

실험 중에 우리는 미니언 머신에서 우선순위가 아닌 배치/유휴 트래픽의 1:2 클래스가 특정 여유 레인 이하로 제한될 때 hsfc가 최상의 결과를 보인다는 것을 발견했습니다. 그렇지 않으면 우선순위가 아닌 트래픽이 프로덕션 작업의 지연 시간에 너무 많은 영향을 미칩니다. miniond는 매초 현재 사용 가능한 대역폭의 양을 결정하여 특정 미니언의 모든 생산 작업의 평균 트래픽 소비를 측정합니다. 네트워크 인터페이스 대역폭에서 이를 뺍니다. 작은 마진으로, 즉

대역은 들어오고 나가는 트래픽에 대해 독립적으로 정의됩니다. 그리고 새로운 값에 따라 miniond는 비우선순위 클래스 제한을 1:2로 재구성합니다.

따라서 우리는 세 가지 격리 클래스(prod, 배치 및 유휴)를 모두 구현했습니다. 이러한 클래스는 작업의 성능 특성에 큰 영향을 미칩니다. 따라서 우리는 이 속성을 계층 구조의 최상위에 배치하기로 결정했습니다. 그러면 계층 구조 대기열의 이름을 보면 우리가 무엇을 다루고 있는지 즉시 알 수 있습니다.

우리 친구들 모두 웹 и 음악 그런 다음 프런트는 prod 아래의 계층 구조에 배치됩니다. 예를 들어 배치 아래에 서비스를 배치해 보겠습니다. 음악 카탈로그, Odnoklassniki에 업로드된 mp3 파일 세트에서 트랙 카탈로그를 주기적으로 컴파일합니다. 유휴 상태의 서비스 예는 다음과 같습니다. 음악 변압기, 음악 볼륨 레벨을 표준화합니다.

추가 줄을 다시 제거하면 전체 서비스 이름 끝에 작업 격리 클래스를 추가하여 서비스 이름을 더 깔끔하게 작성할 수 있습니다. 웹.프런트.프로드, 카탈로그.음악.배치, 변압기.음악.유휴.

이제 서비스 이름을 보면 서비스가 수행하는 기능뿐만 아니라 중요도 등을 의미하는 격리 클래스도 이해합니다.

모든 것이 훌륭하지만 한 가지 씁쓸한 진실이 있습니다. 한 컴퓨터에서 실행되는 작업을 완전히 격리하는 것은 불가능합니다.

우리가 달성한 것: 배치가 집중적으로 소비하는 경우 만 CPU 리소스가 있으면 내장된 Linux CPU 스케줄러가 작업을 매우 잘 수행하며 실제로 프로덕션 작업에 영향을 주지 않습니다. 그러나 이 일괄 작업이 메모리를 사용하여 적극적으로 작동하기 시작하면 상호 영향이 이미 나타납니다. 이는 prod 작업이 프로세서의 메모리 캐시에서 "씻겨 나가기" 때문에 발생합니다. 결과적으로 캐시 누락이 증가하고 프로세서가 prod 작업을 더 느리게 처리합니다. 이러한 일괄 작업으로 인해 일반적인 프로덕션 컨테이너의 대기 시간이 10% 증가할 수 있습니다.

최신 네트워크 카드에는 내부 패킷 대기열이 있기 때문에 트래픽을 격리하는 것이 훨씬 더 어렵습니다. 일괄 작업의 패킷이 먼저 도착하면 해당 패킷이 케이블을 통해 가장 먼저 전송되며 이에 대해 아무 조치도 취할 수 없습니다.

게다가 우리는 지금까지 TCP 트래픽 우선순위 문제만 해결했습니다. hsfc 접근 방식은 UDP에서는 작동하지 않습니다. 그리고 TCP 트래픽의 경우에도 일괄 작업으로 인해 트래픽이 많이 발생하면 prod 작업의 지연도 약 10% 증가합니다.

결함 허용

단일 클라우드를 개발할 때의 목표 중 하나는 Odnoklassniki의 내결함성을 향상시키는 것이었습니다. 따라서 다음에는 가능한 실패 및 사고 시나리오를 더 자세히 고려하고 싶습니다. 컨테이너 오류라는 간단한 시나리오부터 시작해 보겠습니다.

컨테이너 자체는 여러 가지 방법으로 실패할 수 있습니다. 이는 매니페스트에 표시된 것보다 더 많은 리소스를 prod 작업이 소비하기 시작하는 매니페스트의 일종의 실험, 버그 또는 오류일 수 있습니다. 한 가지 사례가 있었습니다. 개발자가 하나의 복잡한 알고리즘을 구현하고 이를 여러 번 재작업한 후 너무 혼란스러워서 결국 문제가 매우 사소하지 않은 방식으로 반복되었습니다. 그리고 prod 작업은 동일한 미니언의 다른 모든 작업보다 우선순위가 높기 때문에 사용 가능한 모든 프로세서 리소스를 소비하기 시작했습니다. 이 상황에서는 격리, 즉 CPU 시간 할당량이 문제를 해결했습니다. 작업에 할당량이 할당되면 해당 작업은 더 이상 할당량을 소비하지 않습니다. 따라서 동일한 시스템에서 실행되는 배치 및 기타 프로덕션 작업에서는 아무 것도 발견되지 않았습니다.

두 번째로 발생할 수 있는 문제는 컨테이너가 떨어지는 것입니다. 여기서 다시 시작 정책은 우리를 구해줍니다. 모두가 이를 알고 있으며 Docker 자체가 훌륭한 작업을 수행합니다. 거의 모든 프로덕션 작업에는 항상 다시 시작 정책이 있습니다. 때로는 일괄 작업이나 프로덕션 컨테이너 디버깅에 on_failure를 사용합니다.

전체 미니언을 사용할 수 없는 경우 어떻게 할 수 있나요?

분명히 다른 머신에서 컨테이너를 실행하십시오. 여기서 흥미로운 부분은 컨테이너에 할당된 IP 주소에 어떤 일이 발생하는지입니다.

컨테이너가 실행되는 미니언 머신과 동일한 IP 주소를 컨테이너에 할당할 수 있습니다. 그런 다음 컨테이너가 다른 시스템에서 시작되면 해당 IP 주소가 변경되고 모든 클라이언트는 컨테이너가 이동했다는 사실을 이해해야 하며 이제 별도의 서비스 검색 서비스가 필요한 다른 주소로 이동해야 합니다.

서비스 검색이 편리합니다. 서비스 레지스트리를 구성하기 위해 다양한 수준의 내결함성을 제공하는 솔루션이 시장에 많이 나와 있습니다. 이러한 솔루션은 로드 밸런서 로직을 구현하고 KV 스토리지 등의 형태로 추가 구성을 저장하는 경우가 많습니다.
그러나 별도의 레지스트리를 구현할 필요는 피하고 싶습니다. 이는 프로덕션의 모든 서비스에서 사용되는 중요한 시스템을 도입하는 것을 의미하기 때문입니다. 이는 이것이 잠재적인 실패 지점임을 의미하며 내결함성이 매우 높은 솔루션을 선택하거나 개발해야 하며 이는 분명히 매우 어렵고 시간이 많이 걸리며 비용이 많이 듭니다.

그리고 또 하나의 큰 단점은 기존 인프라가 새로운 인프라와 함께 작동하려면 일종의 서비스 검색 시스템을 사용하도록 모든 작업을 완전히 다시 작성해야 한다는 것입니다. 많은 작업이 있으며 일부 장소에서는 OS 커널 수준에서 작동하거나 하드웨어와 직접 작동하는 하위 수준 장치의 경우 거의 불가능합니다. 다음과 같은 확립된 솔루션 패턴을 사용하여 이 기능을 구현합니다. 사이드카 어떤 곳에서는 추가 부하가 발생하고 다른 곳에서는 작동이 복잡해지고 추가 오류 시나리오가 발생한다는 의미입니다. 우리는 일을 복잡하게 만들고 싶지 않았기 때문에 Service Discovery 사용을 선택 사항으로 만들기로 결정했습니다.

단일 클라우드에서 IP는 컨테이너를 따릅니다. 즉, 각 작업 인스턴스에는 자체 IP 주소가 있습니다. 이 주소는 "정적"입니다. 서비스가 처음 클라우드로 전송될 때 각 인스턴스에 할당됩니다. 서비스 수명 동안 서비스의 인스턴스 수가 다른 경우 결국에는 최대 인스턴스 수만큼 IP 주소가 할당됩니다.

이후에도 이러한 주소는 변경되지 않습니다. 한 번 할당되고 프로덕션 서비스 기간 동안 계속 존재합니다. IP 주소는 네트워크 전체에서 컨테이너를 따릅니다. 컨테이너가 다른 미니언으로 전송되면 주소가 따라옵니다.

따라서 IP 주소 목록에 대한 서비스 이름 매핑은 거의 변경되지 않습니다. 글 초반에 언급한 서비스 인스턴스의 이름을 다시 살펴보면(1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), DNS에서 사용되는 FQDN과 유사하다는 것을 알 수 있습니다. 그렇습니다. 서비스 인스턴스 이름을 해당 IP 주소에 매핑하기 위해 DNS 프로토콜을 사용합니다. 더욱이 이 DNS는 실행 중이거나 중지된 모든 컨테이너의 예약된 IP 주소를 모두 반환합니다(XNUMX개의 복제본이 사용되고 거기에 XNUMX개의 주소가 예약되어 있다고 가정해 보겠습니다. XNUMX개가 모두 반환됩니다). 이 정보를 받은 클라이언트는 XNUMX개의 복제본 모두와 연결을 시도하여 작동 중인 복제본을 확인합니다. 가용성을 결정하는 이 옵션은 훨씬 더 안정적입니다. 여기에는 DNS나 서비스 검색이 포함되지 않습니다. 즉, 정보의 관련성과 이러한 시스템의 내결함성을 보장하는 데 해결하기 어려운 문제가 없음을 의미합니다. 또한 전체 포털의 운영이 의존하는 중요한 서비스에서는 DNS를 전혀 사용할 수 없으며 구성에 IP 주소만 입력하면 됩니다.

컨테이너 뒤에서 이러한 IP 전송을 구현하는 것은 간단하지 않을 수 있으며 다음 예를 통해 이것이 어떻게 작동하는지 살펴보겠습니다.

단일 클라우드 마스터가 미니언 M1에게 실행 명령을 내린다고 가정해 보겠습니다. 1.ok-web.group1.web.front.prod 주소 1.1.1.1. 미니언에서 작동 새, 이 주소를 특수 서버에 광고합니다. 경로 반사체. 후자에는 M1.1.1.1의 주소 1 경로가 변환되는 네트워크 하드웨어와의 BGP 세션이 있습니다. M1은 Linux를 사용하여 컨테이너 내부에서 패킷을 라우팅합니다. XNUMX개의 경로 리플렉터 서버가 있습니다. 이는 단일 클라우드 인프라의 매우 중요한 부분이기 때문입니다. 이 서버가 없으면 단일 클라우드의 네트워크가 작동하지 않습니다. 세 가지가 동시에 실패할 가능성을 줄이기 위해 가능하면 데이터 센터의 서로 다른 공간에 있는 서로 다른 랙에 배치합니다.

이제 단일 클라우드 마스터와 M1 미니언 간의 연결이 끊어졌다고 가정해 보겠습니다. 이제 단일 클라우드 마스터는 M1이 완전히 실패했다는 가정에 따라 조치를 취합니다. 즉, M2 미니언에게 발사하라는 명령을 내립니다. web.group1.web.front.prod 동일한 주소 1.1.1.1. 이제 1.1.1.1의 네트워크에는 M1과 M2라는 두 개의 충돌하는 경로가 있습니다. 이러한 충돌을 해결하기 위해 우리는 BGP 공지에 명시된 Multi Exit Discriminator를 사용합니다. 이는 광고된 경로의 가중치를 나타내는 숫자입니다. 충돌하는 경로 중에서 MED 값이 낮은 경로가 선택됩니다. 단일 클라우드 마스터는 컨테이너 IP 주소의 필수 부분으로 MED를 지원합니다. 처음으로 주소는 충분히 큰 MED = 1으로 기록되는데, 이러한 긴급 컨테이너 전송 상황에서 마스터는 MED를 줄이고 M000는 이미 MED =로 주소 000을 광고하라는 명령을 수신합니다. 2. M1.1.1.1에서 실행 중인 인스턴스는 이 경우 연결이 없으며 마스터와의 연결이 복원될 때까지 마스터가 이전 테이크처럼 중지될 때까지 그의 추가 운명은 우리에게 거의 관심이 없습니다.

사고

모든 데이터 센터 관리 시스템은 항상 사소한 오류를 수용 가능하게 처리합니다. 컨테이너 오버플로는 거의 모든 곳에서 일반적인 현상입니다.

데이터 센터의 하나 이상의 공간에서 정전과 같은 긴급 상황을 처리하는 방법을 살펴보겠습니다.

데이터센터 관리 시스템에 있어 사고는 무엇을 의미하나요? 우선, 이는 많은 시스템의 대규모 일회성 오류이며 제어 시스템은 동시에 많은 컨테이너를 마이그레이션해야 합니다. 그러나 재해 규모가 매우 큰 경우 데이터 센터의 리소스 용량이 부하의 100% 미만으로 떨어지기 때문에 모든 작업을 다른 미니언에게 다시 할당할 수 없는 경우가 발생할 수 있습니다.

종종 사고는 제어 계층의 실패를 동반합니다. 이는 장비 고장으로 인해 발생할 수 있지만 사고가 테스트되지 않고 부하 증가로 인해 제어 계층 자체가 떨어지기 때문에 더 자주 발생합니다.

이 모든 것에 대해 무엇을 할 수 있습니까?

대량 마이그레이션은 인프라에서 수많은 활동, 마이그레이션 및 배포가 발생함을 의미합니다. 각 마이그레이션은 미니언에게 컨테이너 이미지를 전달 및 압축 해제하고, 컨테이너를 시작 및 초기화하는 데 필요한 시간이 걸릴 수 있습니다. 따라서 덜 중요한 작업보다 더 중요한 작업을 시작하는 것이 바람직합니다.

우리에게 익숙한 서비스 계층 구조를 다시 살펴보고 어떤 작업을 먼저 실행할지 결정해 보겠습니다.

물론 이는 사용자 요청 처리에 직접적으로 관여하는 프로세스입니다. 우리는 이것을 다음과 같이 표시합니다. 배치 우선순위 — 대기열에 할당할 수 있는 번호입니다. 대기열의 우선순위가 더 높으면 해당 서비스가 먼저 배치됩니다.

prod에서는 더 높은 우선순위인 0을 할당합니다. 일괄 처리 - 조금 더 낮음, 100; 유휴 상태 - 더 낮은 200. 우선 순위는 계층적으로 적용됩니다. 계층 구조에서 더 낮은 모든 작업에는 해당 우선 순위가 있습니다. 프로덕션 내부의 캐시가 프런트엔드보다 먼저 실행되도록 하려면 캐시 = 0, 전면 하위 큐 = 1에 우선순위를 할당합니다. 예를 들어, 메인 포털이 프런트엔드에서 먼저 시작되고 뮤직 프런트만 시작되도록 하려는 경우 그런 다음 후자에 더 낮은 우선순위(10)를 할당할 수 있습니다.

다음 문제는 자원 부족이다. 따라서 많은 양의 장비, 데이터 센터 전체 홀이 실패했고 우리는 너무 많은 서비스를 다시 시작하여 이제 모든 사람을 위한 리소스가 충분하지 않습니다. 주요 핵심 서비스를 계속 실행하기 위해 희생할 작업을 결정해야 합니다.

배치 우선순위와 달리 모든 배치 작업을 무차별적으로 희생할 수는 없으며 일부 작업은 포털 운영에 중요합니다. 그러므로 별도로 강조 표시했습니다. 선점 우선순위 작업. 배치되면 우선 순위가 높은 작업이 선점될 수 있습니다. 즉, 무료 하수인이 더 이상 없으면 우선 순위가 낮은 작업을 중지할 수 있습니다. 이 경우 우선 순위가 낮은 작업은 배치되지 않은 상태로 남아 있을 수 있습니다. 즉, 충분한 여유 리소스를 갖춘 해당 작업에 적합한 하수인이 더 이상 없을 것입니다.

계층 구조에서는 유휴 우선 순위를 200으로 지정하여 생산 및 배치 작업이 유휴 작업을 선점하거나 중지하지만 서로는 선점하지 않도록 선점 우선 순위를 지정하는 것이 매우 간단합니다. 배치 우선 순위의 경우와 마찬가지로 더 복잡한 규칙을 설명하기 위해 계층 구조를 사용할 수 있습니다. 예를 들어, 메인 웹 포털에 대한 리소스가 충분하지 않은 경우 음악 기능을 희생하고 해당 노드의 우선 순위를 10으로 낮게 설정한다고 가정해 보겠습니다.

DC 사고 전체

전체 데이터 센터가 실패하는 이유는 무엇입니까? 요소. 좋은 포스팅이었습니다 허리케인이 데이터 센터 작업에 영향을 미쳤습니다.. 요소는 한때 매니폴드의 광학 장치를 태운 노숙자로 간주될 수 있으며 데이터 센터는 다른 사이트와 완전히 연결이 끊어졌습니다. 실패의 원인은 인적 요인일 수도 있습니다. 운영자는 전체 데이터 센터가 무너지는 명령을 내릴 것입니다. 이것은 큰 버그로 인해 발생할 수 있습니다. 일반적으로 데이터 센터 붕괴는 드문 일이 아닙니다. 이런 일은 몇 달에 한 번씩 우리에게 일어납니다.

그리고 이것이 누군가가 #alive로 트윗하는 것을 방지하기 위해 우리가 하는 일입니다.

첫 번째 전략은 격리입니다. 각 단일 클라우드 인스턴스는 격리되어 있으며 하나의 데이터 센터에서만 시스템을 관리할 수 있습니다. 즉, 버그나 잘못된 운영자 명령으로 인한 클라우드의 손실은 단 하나의 데이터 센터의 손실입니다. 우리는 이에 대한 준비가 되어 있습니다. 애플리케이션과 데이터의 복제본이 모든 데이터 센터에 위치하는 중복 정책이 있습니다. 우리는 내결함성 데이터베이스를 사용하고 주기적으로 오류를 테스트합니다.
현재 우리는 XNUMX개의 데이터 센터를 보유하고 있습니다. 이는 XNUMX개의 별도의 완전히 격리된 단일 클라우드 인스턴스를 의미합니다.

이 접근 방식은 물리적 오류로부터 보호할 뿐만 아니라 운영자 오류로부터도 보호할 수 있습니다.

인적 요소로 또 무엇을 할 수 있습니까? 운영자가 클라우드에 이상하거나 잠재적으로 위험한 명령을 내릴 때 갑자기 작은 문제를 해결하여 자신의 생각이 얼마나 되는지 확인하라는 요청을 받을 수 있습니다. 예를 들어 이것이 많은 복제본의 대량 중지이거나 이상한 명령인 경우 새 매니페스트의 버전 번호뿐만 아니라 복제본 수를 줄이거나 이미지 이름을 변경하는 것입니다.

결과

원클라우드의 특징:

• 서비스 및 컨테이너에 대한 계층적 및 시각적 이름 지정 체계를 사용하면 작업이 무엇인지, 작업과 관련이 있는지, 작업 방식과 책임자가 누구인지 매우 빠르게 확인할 수 있습니다.
• 우리는 우리의 생산 및 배치를 결합하는 기술머신 공유의 효율성을 높이기 위해 미니언에 대한 작업을 수행합니다. cpuset 대신 CPU 할당량, 공유, CPU 스케줄러 정책 및 Linux QoS를 사용합니다.
• 동일한 머신에서 실행되는 컨테이너를 완전히 격리하는 것은 불가능했지만 상호 영향은 20% 이내로 유지됩니다.
• 서비스를 계층 구조로 구성하면 자동 재해 복구에 도움이 됩니다. 배치 및 선점 우선순위.

자주 묻는 질문

기성 솔루션을 사용하지 않은 이유는 무엇입니까?

• 다양한 클래스의 작업 격리를 미니언에 배치할 때 다른 논리가 필요합니다. 단순히 리소스를 예약하여 프로덕션 작업을 배치할 수 있다면 배치 및 유휴 작업을 배치하여 미니언 머신에서 리소스의 실제 활용도를 추적해야 합니다.
• 다음과 같은 작업에 사용되는 리소스를 고려해야 합니다.
  • 네트워크 대역폭;
  • 디스크의 유형 및 "스핀들".
• 비상 대응 중 서비스 우선 순위, 리소스에 대한 명령 권한 및 할당량을 표시해야 하는 필요성은 단일 클라우드의 계층적 대기열을 사용하여 해결됩니다.
• 사고 및 사건에 대한 대응 시간을 줄이기 위해 컨테이너에 사람이 이름을 붙일 필요가 있음
• 서비스 검색을 일회성으로 광범위하게 구현하는 것이 불가능합니다. 하드웨어 호스트에서 호스팅되는 작업과 오랫동안 공존해야 하는 필요성(컨테이너를 따르는 "정적" IP 주소로 해결되는 문제, 결과적으로 대규모 네트워크 인프라와의 고유한 통합에 대한 필요성)

이러한 모든 기능은 우리에게 적합하도록 기존 솔루션을 대폭 수정해야 하며 작업량을 평가한 결과 거의 동일한 인건비로 자체 솔루션을 개발할 수 있다는 것을 깨달았습니다. 그러나 귀하의 솔루션은 운영 및 개발이 훨씬 더 쉬울 것입니다. 필요하지 않은 기능을 지원하는 불필요한 추상화가 포함되어 있지 않습니다.

마지막 줄까지 읽어주신 분들의 많은 양해와 관심 부탁드립니다!

출처 : habr.com