Initialize RTGS prototype repository
3센터 A-A-A RTGS 실시간총액결제 프로토타입 최초 버전관리 시작. - backend: Kotlin/Gradle 멀티모듈(sequencer, common, 채널/센터 모듈) - frontend: Vite + TS - infra: docker-compose, prometheus/grafana, ELK 네이티브 스크립트 - loadtest(k6), sim(장애/순서/정합성 시나리오), docs(PoC 보고서/복원력방안)
This commit is contained in:
rtgs
173
docs/(참고2) RTGS_ActiveActive_복원력방안에 대한 의견.txt
Normal file
173
docs/(참고2) RTGS_ActiveActive_복원력방안에 대한 의견.txt
Normal file
@@ -0,0 +1,173 @@
|
||||
=========================================================================
|
||||
리뷰결과
|
||||
=========================================================================
|
||||
1. 리뷰어1(최과장) — 항목별 해석 + 저의 판단
|
||||
리뷰어1은 서두에서 자기 방법론을 밝혔습니다. "이 보고서는 앞 절에서 단순하게 던지고 뒤 절에서 조건을 붙여 정정하는 구조라, 특정 절만 보면 틀려 보인다. 뒤에서 해소되면 OK, 안 되면 표현을 고쳐라." — 이건 공정한 태도입니다. 우리 보고서 구조를 정확히 읽었습니다.
|
||||
|
||||
① (1.3) "거액결제 완결 단위를 다자간 동시처리로 단정했다"
|
||||
해석: 우리는 표에서 "거액결제 = 다자간 동시처리(여러 건 묶어 처리)"라고 썼습니다. 리뷰어는 "거액결제는 실제로는 건별 실시간 총액결제(RTGS)가 기본이고, 다자간 차액결제는 일부일 뿐인데, 마치 거액 전체가 묶음처리인 것처럼 단정했다"고 지적합니다. 그리고 "거액 vs 소액의 진짜 차이는 '묶음이냐 건별이냐'가 아니라 '복구 시한이 있느냐 없느냐'"라고 봅니다.
|
||||
|
||||
저의 판단: 부분 수용 (타당). 리뷰어 지적이 사실관계로 맞습니다. 한은금융망(거액 RTGS)의 심장은 건별 실시간 총액결제이고, 다자간 동시처리(다자간 차액결제 동시처리, DvP·차액 등)는 그 일부입니다. 우리 보고서 1.3의 표와 76번 줄은 거액 전체를 "다자간 동시처리라 못 쪼갠다"로 단정하는데, 이는 과도한 단순화입니다.
|
||||
|
||||
다만 우리 논지 자체는 살아있습니다. "거액은 분산이 어렵다"의 진짜 근거는 다자간 동시처리(그로스가 아닌 배치성 정산)와 다자간 잔액 상호의존성이고, 소액 P2P는 건별 독립이라 분산이 쉽다는 대비는 유효합니다. 즉 결론은 유지, 전제 서술만 정정하면 됩니다.
|
||||
리뷰어가 제시한 "진짜 차이 = 복구 시한 유무"는 매우 날카롭습니다. 이건 오히려 우리 보고서의 핵심 주장(소액은 RTO≈0이라 무중단이 최강 난제)과 정확히 일치합니다. 이 프레임을 받아들이면 1.3이 더 강해집니다.
|
||||
② (2.1) "센터 간 지연이 감내 가능하다는 결론이 이론적 거리 기반 수치뿐 — 실측 필요"
|
||||
해석: 우리는 "광교–강남 25km, 남대문 10km라 동기복제 가능(왕복 수 ms)"이라고 썼는데, 리뷰어는 "그건 직선거리로 계산한 이론값이고, 실제 통신사 회선은 돌아가고 중간 장비를 거쳐 더 느리다. 실측하라"고 합니다.
|
||||
|
||||
저의 판단: 완전 수용 (매우 타당). 이건 리뷰어2의 28페이지 지적, 35페이지 지적과 완전히 같은 말입니다(세 리뷰가 한 점으로 수렴 = 신호가 강함). 우리 보고서도 이미 6.1-3, 6.4-2에서 "실측 필요"로 잡아뒀지만, 본문 2.1의 서술 톤이 "수 ms라 성립한다"고 단정적입니다(320번 줄). "이론 거리 기준 근사이며 회선·보안장비 지연 포함 실측이 성립 전제"라고 본문에서 못박아 톤을 낮춰야 합니다.
|
||||
|
||||
③ (2.2) "순차 코어는 수평확장해도 처리량이 안 늘고 상한이 있다 — 확장 가능 영역(주변)과 불가 영역(코어)이 구분 안 됨"
|
||||
해석: "노드를 늘리면 처리량이 비례해 는다(scale-out)"고 했는데, 리뷰어는 "그건 주변부(입구·검증·조회) 얘기다. 코어(순번기, 한 줄로 세우는 부분)는 아무리 노드를 늘려도 '한 줄'이라 안 늘어난다. 이 둘을 섞어 쓰면 독자가 '이 시스템은 무한 확장된다'고 오해한다"고 합니다.
|
||||
|
||||
저의 판단: 이미 반영됨 — 단, 강화 여지. 우리 보고서는 이 구분을 이미 명확히 하고 있습니다: 240번 줄 "수평 확장이 그대로 통하는 곳은 병렬 구간… 직렬 코어(순번기)는 노드를 늘려도 '한 줄'이라는 본질이 바뀌지 않으므로", 2.3-부속 전제① "단일 순번기 병목". 리뷰어가 이 대목을 못 보고 지적했거나, 핵심 권고 4번(24번 줄)처럼 요약부에서 "확장 가능"만 강조된 것을 문제 삼은 것으로 보입니다.
|
||||
|
||||
→ 부분 수용: 본문은 이미 구분돼 있으나, 요약(0장)과 2.2 도입부에서 "확장"을 말할 때 "단, 코어는 예외"를 한 박자 먼저 붙여 오해 소지를 줄이는 게 좋습니다. 서술 위치 조정 문제이지 논리 결함은 아닙니다.
|
||||
|
||||
④ (2.3) "저널이 확정 순서로 기록된 뒤 그 순서대로 소비하면 순서 역전이 불가능한데, 순서오류를 별도 위험으로 서술한 건 전제와 모순"
|
||||
해석: "번호표를 순서대로 뽑아 순서대로 처리하는데 어떻게 순서가 뒤집히나? 순서오류가 진짜 난다면 그건 너희 저널 설계 자체가 잘못된 것이다."
|
||||
|
||||
저의 판단: 기각 (근거 있음) — 단, 서술 명확화는 수용. 이 지적은 리뷰어가 분산 시스템의 현실을 놓친 것입니다. 핵심 구분은 "순번 부여(numbering)"와 "순번 적용(applying)"은 다른 단계라는 점입니다.
|
||||
|
||||
순번기가 번호를 정확히 1,2,3으로 매겨도, 세 센터가 그 저널을 네트워크로 병렬 수신하는 과정에서 패킷 재정렬·버퍼·비동기 I/O로 도착·적용 순서가 드물게 어긋날 수 있습니다. 이건 실제 분산 시스템의 정상적 현상이고, 우리 보고서 288번 줄이 이미 정확히 이렇게 설명하고 있습니다. 국내 PoC에서도 실제 관찰됐다고 명시돼 있습니다.
|
||||
리뷰어가 "순서오류가 실재하면 저널 소비 구조의 설계 문제"라고 한 것은 절반만 맞습니다 — 맞아요, 그래서 우리는 그걸 "탐지·교정 장치"로 설계에 포함시킨 겁니다. 완벽한 순차 소비를 가정하지 않는 것이 오히려 정직한 엔지니어링입니다.
|
||||
리뷰어의 오해는 "동기화가 확정 순서로 완료되었다는 가정하에서"라는 그의 단서에 드러납니다. 바로 그 가정(완벽 동기 완료)을 결제 시스템은 무비판적으로 믿으면 안 된다는 것이 우리 2.3-부속의 논지입니다.
|
||||
→ 따라서 논리적으로 기각하되, 리뷰어가 오해했다는 것은 서술이 그만큼 오해를 유발했다는 뜻이므로, 2.3-부속 도입부에 "순번 부여 ≠ 순번 적용" 구분을 더 앞세워 방어를 명시적으로 하겠습니다. (기각이지만 표현 보강.)
|
||||
|
||||
⑤ (2.5) "결제엔 IBM MQ가 적합하다고 해놓고, 뒤에서 MQ와 GSLB를 혼용"
|
||||
해석: "MQ가 좋다더니 왜 GSLB랑 섞어 쓰냐, 헷갈린다."
|
||||
|
||||
저의 판단: 기각 (명백히 근거 있음). 이건 리뷰어가 우리 2.5절의 핵심 논지를 정면으로 놓친 것입니다. 우리 보고서 369~388번 줄은 정확히 이 오해를 풀려고 **"GSLB와 MQ는 대체 관계가 아니라 다른 계층"**임을 표까지 그려 설명하고, **경로별 분담(결제 전문=MQ 페일오버 / 접속·조회 API=GSLB)**을 명시적으로 정의합니다. 혼용이 아니라 의도적 역할 분리입니다.
|
||||
|
||||
→ 기각. 다만 리뷰어1·리뷰어2가 모두 이 부분을 헷갈렸다면(리뷰어2는 헷갈리지 않았지만), 이 절이 길고 복잡해 오해 소지가 있다는 신호입니다. 2.5 도입에 "결론 한 줄"(결제=MQ, API=GSLB, 둘은 다른 층)을 먼저 박아 넣으면 오해가 줄어듭니다. 표현 보강만.
|
||||
|
||||
⑥ (4) "FedNow 잔액기록을 '분산 인메모리 그리드'로 썼는데, 실제 FedNow는 애플리케이션 레벨 Raft 저널복제 + 코어별 인메모리 처리 — TIPS와 다른 메커니즘"
|
||||
해석: "해외사례 표에서 FedNow 방식을 틀리게 적었다. FedNow는 사실 우리(저널복제) 방식에 더 가깝다."
|
||||
|
||||
저의 판단: 수용 (사실 정정, 그리고 우리에게 유리). 리뷰어 지적이 사실로 맞다면 — FedNow가 Raft 기반 저널 복제라면 — 이는 우리 4장 표 637번 줄 "분산 인메모리 그리드(구현 사례 기준)"를 정정해야 합니다. 그리고 오히려 우리 논지를 강화합니다: 우리의 "저널 순차처리" 방식이 TIPS뿐 아니라 FedNow와도 일치한다는 뜻이니까요.
|
||||
|
||||
단, 검증 필요: FedNow 내부 아키텍처는 상당부분 비공개입니다(우리 보고서도 649번 줄에서 "미공개"라 인정). 리뷰어가 "확인됨(confirmed)"이라 했지만, 출처가 불명확합니다. "Raft 기반 저널 복제로 알려짐/추정" 수준으로 표현하고, 단정은 피하겠습니다. 무엇보다 리스크가 낮은 방향의 수정(우리에게 유리 + 부정확한 단정 제거)이라 수용합니다.
|
||||
⑦ (6.1) "샤딩을 교차거래 비율 측정에 따라 최적화 옵션으로 채택한다는 서술 정정 필요 — FedNow 샤딩은 원장이 아니라 전문·메시지 복제/결과저장용 NoSQL에 적용"
|
||||
해석: "샤딩(쪼개기)을 원장(잔액장부)에 적용하는 옵션처럼 써놨는데, FedNow의 샤딩은 원장이 아니라 **주변부(전문 저장·NoSQL)**에만 쓴다. 원장을 쪼개는 건 위험하니 그렇게 읽히면 안 된다."
|
||||
|
||||
저의 판단: 수용 (타당, 안전한 방향). 이 지적은 우리 보고서의 다른 부분과 오히려 정합적입니다. 우리는 이미 217번 줄과 2.1 샤딩 각주에서 "샤딩(계좌 소유 분담)은 본안이 아니고, 교차거래 비율 낮을 때의 부하분산 최적화 옵션"으로 격하해뒀습니다. 그런데 리뷰어 말대로 "원장 계좌 샤딩"으로 읽힐 여지가 있고, 그건 우리의 "원장은 단일 순번으로 강한 일관성" 대원칙과 충돌합니다.
|
||||
|
||||
→ 수용: 샤딩 옵션을 언급할 때 **"원장을 쪼개는 것이 아니라 주변부(전문 저장·조회 사본)에 한한다"**는 단서를 명확히 붙입니다. 6.4-1의 "최후엔 샤딩 옵션 재검토"도 같은 맥락에서 오해되지 않게 다듬습니다.
|
||||
|
||||
2. 리뷰어1이 우리 보고서 방향에 주는 영향 — 종합
|
||||
핵심: 리뷰어1은 우리 보고서의 골격(근거리 3센터 A-A-A + 저널 순차처리)을 흔들지 않습니다. 7개 지적 중 방향을 바꾸는 것은 하나도 없고, 모두 "표현 정정·명확화" 수준입니다. 이는 역설적으로 우리 설계가 논리적으로 견고하다는 방증입니다.
|
||||
|
||||
지적 판단 보고서 영향 작업 강도
|
||||
① 거액=다자간 단정 부분수용 1.3 전제 서술 정정("건별 RTGS 기본, 다자간은 일부") + 리뷰어의 "복구시한" 프레임 흡수 中
|
||||
② 지연 실측 완전수용 2.1 톤 하향("이론 근사, 회선·장비 포함 실측이 전제") 中
|
||||
③ 코어/주변 확장 구분 부분수용 0장·2.2 도입에 "코어는 확장 예외" 선제 명시 小
|
||||
④ 순서오류 모순 기각+보강 2.3-부속에 "번호부여≠번호적용" 방어 강화 小
|
||||
⑤ MQ/GSLB 혼용 기각+보강 2.5 도입에 결론 한 줄 선제 小
|
||||
⑥ FedNow 메커니즘 수용 4장 표 정정("Raft 저널복제로 알려짐") 小
|
||||
⑦ 샤딩 범위 수용 샤딩=주변부 한정 단서 명확화 小
|
||||
방향 추천: 리뷰어1 지적은 "우리 논지를 유지하되 방어를 더 촘촘히" 하는 재료입니다. 특히 ①의 "복구시한 유무" 프레임과 ⑥의 "FedNow도 저널복제" 사실은 받아들이면 오히려 우리 주장이 강해집니다. 기각한 ④⑤도 "리뷰어조차 헷갈렸다"는 신호로 받아 서술을 더 친절하게 만드는 계기로 씁니다.
|
||||
|
||||
부장님, 여기까지가 **리뷰어1(1·2단계)**입니다. 이어서 **리뷰어2(3단계)**로 넘어가겠습니다.
|
||||
|
||||
3. 리뷰어2(양팀장님) — 항목별 해석 + 저의 판단
|
||||
리뷰어2는 페이지별 하이라이트+메모 형식입니다. 10개 메모 중 대부분이 "좋다 + 이걸 더하라"입니다. 성격별로 묶어 보겠습니다.
|
||||
|
||||
A. BMT로 실증하라 (메모 3건: p1×2, p11) — 가장 강한 반복 신호
|
||||
해석: "저널 순차처리로 이중지급·순서 막는다는 것, 3센터 AAA 가용성, 15,000 TPS '접수처리' 수치 — 이거 다 말로만 하지 말고 BMT(실증시험)로 확인해야 진짜다. 특히 15,000 TPS는 '접수'까지지 '최종 이체확인'까지가 아니다."
|
||||
|
||||
저의 판단: 완전 수용 (핵심 관통). 이건 리뷰어2의 가장 일관된 메시지이고 전적으로 옳습니다. 우리 보고서는 6.4 BMT 8개 항목으로 이미 대응하고 있고, "15,000 TPS는 접수 한정·end-to-end 아님"도 242번 줄·6.4-8에서 명시했습니다. 리뷰어2가 요구하는 것을 우리가 이미 상당부분 갖췄다는 게 확인됩니다.
|
||||
|
||||
→ 다만 리뷰어2가 명시적으로 요청한 것 중 신규 추가할 것: "3센터 AAA와 2센터 AA도 가능한지 BMT에서 함께 확인"(p1 첫 메모). 이건 우리에게 없던 좋은 지적입니다 — 5.3-②에 "2센터 잠정 개시" 옵션은 있지만, BMT 항목에 "2센터 AA 대안의 복원력 실측"을 명시하면 의사결정 폭이 넓어집니다. 수용.
|
||||
|
||||
B. 최대 목표치(peak) 산정 필요 (메모 p10)
|
||||
해석: "2,000 TPS 기준선은 좋다. 근데 그건 하루 2만건 거액 수준이다. 소액은 거액의 100배 이상 건수인데, 기준선만 있고 **최대목표치(스파이크 정점)**가 없다. 그건 잡아야 한다."
|
||||
|
||||
저의 판단: 완전 수용 (날카롭고 정당). 이건 리뷰어2 지적 중 가장 실질적입니다. 우리 보고서는 "고정 숫자 안 박고 scalable" 논리로 238번 줄 최대치 산정을 회피하는 경향이 있는데, 리뷰어 말이 맞습니다 — 확장성만 강조하고 정점 목표를 안 잡으면 용량 설계·비용 산정이 불가능합니다. "scalable하니 됐다"는 우리 논리의 약한 고리를 정확히 찔렀습니다.
|
||||
|
||||
→ 수용: 2.2에 **"기준선(2,000) + 최대목표치(스파이크 정점 배수) 산정"**을 추가하고, 6.1-1에 "최대목표치 산정" 항목을 넣습니다. 다만 정확한 수치는 이용규모 예측이 필요하므로 "산정 방법론과 확인필요"로 잡습니다. (숫자를 지금 지어내지 않음 — 리뷰어도 "산정 필요"라 했지 "얼마"라 하지 않음.)
|
||||
|
||||
C. 정책·비즈니스 선결 (메모 p1 원장동기화, p5 심플, p2 참가기관)
|
||||
해석:
|
||||
|
||||
p1: "센터간 원장 동기화 해결책이 핵심. 3센터가 순서만 보장하면 센터간 동기화 관리가 불필요함을 보장하라."
|
||||
p5: "RTGS 서비스를 최대한 심플하게. 단방향만, 취소·반려는 새 거래로."
|
||||
p2: "정책 필요성 서술 좋다. 참가기관 관점(통신망 신설, 거액/소액 구분 이용, 장애 대응 변화)도 추가하라."
|
||||
저의 판단: 대체로 수용.
|
||||
|
||||
p1은 이미 우리 핵심 논지 — "동기화가 아니라 하나의 순서를 셋이 재생"(17번 줄)이 정확히 "순서 보장 → 동기화 관리 불필요"입니다. 리뷰어2가 우리 방향에 동의·강조한 것. 그 "보장"을 더 명시적으로 못박으라는 요구로 받아 2.3에 한 줄 강화. 수용.
|
||||
p5 "심플하게(단방향·취소는 신규거래)": 매우 좋은 실무 원칙이나 이건 비즈니스 프로세스 설계 영역(금융결제국 소관)입니다. 우리 보고서 482번 줄이 이미 "비즈니스 요구가 먼저 확정되어야"라고 원칙을 세워뒀습니다. → 부분 수용: 5.3 또는 1장에 "서비스 단순성 원칙(단방향·취소는 신규거래 등)을 비즈니스 설계 시 지향"을 시사점으로 한 줄 추가하되, 우리가 확정하지 않고 금융결제국 협의 사안으로 넘깁니다. (리뷰어1의 "비즈니스 요구가 기술을 끌어야" 프레임과도 정합.)
|
||||
p2 참가기관 관점: 정당합니다. 우리 2.5 참가기관 접속·420번 줄에 참가기관 대응이 있지만, "통신망 신설·거액/소액 구분 이용·장애 대응 변화"를 참가기관 부담 관점에서 1장 또는 2.5에 명시적으로 정리하면 보고서가 더 균형잡힙니다. 수용.
|
||||
D. 거리·비용 현실 (메모 p28, p35) — 리뷰어1 ②와 수렴
|
||||
해석:
|
||||
|
||||
p28: "TIPS 3센터는 각각 15km 이내인데, 광교–강남–본부는 그 2~3배다. 이걸 감안하라. 10Gbps 회선 비용 평가도."
|
||||
p35: "3센터 물리거리 latency + 중간 보안장비 latency까지 감안한 BMT 필요."
|
||||
저의 판단: 완전 수용 (리뷰어1 ②와 3중 수렴 = 최강 신호). 세 지적(리뷰어1 ②, 리뷰어2 p28·p35)이 모두 **"거리·회선·보안장비 지연을 이론값이 아니라 실측으로"**를 가리킵니다. 이건 반드시 반영해야 합니다.
|
||||
|
||||
**특히 "TIPS 15km vs 우리 2~3배"**는 아프지만 정확한 지적입니다. 우리 보고서는 211번 줄 등에서 "TIPS 구조를 충실히 재현"이라 하는데, 거리 조건이 TIPS보다 불리하다는 점을 정직하게 명시해야 합니다. "TIPS를 좇는다"면서 물리 전제(거리)가 다르다는 걸 숨기면 방어 불가능해집니다.
|
||||
10Gbps 회선 비용·보안장비 지연: 6.1-15(비용)·6.4-2(합의지연)에 이미 관련 항목이 있으나, "보안장비 통과 지연"과 "회선 등급별 비용"을 명시적으로 추가합니다.
|
||||
→ 수용: 2.1에 "TIPS 대비 거리 열위(TIPS ≤15km vs 우리 10~30km)를 정직하게 명시 + 보안장비 지연 포함 실측이 성립 전제", 6.1/6.4에 회선비용·보안장비 지연 항목 보강.
|
||||
|
||||
E. 조직·개발 모델 (메모 p34)
|
||||
해석: "신기술이라 완전 외주개발이면 당행 직원 내재화 불가능. 최소 공동개발이 필수다."
|
||||
|
||||
저의 판단: 완전 수용 (강한 실무 통찰). 우리 보고서는 752번 줄에서 "실행모델(자체/공동/외주) 비교 선택"이라고 중립적으로 써뒀는데, 리뷰어2는 "중립적으로 두지 말고, 완전외주는 내재화 불가이므로 최소 공동개발이 필수"라고 방향을 특정하라고 요구합니다. 이건 타당합니다 — 코어(순번기·원장 엔진)를 완전 외주하면 24/365 운영·장애대응 역량이 조직에 안 남습니다.
|
||||
|
||||
→ 수용: 5.3-⑤와 6.2-3에서 "완전 외주 지양, 최소 공동개발 이상을 코어 내재화의 하한선으로" 명시. (리뷰어의 방향 제시를 우리 판단으로 재검증한 결과 동의.)
|
||||
|
||||
F. 시각화 (메모 p36)
|
||||
해석: "부록 A 시뮬레이션 결과를 그래프로 보여줄 수 있나?"
|
||||
|
||||
저의 판단: 조건부 수용 (좋으나 우선순위·검증 유의). 부록 A의 S1~S5 결과(잔액 일치, 오거절 1,300건 등)를 그래프화하면 설득력이 올라갑니다. 다만:
|
||||
|
||||
시뮬레이션이 실제 실행된 것인지 sim 폴더 확인이 필요합니다(그래프는 실데이터라야 의미). 지어낸 그래프는 금물.
|
||||
리뷰어2 종합 (4단계 일부) — 방향 영향
|
||||
메모 판단 보고서 영향 강도
|
||||
A. BMT 실증(3건) 수용 대부분 반영됨 + "2센터 AA 대안 BMT" 신규 中
|
||||
B. 최대목표치 완전수용 2.2·6.1에 peak 목표 산정 추가 (약한고리 보강) 中
|
||||
C-p1 순서보장→동기화불요 수용(동의) 2.3 한 줄 강화 小
|
||||
C-p5 서비스 심플 부분수용 시사점 한 줄(금융결제국 협의) 小
|
||||
C-p2 참가기관 관점 수용 1장/2.5에 참가기관 부담 정리 中
|
||||
D. 거리·회선·보안장비 완전수용 2.1 거리열위 정직 명시 + 6장 비용/지연 中
|
||||
E. 최소 공동개발 완전수용 5.3-⑤·6.2 방향 특정 小
|
||||
F. 그래프 조건부 sim 데이터 있으면 그래프 1개 小
|
||||
리뷰어2도 골격을 흔들지 않습니다. 오히려 **우리 방향에 동의하며 "더 정직하게, 더 실측으로, 더 정책까지"**를 요구합니다. 가장 값진 지적은 **B(최대목표치)**와 D(거리 열위 정직화) — 우리 보고서의 두 약한 고리입니다.
|
||||
|
||||
=========================================================================
|
||||
리뷰결과 의견1
|
||||
=========================================================================
|
||||
제 의도와는 다른 해석이 있어 내용을 일부 추가합니다. (제가 내용을 너무 단순화하여 잘못 쓴 것 같아요)
|
||||
|
||||
(2.3)
|
||||
|
||||
IP 계층에서는 패킷이 뒤섞여 도착할 수 있으나, TCP는 단일 커넥션 내에서 이를 재정렬해 애플리케이션에 순서대로 전달
|
||||
따라서 순서 역전의 실질적 원인은 네트워크 계층 자체가 아니라,
|
||||
(1) 처리량 확보를 위한 멀티 파티션/멀티 스레드 병렬화
|
||||
(2) 3개 센터가 각자 독립된 스트림으로 수신/적용 하는 구조로
|
||||
(1)은 파티션, 재정렬 설계로, (2)는 센터간 진행상태 동기화로 대응
|
||||
|
||||
가정(완벽 동기 완료)을 결제 시스템은 무비판적으로 믿으면 안 된다
|
||||
=>믿는 것이 아니라, 순번부여+3센터 동기화 로직 자체가 애플리케이션 레벨에서 보장되어야 한다는 의미
|
||||
|
||||
|
||||
(2.5 - 아마도 주기능(결제)는 MQ로, 관리/부가 서비스는 GSLB로 두 가지 방법 병행한다는 제 보고서 내용이 들어간 듯 보입니다)
|
||||
|
||||
MQ 페일오버 클러스터와 GSLB를 나눈 스코프가 적절하지 않음
|
||||
결제전문 경로의 "접속+인증"은 하나의 연속된 절차로서 MQ경로에 포함되어야 함 (설계에 따라 연결 후 별도 인증절차를 거칠 수도 있음)
|
||||
GSLB는 관리용 웹페이지 접속 등 부가 기능에 사용
|
||||
|
||||
18p 본안 A, 대안 B 비교 표에서,
|
||||
본안A에 MQ와 GSLB가 모두 포함되어 있는데 서로 다른 두 매커니즘을 하나의 열에 합쳐서 서술함
|
||||
- "부하·전환" 행의 "중앙에서 동적 조정·자동 전환(설정 변경 불요)"은 GSLB와 MQ 페일오버의 속성을 혼합 서술
|
||||
- "중앙에서 동적 조정"은 GSLB 특성 -> 중앙이 DNS 응답 변경으로 능동적·사전적 트래픽 유도
|
||||
- "설정 변경 불요"는 MQ 페일오버 특성 -> 참가기관 클라이언트가 로컬 연결목록 기반, 장애 후 자체 재연결
|
||||
- 전환 주체(중앙 vs 참가기관)·시점(사전 vs 사후)이 상이한 두 방식을 단일 셀에 병기
|
||||
|
||||
이상입니다.
|
||||
|
||||
=========================================================================
|
||||
리뷰결과 의견2
|
||||
=========================================================================
|
||||
처리 순서가 제일 중요합니다.
|
||||
순서는 맨앞단에 GSLB에서 3센터 공통으로 지정해 줘야는데
|
||||
순서만 지정하는 거라 이 부분에서 병목현상은 없을텐데
|
||||
이 GSLB를 3센터 중에 한 곳에서 수행할지 또다른 곳에 놓을지를 가용성 보장 측면에서 결정해야 할 것 같습니다.
|
||||
Reference in New Issue
Block a user