마이크로 서비스에서는 리소스 정보를 어떻게 동기화해야 할까?

[Hyune-c]

• 본문에 있는 링크1 링크2

[Hyune-c]

디스커션 코멘트 테스트

[ghojeong]

Plan A 와 Plan B 에서 설명주신 장단점은 이해가 가는데,
Plan C 의 장점이 잘 이해가 가지 않아서 질문을 드립니다.

인증 진행 간 회원 상세 정보를 보여줘야 하며, 통합인증의 테이블을 사용해야 한다. (스냅샷)

인증 진행 중 회원 상세 정보를 보여주어야 할 때,
다른 테이블에서 JOIN 을 해오는게 아니라 통합인증 테이블 만을 사용해서 보여줘야 하는 요구사항이 있었다고 이해했습니다.
그래서 회원상세 정보가 통합 회원정보 테이블에 이해가 갑니다.
하지만 Platform B 와 P 의 회원정보 테이블에도 해당 Attribute 들이 있어야하는게 잘 이해가 안갑니다.

Platform B 와 P 에 없어도, 이미 통합 회원정보 테이블에 필요한 것들이 전부 있으니,
의도한 목적을 달성할 수 있었던게 아닌가요?

각 플랫폼의 회원 등록/수정을 통합 회원에서도 알아야 한다. (동기화)

신규 통합회원 플랫폼이 아니라, 각 플랫폼에서 회원의 등록/수정이 유지되어야 하고,
기존의 플랫폼들의 등록/수정 작업이, 새로운 플랫폼에서도 쉽게 동기화 해야하는 요구사항이라고 이해했습니다.

동기화를 할때 데이터 변환 및 공유를 쉽게 하기 위해, 서로 같은 Attribute 들을 갖도록 한 게 조금은 이해가 갑니다.
하지만 동기화 시점을 어떻게 하시는 지 궁금합니다.

만약 Platform B, P, 신규 플랫폼 3개가 모두 별개의 서비스로 독립되어 있다면,
동기화 하는 시기에 시차가 생길 것 같아서요.
실시간 보다는 조금더 지연이 생길 것 같은데,
만약 Platform B 와 Platform P 에서 동일한 유저의 등록 혹은 수정을 하는 일이 일어나고,
이를 신규 통합회원과 동기화하려고 할 때 Race Condition 이 발생할 위험은 없는지 여쭈어봅니다.

아마도 Platform B 와 Platform P 에서는 동일한 유저가 존재할 수 없는 식으로 되어있지 않을까 추측이 가는데,
그래도 혹시나 해서 제가 아직 이해못한 엄청난 작업이 뒤에 숨어 있는 듯이 느껴졌습니다.

동기화 지연과 유실에 대해서 큐의 도입을 하면, Race Condition 에 대해서 고려하지 않고
계속 동기화 이벤트를 큐에 푸시하면 충분히 해결될 수 있는지 궁금합니다.

소비된 큐가 유실될 위험이 있다는 표현이 있는데,
소비되어 동기화가 완료된 큐의 이벤트는 사라지는게 맞지 않나라는 생각이 들어서요.

큐가 지나치게 길어짐으로 인해서 메모리가 부족해서 큐에 넣어진 이벤트가 소실되는게 아니라,
소비된 큐가 유실된다는 말씀은
소비된 이후에도 큐에 있던 이벤트를 영구적으로 남기려고 하시는 계획이 있으신건가요?

디버깅 및 복구를 위해 큐 이벤트에 대한 영구적인 이벤트를 남기시려는 계획이 있으신것 같아 여쭈어봅니다.

[Hyune-c]

Platform B 와 P 에 없어도, 이미 통합 회원정보 테이블에 필요한 것들이 전부 있으니,
의도한 목적을 달성할 수 있었던게 아닌가요?

• 서로 다른 환경에서 운영되고 있던 플랫폼의 각 DB와 회원 등록/수정 로직이 통합 중에도 유지되어야 합니다.

기존 플랫폼에 영향도가 최소가 되어야 한다는 전제 조건이 있었기 때문입니다..
기존 플랫폼의 각종 로직 유지를 위해 기존 플랫폼에도 회원 리소스를 가져야 하고, 통합인증의 고유 로직을 위해 통합인증에도 회원 리소스가 있어야합니다.
기존 플랫폼에 조회 API 라도 뚫어줫으면 괜찮았겠지만 그것도 안된다는 상황이라 저렇게 만들었네요.

만약 Platform B, P, 신규 플랫폼 3개가 모두 별개의 서비스로 독립되어 있다면,
동기화 하는 시기에 시차가 생길 것 같아서요.
실시간 보다는 조금더 지연이 생길 것 같은데,

• 동기화 간 지연과 유실에 대해 대비해야 합니다.

만약 Platform B 와 Platform P 에서 동일한 유저의 등록 혹은 수정을 하는 일이 일어나고,
이를 신규 통합회원과 동기화하려고 할 때 Race Condition 이 발생할 위험은 없는지 여쭈어봅니다.

• 회원정보 수정은 누가 해야 될까?
  • 트랜잭션 부분 참조

본문의 위 항목들을 참고하시면 될 듯 합니다.

---

아마 2-3 주에 걸쳐 퇴고할거라 부족한 부분은 구두로 설명하면서 내용을 추가 기록 하겠습니다.

[ghojeong]

오오 감사합니다.
동기화 지연과 유실에 대해서 이미 설명을 작성해주셨는데,
제가 궁금했던 큐와 관련된 부분에 대한 질문을 생략하고, 동기화 관련해서만 질문을 드렸던 것 같아서
기존 질문을 조금 수정했습니다.

새로 고침을 해서 한번 더 두번째 질문 읽어주시면 감사하겠습니다.
"엄청난 작업"에 대한 제 생각을 빼먹었네요 ㅋㅋㅋ

[Hyune-c]

소비된 큐가 유실될 위험이 있다는 표현이 있는데,
소비되어 동기화가 완료된 큐의 이벤트는 사라지는게 맞지 않나라는 생각이 들어서요.

제가 생각하는 소비는 작업 단위가 큐에서 나온 것입니다. (처리 완료와는 다름)
즉 실제 서비스에서는 그 작업 단위가 정상적으로 처리되지 않아 재시도 해야될 수도 있다는 거죠.
이때 재시도의 주체가 작업 단위를 담고 있던 큐 인가? 작업 단위를 받은 서비스인가? 도 중요하다고 생각합니다.

사실 지금 회사 규모에 비해 너무 큰 생각인 것은 맞습니다.

[ghojeong]

오호 넵.
"작업 단위를 담고 있던" 과 "작업 단위를 받은" 에 대한 구분은 하지 못하고 있었는데,
알려주셔서 감사합니다!

생각의 단위를 "서비스" 단위로 했어야 했는데, 일반적인 프로그래밍을 하는 것처럼 자료구조를 단위로 하고 있었네요.
이런 설계는 처음인지라 매우 신기합니다. 👍

[Hyune-c]

여기까지의 피드백으로 본문 수정 완료.

[kyupid]

신규 통합회원이 회원가입/수정시에 플랫폼B와 P가 각 디비에 컬럼이름만 다른채 둘다 똑같이 관리되어야한다는 말씀 맞으신가요? 문제를 정확히 이해못했어요

[Hyune-c]

@kyupid

• 오래되고 사용자가 많은 플랫폼 B와 비교적 최근에 개발되었지만 사용자가 적은 플랫폼 P 가 존재합니다.
• 서로 다른 환경에서 운영되고 있던 플랫폼의 각 DB와 회원 등록/수정 로직이 통합 중에도 유지되어야 합니다.

이미 운영되고 있는 2개의 플랫폼에서 회원 리소스를 하나로 통합하는 작업에서 나오는 문제를 적은 것 입니다.

[kyupid]

• 플랫폼 B와 P의 회원테이블을 통합하려고 한다.
• 통합중에 문제가 생길 수 있다.
• 문제가 생기므로 어떻게 통합해야하는지가 중요하다.
• 플랜ABC로 나누어 설명해보겠다.

이렇게 이해했는데 맞을까요?

[Hyune-c]

네. 일반적인 통합은 단일 DB 안에서 이루어지지만, MSA 에서는 이종의 서비스와 DB 가 존재하고 이 것을 통합/운영하는데 오는 어려움을 기록한 것입니다.

[kyupid]

이해했습니다. 설명 감사합니다!