동작 흐름
1차 체크 서비스
대상 서버를 읽습니다
각 1차 확인 작업은 공개 대상 서버 중 현재 운영 중인 서버만 골라서 점검합니다.
- 공개 서버만 포함
- 비활성 상태 서버는 제외
- 에디션별로 Java / Bedrock 흐름을 분리
주소를 정리하고 안전성을 검사합니다
- URL,
host:port, IPv4, IPv6 입력을 정리합니다. - 한글 도메인 같은 IDN은 ASCII로 변환합니다.
localhost, 사설 IP, loopback, link-local, 내부망 주소는 차단합니다.- Java는 일부 DNS 기반 연결 정보까지 함께 고려합니다.
실제 ping을 보냅니다
- Java와 Bedrock은 서로 다른 방식으로 응답을 확인합니다.
- 응답 시간이 길어지거나 연결이 불가능하면 실패로 분류합니다.
성공하면 즉시 최신 상태를 반영합니다
성공 시 아래 값이 갱신됩니다.
- 온라인 여부
- 현재 / 최대 접속자 수
- 지연 시간
- 버전 정보
- MOTD
- 마지막 온라인 시각
- 연속 실패 횟수 초기화
Java는 비교적 풍부한 메타데이터를 함께 반영할 수 있고,
Bedrock은 응답 구조에 맞는 범위 안에서 핵심 정보만 반영합니다.
실패하면 이전 표시 상태를 보존합니다
이미 이전 상태가 존재하는 서버가 1차 체크에서 실패하면, 사용자에게 보이는 값은 즉시 오프라인으로 바꾸지 않습니다.
- 이전에 보이던 온라인 상태를 우선 유지
- 마지막 점검 시각만 갱신
- 내부적으로 재확인 대상으로 넘김
- 실패 사유를 추적할 수 있도록 기록
이때 상태 이력에도 같은 주기의 점검 기록이 남습니다.
즉, “1차 실패”는 사용자 화면보다 내부 재검증 흐름에 먼저 반영됩니다.
재시도 서비스
재시도 서비스는 전체 서버를 다시 훑지 않습니다.
직전 점검에서 결과가 불안정했던 서버만 골라서 다시 확인합니다.
재시도 서비스가 하는 일
- 스케줄러 입장에서는 빠르게 작업 접수만 확인할 수 있습니다.
- 실제 점검은 백그라운드에서 이어서 실행됩니다.
재시도 결과 처리
재시도는 “최종 확정 단계”입니다.
- 성공하면 최신 상태를 저장하고 retry 플래그를 모두 해제합니다.
- 실패하면 실제 오프라인 상태와 누적 실패 정보가 반영됩니다.
- 같은 점검 주기의 이력은 중복되지 않도록 정리됩니다.
이 구조 덕분에 같은 점검 주기에서 중복된 이력이 쌓이지 않고, 최종 확정값만 남습니다.
Java와 Bedrock의 차이
| 항목 | Java | Bedrock |
|---|---|---|
| 점검 흐름 | Java 전용 흐름 사용 | Bedrock 전용 흐름 사용 |
| 연결 보조 정보 | DNS 기반 연결 정보까지 고려 가능 | 직접 응답 확인 중심 |
| 추가 메타데이터 | 비교적 풍부함 | 핵심 정보 중심 |
MineBoard는 첫 번째 확인에서 빠르게 이상 여부를 잡고,
재확인 단계에서 더 신중하게 최종 상태를 판단하는 방향으로 설계되어 있습니다.
지역 분산 트리거
1차 확인이 끝난 뒤에는 필요할 경우 다른 실행 위치에서 재확인 작업을 이어서 받을 수 있습니다.
이 과정은 보조 안전장치에 가깝고, 추가 연결이 실패하더라도 1차 확인 결과 자체는 유지됩니다.
Last updated on