SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

最近話題の「あのサービス」に学ぶ、技術選定のポイント

サービスを止めずに接種予約を受け入れる! 累計195万件の新型コロナワクチン接種を支える「STORES 予約」インフラ増強と運用の舞台裏


  • X ポスト
  • このエントリーをはてなブックマークに追加

実際の運用ではどうだったのか

 このようなセットアップが終わって一応の目途が立ち、ワクチン接種予約に実際に使われ始めたのは6月でした

 時を同じくして、政府の職域接種の申し込みが開始になり、この間に多くの企業からSTORES 予約 のワクチン接種予約にも申し込みをいただき、実際にお使いいただきました。

 いざアクセスがスパイクしてみると、きちんと待合室が表示されて、順番に案内されている様子が見え、想定通りにバックエンドの負荷を平準化してくれているようでした。大変ありがたかった一方で、逆にそれまで社内で運用してきていた各種のメトリクスでは実際にアクセスがスパイクしているのかどうか一切検知できなくなってしまいました。

 Cloudflare Waiting Roomは、細かな設定が不要で、取り急ぎの導入には便利です。一方で利用状況をモニタリングする方法などは特に提供されておらず(当時)、管理画面をひたすら再読み込みして目視で確認するより他ありませんでした。例えば待合室が使われ始めたらSlackに通知できるような、なんらかの機械的なアクセスがあると良いと思いました。このあたりは今後の発展に期待したいところです。

 また、実運用が始まった後の待合室関連機能の追加開発は難しいとも思いました。Cloudflare Waiting Roomにサンドボックス環境のようなものがないことが理由です。変更点はぶっつけ本番でterraform applyしてみるしかなく、びくびくしながらのリリースでした。実際、ドラスティックな作り直しなどはできていません。小規模なバグ修正を行ったのみで、基本的には6月時点の一発書きの設定が今も動いているに近い状況です。ただ、それであまり困っていないというのも事実で、基本的な機能の完成度は高いと感じます。

 一方で、既存のサービスを止めない、という、当初の目論見が成功したかというと、実際には完全に無影響というわけにはいきませんでした。例えばWebサーバーの負荷は限定的でしたが、ワーカーの負荷は相応に上昇し、メール配信が詰まることがありました。Cloudflare Waiting Roomは急激にスパイクするアクセスを受け止めてくれましたが、やはり過去にない規模のアクセス数は押し寄せてきており、恒常的に負荷が高めで推移していたということになります。このあたりに対する考慮は欠けており、対策は後手に回ってしまいました。

自分の書いたサービスが、エンドユーザーの体験の一部になる

 今回、時間も工数も限られている中で、うまく既存のソリューションを繋ぎ込んで相応の成果を出せたのはよかったと思います。Terraformに手を入れたことと、前述のCloudflare Workersを新たに書いた程度で、STORES 予約 の本体のRailsアプリケーションの改修は最小限で済みました。既存の開発や運用に与えるインパクトが少なく、とくに体制変更などもせずに済んだので、既存のメンバーに負担をかけたり雰囲気が険悪になるといったこともなくて大変助かりました。

 弊社自体も職域接種に参加し、自社サービスを利用してワクチン接種予約を行いました。会場に着くと多くの方が接種の列に並んでおられて、これが全員自分の書いたサービスを使っていたんだなと思うと感慨深いものがありました。普段、Webサイトを開発していて、エンドユーザーの方が列をなしている様子を直接目の当たりにする機会はほとんどありませんから、実際に使っておられる方が目の前にたくさんおられるのは身が引き締まる思いでした。

 また、予約はあくまでオペレーションのごく一部で、現場の皆様のご尽力があってこそのワクチン接種だという当然のこともまた再認識しました。オペレーションやコミュニケーションの工夫もあって流れるように接種が終わり、このスムーズな体験にとって予約がなにかプラスに寄与できていれば良いのだが、ということを思わずにはいられませんでした。

この経験を通して伝えたい、技術選定の2つのポイント

 振り返ってみると今回の教訓として一番大きいのは、速度改善の四文字に惑わされてDBクエリを最適化しようと試みたりしなかったことだと思います。それをやっていたらおそらく期日に間に合いませんでした。

 最初から速いサイトではなく落ちないサイトを目指していたので、やることがソリッドに決まって、効率的に目的を達成できたと思います。どんな施策に効果があるか見えない中で、「これはやらない」を決めていくことは、決断力の必要なしんどい作業ですが、不可欠でもあります。ここを重点的に取り組んでいくことの必要性は再確認するべきだと思います。

 また、やることが決まった瞬間に即座に手を動かそうとせずに既存のソリューションがないかをほんの少しでも調査しておくことが有効でした。今回はたまたまフィット感の高いソリューションを各社が出しており、比較検討の上ひとつを採用することができました。フルスクラッチで自分で似たようなものを作ることは、工数をかければおそらく不可能ではないのでしょうが、安定稼働するまでには長い時間が必要そうです。

 今回の一件は「他社からすでにあるものを導入してきただけ」と言うことができます。一方で、「だけ」と言い切れるところまで要件を落とし込んだのが良かったとも思います。読者の皆さんにも、技術選定の際には、この点を参考にしていただければと思います。

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
この記事の著者

卜部昌平(ウラベ ショウヘイ)

 ヘイ株式会社 テクノロジー部門CTO室本部に所属し、STORES プラットフォームの各サービスに横断的に関わりながら開発をしている。専門はWebバックエンド、ミドルウェア。共著「改訂2版 Ruby逆引きハンドブック」(シーアンドアール研究所)、監訳「プログラミング言語 Ruby」(オライリージャパ...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/15241 2021/12/21 16:37

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング