효율적으로 시스템 확장:고성능 메시징을 위한 프로세스 분할 및 Redis

말로 단순화하기 위해 서비스 A와 서비스 B라는 두 개의 별도 서비스가 있고 그 중간에 pubsub 서비스가 있다고 상상해 보세요.

pubsub 서비스가 무엇인지 확실하지 않다면 한 서비스의 메시지가 다른 서비스에 도달하도록 돕는 브로커라고 상상해 보세요.

그러면 서비스 A가 메시지를 게시하고 pubsub를 통해 서비스 B가 이를 처리합니다. 프로세스가 완료된 후 메시지가 처리되었음을 표시하기 위해 또 다른 프로세스를 수행합니다.

아주 간단하죠?

단지 메시지가 너무 큰 경우 pubsub 서비스의 제한으로 인해 메시지를 성공적으로 게시하지 못하는 경우도 있습니다.

좋습니다. 제가 직면한 문제에 대한 개요를 제공하겠습니다. 그러면 이 문제를 어떻게 해결했습니까? 다음 섹션에서는 제 솔루션을 안내해 드리겠습니다.

나의 첫 번째 접근 방식

다이어그램에서 볼 수 있듯이 메시지는 여러 개의 작은 메시지로 분할됩니다. 분할 방법과 메시지의 어느 부분을 분할해야 하는지는 각 사례와 흐름에 따라 다를 수 있습니다.

하지만 제 경우에는 실제로 메시지에 항목 목록이 포함되어 있으므로 항목별로 분할할 수 있습니다.

10개의 항목이 있다고 가정해 보겠습니다. 이전에는 하나의 메시지에 10개 항목을 모두 게시했습니다. 하지만 이제 메시지를 분할한 후에는 해당 메시지를 10개의 메시지로 변환합니다.

이로 인해 단일 프로세스가 여러 프로세스가 함께 발생하게 됩니다. 단일 게시는 10개의 게시로 바뀌고, 이는 다시 해당 단일 프로세스를 10개의 프로세스로 전환합니다.

그렇게 보면 이상적으로 보이지 않을 수도 있지만, 이것이 제가 생각해낸 최고의 솔루션이며 확실히 효과가 있습니다.

그럼 그냥 나누기만 하면 되는 건가요?

그렇지 않습니다. 프로세스가 완료된 것으로 표시하는 마지막 부분을 기억하시나요?
그렇다면 새 다이어그램에서 해당 부분이 왜 누락되었는지 궁금할 것입니다.

걱정하지 마십시오. 제가 잊어버린 것은 아닙니다. 의도적으로 다음 부분에서 생략했습니다.

문제는 메시지를 분할하여 여러 프로세스로 나눌 때 전체 프로세스가 실제로 완료되었는지 시스템이 알지 못할 수도 있다는 것입니다. 이는 우리가 해결해야 할 또 다른 주요 문제인데, 감사하게도 이에 대한 해결책도 찾았습니다.

마무리 처리 방법

프로세스는 이전과 똑같아 보이지만 중간에 Redis가 추가되었습니다. 이 사례에 대해 유효한 초기 개수가 있는지 확인해야 합니다.

내 경우에는 목록을 게시하고 있으므로 목록의 길이를 초기 카운터로 쉽게 넣을 수 있습니다. 그리고 카운터의 경우 프로세스가 완료될 때마다 1씩 줄일 수 있습니다. 그러면 Redis 카운터를 참조하여 모든 프로세스를 완료했는지 알 수 있습니다. 0에 도달하면 모든 프로세스가 완료되었음을 안전하게 표시할 수 있다는 의미입니다.

마무리

요약하자면, 메시지를 여러 프로세스에서 함께 처리될 여러 메시지로 분할했습니다. 메시지 프로세스를 관리하기 위해 Redis 캐싱을 사용합니다.

위에서 설명한 솔루션은 매우 큰 메시지를 처리하는 데 문제가 있을 때마다 만능이 될 수는 없습니다. 메시지를 스트리밍하는 등 다른 방법도 있지만 그건 나중에 다루겠습니다.

제 글을 끝까지 읽어주셔서 감사합니다! 여러분이 제 기사를 재미있게 읽으셨기를 바라며, 가장 중요하게는 제 기사가 유용했기를 진심으로 바랍니다.

무료로 코딩을 배우세요. freeCodeCamp의 오픈 소스 커리큘럼은 40,000명 이상의 사람들이 개발자로 취업하는 데 도움을 주었습니다. 시작하세요