🥇사이버펑크의 맛을 더한 클라우드 서비스 탄생의 역사

IT 분야에서 일하면서 시스템에는 고유한 특성이 있다는 것을 깨닫기 시작합니다. 그들은 유연하고, 조용하고, 기이하고, 엄격할 수 있습니다. 그들은 끌어당길 수도 있고 밀어낼 수도 있습니다. 어떤 식으로든 그들과 "협상"하고 "함정" 사이를 조종하며 상호 작용의 사슬을 구축해야 합니다.

그래서 우리는 클라우드 플랫폼을 구축하는 영광을 누렸고 이를 위해 우리와 협력할 몇 가지 하위 시스템을 "설득"해야 했습니다. 다행스럽게도 우리는 "API 언어"와 직접적인 손길, 그리고 많은 열정을 가지고 있습니다.

이 기사는 기술적으로 하드코어하지는 않지만 클라우드를 구축하는 동안 직면한 문제에 대해 설명합니다. 나는 우리가 시스템과 공통 언어를 찾는 방법과 그 결과에 대한 가벼운 기술적 환상의 형태로 우리의 길을 설명하기로 결정했습니다.

고양이에 오신 것을 환영합니다.

여행의 시작

얼마 전 우리 팀은 고객을 위한 클라우드 플랫폼을 출시하는 임무를 맡았습니다. 우리는 관리 지원, 리소스, 하드웨어 스택을 갖고 서비스의 소프트웨어 부분을 구현하기 위한 기술을 자유롭게 선택할 수 있었습니다.

또한 다음과 같은 여러 가지 요구 사항이 있었습니다.

서비스를 이용하려면 편리한 개인 계정이 필요합니다.
플랫폼은 기존 청구 시스템에 통합되어야 합니다.
소프트웨어 및 하드웨어: OpenStack + Tungsten Fabric(Open Contrail), 우리 엔지니어들은 이를 아주 잘 "요리"하는 방법을 배웠습니다.

Habra 커뮤니티가 관심을 갖고 계신다면 팀 구성, 개인 계정 인터페이스 개발 및 디자인 결정 방법에 대해 다시 말씀드리겠습니다.
우리가 사용하기로 결정한 도구는 다음과 같습니다.

Python + Flask + Swagger + SQLAlchemy - 완전히 표준적인 Python 세트입니다.
프론트엔드용 Vue.js;
우리는 AMQP를 통해 Celery를 사용하여 구성 요소와 서비스 간의 상호 작용을 수행하기로 결정했습니다.

Python 선택에 대한 질문을 예상하여 설명하겠습니다. 이 언어는 우리 회사에서 틈새 시장을 찾았고, 작지만 여전히 문화가 그것을 중심으로 발전했습니다. 따라서 이에 서비스 구축을 시작하기로 결정했습니다. 더욱이, 그러한 문제의 발전 속도는 종종 결정적입니다.

그럼 우리의 친분을 시작합시다.

자동 청구서 - 청구

우리는 이 사람을 오랫동안 알고 있었습니다. 그는 항상 내 옆에 앉아 조용히 무언가를 세었습니다. 때때로 그는 사용자 요청을 우리에게 전달하고 고객 송장을 발행하고 서비스를 관리했습니다. 열심히 일하는 평범한 남자. 사실, 어려움도 있었습니다. 그는 조용하고, 때로는 사려 깊고, 종종 자기 생각에 빠져 있습니다.

빌링은 우리가 친구를 사귀려고 시도한 첫 번째 시스템입니다. 그리고 우리가 직면한 첫 번째 어려움은 서비스를 처리할 때였습니다.

예를 들어 작업이 생성되거나 삭제되면 내부 청구 대기열로 이동됩니다. 따라서 서비스와의 비동기 작업 시스템이 구현됩니다. 서비스 유형을 처리하려면 작업을 이 대기열에 "넣어야" 했습니다. 그리고 여기서 우리는 문서가 부족하다는 문제에 직면했습니다.

소프트웨어 API의 설명으로 판단하면 여전히 이 문제를 해결할 수 있지만 리버스 엔지니어링을 수행할 시간이 없었기 때문에 로직을 외부로 가져와 RabbitMQ 위에 작업 대기열을 구성했습니다. 서비스 작업은 클라이언트가 개인 계정에서 시작하고 백엔드에서 Celery "작업"으로 전환되며 청구 및 OpenStack 측에서 수행됩니다. Celery를 사용하면 작업 관리, 반복 구성 및 상태 모니터링이 매우 편리합니다. 예를 들어 "셀러리"에 대해 더 자세히 읽을 수 있습니다. 여기에.

또한 빌링으로 인해 자금이 부족한 프로젝트가 중단되지 않았습니다. 개발자들과 대화하면서 우리는 통계를 계산할 때(그리고 정확히 이러한 종류의 논리를 구현해야 함) 중지 규칙 사이에 복잡한 상호 관계가 있다는 것을 알게 되었습니다. 그러나 이러한 모델은 우리의 현실과 잘 맞지 않습니다. 또한 서비스 관리 로직을 백엔드 측으로 가져가서 Celery의 작업을 통해 구현했습니다.

위의 두 가지 문제로 인해 코드가 약간 비대해졌고 앞으로는 작업 작업 로직을 별도의 서비스로 옮기기 위해 리팩토링해야 할 것입니다. 또한 이 논리를 지원하려면 사용자 및 해당 서비스에 대한 일부 정보를 테이블에 저장해야 합니다.

또 다른 문제는 침묵이다.

Billy는 일부 API 요청에 자동으로 "Ok"라고 응답합니다. 예를 들어 테스트 중에 약속된 지불금을 지불한 경우가 여기에 해당합니다(자세한 내용은 나중에 설명). 요청이 올바르게 실행되었으며 오류가 표시되지 않았습니다.

UI를 통해 시스템을 작업하면서 로그를 공부해야 했습니다. 청구 자체도 유사한 요청을 수행하여 특정 사용자(예: admin)로 범위를 변경하고 이를 su 매개변수에 전달하는 것으로 나타났습니다.

일반적으로 문서의 공백과 사소한 API 결함에도 불구하고 모든 것이 잘 진행되었습니다. 로그의 구조와 찾아야 할 내용을 이해하면 로드가 심한 경우에도 로그를 읽을 수 있습니다. 데이터베이스의 구조는 화려하지만 매우 논리적이며 어떤 면에서는 매력적이기도 합니다.

요약하면 상호 작용 단계에서 직면한 주요 문제는 특정 시스템의 구현 기능과 관련이 있습니다.

어떤 식으로든 우리에게 영향을 미친 문서화되지 않은 “기능”;
비공개 소스(청구서는 C++로 작성됨)로 인해 "시행착오" 이외의 다른 방법으로는 문제 1을 해결하는 것이 불가능합니다.

다행스럽게도 이 제품에는 상당히 광범위한 API가 있으며 다음 하위 시스템을 개인 계정에 통합했습니다.

기술 지원 모듈 - 개인 계정의 요청은 서비스 클라이언트에 대해 투명하게 청구되도록 "대리"됩니다.
금융 모듈 - 현재 고객에게 송장을 발행하고 상각하고 지불 문서를 생성할 수 있습니다.
서비스 제어 모듈 - 이를 위해 우리는 자체 핸들러를 구현해야 했습니다. 시스템의 확장성은 우리 손에 달려 있었고 우리는 Billy에게 새로운 유형의 서비스를 "가르쳤습니다".
조금 번거롭긴 했지만 어쨌든 빌리와 나는 사이좋게 지낼 수 있을 것 같아요.

텅스텐 지대를 걷다 – Tungsten Fabric

수백 개의 전선이 흩어져 있는 텅스텐 필드는 이를 통해 수천 비트의 정보를 전달합니다. 정보는 마치 마술처럼 "패킷"으로 수집되고 구문 분석되어 복잡한 경로를 구축합니다.

이는 우리가 친구를 사귀어야 했던 두 번째 시스템인 Tungsten Fabric(TF), 이전 OpenContrail의 도메인입니다. 그 임무는 네트워크 장비를 관리하고 사용자인 우리에게 소프트웨어 추상화를 제공하는 것입니다. TF - SDN은 네트워크 장비 작업의 복잡한 논리를 캡슐화합니다. 기술 자체에 대한 좋은 기사가 있습니다. 예를 들어, 여기에.

시스템은 Neutron 플러그인을 통해 OpenStack(아래 설명)과 통합됩니다.

OpenStack 서비스의 상호 작용.

운영 부서 직원들이 우리에게 이 시스템을 소개했습니다. 우리는 시스템의 API를 사용하여 서비스의 네트워크 스택을 관리합니다. 아직 심각한 문제나 불편을 초래하지는 않았지만(OE 직원의 입장에서는 말할 수 없습니다) 상호 작용에 몇 가지 이상한 점이 있었습니다.

첫 번째는 다음과 같습니다. SSH를 통해 연결할 때 인스턴스 콘솔에 대량의 데이터를 출력해야 하는 명령은 단순히 연결을 "중지"했지만 VNC를 통해서는 모든 것이 올바르게 작동했습니다.

이 문제에 익숙하지 않은 사람들에게는 꽤 재미있어 보입니다. ls /root는 올바르게 작동하지만 예를 들어 top은 완전히 "정지"됩니다. 다행히도 이전에도 비슷한 문제가 발생했습니다. 컴퓨팅 노드에서 라우터로의 경로에서 MTU를 조정하여 결정되었습니다. 그건 그렇고, 이것은 TF 문제가 아닙니다.

다음 문제는 바로 코앞에 있었습니다. 어느 “아름다운” 순간에 라우팅의 마법이 그렇게 사라졌습니다. TF는 장비의 라우팅 관리를 중단했습니다.

우리는 관리자 수준에서 Openstack을 사용하여 작업한 후 필수 사용자 수준으로 이동했습니다. SDN은 작업을 수행하는 사용자의 범위를 "탈취"하는 것처럼 보입니다. 사실은 TF와 OpenStack을 연결하는 데 동일한 관리자 계정이 사용된다는 것입니다. 사용자로 전환하는 단계에서 '마법'이 사라졌습니다. 시스템 작업을 위해 별도의 계정을 만들기로 결정했습니다. 이를 통해 통합 기능을 중단하지 않고 작업할 수 있었습니다.

실리콘 생명체 - OpenStack

기괴한 모양의 실리콘 생물이 텅스텐 필드 근처에 살고 있습니다. 무엇보다 한 번의 스윙으로 우리를 짓밟을 수 있는 자란 아이처럼 보이지만 그에게서 오는 명백한 공격성은 없습니다. 두려움을 불러일으키지는 않지만 그 크기는 두려움을 불러일으킵니다. 주변에서 일어나는 일의 복잡성도 마찬가지입니다.

OpenStack은 우리 플랫폼의 핵심입니다.

OpenStack에는 여러 하위 시스템이 있으며 현재 Nova, Glance 및 Cinder를 가장 적극적으로 사용하고 있습니다. 각각에는 자체 API가 있습니다. Nova는 컴퓨팅 리소스와 인스턴스 생성을 담당하고, Cinder는 볼륨과 스냅샷 관리를 담당하며, Glance는 OS 템플릿과 그에 대한 메타정보를 관리하는 이미지 서비스입니다.

각 서비스는 컨테이너에서 실행되며 메시지 브로커는 "흰 토끼"인 RabbitMQ입니다.

이 시스템은 우리에게 가장 예상치 못한 문제를 안겨주었습니다.

그리고 첫 번째 문제는 서버에 추가 볼륨을 연결하려고 할 때 오래지 않아 발생했습니다. Cinder API는 이 작업 수행을 단호하게 거부했습니다. 좀 더 정확히 말하면 OpenStack 자체를 믿으면 연결은 되지만 가상 서버 내부에는 디스크 장치가 없습니다.

우리는 우회하기로 결정하고 Nova API에 동일한 작업을 요청했습니다. 결과적으로 장치가 올바르게 연결되고 서버 내에서 액세스할 수 있게 됩니다. 블록스토리지가 Cinder에 응답하지 않을 때 문제가 발생하는 것으로 보입니다.

디스크로 작업할 때 또 다른 어려움이 우리를 기다리고 있었습니다. 서버에서 시스템 볼륨의 연결을 끊을 수 없습니다.

다시 말하지만, OpenStack 자체는 연결이 끊어졌음을 "맹세"하므로 이제 볼륨을 별도로 올바르게 작업할 수 있습니다. 그러나 API는 디스크에서 작업을 수행하는 것을 절대적으로 원하지 않았습니다.

여기서 우리는 특별히 싸우지 않고 서비스 논리에 대한 관점을 바꾸기로 결정했습니다. 인스턴스가 있으면 시스템 볼륨도 있어야 합니다. 따라서 사용자는 "서버"를 삭제하지 않고는 시스템 "디스크"를 제거하거나 비활성화할 수 없습니다.

OpenStack은 자체 상호 작용 논리와 화려한 API를 갖춘 다소 복잡한 시스템 세트입니다. 우리는 상당히 상세한 문서와 물론 시행착오를 통해 도움을 받았습니다(그것이 없었다면 우리는 어디에 있었겠습니까).

테스트 실행

지난해 XNUMX월 테스트 출시를 진행했습니다. 주요 임무는 기술적인 측면과 UX 측면에서 전투 모드로 프로젝트를 테스트하는 것이었습니다. 관객을 선별적으로 초대해 테스트를 종료했다. 그러나 우리 웹사이트에서 테스트에 대한 접근을 요청할 수 있는 옵션도 남겨두었습니다.

물론 테스트 자체에는 재미있는 순간이 없지 않았습니다. 왜냐하면 이것이 우리의 모험이 이제 막 시작되는 곳이기 때문입니다.

첫째, 우리는 프로젝트에 대한 관심을 다소 잘못 평가하여 테스트 중에 컴퓨팅 노드를 빠르게 추가해야 했습니다. 클러스터의 일반적인 경우이지만 여기에도 약간의 뉘앙스가 있었습니다. 특정 TF 버전에 대한 문서는 vRouter 작업이 테스트된 특정 커널 버전을 나타냅니다. 우리는 최신 커널로 노드를 시작하기로 결정했습니다. 결과적으로 TF는 노드로부터 경로를 수신하지 못했습니다. 급히 커널을 롤백해야 했습니다.

또 다른 호기심은 개인 계정의 "비밀번호 변경" 버튼 기능과 관련이 있습니다.

우리는 세션 작업을 하지 않도록 JWT를 사용하여 개인 계정에 대한 액세스를 구성하기로 결정했습니다. 시스템이 다양하고 널리 분산되어 있기 때문에 우리는 청구 세션과 OpenStack 토큰을 "래핑"하는 자체 토큰을 관리합니다. 비밀번호가 변경되면 사용자 데이터가 더 이상 유효하지 않아 재발급이 필요하므로 토큰은 "잘못됩니다".

우리는 이 점을 간과했고, 이 작품을 빨리 끝내기에는 자원이 충분하지 않았습니다. 테스트를 시작하기 직전에 기능을 중단해야 했습니다.
현재는 비밀번호가 변경된 경우 사용자를 로그아웃합니다.

이러한 미묘한 차이에도 불구하고 테스트는 잘 진행되었습니다. 몇 주 만에 약 300명이 들렀습니다. 우리는 사용자의 눈으로 제품을 보고, 실제로 테스트하고, 높은 품질의 피드백을 수집할 수 있었습니다.

계속하기

우리 중 많은 사람들에게 이것은 이 규모의 첫 번째 프로젝트입니다. 우리는 팀으로 일하고 건축 및 디자인 결정을 내리는 방법에 대해 많은 귀중한 교훈을 배웠습니다. 적은 리소스로 복잡한 시스템을 통합하고 이를 프로덕션에 적용하는 방법.

물론 코드 측면과 시스템 통합 인터페이스 측면에서 작업해야 할 부분이 있습니다. 이 프로젝트는 아직 초기 단계이지만 신뢰할 수 있고 편리한 서비스로 성장시키려는 야망으로 가득 차 있습니다.

우리는 이미 시스템을 설득할 수 있었습니다. Bill은 자신의 옷장에서 계산, 청구 및 사용자 요청을 성실하게 처리합니다. 텅스텐장의 '마법'은 우리에게 안정적인 통신을 제공합니다. 그리고 OpenStack만이 "WSREP이 아직 애플리케이션 사용을 위한 노드를 준비하지 않았습니다."와 같은 말을 외치며 변덕스러워지는 경우가 있습니다. 하지만 그건 전혀 다른 이야기인데...

최근 서비스를 출시했습니다.
우리의 모든 세부 사항을 찾을 수 있습니다 온라인으로.

CLO개발팀

유용한 링크

OpenStack

텅스텐 직물

출처 : habr.com

사이버펑크를 곁들인 클라우드 서비스 탄생의 역사