Scribble at 2023-04-07 11:34:06 Last modified: unmodified

昨年の８月頃に AWS で立ち上げた EC2 のインスタンスで、或るクライアントのキャンペーン・サイトを運用していた（細かい話だが、コンテンツを制作したり更新したりしているときは、僕は「運営」と言っている。インフラやサーバの面倒だけなら「運用」と言っている）。現在はキャンペーンが終了して、静的なページを公表しているだけだ。キャンペーンでビジターからモニョモニョを募集していたのが10月から年末くらいで、モニョモニョの審査を経て結果を発表したのが先月であるから、おおよそキャンペーンで稼働していたのは半年くらいだろう。それ以外は、静的なコンテンツを置いているだけである。ちなみに、一昨年から続いているキャンペーン・サイトなので、かれこれ AWS で運用し始めて２年目に入っている。ただし、最初はウェブ・サーバが EC2 ではなく Lightsail であったという違いはある。なお、Lightsail を止めた理由は三つほどあって、以前も書いた話なのだが、(1) 他の AWS との連携が分かりにくい、(2) かなり高額なスペックでもインスタンスが頻繁に落ちる、(3) 固定料金なのでクラウドのコスト的なアドバンテージがない。

ということで、自力でサーバを立てて運用できる僕らのような技術者にとっては、やはりフリー・ハンドで扱える EC2 の方が逆に扱いやすい。ということで、昨年度のキャンペーンでは Lightsail から EC2 + + Amazon RDS (MariaDB) に移行して、キャンペーンの開始時に大量のアクセスが見込まれる際には、CloudFront の静的なコンテンツとは違って EC2 のオリジン・サーバが PHP での処理を担当するため、一時的に EC2 をスケール・アップするという処置もとった（おおよそ３日間で、通常のスペックで EC2 を使ったら一か月分の費用を使うくらいのスペック）。

それから、弊社で借りている SAKURA インターネットのクラウドで構築しているサイトから、cron で１分おきに疎通監視のプログラムを動かしていた。タイムアウトすると、

https://chat.googleapis.com/v1/spaces/[...]

のように、Google Workspace の Google Chat で作成した専用のスペース（チャット・ルーム）に PHP が投稿するという仕組みである。この実績としては、上のスクリーンショットで示したように、おおよそ２カ月に１回くらいの頻度でタイムアウトしていたらしい。もちろん、通知が投稿されたらサイトを確認するのだが、別にサイトが落ちているわけではない。そもそも、疎通監視のスクリプトは公開している URL に対してリクエストを投げていて、レスポンスするのは CloudFront が提供するキャッシュである。ということは、オリジン・サーバ（EC2）には何の問題もなくても、CloudFront のように強力な CDN がレスポンスを返せずにタイムアウトしているということになる。これはいかにも変だ。

ただ、二カ月に一回ていどであるから、順番待ちとしてはあり得ることかもしれない。いくら強力な CDN であろうと、常に適正なレイテンシでレスポンスを返すなんて、民生サービスごときで期待してはいけないからだ。もちろん酷すぎると他のクライアントからもクレームは出るだろうし、SLA を特別に結んでいるクライアントもあろう。