Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

失敗だらけのセッションストア分離作業/separate-session-store

 失敗だらけのセッションストア分離作業/separate-session-store

引越しや庭木の剪定などの出張・訪問サービスのプラットフォーム「くらしのマーケット」を運営する、みんなのマーケット株式会社です。
ベトナムでの開発に伴いセッションストア(ElastiCache for Redis)を分離したのですが、その作業の中でいくつか問題が発生しました。分離の経緯および失敗から得られた教訓についてご紹介します。

▼みんなのマーケットは一緒に働く仲間を募集しています!
https://minma.jp/recruit

More Decks by みんなのマーケット株式会社/ Minma Inc.

Other Decks in Programming

Transcript

  1. microapp からのセッション情報の利用 1 日本とベトナム同時に開発するにあたって機能の一部を 
 microapp (特定の機能を完結して提供するアプリ) として分離することで それぞれ独立して開発できるようなアーキテクチャになっています。 


    
 ある機能の開発でベトナムのチームが開発する microapp からセッション 情報を使う必要が出てきました。 
 ベトナムチームに関しては「󰑜ベトナムで󰠁開発はじめました」をご参照ください https://speakerdeck.com/minma_curama/we-began-software-development-in-vietnam
  2. 肥大化した ElastiCache 2 しかし、セッションストアとして利用している ElastiCache (Redis 互換) にはセッションとは関係ない色々 な情報が保存されており、神 ElastiCache

    化してました。 
 
 この状態で microapp を接続すると以下のような問題があると考えました。 
 
 - 必要のない情報にアクセスできてしまう 
 - 意図しないデータ破損のリスク 
 - セキュリティ的に各アプリケーションの権限は最小限に保ちたい 
 - 別のシステムのバグや障害の影響でセッションが利用できなくなる可能性がある 
 - 将来的にセッションストアの最適化が必要になった際の影響範囲が広がる 
 
 この機会にセッションストアを分離することを決めました。 
 なんでも答えてやるぞい
  3. セッションストアは信頼性が求められますので MemoryDB (Redis 互換の高耐久性 DB) の利用を検討しました。以下 のような違いがあることがわかりました。 
 
 -

    障害時のデータロスへの高い耐久性 
 - ElastiCache と比較して特に書き込み速度が遅い 
 - 1インスタンスに db を1つしか作れない 
 - 2個以上 db がある ElastiCache のスナップショットを MemoryDB へリストアできない 
 - クラスターモードが有効(無効化できない) 
 - 接続は TLS が有効(無効化できない) 
 
 途中までは Memory DB を利用する方向で進めていたのですが、既存システムで利用している Redis クライアントがク ラスタモードに対応していなかったため断念し、ElastiCache を使うことになりました。 
 MemoryDB の検討 3
  4. 問題発生! 5 マイグレーション作業の当日にいくつか問題が起きました 
 
 - ElastiCache は MIGRATE コマンドが制限

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

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

    では差や制限がある場合がある 
 - 事前に必ず本番に近い状況で確認を行うべき 
 
 - 計測できるデータをあえてフェルミ推定的に見積もると失敗する 
 - 可能であれば面倒くさがらずに必ず本番データで計測する 
 
 - サービス停止状態で行うメンテナンスでやることは最小限に留める 
 7
  7. 会社について 9 会社名 みんなのマーケット株式会社 Minma, Inc 本社 東京都渋谷区道玄坂 1丁目10-5 渋谷プレイス

    10F 設立 2011年1月17日 代表者 浜野 勇介 従業員数 121名(2023年11月末現在) 事業内容 オンラインマーケットプレイス 「くらしのマーケット」の開発と運営
  8. 社会情勢の影響 事業は10年間継続して、成長している
 コロナ禍でも予約は伸び続けている 
 2020年4月の緊急事態宣言下では、一時は利用を控える動きも見られましたが、控える動き以上に Stay Homeの影響で、家で過ごす時間を快適するためのサービス利用が増加しています。 
 できてないことがたくさんある。まだない出張サービスも定義していく 


    現在は、事業成長の方法はわかっているが、人手が足りなく実行できていないことが多い状態で、今後の 伸びしろは大きいです。また、すでに世の中にある出張サービスだけではなく、出張サービスにすると便 利なものを私たちが出張サービスとして定義し、届けていくことも予定しています。 
 新型コロナウイルス 
 による影響
 長期の成長性
 13