IaasでWordPressを企画したお話
どこかの人が「サービス提供するほうが先であって、変なところに時間使うものじゃない」と言ってきそうな話ですが、ずっと自分の学んだ成果を発表する場所に悩んで得た結論になります。
まだ手を加えなければならない部分が多々ありますが、一応の分岐点として。
なぜIaaSか
IaaSは単純に仮想マシン1基のコントロールをすべて行う必要がある代わりにすべてのカスタマイズが可能になります。
サービス提供速度的な意味だとPaaSなりSaaSなりのようにあらかじめ準備されたソフトウェア環境に載せていくのが非常に速いのですが、各サービスシステムの部品剪定にこだわると、どうしてもPaaSやSaaSでは満足のいく結果が得られません。
なぜIaaSでWordPressか
ただ、WordPressのような「レンタルサーバーでもいける」ようなWEBアプリを導入するのに、わざわざIaaSを使うのは何かオーバースペックなように思われてならないでしょう。
ですが、ただWordPressをアップロードすればいいだけ、に留めてしまったら、例えばレンタルサーバーではPHPのバージョンもApacheのバージョンも、HTTPのバージョンもSSLの暗号スイートも十分にコントロールできません。
特にチューニングが必要なApacheとPHP周り、SSLの暗号スイート周りについては、きちんとデプロイ先を考えなければ後々で引き下がれなくなるのです。
具体的な枠組みの完成
とりあえずどんなものを作ったのかを列挙。
- Host: Google Cloud Platform
- Service: Compute Engine(small)
- OS: Debian9/stretch
- Server: Apache for mpm_event
- Server and PHP Architext: From newer source code
- PHP System: mods_php
- HTTP version: HTTP/2.0
- MySQL: Origin MySQL not MariaDB
- OpenSSL: v1.1.0f
- SSL Key: ECDSA with prime256v1
- SSL Owner: Let's encrypt
- and WordPress.
その結果出来上がったサイトがこちら。
以後、ひとつひとつ解説。
Google Cloud Platform
LAMP環境というよりも、自分にとってもっとも需要を満たしてくれるクラウドサービスとして選択。
App EngineなりKubernetes Engineあたりも魅力的なところだが、今回のコンセプト的な意味で。
料金はだいたい相場だが、DNSとかDomainは別サービスに振った方が安いかも。
Compute Engine
GCPのIaaS環境。とりあえずなんでもかんでも詰め込みたければこれで。
ロードバランス噛ませて、データベースを独立させて、コンテナ稼働にしてなどといったスケーリングをするとコストで悩むのでこじんまりと。
IaaSなら他でも提供されているが、debian9がデフォで選択できたのはこことAWSくらいのはず。
なお筆者はFedoraを入れようかと画策したが、さらに面倒になりそうなので断念。
Debian9 stretch
Ubuntuのver17.04相当なdebian。Kernelが4.13じゃないからUbuntu17.10は新しすぎる。
これを選んだ理由は、リポジトリのデフォルトでOpensslのver1.1.0を使えること。あとカスタムイメージでFedoraを入れないというところの妥協点である。
ただしデフォリポジトリのPHPとapacheは若干古いので、こちらはソースコードからビルドする。
Apache with PHP
サーバーはいったんApacheを選択。mpmのevent駆動なら静的ファイルの処理もnginxに引けを取らない。ただしevent駆動によるmods_phpはけして早いとは言えないので、php-fpmやeventではないmpmの仕様も検討中。
新しめのバージョンならhttp2も読める。
HTTP2.0
これによる全SSL化を実現したかったからGCPを選んだようなもの。AWSでHTTP2.0化をやろうとすると少し裏技が必要だったはずである。
SSLを使用するために適当なドメインネームをお名前.comで所得する。
ちょうどふたけたひとけたセール中だったのでそれにあやかっただけ。
Let's encrypt
個人でSSLするなら現状ここ以外に無料SSLはない。
GCP側でも、設定次第でLet's encryptで自動SSL化してくれるが、鍵とCipher suiteを自己管理するために手動で発行した。
鍵種とCipher suite
鍵のアルゴリズムはECC、ECDSAは256bitで、prime256v1をOpensslに投げ込んだ。
prime256v1だと、Cipher suiteの種類によってChromeとFirefoxにおいてECDHE-ECDSA-AES256-GCM-SHA384という非常に硬いものになる。
ECDSA鍵が256bitで、ECDHEはx25519鍵による。
Opensslのversionを1.1.0にこだわったのは、このECDHE部分でx25519が有効になるようにするため。
その結果、SSL LabsにおいてA+評価をいただいた。
純正MySQL
MariaDBで運用してもよさそうなのだが、一応原点に返るように。
デフォルトのaptだとMariaDBが勝手に入ってしまうので、MySQLのサイトからdebファイルを引っ張ってきてリポジトリを弄ることに。
苦労したところ
ApacheとPHPのビルドは事前にシミュレートしていたのである程度スムーズにいったが、PHPのビルドがmicroだとうまく回らなかったのでsmallに拡張した。
また当初はhttp2接続にならなかったので、nghttp2を導入するなどしてバックアップをしっかり行う。
Let's encriptの発行は初めてだったが、それほど苦も無く達成した。ただSSLの有効化がなかなかなされなかったのがおかしいと思って設定ファイル眺めていたら、httpd.confでhttpd-ssl.confのインクルードがなされていなかった。
感想
やはりすべてこだわって組めることがIaaSの利点であり欠点。
こだわって組むということは、そのこだわった部分に余計な時間を使うということで、実運用として考えるとけして効率のいいことではない。
なんらかの自動化を行ったりする部分もまた、開発者の手腕であろうか。
展望
まだすべてが終わったわけではなく、例えばCSP設定などなどが不十分。リダイレクトはとりあえず動いているのだが、XSS防御の面でまだ不安があるし、Wordpress本体のセキュリティにいろいろ不安がある。
あるいはServerヘッダで流しているモノをふさがないとwappalyzerなどの解析ツールにバージョン情報を垂れ流してセキュリティの不安があるのでこれを封じなければならない。
SSLもsuiteにCHACHA20-POLY1305を入れているが、これはAES処理能力をハードウェアで持たないARMなモバイルに優しくするため。これをうまくモバイルがつなげられるようコントロールしたい。
SEOについては、もっとできることをやって、見られる見た目と有用な書き込みをしてからだろう。