CLOSE

ZOZOTOWN Azure SQL Database 節約術(全2記事)

スケールアウトのデメリットをいかにして解決するか? ZOZOTOWNのAzure SQL Databaseコスト節約術 Part2

2019年5月23日、DMM.comとZOZOテクノロジーズによる合同勉強会「DMM x ZOZOを支える基盤技術」が開催されました。数多くのサービスを展開している2つの巨大プラットフォームは、どのようなインフラ基盤・運用によって支えられているのか? 2社で活躍するエンジニアたちが、その舞台裏を明かします。プレゼンテーション「ZOZOTOWN HTTPS化におけるSREチームのアプローチ」に登壇したのは、株式会社ZOZOテクノロジーズ開発部、リプレースチームの鶴見純一氏と杉山弘二氏。講演資料はこちら

スケールアウトのデメリットを解決する方法

杉山:スケールアウトのデメリットをどのように解決して運用しているのか、私からお話しさせていただきます。

Read Scale-Outのデメリットですが、Azureの標準機能ではセカンダリレプリカのメトリクスは取得できません。基本的に監視のできないサービスは、運用がむずかしいのではないかと思います。

そこで、セカンダリレプリカも含めたカスタムメトリクスの収集システムを作り、メトリクスを可視化するDatadogというサービスを使って運用をしております。

監視のポイントですが、システム監視の要件としてRead Scale-Outを使用する場合でもCPU、メモリ、ディスクなどのメトリクスは必要です。

セカンダリレプリカを含めた定期的なメトリクスを取得できること。その他、ジョブやレプリケーションなどの実行、パッチの実行状況など、そういったカスタムのメトリクスも取得したい。そしてオートスケールによって台数増減もしますので、これも自動的にメトリクスを取得するようにしたい。そして安定した定期実行を実現したいなどがあります。

定期実行を行うシステムを構築する場合の選択肢としてバーチャルマシンを立てて、Cronで定期実行させる。また、OSS系のジョブスケジューラーを使うという選択肢があるかと思います。

当社では、クラウドで運用するアプリケーションをKubernetesで、既に運用しておりました。そこで、監視システムの運用環境もKubernetesを使って統一することで、管理の面でも運用負荷が下がるということで、KubernetesのCronJobというものを選択しました。

CronJobのメリット

Kubernetesとは、簡単に申し上げるとコンテナ化したアプリケーションのデプロイ、スケーリング、および管理を行うためのオープンソースのコンテナオーケストレーションシステムです。現在ではAzureやAWS、GCPといった主要なクラウドベンダーさんがサポートしているプラットフォームです。

そのKubernetesのCronJobとは?

Kubernetes上で定期実行を実現するためのリソースになっています。Kubernetes CronJobを使用してターゲットに合わせたカスタムメトリクス収集システムを稼働させて、Datadogで可視化をして、監視システムとして構築、運用をしております。

ここでCronJobのメリットをいくつかお話をさせていただきます。

まず、コンテナの鮮度です。CronJobでは定期実行でJobコンテナが起動するため、毎回フレッシュなコンテナが起動します。そのコンテナは終了後は破棄されるという動きをします。Jobコンテナ内にキャッシュやゴミがたまらないメリットがあります。

次に機能性です。ジョブスケジューラーですので、通常のCronにはない自動リトライや重複実行の制御、生存期間の設定など、さまざまな機能があるので使いやすいです。

次に汎用性、メンテナンス性です。

マニフェストファイルに環境変数や秘匿情報を設定できるので、稼働設定の変更が容易にできます。1つの種類のJobイメージを全ターゲットに流用できるため、汎用性、メンテナンス性が良いです。

1つのイメージで、環境変数や稼働設定をA、B、Cと書き換えて設定することで、それぞれ運用しているクラスタ(Aクラスタ、Bクラスタ、Cクラスタなど)に対象を向けることができます。

次に安定性です。

Jobスケジュールを実行する際、KubernetesではNodeの空きスペースを考慮して、Podを配置してくれます。そのため、リソースの偏りが発生しにくく安定して稼働させることができます。

使用したKubernetesリソース

今回使用したKubernetesのリソースです。

JobのコンテナとしてCronJobを使用しています。こちらは対象のデータベース……Read Scale-Outのセカンダリレプリカです。メトリクス情報をAPIに問い合わせをして、取得したメトリクスをDatadogに送信するという役割を持っております。

次に、APIコンテナとしてdeploymentを利用しております。こちらは任意のデータベースにDMV(動的管理ビュー)の情報取得クエリを発行して、その後JSONを返却するAPIコンテナになっています。

そして次にClusterIP。こちらはdeploymentをクラスタ内で名前解決させるために利用しております。

この3つのリソースを使用したシステムの構成がこちらです。

KubernetesのAPIサーバがスケジュールに基いてCronJobの作成を指示します。そうすると、Kubernetes(厳密にはcontainerd)がコンテナの作成を指示し、モニターのCronJobが起動します。

モニターはサービスに向けてAPIリクエストを投げ、APIはクエリを発行、各プライマリレプリカ、セカンダリレプリカからDMV情報を取得して、JSONで返却。返却されたメトリクス情報をJobコンテナがDatadogに送信します。送信が完了するとJobのコンテナは破棄される。というサイクルになっております。

送信されたメトリクスは、Datadogのダッシュボードでグラフに起こして見ることができました。

もちろんDatadogはAlertingの機能などもあるので、メトリクスを使用して、しきい値を設定し制限や条件を超えた場合にSlackへアラートをとばす設定をしております。

緊急時にCPUが90パーセントを超えて100パーセント張り付きそうになった時などには、PagerDutyを使って監視担当者へオンコールをする機能も実装しております。

メトリクス収集システムのKubernetesをどう監視しているか?

ちなみに、メトリクス収集システム自体のKubernetesをどのように監視しているの? という疑問を持たれることもあるかもしれません。DatadogにはAzure IntegrationやKubernetes Integrationと呼ばれるものがあり、各種標準的なメトリクスはこちらを使うことで取得できます。

Azure Integrationではセカンダリレプリカのメトリクスの取得はできない状況です(※2019年5月23日現在)。将来的にこちらのインテグレーションでセカンダリレプリカの情報なども取れるようになれば、もっと使いやすく専用のシステムも作る必要がなくなるので、できれば実現してほしいと思っております。

簡単にまとめさせていただきます。

Azure Automation、SQL DatabaseのRead Scale-Out、KubernetesのCronJob、こちらを組み合わせてシステムを構築することで、当初のコストから約70パーセント程度のコストを削減できました。

システムを刷新する場合、コストも大事な要素になると思います。ビジネスにも影響がある要素です。今回の取り組みにより、コストを70パーセントほど削減できたことは、非常に良い取り組みになったのではないかと思っております。

最後に、このようなデメリットを技術で解決をし、よりよいシステムを作って運用していく。そういった創意工夫が、とてもおもしろい取り組みになると私自身感じたところです。

ご清聴ありがとうございました。

(会場拍手)

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 孫正義氏が「知のゴールドラッシュ」到来と予測する背景 “24時間自分専用AIエージェント”も2〜3年以内に登場する?

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!