마이크로 서비스 시스템 아키텍처는 어떻게 네트워크 병목 현상을 피합니까?

서버 응용 프로그램의 마이크로 서비스 아키텍처에 대해 많이 읽었으며 내부 네트워크 사용이 단일체 아키텍처와 비교할 때 병목 현상이나 중대한 단점이 아닌지 궁금합니다.

정확성을 위해 두 용어에 대한 나의 해석은 다음과 같습니다.

1. 모놀리스 아키텍처 : 모든 기능, 데이터 등을 처리하는 단일 언어로 된 하나의 응용 프로그램.로드 밸런서는 최종 사용자의 요청을 각각의 응용 프로그램 인스턴스 하나를 실행하는 여러 컴퓨터에 분산시킵니다.

2. 마이크로 서비스 아키텍처 : 기능 및 데이터의 작은 부분을 처리하는 많은 애플리케이션 (마이크로 서비스). 각 마이크로 서비스는 네트워크를 통해 액세스되는 공통 API를 노출합니다 (동일한 시스템의 프로세스 간 통신 또는 공유 메모리와 반대). API 호출은 주로 서버에서 페이지를 생성하도록 지정되지만이 작업 중 일부는 클라이언트가 개별 마이크로 서비스를 쿼리하여 수행합니다.

순진한 상상에 따르면, 마이크로 서비스 아키텍처는 동일한 시스템 (메모리 및 디스크)에서 더 빠른 리소스와 반대로 느린 네트워크 트래픽을 사용하는 것처럼 보입니다. 내부 네트워크를 통한 API 쿼리로 전반적인 응답 시간이 느려지지 않도록하려면 어떻게해야합니까?

내부 네트워크는 종종 1Gbps 이상의 연결을 사용합니다. 광섬유 연결 또는 본딩은 서버간에 훨씬 더 높은 대역폭을 허용합니다. 이제 API에서 JSON 응답의 평균 크기를 상상해보십시오. 1 초 안에 1Gbps 연결을 통해 이러한 응답을 얼마나 전송할 수 있습니까?

실제로 수학을하자. 1Gbps는 초당 131 072KB입니다. 평균 JSON 응답이 5KB (꽤 많은 경우) 인 경우 한 쌍의 시스템으로 회선을 통해 초당 26214 개의 응답을 보낼 수 있습니다 . 그렇게 나쁘지 않습니까?

이것이 네트워크 연결이 일반적으로 병목 현상이 아닌 이유입니다.

마이크로 서비스의 또 다른 측면은 쉽게 확장 할 수 있다는 것입니다. 하나는 API를 호스팅하고 다른 하나는 그것을 소비하는 두 개의 서버를 상상해보십시오. 연결에 병목 현상이 발생하면 두 개의 다른 서버 만 추가하면 성능이 두 배가됩니다.

이는 초당 26,214 개의 응답이 앱의 규모에 비해 너무 작을 때입니다. 다른 9 쌍을 추가하면 이제 262 140 개의 응답을 제공 할 수 있습니다.

그러나 우리의 서버 쌍으로 돌아가서 비교해 봅시다.

• 데이터베이스에 캐시되지 않은 평균 쿼리에 10ms가 걸리면 초당 100 개의 쿼리로 제한됩니다. 100 개의 쿼리 26,214 응답. 초당 26214 응답 속도를 달성하려면 많은 양의 캐싱 및 최적화가 필요합니다 (응답이 실제로 데이터베이스 쿼리와 같은 유용한 작업을 수행해야하는 경우 "Hello World"스타일 응답은 적합하지 않습니다).

• 내 컴퓨터에서 현재 Google 홈페이지 용 DOMContentLoaded는 394ms가 발생했습니다. 요청이 전송 된 후 초당 3 회 미만의 요청입니다. Programmers.SE 홈 페이지의 경우 603 ms가 발생했습니다. 요청이 전송 된 후 초당 2 건의 요청도 아닙니다. 그건 그렇고, 나는 100 Mbps 인터넷 연결과 빠른 컴퓨터를 가지고 있습니다 : 많은 사용자가 더 오래 기다릴 것입니다.

  병목 현상이 서버 간의 네트워크 속도 인 경우 해당 두 사이트는 문자 그대로 페이지를 제공하는 동안 다른 API를 수천 번 호출 할 수 있습니다.

이 두 사례 네트워크 아마 이론에 병목 수 없음을 보여준다 (실제로, 당신의 병목 현상의 정확한 위치를 확인하기 위해 실제 벤치 마크 및 프로파일 링을 수행해야합니다 귀하의 특정 하드웨어에서 호스팅되는 특정 시스템을). 실제 작업 (SQL 쿼리, 압축 등)을 수행하고 최종 사용자에게 결과를 보내는 데 소요되는 시간이 훨씬 더 중요합니다.

데이터베이스에 대한 생각

일반적으로 데이터베이스는 데이터베이스를 사용하여 웹 응용 프로그램과 별도로 호스팅됩니다. 응용 프로그램을 호스팅하는 서버와 데이터베이스를 호스팅하는 서버 간의 연결 속도는 어떻습니까?

실제로 연결 속도에 문제가있는 경우, 즉 데이터베이스 자체에서 처리 할 필요가없고 현재 사용할 수있는 대량의 데이터 (즉, 큰 이진 파일)를 저장하는 경우가 있습니다. 그러나 이러한 상황은 거의 없습니다. 대부분의 경우 전송 속도는 쿼리 자체 처리 속도와 비교할 때 그리 크지 않습니다.

전송 속도가 실제로 중요한 것은 회사가 NAS에서 대용량 데이터 세트를 호스팅하고 동시에 여러 클라이언트가 NAS에 액세스하는 경우입니다. SAN이 솔루션이 될 수있는 곳입니다. 이것은 유일한 해결책은 아닙니다. Cat 6 케이블은 최대 10Gbps의 속도를 지원할 수 있습니다. 케이블이나 네트워크 어댑터를 변경하지 않고 속도를 높이기 위해 본딩을 사용할 수도 있습니다. 여러 NAS에서 데이터 복제를 포함하는 다른 솔루션이 있습니다.

속도를 잊어 버리십시오. 확장성에 대해 생각

웹앱의 중요한 점은 확장이 가능하다는 것입니다. 실제 성능은 중요하지만 (아직 더 강력한 서버에 비용을 지불하고 싶지 않기 때문에) 확장 성은 필요할 때 추가 하드웨어를 던질 수 있기 때문에 훨씬 더 중요합니다.

• 특별히 빠른 앱이 없다면 더 강력한 서버가 필요하기 때문에 돈을 잃게됩니다.

• 확장 할 수없는 빠른 앱을 보유한 경우 증가하는 수요에 대응할 수 없기 때문에 고객을 잃게됩니다.

같은 방식으로 가상 머신은 10 년 전에 거대한 성능 문제로 인식되었습니다. 실제로 서버에서 응용 프로그램을 호스팅하는 것과 가상 컴퓨터에서 호스팅하는 것은 성능에 중요한 영향을 미쳤습니다. 오늘날의 격차는 훨씬 작지만 여전히 존재합니다.

이러한 성능 손실에도 불구하고 가상 환경은 유연성으로 인해 매우 인기가있었습니다.

네트워크 속도와 마찬가지로 VM이 실제 병목 현상이며 실제 규모에 따라 VM없이 앱을 직접 호스팅하여 수십억 달러를 절약 할 수 있습니다. 그러나 이는 앱의 99.9 %에서 발생하는 것이 아닙니다. 병목 현상은 다른 곳에서 발생하고 VM으로 인한 몇 마이크로 초 손실의 단점은 하드웨어 추상화 및 확장 성의 이점으로 쉽게 보상됩니다.

나는 당신이 '마이크로'부분을 너무 많이 읽고 있다고 생각합니다. 모든 클래스를 네트워크 서비스로 대체하는 것이 아니라, 모 놀리 식 애플리케이션을 합리적인 크기의 컴포넌트로 구성하고 각 컴포넌트는 프로그램의 측면을 처리합니다. 서비스는 서로 통신하지 않으므로 최악의 경우 큰 네트워크 요청을 여러 개의 작은 요청으로 분할했습니다. 반환 된 데이터는 수신 한 데이터와 크게 다르지 않습니다 (더 많은 데이터를 반환하고 클라이언트에서 통합 할 수는 있지만)

결과 시스템이 구성을 통해 단일 응용 프로그램 또는 분산 응용 프로그램으로 실행하기에 충분히 유연 할 수 있도록 코드와 리소스 액세스를 구성합니다. 공통 인터페이스 뒤의 통신 메커니즘을 추상화하고 동시성을 염두에두고 시스템을 구축하는 경우 시스템을 프로파일 링 하고 실제 병목을 찾은 후 모든 것을 쉽게 최적화 할 수 있습니다 .

분산 (엔티티 수준) 시뮬레이션이라는 매우 다른 가정으로 다른 산업에서 다른 관점을 추가하고 싶습니다. 개념적으로 이것은 분산 FPS 비디오 게임과 매우 유사합니다. 주요 차이점 : 모든 플레이어는 일부 상태를 공유합니다 : 드래곤이 현재있는 곳; 데이터베이스 호출이 없습니다. 모든 것이 속도와 지연 시간을 줄이기 위해 RAM에 보관되며 처리량은 관련성이 적습니다 (그러나 완전히 무시할 수는 없습니다).

각 참여 애플리케이션을 단일체 (플레이어의 모든 측면을 나타냄) 또는 마이크로 서비스 (군중에서 단일 플레이어를 나타냄)로 생각할 수 있습니다.

동료들의 관심을 받아 단일 참여 애플리케이션 자체를 공유 할 수있는 소규모 마이크로 서비스 (예 : 피해 중재 또는 가시선 계산, 일반적으로 시뮬레이션에 번들로 제공되는 항목)로 분류했습니다.

문제는 전화를 전달하고 요청을 기다리는 대기 시간입니다. 다른 사람들이 지적했듯이 대역폭은 관련이 없으며 풍부합니다. 그러나 가시 거리 계산이 1 마이크로 초에서 100 마이크로 초로 진행되는 경우 (예 : 모든 플레이어 응용 프로그램에서 공유하는 새로운 마이크로 서비스의 대기열로 인해) 큰 손실이 발생합니다 (여러 가지 또는 여러 가시 거리 계산이 필요할 수 있음). 각 업데이트, 여러 업데이트 / 초).

서비스 작동 방식, 서비스 요청시기 및 교환되는 데이터에 대해 신중하게 생각하십시오. 우리의 응용 프로그램은 이미 위치 정보 만 교환하지 않고 잘못된 계산 정보를 교환합니다. 나는 위치 x에 있고 속도 q에서 y 방향으로 향하고 있습니다. 그리고 그 가정이 바뀔 때까지 내 정보를 업데이트 할 필요가 없습니다. 업데이트가 적고 대기 시간 (아직 문제가되는 경우)이 비례 적으로 덜 자주 나타납니다.

따라서 더 높은 주파수에서 미세 입자로 서비스를 요청하는 대신 다음을 수행하여 주파수를 낮추십시오.

1. 요청 된 데이터 변경 및 로컬 계산 사용
2. 비동기 응답을위한 쿼리 또는 트리거 매개 변수 전송
3. 일괄 요청
4. 추측에 대한 요청을 예측하고 사전에 응답을 준비 (게으른 평가의 반대)
5. 가능하면 다른 마이크로 서비스를 호출하는 마이크로 서비스를 피하십시오. 이것은 분명히 문제를 복잡하게 만듭니다. 나는 이것이 마이크로 서비스를 더 크게 만들고 포인트를 어느 정도 훼손시키는 동기 유발이라는 것을 이해하지만 마이크로 서비스는 대기 시간의 친구가 아니다. 어쩌면 그것을 인정하고 극복하십시오.

이제 시스템에 대한 가정을 확인하십시오. 대기 시간보다 처리량에 더 관심이 있거나 공유 상태 등이없는 경우, 마이크로 서비스를 사용하십시오. 나는 그들이 이해가되지 않는 곳에서는 사용하지 말라고 말하고 있습니다.

순진한 상상력이 맞습니다. 그리고 종종 그것은 중요하지 않습니다. 현대 기계는 빠릅니다. 마이크로 서비스 아키텍처의 주요 장점은 개발 및 유지 관리 노력과 시간에 있습니다.

물론 하나의 실행 파일에 공유 메모리를 사용하거나 여러 서비스를 물리적으로 배포 할 수 없다는 규칙도 없습니다. 당신이 디자인하는 한 그것에 의존하지 않도록하십시오.

많은 사람들이 언급했듯이 네트워크 병목 현상이 아닙니다. 네트워크 취성에 관한 것입니다. 따라서 첫 번째 단계는 동기식 통신을 피하는 것입니다. 소리보다 쉽습니다. 올바른 경계를 가진 서비스 만 있으면됩니다. 올바른 경계로 인해 서비스가 자율적이고 느슨하게 결합되며 응집력이 높습니다. 좋은 서비스에는 다른 서비스의 정보가 필요하지 않습니다. 이미 있습니다. 좋은 서비스가 소통하는 유일한 방법은 이벤트를 통하는 것입니다. 좋은 서비스는 결국 일관성이 있으므로 분산 트랜잭션이 없습니다.

이러한 장점을 달성하는 방법은 먼저 비즈니스 기능을 식별하는 것입니다. 비즈니스 기능은 특정 비즈니스 책임입니다. 전반적인 비즈니스 가치에 약간의 기여. 시스템 경계에 대해 생각할 때 취하는 단계 순서는 다음과 같습니다.

1. 더 높은 수준의 비즈니스 책임을 식별하십시오. 그들 중 몇 가지가있을 것입니다. 이 서비스를 조직이 비즈니스 목표를 달성하기 위해 따라야하는 단계로 취급하십시오.
2. 각 서비스 내에서 더 깊이 탐구하십시오. 부모 서비스로 구성된 하위 서비스 서비스를 식별하십시오.
3. 처음 두 지점과 함께 서비스 커뮤니케이션에 대해 생각합니다. 비즈니스 프로세스 결과를 서로에게 알리기 위해 주로 이벤트를 통해 수행해야합니다. 이벤트는 데이터 컨베이어로 간주되지 않아야합니다.

비즈니스 서비스에는 사람, 응용 프로그램, 비즈니스 프로세스가 포함됩니다. 일반적으로 그 일부만 기술 권한으로 표시됩니다.

이것은 약간 추상적으로 들릴 수 있으므로 아마도 서비스 경계 식별 의 예가 흥미로울 것입니다.

현재 답변에 추가 할 또 다른 요소입니다. A의 단위 서비스 . 모든 통화에서 대기 시간을 피하기 위해 10 회의 통화를하는 대신 DTO에 필요한 10 개의 데이터를 가져 오는 통화를합니다.

그리고 마이크로 서비스는 사람들이 생각하는 것만 큼 작지 않다는 것을 기억하십시오.