Repository navigation
measure(rpo-rto): 새 서버 약 140초 · 반출 업로드 1초 미만 · 리플리카 승격 0.25~8초 (EC2) - #843
Merged
Merged
Conversation
rpo-rto-targets.md 후보 표에서 «새 서버 준비 시간» 과 «반출 주기별 업로드 비용» 이 미측정으로 남았다. - ec2_userdata.sh: 빈 AL2023 박스가 복구 대상(mysql 쿼리 가능)이 되기까지 단계별 시각(ms) - ship_cost.sh: 쓰기 속도(가정 피크 45행/초 · 한계) × 반출 주기(60·300초, ABBA)에서 반출 1건마다 FLUSH ms · 파일 bytes · S3 업로드 ms - launch.sh: 3대 동시(준비 시간 반복 = 박스 수), SHA 고정·terminate·태그 로컬 Docker 엔진이 응답하지 않아 스모크는 못 돌렸다 — 첫 실행이 EC2 이고 실패는 노드 1 에서 빨리 드러난다. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Kd5JwNEziZGdMPDyw6F43Z
문서는 «리플리카를 붙이면 RTO 가 짧아진다» 고 가정했을 뿐 승격 시간을 잰 적이 없다. - promote.sh: 소스를 죽인 순간부터 리플리카가 새 쓰기를 받기까지 4구간(io_stop·apply·switch·write) + 죽이는 순간의 밀림(lag·backlog_tx) + 잃은 트랜잭션. 쓰기 속도 2팔(가정 피크 · 한계), 버림판 포함 - 감지·판단·앱 연결 전환 시간은 제외(결과에 명시). 같은 박스 컨테이너라 CPU 를 나눠 쓴다는 한계도 조건 파일에 남김 - 로컬 스모크: 리플리카를 super_read_only 로 «기동» 하면 이미지 초기화가 실패한다 → 기동 뒤에 건다 Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Kd5JwNEziZGdMPDyw6F43Z
§6-2 에 남은 빈칸 셋을 EC2(m6i.xlarge · 8.0.46)로 쟀다. - 새 서버 준비: 빈 EC2 → 복구 대상 MySQL 이 쿼리를 받기까지 약 140초(3대), 그중 bootstrap 107~110초. 구성 2 복구 시간은 다른 실험 값과 합쳐 약 6.5~7분 - 반출 업로드: 가정 피크(초당 45행)에서 반출 1번 0.48~0.71초 · FLUSH 52~56ms → «최대 손실 = 주기 + 업로드 시간» 의 업로드 몫은 1초 미만 - 리플리카 승격: 밀림 없으면 약 0.25초, 약 21초 밀리면 약 7.8초(거의 전부 적용). 한 박스 동거라 «잃은 0» 은 다른 박스에선 성립 안 함, 감지·앱 전환 시간 제외 숫자 결정(반출 주기·백업 주기·보존·리플리카)은 여전히 사용자 몫 — 근거만 붙였다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Member
Author
|
@coderabbitai review |
|
Caution Review failedThe pull request is closed.
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. |
Action not completed
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
무엇
docs/decisions/rpo-rto-targets.md§6-2 에 남아 있던 빈칸 셋을 EC2(m6i.xlarge · MySQL 8.0.46)로 쟀다. rig 는 앞 커밋 둘(8200b521·96677a25), 결과·문서는 마지막 커밋.142.9초). 그중 bootstrap 107110초loadtest/results/server-prep-and-ship-cost-2026-11-08/README.md§156ms. 최대 속도로 쓰면 1GB 파일 2.312초loadtest/results/replica-promotion-2026-11-08/README.md95초 ≈ **약 6.57분**(서로 다른 실험의 합, 사람 시간 제외)인용할 때 떼면 안 되는 조건
결정은 아직
반출 주기 · 백업 주기 · 보존 기간 · 리플리카(Q4·Q5·Q6) 숫자는 그대로 열어 두었다. 이 PR 은 근거만 붙인다.
🤖 Generated with Claude Code