Amazon Web Services ブログ
コラボスタイル が Aurora Serverless v2の採用でスケールアップ時のダウンタイムをゼロに。負荷の高かったスケールアップ作業からも解放
コラボスタイルは、クラウド型ワークフロー製品の開発・販売と、ワークスタイル自体のデザインやワークプレイスを構築する事業を展開しています。2022年12月に、自社で開発しているクラウドワークフローシステム「コラボフロー」をAurora PostgreSQL Serverless v2化することでスケールアップ時のダウンタイムをゼロに、負荷の高かったスケールアップ作業時の運用負荷を大幅に削減することに成功しました。本ブログは、2023年8月9日に実施した、2時間で学ぶ！Amazon Aurora オススメ機能 ～Aurora Serverless v2 ～のイベント内で、コラボスタイルの成島様にご登壇いただいた発表内容を元に、Aurora Serverless v2化の導入検討から導入効果についてまとめたものになります。Aurora Serverless v2の導入を検討している方の参考になればと思います。
アーキテクチャ
以下は、Aurora Serverless v2採用前のコラボフローのアーキテクチャになります。インターネットからWAFを経由するリクエストがCloudFrontからALBを経てアプリケーションサーバーに振り分けられます。アプリケーションサーバーからのリクエストは、Aurora クラスターのWriterインスタンスにアクセスして実行されていました。
大規模な障害の発生
2022年の前半、コラボフローでユーザーの業務に影響するような障害が発生しました。障害の原因を分析した結果、大きく2点が原因であることがわかりました。１つはコラボフロー自体のサービス面の問題で、1. ユーザー数の急激な増加、2. 利用状況の変化、3. アクセス数の増加により、データベースへの負荷が急増したことが原因でした。そしてもう１つはエンジニアのマインド面で、データベース運用が特定のエンジニアに属人化していたことでそのエンジニアを頼りすぎてしまい、多角的な視点が欠如していたことに気づきました。この障害がきっかけで、コラボスタイルでは特定の個人ではなくチームとして対応できるようSREチームを立ち上げ、障害を起こさないインフラ作りをチームで推進することになりました。
スケールアップによる新たな課題
SREチームでは、データベースの負荷を分析して、必要であればAuroraのスケールアップを実施するような運用にしました。これによって、障害を未然に防ぐことができるようになりました。一方で、スケールアップにともなう新たな課題に直面することになりました。
スケールアップにともなう新たな問題
- リザーブドインスタンス（RI）のサイジング
１つ目はRIのサイジングです。RIは最低1年単位での契約になるため、見積もりも１年間の予測を立てる必要があります。ですが、この障害以降の半年間で２回のスケールアップを実施しており、１年間の予測を立てることが難しい状況になっていました。 - 検証負荷
コラボスタイルでは、インスタンスサイズの変更に多くの時間を使って検証作業を実施していました。アプリケーションサーバーも含めた検証環境の構築や負荷テスト、負荷テスト結果の分析など、多くの作業が発生するため、スケールアップ毎に多くの時間を割く必要がありました。 - 停止メンテナンスの増加
スケールアップによるメンテナンスが増えることは、コラボフローのサービスへの影響はもちろん、ユーザーへのメンテナンスの案内や、メンテナンスの夜間作業などのエンジニアへの負担など、間接的な運用負荷も増えることになります。また、このような状況だと年間でのメンテナンス計画も立てづらい状況でした。 - 監視時間の増加
RIのサイジングやメンテナンスが必要なタイミングを適切に把握するためには、分析作業の頻度も多くする必要があります。その結果、監視時間や分析作業、判定会議などの運用負荷が増加し、本来SREとして取り組むべき作業時間が削られる、という問題も発生していました。
Aurora Serverless v2の導入
このような課題を解消するために、Aurora Serverless v2を導入することを決めました。Aurora Serverless v2は負荷に応じてシームレスにスケーリングすることができるため、コラボフローでのスケーリング時の運用課題を解決できる機能でした。
また、Aurora Serverless v2への変更も、通常のプロビジョンドインスタンスと同じように変更することができます。今回の移行では、ReaderをServerless v2に変更して１ヶ月程度検証したあと、フェイルオーバーで WriterをServerless v2に変更する、といった手順で、徐々にServerless v2に変更しました。この手順であれば、万が一Serverless v2に問題があった場合でも、再度フェイルオーバーすることで簡単にプロビジョンドインスタンスに戻すことも可能でした。
Aurora Serverless v2の導入による効果
Aurora Serverless v2導入して半年以上経過しましたが、パフォーマンス等の問題は発生しておらず、課題だったスケーリングに伴う運用負荷も大幅に改善することができました。
- Aurora Serverless v2の性能
Aurora Serverless v2の導入後、通常時はもちろん、サービスによる急激な負荷増大でスケーリングした時でも、4.5ms以下のレイテンシーでパフォーマンスを維持することができており、プロビジョンドと比較しても遜色ないパフォーマンスを実現できています。
- 運用負荷の改善、RIのサイジングの改善
Aurora Serverless v2はRIがないため、難しい見積もり作業自体が不要になりました。 - 検証負荷の改善
インスタンスサイズの変更に伴う検証作業は無くなりました。これにより、検証作業に関わるエンジニアの作業工数を削減することができ、本来SREが対応すべき作業にリソースを集中させることができるようになりました。さらに、以前は検証に伴う環境作成で発生するインスタンスコストも削減することができています。 - 停止メンテナンスの改善
スケールアップ作業自体が不要になり、エンジニアによる深夜対応なども改善されました。また、年間でのメンテナンス計画も立てやすくなりました。 - 監視時間の改善
RIのサイジングやメンテナンスが必要なタイミングを把握するためのモニタリングは不要になり、それに伴う打ち合わせなども無くなりました。一方で、Aurora Serverless v2のリソースを監視、分析して、最適化できるよう取り組んでいます。
Aurora Serverless v2の最適化
ここでは、SREチームで実施したAurora Serverless v2の最適化の取り組みの１つをご紹介します。SREチームがAurora Serverless v2のリソースを分析したところ、サービスの負荷が低い夜間の時間帯で思うようにスケールダウンがされず、日中のACU（Aurora Capacity Unit）のままのリソースが割り当てられていることがわかりました。ACUは、Aurora Serverless v2のデータベース容量で、1ACUあたり約 2 GiB のメモリとそれに対応する CPU、ネットワークが割り当てられます。
上記のグラフは、オレンジがACUのUtilizationで青がServerless Capacity、赤背景が負荷の低い夜間の時間帯です。ACUのUtilizationを見ると、負荷の低い赤背景の時間帯でも60ACUが割り当てられています。このため、負荷が低い時間帯に対してスケジュールで最小と最大のACUの設定を変更することにしました。このACUの最小値と最大値は再起動が不要で動的に変更可能であるため、Amazon EventBridgeのスケジュールでAWS Lambdaを呼び出し、値を変更することにしました。
この結果、負荷の低い時間帯にスケールダウンされるようになりました。これにより応答性能を維持しつつ、インスタンスのコストを12%削減することができています。
まとめ
コラボスタイルでは、今回のAurora Serverless v2の導入を成功させたことで、運用時の課題を改善し、SREチームとして本来の業務に専念することができるようになりました。そして、SREチームが「サービスを守る最強の盾」と代表から評価されるほど、社内でサービスを安定させるためのキーファクターになったことや、開発部の中にSREチームの考え方を強く浸透させることができたこともAurora Serverless v2採用の効果だったと言えそうです。コラボスタイルのSREチームでは、引き続きAWSサービスを利用しつつシステムの安定化やコスト最適化などに取り組んでいく予定です。