Movatterモバイル変換

Amazon Auroraを使いこなすためのベストプラクティスと最新アップデートAmazon Web Services Japan K.K.#AuroraMatsuri

⾃⼰紹介• 星野豊 (ほしのゆたか)– @con_mame– facebook.com/conmame– データベースソリューションアーキテクト• 経歴– 全てオンプレ環境のインフラエンジニア– 全てAWS環境のインフラエンジニア• 担当– Webサービス / game / Video・Live Streamingなどのメディア系のお客様

Amazon Aurora• re:Invent 2014で発表されたRDSの新しいエンジン• Amazonがクラウド時代にリレーショナル・データベースを作るとどうなるかを1から考え構築– 新しい技術的チャレンジを盛り込んでいる• エンタープライズグレードの可⽤性とOSSレベルのコストを両⽴

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

Amazon Auroraの特徴• MySQL5.6と互換性があるため、既存のアプリケーションを簡単に移⾏可能• ストレージが10GBから64TBまでシームレスに拡張• 3AZに2つずつ、計6つのデータのコピーを保持– S3にストリーミングバックアップを実施• VPC内に起動– Security GroupやNACLを使⽤してアクセスコントロール可能• Amazon Auroraは99.99%の可⽤性を実現するように設計されている

P o s t g r e S Q L F o r A u r o r aAurora is now fully compatible withboth PostgreSQL and MySQL

1/10th The Cost OfCommercial GradeDatabasesFully PostgreSQLCompatibleSeveral times betterperformance than typicalPostgreSQL databaseScalable,Durable and SecureMigrate FromRDS For PostgreSQLAmazon Aurora PostgreSQL-Compatible Edition

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

メトリクススキーマ• INFORMATION_SCHEMA.REPLICA_HOST_STATUS• mysql.ro_replica_statusmysql> SELECT SERVER_ID, REPLICA_LAG_IN_MILLISECONDS, SESSION_ID FROMINFORMATION_SCHEMA.REPLICA_HOST_STATUS;+-----------------+-----------------------------------------------------+-----------------------------------------+| SERVER_ID | REPLICA_LAG_IN_MILLISECONDS | SESSION_ID |+-----------------+----------------------------------------------------+-------------------------------------------+| demo-db01 | 18.458999633789062 | 62c35a1c-2f61-11e5-96de-06be620fb7bd || demo-db02 | 0 | MASTER_SESSION_ID || demo-db03 | 19.39299964904785 | 6194b000-2f61-11e5-9bf6-12715c13435b |+-----------------+---------------------------------------+--------------------------------------------------------+

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

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

クラスタエンドポイント• WriterとReaderのセットをクラスタと呼び、クラスタで常にWriter(マスタ)を指すクラスタエンドポイントが存在する• 各Auroraノードは個別にエンドポイントを持っている(⾍眼鏡タブ内のEndpointで確認可能)ReaderWriter

クラスタエンドポイントAvailability Zone A Availability Zone BVPC subnet VPC subnetVPC subnet VPC subnetAurora Writer Aurora Readerクラスタエンドポイント• 各Auroraノードは個別にエンドポイントを持っている• クラスタエンドポイントは、その時アクティブなAurora WriterノードのCNAME• Readは各Readerを参照するWrite

クラスタエンドポイント• フェイルオーバが発⽣すると、Auroraノードの昇格が⾏われ、クラスタエンドポイントの指し先が変わるAvailability Zone A Availability Zone BVPC subnet VPC subnetVPC subnet VPC subnetAurora Writer Aurora WriterクラスタエンドポイントWrite

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

Aurora Driver• MariaDB Connector/J 1.2.0から含まれている– https://mariadb.com/kb/en/mariadb/mariadb-connector-j-120-release-notes/– リリースノートには明確にAuroraの記述は無いがドキュメント中に記載• https://mariadb.com/kb/en/mariadb/about-mariadb-connector-j/• https://mariadb.com/kb/en/mariadb/failover-and-high-availability-with-mariadb-connector-j/#specifics-for-amazon-aurora– 2015.09 Amazon Linuxよりrpmを提供• 現在の提供機能– Fast failover

Aurora Driverhttps://mariadb.com/kb/en/mariadb/failover-and-high-availability-with-mariadb-connector-j/

0.00%5.00%10.00%15.00%20.00%25.00%30.00%35.00%1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 350 - 5s – 30% of fail-overs0.00%10.00%20.00%30.00%40.00%50.00%1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 355 - 10s – 40% of fail-overs0%10%20%30%40%50%60%1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 3510 - 20s – 25% of fail-overs0%5%10%15%20%1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 3520 - 30s – 5% of fail-oversDatabase fail-over time

Auroraのパフォーマンスを引き出すために• クエリ並列度が⾼い、データサイズが⼤きいケースで効果を発揮• ロック機構やQuery Cache、スレッドプールなどに改善を⼊れて性能向上を⾏っている– Query Cacheはwrite heavyな環境ではoffを推奨– 全コアを効率的に利⽤する設計により、CPU利⽤率はMySQLと⽐較して⾼くなるが、性能が落ちにくくなっている

よく⾒ると• CPU / Memoryの利⽤率がMySQLより⾼いがスループットが出ている– 分散ロック機構によりCPUリソースを使いきってスループットを出している

何をみるのか？• よく聞かれる質問– CPU利⽤率⾼いんだけど?– メモリ利⽤量多いんだけど？– Disk IOが多めなんだけど？• ⾒てほしいこと– Auroraはマシンリソースを最⼤限利⽤してスループットを出す設計– システム全体でパフォーマンスが向上– 管理コスト、障害耐性、データ保全性

何をみるのか？• AuroraはMySQL互換ですが、マシンリソースの使い⽅が根本的に違います• Auroraが得意な場⾯・状況を理解してパフォーマンスを測定– マシンリソースを使い切りそうになっても、MySQLと⽐べるとスループットやレスポンスタイムの落ち⽅が緩やか

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

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

チューニングTips• 1トランザクションで⼤量の更新や削除を⾏ったり、⼤量データのシーケンシャルリードを⾏う場合• 1トランザクションで⼤量の更新・削除やシーケンシャルリードを⾏う場合Amazon Auroraのアーキテクチャに合わせてクエリを実⾏することで性能を向上させることが可能• Amazon Auroraは並列でトランザクションが実⾏されるワークロード(実ワークロード)に向けてチューニングされているため、クエリを分割して並列で実⾏

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

パフォーマンスの改善• Large dataset read performance– スケジューラの改善により、IO/CPUヘビーなワークロードでAuroraが動的に処理スレッド数を調整することでIO数/CPU利⽤率のバランスがとれ、性能を向上させる• Fast Insert– Primary keyで並んでいるデータを LOAD DATA や INSERT INTO ... SELECT で並列に実⾏した場合の速度を改善 (将来的には他のワークロードにも適⽤予定)– モニタリング⽤にGlobal変数を追加• aurora_fast_insert_cache_hits: キャッシュのcursorにヒットした• aurora_fast_insert_cache_misses: ヒットせずindexを⾛査した• Parallel Read Ahead– B-Treeスキャン性能を向上させる。Disk pageの読み込みパターンを⾃動的に判断し、事前にフェッチしバッファキャッシュに載せることで速度改善を⾏う。– 現在は、Writerで有効になっており、今後の改善でReaderにも適⽤を⾏う

Amazon Auroraの使いどころ

クエリ同時実⾏数やテーブルサイズが⼤きい• Amazon Auroraに移⾏することで、クエリスループットの向上などが⾒込まれる– マルチコア環境でCPUを効率的に利⽤– 分散ロック機構やQuery Cacheの改善による性能向上• ディスク– データ量の増加に応じてディスク容量を気にする必要が無い– 性能に影響を及ばさずバックアップ

複数のサーバにシャーディングしている• 複数の⼩さいDBを1つにまとめる– コスト効果増⼤と管理コストの軽減– シャーディングをするデータベースを減らすことでアプリケーションの設計を簡略化出来る– 障害時の影響を考慮する必要はある– シャーディングガイド• http://amzn.to/2m1ay4P

改善を⾏って来た機能

Reader Endpointの追加• Amazon Aurora cluster内のReaderに単⼀のエンドポイントを提供– ReaderがFailoverした場合は、再接続を⾏うことで新しいReaderに接続が可能– Round Robinで接続• メリット– Load Balancing – クラスタエンドポイントに接続することでDBクラスタ内のリードレプリカ間でコネクションのロードバランシングが可能。リードワークロードを分散することで利⽤可能なReader間でリソースを効率的に活⽤することができます– Higher Availability – 複数のAuroraレプリカをAvailability Zone毎に配置し、リードエンドポイント経由で接続することが可能。Availability Zoneの可⽤性の問題が万が⼀発⽣した場合、リードエンドポイントを利⽤することで最⼩限のダウンタイムでリードトラフィックを他のレプリカに実⾏可能– 今までHAproxyなどで分散されていた⽅は置き換えることでシンプルに負荷分散• 注意点– DNSベースなのでアプリケーションやドライバ側でIPアドレスのキャッシュ周りの設定の確認やfailoverのテストを推薦– Readerが1インスタンスもいなくなった場合はWriterへfailbackを⾏うため、Reader EndpointがWriterをさす

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

Endpoint活⽤tips• Cluster / Reader endpointを利⽤することでバックエンドのAuroraインスタンスの状態をアプリケーションから意識する必要が軽減されてきた• さらに恩恵を受けるためにアプリケーション / ドライバで適切にリトライを⾏ったり、コネクションプーリングの再接続を設定– アプリケーションの可⽤性の更なる向上

MySQLスナップショットバックアップからの移⾏• Percona Xtrabackupを利⽤して作成したバックアップデータを利⽤してオンプレミス環境やAmazon EC2上のMySQLからAmazon Auroraクラスへ移⾏する– mysqldumptと⽐較したテストで約20倍⾼速に移⾏可能• バックアップデータをS3にアップロードし、そのデータを利⽤– アップロードにはManagement ConsoleやCLI tools、データサイズが⼤きい場合はAWS Import/Export Snowballを利⽤してS3へ転送する• MySQLからAmazon Auroraへレプリケーションを⾏う機能と合わせて利⽤することで、アプリケーションのダウンタイムを短縮可能

クロスリージョンレプリケーション対応• リージョン間でWriterとReaderを配置可能• クロスリージョンレプリケーションのセットアップなどは全てマネージド• コンソールやAPI経由で簡単に構築可能• DRや他リージョンへDBを移設する場合などに利⽤• 注意点• 機能を有効にする前に必ず最新のパッチを適⽤して下さい• バイナリログを利⽤したレプリケーションのため、設定前にDBパラメータグループでbinlog_formatを設定(MIXED推薦)• バイナリログを利⽤したリージョン間レプリケーションのため、⼤きめのレプリカラグが発⽣しやすい

フェイルオーバー順の指定• Amazon Auroraのフェイルオーバーの順位を任意に設定可能– フェイルオーバーで昇格させるReaderの順番を指定可能• 優先的にフェイルオーバー先に指定するReaderを設定可能なため、バッチや集計⽤となどで利⽤している、サービスに組み込みたくないReaderを作ることも可能• 優先度: Tier 0 > Tier 1 > … > Tier 15• 同じ優先度のReaderが存在する場合– Writerよりも⼤きいインスタンス– 優先度もインスタンスサイズも同じ場合は、同じ優先度のReaderから任意に選択される

Cluster View• Amazon Aurora Clusterの情報専⽤の画⾯– Cluster毎に情報を参照出来る– 例: Cluster Snapshotからリカバリを⾏ったり、Cluster内のDBインスタンスを全て削除した場合、Cluster定義のみが残るので、Instance Viewには表⽰されないが、Cluster Viewには表⽰される

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

Advanced AuditingMariaDB server_audit plugin Aurora native audit support• We can sustain over 500K events/secCreate event stringDDLDMLQueryDCLConnectDDLDMLQueryDCLConnectWriteto FileCreate event stringCreate event stringCreate event stringCreate event stringCreate event stringLatch-freequeueWrite to FileWrite to FileWrite to FileMySQL 5.7 AuroraAudit Off 95K 615K 6.47xAudit On 33K 525K 15.9xSysbench Select-only Workload on 8xlarge Instance

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

ゼロダウンタイムパッチNetworkingstateApplicationstateStorage ServiceAppstateNetstateAppstateNetstateBeforeZDPNewDBEngineOld DBEngineNewDBEngineOld DBEngineWithZDPセッションはパッチ適⽤時に切断されるパッチ適⽤中でもセッションは維持されるStorage Service

性能に関する改善• Replication improvements– Readerのbuffer cacheを更新するためのログストリームを改善することで、heavywriteやreadワークロードで、リードパフォーマンスの向上と安定• Throughput improvements for workload with cached reads– Buffer cacheから取得する様なワークロードで、Amazon Auroraはラッチフリーアルゴリズムをread viewに適⽤することでスループットを向上させました– SysbenchのSelect onlyのベンチマークでは、Amazon Auroraは625K reads/sec、MySQL5.7は164K reads/secの結果がみられました• Throughput improvements for workload with hot row contention– Amazon Auroraは新しいロックリリースアルゴリズムを利⽤することで、多くのトランザクションが特定のrowやpageにアクセスするようなワークロードで性能向上を⾏ないました– TPC-Cベンチマークの結果では、MySQL5.7と⽐較して最⼤16倍のスループットとなりました

db.t2.medium インスタンスクラスサポート• 検証・テスト向けにdb.t2.mediumインスタンスをサポート– テストや開発向けに利⽤を推薦– CPUCreditUsageとCPUCreditBalanceの監視を⾏う

Improved index build• secondary indexの作成/変更を⾼速化– db.r3.8xlargeを利⽤した場合、最⼤約75%⾼速化– ボトムアップ⽅式でインデックスを構築し、不要なページ分割を排除することで⾼速

Faster index build§ MySQL 5.6 はLinuxの先読みを活用していますが、これにはbtreeに連続したブロックアドレスが必要です。そのためエントリーをトップダウンで新しいbtreeに挿入する際に、分割とたくさんのロギングを引き起こします。§ Auroraはtree内のポジション(ブロックアドレスではなく)を元にブロックをスキャンしてプリフェッチ§ Auroraはリーフブロックを作製してからブランチを作製していく• 分割が発生しない• 各ページは1度のみ参照される• 1ページに1ログレコード2-4X better than MySQL 5.6 or MySQL 5.7024681012r3.large on 10GBdatasetr3.8xlarge on10GB datasetr3.8xlarge on100GB datasetHoursRDS MySQL 5.6 RDS MySQL 5.7 Aurora 2016

Performance schema• Performance schemaを有効にした場合の性能劣化を最⼩限に– Amazon Auroraチームのベンチマークでは、Sysbenchを⽤いた場合MySQLでは60%性能低下があったが、Amazon AuroraではMySQLと⽐較して1/4の劣化だった– db.r3.8xlargeを⽤いた場合、 Performance schemaを有効にした状態のSysbenchで100K write/sec, 550K reads/sec

性能・安定⾯の向上• Smart read selector– 全てのリードリクエストで、異なるストレージセグメント間で適切なストレージセグメントを選択することでリードレイテンシを改善– SysBenchを⽤いたWriteワークロードのテストで27%性能向上

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) LANGUAGESQLBEGINCALL mysql.lambda_async(’Lambda ARN', CONCAT('{ "subject" : "', subject, '", "message" : "', message, '" }') );END;;DELIMITER ;

Load Data From S3• S3バケットに保存されたデータを直接Auroraにインポート可能– テキスト形式(LOAD DATA FROM S3)・XML形式(LOAD XML FROM S3)– LOAD DATA INFILEとほぼ同様のオプションをサポート (圧縮形式のデータは現在未サポート)<row column1="value1" column2="value2" /><row column1="value1" column2="value2" /><row><column1>value1</column1><column2>value2</column2></row><row><field name="column1">value1</field><field name="column2">value2</field></row>

拡張モニタリング50+ system/OS metrics | sorted process list view | 1–60 sec granularityalarms on specific metrics | egress to Amazon CloudWatch Logs | integration with third-party tools

拡張モニタリングProcess listMetrics list

spatial index• 空間インデックスサポート– Amazon Auroraは今までも地点やエリアを表すためにGEOMETRY型を利⽤可能で、この型を使ってカラムを作成し、ST_Contains,ST_CrossesやST_Distanceといった機能をspatial queryを実⾏するために利⽤可能• ⼤きなデータセットに対してスケールするには不⼗分な点や制限があった– Amazon Auroraではdimensionally ordered space-filling curveを利⽤しスケールし、⾼速かつ正確に情報を取得できる改善を⾏った• MySQL5.7と⽐較して最⼤2倍のパフォーマンス

様々な性能改善• Throughput improvement for workloadswith hot row contention• Insert performanceの向上• などなど

§ プライマリーキーでソートされているデータのバッチインサートの速度を改善。インデックス⾛査を⾏う際のカーソル位置をキャッシュ§ データパターンに応じて動的に機能を有効・無効化§ ツリーを下⽅向に⾛査する際のラッチロックの競合を軽減§ 双⽅向で全てのINSERTワークロードで有効– LOAD INFILE, INSERT INTO SELECT, INSERTINTO REPLACE, Multi-value inserts.Insert performanceIndexR4 R5R2 R3R0 R1 R6 R7 R8IndexRootIndexR4 R5R2 R3R0 R1 R6 R7 R8IndexRootMySQL: 全てのINSERTがrootからB-treeをトラバースするAurora: indexトラバースを抑制

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

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

Amazon Aurora• クラウド時代にAmazonが再設計したRDBMS– MySQL5.6と互換があり既存の資産を活かしやすい• ⾼いクエリ実⾏並列度・データサイズが⼤きい環境で性能を発揮– Amazon Auroraはコネクション数やテーブル数が多い環境で優位性を発揮• ⾼可⽤性・⾼速なフェイルオーバ・PITRを実現するための多くのチャレンジ

[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス

Movatterモバイル変換

Change Language

[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス

Embed presentation

Recommended

More Related Content

What's hot

Viewers also liked

Similar to [Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス

More from Amazon Web Services Japan

[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス