서보 모터가 마이크로서비스를 만났을 때: 데이터 아키텍처에 관한 것

이런 상황을 겪어본 적이 있나요? 생산라인에는 수십 개의 서보 모터가 동시에 돌아가고 있고, 데이터가 밀물처럼 쏟아져 들어온다. 여기의 서보 각도 데이터는 아직 저장되지 않았으며 로봇 팔의 실시간 토크 정보가 다시 입력되었습니다. 데이터베이스가 숨을 쉬지 못하고 시스템이 때때로 몇 밀리초 동안 정지됩니다. 하지만 이 몇 밀리초가 때로는 실제로 두통을 유발할 수 있습니다.

우리가 자동화 프로젝트를 할 때 흔히 접하는 상황이 아닐까요? 기기는 점점 더 똑똑해지고, 데이터의 양은 점점 더 많아지고 있습니다. 기존의 단일 데이터베이스 아키텍처는 부적절해 보이기 시작했습니다.

마이크로서비스 시대의 데이터베이스 객관식 문제

그렇다면 다음과 같은 질문이 떠오릅니다. 마이크로서비스 아키텍처에서 데이터베이스를 어떻게 설계해야 할까요?

"모든 서비스가 데이터베이스를 공유하는 것이 얼마나 간단합니까!"라는 목소리가 들렸습니다. 하지만 실제 운영을 해 보면 이러한 단순함 뒤에는 많은 문제점이 숨어 있다는 것을 알게 됩니다. 특정 서비스의 테이블 구조를 변경하면 실수로 다른 기능에 영향을 미칠 수 있습니다. 데이터 결합이 너무 빡빡하고 특정 모듈을 확장하기가 어렵습니다.

또 다른 사고 방식이 대중화되고 있습니다. 각 마이크로서비스는 자체 데이터베이스를 관리합니다. 합리적으로 들리죠? 조향 기어 제어를 담당하는 모듈은 자체 위치 데이터를 관리하고, 모터 상태를 모니터링하는 모듈은 자체 실행 로그를 저장하도록 합니다. 각자는 서로 간섭하지 않고 자신의 임무를 수행합니다.

하지만 새로운 질문이 생깁니다. 데이터가 분산된 후 교차 서비스가 필요한 데이터 쿼리는 어떻게 해야 할까요? 예를 들어, 특정 기계 장치의 전반적인 효율을 분석하려면 서보 모터의 응답 속도, 해당 스티어링 기어의 위치 결정 정확도, 기계 구조의 부하 데이터를 살펴봐야 합니다. 데이터는 여러 곳에 분산되어 있어 이를 하나로 묶는 데 시간이 많이 걸리고 힘듭니다.

kpower해결책: 패턴과 균형

우리는 며칠 동안 이것에 대해 생각해 왔습니다. 존재하다kpower실제 프로젝트 경험을 통해, 경직된 템플릿이 아닌 유연한 데이터 구성 방법인 적절한 "데이터베이스 스키마"를 찾는 것이 핵심이라는 것을 알았습니다.

예를 들어, "각 서비스에 대한 별도의 데이터베이스" 모델은 모터 제어 시스템에 특히 유용합니다. 실시간 제어 모듈의 데이터는 응답 속도를 보장하기 위해 독립적으로 저장됩니다. 기록 분석 모듈은 장기적인 추세 분석을 용이하게 하기 위해 또 다른 저장 전략 세트를 사용합니다. 데이터의 경계가 명확하고, 서비스는 타인의 데이터베이스를 직접 살펴보는 것이 아닌 명확한 인터페이스를 통해 필요한 정보를 교환합니다.

데이터 일관성을 보장하는 방법은 무엇입니까? 우리는 종종 이벤트 중심 접근 방식을 채택합니다. 서보가 지정된 작업을 완료하면 "작업 완료" 이벤트를 게시합니다. 동작 궤적 기록 서비스와 같이 이 상태에 관심이 있는 다른 서비스는 이 이벤트를 수신 및 처리하고 자체 데이터를 업데이트합니다. 이 접근 방식은 서비스 간의 직접적인 데이터베이스 종속성을 방지합니다.

생산 라인의 이론부터 실제 시나리오까지

작년에 우리는 이러한 아이디어를 활용한 자동화된 생산 라인 개조 프로젝트를 지원했습니다. 생산 라인에는 12개의 서보 모터가 함께 작동하며 각 모터는 작동 매개변수, 오류 코드 및 유지 관리 내역을 기록해야 합니다. 세 세트의 로봇 팔의 서보는 실시간으로 위치 데이터를 교환해야 합니다.

모든 데이터가 하나의 데이터베이스에 쌓이면 실시간 제어 데이터와 분석 데이터가 리소스를 차지하게 됩니다. 우리는 분할 정복 전략을 채택했습니다. 실시간 제어 서비스를 위한 고성능 시계열 데이터베이스를 구성하여 모터 속도 및 토크의 실시간 값을 저장합니다. 장비 매개변수 및 유지 관리 기록을 저장하기 위해 장비 관리 서비스용 관계형 데이터베이스를 구성합니다. 분석 서비스는 필요에 따라 다양한 소스에서 데이터를 가져와 포괄적인 처리를 수행합니다.

결과는? 실시간 제어 응답 지연이 40% 감소하고, 데이터 분석 쿼리 속도가 향상됩니다. 각 데이터베이스는 자체 주요 작업을 대상으로 할 수 있으므로 모든 유형의 데이터 작업을 저글링할 필요가 없습니다.

실제 세부 사항

데이터베이스 스키마를 선택할 때 일반적으로 다음과 같은 몇 가지 질문을 합니다.

이 서비스의 데이터 액세스 모델은 무엇입니까? 소량의 데이터를 실시간으로 자주 읽고 쓰는 걸까요, 아니면 가끔 대규모 분석 쿼리를 수행하는 걸까요?

예상되는 데이터 증가량은 어느 정도입니까? 일부 센서 데이터는 초당 여러 개의 레코드를 생성하며, 이는 한 달 안에 엄청난 양으로 누적될 수 있습니다.

서비스 간의 데이터 종속성은 얼마나 강력합니까? 실시간 동기화가 정말로 필요합니까, 아니면 짧은 지연이 허용됩니까?

이러한 질문에 답하고 나면 모드 선택이 훨씬 더 명확해집니다. 실시간 요구 사항이 높은 제어 데이터는 메모리 내 데이터베이스 또는 특정 시계열 데이터베이스에 적합할 수 있습니다. 복잡한 쿼리 관계가 필요한 구성 데이터의 경우 기존 관계형 데이터베이스가 더 적합할 수 있습니다. 많은 양의 기록 로그 데이터의 경우 열형 스토리지 엔진이 더 나은 성능을 발휘하는 경우가 있습니다.

패턴은 속박이 아니라 춤이다

좋은 데이터베이스 스키마는 구속복과 같아서는 안 되며, 필요한 지원을 제공하면서 자유롭게 움직일 수 있게 해주는 몸에 꼭 맞는 작업복과 같아야 합니다. 존재하다kpower우리의 프로젝트 경험을 통해 가장 성공적인 구현은 유연성을 발휘할 수 있는 팀인 경우가 많다는 사실을 발견했습니다.

이들은 특정 기능을 위한 보조 스토리지 솔루션과 결합된 핵심 서비스를 위한 기본 데이터베이스 스키마를 선택합니다. 정밀한 기계 시스템과 마찬가지로 각 구성 요소는 가장 적합한 재료와 구조를 가지므로 결합 시 최대의 효과를 얻을 수 있습니다.

때로는 서로 다른 서비스 간에 원활하게 흐르는 이러한 데이터를 보면 잘 설계된 전송 시스템이 생각납니다. 기어 사이에 동력이 전달되고 모든 링크가 적절하게 전달되어 최종적으로 정밀한 움직임으로 변환됩니다.

에 쓰여진

마이크로서비스에서의 데이터베이스 설계는 궁극적으로 서비스 독립성과 데이터 무결성 간의 균형, 실시간 성능과 쿼리 유연성 간의 균형, 단기 개발 효율성과 장기 유지 관리 비용 간의 균형을 찾는 것입니다.

모든 경우에 적용되는 일률적인 답변은 없으며 특정 시나리오에 적합한 선택만 있을 뿐입니다. 모든 프로젝트는 모터 제어에서 기계적 조정에 이르기까지 새로운 탐구이며, 데이터 아키텍처는 항상 모든 것을 자동으로 지원하는 초석입니다.

밤이 되어 생산 라인의 장비가 유지 관리 기간에 들어가도 조용히 실행되는 데이터베이스는 여전히 하루의 데이터를 분류하고 내일의 효율적인 작동을 준비하고 있습니다. 마치 정밀한 기계 장치 세트처럼 각 부품이 올바른 위치에 있으며 임무를 수행합니다.

2005년에 설립된 Kpower는 중국 광둥성 둥관에 본사를 둔 소형 모션 유닛 전문 제조업체입니다. Kpower는 모듈형 드라이브 기술의 혁신을 활용하여 고성능 모터, 정밀 감속기 및 다중 프로토콜 제어 시스템을 통합하여 효율적이고 맞춤형 스마트 드라이브 시스템 솔루션을 제공합니다. Kpower는 스마트 홈 시스템, 자동 전자 장치, 로봇 공학, 정밀 농업, 드론 및 산업 자동화 등 다양한 분야를 포괄하는 제품을 통해 전 세계 500개 이상의 기업 고객에게 전문 드라이브 시스템 솔루션을 제공해 왔습니다.