paint-brush
AWS S3에서 MinIO로 송환하기 위해 알아야 할 모든 것~에 의해@minio
8,789 판독값
8,789 판독값

AWS S3에서 MinIO로 송환하기 위해 알아야 할 모든 것

~에 의해 MinIO12m2024/03/22
Read on Terminal Reader
Read this story w/o Javascript

너무 오래; 읽다

송환과 관련된 비용 및 절감 효과에 대해 좀 더 자세히 알아보고 자체 분석을 더 쉽게 구성해 보겠습니다.

People Mentioned

Mention Thumbnail
featured image - AWS S3에서 MinIO로 송환하기 위해 알아야 할 모든 것
MinIO HackerNoon profile picture


이전 게시물에 대한 답변은 다음과 같습니다. AWS S3에서 MinIO로 송환하는 방법 , 정말 놀라운 일이었습니다. 우리는 기업으로부터 송환 조언을 요청하는 수십 통의 전화를 받았습니다. 우리는 이러한 답변을 이 새 게시물에 집계하여 송환과 관련된 비용 및 절감액을 좀 더 자세히 분석하여 귀하가 자체 분석을 더 쉽게 구성할 수 있도록 했습니다. 데이터 마이그레이션은 많은 사람들에게 어려운 작업입니다. 실제로 그들은 새로운 데이터가 MinIO에 들어오는 것을 목표로 삼고 클라우드에서 오래된 데이터를 마이그레이션하거나 성장하지 않고 그대로 두는 데 시간을 쏟습니다.

송환 개요

AWS S3에서 데이터를 송환하려면 다음 일반 지침을 따르십시오.


  1. 데이터 요구 사항 검토: AWS S3에서 송환해야 하는 특정 버킷과 객체를 결정합니다. 버킷별로 비즈니스 요구 사항과 규정 준수 요구 사항을 이해해야 합니다.


  2. 송환 대상 식별: 이미 MinIO로 송환하기로 결정했습니다. 이제 온프레미스 데이터 센터나 다른 클라우드 공급자 또는 코로케이션 시설에서 MinIO를 실행하도록 선택할 수 있습니다. #1의 요구 사항을 사용하여 예상되는 스토리지, 전송 및 가용성 요구 사항에 맞는 하드웨어 또는 인스턴스를 선택합니다.


  3. 데이터 전송: AWS S3에서 MinIO로의 데이터 전송을 계획하고 실행합니다. MinIO에 내장된 배치 복제를 사용하거나 MinIO 클라이언트를 사용하여 미러링하기만 하면 됩니다(참조: AWS S3에서 MinIO로 송환하는 방법 자세한 내용은). AWS DataSync, AWS Snowball 또는 AWS Snowball을 사용하는 등 데이터 전송에 사용할 수 있는 몇 가지 추가 방법이 있습니다. TD SYNNEX 데이터 마이그레이션 , 또는 AWS API를 직접 사용합니다.


  4. 데이터 액세스 및 권한: 송환된 데이터에 대해 버킷별로 적절한 액세스 제어 및 권한이 설정되어 있는지 확인합니다. 여기에는 데이터 보안을 보장하기 위해 사용자 액세스, 인증, 권한 부여를 관리하기 위한 IAM 및 버킷 정책이 포함됩니다.


  5. 객체 잠금: 마이그레이션 후에 객체 잠금 보존 및 법적 보존 정책을 유지하는 것이 중요합니다. 대상 객체 저장소는 Amazon S3와 동일한 방식으로 규칙을 해석해야 합니다. 확실하지 않은 경우에는 Cohasset Associates 규정 준수 평가 대상 객체 저장소 구현에 대해.


  6. 데이터 수명주기 관리: 송환된 데이터에 대한 데이터 수명주기 관리 전략을 정의하고 구현합니다. 여기에는 보존 정책, 백업 및 복구 절차, 버킷별 데이터 보관 방식 정의가 포함됩니다.


  7. 데이터 검증: 전송된 데이터의 무결성과 완전성을 보장하기 위해 검증합니다. 데이터가 손상이나 손실 없이 성공적으로 전송되었는지 확인하기 위해 필요한 점검과 테스트를 수행하십시오. 전송 후 개체 이름, ETag 및 메타데이터, 체크섬 및 개체 수는 소스와 대상 간에 모두 일치합니다.


  8. 애플리케이션 및 워크플로 업데이트: 좋은 소식은 클라우드 네이티브 원칙에 따라 애플리케이션을 구축하는 경우 새로운 MinIO 엔드포인트에 맞게 애플리케이션을 재구성하기만 하면 된다는 것입니다. 그러나 애플리케이션과 워크플로가 AWS 에코시스템과 함께 작동하도록 설계된 경우 송환된 데이터를 수용하기 위해 필요한 업데이트를 수행하십시오. 여기에는 구성 업데이트, 통합 재구성 또는 경우에 따라 코드 수정이 포함될 수 있습니다.


  9. 모니터링 및 최적화: 송환된 데이터 환경을 지속적으로 모니터링하고 최적화하여 최적의 성능, 비용 효율성 및 데이터 관리 모범 사례 준수를 보장합니다.

송환 단계

클라우드 송환에 대한 예산을 책정하고 계획할 때 고려해야 할 요소가 많이 있습니다. 다행스럽게도 우리 엔지니어들은 많은 고객과 함께 이 작업을 수행했으며 귀하를 위한 세부 계획을 개발했습니다. 소수의 워크로드부터 수백 페타바이트까지 모든 것을 본국으로 송환한 고객이 있습니다.


가장 큰 계획 작업은 네트워킹, 임대 대역폭, 서버 하드웨어, 송환하도록 선택되지 않은 데이터에 대한 보관 비용, 자체 클라우드 인프라를 관리하고 유지하는 데 드는 인적 비용에 대한 선택을 고려하는 것입니다. 이러한 비용을 추정하고 이에 대한 계획을 세우십시오. 클라우드 송환 비용에는 클라우드에서 데이터 센터로 데이터를 다시 이동하는 데 드는 데이터 송신 비용이 포함됩니다. 이러한 수수료는 클라우드 잠금을 강제할 만큼 의도적으로 높습니다. 이러한 높은 송신 비용을 기록해 두십시오. 이는 관리하는 데이터의 양이 증가함에 따라 송신 비용이 증가하기 때문에 퍼블릭 클라우드를 떠나는 경제적 주장을 입증합니다. 그러므로 본국으로 송환할 예정이라면, 더 늦기보다는 빨리 조치를 취하는 것이 좋습니다.


우리는 이동해야 하는 데이터와 메타데이터에 중점을 둘 것입니다. 이는 송환에 필요한 작업의 80%입니다. 메타데이터에는 버킷 속성 및 정책(액세스/비밀 키를 기반으로 한 액세스 관리, 수명 주기 관리, 암호화, 익명 공개 액세스, 객체 잠금 및 버전 관리)이 포함됩니다.


지금은 데이터(객체)에 집중하겠습니다. 마이그레이션하려는 각 네임스페이스에 대해 이동하려는 버킷 및 개체의 인벤토리를 작성합니다. DevOps 팀은 이미 중요한 현재 데이터를 보관하는 버킷을 알고 있을 가능성이 높습니다. 당신은 또한 사용할 수 있습니다 Amazon S3 인벤토리 . 높은 수준에서는 다음과 같습니다.


네임스페이스

총 버킷

총 개체 수

총 개체 크기(GB)

일일 총 업로드(TB)

일일 총 다운로드(TB)

ns-001

166

47,751,258

980,014.48

50.04

14.80

ns-002

44

24,320,810

615,033.35

23.84

675.81

ns-002

648

88,207,041

601,298.91

328.25

620.93

ns-001

240

68,394,231

128,042.16

62.48

12.45


다음 단계는 마이그레이션할 각 버킷과 해당 속성을 네임스페이스별로 나열하는 것입니다. 해당 버킷에 데이터를 저장하고 읽는 애플리케이션을 기록해 둡니다. 사용량에 따라 각 버킷을 핫, 웜, 콜드 계층 데이터로 분류합니다.


요약 버전에서는 다음과 같습니다.


버킷 이름

속성

핫/웜/콜드 계층

여기에 JSON을 복사하여 붙여넣으세요.

스파크, 아이스버그, 드레미오

더운

여기에 JSON을 복사하여 붙여넣으세요.

탄력있는

따뜻한

여기에 JSON을 복사하여 붙여넣으세요.

탄력적(스냅샷)

추운


이제 데이터 수명 주기 관리에 관해 몇 가지 결정을 내려야 하며, AWS 수수료를 절약할 수 있는 좋은 방법이 있으므로 세심한 주의를 기울이십시오. 액세스 빈도에 따라 각 버킷의 객체를 핫, 웜 또는 콜드로 분류합니다. 비용을 절약할 수 있는 가장 좋은 방법은 콜드 계층 버킷을 S3 Glacier로 직접 마이그레이션하는 것입니다. 다시 업로드하기 위해 다운로드하는 데 송신 비용이 발생할 이유가 없습니다.


본국으로 송환하는 데이터의 양에 따라 마이그레이션 방법을 선택할 수 있는 몇 가지 옵션이 있습니다. 시간이 지남에 따라 핫 데이터와 웜 데이터를 새 클러스터에 복사하는 동안 새 MinIO 클러스터에서 새 데이터를 로드하고 작업하는 것이 좋습니다. 물론 객체를 복사하는 데 필요한 시간과 대역폭은 복사하는 객체의 수와 크기에 따라 달라집니다.


여기에서 AWS S3에서 송환할 총 데이터를 계산하는 것이 매우 도움이 될 것입니다. 재고를 살펴보고 핫 및 웜으로 분류된 모든 버킷의 총 크기를 확인하십시오.


총 핫 및 웜 계층 데이터 = 1,534,096.7GB

사용 가능한 대역폭 = 10Gbps

필요한 최소 전송 시간(총 객체 크기 / 사용 가능한 대역폭) = 14.2일


위의 총액을 기준으로 데이터 송신 비용을 계산합니다. 나는 사용하고있다 정가 하지만 귀하의 조직은 AWS로부터 할인을 받을 수 있습니다. 또한 연결 대역폭으로 10Gbps를 사용하고 있지만 원하는 대로 사용할 수 있는 대역폭은 어느 정도일 수 있습니다. 마지막으로 S3 데이터의 1/3이 S3 Glacier Deep Archive로 이동된다는 가정하에 작업하고 있습니다.


S3 Glacier에 계층화된 총 데이터 = 767,048.337GB

S3에서 S3 Glacier로의 전송 수수료($0.05/1000개 객체) = $3,773.11

S3 Glacier Deep Archive 월별 스토리지 요금 = $760


앞으로 S3 Glacier Deep Archive 사용에 대한 예산을 책정하는 것을 잊지 마십시오.


전송될 총 데이터 = 1,534,096.7GB

처음 10TB($0.09/GB) = $900

다음 40TB($0.085/GB = $3,400)

다음 100TB는 $0.07/GB = $70,000

$0.05/GB로 150TB를 초과하는 추가 = $69,205

총 송신 수수료 = $143,504


단순화를 위해 위 계산에는 객체당 작업 비용($0.40/1m)이나 LISTing 비용($5/1m)이 포함되지 않습니다. 대규모 송환 프로젝트의 경우 네트워크를 통해 개체를 보내기 전에 개체를 압축하여 송신 비용을 일부 절약할 수도 있습니다.


또 다른 옵션은 AWS Snowball을 사용하여 객체를 전송하는 것입니다. Snowball 디바이스는 각각 80TB이므로 송환을 위해 20개가 필요하다는 것을 미리 알고 있습니다. 기기당 요금에는 사용 기간 10일과 배송 2일이 포함됩니다. 추가일은 기기당 $30로 이용 가능합니다.


20 Snowball 디바이스 서비스 요금(개당 $300) = $6,000

R/T 배송(3~5일, 기기당 $400) = $8,000

S3 데이터 출력($0.02/GB) = $30,682

총 Snowball 요금 = $38,981.93


AWS는 다음을 포함한 AWS 서비스에서 읽고 쓰는 데 필요한 표준 요청, 스토리지 및 데이터 전송 요금을 청구합니다. 아마존 S3 그리고 AWS 키 관리 서비스(KMS) . 작업 시 추가 고려사항이 있습니다. Amazon S3 스토리지 클래스 . S3 내보내기 작업의 경우 S3에서 Snow Family 디바이스로 전송된 데이터에는 LIST, GET 등과 같은 작업에 대한 표준 S3 요금이 청구됩니다. 또한 Amazon CloudWatch Logs, Amazon CloudWatch Metrics 및 Amazon CloudWatch Events에 대한 표준 요금도 청구됩니다.


이제 우리는 이 엄청난 양의 데이터를 마이그레이션하는 데 걸리는 시간과 비용을 알고 있습니다. 시기와 수수료의 조합을 기반으로 어떤 방법이 귀하의 요구 사항을 충족하는지에 대한 비즈니스 결정을 내리십시오.


이 시점에서 우리는 온프레미스 또는 코로케이션 시설에서 MinIO를 실행하는 데 필요한 하드웨어에 대한 요구 사항도 알고 있습니다. 1.5PB의 스토리지에 대한 위의 요구 사항을 고려하여 데이터 증가를 예측하고 당사에 문의하십시오. 권장 하드웨어 및 구성 페이지와 MinIO 배포에 가장 적합한 하드웨어 선택 .


첫 번째 단계는 MinIO에서 S3 버킷을 다시 생성하는 것입니다. 개체 마이그레이션 방법에 관계없이 이 작업을 수행해야 합니다. S3와 MinIO는 모두 서버 측 암호화를 사용하여 객체를 저장하지만 암호화 키 마이그레이션에 대해 걱정할 필요가 없습니다. 다음을 사용하여 선택한 KMS에 연결할 수 있습니다. 암호화 키를 관리하는 MinIO KES . 이렇게 하면 MinIO에서 암호화된 테넌트와 버킷이 생성될 때 새 키가 자동으로 생성됩니다.


객체를 복사하는 여러 가지 옵션이 있습니다: 일괄 복제 및 mc mirror . 예전 블로그 포스팅, AWS S3에서 MinIO로 송환하는 방법 두 가지 방법에 대한 자세한 지침이 포함되어 있습니다. S3에서 온프레미스 MinIO로 객체를 직접 복사하거나, EC2에서 실행되는 임시 MinIO 클러스터를 사용하여 S3를 쿼리한 다음 온프레미스 MinIO로 미러링할 수 있습니다.


일반적으로 고객은 AWS Snowball 또는 TD SYNNEX의 데이터 마이그레이션 하드웨어 및 서비스와 결합하여 우리가 작성한 도구를 사용하여 더 많은 양의 데이터(1PB 이상)를 이동합니다.


MinIO는 최근 Western Digital 및 TD SYNNEX와 제휴하여 Snowball 대안을 마련했습니다. 고객은 Western Digital 하드웨어 배송을 받기 위한 기간을 예약하고 임대 기간 동안 필요한 비용을 지불할 수 있습니다. 더 중요한 것은 서비스가 특정 클라우드에 묶여 있지 않다는 것입니다. 즉, 기업은 이 서비스를 사용하여 유비쿼터스 S3 프로토콜을 사용하여 클라우드 안팎으로 데이터를 이동할 수 있습니다. 자세한 서비스 내용은 홈페이지에서 확인하실 수 있습니다. 데이터 마이그레이션 서비스 TD SYNNEX 사이트의 페이지.


정책 및 버킷 속성을 포함한 버킷 메타데이터는 get-bucket 사용하여 읽을 수 있습니다. S3 API 호출 그런 다음 MinIO에서 설정합니다. MinIO SUBNET에 등록하면 당사 엔지니어가 귀하와 협력하여 액세스 키/비밀 키를 기반으로 한 액세스 관리, 수명 주기 관리 정책, 암호화, 익명 공개 액세스, 불변성 및 버전 관리 등 AWS S3에서 이러한 설정을 마이그레이션합니다. 버전 관리에 대한 한 가지 참고 사항은 각 버전 ID가 내부 UUID이기 때문에 데이터가 마이그레이션될 때 AWS 버전 ID는 일반적으로 유지되지 않습니다. 객체는 일반적으로 이름으로 호출되므로 이는 고객에게 큰 문제가 되지 않습니다. 그러나 AWS 버전 ID가 필요한 경우 이를 MinIO에 보존하는 확장 기능이 있으며 이를 활성화하도록 도와드리겠습니다.


특히 주의하세요 IAM 및 버킷 정책 . S3는 AWS 인프라에서 사용자가 남기는 유일한 부분이 아닐 것입니다. S3 버킷에 액세스할 때 애플리케이션이 사용할 서비스 계정이 많이 있습니다. 지금은 모든 서비스 계정을 나열하고 감사하기에 좋은 시기입니다. 그런 다음 ID 공급자에서 다시 생성할지 여부를 결정할 수 있습니다. 자동화를 선택한 경우 Amazon Cognito를 사용하여 외부 OpenID Connect IDP 및 AD/LDAP와 IAM 정보를 공유합니다.


객체 보존, 객체 잠금, 아카이브/계층화 등 데이터 수명주기 관리에 특별한 주의를 기울이십시오. 각 버킷에서 get-bucket-lifecycle-configuration 실행하여 사람이 읽을 수 있는 수명 주기 규칙의 JSON 목록을 얻습니다. MinIO 콘솔 또는 MinIO 클라이언트(mc)를 사용하여 AWS S3 설정을 쉽게 다시 생성할 수 있습니다. get-object-legal-holdget-object-lock-configuration 과 같은 명령을 사용하여 특별한 보안 및 거버넌스 처리가 필요한 개체를 찾아냅니다.


수명주기에 관해 이야기하면서 잠시 백업 및 재해 복구에 대해 이야기해 보겠습니다. 백업 및 재해 복구를 위해 복제할 추가 MinIO 클러스터를 원하십니까?


객체가 AWS S3에서 MinIO로 복사된 후에는 데이터 무결성을 검증하는 것이 중요합니다. 이를 수행하는 가장 쉬운 방법은 MinIO 클라이언트를 사용하여 S3의 이전 버킷과 MinIO의 새 버킷에 대해 mc diff 실행하는 것입니다. 그러면 버킷 간의 차이가 계산되고 누락되었거나 다른 객체의 목록만 반환됩니다. 이 명령은 소스 및 대상 버킷의 인수를 사용합니다. 귀하의 편의를 위해 다음을 생성할 수도 있습니다. 별칭 S3 및 MinIO의 경우 전체 주소와 자격 증명을 계속 입력할 필요가 없습니다. 예를 들어:


 mc diff s3/bucket1 minio/bucket1


좋은 소식은 기존 앱을 새로운 MinIO 엔드포인트로 지정하기만 하면 된다는 것입니다. 일정 기간 동안 앱별로 구성을 다시 작성할 수 있습니다. 객체 스토리지의 데이터 마이그레이션은 파일 시스템보다 방해가 적습니다. 새 클러스터에서 읽기/쓰기가 가능하도록 URL을 변경하기만 하면 됩니다. 이전에 애플리케이션을 지원하기 위해 AWS 서비스에 의존했다면 해당 서비스는 데이터 센터에 존재하지 않으므로 해당 오픈 소스 서비스로 교체하고 일부 코드를 다시 작성해야 합니다. 예를 들어 Athena는 Spark SQL, Apache Hive 및 Presto, Kinesis는 Apache Kafka, AWS Glue는 Apache Airflow로 대체될 수 있습니다.


S3 마이그레이션이 전체 애플리케이션을 온프레미스로 이동하려는 대규모 노력의 일부라면, S3 이벤트 알림 새 데이터가 도착하면 다운스트림 서비스를 호출합니다. 그렇다면 두려워하지 마십시오. MinIO는 지원합니다. 이벤트 알림 또한. 여기서 가장 간단한 마이그레이션은 알림을 수신하기 위해 사용자 정의 웹후크를 구현하는 것입니다. 그러나 내구성과 탄력성이 더 뛰어난 대상이 필요한 경우 Kafka 또는 RabbitMQ와 같은 메시징 서비스를 사용하십시오. 또한 PostgreSQL 및 MySQL과 같은 데이터베이스로 이벤트 전송을 지원합니다.


이제 송환을 완료했으므로 스토리지 운영, 모니터링 및 최적화에 관심을 돌릴 차례입니다. 좋은 소식은 MinIO에는 최적화가 필요하지 않다는 것입니다. 소프트웨어에 최적화 기능이 내장되어 있어 하드웨어에 대한 최고의 성능을 얻을 수 있다는 것을 알 수 있습니다. 새로운 MinIO 클러스터 모니터링을 시작하여 지속적으로 리소스 활용도와 성능을 평가할 수 있습니다. MinIO 노출 측정항목 귀하가 사용할 수 있는 Prometheus 엔드포인트를 통해 모니터링 및 경고 플랫폼 선택 . 모니터링에 대한 자세한 내용은 다음을 참조하세요. Prometheus 및 Grafana를 사용한 멀티 클라우드 모니터링 및 알림 그리고 OpenTelemetry, Flask 및 Prometheus를 사용하는 MinIO의 측정항목 .


와 함께 서브넷 , 우리는 당신의 뒤를 지원합니다 2일차 작업 MinIO와 함께. 구독자는 클러스터를 원활하게 실행하기 위해 내장된 자동화된 문제 해결 도구에 액세스할 수 있습니다. 또한 지원 포털을 통해 엔지니어에게 실시간으로 무제한 직접 지원을 받을 수 있습니다. 또한 연례 아키텍처 검토를 통해 객체 스토리지 투자의 미래 경쟁력을 높일 수 있도록 도와드립니다.

마이그레이션 및 저장

클라우드 제공업체에 백지 수표를 보내던 시절이 지났다는 것은 비밀이 아닙니다. 현재 많은 기업이 잠재적인 절감액을 찾기 위해 클라우드 지출을 평가하고 있습니다. 이제 구체적인 기술 단계와 재무 프레임워크를 포함하여 AWS S3에서 MinIO로 마이그레이션을 시작하는 데 필요한 모든 것이 갖추어져 있습니다.


송환 비용 절감에 대한 기대가 있으신 경우 다음 주소로 문의해 주십시오. [email protected] .


여기에도 나타납니다.