お客様のストレージ · WordPress + WooCommerce
WooCommerce 向け AWS S3
Alter Product プラグインには AWS S3 ストレージモジュールが組み込まれています。対応するプラグインのファイルグループを独自の非公開バケットに保存し、WordPress から接続して、プラグインのツールで既存ファイルを移行できます。
接続したストレージの容量を増やしても、Alter Product からストレージ容量の追加料金は請求されません。保存、リクエスト、データ転送の費用は AWS がお客様のアカウントに請求します。WordPress ホスティングの費用、および通常のプランと埋め込みセッションのルールは引き続き適用されます。
この手順はプラグイン内の設定ガイドに沿っています。AWS コンソールの名称は英語のまま記載しています。
ストレージ、ファイル配信、費用
S3 はプラグインのファイルオブジェクトを保存します。アクセス権を確認してブラウザーに配信する役割は、引き続き WordPress が担います。
プラグイン用の非公開ストレージ
ブラウザーが S3 から直接ダウンロードすることはありません。WordPress が非公開バケットからファイルを取得して検証し、独自のエンドポイントから配信します。S3 の CORS は空のままにし、Block Public Access を有効にしてください。公開バケットや CDN への直接接続ではありません。
このモジュールが対象とするのは、対応する Alter Product のファイルグループです。バケットを接続しても、WordPress の全ファイルが移動するわけではなく、埋め込みツールの上限も変わりません。
使用したリソースの費用を AWS に支払う
接続したバケットの容量を増やしても、Alter Product の追加料金は発生しません。AWS の料金は使用量、リージョン、ストレージクラスによって異なります。固定料金だと想定せず、最新の S3 料金表をご確認ください。
ファイルは WordPress が配信するため、その通信はホスティング側の転送量にも計上される場合があります。S3 を利用しても、ホスティングの転送量がゼロになったり、サーバーの処理能力が無制限になったりするわけではありません。
対応する設定でバケットを作成する
以下のフィールド名は、英語版 AWS コンソールとプラグイン内の設定ガイドに合わせています。
汎用バケットを作成する
AWS にサインインし、Amazon S3 を開いて General purpose buckets → Create bucket を選択します。リージョンを選び、小文字の英字、数字、ハイフンを使って、ピリオドを含まない名前を付けてください。AWS が付加した接尾辞も含め、バケットの完全な名前をコピーします。
- 表の設定を適用し、Create bucket を選択します。
- バケットの完全な名前、リージョン、バケット所有者の 12 桁の AWS アカウント ID を控えます。
- Cross-origin resource sharing (CORS) は空のままにします。S3 へのリクエストは WordPress サーバーから送信されます。
| AWS のフィールド | 設定値 |
|---|---|
| Bucket type | General purpose |
| Bucket namespace | Account Regional namespace (推奨) |
| Object Ownership | ACLs disabled / Bucket owner enforced |
| Block Public Access | Block all public access (4 つの設定すべて) |
| Bucket Versioning | Enable |
| Default encryption | Server-side encryption with Amazon S3 managed keys (SSE-S3 / AES256) |
| Bucket Key | Disable |
| Advanced settings → Object Lock | Disable |
HTTPS を必須にする
バケットを公開したり、オブジェクトへのアクセス権を付与したりせずに、通信のルールを追加します。
バケットポリシーを追加する
Permissions → Bucket policy → Edit を開きます。2 か所の EXAMPLE-BUCKET をバケットの完全な名前に置き換えてください。既存のポリシーがある場合は、そのステートメントを維持し、文書全体を確認してからこのルールを追加します。
- エディターのメッセージを確認し、Save changes を選択します。
- ルールが保存されたことを確認します。Block all public access は有効のままにします。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyInsecureTransport",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::EXAMPLE-BUCKET",
"arn:aws:s3:::EXAMPLE-BUCKET/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false",
"aws:PrincipalIsAWSService": "false"
}
}
}
]
}権限を限定した IAM アクセスを作成する
AdministratorAccess や AmazonS3FullAccess ではなく、このバケットとプレフィックス専用のポリシーを使用します。
プラグイン用のポリシーを作成する
IAM → Policies → Create policy → JSON に以下の文書を貼り付けます。すべての EXAMPLE-BUCKET をバケットの完全な名前に置き換えてください。プレフィックス alter-product は WordPress の Folder prefix と一致させます。別のプレフィックスを使う場合は、すべてのオブジェクト用 Resource で変更してください。
- ポリシーを検証し、Next を選択して、AlterProductS3Storage などの名前を付けます。
- Create policy を選択し、ユーザー設定で使うために名前を控えます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ReadRequiredBucketControls",
"Effect": "Allow",
"Action": [
"s3:GetBucketVersioning",
"s3:GetBucketOwnershipControls",
"s3:GetBucketPublicAccessBlock",
"s3:GetEncryptionConfiguration"
],
"Resource": "arn:aws:s3:::EXAMPLE-BUCKET"
},
{
"Sid": "WriteAndReadVersionedPluginObjects",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObjectVersion"
],
"Resource": [
"arn:aws:s3:::EXAMPLE-BUCKET/alter-product/objects/*",
"arn:aws:s3:::EXAMPLE-BUCKET/alter-product/.storage-tests/*"
]
},
{
"Sid": "RecoverJournalOwnedObjects",
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::EXAMPLE-BUCKET/alter-product/objects/*"
},
{
"Sid": "DeleteOnlyConnectionTestVersions",
"Effect": "Allow",
"Action": "s3:DeleteObjectVersion",
"Resource": "arn:aws:s3:::EXAMPLE-BUCKET/alter-product/.storage-tests/*"
}
]
}専用ユーザーとアクセスキーを作成する
IAM → Users → Create user を選択します。Provide user access to the AWS Management Console は選択しないでください。
- Next → Attach policies directly を選択し、上記のポリシーだけを割り当てます。Create user を完了します。
- そのユーザーの Security credentials → Access keys → Create access key を開きます。この手動のプラグイン設定では Other → Next、続いて Create access key を選択します。
- Access key ID と Secret access key をパスワードマネージャーに保存します。シークレットが表示されるのは一度だけです。HTTPS 経由で WordPress に直接入力し、メッセージやスクリーンショットで共有しないでください。
WordPress の接続を保存してテストする
HTTPS で開いたストアの管理画面で Alter Product → Settings → Storage に進みます。AWS S3 と + / Add connection を選択します。
接続情報を入力する
New connection を選択します。同じ組み込み手順は AWS S3 setup guide からも確認できます。
- Save connection を選択し、確認メッセージを待ちます。
- Test connection を選択します。再テストの前に変更を保存してください。
- ダイアログと Last connection test 列で結果を確認します。保存後にキー欄が空になるのは意図した動作です。
| フィールド | 入力する値 |
|---|---|
| Bucket name | バケットの完全な名前。ARN、s3:// URL、HTTPS アドレスではなく、ピリオドを含めません。 |
| Folder prefix | IAM ポリシーと一致する alter-product。英字、数字、ハイフン、アンダースコアと区切られたフォルダーを使用し、先頭や末尾にスラッシュを付けないでください。 |
| Bucket owner AWS account ID | 所有者の 12 桁のアカウント ID。スペースは含めません。 |
| AWS region | バケットの実際のリージョン。フォームの既定値は eu-central-1 です。 |
| AWS access key ID / AWS secret access key | 保存しておいた専用 IAM ユーザーのキーペア。 |
| Use temporary AWS credentials | この IAM ユーザーの長期キーでは選択しません。一時認証情報の場合に限り有効にし、AWS session token を入力します。 |
接続テストが失敗した場合
バケット名、所有者、リージョン、必須設定、および WordPress と IAM のプレフィックスが完全に一致することを確認してください。CORS は空のままにし、公開アクセスの保護を無効にしないでください。
保存されたバケット、プレフィックス、所有者、リージョンが接続の識別情報になります。別の保存先には New connection を選択します。Edit → Reconnect は、既存のファイル参照を維持して認証情報を差し替えるための操作です。
アクセスキーを含めず、テスト結果をサポートに伝えてください。この S3 を既定の保存先にするには、接続テストの成功が必要です。
既定の保存先を選び、既存ファイルを移行する
既定の保存先の選択と移行は、別々の操作です。
新しいグループで S3 を使う
保存済み接続の行で Make default を選択します。プラグインは接続をテストし、成功した場合にのみ既定の保存先を変更します。対象は新しいファイルグループです。既存のグループとその後のリビジョンは、移行するまで記録済みの保存先を使います。
対応する既存グループを移行する
初回の移行前に、データベース、WordPress ソルト、ファイルをまとめてバックアップします。テスト環境または小さなグループから始めてください。移行先の S3 行で Migrate を開きます。パネルを開くだけではファイルはコピーされません。
Auto migration は、選択した移行先以外にある対応グループを対象とします。無関係な WordPress ファイルまで移行する機能ではありません。
- Start migration を選択します。プラグインは S3 をテストし、各グループを準備、コピー、検証してから参照先を切り替えます。
- ページは開いたままにしてください。Pause は処理中のグループが終わると停止し、Resume migration は保存済みの進捗から再開します。ページを閉じた場合は、再度開いて後続処理を再開してください。
- グループの処理に失敗したら、メッセージと Advanced を確認し、原因を解消して再開します。アップロード結果が不明な操作を、確認せず繰り返さないでください。
- Migration completed の後は、通常のリソース読み取り、編集、プレビュー、注文ファイルへのアクセスを確認します。走査中に作成されたグループには、追加の実行が必要な場合があります。
行を削除しても保存済みファイルは削除されない
必要に応じて先に既定の保存先を切り替えます。Remove は接続を一覧から除外しますが、既存ファイルと保存済みの認証情報は引き続き利用できます。AWS オブジェクトの削除コマンドではありません。
WordPress ノード間でストレージを共有する
共有の S3 保存先を使うと、単一ノードのファイルディスクへの依存を減らせます。ただしロードバランサーの背後では、WordPress の状態を適切に共有する構成が引き続き必要です。
複数ノードで運用するための要件
ロードバランサーの背後で 1 つの WordPress 環境を動かすには、以下をすべて揃えてください。
- 一貫した 1 つの SQL 書き込み先と、共有されたプラグインのデータベース状態。
- ローカルに残るファイルと、保持する移行元ファイルのための共有 uploads ディレクトリ。
- 保存済み認証情報と暗号化ファイルを読めるよう、全ノードで同じ元の WordPress ソルト。
- 転送処理のための、ノードごとの非公開一時ディレクトリ。
- 一貫したプラグイン設定と、同じ非公開 S3 バケットおよびオブジェクトバージョンへのアクセス。
- 標準の wpdb、ネイティブの mysqli、InnoDB テーブルを使ってください。HyperDB などのデータベースルーティング用ドロップインは非対応です。ここでの負荷分散は HTTP レベルを対象としています。
復旧とキーのローテーションに備える
データベース、ソルト、参照されているファイルバージョンを一緒に保持してください。
バックアップ、再接続、検証を行う
同じ保存済み接続の認証情報を差し替えるには Edit → Reconnect を使います。古いキーを無効にする前に、そのキーを使う可能性がある他の保存済み接続も含め、現在と過去のファイルを読めることを確認してください。
S3 のバージョニングを有効のままにし、プラグインが参照するバージョンを保持します。必要な履歴バージョンを削除する lifecycle ルールは適用しないでください。データベース、ソルト、保存済みファイルを一緒に復元できることを確認します。
一時認証情報には有効期限があり、新しい有効なトークンとキーが必要です。プラグインは自動更新しません。ストアの規模に応じて、AWS の使用量とホスティングの転送量を監視してください。