はじめに
はじめまして、今年1月からSREチームに加入した千明です。
SREと名乗っているものの、前職ではバックエンドエンジニアが本職だったこともあり、インフラ構築以外にもアプリケーションの改修もしたり、幅広く業務にあたっております。
まだまだSREとしてはひよっこですが、会社に貢献できるように日々努力しているところです。
今回は直近でコーポレートサイトをリニューアルしたこともあり、AWS上で管理していたWordPressをShifterへ移行をした話をしたいと思います。
なぜ移行したのか
主な理由は、WordPressを面倒見るSREの人的コストを削減するためです。
WordPressは本体やプラグインに脆弱性が見つかることがあるため、最新の状態であることが推奨されます。
ですが、WordPressは更新頻度が高く、更新するにも事前検証が欠かせないため、自らが全ての面倒をみると多くの人的コストがかかります。
そうなると、ANDPADの成長にコミットする時間が減ってしまうため、外部サービスへ移行することとしました。
Shifterとは
ShifterはWordPressのホスティングサイトの1つで、以下のような特徴があります。
- WordPressのサイトを静的化したもの（Artifact）をCloudFrontで公開する。
- Artifactは世代管理されていて、以前のバージョンにロールバックできる。
- Artifactは公開前にプレビュー環境にて動作確認できる。
ShifterはWordPressを直接公開しないので、WordPress本体やプラグインの脆弱性を心配する必要もないですし、投稿者が更新ミスをしてもプレビュー環境で気づくことができ、間違って公開してもロールバックできるので、SREが面倒を見なくても運用ができる仕組みが揃っています。
どうやって移行したのか
基本的にはAll-in-One WP Migrationプラグインを利用してサイトのバックアップを取って、Shifterへインポートするだけでした。
ただし、既存サイト側の問題でいくつか改修が必要なケースがありました。
- 固定ページで動的にページ送りをしている部分が静的化の対象にならず、アーカイブページで作り直した。
- 投稿アーカイブページを利用するために、functions.phpの中で明示的にページを追加する必要があった。
- 動的フォームを利用するため、別の外部サービスが必要だった。(弊社ではformrunというサービスを利用しています。)
以上、移行する際に様々な問題がありましたが、ShifterではShifter-LocalというDockerで動くLocal環境が提供されているので、手軽に事前検証や改修を行うことができました。
また、どうしても困った時でも問い合わせすると1営業日以内に返信していただけるので、とても助かりました。
移行してどうだったか
まだ移行したばかりでまだ完全に手離れできていませんが、テーマやプラグインの更新作業も投稿者側でできるようになったので、運用が定着すれば、面倒を見ることはなくなりそうです。
更新内容は事前にプレビュー環境で確認できるので、万が一プラグイン側に問題があってもロールバックできるので便利だと思います。
現在取り組んでいること
現在はサイトの品質向上や冗長性を考慮して以下の2点に取り組んでいます。
アクセスログをDatadog Logsで可視化
最近ShifterのアクセスログをS3バケットへ出力する機能が追加されました。
アクセスログをDatadog Logsに投入して可視化することで、サイトの利用状況を分析したいと考えています。
障害時の体制整備
Shifterが何らかの原因でサービス障害が起きてしまっても、ドメインを切り替えてサイトを公開できる体制を整備しています。
ShifterのWebhookを利用して、Artifactを自動で別のホスティングサービスへデプロイして公開する仕組みを検討中です。
おわりに
今回はWordPressの話でしたが、便利な外部サービスを利用することで人的コストを減らせることができました。
ANDPADもまだまだ成長段階で、サービス開発していくために多くの人手が必要なので、SREとして管理の手間が省けてとても助かっています。
ANDPADも建設業界の方々にとって、より便利なサービスにしていきたいですね！
