こんにちは〜。チーフエンジニアのid:cockscombです。

最近、同僚のid:yashigani_wとともに、はてなのコーポレートサイトを静的サイトとして再構築しました。ちょっとした仕事ではありますが、経験によって得られた暗黙知を形式知へ昇華するため、ここに紹介します。

はてなのコーポレートサイトとは

弊社のコーポレートサイトは一般的なそれと同様に、株式会社としての「はてな」に関心を持っていただいた方々とコミュニケーションするための窓口です。会社情報を提供したり、あるいはプレスリリースなどの情報を公開したり、またあるいは採用に関する窓口になっています。必然的に社内でも関係する部署が多く、会社の規模の拡大とともに運用を改善するインセンティブが高まっていました。

これまでコーポレートサイトは、普通のWebアプリケーションとして構築されていました。Webアプリケーションといってもそれほどアプリケーションしておらず、テンプレートエンジンでHTMLを作って返すくらいのものです。作られた頃の背景などを考えると、リーズナブルな選択だったように思われます。

サイトを静的化するメリット

ここでいう静的化とは、Webサーバーがリクエストに応答する際に「単にファイルを返せばよい」とすることです。単にファイルを返せばよいということは、Webアプリケーションが動的な処理をする必要がなくなり、なんなら大半のリクエストにCDNだけで応答できるということです。

CDNでレスポンスを返せるので、Round-Trip Timeは短くなり、また突発的なアクセスの増加に対しても堅牢です。放っておいても壊れにくいのは大きなポイントです。

一方で、静的化による制約もあります。当然のことながら動的にコンテンツが増えても対応できません。あるいは、User-Agentに応じて異なるページを返すようなことも、ふつうはできません。

最近では、サーバーサイドで静的ファイルを生成する手法も出てきました。これならコンテンツが動的に増えても、最初のリクエストで静的ファイルが作られるので問題ありません。二度目のリクエストからは静的ファイルとして応答できます。Webアプリケーションと静的サイトのいいとこ取りになっています。

とはいえ我々のコーポレートサイトでは、動的にページが増えるようなことはないため、単に静的化するのが適していると考えられます。ページを増やしたり書き換えるのは我々なので、そのたびにデプロイすればよいはずです。

どのようにサイトの静的化を進めたか

それでは具体的にどのような作業を行ったかを振り返ってみます。

1. 静的ファイルをNext.jsで生成

静的サイトを作るため、既存のページを静的サイトジェネレータに移植します。テンプレートエンジンからの移植になりますが、ページ数的には十分に現実的です。ただし、今後もほとんど変更されないであろうページは、単にHTMLとして取り込みました。

静的サイトジェネレータにはNext.jsを選びました。我々はReactのエコシステムに慣れていて、Next.jsを使った案件も経験しており、社内にもノウハウが蓄積されています。

Next.jsは、今回利用する静的サイトへのエクスポート（Static HTML Export）にも、Server Side Rendering（SSR）にも対応しています。さらに、前述したような「サーバーサイドで静的ファイルを生成する手法」にあたるStatic Site Generation（SSG）のIncremental Static Generation機能も持っています。

Next.jsひとつでさまざまな状況に対応でき、非常に便利です。

2. 運用を自動化したい

先に述べたようにコーポレートサイトは関係する部署が多いため、運用を改善する必要があります。運用負荷を低減するために、真っ先に思いつくのは自動化です。

継続的デプロイを志向して、Gitでメインブランチにマージしたら自動的にプロダクション環境へ反映されるようにできるとよさそうです。合わせてGitHubの機能を使って、メインブランチを保護ブランチに指定し、権限を制約します。

さらに、GitHubのプルリクエストひとつひとつにプレビュー環境が作成されると便利そうです。関係者が複数の場合には、合意を取りながら作業を進めやすく、マージ可能かどうかの判断もできます。特に現在のような、リモートワークを前提とした働き方の中では、URLを共有するだけで状況を伝えられるのは便利です。

3. ホスティングサービスを選択する

静的サイトをホスティングするには、いろいろな方法があります。nginxで配信してもいいし、S3に置いてCloudFrontを通してもよいでしょう。

しかし最近では、静的サイトやSingle-Page Application（SPA）のためのホスティングサービスがよく使われています。そのうち以下の3つを検討しました。

結論から書くと、我々はAWS Amplify Consoleを選択しました。

Gitと連携した継続的デプロイ（上記2.を参照）について、AWS Amplify Consoleでは（Netlifyでも）よくサポートされています。ブランチごと、あるいはプルリクエストごとにプレビュー環境を作ることも容易です。プレビュー環境へのアクセス制限もでき、リダイレクトの柔軟さもあります。

NetlifyとAmplify Consoleはどちらも要件を満たせそうでしたが、普段からAWSを使っているため、Amplify Consoleを選びました。AWSのサポートプランにも加入しているので、いざというときも安心です。

Firebase Hostingは、BaaSとしてFirebaseとの連携はよいものの、プレビュー環境を作るのが容易ではなく、候補から外れました。

4. 動的なコンテンツを表示する

コーポレートサイトでは、いろいろな新着情報を動的に表示する箇所があります。一部はJSON API経由で取得して表示し、また一部ははてなブログMediaをサブディレクトリで運用しています。

JSON APIは、AWS Amplifyを使えば簡単に用意できます。これはAmplifyの面白いところで、GraphQLのスキーマを書いておくと、それをもとにLambdaやDynamoDBを（内部的にCloudFormationを使って）プロビジョニングできます。これによって、LambdaをバックエンドとしたGraphQL APIをとても簡単に作れます。

またAmplify Consoleのリダイレクト機能には、リダイレクトだけでなくプロキシとして動作させるモードがあります。これを使って、特定のパスを別にデプロイしたnginxへプロキシして、はてなブログMediaを活用しています。