new cloud design pattern using amazon aurora

New Cloud Design Patternusing Amazon Aurora

Amazon RDS for Aurora東京ローンチ記念セミナー

classmethod.jp 2

2015 年 11 月 10 日 クラスメソッド株式会社AWS コンサルティング部 大栗　宗

自己紹介大栗 宗（おおぐりはじめ）@maroon1stAWS 環境におけるインフラ環境のコンサルティング、設計、構築

http://dev.classmethod.jp/author/oguri-hajime/

classmethod.jp 3

クラスメソッド株式会社• 2004 年設立• 主な事業内容

– AWS コンサル / 監視– モバイルアプリ開発– データ分析環境開発

• APN プレミアコンサルティングパートナー• APN コンピテンシー：ビッグデータ、モバイルclassmethod.jp 4

• 社員執筆による技術ブログ

http://dev.classmethod.jp• Aurora 関連 34 本• re:Invent 2015 関連 200 本• AWS 関連： 2000 本以上

classmethod.jp 5

Developers.IO の負荷問題• アクセス数 → re:Invent 等イベント

• 投稿数　　 → 4800 本以上

• 投稿者　　 → 社員全員

• ランク制　 → SNS ポイントの集計

classmethod.jp 6

Developers.IO の構成• Elastic Beanstalk ＋ WordPress が基本構成• eb clone で新環境• Snapshot で移行

classmethod.jp 7

移行結果

classmethod.jp 8

MySQL Aurora最小値 40 ms 18 ms最大値 110 ms 35 ms中央値 50 ms 25 ms

MySQL Aurorainsert 30~50 ms 9 msother 3 ms 2 msselect 5 ms 3 msdelete 25~30 ms 7 msupdate 25~30 ms 6 ms

Top database operationsby time consumed

Databese response time

移行結果• 移行前： db.m3.medium (MySQL Multi-AZ)

移行後： db.r3.large (Aurora)$ 172.8 → $ 252

• 標準でデータが 6 重化されるため十分な対障害性があるので Single-AZ で十分と判断

• 約 1.5 倍のコストで 2~5 倍の性能

classmethod.jp 9

AURORA 移行中の事例

SNS サイトでの移行

classmethod.jp 10

SNS サイトの DB• RDS(db.r3.8xlarge) • エンジンは MySQL• 9 台のレプリカ• 継続的な書き込み• EC2−Classic 環境

classmethod.jp 11

Aurora に対する期待• 高性能化による台数削減

→ ランニングコスト減少　 管理対象の減少

• 高可用性→ 現状はコスト削減のため Single-AZ　 障害時に高速な回復

classmethod.jp 12

classmethod.jp 13

鋭意移行検証中

NEW CDP の提案

DB Scheduled Scale Up

classmethod.jp 14

CDPAWS クラウドデザインパターン (AWS Cloud Design Pattern, 略して CDP と呼ぶ ) とは、 AWSクラウドを使ったシステムアーキテクチャ設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を、分かりやすく分類して、ノウハウとして利用できるように整理したものである。

http://aws.clouddesignpattern.org/index.php/ より

classmethod.jp 15

DB の良くある悩み• DB は性能向上を Scale Up で行うため

サービス期間中には切替えられません。そのためピーク時の負荷に合わせたサイジングを行います。常時ピーク性能のスペックを使用するので高コストになりがちです。

classmethod.jp 16

解決方針• Aurora は高速なフェイルオーバーが可能。

サービス中に、スペックの異なるインスタンスへ入れ替えが可能ではないか？→ DB Scheduled Scale Up

classmethod.jp 17

DB Scheduled Scale Up• 負荷のピーク前に Scale Up でスペック

を上げて、ピーク後に Scale Down でスペックを下げる。

• 高速なフェイルオーバーと定時起動が必要となる。

classmethod.jp 18

高速なフェイルオーバー• フェイルオーバーを更に高速に

→ MariaDB Connector/J• Aurora のグローバル変数 (innodb_read_only)

で writer と reader を判断する JDBC ドライバ。

• 1〜 2秒で切り替えが可能。

classmethod.jp 19

定時起動• 決まった時刻に API を実行したい

→ Lambda でスケジュール実行

• コードの記述のみ (OS の管理無し ) で実行可能なコンピューティング リソース

• cron形式でスケジュールを記述可能

classmethod.jp 20

構造1. 大きなスペックの Aurora を

reader として起動する

classmethod.jp 21

構造2. 両方の Aurora へ向くように接続情報を更新する

classmethod.jp 22

構造3. Aurora をフェイルオーバー

EC2 の接続先も切り替わる

classmethod.jp 23

構造4. 大きいインスタンスのみに接続情報を更新する

classmethod.jp 24

構造5. 小さいインスタンスを削除

classmethod.jp 25

注意• 現状では Java アプリケーションのみ対応。

(MariaDB Connector/J は JDBC ドライバ )• 接続情報の更新は、 Run Command や Elastic

Beastalk の B/G デプロイ等が考えられる。

• MariaDB MaxScale で対応してくれるとアプリの言語に依存しない。

classmethod.jp 26

まとめ

classmethod.jp 27

まとめ• Single-AZ でも十分な対障害性。• エンタープライズ DBだけでなく OSS

DB と比較して低価格の場合も。• 高速なフェイルオーバーでダウンタイム

を極小化。 MariaDB Connector/J で更に高速に。

classmethod.jp 28