11/10 Amazon RDS for Aurora 東京ローンチ記念セミナーに行ってきました

AWS Aurora RDS

タイトルの通り、
「Amazon RDS for Aurora 東京ローンチ記念セミナー」
に参加してまいりました。

AmazonWebServicesの皆さまはAuroraTシャツ着てました。かっくいー。


さて、とてもタメになったので、講演内容を速報したいと思います。

Auroraとは

ステキなまとめ資料があったのでそのままシェア。

www.slideshare.net
(けして書くのがめんどくさかったわけではありません。キリ)

以下、AmazonWebService安田さんからのトピックです。

  • TalendがAurora対応したとのこと！
  • DataSpiderもAurora対応したとのこと！
  • SVFクラウドもAuroraを採用しているとのこと！

高い堅牢性・拡張性・リーズナブルといった部分が評価されているとのことです。

講演一覧

  1. 「Amazon Aurora のエンタープライズワークロードでの活用」
  2. 「MySQL から Amazon Aurora への移行事例」
    • 株式会社グラニ様
  3. 「ドワンゴが Aurora 使ってみた（仮）」
  4. 「APNパートナー各社によるAmazon Aurora 評価・検証結果発表」
    1. データを使用した Amazon RDS for MySQL と Amazon Aurora の検証
      • アイレット株式会社　新谷 充 様
    2. Amazon Auroraはこう使おう！～基幹業務をフルクラウド化するポイント～
    3. New Cloud Design Pattern using Amazon Aurora
    4. Amazon Aurora＋ScaleArc による Amazon Aurora のデータベース分散処理技術の最大活用
      • 株式会社システムサポート様
    5. エンタープライズシステムにおける Amazon RDS for Aurora 活用ノウハウ

そうそうたる企業様が並んでいますね。
今回すごく注目？していたのは、基幹業務のフルクラウド化といったところでした。(Aurora関係ねー)
経営にITが貢献するための環境(AWS等)は整ってきていて、
これからはエンジニアの腕の見せ所ですよ、といった内容と受け止めました。
# もちろん組織も変わらないといけないけど。

mysql5.7への追随はどうなるのか？など非常に気になりますね。

講演内容

「Amazon Aurora のエンタープライズワークロードでの活用」

講演者様：Debanjan Saha(Amazon Web Services, Inc. GM, Amazon Aurora & MySQL)

「less than 10ms replica lag」

■サマリ
  • 高い堅牢性・可用性
  • 商用製品並みのハイパフォーマンス
  • OSS並みの低コスト(Mysqlと比べて安いケースも)
    クラウド時代のデータベースにおいてすごく良い選択
■エンタープライズ向けシステムに必要な要件をもとにAuroraを開発
  • 高い障害性
  • 安定した性能(あらゆるケースにおいて安定した性能を発揮)
  • 専門家を必要としない
  • 低コスト、かつライセンス不要
■クラウド向けのRDBMSを、1から再設計することにより、下記を実現
  • エンタープライズ級の可用性とパフォーマンス
    • 3箇所のデータセンタに6つの複製
    • 30秒以内にF/O！！！
    • クラッシュリカバリは即時に実施可能！！！
    • 50万read/sec,10万回write/sec(8xlarge)
    • 15個までのリードレプリカ、低遅延10ms
    • 64TBまで自動スケール可能(mysqlは6TBまで。)
  • マネージドサービス
    • 高速プロビジョン&デプロイ
    • 自動化されたパッチ&アップグレード
    • バックアップ・PITR
    • コンピュートノード・ストレージのスケーリング
  • 商用DBMSと比べて1/10のコスト
  • Mysqlとの完全互換
  • OSSのような使いやすさ、コスト効果
■Auroraのアーキテクチャ概要
  • ストレージは3AZを跨いでデータを保持
  • S3に透過的にバックアップされる
  • 1つのマスタ、15個までのリードレプリカを持つことができる。
    • マスタが故障した場合、15個のリードレプリカのいずれにもFO可能
■利用顧客について

ex:)Expedia/GE/PG&E,Earth nEtworks,ISCS,Alfresco,United Nation

  • Expedia事例

    • SQLServer,Casandra,SolrからAuroraへの移行
    • スケーラビリティ&パフォーマンス要件を満たし、コストも低減できた。
    • 平常時25,000(up to 70,000)insert/sec
    • 平均レスポンス：read 30msec,write 17msec

  • PG&E事例

    • 1,600万人の顧客、70,000平方マイルのサービスエリア
    • 低遅延のリードレプリカを使って、顧客アクセスに対応
    • 高速にリードレプリカを作成できることがよかった
    • MCシステムの実現性をAuroraは持っていた

  • ISCS事例

    • Oracle,SQLServer(通常業務&DWH)からの移行
    • IT支出の中で大部分を占めていた&維持管理が従来の課題
    • パフォーマンスに余裕を持たせた構成がSQLServerの70%のコストであった
    • バックアップウィンドウの排除が実現可能
    • RedshiftへのデータロードはReadReplicaを使用

  • Alfresco事例

    • 195ヵ国,1,800以上の組織が利用
    • 数十億ドキュメント級までスケールしていた。
    • 1秒未満のレスポンス時間を要求されていた。
    • 10億ドキュメントに対し、300万リクエスト/時までスケール
      • 現行システムの10倍の高速化
    • 巨大なDCからコスト効果に優れたAWSとAuroraへ移行した

  • EarthNetwork

    • 25TB以上のデータを毎日処理,分析ニーズが日々高まっていた
    • SQLServerからAuroraへの移行、パフォーマンス・スケーラビリティを実現

  • threat stack

    • 脅威分析のために非常に大きく連続したデータストリームを扱う
    • 約50万Insert/Sec,1日の生データは10TB
    • CassandraからAuroraへの移行、時系列データを扱うメインのデータべースにした
■高可用性のためのデザイン
  • 3AZ,6複製
  • データの読み書きにクォーラムを採用
    • 書き込みは4/6,読み込みは3/6
  • peer to peer goshipレプリケーション
    • ストレージとコンピュートノードが常に連携
    • ストレージノードでは常にブロック検査を実施、問題がある場合すぐさま復旧
  • クォーラムの実現により、AZ障害、ストレージの2重障害にも対応
  • 障害の検知・復旧・複製についてはバックグラウンドで自動的に実施
  • 高速なクラッシュリカバリ
    • 伝統的なDBでは最後のチェックポイントからのログを適用
      • Mysqlではシングルスレッドで行われ、ディスクアクセスが非常に多い
    • Auroraではストレージノード側で実施
      • 並列・分散・非同期に実施
      • 必要になったタイミングで、DiskReadの一環として、オンデマンドでredo logの適用を実施
      • 結果として、クラッシュ時のリカバリ処理は1秒以内に実現
  • Auroraのフェイルオーバは非常に速い
    • MariaDB製のドライバを使うことで、DNS Propagationをスキップできる
    • 上記により、通常30秒未満でFOが可能
  • 連続的なバックアップに関して
    • 従来のDBではバックアップ中に何もできない問題があった
    • Auroraでは多数のストレージがあるため、各ノードで定期的にS3に送ることで、連続的なバックアップを実現
    • PITRについても、必要なセグメントのスナップショットをS3から並列で持ってこれる
      • 通常のDBと比べて非常に高速
■エンタープライズ級のパフォーマンス
  • AuroraのページにWhitePaperがある。
  • テーブル数に応じたスケールを実現
    • mysqlではテーブル数の増加に比例して劣化
    • Auroraは問題ない、Mysqlの11倍
  • データ数の増加に対してもスケールを実現
    • mysqlではデータ量の増加に比例して劣化
    • Auroraは問題ない、Mysqlの67倍
  • 接続数の増加に対してもスケールを実現
    • mysqlでは接続数の増加に比例して劣化
    • Auroraは問題ない、Mysqlの8倍
■なぜMysqlより早いか？
  • IO FLOWが非常にシンプル
    • REDOレコードをまとめる。LSNが並ぶ。
  • Mysqlではそれぞれのスレッドが処理
  • Auroraではキューイングシステム
  • 非同期で行われるグループコミット
    • まずはBuffer、4/6のストレージからAckが帰ってきたらcommit
■アドバンスト・モニタリングがそのうち実現される。

顧客からOSのモニタリングをしたいというオーダーが多い

  • 50以上のシステム/OSメトリクスを見えるように実現。
  • 画面からプロセスリストを並べ替えることも可能
  • データ取得単位を1秒単位に！！！！
■Don't be constrained by licenses, cost, or capacity

一部のケースにおいてAuroraはMysqlと比べても低コスト。

  • Idle状態のリードレプリカが不要
  • リードレプリカごとにストレージを切り出す必要がない
  • IO担保にではなく、使用IOに対して課金
  • 全体として、ストレージコストの最適化を進めることもできる。
■QA
  • mysqlだとテーブルサイズが大きいカラムの変更などに非常に時間がかかる,Auroraにおいて改善があるか
    • いくつかは改善が加えられている、まだすべてではない
    • 現在オンラインDDL処理に向けて改良を行っている、3-6ヵ月程度でのリリースを目指している
  • モバイルSDKにおけるコールは実現可能か
    • もちろん可能
  • 小さいインスタンスタイプをサポートする予定があるか
  • 巨大テーブルに対するAlterでOOMが起きがち
  • MHAなどのような、数秒でのアップグレードを実現する予定はあるか
    • サポートは考えていない,別インスタンスを立ち上げて切り替えることを検討してほしい。(?)

「MySQL から Amazon Aurora への移行事例」

講演者様：吉崎様(株式会社グラニ様)

■Nice to meet you, Aurora!

発表スライドはこちら
https://speakerdeck.com/guitarrapc/nice-to-meet-you-aurora

目的1：RDS for Mysql からAuroraへ移行してみての変化
目的2：Auroraへの移行での注意点
■環境について
  • New Relicを使った計測
    • AP,DB,Redis,xternalの監視・通知
  • APが発行したクエリをすべてBigqueryに移行
■パフォーマンスについて
  • Mysql:15-22msec
  • Aurora:5.5msec
    • updateの高速化が顕著
    • 16msec→2.2msec
■DeepDown
  • select:グラニさんの環境ではあまり変わらなかった。0.98倍程度(query cache : off)
  • update:5倍程度の高速化を実現
  • insert:2倍程度の高速化を実現
  • delete:グラニさんの環境では若干遅くなった。0.8倍程度
■性能に関する考察
  • Multi-AZでの転送高速化
  • 非同期のグループコミット
  • スレッドプール・ロックハンドリングの改善
■移行に関して
  • まずはAWSサポート資料を見ればOK！
  • 移行に関しては2パターン考えられる
    1. snapshot移行
    2. レプリケーション移行
      • 500GB-1TB程度の現実案がコレ(サービスへの影響を考慮)
  • 注意点
  • Snapshot移行について
    • 120GB(r3.4xlarge)
    • 1100GB(r3.8xlarge)
      • マイグレーション所要時間：10:42h
        • データによって3hで終わったりすることもある
        • インスタンスタイプの変更で高速化することもある
        • とはいえサービス停止時間が許容できない。。。
      • レプリカ作成所要時間：0:06h
■上記のような場合にレプリケーションマイグレーション
■注意点
  • セキュリティグループの設定がDBインスタンス単位からクラスタ単位へ
    • RouteTableによる制御を実現
      • 本番マスター：IGWと繋がらないPrivateRouteTableにAZアサイン
      • 本番レプリカ：IGWと繋がっているPublicRouteTableにAZアサイン
        • ルーティング時点で接続を制御
  • High CPU/Memory/QueueDepth
    • RDS fro MysqlはCPU60%程度から明らかな性能劣化
    • AuroraではCPU100%近くでも堅調に動作している
  • tmp_dirのサイズはインスタンスタイプに依存
  • FailOver先のレプリカ指定は未実装
    • 将来的な実装を想定しているとのこと
  • CachePurgeは未実装
■サマリ
  • 特にマルチAZを使用している場合に性能向上、ノード構成数低減にも寄与
  • 耐障害性の向上
  • コスト低減にも寄与

「ドワンゴが Aurora 使ってみた（仮）」

講演者様：細川様(株式会社ドワンゴ様)

■経緯
  • 多数エンジニアあり
  • 各種機器多数保持
  • クラウド利用はあまり進んでいなかった
■新機能の積極的検証・導入を実施
  • Amazon Lambda : 3ヵ月くらいでProductIn
  • API gateway：2週間程度でProductIn
  • Aurora：on going 検証中
■適用プロジェクト
  • LDR(国産RSSリーダー)
    • Livedoor→Line→Dwangoと移管
    • 9年間続いているサービス
      • 各時点で負荷軽減策を実施
        • Apレイヤで水平分割を実装
        • コードベースは古く、特定DC内で動くことを前提としたコードであった
          • プロセスに対応するソースコードが既になかったり
          • アクセス先IPのサーバがなかったり
    • システム構成
      • DBはMysql on EC2 Instance
      • 15台10TB程度のデータをAuroraに移行できないか検証中
■メリット
  • Mysqlと完全互換である点
    • 現行のコードセットで動作することの検証が完了
    • 運用上必要な設定値がそのまま流用することが可能
    • なじんだ手順でのデータ移行が可能
  • ディスクの使用特性
    • ディスクの使用効率や運用面で現時点ではマイナスポイントもある
      • 一度拡張した領域はシュリンクされない(=課金対象となる)
    • 空き領域の再利用はわりと効率よく行われている
  • パフォーマンスに関して
    • 5系統の記事DBをAPレイヤで水平分割
      • 並列数を1系統に集中する
      • クローラおよび空き容量確保バッチが裏で実現される
    • 実環境を模した環境で試験を実施
      • 目標をクリアし、サービス運用上ピークとなるクエリをさばけた
      • 数TBのデータセットでクローリングした情報を追加した長期安定試験を実施
        • 目立った性能劣化は見られなかった
        • 最大64TBまでシームレスにサポートされる点は安心できる
    • CPUが100%に張り付くケースがある
      • ただし、上記はAuroraの特性なので心配視していない
  • フルマネージドであることによる運用負荷の削減

「APNパートナー各社によるAmazon Aurora 評価・検証結果発表」

データを使用した Amazon RDS for MySQL と Amazon Aurora の検証

講演者様：新谷 充 様(アイレット株式会社(CloudPack))

■バンダイナムコ様との共同検証
  • 検証にあたっては、下記の前提とした
    • 本番データを使用した
    • 環境は基本的なLAMP環境とした
    • tcpdumpにより本番APで流れるクエリを抽出
    • snapshot,amiからWeb/APサーバ・Auroraを構築
      • 比較のためMysqlも作成
      • 試験のたびにRDSを再作成
  • 測定結果
    • 1回目:waitあり、エラー処理無し
      • 特に差分なし。処理にエラーあり
    • 2回目:wait無し、エラー処理無し
      • 特に差分なし。処理にエラーあり
    • 3回目:wait無し、エラー処理あり
      • mysql:8.5hr,Aurora:4.5hr
  • 考察
    • AuroraのほうがCPUを使用している
    • AuroraのほうがQueueDepthが圧倒的に高い
      • Auroraは並列処理に特化しているため、自然な振る舞い
      • Read/WriteThroughputに問題なければ良い
  • 追加検証
    • ウォームアップ処理を双方に実施することで、Mysqlのパフォーマンスも改善
      • mysql:4.8hr,Aurora:4.0hr
  • まとめ
    • (性能)並列処理が最適化されているため、同時接続が多いとパフォーマンスが高い
    • (性能)クエリが一斉に流れても、滞留なく処理される
    • (性能)ディスク性能がRDS for Mysql と比べて安定している
    • (運用)キャッシュがrebootで消えない！
    • (運用)レプリケーションラグがない、作成も早い
    • (運用)使用量にあわせてディスクが動的にスケーリング
  • 今後のAuroraに期待すること

Amazon Auroraはこう使おう！～基幹業務をフルクラウド化するポイント～

講演者様：漆原 茂 様(ウルシステムズ株式会社)

■「待ってました！クラウド型RDBMS~Aurora~」
■やはり基幹業務にはRDBMS
  • わかりやすいプログラミングモデル
  • データの一貫性
  • トランザクション管理
  • 分散処理
  • 耐障害性
■移行を支援するツール
  • AWS Schema Conversion Tool
  • AWS Database Migration Service
■～AP業務移行をどのようにして実現すればよいか？～
→APアーキテクチャが全てを邪魔している
■MicroServiceArchitectureを実現したい！
  • Restfulで、全てAPI経由なアクセス
  • APを「複数のサービスの組み合わせ」で作る
  • 個々のサービスは独立して開発・デプロイ可能
  • 特定の技術にロックインされない
AWSはマイクロサービスに相性よし
  • サービスプロビジョニング
  • サービスのモニタリング
  • 独立した運用・デプロイ →devops文化
  • 水平分散可能
作り上げたモノリシックなものをブレークダウンすると良い

This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile. .
参照元：http://martinfowler.com/bliki/MonolithFirst.html

何が必要か？～TeamとDevops文化～
MicroService用のフレームワーク
Aurora活用のステップ

New Cloud Design Pattern using Amazon Aurora

講演者様：大栗様(クラスメソッド株式会社様)
発表スライドはこちら →http://www.slideshare.net/maroon1st/new-cloud-design-pattern-using-amazon-aurora?utm_source=feedburner&utm_medium=twitter&utm_campaign=Feed%3A+slideshare%2FUARV+%28Why+China+will+over+take+India+as+the+world+Leader+with+Gold%29

■developpers.ioのシステム構成
  • Elastic beanstalk + WordPressが基本構成
  • eb cloneで新環境構築
  • データについてはSnapshot
■移行後
  • だいたい倍程度のパフォーマンスが得られた
  • データが6重化されているため、Single-AZで十分と判断
  • コスト1.5倍程度で性能が2-5倍程度
■システム移行事例
  • Mysql(8x.large)のレプリカ9台→Aurora移行を想定
  • 高性能化による台数削減を期待
  • 高可用性を実現
  • 現在鋭意移行検証中
■new cloud design patternを設計
  • Auroraは高速FOが可能！
    • サービス中に高速FOを駆使し、インスタンスタイプを変更できないか
DBScheduledScaleupと名付けた！
  • MariaDB Connector/jを使用
  • Lambdaを使用してスケジュール起動
  • 大きなインスタンスタイプのノードを立ち上げておき、小さいノードと瞬間的に切り替えを実施
  • 定期的なスケールアップを実現

Amazon Aurora＋ScaleArc による Amazon Aurora のデータベース分散処理技術の最大活用

講演者様：山口様(株式会社システムサポート様)

■～一般的なDB処理の大部分がreadである～説
  • 一般的には、read90%,write10%を言われている
  • Auroraでは数クリックで参照処理の改善を実施することができる
    • ReadReplicaの構築によって参照処理の負荷を分散
readreplicaの追加に対するAP改修をScaleArcが吸収
  • read/write split という機能を持つ
    • AP側はScaleArcに投げるだけでよく、ScaleArcがマスター・スレーブを投げ分けてくれる
  • 検証結果
構成 実行時間
構成1:AP1台,Master1台,Slave1台 470.37sec
構成2:AP1台,Master1台,Slave2台 233.13sec
構成3:AP1台,Master1台,Slave3台 155.62sec

※SelectQueryのみを発行

■その他Auroraに関する取組
  • OracleDatabaseからAuroraへのマイグレーションを積極的に実施
    • 一部AP改修は必須だが、コスト的に非常に有用と考える

エンタープライズシステムにおける Amazon RDS for Aurora 活用ノウハウ

講演者様：西岡様(株式会社野村総合研究所様)

■Aurora検証
  • コスト観点
    • Oracleと比較して33%のコスト削減
  • アプリ開発への影響を少なく
  • スケーラビリティの確保
    • Replicaを増やすことでスケーラビリティを確保したい
    • Oracle RACでは各インスタンスにおいて読み書き可
    • Auroraでは、参照スケーラビリティが確保されている
      • Replicaの増加によってMasterの性能劣化がないか検証済み、問題はなかった。
  • 高可用性に関して
    • 高可用性であることが望ましい、データ遠隔地保管のソリューションがほしい。
      • Auroraでは99.99%,SLAは99.95%が保証されている。
■エンタープライズシステムで活用するうえでのポイント
  • コスト削減できる点は大きなメリット
  • 性能に関して、基礎数値の確保などのために、実機検証が必要
    • Aurora単体では更新スケーラビリティを確保できないため、シャーディングなどの工夫が必要
  • 99.999%の可用性が確保されているわけではない
■Auroraに対する期待
  • 更新処理をスケールアウト構成にできないか
  • リージョン間のAuroraレプリケーションの暗号化


上記を受けての今後の展望は別途書きますかね。

とりあえず以上ということで。