こんにちは、サイオステクノロジー武井です。流行りのタイトルを付けてみました。
AzureでWordPressを構築する際に、何を使って構築しようか悩みますよね。仮想マシン、Azure App Service、Azure Kubernetes Service、、、色々あります。今回はその用途別にメリデリをダラダラ語ろうかと思います。主観も含まれているかと思いますのでアシカラズ。
目次
仮想マシン
まず仮想マシンですが、性能は問題ないですが耐障害性や管理面で他と劣ります。
他のマネージドなサービス(Azure App ServiceやAzure Kubernetes Service)と比べて、もちろん、OS周りの面倒を見なければいけないので、色々と手間がかかります。
耐障害性という観点でもちょっと面倒かもしれません。冗長構成を作るとなると、自分でAzure Load BalancerやApplication Gatewayなどの負荷分散の仕組みを構築しなければなりません。
後に話しますが、WordPressで大事なストレージにおいては、WordPressに必須であるNFSのストレージをマウントできますし、そのあたりは問題ないかなぁと。
でもやっぱりめんどくさいですよね。今ならもっと簡単でナウいマネージドなサービスがあるので、そっちを使いたいところです。
Azure App Service
結論から申し上げますと本格的なWordPressを運用するには厳しいところです。
Azure App Serviceは、アプリケーションを実行するPaaSな環境で、ビルドしたものをFTPなりGitなりでアップロードするだけで、サクッとアプリが動きます。OSやアプリケーションサーバーが全てマネージドになっているのでラクチンです。
動作するランタイムは豊富で、もちろんPHPもあるのでWordPressを動作させるのにモッテコイな感じかと思いますが、問題なのはストレージです。
WordPressはアップロードした画像、インストールしたプラグイン、テーマなどを全てストレージで管理します。もちろん、Azure App Serviceで運用する場合はそれらを何らかの共有ストレージにホストしなければなりません。Azure App Service自体はエフェメラルなので、スケールイン・スケールアウトなどでAzure App Serviceの腹の中に持っているファイルは消えてしまうからです。
となると、問題はそのプロトコルです。Azure App Serviceでサポートされているストレージは、BlobとAzure Files(CIFS)です。スケールアウトをしないという前提であればBlobでもいいかなと思いましたが、Blobは今年の2月より読み取り専用となってしまったようで、これは使えません。
というと、残る選択肢はAzure Filesのわけですが、これはちょっと使えないのです。というのは、WordPressはその特性上、非常に小さい大量のファイルを読み込む必要があります。大半はインストールしたプラグインです。プラグインは、ユーザーが必要に応じて出したり入れたりするので、共有ストレージに格納する必要があります。よってAzure Filesに格納するわけですが、CIFSというプロトコルは大量の小さいファイルを読み込むのが超苦手です。
最初は早いのですがプラグインを10個くらい入れるとだんだん遅くなり、20個超えたあたりでレスポンスがなかなか帰ってこなくなります。体感的には10秒以上かかる感じです。うーん。
これを解決するのがNFSのストレージです。NFSはプロトコルによるオーバーヘッドが少ないので、大量の小さいファイルも高速で読み込むことができるみたいです。ただし、Azure App ServiceからはNFSのストレージをマウントすることができません。
試しにLinuxのAzure App Serviceでマウントしようとしたら、operation not permittedみたいなメッセージが出て、できませんでした。どうやら、Azure App ServiceはDockerコンテナがその実行基盤らしく(ルートディレクトリにdockerenvがありました)、Capabilityの設定でmountコマンドを禁止しているらしいです。サポートにも確認しましたが、privillegedをtrueにすることはできないようです。
ということでAzure App Serviceは無理そうです。
Web App for Containers
こちらもAzure App Serviceと同じ理由で厳しそうです。
Web App for ContainersはAzure App Serviceと機能はほぼ一緒です。というかAzure App Service自体の実行基盤はDockerコンテナで、Web App for Containersは、そのコンテナを生成するイメージを自由に指定できるみたいな感じです。
なのでサポートされているストレージはBlobかAzure Filesっていうのも同じですし、mountコマンドがCapbilityでオフられているのも同じです。
うーん、残念・・・。
Azure Container Instances
これもちょっと厳しそうかなと。と言いつつ私ブログ書いてますが。
Azure Container Instancesはコンテナをサーバーレスで実行する基盤で、あくまでもシンプルにコンテナを動かす実行基盤として使うものです。これ単体でProduction用途で通じるWebアプリケーションを動かすのは厳しい感じがします。負荷分散の機能もないですし。。。
Azure Automationと組み合わせてバッチ実行基盤として使ったり、Kubernetesの仮想ノードから使われるサーバーレスなコンテナみたいな用途が一般的のようです。
Azure Container Instances + Azure Automationで超格安バッチ実行基盤を構築！！
Virtual Machine Scale Sets
試してはいませんが、これはイケそうな気がします。仮想マシンのベースのイメージを元に、負荷に応じて仮想マシンを生成しスケールできるというすぐれものです。
負荷分散やオートスケーリングなどWebアプリケーションに必要なものは結構そろってますし、Azure App SerivceやWeb App for ContainersのようにCapbilityの制限もないので、NFSのストレージもマウントできます。
ただ、ベースの仮想マシンのイメージを作るのがちょっと面倒そうな感じはします。
Azure Kubernetes Service
これは本格的なWordPressを運用可能です。実績もありですし、このブログの運用基盤もこれです。
Azure Kubernetes Serviceで実現する超低予算＆(ほぼ)フルマネージド＆本格的なWordPress環境
Docker HubにあるOfficialなWordPressのイメージを使えば構築も楽ちん、Azure Kubernetes Serviceもマネージドなサービスですのでラクチンですし、負荷に応じてスケールアウトさせたりとか、誠に便利です。
肝心のストレージもNFSなものをマウントできます。Persistent VolumeでNFSがサポートされているので、それを使えば簡単です。NFSなストレージを構築する必要がありますが。
最近プレビューになったAzure StorageのNFSサポートの機能を使おうと思ったけど何故かうまくいきませんでした(´・ω・｀)
兎にも角にも、Azure Kubernetes Serviceであれば、本格的なWordPressも運用できそうですが、「WordPressにAzure Kubernetes Service？運用大変そう・・・」という声が聞こえてきそうです。確かにそのとおりかもしれません。
Kubernetesは運用が大変と言われますが、たしかにそのとおりです。色々なサービスが複雑に絡み合って動いているので、ちょっとトラブルが起きると、なかなかにトラブルシュートが大変です。
まとめ
そろそろまとめに入りたいと思いますが、個人的にはWeb App for ContaiersでNFSなストレージが使えればWordPressの実行環境としては最高だと思います。構築も運用もラクチンですし。
ということで、AzureでWordPressを実行させるために必要なたったひとつのことは以下です。
ストレージはNFSにすること
これだけです。。。
