Amazon Aurora 事例祭り に行ってきたので、メモを公開します。

社内共有で Slack に貼ろうと思っていたメモなのですが、長くなったのでブログに公開します。

概要

Amazon Aurora 事例祭り （2017 年 3 月 7 日開催） | AWS

セッション内容

Amazon Aurora を使いこなすためのベストプラクティスと最新アップデート

• @con_mame さん
  • データベースソリューションアーキテクト
• 登壇資料: [Aurora 事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
• 開発サイドからの知見と今後の展望
• PostgreSQL For Aurora でるよ！
  • 9.6.4 と互換
  • MySQL 版と同等の機能ができるようにする予定（まだ開発中なので確約はできない）
• 製品の詳細 - Amazon Aurora | AWS の再紹介
• Aurora は障害時のフェイルオーバーでは DNS レベルで master を切り替える
  • DNS の TTL は 5s
  • アプリケーション側で DNS キャッシュしていると切り替えが遅れるので注意
• master か否かは read only の変数を見ると分かる（ パラメータ名は聞き漏らしました ）
• JDBC Driver を使っている人は MariaDB Connector/J 1.2.0 が Aurora 対応したのでオススメ
  • master 判定が組み込まれており、フェイルオーバー時の切り替えが速い
• Aurora のパフォーマンスを引き出すために
  • クエリ並列度が高い、データサイズが大きいケースで効果を発揮
  • ロック機構や Query Cache 、スレッドプールなどに改善を入れて性能向上を行っている
  • CPU / Memory の利用率が MySQL より高いがスループットが出ている
    • 分散ロック機構で CPU リソースを使い切ってスループットを出している
• MySQL 互換ではあるが、マシンリソースの使い方が根本的に違う
  • 使い切ってスループットを出す設計なので、ベンチなどをとる際はスループットに着目してもらえると嬉しい
• チューニング指針
  • まずはデフォルトのパラメータグループをベースに
  • 適切なインスタンスタイプを選択することが大切
    • それでもダメならパラメータグループを設定
  • 1 トランザクションで大量の更新や削除を行ったり、大量のシーケンシャルリードを行う場合
    • range に区切って実行すると並列度が上がって良い（ Prallel Read Ahead ）
• 移行オススメな方々
  • スループットを向上させたい
  • ディスク容量が気になる
• 最近のリリース
  • Reader Endpoint の追加
  • クロスリージョンレプリケーション対応
  • フェイルオーバー順の指定
  • Cluster View
    • インスタンス状況の一覧など
• 今後の展望（ re:Invent で発表されたやつ）
  • RDS MySQL DB インスタンスから Aurora Read Replica が作成可能に
  • Advanced Auditing
  • Zero downtime patch
  • etc. （色々とご紹介頂きましたが、既出の内容なので省略）

AWS Database Migration Service と Schema Conversion Tool の使いドコロ

• AWS Database Migration Service（データベースを簡単かつ安全に AWS へ移行） | AWS
• AWS Schema Conversion Tool とは - AWS Schema Conversion Tool
• 適用できる組み合わせが広い
• 自動変換できないところをレポートにまとめてくれるの便利
• 詳細なパターン、フローをご紹介いただいた。メモが追いつかないのでスライドが公開されることを期待 -> 公開していただきました！
• 登壇資料: [Aurora 事例祭り]AWS Database Migration Service と Schema Conversion Tool の使いドコロ

Oracle RAC から Aurora MySQL へ移行したお話

• @darshuheider さん
• 登壇資料: Amazon Aurora 事例祭りに登壇させていただきました！ | レコチョクのエンジニアブログ
• レコチョクとは
  • デジタル音源配信サービス
  • 音楽ダウンロードアプリ、音楽ダウンロードサイト、曲のランキング・歌詞は【レコチョク】iPhone/Android 対応
  • 機能やサービスごとにシステムを構築（マイクロサービス？）
• クラブレコチョクとは
  • レコチョクが展開するサービスへ会員機能を提供
  • 有効会員数は約 1000 万
  • アクセス数は多いと秒間 250 リクエストを超える
  • サービス横断で使われるので可用性が重要
• Aurora を選択した理由
  • 会社全体としての課題
    • データ総量の予測が困難になってきた
    • コスト最適化
      • 短期間でのサービス立ち上げ
      • 急激なアクセス増に対する対応のためインフラを多めに確保していた
    • コストの明確化
  • 既存構成
    • Oracle で RAC 構成
    • DBA がインフラを運用
  • Aurora へのモチベーション
    • 可用性の担保
    • 運用工数を抑えたい
• どのように Aurora へ移行したか
  • DMS などの移行ツールが一般公開される前だったので、全て自前のスクリプト
  • テーブルを再作成
    • DDL の作成
    • パラメータグループの作成
      • デフォルトのトランザクション分離レベルが Oracle と違うところがやらかしポイント
  • SQL の修正
    • MySQL の構文に移植。
  • データの移行
    • 更新日を見ながら過去数年分を一気に移行
    • 移行後、差分を適用
  • 性能試験
    • 本番相当のデータを使って運用テスト、負荷テストを実施
      • スロークエリをチェック
    • 実行計画を取ってフルスキャンしているものを確認
    • 問題があったものを対応
      • SQL の最適化
      • インデックス追加
      • サブクエリ排除
      • 検索専用のテーブルを追加（後方一致検索が重かった）
      • パラメータの修正は一切行わず
        • Aurora のデフォルト値を信用
• どのように Aurora を運用しているか
  • 何を見ればいいかわからないところからスタート
    • 標準的に見る項目や閾値を策定、ダッシュボード作成
  • Aurora に合わせた監視内容に変更
    • CPU 使用率が高い
      • リソースをフル活用するため
      • リソースの監視を止め、スループットやレイテンシーの監視のみにした
  • 結果
    • Aurora による障害はこれまで 0
      • メンテナンスによる停止はあったが、ゼロダウンタイムパッチにより解消
    • DB サーバ運用に工数をほとんど割かなくてよくなった
    • 性能は問題なし（むしろ早くなった）
    • ライセンス費用が 0
  • 今後への期待
    • PostgreSQL 互換
    • 暗号化されたスナップショットの別リージョンへのコピー
      • バックアップを別リージョンに置きたかった

MySQL on Fusion IO から Amazon Aurora への移設による費用削減効果

• 三国 INFINITY（三国インフィニティ） | Mynet Inc. ( 株式会社マイネット )
• 旧 DB 構成
  • 12 Core 3 ペア
  • 32 Core （ メモ取り切れなかった ）
• サーバ費用
  • 全体: 185 万円 / 月
  • 内、DB の費用: 92.5 万円 / 月
• AWS 移設計画
  • マスター DB 全て Aurora 化
  • スレーブは Aurora のパフォーマンス最大 5 倍を信じて捨てる
• 新構成の費用
  • DB の費用が約 16 万円 / 月 に（82%減）
  • リザーブドインスタンス（年間で購入、月額で割った値）
  • オンプレサーバを見守る人が不要になり、人件費も大幅に削減
  • 順調に稼働中
• 質疑応答
  • メンテナンスは減ったか
    • 移行では流石にメンテナンスした
    • メンテナンス回数は減った
    • そんなに止めることはない
  • どのくらいのデータ量をどのくらいの期間で移行したか
    • メンテナンス自体は 2 日間という長期（ゲームとしてはかなり長期）
    • 数 10GB

毎日新聞ニュースサイトをクラウド化 ～ Amazon Aurora 導入事例紹介～

• 毎日新聞のニュース・情報サイト
• CMS 機能
• Aurora 採用理由
  • 高パフォーマンス
    • 高スループット
    • 低レイテンシーのリードレプリカ
  • メンテナンスビリティ
  • コスト
    • ストレージが特にメリットと感じられた
  • MySQL 互換
  • 移行の簡単さ
• 採用による効果
  • メンテンナンスレス
  • トラブルレス
  • 技術者、社内利用者の意識改革
    • 背中を気にしなくてよくなり、様々な好循環があった

MySQL から Aurora へ - 劇的な性能向上に止まらない、Aurora 移行によるメリット -

• スマホでフェイト！｜ Fate/Grand Order 公式サイト
• リリース時は MySQL 、途中で Aurora に移行
• Aurora 移行方針、準備
  • モチベーション
    • ユーザー増を考えるととりあえず移行すればメリットありそう
      • MySQL5.6 との互換性
      • 5 倍のパフォーマンス
    • Aurora だけで処理を捌ききれなくなったらどうするの
      • 参照クエリを slave に振り分けることを考えていた
      • MySQL ではレプリ遅延が 10 秒を上回ってくるのであかん
      • Aurora なら 10ms - 20ms くらいなのでいけそう
    • DB データ量が急増するゲーム施策のインフラ対応コストを削減したい
      • ストレージ容量を増やそうとするとメンテだった
      • Aurora の自動スケール嬉しい！
      • 検討時のデータ容量は 600GB 程度だったので 64TB あれば余裕そう
      • とはいえデータを減らす努力は忘れずに
    • インフラ費用を削減したい
      • 検討当時は 200GB のデータサイズに対して 1TB 以上のストレージ容量を確保していた
      • ユーザー数が増加していたので、余裕を持たせる必要
      • Aurora 移行ならインフラ構成に手を入れずに対応できるので嬉しい
  • 方針
    • 移行前後のデータ不整合はダメ
    • 移行後の Aurora 障害を考慮し、切り戻しできるように移行
  • 手順
    • スナップショット作成（メンテ 1h）
    • スナップショットから Aurora 作成（5h）
    • ---メモ取りきれなかった---
• 失敗
  • 移行後 48 時間後にサーバの応答速度が不安定に
  • slow query で init DB が重い
  • binlog のパージっぽい
  • 原因
    • init DB 時にパフォーマンスが劣化する Aurora v1.6 のバグ
    • v1.6.5 で fix
  • MySQL に切り戻した後、v1.7 で再移行した
• 成果
  • オートスケール上手いこといっている
  • 30%の費用減
• まとめ
  • 互換性のため移行の難易度は高くない
  • パフォーマンスいい感じ
  • とはいえ移行失敗時の切り戻しはしっかりね
• 小ネタ
  • スナップショット作成が爆速
    • MySQL で 15 分だったのが 1 分で終わる
  • アップグレード管理
    • ダウンタイムなしのアップグレードがリリースされたが、実行時のパフォーマンスは劣化するようなので注意
• 質疑応答
  • init DB の地雷は他社でも踏んだ気配？
    • 事後に調べたらあったご様子
  • init DB のバグは事前に伝えてもらえなかったの？
    • AWS 側としてはここまでの影響が生じるとは予測できなかったため、事前にお伝えすることができなかった

以上

運営、登壇の皆様、ありがとうございました。

メモに何か間違いなどありましたらご指摘いただければ幸いです。

今回のお話を伺った限りでは既存 DB からの移行もスムーズに行なえ、ゼロダウンタイムアップグレードもリリースされて機が熟してきたなーという雰囲気でした。

担当サービスでも既に Aurora が導入されているので、上手く行かないパターンの知見も溜めていきたいところです。