Scribble at 2022-10-04 11:04:06 Last modified: 2022-10-04 15:27:54

このところヘテムルの挙動が悪い。この Notes の投稿はローカルで動作する PHP の FTP 関数を使って、ヘテムルにデータ・ファイルを転送しているのだが、その転送がたびたびタイムアウトするか処理が終わるまでに５分くらいかかったりしている。レンタル・サーバを使っているなら避け難いことではあるが、(1) サーバそのもののスペックが企業側のコスト・カットによって貧弱なまま放置されていたりする、(2) レンタル・サーバに同居している他の利用者が無駄であるか不正な動きをするプログラムを実行している、(3) C/S モデルでは避けられない経路上に起きるパフォーマンスのあらゆる障害、といった事情で、どうしようもない場合があるからだ。こういうリスクを避けるには、もちろん専用のサーバを借りるという選択肢がある。更に最近ではクラウドのサーバが利用できるため、(2) だけではなく (1) についても、借りたサーバ（インスタンス）のスペックに問題があれば IaaS なら簡単にスケール・アップできるし、プランが同じでもインスタンスを作り直して対応できる。(3) はネットワーク上の問題だから、原則として避けようがない。もちろん、専用のサーバを借りる場合、サーバを自力で運用できる技術力や知識や経験があればという大きな条件はあるが、この程度の目的や用途であれば、僕らのようなレベルのエンジニアでなくても構わない。ただし、結論を先に言ってしまうようだが、僕はヘテムルからクラウドに移行するつもりはない。ここから先に詳しく説明するが、AWS を借りるコストに加えてインスタンスを管理する僕自身の工数というコストが高すぎるからだ。

数年前までは AWS などを具体的に使っていなかったために、技術力は最初からあるし知識も AWS の解説書くらいは読んだけれど、現実にインスタンスを組んだり CloudFront や Route53 との連携で運用する経験は不足していたため、昨年から受託案件で AWS を利用する機会ができたのはありがたいことだ。そうして実際に使い始めると分かることだが、上記で紹介しているコタツ記事など読んでも読まなくても同じである。クラウド・サービスにとって最大かつ最高の情報は、やはりどう考えてもコストの話であって、これは経験者にしか具体的な事実が書けない。もちろん想定したプランとアクセス数を前提に、架空のコストを算出できるにはできるが、そのレベルの算数をやるために必要な予備知識すらないのがコタツ記事のライターというものである。IT やネット・サービスのライターで、まじめな話、２進数と10進数の基数変換ができる人なんて、1,000人に１人すらいないだろう（ちなみに「ITパスポート」レベルの知識である）。

さて、レンタル・サーバの代わりに使うのであるから EC2 のインスタンスを建てることになるのが大多数の事例だろう。そして、専有のサーバとして EC2 を運用することになるわけだが、レンタル・サーバで言う「マネージド」と呼ばれるプランと同じように、サーバのハードウェアやネットワークについての管理を Amazon に任せることとなるため、レンタル・サーバよりもコストがかかるのは当然である。自分だけが使える専用のサーバを運用するのだから、いまだと1,000アカウントくらいが１台のブレードを共有するレンタル・サーバとは別の話であるという自覚が必要だ。レンタル・サーバと同じようなスペックを組んでしまうと、クラウドでは割高になる可能性がある。なぜなら、レンタル・サーバのサイトで掲示されているサーバのスペックは、どれほどの数かは知らないが多数の他のアカウントと共有しているリソースなのであって、自分のサイトがそのスペックを全て使えるわけではないからだ。

個人のサイトを建てるのであれば、それまでレンタル・サーバで取得してきたログやアクセス解析の情報から判断して、最小限のスペックで EC2 インスタンスを組むのが正しい。当サイト（MarkupDancing）を例にすると、当サイトの2022年9月についてはアクセス数（ユニーク・アクセス）が月間で2,901、ページ・ビューが月間で19,375となっている。特定の IP アドレスからのアクセスが多いようなので、もちろん僕自身のアクセスも含まれるし、古くから Hatena アンテナや RSS リーダで定期的にアクセスしている事例もあるため、「肉入り」のアクセスは非常に少ないと思う。単純に検索エンジンやブックマークから人がわざわざアクセスしている事例は、たぶん９月の一ヵ月で100くらいだろう。こういうサイトに（もちろん内容とか記事の質なり評価とアクセス数が比例するとは全く思っていないが）過剰なスペックを割り当てる必要はない。よって、AWS なら "micro" とか "nano" といった名称で設定される計算リソースを用意すれば十分である。ただし、確保するストレージはアクセス数と強い関係がないので、OS、それからスワップ・ファイルを作成するサイズ、そしてコンテンツの容量と合わせて、最低でも 20 GB ていどは確保しておくのが望ましい。そして、これだけのスペックであれば、AWS の運用コストは月額にして $9 弱くらいになる（Osaka リージョンで Amazon Linux 2 を入れた t3.micro のリソースを使い、ストレージは general purpose ssd (gp2) で 20 GB を確保した場合の見積もり）。現在は円安だから月額の料金が1,300円弱くらいになっているが、それでもヘテムルでの３ヵ月料金である4,950円よりは３ヵ月ぶんで1,000円以上も安い。というか、EC2 インスタンスのプランを更に増強してヘテムルの料金に近くしても、EC2 は事実上の専有サーバなのだから中身がぜんぜん違う。

ヘテムルと AWS を単純に比較できない理由はいくつかある。その一つの理由は、ヘテムルにはデータベースが別のリソースとして用意されているけれど、AWS にはないからだ。EC2 にデータベースを同居させることはできるが、その場合はインストールもアップデートも全て自己責任で運用しなくてはいけない。よって、MarkupDancing のようにデータベースを全く使わずに CMS を運用しているサイトでは不要だが、WordPress のサイトだと自力で MariaDB をインストールして管理するか、あるいはもっと安全かつ簡単にデータベースを導入するたに Amazon RDS for MariaDB を別のインスタンスとして用意しなくてはいけない。そして、データベースは意外にコストがかかるという事実は知っておいたほうがいい。上記のようなコタツ記事を書いてるライターは AWS を実際には使ったこともなくて適当にネットで調べただけで書いているのだろうから、こういうことを知りもしないだろうし、実感としても分からないはずである（ああしたクズみたいな記事を書く手合いは、WordPress のサイトを運営するならデータベースが必要であるということすら、知らない可能性がある。いまや、レンタル・サーバで WordPress を使うならボタン一つでインストールできてしまうからだ）。

そうして、実際に最低スペックの db.t2.micro でインスタンスを用意すると、ストレージも少なくして 20 GB ていどにしても、月額のコスト見積もりは $20.36 つまり DBMS のインスタンスを追加するだけで3,000円くらいの予算が更に必要となる。もうお分かりだと思うが、ウェブ・サーバとデータベース・サーバを運用するなら、AWS は標準的なレンタル・サーバよりも〈絶対に〉コストがかかるのである。おおよそで言えば、３倍ていどと考えた方がいい。ドメインの契約費用も加味して一ヵ月のコストに組み合わせると、大雑把になるが一ヵ月で5,000円くらいの小遣いをウェブサイトの運営に捻出できるかどうかという話になる。もちろん、インスタンスの管理・運用という自分自身の工数は除外しての話だ。僕らのようなレベルのエンジニアであれば、ログを見たり CloudWatch の画面で色々な計測値を眺めたりする工数だけでも、それなりの金額を請求しているわけなので、こういうコストも（もしサイトのパフォーマンスを重視するなら）バカにできない。

そして、こういう実務上の経験があって、上記で紹介したような cost estimation といった机上の議論ですらヘテムルに比べたら高額な費用がかかるわけなので、いまのところはクラウドにサーバを移行させるつもりはないわけである。