Amazon Aurora 最新アップデートと日本のお客様の移行事例
44
Amazon Aurora 最新アップデートと 日本のお客様の移行事例 Amazon Web Services Japan K.K. Yutaka Hoshino
-
Upload
amazon-web-services-japan -
Category
Technology
-
view
6.413 -
download
3
Transcript of Amazon Aurora 最新アップデートと日本のお客様の移行事例
Amazon Aurora 最新アップデートと日本のお客様の移行事例
Amazon Web Services Japan K.K.
Yutaka Hoshino
自己紹介
• 星野 豊 (ほしの ゆたか)– @con_mame– facebook.com/conmame– ソリューションアーキテクト
• 経歴– ニコニコ動画インフラエンジニア– Cookpadインフラエンジニア
• 担当– Webサービス / game / Video・Live Streamingなどのメディア系
のお客様
Amazon Aurora
2015/7/28 GAリリースVirginia / Oregon / Ireland
2015/10/7 Tokyoリージョンリリース
2016/2/12 Sydneyリージョンリリース
Amazon Auroraローンチイベント @東京
リレーショナルデータベースをもう一度考える
• 今、データベースを再度実装するならどうするか？– 少なくとも1970年代の方法で実装はしない
– AWSサービスを活かすことができ、スケールアウトが簡単で、セルフヒーリングが出来るようなデータベースを作りたいと考えた
Amazon Auroraの特徴
クエリ性能の向上
コストパフォーマンスが良い 高可用性・高耐久性セキュリティにも配慮
MySQL5.6互換スケーラブル
Amazon Auroraの特徴
• MySQL5.6と互換性があるため既存のアプリケーションを簡単に移行可能
• ストレージが10GBから64TBまでシームレスに拡張
• 3AZに2つずつ、計6つのデータのコピーを保持– S3にストリーミングバックアップを実施
• VPC内に起動– Security GroupやNACLを使用してアクセスコントロール可能
• Amazon Auroraは99.99%の可用性を実現するように設計されている
http://bit.ly/1LXB7Jq
Amazon Aurora
• ログとストレージレイヤをシームレスにスケールするストレージサービスに移動
• EC2, Amazon DynamoDB, Amazon SWFなどのAWSサービスを管理コンポーネントに採用
• Amazon S3を利用して99.999999999%の耐久性でストリーミングバックアップ
Logging + Storage
SQL
Transactions
Caching
Amazon S3
Amazon DynamoDB
Amazon SWF
Amazon Route 53
新機能
Enhanced monitoring
50+ system/OS metrics | sorted process list view | 1–60 sec granularity
alarms on specific metrics | egress to Amazon CloudWatch Logs | integration with third-party tools
Enhanced monitoring
Process list
Metrics list
Important systems and OS metrics
User
System
Wait
IRQ
Idle
CPU Utilization
Rx per declared ethn
Tx per declared ethn
Network
Num processes
Num interruptible
Num non-interruptible
Num zombie
Processes
Process ID
Process name
VSS
Res
Mem %
consumed
CPU % used
CPU time
Parent ID
Process List
MemTotal
MemFree
Buffers
Cached
SwapCached
Active
Inactive
SwapTotal
SwapFree
Dirty
Writeback
Mapped
Slab
MemoryTPS
Blk_read
Blk_wrtn
read_kb
read_IOs
read_size
write_kb
write_IOs
write_size
avg_rw_size
avg_queue_len
Device IO
Free
capacity
Used
% Used
File System
Enhanced monitoring
• CloudWatch logsにメトリクスを送信出来る
• CloudWatch logs->Lambda->Amazon Elasticsearch Service連携も容易– Kibanaを使って可視化も可能 (KibanaはAmazon
Elasticsearch Serviceにインストール済)
– アプリケーションやクエリの種類に応じたメトリクスも取得すれば、アプリケーション・DBサーバメトリクス・クエリのパフォーマンスを一箇所で閲覧可能
Enhanced monitoring
• CloudWatch logsからElasticsearch Service
Encryption at rest
• Key Management Service(KMS)を利用し、透過的な暗号化と復号を行う– 暗号化指定はAuroraクラスタ起動時のみ– ストレージ内やスナップショットが暗号化される– 暗号化されたスナップショットを暗号化が無効なAuroraクラスタに復元は
出来ない
• ディスクに書き込まれるタイミングで自動的に実施
• テーブルの中身を暗号化するものでは無い点注意– 実施する場合はアプリケーションなどで実施 (KMSを活用可能)
Performance improvement
• 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を走査した
Lab mode
• 今後提供予定の機能を試すことが出来る– 現在はLogical Read Ahead機能を提供中
– DBパラメータグループ aurora_lab_mode 変数で設定可能
– 開発中の機能なので本番適用ではなく検証目的でお使い下さい
– フィードバックをお待ちしています！
• Logical Read Ahead– Facebook MySQLにも同名の物が有りますがAmazon Aurora
用に独自実装されたものです
メンテナンス方針と最近の改善
Amazon Auroraが取り組んでいること
• パフォーマンスの向上– 様々な環境下でAuroraの性能を発揮出来るように性能改善を各レ
イヤーで実施– マイグレーション速度向上
• 可用性・堅牢性の向上– 耐障害性の向上– Bugの修正やMySQL側のパッチの取り込み
• 安定性の向上
GA後 数ヶ月で改善したこと
書き込みバッチサイズのチューニング
read/write I/O要求送信の非同期化
パージスレッドのパフォーマンス
バルクインサートのパフォーマンス
バッチ操作
フェイルオーバー時間の短縮
mallocの削減
システムコールの削減
Undoスロットのキャッシュパターン
協調したログ適用
その他
binlogと分散トランザクション
ロックの圧縮
先読み(read-ahead)
顧客フィードバック
ホットな行競合
ディクショナリ統計
小さなトランザクションのコードパス
クエリーキャッシュのread/write競合
ディクショナリシステムのmutex
ロック競合
Backport MySQL Bug fix
• Port Bug#16446108 SEGV IN FTSPARSE().• Port Bug#19465984 INNODB DATA DICTIONARY IS NOT UPDATED WHILE RENAMING THE COLUMN.• Port Bug#16834860 FTS CRASH AFTER RENAMING TABLE TO DIFFERENT DATABASE.• Port Bug#18596756 - FAILED PREPARING OF TRIGGER ON TRUNCATED TABLES CAUSE ERROR 1054.• Port Bug#18684393 - METADATA CHANGES MIGHT CAUSE PROBLEMS WITH TRIGGER EXECUTION.• Port Bug#17566396: MATERIALIZATION IS NOT CHOSEN FOR LONG UTF8 VARCHAR FIELD.• Port Bug#16697792: POOR EXECUTION PLAN WHEN ORDER BY WITH LIMIT X• Port Bug#17083851 BACK• Port Bug#11765744 TO 5.1, 5.5 AND 5.6• Port Bug#20788853 MUTEX ISSUE IN SQL/SQL_SHOW.CC RESULTING IN SIG6. SOURCE LIKELY
FILL_VARIABLES• Port Bug#18903155: BACK• Port Bug-18008907 TO 5.5+ VERSIONS.• Port Bug #17607956 Addressed incomplete fix in MySQL full text search affecting tables where the
database name begins with digit. • Adapt fix for a stack overflow error in MySQL 5.7 for Bug#19678930
https://forums.aws.amazon.com/ann.jspa?annID=3455
https://forums.aws.amazon.com/ann.jspa?annID=3396
Amazon Aurora利用事例
国外利用事例
• re:Invent 2015 Keynoteで発表
Amazon Auroraへの移行事例
• 既に日本でも多くのシステムがAmazon Auroraへ移行・検証が進んでいます– エンタープライズシステム・大規模webサービス・スタート
アップ・ソーシャルゲーム
毎日新聞社 様
• 12/6からAWSにフルマイグレーション
• コンテンツを格納しているデータベースは全てAmazon Aurora
• 当初RDS MySQLで検討していたが高速なフェイルオーバー、障害耐性面、MySQLより低コストという理由でAmazon Auroraを採用 (本番移行2週間前に決断・アプリケーションの変更は一切なし)
アーキテクチャ
記事データなど全てAmazon Auroraに格納
移行理由
• MySQLよりコスト減– MySQLだと「インスタンス数×ストレージ料金(使わない分も先
買)」が、Auroraだと「1クラスタ1ストレージ料金(使っている分だけ)」で良いので、大幅にコストが削減できた
– その分、インスタンスの増強に利用）
• 本番移行２週間前の変更だったが、開発したアプリケーションの変更は一切なし– ソースコード、設定ファイルなどの修正は全く行わなかった
Grani 様
Aurora 3x faster than MySQL (Total)
Query Average duration
Delete : 0.8x slower
Amazon Auroraによるコスト削減効果
性能向上によるDB 統合でノード削減も期待できる
Grani様の場合、DB統合も行い 年間 2,200万円超 のコスト削減効果
RDS (db.r3.4xlarge / gp2 /
OnDemand)Hourly Daily Yearly
RDS for MySQL(MultiAZ + 1
ReadReplica)
$4.54 + $2.27 =
$6.81$163.44 $59,655.60
Aurora (+ 1 Replica) $2.8 * 2 = $5.6 $134.40 $49,056.00
削減効果 ▲$1.21 ▲$29.04 ▲$10599.6
dwango 様
適用プロジェクト
• LDR– 国産RSSリーダー(Livedoor開発→Lineへ移行→Dwangoに譲受)– 3社に渡り約9年間続いたサービス
• その時々での負荷軽減策が実装されている• アプリケーションレイヤーで水平分割を実装など• コードベースは古く、特定DC内で動くことを前提としたコードなど
» プロセスに対応するソースコードが既に削除されていたり» アクセス先IPのサーバーが既に存在しなかったり
• 長い歴史があるだけに、大量の記事情報がMySQL上に存在
その数 15台 約10TB
LDR構成
パフォーマンス
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance • 5系統の記事DBをアプリケーションレイヤーで水平分割
• Auroraは「最大 5 倍のスループットを提供」とのこと
• １系統のAuroraに集約してもいけるはず！
Aurora
ディスク使用特性
• ディスク使用効率や運用面で現時点ではマイナスポイントもある– レコード削除しても一旦増えた使用領域はシュリンクされない– Compressed row formatをサポートしていない
• 一方で空き領域の再利用は効率よく行われている
• 各スキーマの“DATA_FREE / (DATA_LENGTH + INDEX_LENGTH)”の平均値をとったものを比較
まとめ
Amazon Aurora
• 業界問わずAmazon Auroraへの移行事例が増えてきている– AWSのサービスの中で最も高速に成長をしている
• 積極的に新機能の追加・性能の改善を行っている
• 安定性向上のためのBug fixも行っている– 様々なワークロードで安定して性能を発揮できる環境を重要視している
