Amazon Aurora Day 2018（3/28）

ちょっと放置してしまいました。

Amazon Aurora Day （2018年3月28日開催）

※リンク先、いつまで残るかな？

今回は「Aurora Day」といいつつほとんどPostgreSQL互換の話、それも「Oracleなど（というかほぼOracle）から移行してちょうだいアピール」が中心だったので、当初より最後まで聞く予定はしておらず、Keynote 1からSession 3まで聞いて帰りました。

※すでにMySQL互換を使っているユーザの多くはKeynote 1だけで帰って行ったようです…というか、セッション内容を見てキャンセルしたユーザのほうが多かったかも。私はPostgreSQL互換版の情報も知りたかったので午後まで残りました。

というわけで、個別Keynote／Sessionに分けてではなく、聞いた範囲全体まとめて、かつ気になった点のみの箇条書きです（すでに何度も聞いている話と、一部公表NGっぽい内容は割愛）。

AuroraはAmazon（AWS）が最初から「これ作ってサービスに加えたい」と思って作り始めたサービスではなく、（潜在的な？）大口顧客が欲していたものを考えて作ったら結果的にできたサービス
スキーマデザインとクエリ作成とその最適化はユーザがやること／残りはAWSがやること（フェイルオーバー、バックアップ＆リカバリ機能など）
AWSの上位100顧客のうち3/4が使っている→「プロダクトにお試し導入」的な使い方をしている顧客を含めれば妥当な数か？
最近はNoSQLからSQL（RDBMS）への「出戻り」が増えている
例示されたのは多ノードCassandra vs Auroraクラスタ（OLAP＋OLTP、数百万回の読み込みとバッチ更新）、Aurora側は大きなインスタンスで構成されるクラスタ1～数個、ではなくて小さなインスタンスで構成されるクラスタが10個（シャーディング）→AWSが「推奨」していたやり方とは違うんでないかい？
顧客が↑のような使い方をするので、後々、マルチマスターの話に繋がっていく
Readerのオートスケーリングの話が出たが、Buffer Poolのウォームアップは対応する（した）のだろうか？
20万write/sec以上ならマルチマスターで
単一リージョンマルチマスター、マルチリージョンマルチマスターとも、Oracle RACやPaxos（分散ロック管理や2フェーズコミット、Paxosコミット）との比較で「Auroraのほうがうまく機能する」と自信ありげ→でも前者（単一リージョンマルチマスター）で「ラウンドロビン」というやや不穏なキーワードが…
単一リージョンマルチマスターで複数のDBノードが別々のストレージノードに書き込み→コンフリクトなし（わかる）
単一リージョンマルチマスターで複数のDBノードが同じストレージノードの同じ領域に書き込み→「コンフリクトは発生するが少数のコーディネートで済む」との話だが、「どちらのコミットが先か」って結構難しい問題を孕むのでは？（だから、こういうシステムでは「優先／Learderノード」があったり高精度のクロックを使ったりするんだろうけど）
マルチリージョンマルチマスターのデータレプリケーションはストレージレイヤーで実行、ラグ1秒以内→すごいけど気は遣いそう…
パラレルクエリサポート（ストレージノードの数千のCPUにプッシュダウン／もうすぐリリース）→データ分析しやすくなる
「データに近い場所で処理を実行すると、ネットワークのトラフィックとレイテンシを軽減できる」→この間Oracleのセミナー（大阪のJavaのやつ）で聞いたのと同じ趣旨の話だ
Aurora Serverlessで「Warm Buffer Poolの提供」という話が…コレないと全く使えないはずなので朗報？→スライドには明確な記述がなかった（口頭説明のみ）
ノーマルAuroraのReaderとかのウォームアップ問題も解決してほしいな…
パフォーマンスインサイト、MySQL互換版でも3週間後にリリース予定→Aurora自体のバージョンアップは必要になるのかな？
MySQL 5.7のGTID、マルチソースレプリケーションも近日中に提供予定→これ、AWS的にはあまりサポートしたくないのだろうと思うが（勝手な推測）、潜在的な大口顧客／影響力のある顧客に「これがないとオンプレからの移行も、移行後の運用もできない」と散々言われまくったのでは？（勝手な推測その2）
マルチスレッドスレーブはちゃんと動くようになるのか？
PostgreSQL互換版Auroraの基本構造はMySQL互換版と同じ
PostgreSQL互換版のほうがオリジナルのコードベースをちゃんと使ってるらしい→「互換性のレイヤーがあるのではなく、PostgreSQLの実装をそのまま利用」→だからPostgreSQLとの機能面の互換性は完璧、という趣旨のことを言ってた
本家との比較でVacuum時間を大幅削減
DMS使うならSCTの評価レポートを先に出すべし→どのくらい大変な移行作業になるかが判明するから
直近のアップデートで9.6.6互換に／orafce、prefix拡張モジュールのサポート
PostgreSQL 10互換版、1ヶ月後に出るよ→思ったより早い？
あと、クロスリージョンレプリケーション、アウトバウンドレプリケーション、マルチマスター、サーバレスなども順次対応
ベンチマークの話は色々面白かったけど書けない雰囲気だったので書かない→参加者に公開された資料は多分セッションそのままみたいだけど
初期データロードで面白い現象があったことだけは触れておく→これはOracleが絡まないから公開OKだと思うが、Auroraのほうが本家PostgreSQLより外部キー再構築がかなり遅くて、Vacuumが超高速なのを帳消しにしてる→Auroraのストレージ構造の弱点？Aurora頑張れ
リコーさん、DMSで頑張って行こう、じゃなくて移行→DMS、utf8mb4が使えないというトンデモ仕様が…辛そう
リコーさんのAurora（MySQL互換）フェイルオーバー絡みのトラブルの話のうちの1つはQiitaで見たヤツだった
MariaDB Connector/Jを使う事例だったが、MySQL Connector/Jからの移行はそこそこ大変なはず（ウチは断念した）
ターゲット or ソースDBフェイルオーバーでレプリケーション（DMSのCDC）がコケるのは辛そう
開発／ステージング用のAuroraクラスターをスナップショットから作るのが遅い→同意、ただ、時々失敗する、というのはウチでは経験したことがない→スナップショット取るときにスナップショット名が既存と被ったことを気付かずに処理してトラブったことはあったが
インスタンスだけ削除してクラスターを残すと、S3でスナップショットを保持する場合の5倍の料金でOKなのでそうしている→インスタンスを止めてしまうとBuffer Poolのウォームアップにそれなりに時間が掛かるはずなんだけど、そこは大丈夫なのかな？（「開発用」ならいいか）
バイナリログなし環境で走るゼロダウンタイムパッチは、かえってトラブルになることがあるので実は怖い
orafce＝PostgreSQL上でOracle DBのいくつかの機能を使えるようにする拡張モジュール→先日のMANABIYAで聞いたばかりだった
全機能で見るとPostgreSQL標準＋orafceはOracleの機能カバー率34%だが、実案件では大体7割を超える→OSSセンタ調べで73%
orafceのデモ、地味にスゴいかもしれないけど、残念ながら画が地味すぎてそのスゴさは伝わってない（と思う）