失敗だらけのセッションストア分離作業
 みんなのマーケット株式会社
 SRE / 片山
 
2023-12-19

microapp からのセッション情報の利用 1 日本とベトナム同時に開発するにあたって機能の一部を 
 microapp (特定の機能を完結して提供するアプリ) として分離することで それぞれ独立して開発できるようなアーキテクチャになっています。 
 
 ある機能の開発でベトナムのチームが開発する microapp からセッション 情報を使う必要が出てきました。 
 ベトナムチームに関しては「󰑜ベトナムで󰠁開発はじめました」をご参照ください https://speakerdeck.com/minma_curama/we-began-software-development-in-vietnam

肥大化した ElastiCache 2 しかし、セッションストアとして利用している ElastiCache (Redis 互換) にはセッションとは関係ない色々 な情報が保存されており、神 ElastiCache 化してました。 
 
 この状態で microapp を接続すると以下のような問題があると考えました。 
 
 - 必要のない情報にアクセスできてしまう 
 - 意図しないデータ破損のリスク 
 - セキュリティ的に各アプリケーションの権限は最小限に保ちたい 
 - 別のシステムのバグや障害の影響でセッションが利用できなくなる可能性がある 
 - 将来的にセッションストアの最適化が必要になった際の影響範囲が広がる 
 
 この機会にセッションストアを分離することを決めました。 
 なんでも答えてやるぞい

セッションストアは信頼性が求められますので MemoryDB (Redis 互換の高耐久性 DB) の利用を検討しました。以下 のような違いがあることがわかりました。 
 
 - 障害時のデータロスへの高い耐久性 
 - ElastiCache と比較して特に書き込み速度が遅い 
 - 1インスタンスに db を1つしか作れない 
 - 2個以上 db がある ElastiCache のスナップショットを MemoryDB へリストアできない 
 - クラスターモードが有効（無効化できない） 
 - 接続は TLS が有効（無効化できない） 
 
 途中までは Memory DB を利用する方向で進めていたのですが、既存システムで利用している Redis クライアントがク ラスタモードに対応していなかったため断念し、ElastiCache を使うことになりました。 
 MemoryDB の検討 3


 移行作業はサービスを停止した状態で行うこととし、ダウンタイムを許容できるシンプルな作業でした。 
 
 今回、全データではなくセッションで必要な一部のキーだけを新しいクラスタへ移行したかったため、redis-cli の MIGRATE コマンド を利用して移行を行うことにしました。 
 
 クラスタのサイズは本番稼働のDBを触ることを怖がり、日々の利用者数を元に大体これくらいだろうと推定して用意しまし た。
 移行方法 4

問題発生！ 5 マイグレーション作業の当日にいくつか問題が起きました 
 
 - ElastiCache は MIGRATE コマンドが制限 されており用意していたコマンドが使えなかった 
 - テストでは EC2 上で動く Redis から ElastiCache への移行しか試していなかった 
 - 想定していたよりもデータ量が多かったためクラスタを作り直す必要ができた 
 - 新しい仕組みのリリースに必要な作業も同時に進めていたがそこでもトラブルが発生した 
 
 その時点で予定していたサービス再開時刻を大幅に過ぎてしまったため、作業の巻き戻しを行いました。 
 制限される Redis コマンド https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/red-ug/RestrictedCommands.html

ElastiCache → ElastiCache のマイグレーション方法の再考をしました 
 - (ボツ) DUMP と RESTORE コマンドを組み合わせる 
 - コマンドが複雑になり、データ転送時間も非常に長くなりました 
 - (採用) 全てのデータをリストアした後に、DEL コマンドで不要なキーを削除する 
 - DEL はデータ転送が不要かつ複数のキーを同時に指定できるため、高速に完了した 
 
 本番のデータのスナップショットを復元して移行作業の予行練習を行いました 
 - 必要なサイズを実測することができたので、必要なリソースを見積れた 
 - DUMP & RESTORE では実行時間が現実的ではないことに気づくことができた 
 
 サービス停止状態で行うメンテナンスではセッションストアの分離作業だけとしました 
 - 他の作業はサービスの停止をせずにリリース可能でしたので、別日に回しました 
 
 
 リベンジの結果、セッションストアの分離作業は無事に完了しました。 
 リベンジのために 6

教訓 セッションストアの分離作業では以下のような教訓が得られました。 
 似たような移行作業をされる方の参考になれば幸いです。 
 
 - AWS マネージドサービスと元の OSS では差や制限がある場合がある 
 - 事前に必ず本番に近い状況で確認を行うべき 
 
 - 計測できるデータをあえてフェルミ推定的に見積もると失敗する 
 - 可能であれば面倒くさがらずに必ず本番データで計測する 
 
 - サービス停止状態で行うメンテナンスでやることは最小限に留める 
 7

書いた人 8 2020年 みんなのマーケットに新卒入社 最近、アーキテクチャを設計するために diagrams.net（draw.io）で 箱と箱を線で結ぶのが楽しくなってきました。 片山 SRE 以降のスライドはみんなのマーケットの会社紹介になります！！

会社について 9 会社名 みんなのマーケット株式会社 Minma, Inc 本社 東京都渋谷区道玄坂 1丁目10-5 渋谷プレイス 10F 設立 2011年1月17日 代表者 浜野 勇介 従業員数 121名（2023年11月末現在） 事業内容 オンラインマーケットプレイス 「くらしのマーケット」の開発と運営

私たちのプロダクト 10 生活の「困った」を解決できるプロが集まる プラットフォーム「くらしのマーケット」 頼める出張サービスの種類 事業者の数 300種類以上！
 70,000事業者を突破！
 エアコンクリーニング、引越し、庭木剪定..などの生活関連サービス 日本全国の事業者が登録、売上を伸ばしている

私たちのビジョン 11 正直者が馬鹿を見ない世界を作る
 テスト前に必死で勉強したのに、先輩から過去問をもらっていた友達が自分よりいい成績を取った…
 会社のことを思って地味な仕事も引き受けてきたのに、上司に気に入られている同期が昇進した…
 
 世の中では、不条理なことが起きます。
 でも、悪賢い人が得をして、正直な人が損をする世界なんて嫌です。
 
 江戸時代の思想家、石田梅岩は「二重の利を取り、甘き毒を喰ひ、自死するようなこと多かるべし」
 つまり、悪賢い者には必ず報いがあると説きました。
 さらに「実の商人は、先も立ち、我も立つことを思うなり」とも表し、
 まず相手の利害を優先し、その結果として自身も利益を得ることが商人の本文だと説きました。
 
 私たちは、先も立ち、我も立つ、正直な人が報われる世の中を作ります。


私たちのミッション 「人と人」が関わるサービスを、
 安心して取引できる仕組みを提供する
 私たちは、くらしのマーケットを通じて、
 世の中のあらゆるサービスをインターネットで安心して取引できる仕組みを提供していきます。
 インターネットでモノを買う時、みんなが楽天市場やAmazonを利用するように、
 サービスを買う時は、みんながくらしのマーケットを利用してくれる…そんな世界を目指します。
 
 多くのベンチャー企業が、自社の成長をアピールしますが、いちばん重要なことは、
 その会社がその時に「どれだけ成長しているか」ではなく、その会社が今後「どこまで成長できるか」です。
 
 みんなのマーケットは巨大な市場に挑んでいます。私たちと一緒に、大きく成長していきましょう。
 12

社会情勢の影響 事業は10年間継続して、成長している
 コロナ禍でも予約は伸び続けている 
 2020年4月の緊急事態宣言下では、一時は利用を控える動きも見られましたが、控える動き以上に Stay Homeの影響で、家で過ごす時間を快適するためのサービス利用が増加しています。 
 できてないことがたくさんある。まだない出張サービスも定義していく 
 現在は、事業成長の方法はわかっているが、人手が足りなく実行できていないことが多い状態で、今後の 伸びしろは大きいです。また、すでに世の中にある出張サービスだけではなく、出張サービスにすると便 利なものを私たちが出張サービスとして定義し、届けていくことも予定しています。 
 新型コロナウイルス 
 による影響
 長期の成長性
 13

14 JOIN OUR TEAM! https://minma.jp/recruit