Kubernetes 및 자동화 덕분에 XNUMX시간 만에 클라우드로 마이그레이션하는 방법

URUS 회사는 다양한 형태로 Kubernetes를 시도했습니다. 즉, 베어메탈, Google Cloud에 독립적으로 배포한 다음 플랫폼을 Mail.ru Cloud Solutions(MCS) 클라우드로 이전했습니다. Igor Shishkin은 새로운 클라우드 제공업체를 선택한 방법과 기록적인 XNUMX시간 만에 어떻게 마이그레이션할 수 있었는지 설명합니다(t3ran), URUS의 수석 시스템 관리자입니다.

우루스는 무슨 일을 하나요?

도시 환경의 질을 향상시키는 방법에는 여러 가지가 있는데, 그 중 하나가 도시를 환경친화적으로 만드는 것입니다. 이것이 바로 스마트 디지털 서비스 회사인 URUS가 작업하고 있는 작업입니다. 여기서 그들은 기업이 중요한 환경 지표를 모니터링하고 환경에 대한 부정적인 영향을 줄이는 데 도움이 되는 솔루션을 구현합니다. 센서는 공기 구성, 소음 수준 및 기타 매개변수에 대한 데이터를 수집한 다음 분석 및 권장 사항을 위해 통합 URUS-Ekomon 플랫폼으로 보냅니다.

URUS가 내부에서 작동하는 방식

URUS의 대표적인 고객은 주거지역이나 그 인근에 위치한 회사입니다. 이는 공장, 항구, 철도 기지 또는 기타 시설일 수 있습니다. 고객이 이미 경고를 받았거나, 환경 오염으로 인해 벌금을 부과받았거나, 소음을 줄이고 유해한 배출량을 줄이려는 경우 고객이 우리에게 오며 우리는 이미 환경 모니터링을 위한 기성 솔루션을 제공합니다.

H2S 농도 모니터링 그래프는 인근 공장의 정기적인 야간 배출을 보여줍니다.

URUS에서 사용하는 장치에는 환경 상황을 평가하기 위해 특정 가스의 함량, 소음 수준 및 기타 데이터에 대한 정보를 수집하는 여러 센서가 포함되어 있습니다. 정확한 센서 수는 항상 특정 작업에 따라 결정됩니다.

측정의 세부 사항에 따라 센서가 있는 장치는 건물 벽, 기둥 및 기타 임의의 장소에 위치할 수 있습니다. 이러한 각 장치는 정보를 수집하고 집계하여 데이터 수신 게이트웨이로 보냅니다. 장기 보관을 위해 데이터를 저장하고 후속 분석을 위해 사전 처리합니다. 분석 결과로 얻은 가장 간단한 예는 AQI라고도 알려진 대기질 지수입니다.

이와 동시에 다른 많은 서비스도 우리 플랫폼에서 운영되지만 주로 서비스 성격을 띠고 있습니다. 예를 들어 알림 서비스는 모니터링되는 매개변수(예: CO2 함량)가 허용 값을 초과하는 경우 클라이언트에 알림을 보냅니다.

데이터를 저장하는 방법. 베어메탈 기반 Kubernetes 이야기

URUS 환경 모니터링 프로젝트에는 여러 데이터 창고가 있습니다. 하나에서는 "원시" 데이터, 즉 장치 자체에서 직접 받은 데이터를 보관합니다. 이 저장소는 모든 표시기의 기록을 포함하는 오래된 카세트 테이프와 같은 "자기" 테이프입니다. 두 번째 유형의 저장소는 전처리된 데이터(센서 간의 연결과 장치 자체의 판독값, 조직, 위치 등과의 제휴 등에 대한 메타데이터가 풍부한 장치의 데이터)에 사용됩니다. 이 정보를 사용하면 특정 지표가 어떻게 작동하는지 동적으로 평가할 수 있습니다. 일정 기간 동안 변경되었습니다. 당사는 “원시” 데이터 저장소를 무엇보다도 백업으로 사용하고 필요한 경우 전처리된 데이터를 복원합니다.

몇 년 전 스토리지 문제를 해결하려고 했을 때 Kubernetes와 OpenStack이라는 두 가지 플랫폼을 선택할 수 있었습니다. 그러나 후자가 상당히 괴물처럼 보이기 때문에(이 사실을 확인하려면 아키텍처를 살펴보십시오) 우리는 Kubernetes를 선택했습니다. 이를 지지하는 또 다른 주장은 상대적으로 단순한 소프트웨어 제어, 즉 리소스에 따라 하드웨어 노드까지 보다 유연하게 자를 수 있는 능력이었습니다.

Kubernetes 자체를 마스터하는 것과 병행하여 데이터를 저장하는 방법도 연구했으며 Kubernetes의 모든 스토리지를 자체 하드웨어에 유지하면서 뛰어난 전문 지식을 얻었습니다. 그 당시 우리가 Kubernetes에 살았던 모든 것: 상태 저장 스토리지, 모니터링 시스템, CI/CD. Kubernetes는 우리에게 올인원 플랫폼이 되었습니다.

그러나 우리는 Kubernetes를 서비스로 사용하고 싶었고 지원 및 개발에는 참여하지 않았습니다. 게다가 베어메탈에서 유지하는 데 비용이 많이 들고 지속적으로 개발이 필요했습니다! 예를 들어, 첫 번째 작업 중 하나는 Kubernetes Ingress 컨트롤러를 조직의 네트워크 인프라에 통합하는 것이었습니다. 특히 그 당시에는 DNS 레코드나 IP 주소 할당과 같은 프로그래밍 방식의 리소스 관리를 위한 준비가 되어 있지 않았다는 점을 고려하면 이는 번거로운 작업입니다. 나중에 우리는 외부 데이터 저장소를 실험하기 시작했습니다. 우리는 PVC 컨트롤러를 구현해 본 적이 없었지만, 그럼에도 불구하고 이것이 전담 전문가가 필요한 넓은 작업 영역이라는 것이 분명해졌습니다.

Google Cloud Platform으로의 전환은 임시 해결책입니다.

우리는 이것이 계속될 수 없다는 것을 깨닫고 데이터를 베어메탈에서 Google Cloud Platform으로 옮겼습니다. 사실 당시 러시아 회사에는 흥미로운 옵션이 많지 않았습니다. Google Cloud Platform 외에 Amazon만이 유사한 서비스를 제공했지만 우리는 여전히 Google의 솔루션을 선택했습니다. 그런 다음 Google 자체가 프로덕션에서 일종의 PoC Kubernetes라는 사실은 말할 것도 없고 업스트림에 더 가깝고 경제적으로 더 수익성이 있는 것처럼 보였습니다.

고객 기반이 성장함에 따라 첫 번째 주요 문제가 나타났습니다. 개인 데이터를 저장해야 했을 때 우리는 선택의 기로에 섰습니다. Google과 협력하여 러시아 법률을 위반하거나, 아니면 러시아 연방에서 대안을 찾고 있는 것입니다. 선택은 전체적으로 예측 가능했습니다. 🙂

이상적인 클라우드 서비스를 본 방법

검색을 시작할 때 우리는 미래의 클라우드 제공업체로부터 무엇을 얻고 싶은지 이미 알고 있었습니다. 우리가 찾고 있던 서비스는 무엇입니까?

• 빠르고 유연함. 이를 통해 언제든지 새 노드를 신속하게 추가하거나 무언가를 배포할 수 있습니다.
• 저렴. 우리는 자원이 부족했기 때문에 재정 문제에 대해 매우 걱정했습니다. 우리는 Kubernetes를 사용하고 싶다는 것을 이미 알고 있었으며 이제 이 솔루션 사용의 효율성을 높이거나 최소한 유지하기 위해 비용을 최소화하는 것이 과제였습니다.
• 자동화됨. 우리는 관리자나 전화 통화, 비상 모드에서 수십 개의 노드를 수동으로 올려야 하는 상황 없이 API를 통해 서비스 작업을 할 계획이었습니다. 대부분의 프로세스가 자동화되어 있으므로 클라우드 서비스에서도 동일한 결과를 기대했습니다.
• 러시아 연방에 있는 서버. 물론 우리는 러시아 법률과 동일한 152-FZ를 준수할 계획이었습니다.

당시 러시아에는 Kubernetes aaS 제공업체가 거의 없었으며, 제공업체를 선택할 때 우선순위를 타협하지 않는 것이 중요했습니다. 우리와 함께 작업을 시작했고 여전히 협력하고 있는 Mail.ru 클라우드 솔루션 팀은 API 지원과 Horizon을 포함하는 편리한 제어판을 갖춘 완전히 자동화된 서비스를 제공했습니다. 이를 통해 우리는 임의의 수의 노드를 신속하게 늘릴 수 있었습니다.

XNUMX시간 만에 MCS로 마이그레이션한 방법

이러한 움직임에 많은 기업들이 어려움과 좌절을 겪게 되지만, 우리의 경우에는 그런 일이 없었습니다. 운이 좋았습니다. 마이그레이션이 시작되기 전에 이미 Kubernetes 작업을 하고 있었기 때문에 파일 세 개를 수정하고 새로운 클라우드 플랫폼인 MCS에서 서비스를 시작했습니다. 그 무렵 우리는 마침내 베어메탈을 떠나 Google Cloud Platform에서 살았다는 점을 상기시켜 드리겠습니다. 따라서 이동 자체에는 XNUMX시간이 채 걸리지 않았으며 장치에서 데이터를 복사하는 데 약간의 시간(약 XNUMX시간)이 소요되었습니다. 그 당시 우리는 이미 Spinnaker(지속적인 전달을 제공하는 멀티 클라우드 CD 서비스)를 사용하고 있었습니다. 또한 이를 새 클러스터에 신속하게 추가하고 평소와 같이 계속 작업했습니다.

개발 프로세스와 CI/CD의 자동화 덕분에 URUS의 Kubernetes는 한 명의 전문가(그리고 바로 저)가 처리합니다. 어떤 단계에서 다른 시스템 관리자가 나와 함께 일했지만 우리가 이미 모든 기본 루틴을 자동화했고 기본 제품 부분에 점점 더 많은 작업이 있다는 것이 밝혀졌으며 이에 리소스를 할당하는 것이 합리적이었습니다.

우리는 환상 없이 협력을 시작했기 때문에 클라우드 제공업체로부터 기대했던 것을 받았습니다. 사고가 발생한 경우 대부분 기술적 문제였으며 서비스의 상대적 신선도로 쉽게 설명할 수 있는 사고였습니다. 가장 중요한 점은 MCS팀이 빠르게 단점을 보완하고, 메신저로 질문에 빠르게 답변한다는 점이다.

Google Cloud Platform에 대한 내 경험을 비교해 보면 피드백 버튼이 전혀 필요하지 않았기 때문에 피드백 버튼이 어디에 있는지조차 몰랐습니다. 그리고 문제가 발생하면 구글 자체적으로 일방적으로 알림을 보냈습니다. 하지만 MCS의 경우 가장 큰 장점은 지리적으로나 정신적으로나 러시아 고객과 최대한 가깝다는 점이라고 생각합니다.

미래에 클라우드를 활용하는 방법

이제 우리의 작업은 Kubernetes와 밀접하게 연결되어 있으며 인프라 작업의 관점에서 우리에게 완전히 적합합니다. 따라서 일상적인 작업을 단순화하고 새로운 작업을 자동화하고 서비스의 안정성과 신뢰성을 높이기 위해 지속적으로 새로운 관행과 서비스를 도입하고 있지만 어디에서나 마이그레이션할 계획은 없습니다... 이제 Chaos Monkey 서비스를 출시합니다(구체적으로). , 우리는 카오스쿠베를 사용하지만 이것이 원래 Netflix에서 만든 개념을 바꾸지는 않습니다: ). Chaos Monkey는 한 가지 간단한 작업을 수행합니다. 즉, 임의의 시간에 임의의 Kubernetes Pod를 삭제합니다. 이는 서비스가 n-1개의 인스턴스 수로 정상적으로 작동하는 데 필요하므로 어떤 문제에 대비할 수 있도록 스스로 훈련합니다.

이제 저는 동일한 클라우드 플랫폼인 타사 솔루션을 사용하는 것이 젊은 기업에게 유일하게 옳은 일이라고 생각합니다. 일반적으로 여행 초기에는 인적, 재정적 자원이 제한되어 있으며 자체 클라우드나 데이터 센터를 구축하고 유지하는 데 비용이 많이 들고 노동 집약적입니다. 클라우드 공급자를 사용하면 이러한 비용을 최소화할 수 있으며, 지금 여기에서 서비스 운영에 필요한 리소스를 신속하게 확보하고 사후에 이러한 리소스에 대한 비용을 지불할 수 있습니다. URUS 회사는 당분간 클라우드에서 Kubernetes에 충실할 것입니다. 하지만 지리적으로 확장하거나 특정 장비를 기반으로 솔루션을 구현해야 할 수도 있다는 것을 누가 압니까? 아니면 소비되는 리소스의 양이 예전처럼 베어메탈 기반 Kubernetes를 정당화할 수도 있습니다. 🙂

클라우드 서비스를 사용하면서 배운 것

우리는 베어메탈에서 Kubernetes를 사용하기 시작했고 그곳에서도 나름대로 괜찮았습니다. 하지만 그 강점은 클라우드의 aaS 구성요소로서 정확하게 드러났습니다. 목표를 설정하고 모든 것을 최대한 자동화하면 공급업체 종속을 피할 수 있으며 클라우드 제공업체 간 이동에는 몇 시간이 걸리고 신경 세포는 우리와 함께 유지됩니다. 우리는 다른 회사에 조언할 수 있습니다. 리소스가 제한되어 있고 개발 속도가 최대인 자체 (클라우드) 서비스를 시작하려면 지금 바로 클라우드 리소스를 임대하여 시작하고 Forbes가 귀하에 대해 쓴 후 데이터 센터를 구축하십시오.

출처 : habr.com