ISP시스템, 용서하고 안녕! 서버 제어판을 작성하는 이유와 방법

안녕하세요! 우리는 "호스팅 기술"이며 5년 전에 출시되었습니다. VDSina — 개발자를 위해 특별히 제작된 최초의 vds 호스팅. 우리는 DigitalOcean과 같이 편리하게 만들기 위해 노력하지만 러시아의 지원, 결제 방법 및 서버가 러시아에 있습니다. 그러나 DigitalOcean은 신뢰성과 가격뿐 아니라 서비스이기도 합니다.

ISPsystem의 소프트웨어는 멋진 서비스로 가는 길에 우리의 손을 묶는 밧줄이었습니다. XNUMX년 전 Billmanager 빌링과 VMmanager 서버 제어판을 사용하면서 자체 제어판 없이는 좋은 서비스를 제공하는 것이 거의 불가능하다는 것을 금방 깨달았습니다.

ISPsystem이 편의성을 없앤 방법

버그

우리는 버그를 직접 고칠 수 없었습니다. 매번 다른 사람의 지원에 편지를 쓰고 기다려야 했습니다. 모든 문제에 대한 해결책은 타사의 대응이 필요했습니다.

ISPsystem 지원은 정상적으로 응답했지만 수정 사항은 몇 가지 릴리스 후에만 제공되었으며 항상 그런 것은 아닙니다. 때로는 치명적인 버그가 몇 주 동안 수정되었습니다. 고객을 안심시키고 사과하고 ISP 시스템이 버그를 수정하기를 기다려야 했습니다.

다운타임 위협

업데이트는 새로운 오류를 유발하는 예측할 수 없는 중단 시간을 생성할 수 있습니다.

각 업데이트는 복권이었습니다. 청구서를 은폐하고 업데이트의 신에게 희생해야 했습니다. 업데이트로 인해 10-15분 동안 다운타임이 몇 번 발생했습니다. 당시 우리 관리자는 가만히 앉아 있었습니다. 다운타임이 얼마나 오래 지속될지 알 수 없었고 ISPsystem이 언제 새 업데이트를 출시할지 예측할 수 없었습니다.

XNUMX세대에서는 Billmanager가 더 좋아졌지만 필요한 기능에 액세스하려면 이미 매주 업데이트되는 베타를 설치해야 했습니다. 문제가 발생하면 다른 개발자가 문제를 고칠 수 있도록 액세스 권한을 부여해야 했습니다.

불편한 패널 인터페이스

모든 것이 서로 다른 패널로 나뉘어 서로 다른 위치에서 제어되었습니다. 예를 들어 클라이언트는 Billmanager를 통해 결제했으며 VMManager에서 VDS를 재부팅하거나 다시 설치해야 했습니다. 우리 직원은 클라이언트를 돕기 위해 창 사이를 전환하고 클라이언트 서버의 로드를 확인하거나 클라이언트가 사용 중인 OS를 확인해야 했습니다.

이러한 인터페이스는 우리와 고객 모두에게 시간이 걸립니다. 이러한 상황에서 DigitalOcean과 같은 편리함은 의심의 여지가 없습니다.

빈번한 API 업데이트로 짧은 수명 주기

우리는 자체 플러그인을 작성했습니다. 예를 들어 VMManager에 없는 추가 결제 방법이 있는 플러그인입니다.

최근 몇 년 동안 VMManager의 수명 주기는 상대적으로 짧았으며 새 버전에서는 API의 변수 또는 함수 이름이 임의로 변경될 수 있습니다. 이로 인해 플러그인이 손상되었습니다. 이전 버전에 대한 지원은 빠르게 단계적으로 중단되었으며 업데이트해야 했습니다.

수정할 수 없습니다.

보다 정확하게는 가능하지만 매우 비효율적입니다. 라이센스 제한으로 인해 소스 코드를 변경할 수 없으며 플러그인을 작성할 수만 있습니다. 최대 플러그인 - 일부 메뉴 항목, 단계별 마법사. ISPsystem은 다목적성을 위해 설계되었지만 특수 솔루션이 필요했습니다.

그래서 내 자신의 패널을 작성하기로 결정했습니다. 우리는 목표를 설정했습니다:

• 오류, 버그에 신속하게 대응하고 클라이언트를 기다리게 하지 않고 직접 수정할 수 있습니다.
• 워크플로 및 클라이언트 요구 사항에 맞게 인터페이스를 자유롭게 수정합니다.
• 깔끔하고 이해하기 쉬운 디자인으로 사용성을 높였습니다.

그리고 개발을 시작했습니다.

새로운 패널 아키텍처

자급자족 개발팀이 있어서 패널을 직접 작성했습니다.
주요 작업은 세 명의 엔지니어가 수행했습니다. 기술 이사 Sergey는 아키텍처를 제안하고 서버 에이전트를 작성했으며 Alexey는 청구를 수행했으며 프런트 엔드는 프런트 엔드 Artysh가 조립했습니다.

1단계: 서버 에이전트

서버 에이전트는 라이브러리를 관리하는 Python 웹 서버입니다. libvirt, 차례로 지배 Qemu-kvm 하이퍼바이저.

에이전트는 libvirt 라이브러리를 통해 vds 생성, 중지, 삭제, 운영 체제 설치, 매개 변수 변경 등 서버의 모든 서비스를 관리합니다. 기사 발행 당시에는 XNUMX개 이상의 다양한 기능이 있으며 고객의 작업과 요구 사항에 따라 보완합니다.

이론적으로 libvirt는 청구에서 직접 제어할 수 있지만 이렇게 하려면 너무 많은 추가 코드가 필요했고 이러한 기능을 에이전트와 청구 간에 분리하기로 결정했습니다. 청구는 단순히 JSON API를 통해 에이전트에 요청을 합니다.

에이전트는 인터페이스가 필요하지 않고 서버 콘솔에서 직접 테스트할 수 있었기 때문에 우리가 가장 먼저 한 일입니다.

서버 에이전트가 우리에게 준 것: 모든 사람의 삶을 단순화하는 계층이 나타났습니다. 청구는 많은 명령을 보낼 필요가 없지만 요청만 하면 됩니다. 에이전트는 필요한 모든 작업을 수행합니다. 예를 들어 디스크 공간과 RAM을 할당합니다.

2단계. 청구

우리 개발자 Alex에게 이것은 첫 번째 제어판이 아니었습니다. Alex는 오랫동안 호스팅을 해왔기 때문에 클라이언트가 필요로 하는 것과 호스트가 필요로 하는 것이 무엇인지 일반적으로 이해했습니다.

우리는 청구를 "제어판"이라고 부릅니다. 여기에는 돈과 서비스뿐만 아니라 관리, 고객 지원 등이 포함됩니다.

ISPSystem 소프트웨어에서 전환하려면 고객을 위해 이전 기능을 완전히 보존하고 사용자의 모든 재무 활동을 이전 청구서에서 새 청구서로 이전하고 이들 간의 모든 서비스와 연결을 이전해야 했습니다. 우리는 현재 제품에 무엇이 있는지 연구한 다음 주로 DO 및 Vultr와 같은 경쟁사의 솔루션을 연구했습니다. 단점과 장점을 살펴보고, ISP시스템에서 구형 제품을 사용해본 분들의 피드백을 모았습니다.

새로운 결제는 클래식 PHP, MySQL(향후 PostgreSQL로 전환할 계획임), 백엔드의 프레임워크인 Yii2, 프런트의 VueJS 등 두 가지 스택을 사용했습니다. 스택은 서로 독립적으로 작동하고 다른 사람들이 개발하며 JSON API를 사용하여 통신합니다. 그때와 지금 우리는 개발을 위해 PHP스톰 и 웹스톰 JetBrains를 사랑합니다(안녕하세요!)

패널은 결제 시스템 모듈, 도메인 등록 모듈 또는 예를 들어 SSL 인증서 모듈과 같은 모듈식으로 설계되었습니다. 새 기능을 쉽게 추가하거나 이전 기능을 제거할 수 있습니다. 확장을 위한 토대는 "하드웨어를 향하여" 반대 방향을 포함하여 구조적으로 마련되었습니다.

우리는 무엇을 얻었습니까?: 우리가 완전히 제어할 수 있는 제어판. 이제 버그는 몇 주가 아닌 몇 시간 만에 수정되며 ISPSystem의 요청이 아닌 고객의 요청에 따라 새로운 기능이 구현됩니다.

3단계 인터페이스

인터페이스는 우리 팀의 아이디어입니다.

먼저 인터페이스에서 근본적으로 아무것도 변경하지 않고 ISPsystem API를 통해 추가 기능을 만들면 어떤 일이 일어날지 살펴보았습니다. 그렇게 밝혀졌고 우리는 모든 것을 처음부터 시작하기로 결정했습니다.

우리는 깨끗하고 최소한의 디자인으로 인터페이스를 논리적으로 만드는 것이 가장 중요하다고 믿었습니다. 그러면 아름다운 패널을 얻을 수 있습니다. 요소들의 위치는 메가플랜에서 논의했고 이제 사용자가 컨트롤 패널에서 보는 인터페이스가 점차 탄생할 것입니다.

ISPsystem용 결제 플러그인을 이미 만들었기 때문에 결제 페이지의 디자인이 가장 먼저 나타났습니다.

프런트엔드

그들은 패널을 SPA 응용 프로그램으로 만들기로 결정했습니다. 리소스를 요구하지 않고 빠른 데이터 로드가 가능합니다. 우리의 프론트엔드 Artysh는 Vue에 작성하기로 결정했습니다. 당시 Vue가 막 나타났습니다. 우리는 프레임워크가 React처럼 동적으로 발전하고 얼마 후 Vue 커뮤니티가 성장하고 라이브러리의 바다가 나타날 것이라고 가정했습니다. 우리는 Vue에 걸었고 후회하지 않았습니다. 이제 백엔드에 이미 프로그래밍된 새로운 기능을 전면에 추가하는 데 시간이 거의 걸리지 않습니다. 프런트 엔드 패널에 대한 자세한 내용은 별도의 기사에서 알려 드리겠습니다.

프론트엔드를 백엔드에 연결

프런트엔드는 푸시 알림을 통해 백엔드에 연결되었습니다. 열심히 노력하고 나만의 핸들러를 작성해야 했지만 이제 페이지의 정보가 거의 즉시 업데이트됩니다.

무슨 일이에요: 패널 인터페이스가 더 간단해졌습니다. 적응형으로 만들었고 빠른 로딩을 통해 패널 작업을 위해 별도의 애플리케이션을 설치하지 않고도 이륙 직전 몇 분 동안 휴대폰에서도 사용할 수 있습니다.

4단계. 테스트 및 마이그레이션 계획

모든 것이 시작되고 첫 번째 테스트가 통과되었을 때 마이그레이션 문제가 발생했습니다. 먼저 Billing을 설치하고 서버 에이전트와 함께 작동 테스트를 시작했습니다.

그런 다음 이전 청구서에서 새 청구서로 데이터베이스를 전송하는 간단한 스크립트를 작성했습니다.

Billmanager, VMmanager 및 IPmanager manager의 세 가지 이전 데이터베이스에서 데이터가 하나의 새 데이터베이스로 병합되었기 때문에 문자 그대로 모든 것을 테스트하고 다시 확인해야 했습니다. 아마도 테스트 마이그레이션은 우리가 새로운 패널을 개발하는 과정에서 마주한 가장 어려운 일이었을 것입니다.

재확인 후 이전 결제를 종료했습니다. 마지막 데이터 마이그레이션은 매우 골치 아픈 순간이었지만 다행스럽게도 눈에 띄는 문제 없이 몇 분 만에 완료되었습니다. 일주일 동안 수정한 사소한 버그가 있었습니다. 대부분의 시간은 무슨 일이 일어났는지 테스트하는 데 사용되었습니다.

그런 다음 새 패널 주소와 청구서가 포함된 편지를 고객에게 보내고 리디렉션을 수행했습니다.

결과 : 살아있어!

행복한 결말

우리 소프트웨어의 첫 작업 시간부터 우리는 전환의 모든 즐거움을 느꼈습니다. 코드는 완전히 우리 것이었고 편리한 아키텍처를 사용했으며 인터페이스는 깨끗하고 논리적이었습니다.

신규 패널 출시 후 첫 리뷰

우리는 부하가 가장 적은 2017년 새해 전날인 XNUMX월에 전환 프로세스를 시작하여 고객이 전환을 더 쉽게 할 수 있도록 했습니다. 휴일 전날에는 거의 아무도 일하지 않습니다.

우리 시스템으로 전환할 때 얻은 가장 중요한 점은(일반적인 안정성과 편의성을 제외하고) 주요 고객을 위한 기능을 신속하게 추가할 수 있는 능력입니다.

다음은 뭐지?

우리는 성장하고 있으며 데이터, 고객, 고객 데이터의 양이 증가하고 있습니다. Memcached 서버와 서로 다른 작업을 수행하는 두 개의 큐 관리자를 백엔드에 추가해야 했습니다. 프런트엔드에는 캐싱과 자체 대기열이 있습니다.

물론 우리는 예를 들어 HighLoad를 추가했을 때와 같이 제품이 개발되고 더 복잡해짐에 따라 여전히 모험을 했습니다.

다음 기사에서는 Hi-CPU 관세가 어떻게 시작되었는지, 즉 하드웨어, 소프트웨어, 우리가 해결한 작업 및 수행한 작업에 대해 설명합니다.

출처 : habr.com