de:code 2019 DP07...Azure SQL Database Hyperscale クラウド向けにデザインされたVLDB...
Transcript of de:code 2019 DP07...Azure SQL Database Hyperscale クラウド向けにデザインされたVLDB...
de:code 2019 DP07
そのオンプレの DB、どうやって Azure SQL
Database へ移行しますか?
~Benesse進研ゼミの事例~
日本マイクロソフトデジタルトランスフォーメンション事業本部
クラウドソリューションアーキテクト
高木充弘
ベネッセコーポレーションデジタル開発部技術支援課
課長
山崎 能史
ベネッセコーポレーションデジタル開発部
シニアアーキテクト
植田 省司
本日お伝えしたい事
DBの選択肢
コスト削減化
構成の再設計
SQL DB
検討フェーズ
SQL DB
移行フェーズ
SQL DB
運用フェーズ
事例からの学び最新情報からの学び
①選定のポイント
➂障害を未然に防ぐ
ポイント
➁移行作業
成功のポイント
vCoreモデル
Azure SQL Databaseの種類
• 予測可能なワークロード
• データベースレベルのサービス
• マルチテナント アプリケーショ
ン向け
• リソースを共有し効率的に
使用
Single Elastic Pool
DTU モデル
vCoreモデル
New
• ハイパースケール
• サーバーレス
• SQL Server との高い
互換性
• SQL Server 2005 以降
からの直接移行
• インスタンスレベルのサービス
• タイムゾーン指定
Managed Instance
New
GA
2GB 1TB 4TB 8TB 64TB 240TB
最大ストレージサイズ
• Premium
• General Purpose
• Business Critical
• Basic • Standard
• Hyperscale~100 TB
GA
※ プールの上限内で
1DB あたり
• Business Critical
• General Purpose
Elastic Pool
Single
Azure SQL Database Hyperscale
クラウド向けにデザインされた VLDB 用サービス
• 100TB の DB サイズをサポート
• サイズに関係ない瞬間的なバックアップ
• RPO は 0 分、RTO 10 分未満
• 読み取り専用のレプリカの数を最大 4台
• SLAは99.95%、複数のレプリカは99.99%
• スケールアップ/スケールダウンはオンラインでデータ
サイズに関係なく、5 分から 10 分程度
Azure SQL Database Hyperscale
• Hyperscaleから Single Database への移行はできない
• geo レプリケーションは未対応
• エラスティック プールは未対応
• SQL Database Managed Instanceでは未サポート
• 計算ノードのスケールアップとスケールダウンは自動ではない
Azure SQL Databaseの悩み
• 月額固定料金
• オートスケール型
Azure SQL Database Serverless
コンピューティングを持たない
CPU使用時間に応じて秒課金
自動停止
8:0
0
9:0
0
10:0
0
11:0
0
12:0
0
13:0
0
14:0
0
15:0
0
16:0
0
17:0
0
18:0
0
19:0
0
20:0
0
21:0
0
22:0
0
23:0
0
0:0
0
1:0
0
2:0
0
3:0
0
4:0
0
5:0
0
6:0
0
7:0
0
8:0
0
Azure SQL Database Serverless
最大vCore数
最小vCore数
CPU使用率
自動停止
課金なし
0.5 vCore
4 vCore
Azure SQL Database
• ウォームアップの間はアクセスの遅延が発生
• アイドル時間帯の index 自動チューニング、DB 監視で SQL を発行するような運用をしている場合、自動停止までの時間が延びる
• 性能を重視よりもコストを重視しているシステム
• 開発・テスト環境
• よくアクセスする DB は Single DB で、限定的に利用する DB はServerless のように使い分けする
クラウド化を検討するモチベーションは何か?
クラウド化する
モチベーション
運用負荷削減
End of Support
システム
リプレイス セキュリティGDPR
Big Data分析基盤導入
柔軟なリソース活用
DC契約期限切れ
現行システムの課題は?
ランニングコスト
EOL対応という「守り」もしつつ、新価値提供の「攻め」も
やらなければ...
新機能を追加するにはオンプレサーバを構築する必要がある。
サービス提供と直結しない領域にパワーが割かれるのは...
EOL 運用負荷
SQL移行ツール
• 膨大なSQLがあるため、移行時にはSSMAを有効活用
https://docs.microsoft.com/ja-jp/sql/ssma/sql-server-migration-assistant?view=sql-server-2017
SQL Server Migration Assistant
SQL修正の自動変換
手動変換したSQLの割合
%
• SSMAで自動変換が有効だった
• 移植作業量 → 1ヶ月で作業完了(5人月)
SQL総Step数 270万 Step
テーブル数 131 テーブル
Index数 65 index
実行SQL数 247 SQL
PL/SQL 5 本
SSMA注意事項
• PL/SQLは自動変換すると性能が落ちる
• DB特性はそれぞれ。本PJで約50個の差異発生
OracleはSQLが間違っていても動く
例)テーブル名.項目名が全角ピリオドでもOracleなら動くが、SQLDBだと動かない
Nullの扱いが違う(ちょっとハマった)
例)OracleだとNullは空文字とほぼ同義。SQLDBは異義。ソートの順番も違う
SQLミスの補完
文字の取り扱い
日付の取り扱い
関数の差異
シーケンスの取り扱い
ロック仕様差異
データ移行方法
• ネットワーク移送を採用
• 本番移行当日だけでは移行できないので初回と差分で移行
• 学年ごとにファイルを分割
• 移行当日は6時間のシステム停止で最終データ同期
分類 利用機能 結果
初回移行オンプレDBから出力したCSVファイルをBLOBへ送信し、Bulk インサート
データサイズ:580GB(1学年分)AZcopyでの転送時間:3時間SQLDBへのinsert時間:86時間
差分移行
オンプレDBから出力したCSVファイルをSSISを使ってインサート週次と日次に分ける
日次差分:1GB→2時間
移行した結果
• ランニングコストは 、障害 0件
• 高負荷時のスケールアップが容易に
• 4月号の年間最大負荷期間も楽々クリア
• DR対応 - 東日本リージョンの災害時は、西日本リージョンへ
• 12時間で1時間前の状態に復旧
• GeoバックアップからのリストアにてSQL DBを復旧させるため、西日本
リージョン側ランニングコストは数万円/月
71
どうやって監視する?
• “監視の民主化”→ 運用 + 開発 + ユーザ部門が同じツールで監視
• 各種メトリックスを1分粒度 / 460日間過去まで遡ることが可能
→ 障害の事前予防に大変有効!
可視化DTU/Session
CPU/Memory
IaaS VM
PaaS DB
(監視)
ベネッセの写真に置き換え
開発フロアー、事業部門フロアーに
複数のモニターを設置し可視化
まとめ
選定のポイント
障害を未然に防ぐポイント
移行作業成功のポイント
• SQL DBはインフラ層の維持をしなくて良いので激楽
• 繁忙期・障害の時にスケールアップできる構成に
• SSMAなどの既存ツール(+ナレッジ)を活用
• データ移行の方式をデータの質に着目して立案
• “監視の民主化” - 安定稼働させるために可視化と監視を
© 2018 Microsoft Corporation. All rights reserved.
本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。
© 2019 Microsoft Corporation. All rights reserved.
本情報の内容 (添付文書、リンク先などを含む) は、de:code 2019 開催日 (2019年5月29~30日) 時点のものであり、予告なく変更される場合があります。
本コンテンツの著作権、および本コンテンツ中に出てくる商標権、団体名、ロゴ、製品、サービスなどはそれぞれ、各権利保有者に帰属します。