QiitaのAWS初心者 Advent Calendar 2018 13日目

「Oracleじゃなきゃ、やだやだー、絶対やだー。PostgreSQLなんてものは、使ったこと無いし。むしろ、ポスグレなんてものは存在しなかった。」という、プロジェクト備えてRDS for Oracleを検証した結果を紹介します。
※なお、計測結果については、日々変わる可能性があるため、あくまで、目安としてください。なお、当結果に基づいて被害が発生しても（以下略）

検証環境

・DB Client：Win 2016 + Oracle Instant Client 12.2.0.1.0
・DB Server：RDS for Oracle 12.2.0.1 SE Two License Included

検証結果

・db.t2.smallインスタンスの作成：20分
・インスタンスの削除：5分
・インスタンスサイズの拡大 （db2.t2.small ⇒ db2.t2.medium)：5分
・インスタンスサイズの縮小 （db2.t2.medium ⇒ db2.t2.small)：5分
・インスタンスの停止：10分
・インスタンスの起動：5分
・ディスクサイズの拡張(40GB->60GB) ：5分*1
・ディスクサイズの縮小：NG
・EC2に導入したSQL*PlusからRDSへの接続：OK *2
・SQL*PlusからSQLを実行して日本語の表示：OK *3
・SQL*Plusを使ってPL*SQLの作成、実行：OK


※結果は、無負荷実施時における、およその時間を掲載。トランザクション流しながら実施した場合、クラッシュリカバリなどの時間がかかるため、さらに時間がかかると思われる。
*1 インスタンス再起動後、バックグラウンドでStorage Optimizationが走る。20分程度実行していた。
*2 Instant Client 18.3.0.0.0は、Oracle DBへの接続完了後、「SP2-0310: ファイル"LOGIN.SQL"をオープンできません。」と出力される不具合（？）あり。
*3 クライアント側文字コードは、NLS_LANG=Japanese_japan.JA16SJISTILDEを使用。Japanese_Japan.AL32UTF8を使用すると、Plusの日本語出力が文字化けする。

検証結果を踏まえた設計方針

SoR向け。

ディスクサイズ

・拡張は、簡単に可能。ただし、縮小は不可能。よって、物理設計でざっくり見積もった初年度のサイズをもとに、構築する。あとは、毎年、必要に応じて拡張していく。
・RDSにおいてもディスクフルにすると、DBを停止させてしまうので監視は必須。

メモリやCPU

インスタンスタイプを変えることにより、簡単に大きくしたり、小さくしたりすることが可能。システムテスト時に初年度程度のデータ突っ込んで、インスタインスサイズ変えて、決めれば良いかと。

作者の気持ち

Auroraは、一見、良さげに見えるものの、きちんと運用するためには、Oracle DBやPostgreSQLをマスターしたときのように、内部動作の仕組みをきちんと理解しないと怖いかな。と。