結論（2020年3月2日時点）

• OS（Ubuntu 20.04）
• WEBサーバー(Apache 2.4、OpenLiteSpeed 1.7.9)
• PHPバージョン（php 8.0）WordPressに反映せず
• データベースサーバー（MariaDB 10.4)
• SSL認証局（Let’s Encrypt、Google Trust Services）

上記の構成ではロードバランサーが構築できません。php 8.0に対応していないプラグインも結構ありますので、無理にロードバランサーを利用する必要もないかも知れません。おそらく中小企業でも必要ありません。

導入趣旨：上記の画像

• 現状：
  「ユーザー」→「Cloud DNS」→「Google Compute Engine　＆　Google Cloud Storage」

• 作業後：
  「ユーザー」→「Cloud DNS」→「負荷分散 Load Balancing」→「Cloud CDN」→「Google Compute Engine　＆　Google Cloud Storage」

• 侵入経路を狭め、セキュリティ強化をし、効率的な配信をします。

2020年12月19日午前1時より数時間格闘しましたが、新規構築作業は失敗しました。正常な状態に復元しています。ご不便をお掛け致しました。

作業時間

2020年12月19日午前1時より数時間、不正アクセス対策のセキュリティ強化のため、WEBサーバーの構築を一新します。リアルタイムで更新して参ります。一時的にアクセス不能時間が発生します。この間の投票は問題ありませんが、コメントは消失してしまう恐れがあります。完了報告までの時間、ご理解の程よろしくお願い致します。以下、私の作業手順メモです。

事前準備

1. ロードバランサー用のファイアウォールルールを新たに作成。
   ロードバランサー用のヘルスチェックが通るようにする。
   allow-health-checks：ターゲットはネットワーク上のすべてのインスタンス、ソースIP範囲「35.191.0.0/16」「130.211.0.0/22」、プロトコル「tcp」、
2. ロードバランサー用のヘルスチェックを作成。
   http-health-checks：ヘルス条件「チェック間隔300秒、タイムアウト300秒、正常しきい値2回、異常しきい値10回」デフォルトは「5，5，2，2」、このままだとサーバーに負荷がかかりすぎるから変更。
   

ロードバランサーへ設定するVMインスタンスを作成。

1. GCPでVMインスタンスのバックアップのスナップショット作成。
2. スナップショットを元にしてイメージを作成。
3. インスタンステンプレートを作成。
   カスタムイメージを元にする。マシンスペック、ディスク形態、ディスクサイズ、httpにチエック、セキュリティでSSH認証鍵設定。
4. マネージドインスタンスグループを作成。
   ロードバランサーはオートスケールさせない。コメント欄を外部サーバーで運用していないから齟齬が出る。
   シングルリージョン、シングルゾーン、作成したテンプレートを選択、自動スケーリングしない、インスタンスの最大数1、ヘルスチェックしない。
5. インスタンスグループが作成できたら、VMインスタンスの外部IPアドレスを固定する。
6. WinSCPで外部からVMインスタンスへログインしてファイル編集できるか確認。
   

ロードバランサーを作成

• ロードバランサーを作成する理由
  不正アクセスを試みようとする頻度が多くなり、広範囲になってきた。セキュリティ強化のためロードバランサーを利用して、背後に「Cloud CDN」を設定して、下に「VMインスタンス」と「Google Cloud Storage」をぶら下げる。ロードバランサーの固定IPになり、VMインスタンスの外部IPは外からは分からなくなる。同時にGoogleが提供する「SSL/TLS証明書」を利用でき自動更新される。

• HTTP(S) 負荷分散（L7、レイヤ7）を作成。

1. バックエンドの構成：
   バックエンドサービスを作成、プロトコル「http」、事前に作成した「インスタンスグループ」を選択。
   ついでに「Cloud CDN」にチェックを入れて設定する。
   事前に作成した「ヘルスチェック」を選択。
   高度な設定、セッションアフィニティ「生成したCookie」「86400秒」に設定して作成。
   すでに作成済みのバックエンドバケットを設定。Cloud Storage バケットには「独自サブドメイン」を参照して選択、「Cloud CDN」にチェックを入れて有効にする。
2. ホストとパスのルール：メディアファイルの配信設定を設定する。
   ①ホスト「*」パス「/*」バックエンド「事前作成バックエンドサービス選択」
   ②ホスト「*」パス「/media/*」バックエンド「事前作成バックエンドバケット選択」
3. フロントエンド：「http」「https」の両方アクセス可能にして、「SSL/TLS証明書」取得、「ロードバランサーのIPアドレス」取得する。
   「https」から作成、「HTTPS(HTTP/2を含む)、「IPアドレス作成」「新しい証明書作成」「Google管理の証明書を作成」。
   ドメイン欄「独自ドメイン、サブドメイン」すべて作成。プロビジョニングが開始されるが、この時点では証明書は通らない（Cloud DNS設定未完了）。2回目の作成時には取得できる。
   次に、「http」を作成。IPアドレスは上記で取得したロードバランサーのIPを選択。
4. 作成完了。

「http→httpsリダイレクト正規化」

1. リライトルールを変更して「http→httpsリダイレクト正規化」
2. リダイレクトループが発生するから、回避する
3. WEBサーバーの再起動を忘れずに。

Cloud DNSのAレコード設定変更

1. ロードバランサー専用のIPアドレスに設定変更
2. Google Cloud StorageのサブドメインをAレコードに追加する。（同一IPアドレス）
3. ロードバランサーのフロントエンドで「SSL/TLS証明書」を再取得。
   すべてのAコード設定が終了、「SSL/TLS証明書」設定も完了する。

メディアファイルを独自ドメインで配信する設定変更

1. EWWW Image Optimizer：
   WebPファイルも「Google Cloud Storage」から独自ドメインで配信
   「https://storage.googleapis.com/gcs.tohyo2020.org/media/」
   ↓書き換え
   「https://tohyo2020.org/media/」

1. WP-Stateless：
   「Google Cloud Storage」から独自ドメインで配信
   「https://storage.googleapis.com/gcs.tohyo2020.org/media/」
   ↓書き換え
   Folder Custom → 「/media/」
   Domain → 「https://tohyo2020.org/」
   すべてのメディアファイルを同期し直す。
   2万5000ファイルほどあるので、どのくらいの時間がかかるか不明。

すべての作業が完了後

• すぐに、スナップショットでバックアップする。

失敗した場合

• 一旦、2020年12月19日午前1時の時点で復元。

結論：失敗報告

• 失敗しました。数時間格闘しましたが、綺麗な状態で稼働するには至りませんでした。2020年12月19日午前1時の時点に復元しました。

• 収穫として、たくさんのエラーが確認できました。他のサイトではロードバランサーを利用できていたので作業手順としては問題ないと思っていました。

• 思い返せば、他のサイトでもロードバランサーを利用する時に、何度も何度もできなかった。あとで同じ設定をしたらできた。Googleのサーバーとの相性もあるんだったな。人と同じだね。

• どこかしらの組み合わせに問題があるようです。

• OS（Ubuntu 20.04、Debian 9）
• WEBサーバー(Apache 2.4、OpenLiteSpeed 1.6)
• PHPバージョン（7.0, 7.2, 7.3, 7.4, 8.0）
• データベースサーバー（MySQL 8.0、MariaDB 10.4)
• SSL認証局（Let’s Encrypt、Google Trust Services）

• どの組み合わせが悪いのか、分かりません。調べても、どの組み合わせが良いのか、分かりません。というか、理想としている組み合わせの例がありませんでした。
  理想と現実が異なったようです。現状でも暗号化などのセキュリティ面では問題はありませんので、少し立ち止まり様子を見ようと思います。
  当サイトでは原則として、個人情報を取り扱っておりませんので「そこまでする必要あるのか」と言われれば、ないかもしれません。

• また、挑戦しようと思います。

---