注目の記事

AuroraかRDSどちらを選ぶべきか比較する話をDevelopers.IO 2019 in OSAKAでしました #cmdevio

Developers.IO 2019 in Osakaの登壇内容「AuroraかRDSどちらを選ぶべきか」をブログ向けにアレンジしたものです。違いを理解して適切に使い分けられるようになりましょう、という内容だったのですが、、
特集

かずえ

2019.10.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、大阪オフィスのかずえです。10/11に、弊社は Developers.IO 2019 in Osakaを開催いたしました。お越し下さった皆様、ありがとうございました！

私は今回、「AuroraかRDSどちらを選ぶべきか」というタイトルで登壇させていただきました。このエントリはその内容をブログ用にアレンジしたものになります。

ゴール

AuroraとRDSの違いを理解して、 適切に使い分けることができるようになる

もくじ

RDSとは

皆さんご存知かと思いますが、RDSはAmazon Relational Database Serviceの略です。マネージド型のリレーショナルデータベースサービスですね。マネージド型ですので、データベース運用における面倒な部分を色々AWS側が面倒見てくれるサービスになっています。

Auroraとは

対してAuroraはどのようなサービスなのか。こちらはクラウド向けにAWSが新たに開発したRDBのサービスとなります。MySQLと互換性のあるバージョンと、PostgreSQLと互換性のあるバージョンがあります。それぞれMySQLの最大5倍、PostgreSQLの最大3倍高速であるとAWSは謳っております。

そもそも、このタイトルはおかしい

セルフツッコミになってしまいますが、このブログエントリのタイトル「AuroraかRDSどちらを選ぶべきか」は少しおかしいです。AuroraはRDSの一部です。上記はRDSのコンソールのキャプチャですが、RDSでデータベースを作成する際にDBエンジン選択欄でAuroraがでてきます。

ですので、このタイトル正確には「AuroraかAuroraじゃないRDSどちらを選ぶべきか」とか「（RDSで）MySQL(PostgreSQL)かMySQL(PostgreSQL)互換のAuroraどちらを選ぶべきか」のほうが正しいです。ですが長いので今の省略したタイトルで行かせていただきました。ご了承ください。

RDSとAuroraの違い

では、RDSとAuroraにはどのようなちがいがあるのでしょうか。今日は2点、アーキテクチャについてとAurora独自の機能についてお話したいと思います。

アーキテクチャの違い

この点が今回一番抑えておいていただきたい点です。

RDS

まず、RDSのアーキテクチャについて見ていきましょう。

RDSの場合、そのアーキテクチャーはEC2にMySQLやPostgreSQLを自前でインストールする場合と大差ないとお考えいただいて構いません。左上の青い四角がDBインスタンス、つまりEC2インスタンスのようなコンピューティングリソースです。そこにストレージとしてEBSが繋がっています。EBSは2台存在しており、ミラーリングすることで耐久性を高めています。

もしレプリカを作成する場合、このインスタンス+EBS2台というセットがもう一つできます。レプリカはプライマリから連携されるログを使って自身のストレージのデータを更新し、プライマリと同期します。

Aurora

続いて、Auroraです。以下の図はAurora DB クラスターを表しています。Aurora DB クラスターとは、Auroraのデータベースを作成した際に作られるコンポーネント全体のことです。

大きく異なる点は、インスタンスとストレージが分離していることです。そしてそのストレージが、1AZあたり2箇所、3AZに渡りコピー、つまり2✖︎3=6箇所のストレージにコピーされる点です。この6つのストレージボリュームは互いに通信し、もしいずれかのストレージがデータ消失などした場合は修復し合う仕組みになっています。

インスタンスがストレージを使うことを考えると、6箇所に読み込み/書き込みにいくのは処理が遅くなるのでは？と思うかもしれません。しかし、これら6箇所へのアクセスは並列に行われますので、特に重くなることはありません。また、書き込みは4/6、読み込みは3/6のストレージで成功したらクライアントに処理成功と返すことになっています。すべてのストレージから結果を待つ必要はありません。何故こうなっているのかというと、仮に1,2個のストレージでネットワーク障害、ディスク破損などの問題が起こっていたとしても、そのことがクライアントからのリクエストに影響しないようにするためです。さらに前述のとおり、そのような問題が起きたストレージはのちほど自動修復されます。

Auroraにしかない機能

ここからはAuroraにしかない機能を紹介していきます。色々たくさんあってすべては紹介しきれないのでダイジェスト版です。

Protection Groups

先ほど、Auroraのストレージ層は3AZにまたがって6つのコピーを持つとお伝えしました。もう少し詳細にお伝えすると、ストレージは10GBごとに3AZにまたがって6つのコピーを持つ構成になっています。この10GBの塊のことをProtection Groupと言います。

例えばこの図の場合、左に10GB分のデータが3AZにまたがって6箇所にコピーされており、右半分ではまた別の10GBデータが3AZにまたがって6箇所にコピーされている、計20GBのデータの例になっています。

この構成の何が嬉しいのでしょうか？それは、各Protection Groupに対して並列に同時に処理を行なえる点です。

こちらの図は、RDSとAurora両方でリカバリ処理を実行する際を図示したものです。 左はRDSです。T0地点でクラッシュが発生したとすると、直近のスナップショットデータから、それ以降のログを逐次適用していくことでリカバリを行ないます。このログ適用量が多いと、リカバリ完了までに何時間もかかったりします。 対してAuroraの場合。直近のスナップショットから全Protection Group 並列でログ適用が行われます。一つ一つのProtection Groupは最大10GBなので、処理が長期化することはありません。 上記はリカバリ時の例ですが、バックアップ取得やリストアでも同様のメリットを出すことができます。

BackTrack

前述のバックアップやリカバリなどとは別の方法で、「データを巻き戻す」ことができる機能です。上記図の場合ですと、T4時点からT3時点に巻き戻したり、T2からT1に巻き戻したりしています。

ユースケースとしては、まず第一にオペミス時が挙げられます。テーブルをDROPしちゃったとか、重要なデータをDELETEしちゃったとか。こういった際にBackTrackを使うと、瞬時にオペミス前の状態に回復することができます。 またBackTrackは巻き戻すだけでなく、戻したデータをすすめることもできます。例えば3時間前の状態に戻した後に2時間進めて、最初の状態から見れば1時間前の状態にする、などといったことができます。これを使えば、ちょっとずつデータを進めていって、データの変更されたタイミングがいつかを突き止める、なんていうこともできます。

クラスタキャッシュ管理による高速リカバリ

この図は横軸が時系列、縦軸がTransactions Per Second(TPS)、DBのパフォーマンスを表す指標を表しています。真ん中の赤い縦線の位置、このタイミングでフェールオーバーが発生したとお考えください。

Auroraはプライマリがクラッシュした場合、リードレプリカをプライマリに自動昇格させることができます。この例の場合、フェールオーバーには32秒かかりました。これは非常に高速です。ですがその後、TPSがフェールオーバー前と同じ水準に戻るまでに340秒かかっています。これはなぜでしょうか。

これは、新しくプライマリになったインスタンスが、これまでプライマリだったインスタンスと同じキャッシュを持っていないからです。キャッシュがない分、ディスクIOが頻発しTPSが下がっています。

そこでクラスタキャッシュ管理機能です。この機能は、プライマリインスタンスが持っているキャッシュを、特定のレプリカと共有することができる機能です。プライマリがクラッシュしてフェールオーバーが発生し、レプリカがプライマリに昇格した際、このプライマリインスタンスはこれまでプライマリだったインスタンス（クラッシュしたインスタンス）が持っていたキャッシュをそのまま使うことができるので、すぐに元の水準のパフォーマンスに回復することが可能です。下記の図の青線がクラスタキャッシュ管理を使った場合の例です。フェールオーバー時間、これは変わりません。がその後、すぐに元の水準のTPSに戻っていることがわかるかと思います。これがクラスタキャッシュ管理機能の効力です。

並列クエリ

続いて並列クエリ（Parallel Query）のご紹介です。

この図はまたもやAurora DBクラスター を表しています。Database Nodeと書かれている上がインスタンス層、下がストレージ層です。

クエリ実行やトランザクション処理などは、インスタンス層（Database Node )の仕事です。ですが、実はストレージ層にもCPUが存在しています。しかも数千個と大量に存在しています。これらは普段はディスクの読み書きの用途に使われているのですが、インスタンス層がやっているクエリ実行などの処理をそのストレージ層のリソースにオフロードして、ストレージ側で処理してしまおうというのが並列クエリです。このことによってクエリ実行処理が爆速化します。

NETFLIX社の事例があったのでご紹介します。NETFLIXはこの並列クエリ機能を利用することによって、120倍高速になったクエリがあったそうです。また、検証した22クエリのうち8クエリにおいて10倍以上高速化させることができたそうです。この並列クエリはすべてのクエリを高速化するものではなく、得意不得意があるそうなのでこの例のようにすべてのクエリが高速化するわけでもないのですが、それにしてもすごい効果ですよね。この結果を受けてNETFLIXはAuroraのインスタンスタイプをr3.8xlargeからr3.2xlargeにスペックダウンすることができたそうです。

Global Database

続いてGlobal Databaseです。こちら一言で申しますと「ストレージレイヤでのリージョン間レプリケーション」です。

実はこのGlobal Databaseが登場する前から、リージョン間レプリケーションの機能は存在していました。Cross-Region Read Replicaという機能です。

こちらは、インスタンス間でログファイルを連携しあい、受け取ったレプリカインスタンスが自身のストレージを更新するというものでした。

対して、Global Databaseです。先ほどもお伝えした通りストレージ層（だけ）でレプリケーションが可能になります。

このことにより、リージョン間レプリケーションにも関わらず通常1秒以内のレプリカ遅延を実現できます。また、プライマリインスタンスがあるリージョンが完全に停止したとして、別のリージョンにプライマリインスタンスを置いて復旧再稼働するのに、通常1分以内しかかかりません。さらに嬉しいことに、このレプリケーションはストレージだけで行われるものですので、レプリケーション先にインスタンスを設置しなくてもレプリケーションが可能です。これにより低価格でDR対策構成が実現できます。

Aurora Serverless

続いてAurora Serverlessのご紹介です。以下はまたまたAurora DB クラスターの図です。青い「SCALABLE DB CAPACITY」と書かれている部分がインスタンス層、その下のオレンジの「DB STRAGE」がストレージ層ですね。

Aurora Serverlessが何なのかというと、このインスタンス層が需要に合わせて自動スケールする機能です。全く使用していない際にはインスタンスはシャットダウンされますので、インスタンス部分の課金をゼロにすることができます。（ストレージの課金は依然発生します。）

ユースケースとしては、平日日中しか稼働しない開発や検証環境用のデータベースとしてや、まったく需要が予測できないようなワークロード向けなどが考えられます。

Aurora Serverless Data API

また、Aurora Serverlessはその名前から勘違いされやすいですが、Lambdaなどサーバレスなサービスと組み合わせることに最適化されたものではありません。通常のAuroraと異なる点はインスタンス部分が自動スケールする点だけで、普通にVPC内にリソースを作りますし、接続ポートもMySQLやPostgreSQLのポートです。なのですが、このAurora Serverless Data APIという機能がリリースされました。これはAurora DBクラスターに接続できるHTTPSエンドポイントが作られ、REST形式もしくは各言語のSDKからパブリックアクセスできるようになるというものです。これによって、VPCの外側、例えばIoT機器からのアクセスが容易になりますし、LambdaでRDSに接続する際、これまではVPC Lambdaを使うしかなく、VPC Lambdaは色々な辛い点があるのですが、その辛さを解消することができます。

※VPC Lambdaの辛い点も改善されてきております。この点の詳細は以下の弊社岩田のブログが大変参考になると思いますので、ご興味のある方はぜひご一読ください。

ここまで、Auroraにしかない機能として以下機能をざっとご紹介しました。

  • バックアップ/リストア/リカバリーが早い(Protection Groups)
  • BackTrack
  • クラスタキャッシュ管理による高速リカバリ
  • 並列クエリ
  • Global Database
  • Aurora Serverless

注意点としてはDBエンジン（MySQL互換かPostgreSQL互換か）やバージョンによって対応状況がまちまちである点です。ですのでお使いになりたいDBエンジンのバージョンで、利用したい機能が利用できるかどうかは必ず確認してください。

RDSかAuroraどちらを選ぶべきか

さて本題に参りましょう。

基本的にはAuroraを推します。これまでご紹介した通り、パフォーマンス、可用性、耐久性など各性能が高い上に便利な機能も色々と揃っているからです。ですが、Auroraが使えないケースや、Aurora使えるケースでもあえてRDSを使うべきケースもありますので、それぞれご紹介したいと思います。

その前に

なのですが、その前に本当にリレーショナルデータベースが最適なのか？という点は一度立ち止まって考えてみるべきかと思います。

RDBは確かに色々融通がきいて汎用性が高いです。ですがAWSはRDS/Aurora以外にも様々なデータベースサービスを提供しています。ワークロードによってはRDBよりこれら他のサービスの方が適している場合がありますので、これらも含めて検討するようにしましょう。

どのようなサービスがあって、それぞれどういう際に使うべきなのかざっくり理解するには、今年のAWS SUMMIT でAWSのSAの方がお話しされていた以下「【初級】AWS におけるデータベースの選択指針」がオススメです。

※スライド資料はこちら

Auroraを使えないケース

さて話を戻しましょう。まずAuroraを使えないケースについて見ていきます。

以下のようなケースが主に考えられます。

  • DBエンジンが異なる
  • バージョンが異なる
  • ストレージエンジンが異なる（MySQLの場合）
  • インスタンスタイプが異なる

DBエンジンが異なる

まずは、ここまでの話で何度かでてきましたが、DBエンジンの話です。

RDSで現在使えるDBエンジンは以下5つです。

  • MySQL
  • PostgreSQL
  • MariaDB
  • Oracle
  • SQL Server

ですが、Auroraが互換性を持つのはMySQLとPostgreSQLのみです。ですのでその他の3製品をお使いになるのであれば、RDSを選択するしかありません。

バージョンが異なる

また、仮にMySQLやPostgreSQLを使う場合でも、使えるメジャーバージョンがRDSとAuroraでは異なります。以下は2019/10/11現在RDSで使えるバージョンです。

  • MySQL
    • 5.5
    • 5.6
    • 5.7
    • 8.0
  • PostgreSQL
    • 9.3
    • 9.4
    • 9.5
    • 9.6
    • 10
    • 11

一方Auroraはどうでしょうか。これだけ減ります。

  • MySQL
    • 5.6
    • 5.7
  • PostgreSQL
    • 9.6
    • 10

というわけで、お使いになりたいバージョン次第ではRDS一択になる場合があります。

ストレージエンジンが異なる（MySQLの場合）

次に、これはMySQLの場合のみの話ですが、ストレージエンジンについてです。

現在AuroraがサポートしているのはInnoDBストレージエンジンのみです。ですのでMyISAMなど他のストレージエンジンをお使いになりたい場合はRDSを使う必要があります。MyISAM、トランザクション機能はありませんがInnoDBより早かったりします。

なのですが、RDSのドキュメントを見たところ、RDSでも推奨はInnoDBだ、という感じの記述がありました。またサポートしていないストレージエンジンもあるようです。InnoDB以外をお使いになる予定の方はドキュメントをしっかりご確認ください。

インスタンスタイプが異なる

これが決定打となってRDSを選ばれることはないと思いますが、一応ご紹介します。使えるインスタンスタイプもRDSとAuroraでは異なります。まずRDSの場合です。これはRDSのMYSQL 5.6 で使えるインスタンスタイプの一覧です。

Aurora MySQL5.6互換になるとこのように変化します。

m系がすべて選択できなくなっています。またt系のバリエーションも非常に減ってますね。

(Auroraも使えるけど)RDSを使うべきケース

続いて、Aurora/RDSどちらも使えるけど、あえてRDSを使うべきケースについて見ていきましょう。

DBエンジンの新機能をいち早く使いたい

以下は、RDSとAuroraで特定のDBエンジンバージョンにいつ対応したか、の表です。

例1: PostgreSQL 10対応
RDS 2018/02/27 (10.1),2018/07/25 (10.4)
Aurora 2018/09/25 (10.4 互換)
例2: MySQL 5.7対応
RDS 2016/02/22
Aurora 2018/02/06

どちらもRDSの方が先に対応していますよね。これからもRDSの方が先に対応する流れは変わらないと思います。これはなぜかというと、AuroraはあくまでMySQL「互換」、PostgreSQL「互換」だからです。新バージョンのMySQLやPostgreSQLがリリースされても、Auroraはそれをそのまま使えず、AWSの中のエンジニアがAuroraのアーキテクチャにフィットするように改修を加える必要がある分、対応に時間がかかるのです。

というわけでDBエンジンの新バージョンに搭載される新機能をいち早くお使いになりたいのであれば、RDSの方がよいでしょう。というか、EC2にMySQLやPostgreSQLを自前インストールしてお使いになる方が良いかもしれませんね。

適用されないパラメーターが重要

続いてのケースです。 Auroraでは、素のMySQLやPostgreSQLとアーキテクチャが異なるため、一部のパラメータが無効になっております。もしこの無効になっているパラメーターがどうしても重要なケースに遭遇した場合は、RDSをお使いになる方が良いです。

例を挙げます。MySQLのinnodb_change_bufferingというパラメーターがAuroraでは無効になっています。

このパラメーターはどういうものかというと、データ更新時のディスクへの書き込みを遅らせる機能です。パフォーマンスのボトルネックになりやすいのはディスクへの書き込みです。そこでこの機能は、本来データ更新が発生した際に即時ディスクへ書き込みに行くところを遅らせて、そのタイミングではメモリ上のキャッシュ更新だけ行なうことで書き込み処理の高速化を計ります。書き込みは後ほど実施されます。ライトスルーな処理をライトバックにする機能ですね。

これがAuroraでは無効になっているため、ランダムなディスクアクセスが大量に発生するような処理、たとえばセカンダリインデックスを大量に更新するような処理が走る場合、遅くなる可能性があります。 とはいえAuroraはベースパフォーマンスが良いので、この点が気になる場合は、きちんと検証されることをお勧めいたします。

安くしたい

3つ目のRDSを選ぶべきケース、それは安くしたいケースです。Auroraの方が割高になる理由を2点ご紹介します。

課金形態の違い

RDSの主な課金ポイントはインスタンスとストレージの稼働時間による従量課金、この2点です。ですがAuroraは、RDSと同じくインスタンスとストレージの稼働時間による従量課金に加えて、I/Oリクエスト数による従量課金も発生します。東京リージョンの場合、100万件のリクエストあたり0.24ドルです。

DBインスタンス従量課金

2点目のAuroraの方が割高になる理由は、DBインスタンス従量課金の単位時間あたりの料金が高いからです。東京リージョンでMySQL、シングルAZ（シングルインスタンス）、r5インスタンスタイプでRDSとAuroraのインスタンス料金を比べてみました。

RDS(USD/h) Aurora(USD/h) 価格差
r5.large 0.285 0.35 122.81%
r5.xlarge 0.57 0.7 122.81%
r5.2xlarge 1.14 1.4 122.81%
r5.4xlarge 2.28 2.8 122.81%
r5.12xlarge 6.84 8.4 122.81% |

Auroraの方が2割ちょっと高くなっています。これはr5インスタンスタイプの結果ですが、t系インスタンスでもほぼ同じくらいになっています。

必ずRDSの方が安くなる、とは言えない

上記2点の理由でAuroraが割高、つまりRDSの方が安くなることが多いです。が、必ず安くなるとは言えないです。Auroraの方が安くなる部分も色々と存在していますので、その点も見ていきましょう。

Multi-AZが不要なケース

Auroraの場合、Multi-AZ構成をとらなくても良いかもしれません。 もう一度Auroraのアーキテクチャの図を載せます。Auroraは、DBインスタンスが一台つまりSingle-AZであっても、ストレージ部分は3AZにまたがって6つのコピーを持つようになっています。つまりこの状態でも耐久性は十分にあるわけです。もっというとバックアップはS3上に保存されます。S3の耐久性は99.999999999％（イレブンナイン）です。

また、シングルインスタンス構成で、そのインスタンスがクラッシュした際のことを考えます。この場合、Auroraはインスタンスの自動復旧を行ないます。この復旧は通常10分未満で完了します。この10分のダウンタイムを許容できるのであれば、Mulit-AZにせずとも良いのではないでしょうか。RDSのMulti-AZに比べれば、AuroraのSingle-AZはかなり割安です。

この点についての詳細は、以下ブログエントリにまとまってますのでご確認ください。

StandByレプリカ不要

「クラスタキャッシュ管理による高速リカバリ」の項で触れていますが、Auroraはプライマリインスタンスがクラッシュした際、リードレプリカをプライマリインスタンスに自動昇格させることができます。 ところがRDSではこれができません。RDSではMulti-AZ構成にした場合スタンバイインスタンスが作成されますが、このインスタンスはスタンバイインスタンスとしての役割だけでリードレプリカとして使うことはできません。

というわけで、Multi-AZかつリードレプリカを設置する構成にする場合、RDSでは最低インスタンス3台（プライマリ、スタンバイ、リードレプリカ）から始める必要がありますが、Auroraでは2台（プライマリ、リードレプリカ（スタンバイの役割兼務））から始めることができます。

レプリカ分のストレージ料金かからない

もう一度Auroraのアーキテクチャの図です。AuroraのストレージはDBインスタンスに紐づくのではなくAuroraDBクラスター全体に紐付きます。どういうことかというと、例えリードレプリカインスタンスをドカドカ（最大15台）増やしたとしても、増えるのはDBインスタンスだけでストレージは増えません。

一方RDSは各インスタンスごとに自分のストレージを持つ構成ですので、リードレプリカを作るたびにインスタンスの従量課金に加えストレージの従量課金も発生します。

レプリカの台数減らすorスペック下げられるかも

RDSのアーキテクチャの再掲です。 リードレプリカで行われる処理について考えてみましょう。名前の通り、プライマリインスタンスが本来やる読み込み処理を、リードレプリカが代わりに処理することでプライマリの負荷を下げます。ということで読み込み処理は発生しますよね。加えてリードレプリカ、実は書き込み処理も多量に発生します。なぜかというと、リードレプリカは独自のストレージを持っており、そこにあるデータをプライマリインスタンスと同期させるために、プライマリで実施された書き込み処理はすべてレプリカ側でも実施する必要があるからです。というわけで、RDSの場合、リードレプリカは読み込み処理、書き込み処理どちらも行なっているわけです。

一方Auroraはどうでしょうか。先ほどから何度もご説明している通り、Auroraはインスタンス間でストレージを共有しています。というわけで、リードレプリカは書き込み処理をする必要がありません。だって見に行くデータは既にプライマリインスタンスが更新してますからね。ですのでAuroraのリードレプリカは読み込み処理のみに集中することができます。RDSで書き込みに使っていた分のリソースを浮かすことができるので、レプリカインスタンスの台数を減らしたりスペックを下げることで料金を下げることができるかもしれません。

さらに付け加えると、AuroraはリードレプリカをAuto Scalingすることができます。ですので需要に応じた分だけのレプリカを建て、無駄な課金を抑えることができます。

トータルコストで考える

ちょっと屁理屈に聞こえるかもしれませんが…たしかにAuroraの方がAWS利用費は高くなるかもしれませんが、その分人的コストを抑えれますよ？という話です。 Auroraには作業負荷を下げられる部分がたくさんあります。そもそもパフォーマンスが良いのでクエリチューニングをガリガリしなくても求められる速度が出たり（出やすかったり）、レプリカをAutoScalingできるので何台建てるか検討する必要がなかったり、オペミスしてもBackTrackですぐに復旧できたりなどなど。 これらの機能を使って作業量を減らし、エンジニアをもっと重要なタスクに取り組めるようできれば、多少のAWS利用費のアップもお安いもの、と捉えることはできないでしょうか。

まとめ

「AuroraとRDSの違いを理解して、適切に使い分けることができるようになる」というゴールを目指して、

  • アーキテクチャの違い
  • Auroraにしかない機能
  • Auroraがつかえないケース
  • (Auroraも使えるけど)RDSを使うべきケース

についてお伝えしてきました。かなり長くなりましたが、「適切に使い分けることができるようになる」についての私の結論は以下です。

Auroraすごい。みんなもまずAurora試そうぜ！！

AWSが本気を出して作ったクラウド時代のRDBであるAurora、みなさんのワークロードにもハマる部分が必ずあるはずです。まずこの恩恵を受けることから考え始められると良いと思います。

そして、このエントリを通じてAuroraのすごさを感じていただけましたら幸いでございます。 もしAuroraのすごさを感じていただけなかったのなら、それはAuroraがすごくないのではなく、私のプレゼンが悪かっただけです。 ちゃんとすごさを伝えられるようになりたいので、ぜひどこが悪かったかフィードバックをください笑 以上です。ここまでお読みいただき、ありがとうございました！

登壇資料

参考資料

AWS

関連記事

安定したAWSアカウントのデータベース利用費が2024年3月から増えていたらRDS延長サポートを要チェック!

quiver

2024.03.21

【負荷試験】AWS上でISUCON13の過去問環境を構築して簡単なDBチューニングをやってみた

入井啓太

2024.03.17

Introduction to Joins in MySQL

Charu Srivastava

2024.03.13

Aurora MySQLのスナップショットを使用してTiDB Serverlessにデータを移行してみた

えがわ

2024.03.07