このブログサイトがめちゃくちゃ重くなったのを直した話

最近はご飯の事ばかり書いていたのですが久しぶりにエンジニア的な話をします。

2019/12/22にこのブログサイトがめちゃくちゃ重くなってしまったのを翌日の23日に直しました。この記事ではどうしてサイトが重くなったのか、そしてどうやって直したのかを書いていきたいと思います。

経緯

このサイトはGoogle Cloud Platform（以下GCP）というGoogleのクラウドサーバ上にあります。クラウドサーバではどこのサーバを使用するかを選択できます。サーバが置いてある地域をリージョンと言います。

選択できる国、リージョンは様々で、アメリカ、日本、シンガポール、イギリスなどがあります。サーバの値段も様々で、例えば日本とアメリカでは日本のサーバの方が高い傾向にあります。

サーバの場所もそうなのですが、サーバのタイプ（＝インスタンスタイプ）によって値段が違います。12/12にE2という新しいタイプがリリースされたというニュースを読み、E2の方が安くなりそうだったので変えてみることにしました。

インスタンスタイプを変えるんだったら、どうせならリージョンも変えて値段を安くしてみようと思い、リージョンも東京からアメリカのアイオワに変えることにしました。

インスタンスタイプとリージョンの変更はそんなに難しくありません。このサイトはGCPのKubernetesという仕組みの上で動いています。ここでは詳しく説明しませんが、サーバリソース管理などを簡単にしてくれる仕組みです。

そんな仕組みを使ってインスタンスタイプとリージョンを変更し、このサイトにアクセスしてみたところ・・・遅い！！！！

なんでだろう、と思ったのですが、まず最初に疑ったのは、リージョンでした。

基本的にアクセス元の場所からサーバの位置が遠いとレスポンスタイムが長くなります。インターネットの世界でも物理的な距離がレスポンスタイムに影響します。

僕は東京にいるので、アメリカのアイオワにあるサーバにアクセスするのに時間がかかっているのだろう、最初はそう思っていました。

んーーー、でもサーバ費用を抑えることができるなら我慢するしかないのか。。。そう思っていましたが、別の原因があるのではと思い始めてきました。

このブログサイトの情報はデータベースに格納されています。データベースとは、データを格納する箱のようなものです。

そのデータベースはどこにあるかというと、東京でした。

ウェブサイトというのは、データベースから取ってきた様々な情報を表示しています。このブログサイトも例外ではなく、そんな仕組みを取っています。

このサイトの本体が置いてあるサーバはアメリカ・アイオワにある。でもデータベースは東京にある。そんなチグハグな状態になっていたのです。つまり、１つのページを表示するために何回も何回もアイオワと東京を往復していたのです。それは時間かかりますよね。。。

ブログ本体が格納されているサーバとデータベースのサーバの物理的な距離を縮める事で解決でした。

データベースもアイオワに変更しました。

この状態でサイトにアクセスしてみると・・・・おぉ！！！速い！！チグハグ状態から考えると圧倒的に速いです。元の状態に比べてもそんなに遅くなってる気はしないです。（これは気のせいかもしれないが）

今回はサーバ費用を抑えるという目的でサーバのインスタンスタイプとリージョンを変更しました。ウェブサイト全てのサーバ構成を考えないでリージョンを変更すると大変なことになるなと勉強になりました。（いや、仕事を通じて知っているはずだったのですが、完全に見落としていました。。。）

皆さんもサイトのサーバのリージョン変更には気をつけましょう！

最後までお読みいただきありがとうございました。