기업이 클라우드 스토리지에서 저지르는 흔한 실수와 이를 피하는 방법

Source: Dev.to

계속해서 나는 대기업들이 클라우드 스토리지를 마법 같은 무한 디스크처럼 취급해서 돈을 낭비하고, 성능을 저하시키며, 혹은 규정 준수 악몽을 만들고 있는 것을 본다. 그렇지 않다. 클라우드 스토리지는 도구 상자일 뿐이다. 그리고 모든 일을 망치로 해결하려 하면 결국 엄지손가락을 다치게 된다. 여기 내가 가장 흔히 보는 실수들과, 만약 처음부터 다시 구축한다면 어떻게 피할 수 있는지에 대한 방법을 정리했다.

1. 클라우드 스토리지를 온‑프레미스 SAN처럼 다루기

대신 하는 방법

• 오브젝트 스토리지를 기본으로 사용:
  • 팀 간에 공유되는 경우
  • 읽기‑위주인 경우
  • 장기 보관되는 경우
• 블록 스토리지는 지연‑민감하고, 긴밀히 결합된 워크로드(예: 데이터베이스, 특정 레거시 앱)용으로 예약.
• “모든 것을” 블록 스토리지에 넣고 있다면, 이는 클라우드에서 옛 방식을 재구현하고 있다는 빨간 신호입니다.

2. 모든 데이터를 가장 뜨거운(가장 비용이 많이 드는) 티어에 보관하기

이를 피하는 방법

• 데이터를 hot / warm / cold / archive 티어로 분류합니다.
• 기본적으로 모든 버킷에 자동 라이프사이클 정책을 적용합니다:

# Example lifecycle policy (pseudo‑YAML)
rules:
  - action: transition
    days: X          # after X days → cool tier
    storageClass: COOL
  - action: transition
    days: Y          # after Y days → archive tier
    storageClass: ARCHIVE
  - action: delete
    days: Z          # optional: delete after Z days

• 데이터를 뜨겁게 유지해야 한다는 이유를 적극적으로 제시할 수 있는 경우에만 예외로 둡니다.
• 경험 법칙: 누군가가 5초 안에 데이터셋을 뜨겁게 유지해야 하는 이유를 말하지 못한다면, 그 데이터셋은 뜨거운 티어에 있을 필요가 없을 가능성이 높습니다.

3. Egress 및 API 비용 무시

이를 피하는 방법

• 기본적으로 컴퓨트와 스토리지를 동일한 지역에 공동 배치합니다.
• 고 I/O 워크로드의 경우, 작은 파일을 큰 객체로 샤딩합니다 (예: WebDataset, TAR, Parquet).
• 캐싱 사용:

Local NVMe or node‑local SSDs as a read‑through cache for frequently accessed datasets.

• 다음을 표시하는 비용 대시보드를 설정합니다:
  • 가장 많은 egress 소스
  • API 요청이 가장 많은 버킷

egress와 API 호출을 측정하지 않으면 놀라게 됩니다. 클라우드 서프라이즈는 언제나 비용이 많이 듭니다.

4. 성능‑중요 워크로드에 대한 데이터 로컬리티 전략 부재

나의 규칙

• 데이터와 컴퓨팅은 물리적으로 가능한 한 가깝게 위치해야 합니다.

대규모 학습 워크로드의 경우

• 동일한 리전의 객체 스토리지에 정규 데이터를 보관합니다.
• 작업 시작 전에 활성 샤드를 로컬 NVMe에 스테이징합니다.

실시간 추론이 중요한 경우

• 모델과 핵심 피처를 로컬 SSD / 고성능 블록 스토리지에 보관합니다.

고성능 GPU에 비용을 지불하고 있다면, GPU가 바이트를 기다리며 유휴 상태가 되는 것보다 빠른 스토리지를 과다 프로비저닝하는 것이 거의 항상 더 저렴합니다.

5. 과도한 공유와 부족한 거버넌스 버킷

처리 방법

• 데이터 도메인별 설계를 하고, “모든 것을 통제하는 하나의 버킷”은 피합니다:
  • analytics-, ml-, raw-, archive-, 등.
• 버킷/도메인별로 명확한 소유자를 지정합니다:
  • Data owner
  • Access‑policy owner
  • Lifecycle‑policy owner
• 최소 권한 IAM을 사용합니다:
  • 가능한 경우 읽기 전용
  • 쓰기 권한을 최소화
  • 프로덕션 버킷과 실험 버킷을 강력히 분리

보안 팀이 이를 좋아합니다. 감사팀도 마찬가지입니다. 무엇보다 사고를 줄여줍니다.

6. 버전 관리도, 백업도, 복구 테스트도 없음

실용적인 접근법

• 버전 관리를 켭니다 생산 모델, 설정 파일, 혹은 중요한 참조 데이터를 저장하는 모든 버킷에 대해.
• 명확한 복제/백업 전략을 정의합니다:
  • “이 지역이 사라지면 큰 문제가 된다”는 데이터셋에 대해 지역 간 복제.
  • 실수로 삭제되는 것을 방지하기 위해 별도의 “백업 프로젝트/계정”을 사용합니다.
• 복구를 실제로 테스트합니다:
  • 백업에서 임의의 데이터셋을 꺼냅니다.
  • 복구에 걸리는 시간을 측정하고 오류가 발생했는지 기록합니다.

복구를 한 번도 해본 적이 없다면, 작동하지 않을 것이라고 가정하세요.

7. 모두가 “원하는 대로” 영원히 하게 하기

내가 권장하는 방법

• 작은 집합의 storage patterns 만들기:
  • “Analytics dataset pattern”
  • “ML training dataset pattern”
  • “Archive pattern”
• 템플릿 및 도구 제공:
  • Terraform modules, bucket‑naming conventions, lifecycle defaults.
• 편차를 허용하되—우연이 아니라 explicit decisions로 만들 것.

목표는 자체적인 중앙 통제를 위한 것이 아니라; 같은 일을 20가지 방법으로 하면서 각각이 조금씩 다른 방식으로 깨지는 상황을 피하기 위함이다.

모두 합치기

• 데이터는 어디에 저장되어 있나요?
• 버킷은 누가 소유하고 있나요?
• 라이프사이클 정책은 무엇인가요?
• 데이터를 얼마나 자주 이동하거나 복원하나요?

제가 보는 대부분의 “GPU 성능 문제”는 실제로는 위장된 스토리지 설계 문제입니다. 클라우드 스토리지를 전략적 시스템(데이터 분류, 접근 제어, 라이프사이클 관리, 복원 테스트, 그리고 로컬리티 고려)으로 다루면 보안이 향상되고 비용이 절감되며 GPU가 훨씬 더 만족해합니다.