Azure SQL Database 節約術
鶴見純一氏（以下、鶴見）：「ZOZOTOWN Azure SQL Database 節約術」ということで、鶴見と杉山の2名で発表します。
まず、自己紹介をさせてください。
ZOZOテクノロジーズの開発部リプレースチーム リーダーの鶴見と申します。2016年に入社し、当初はファッションコーディネートアプリ「WEAR」のバックエンドを担当していました。2017年の冬からファッション通販サイト「ZOZOTOWN」のリプレースチームで、リプレースを行っております。
杉山 弘二氏（以下、杉山）：私はZOZOテクノロジーズ開発部リプレースチームの杉山と申します。
2017年にスタートトゥデイ工務店、現ZOZOテクノロジーズに入社をいたしました。前職等々も含めて、現職ではクラウド周りを触っておりますが、フロントエンドからサーバサイド、インフラ、クラウド、iOS、ネイティブアプリまで、幅広く経験を持つクリエイターです。
後半の監視周りのシステムを担当いたしましたので、こちらのお話をさせていただきます。
鶴見：最初に1点だけ宣伝させてください。今日1本サービスがリリースされました。「コーデ相談 by WEAR」というサービスで、Amazon Alexaのスキルで、音声だけでコーディネートの相談ができるサービスがリリースされたので、興味をお持ちいただけましたら、使ってみてください。
SQL Database節約の経緯
ここから本題に入ります。SQL Databaseの節約ですが、なぜ節約が必要になったかを話したいと思います。オンプレで苦労したことの1つが、ZOZOTOWNは今もほぼオンプレで動いていて、データベースをスケールアップさせるのが大変でした。
そして「セールの時だけスケールアップさせたい」という要望がありました。ZOZOTOWNの2018年の実績でいうと、年に4、5回、大きなセールがあります。この時だけスケールアップをさせたいという要望です。
オンプレで解決しようとすると、セールに耐えうるだけのリソースを事前に用意する必要があります。そうなるとハードウェアの調達など、数ヵ月前から準備が必要な状態でした。それをクラウドにすれば、データベースを簡単にスケールアップさせることができるのではないかと考えました。
現在オンプレミスの中で書き込み系のデータベースと参照系のデータベースに分かれていて、どちらもSQL Serverで動かしていましたが、その片方の参照系のデータベースをクラウドへ移行しました。クラウドに移行したので、PaaSであるSQL Databaseを使っています。クラウドはAzureを使っています。
クラウドに移して、データベースのスケールアップ・スケールダウンできるようになったのですが、料金高く、予算オーバーになってしまいました。そのため、コスト削減が必要になりました。
参考までにどのくらいかの料金を載せています。
モデルやサービスレベル、Core数とメモリ数によって料金が変わってきます。
ZOZOTOWNの場合、このSQL Databaseは何個か立てているので大きな金額になっています。
コスト削減のために行ったこと
コスト削減のために2つのことを行いました。
1つ目がSQL Databaseのオートスケール、2つ目がRead Scale-Outと呼ばれるものです。1つずつ説明させていただきます。
まず、オートスケールについてです。オートスケールには2種類あるかと思っています。
1つ目がデータベースのCPUやメモリ使用量によってスケールをアップ・スケールダウンさせる方法、もう1つは事前にアクセスが増える時間帯がわかっているのであれば、時間帯でスケールアップ・スケールダウンさせる方法です。
ZOZOTOWNの場合、アクセスには波があります。
朝から夕方までのアクセスは普通ぐらいで、夕方から夜にかけてはアクセスが増えていきます。また、深夜帯になるとアクセスが少なくなります。だいたいのECサイトはこのようなトラフィック数の推移かと思います。
これに合わせて、スケールを変更してみてはどうかと考えました。
例えばこのような設定です。
時間帯別にそれぞれのCore数やメモリ数を変更させて、1時間当たりの料金をできるだけ抑えるようにする設定です。実際にこのコストを計算したところ、常に16Core使ってたとすると\927,000ぐらいかかりますが、時間帯によってスケールさせると\502,000ぐらいになり、これでだいたい40数パーセントのコスト削減に繋がりました。
Azure Automation
どう実現させたかですが、Azure Automationを使っています。Azure AutomationはPowerShellを、定期的に実行してくれるサービスになっています。
スケール変更は簡単なプログラムを用意するだけで実現できます。
そして用意したPowerShellをAzure AutomationのRunbookに登録し、スケジュールを決めることでスケールアップ・スケールダウンすることができるようになりました。
これにはメリットとデメリットがあります。
メリットは先ほどお伝えしたようにコストを40パーセント削減できたことです。仕組み化したので、セール時も同様の仕組みで対応が可能になりました。
デメリットは、今回ビジネスクリティカルというサービスレベルを使ったのですが、その場合スケール変更にだいたい30分以上かかります。今まで何十回もスケールをアップさせたりダウンさせたりしていますが、だいたい30分ぐらいかかっています。公式では容量100GBに対して90分以内と記載がありました。なので、かなり時間は掛かってしまう印象です。
また、スケール変更時に10秒ほどの切断がどうしても発生してしまいます。ここはリトライ処理を入れていて、一度接続を試みてだめだった場合、別のDBに接続がいくようなリトライ処理を入れて、回避させています。
スケールダウンでリソースを低めにしすぎると、メモリも同時に少なくなってしまい、主要データがメモリに乗らない状態になってしまうことがあります。パフォーマンスがかなり落ちてしまうので、調整が必要です。
Read Scale-Out
もう1つ、Read Scale-Outを行っています。
Azureでデータベース作ると、ユーザから見ると1つのデータベースに見えますが。
実際はAzureの中で3重化されています。ユーザから見えているのは、この「プライマリレプリカ」と呼ばれている部分だけです。実は裏にセカンダリレプリカが2つ作成されています。
特徴としては、プライマリレプリカのデータだけReadとWriteが可能になっていて、セカンダリレプリカに対してはReadしかできない仕様になっています。デフォルトではReadする機能はオフになっているので、有効化させる必要があります。セカンダリレプリカは2つ必ず作成されますが、参照できるReadとして使えるのはそのうち1つだけです。
Azure Portalからでも簡単に有効化や無効化ができたり、もちろんPowerShellでも簡単に設定の変更ができます。
接続するときは、この接続文字列の中に「ApplicationIntent」というものがあるので、そこに対してどちらのデータベースに接続するかを指定できます。
こちらもメリットとデメリットがあります。
メリットは1台のデータベース料金で2台分のReadの性能が発揮できることです。デメリットはセカンダリレプリカのメトリクスが簡単に取得できないことです。標準のメトリクス取得が用意されていないので、そのCPUやメモリを取る場合はデータベースに直接接続しないと値が見れない状態でした。
こうしたデメリットがあったので、対策を入れました。この続きは、杉山から発表させていただきます。
