1.6K Views
August 27, 24
スライド概要
ウェルスナビ株式会社 技術広報チームの公式アカウントです。
Aurora負荷への取り組みと 新たな課題 齋藤 颯⽃ @SRE meetup 〜サービス事業会社のSREが向き合う課題〜 1
⾃⼰紹介 齋藤 颯斗(Saito Hayato) ウェルスナビ株式会社 システム基盤チーム / SRE ウェルスナビでは ● 2024年4⽉ 新卒⼊社 ● ロボアドおよびDB周りの改善を担当している ひとこと ● 最近かなり暑いので、熱中症に気をつけてください 2 @2024 WealthNavi Inc.
本セッションでお話しすること 1. サービスをスケールする上で直⾯した課題 ○ Auroraへの負荷 ○ アプリの性能劣化 ○ スケールさせるために取り組んでいること 2. リアーキテクティング中に起きた課題 ○ 取り巻く状況の変化とその対応 3. 新たな課題と次への取り組み ○ 新たに⾒えてきたもの... 3 @2024 WealthNavi Inc.
アジェンダ 1. 現行のアーキテクチャ 2. アーキテクチャの刷新 3. 取り巻く状況の変化 4. Next Action 5. さいごに 4 @2024 WealthNavi Inc.
1. 現行のアーキテクチャ 2. アーキテクチャの刷新 3. 取り巻く状況の変化 4. Next Action 5. さいごに 5 @2024 WealthNavi Inc.
現⾏のアーキテクチャ 全てのAPIが1つのAuroraに向いている 基本情報 6 データベース Amazon Aurora MySQL アプリケーション 90個以上 バッチ / 1day 300個以上 @2024 WealthNavi Inc.
現⾏のアーキテクチャ スケールさせる上でのボトルネック ● 証券残⾼テーブル ○ ユーザーの資産評価額を保持 ○ 総レコード数は22億超え ○ 最もリクエスト数が多い ● 毎⽇、ユーザーの資産評価額額を更新する ○ 運⽤期間の⻑いユーザーほど、データ量が 増える 影響 ● 性能劣化 ● Auroraへの負荷 ● バッチの遅延 7 @2024 WealthNavi Inc.
現⾏のアーキテクチャの課題 解決したいこと ● アクセスが集中する時間帯とバッチが重なると、性能劣化が顕著になる ● ユーザー数の増加に伴うスループットの低下 ● 特に、ポートフォリオ画⾯の表⽰でレイテンシが悪化している ⽬標 ● ユーザーが増加しても性能劣化しにくいアーキテクチャへの変更 8 @2024 WealthNavi Inc.
1. 現行のアーキテクチャ 2. アーキテクチャの刷新 3. 取り巻く状況の変化 4. Next Action 5. さいごに 9 @2024 WealthNavi Inc.
DynamoDB移⾏ 証券残⾼を含むポートフォリオ関連テーブルをアーカイブ化してDynamoDBへ複製する 10 @2024 WealthNavi Inc.
ポートフォリオ概要 全期間分の資産評価額をグラフで表⽰している (※画面はイメージです) 11 @2024 WealthNavi Inc.
アーキテクチャ変更前 ● 証券残⾼テーブルを含む10個以上のテーブル群から⽣成している ● 全期間分をAuroraから取得 (※画面はイメージです) 12 @2024 WealthNavi Inc.
アーキテクチャ変更後 ● アーカイブ済みの過去履歴をDynamoDBから⽣成 ● 最新履歴のみをAuroraから取得 (※画面はイメージです) 13 @2024 WealthNavi Inc.
DynamoDB移⾏ Pros ● DynamoDBのパーティショニングを使⽤することでスループットを改善 ○ ユーザーIDでパーティショニングするだけでよいため、全期間スキャンおよび セカンダリインデックスが不要になる ○ スキャン範囲が固定されるため、シーケンシャルなスキャンによる速度改善が期待できる ● ポートフォリオの表⽰をDynamoDBで⾏うことでAuroraの負荷を⼤幅に軽減 ○ ユーザーからのリクエストにかかるレイテンシを改善できる ○ ユーザからのアクセス負荷が軽減されたことで、バッチの実⾏時間の短縮が期待できる Cons ● システムの複雑性の増⼤ ● 運⽤コストの増加 14 @2024 WealthNavi Inc.
1. 現行のアーキテクチャ 2. アーキテクチャ刷新 3. 取り巻く状況の変化 4. Next Action 5. さいごに 15 @2024 WealthNavi Inc.
短期間で状況が⼤きく変わった ● ⾦融市場の相場が不安定になったことで、アクティブユーザーが急増 ● 特定の時間帯だけ、なぜかスパイクし始める ● バッチの実⾏スケジュール調整も難しくなってきた ● インスタンスサイズを最⼤まで引き上げたばかりで、これ以上のスケールアップ ができない この短期間でこれらの課題が顕著になったため、早急に解決しなければ ならなくなった..... 16 @2024 WealthNavi Inc.
Reader/Writerの振り分け 特定のエンドポイントからのリクエストをReaderへ振り分け 17 @2024 WealthNavi Inc.
Reader/Writerの振り分け Pros ● ホットスタンバイさせていたReaderを活⽤できる ● インフラ側ですぐに対応可能 ○ アプリケーションの改修を必要としない ○ 特定のエンドポイントからのリクエストを参照⽤のAPIに振り分けるだけでよい Cons ● Reader障害発⽣時、他の参照できるReaderがないため再起動までの間ダウンタイムが⽣じる ● Readerへ振り分ける読み取り負荷の調整が必要になる ● Reader参照⽤のECSインスタンスが増えることによる、コストの増加 18 @2024 WealthNavi Inc.
検証⽅法 ● アーキテクチャ検証 ○ Reader参照APIのモニタリング ● 性能検証 ○ 負荷テスト ○ パフォーマンス測定 ○ キャパシティ測定 ● 障害テスト ○ TTLによる接続先切り替え ● リグレッションテスト ○ Autifyによる⾃動リグレッション ○ ⼿動リグレッション 19 @2024 WealthNavi Inc.
1. 現行のアーキテクチャ 2. リアーキテクティング 3. 取り巻く状況の変化 4. Next Action 5. さいごに 20 @2024 WealthNavi Inc.
今後の⽅針 ● Readerを積極的に活⽤していく ○ 読み取り負荷を少しずつReaderに分散させる ○ Fail Overが発⽣しても、ダウンタイムを短くする ● 同時並⾏でDynamoDBへ移⾏していく ○ 本番環境への影響を与えない ○ 本番環境への反映はできる限り短時間で終わらせる ● データベース周りの運⽤改善 ○ 新規リリース前の性能検証 ○ スロークエリのアラートと改善プロセスの整備 ○ アプリ‧バッチのモニタリング強化 21 @2024 WealthNavi Inc.
新たな課題 / 次への取り組み ● Read/Write 両⽅のスケーリング ○ ⽇々増え続けるレコード ○ 書き込みパフォーマンスの低下 ● データモデルの改善 ○ データ構造 ○ ライフサイクル ● ホットキースロットリングの回避 ○ DynamoDB特有の特定のパーティションキー読み取り集中による速度制限 ● コスト改善 ○ DynamoDBの消費キャパシティとデータストレージ量の調整 ○ データサイズに応じた課⾦ 22 @2024 WealthNavi Inc.
1. 現行のアーキテクチャ 2. リアーキテクティング 3. 取り巻く状況の変化 4. Next Action 5. さいごに 23 @2024 WealthNavi Inc.
Appendix 定期的にWealthNaviの開発(技術‧組織)に関する情報を発信しています。 開発者ブログ ● 技術広報に関する お問い合わせ先 ● https://zenn.dev/p/wn_engineering ブックマーク追加や記事への「いいね」していただけると嬉しいです ウェルスナビ DevRelチーム([email protected]) 24 @2024 WealthNavi Inc.
【重要な注意事項】 ● 本資料は、断定的判断を提供するものではなく、情報を提供することのみを⽬的としており、いか なる種類の商品も勧誘するものではありません。最終的な決定は、お客様⾃⾝で判断するものと し、当社はこれに⼀切関与せず、また、⼀切の責任を負いません。 ● 本資料には将来の出来事に関する予想が含まれている場合がありますが、それらは予想であり、ま た、本資料の内容の正確性、信頼性、完全性、適時性等を⼀切保証するものではありません。本資 料に基づいて被ったいかなる損害についても、当社は⼀切の責任を負いません。また、当社は、新 しい情報や将来の出来事その他の情報について、更新⼜は訂正する義務を負いません。 ● 本資料を利⽤することによりお客様に⽣じた直接的損害、間接的損害、派⽣的損害その他いかなる 損害についても、当社は⼀切の責任を負いません。 商号等:ウェルスナビ株式会社 金融商品取引業者 関東財務局長(金商) 第2884号 加入協会:日本証券業協会 一般社団法人日本投資顧問業協会 25 @2024 WealthNavi Inc.
ご清聴ありがとうございました 26 @2024 WealthNavi Inc.