Engine上にオートスケールで拡張するWordPressを構築していく方法を書いていきます。今回は実際にWorePressの設定とオートスケールの構築を行っていきます。仮にデータベースの名前を”wordpress”とした場合...まずは、ログイン。-pDB作成&権限設定。「ぱすわーど」のところは指定したいパスワードを入れてください。privileges;”instance-group-web%”はNFSと同じようにワイルドカードで指定しています。ついでにメンテしやすいようにdbサーバー(localhost)からのアクセスも許可しています。WordPressのインストールWordPressの公式サイトからダウンロードして/var/contents/hoge.com/html配下、つまりngixが読みに行くNFSでマウントしたディレクトに展開してください。インスタンスを見ると”外部IP”のリンクがあるので、クリックしてください。これでWordPressの初期セットアップ画面が出るはずです。ホストとDBとユーザーとパスワードを設定してください。DBとユーザーはさっきの例だと全部”wordpress”ですね。今回、WebサーバーとDBサーバーが分かれているので、dbのホスト名はlocalhostでは駄目です。”db.c.my-project99.internal”のようにDBサーバーのホスト名を指定してください。これでWordPressが立ち上がるはずです。Webコンソールでの作業になります。gcloudコマンドでもできるのですが、まずはUI使った方がわかりやすいと思います。した流れは以下のような感じです。サービスを設定するオートスケールの設定Webサーバーのスナップショット作成さっき作ったWebサーバーのデータをスナップショットとして保存します。“スナップショット”をたどります。上に”新しいスナップショット”のボタンがあるのでクリック。”名前”は適当に、ソースディスクにWebサーバーで使用しているディスクを指定して、”作成”を押すとしばらくするとスナップショットができあがります。スナップショットからディスクを作成スナップショットからディスクを作成します。“ディスク”をたどります。上に”新しいディスク”のボタンがあるのでクリック。“名前”は適当で、ゾーンはサーバーと同じにしておきます。”ソースの種類”を”スナップショット”にして、さきほどのスナップショットを選び、”作成”を押します。するとディスクができあがります。ディスクからイメージ作成ディスクからイメージを作成します。スナップショットから直接イメージできれば早いんですけどね(笑)。“イメージ”をたどります。上に”新しいイメージ”のボタンがあるのでクリック。イメージは今後のことを考えて多少わかりやすい名前がよいかと思います。私はimage-web01みたいな形で更新の度に最後の数字を変えていって、動作が安定したら古いイメージは消しています。説明には「これこれを直したイメージ」みたいなメモを書くと管理しやすいと思います。”ソースディスク”にさきほど作成したディスクを選んで”作成”を押します。今までより時間がかかります。インスタンステンプレートを作成してイメージを指定オートスケールで立ち上げる基になるインスタンスのテンプレートを作ります。テンプレート”をたどります。テンプレート”のボタンがあるのでクリック。マシンタイプに”f1-micro”、ブートディスクから”自分で作成したイメージ”を選び、さっき作ったイメージを指定します。f1-microで非力だと感じたら、ここでマシンタイプを上位のモノにしておけば、それでインスタンスを作成してくれるようになります。グループ”をたどります。グループ”のボタンがあるのでクリック。ここの”名前”が重要です。ランダムな4桁の文字列で名前が決まります(Webコンソールから設定した場合)。名前はNFSやデータベースの接続許可に使われます。”instance-group-web”と入れます。すると自動で作成されるインスタンスは”instance-group-cr3f”などのような名前で作られるため、NFSやDBサーバーに接続ができます。インスタンステンプレートにはさきほど作成したインスタンステンプレートを指定します。”自動スケーリング”は”オン”にします。これがオートスケーリングのスイッチです。これをオンにするとスケーリングの設定が表示されます。CPU使用率60%になっていますが、サーバーのCPU使用率が60%を超えると負荷分散のために自動でサーバーが立ち上がる、という設定です。インスタンスの最大数は何台まで自動で増やすかの設定です。作成を押すとインスタンスグループは完成です。ヘルスチェックを作成ロードバランサの前にヘルスチェックを作りましょうか。これはGoogleの監視システムが定期的にWebサーバーにアクセスして、ちゃんと稼働しているサーバーを判断するための設定です。ロードバランサはこのヘルスチェックで正しく動作していることが確認できたサーバーにのみ処理を割り振ります。ここではリクエストパスの指定が重要になってきます。http://hoge.com/にアクセスして正常応答...つまりHTTPステータスコードで200が返るかを調べるという意味になります。気をつけないといけないのが、うちのサイトのようにhttps://a-tak.comにアクセスするとhttps://a-tak.com/blogにリダイレクトするようなサイトだと、HTTPステータスコードは301をウェブサーバーが返してしまうので、ヘルスチェックは異常を検知し、ロードバランサは処理を割り振りしません。全部のサーバーがこのような状態だと、Webページはまったく見えない状態になります。昨日の昼頃うちのサイトが全滅してたのは、そのせいです(笑)。この場合はリクエストパスに”/blog/index.php”を指定するような形になります。Apacheのデフォルトのテストページもブラウザで見るとページは見えますが、HTTPステータスコードは403が返るので、いつまで経ってもロードバランサ経由でアクセスしてもサイトが見えない状態になります。WordPressがちゃんと動いているということを確認するということでは、ブログのトップページのindex.phpを指定するのが筋ですが、microサーバーは貧弱なので、静的なHTMLを用意してそこをチェックするようにした方がいいかもしれません。ヘルスチェックのアクセスはnginxのaccess_logに”GoogleHC”としてステータスコード付きで残るので、うまく動かないときはアクセスが来ているか、ステータス200を返しているかをチェックしてみてください。あと、補足するとこのヘルスチェックは、設定してから実際に設定が反映するまで、かなり時間がかかります。それこそ5分とか10分とか。アクセスが来ない場合は、しばらく待ってみるか、サイト毎のアクセスログではなくnginxのデフォルトのaccess_logの方に記録が出てないか見てください。バーチャルホストの設定していると、思わぬところにログが出ている場合があります。HTTP負荷分散でロードバランサを作成ロードバランサ自体の設定をしていきます。負荷分散”をたどります。上に”ロードバランサを作成”のボタンがあるのでクリック。すると次の画面に移ります。真ん中あたりの”グローバル転送ルールを追加”をクリック。IPアドレス”を選んで固定IPを取得し、それを選びます。”作成”を押すと元の画面に戻ります。ここで設定したIPにアクセスするとロードバランサーが振り分けの処理をしてくれるようになります。サイトのDNSにもここのIPを指定することになります。サービスを設定する”をクリック。ここではロードバランサーが受けた通信をどのサーバーに振り分けるかを指定します。グループ”を選ぶところがあります。ここにちょっと前に作成したインスタンスグループを指定します。”ヘルスチェック”も先ほど追加したものを指定することをお忘れなく。動作確認これでグローバル転送ルールに指定した外部IPに通信するとWebサーバーのインスタンスに通信がいってWebページが表示されるようになりますが、ヘルスチェックのところに書いたように、ヘルスチェックが開始されるまでタイムラグがあるので、設定変更後はすぐに反映しません。GoogleHCのアクセスがあるまで待ちましょう。アクセスが着始めて無事HTTP200を返し始めたら、Webページも表示されるようになります。駄目だったら、ヘルスチェックのところに書いた内容をチェックしてみましょう。オートスケールで作成されるサーバーのイメージを変更するオートスケールは便利で素敵なんですが、難点としては必ずイメージを元に作成されるので、OSのアップデートやnginxの設定を変更した場合は、イメージを作り直す必要があるということです。だいたいこんな手順でやります。Webサーバーのスナップショット作成スナップショットからディスクを作成ディスクからイメージ作成インスタンステンプレートで「instance-template-web」をコピーして「instance-template-web-1」を作成。イメージは先ほど作ったものを指定。instance-group-web」を編集してテンプレートに「instance-template-web-1」を指定gcloudコマンドで起動しているインスタンスを再作成イメージを再作成して、インスタンステンプレートを作って、インスタンスグループに適用する感じですね。起動しているインスタンスには変更は反映されないのでgcloudコマンドでインスタンスを再作成するという流れです。インスタンステンプレートをコピーして元のテンプレートを残しているのは、何か問題があったときに元のテンプレートに戻せるようにするためです。インスタンスの再作成は、こんな感じのコマンドで行います。instance-group-web-abcd↓こういう意味です。再作成するインスタンス名Webコンソールでもインスタンスグループのインスタンステンプレートを変更しようとするとgcloudコマンドの例を教えてくれるのですが、その例が間違ってる(たぶん古い仕様)ので、上の例を元にコマンドたたいてください。あと、再作成中はそのインスタンスは通信受け付けられないので、再作成は少しずつ実行しないとだめです。全部再作成始めちゃうと、これまたWeb全滅しますから。こんな感じで地味に面倒なので、このあたりのイメージ再作成はWebコンソールではなくgcloudのコマンドを使ったスクリプト処理でできるようにしておきたいですね。個人で簡単に超並列処理サーバーが立てられる時代とりあえずやってみましたが、個人のブログではここまで必要ないですね(笑)。イメージ再作成とか運用がめんどくさい。あと、設定がよくないのかWordPressにプラグイン詰め込みすぎているのか、WordPressの管理画面にアクセスすると負荷が上がって、インスタンスが一気に作成され始めます。AmazonEC2のmicroも似たような感じだったから元々こういうモノなのかもしれませんが。場合によってはもう一段上のサーバーにした方が、パフォーマンス的にもコスト的にも良いかもしれません。この構成で運用して見てみようかと思います。個人でオートスケール構成のサーバー群を構築できるとは、とんでもない時代になりましたね。[追記]オートスケールだとサーバーが勝手に消えていくので、ログも消失しますね。syslogサーバー立てて、そこにログは飛ばさないといけないですね。Apple野郎なおっさんでしたが、ちょっと最近のAppleには飽き気味。A-tak.comは2002年2月から運営(前身のサイトは1999年3月から)。コメントをキャンセルメールアドレスが公開されることはありません。*サイト上に表示された文字を入力してください。コメントデータの処理方法の詳細はこちらをご覧ください。このサイトの使用を継続することで、その使用に同意したとみなされます。コントロール方法を含む詳細についてはこちらをご覧ください。