🥇사이버펑크로 양념된 클라우드 서비스 창조의 역사

IT 경험이 쌓일수록 시스템에는 고유한 특징이 있다는 것을 깨닫게 됩니다. 시스템은 유순할 수도, 조용할 수도, 변덕스러울 수도, 엄격할 수도 있습니다. 당신을 사로잡을 수도, 밀어낼 수도 있습니다. 어떤 식으로든 시스템과 "협상"하고, "함정" 사이를 헤쳐나가며, 시스템 간의 상호 작용 고리를 구축해야 합니다.

그래서 클라우드 플랫폼을 구축하는 영광을 얻게 되었고, 이를 위해 몇몇 하위 시스템을 우리와 함께 일하도록 "설득"해야 했습니다. 다행히 "API 언어"와 든든한 손길, 그리고 넘치는 열정이 있었습니다.

이 글은 기술적인 내용을 심도 있게 다루지는 않겠지만, 클라우드 구축 과정에서 겪었던 문제들을 설명하고자 합니다. 저는 시스템과의 공통 언어를 어떻게 찾았는지, 그리고 그 결과 어떤 결과가 나왔는지에 대한 가벼운 기술적 상상력의 형태로 저희의 여정을 설명하기로 했습니다.

컷 아래에 오신 것을 환영합니다.

여행의 시작

얼마 전, 저희 팀은 고객을 위한 클라우드 플랫폼 출시를 담당했습니다. 저희는 관리, 리소스, 하드웨어 스택의 지원을 받았고, 서비스의 소프트웨어 부분을 구현하기 위한 기술 선택에 있어 자유로웠습니다.

또한 다음과 같은 몇 가지 요구 사항도 있었습니다.

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

Habr 커뮤니티에 관심이 있으시다면, 팀이 어떻게 구성되었는지, 개인 계정 인터페이스가 어떻게 개발되었는지, 그리고 디자인에 대한 결정이 어떻게 내려졌는지에 대해서는 나중에 말씀드리겠습니다.
우리가 사용하기로 결정한 도구는 다음과 같습니다.

Python + Flask + Swagger + SQLAlchemy는 상당히 표준적인 Python 집합입니다.
프런트엔드는 Vue.js를 사용합니다.
구성 요소와 서비스 간의 상호작용은 AMQP 대신 Celery를 사용하여 수행하기로 결정했습니다.

Python 선택에 대한 질문을 예상하며 설명드리겠습니다. Python은 저희 회사에서 자리를 잡았고, 작지만 여전히 Python을 중심으로 한 문화가 형성되었습니다. 그래서 Python을 기반으로 서비스를 구축하기로 결정했습니다. 게다가 이러한 작업에서는 개발 속도가 종종 중요한 역할을 합니다.

그럼, 우리의 친분을 시작해 볼까요.

무음 청구서 - 청구

이 친구는 오랫동안 알고 지냈어요. 항상 우리 옆에 앉아 묵묵히 뭔가를 세곤 했죠. 가끔은 사용자 요청을 전달하고, 고객 송장을 발행하고, 서비스도 관리해 줬어요. 정말 성실하고 열심히 일하는 분이었어요. 물론 힘든 점도 있었지만요. 조용하고, 가끔은 사려 깊고, 종종 자기 생각을 내비치는 분이었어요.

청구 시스템은 우리가 처음 접해 보려고 했던 시스템입니다. 그런데 가장 먼저 어려움을 겪은 건 서비스 처리였습니다.

예를 들어, 작업을 생성하거나 삭제할 때 해당 작업은 내부 청구 대기열에 저장됩니다. 이것이 바로 서비스를 이용한 비동기 작업 시스템이 구현되는 방식입니다. 서비스 유형을 처리하려면 작업을 이 대기열에 "넣어야" 했습니다. 그런데 여기서 문제가 발생했습니다. 바로 문서화 부족입니다.

소프트웨어 API 설명을 보면 이 작업은 여전히 해결 가능하지만, 리버스 엔지니어링을 할 시간이 부족하여 로직을 외부로 옮기고 RabbitMQ 위에 작업 큐를 구성했습니다. 서비스 작업은 클라이언트가 개인 계정에서 시작하여 백엔드에서 Celery "작업"으로 변환되고 청구 및 OpenStack 측에서 실행됩니다. Celery를 사용하면 작업을 관리하고, 반복 작업을 구성하고, 상태를 매우 편리하게 모니터링할 수 있습니다. "Celery"에 대한 자세한 내용은 다음에서 확인할 수 있습니다. 여기에.

또한, 자금이 바닥났을 때 청구가 프로젝트를 중단시키지 않았습니다. 개발자들과 이야기를 나누면서 통계 계산 시 (그리고 바로 이 로직을 구현해야 합니다) 중단 규칙 간의 복잡한 관계가 있다는 것을 알게 되었습니다. 하지만 이러한 모델은 우리의 현실에 잘 맞지 않았습니다. 또한, 서비스 관리 로직을 백엔드 측으로 이전하여 Celery의 작업을 통해 이를 구현했습니다.

위의 두 가지 문제로 인해 코드가 다소 복잡해졌고, 향후 작업 로직을 별도의 서비스로 옮기기 위해 리팩토링해야 할 것입니다. 또한 이 로직을 지원하기 위해 사용자와 서비스에 대한 일부 정보를 별도의 테이블에 저장해야 합니다.

또 다른 문제는 침묵이다.

Billy는 일부 API 요청에 "OK"라고 조용히 응답합니다. 예를 들어, 테스트 기간 동안 약속된 결제를 완료했을 때 이런 일이 발생했습니다(자세한 내용은 나중에 설명). 요청은 정상적으로 실행되었고 오류는 발견되지 않았습니다.

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

전반적으로 문서의 빈틈과 사소한 API 결함에도 불구하고 모든 것이 순조롭게 진행되었습니다. 로그는 구조와 주의 사항을 이해한다면 부하가 심한 상황에서도 읽기 쉽습니다. 데이터베이스 구조는 복잡하지만, 상당히 논리적이며 어떤 면에서는 매력적이기도 합니다.

따라서 요약하자면, 상호작용 단계에서 우리가 마주한 주요 문제는 특정 시스템의 구체적인 구현 기능과 관련이 있습니다.

우리에게 어떤 식으로든 영향을 미치는 문서화되지 않은 "특징"
폐쇄 소스(청구는 C++로 작성됨)로 인해 문제 1을 "시행착오"가 아닌 다른 방법으로 해결하는 것은 불가능합니다.

다행히도 해당 제품은 상당히 광범위한 API를 갖추고 있으며, 우리는 다음과 같은 하위 시스템을 개인 계정에 통합했습니다.

기술 지원 모듈 - 개인 계정의 요청은 서비스 클라이언트를 위해 투명하게 청구서에 "프록시"됩니다.
재무 모듈 - 현재 고객에게 송장을 발행하고, 대손 처리를 하고, 지불 문서를 생성할 수 있습니다.
서비스 관리 모듈 - 자체 핸들러를 구현해야 했습니다. 시스템의 확장성이 저희의 손에 들어왔고, 우리는 Billy에게 새로운 유형의 서비스를 "훈련"시켰습니다.
노력은 좀 필요했지만, 빌리와 저는 잘 지낼 수 있을 것 같아요.

텅스텐 들판을 걷다 - 텅스텐 원단

수백 개의 전선이 흩뿌려진 텅스텐 장은 수천 비트의 정보를 스스로 통과시킵니다. 정보는 마치 마법처럼 "패킷"으로 수집되고 분류되어 복잡한 경로를 구축합니다.

이것이 우리가 친해져야 했던 두 번째 시스템, 즉 텅스텐 패브릭(TF, 이전 명칭: OpenContrail)의 영역입니다. 이 시스템의 역할은 네트워크 장비를 관리하고 사용자에게 소프트웨어 추상화를 제공하는 것입니다. TF(SDN)는 네트워크 장비 작동의 복잡한 로직을 캡슐화합니다. 예를 들어, 이 기술 자체에 대한 좋은 글이 있습니다. 여기에.

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

OpenStack 서비스의 상호작용.

운영 부서 직원들이 저희에게 이 시스템을 소개해 주었습니다. 저희는 이 시스템의 API를 사용하여 서비스의 네트워크 스택을 관리합니다. 아직 심각한 문제나 불편을 겪지는 않았지만 (운영 부서 직원들은 잘 모르겠지만), 몇 가지 흥미로운 상호작용이 있었습니다.

첫 번째는 다음과 같습니다. SSH를 통해 연결한 경우 인스턴스 콘솔에 대량의 데이터를 출력해야 하는 명령은 연결을 단순히 "멈추게" 했지만, VNC를 통해서는 모든 것이 정상적으로 작동했습니다.

이 문제에 익숙하지 않은 분들을 위해 설명드리자면, 꽤 우스꽝스럽게 보입니다. ls /root는 정상적으로 작동하지만, 예를 들어 top은 완전히 "멈춰" 있습니다. 다행히도 저희는 이미 비슷한 문제를 경험했습니다. 컴퓨트 노드에서 라우터로 가는 경로의 MTU를 조정하여 해결했습니다. 참고로, 이 문제는 TF(전송 시스템) 문제가 아닙니다.

다음 문제는 바로 코앞까지 다가와 기다리고 있었습니다. 어느 "멋진" 순간, 라우팅 마법이 갑자기 사라졌습니다. TF가 하드웨어 라우팅 관리를 중단한 것입니다.

OpenStack을 관리자 수준에서 사용하다가 필요한 사용자 수준으로 전환했습니다. SDN이 작업을 수행하는 사용자의 범위를 "차단"하는 것 같습니다. 문제는 TF와 OpenStack을 연결하는 데 동일한 관리자 계정이 사용된다는 것입니다. 사용자 수준으로 전환하는 단계에서 "마법"은 사라졌습니다. 시스템 작업을 위한 별도의 계정을 생성하기로 결정했습니다. 이를 통해 통합 기능을 손상시키지 않고 작업할 수 있었습니다.

실리콘 라이프폼 - 오픈스택

기이한 모양의 실리콘 생물이 텅스텐 광전 근처에 산다. 겉모습은 마치 다 큰 아이처럼 생겼는데, 한 번의 휘두르기로 우리를 짓밟을 수 있을 정도지만, 겉보기에는 공격적인 모습은 아니다. 공포를 유발하지는 않지만, 그 크기가 놀랍다. 주변에서 벌어지는 일들의 복잡성 또한 마찬가지다.

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

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

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

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

서버에 추가 볼륨을 연결하려고 했을 때 첫 번째 문제가 발생하는 데 오래 걸리지 않았습니다. Cinder API는 이 작업을 단호하게 거부했습니다. 더 정확히 말하면, OpenStack 자체의 주장대로라면 연결은 설정되었지만 가상 서버 내부에 디스크 장치가 없는 것입니다.

저희는 "돌아가서" Nova API에 동일한 작업을 요청하기로 했습니다. 그 결과, 기기는 정상적으로 연결되었고 서버 내에서 접근 가능합니다. 문제는 블록 스토리지가 Cinder에 응답하지 않을 때 발생하는 것으로 보입니다.

디스크 작업 시 또 다른 어려움이 발생했습니다. 시스템 볼륨을 서버에서 분리할 수 없었습니다.

다시 한번 말씀드리지만, OpenStack 자체는 연결을 끊었으며 이제 볼륨을 개별적으로 제대로 사용할 수 있다고 "선언"합니다. 하지만 해당 API는 디스크에서 작업을 수행하고 싶어하지 않았습니다.

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

OpenStack은 자체적인 상호작용 로직과 복잡한 API를 갖춘 상당히 복잡한 시스템입니다. 하지만 상당히 상세한 문서와 시행착오적인 방법(이러한 방법 없이는 어떻게 되었을까요?) 덕분에 우리는 구원받을 수 있습니다.

테스트 실행

작년 12월에 테스트 출시를 진행했습니다. 주요 목표는 기술적인 측면과 UX 측면에서 프로젝트를 전투 모드로 테스트하는 것이었습니다. 참가자는 선택적으로 초대되었고 테스트는 마감되었습니다. 하지만 웹사이트를 통해 테스트 참여를 요청할 수 있는 기회도 남겨두었습니다.

물론, 테스트 자체도 재밌는 순간이 없지는 않았습니다. 왜냐하면 이것은 단지 우리 모험의 시작일 뿐이기 때문입니다.

첫째, 프로젝트에 대한 관심을 다소 잘못 예측하여 테스트 도중에 컴퓨팅 노드를 급히 추가해야 했습니다. 클러스터에서 흔히 발생하는 문제이지만, 여기에도 미묘한 차이가 있었습니다. 특정 버전의 TF 문서에는 vRouter 작업이 테스트된 특정 커널 버전이 명시되어 있습니다. 최신 커널을 사용하여 노드를 시작하기로 결정했습니다. 그 결과, TF는 노드에서 경로를 수신하지 못했습니다. 급히 커널을 롤백해야 했습니다.

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

세션을 사용하지 않기 위해 JWT를 사용하여 개인 계정 접근을 관리하기로 했습니다. 시스템이 다양하고 널리 분산되어 있기 때문에, 저희는 자체 토큰을 관리하고 있습니다. 이 토큰은 청구서의 세션과 OpenStack의 토큰을 "래핑"합니다. 비밀번호가 변경되면 사용자 데이터가 더 이상 유효하지 않아 재발급되어야 하므로 토큰은 당연히 "유효하지 않게" 됩니다.

우리는 이 점을 놓쳤고, 이 글을 빨리 완성할 만큼의 자원이 부족했습니다. 테스트 시작 직전에 기능을 삭제해야 했습니다.
현재는 비밀번호가 변경된 경우 사용자를 로그아웃합니다.

이러한 미묘한 차이에도 불구하고 테스트는 순조롭게 진행되었습니다. 몇 주 만에 약 300명이 저희를 방문했습니다. 사용자의 눈으로 제품을 살펴보고, 실제로 사용해 보고, 양질의 피드백을 수집할 수 있었습니다.

계속하기

우리 중 많은 사람들에게 이 프로젝트는 이 정도 규모의 첫 프로젝트입니다. 우리는 팀워크, 아키텍처 및 디자인 결정, 제한된 리소스로 복잡한 시스템을 통합하고 프로덕션에 적용하는 방법 등 여러 가지 귀중한 교훈을 얻었습니다.

물론, 코드와 시스템 통합 인터페이스 모두에서 아직 해야 할 일이 많습니다. 이 프로젝트는 아직 초기 단계이지만, 저희는 이 프로젝트를 안정적이고 편리한 서비스로 발전시키겠다는 포부로 가득 차 있습니다.

우리는 이미 시스템을 설득하는 데 성공했습니다. 빌은 계산, 청구, 사용자 요청을 자기 옷장에서 성실하게 처리합니다. 텅스텐 필드의 "마법"은 안정적인 연결을 제공합니다. 그리고 OpenStack만이 가끔 "WSREP이 아직 애플리케이션에 사용할 노드를 준비하지 않았습니다"와 같은 소리를 내며 문제를 일으키기도 합니다. 하지만 그건 완전히 다른 이야기입니다...

우리는 최근 서비스를 시작했습니다.
자세한 내용은 당사에서 확인하실 수 있습니다. 온라인으로.

CLO 개발팀

유용한 링크

OpenStack

텅스텐 직물

출처 : habr.com

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