Google Cloud - instance 간 통신 (pubsub + memcache 는 인스턴스 간 통신 및 일관성 보장)

GCP - appengine는 version 관리 응용을 통해 appengine에 여러 개의 version(dev,qa 등)을 배치할 수 있다. 각각의 version에는 여러 개의 instance가 있을 수 있다. 하나의 instance는 SpringBoot를 바탕으로 하는 마이크로 서비스로 간단하게 이해할 수 있다. 요청이 도착할 때 appengine는 일정한 정책에 따라 어느 instance가 이 요청을 처리하는지 선택한다. 만약에 기존의 instance가 처리하는 데이터가 이미 많다면그러면 appengine는 이 요청을 처리하기 위해 새로운 instance를 시작합니다. 이 행위는 주로 instance의 세 가지 확장 정책에 의해 결정됩니다. 수동, 자동, 기초입니다.
배경.
응용 데이터는 GCP의 데이터 저장 구성 요소인 데이터스토어에 저장되며 데이터스토어는 NosQL 데이터베이스입니다.가령 우리의 응용 프로그램이 그 중 일부 데이터 M의 조작에 대한 QPS 요구가 매우 높고 매번 데이터스토어에서 조회하면 수요를 만족시키지 못할 것이다.

//    M   
POST /m

//    M   
GET /m

솔루션
요청의 처리 속도를 높이기 위해서, 프로그램이 시작될 때 (즉 instance가 시작될 때) 이 부분의 데이터를 모두 메모리에 불러온 다음, 매번 데이터스토어에서 조회하지 않고 메모리에서 직접 읽습니다.이런 방식에는 몇 가지 문제가 해결되어야 한다.

요청이 도착할 때마다 appengine가 요청 루트를 어느 instance에 줄지 확인하지 않기 때문에 이 부분의 데이터가 업데이트될 때(POST /m) 이 버젼의 모든 instance에 데이터 동기화를 알릴 필요가 있음

POST /m 요청에서 모든 instance가 데이터를 동기화하는 데 성공했는지 확인해야 (모든 instance에서 M 데이터가 일치함) 요청 처리가 성공한 상태로 되돌아갈 수 있습니다.

데이터 동기화 - pubsub
instance 간 통신은 까다로운 문제입니다. appengine가 API나 외부 구성 요소를 직접 제공하지 않았기 때문에, 심지어 지정한 instance에 요청을 보내려면 많은 유연성을 희생해야만 실현할 수 있습니다.물론 대다수 상황에서 요청하는 루트는 appengine가 제어해야 하며 특정한 특수한 수요를 실현할 때만 특수한 방법을 고려할 수 있다.
데이터 동기화의 기본적인 사고방식은 POST /m시 데이터스토어transactions에서 M 데이터를 업데이트하고 업무가 성공적으로 제출된 후에pubsub를 통해 모든instance가 데이터스토어에서 최신 데이터를 업데이트한다고 통지하며 모든instance가 데이터를 업데이트한 것을 확인한 후에 성공을 요청하는 것이다.
appengine 요청 루트 설명을 보면 다음 형식의 주소를 통해 요청 루트를 지정한 instance에 전달할 수 있음을 알 수 있습니다.https://[INSTANCE_ID]-dot-[VERSION_ID]-dot-[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com 그러나 이런 방식은 확장 방식을 수동 확장으로 설정해야 한다. INSTANCE_ID는 instance의 유일한 id가 아니라 아래 색인이다. 예를 들어version 테스트는 3개의 instance가 있는데 각각 A, B, C이다. 그러면 테스트[0], 테스트[1], 테스트[2]를 통해 세 개의 instance에 성공적으로 접근할 수 있다는 것을 보장할 수 있다. 그러나test[0]가 도대체 A, B, C를 가리키는지 알 수 없다.
pubsub는 GCP의 메시지 구성 요소로 메시지가 발송된 후 소비자들은 두 가지 방식으로 메시지를 소비한다:pull과push

pull: 끌어당기는 방식으로 정보를 소비하는 목적입니다. 우리의 목적은'데이터 동기화'라는 메시지를 모든 instance에 즉시 알리는 것입니다. pull의 방식은 모든 instance가 윤문으로 메시지를 검사하고 끌어당기는 것이기 때문에 자원 점용과 응답 속도(POST /m에 있어서 요구를 만족시킬 수 없습니다.

push: 이런 방식은pubsub의 지정한 topic에 메시지를 보내면pubsub는 이 메시지를push에서 이 topic의 모든subscriber(subscriber가 지정한endpoint에 구독할 수 있도록 설정합니다. 여기에 우리의 영역은 https://[INSTANCE_ID]-dot-[VERSION_ID]-dot-[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com로 설정해야 합니다.

주의해야 할 것은pubsub의 tpoic와subscriber의 창설은 한 번만 실행하면 됩니다. 버젼이 시작된 후에 appengine-taskqueue를 통해 n개의subscriber를 창설할 수 있습니다. n은 이 버젼의 실례수입니다.이것은 실례 수량 n이 상수라는 것을 의미한다. (수동 확장 모드만 n이 상수임을 확보할 수 있다.)
여기까지 POST /m 에서 모든 instance에 '데이터 동기화' 를 알리면 이 메시지를 정확하게 보내고 최종적으로 모든 instance에 알릴 수 있습니다.appengine 예약된/사용ah/push-handlers/.* 경로는 endpoint의 인증과 권한을 간소화할 수 있다. 최종 endpoint는 다음과 같은 형식이다. https://[INSTANCE_ID]-dot-[VERSION_ID]-dot-[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com/_ah/push-handlers/your-topic-namepubsub가push를 진행할 때 각instance의POST /_ah/push-handlers/your-topic-namecontroller/handler는 요청을 받고 메시지 내용을 휴대한다.이 요청에서 우리는 메시지에서 데이터를 어떻게 업데이트해야 하는지 알고 데이터 동기화 작업을 완성할 수 있다.
일관성 - memcahce
위에서 데이터 동기화의 구체적인 절차를 소개했는데 이 과정에서 일치성을 확보하는 것이 매우 중요하다. 주로 데이터 동기화를 할 때 모든 instance가'데이터 동기화'정보를 성공적으로 소비해야 POST /m요청이 성공적으로 처리된 상태로 되돌아갈 수 있다는 데 나타난다.
여기서 version의 instance 수량 n은'상량'이다. 그러면 우리는 하나의 공공 장소에서 표지 A를 유지하기만 하면 현재 성공적으로 동기화된 instance 수량을 표시한다. 이 A==n일 때 모든 instance가 데이터를 성공적으로 동기화했다는 것을 의미한다.
appengine-memcache는 주로 appengine에 응용되는 분포식 캐시 서비스입니다. 우리는 위에 이 유일한 표지를 저장할 수 있습니다. POST /m 요청에서'데이터 동기화'메시지를 성공적으로 발송한 후memcache에서 A의 값을 조회하는 방식으로memcache에서 A의 값을 조회할 수 있습니다. 동시에POST /_ah/push-handlers/your-topic-name에서 A의 값을 증가시켜야 합니다. A==n일 때 동기화가 완료되었음을 나타냅니다.