Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databasesを読む(その7 LESSONS LEARNED)
7 LESSONS LEARNED
ここでは、クラウドで一般的なシナリオとそれに求める期待にフォーカスして、新たな方向性を導き出す。
7.1 マルチテナンシーとデータベースの統合
SaaSでは、一般的にschema/databaseをテナントの単位として、異なる顧客を単一のインスタンスにまとめている。
すべての顧客が一度にアクティブになることはないので、顧客ごとに専用のインスタンスを購入する必要がないので、コストとの削減ができている。
(このモデルは、Salesforce.com のような有名なマルチテナントアプリケーションとは大きく異なる。Salesforce.comでは、マルチテナント・データ・モデルを使用し、複数の顧客のデータを単一のスキーマで統一されたテーブルにまとめ、テナントは行ごとに識別される。)
その結果、多数のテーブルを含むデータベースになる。
小規模なデータベースであっても、150,000テーブルを超える場合もよくある。
これは、dictionaryキャッシュなどのメタデータを管理するコンポーネントに負担がかかる。
さらに重要なのは、このようなお客様が必要としているのは、
- 高レベルのスループットと多くの同時接続を維持すること
- データが使用されたときにのみプロビジョニングされ、支払いが行われるモデル、
- ジッターの低減( 一つのテナントのスパイクが他のテナントに与える影響を最小限になる)
Auroraはこれらをサポートしており、このようなSaaSアプリケーションに非常に適している。
7.2 同時接続が多い状態でのオートスケーリング
突然の予期せぬイベントによるトラフィックのスパイクに対応する必要がある。
ある大手のお客様は、データベースに負荷をかけることなく、通常のピークのスループットを大幅に超えるスパイクが発生した。
このようなスパイクに耐えられるためには、データベースは同時接続の増大をうまくハンドリングすることが重要になる。
Auroraでは、基盤となるストレージシステムが非常にスケーラブルなので、このアプローチは実現可能である。
Auroraのユーザーの中には、毎秒8000以上の接続がある人もいる( per instanceだと思うけどインスタンスサイズの記載がない )
7.3 スキーマの進化
Ruby on Railsのような最新のWebアプリケーションフレームワークは、ORMと深く結合している。
その結果、アプリケーション開発者は簡単にかつ頻繁にデータベースのスキーマを変更できる。
MySQLは自由なスキーマ変更ができる仕組みを提供しているが、殆どのスキーマ変更の実装はテーブルのfullコピーが前提のため、スキーマの変更は辛いものである。
これは実際的な問題なので、Auroraでは効率的なオンライン DDL を実装した。
この実装は下記の通り
- ページ単位でスキーマをバージョン管理し、スキーマ履歴を使って個々のページを必要に応じてデコードする
- modify-on-write (書き込み時に修正するCoWのもじりかな。。。)を使用して個々のページを最新のスキーマに遅延アップグレードする
7.4 可用性とソフトウェアのアップグレード
ユーザーはクラウドネイティブなデータベースに高い期待を寄せていますが、それはAWSのインスタンス群の運用やサーバーへのパッチ適用の頻度と相反することがある。
ユーザーはAuroraを主に本番アプリケーションを支えるOLTPサービスとして使用しているの、中断が発生するとそれはトラウマを引き起こす。
多くのユーザーは、たとえ6週間に1度30秒程度の計画ダウンタイムであっても、私たちが行うデータベースソフトウェアのアップデートに対してひどく脆弱である。
なので、AuroraではZDP（Zero Downtime Patch）機能をリリースした。
これにより、動作中のデータベース接続に影響を与えることなく、パッチを適用することができる。
図12に示すように、ZDPは、アクティブなトランザクションがない瞬間を探し、その瞬間にアプリケーションの状態をローカルのエフェメラルストレージに一時的に保存し、データベースエンジンにパッチを当てた後、アプリケーションの状態を再ロードするという仕組みになっている。
このプロセスでは、ユーザー・セッションはアクティブなままで、エンジンが変更されたことに気がつくことはない。
