AWS S3 から MinIO への復帰に必要なすべての情報

前回の投稿に対する反応AWS S3 から MinIO に復帰する方法は、驚くべきものでした。企業から本国への帰還に関するアドバイスを求める電話が何十件も寄せられました。私たちは、それらの回答をこの新しい投稿にまとめ、本国への帰還に関連するコストと節約についてもう少し深く掘り下げて、皆さんが独自の分析をまとめやすくしました。データの移行は、多くの人にとって困難な作業です。実際には、新しいデータを MinIO に取り込んで、古いデータをクラウドから移行するのに時間をかけていたり、そのままにしておいて増やさなかったりします。

帰国の概要

AWS S3 からデータを送還するには、次の一般的なガイドラインに従います。

1. データ要件の確認: AWS S3 から戻す必要がある特定のバケットとオブジェクトを決定します。バケットごとにビジネスニーズとコンプライアンス要件を理解していることを確認します。

   
   

2. 復帰先の特定: MinIO への復帰はすでに決定しているので、オンプレミスのデータ センターで実行するか、別のクラウド プロバイダーまたはコロケーション施設で実行するかを選択できます。#1 の要件を使用して、予測されるストレージ、転送、および可用性のニーズに合わせてハードウェアまたはインスタンスを選択します。

   
   

3. データ転送: AWS S3からMinIOへのデータ転送を計画して実行します。MinIOに組み込まれているバッチレプリケーションを使用するか、MinIOクライアントを使用してミラーリングします（ AWS S3 から MinIO に復帰する方法詳細については、こちらをご覧ください。AWS DataSync、AWS Snowball、 TD SYNNEX データ移行、または AWS API を直接使用することもできます。

   
   

4. データ アクセスと権限:バケットごとに、返還されたデータに対して適切なアクセス制御と権限が設定されていることを確認します。これには、データのセキュリティを確保するためにユーザー アクセス、認証、承認を管理するための IAM およびバケット ポリシーが含まれます。

   
   

5. オブジェクトロック:移行後もオブジェクトロックの保持と法的保留ポリシーを維持することが重要です。ターゲットオブジェクトストアはAmazon S3と同じようにルールを解釈する必要があります。不明な場合は、コハセットアソシエイツコンプライアンス評価ターゲット オブジェクト ストアの実装について。

   
   

6. データ ライフサイクル管理:返還されたデータのデータ ライフサイクル管理戦略を定義して実装します。これには、保持ポリシー、バックアップおよび回復手順、バケットごとのデータ アーカイブ方法の定義が含まれます。

   
   

7. データ検証:転送されたデータを検証して、その整合性と完全性を確認します。データが破損や損失なく正常に転送されたことを確認するために必要なチェックとテストを実行します。転送後、オブジェクト名、ETag とメタデータ、チェックサム、およびオブジェクトの数はすべて、ソースと宛先間で一致します。

   
   

8. アプリケーションとワークフローの更新:幸いなことに、クラウドネイティブの原則に従ってアプリケーションを構築する場合、新しい MinIO エンドポイント用に再構成するだけで済みます。ただし、アプリケーションとワークフローが AWS エコシステムで動作するように設計されている場合は、戻されたデータに対応するために必要な更新を行ってください。これには、構成の更新、統合の再構成、場合によってはコードの変更が含まれる場合があります。

   
   

9. 監視と最適化:最適なパフォーマンス、コスト効率、およびデータ管理のベスト プラクティスの遵守を確保するために、帰還されたデータ環境を継続的に監視および最適化します。

帰国の手順

クラウドの帰還の予算と計画には、考慮すべき要素が数多くあります。幸いなことに、当社のエンジニアは多くのお客様とこの作業を行っており、詳細な計画を策定しています。少数のワークロードから数百ペタバイトまで、あらゆるものを帰還させたお客様もいます。

計画における最大の課題は、ネットワーク、リース帯域幅、サーバー ハードウェア、本国への送還対象とならなかったデータのアーカイブ コスト、独自のクラウド インフラストラクチャの管理と維持にかかる人件費など、さまざまな選択肢について熟考することです。これらのコストを見積もり、計画を立ててください。クラウド送還コストには、クラウドからデータ センターにデータを戻すためのデータ エグレス料金が含まれます。これらの料金は、クラウド ロックインを強いるほど意図的に高く設定されています。この高額なエグレス料金に注意してください。管理するデータ量が増えるとエグレス料金も高くなるため、パブリック クラウドを離れる経済的根拠が裏付けられます。したがって、本国への送還を行う場合は、早めに行動を起こす方が得策です。

ここでは、移行する必要のあるデータとメタデータに焦点を当てます。これは、復帰に必要な作業の 80% を占めます。メタデータには、バケットのプロパティとポリシー (アクセス/シークレット キーに基づくアクセス管理、ライフサイクル管理、暗号化、匿名パブリック アクセス、オブジェクトのロックとバージョン管理) が含まれます。

今はデータ（オブジェクト）に焦点を当てましょう。移行したい名前空間ごとに、移動したいバケットとオブジェクトのインベントリを作成します。DevOpsチームは、どのバケットに現在の重要なデータが含まれているかをすでに把握している可能性があります。 Amazon S3 インベントリ大まかに言うと、次のようになります。

次のステップでは、移行するすべてのバケットについて、名前空間ごとに各バケットとそのプロパティをリストします。そのバケットにデータを保存および読み取るアプリケーションを書き留めます。使用状況に基づいて、各バケットをホット層、ウォーム層、またはコールド層データに分類します。

要約すると、次のようになります

この時点で、データライフサイクル管理についていくつかの決定を下す必要がありますが、AWS 料金を節約する優れた方法があるので、細心の注意を払ってください。各バケット内のオブジェクトを、アクセス頻度に基づいてホット、ウォーム、コールドに分類します。コストを節約する優れた方法は、コールド層のバケットを直接 S3 Glacier に移行することです。ダウンロードして再度アップロードするだけで、エグレス料金が発生する理由はありません。

移行するデータの量に応じて、移行方法を選択するオプションがいくつかあります。ホット データとウォーム データを新しいクラスターに徐々にコピーしながら、新しい MinIO クラスターに新しいデータを読み込んで操作することをお勧めします。オブジェクトのコピーに必要な時間と帯域幅は、もちろん、コピーするオブジェクトの数とサイズによって異なります。

ここで、AWS S3 から送還するデータの合計を計算すると非常に役立ちます。インベントリを確認し、ホットとウォームに分類されるすべてのバケットのサイズを合計します。

上記の合計に基づいてデータ送信料金を計算します。定価ただし、組織によっては AWS の割引を受けられる場合があります。また、接続帯域幅として 10 Gbps を使用していますが、これより多くても少なくてもかまいません。最後に、S3 データの 3 分の 1 が S3 Glacier Deep Archive に単に移行されるという前提で作業を進めています。

今後の S3 Glacier Deep Archive の使用に備えて予算を確保することを忘れないでください。

簡単にするために、上記の計算にはオブジェクトごとの操作料金 ($0.40/100 万) も LIST のコスト ($5/100 万) も含まれていません。非常に大規模な送還プロジェクトの場合、ネットワーク経由で送信する前にオブジェクトを圧縮して、送信料金の一部を節約することもできます。

もう 1 つのオプションは、AWS Snowball を使用してオブジェクトを転送することです。Snowball デバイスはそれぞれ 80 TB なので、返還作業には 20 台必要であることが事前にわかっています。デバイスあたりの料金には、10 日間の使用料と 2 日間の配送料が含まれます。追加の日数は、デバイス 1 台あたり 30 ドルで利用できます。

AWSは、AWSサービスからの読み取りと書き込みに対して、標準のリクエスト、ストレージ、データ転送料金を請求します。アマゾンS3そしてAWS キー管理サービス (KMS)作業する際には、さらに考慮すべき点があります。 Amazon S3 ストレージクラスS3 エクスポート ジョブの場合、S3 から Snow ファミリー デバイスに転送されたデータは、LIST、GET などの操作に対して標準の S3 料金で課金されます。Amazon CloudWatch Logs、Amazon CloudWatch Metrics、Amazon CloudWatch Events に対しても標準料金が課金されます。

これで、この膨大な量のデータを移行するのにかかる時間とコストがわかりました。タイミングと料金の組み合わせに基づいて、どの方法がニーズを満たすかビジネス上の決定を下してください。

この時点で、オンプレミスまたはコロケーション施設でMinIOを実行するために必要なハードウェアの要件もわかっています。上記の1.5PBのストレージ要件を考慮して、データの増加を予測し、推奨ハードウェアと構成ページとMinIO 導入に最適なハードウェアの選択。

最初のステップは、S3バケットをMinIOで再作成することです。これは、オブジェクトの移行方法に関係なく行う必要があります。S3とMinIOはどちらもサーバー側の暗号化を使用してオブジェクトを保存しますが、暗号化キーの移行について心配する必要はありません。選択したKMSに接続するには、暗号化キーを管理するMinIO KESこの方法では、暗号化されたテナントとバケットが MinIO に作成されると、新しいキーが自動的に生成されます。

オブジェクトをコピーするには、バッチレプリケーションとmc mirrorという複数のオプションがあります。前回のブログ投稿では、 AWS S3 から MinIO に復帰する方法両方の方法の詳細な手順が含まれています。オブジェクトを S3 からオンプレミスの MinIO に直接コピーすることも、EC2 で実行されている一時的な MinIO クラスターを使用して S3 をクエリし、オンプレミスの MinIO にミラーリングすることもできます。

通常、お客様は、当社が作成したツールを AWS Snowball または TD SYNNEX のデータ移行ハードウェアおよびサービスと組み合わせて使用し、大量のデータ (1 PB 以上) を移動します。

MinIO は最近、Western Digital および TD SYNNEX と提携して Snowball の代替品をリリースしました。顧客は、Western Digital ハードウェアの配送スケジュールを設定し、レンタル期間中に必要なものに対して料金を支払うことができます。さらに重要なのは、このサービスは特定のクラウドに縛られていないことです。つまり、企業はこのサービスを使用して、ユビキタスな S3 プロトコルを使用して、クラウド間でデータを移動できます。このサービスの詳細については、データ移行サービスTD SYNNEX サイトのページ。

ポリシーやバケットのプロパティを含むバケットのメタデータは、 get-bucketを使用して読み取ることができます。 S3 API呼び出しその後、MinIO で設定します。MinIO SUBNET にサインアップすると、当社のエンジニアがお客様と協力して、アクセスキー/シークレットキーに基づくアクセス管理、ライフサイクル管理ポリシー、暗号化、匿名パブリックアクセス、不変性、バージョン管理などの設定を AWS S3 から移行します。バージョン管理に関する注意点の 1 つは、各バージョン ID が内部 UUID であるため、データの移行時に AWS バージョン ID は通常保持されないことです。オブジェクトは通常名前で呼び出されるため、お客様にとってこれはほとんど問題になりません。ただし、AWS バージョン ID が必要な場合は、MinIO でそれを保持する拡張機能があり、それを有効にするお手伝いをします。

特に注意すべき点IAM とバケットポリシーS3 は、AWS インフラストラクチャで残す唯一の部分ではありません。S3 バケットにアクセスするときにアプリケーションが使用するサービス アカウントが多数あります。この機会に、すべてのサービス アカウントを一覧表示して監査してください。その後、ID プロバイダーでそれらを再作成するかどうかを決定できます。自動化する場合は、Amazon Cognito を使用して、IAM 情報を外部の OpenID Connect IDP および AD/LDAP と共有します。

オブジェクトの保持、オブジェクトのロック、アーカイブ/階層化などのデータライフサイクル管理に特に注意してください。各バケットでget-bucket-lifecycle-configurationを実行して、人間が判読できるライフサイクルルールの JSON リストを取得します。MinIO コンソールまたは MinIO クライアント (mc) を使用して、AWS S3 設定を簡単に再作成できます。get get-object-legal-holdやget-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はサポートしていますイベント通知も同様です。ここでの最も簡単な移行は、通知を受信するためのカスタム Webhook を実装することです。ただし、より耐久性と回復力のある送信先が必要な場合は、Kafka や RabbitMQ などのメッセージング サービスを使用してください。PostgreSQL や MySQL などのデータベースへのイベントの送信もサポートされています。

復帰が完了したら、ストレージ操作、監視、最適化に目を向けましょう。幸いなことに、MinIO では最適化は必要ありません。最適化はソフトウェアに組み込まれているため、ハードウェアの最高のパフォーマンスが得られることがわかります。新しい MinIO クラスターを監視して、リソースの使用率とパフォーマンスを継続的に評価する必要があります。MinIO は、 メトリクスPrometheusエンドポイント経由で、監視および警告プラットフォームの選択モニタリングの詳細については、 Prometheus と Grafana によるマルチクラウド監視とアラートそしてOpenTelemetry、Flask、Prometheus を使用した MinIO のメトリクス。

とサブネット、私たちはあなたをサポートします2日目の作戦MinIO を使用すれば、組み込みの自動トラブルシューティング ツールにアクセスして、クラスターをスムーズに実行できます。また、サポート ポータルを通じて、エンジニアによる無制限のリアルタイム サポートも受けられます。さらに、毎年のアーキテクチャ レビューにより、オブジェクト ストレージへの投資を将来にわたって保証するお手伝いもいたします。

移行して保存

クラウド プロバイダーに白紙の小切手を切る時代は終わったことは周知の事実です。現在、多くの企業がクラウド支出を評価して、潜在的な節約を見つけようとしています。これで、具体的な技術的手順や財務フレームワークなど、AWS S3 から MinIO への移行を開始するために必要なものがすべて揃いました。

帰国費用の節約の可能性にご興味がおありでしたら、ぜひご連絡ください。こんにちは。