概要

2024年3月にリニューアルしたコーポレートサイトについて、インフラ周りでどんな取り組みをしてきたのか、やったことをまとめます。

※ この記事はアプリケーション編の続きです。

この記事で書くこと

コーポレートサイトをリニューアルするにあたり、インフラをレンタルサーバからAWSへ引っ越しました。
考えることが多く大変でしたが、学びも多かったのでやってきたことをざっくり書いていきます。

構成図

AWSの構成図から、どのようなものをつくってきたか俯瞰しておきます。

大まかに概要をまとめておくと、フロントエンドとバックエンド(ヘッドレスWordPress)でアプリケーションを分離することで、デザインや機能を柔軟にカスタマイズできるようにしました。
そして、キャッシュを導入することでページ表示スピードを改善させました。

さらに監視環境を整えることで、問題が起き次第すぐに対処できるような仕組みも構築しています。

上で挙げただけでもたくさんの要素があるので、本記事ではとくに力を注いだところを抜粋して紹介します。

---

WordPress環境の引っ越し

今回は、レンタルサーバで動き続けているコーポレートサイトをAWS環境へ移植することでリニューアルさせました。

コーポレートサイトは全世界に公開されており、加えて社員が日々ブログ記事を書いているので、サイトを停止させることなくデータを移植させたいところです。
動き続けているアプリケーションを移植させるにはどうすれば良いか、試行錯誤を重ねたところなのでやってきたことを振り返ってみます。

WordPressをどうやって移植させたか

WordPressでは、テーマやプラグインをコマンドラインから編集することができるWP-CLIというツールが提供されています。
これを利用することで、リニューアル後のWordPress環境をコマンド1つで構築できるようにしました。

構築手順の冪等性

すると、WordPressデータとコマンドを入力に、常に同じ手順で環境がつくれるようになりました。
環境をつくる手順を統一することで、検証環境を経て安全に本番環境へとデプロイできるようになります。

生きているドメインをどうやって切り替えるか

コーポレートサイトはリニューアル後もrightcode.co.jpドメインを引き継いでいます。
こう書くとただドメインの向き先を切り替えれば良いように見えますが、どうやって事前に検証し、どうやって切り替えるかは大きな悩みの種でした。

ドメイン切り替えの難しさ

ドメインはDNSサーバだけでなく、WebサーバやCloudFrontからも参照されています。
具体的には、リクエストのあったドメイン名をもとに、どこへリクエストを中継するか決定されています。

このような仕組みをリリースのタイミングでまとめて本番向けに切り替えるのは、とてもリスクが高いです。
事前に検証しておいて、あとは設定を少し変えるだけ。そのような安心安全な心持ちでリリース日を迎えたいところです。

検証、そして切替

色々と悩みましたが、/etc/hostsファイルを書き換えることで、問題を解決させました。
つまり、ローカルでだけrightcode.co.jpドメインの名前解決の結果をCloudFrontのエッジサーバのIPアドレスで上書きしておきます。

こうすることで、CloudFrontやWebサーバは、あたかもコーポレートサイトがリニューアルした後の状態であるようなリクエストを受け取れるようになります。

シンプルな手順ではありますが、これだけで本番に限りなく近い環境で動作確認ができるようになります。さらに当日のリリース作業は、ドメインの向き先を切り替えるだけで完結するようになります。

切り替え作業を終えてみて

改めてリリースを経験してから振り返ってみると、この検証・リリース手順は大正解でした。
検証やリリースでも大きなトラブル無く乗り越えることができたので、ドメインを引き継いでアプリケーションを移植するときは、この経験を活かしていきたいです。

自動デプロイ-フロントエンド

WordPressをヘッドレス化させたことで、フロントエンドアプリケーションはWordPressへの依存を最小限としています。
フロントエンド環境はモダンな構成を追究しているので、自動デプロイも実現したいところです。

ECR・ECS環境で自動デプロイを実現させる上で、選択肢がたくさんあって迷ったので、どんな考えのもと、どのデプロイ方法を選択したのか整理してみます。

デプロイ方法の選択肢

AWS環境に構築したアプリケーションで自動デプロイを実現する場合、自動デプロイの仕組みをAWS・GitHub Actionsいずれに寄せるかが肝になってきます。
参考

どちらかが優れているというわけでもないので、コーポレートサイトのプロジェクトがどちらに合っているのか、判断できるようさまざまな軸から検討しました。

検討軸

最終的に、GitHub Actionsで完結させる構成を採用しました。
ここに至るまでに考えたことをざっくりと整理しておきます。

シンプルさ

GitHub Actionsでは、AWS公式が豊富なactionを提供してくれています。
おかげで、ワークフローからactionを呼び出すだけで、ECRを経てECSへアプリケーションを自動デプロイするような仕組みが簡単につくれます。

参考

以前は課題となっていたシークレット管理がOIDC認証で安全に運用できるようになったのも、運用のシンプルさを助けてくれています。

参考

デプロイ方法

ローリングアップデート・Blue/Greenデプロイが主に比較されます。
コーポレートサイトではリニューアルさせた後は、ページの見た目や配置を少し変えるような変更がメインです。
つまり、リニューアル後は比較的動作が安定するようになります。

ですので、シンプルに構築できるローリングアップデートで十分だと判断しました。

---

以上のように、いくつかの観点からデプロイ方法を検討し、最終的にはシンプルに運用できそうな
GitHub Actionsで完結させる構成にたどり着きました。

GitHub Actionsでデプロイするようになっての感想

リニューアル後もGitHub Actionsの恩恵にあずかっていますが、構築・運用いずれもシンプルにできて満足です。

ワークフローを見れば、デプロイ処理で何が起きているか一目で分かるのがありがたいですね。
デプロイで問題が起きたときもワークフローを調べていけば、どんな仕組みでどこに問題がありそうか調査しやすくて助かっています。

その他

キャッシュ

CloudFrontで画像やCSSなどの静的コンテンツをキャッシュさせることで、応答速度を改善させました。
リニューアル前は一部の記事で表示に数秒かかることもありましたが、今はサクサク表示されるはずです。

キャッシュ以外にもいろいろがんばったところはありますが、結果として、メインの閲覧媒体であるPC向け画面では、PageSpeedInsightsにて高いスコアを獲得できています。

監視

アプリケーションで発生した問題は、Slackチャンネルへ通知されるようにしました。
こうすることで、問題が起きたときにすぐに調べられるような仕組みを整えることができました。

振り返り

経験の無い領域もいくつかありましたが、なんとかリリースを迎えることができました。
未経験の技術も先行事例を参考にただ導入するのではなく、今のプロジェクトになぜ必要なのか・どんな課題を解決させたいのか明確にすることで、良き構成で構築できたのではないかと思います。

ここに書ききれない学びもたくさんあったので、本記事以外でもブログ記事の形で知見を共有していきたいです。

まとめ

本記事では、コーポレートサイトのリニューアルにて、インフラ周りで何をやってきたかまとめました。
まだまだ改善させたいところは残っているので、ここから更に良くしていきたいです。