1. 第22回 【WordPress】 GCP Google Cloud Storageのバケット作成と権限の設定方法
環境:Debian 9 php 7.0 Apache 2.4.25 MySQL 5.7 Cocoon
目的:「WordPress」のメディアを「Google Cloud Storage」から配信する準備
今回は、「第22回」の部分です。「Google Cloud Storage」は、「Amazon AWS」でいうところの「S3」(Amazon Simple Storage Service)です。
「WordPress」のメディアファイルを「WordPress本体」のサーバーではなく「Google Cloud Storage」から配信することによって「WordPress本体」の負荷を軽減させることができます。
私の解釈ですが、
「Google Cloud Storage」から画像を配信する場合、貧弱なサーバーであっても、鮮明で高画質な画像を配信することができるものと考えています。
まだまだ、先の話ではありますが「5G」が普及した時、どのような世界が広がっているか、勝手に想像してみます。少し昔を振り返りながら。
- ポケットベル:7文字(14数字)
- ポケットベル:9文字(18数字)
- ポケットベル:11文字(22数字)
固定電話からポケットベルへ送信できる文字が「1,2文字」増えただけで、革命が起きたような空気感があった時代。「ポケベル用語」で検索すれば分かりますが、今の人には解読できないような数列が並んでいました。
「11,12文字の送信ができるようになったあたりから「PHSと携帯電話」が普及し始めました。その当時、「繋がらないから必要ない」と言われていました。「お前、バリ3?」そんな会話が普通。
当時はこんな感じじゃなかったかな。
- 家電からかけるからすぐ取って(家電から携帯だと料金が高い)
- 待ち合わせでイライラしなくなった
- 出先で色々調べられるようになった
そこへ、スマートフォン登場。
ガラケーと比べて、フリーズした。
- スマートフォンにしてみたんだけど固まる
- スマートフォンなのに圏外になる
- 段々と機種も充実し始め、課金ゲーム時代到来。
「4G」登場。
快適だけど、既読スルー。
- アプリ
- 検索
- 地図
「動画」を見るにしても問題ないし「5G」いらないんじゃないかな。通信料金下がるのかな。
既読スルーは変わらず。女性が言う「今度ね。」に今度はないんだと早く気づいてほしい。
- 映画、ドラマ、アニメ、ゲーム
- グラフィック表示がどこまで進化するのか
- 少なくとも通信量の上限に引っかかっている人には恩恵がある。
この先、どうなっているか、生きていたら分かるかな。
一つ言えるとしたら、通信量が増え便利になったがゆえ、奥ゆかしい感情が少し減った感覚があります。
「Google Cloud Storage」に話を戻します。
昔を振り返れば、「5G」時代が到来した際には、画像や動画の通信量なんてものだって、微々たる差にすぎなくなるように思います。でも、コンテンツを充実させるメディアファイルは鮮明な画像でファイルサイズは大きくなり、WordPress本体への負荷は多くなることは間違いないことかと思います。
そこで、メディアファイルを別の場所から配信してしまえば、WordPress本体への負荷を軽減させることができてWordPress本体が軽くなります。「画像ファイルを軽くしたから検索の上位に表示されますよ」なんていうのは過去の話になっていきそうです。
再度ですが、今回は、「第22回」の部分です。
- 気持ちいいほどに「メディアファイル」を管理することができるようになります。
- 「WordPress」本体に負担をかけることなく、「Google Cloud Storage」から配信できるようになります。
- 「PageSpeed Insights」の「次世代フォーマットでの画像の配信」「webp」ファイルで配信ができるようになります。
- 第20回 WordPressプラグイン 「EWWW Image Optimizer」
- 第21回 WordPressプラグイン 「Media Library Folders for WordPress」
- 第22回 GCP 「Google Cloud Storage」のバケット作成と権限の設定方法
- 第23回 WordPressプラグイン 「WP-Stateless」と「GCS」を連携させ、メディアファイルをGCSから配信させる方法
- 第24回 今まで設定したメディアファイル連携やhttps設定を行うとどうなるか、ついでにサイトアイコン変更
「Google Cloud Storage」設定
- GCPGoogle Cloud Storage
バケットの作成
- GSCGoogle Search Console
ドメイン所有権の確認
- GCPGoogle Cloud Storage
バケットの作成
- GCPGoogle Cloud Storage
権限設定
1.1 Google Cloud Storage 設定画面
- 「GCP」「Storage」「ブラウザ」の順番にクリックして「Google Cloud Storage」設定画面へ遷移します。
- 上部の「バケットを作成」をクリックして、次へ進みます。
1.2 バケット名
- 「バケット名」:任意ですが、「ドメイン所有権の確認」の手順は省きません。
「例、gcs.tohyo2020.org」
「独自ドメインのサブドメイン」で設定します。
- 「②の詳細」を新しいタブで開いて、次へ進みます。
「独自ドメイン」と「適当な名前」の違い。
「ロードバランサー」を利用すると顕著にわかります。
ロードバランサーを利用していない「投票2020」、このWebサイトの場合。
「例、サイトアイコン(ファビコン)」を表示すると、
- 「Google Cloud Storage」のサイトアイコンで配信。
- 「例、https://storage.googleapis.com/gcs.tohyo2020.org/media/polling2020_icon.png」
「バケット名の前に、「Google Cloud Storage」専用のURLが付きます。
ロードバランサーを利用した「Tokyo2020 unofficial 非公式」の場合。
「例、サイトアイコン(ファビコン)」を表示すると、
- 「独自」のサイトアイコンで配信。
- 「例、」
「バケット名の前に、「Google Cloud Storage」専用のURLが付きません。
ロードバランサーを利用すると「Google管理の証明書(SSL/TLS)」は✔するだけで自動更新の証明書が作成できます。URLの左側にある鍵マークをクリックすると、証明書が異なることも確認できます。
1.3 ドメイン所有権の確認
のちに「Google Search Console」には登録することになるので、ドメイン所有権の確認はしておいて損はないと思います。
- 「Google Search Console」を開きます。
1.4 「Google Search Console」でドメイン所有権の確認
- 「独自ドメイン」を入力して「続行」をクリックして、次へ進みます。
1.5 「Google Domains」は自動確認
- 「所有権を自動確認しました」
「Google Domains」を利用していると予期せぬメリットに巡り会います。
1.6 「Google Domains」以外の確認方法
- 上の赤枠「自動確認」の下の枠を開きます。
- 下の赤枠「2」に表示されているコードをコピーします。自分が利用しているWebサーバーに
- 自分が利用しているWebサーバーの「DNS設定」で、「TXTレコード」を追加します。「コピーしたコード」を
- 「TXTレコード」に「コピーしたコード」を貼り付けます。
- 下記画面に戻り「確認」をクリックして、「ドメイン所有権」を確認します。
1.7 バケット名の作成完了
- 「続行」をクリックして、次へ進みます。
1.8 データ保存場所の選択
- 「ロケーションタイプ」を選択して、次へ進みます。
- 「ロケーションタイプ」をどれにしたら良いか迷った時は、「詳細」をクリックして、料金体系を見ると判断しやすいと思います。
「Google Cloud Storage」料金の比較(GB 単位/月)
- Standard Storage $0.026
- Nearline Storage $0.010
- Coldline Storage $0.007
- Archive Storage $0.004
- Standard Storage $0.023
- Nearline Storage $0.016
- Coldline Storage $0.006
- Archive Storage $0.0025
- なぜか一番長い期間にアクセスされそうな「Nearline Storage」が、「東京単一リージョン」より「アジアマルチリージョン」の方が安いんですよね。
- 「ライフサイクルルールの設定」によっても選択が異なると思いますので、最後まで見ていただいてから選択したほうが良いと思います。
1.9 ストレージクラスの選択
- 「Standard」を選択して、次へ進みます。
1.10 認証情報を作成
- 「きめ細かい管理」を選択して、次へ進みます。
個人的にはどちらでも良いと思います。法人で大規模であれば別だと思いますけど。
1.11 バケットの作成完了
- オブジェクトへのアクセス制御は、初期設定で「Googleが管理する鍵」になっているので、そのまま「作成」ボタンを押して、次へ進みます。
1.12 権限設定
この権限設定では、一般に公開するために、すべてのユーザーがアクセスできるように設定を行ないます。
- 「権限」タブに移動し「メンバーを追加」をクリックして、次へ進みます。
1.13 メンバーを追加
- 「メンバーを追加」をクリックすると、右側から設定画面がスライドしてきます。
- 「新しいメンバー」に「a」を入力すると、候補に「allUsers」が出てくるので、クリックします。
- 「+別のロールを追加」をクリックして、次へ進みます。
1.14 「API を呼び出す場所」の選択
- 「Cloud Storage」にマウスを合わせます。
- 「ストレージオブジェクト閲覧者」にマウスを合わせます。
- 最後に出てきた「ストレージオブジェクト閲覧者」をクリックして、次へ進みます。
1.15 GCSのアクセス権
- 「ストレージオブジェクト閲覧者」の選択ができたら、「保存」ボタンをクリックして、次へ進みます。
1.16 一般公開
- 「保存」をクリックすると、下記画面が表示されます。
- 「一般公開アクセスを許可」をクリックして、次へ進みます。
1.17 「権限」タブ
- 「allUsers」が「ストレージオブジェクト閲覧者」として追加されています。
1.18 ライフサイクルルール設定
- 初期設定でストレージクラス「Standard」が設定されていますが、このままだと「Standard」の料金がかかります。
- ストレージクラスを変更する期間を設定します。
- 「ライフサイクルルールを追加」をクリックして、次へ進みます。
1.19 オブジェクト条件の選択
- 「年齢」を選択し、「30日」と入力して、次へ進みます。
アップロード後に、どのくらい経過したら、という設定です。
1.20 ストレージクラスの選択
- 「Nearline に設定」を選択して、「次へ」ボタンをクリックします。
1.21 ライフサイクルルールの確認
- 「30日以上経過」「Nearline に設定」にできていたら「保存」ボタンをクリックして、ライフサイクルルールを追加します。
1.22 2つ目のライフサイクルルール
さらに、アップロード後に、どのくらい経過したら、という設定を追加します。上記では「30日後」としていましたが、もっと前の「メディアファイル」はアクセスが頻繁ではないはずなので「365日後」の設定を行ないます。
- 「年齢」を選択、「365日」を入力して、「次へ」ボタンをクリックします。
1.23 2つ目のストレージクラスを選択
- 「Coledline に設定」を選択して、「次へ」ボタンをクリックします。
1.24 ライフサイクルルールの確認
- 「365日以上経過」「Coledline に設定」ができていたら、「保存」ボタンをクリックして、2つ目のライフサイクルルールを追加します。
1.25 ライフサイクルルール画面
- ライフサイクルルールが追加された画面です。
- 2020年7月時点では、再度「Storage」にアクセスし、「バケットロック」タブに移動しても、設定したはずのライフサイクルルールが表示されません。
- ライフサイクルルールを確認するには、「バケットロック」「ライフサイクルルールを追加」「キャンセル」の順番にクリックします。
- 「設定されているライフサイクルルール」を確認することができます。
1.26 「Storage」画面
「GCP」「Storage」「ブラウザ」の順番にクリックすると下記画面が表示されます。
- バケットの作成が完了
- すべての人に一般公開
- どのくらい経過したら、どのストレージクラスで配信するか
こういったことの設定が確認できます。
1.27 さいごに
「適当なバケット名」で設定を紹介されているサイトを見ますが、そこまでの手間はかからないので、「サブドメインでのバケット名」で作成することをお勧めします。
それは、「ロードバランサーの方が管理が楽だな」と思った瞬間、「サブドメインで作成していなかったから、Googleが管理する証明書にすることができない」ということが発生してしまうからです。
いつでもロードバランサーを快適に利用できるようにしておいた方が何かと便利なような気がします。
【コメント】 ※「メールアドレス不要」