DOCS/journey/ideas/260313_internal_nas_direct_go_sync_아이디어.md

tags

tags
infra nas companyx sync go ideas

260313 내부 NAS 직접 Go 동기화 아이디어

상위 원칙

• Infra Project Identity
• Core Infrastructure Principles
• 공통 작성 원칙: 0_VALUE Writing Principles

관련 문서

• 내부 NAS -> 외부 NAS 경로 교정 및 Go 프로브 검증
• 외부 NAS 동기화 Go/Python/DSM 도구화 리서치
• 외부 NAS -> 내부 NAS 컴퍼니엑스 실시간동기화 리서치

문제 인식

• 현재 Company X 동기화의 실행 주체는 23 서버다.
• 하지만 외부 NAS 원격 조회, 내부 NAS 저장, 주기 실행 상태를 보면 실제 데이터 중심은 내부 NAS 쪽에 더 가깝다.
• 이번 검증으로 내부 NAS에서 외부 DSM 응답과 정적 Go 프로브 실행까지 확인됐으므로, 이제는 23 서버를 거치지 않고 내부 NAS가 직접 동기화 주체가 되는 구조를 검토할 수 있다.
• 지금 구조는 외부 NAS 조회와 내부 NAS 저장 사이에 23 서버가 중간 실행자로 끼어 있다.
• 이 중간 실행자는 현재 동작하지만, 장기적으로 보면 데이터가 머무는 곳과 실행 주체가 갈라져 있어 책임 경계가 한 번 더 꺾인다.

현재상태 -> 기대상태

현재상태

• 실행 주체:
  • 23 서버 crontab
• 실행 파일:
  • /home/admin/infra/scripts/bin/companyx_external_nas_sync.py
  • /home/admin/infra/scripts/bin/companyx_external_nas_sync_hierarchical.py
  • 래퍼:
    • companyx_external_nas_sync_fullscan_cron.sh
    • companyx_external_nas_sync_hierarchical_cron.sh
• 스케줄:
  • */30 * * * * 계층형 동기화
  • 0 1 * * * 하루 1회 전수조사
• 락:
  • /home/admin/.locks/companyx_external_nas_sync.lock
• 런로그:
  • /mnt/hdd/logs/companyx/companyx_external_nas_sync_hierarchical.log
  • /mnt/hdd/logs/companyx/companyx_external_nas_sync_fullscan.log
• 상태/요약:
  • /mnt/nas/workspace/.sync-logs/
  • /mnt/nas/workspace/.sync-logs-hierarchical/
• 저장 구조:
  • 외부 NAS DSM API 조회 -> 23 서버 실행 -> 내부 NAS /mnt/nas/workspace/6.Company X 저장
• 구조 해석:
  • 외부 원본은 외부 NAS
  • 실제 저장 기준은 내부 NAS
  • 하지만 동기화 판단과 실행은 23 서버가 맡고 있다.

기대상태

• 실행 주체:
  • 내부 NAS 자체 스케줄러 또는 내부 NAS cron
• 실행 파일:
  • 내부 NAS에 배포한 Go 단일 바이너리
• 스케줄:
  • 현재 23 서버와 같은 30분 계층형 + 1일 1회 전수조사
  • 또는 같은 의미의 내부 NAS 스케줄 구성
• 락:
  • 내부 NAS 로컬 경로에서 단일 락 파일 관리
• 런로그:
  • 내부 NAS 로컬 로그 경로에 기록
• 상태/요약:
  • 내부 NAS 로컬 저장소 기준 경로에 기록
• 저장 구조:
  • 외부 NAS DSM API 조회 -> 내부 NAS 직접 실행 -> 내부 NAS 로컬 저장소 기록
• 23 서버 역할:
  • 문서화, 상태 확인, 원격 트리거, 결과 수집만 담당
• 구조 해석:
  • 외부 원본은 여전히 외부 NAS
  • 저장 기준도 내부 NAS
  • 실행 판단과 기록도 내부 NAS가 직접 맡는다.

아이디어

• 동기화 프로그램을 Go 단일 바이너리로 만들고, 이를 내부 NAS에서 직접 실행한다.
• 외부 NAS는 DSM API로 읽고, 내부 NAS 로컬 저장소로 바로 기록한다.
• 23 서버는 동기화 본체가 아니라:
  • 문서화
  • 결과 수집
  • 경보/상태 모니터링
  • 필요 시 원격 트리거 역할로 줄인다.

핵심 한 줄은 아래와 같다.

• 저장 기준이 내부 NAS라면, 동기화 실행 주체도 내부 NAS로 맞추는 편이 더 자연스럽다.

23 서버와 같은 설정으로 갈 수 있는가

결론부터 말하면 운영 의미는 거의 같게, 구체 경로는 일부 다르게 가져갈 수 있다.

그대로 가져갈 수 있는 것

• 30분 계층형 + 새벽 1시 전수조사의 이중 스케줄 구조
• 단일 락 파일로 중복 실행 방지 원칙
• 실행 로그와 상태/요약 JSON을 분리하는 방식
• mtime + size 기반 증분 판정 방향
• 계층형 캐시 + 전수조사 보정이라는 운영 개념

이름은 같게 가져갈 수 있지만 경로는 바뀌는 것

• 현재 23 서버 경로:
  • /home/admin/infra/scripts/bin/...
  • /home/admin/.locks/...
  • /mnt/hdd/logs/companyx/...
  • /mnt/nas/workspace/.sync-logs...
• 내부 NAS 직접 실행 시:
  • NAS 로컬 실행 경로
  • NAS 로컬 락 경로
  • NAS 로컬 로그 경로
  • NAS 로컬 상태/요약 경로 로 재정의해야 한다.

그대로 가져가면 안 되는 것

• /mnt/nas를 실행 경로로 쓰는 방식
  • 현재 CIFS 마운트 경로 직접 실행은 Permission denied였다.
• 23 서버의 crontab 자체
  • 내부 NAS에서는 DSM 작업 스케줄러 또는 NAS 측 cron에 맞춰 다시 정의해야 한다.
• 23 서버의 workspace-config 파일 경로 하드코딩
  • 내부 NAS는 별도 런타임/시크릿 주입 방식이 필요하다.

즉 이 아이디어는 23 서버 설정을 그대로 복사하는 것이 아니라, 운영 패턴은 동일하게 유지하고 실행 위치와 경로만 내부 NAS 기준으로 치환하는 방향이 맞다.

기대 효과

• 외부 NAS 조회와 내부 NAS 저장 사이에 23 서버를 중간 실행자로 두지 않아 구조가 단순해진다.
• 저장 기준 장비와 실행 주체가 같아져서, 실패 위치와 운영 책임 경계가 더 직접적으로 보인다.
• Go 단일 바이너리 기준으로 내부 NAS에 배포·교체하기 쉬운 구조를 만들 수 있다.
• 23 서버 장애가 곧바로 동기화 주체 장애로 이어지지 않는 방향을 만들 수 있다.

검증이 필요한 이유

• 현재는 DSM 로그인 + 목록 조회까지만 검증됐고, 실제 파일 다운로드/증분 판단/삭제 후보 기록 전체를 내부 NAS Go 바이너리로 옮긴 것은 아니다.
• 내부 NAS DSM 6.2.4 환경에서 재부팅 후 기본 게이트웨이 교정이 유지되는지 아직 별도 검증이 없다.
• 내부 NAS에서 장시간 동기화 프로세스를 어떤 방식으로 스케줄링하고, 로그를 어디에 남기고, 실패 시 누가 복구를 담당할지 운영안이 아직 열려 있다.

이 문서에서 빼야 하는 내용

• 실행 순서, 배포 절차, 롤백 절차, 상태 파일 스키마 확정은 plans로 보낸다.
• 실제 구현 코드, 빌드 명령, 배포 로그, 검증 결과는 worklog 또는 troubleshooting으로 보낸다.
• 현재 Python 스크립트를 어떤 범위까지 유지할지, 병행 운영 기간을 둘지는 plans에서 정한다.

현재 판단

• 이 아이디어는 불가능한가 단계는 이미 지났다.
• 현재 남은 질문은 내부 NAS 직접 실행이 더 자연스러운 구조인가인데, 지금까지의 검증으로는 그렇다 쪽 근거가 더 강하다.
• 따라서 이 문서의 핵심 제안은 아래 한 문장으로 닫을 수 있다.

Company X 외부 NAS 동기화는 장기적으로 23 서버 경유 구조보다 내부 NAS 직접 Go 실행 구조가 더 자연스럽다.