마이크로서비스 아키텍처를 선택하는 방법은 무엇입니까? 시스템을 더욱 안정적으로 실행하세요

혹시 접해보셨나요? 처음 온라인에 등장했을 때는 시스템이 괜찮았지만 사용자가 너무 많아지면 시스템이 중단되었습니다. 새로운 기능을 추가하면 전체 시스템을 다시 테스트해야 합니다. 팀은 뭔가를 바꾸고 싶었지만 다른 곳에서도 문제가 발생했습니다. 솔직히 말해서 많은 팀이 이런 종류의 문제에 직면해 있습니다. 원래 선택한 아키텍처가 이제 묶여 있습니다.

무엇을 해야 할까요? 마이크로서비스는 좋은 아이디어처럼 보이지만 구체적으로 어떻게 수행할 수 있을까요?

해체할 것인가, 해체하지 않을 것인가? 이건 문제야

일부 팀에서는 모든 코드를 모아서 그렇게 간단하다고 생각합니다. 실제로 개발 초기에는 속도가 빨랐으나 반년이 지나니 코드가 엉망이 됐다. 어디에 영향을 미칠지 모르기 때문에 누구도 감히 함부로 움직일 수 없습니다.

다른 팀은 너무 세분화되어 있습니다. 5~6개 서비스에 걸쳐 간단한 함수를 호출해야 하고, 문제를 확인하려면 3~4개의 모니터링 패널을 살펴봐야 한다. 배포는 더욱 까다롭습니다. 하루 안에 완료할 수 있었던 일을 이제 여러 팀의 조정이 필요합니다.

마치 레고를 만드는 것과 같습니다. 모든 부품이 서로 붙어 있는 경우, 창문을 교체하려면 건물 전체를 해체해야 합니다. 하지만 각 부품이 너무 작아서 눈에 띄지 않으면 조립할 때 손이 아프고 잃어버리기 쉽습니다.

그럼 어떻게 해체해야 할까요?

그 "딱 맞는" 지점을 찾아보세요

좋은 마이크로서비스 아키텍처는 실제로 균형을 찾는 것입니다. 팀이 독립적으로 개발할 수 있을 만큼 독립적이어야 하지만, 간단한 일을 복잡하게 만들지 않을 만큼 컴팩트해야 합니다.

이 지점을 찾는 방법은 무엇입니까? 사업 자체를 살펴보세요. 기능이 자주 변경되는 경우 별도의 서비스여야 합니다. 데이터 세트가 항상 함께 표시된다면 그래야 합니다. 예를 들어, 회원가입부터 로그인, 개인정보까지 사용자 정보가 3개의 서비스로 분할된다면 사용자 페이지가 표시될 때마다 인터페이스를 3번 조정해야 합니다. 왜 귀찮게?

하지만 주문 시스템은 다릅니다. 주문하는 과정, 결제하는 과정, 배송하는 과정이 각각 다릅니다. 이들은 서로 다른 빈도로 변경되고 이를 담당하는 팀이 다르기 때문에 완전히 분리 가능합니다.

알고 계셨나요? 때로 가장 어려운 것은 기술이 아니라, 얽힌 코드를 풀어내겠다는 결심이다. 수년 동안 정리된 차고와 같습니다. 처음에는 '이거 도움이 될 것 같다'고 늘 생각했지만, 결국 아무것도 버릴 수가 없었습니다. 하지만 실제로 정리하고 나면 공간도 더 넓어지고 물건 찾기도 더 쉬워진다는 걸 알게 될 거예요.

군인들이 서로 이야기를 나누도록 하십시오.

일단 분해되면 어떻게 의사소통을 할 수 있나요? 두 가지 일반적인 방법이 있습니다. 하나는 동기식 호출입니다. 전화를 거는 것과 같이 내가 전화를 걸면 즉시 응답해야 합니다. 다른 하나는 이메일을 보내는 것과 같은 비동기식 메시징입니다. 내가 보냈고 사용자는 편리하게 처리할 수 있습니다.

동기 호출은 간단하고 직접적이므로 즉각적인 응답이 필요한 시나리오에 적합합니다. 예를 들어, 사용자의 잔액을 확인할 때 결과가 표시되기까지 5분을 기다릴 수는 없겠죠? 그러나 여기에는 문제가 있습니다. 호출된 서비스가 중단되면 호출자도 중단됩니다. 마치 도미노처럼 하나가 넘어지고 또 하나가 넘어지는 것입니다.

비동기 메시지는 더 유연합니다. 서비스는 메시지 대기열을 통해 통신하며 발신자는 수신자가 처리를 마칠 때까지 기다릴 필요가 없습니다. 수신 서비스를 일시적으로 사용할 수 없는 경우에도 메시지는 보낸 사람에게 영향을 주지 않고 대기열에서 대기합니다. 이것은 편지를 보내기 위해 우체국에 가는 것과 같습니다. 우체통에 편지를 넣고 우체부가 픽업할 때까지 기다리지 않고 떠나시면 됩니다.

그러나 비동기에는 대가가 따른다. 메시지 대기열을 관리하고 손실되거나 중복된 메시지를 처리하면서 시스템이 더욱 복잡해졌습니다. 때로는 비즈니스 프로세스가 어디로 갔는지 추적하기 위해 전문적인 서비스가 필요할 수도 있습니다.

어느 것을 선택할까요? 귀하의 비즈니스가 허용할 수 있는 지연의 정도와 허용할 수 있는 복잡성의 정도에 따라 달라집니다. 절대적인 좋고 나쁨은 없으며 단지 적합 여부만 있을 뿐입니다.

데이터로 무엇을 해야 할까요? 나누느냐, 나누지 않느냐

데이터 스토리지는 아마도 마이크로서비스에서 가장 어려운 문제일 것입니다. 전통적인 접근 방식은 모든 서비스가 데이터베이스를 공유하는 것입니다. 간단하죠? 하지만 문제는 여기에도 있습니다. 데이터베이스 구조가 변경되면 모든 서비스가 영향을 받을 수 있습니다. 설상가상으로 서비스는 데이터베이스를 통해 암묵적으로 결합됩니다. 필드를 변경하면 해당 필드가 사용되고 있는지 어떻게 알 수 있습니까?

마이크로서비스의 이상적인 상태는 각 서비스가 자체 데이터베이스를 갖는 것입니다. 이러한 방식으로 서비스는 실제로 분리되며 한 서비스의 데이터베이스 구조 변경은 다른 서비스에 영향을 미치지 않습니다. 그러나 여기에 문제가 있습니다. 비즈니스 데이터는 자연스럽게 관련되어 있습니다. 주문은 사용자 정보를 알아야 하고, 물류는 제품 세부정보를 알아야 합니다. 이러한 데이터를 동기화하는 방법은 무엇입니까?

두 가지 일반적인 방법이 있습니다. 하나는 이웃집에 물건을 빌리러 가는 것처럼 서비스 간 API를 통해 필요한 데이터를 얻는 것이다. 장점은 데이터가 항상 최신 상태라는 점이지만, 단점은 호출 체인이 길면 시스템 성능에 영향을 미칠 수 있다는 점입니다.

다른 하나는 각 서비스가 필요한 데이터의 복사본을 저장하는 데이터 복제입니다. 집에 도구가 있는 것처럼 나도 같은 도구 세트를 구입합니다. 이렇게 하면 서비스 간 빈번한 호출이 필요하지 않지만 데이터 동기화가 새로운 문제가 되었습니다. 내 손에 있는 데이터가 귀하의 데이터와 일치하는지 어떻게 보장할 수 있을까요?

kpower고객의 아키텍처 설계를 지원할 때 우리는 하이브리드 솔루션을 권장하는 경우가 많습니다. 즉, 핵심 데이터는 독립적이고 공유 데이터는 이벤트를 통해 동기화됩니다. 사용자 정보가 업데이트되면 사용자 서비스는 "사용자가 업데이트되었습니다" 이벤트를 게시하고 이 이벤트에 주의를 기울이는 다른 서비스는 자체적으로 저장된 관련 데이터를 업데이트합니다. 이는 독립성을 유지하고 데이터 일관성을 보장합니다.

운영 및 유지 관리 문제 - 복잡성에서 단순성까지

마이크로서비스는 실제로 모놀리식 애플리케이션보다 배포하기가 더 복잡합니다. 과거에는 하나의 애플리케이션만 시작하면 되었지만 이제는 수십 개, 심지어는 수십 개의 서비스를 시작해야 한다고 상상해 보십시오. 모니터링은 어떻습니까? 로그를 확인하는 방법은 무엇입니까? 문제가 발생했을 때 문제를 빠르게 찾는 방법은 무엇입니까?

좋은 도구와 프로세스가 필요한 곳입니다. 컨테이너화 기술은 배포를 통합합니다. 각 서비스는 컨테이너 이미지로 패키징되며 모든 환경에서 동일하게 실행됩니다. 오케스트레이션 도구는 이러한 컨테이너를 관리하는 데 도움이 됩니다. 실패한 컨테이너는 자동으로 다시 시작하고 트래픽이 증가하면 자동으로 확장됩니다.

모니터링도 계층화되어 있습니다. 이는 전반적인 시스템 상태와 개별 서비스의 성능에 따라 달라집니다. 링크 추적은 특히 유용합니다. 요청은 5~6개의 서비스를 통과합니다. 각 서비스에서 소요된 시간과 정체된 단계를 명확하게 확인할 수 있습니다.

로그 수집도 마찬가지로 중요합니다. 모든 서비스의 로그를 동일한 인터페이스로 모아서 검색합니다. 그렇지 않으면 문제가 발생하면 각각 7~8개의 서버에 로그인해 로그를 확인해야 한다. 문제가 확인될 때쯤이면 사용자는 도망가게 될 것입니다.

실제로 구조가 커집니다.

이 모든 것을 말하고 나면 어떤 아키텍처 패턴이 가장 좋은지 궁금할 것입니다.

진실은 표준적인 대답이 없다는 것입니다. 가장 적합한 아키텍처는 다른 사람의 디자인을 복사하는 것이 아니라 실제 비즈니스에서 발전해야 합니다.

처음에는 모놀리식 애플리케이션으로 시작할 수 있지만 의식적으로 비즈니스 모듈별로 코드를 구성해야 합니다. 모듈을 실제로 독립적으로 개발해야 하는 경우 이를 마이크로서비스로 분할하세요. 이러한 점진적인 발전은 처음부터 완벽한 마이크로서비스 아키텍처를 설계하는 것보다 더 실용적이고 덜 위험합니다.

kpower팀은 그러한 여행을 많이 해왔습니다. 초기 코드 덩어리부터 명확한 서비스 경계까지; 수동 배포 스크립트에서 자동화된 파이프라인까지; 문제 발생 시 스크램블링부터 시스템 자동 복구까지. 이 과정은 나무를 가지치기하는 것과 같습니다. 한 번에 모든 가지를 잘라내는 대신 필요에 따라 천천히 다듬어 나무가 더 건강하게 자랄 수 있습니다.

아키텍처는 도면의 선이 아니라 비즈니스 운영을 지원하는 뼈대입니다. 강해야 하지만 단단해서는 안 됩니다. 유연해야 하지만 느슨해서는 안 됩니다. 균형을 찾으면 시스템이 살아나게 됩니다. 시스템은 변화에도 불구하고 성장하고 적응하며 안정적인 상태를 유지합니다.

이것이 우리가 추구하는 것이 아닌가? 비즈니스가 기술에 적응하도록 하기보다는 기술이 진정으로 비즈니스에 도움이 되도록 하십시오. 건축이 더 이상 매일 걱정하는 문제가 아니라면 가치 자체를 창출하는 데 더 집중할 수 있습니다. 그 당시에는 건축의 존재를 잊어버렸을지도 모릅니다. 최고의 건축은 사람이 느낄 수 없는 건축인 경우가 많습니다.

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