上記画像は「WordPress」を「GCP」マルチリージョンのロードバランサーで運用する最終形です。
また「Google Cloud CDN」を挟み「GCPのVMインスタンス」と「Google Cloud Storage」を利用して、サーバー負荷の軽減も行っています。
第6回は赤枠内、「Admin インスタンスグループ」を作成します。
GCPのロードバランサーを利用した「tokyo2020unofficial.com」の設定です。
ロードバランサーを利用していない「投票2020」の設定はこちらの目次です。
ロードバランサーはランニングコストが高いので一時休止しています。気分次第で記事は更新していきます。
第6回 【WordPress_ロードバランサー】 GCP で WordPress adminのインスタンスグループを作成する。
環境：Debian 9 php 7.0 Apache 2.4.25 MySQL 5.7 Cocoon
目的：ロードバランサー作成の準備です。
ロードバランサーの背後に「WordPressを配置」させるための「adminインスタンスグループ」を作成します。
- ロードバランサーに必要なインスタンスグループを作成するには、この順番が必要不可欠になります。
- 第2回スナップショット
- 第3回イメージ
- 第4回インスタンステンプレート
第5回にSSH認証鍵取得について記載しています。
- 第6回インスタンスグループ
「admin インスタンスグループ」作成方法
「GCP」で作成した「admin インスタンステンプレート」を元に「admin インスタンスグループ」を作成します。
1.1 インスタンスグループ作成画面
- 「インスタンスグループの画面」へ遷移します。
- 「メニュー」「Compute Engine」「インスタンスグループ」の順にクリック。
- 上部の「インスタンスグループを作成」をクリック。
1.2 インスタンスグループ作成画面上部
- 「インスタンスグループの作成」画面上部の入力。
- 「新しいマネージドインスタンスグループ」をクリック。
- 「名前」は任意ですが「adminインスタンステンプレート」と同一にしたほうがわかりやすいです。
- 「ロケーション」は「シングルゾーン」を選択。
- 「リージョン」は、日本であれば、「東京」あるいは、「大阪」を選択。
海外にした場合、遠い場所のリージョンを選択すると、転送料金が高くなります。 - 「ゾーン」は、好きなものを選択。どこでも大丈夫です。
大企業になるとゾーンによってスペックを気にする必要が出てきますが、中小企業や個人なら関係ないと思います。ハイスペックなマシンがあるかどうかという判断ですので気にしません。
- ロードバランサー（Load Balancing）でオートスケールするには、「新しいマネージドインスタンスグループ」を選択する必要があります。
- 「新しい非マネージドインスタンスグループ」は「指定したVMインスタンスのみ」で「ロードバランサー」としての機能しますが、オートスケールすることはできません。
1.3 インスタンスグループ作成画面中部
- 「インスタンスグループの作成」画面中部の入力。
- 作成した「インスタンステンプレート」を選択。
1.4 インスタンスグループ作成画面下部
- 「インスタンスグループの作成」画面下部の入力。
- 「自動スケーリング」「自動スケーリングモード」で「自動スケーリングしない」を選択。
- 「インスタンスの最小数」は、「1」。
- 「インスタンスの最大数」は、「1」。
- 「自動修復」は「ヘルスチェックをしない」。
- 「作成」して、次へ。
- 仮に「adminインスタンスグループ」を自動スケーリングしてしまうと、サーバーに負荷がかかった場合、「同一リージョン」に「同一の admin VMインスタンス」が複製されてしまいます。
- 何が問題かというと、WordPressにアクセスはできますが、記事を「投稿」「更新」などを行なった場合において、
「同一の認証鍵」を使用していて全く同一のクローンですから、「GCP」「WordPress」の双方が混乱してしまうようです。その結果として、「CPU使用率」が「800%」とかいう訳のわからない状態になってしまい、「投稿」「更新」のどちらも行なうことができなくなります。 - それゆえ、「自動スケーリングしない」、「VMインスタンス」の「最小数1」「最大数1」とし、「自動スケーリング」させないようにします。
- 慣れてきた時、「自動修復」で「ヘルスチェックする」ようにして、サーバーが落ちたら、再作成されるし安全なんじゃないかと考えて「ヘルスチェックする」を選択してしまったこともあります。
何が起きたかというと、負荷がかかり「admin VMインスタンス」が動作しなくなった時、「adminインスタンステンプレート」を元にして「admin VMインスタンス」の再作成が行われます。新たに編集してきた設定や記事の更新分がすべて消失します。
強制的に負荷をかけてサーバーダウンをさせたことがあります。「ヘルスチェックをしない」に設定をすると更新分が残っていました。ポイントは応答するようになるまで待つというのが最善策だと思います。
1.5 インスタンスグループ作成後の画面
- 画面一番上の行に「tokyo2020-admin-xxxxxxxxxxxxxx」という「admin VMインスタンスグループが作成されているのが確認できます。
「警告マーク」は最低でも3つのゾーンを選択しないと出ます。
1.6 外部IPアドレスを固定
「admin インスタンスグループ」を作成すると新たに「admin VMインスタンス」が作成されます。この「外部IPアドレス」を「エフェメラル」から「静的」に変更して「固定」します。
「admin インスタンスグループ」を作成すると、自動的に「admin VMインスタンス」が作成されるので「外部IPアドレス」の固定は忘れがちです。
- 「メニュー」「VPCネットワーク」「外部IPアドレス」の順にクリック。
- 赤枠の部分が「エフェメラル」になっている箇所を「静的」として「外部IPアドレス」を固定します。
1.7 WinSCP へ固定IPアドレスを入力
「admin VMインスタンス」の「外部IPアドレス」が固定できたら、「WinSCP」を起動します。「第5回」を参考にしてください。
- 「新しいサイト」をクリック。
- 「ホスト名」に「例、34.84.67.43」
「インスタンスグループ作成で自動的に作られた「VMインスタンス」の「固定した外部IPアドレス」を入力。
- ユーザ名は「第5回」で生成した「SSH認証鍵」と同一です。
- 設定をクリックして次へ。
1.8 権限設定
- 「SFTP」をクリック。
- 「SFTPサーバ」に「sudo /usr/lib/openssh/sftp-server」を入力して、次へ。
1.9 SSH認証鍵設定
- 上記画面のまま「認証」をクリック。
- 「第5回」で保存した「例、private-key.ppk」ファイルを選択し、「OK」をクリックして、次へ。
GCP側の「adminインスタンステンプレート」を新しく作成する際、この画面の「公開鍵を表示」をクリックすると、「SSH認証鍵」を表示することができます。間違えて「adminインスタンステンプレート」を先に削除してしまった場合の対処方法としても利用できます。
1.10 設定保存
- 一通り赤枠の部分の入力を確認して、「保存」。
- 「パスワード」は空欄です。「SSH認証鍵」がパスワードの代わりになります。
1.11 WinSCP でWordPressへログイン
- 「ログイン」をクリック。
これは、「adminインスタンスグループ」が正しく作成でき、自動的に作成された「admin VMインスタンス」に「固定したIPアドレス」と「認証鍵」を利用してアクセスできるかどうかの確認です。
1.12 インスタンスグループ設定完了
- 正しくログインができたら、「WinSCP」を通じて「GCPサーバーの中にある WordPress」にアクセスできていて、エクスプローラーのように編集できる画面になります。これで設定が完了です。
2回目以降ログインする際、以前の一時ファイルが残っている場合があります。その際には、「更新」をクリックしてログインします。
次は第7回です。
第7回 【WordPress_ロードバランサー】 GCP で 「admin インスタンスグループ」を利用して、WordPress のロードバランサーを作成する。
【コメント】 ※「メールアドレス不要」