ZOZOTOWN Azure SQL Database 節約術 / ZOZOTOWN SQL Database Cost Reduction

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Copyright © ZOZO Technologies, Inc. All Rights Reserved. SQL Database 節約の経緯オンプレで苦労した事の1つは、データベースをスケールアップさせるのが容易ではない事。 2018/01 冬セール 2018/05 ZOZOWEEKセール 2018/06 夏セール 2018/11 ZOZOWEEKセール / 福袋 ※2018年セール時期実績

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Copyright © ZOZO Technologies, Inc. All Rights Reserved. SQL Database 節約の経緯 Azure SQL Database 料金リージョン：東日本 / ハードウェア世代：4世代 / モデル：vCore / サービスレベル：ビジネスクリティカルその他、容量も1GB単位で選択でき課金されます。 Core数メモリ (GB) 月額 (¥) 4 28 約23.5万 8 56 約47.0万 16 112 約94.1万 24 157 約141.0万 2019年5月時点の金額

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Copyright © ZOZO Technologies, Inc. All Rights Reserved. SQL Database オートスケール例えば、以下のような設定にする。リージョン：東日本 / ハードウェア世代：4世代 / モデル：vCore / サービスレベル：ビジネスクリティカル ` 時間帯 Core数メモリ (GB) 1時間 8:00 – 18:00 8 56 ¥644.2 18:00 – 24:00 16 112 ¥1288.5 00:00 – 8:00 4 28 ¥322.1

Slide 20

Slide 20 text

Copyright © ZOZO Technologies, Inc. All Rights Reserved. SQL Database オートスケール常に 16Core を利用した場合 ¥1,288.5 (16Core) * 24時間 * 30日 = ¥927,720 時間帯別にスケール変更した場合 ¥644.2 (8Core) * 10時間 * 30日 = ¥193,260 ¥1,288.5 (16Core) * 6時間 * 30日 = ¥231,930 ¥322.1 (4Core) * 8時間 * 30日 = ¥77,304 合計 ¥502,494 `

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Copyright © ZOZO Technologies, Inc. All Rights Reserved. SQL Database オートスケールスケール変更する PowerShell を用意する。 Set-AzSqlDatabase -ResourceGroupName ` -DatabaseName ` -ServerName ` -Edition ` -ComputeGeneration ` -VCore

Slide 23

Slide 23 text

Copyright © ZOZO Technologies, Inc. All Rights Reserved. SQL Database オートスケール Azure Automation の Runbook に PowerShell を登録し、スケジュールを決めるだけでスケールできるようになる。 CPUやメモリの使用率でスケールさせる場合は、定期的にCPUやメモリのチェックを Azure Automation に組み込む。

Slide 24

Slide 24 text

Copyright © ZOZO Technologies, Inc. All Rights Reserved. SQL Database オートスケールメリット • コスト削減できる。 • 仕組み化したことでセール時も同様の対応が可能デメリット • ビジネスクリティカルの場合、ZOZOTOWNだとスケール変更に30分程度かかる。（スケールの時間はモデル、サービスレベル、容量により異なります） • スケール変更時（切替時）に10秒程度の切断がある。 • スケールダウンでメモリも小さくしすぎると、主要データがメモリに乗らなくなる可能性がある。（パフォーマンス劣化の可能性） `

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Copyright © ZOZO Technologies, Inc. All Rights Reserved. SQL Database Read Scale-Out ユーザ Primary Replica Secondary Replica Secondary Replica DTUモデル Premium または、vCore モデルビジネスクリティカルを利用すると3重化される。 Read Scale-Out にて Secondary Replica の1つを Read することが可能となる。同期

Slide 27

Slide 27 text

Copyright © ZOZO Technologies, Inc. All Rights Reserved. SQL Database Read Scale-Out 特徴 • Primary Replica はデータの Read / Write が可能。 • Secondary Replica はデータの Read のみ可能。デフォルトで Read 機能は OFF になっているため利用するときは有効化が必要。 • Secondary Replica は2つ作成されるが、Read として利用できるのは1つのみ。

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Copyright © ZOZO Technologies, Inc. All Rights Reserved. SQL Database Read Scale-Out 接続時に Primary Replica、Secondary Replica を指定する # Primary Replica接続 Server=tcp:;Database=;ApplicationIntent=ReadWrite; User ID=;Password= # Secondary Replica接続 Server=tcp:;Database=;ApplicationIntent=ReadOnly; User ID=;Password=

Slide 31

Slide 31 text

Copyright © ZOZO Technologies, Inc. All Rights Reserved. SQL Database Read Scale-Out メリット • 1台のデータベース料金で、2台分の Read として利用できる。デメリット • Secondary Replica のメトリクスが簡単に取得できない。標準でメトリクス取得が用意されていないため、データベースに接続し直接参照しないとメモリやCPUの値が取れない。

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Copyright © ZOZO Technologies, Inc. All Rights Reserved. Read Scale-Out のデメリット・Azure 標準の機能では、 Secondary Replica のメトリクス取得ができない。・監視できないサービスは運用できない。 Secondary Replica も含めた、カスタムメトリクス収集システムを自前で作って Datadog で運用している。

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Copyright © ZOZO Technologies, Inc. All Rights Reserved. 定期実行を行うシステムを構築する場合の選択肢・Virtual Machine を立てて cron で定期実行させる。・OSS系のジョブスケジューラーを使う。 ┗ kubernetes の「CronJob」を選択。弊社では、クラウドで運用するアプリケーションを kubernetes で運用している。監視システムの運用環境も kubernetes に統一することで、管理の面でも運用負荷が下がることから、 kubernetes CronJob を選択した。

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Copyright © ZOZO Technologies, Inc. All Rights Reserved. 使用する kubernetes リソース・Jobコンテナ： cronjob ( monitor-cronjob ) 対象データベース（Read-Scale-Out の Secondary Replica）のメトリクス情報を API に問い合わせ。取得したメトリクスを Datadog に送信する。・APIコンテナ： deployment ( monitor-deployment ) 任意のデータベースに DMV（動的管理ビュー）の情報取得クエリを発行し、JSON返却。・ClusterIP： service ( monitor-service ) deployment を Cluster内で名前解決させる。

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Copyright © ZOZO Technologies, Inc. All Rights Reserved. ちなみに、メトリクス収集システムを稼働している kubernetes の監視はどうしてるの？・Datadog には、「Azure Integration」や「kubernetes Integration」があり、各種標準的なメトリクス取得ができるので、これを使う。なお、Azure Integration では Secondary Replica のメトリクスは現在、取得できない。 ※2019年5月23日現在

Slide 51

Slide 51 text

Copyright © ZOZO Technologies, Inc. All Rights Reserved. まとめ Azure Automation、Read Scale-Out 、kubernetes CronJobを組み合わせてシステムを構築することで、当初のコストから約70%程度削減することができた。システム刷新する場合、コストも大事な要素。ビジネスにも影響があるため、非常に良い取り組みとなった。

Slide 52

Slide 52 text