Boost」など、さまざまなカンファレンスを企画・運営しています。BOOKS(コードジン・ブックス)は、CodeZineの連載からカットアップした、開発現場の課題解決に役立つ書籍シリーズです。いうテンションのプロジェクトでしたが、冷静に考えると実際にはDB負荷はそこまで大きくないな、という仮説を立てました。ワクチン接種は人間がボトルネックになるシステムです。1000回、2000回と接種する人はいません。仮に国内の居住者がもれなく2回ずつ接種したとしても、これから半年で最大3億回のワクチン接種が国内で行われて、それ以上は多くならないです。いうと、DBに詳しいSREの方などですと明確に「違う」と言えるのではないでしょうか。そのくらいの行数を毎日といった頻度で処理しているDBは世の中には数多あるかと思います。つまるところ、アクセスが殺到してシステムが落ちる、というとき、落ちているのはおそらくDBではないです。前段のWebサーバーです。ここだけ救えば良いのだろうという目星をつけました。ワクチン接種予約専用に作られたシステムというわけではありません。他にもさまざまな業種の予約業務に利用されており、ワクチン接種予約にアクセスが殺到しているときに、サイトの他の部分には影響を及ぼさないようにする必要がありました。すべてのコンテンツが「https://coubic.com」上でサブドメインも切られずに提供されており、URLは急に変えることはできません。重要なのは管理画面で、お客さまが大量にアクセスしているからといってマーチャントまで締め出されてしまうとマーチャントの業務に支障が出てしまいます。そこで、サイトの一部だけを選択的にレートリミットできるようなソリューションを探すことにしました。Room」などと検索した結果、使えそうだなと思ったのは以下の3つです(すべて英文)。Lambda@Edgeおおむねの傾向として上から下に向かって細かな制御ができるようになる(しないといけない)印象です。今回はこのうち、一番簡単に使えそうなCloudflareを選択しました。Cloudflareを選んだ理由としては、ひとつは正直なところ先方からの提案があったからというのも大きいです。そのほかにもTerraformで設定が書けるというのも大きなアドバンテージに映りました。インフラ構築の多くがTerraformで達成されています。自分たちがすでに利用しているテクノロジーからの大きな乖離がないのは大事です。この新しいソリューションを選択することがどのくらい大変で、どのような運用負荷がかかるかを容易に想像することができるからです(※)。5月の時点では実はterraform-provider-cloudflareのcloudflare_waiting_roomのリソースはプルリクエストが出たばかりでマージされていませんでした。当初、プルリクエストされている内容を手元でビルドする必要があって一手間必要でしたが、これは6月頃にめでたくマージされ、今は特別な手順を必要とせず動くようになりました。上記の通り「既存のサービスを止めない」がトッププライオリティです。チームの他のメンバーが通常の開発を通常のスプリントで実施しており、これを止めてサイト最適化に注力させるのも今後の計画に影響があると考え、できれば既存のサービス「の開発」も止めずに済めばいいと考えました。そこでおおむね以下のような方針で構成していくことにしました。既存のサービスサイトである「https://coubic.com」には既存のサービスがこれまで通りデプロイされ運用されている状態をキープします。その隣にワクチン接種予約をハンドリングする専用のサイトとして「https://stores-reserve.com」を作成し、Cloudflareでサーブします。Ruleで判断し、必要に応じて「https://stores-reserve.com」にALBのレイヤーでリダイレクトすることにします。Roomが待ち受けており、それぞれのマーチャント(≒接種会場)ごとに個別のレートリミットを実施します。Roomでは個々のユーザーからのアクセスに固有のCookieを割り振って、どのユーザーがどの順序でサイトに訪問してきたかを管理します。発行済みCookieの数が多すぎて、アクセスが殺到していると判断される時には、ここでHTMLをレンダリングして終了です。サイトに余裕がある時にはCloudflareからALBにリクエストを戻します。リダイレクトがループにならないように注意しながら、実際のサイトへリクエストを投げます。実際の構成このような構成にすることで、既存の管理画面などへのアクセス経路には一切変更を加えることなく、アクセスが殺到することが予想されるワクチン予約の予約画面のみを保護することができます。既存のサイトの側はこれまで通りに開発してこれまで通りにデプロイすることが可能になっており、すでに並行して走っている他の開発案件にも影響を与えません。以上の流れでおおむねうまくいきましたが、何点かは追加で対策が必要でした。CORS対応が追加で必要でした。今回、これまでのドメインと別のドメインを新たに作成しましたが、それらの間でjavascriptなどを共有する必要があります。*でいいのではないかというと、そうもいきません。Room)がCookieを使っているというのが肝です。*ではいけないので、きちんとドメインを明示する必要があります。Workersを使いました。本体側にも少しだけ変更を入れました。Facebookログイン機能があるのですが、これを使うとリダイレクト先に「coubic.com」が登録されているので「coubic.com」の側にアクセスしてしまいます。これを避けるため、今回はワクチン接種予約にはFacebookログインは使わないだろうと割り切り、導線を非表示にするといった対応もしました。プラットフォームの各サービスに横断的に関わりながら開発をしている。専門はWebバックエンド、ミドルウェア。プラットフォームチームの意義と実践のポイント1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。プラットフォームチームの意義と実践のポイント1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。プラットフォームチームの意義と実践のポイント1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。NEW新着記事一覧を見るイベント今後の予定を見るCodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。イラストの無断転載を禁じます。記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。