内容の正確性には十分な注意を払っていますが、正確性を保証するものではありません。
誤りがこちらよりあればご指摘いただけますと幸いです。
どんなもの？
Amazon Aurora が固定インスタンス方式からオンデマンドでの自動スケールを実現する Aurora Serverless で得られた知見や最適化手法についてまとめているもの
主に Aurora Serverless v1 で顕在化した課題を Aurora Serverless v2 で解決に至るまでをメインに扱っている
v1のアーキテクチャ
- v1ではフロントエンド層のProxyとデータベース層のインスタンスをマッピングすることによりServerlessを実現していた
- しかしワークロードによってはProxy層の性能がボトルネックになることがあった
- 運用の観点ではDBエンジンに新機能が追加されるたびにセッション転送コードを移植する負担も大きい
- データベース層のインスタンスをマイグレーション時に再起動/再構築する必要があった
- マイグレーション時は書き込みなどが少ないタイミングで行う必要があり、柔軟さにかけていた
- 結果としてスケールアップやスケールダウンのタイミングが遅れる問題があった
- セッション転送はすべてのセッション状態（例えば一時テーブルなど）に対応できなかったため、特定のワークロードでの移行が制限される点があった
- マイグレーション時は書き込みなどが少ないタイミングで行う必要があり、柔軟さにかけていた
- セッション転送が停止時間を要求することから、大幅な容量変化（2倍単位）に限定され柔軟なスケーリングが実現しにくく、結果としてコスト効率やパフォーマンスに悪影響が出る可能性があった
先行研究(v1)と比べてどこがすごい？
- 低レイテンシーのスケーリングが可能となった
- よめ細かやかななスケーリングを実現できるため、コスト効率やパフォーマンスの改善ができた
- インプレーススケーリングによるスケーリングとライブマイグレーションによるスケーリングを組み合わせ、より柔軟なコントロールが可能になった
- ライブマイグレーションはホストに余剰がないときであっても、ライブマイグレーションを行うことで、DBを再構築することなくマイグレーションしている
技術や手法のキモはどこ？
インプレーススケーリング
- ホストに余剰がある場合は、不要なマイグレーションを避けACUの調整だけを行うことで、低いレイテンシーでDBの拡張を実現している
- リソース使用状況の収集・推定を高頻度（1秒単位）に行い必要に応じてACUを増やす
- ホストに余剰がある状態（ホットとされていない）ではインプレースでACUを増やす
- ホストが余剰がない（ホット）と判断された場合、ACUの変更を一時的に凍結しACUの変更を防ぐ
ライブマイグレーション
- v1のフロントエンドProxy方式を廃止し、（おそらくVMの）ライブマイグレーションを用いてマイグレーションしている
- ライブマイグレーションを支えるリアクティブな制御
- ホストを意図的に「アンバランス」に制御することでパッキングの最適化をしている
- リソースの空きがあるホストを用意しておくことで、マイグレーション先を確保している
- 異なるワークロード（CPU集約型、メモリ集約型、ネットワーク集約型）を同一ホストに配置することでパッキング密度を向上させている
- データベース内のバッファプールなどの内部メトリクスを用いてより精度の高いマイグレーションが実現されている
- Linuxカーネル側のメモリオフライニングとコンパクションにより、使用されなくなったメモリをホストに素早く返却している
どうやって有効だと判断した？
- 実際の運用データとシミュレーション結果に基づいて評価が行われた
- ほとんどの場合（99.98%前後）のスケールアップ要求がホスト内でのインプレーススケーリングにより処理され、中断なく柔軟にリソースが拡大できた
- ライブマイグレーションが必要になった場合でも、1回またはそれに近い回数で済んでおり、平均マイグレーション回数が1.56～1.68程度と低い値である
- ホストが過度の負荷状態（「ホット」状態）に達するケースの割合も低く、再パッキングが必要となる状況が最小限に抑えられている
議論はある？
- リアルタイムのデータに依拠したリアクティブ制御と、予測的手法との統合によるさらなる最適化の可能性
- 時間帯効果のような予測可能なワークロード特性を十分に活用できておらず、予測技術を導入することで、ライブマイグレーションを事前にスケジューリングしたり、ホストをより効果的に解放してコストを削減したりできる可能性がある
- 現状の実装ではスケールダウンはより保守的に行われる（再度負荷が高くなる可能性があるため）
- 予測の精度をあげることで、よりコスト効率よく運用が行える余地がある
- 将来的には、機械学習（ML）や強化学習（RL）に基づいたより高度な技術をワークロード予測や意思決定に適用することも見据えている
次に読むべき論文は？
- Firecracker: Lightweight Virtualization for Serverless Applications
- iOverbook: Intelligent Resource-Overbooking to Support Soft Real-time Applications in the Cloud
- Remus: Efficient Live Migration for Distributed Databases with Snapshot Isolation
- Control Theory: a Foundational Technique for Self Managing Databases
- Improving Resource Efficiency at Scale with Heracles
memo:
マイグレーションステップ
- ステージ1
- ACUが所定の閾値を超えたているかどうかを判定する
- ステージ2
- マイグレーションの対象とならないインスタンスを、直近にマイグレーションされたなどの条件で除外して、候補数を絞る。
- フィルタ後のインスタンス群に対して、各インスタンスにバイナリ（真偽）で表される各種スコアを算出し、加重和で優先順位を決定する。たとえば、直近にマイグレーションされたか否かを示すスコアなど。
- 各インスタンスについて、退避できれば、ホストのホット状態をより大幅に軽減できるという考えと、インスタンスがまだ使用していないネットワークの受信/送信スループット、EBS スループット、EBS IOPS の未使用割合の線形結合による数値スコアを計算し、加重和によって最終的な数値スコアを得る。候補の中で、最も高い優先度スコアを持つインスタンスが選定される
- ステージ3
- 対象ホストがアクティブであるか、新しいインスタンスを受け入れてもACUの閾値を超えないか、かつマイグレーションを支える帯域を持ち、さらにインスタンス数が所定の閾値未満であるかといったフィルタを適用する。
- 障害耐性のため、同一クラスターのインスタンスは別ホストに配置すること、また最近故障や失敗したマイグレーションに関与していないホストが望ましいとするなどの観点から、ホストの優先順位を決定する。
- 数値スコアを 2 つ計算し、それらを積の形で組み合わせて最終スコアを求める（スコアの高いホストが望ましいとみなされる）。1 つ目は、いわばビンパッキングの最適フィット（best-fit）的なヒューリスティックであり、ホスト上の負荷と新たに追加されたインスタンスに対応する熱の比率を基に算出されます。2 つ目は、利用率の最も高いリソース（CPU・メモリ・ネットワーク）に対応する ACU の比率の補数として計算され、これによりリソース間の偏りを低減する効果があります。
セッション転送の課題
- v1ではフロントエンドのProxy層とデータベースに分離されていた
- v1ではこのフロントエンド層のProxyによるセッション転送によるスケーリングを実現していた
- しかし、ワークロードによってはProxy層の性能がボトルネックになることがあった
データベース再構築時の停止期間に起因する問題
- 先に記載したようにv1ではセッション転送によるマイグレーションを行っていた
- つまり、バックエンドのデータベースのマイグレーション時にDBエンジンの状態の最初期化とセッション状態の転送を伴う
- データワークロードによっては静穏なタイミングでの転送が困難で、結果としてスケールアップやスケールダウンのタイミングが遅れる問題があった
- セッション転送はすべてのセッション状態（例えば一時テーブルなど）に対応できなかったため、特定のワークロードでの移行が制限される点があった
- セッション転送が停止時間を要求することから、大幅な容量変化（2倍単位）に限定され柔軟なスケーリングが実現しにくく、結果としてコスト効率やパフォーマンスに悪影響が出る可能性があった
