WordPressの画像をS3において独自ドメインで配信する

お陰様で litera.app/blog のアクセス数が月間 100 万 PV に迫る勢いまで成長し、今まで適当に設定した（嘘です）冗長化と負荷分散設定ではもはや死に体になってきていたので、ちゃんとコンテンツ配信できる仕組みを整えてみました。この記事では以下の内容でやった内容や起こった事象を書き記して、同じことを考えている方の参考になれば、と思います。

WordPress のプラグイン「Export Media Library」を使って画像をエクスポートし、S3 に移行(誤り)
WordPress のプラグイン「search regex」を使って記事中の URL を S3 の新 URL に置換
EC2 インスタンスから画像を一気に S3 にコピー
Route53 でドメインの割り振り先を S3 のバケット URL に設定(誤り)
CloudFront で S3 バケットの SSL 証明書を取得
Route53 でドメインの割り振り先を CloudFront の URL に設定
WordPress のプラグイン「search regex」を使って記事中の URL を新 URL に置換

目次見ただけで長い記事になりそうだ、、ChatGPT 君の力を借りよう。

wordpressのプラグイン「Export Media Library」を使って画像をエクスポートし、S3に移行(誤り)

まず、私は画像を移行するために「Export Media Library」という WordPress のプラグインをインストールしました。このプラグインは、WordPress のメディアライブラリ内の画像を一括でエクスポートする機能を提供してくれます。

最初に「Export Media Library」プラグインをインストールしました。これは特に問題なし。
次に、「Export Media Library」を使用して画像をエクスポートし、ローカル PC にダウンロードしました。これも特に問題なし（と思っていた）

しかし、このプラグインは WordPress が自動生成するサムネイル画像をエクスポートすることができないことを S3 にアップロードされた画像の数と見比べて判明。結果として、一部の画像のみが S3 に移行された。あと自動生成した画像数が多く、これ全部一回ローカルに転送したらネットワーク使用量（＝費用）やばくない？ということで、画像の出力と S3 へのアップは別の方法を模索するため、一回断念。

このため、ブログ記事内では、一部の画像が S3 から配信され、他の画像は従来の EC2 インスタンスから配信されるという状況になってしまいました。こ、これは望ましくないぞ、、でももう時間が、、ということでせっかく休日に作業したのに中途半端な状態で終わることに。

教訓：WordPressの画像を移行するのに「Export Media Library」はおすすめしません。後述しますが、画像の移行先が S3 なら EC2 インスタンスから Amazon CLI を使って直接アップできるし、サブネット内からの転送なので料金もかかりません。ので、そちらを使ったほうがいいです。

wordpressのプラグイン「search regex」を使って記事中のURLをS3の新URLに置換

さて、実は結果だけもう先に書いちゃってますが、一部の画像とはいえ S3 にアップしたので、少しでもブログの負荷を下げるために、S3 を参照できる画像は S3 側のパスに変えておくのに「search regex」というプラグインで検索を置換を行いました。

しかしこれがまた曲者で。

記事数に対して検索結果が全然少ない。1/3 くらい。これ、あとから（作業開始後１時間～１時間半後くらいに）発覚したんですが、自動生成されたサムネイル画像のパスが保存されているテーブルが検索対象になっていない？ぽく、結局本文内の記事のみ S3 の URL にアップデートすることになりました。

それでも何度か置換を行えば必要な分（本文内の画像URL）は全部置き換わったので、結果としては楽に置換できたと思います。でも全件対象にならないのかは謎です。内部で limit 処理でも入れてるのかな？という感じ。興味がある人は調べて私におせーてください。ご連絡はこちらから。

Webエンジニア

裁量をもって働きたい！自由な発想で世の中に便利なものを届けるエンジニア募集

私たち株式会社リベンリは、湘南を拠点に活動するソフトウェア開発会社です。主に自社開発の「Litera App（リテラアップ）」と、システムの受託開発事業を展開しています。 ■Litera App■ 「Litera App」は、ユーザーのPC操作に合わせて、より効率的な操作方法や覚えるべき機能を、自動で教えてくれるWindowsソフトです。いつも通り作業するだけで、必要な操作方法だけをその場でアドバイスしてくれるので、効率よくスキルを習得できます。業務傾向のレポートを活用すれば、さらなる業務効率化と経費削減を見込めます。 ■受託開発■ 不動産、金融、製造、サービス業など、様々な業界のクライアントから依頼を受けて開発をしています。これまでの経験を生かして、企画立案からお手伝いするケースもあります。ユーザー目線に立って、どのようなUI/UXを構築するか、クライアントやサービスの利用ユーザーの意見を汲み取り、構築していきます。開発段階におけるメンバーからの意見も大切にしています。 ▍今後の展望日本の生産性を高めるために「Litera App」の開発を進めるとともに、より良いシステムを世の中に構築する受託開発の両軸で拡大を図っていきます。「Litera App」は、既に大手企業での導入が進んでおり、今後も新機能の開発を進めていく予定です。また、受託開発においては、開発メンバーが様々なシステムに触れて成長することで、自社のノウハウを高め、新しいサービスに、どんどんチャレンジしていける開発会社になることを目標にしています。 ■人の生活を便利にするものをつくり続ける■ Litera Appや受託開発事業で、その業界特有の課題やユーザーのニーズを知ることが出来ます。そこに、リベンリが大切にする、「自由な発想とアクション」を掛け合わせて、世の中の生活をより便利にするものをつくっていきたいと考えています。

株式会社リベンリ

EC2インスタンスから画像を一気にS3にコピー

ブログ画像の URL を一部変更し、S3 から読みだしたことでブログサーバの負荷はほんの少しだけ軽減されたように思います。とはいえ、夕方くらいには CPU クレジットが 150 近くまで減り、ハラハラしながらモニタリングしていました。

もちろんこの間、ただ減っていく CPU クレジットを手をこまねいて眺めていたわけではありませんよ。EC2 にある画像を S3 に直接アップできないものか、と調査を進め、以下のようにすることで直接アップが可能だという知見を得ました。

１．ブログサーバの含まれる VPC に、S3 へのエンドポイントを追加
２．ブログサーバの IAM に S3 へのアクセス権を付与
３．Amazon CLI でバケットを指定してファイルをコピー

上記１～３もちょっと調べればやり方の記事は出てくるので、ここではいろいろと発生した問題について記載します。

１：特に問題なし（参照した記事から実際の設定画面の UI が変わっていたけど、まぁなんとかなるレベル。

２：先にコマンドだけ試しちゃったので S3 へのアクセス権限がねーぜ、と言われたので EC2 内のコマンド実行ユーザ単位のアクセス権にするか、EC2 インスタンスの IAM ユーザに S3 のアクセスポリシーを割り当てるか考えました。後者のほうが楽だったので AWS の管理コンソールから S3 へのポリシーを割り当てた。

３：最初は cp コマンドでやろうと思ってましたが、いろいろ調べて sync コマンドでフォルダをまるごと指定して実施。--exculde "" --include ".png" などで転送ファイルオプションを指定して、不要な index.php が S3 に行かないように制御して全ファイルの転送は終了

ファイルの転送処理自体の作業はなんてことなかったんですが、途中実は年度を間違えてコピーしていたことに気づき、10 ヶ月分の転送処理をやり直したのは秘密です。とはいえ、それも 10 分くらいの手戻りでしたが。

Route53でドメインの割り振り先をS3のバケットURLに設定(誤り)

よっしこれで S3 から全画像を配信できる準備が整ったぞ！と意気揚々とし次は S3 にドメインを割り当てる番だ、とうっきうきで Route53 にドメインの設定を行って、早速アクセス。

無味無臭なあのブラウザのエラー画面で「SSL証明書が怪しいんだぜ～？」という警告を頂戴する。

そういや、S3 ってどうやって独自ドメインの SSL 設定するんだっけ？と調べたところ、どうやらCloudFront を経由しないと SSL 化できないとのネット記事。

CloudFrontでS3バケットのSSL証明書を取得

ということで、以下のように作業。

１．CloudFront でオリジンを S3 のバケットにしてキャッシュ化する。
２．AWS Certificate Manager で SSL 証明書のリクエストを作成。ドメインは Route53 上にあるので、この画面だけで Route53 への Vefiry 用 CNAME が登録できる。この点は AWS 使ってその便利さを再度実感した。
３．ドメイン所有者検証( Verify )には数分程度かかるが、それも無事に終了。