この記事はLCL Advent Calendar 2021 - 11日目です。
こんにちは。id:kasei_san です。今回は wordpressで動作している弊社コーポレートサイトをECS化したので、その時のハマりどころやポイントを紹介していきたいと思います。
既存のコーポレートサイト環境の問題
元々コーポレートサイトは、いろいろな事情でEC2の中のDockerで動かしている状態でした(ECS on EC2ではありません)。 そのため、運用上いろいろな問題がありました。
- 環境の構築手順が自動化されておらず、EC2が死んでしまうと復旧に時間が掛かる。
- EC2側のセキュリティ対策も必要。
- 環境やデプロイの方法がこのプロジェクト特有で学習コストが高い。
ちょうど当時、社内の各アプリのTerraform化を進めようとしていたところでした。そのためコーポレートサイトも、これらの問題を解決するためTerraformを使い、ECS化を進めることとなりました。
更新後の環境
最終的には以下のような環境となりました(正確には他にもいくつかのサービスを使用しています)。
その中から、工夫したポイントを紹介しようと思います。
wordpressのofficial Imageは使用せず、独自ImageとNginxを使用
Fargateで動かしている Docker Imageは、wordpressのofficial Imageではなく、PHPのImageにwordpressを独自にインストールしたものと、Nginxを使用しています。
これは、LCLで他に運用しているwebサーバがすべてNginxであるためです。コーポレートサイトだけがApacheであったため、知見が少なく、対応できるメンバーが少ないという問題がありました。そのため、これを機にLCLのwebサーバをすべてNginx としました。
また、Nginx化するにあたり、wordpressの向けのnginx.confを作る必要がありましたが、Nginx公式が詳細な記事を上げており、スムーズに対応できました。
ただ、1点困ったこととして、Nginx公式の方法は、Nginxとwordpressが同一のサーバ上にある前提の設定となっていました( try_files を使って、wordpressのディレクトリの .php のファイルを探したりしています)。
そのため、1コンテナ1アプリの原則で、wordpressとNginxでコンテナを分けた場合、Nginxには静的ファイルだけではなく、wordpressのファイルもすべてCOPYする必要がありました。
メディアファイルのストレージとしてEFSを採用
wordpressでは、uploadしたメディアファイルを扱う必要があるため、そのストレージとして、EFSを使用しています。
具体的には、wp-content/uploads をEFSからマウントしています。
図ではS3も使用していますが、こちらは定期的に更新する必要があるファイルをupする先として使用しています。
当初、upload先をS3とするwordpressプラグインを使用する予定でした。しかし、一番メジャーと思われる WP Offload Media の assets-pull-addon の最新バージョンでは、既存ファイルのuploadをサポートしなくなっていました…。他にもいくつかプラグインを調査しましたが、既存のファイルをS3にコンバートするちょうどよい方法は見つからず。EFSを採用することとなりました。
EFSは速度が遅く、コストが高いというイメージでしたが、コーポレートサイトはそこまでリクエスト数も多くないため、コストが安いバーストスループットで問題なく動作し、また、速度についても CloudFront でキャッシュするため、問題ありませんでした。
Terraform + ECS化しての感想
運用方法が他のTerraform + ECSで運用している他のアプリと同様となりました。これにより、運用のためのコストが大きく下がりました。コーポレートサイトはエンジニアが手を入れることが少なく、なにかを作業をするたびに手順を思い出す必要があり、それに結構な時間を食われていました。 また、ECSで動作しているため、taskが壊れてもすぐに復旧できるのは、とても安心感がありますね。
以上となります。今後、手軽に更新できるようになったことを生かし、素早くwordpressをupdateしていこうと思います。
