[논의] feat/backup: 외부 기능 참조에 관하여

[chiho0270]

데이터 백업 관리 #12
데이터 백업 기능은 "직원 데이터 백업 관리"의 역할을 지녔습니다.
그 중 직원 정보 수정 이력과 직원 정보, 파일 저장을 내부 처리가 아닌 외부 처리를 요구하고 있습니다.
이에 대해서 어떤 방식으로 참조할지 의견을 구하고자 합니다.

직원 정보 수정 이력

• 백업 전제조건

  이전 백업으로부터 현재 사이에 등록된 직원 정보 수정 이력이 있다면 백업 필요

• 직원 정보 수정 이력의 시간을 비교 대상으로 호출하고자 합니다.
  (수정 이력과 백업 이력의 비교 중 백업 필요의 판단을 수행하기 위해서는 시간이 적합하다고 생각하였습니다.)

직원 정보

• 백업 대상

  모든 직원 정보를 .csv 파일 생성

• 모든 직원 정보를 한 번에 처리하기보다 하나의 직원에 대한 상세 정보를 다음과 같이하고자 합니다.
  (해당 정보는 프로토타입의 파일 순서를 참고하였습니다.)

  {직원 정보 식별자}
{사원번호}
{이름}
{이메일}
{부서} *
  {직급}
{입사일}
{상태}

  *해당 부분에서 부서 이름과 부서 식별자에 대해 고민 중입니다. (프로토타입에서는 부서 이름을 표기하고 있습니다.)
  다음은 프로토타입에서의 백업 파일 순서입니다.

파일 관리

• 백업 파일

  백업 성공 시 생성된 employee_backup_{backupId}_{timeStamp}.csv을 파일 저장
  백업 실패 시 생성된 employee_backup_log_{backupId}_{timeStamp}.log을 파일 저장

• 생성된 파일을 파일 관리로 요청보내고, {파일 식별자}를 응답받고자 합니다.
  다음은 프로토타입에서의 백업 파일명입니다.

[kimdotcom2]

생성, 수정, 퇴사 등 이력 유형에 상관없이 새로운 수정 이력이 추가되면, 스케줄러 동작 시점에서 해당 시간을 비교해 데이터 백업의 수행 여부를 결정해야 합니다.

제가 담당하는 직원 정보 수정 이력 모듈에서는 가장 최근에 추가된 이력의 createdAt을 LocalDateTime의 형태로 반환하는 메소드를 인터페이스로 제공해드리면 될 것 같습니다.

제가 이해한 게 맞을까요?

[chiho0270]

데이터 백업 등록은 1시간 주기 자동 반복의 스케줄러 실행과 웹에서의 수동으로 수행 할 수 있습니다.

네, 맞습니다.

[kimdotcom2]

@chiho0270

//BackUp 모듈의 백업 여부 판단을 위한 최근 로그 일자 조회
LocalDateTime getRecentLogDate();

그러면 이러한 형태의 메소드 추가하겠습니다.

[chiho0270]

확인했습니다. 감사합니다!

[chiho0270]

해당 백업 데이터의 요구하는 데이터는 직원 정보입니다. 다음과 같은 데이터 중 부서에 관한 처리

• 직원 정보: 현재 PR [Feat] 직원 정보 관리 기능 구현 (#10) #38 의 Domain 중 부서이름에 관한 데이터를 지니지 않음으로 부서 관리에서 반환 받아야하는지 고민입니다.

아래 두 기능에 대해서는 논의보단 제안인 것 같습니다.

• 직원 정보 수정 이력: 가장 최근에 추가된 이력의 생성 시간 반환
• 파일: 생성 파일의 저장 요청에 파일 식별자 반환

[mainlib990]

@chiho0270 님 안녕하세요. 저의 모듈과 의존관계 있는 부분이라 저와 인터랙션이 필요한 부분같아 의견 남깁니다.

BackupService는 EmployeeService.getEmployees()를 통해 직원 정보를 가져오실수 있을걸로 기대됩니다. 하지만 모든 정보를 한번에 가져오게될 경우 데이터 양이 많아 OOM(Out Of Memory) 문제가 발생하게 됩니다. 따라서 배치 처리가 필요한 부분이며, EmployeeService는 페이지네이션이 필요한 부분입니다.

DTO를 제안해주시면 제가 반영하여 PR 올리겠습니다!

그리고 위와 같이 배치처리를 할 경우 일관성과 확장성 문제가 발생하는데 그 부분에 대해서 좀더 자세한 대화가 필요해보입니다.
BackupService는 EmployeeService를 통해 읽기 작업만 합니다. 따라서 MVCC로만 해결 가능해보이며, 트랜잭션 고립 수준은 다음과 같은 문제를 피할 수 있어 Repeatable Read가 적절해 보입니다:

• Read Committed 할 경우: 최신 커밋 기반으로 레코드 반환
• Repeatable Read 할 경우: 트랜잭션 시작 스냅샷 기준으로 레코드 반환, 따라서 배치 처리 도중 레코드가 삭제되더라도 일관성 유지 가능

하지만 MySQL의 경우, 트랜잭션 고립성 수준을 Repeatable Read로 할 시 팬텀 리드가 발생하기 때문에 Serializable로 할지에 대한 논의는 필요해보입니다. 또한, 주석을 통해 DB Vender 변경시 일관성 문제 발생할 수 있다는 내용을 포함시켜주시면 좋을것 같아보입니다.

@chiho0270 님 의견 어떠한가요??

[chiho0270]

다음은 Dto 제안 입니다.

public record EmployeeBackupDto(
    Long id,
    String employeeNumber,
    String name,
    String email,
    String departmentName,
    String position,
    LocalDate hireDate,
    EmployeeStatus status
) {
}

public record BackupEmployeePageRequestDto(
    Long cursor
    Long idAfter
    Integer size
) {
}

public record BackupEmployeePageResponseDto(
    List<EmployeeBackupDto> content,
    String nextCursor,
    Long nextIdAfter,
    Integer size,
    Long totalElements,
    Boolean hasNext
) {
}

[mainlib990]

@chiho0270 님 순서도 공유 감사합니다.
실패 처리는 Exception 발생시 실패 처리로 변경하라는 의미 같습니다. 나머지는 그대로 진행하셔도 될것같습니다.

[chiho0270]

아하,,,! 알겠습니다.
감사합니다.

[mainlib990]

#47 이슈 등록 완료

[mainlib990]

#48 PR 등록 완료

@chiho0270

[chiho0270]

@SeoGyeongWon 님 안녕하세요!
이전 파일 관리 DTO 생성에 대해 언급한 부분이 완료되지 않은 것 같아서 재차 글 올립니다.
당시 대화에선 명확한 코드 설명이 없이 넘어갔던 것으로 인지하고 있습니다.
때문에 DTO 제안 드리고자 합니다. (만일 이미 생성한 DTO가 있으시다면 코멘트 남겨주시길 바랍니다.)
(#39 를 참고하여 byte[] fileData를 사용했습니다.)

public record FileUploadRequestDto(
        String fileName,
        String fileType,
        byte[] fileData,
        Long fileSize
) {
}

public record FileUploadResponseDto(
        Long fileId
) {
}

public record FileDownloadRequestDto(
        Long fileId
) {
}

public record FileDownloadResponseDto(
        String fileName,
        String fileType,
        Long fileSize,
        byte[] fileData
) {
}

[chiho0270]

위 DTO는 백업 기준에서 어떤 정보로 요청하고 반환이 필요한 지에 대해 작성한 것입니다.
파일 관리 기능 측 메타 정보과 실제 파일에 관한 요구사항을 고려치않은 제안 이오니 참고 부탁드립니다.

[chiho0270]

안녕하세요, @SeoGyeongWon 님!
코멘트를 정정해야 할 것 같아 작성합니다.

아래 DTO에서 Long fileSize가 파일 관리의 기능 중 파일 크기 계산이 있다면, 지워도 됩니다.

public record FileUploadRequestDto(
        String fileName,
        String fileType,
        byte[] fileData,
        Long fileSize
) {
}

---

죄송합니다. 파일 다운로드 요청에 대한 다운로드 작업은 파일 관리의 기능인 것 같습니다.

처음 생각은 파일 다운로드 요청에 파일 다운로드 응답으로 파일을 백업에 보내 사용자에게 파일을 반환해야 한다고 생각했습니다.
하지만, 파일 다운로드 로직에서 백업에 오는 것 쓸데없이 유턴하는 것과 같다는 생각이 들어, 아래 FileDownloadResponseDto의 제안을 취소합니다.

public record FileDownloadResponseDto(
        String fileName,
        String fileType,
        Long fileSize,
        byte[] fileData
) {
}

[SeoGyeongWon]

@chiho0270
치호님 너무 늦게 답변드려서 죄송합니다..... 언급과 메일들을 확인하지 못했었습니다....

백업 관리 기능에서 작성하고 생성된 파일을 MultiPartFile로 변환하고 FileService로 전달하여 파일의 저장을 수행하면 될것 같습니다.

먼저, 파일 관리 기능중 파일 크기 계산이 있습니다. 이를 Multipar의 함수인 getSize()로 구하고자 합니다.

1.

저는 upload관련 Dto를 작성을 안하는쪽으로 생각하고 있습니다.

파일 관리 기능에서 직접 파일을 올리는것이 아닌 파일을 전달 받아 메타정보와 실제파일로 분리하여 저장하는 기능으로 이해를 했습니다.

그렇기에 전달받은 파일의 메타정보를 다루고자 FileMetadataDto를 작성하였습니다.

public record FileMetadataDto(
    Long fileId,
    String fileName,
    String fileType,
    Long fileSize,
    String filePath
) {}

2.

파일 다운로드 기능은 프로토 타입 상 실제 파일 다운로드의 기능이 아닌 직원 목록에서 프로필 이미지가 있는 사람들은 프로필 부분에 이미지가 등록되어 나오게 하는것이라고 이해를 했습니다.

그렇기에 따로 fileId만을 요청하지 않아도 될것같다 생각하여 FileDownloadRequestDto를 작성하지 않았습니다.

위의 기능을 파일의 Id와 File Id에 해당하는 바이트값 으로 파일을 불러와 다운로드에 대한 응답을 수행하고자 생각했습니다.

public record FileDownloadResponseDto(
    Long fileId,
    byte[] fileData
) {}

그렇기에 저는 위의 두 DTO 만을 생성해두었습니다.

현재 PR로 올라가있는 부분과 달라진 부분은 없습니다.

[chiho0270]

@SeoGyeongWon
안녕하세요 경원님, 우선 말씀해주신 사항들을 잘 읽었습니다. 감사합니다.

1 번 사항에 대해 인지했습니다. 메타 정보 관해서는 백업 기능과 무관함으로 그대로 진행해주시면 되겠습니다.
하지만, 위 글에서 제 의견은 실제 파일을 다루는 백업 기능에 한해서 추가적인 DTO 작성을 요구하고 있었습니다.
해당 사항에 대해 검토부탁드립니다.

2 번의 경우 요구사항에 관해 이야기해야 할 것 같습니다.
제 생각은 다음과 같습니다.

• 파일 관리 기능은 메타 정보와 실제 파일을 분리된 부분으로 보고 있습니다.
  때문에 다음과 같이 이해하였습니다.
  • 메타 정보 : 이미지 파일 경로 등
  • 실제 파일 : 백업 및 로그 파일
• 파일 관리 요구사항은 직원 정보 프로필 이미지로 대상을 제한하지 않았으며, 백업 관리 요구사항에 따르면 파일 관리 요구사항에 따라 파일을 저장하라 지시되어 있습니다.
  따라서, 메타정보를 통해 등록된, 직원 정보 프로필 이미지를 불러오는 것은 찬성입니다.
  추가적으로 파일 다운로드 기능에 대해 마련하는 것이 요구사항에 따르는 것이라 판단했습니다.
  실제 프로토타입을 확인해보시면 아래와 같이 백업 이력 다운로드가 가능합니다.

---

검토 부탁드립니다.. 제 견해와 다른 점이 있다면 코멘트 부탁드리겠습니다.

[SeoGyeongWon]

@chiho0270

치호님께서 말씀해주신 내용이 맞습니다.

백업 데이터관련해서 파일 다운로드밑 업로드를 위해 추가적인 DTO작업이 필요할것 같습니다.

치호님이 제안 주셨던 DTO내용 반영행할것 같습니다.

감사합니다!