Amazon RDSをさわって考えた

やっと再開

新しい年になってもなかなかブログが捗らなかったが、今年から「ですます調」から「である調」に変えて再開することにした。

Amazon RDSを使ってみた

今までクラウドでデータベースを使うということに性能面でどうしても違和感を持っていたので、あまり積極的に関心を寄せなかったのだが、仕事の関係でPostgreSQL on RDSを使う機会があったので、個人的にも無料の範囲で試してみることにした。Amazon RDS

詳しい構築手順等は検索すればいろいろ見つかるので割愛するが、ゆっくり確認しながらでも３０分程度でDBインスタンスが構築できてしまうのは驚異的である。

インスタンス作成中

RDSとOSS

当然のことながらRDSとOSSは相性がいい。ライセンス費用が発生しないからだ。一方商用製品であるOracleとMSSQLはライセンス費用を考慮する必要がある。

例えばOracle Enterprise EditionをRDSで使用する場合は、自前のライセンスを用意する必要がある。

バックアップ

RDSではバックアップウィンドウを指定するだけで勝手にバックアップを取得してくれる。万一バックアップからリカバリする場合は、今までのインスタンスとは別にインスタンスを作成しそちらにリカバリするなど多少運用を考える必要があるが、フルマネージドRDBサービスとしての重要な機能のうちの１つであるであることに間違いはない。

監視

AWSで提供されるCloudwatchによって、パフォーマンスデータの取得及び可視化（グラフ化）が可能である。

監視項目（メトリック）の数も充実している。

冗長構成

無料お試し版では使えないが、マルチAZ配置とすれば異なるアベイラビリティ・ゾーン間で「プライマリ」と「スタンバイ」レプリカの構成を自動的に構成・管理することができる。

「プライマリ」側に何らかの異常があった場合でも「スタンバイ」へ自動的に切り替えることで運用を継続することができる。

Oracleの世界で言うところのData Guardのような仕様で冗長性を担保する。

Oracle RACのサポートについて

将来サポートされるかどうかは不明だが、現在RDSではOracle RACはサポートされていない。

これは技術的なハードルというよりもむしろRDSの冗長性に対する考え方によるものなのかもしれない。

Oracle RACのようなActive-Active構成を実現するためには、複数ノードから同時アクセス可能なASMのような仕組みを実装必要があるが、「１つのインスタンスは１つのノードでしか動かさない」という割り切りをすれば、そのような仕組みは不要でありより一般的なファイルシステムを使用することができる。

また、Oracle RACにおいてはノード間通信であるキャッシュフュージョンが発生すると性能が劣化することはよく知られている。

だからノードを増やすスケールアウトで性能を担保するというのは実は難しく、マシンスペックを上げて対応するスケールアップで性能を担保する方が設計上は確実であるという考えにRDSは至ったのかもしれない。

どこまでユーザに変更を許すか

RDSはSSHによりOS領域にログインすることはできない仕様となっている。従ってユーザができることは限られており、逆にユーザの不適切なオペレーションによる環境破壊等を防止する仕組みであると考えても良いのかもしれない。

パラメータもマシンスペック（インスタンスクラス）に応じてチューニングされたものが自動的に設定されるため、ユーザは基本的にパラメータを変更する必要はない。

どうしてもデフォルトパラメータから変更したい場合は、パラメータグループを作成して反映させるようになっている。

考えてみれば、パラメータはデフォルトのまま運用するべきではないと言っていたのは昔の話で、例えばOracleではパラメータの自動チューニングが進化しているので、パラメータを変更してチューニングするという機会はどんどん減っている。

Amazon RDSは使えるか

クラウド環境に大切なデータを預けるのは如何なものか的な考え方は未だに根強いが、十分なコストメリットとセキュリティの妥当性を実感できればRDSのような環境を業務に活用するという流れは加速されるだろう。

私が漠然と持っていた性能面に関する懸念も杞憂に終わるのではないかとさえ思えるほど、RDSの内容と選択の多様性は充実している。