엔지니어 4명, 서버 7000대, 글로벌 팬데믹 XNUMX건

헤이 하브르! 나는 기사의 번역을 당신의 관심에 제시합니다 "엔지니어 4명, 서버 7000대, 그리고 하나의 글로벌 팬데믹" 아디브 다우(Adib Daw).

해당 헤드라인이 척추를 약간 떨게 하지 않는다면 다음 단락으로 건너뛰거나 다음 페이지를 방문하십시오. 회사에서의 경력 - 우리는 이야기하고 싶습니다.

우리는 누구인가?

우리는 코드 작성과 하드웨어 작업을 좋아하는 4명의 펭귄으로 구성된 팀입니다. 여가 시간에는 미국 전역의 7000개 데이터 센터에 분산된 Linux를 실행하는 3개 이상의 물리적 서버를 배포, 유지 관리 및 운영하는 일을 담당합니다.

우리는 또한 지중해 해변에서 차로 짧은 거리에 있는 우리 사무실에서 편안하게 현장에서 10km 떨어진 곳에서 이 작업을 수행할 기회를 가졌습니다.

규모 문제

상대적으로 초기 투자 비용이 낮기 때문에 스타트업이 클라우드에서 인프라를 호스팅하여 시작하는 것이 합리적이지만 Outbrain에서는 자체 서버를 사용하기로 결정했습니다. 클라우드 인프라 비용이 일정 수준까지 개발된 후 데이터센터에 위치한 자체 장비를 운영하는 데 드는 비용을 훨씬 초과하기 때문에 이렇게 했습니다. 또한 귀하의 서버는 최고 수준의 제어 및 문제 해결 기능을 제공합니다.

우리가 발전함에 따라 문제는 항상 가까이에 있습니다. 게다가 그들은 대개 그룹으로 옵니다. 서버 수명주기 관리는 서버 수가 급격히 증가하는 상황에서 제대로 작동하려면 지속적인 자체 개선이 필요합니다. 데이터 센터의 서버 그룹을 관리하는 소프트웨어 방법은 빠르게 다루기 어려워집니다. QoS 표준을 충족하면서 오류를 감지, 문제 해결 및 완화하는 것은 매우 다양한 하드웨어 배열, 다양한 작업 부하, 업그레이드 기한 및 누구도 걱정하고 싶어하지 않는 기타 좋은 것들을 저글링하는 문제가 됩니다.

도메인을 마스터하세요

이러한 많은 문제를 해결하기 위해 우리는 Outbrain의 서버 수명주기를 주요 구성 요소로 나누고 이를 도메인이라고 불렀습니다. 예를 들어, 한 영역은 장비 요구 사항을 다루고, 다른 영역은 재고 수명 주기와 관련된 물류를 다루고, 세 번째 영역은 현장 직원과의 커뮤니케이션을 다룹니다. 하드웨어 관찰 가능성에 관한 또 다른 사항이 있지만 모든 사항을 설명하지는 않습니다. 우리의 목표는 코드를 사용하여 추상화할 수 있도록 도메인을 연구하고 정의하는 것이었습니다. 작업 추상화가 개발되면 배포, 테스트 및 개선되는 수동 프로세스로 전환됩니다. 마지막으로 도메인은 API를 통해 다른 도메인과 통합되도록 구성되어 배포, 테스트 및 관찰이 가능한 총체적이고 역동적이며 끊임없이 진화하는 하드웨어 라이프사이클 시스템을 형성합니다. 다른 모든 생산 시스템과 마찬가지로.

이 접근 방식을 채택함으로써 우리는 도구와 자동화를 만들어 많은 문제를 올바르게 해결할 수 있었습니다.

도메인 필요

초기에는 이메일과 스프레드시트가 수요를 충족할 수 있는 실행 가능한 방법이었지만, 특히 서버 수와 ​​수신 요청량이 특정 수준에 도달한 경우에는 성공적인 솔루션이 아니었습니다. 급속한 확장에 직면하여 들어오는 요청을 더 효과적으로 구성하고 우선순위를 지정하기 위해 우리는 다음을 제공할 수 있는 티켓팅 시스템을 사용해야 했습니다.

• 관련 필드만 보기를 사용자 정의하는 기능(간단)
• 개방형 API(확장 가능)
• 우리 팀에 알려짐 (이해함)
• 기존 워크플로와의 통합(통합)

우리는 Jira를 사용하여 스프린트와 내부 작업을 관리하므로 고객이 티켓을 제출하고 결과를 추적하는 데 도움이 되는 또 다른 프로젝트를 만들기로 결정했습니다. 들어오는 요청과 내부 작업 관리에 Jira를 사용하면 모든 프로세스를 전체적으로 볼 수 있는 단일 Kanban 보드를 만들 수 있었습니다. 우리 내부 "클라이언트"는 추가 작업(예: 도구 개선, 버그 수정)에 대한 덜 중요한 세부 사항을 조사하지 않고 장비에 대한 요청만 보았습니다.

Jira의 칸반 보드

보너스로 이제 모든 사람이 대기열과 우선순위를 볼 수 있다는 사실로 인해 특정 요청이 "대기열의 어느 위치"에 있었고 그 이전에 무엇이 있었는지 이해할 수 있게 되었습니다. 이를 통해 소유자는 당사에 연락하지 않고도 요청의 우선순위를 다시 설정할 수 있었습니다. 드래그하면 그게 다입니다. 또한 Jira에서 생성된 지표를 기반으로 요청 유형에 따라 SLA를 모니터링하고 평가할 수 있었습니다.

장비 수명주기 영역

각 서버 랙에 사용되는 하드웨어 관리의 복잡성을 상상해 보십시오. 더 나쁜 점은 많은 하드웨어(RAM, ROM)가 창고에서 서버실로 옮겨질 수 있다는 것입니다. 또한 실패하거나 삭제되어 교체/수리를 위해 공급업체에 반환됩니다. 이 모든 내용은 장비의 물리적 유지 관리에 참여하는 코로케이션 서비스 직원에게 전달되어야 합니다. 이러한 문제를 해결하기 위해 우리는 Floppy라는 내부 도구를 만들었습니다. 그의 임무는 다음과 같습니다.

• 현장 직원과의 커뮤니케이션을 관리하고 모든 정보를 집계합니다.
• 완료되고 검증된 각 장비 유지 관리 작업 후에 "창고" 데이터를 업데이트합니다.

결과적으로 웨어하우스는 모든 측정 항목을 표시하는 데 사용되는 Grafana를 사용하여 시각화됩니다. 따라서 우리는 창고 시각화 및 기타 생산 요구 사항에 동일한 도구를 사용합니다.

Grafana의 창고 장비 제어판

보증이 적용되는 서버 장치의 경우 Dispatcher라고 하는 다른 도구를 사용합니다. 그:

• 시스템 로그를 수집합니다.
• 공급업체가 요구하는 형식으로 보고서를 생성합니다.
• API를 통해 공급업체로부터 요청을 생성합니다.
• 진행 상황을 추가로 추적하기 위해 애플리케이션 식별자를 수신하고 저장합니다.

당사의 청구가 승인되면(보통 업무 시간 내) 예비 부품이 해당 데이터 센터로 전송되어 직원이 승인합니다.

젠킨스 콘솔 출력

통신 영역

끊임없이 증가하는 용량이 필요한 비즈니스의 급속한 성장에 발맞추기 위해 우리는 로컬 데이터 센터의 기술 전문가와 협력하는 방식을 조정해야 했습니다. 처음에는 확장이 새로운 서버 구입을 의미했다면 통합 프로젝트(Kubernetes로의 전환을 기반으로 함) 후에는 완전히 다른 것이 되었습니다. "랙 추가"에서 "서버 용도 변경"으로의 진화.

새로운 접근 방식을 사용하려면 데이터 센터 직원과 보다 편안하게 상호 작용할 수 있는 새로운 도구도 필요했습니다. 이러한 도구는 다음을 위해 필요했습니다.

• 간단;
• 자치;
• 능률;
• 신뢰할 수 있음.

우리는 체인에서 우리 자신을 배제하고 기술자들이 서버 장비를 직접 다룰 수 있도록 업무를 구조화해야 했습니다. 우리의 개입 없이 작업량, 근무 시간, 장비 가용성 등과 관련된 모든 문제를 정기적으로 제기하지 않고.

이를 달성하기 위해 우리는 모든 데이터 센터에 iPad를 설치했습니다. 서버에 연결하면 다음과 같은 일이 발생합니다.

• 장치는 이 서버에 실제로 일부 작업이 필요함을 확인합니다.
• 서버에서 실행 중인 애플리케이션이 닫힙니다(필요한 경우).
• 필요한 단계를 설명하는 일련의 작업 지침이 Slack 채널에 게시됩니다.
• 작업이 완료되면 장치는 서버의 최종 상태가 올바른지 확인합니다.
• 필요한 경우 응용 프로그램을 다시 시작합니다.

또한 기술자를 돕기 위해 Slack 봇도 준비했습니다. 다양한 기능(우리는 지속적으로 기능을 확장하고 있었습니다) 덕분에 봇은 작업을 더 쉽게 만들고 우리의 삶을 훨씬 더 쉽게 만들었습니다. 이러한 방식으로 우리는 서버의 용도를 변경하고 유지 관리하는 대부분의 프로세스를 최적화하여 워크플로에서 스스로를 제거했습니다.

우리 데이터 센터 중 하나에 있는 iPad

하드웨어 도메인

데이터 센터 인프라를 안정적으로 확장하려면 각 구성 요소에 대한 우수한 가시성이 필요합니다. 예를 들면 다음과 같습니다.

• 하드웨어 장애 감지
• 서버 상태(활성, 호스팅, 좀비 등)
• 소비 전력
• 펌웨어 버전
• 전체 비즈니스에 대한 분석

우리의 솔루션을 통해 우리는 장비를 구입하는 방법, 장소, 시기, 때로는 실제로 필요하기 전에도 결정할 수 있습니다. 또한 다양한 장비의 부하 수준을 파악하여 향상된 리소스 할당을 달성할 수 있었습니다. 특히 에너지 소비. 이제 우리는 랙에 서버를 설치하고 전원에 연결하기 전, 수명 주기 전반에 걸쳐 최종적으로 폐기될 때까지 서버 배치에 대해 정보에 입각한 결정을 내릴 수 있습니다.

Grafana의 에너지 대시보드

그러다가 코로나19가 나타났는데...

우리 팀은 미디어 회사와 게시자가 온라인에서 방문자가 관심을 가질 수 있는 관련 콘텐츠, 제품 및 서비스를 찾을 수 있도록 지원하는 기술을 개발합니다. 우리의 인프라는 흥미로운 뉴스가 발표될 때 생성되는 트래픽을 제공하도록 설계되었습니다.

코로나19를 둘러싼 언론의 집중적인 보도와 트래픽 증가로 인해 우리는 이러한 압력에 대처하는 방법을 시급히 배워야 했습니다. 더욱이 이 모든 일은 공급망이 중단되고 대부분의 직원이 집에 있는 글로벌 위기 중에 수행되어야 했습니다.

그러나 우리가 말했듯이 우리 모델은 이미 다음을 가정합니다.

• 데이터 센터의 장비는 대부분 물리적으로 접근할 수 없습니다.
•  우리는 거의 모든 물리적 작업을 원격으로 수행합니다.
• 작업은 비동기식, 자율적, 대규모로 수행됩니다.
• 우리는 새로운 장비를 구매하는 대신 "부품으로 제작" 방식을 사용하여 장비 수요를 충족합니다.
• 우리는 단지 일상적인 수리를 수행하는 것이 아니라 새로운 것을 창조할 수 있는 창고를 가지고 있습니다.

따라서 많은 기업이 데이터 센터에 물리적으로 접근할 수 없도록 하는 글로벌 제한은 우리에게 거의 영향을 미치지 않았으며 예비 부품과 서버에 관해서는 장비의 안정적인 작동을 보장하려고 노력했습니다. 그러나 이는 갑자기 일부 하드웨어를 사용할 수 없다는 것이 밝혀졌을 때 발생할 수 있는 사고를 방지하기 위한 목적으로 수행되었습니다. 우리는 현재 수요를 충족하려는 목표 없이 준비금이 채워졌는지 확인했습니다.

요약하자면, 데이터 센터 업계에서 일하는 우리의 접근 방식은 좋은 코드 디자인의 원칙을 데이터 센터의 물리적 관리에 적용하는 것이 가능하다는 것을 입증했다고 말하고 싶습니다. 그리고 아마도 당신은 그것이 흥미로울 것입니다.

원본 : tyts

출처 : habr.com