More than 1 year has passed since last update.

【初心者向け】Wordpressでサイトを立ち上げるときの超オススメ構成

Last updated at 2022-12-16Posted at 2020-12-14

はじめに

wordpressを立てたときにどんな構成にするかわりと悩んだので、新しく立てようとしていて自分と同じように悩んでいる方の参考になればと思います。

まず後ろ向きな前提共有から、
・お金はかけたくない
・運用コストもかけたくない
・構築コストもかけたくない
・セキュリティ面を超堅牢に、、ってわけでもない

次に前向きな前提共有です、
・サイトパフォーマンスは高く保ちたい
・https化したい
・productionだけでなくテスト用のstaging環境も欲しい

以上が、自分がwordpressを立てる際に考えてたことです。

結論からいうと、最終的にこんな構成になりました。

(created by drawio in vscode)

これにすりゃええやんってのにもっと早く気づきたかったっていう話です。

ここからは、最初にどういうアプローチをとったか、何につまづいたか、最終的な構成はどうなったのかと紹介していきます。

1. 安くてお手軽なサーバはどれだ

まず検討すべきはサーバかと思います。
過去に先輩がawsのLightsailというEC2でwordpressのインスタンスを作成していたので、そのやり方を最初に参考にしました。

1-1. 月額利用料金が安い

月額3.5ドルしかかかりません。安いですね。
メモリやSSDに関しては想定するトラフィック量やコンテンツ量に応じて変える必要がありますが、要件が肥大化すればするほどwordpress以外の選択肢を取るほうが現実的に有効なケースも多いと思うので、wordpressで簡単なサイトが欲しいならこれくらいのスペックでも全然十分だという印象です。

余談ですが、最近Lightsailでコンテナが月額7ドルで利用可能になったそうです。
サーバレスのfargateは業務で使う分には非常に便利ですが費用面が気になるため、簡易版として扱うには便利かもです。
（localでもdockerで開発できるし、今紹介してるやつよりこれのほうが良い可能性もある）
[アップデート] Amazon Lightsail でコンテナが利用可能になりました！
プライベートなコンテナイメージを Amazon Lightsail コンテナサービスで使う

1-2. 公式ドキュメントが豊富

安くて手軽に構築ができて安心感もあるawsのLightsailは、他のレンタルサーバよりも迷わず選定がしやすく、日本語ドキュメントが豊富にあるし、aws社は常に網羅的にドキュメントを用意してくれる印象があるので困ることも少ないのかなと思います。

注意：自分はもう構築が終わっちゃってて構成を変える予定もないので、他社のレンタルサーバとの詳細な比較はモチベが湧かずやってませんのであしからず。

1-3. バックアップが簡単

lightsailはインスタンスのスナップショットを自動で７日分まで取得してくれます。
wordpressをアップデートした際や何か大きな変更を行う際は、サイトで不具合が起きる可能性もあります。何かあった時のためのバックアップが簡単に取得できて、そこからすぐにインスタンスの再作成ができる点は非常に安心できるし便利です。

2. https化は絶対にしたい

Lightsailを使うとポチポチボタン押して作成！ってするだけでwordpressのインスタンスが出来上がります。
じゃあ次はドメインとDNSを繋いでブラウザでURL叩いたらサイトが見れるようにしようってなると思うんですが、その際に絶対にhttps化しておきたいです。

GoogleのSEO評価を上げるためにも、ちゃんと手入れが行き届いてる安全なサイトであることをユーザーに伝えるためにも、鍵マークがとにかく喉から手が出るほど欲しいです。

ではどう実現するのが一番てっとり早いのか、自分がweb上で検索した際は下記の順でやり方を学んでいきました。

2-1. wordpressのhttps化プラグインを使用

wordpressは非エンジニアでもサイトが構築できるのが利点です。なのでプラグインをポチッと入れてポチッと設定すれば出来るよ！！って記事がweb上に大量に存在します。

「ふーむ、、ならこのプラグイン使ってみるか、てっとり早そうだし。」と誰もが気軽に試すと思うんですが(自分も..)、思わぬエラーに出会ったりしたときにその対策もよくわからず、後から激しく後悔しました。

特にサイトのhttps化は、httpリクエストが来た場合にhttpsにリクエストを流す、というリダイレクト処理をwebserverに行わせるため、apacheなどの基幹的なファイルをいじることになります。

そんな大事な作業をよくわからないプラグインに任せるのは非常に怖いです。

なぜなら、今は手早く構築できてそれでよくても、1年後などにプラグインがupdateされておらずwordpress本体のバージョンとの依存性で競合してしまっていたら動かなくなるリスクがあるからです。

また、プラグインを有効化するとサイト内のどこかのファイルが上書きされるんですが、どこがどう書き換わったのかマジでよくわからないのでエンジニアとしては万が一エラーにハマったときに原因究明がすごくやりづらいです。

実際に自分は無限リダイレクトループの発生に見舞われ時間を失いました。。。

プラグインが便利なのは重々承知だし、他に使っているプラグインなどは普通にあるんですが、https化だけはプラグインに任せるのはやめたほうが無難なのでは？？という結論に至りました。

2-2. Let's Encryptの無料証明書を使う

では誰にhttps化を担わせるか。Lightsailで立てたインスタンス自身に任せる方法があります。

鍵マークを付けるためにはサイトの安全性を保証する証明書が必要です。
それが無料で貰えるのはLet's Encryptが有名です。

手順

サーバーにLet's Encryptの無料証明書をインストール
apacheとwordpressにhttpがきたらhttpsへリダイレクトさせる処理追加
Let's Encryptの無料証明書を更新するcronの設定

もしこのやり方を取る方がいれば、こちらの記事が丁寧にまとまっているので参考にどうぞ。
Lightsailで常時SSLのWordPress

2-2-1. 【メリット】プラグインを使わずにできる

変更した箇所が明確になっているということは、何かエラーが発生した際はその箇所を取り除けばすぐに復旧できます。
プラグインを使わずに実現できていること自体がメリットです。

2-2-2. 【メリット】無料で実現できる

Let's Encryptは無料証明書として有名なので、けっこう沢山利用されているみたいです。
サイトの鍵マークをクリックして、証明書(有効) > 発行元　を見ると、どこの証明書かわかりますが、たまにLet's Encryptを見かけることがあります。
無料でお手軽だし、みんなが使ってるからやり方が沢山載っていて安心できるところが利点です。

2-2-3. 【デメリット】apacheとwordpressのファイルに手を加える必要がある

個人的にはできればここに手を入れたくありません。
単にapacheだけなら公式ドキュメント読んで設定すればいいんですが、apacheとwordpressが組み合わさるとどんな挙動をするのかが把握しきれず不安が残りました。
実際に、このへんのファイルを弄って挙動確認などをしてみたりもしたんですが、うまくいかないときのデバッグがつらかったです。（ただ、自分の対応力が低かっただけかもしれないので、リーズナブルな選択肢としてはアリかも。）

2-2-4. 【デメリット】cronの設定が必要

証明書は取得時から年数が経つと有効期限が切れてしまいます。
awsの証明書を使っている場合(AWS Certificate Manager)は、証明書の更新をawsが勝手にやってくれるので期限のことは何も気にする必要がありません。

しかし、Let's Encryptはそういった"証明書管理"は何もしてくれません。
ではどうするかというと、Let's Encryptの証明書期限を更新する処理をこちらから定期的に実行することになります。

サーバーで定期的に処理を実行するのに最適なのがcron(クーロン)と呼ばれるやつです。
そのcronに対して、1ヶ月おきにこの処理を実行してっていうお願いを設定します。

証明書更新のシェルスクリプト
cronの設定

最初の前提でいったように、運用コストを減らしたいので「何か重要な処理を担うcronが稼働している」という事実自体を運用における共有事項から抹消したいです。

よって、自分はこの方針を取るのをやめました。
なお、当初は証明書やLightsailロードバランサー、CloudFront周りの料金感覚がよくわかっていなかったので、staging環境ぐらい無料にしといたほうがリーズナブルでよくね？とこの方針を検討していました。
（そもそもstaging環境とproduction環境は完全に同じ構成を取ったほうが何かあった時の原因究明がしやすいので、そういう発想が無い時点で構築担当者としてダメだったような気がします。当たり前だと思われる方も沢山いるとおもいますが、自分の失敗談として載せておきます。）

2-3. Lightsailのロードバランサーを使う

次に考えたのがLightsailのロードバランサーです。
数年前に先輩が立てていたwordpressがLightsailにあって、そこにロードバランサーが使われているのを見つけてこのやり方を知りました。

2-3-1. 【メリット】証明書を簡単に取得できて管理までしてくれる

awsが提供するEC2の廉価版サービスなので、証明書の管理などもやってくれます。
ロードバランサを立てて証明書をポチッと作成して付けるだけでhttps化できます。

証明書はDNS方式で自動更新されるので、期限が切れることを心配する必要もありません。

2-3-2. 【デメリット】月額18ドルかかる

簡単かつ安全にhttps化ができて、証明書の期限切れを心配する必要がないという利点だけで、月額18ドルを払う価値があるのではないか？、一度はそう思いました。

そして、構築しました。

この構成は全てLightsailで稼働している点は見通しがいいですが、証明書のためだけにロードバランサーを置くのはどうなのだろうか、と疑問に思いました。もしトラフィックが増えてきた場合は2台→3台と簡単に負荷分散させることができる点が便利そうなのですが、そんな量のトラフィックがくることは全く想定してませんでした。

3. 高いサイト評価を得るには

サイトを作ったあとは、コンテンツを追加してページを公開しますが、SEO評価を上げていけるのかどうかが気になると思います。

自分もリリースまでの間は何度も何度もしつこいぐらいPageSpeed Insightsでサイトをチェックしました。

SEO評価のためにエンジニアが出来ることは色々ありますが、その中でも最もエンジニアが責任を持つべきはサイトの速度面だと思ったからです。

Googleはユーザーフレンドリーな良いサイトと良いコンテンツを評価する。
その際に、コンテンツ開発部隊がいくらライティングや記事設計を頑張っても、肝心のサイトパフォーマンスが酷ければ努力が水の泡となってしまうためです。

特に初期リリース段階でもしSEO高評価を狙おうとしているのであれば、サイト側の基盤パフォーマンスを上げるための作戦立て・設計・実装には十分コストをかける価値があるので、wordpressだからこそ出来るベストな構成がないかを考えるのが良いと思います。
（ちなみに、自分はamp化やPWA、サイトマップ、SEO対策用プラグイン、画像圧縮方法、キャッシュなどをリサーチしました。ampは酷い仕上がりとなり不採用、pwaはそこそこ動くけども特に要望もなく不採用、キャッシュは後述のCFに任せるので不採用、他は採用となりました。）

また、最近はWeb Vitals（LCP,FID,CLS）の３つの指標を満たすことがSEO評価において重要とGoogleが公言してるので、そちらに早めに対応することが大事になっていたりします。
もう既に上記のコアアルゴリズムのアップデートが実施されちゃったみたいなので、そろそろ順位変動とか来てもおかしくないなと注視してる段階です。（2020-12-06記載）

だから誰かwordpressサイトでWeb Vitals高評価を叩き出せる構成・やり方を見つけてください〜(他力本願)(自分でやれ)

3-1. パフォーマンス向上のためのキャッシュを誰が担うのか問題

少し話がそれたので戻りますが、パフォーマンス向上策の一つとしてブラウザからwebサイトへのリクエストをキャッシュするのが超有効です。

大抵のwebサイトの表示は、データくれ！→おk→返却、というフローを取るんですが、これをデータくれ！→もう既にあります→マジか、じゃあ表示というフローに変えることができるのがキャッシュです。

じゃあ、そのキャッシュ処理を誰が担うのかという問題になります。

3-2. Lightsailのロードバランサーではキャッシュできない

先ほどの構成だと、wordpressの手前にロードバランサーがいます。なのでロードバランサーにキャッシュしてほしくなります。
そうするとリクエスト回数が減り、リクエスト回数が減るとデータ通信にかかる時間が減り、結果的にサイト速度は早くなるからです。

ただ、自分の知ってる限りではLightsailロードバランサーでキャッシュする方法はなさげです(インスタンスとは違ってsshもできない)。

3-3. apacheとwordpressのどちらでキャッシュするか

では、ロードバランサーの後ろにいるLightsailのインスタンスの中にいる、apacheもしくはwordpressにキャッシュを担わせることになります。

自分が調べたときは色々なプラグインや紹介記事が出てきました。どれがいいのやら、ぱっと見だと全然わかりませんでした。

やり方としては、apacheのキャッシュ設定を調べて、apacheのconfファイルを自前でいじるか、良さそうなプラグインを入れてそれに全部任せてしまうかのどちらかになると思います。

自分は、プラグインでキャッシュした場合にデバッグや原因究明が不可能になりそうな気がしたので最終手段にしようと思いました。
キャッシュはバグを引き起こしやすいもので、キャッシュしてはいけないものがされていてユーザーに間違ったものを見せてしまう現象がよくあり、それを未然に防ぐためにはそこそこ神経質になる必要があります。
あとはコンテンツを変更したのに反映されない！？なんで！？って思っていたらキャッシュが効いてただけでした、とかキャッシュ時間がモノによっては違うからコンテンツ反映まで待機してください、とかあるあるな印象です。

結論としては、キャッシュのプラグインに手を出すのは怖いなって思いました。
（ただ、パフォーマンスを上げるために再度検討する可能性はあります。）

4. CloudFrontでええやん

サイト速度上げるために少なくともアセット類(jpg,png,css,js)はキャッシュさせたい。
でも見通しはできるだけよくしておきたい。。

そう思いつつ何かないのか検索してたら、CloudFrontを使ってる構成の記事に出会いました。
（どれだったか覚えてないけど、丁寧なのが2~3記事以上ありました。）

え？、、、これでいいやん。。。ってなりました。
普段業務でCFを使っていたのに、なぜ自分はこれにしなかったのかと激しく後悔しました。

4-1. 【メリット】簡単かつ安全にhttps化

CloudFrontはawsが提供するCDNです。
世界中にエッジサーバが存在し、そこが良い具合にデータをキャッシュして各ユーザーに返却してくれる大変素晴らしいやつです。

そんなCFは、クライアント(ユーザー)側とオリジン(webサーバー)側の両方のリクエストをどっちのプロトコル(https/http)にするか簡単に制御することができます。
CFにはACMで作成した証明書(たしか月額1ドルくらいで、自動更新も可）を付与できるので、簡単にhttps化できるのです。
わざわざLightsailのロードバランサなど使わずとも、CFにhttps化を担わせれば良かったんですね。
(ちなみにLightsail側は独自のDNSやroute53的な設定を持ってて、GUIが本家と少し違ってわかりづらいため、やはりオススメしません）

4-2. 【メリット】強力なキャッシュ

CFの強みは細かいキャッシュ設定ができることです。
アセット類(jpg,png,css,js)にリクエストが飛んできた場合はCFにキャッシュしてもらってそこから返します。
こうすることでリクエスト量が減ってサイト速度が早くなります。

設定例はこんな感じ

4-3. 【メリット】セキュリティ面での柔軟性

wordpressでセキュリティ対策をしっかりするには、色々考慮して実装しないといけないものが多いです。

セキュリティ面の対策話はこちらの記事が参考になりますので、興味ある方はどうぞ。
【WP】WordPressの基本的なセキュリティ対策
 WordPressの侵入対策は脆弱性管理とパスワード管理を中心に考えよう

CFにはWAFというファイアーウォールを簡単に組み合わせることが出来るので、不正なリクエストが来たらブロックするためのルールを自由に設定することができます。

wordpress側で色々とやらないといけないことがあるにせよ、ひとまずWAFがアタッチされているCFを経由させることができる点は非常に安心できます。　

ちなみに料金面についてはCFは稼働時間に対する課金でなく通信量に対する課金がメインなので、トラフィック量が大したことないならばそこまでボトルネックにはならないはずです。
CFの料金はこちら

5. 最適解

上記でいこうと決めたのでstaging環境を同じ構成で作成しました。
危ないファイルをいじったりしなくていいので、構築や確認作業が非常に楽です。
また、料金面も全然許容範囲です。

6. おわりに

wordpressを立てる際に自分が最適解だと思っている構成とそこに至る過程をご紹介しました。
感想やご意見などお待ちしてます。

似たような話だと、こちらの記事も参考になるかと思います。
WordPressサイトをCloudFrontで配信する

そもそもwordpressってどうなん？という評価は下記の記事が参考になりますので、興味ある方はどうぞ。
【WordPress】WordPressのここがダメ
 【WordPress】WordPressのここがイイ

余談ですが、CF構成で構築したあと、コンテンツも少ない状態なのになぜかサイト速度が遅かったです。
原因を調べていたらNotoSansJapaneseというGoogleフォントの読み込みが遅いせいだと分かりました。
これを改善するだけでPageSpeed Insightsのスコアが30点ほど上がってmobile/pcともに90点越えの緑になりました。
こちらの記事が非常に参考になりましたので、興味ある方はどうぞ。
Google FontsのNoto Sans Japaneseが重い？記述を変えたら速くなるかも！
なお、wappalyzerとPageSpeed Insightsを使ってweb上のwordpressサイトをいくつか速度チェックしてみたら、大抵のサイトがこのフォント読み込み遅い問題のために速度評価を大きく落としていました。リーズナブルに改善できるため非常に勿体無いです。

wordpressは世界中で一番使われているCMSでシェアもweb上では圧倒的だそうです。
脆弱性の温床になりやすいとはいえ、「サイトが欲しい」という人々の欲望に対してリーズナブルに満足してもらえる解答を出せてる時点で、革新的良サービスなのだと思います。
ただ、エンジニア泣かせな点が多々あることは間違いないので、お気をつけて！！
(もう原因不明のリダイレクトループは嫌だ、やだよぉ...)

7. 参考文献

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up