root@kmconner.net:~/www/# cat << TECH
###################################################################################
##                                             TOP  PROFILE  POSTS  TAGS  ABOUT  ##
##                                                                               ##
##                         Welcome to kmconner’s Website                         ##
##                               浅く広く 時に深く                               ##
##                                                                               ##
###################################################################################
TECH
root@kmconner.net:~/www/# cat << TECH
###########################################
##     TOP  PROFILE  POSTS  TAGS  ABOUT  ##
##                                       ##
##     Welcome to kmconner’s Website     ##
##           浅く広く 時に深く           ##
##                                       ##
###########################################
TECH

ブログをリニューアルした

みなさんお久しぶりです。 この度ブログをリニューアルしました。

元々ポートフォリオサイトとは別サイトでしたが、今回ブログと同じサイトに統合しました。

インフラ周りも色々と変わっているのでその辺りも紹介します!

今までの構成

今までは WordPress を使っていました。サーバーは Xserver1 で動かしていました。

しかし、 Word Press や Xserver には個人的にいくつか不満点があり、その結果として今回のブログ移行となりました。

以前の構成になった理由

以前のブログを開設したきっかけは CAMPHOR- アドベントカレンダー2 に投稿しようと思ったためです。 そのため、比較的短期間でブログ記事を公開できる環境を整える必要があったため、自分でブログを作るのではなく、既存のサービスを使うか既存の CSM を用意したレンタルサーバーなどでホスティングすることを検討しました。

当時はクラウド、サーバーなどに関する知識もなく、 CSM やブログサービスなどはどれを使っても大して変わらないだろうと考え、一番メジャーであるという理由で WordPress を使用することにしました。

WordPress をホスティングするにはレンタルサーバーにもある程度の性能が必要となりますが、当時インターネットで調べた限りある程度安くて性能が一番良さそうだったという理由で Xserver を選択しました。

WordPress に対する不満

一番不満だったのは記事の管理がテキストベースで行えない点です。WordPress には記事を書くためのエディターの機能があり、記事はの執筆にはそれを用いるのが一般的です。 しかしこのエディターは自分にとっては非常に使いづらく、結果的に記事を書くための心理的ハードルを上げる原因となっていました。

また、数多く用意されたプラグインの組み合わせは場合によってはしばしばそれらが干渉し合って想定した通りに動かないなどの問題点も発生していました。 そしてそれらのプラグインのアップデートや WordPress 本体のアップデートなどは問題をより複雑にしてしまっています。

Xserver に対する不満

サービスを契約して一番初めに「え???」となったのはサーバーが IPv6 に対応していなかったことです。 最近の Web サイトはもちろん対応しているのに加え、一部のフレッツ系回線では IPv6 よりも IPv4 の方が圧倒的に遅いという場合もあり、 IPv6 に対応していることは非常に大切です。 (これはプロトコルそのものの特性というよりは使用しているインフラが IP のバージョンによって異なっているためです。詳しくはネット検索でもしてみてください。)

他にも設定の変更がやりにくい部分が多いなど色々と問題があり、月額1000円程度掛かっていたため解約することにしました。

新しい構成

この図が今回作成したブログのアーキテクチャ図です。

新しいサイトの構成

Xserver は解約し、全て AWS に移行しました。 DNS サーバーは Route533 を使用し、サイトのホスティングには S34 と CloudFront5 を使用しています。

また、インフラは Terraform6 によって構築されています。

また、記事は Markdown によって記述してそれから hugo7 によって静的サイトを生成、そのデータをホスティングしています。

旧サイトからのリダイレクトだけでなく、新サイトへアクセスする際の一部処理においても AWS Lambda@Edge を使用しています。(詳細はここでは省略します。)

新構成を検討する際のポイント

先程も述べた通り、以前の構成にはいくつか不満点がありました。 そのため、この構成を考える際に次の条件を必須と考えました。

  1. 記事をテキストファイルによって管理できること
  2. ローカルでのテスト環境が容易に構築できること
  3. インフラ管理をできる限り自動化でき、その構成を容易に変更できること
  4. サーバーが HTTPS、HTTP2.0、IPv6 の全てに対応していること
  5. ホスティングするのに必要な料金がある程度安いこと

一見条件が多いようにも見えますが1つ1つはそこまで難しいことではないはずです。

静的サイトの生成

まず初めに検討したのはサイトを静的サイト、動的サイトのどちらの形式でホスティングするかという点です。 これはインフラの構成を検討する際に大きく影響してくるためとても重要な選択です。

ブログの最も重要な機能は記事を公開することです。サイトによってはコメント機能もありますがせいぜいスパムが来る程度で自分の場合にはほぼ使っていませんでした。 また、 WordPress には記事の編集機能もありますがこれも先述の通り不要だと考えました。

レンタルサーバーやクラウドサービスを考えた時に、静的サイトをホスティングする方が動的サイトをホスティングするのに比べて料金が安い場合が多いというのもあり、静的サイトとして公開することにしました。

今回は静的サイトジェネレーターとして hugo を使用しました。 hugo とは markdown の形式で記事を記述し、それを元に静的な HTML 等を生成するソフトウェアです。

hugo でサイトを作るには記事本体だけではなくサイトの見た目を指定するテーマも必要です。 これも、今回は自作してみました。(自作する際の詳細はここには書きませんが、、、)

hugo を使用することで記事を全てテキストファイルで記述することができ、先に挙げた要件のうち1を満たせたと考えられます。

また、hugo にはテスト用の Web サーバーをホスティングする機能があり、これを使用することによって容易にテスト環境を使うことができます。つまり先にあげた要件の 2 を満たせたことになります。

インフラの選定

今回はインフラの選定にあたって、主に構築、変更の容易さと月当たりの料金の2つを考慮しました。

構築、変更の容易さ

静的サイトをホスティングするためのサービスには様々なものがありますが、設定の自動化や変更の容易さに関しては一般的なレンタルサーバーに比べてクラウドサービスに軍配が上がることが多いです。 AWS などのクラウドサービスには設定を取得、更新を行うための API が用意されており、これらを使用することで構成を変更することもできます。 インフラの手動管理はミスの源であり、管理者のやる気を削ぐ原因にもなります。

そのため、今回はインフラ構築は terraform を使って全て自動的に構築されるようにしました。 Terraform に関しては別記事でも書くつもりですが、このツールを用いることで構成を記述したファイルに従ってインフラを構築してくれるツールで、いわゆる Infrastructure as Code を実現できます。

利用料金

レンタルサーバーとクラウドでは一般的に料金の計算方法がことなります。 前者は月あたりなどでスペックに応じた固定料金なことが多いですが、クラウドサービスの場合は従量課金制になっていることが多いです。

今回は自分が使い慣れているクラウドサービスである AWS においてコストを試算しています。

つまり、クラウドを使用した場合のコストを正しく見積もるにはこのサイトへのアクセス数を見積もる必要があります。 お気づきかもしれませんが、このサイトへのアクセスは非常に少なく、多めに見積もっても月 10,000 アクセスもありません。 (この数字は純粋なアクセス数ではなく、旧サーバーに対して GET リクエストが行われた回数になります。)

このアクセス数ではどちらを選んでも対してコストは変わりません。 どちらも最大で数百円程度で済むでしょう。

また、同じ値段であっても CloudFront を使用することによるアクセス速度の向上が見込まれるため、より価値があると考えています。

AWS や CloudFront を使用することで先に挙げた要件のうち 3 以降が全て満たされると考えられます。

インフラの構築

先述の通り、インフラには AWS のサービスである S3 と Cloudfront を使用しています。 このインフラ構成は AWS をよく使う人にとっては一般的なものだと思います。

hugo によって生成された静的サイトのファイル群は S3 Bucket にコピーされ、それを Origin として CloudFront で配信しています。

ちなみに S3 に関してはそれ単体で Web サイトをホスティングする機能がありますがこの方法は今回は選択していません。 これは、 Cloudfront を使用した方がより細かな設定ができ、アクセスも高速になるためです。

また、この辺りの構成は、 Terraform を使うことでこれらの構成をコードによって記述して自動的に構築されています。

このサイトの今後

現状のこのサイトはまだ完成したしたというわけではありません。 色々と改善したい点はあります。

今後しばらくは大きなアップデートをする予定はないですが、少しずつアップデートしていく予定です。

おわりに

今回は長々とブログのリニューアルのことを書いてきましたが、このリニューアルによって書くためのハードルがかなり下がったように思えます。

なかなか頻繁に書くのは難しい気がするもののできる限り更新していきたいなーと思っています。


  1. https://www.xserver.ne.jp/ ↩︎

  2. https://advent.camph.net/ ↩︎

  3. https://aws.amazon.com/route53/ ↩︎

  4. https://aws.amazon.com/s3/ ↩︎

  5. https://aws.amazon.com/cloudfront/ ↩︎

  6. https://www.terraform.io/ ↩︎

  7. https://gohugo.io/ ↩︎