데이터 이분법: 데이터와 서비스 간의 관계 재고

안녕하세요 여러분! 좋은 소식이 있습니다. OTUS가 6월에 강좌를 다시 시작합니다. "소프트웨어 아키텍트", 이와 관련하여 우리는 전통적으로 유용한 자료를 귀하와 공유합니다.

아무런 맥락도 없이 이 전체 마이크로서비스를 접했다면 조금 이상하다고 생각할 수도 있을 것입니다. 애플리케이션을 네트워크로 연결된 조각으로 분할한다는 것은 필연적으로 결과 분산 시스템에 복잡한 내결함성 모드를 추가하는 것을 의미합니다.

이 접근 방식에는 서비스를 여러 개의 독립적인 서비스로 나누는 작업이 포함되지만 최종 목표는 해당 서비스를 다른 시스템에서 실행하는 것 이상입니다. 여기서는 본질적으로 분산되어 있는 외부 세계와의 상호 작용에 대해 이야기하고 있습니다. 기술적인 의미가 아니라 많은 사람, 팀, 프로그램으로 구성된 생태계의 의미에서 각 부분이 어떻게든 제 역할을 수행해야 합니다.

예를 들어, 회사는 특정 목표 달성에 집합적으로 기여하는 분산 시스템의 모음입니다. 우리는 수십 년 동안 이 사실을 무시하고 파일을 FTP로 보내거나 기업 통합 도구를 사용하여 통합을 달성하려고 노력하면서 우리 자신의 고립된 목표에만 집중해 왔습니다. 하지만 서비스가 등장하면서 모든 것이 달라졌습니다. 서비스는 우리가 지평선 너머를 바라보고 함께 작동하는 상호 의존적 프로그램의 세계를 볼 수 있도록 도와주었습니다. 그러나 성공적으로 일하기 위해서는 근본적으로 다른 두 가지 세계, 즉 우리가 다른 많은 서비스의 생태계에 살고 있는 외부 세계와 우리가 혼자 통치하는 개인 내부 세계를 인식하고 설계해야 합니다.

이 분산된 세계는 우리가 자랐고 익숙한 세계와 다릅니다. 전통적인 모놀리식 아키텍처를 구성하는 원칙은 비판을 견디지 못합니다. 따라서 이러한 시스템을 올바르게 구축하는 것은 멋진 화이트보드 다이어그램이나 멋진 개념 증명을 만드는 것 이상입니다. 요점은 그러한 시스템이 장기간에 걸쳐 성공적으로 작동하도록 보장하는 것입니다. 다행스럽게도 서비스는 모양은 다르지만 꽤 오랫동안 존재해 왔습니다. SOA 수업 Docker, Kubernetes 및 약간 초라한 힙스터 턱수염으로 노련해지더라도 여전히 관련성이 있습니다.

따라서 오늘 우리는 규칙이 어떻게 변경되었는지, 서비스와 서비스가 서로 전달하는 데이터에 접근하는 방식을 다시 생각해야 하는 이유, 그리고 이를 수행하기 위해 완전히 다른 도구가 필요한 이유를 살펴보겠습니다.

캡슐화가 항상 친구가 되는 것은 아닙니다.

마이크로서비스는 서로 독립적으로 작동할 수 있습니다. 그들에게 가장 큰 가치를 부여하는 것은 바로 이 속성입니다. 이 동일한 속성을 통해 서비스를 확장하고 성장할 수 있습니다. 수천조의 사용자 또는 페타바이트의 데이터로 확장한다는 의미는 아니지만(이것 역시 도움이 될 수 있음) 팀과 조직이 지속적으로 성장함에 따라 사람 측면에서 확장된다는 의미입니다.

그러나 독립은 양날의 검이다. 즉, 서비스 자체가 쉽고 자연스럽게 구동될 수 있다. 그러나 다른 서비스를 사용해야 하는 기능이 서비스 내에서 구현되면 결국 두 서비스를 거의 동시에 변경해야 합니다. 모놀리스에서는 변경하기가 쉽고 릴리스로 보내기만 하면 되지만 독립 서비스를 동기화하는 경우에는 더 많은 문제가 발생합니다. 팀과 릴리스 주기 간의 조정은 민첩성을 파괴합니다.

표준 접근 방식의 일부로, 그들은 단순히 서비스 간의 기능을 명확하게 구분하여 성가신 엔드투엔드 변경을 피하려고 노력합니다. Single Sign-On 서비스가 좋은 예가 될 수 있습니다. 다른 서비스와 차별화되는 역할이 명확하게 정의되어 있습니다. 이러한 명확한 분리는 주변 서비스에 대한 수요가 급변하는 세계에서 Single Sign-On 서비스가 변경될 가능성이 낮다는 것을 의미합니다. 이는 엄격하게 제한된 맥락 내에서 존재합니다.

문제는 현실 세계에서 비즈니스 서비스가 항상 동일하고 순수한 역할 분리를 유지할 수 없다는 것입니다. 예를 들어, 동일한 비즈니스 서비스는 다른 유사한 서비스에서 제공되는 데이터와 더 효과적으로 작동합니다. 온라인 소매업에 종사하는 경우 주문 흐름, 제품 카탈로그 또는 사용자 정보 처리가 많은 서비스에 대한 요구 사항이 됩니다. 각 서비스가 작동하려면 이 데이터에 액세스해야 합니다.

대부분의 비즈니스 서비스는 동일한 데이터 스트림을 공유하므로 해당 서비스의 작업은 변함없이 서로 얽혀 있습니다.

따라서 우리는 이야기할 가치가 있는 중요한 점에 이르렀습니다. 서비스는 주로 독립적으로 작동하는 인프라 구성 요소에 적합하지만 대부분의 비즈니스 서비스는 훨씬 더 밀접하게 얽혀 있습니다.

데이터 이분법

서비스 지향 접근 방식이 이미 존재할 수 있지만 서비스 간에 대량의 데이터를 공유하는 방법에 대한 통찰력이 여전히 부족합니다.

가장 큰 문제는 데이터와 서비스가 분리될 수 없다는 것입니다. 한편, 캡슐화는 서비스를 서로 분리하고 성장과 추가 변화를 촉진할 수 있도록 데이터를 숨기도록 장려합니다. 반면, 다른 데이터와 마찬가지로 공유된 데이터도 자유롭게 분할하고 정복할 수 있어야 합니다. 요점은 다른 정보 시스템처럼 자유롭게 즉시 작업을 시작할 수 있다는 것입니다.

그러나 정보 시스템은 캡슐화와 거의 관련이 없습니다. 사실, 그것은 정반대입니다. 데이터베이스는 저장한 데이터에 대한 액세스를 제공하기 위해 최선을 다합니다. 필요에 따라 데이터를 수정할 수 있는 강력한 선언적 인터페이스가 함께 제공됩니다. 이러한 기능은 예비 연구 단계에서는 중요하지만 끊임없이 진화하는 서비스의 복잡성 증가를 관리하는 데는 중요하지 않습니다.

그리고 여기서 딜레마가 발생합니다. 모순. 이분법. 결국 정보 시스템은 데이터 제공에 관한 것이고 서비스는 숨기기에 관한 것입니다.

이 두 가지 힘은 기본입니다. 그들은 우리 작업의 많은 부분을 뒷받침하며 우리가 구축하는 시스템의 우수성을 위해 끊임없이 싸우고 있습니다.

서비스 시스템이 성장하고 발전함에 따라 우리는 다양한 방식으로 데이터 이분법의 결과를 목격합니다. 서비스 인터페이스가 더욱 광범위한 기능을 제공하도록 성장하여 매우 멋진 자체 개발 데이터베이스처럼 보이거나, 좌절감을 느끼고 서비스에서 서비스로 전체 데이터 세트를 검색하거나 이동하는 방법을 구현하게 될 것입니다.

결과적으로 멋진 자체 개발 데이터베이스처럼 보이는 것을 생성하면 수많은 문제가 발생하게 됩니다. 왜 위험한지에 대해서는 자세히 설명하지 않겠습니다. 공유 데이터베이스, 엔지니어링 및 운영에 상당한 비용이 소요된다고 가정해 보겠습니다. 어려움 그것을 사용하려는 회사를 위해.

더 나쁜 것은 데이터 양이 서비스 경계 문제를 확대한다는 것입니다. 서비스 내에 공유되는 데이터가 많아질수록 인터페이스는 더욱 복잡해지고 다양한 서비스에서 제공되는 데이터 세트를 결합하는 것은 더욱 어려워집니다.

전체 데이터 세트를 추출하고 이동하는 대체 접근 방식에도 문제가 있습니다. 이 질문에 대한 일반적인 접근 방식은 단순히 전체 데이터 세트를 검색하고 저장한 다음 이를 각 소비 서비스에 로컬로 저장하는 것처럼 보입니다.

문제는 서로 다른 서비스가 자신이 소비하는 데이터를 다르게 해석한다는 것입니다. 이 데이터는 항상 가까이에 있습니다. 로컬에서 수정되고 처리됩니다. 아주 빨리 그들은 소스의 데이터와 공통점을 갖지 않게 됩니다.

복사본의 변경 가능성이 높을수록 시간이 지남에 따라 데이터가 더 많이 변합니다.

설상가상으로 이러한 데이터는 나중에 수정하기가 어렵습니다(MDM 이것이 실제로 구출될 수 있는 곳입니다). 실제로 기업이 직면하고 있는 다루기 힘든 기술 문제 중 일부는 애플리케이션마다 증가하는 서로 다른 데이터로 인해 발생합니다.

이 문제에 대한 해결책을 찾으려면 공유 데이터에 대해 다르게 생각해야 합니다. 그것들은 우리가 구축하는 아키텍처에서 일류 객체가 되어야 합니다. 팻 헬랜드 이러한 데이터를 "외부"라고 부르는데 이는 매우 중요한 기능입니다. 서비스의 내부 작동을 노출하지 않도록 캡슐화가 필요하지만 서비스가 공유 데이터에 쉽게 액세스하여 작업을 올바르게 수행할 수 있도록 해야 합니다.

문제는 서비스 인터페이스, 메시징, 공유 데이터베이스 중 어느 것도 외부 데이터 작업을 위한 좋은 솔루션을 제공하지 않기 때문에 오늘날에는 두 접근 방식 모두 적합하지 않다는 것입니다. 서비스 인터페이스는 어떤 규모의 데이터 교환에도 적합하지 않습니다. 메시징은 데이터를 이동하지만 기록을 저장하지 않으므로 시간이 지남에 따라 데이터가 손상됩니다. 공유 데이터베이스는 한 지점에 너무 집중하여 진행을 방해합니다. 우리는 필연적으로 데이터 오류의 순환에 갇히게 됩니다.

데이터 실패의 주기

스트림: 데이터 및 서비스에 대한 분산형 접근 방식

이상적으로는 서비스가 공유 데이터와 함께 작동하는 방식을 바꿔야 합니다. 이 시점에서 어느 접근법이든 앞서 언급한 이분법에 직면하게 됩니다. 그 위에 뿌려서 사라지게 할 수 있는 마법 가루가 없기 때문입니다. 그러나 우리는 문제를 다시 생각해 보고 타협점에 도달할 수 있습니다.

이러한 타협에는 어느 정도의 중앙 집중화가 포함됩니다. 안정적이고 확장 가능한 스트림을 제공하기 때문에 분산 로그 메커니즘을 사용할 수 있습니다. 이제 우리는 서비스가 이러한 공유 스레드에 참여하고 작동할 수 있기를 원하지만 이 처리를 수행하는 복잡한 중앙 집중식 God Services는 피하고 싶습니다. 따라서 가장 좋은 옵션은 각 소비자 서비스에 스트림 처리를 구축하는 것입니다. 이러한 방식으로 서비스는 다양한 소스의 데이터 세트를 결합하고 필요한 방식으로 작업할 수 있습니다.

이 접근 방식을 달성하는 한 가지 방법은 스트리밍 플랫폼을 사용하는 것입니다. 많은 옵션이 있지만 오늘은 Kafka를 살펴보겠습니다. Kafka의 상태 저장 스트림 처리를 사용하면 제시된 문제를 효과적으로 해결할 수 있기 때문입니다.

분산 로깅 메커니즘을 사용하면 잘 다져진 경로를 따르고 메시징을 사용하여 작업할 수 있습니다. 이벤트 중심 아키텍처. 이 접근 방식은 발신자가 아닌 수신자에게 흐름 제어를 제공하기 때문에 요청-응답 메커니즘보다 더 나은 확장 및 분할을 제공하는 것으로 간주됩니다. 그러나 이생의 모든 것에 대해 비용을 지불해야 하며 여기에는 중개인이 필요합니다. 그러나 대규모 시스템의 경우에는 그만한 가치가 있습니다(일반적인 웹 애플리케이션의 경우에는 그렇지 않을 수 있음).

브로커가 기존 메시징 시스템이 아닌 분산 로깅을 담당하는 경우 추가 기능을 활용할 수 있습니다. 전송은 분산 파일 시스템뿐만 아니라 거의 선형적으로 확장될 수 있습니다. 데이터는 꽤 오랫동안 로그에 저장될 수 있으므로 메시지 교환뿐만 아니라 정보 저장도 가능합니다. 변경 가능한 공유 상태에 대한 걱정 없이 확장 가능한 스토리지입니다.

그런 다음 상태 저장 스트림 처리를 사용하여 소비 서비스에 선언적 데이터베이스 도구를 추가할 수 있습니다. 이것은 매우 중요한 아이디어입니다. 데이터는 모든 서비스가 액세스할 수 있는 공유 스트림에 저장되지만 서비스에서 수행하는 집계 및 처리는 비공개입니다. 그들은 엄격하게 제한된 상황에서 고립되어 있음을 발견합니다.

불변 상태 스트림을 분리하여 데이터 이분법을 제거합니다. 그런 다음 상태 저장 스트림 처리를 사용하여 모든 서비스에 이 기능을 추가합니다.

따라서 귀하의 서비스가 주문, 제품 카탈로그, 창고 작업을 수행해야 하는 경우 전체 액세스 권한을 갖게 됩니다. 결합할 데이터, 처리할 위치 및 시간이 지남에 따라 변경되는 방식은 귀하만이 결정할 수 있습니다. 데이터가 공유된다는 사실에도 불구하고 데이터 작업은 완전히 분산되어 있습니다. 모든 것이 귀하의 규칙에 따라 진행되는 세상에서 각 서비스 내에서 생산됩니다.

무결성을 손상시키지 않고 데이터를 공유하세요. 필요한 모든 서비스에서 소스가 아닌 함수를 캡슐화합니다.

데이터를 한꺼번에 이동해야 하는 경우가 있습니다. 때때로 서비스에는 선택한 데이터베이스 엔진의 로컬 기록 데이터 세트가 필요합니다. 중요한 점은 필요한 경우 분산 로깅 메커니즘에 액세스하여 원본에서 복사본을 복원할 수 있다는 것을 보장할 수 있다는 것입니다. Kafka의 커넥터는 이 작업을 훌륭하게 수행합니다.

따라서 오늘 논의된 접근 방식에는 몇 가지 장점이 있습니다.

• 데이터는 장기간 로그에 저장될 수 있는 공통 스트림의 형태로 사용되며, 공통 데이터를 사용하는 메커니즘은 각 개별 컨텍스트에 하드와이어되어 있어 서비스가 쉽고 빠르게 작동할 수 있습니다. 이러한 방식으로 데이터의 이분법이 균형을 이룰 수 있습니다.
• 다양한 서비스에서 들어오는 데이터를 세트로 쉽게 결합할 수 있습니다. 이는 공유 데이터와의 상호 작용을 단순화하고 데이터베이스에서 로컬 데이터 세트를 유지할 필요성을 제거합니다.
• 상태 저장 스트림 처리는 데이터만 캐시하고 정보의 출처는 일반 로그로 유지되므로 시간이 지남에 따라 데이터가 손상되는 문제는 그리 심각하지 않습니다.
• 서비스의 핵심은 데이터 기반입니다. 즉, 데이터 양이 계속 증가함에도 불구하고 서비스는 여전히 비즈니스 이벤트에 신속하게 대응할 수 있습니다.
• 확장성 문제는 서비스가 아닌 브로커에 있습니다. 확장성에 대해 생각할 필요가 없기 때문에 서비스 작성의 복잡성이 크게 줄어듭니다.
• 새로운 서비스를 추가하는 데 기존 서비스를 변경할 필요가 없으므로 새로운 서비스 연결이 더 쉬워집니다.

보시다시피 이는 단순한 REST 그 이상입니다. 우리는 분산된 방식으로 공유 데이터로 작업할 수 있는 도구 세트를 받았습니다.

오늘 기사에서는 모든 측면을 다루지는 않았습니다. 요청-응답 패러다임과 이벤트 중심 패러다임 사이의 균형을 맞추는 방법을 알아내야 합니다. 하지만 이 문제는 다음 시간에 다루겠습니다. 예를 들어 상태 저장 스트림 처리가 왜 그렇게 좋은지 더 잘 알아야 할 주제가 있습니다. 이에 대해서는 세 번째 기사에서 이야기하겠습니다. 그리고 우리가 활용한다면 활용할 수 있는 다른 강력한 구조도 있습니다. 예를 들어, 정확히 한 번만 처리. 이는 거래 보장을 제공하기 때문에 분산 비즈니스 시스템의 판도를 바꾸는 것입니다. XA 확장 가능한 형태로. 이 점은 네 번째 기사에서 논의될 것입니다. 마지막으로 이러한 원칙의 구현 세부 사항을 검토해야 합니다.

하지만 지금은 이것만 기억하세요. 데이터 이분법은 비즈니스 서비스를 구축할 때 직면하는 힘입니다. 그리고 우리는 이것을 기억해야 합니다. 비결은 모든 것을 뒤집어서 공유 데이터를 일류 개체로 취급하기 시작하는 것입니다. 상태 저장 스트림 처리는 이에 대한 고유한 절충안을 제공합니다. 진행을 방해하는 중앙 집중식 "신 구성 요소"를 방지합니다. 또한 데이터 스트리밍 파이프라인의 민첩성, 확장성 및 탄력성을 보장하고 이를 모든 서비스에 추가합니다. 따라서 우리는 모든 서비스가 해당 데이터에 연결되고 작업할 수 있는 일반적인 의식의 흐름에 집중할 수 있습니다. 이는 서비스를 더욱 확장 가능하고 상호 교환 가능하며 자율적으로 만듭니다. 따라서 화이트보드와 가설 테스트에서 보기 좋게 보일 뿐만 아니라 수십 년 동안 작동하고 발전할 것입니다.

과정에 대해 자세히 알아보세요.

출처 : habr.com