はじめに
この記事では、WordPress サイト上のメディアファイルを外部サービスへオフロードするメリット・デメリット、及びその方法について言及します。
以下のような方は参考になるかと思います。
- AWS 上で WordPress を運用している
- Auto Scaling Group をシングルインスタンス構成で運用している
- EBS ルートボリュームにメディアファイルを保持している
それでは、はじめましょう。
WordPress のメディアファイルオフロードの必要性
AutoScaling と EBS 初期化問題の説明
AWS 上での WordPress サイトの運用では、EC2 が用いられることが多々あります。
構成は人に依りますが、ASG を利用している方も多いでしょう。
※ASG: Auto Scaling Group
ASG は、トラフィックの変動に応じて自動的にEC2インスタンスの数を増減させることで、可用性とコスト効率を最適化します。
しかし、ASG には一つの重要な点を理解しておく必要があります。
それは、ASG がシングルインスタンス構成である場合、新規インスタンスを起動し、既存インスタンスを終了するため、EBS ボリュームも同様に作成・終了されるという点です。
※EBS: Elastic Block Store
これによって、WordPress のメディアファイルが失われます。
なぜなら、これらは通常インスタンスのルートボリュームに保存されるためです。
これは、インスタンスがヘルスチェックに失敗すると発生します。
これによって、インスタンスが終了・新規作成されます。
新規作成されたインスタンスは AMI から作られます。
※AMI: Amazon Machine Image
その AMI がバックアップされた時点以降に追加されたメディアファイルは含まれていません。
これによって、インスタンス復元後にメディアファイルが消失する可能性があります。
なお、例えば記事を RDS で保持している場合は、画像だけ非表示になります。
メリット・デメリット: メディアファイルオフロード
この問題を解決する一つの方法が、メディアファイルのオフロードです。
オフロードとは、メディアファイルを EC2 インスタンスの EBS から別の永続的なストレージサービスに移動することを指します。
AWSでは、この目的のために EFS または S3 が一般的に使用されます。
※EFS: Elastic File System
※S3: Simple Storage Service
メリット: メディアファイルオフロード
オフロードのメリットは主に以下の通りです：
- 永続性：
- メディアファイルはEC2インスタンスとは独立して永続的に保存されます
- スケーラビリティ：
- EFS や S3 は、保存できるデータ量に制限がなくスケーリング可能です
- セキュリティ：
- S3 や EFSは、データの暗号化やアクセス制御等のセキュリティ機能を提供します
デメリット: メディアファイルオフロード
一方で、オフロードのデメリットも考慮する必要があります：
- コスト：
- EFS や S3 は、使用したストレージ量に応じた料金が発生します
- 特に、EFS は比較的コストが高いとされています
- 複雑性：
- オフロードの実装と管理は若干の技術的な理解と知識を必要とします
オフロードオプション：EFS vs S3
EFS と S3 の比較
EFS は、複数の EC2 インスタンスから同時にアクセスできる共有ファイルストレージサービスです。
NFS プロトコルを使用して EC2 と連携し、データは自動的に複数の AZ に保存されます。
※NFS: Network File System
※AZ: Availability Zones
これによって、高い耐久性とスケーラビリティが実現されます。
一方、S3 はオブジェクトベースのストレージサービスです。
データは “オブジェクト” として保存されます。
S3 は、高いデータの耐久性と無制限のスケーラビリティを提供します。
また、S3 は HTTP を通じてデータにアクセスするため、EC2 だけでなく他のサービスやデバイスからも直接アクセス可能です。
メリット・デメリット: EFS vs S3
メリット・デメリット: EFS
EFS の主なメリットは以下の通りです：
- 高いパフォーマンス:
- 多くの EC2 インスタンスから同時にアクセスできます
- そのため、高い I/O パフォーマンスを発揮します
- 簡単な統合:
- NFS プロトコルを利用して EC2 と統合できます
- そのため、既存のアプリケーションとの互換性が高いです
EFSの主なデメリットは以下の通りです：
- コスト:
- S3 と比較してコストが高めです
- 特に、多くのデータを保存する場合や、長期間保存する場合にはコストが増加します
- 地域限定:
- EFS は、同一リージョン内のインスタンスからのみアクセス可能です
メリット・デメリット: S3
S3 の主なメリットは以下の通りです：
- コスト効率:
- EFSと比較してコストが低いです
- 特に、大量のデータを保存する場合や、長期間保存する場合には、S3のコスト効率は非常に高いです
- 高いアクセシビリティ:
- S3のデータはHTTPを通じて世界中からアクセスできます
- これにより、様々なサービスやデバイスから直接データにアクセスすることが可能です
S3 の主なデメリットは以下の通りです：
- 設定の複雑性:
- S3 を WordPress と統合するためには、プラグインを使用します
- プラグインの組み合わせによっては、考慮事項が増えます
- 一貫性の問題:
- データの書き込み後すぐに読み込むと、最新のデータが反映されていない可能性があります
- これは「結果整合性」と呼ばれる特性によるもので、一部のアプリケーションで問題を引き起こす可能性があります
以上から、どちらのサービスを選ぶべきかは、要件と予算に依ります。
今回私はコスト効率を重視し、S3を選択しました。
次の章では、具体的な実装手順について解説します。
S3オフロードの実装手順
S3バケットの作成
まず、WordPress のメディアファイル保存用のS3バケットを作成します。
- AWS Management Consoleにログインする
- S3 サービスページに移動する
- 「バケットを作成」をクリックする
- バケットの名前を入力する
- リージョンを指定する
- 「バケットを作成」をクリックする
IAMロールの作成とアタッチ
次に、EC2 インスタンスが S3 バケットにアクセスするための IAM ロールを作成します。
- IAM サービスページに移動する
- 「ロール」セクションに移動する
- 「ロールの作成」をクリックする
- EC2サービスを選択し、「次のステップ」をクリックする
- 「AmazonS3FullAccess」ポリシーを検索し、選択します
- 「次のステップ」をクリックする
- ロールの名前とオプションで説明を入力する
- 「ロールの作成」をクリックする
次に、作成したロールを EC2 インスタンスにアタッチします。
- EC2 サービスページに移動する
- 対象のインスタンスを選択する
- 「インスタンス設定」から「IAMロールのアタッチ/置換」を選択する
- 先ほど作成した IAM ロールを選択し、「適用」をクリックする
WP Offload Media Lite のインストールと設定
WP Offload Media Lite のインストール
次に、WordPress に WP Offload Media Lite プラグインをインストールします。
- WordPressのダッシュボードにログインする
- 「プラグイン」メニューから「新規追加」を選択する
- 「WP Offload Media Lite」を検索し、インストールし、有効化する
WP Offload Media Lite の設定
次に、WP Offload Media Lite の設定を行います。
Storage Provider セクション
1. Select Provider は Amazon S3 を選択します。
2. Connection Method は、”My server is on Amazon Web Services and I’d like to use IAM Roles” を選択します。
3. Save Setting はスキップし、Save & Continue をクリックします。
Bucket セクション
1. New or Existing Bucket? では “Use Existing Bucket” を選択します。
2. Select Bucket では、”Browse existing buckets” を選択し、対象を選択します。
Security セクション
Security セクションでは、CloudFront を利用していない限り “Block All Public Access” と “Object Ownership” を無効化しておきましょう
設定確認
これで、設定は完了です。
必要に応じて、保存する S3 パスを追加しましょう。
なお、”Remove Local Media” は ローカルの EBS ボリュームからメディアファイルを削除します。
これによって、EBS ボリュームの容量を開放することが可能です。
しかし、既存のプラグインが正常に働かなくなる可能性があるため注意しましょう。
私の場合、「TinyPNG」という画像最適化プラグインを使用していますが、”Remove Local Media” を有効にすると、画像が圧縮されなくなってしまいました。
そのため、”Remove Local Media” は無効にし、ローカルメディアは cron ジョブで定期的にクリーンアップしています。
既存のメディアファイルの S3 への移行
残念ながら、無料版の機能では既存のメディアファイルは移行できません。
そのため、既存のメディアファイルを移行する方法は以下の通りです。
- 有料版にアップグレードする
- 何とか手動で移行する
「何とか手動で移行する」については、いくつかやり方はあるかと思います。
一つは、S3 に Sync して、必要なファイル・DBレコードを修正する方法
もう一つは、既存のメディアファイルをいったん全削除し、再度アップロードする方法
メディアファイルが少ない場合は、後者でも良いかもしれませんね。
まとめ
本記事では、WordPress のメディアファイルオフロードについて議論しました。
さらに、EFS と S3 を比較し、各々の利点と欠点について評価しました。
また、S3 へのオフロード実装手順を説明しました。
正直、今回 S3 へオフロードしたのは「WP Offload Media Lite」を使ってみたかったというのも大きいです。
結果、既存のメディアファイルは無料版ではオフロードできませんでした。
もしかしたら、探せば無料でできるものもあるかもしれません。
また、EFS へオフロードする方法もありですが、そもそも AMI の取得頻度を高めれば、今回の要件 (ASG による再起動でメディアファイルを失いたくない) は満たすことができます。
AWS アーキテクチャは無限通りあります。
ご自身の得意なやり方や、システム要件に合わせて実装しましょう。
コメント