AuroraがAWS史上最も急成長しているサービスであるということから、今後もAWSはAuroraに力を入れてくるでしょう。今時、システム全体をクラウドに乗せるのに、DBだけCPUライセンスが必要というのは確かに現実的ではありません。商用DBからオープンソースDB、そしてAuroraへの流れは自然な流れなのかもしれません。
【Keynote1】Amazon Aurora with MySQL compatibility最新情報～MySQL5.7対応やプレビュー機能の狙い～
スピーカー
Sirish Chandrasekaran Principal Product Manager
なぜAuroraを作ったのか？
· Intuit社の事例
Auroraとは
· DBをクラウド環境のために再構築
特徴
· スケールアウト、分散、マルチテナントデザイン
· AWSを活用した、サービス指向アーキテクチャ
· フルマネージドサービス、自動化されたタスク
· ハイエンドDBのような性能と可用性
· オープンソースDBのようなシンプルさとコスト効率
· MySQLやPostgreSQLとの互換性
· 利用した分だけ支払うモデル
· マネージドサービスとして提供
Auroraを入れてもらえれば他は何もしなくていい、というようにしたい
1. スケールアウト、分散、マルチテナントデザイン
· コンピュートレイヤをストレージレイヤと分離している
o DB専用に作られたログストレージ
o ストレージボリュームは3つのAZにすトライピング
o 各AZに2つずつ、計6つのデータのコピーを保持
§ AZ＋１の障害にも対応可能
o Masterとレプリカが同じストレージを参照している
2. AWSを活用した、サービス指向アーキテクチャ
· エコシステムを利用した構成
o Lambda
§ ストアドプロシージャ、トリガーからLambdaイベントを実行
o S3
§ S3からデータをロードしたり、スナップショットをS3に保存
o IAM
§ IAMロールをDBアクセス管理に利用
o CloudWatch
§ システムメトリクスや監査ログを保存
3. フルマネージドサービス、自動化されたタスク
· ユーザ
o スキーマデザイン
o クエリ作成
o クエリの最適化
· AWS
o 自動化されたフェイルオーバー
o バックアップとリカバリ
o 分離とセキュリティ
o 自動パッチ適用
o 定期的なメンテナンス
· 時間のかかるDB管理タスクを自動化することで、アプリの改善やビジネスに専念してもらう
o AWS史上最速で成長しているサービス
o AWSTOP100のうち、3/4が利用している
§ なぜAuroraに移行したのか？
§ オープンソースを使っていたユーザ
§ より高いパフォーマンス（最大5倍）
§ コストを最大60％削減
§ 簡単な移行。アプリの変更なし
§ コマーシャルDBを使っていたユーザ
§ 1/10のコスト。ライセンスなし
§ Cloudシステムとの統合
§ 同等のパフォーマンスと可用性
o 今のトレンドは、NoSQLからAuroraへの移行
§ ハイパフォーマンスアプリ用のデータストア
§ Cassandra（>100nodes）Aurora(～10clusters)
§ 大規模な遺伝子情報を扱う会社が、Auroraに移行することで、10ms未満の読み取りレイテンシと大幅なコスト削減
パフォーマンス
· MySQL5.6&5.7と比較
o R3ベースで約5倍の性能
· リードレプリカレイテンシ
· I/O
o RDSの場合
§ プライマリインスタンス＞EBS＞EBSミラー
§ プライマリからレプリカへ
§ レプリカインスタンス＞EBS＞EBSミラー
§ それぞれボリュームが独立しているため時間がかかる
§ 両方のインスタンスで同様の作業負荷が発生する
o Auroraの場合
§ シェアードストレージに書き込むのみ
§ 物理的なIOは発生していない
§ RDSとくらべて8倍速い
· Auroraでのパフォーマンス向上
o DMLスループット
§ Fast B-tree insert
§ Z-order spatial indexes
§ Smart read-node selector
§ どのノードを読むのが一番早いかを判断
o クエリ実行
§ ハッシュjoin
§ 一部のクエリでは8倍性能が向上した
o DDL
§ パフォーマンスの高い監査機能
可用性について
· パフォーマンスはDBが正常に稼働しているときに気にすること
· なぜ6つのコピーが必要なのか？
o AZ+1の障害に対応する
§ 大規模な環境だと常に何かしらの障害は起きる
§ AZ障害は運命共同
§ AZ+1障害にも対応できて、修復も可能である必要がある
· 15台までの昇格可能なレプリカ
o Masterが失われても10秒以内に昇格できる
Auroraは簡単
· RDSはたくさんのことを処理してくれる
· さらに64TBまで10GBずつ自動スケールするストレージ
· DBのcloneも簡単にできる
o コピーではないので早い
なぜ安価なのか？
· RDS
o シェアードストレージがないので、プライマリ・レプリカごとにストレージが必要
· Aurora
o ストレージは1つのみ
§ このため、RDSよりも30％削減できる
o 地裁インスタンスサイズにするとさらにコスト削減できる
移行も容易
· 各種マイグレーションツールを用意している
Auroraの新機能
1. Multi-Master
· 1つのMASTER、15のリードレプリカが現状
· シングルAZなら全部がMasterになる？（要確認）
· Auroraのダウンタイムをゼロにしたい！という要望 ex.ECサイト
· 書込みの性能（20万/秒以上の性能が必要）ex.ゲームなど
· 継続した書込み可用性
o M1接続中に障害発生しても、他のノードへ接続を再接続
o シェアードストレージなので影響はゼロ
2. パラレルクエリ
· クエリをストレージノードの数千のCPUにプッシュダウン
· Auroraストレージには数千のCPUがある
· ユースケース
o OLTPワークロードの分析クエリ
o アドホッククエリに対するETLパイプラインを作らなくてよい
o 複数の分析クエリを同時実行
3. サーバレス
· 可変ワークロードを持つアプリ用のオンデマンド、自動スケーリングDB
· ユースケース
o スケールアップ・ダウン
o 0からスケール
4. パフォーマンスインサイト
· DB管理をしやすくするもの
· DBの負荷を表示するダッシュボード
· ボトルネックの原因を表示
o TOP SQL
5. MySQL5.7 compatibility
· 互換性
o JSONサポート
【Keynote2】Amazon Aurora with PostgreSQL compatibility最新情報～ついに東京リージョンでも利用可能に～
スピーカー
Kevin Jernigan Sr.Product Manager
RDSの歴史
· 2006年 S3リリース
· 2009年 RDSリリース
· 2012年 Oracleサポート
· 2013年 PostgreSQLサポート
· 2014年 Auroraをアナウンス
· 2015年 Aurora with MySQLがGA
· 2017年 Aurora with PostgreSQL compatibilityがGA
これまでのDBはスケールが難しい
· 複数の機能レイヤーが1つのアプリケーションになっている
· 従来のアプローチ
o アプリレイヤでシャーディング など
· RDBをもう1度考える
o Cloudでやるならどうするか？
o Auroraの誕生
Auroraをよりよく
· PostgreSQL
o オープンソースDBである
o 20年の歴史がある
o コミュニティが所有している
o 扱いやすいオープンソースライセンス
o 高性能
o 標準SQL
o 12言語でのストアドプロシージャサポート（Java、Rubyなど）
o Oracleからの移行先としても採用しやすい
o AWS移行ツールによる自動変換率は、OracleからPostgreSQLが最も高い
PostgreSQL compatibilityが意味するもの
· PostgreSQL9.6 + Aurora
o パフォーマンス向上（2~3倍）
o 可用性（30秒未満でのフェールオーバー）
o 堅牢性（３AZ6レプリカ）
o リードレプリカ（15台まで）
· セキュリティと暗号化
o KMS
o IAM
· RDSによる管理機能
· データロード・アンロード
o AWSマイグレーションツール
· PostgreSQLとの互換性
o 互換性のためのレイヤーがあるのではない
o PostgreSQLの実装をそのまま利用している
o 互換性に関してはバグはない
パフォーマンス
· 同じサイズのインスタンスで比較
o PostgreSQL
§ 3つのEBS
· pgbenchでの比較結果
o ピーク性能の1.6倍以上
o 最多クライアント数で実行した際の2.9倍以上のスループット
· Sysbench出の比較結果
o ピーク性能の2倍以上
o 最多クライアント数で実行した際の5倍以上のスループット
· AWSの見解
o 保守的に見ても、標準のポスグレよりも2~3倍性能がいいと言える
· スループット比較
o DBサイズが10GBから100GBに増えるとどうなるか？
o 1.8倍から4.4倍違う
§ GQ版はプレビュー版よりもさらに高性能になっている
o DBロードでは、標準の2倍以上速く完了
§ コピー
§ バキューム処理
§ 特にAuroraはバキューム処理が早い
§ 標準よりも86％削減できる
§ Writeの回数が圧倒的に減っているため
§ インデックス構築
· レスポンスタイム比較
o 標準に比べて2倍以上短い
o スパイクも99%削減
§ 標準はチェックポイント時に跳ね上がる
§ Auroraはチェックポイントのスパイクはない
§ 標準よりも99%削減
§ チェックポイントを持たない
· スループット比較
o 標準に比べて3倍以上一貫した結果が得られた
· リカバリ時間比較
o ストレージシステムのリカバリが高速に実行可能
o 標準よりも97%短く
§ 標準
§ redoログサイズとともにクラッシュリカバリの時間が増加
§ redoログ3GBで19秒
§ redoログ30GBで123秒
§ Aurora
§ redoを持たない
§ 極めて高いスループットを維持
§ 3秒以内にリカバリを完了
パフォーマンスインサイト
· DBの可視化をするダッシュボード
· データサンプリングを自動化する
o Top SQLも見れる
· まだプレビュー版
o GA提供はまだ
DBマイグレーションサービス
· AWS DB Migration Service
o データ移行の開始まで10分以下
o 移行中もアプリを実行可能
o 同種・異種間DBにて移行可能
· AWS Schema Conversion Tool
o RDBのコンバート
o DWHのコンバート
o 利用すると評価が得られる
§ 自動コンバートできないものがあれば理由も表示される
o 様々なターゲットを比較できる
§ 例えば、OracleからどのオープンソースDBがいいかを教えてくれる
§ MySQLか？
§ PostgreSQLか？
Aurora with PostgreSQLについて
· 10/24ローンチ
· セキュリティ
o KMS
o SSL
o VPC default
· 高可用性
o 15代のリードレプリカ
o 高速なクラッシュリカバリ
· 高性能
o 標準の2～3倍のスループット
· 運用/互換性
o 機能レベルでの標準ポスグレとの互換性
§ 10.3もサポートする
§ メジャーバージョンは3年サポートする
§ マイナーバージョンは1年サポートする
直近のアップデート
· GAローンチ（12のリージョン。東京含む）
· HIPAA認証
· 暗号化されたRDSスナップショットのインポート
· RDS for PostreSQLから、Aurora PostgreSQLリードレプリカの作成
o ダウンタイムを減らすことができる
· Aurora PostgreSQL 1.1リリース（標準9.6.6との互換性）
今後
· PostgreSQL10のサポート（1か月以内）
· クロスリージョンレプリカ
· アウトバウンドレプリケーション
· マルチマスタ
· サーバレス
· これらは来年早々にはできるようになると思う
Auroraファミリー
· Aurora MySQLに早く追いついていく
【Session1】徹底検証！！Aurora with PostgreSQL compatibility
スピーカー
株式会社アクアシステムズ 影山さん
内容
ブログへの掲載禁止のため割愛。
【Session2】マルチリージョンのテレビ会議クラウドをAurora+DMSで実現した話
スピーカー
株式会社リコー 井上さん
関連発表
サービス全断はダメ、ゼッタイ。途切れないテレビ会議システムを目指して。 ※去年のAWSサミット発表資料
Ricoh USCとは
· ビジネス向けテレビ会議システム
· 専用端末＋クラウド
· グローバル
o お客様に近い映像配信サーバから届ける
o AWSで11のリージョンを使っている
· 多拠点つなげる
· 2011年からprivateクラウドで運用開始
· 2017年に全サービスのパブリッククラウド移行完了
o Aurora運用開始
現構成
· 呼制御系
o AWSの公式ページに構成図あり
o ECSなど活用
· 映像配信
· サービス監視
AWS移行直後の構成
· オンプレからほぼそのままの構成で移行
· MySQL/RDSを1セット配置
· 課題
o インスタンス数が多い
§ 複数リージョンで協調動作するシステム
§ データは主に3種類
§ 主リージョンで書き込み、全リージョンで参照
§ 全リージョンで読み書き、主リージョンに集約
§ SPOFの内向性が必要
o フェイルオーバー時間に不満
§ アプリ対応に限界
o ストレージ不足に拡張処理が必要
o 小サイズのRDSは効率が悪い
§ ５GBで十分なDBもある
§ GP2ストレージの性能不足、補うには33GB以上が必要！！
· 進構成の検討
o Auroraの利用
o しかし
§ 数が多いため高コストで無駄が多い
o そこで
§ DMSによる柔軟なレプリケーション構成を検討
· DMS
o 移行を行うマネージドサービス
§ RDBMSからS3などもできる
o 一括コピー、継続的コピーが可能
o テーブルを取捨選択してコピー可能
o スキーマを変換しながらのコピー可能
· DMSとMySQL
o 変更検知はBinary Logを使用
§ checksumなし
o 注意点
§ 文字セットの制限
§ 以下は使えない
§ utf8mb4
§ us_ascii
§ 開始点は秒単位の時刻で指定
· 最終的なDMS導入決定
o 想定外の問題はAWSと協力してつぶしていく！！
新構成と移行
· リージョンごとに1つのAuroraクラスタをマルチAZで設置
· 検証
o Auroraのサイジング
o アプリの機能テスト・性能テスト
o ソースおよびターゲットDBのフェイルオーバー
o DMSの機能・性能
· 検証で分かったこと
o 機能や性能に問題はない
o Auroraのフェイルオーバー追従に課題
· Auroraのフェイルオーバー
o マルチAZでは30秒くらいで切り替わる
· クライアントから見た課題
o 読み書きするクライアントがレプリカにつながってしまう
· 対策
o JavaアプリはMariaDB Connector/Jを利用
§ 高速フェイルオーバーの恩恵を受けれる
o クライアントを修正する
§ 泥臭い修正
· DMSの挙動
o ターゲットのAuroraが切り替わる：自動接続
o ソースのAuroraが切り替わる：自動接続しない
§ DMS1.9時点
· 対策
o DMSタスク監視
· 移行手順１
o MySQLからAuroraのリードレプリカを用意してレプリケーション
o そのほかのDBからもAuroraへレプリケーション
· 移行手順２
o 当日の作業は30分くらい
§ 旧DBからAuroraへのレプリケーション停止
§ DMSで処理できないDBをダンプから投入
§ DMSタスク作成＆開始
9か月分かったこと
· Auroraクラスタは毎日作るものではない
o 開発環境は毎日構築・破棄
o Auroraクラスタのスナップショットからの構築は遅い。時々失敗する
o Auroraクラスタだけ残してもコストはS3の5倍程度
o 句ら鵜s他を残し、DBインスタンスのみ毎日構築するようにした
· Auroraアップっグレードとの付き合い方
o 必須アップグレードは所定の期間内にメンテナンスが必要
o 20~30秒のダウンタイムが発生
§ 本番環境以外で影響確認したい
o 旧バージョンのAuroraを顧客が作る方法はない
§ 本番以外で常時稼働環境が必要になる！！
· Zero Downtime Patching
o 接続を維持したままアップグレードできる機能
o DBの使い方によって背教が出る
§ サーバサイドのプリペアドステートメントが消える、など
まとめ
· すこしずつ移行するのがおすすめ
· 最終形ではない
o 日々のキャッチアップ
【Session3】Oracle DatabaseからAurora with PostgreSQL compatibilityへの移行～orafceの活用による活用事例＆メリット～
スピーカー
NTTテクノクロス株式会社 勝俣さん
orafceとは？
PostgreSQL上でOracleの機能を使えるようにする拡張モジュール 以下が使えるようになる - Data Type - SQL Queries - SQL Functions - SQL Operators - Packages
意外と多い細かな違い
· Varchar2(n)
o Oracle：byte数指定
o PostgreSQL：文字数指定
· DATE型
o Oracle：年月日時分秒
o PostgreSQL：年月日
メリット
· 移植の効率化
o ポスグレ標準＋orafceがサポートする関数カバー率：34%
o 実案件で使うだろう関数のカバー率：73%
【Session4】Oracle DatabaseからAmazon Auroraに移行するための実践ガイド
スピーカー
アマゾンウェブサービスジャパン株式会社 江川さん
お客様の声
· クラウドにシステム全体を移すのであれば、RDBMSもクラウドネイティブにしたい
· RDBMSもオートスケールさせたいが、CPUライセンスだとできない
· IT予算の多くをOracleライセンスを占めている
現場の悩み
· 業務部門・アプリ開発部門
o アプリへの影響はどれくらい？
o 移行の業務停止は短くしたい
· IT・インフラ部門
o 業務部門に何をガイドしたりいいの？
o 従来の管理腫瘍がどう変わる？
o 移行費用はかけたくない
決めないといけないこと（５W1H）
1. What?（対象システムは？）
2. Why?（移行理由は？）
3. How?（移行戦略は？）
AWSの考える6つの戦略
1. Re-Host(ホスト変更）
2. Re-Platform（プラットフォーム変更）
3. 移行の複雑さ2位
4. Re-Purchase（買い替え）オンプレのOracleを、ライセンス込のRDS for Oracleへ
5. Refactor（書き換え）オンプレのOracleをAuroraに変更する、など
6. 移行の複雑さ1位
7. その分のメリットは大きい
8. Retire（廃止）このタイミングで古いDBやシステムを破棄する
9. Retain（保持）オンプレを使い続ける（Oracle9iに依存してるアプリなど）
4. Where?（移行先は？）
· RDS
o Aurora MySQL
o Aurora PostgreSQL
§ 結合法方
§ ネステッドループ
§ ハッシュ
§ ソートmerge
§ インデックス
§ Bツリー
§ 関数
§ 空間
§ 全文
§ ゾーンマップ
§ 制約
§ NOT NULL
§ PK
§ UNIQUE
§ FK
§ CHECK
· Redshift
o データウェアハウス用途
· on EC2
5. When?（期限は？）
· 工数見積が必要
o 工数＝移行先との違いの量
6. Who?（担当者は？）
· 工数見積が必要
o 工数＝移行先との違いの量
移行支援サービス
· 計画
o AWS CTO Calculator
· 移行
o AWS DMS
· 運用
AWS DMSとは
· 既存DBを最小限のダウンタイムでマイグレーションするサービス
· 同種はもちろん異種プラットフォームの移行にも対応
· 移行中もアプリケーションは稼働したまま
o AWS上にDMS用のAurora起動
o 移行元のDBとDMSを以下で接続
§ Internet
§ VPN
§ Direct Connect
o DB同期が完了したら、アプリ側のDBの向き先を変える（ダウンタイムはここだけ）
· マルチAZ構成が可能
AWS Schema Conversion Tool
· ソースDBのビューやFunctionをターゲットDB向けに変換
· デスクトップアプリで提供
· できること
o 自動変換＆自動変換の補助
o 評価レポートの作成
§ どこができるか色分けされたグラフが出る
§ 緑：自動変換
§ 青：検討が必要
§ 赤：深い検討が必要
o アプリケーションSQLにも対応
事例
· レコチョク
o Oracle RACからAurora移行
§ 1000万会員のDB
o DMS/SCTリリース前に手動で移行
o 結果
§ Auroraによる障害はこれまでゼロ
§ DBサーバ運用に工数はほとんど咲かなくてよい
Oracleとの違い
· Objectの主な違い
o MySQLのシーケンス
§ AUTO_INCREMENT属性を付与
§ NULLまたは0を入れる
o PostgreSQLのマテリアライズドビュー
§ リフレッシュは手動のフルリフレッシュのみ
§ 読み取り専用のみ対応
o PostgreSQLのDBリンク
§ dblink
§ 関数として実装されている
§ ビューで隠ぺいするのが一般的
§ postgres_fdw
o パーティショニング
§ MySQL
§ RANGE、HASH、LIST、KEY
§ PostgreSQL
§ RANGE、LIST
§ v10~宣言的パーティショニング
§ ストアドプロシージャ/ストアドファンクション
§ AuroraはJavaプロシージャに未対応
· 互換性がないとどうなるのか
o 文法ERRORになる
§ 地道に対応する
o 文法ERRORにならず結果が異なる
§ このパターンが厄介
結果相違を起こしやすい2大ポイント
1. NULLと空文字の扱いの違い
2. OracleがSQL標準からずれている
o Oracleでは区別しない
o MySQLやPostgreSQLは区別する
3. 対策
o ''でgrepするとよい
o 外部結合した後の||にも注意
4. CHARの埋められた空白の扱いの違い
5. Oracleは末尾の空白を保持する
6. MySQLとPostgreSQLは、末尾の空白を無視する
トランザクション分離レベル
· 数やデフォルトがDBで違う
バキューム
· postgreSQL独自
· 運用設計が必要
o 今は自動になっている
【Session5】移行の前には移行アセスメントを～移行難易度や工数を事前に確認する～
スピーカー
アマゾンウェブサービスジャパン株式会社 北川さん
現実では・・・
簡単にDB移行できないこともある（外字が入っているとか）
移行前に実施すべき内容
1. システムの棚卸
2. 移行対象DBを使っているシステムの把握
3. システム間連携の有無
4. データの流れの把握
5. 障害発生時の復旧プロセス
6. そもそもDMSがサポートしているDBバージョン・エディションか？
7. 移行対象の決定
8. ミドルウェアのサポート終了期間の確認（緊急度）
9. アセスメントの実施
10. プロシージャの数
o DDLはSCTで自動変換できる
o プロシージャはDCTの自動変換率が比較的低い
§ SCTで評価レポートを作成する
§ 予想工数が色分けされる
§ 青：1時間未満
§ 黄：4時間未満
§ 赤：4時間以上
11. SELECT文の数
o 自動変換率が比較的低い
12. テストの洗い出し、工数確認
o SQL解釈の方言で同じSQLでも結果が違う可能性がある
o データが正しく移行されたかの確認が必要
o テストフレームワークがあればよいが、なければ大変
o 工数だけで判断しない
§ 重要度と緊急度も考慮する
13. 移行計画
o ダンプツール
o CSVアンロード
o レプリケーション
o DMS
§ 何でもかんでもDMSでやろうとしない
§ ネイティブの方法がベストな時もある
14. 事前検証の実施
15. 選択した移行方法で留意事項を確認
o ￥マーク、外字など
o 同期レプリケーションか？非同期レプリケーションか？
§ どれくらい時間差があるのか
§ 非同期の場合クラッシュしたらどうするか？
§ マルチAZ構成
§ DMSで二重障害が起きるとどこから再開するかが困難
§ 「十分な時間がとれるか？」を再度検討すべき
16. スケジュールの策定
17. 事前検証結果から、移行方法が妥当か確認
18. 連携状況から他のシステムを含めた影響を確認
o 本当に並行移行させる必要があるのか？
o 1日止めれば難易度は下がるのでは？（安全かつ確実）
§ など
19. トラブルを見越したスケジュールを組む
20. 検証には可能な限り実データを使用する
https://www.yokoyan.net/entry/2018/03/30/220000
0 件のコメント:
コメントを投稿