上記画像は「WordPress」を「GCP」マルチリージョンのロードバランサーで運用する最終形です。
また「Google Cloud CDN」を挟み「GCPのVMインスタンス」と「Google Cloud Storage」利用し、サーバー負荷の軽減も行っています。
第7回は赤枠内、「ロードバランサー」 を作成します。
GCPのロードバランサーを利用した「tokyo2020unofficial.com」の設定です。
ロードバランサーを利用していない「投票2020」の設定はこちらの目次です。
ロードバランサーはランニングコストが高いので一時休止しています。気分次第で記事は更新していきます。
第7回 【WordPress_ロードバランサー】 GCP で 「admin インスタンスグループ」を利用して、WordPress のロードバランサーを作成する。
環境：Debian 9 php 7.0 Apache 2.4.25 MySQL 5.7 Cocoon
目的：ロードバランサーの作成です。同時に「https化」対応「GoogleのマネージドSSL証明書」取得。
第6回までに、ロードバランサーに必要なインスタンスグループを作成しました。
今回は、ロードバランサーを作成しながら、SSL/TLS対応を行なうために「GoogleのマネージドSSL証明書」も一緒に取得します。
「投票2020」では「Let’s Encrypt」を利用しています。
「tokyo2020unofficial.com」では、ロードバランサーで「Google Trust Service」の証明書を利用しています。
「http→https」301リダイレクト正規化はまだこの先です。
「ロードバランサー」や「CDN」の背後にある「WordPress」は通常の正規化では「301リダイレクト」ができません。「WordPress」の他ファイルでも編集が必要ですので、別記事で書きます。
httpsでアクセスできるようになるまで。
- 第7回ロードバランサーの作成
- 第7回バックエンド
「第6回」までに作成した「admin インスタンスグループ」を配置。
- 第7回フロントエンド
ロードバランサーの「固定IPアドレス」取得
「GoogleのマネージドSSL証明書」取得
- 第8回Cloud DNS
ロードバランサーの「固定IPアドレス」を設定。
- 第8回WordPress
一般設定「http」→「https」へ書き換え。
- 第8回ファイアウォールルール
ロードバランサー用にヘルスチェックのルートを設定。
- 第9回「http→https」
301リダイレクト正規化。リダイレクトループ回避。
1.1 ロードバランサーの作成画面へ。
- 「メニュー」「ネットワークサービス」「負荷分散」「ロードバランサを作成」の順にクリック。
1.2 「HTTP(S)負荷分散」
- 「HTTP(S)負荷分散」の「設定を開始」をクリックして、次へ。
1.3 「HTTP(S)負荷分散」インターネット接続
- 「続行」をクリックして、次へ。
1.4 ロードバランサーの名前
- 「名前」は任意です。入力して、次へ。
1.5 「バックエンド」設定
- 「バックエンドの設定」「バックエンドサービス」「バックエンドサービスを作成」の順でクリックして、次へ。
1.6 バックエンドサービスの作成
「バックエンドサービスの作成」上部の設定。
- 「名前」は任意です。
- 「プロトコル」は「HTTP」。
- 「新しいバックエンド」「インスタンスグループ」は「第6回」に作成したものを選択。
- 「Cloud CDN」「✔」します。「WordPress」なので意味があるのか微妙です。
「Google Cloud Storage」の前にも「Cloud CDN」を挟むので意味があるか微妙です。
いらないと判断すれば「Cloud CDN」「✔」は外しても良いと思います。 - 「ヘルスチェック」をクリックして、「新しいヘルスチェック作成」をクリックして、次へ。
1.7 ヘルスチェック作成
「バックエンドサービスの作成」ヘルスチェックの設定。
- 「名前」は、任意です。「ヘルスチェックだよ」とわかる名前が良いです。
- 「プロトコル」は「HTTP」。
- ヘルス条件のデフォルト
「チェック間隔」10秒
「タイムアウト」5秒
「正常しきい値」2回連続して成功
「異常しきい値」3回連続して失敗
- 「ヘルス条件」が、ポイントです。
デフォルトは以下になりますが、私は変更していますので、次へ。
1.8 ヘルスチェック作成のポイント
「バックエンドサービスの作成」ヘルスチェックの設定。
赤字で記した箇所がポイントです。
読み飛ばしてもいい部分です。
- ヘルス条件「私の変更後です。」
「チェック間隔」60秒
「タイムアウト」60秒
「正常しきい値」2回連続して成功
「異常しきい値」5回連続して失敗
- 「保存して次へ」をクリック。
- 「チェック間隔」10秒 → 60秒
- 「タイムアウト」5秒 → 60秒
なぜこれだけ長い秒数を設定するのか。
何度もテストを繰り返して感じたのは、この秒数が短いと「ヘルスチェックだけ」で、それぞれの「VMインスタンス」にかなりの負荷がかかり、常にCPU使用率が高く維持されてしまいます。（ヘルスチェックってなんだ？というところから調べた結果です..）
「CPU使用率」が60%に達するとオートスケールし始めます。それが連鎖していき、意味もないような「ネズミ講ロードバランサー」になってしまいます。
気づいたことは、この「ロードバランサー」は企業を相手にしていて「貧弱なマシンスペック」を選択した場合、「頻繁なヘルスチェック」に耐えられないと解釈しました。
そこで、企業でもないので、頻度を減らしてみたらどうかと何度も試してみた結果がこのくらいの秒数です。
「CPU使用率」の負荷が非常に軽減でき、かつ、オートスケールする「VMインスタンス」が動作しなくなった時に、作成し直す感度も問題なく最適というのが、相当期間試してみた私の感想です。
- 「正常しきい値」2回連続して成功 → 変更なし
- 「異常しきい値」3回連続して失敗 → 5回
ロードバランサーに利用する「ヘルスチェック」の作成方法には2種類あります。
- 「ロードバランサー」を作成する過程で、「ヘルスチェック」を作成する。
デフォルト：3回 - 直接「ヘルスチェック」を作成する。
デフォルト：2回
- 「異常しきい値」3回連続して失敗を5回にすると、個人で運用する「VMインスタンス」のマシンスペックでは、ちょうど良いように思います。
1.9 バックエンドサービスの詳細
- 「バックエンドの設定」の「バックエンドサービス」の作成が完了しました。
- さらに詳細な「バックエンドサービス」の設定ができます。
- 作成できた「バックエンドサービス」の「鉛筆マーク」をクリックして、次へ。
1.10 設定
今まで設定してきた部分と重複する部分が多々ありますが、1点異なる箇所が最下部です。
- 「高度な設定」をクリックすると、詳細設定が可能になります。
1.11 「バックエンドサービス」の高度な構成
「バックエンドの設定」の「バックエンドサービスの画面」最下部。「セッションアンフィニティ」の部分です。
- 「生成したCookie」「86400秒」として設定しています。
設定項目の理由は下記画面下に記載しています。
- 「更新」をクリックして、次へ。
セッションアンフィニティには3種類あります。
このセッションアンフィニティは、アクセス解析に必要な情報と解釈しています。
- なし
何もしないし、アクセス解析できない。 - クライアントIP
例えば、「全国チェーン吉野家」、1人が移動すればIPアドレスが変わります。
ゆえに「10」の売上に対し、
「1人が10回来店したのか」、「10人が1回ずつ来店したのか」どちらか判別できません。特にロードバランサーを利用したオートスケールだと。どのインスタンスにアクセスしたかがわかりません。 - 生成したCookie
こちらを選択した場合、「1人が10回来店したのか」、「10人が1回ずつ来店したのか」判別できるようになります。そして、その情報を1日でリセットするのが「86400秒」です。秒数は変更可能です。
セッションアンフィニティについて、Google 公式。
1.12 「ホストとパスのルール」設定
「ホストとパスのルール」の設定。現段階では設定を行う必要がありません。「Google Cloud Storage」を利用する時には「バケット」を作成した後、設定する項目です。
仮に「Google Cloud Storage」を作成していたら、メディアファイルを片側に寄せて、WordPress本体とは分けて配信するように設定します。（WordPress本体が軽くなる）
「WordPress本体」側を設定。
ホスト：「*」
パス：「/*」
バックエンド：作成した「バックエンドサービス」
「Google Cloud Storage」側を設定
ホスト：「*」
パス：「/media/*」→Google Cloud Storageのフォルダが「media」の場合の指定
バックエンド：「作成したバケット」（Google Cloud Storage 本体）
1.13 「フロントエンド」設定
「フロントエンドの設定」画面です。
- 私はすでに設定しているので、「HTTP」「HTTPS」の２つが表示されています。
「フロントエンドのIPとポートを追加」をクリックして、次へ。
1.14 フロントエンドのIPとポートを追加
「フロントエンドの設定」画面です。
- 「フロントエンドの設定」画面です。
1.15 「HTTPS」の方の設定①
「フロントエンドの設定」画面上部、詳細設定。
- 「名前」は、任意です。
「HTTP」なのか「HTTPS」なのか判断ができるような名前が最適です。
- 「プロトコル」は、「HTTPS(HTTP/2を含む)」を選択。
- 「IPアドレス」は、「エフェメラル」から「IPアドレスを作成」に変更します。
この「IPアドレス」が「ロードバランサーの代表」となる「外部IPアドレス」です。
1.16 「HTTPS」の方の設定②
「フロントエンドの設定」画面下部、詳細設定。
- ここで、SSL証明書を一緒に作成してしまいます。
- 「証明書」、「新しい証明書の作成」の順でクリック。
1.17 「Google 管理の証明書を作成する」
「新しい証明書の作成」画面です。
Google が取得および管理する証明書（Google マネージド証明書）
いわゆる、SSL証明書です。
クリックして選択するだけで「SSL証明書」を設定できるので非常に簡単です。
- 「名前」は、任意。証明書という意味で、「ssl」は含めたほうがわかりやすいです。
- 「作成モード」は、「Google 管理の証明書を作成する」を選択。
- 「ドメイン」は、「wwwなし」「wwwあり」の両方を入力し、下部の「作成」をクリックして、次へ。
- 2020年2月くらいから、サブドメインも一緒に「Google 管理の証明書」できるようになったようです。それまでは、欄がありましたが、入力したらエラーになっていました。
1.18 「HTTP」の方の設定
- 「Google 管理の証明書」が作成でき「HTTPS」のフロントエンドが作成できたら、「HTTP」の方も同様に設定します。
- 「HTTPS」「HTTP」の両方が作成できたら、「更新」クリックして、次へ。
1.19 設定確認
- 「すべてが正しく設定できたら」緑色の✔マークがつきます。
わかりにくいですが、下の赤枠に「詳細メニュー」というリンクがあります。結構詳細な設定や確認ができますが、わかりにくい位置にあります。今回はスルーします。
- 設定項目を確認するため、矢印部分をクリックして、次へ。
1.20 設定完了
- 上記画面の「ロードバランサー」のリンクをクリックすると下記画面になります。
「admin インスタンスグループ」と「Google 管理の証明書」が表示されます。
ここで「第7回」の設定完了です。 - この段階でWordPressの「テーマ」を導入するのが1番タイミングが良いと思います。
- 第2回 【WordPress】 テーマ「Cocoon」を導入する
ロードバランサーを利用する時、しない時に関係なくこちらを参考にしてみてください。
- 以下はその後に付随する、その他の機能です。
- フロントエンド
「HTTPS」欄、右側、赤色の「！」があります。これは「Google 管理の証明書」に「Google Cloud Storage」を含んだ場合です。「CNAME」ではなく「Aレコード」で設定しないと、「SSL証明書」の対応をしていないことが分かります。 - ホストとパスのルール
「Google Cloud Storage」を含んだ場合です。利用する時には「バケット」を作成した後、設定する項目です。 - バックエンド
「ロードバランサー」の背後にある「バックエンド」、「インスタンスグループ」の一覧です。 - バックエンドバケット
「Google Cloud Storage」を設定する項目です。
あとがき
1.21 あとがき①
「メニュー」「ネットワークサービス」「負荷分散」「詳細メニュー」の順にクリックし、「証明書」へ遷移。
1.22 あとがき②
- 2020年2月時点、ロードバランサー利用しない時、「Google Cloud Storage」には「Google 管理の証明書」は対応していません。
1.23 あとがき③
- 2020年4月20日時点、ロードバランサー利用しない時、「Google Cloud Storage」には「Google 管理の証明書」は対応していません。
1.24 あとがき④
- 「ワイルドカード」は利用できません。
1.25 あとがき⑤
- 「ワイルドカード」は利用できません。
「Google 公式」、ここに「Google Cloud Storage」に対して、「Google 管理の証明書」が対応。と書かれればとても簡単に設定できるようになります。
【コメント】 ※「メールアドレス不要」