de:code 2019 DP07

そのオンプレの DB、どうやって Azure SQL

Database へ移行しますか?

～Benesse進研ゼミの事例～

日本マイクロソフトデジタルトランスフォーメンション事業本部

クラウドソリューションアーキテクト

高木充弘

ベネッセコーポレーションデジタル開発部技術支援課

課長

山崎 能史

ベネッセコーポレーションデジタル開発部

シニアアーキテクト

植田 省司

本日お伝えしたい事

DBの選択肢

コスト削減化

構成の再設計

SQL DB

検討フェーズ

SQL DB

移行フェーズ

SQL DB

運用フェーズ

事例からの学び最新情報からの学び

①選定のポイント

➂障害を未然に防ぐ

ポイント

➁移行作業

成功のポイント

SQL Database 最新情報

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契約期限切れ

そのオンプレの DB、どうやって

Azure SQL Database へ移行しますか?

～ Benesse 進研ゼミの事例 ～

自己紹介

事業部門の開発チームにて進研ゼミに関する

デジタルサービスの開発を担当

デジタル開発部 技術支援課課長

山崎 能史

デジタル開発部シニアアーキテクト

植田 省司

• 進研ゼミの専用タブレットを用いたデジタル学習

• 会員数60万人を超えるユーザ様に毎日学習でご利用

• データ量は4TB/200億レコードありました...

現行システムの課題は？

ランニングコスト

EOL対応という「守り」もしつつ、新価値提供の「攻め」も

やらなければ...

新機能を追加するにはオンプレサーバを構築する必要がある。

サービス提供と直結しない領域にパワーが割かれるのは...

EOL 運用負荷

オンプレシステムの構成

12台

12台

5台

6台

Webサーバ

アプリサーバ

Coherenceサーバ

DBサーバ

1.選定のポイント

どこに移行する？

Azureを選定した理由

「エンタープライズ向けの対応」

データベースは何に移行する？

PaaS Database

IaaS

CosmosDBSQL DW Managed

Instance

SQL Database

SQL Database を選定した理由

MS SQL一択

IaaS系はできるだけ排除

でもPaaS DBって... 心配有りません?

2.移行作業成功のポイント

開発着手前の心配事

• SQLをどれだけ修正する必要があるのか

• Azureで性能が出せるか、負荷に耐えられるか

• 大量のデータ移行ができるのか

不安

移行開発のポイント

• 自動変換ツール（SSMA）の採用

• システムテスト前に負荷試験の実施

• データの質（Update頻度）に合わせた移行方法

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ミスの補完

文字の取り扱い

日付の取り扱い

関数の差異

シーケンスの取り扱い

ロック仕様差異

性能・負荷試験の実施

F8×6台、P11×2台の構成を想定

F4×6台、P11×2台でOK！コストダウン

負荷状況（F4×P11）WebサーバCPU使用率

DBサーバCPU使用率

2,600TPSでCPU最大使用率

約50%

2,600TPSでCPU最大使用率

100%

最終構成決定

SQL Database

P11 x 2台

上限4TBのため、PaaS DBを2台使用

オンプレサーバ 35台を Azure側 9台で置き換え

データ移行方法は？

• データ量が多い、本番の差分更新が多い

• データ移行方法がたくさんあってよくわからない

データ移行方法

• ネットワーク移送を採用

• 本番移行当日だけでは移行できないので初回と差分で移行

• 学年ごとにファイルを分割

• 移行当日は6時間のシステム停止で最終データ同期

分類 利用機能 結果

初回移行オンプレDBから出力したCSVファイルをBLOBへ送信し、Bulk インサート

データサイズ：580GB（1学年分）AZcopyでの転送時間：3時間SQLDBへのinsert時間：86時間

差分移行

オンプレDBから出力したCSVファイルをSSISを使ってインサート週次と日次に分ける

日次差分：1GB→2時間

速度重視でワークテーブルからのmergeを採用mergeだとテーブルロックが発生

気を付けるべきポイント

移行した結果

• ランニングコストは 、障害 0件

• 高負荷時のスケールアップが容易に

• 4月号の年間最大負荷期間も楽々クリア

• DR対応 - 東日本リージョンの災害時は、西日本リージョンへ

• 12時間で1時間前の状態に復旧

• GeoバックアップからのリストアにてSQL DBを復旧させるため、西日本

リージョン側ランニングコストは数万円/月

71

3.障害を未然に防ぐポイント

どうやって監視する？

• “監視の民主化”→ 運用 + 開発 + ユーザ部門が同じツールで監視

• 各種メトリックスを1分粒度 / 460日間過去まで遡ることが可能

→ 障害の事前予防に大変有効！

可視化DTU/Session

CPU/Memory

IaaS VM

PaaS DB

（監視）

ベネッセの写真に置き換え

開発フロアー、事業部門フロアーに

複数のモニターを設置し可視化

それでもPaaSならではのトラブルがありました！

4月号配信の繁忙期にSQL Database の予告なしメンテ

PaaSのメンテナンス時間を指定したい！

PaaS（SQL Database）のメンテナンス時間枠を

JST夜間などで指定させて欲しい💢

ものすごく切実な願いです

セッションのおさらい

まとめ

選定のポイント

障害を未然に防ぐポイント

移行作業成功のポイント

• SQL DBはインフラ層の維持をしなくて良いので激楽

• 繁忙期・障害の時にスケールアップできる構成に

• SSMAなどの既存ツール（+ナレッジ）を活用

• データ移行の方式をデータの質に着目して立案

• “監視の民主化” - 安定稼働させるために可視化と監視を

Thank you all for your patience!

© 2018 Microsoft Corporation. All rights reserved.

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

© 2019 Microsoft Corporation. All rights reserved.

本情報の内容 (添付文書、リンク先などを含む) は、de:code 2019 開催日 (2019年5月29~30日) 時点のものであり、予告なく変更される場合があります。

本コンテンツの著作権、および本コンテンツ中に出てくる商標権、団体名、ロゴ、製品、サービスなどはそれぞれ、各権利保有者に帰属します。