JAWS DAYS 2016でAmazon Auroraの話を聞いてきた
3月12日に開催されたJAWS DAYS 2016に行ってきました。いくつかセッションを聞いてきたのですが、今回は[Deep Dive]Amazon Auroraセッションについて復習がてら書きます。
「クラウドソーシングLancers」を支えるAurora
ランサーズでインフラエンジニアをされている金澤さんの発表。実際の運用ノウハウやグラフなどが書かれていて、すごく参考になりました (p.19-26, p.28-32など)。DBパフォーマンスを継続的に計測する仕組みは面白いですね (p.12)。
個人的には、Auroraにしたけどパフォーマンスが上がらなかったところが気になりました。スロークエリが増えた点と、クエリキャッシュのヒット率が低下した点が怪しいらしいです。これが原因だとすると、サービスによっては、逆にパフォーマンスが下がってしまうかもしれません。導入するときは要チェックですね。
Amazon Aurora最新update – Amazon Aurora GAのその後
AWSソリューションアーキテクトの星野さんの発表。Amazon Auroraのアーキテクチャや、MySQLとの仕組み上の違いなどがわかる良い発表でした。資料は見つけられなかったのですが、次の２つが近いと思います。
また、その場では理解できない部分があったので、AWS re:invent 2016の動画を参考にしました。
Amazon AuroraのアーキテクチャというとLog Structured Storageが有名ですが、これについては良い記事が既にあるので省略します。ここでは、ややマイナー感もある以下の３トピックについて、僕の理解を残しておきます。
- ストレージノードの更新
- 非同期グループコミット
- スレッドプール
ストレージノードの更新
Amazon Auroraは3つのAZにある6つのストレージノードにデータを書き込みます。このスライドは、各ストレージノードで行われている処理を説明しています。
ポイントとしては、２で永続化処理が行われたら、すぐにACKを返しているところだと思います。レイテンシに影響が出る処理は１と２だけで、残りは非同期に処理しています。
面白いのは、４でGossipプロトコルを使っているところです。GossipはHashicorpのConsul/Serfで有名になった気がしますが、こんなところでも使われているんですね。ストレージノード間で書き込み情報を交換して、書き込みができていないノードがあった場合に補完しているようです。
非同期グループコミット
このスライドはAuroraの非同期グループコミットについて説明しています。
従来のグループコミットの問題点として、最初にコミットしようとしたWriterのレイテンシが長くなる、と指摘しています。従来の方法は、バッファが一杯になるか一定時間経過するまで、ディスクへの書き込みを待っていたようです。そのため、まとめてコミットされるグループのうち、最初にコミット要求を出したWriterは待ち時間が長くなると。詳しくないですが、MySQLのグループコミットはこういう実装になっているのでしょうか。
これがAuroraになると、コミット要求が来たら、非同期に動くスレッドがどんどんストレージノードに書き込み要求を出すようです。そのため、最初にコミット要求を出したWriterが不利になりにくいようです。ちょっとこの理解でいいか自信がないですが。。。
スレッドプール
最後はスレッドプールの話題です。MySQLのコミュニティ版はスレッドプール機能がないため、接続数の増加に対してスケールしにくい問題があります。特にコンテキストスイッチのコストが問題になります。また、MySQLのエンタープライズ版はスレッドプール機能をもちますが、処理がストールしているかどうかを決める閾値の設定が大変なようです。
Auroraでは、サイズを動的に調整するスレッドプールが実装されているようです。これにより、一時的な接続数の増加等にも耐えられるようです。
まとめ
JAWS DAYS 2016の[Deep Dive]Amazon Auroraセッションについて書きました。Amazon Auroraについて仕組みから実践まで幅広く知ることが出来る良い機会でした。6月のAWS Summit Tokyoも楽しみですね！
