Amazon Aurora (MySQL-compatible edition) Deep Dive

Size: px

Start display at page:

Download "Amazon Aurora (MySQL-compatible edition) Deep Dive"

ともあきかくはり
6 years ago
Views:

Amazon Aurora (MySQL-compatible edition) Deep Dive Amazon Web Services Japan K.

2 内容についての注意点本資料では 2017 年 6 1 時点のサービス内容および価格についてご説明しています最新の情報は AWS 公式ウェブサイト ( にてご確認ください資料作成には分注意しておりますが資料内の価格と AWS 公式ウェブサイト記載の価格に相違があった場合 AWS 公式ウェブサイトの価格を優先とさせていただきます価格は税抜表記となっています本居住者のお客様が東京リージョンを使する場合別途消費税をご請求させていただきます AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change in accordance with the AWS Customer Agreement available at Any pricing information included in this document is provided only as an estimate of usage charges for AWS services based on certain information that you have provided. Monthly charges will be based on your actual use of AWS services, and may vary from the estimates provided.

3 Amazon Aurora の特徴ハイパフォーマンススケーラブル MySQL5.6 互換セキュリティにも配慮フルマネージド可性耐久性

Amazon Aurora の価格 vcpu Mem Hourly Price db.t2.small 1 2 $0.063 db.t2.medium 2 4 $0.125 db.r3.large 2 15.25 $0.35 db.r3.xlarge 4 30.5 $0.70 db.r3.2xlarge 8 61 $1.

4 Amazon Aurora の価格 vcpu Mem Hourly Price db.t2.small 1 2 $0.063 db.t2.medium 2 4 $0.125 db.r3.large $0.35 db.r3.xlarge $0.70 db.r3.2xlarge 8 61 $1.40 db.r3.4xlarge $2.80 *NEW* *NEW* ライセンス料は不要ロックインもない使った分だけ課 db.r3.8xlarge $5.60 ストレージ : $0.120/GB/ 月 IO 課金 : $0.240/100 万リクエスト東京リージョンの価格

5 アーキテクチャ

6 Aurora のストレージ SSDを利したシームレスにスケールするストレージ 10GBから64TBまでシームレスに動でスケールアップ AZ 1 AZ 2 AZ 3 SQL Transactions Caching 実際に使った分だけ課標準で可性を実現 3AZ に 6 つのデータのコピーを作成 Log structured Storage Amazon S3

7 ストレージノードクラスタ Protection Group 毎に 6 つのストレージノードを使各ログレコードは Log Sequence Number(LSN) を持っており不重複しているレコードを判別可能不している場合はストレージノード間で gossip protocol を利し補完をう

8 ディスク障害検知と修復 2 つのコピーに障害が起こっても読み書きに影響は無い 3 つのコピーに障害が発しても読み込みは可能動検知修復 AZ 1 AZ 2 AZ 3 SQL Transactio n Caching AZ 1 AZ 2 AZ 3 SQL Transaction Caching 読み込み可能読み書き可能

9 IO traffic in Aurora ( ストレージノード ) IO FLOW Primary instance Peer storage nodes LOG RECORDS 4 ACK INCOMING QUEUE 2 PEER-TO-PEER GOSSIP SORT GROUP STORAGE NODE UPDATE QUEUE HOT LOG 3 1 COALESCE 5 POINT IN TIME SNAPSHOT GC DATA BLOCKS 7 SCRUB 8 1 レコードを受信しインメモリのキューに追加 2 レコードを永続化して ACK 3 レコードを整理してギャップを把握 4 ピアと通信して埋め 5 ログレコードを新しいバージョンのデータブロックに合体 6 定期的にログと新しいバージョンのブロックを S3 に転送 7 定期的に古いバージョンのガベージコレクションを実施 8 定期的にブロックの CRC を検証 6 OBSERVATIONS S3 BACKUP 全てのステップは同期ステップ 1 と 2 だけがフォアグラウンドのレイテンシーに影響インプットキューは MySQL の 1/46 (unamplified, per node) レイテンシーにセンシティブな操作に向くディスク領域をバッファーに使ってスパイクに対処

10 セキュリティデータの暗号化 AES-256 ( ハードウエア援 ) ディスクと Amazon S3 に置かれている全ブロックを暗号化 AWS KMS を利したキー管理 SSL を利したデータ通信の保護標準で Amazon VPC を使ったネットワークの分離ノードへ直接アクセスは不可能 Application SQL Transactions Caching Storage 業界標準のセキュリティとデータ保護の認証をサポート Amazon S3

11 フェイルオーバとリカバリ

12 フェイルオーバとリプレースリードレプリカが存在する場合は 1 分程でフェイルオーバ可能 RDS for MySQL よりも速にフェイルオーバ可能リードレプリカが存在しない場合は分程 Multi-AZ 配置として別 AZ で起動可能 RDS for MySQL と違いリードアクセス可能

13 速でより予測可能なフェイルオーバー時間 MYSQL DB failure Failure detection DNS propagation App running Recovery Recovery AURORA WITH MARIADB DRIVER DB failure Failure detection DNS propagation sec Recovery 3-20 sec App running

14 Database fail-over time 0-5s 30% of fail-overs 5-10s 40% of fail-overs 35.00% 50.00% 30.00% 25.00% 40.00% 20.00% 15.00% 10.00% 30.00% 20.00% 5.00% 0.00% % 0.00% s 25% of fail-overs 20-30s 5% of fail-overs 60% 50% 20% 40% 15% 30% 10% 20% 10% 0% % 0%

15 Streaming backup と PITR Amazon Aurora では各セグメント毎に Amazon S3 へ継続的に増分バックアップを取得している Backup retention period でバックアップを残す期間を指定可能 Amazon Aurora が使しているディスクの仕組みによりパフォーマンスへ影響を与えない PITR で 5 分前から Backup Retention Period までの任意の位置に秒単位で復元可能

16 Streaming backup Segment snapshot Log records Segment 1 Segment 2 Segment 3 Recovery point Time 各セグメントの定期的な Snapshot は並列でわれ redo log はストリームで継続バックアップのために S3 に送られるパフォーマンスや可性に対する影響は無しリストアでは適切なセグメントの Snapshot とログストリームをストレージノードに転送し並列で同期で適していく

17 Writer / Reader ノードの識別 innodb_read_only を参照 SHOW GLOBAL VARIABLES LIKE 'innodb_read_onlyʼ; OFF: Writer ON: Reader アプリケーションやドライバで Aurora ノードに対する負荷分散やフェイルオーバーロジックの実装に利可能

18 SQL によるフェイルオーバのテスト SQL によりノードディスクネットワーク障害をシミュレーション可能データベースノードのクラッシュをシミュレート : ALTER SYSTEM CRASH [{INSTANCE DISPATCHER NODE}] レプリケーション障害をシミュレート : ALTER SYSTEM SIMULATE percentage_of_failure PERCENT READ REPLICA FAILURE [ TO ALL TO "replica name" ] FOR INTERVAL quantity [ YEAR QUARTER MONTH WEEK DAY HOUR MINUTE SECOND ]; 他にもディスク障害をシミュレートディスクコンジェスションをシミュレート

19 Amazon Aurora Driver

20 Aurora Driver MariaDB Connector/J 以降に含まれているリリースノートには明確に Aurora の記述は無いがドキュメント中に記載 Amazon Linux より rpm を提供現在の提供機能 Fast failover Auto node discovery

21 Aurora Driver

22 パフォーマンス Tips

23 インスタンスサイズによるスケール WRITE PERFORMANCE READ PERFORMANCE Aurora MySQL 5.6 MySQL 5.7 AuroraはRead/Writeパフォーマンス共にインスタンスサイズに例してスケール

24 チューニング指針 Amazon Aurora は MySQL と較してインスタンスリソースを効率的に最限利する設計 CPU やメモリの利率がめだがパフォーマンスに影響が出ない限りは過度な配は必要ない Amazon Aurora は実際のワークロードで性能が発揮できるように開発チューニングがわれている監視項はインスタンスリソースでは無く実際のパフォーマンステストを元にクエリレイテンシやスループット buffer pool の cache hit レートに注

25 チューニング指針まずはデフォルトのパラメータグループを使 Amazon Aurora はデフォルトの設定でパフォーマンスを発揮できるようにチューニング済み適切なインスタンスタイプを選択することが切それでも性能が出ない場合にパラメータグループの変更を検討

26 チューニング Tips 1 トランザクションで量の更新や削除をったり量データのシーケンシャルリードをう場合 1 トランザクションで量の更新削除やシーケンシャルリードをう場合 Amazon Aurora のアーキテクチャに合わせてクエリを実することで性能を向上させることが可能

27 チューニング Tips SELECT (Parallel Read Ahead で大幅性能改善 ) #1> SELECT * FROM Table; #1> SELECT * FROM Table WHERE id BETWEEN 1 AND 10000; #2> SELECT * FROM Table WHERE id BETWEEN AND 20000; #3> SELECT * FROM Table WHERE id BETWEEN AND 30000; #4>... DELETE / UPDATE #1> DELETE * FROM Table WHERE id >= ; #1> DELETE FROM Table WHERE id BETWEEN AND 20000; #2> DELETE FROM Table WHERE id BETWEEN AND 30000; #3> DELETE FROM Table WHERE id BETWEEN AND 40000; #4>...

28 新しいメトリクス画 Throughput Select Commit DML/DDL Latency Select Commit DML/DDL Cache Hit Ratio Buffer Cache Result Set Deadlocks Login Failures Blocked Transactions

29 メトリクススキーマ

30 メトリクススキーマ INFORMATION_SCHEMA.REPLICA_HOST_STATUS mysql.ro_replica_status mysql> SELECT SERVER_ID, REPLICA_LAG_IN_MILLISECONDS, SESSION_ID FROM INFORMATION_SCHEMA.REPLICA_HOST_STATUS; SERVER_ID REPLICA_LAG_IN_MILLISECONDS SESSION_ID demo-db c35a1c-2f61-11e5-96de-06be620fb7bd demo-db02 0 MASTER_SESSION_ID demo-db b000-2f61-11e5-9bf c13435b

31 拡張モニタリング CPU Utilization User System Wait IRQ Idle Network これらのメトリクスを最短 1 秒間隔で取得可能 Rx per declared ethn Tx per declared ethn Processes Num processes Num interruptible Num non-interruptible Num zombie Process List Process ID Process name VSS Res Mem % consumed CPU % used CPU time Parent ID Memory MemTotal MemFree Buffers Cached SwapCached Active Inactive SwapTotal SwapFree Dirty Writeback Mapped Slab Device IO TPS Blk_read Blk_wrtn read_kb read_ios read_size write_kb write_ios write_size avg_rw_size avg_queue_len File System Free capacity Used % Used

32 拡張モニタリング CloudWatch Logs にメトリクス送信可能 CloudWatch logs->lambda- >Elasticsearch Service 連携も容易 Kibana を使ってアプリケーション DB サーバメトリクスクエリのパフォーマンスを箇所で閲覧可能

33 Amazon Aurora への移

34 マイグレーション時の注意 Amazon Aurora は InnoDB / ROW_FORMAT=Dynamic のみサポート InnoDB 以外のストレージエンジンや ROW_FORMAT=COMPRESS は対応マイグレーション時に動でからコンバートされるが事前に動で対応ストレージエンジンや ROW FORMAT への変換を推薦 White paper:

35 RDS for MySQL からマイグレーションマネージメントコンソールから数クリックで Amazon Aurora へ移可能 RDS for MySQL のスナップショットから Amazon Aurora へマイグレーション可能 RDS for MySQL は 5.6 を使う必要がある

36 RDS MySQL DB インスタンスから Amazon Aurora Read Replica を作成 RDS MySQL インスタンスから Amazon Aurora にダウンタイムを最限に移する場合 Snapshot から Aurora クラスタを起動し動でレプリケーションを設定する必要があったこの機能を利することによってワンクリックで RDS MySQL の Snapshot から Aurora Read Replica を起動しレプリケーションの設定まで動でわれる

37 RDS MySQL DB インスタンスから Amazon Aurora Read Replica を作成 Write Application Read RDS MySQL5.6 (Master) Aurora (Writer) RDS MySQL の RR を作る感覚で Aurora クラスタへレプリケーション環境を自動で作成 Aurora (Reader)

38 MySQL スナップショットバックアップからの移 Percona Xtrabackup を利して作成したバックアップデータを利してオンプレミス環境や Amazon EC2 上の MySQL から Amazon Aurora クラスへ移可能 mysqldump と較したテストで約 20 倍速に移可能 S3 にアップロードしたバックアップデータを利アップロードには Management Console や CLI tools データサイズがきい場合は AWS Import/Export Snowball を利して S3 へ転送する

39 改善をって来た機能

40 Reader Endpoint の追加 Amazon Aurora cluster 内の Reader に単のエンドポイントを提供 Reader が Failover した場合は再接続をうことで新しい Reader に接続が可能 Round Robin で接続メリット Load Balancing クラスタエンドポイントに接続することで DB クラスタ内のリードレプリカ間でコネクションのロードバランシングが可能 Higher Availability 複数の Aurora レプリカを Availability Zone 毎に配置しリードエンドポイント経由で接続することが可能今まで HAproxy などで分散されていたは置き換えることでシンプルに負荷分散注意点 DNS ベースなのでアプリケーションやドライバ側で IP アドレスのキャッシュ周りの設定の確認や failover のテストを推薦 Reader が 1 インスタンスもいなくなった場合は Writer へ failback をう

インスタンスもいなくなった場合は Writer に failback Aurora Reader VPC subnet

41 Reader Endpoint クラスタ内の Reader にラウンドロビンで接続 VPC subnet Aurora Writer Read リーダエンドポイント VPC subnet 常に Reader に接続されるが Reader が 1 インスタンスもいなくなった場合は Writer に failback Aurora Reader VPC subnet Availability Zone A Aurora Reader VPC subnet Availability Zone B Reader の追加削除は動でわれる

42 IAM Authentication Integration Amazon Aurora へログインするための認証に IAM が利可能に (1.10 以降 ) IAM のリソース制限を利可能パスワードとして Signature Version 4 を利 (15 分間有効の時 token) SSL 接続が必須データベースアクセスに必要な認証情報を EC2 インスタンスなどに配置しなくても良い AWS SDK や AWS CLI Tools 対応

43 IAM Authentication Integration CREATE USER iam-database-user IDENTIFIED WITH AWSAuthenticationPlugin as 'RDS'; server SSL 接続

44 Lambda Function Integration Amazon Aurora 内から AWS Lambda を呼び出せるストアードプロシジャーとして実 (mysql.lambda_async) 同期で Lambda を実する IAM Role で事前に Aurora へ権限を付与しておく DELIMITER ;; CREATE PROCEDURE SNS_Publish_Message (IN subject VARCHAR(255), IN message TEXT) LANGUAGE SQL BEGIN CALL mysql.lambda_async( Lambda ARN', CONCAT('{ "subject" : "', subject, '", "message" : "', message, '" }') ); END ;; DELIMITER ;

45 Load Data From S3 S3 バケットに保存されたデータを直接 Aurora にインポート可能テキスト形式 (LOAD DATA FROM S3) XML 形式 (LOAD XML FROM S3) LOAD DATA INFILE とほぼ同様のオプションをサポート ( 圧縮形式のデータは現在未サポート ) Manifest による括ロードにも対応 (Version 1.11 以降 ) <row> <column1>value1</column1> <column2>value2</column2> </row> <row> <field name="column1">value1</field> <field name="column2">value2</field> </row> <row column1="value1" column2="value2" /> <row column1="value1" column2="value2" />

46 spatial index 空間インデックスサポート Amazon Aurora は今までも GEOMETRY 型や ST_Contains, ST_Crosses や ST_Distance といった spatial query が利可能きなデータセットに対してスケールするには不分な点や制限があった Amazon Aurora では dimensionally ordered space-filling curve を利しスケールし速かつ正確に情報を取得できる改善をった MySQL5.7 と較して最 2 倍のパフォーマンス

Spatial Index Benchmarks Sysbench points and polygons R-Tree MySQL 5.

7 Z-index / Aurora (dimensionally ordered space filling curve) 0 Select-only

47 Spatial Index Benchmarks Sysbench points and polygons R-Tree MySQL Aurora MySQL 5.7 Z-index / Aurora (dimensionally ordered space filling curve) 0 Select-only (reads/sec) Write-only (writes/sec) r3.8xlarge using Sysbench on <1GB dataset Write Only: 4000 clients, Select Only: 2000 clients, ST_EQUALS

Latch-free queue Write to File Connect Connect Create event string Write to File Write to File MySQL 5.

48 Advanced Auditing MariaDB server_audit plugin Aurora native audit support Query Query Create event string DDL DDL Create event string Write to File DML DCL Create event string DML DCL Create event string Create event string Latch-free queue Write to File Connect Connect Create event string Write to File Write to File MySQL 5.7 Aurora We can sustain over 500K events/sec Audit Off 95K 615K 6.47x Audit On 33K 525K 15.9x Sysbench Select-only Workload on 8xlarge Instance

49 Zero downtime patch (ZDP) コネクションを切断すること無くオンラインでパッチを適 5 秒程度スループットの低下が起こるがアプリケーションとの接続を維持したままパッチを適可能に (1.10 以降 ) ベストエフォート既に開かれている SSL コネクションアクティブなロックトランザクションの完了やテンポラリテーブルの削除を待機しパッチ適可能なウインドウが出来た場合ゼロダウンタイムパッチとして適ゼロダウンタイムパッチで適出来るウインドウがなかった場合通常のパッチ適プロセスを実以下の条件では通常通りのパッチ適プロセスを実施バイナリログを有効にしている SSL を利した接続をっており ZDP のリトライ回数内に接続が終了しない

50 Zero downtime patch (ZDP) Before ZDP セッションはパッチ適時に切断される Net stat e Net state App state App state Old DB Engine New DB Engine Storage Service With ZDP パッチ適中でもセッションは維持される Networking state Application state Old DB Engine New DB Engine Storage Service

51 性能安定向上に対する新機能

52 Cached read performance Catalog concurrency: データディクショナリの同期とキャッシュ破棄の効率化 NUMA aware scheduler: NUMA を考慮したスケジューラへ変更すること複数 CPU が搭載されているインスタンスで性能向上 Read views: read view を作成する際にラッチフリーな read view を作成するアルゴリズムに変更 25% Throughput gain MySQL 5.6 MySQL 5.7 Aurora 2015 Aurora ,000 read requests/sec * R3.8xlarge instance, <1GB dataset Sysbench

Non-cached read performance Smart scheduler: IO ヘビー CPU ヘビーなワークロードそれぞれに動的に処理スレッドを割り当てるスケジューラに変更 Smart selector: 最も良いパフォーマンスのストレージノードにあるデータを選択することでリードレイテンシーを軽減 Logical read ahead (LRA):

53 Non-cached read performance Smart scheduler: IO ヘビー CPU ヘビーなワークロードそれぞれに動的に処理スレッドを割り当てるスケジューラに変更 Smart selector: 最も良いパフォーマンスのストレージノードにあるデータを選択することでリードレイテンシーを軽減 Logical read ahead (LRA): btree の順序に応じて事前に page を読み込んで置くことで IO wait を軽減 10% Throughput gain MySQL 5.6 MySQL 5.7 Aurora 2015 Aurora ,000 requests/sec * R3.8xlarge instance, 1TB dataset Sysbench

54 Insert performance Root プライマリーキーでソートされているデータのバッチインサートの速度を改善インデックス査をう際のカーソル位置をキャッシュ R0 R1 Index R2 R3 R4 R5 Index R6 R7 R8 データパターンに応じて動的に機能を有効無効化ツリーを下向に査する際のラッチロックの競合を軽減 MySQL: 全てのINSERTがrootからB-treeをトラバースする Root Index Index 双向で全ての INSERT ワークロードで有効 LOAD INFILE, INSERT INTO SELECT, INSERT INTO REPLACE, Multi-value inserts. R0 R1 R2 R3 R4 R5 Aurora: indexトラバースを抑制 R6 R7 R8

55 Faster index build MySQL 5.6 は Linux の先読みを活しているため btree に連続したブロックアドレスが必要そのためエントリーをトップダウンで新しい btree に挿する際に分割と多くオンロギングが発 Aurora は tree 内のポジションを元にブロックをスキャンしてプリフェッチしリーフブロックを作製してからブランチを作製していく分割が発しない各ページは 1 度のみ参照される 1 ページに 1 ログレコード 2-4X better than MySQL 5.6 or MySQL 5.7 Hours r3.large on 10GB dataset r3.8xlarge on 10GB dataset r3.8xlarge on 100GB dataset RDS MySQL 5.6 RDS MySQL 5.7 Aurora 2016

Lab mode 今後提供予定の機能を試すことが可能 DB パラメータグループ aurora_lab_mode 変数で設定可能開発中の機能なので本番適ではなく検証的でお使い下さい GA クオリティですが全てのワークロードで性能が発揮出来るか検証をっている段階です

56 Lab mode 今後提供予定の機能を試すことが可能 DB パラメータグループ aurora_lab_mode 変数で設定可能開発中の機能なので本番適ではなく検証的でお使い下さい GA クオリティですが全てのワークロードで性能が発揮出来るか検証をっている段階ですフィードバックをお待ちしています! 現在ご提供中 Lock compression ロックマネージャーが利するメモリを最 66% 削減 OOM を起こさず更に多くのロックを同時に取得することが可能に Fast DDL nullable カラムをテーブルの最後に追加する場合にデータ件数によらず速に変更がなえます

57 Fast DDL: Aurora vs. MySQL MySQL Amazon Aurora Root table name operation column-name time-stamp Index Index Table 1 Table 2 Table 3 add-col add-col add-col column-abc column-qpr column-xyz t1 t2 t3 Leaf Leaf Leaf Leaf フルテーブルコピー : 全てのインデックスを再構築 - 数時間から数かかることも DML クエリ実のために時領域が必要 DDL クエリが DML クエリスループットに影響 DML クエリ実中にテーブルロックが発メタデータテーブルにエントリーを追加しスキーマバージョニングを利変更を適するために最新のスキーマへブロックをアップグレードする際は modify-on-write 現在はテーブルの最後に Nullable なカラムを追加する場合に対応

58 Fast DDL performance Aurora MySQL 5.6 MySQL 5.7 On r3.large 10GB table 0.27 sec 3,960 sec 1,600 sec 50GB table 0.25 sec 23,400 sec 5,040 sec 100GB table 0.26 sec 53,460 sec 9,720 sec Aurora MySQL 5.6 MySQL 5.7 On r3.8xlarge 10GB table 0.06 sec 900 sec 1,080 sec 50GB table 0.08 sec 4,680 sec 5,040 sec 100GB table 0.15 sec 14,400 sec 9,720 sec

59 さらなる改善に向けて

60 Database backtrack

61 How does it work? t 0 t 1 Invisible t 2 t 4 Invisible t 3 Rewind to t 3 Rewind to t 1 t 0 t 1 t 2 t 3 t 4 DB の貫した状態を提供するためにログストリーム中のログを LSN ツリー内のブランチを元に可視不可視にする最初の t2 から t1 への rewind は紫のログを不可視にする次の t4 から t3 へ DB を rewind する場合と紫のログを不可視にする

62 Database backtrack vs Offline Point in Time Restore (PiTR) Database backtrack Database backtrack は現在のデータベースの状態を変更数テラバイトのテータベースでも数秒で利可能になる追加のストレージの料は発しない複数回の PITR のイテレーションの実施も現実的購した rewind ストレージを元にした rewind period 内の範囲で実可能 Cross-region online PiTR は未サポート Offline PiTR PITR は現在の DB のバックアップから所望の時点の新しい DB を作成数テラバイトのデータベースをリストアするのに数時間かかるリストアされたそれぞれの DB 毎にストレージ料がかかる複数回のオフライン PITR は時間を消費するオフライン PITR はスナップショットか設定したバックアップウインドウ内で実可能 Aurora は Cross-region PITR をサポート

63 Database cloning

64 Database cloning ストレージコストを増やすことなくデータベースのコピーを作成データをコピーするわけではないためクローンの作成はほぼ即座に完了データのコピーはオリジナルボリュームとコピー先のボリュームのデータが異なる場合の書き込み時のみ発 Dev/test applications Clone Benchmarks Clone Clone ユースケースプロダクションデータを使したテストデータベースの再構成プロダクションシステムに影響を及ばさずに分析的で特定の時点でのスナップショットを保存 Production applications Production applications Production database

65 まとめ

66 Amazon Aurora クラウド時代に Amazon が再設計した RDBMS MySQL5.6 と互換があり既存の資産を活かしやすいいクエリ実並列度データサイズがきい環境で性能を発揮 Amazon Aurora はコネクション数やテーブル数が多い環境で優位可性実環境での性能向上を実現するための多くのチャレンジを継続してっている

67 Thank you!

PowerPoint Presentation

PowerPoint Presentation Amazon Aurora deep dive 性能向上の仕組みと最新アップデート Yutaka Hoshino, Solutions Architect Amazon Web Services Japan K.K. 2016/6/2 自己紹介星野豊 (ほしのゆたか) @con_mame conmame ソリューションアーキテクト DB Specialized SA メディア系のお客様や大規模なWebサービス企業様を担当