サービス縮退に伴いAmazon Aurora Serverlessを導入した話

WRITER: h.tatsu
2022/01/17
このエントリーをはてなブックマークに追加
シェア

はじめに

10ANTZでは数多くのゲームタイトルを開発、運用しています。中でも弊社でトップクラスの人気を誇る「乃木恋」というタイトルがあります。この記事を執筆している時点で6周年目を迎える長寿タイトルで、今もファンの方々に楽しんでいただけていると思います。一方その影では、役目を終えてクローズしていくタイトルも当然あります。本記事では、タイトルのクロージングにおいて、その対応の中で少しチャレンジした件について記載します。

背景

クロージング対応を任された当時、弊社CTOから可能であればサーバ費用のコストダウンを検討するように依頼を受けていました（本音はそのまま静かにクロージングしたかったですね）。10ANTZの運用タイトルは、普段からなるべく無駄のないように最適化されたサーバ環境を整えるように気をつけています。その中で更にコスト削減を狙うための一つの手段として、Amazon Aurora Serverless(以降、AuroraServerless)を導入できないか検討を始めました。

事前調査

AuroraServerlessは、簡単に説明すると必要な時に起動し、アクセスがない時には自動的に停止できるAuroraと思っていただければ良いと思います。執筆時点でv1、v2(プレビュー版)の２つが公開されています。当時はv1を採用しAuroraServerlessへの移行を行いました。ここからは当時AuroraServerlessについて調査した内容についてまとめます。

自動的に停止してくれる

サーバーレスというだけあってこれが一番のウリだと思いますが、アクティビティが一定時間ない場合は、一時停止させる設定が可能です。停止条件はキャパシティーの設定から変更でき、デフォルトでは5分アクティビティがない場合は停止とされているので、こちらで利用目的に応じた時間に設定可能です。また、一時停止オプションを選択しなければ停止させないことも可能です。

 

料金

AuroraServerlessの料金は、Aurora capacity unit(ACU)のサイズと利用した時間で決まります。ACU では、約 2 GB (GB) のメモリ、対応する CPU、およびネットワーキングが組み合わせられています。データベースストレージは、自動的に 10 ギビバイト (GiB) から 128 tebibytes (TiB) にスケールされます。ACUの最小、最大値はキャパシティーの設定から指定できます。設定によりますが、基本的に常時起動しておくならServerlessの方が料金は高いです。

自動スケーリング

料金調査でも少し述べていますが、自動スケーリングをしてくれるのもメリットのひとつです。負荷（ CPU 使用率と接続数）が制約の範囲を超えると自動的にスケールアウトするように設計されています。気をつける点としては、状況によってはスケーリングがされないこともあるのでユースケースとの相性も導入の際は検討事項になると思います（※スケーリング不可能なシチュエーションは後述する）。

自動スケーリングできない場合がある

公式ドキュメントでは自動スケーリングができない場合として下記の３項目が記載されています

  • クエリの実行時間が長い
  • トランザクションが進行中である
  • 一時テーブルまたはテーブルがロックされている

AuroraServerless はスケーリングする場合60~600sの間にスケーリングポイントを探します（時間は設定可能）。上記の３つの状況だと、単純にこのスケーリングポイントが見つからず自動スケーリング操作がタイムアウトしてしまいます。もちろん、[容量の変更を強制する] オプションから強制的に変更するようにもできますが、こちらもアプリケーション側の実装内容にもよって選択肢とするかどうかは変わってくると思います。公式ドキュメントにも設定する場合はアプリケーションが切断された接続または不完全なトランザクションから回復できる場合にのみ、[強制] オプションを選択することをお勧めします。と記載されています。

スケーリング時のダウンタイムの検証

最後の調査として、スケーリングした場合のダウンタイムの簡単な検証結果について記載します。

  • 検証方法
    • サーバレス環境のDBに対して継続的にINSERTするシェルを作成。
    • シェル実行中に手動でスケーリングを行い、ダウンタイムの発生について検証する

検証結果として、スケールアップする場合 (例えばACUを1から2へ変更する場合などは)、基本的には接続断などのダウンタイムは発生しない。一方でスケールダウン時はconnectionが切れる場合があった。

シチュエーション イベントメッセージ
スケールアップ時 キャパシティを 1 から 4 に変更

イベントメッセージ
Scaling DB cluster from 1 capacity unit to 4 capacity units for this reason: The customer initiated scaling.
The DB cluster has scaled from 1 capacity unit to 4 capacity units.
スケールダウン時 キャパシティを 4 から 1 に変更

イベントメッセージ
The DB cluster failed to scale from 4 capacity units to 1 capacity unit for this reason: A scaling point wasn’t found.
Scaling DB cluster from 4 capacity units to 2 capacity units for this reason: Autoscaling.
The DB cluster has scaled from 4 capacity units to 2 capacity units, but scaling wasn’t seamless for this reason: The database became unavailable.

導入時の懸念点

ある程度調査が終わった段階で導入する上でいくつかの懸念点が浮かびあがりました。

  • 常時稼働サービスでの事例があまり公開されていない
  • 常時稼働するようなユースケースは推奨されていなさそう
  • 本当にコスト削減になるか？

常時稼働サービスでの事例があまり公開されていない

当時AuroraServerlessの導入事例を調べると、使用頻度の低いアプリケーションや開発やテスト用のデータベースとしての用途で導入している企業や、データ分析API作成用に使用した事例がほとんどでした。これらは「使いたい時に使いたい分だけ」というサーバレス化のメリットを生かしたもので、今回の対応とはユースケースが根本的に異なっているものでした。

常時稼働するようなユースケースは推奨されていなさそう

AWS公式で公開されているユースケースを見ると、下図とされており、常時稼働中のサービスでは利用推奨されてないように見えました。

本当にコスト削減になるか？

しかしながら、今回の一番の目的はコスト削減で、ちゃんと稼働しコスト削減ができればサーバレス化で良いと考えていました。結果としては導入に踏み切ったのですが、導入理由としては料金見積もりで、常時稼働状態で当時のコストよりサーバレス化したほうが安くなったからです。

導入結果と感想

導入はこれまで稼働していたAuroraのスナップショットを元にサーバレスクラスター作成すればOKで、30分程あれば生成されます（所要時間はデータ量によって異なりますが、2年ほど稼働したタイトルでこの程度）。事前にサーバレスクラスターの設定まわりを確認しておくと本番の切替時にスムーズにいくのでおすすめします。

導入後は特に問題もなく、これまで通りサービス運用ができ、無事にクロージングまで稼働し続けることができました。AuroraServerless本来のユースケースとは異なっていたとは思いますが、今回の目的を達成するための手段の一つとしては間違っていなかったと思いますし、何より、AuroraServerless化の経験が積めたことは個人的には良かったと思います。導入へのハードルはそれほど大きくは無いので、興味のある方は一度テスト環境用にでも導入してみると面白いかもしれません。

参考

  1. AWS公式ドキュメント