Azure Kubernetes Serviceで実現する超低予算&(ほぼ)フルマネージド&本格的なWordPress環境

こんにちは、サイオステクノロジー技術部 武井(Twitter:@noriyukitakei)です。今回は、超低予算で実現する本格的WordPress環境 on Azure Kubernetes Serviceについてお話したいと思います。

実はこの記事が公開される日に、今回ご紹介するWordPress on Azure Kubernetes Service環境にこのブログを移行しております。

今回ご紹介するのは、その名の通り、WordPressをAzure Kubernetes Service上で構築しました。そしてなるべくたくさんの機能を低予算で実現してみました。

では早速システム構成からご説明致します。

システム構成

今回構築したシステムの構成図は以下のとおりです(図が細かいのでクリックして拡大して見てください)。

弊社は以下の2つのブログを運用しており、今回この2つのブログを移行する必要がありました。

以前はそれぞれ別々のVirtual Machineで稼働していましたが、今回一つのKubernetesクラスターに統合しました。

構成をざっくりご説明しますと、フロントエンド用Node、バックエンド用Nodeと言われるNodeがそれぞれ2台ずつあり、NGINX IngressでL7ロードバランシングしています。フロントエンド用Nodeには負荷の低い静的HTML参照の処理を格安のBシリーズのVMで、バックエンド用Nodeには負荷の高い管理画面系の処理をFシリーズのコンピュート優先のちょっとお高めのVMで処理しています。メールの送信にはSendGrid、画像やプラグインなどのコンテンツ保存にはNFS Server on VM、データベースにはAzure Database for MySQLを使っております。ご覧のとおり、(ほぼ)フルマネージドな環境となっております。

では、それぞれの機能を詳細にご説明してまいります。

Azure kubernetes Service

言わずとしれた、Azureが提供するKubernetesのマネージドサービです。今回は2つのノードプールを作成し、それぞれフロントエンド用Node、バックエンド用Nodeと呼ばれるものがプール内で稼働しております。

フロントエンド用Nodeは静的なHTML参照などの負荷の低い処理を行います。今回、WordPressのプラグインの一つである「WP Super Cache」というものを使っており、一度ユーザーが参照したものは次回からは静的なHTMLを参照するようにしております。これは比較的負荷の軽い処理であり、これをフロントエンド用Nodeが担当します。このNodeにはBシリーズといわれる、あんまり性能は高くないけど安いVMを使っています。正確なインスタンスサイズはB2sであり、2020年1月9日現在(東日本リージョン)のお値段は、4,538円/月です。

バックエンド用Nodeは、管理画面でブログを作成する処理を担当します。これはPHPで動作しますので、比較的処理が重いものであり、このNodeには、ちょっとお高めだけど高性能なFシリーズのVMを使っております。正確なインスタンスサイズはF2s_v2であり、2020年1月9日現在(東日本リージョン)のお値段は、8,928円です。

フロントエンド用Node、バックエンド用Nodeの振り分けはL7ロードバランサーであるNGINX Ingressで行い、URLで振り分けをしております。/wp-admin(管理画面のロケーション)以下のアクセスはバックエンド用Node、それ以外はフロントエンド用Nodeに振り分けています。ついでにNGINX IngressでSSLの終端も行っています。

NGINX Ingress用のPodはフロントエンド用Nodeにそれぞれ1台ずつ配置されており、その前段にAzure Load Balancerが稼働しており、2台のNGINX Ingress用のPodにL4でロードバランシングしています。こちらについての詳細はAzure Kubernetes ServiceでNGINX Ingressによる負荷分散というブログに記載しております。

Azure Container Registry

Azureが提供するDockerイメージ用のプライベートリポジトリです。もちろんマネージドサービです。今回、Docker Hubで提供されているWordPressの公式イメージをそのまま使いたかったのですが、若干修正しなければいけないところがあり、その修正したイメージをAzure Container Registryに格納しております。

NFS Server on VM

WordPressの画像やプラグインは動的に変化するコンテンツですので、何らかの共有ストレージに格納して各Podから参照させる必要があります。

Azure Kubernetes Serviceで利用できるものは以下の3つがあります。

  1. Azure Files → 詳細はこちら
  2. VM上に立てたNFS Server → 詳細はこちら
  3. Azure NetApp Files → 詳細はこちら

最初は1を試しました。Azure Filesは、Azureで利用できるマネージドなファイルサーバーであり、SMBプロトコルを介して通信できます。なので、Windowsからでも簡単にマウント出来て非常に便利です。マネージドなので、仮想マシンにsambaサーバー立てたときのように、面倒くさい管理も不要です。

が、Azure Filesを使ったらなぜかWordPressが激オソになりました。どうやら大量の細かいPHPファイルを読み込むのに時間がかかっていたようです。SMBというプロトコルのせいもあるのでしょうか?1ページ読み込むのに8秒くらいかかっていたので、使いものにならなく断念しました。

次に2を試しました。言わずとしれたNFSです。これで激オソが解消されて、激ハヤになりました。プロトコルの違いなのか、それとも他に原因があるのか、詳細はわかってはいないのですが、ほっと胸をなでおろしましたε-(´∀`*)ホッ

しかし、やっぱり今の時代VM使ったら負けみたいな風潮もあるようなないような感じですし、他にマネージドなストレージサービスないかなーと探していたところ、3に行き着きました。東日本リージョンで使える様になったのはつい最近のことらしいので、マジでいいタイミングでした。ただし、めちゃくちゃ料金が高いです(T_T)こんなの払いきれません。

ということで結局2に落ち着きました。これが、「タイトルの(ほぼ)フルマネージド」の「ほぼ」が取れない所以です。ここもマネージドにできたら完璧だったのにー。

このストレージには、SIOS Tech.lab (https://tech-lab.sios.jp/)とOSS on Azure (https://azure.sios.jp/)の2つのブログのコンテンツを格納して、それぞれのPodからマウントしています。図にしますと以下のようになります。

 

WordPressは画像などのコンテンツはwp-contentディレクトリに格納する仕様になっています。今回は2つのブログがあるので、NFS Server on VM上に作成しがボリュームにtechlab、ossonazという2つのディレクトリを作成して、SIOS Tech.lab (https://tech-lab.sios.jp/)用のPod、OSS on Azure (https://azure.sios.jp/)用のPodからそれぞれをNFSマウントします。

VMのインスタンスサイズはB2sにしておりまして、2020年1月9日現在(東日本リージョン)のお値段は、4,129円/月くらいになります。

Azure Database for MySQL

言わずと知れた、Azureが提供するMySQLのマネージドなサービスです。WordPress用のデータベースとして使っています。ユーザーのブログ参照は先程ご説明したようにキャッシュプラグインを使いますので、静的なHTMLにアクセスすることになります。つまりデータベースへのアクセスが発生するのは管理画面での作業のみです。おそらくあんまりデータベースへのアクセスは発生しません。よって、一番価格の低いBasicの1 vCoreにしております。お値段は、4337円/月です。

Azure Database for MySQLの中には2つのデータベースを構築しており、それぞれSIOS Tech.lab (https://tech-lab.sios.jp/)用とOSS on Azure (https://azure.sios.jp/)用になります。

SendGrid

Azureが提供するメール送信のためのマネージドサービです。Freeでも25,000通/月のメールが送れますので、Freeにしています。なので、お値段は0円です。

構築しよう!!

先程ご紹介した環境の構築方法をご説明致します。今後の手順でご紹介するリソースグループ名を始めとした各種名称は、適宜、ご自身の環境に合わせて修正してくださいませ。

Azure Container Registryの構築

まずはKubernetesがコンテナを作成するためのイメージを持ってくるレジストリを作成します。通常はDockerHubなどの公開レポジトリを使うのではなく、クローズドなレポジトリを使います。Azure Container Registryはそんなクローズドなレポジトリを提供してくれます。

Azureポータルにアクセスして、「リソースの作成」をクリックします。

Screen Shot 2019-11-21 at 21.26.30

 

「container」と入力すると、「Container Registry」が表示されますので、それをクリックします。

Screen Shot 2019-11-21 at 21.28.01

 

「作成」をクリックします。

Screen Shot 2019-11-21 at 21.29.43

 

「レジストリ名」はレジストリを一意に識別する任意の名称を入力します。後ほどこの値は、レジストリのホスト名の一部になりますので、よく考えて変な名前をつけないようにしましょう。「管理者ユーザー」は有効にしておいて下さい。詳細は後ほど説明します。SKUはとりあえず「Standard」にして下さい。後は、環境に合わせて適宜入力して、最後に「作成」をクリックします。

Screen Shot 2019-11-21 at 21.32.15

 

Azure Container Registryのリソースの作成が完了したら、左部メニューの「アクセスキー」をクリックして、「ログインサーバー」「ユーザー名」「パスワード(2つあるうちのいずれか)」をメモして下さい。ちなみにこのユーザーはテスト用に利用する管理用ユーザーです。本番用途では別途サービスプリンシパルを作成して、適切な権限(Azure Container Registryへの読み取り権限のみ)を割り当てて下さい。

Screen Shot 2019-11-21 at 21.37.12

Azure Kubernetes Serviceの構築

では、いよいよAzure Kubernetes Serviceの構築です。

Azureポータルにアクセスして、「リソースの作成」をクリックします。

Screen Shot 2019-11-21 at 21.26.30

 

「Kubernetes」と入力すると「Kubernetes Service」が表示されますので、クリックします。

Screen Shot 2019-11-21 at 21.42.16

 

「作成」をクリックします。

Screen Shot 2019-11-21 at 21.46.10

 

「クラスター名」はKubernetesクラスターを一意に識別する任意の名称を入力して下さい。「ノードサイズ」は、コンテナが稼働するNodeの仮想マシンのサイズです。なるべくサイズの小さいのを選んでおいたほうがお財布に優しいです。検証用ですし。後はご自分の環境に合わせて適宜入力して、最後に「確認および作成」をクリックします。

Screen Shot 2019-11-21 at 21.48.29

 

入力項目を確認して「作成」をクリックします。しばらくかかるので、気長に待ちましょう。

Screen Shot 2019-11-21 at 21.49.25

 

kubectlコマンドをインストールします。その前にまず、Azure CLIをインストールしましょう。Macを想定しております。他の環境はここを参考にインストールしてくらはい。

次にkubectlをインストールします。

kubectlコマンドを動かすための認証情報を作成します。noriaksはAzure Kubernetes Serviceを作成したリソースグループ、norichan-aksはKubernetesクラスター名です。

これで準備は整いました。

ノードプールの追加

フロントエンド用Nodeはキャッシュされた静的なHTMLを処理するだけですので低価格のVMで、バックエンド用Nodeは管理画面での投稿処理などの高負荷な処理を行うので高価格・高性能なVMを使うと先程ご説明致しました。

ノードごとのインスタンスサイズの使い分けはAzure Kubernetes Serviceのノードプールという機能を使います。ノードプール単位でVMのインスタンスサイズを指定することが出来ます。イメージとしては以下の図みたいな感じです。

まず、Azure Kubernetes Serviceのポータルのトップ画面の左部メニューで「ノードプール」をクリックします。

 

「ノードプールの追加」をクリックします。

 

「ノードプール名」に任意の名称、「OSの種類」はLinux、「Kubernetesバージョン」は現時点の最新のもの、「ノードサイズ」はF2s_v2、「ノード数」は2として、「追加」をクリックします。

 

しばらくするとノードが以下のように追加されていることが確認できると思います。

Azure Database for MySQLの構築

Azureポータルにアクセスして、「リソースの作成」をクリックします。

Screen Shot 2019-11-21 at 21.26.30

 

「Azure Database for MySQL」と入力してエンターを押します。

 

「作成」をクリックします。

 

サブスクリプション、リソースグループはご利用の環境に応じたものを入力します。「サーバー名」はMySQLのホスト名の一部になりますので、慎重に考えてください^^;「管理者ユーザー名」「パスワード」はそのままMySQLのユーザー名とパスワードになります。「場所」はご利用の環境に近いところ、「バージョン」は5.7を選択してください。そして、「サーバーの構成」をクリックしてください。

 

「Basic」のタブをクリックしてvCoreを1にしてください。その他は以下のようにデフォルトのままで「OK」をクリックしてください。

 

先程の画面に戻りますので、「確認および作成」をクリックしてください。

 

「作成」をクリックして、しばらくすれば完了です\(^o^)/

SendGridの構築

Azureポータルにアクセスして、「リソースの作成」をクリックします。

Screen Shot 2019-11-21 at 21.26.30

 

「SendGrid」と入力してエンターを押します。

 

「作成」をクリックします。

 

サブスクリプション、リソースグループ、場所はご利用の環境に応じたものを入力します。「Name」「Password」はSendGridポータルへのログインIDとパスワードになります。「Pricing Tier」は「Free」を選択してください。「Contact details」は名前や会社名などを入力してください。最後に「Review + Create」をクリックします。

 

内容を確認して「Create」をクリックすれば完了です\(^o^)/

 

WordPressのDockerイメージの修正

今回の構築に用いるWordPressのDockerイメージは以下のような構成になっております。

今回はwp-content配下をNFS Server on VMにマウントする予定なのですが、どうやらWordPressのDockerイメージは、Docker起動時に実行されるエントリポイントdocker-entrypoint.shにより、wp-content配下にあるいくつかのプラグインやPHPファイルを上書きしてしまうということが発覚しました。docker-entrypoint.sh実行よりも、wp-contentへのNFS Server on VMのマウントを遅らせることができればいいのですが、そんなことはできそうもないので、docker-entrypoint.shを書き換えることとしました。

 

ソースコードを読んでいると、どうやらDockerfileによって/usr/src/wordpress配下に解凍されたWordPress本体を、/var/www/htmlに展開し直しているようです。それを行っているのが15行目です。なので15行目で展開される前にwp-content配下のファイルをすべて消してしまえばいいのです。

 

なので、16行目を追加しました。

 

こちらでDockerイメージを作成し直して、Azure Container Registryへプッシュします。

NFS Server on VMの構築

VM上にNFS Serverを構築します。VMの構築の仕方は割愛します。ほぼ、Azure Kubernetes Serviceでの共有ストレージ(NFS Server on VM編)のブログに記載のとおりに構築しております。

基本的に以下のコマンドを実行すると、NFS Serverが一発でインストール出来ます。引数を3つ取りますが、3つ目の引数はNFSサーバーを公開するサブネットを指定します。特に指定しなければ、全てのサブネットに対して公開されますが、絞りたい場合は、AKSのノードが配置されているサブネットを指定して下さい。

PersistentVolumeリソースの作成

PersistentVolumeのマニフェストを以下のように作成します。

 

適用します。

PersistentVolumeClaimリソースの作成

PersistentVolumeClaimのマニフェストを以下のように作成します。

 

適用します。

ヘルスチェックスクリプトの作成

Kubernetesの死活監視(LivenessProbe&ReadinessProbe)のためにヘルスチェックスクリプトを作成します。WordPressはMySQLに接続できないと機能しないので、ヘルスチェックにはMySQLに対して簡単なクエリを投げて成功すれば200、失敗すれば500のHTTPステータスコードを返すようにします。

完成したらwp-contentディレクトリ直下に配置します。

Sercretリソースの作成

WordPressの設定に必要な項目の中で、「データベースへ接続するパスワード」「各種SALT値」を格納したSecretリソースを作成します。

 

適用します。

Nodeにラベルを付与

フロントエンド用Node、バックエンド用NodeにそれぞれWordPress用のPodを1個ずつ割り当てます。そのためにAffinityを使います。Nodeにラベルを付与して、Podをデプロイするときに特定のラベルが付与されたNodeにスケジューリングするようにします。

まずNodeの情報を取得します。下記のように4つのNodeが表示されます。

 

フロントエンド用Nodeにuser、バックエンド用Nodeにadminというラベルを付与します。

Deploymentリソースの作成

SIOS Tech.lab (https://tech-lab.sios.jp/)のブログページ(下図(1))と管理画面(下図(3))、OSS on Azure (https://azure.sios.jp/)のブログページ(下図(2)と管理画面(下図(4))を構成するDeploymentリソースを作成する必要があります。

 

 

まず(1)SIOS Tech.lab (https://tech-lab.sios.jp/)のブログページを作成するためのマニフェストを以下のように定義します。

 

次に(3)SIOS Tech.lab (https://tech-lab.sios.jp/)の管理画面を作成するためのマニフェストを以下のように定義します。

 

次に(2)OSS on Azure (https://azure.sios.jp/)のブログページを作成するためのマニフェストを以下のように定義します。

 

次に(4)OSS on Azure (https://azure.sios.jp/)の管理画面を作成するためのマニフェストを以下のように定義します。

 

作成したマニフェストを適用します。

NGINX Ingressの作成

NGINX Ingressを作成します。基本的には「Azure Kubernetes ServiceでNGINX Ingressによる負荷分散」でご紹介したとおりに進めます。

まずAzure Load Balancerに割り当てるパブリックIPアドレスを作成します。

 

次にHelmをインストールします。ワタクシMacな環境なのでMac前提にお話します。バージョン3からTillerがいらなくなりました。やった(^o^)

 

Helmの公式レポジトリを追加します。

 

次にNGINX IngressのPodを格納するNamespaceを作成します。

 

HelmでNGINX Ingressを作成します。

–set controller.replicaCount=2は、NGINX IngressのPodを何個作るかを指定します。必ず2個以上として下さい。1個しか作らないと、万が一そのPodが落ちると、サービスがダウンしてしまいます。

 

Serviceを見てみます。

nginx-ingress-1577021421-controllerは先程の図のAzure Load Balancerのリソースです。もう一つのnginx-nginx-ingress-1577021421-default-backendは、後述する負荷分散ルールを定義するマニフェストに定義したパスのどれにも該当しないときに振られるService(ClusterIP)です。Load BalancerにグローバルIPアドレスが割り当てられているのがわかります。このIPアドレスを外部DNSサービスにAレコードとして登録して下さい。

次にNodePortとして公開します(必要なのはClusterIPだけなので、なぜNodePortが必要なのか不明ですが、公式のマニュアルにもそう書いてあります)。SIOS Tech.lab (https://tech-lab.sios.jp/)のブログページと管理画面、OSS on Azure (https://azure.sios.jp/)のブログページと管理画面の合計4つのNodePortを作成します。以下のマニフェストを作成します。

 

作成したマニフェストを適用します。

 

IngressでSSL終端するための証明書と秘密鍵を格納します。server.crtを証明書、server.keyを秘密鍵とします。

 

以下のマニフェストを作成します。Ingressによる負荷分散ルールを定義するためのものです。ingress.ymlというファイル名で保存します。

 

デプロイします。

データ移行

旧WordPressから新WordPressにデータ移行を行う必要があります。本記事の本質ではないので詳細は割愛させていただきますが、以下の2つのデータを移行するのみで基本的にはOKです。

  • wp-contentディレクトリ配下のファイル
  • MySQLのデータベース

WordPressのバージョンアップも今回行ったので、幾つか動かないプラグインもありましたが、、、。

動作確認

SIOS Tech.lab (https://tech-lab.sios.jp/)、OSS on Azure (https://azure.sios.jp/)にアクセスしたら、きちんと表示されました(^o^)管理画面の動作もバッチリでした。

気になるお値段は?

月額のAzure使用料は以下の通りとなります。

フロントエンド用Node 9,076円/月 (4,538円/月 × 2)
バックエンド用Node 17,856円/月 (8,928円/月 × 2)
Azure Database for MySQL 4,337円/月
NFS Server on VM 4,129円/月
合計 35,398円/月

これだけの本格的なクラスターで、たったこれだけのお値段って安いですよね\(^o^)/

まとめ

Azure Kubernetes Serviceすごいですね。これだけの本格的なクラスタを(ほぼ)フルマネージドで構築できるんです。No Azure Kubernetes Service、No Life!!ヮ(゚д゚)ォ!

>> 雑誌等の執筆依頼を受付しております。
   ご希望の方はお気軽にお問い合わせください!

ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

2人がこの投稿は役に立ったと言っています。

コメント投稿

メールアドレスは表示されません。


*