スケールアウトのデメリットを解決する方法
杉山：スケールアウトのデメリットをどのように解決して運用しているのか、私からお話しさせていただきます。
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パーセントほど削減できたことは、非常に良い取り組みになったのではないかと思っております。
最後に、このようなデメリットを技術で解決をし、よりよいシステムを作って運用していく。そういった創意工夫が、とてもおもしろい取り組みになると私自身感じたところです。
ご清聴ありがとうございました。
（会場拍手）
