Aurora Serverless からAurora Serverless v2への課題と知見を 論文から読み解く VRC技術・学術系イベントHUB ✕ #Vketステージ コラボ 第21回 分散システム集会 on VRChat @bootjp / ぶーと 

本日の発表の流れ ● 自己紹介 ● Aurora Serverlessとは ○ Auroraとは、Aurora Serverlessとは... ● Aurora Serverles v1で抱えていた課題 ○ Proxyのボトルネック、Proxyのコード追従コスト、マイグレーションに再起動が必要... ● Aurora Serverless v2による改善 ○ Proxy層の廃止、インプレーススケーリング、ライブマイグレーション... ● 評価手法と評価結果 ● 展望 ● まとめ ● 質疑応答 

自己紹介 分散システム集会の主催の一人。 分散合意アルゴリズムのRaftや 分散KVS、TiKV、Redisが好きです。 仕事では、マイクロサービス／マルチプロダク ト構成へ展開できる、疎結合なイベント基盤の 設計、実装をしています。 ぶーと @bootjp 

本日の発表の流れ ● 自己紹介 ● Aurora Serverlessとは ○ Auroraとは、Aurora Serverlessとは... ● Aurora Serverles v1で抱えていた課題 ○ Proxyのボトルネック、Proxyのコード追従コスト、マイグレーションに再起動が必要... ● Aurora Serverless v2による改善 ○ Proxy層の廃止、インプレーススケーリング、ライブマイグレーション... ● 評価手法と評価結果 ● 展望 

Aurora Serverlessとは？ ● Amazon Web Serviceが提供するオンデマンドスケールするAmazon Aurora… 

Aurora Serverlessとは？＞Auroraとは？ ● Amazonが作ったMySQL, PostgreSQL互換のDB ● RDS for MySQL, PostgreSQLと異なりAmazonにより結構手が入っている ○ ストレージ層で分散処理をしている ● 今回はこの話をメインで扱わないのでまた今度... 

Aurora Serverlessとは？＞Auroraとは？ ● Amazonが作ったMySQL, PostgreSQL互換のDB ● RDS for MySQL, PostgreSQLと異なりAmazonにより結構手が入っている ○ ストレージ層で分散処理をしている ● 今回はこの話をメインで扱わないのでまた今度... このあたりを勤め先の ブログで書いたので興 味がある人は見てね 

Aurora Serverlessとは？＞Auroraとは？ ● Amazonが作ったMySQL, PostgreSQL互換のDB ● RDS for MySQLRDS for PostgreSQLと異なりAmazonにより結構手が入っている ○ ストレージ層で分散処理をしている ● 今回はこの話をメインで扱わないのでまた今度... Auroraは既存のDBから だいぶ手が入っていて 面白いよ 

Aurora Serverlessとは？＞Auroraとは？ ● Amazonが作ったMySQL, PostgreSQL互換のDB ● RDS for MySQLRDS for PostgreSQLと異なりAmazonにより結構手が入っている ○ ストレージ層で分散処理をしている ● 今回はこの話をメインで扱わないのでまた今度... Auroraは既存のDBから だいぶ手が入っていて 面白いよ 

● Auroraのサーバーレス版 ○ 指定したリソース（ACU）の範囲でインスタンスサイズの管理を自動化してくれる ■ 自動で負荷が高くなればACUをあげる ■ 自動負荷が低くなればACUを下げる ○ ACUはCPUとメモリの単位を抽象かした概念 ■ ACU=2ギビバイトのメモリと対応するCPU ○ Aurora Serverlessとは？＞Aurora Serverless 

● Auroraのサーバーレス版 ○ 指定したリソース（ACU）の範囲でインスタンスサイズの管理を自動化してくれる ■ 自動で負荷が高くなればACUをあげる ■ 自動負荷が低くなればACUを下げる ○ ACUはCPUとメモリの単位を抽象かした概念 ■ ACU=2ギビバイトのメモリと対応するCPU ○ Aurora Serverlessとは？＞Aurora Serverless https://www.amazon.science/publications/resource-management-in-aurora-serverless 本日はこの論文を題材 に話をします。 

本日の発表の流れ ● 自己紹介 ● Aurora Serverlessとは ○ Auroraとは、Aurora Serverlessとは... ● Aurora Serverles v1で抱えていた課題 ○ Proxyのボトルネック、Proxyのコード追従コスト、マイグレーションに再起動が必要... ● Aurora Serverless v2による改善 ○ Proxy層の廃止、インプレーススケーリング、ライブマイグレーション... ● 評価手法と評価結果 ● 展望 ● まとめ ● 質疑応答 

Aurora Serverles v1で抱えていた課題 ● セッション転送方式によるProxy部分のボトルネック ● DBエンジンの機能追加への追従コスト ● スケールアップマイグレーション時の再起動 ○ マイグレーション時の制約 

Aurora Serverles v1で抱えていた課題 > v1のアーキテクチャの概要 ● v1のアーキテクチャ Proxy Aurora Serverless instance Client セッション転送 フロントエンド Proxy 

Aurora Serverles v1で抱えていた課題 > Proxy方式によるボトルネック ● Proxy層の負荷が問題でボトルネックとなることがあった Proxy Aurora Serverless instance Client 

Aurora Serverles v1で抱えていた課題 > 新機能のコード移植コスト ● DBエンジンに新機能が追加されるたびにセッション転送コードを移植する負担も大きい Proxy Aurora Serverless instance Client ここに新たなプロトコルを実装する必要 がある 

● v1ではマイグレーション時に再起動が必要だった ○ not ライブマイグレーション ● すべての種類のセッション状態でのマイグレーションに対応できず ○ 一時テーブルがあったりするとだめらしい ■ やろうと思えばできそうな気がするけど、できないらしい（？） ● マイグレーションできる静止時間を確保する必要がある ○ →スケールできるタイミングが限られる ■ →細かい粒度でのスケールアップを諦め2倍や半分などのスケーリングに ● コスト効率が悪い Aurora Serverles v1で抱えていた課題 > スケールアップ時の再起動 Proxy Aurora Serverless instance old Client Aurora Serverless instance new 一時テーブルの情報 がメモリにしかない とかかも（？） 

● v1ではマイグレーション時に再起動が必要だった ○ not ライブマイグレーション ● すべての種類のセッション状態でのマイグレーションに対応できず ○ 一時テーブルがあったりするとだめらしい ■ やろうと思えばできそうな気がするけど、できないらしい（？） ● マイグレーションできる静止時間を確保する必要がある ○ →スケールできるタイミングが限られる ■ →細かい粒度でのスケールアップを諦め2倍や半分などのスケーリングに ● コスト効率が悪い Aurora Serverles v1で抱えていた課題 > スケールアップ時の再起動 Proxy Aurora Serverless instance old Client Aurora Serverless instance new 一時テーブルの情報 がメモリにしかない とかかも（？） 

本日の発表の流れ ● 自己紹介 ● Aurora Serverlessとは ○ Auroraとは、Aurora Serverlessとは... ● Aurora Serverles v1で抱えていた課題 ○ Proxyのボトルネック、Proxyのコード追従コスト、マイグレーションに再起動が必要... ● Aurora Serverless v2による改善 ○ Proxy層の廃止、インプレーススケーリング、ライブマイグレーション... ● 評価手法と評価結果 ● 展望 ● まとめ ● 質疑応答 

Aurora Serverless v2による改善（詳細は後述） ● Proxy層の廃止 ○ インプレースマイグレーションとライブマイグレーションでProxyを廃止 ○ Proxy層のボトルネックを解消 ○ Proxy層の実装追従コストを解消 ● インプレーススケーリング ○ インプレースでスケールすることにより低遅延でスケーリング ● ライブマイグレーション ○ インプレースでマイグレーションできない場合もライブマイグレーションを行う ○ => マイグレーションできる状態が限られる問題の解消 

Aurora Serverless v2による改善 > インプレーススケーリング ● ホストに余剰がある場合は、ACUの調整だけを行う ○ 低いレイテンシーでDBの拡張を実現している ● リソース使用状況の収集・推定を高頻度（1秒単位）に行う ○ 必要に応じてACUを増やす/減らす ● ホストに余剰がない時はACU変更を凍結 マイグレーションを行う ○ マイグレーションの話は次のスライドで ACUはAurora Capacity Unitといっ てメモリとCPUのリ ソース管理の単位で す。 

Aurora Serverless v2による改善 > ライブマイグレーション ● ホストにリソース余剰がない時はライブマイグレーションを行う ○ フロントエンド層のProxyを廃止 ● ホストを意図的にアンバランスに配置している ○ リソースの空きがあるホストを用意し、ライブマイグレーション先を確保している ○ 異なるワークロードを同一ホストに配置し、パッキング密度を上げている ■ CPU集約型、メモリ集約型、ネットワーク集約型 ● データベース内の内部メトリクスを用いて精度の高いマイグレーションが実現 ○ バッファプール使用状況、最大値 ○ ワーキングセットのサイズ推定値 ● Linuxカーネル側へのチューニング ○ メモリオフライニングとコンパクション ライブマイグレー ションはおそらくVM のライブマイグレー ション（明示はされ てないけど...） 

Aurora Serverless v2による改善 > ライブマイグレーション ● Linuxカーネル側へのチューニング ○ メモリオフライニング ■ 未使用メモリ領域を動的にホストへ返却する ○ コンパクション ■ 4KB単位の細かなフリーページを可能な限り2MB単位の大きなブロックにまとめ ● ページフォルト時のオーバーヘッドを抑制 ○ コールドページの特定 ■ カーネルプロセスが常にページを監視しコールドページを特定 ● ファイルベースのコールドページは解放 ● 匿名のコールドページはスワップアウト ○ フリーページの報告 ■ 2MB の連続空きを見つけた場合、ハイパーバイザーに報告しその後ハイパーバイザーがそのメモリを回収する 一部はNitroの機能 

本日の発表の流れ ● 自己紹介 ● Aurora Serverlessとは ○ Auroraとは、Aurora Serverlessとは... ● Aurora Serverles v1で抱えていた課題 ○ Proxyのボトルネック、Proxyのコード追従コスト、マイグレーションに再起動が必要... ● Aurora Serverless v2による改善 ○ Proxy層の廃止、インプレーススケーリング、ライブマイグレーション... ● 評価手法と評価結果 ● 展望 ● まとめ ● 質疑応答 

評価手法と評価結果 ● 評価は以下の二通りで行われた ○ 実際の運用データ ○ シミュレーション結果 ● 評価結果 ○ ほぼインプレーススケーリングで処理可能になった ■ ほぼ=99.98% ○ ライブマイグレーションが必要になった場合 ■ 1回またはそれに近い回数で済んでいる ■ 平均マイグレーション回数が1.56～1.68程度と低い値である ○ ホストが過度の負荷状態に達するケースの割合も低い ■ 再パッキングが必要となる状況が最小限に抑えられている 

本日の発表の流れ ● 自己紹介 ● Aurora Serverlessとは ○ Auroraとは、Aurora Serverlessとは... ● Aurora Serverles v1で抱えていた課題 ○ Proxyのボトルネック、Proxyのコード追従コスト、マイグレーションに再起動が必要... ● Aurora Serverless v2による改善 ○ Proxy層の廃止、インプレーススケーリング、ライブマイグレーション... ● 評価手法と評価結果 ● 展望 ● まとめ ● 質疑応答 

展望 ● リアクティブ制御と、予測的手法との統合によるさらなる最適化の可能性 ○ 時間帯効果のような予測可能なワークロード特性を十分に活用できていない ■ ライブマイグレーションを事前にスケジューリング ■ ホストをより効果的に解放してコストを削減したりできる可能性がある ○ 予測の精度をあげることで、よりコスト効率よく運用が行える余地がある ● 機械学習や強化学習に基づいた高度なワークロード予測を入れることも見据えている 

本日の発表の流れ ● 自己紹介 ● Aurora Serverlessとは ○ Auroraとは、Aurora Serverlessとは... ● Aurora Serverles v1で抱えていた課題 ○ Proxyのボトルネック、Proxyのコード追従コスト、マイグレーションに再起動が必要... ● Aurora Serverless v2による改善 ○ Proxy層の廃止、インプレーススケーリング、ライブマイグレーション... ● 評価手法と評価結果 ● 展望 ● まとめ ● 質疑応答 

まとめ ● Aurora Serverless v1には以下の課題があった ○ Proxy層のボトルネック ○ ProxyのDBエンジンの機能追加への追従コスト ○ スケールアップマイグレーション時の再起動 ■ 結果的にマイグレーションタイミングの制約が強かった ● v2では次の手法を用いた ○ セッション転送のためのProxyを廃止 ■ Proxyのボトルネックと追従コストを解決 ○ スケール時の再起動を不要にし、スケーリングタイミングを柔軟に ■ インプレーススケーリング ● ACUを動的に変更する ■ ライブマイグレーション ● ホストに余剰がない場合ライブマイグレーションを行いダウンタイムを最小化 

質疑応答