Thinkings株式会社で提供しているサービス「sonar ATS」は毎年3月と6月が繁忙期になります。
採用管理に用いられるシステムのため、学生用サーバ、顧客（企業）用サーバが必要になります。
採用活動が活発になる3月、6月は、アクセス集中に耐えられるようにインフラの増強をしており、知見もだいぶたまってきたので情報発信したいと思います。
sonar ATSのインフラ構成と増強対応方針
sonar ATSは、Microsoftによって提供されているAzure上にて構成されています。
主に下記などで構成されています。
- Azure Cloud Services
- Azure SQL Database
- Azure Storage
- Azure Cache for Redis
- Azure Front Door
2024年3月の繁忙期対応として実施した内容は下記になります。
- Cloud Servicesのインスタンス数増加
- Elastic Poolの最大DTU増加
- Cache for Redisのスケールアップ
- フェールオーバー環境の構築
Cloud Servicesのインスタンス数増加
sonar ATSでは、Cloud Servicesの平均CPUが一定以上にならないように、オートスケール機能や手動スケールによって負荷分散を行っています。
今年は学生用サーバのインスタンス数を30台から45台へ増加させました。
（sonar ATSの学生用サーバーは、3月に求人エントリーを開始する企業が過半数いるため、アクセス集中する）
学生用サーバは、Azure Portalのメトリック機能で平均CPU(%)が30%未満になるように調整しています。
今年は例年より負荷が上がらなかったので、35台とかでも良かったかもしれません。（平均CPU(%)が最大でも20%を超えていないため）
この30%という閾値は、完全に経験からくるものです。
この閾値を超えると、レスポンスが遅くなるなどの影響が出始めます。これは、サービス運用の中で台数調整を繰り返す中で得た知見になります。
（ソフトウェアの特徴によってこの閾値は前後するため、「sonar ATSでは」という限定的な話です）
Elastic Poolの最大DTU増加
sonar ATSでは、Azure SQL Database の Elastic Pool を複数に分けることで負荷分散を行っています。
sonar ATSは顧客の単位を「クライアント」、顧客がサービスを購入する際の単位を「プロジェクト」としており、Elastic Pool 毎にプロジェクト数の最大値を決めて管理をしています。
これは、1プロジェクトあたりの平均DTUを4として、Elastic Poolの最大DTUに対して収容可能なプロジェクト数を計算しています。
平均DTUが4というのは、過去2年分の稼働実績データと当時の稼働プロジェクト数とで傾向を分析した結果導き出された数値です。これまでの担当者が当時の実績データを蓄積してくれていたから出来たことですね。（Azure上の実績データは一定期間で消えるため、データの収集と記録は重要）
ちなみに、平常時は平均DTUを4で計算しますが、繁忙期は平均DTUを5で計算しています。
Cache for Redisのスケールアップ
sonar ATSでは、Cache for Redisでセッション管理をしているため、Azureのアラート通知を使った監視や稼働実績の定期監視、スケールアップの実施により負荷低減を行っています。
繁忙期はリアルタイムで稼働状況の監視を行っております。
稼働実績の定期監視については、基本的にServer Loadの値を監視しており、これが70%以下になるようにスケールサイズを調整しています。
（今回はP2からP3にスケールアップしました。）
当時、Redisの稼働が100%に張り付いていることが原因の障害が発生したばかりだったので、稼働の急な増加に備えてスケールアップの判断をしました。
3/1からスケールアップしていますが、図を見ると70%以下をキープできていますね。
フェールオーバー環境の構築とその経緯
sonar ATSでは、フェールオーバー環境を常時立ててはいません。
平常時は東日本環境で稼働をしており、繁忙期のみフェールオーバー環境を立てています。
Azure SQL Database以外は1時間もあればフェイルオーバー環境を構築できるため、Azure SQL Databaseのみ準備しておきます。
手順は下記です。
- Azure SQL Databalseのリソースにフェイルオーバーグループを構成する
- Elastic Poolを西日本リージョン向けに作成する
- この際、リソースグループやサーバーは西日本環境用のものを設定する
- フェイルオーバーグループへ「データベースの追加」をする
平常時に東日本環境で大規模障害が発生した場合は、フェールオーバー環境をその時に立てる運用になっています。
じゃぁ、なぜ繁忙期だけ事前に環境立ててるの？という話なんですが、これは過去の痛い経験に基づきます。。
2016年6月1日にAzure（東日本リージョン）の大規模障害が発生して、sonar ATSも大きな影響を受けました。
6月1日の選考開始に向けて準備されていた顧客企業の期待に応えられない状況となってしまいました。
担当エンジニアの所感
担当の方に「この業務やっててどうですか？」と聞いてみました。以下、回答になります。
導入実績が1,900社以上となりsonar ATSって、かなり大きなサービスになってきていると思うんですが、サーバーの負荷とかって「1顧客あたり4dtu」って言いきれるものでもないと感じています。だから、未来1年とか2年先の顧客数の遷移予測を立てて、今後どこに問題が出そうかなどを考察するようにしています。
営業の皆さんが頑張ってくれている甲斐あって、顧客数2,000も近い未来で超えてくると予測しています。
「そういうプロダクトを支えられている」というやりがいも感じますし、それだけの技量がついたっていうのは自分にとって嬉しく思います。
Discussion