背景

こんにちは、キュービックでSREをやっているYuhta28です。キュービック内のテック技術について発信します。
弊社ではふるセレというふるさと納税メディアサイトを運営しています。

ふるさと納税は年末に最もアクセスが集中し、弊社のメディアも12月の駆け込み申し込みに向けて多くのユーザーがアクセスしました。夏くらいに年末に向けたアーキテクチャ改善に向けた検討をおこない、11月~12月に見直しをおこないまして特に大きな障害もなく年を越せました。
今回は取り組んだアーキテクチャ改善について紹介いたします。

改修前

ふるセレはWordPress中心の純粋なWebメディアと各種ふるさと納税サイトから返礼品のデータを取得するためのスクレイピング機能が合体したサイトです。

アーキテクチャ上部のmediaと記載されたEC2がWordPressを構築するフロント部分となります。当初はリリース優先で構築したため一つのEC2の中にMySQL DBを含めたオールインワン構成になっており、このEC2がダメになると障害が発生する脆い構成になっていました。またWordPressのプラグイン改修も直接サーバへFTPでファイル転送をおこなう運用で検証環境と本番環境で差分が度々生じてしまい、運用コストが高いという課題もありました。
年末まで時間が限られていたので、WordPress担当エンジニアチームにヒアリングしてWordPressのインフラアーキテクチャ観点から改修したほうがいい点を提案しました。

提案一覧

EC2からDB切り出し
EC2のオートスケーリング化
FTPデプロイからGitベースの自動デプロイ実装

また直接のインフラ基盤改善とは別に今後の運用をやりやすくするために以下の2つも提案しました。

環境別AWSマルチアカウント構成
TerraformによるInfrastructure as Code(IaC)構成

AWSマルチアカウント構成は弊社ブログの最初の記事にて紹介していますが、環境単位、プロダクト単位でAWSアカウントを分けたほうがセキュリティリスクの低下や環境毎やプロダクト毎のAWSコストが可視化しやすくなるので今後新規サービス・プロダクトを展開するさいはマルチアカウント構成で進めていくようにしています。
またTerraformによるIaCを実現すれば別アカウントに同じ構成の検証環境作るときも手動作成時に生じがちなオペレーションミスを減らせることから、マルチアカウント運用する際にまとめて実施しようと考えました。

改善作業

Terraformディレクトリ構成

Terraformのディレクトリ構成はいわゆるモジュールを使った構成にしています。

#一部省略
├── env
│   ├── dev
│   └── prd
└── modules
    ├── codepipeline
    ├── ec2
    ├── rds
    └── vpc

ブログでは記事を読みやすくするためにだいぶ削りましたがvariables.tfやoutput.tfなどを使ってモジュールを共通化させています。TerraformでIaCができたら検証環境用のAWSアカウントを用意して構築していきます。

アーキテクチャ改善

提案一覧にもあったとおり新たにAmazon Aurora DBを実装してDBとWebサーバー部分にあたるEC2のオートスケーリング化して冗長化を図っています。

EC2のオートスケーリングに関しましてはスケーリング間のWordPressコンテンツの同期についてどうしようかという課題がありました。当初はEFS¹をマウントしてEC2間を同期することを検討しましたが、記事更新にとてつもなく時間がかかるという問題があり、導入を見送りました。
やや古典的な方法になりますが、外部公開しない社内限定のオートスケーリング外のEC2を用意して記事更新はそのEC2で実施、オートスケーリングされたEC2からrsyncで定期実行してWordPressコンテンツ配下のディレクトリを同期するという方法を採用しました。

DBの切り出しに関しては特別なことはしていません。基本的にデータの書き込みは記事の更新だけですので、マーケター側に移行作業中に更新を控えていただく旨を通達し、移行後にWordPressの設定ファイルから接続先をAurora DBに切り替えるだけで完了しました。

docs.aws.amazon.com

自動デプロイ実装

最後に取り組んだのがGitHubにpushしてdevelopブランチ、mainブランチにマージしたら自動デプロイできるCD基盤の実装です。
先のアーキテクチャ図にもあるとおりAWS CodePipelineを利用してGitHubの特定ブランチにpush(merge)されたらCode Deployが動いてWordPress配下のコンテンツディレクトリが自動反映されるようになります。

所感

ふるセレのアーキテクチャ改修について紹介いたしました。最初にインフラアーキテクチャを実装したエンジニアはすでに退職済みでしたので、残されたドキュメントの探索から始まり現状の課題やWordPress担当エンジニアの改善したいことをヒアリングしてよりよい運用ができるようにアーキテクチャを再構築しました。今回は触れていませんが各種ふるさと納税サイトからの返礼品の情報を集める部分に関しましてはまだまだ改善の余地があると考えていますので今後はその辺りの改善ができるようにモニタリング基盤を強化してデータを可視化しようと思います。