Link and Motivation Developers' Blog

リンクアンドモチベーションの開発者ブログです

Amazon Aurora のローカルストレージについて調べてみた

こんにちは。リンクアンドモチベーション SRE グループの綿引と申します。

今回 Amazon Aurora の「ローカルストレージ」に関して調べる機会がありましたのでご紹介したいと思います。

 

 

背景

先日CloudWatchメトリクスを眺めていたのですが、RDSに「FreeLocalStorage」という項目があることに気づきました。

 

 

「Aurora のボリュームは自動拡張するのにストレージのメトリクスってあるんだ」と驚き、次に「このLocalStorageとは何だっけ?」ということが気になり、調べてみたということが背景になります。

 

Amazon Aurora とは


まず簡単に Aurora についておさらいですが、フルマネージド型のリレーショナルデータベースサービスで以下のような特徴があります。

(参考:「Amazon Aurora の特徴」)

-----------------

  • MySQL および PostgreSQL と完全な互換性あり
  • 標準的な MySQL の最大 5 倍のスループットと標準的な PostgreSQL の最大 3 倍のスループット
  • ストレージのニーズが増大するにつれて、データベースボリュームのサイズが自動的に拡張
  • 各データベースボリュームは3 つのAZにわたって 6 つレプリケートされており耐障害性が優れている

-----------------

上記の特徴に記載した通り「データベースボリュームのサイズが自動的に拡張」するため、Amazon RDS for MySQL のようにストレージを追加したり、ストレージの容量を監視をする必要もありません。

 

ではLocalStorageとは一体何なのでしょうか?

次で Aurora のストレージについて掘り下げてみようと思います。

 

Aurora ストレージの種類

Aurora には次の 2 種類のストレージがあります。

 

① 永続データ用のストレージ (クラスターボリューム)

  • 複数のアベイラビリティーゾーンにまたがる仮想データベースストレージボリューム
  • データの保存場所
  • 自動的に増加する

 

② Aurora インスタンスのローカルストレージ

  • エラーログ、一般ログ、スロークエリログ、監査ログ、および InnoDB 以外の一時テーブルの保存に使用
  • 自動拡張しない
  • より大きな DB インスタンスクラスに移動することによってのみ変更できる

自動拡張されるのは①のクラスターボリュームのみであり、②のローカルストレージは自動拡張されません。

 

 

このローカルストレージが枯渇すると、Aurora インスタンスがローカルストレージに情報を書き込めなくなりエラーとなってしまいます。

 

エラーになるとアプリケーションからのリクエストにも応答しなくなるため障害につながってしまいますので、監視は必須です。

では対応策にはどのようなものがあるか調べてみます。 

 

対応策

対応策に関しては以下の資料を参考に致しました。

 

参考 : Aurora for MySQL 互換のローカルストレージには何が保存されていますか? ローカルストレージの問題はどのようにトラブルシューティングすればよいですか?

https://aws.amazon.com/jp/premiumsupport/knowledge-center/aurora-mysql-local-storage/

 

対応策① インスタンスタイプを上位のものに変更する

ローカルストレージの容量を増やすにはインスタンスタイプを上位のものに変更することが必要です。

インスタンスタイプ毎のローカルストレージは以下の資料に記載があります。

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.Performance.html#AuroraMySQL.Managing.TempStorage

 

対応策② 一時テーブルの最適化 (InnoDB以外で有効)

InnoDB以外の一時テーブルの保存に使用されるため、InnoDB以外のストレージエンジンを使用している場合のみ有効です。

「max_heap_table_size」及び「tmp_table_size」の値を大きくすれば一時テーブルがメモリに出力されるケースが多くなるため効果が期待できます。

但し、以下の理由により設定の難易度は高めです。

  • InnoDB以外のストレージエンジンでなければならない
    • 上記パラメータの値を上げた所で、それを超える容量の一時テーブルが発生した場合ディスクに出力されてしまう
    • 上記パラメータの値を上げるとメモリ容量を今までより使用するため、メモリ側に影響がないかを監視する必要がある

 

これらをまとめるとコストは上がりますが、①のインスタンスタイプを上位のものに変更するのが良さそうです。

 

最後に


今回 Aurora のローカルストレージに関して調査を行いましたが、Aurora にもストレージ監視が必要ということが分かり非常に勉強になりました。
弊社でも Aurora は使用しており監視は元々行っていたのですが、もし Aurora をお使いで監視をされていないなどあれば、是非設定頂ければと思いますし、ローカルストレージが問題となった際は本記事を思い出していただけると幸いです。