はじめに

初めまして
出張撮影マッチングプラットフォームのOurPhotoというサービスのエンジニアリングマネージャーをしているdoueと申します。

当サービスでは、データベースにAWSのAurora(MySQL)を使用しています。
2021/8に、AzureからAWSへのインフラ全面移行を果たし、その後、2021/10に当サービスでの繁忙期が迫ってきたため
Auroraのリードレプリカをオートスケールするように変更いたしました。

その際に起きてしまったことを懺悔したいと思い、記事を書かせていただきました。

当時の心構え

当時、当サービスの本番環境では
Auroraが１台構成で稼働していました。

Azure時代から元々DBが一台構成となっており、とりあえずはその形を踏襲して
Auroraでも1台構成にしていました。

繁忙期が10月に来ることはわかってはいたため
「まあリードレプリカ＆オートスケールの設定はすぐできるし大丈夫」くらいの感覚で
その時にサービス負荷に耐えるようと考えていました。

そしてその時は突然やってきました。。

サービス繁忙期が10月と言ってはいましたが
実は、10月中旬までは、負荷もあまり上がらず、気にしていなかったのですが
突然、夜の時間帯にCPUが100%に張り付く事態になってしまいました。

例年、ユーザー数も増加してきていたのもあって予想を超えた負荷になってしまいました。

元々、リードレプリカを入れて、オートスケールをすることでCPU使用率は緩和されることは予想できていて
さらにその設定事態難しくもないため
問題が起きたのち、「してやったり」の気持ちで、即座にリードレプリカを設定しました。

結果、CPU使用率もガクンと減ってくれ、一件落着しました。

リードレプリカを導入した後、謎のエラーが多発しました。。
その後開発チームで原因調査をした結果

アプリケーションのプロセス内で
リードインスタンスと、ライトインスタンスを行ったり来たりしていたため
DBに不整合が起きてエラーになっている

という問題が起きてしまいました。
いわゆるレプリケーションの遅延です。

書き換えたはずのレコードが、直後のプログラムで参照した時に反映されてないためエラーが発生してしまっていました。

「いやいや、仕組み的にはそれはそうだけどさ〜・・・」
という気持ちにはなりつつ、そんなことある！？と内心半信半疑でした。

当サービスでのサーバーサイドは、Laravelで動いていますが
stickyオプションというものが存在します。

Laravel公式ドキュメントからの引用

現在のリクエストサイクルにデータベースに対して「書き込み(write)」処理が実行されると、すべての「読み込み(read)」操作で"write"接続が使われるようになります。

「そうそうこれこれ〜〜〜〜〜〜」と、なぜか感動してしまいました。

Laravelではこちらを設定するだけで、リードレプリカが問題なく動くようになります。

リードレプリカ自体は、弊社の他プロダクトでも当たり前のように導入しており
設定が超簡単なので油断していました。

ユーザーや社内メンバーに多大なご迷惑をかけてしまったのは
マネージャーである私の責任に他ありません。

さて、今回の問題はちゃんと調べてればよかったよね、という話ではありますが
しっかりと、検証環境で確認しておくことが、やっぱり非常に重要だったなと
僕たちに気づきを与えてくれました。

ソフトウェアの世界では、何が起きるか本当にわかったものではありません。
今後はしっかりと検証を重ねて本番リリースをしていきます。

ここまでお読みいただいた方々、ありがとうございました。
OurPhotoという出張撮影サービスを少しだけ紹介させていただきます。

OurPhotoでは、「あたらしい写真文化をつくる」というビジョンのもと運営をしているサービスです。
特に七五三やお宮参りと言ったイベントは
従来、スタジオ撮影といった方法で思い出として写真に収めるのが通例となっています。

また、カップルや家族などの記念日などだけではなく
日常も含め、その素敵な瞬間をもっと気軽に安心して写真に残せたらという思いでOurPhotoを運営しています。

ご興味を持っていただけた方は
ぜひOurPhotoで、大切な方との思い出を写真に残してみてください。