出典について
この記事は、CODESHIP内のBarry Jones氏による「Heroku PostgreSQL vs. Amazon RDS for PostgreSQL」(2015/06/17)を翻訳したものです。
PostgreSQLは十分な機能を備え、Web開発を行うときのリレーショナルデータベースの選択肢となってきた。 開発チームは自前でホスティングするか、サービスプロバイダーのデータベースを利用するかの選択に迫られる。
PostgreSQLの世界での2大プレーヤーといえば、Heroku PostgreSQLとAmazon RDS for PostgreSQLである。 今日は、この両方のプラットフォームを比較することにする。
Herokuはアプリケーション開発においてMySQLに変えてPostgreSQLを押出した最初の大きなプロバイダである。 Heroku PostgreSQLプラットフォームのたち上げは、2007年にさかのぼる。 Amazon Web ServecesはRDS for PostgreSQLサービスを2013年11月のAWS re:Invent conferenceで発表し、参加していたプログラマからものすごい大喝采を受けた。
料金比較
機能に深入りする前に、表に現れる価格について確認しよう。 もちろん、どちらのサービスも得意領域を持っており、直接的なコストを上回る生産性と維持管理性に対する異なる価値を提示している。 しかしながら、後にあげる必要な機能と天秤にかけられるよう基本的な価格を理解する価値は大きいだろう。
HerokuのPostgreSQLの料金は最も単純である。従量の価格と、それで何が利用できるかは非常に明確で、単純な月当たりの従量課金となっている。 この中にはデータベース、ストレージ、データ転送、I/O、バックアップ、SLA、そして価格表に記載されたその他の機能がある。
RDSのPostgreSQLでは、料金はそれぞれのリソースの利用に応じて小さな単位にブレークダウンされている。 価格を見積もる為に必要な要素がより多くあり、それゆえHerokuのPostgreSQLと正確に比べるのは難しい。
インスタンスの種類に応じて時間毎の料金があり、マルチAZ構成のインスタンスだと高くなり、1年、もしくは3年のコストを前払いしインスタンスを予約すると安くなる。 ストレージの費用と、ストレージクラス(どちらにもシングル構成とマルチAZ構成がある)、プロビジョンドIOPSレート、バックアップストレージ、データ転送、、、様々な特殊なケースを考える必要がある。また、サインアップすれば最も安価なプランを1年間無料で利用できる点も忘れずに考慮して欲しい。
あるRDSのプランと、Heroku Premium 4プランの比較をここに記載する。
Heroku Premium 4
- $1,200/月
- 15 GB RAM
- 512 GB storage
- 500 コネクション
- 高可用構成
- 最大 15分のダウンタイム/月
- 1週間のロールバック
- ポイントインタイムリカバリ
- 暗号化(移動のないデータ)
- 継続的保護 (Write-Ahead-Logの別サイトへの保存)
RDS for PostgreSQL
- $1,156/月 でのオンデマンド利用または $756/月 での1年予約
- db.m3.xlarge マルチAZ構成 at $0.780/時間 ($580)
- 4 vCPU, 15GB RAM
- 暗号化(移動のないデータ)
- 512 GB プロビジョンドストレージ (SSD) at $0.250/GB ($128)
- 2000プロビジョンドIOPS at $0.20/IOPS ($400)
- 1週間のロールバックを行う為に、必要な無料分を超えたバックアップストレージ、512 GB at $0.095/GB ($48)
- データ転送は多くのケースでは$0と予想される
- 22分のダウンタイム/月 (AWS RDS SLA 99.95% アップタイムに基づき計算)
ここで、比較において重要なことを記載しておこう。
- Herokuは、プランに対するCPU数が明記していない
- Herokuの高可用構成は、AWS RDSのマルチAZと同等である。どちらを利用しても、リードレプリカは、故障が発生した時に自動でフェイルオーバーする目的で、地理的に異なる場所に維持管理される。
- Herokuでは、ストレージは完全に確保されており、IOPSに対して課金が発生しない。つまり、IOPSに対してどのような制限があるか分からないが、非常に高性能なデータベースがある。AWSの512GBストレージで利用できる最小限のIOPSを確保したところ、2000IOPSであった。これは、5000IOPSまで増やすことが可能で、この場合$600/月の費用が加算される。
- AWS RDSのバックアップはプロビジョンドストレージが実際にどの程度利用されているかによっては、費用がかからない可能性がある。バックアップストレージは、プロビジョンドストレージの容量までは無料であり、バックアップは一般的に小さく、徐々に増加するものであり、インデクスで利用される領域は重大なインパクトを及ぼすものではないからである。この見積りは、1週間のロールバックに必要な7日間のストレージ基づいて実施した。
- AWS RDSのストレージは、臨機応変にスケールアップ可能で、特定のRAMとストレージにしたいというニーズを満たし、その結果価格のパターンが大きく異なる。この比較は同等のパターンを導くことを目的としたものである。
- AWSはAZからデータを外に転送するときのみに課金する(マルチAZ間の転送は含まない)ため、転送料は大多数のケースでかからない
ちんぷんかんぷんである。
セットアップの簡単さ
HerokuのPostgreSQLの設定はとても簡単である。
PostgreSQLプロジェクトを作ればいつでも、無料のdevプランがすでに接続待ちの状態で作成される。データベースをアップグレードする時は、指定されたユーザー名、パスワード、ホスト名、またシステムでランダムに生成されたデータベース識別子をもつ新しいコネクションが与えられる。データベースの接続はセキュアである必要があるが、インターネットのどこへでもアクセスできる必要があり、あなたのPCに直接接続できる、ということも含め出来る必要がある。デプロイするリージョンも、選ぶことが出来て、US Eastリージョンか、Europeanリージョンとなる。
RDSのPostgreSQLは、設定がもう少し複雑である。価格の欄に並んだ様々なオプションを選択する必要があり、これにはインスタンスタイプ、マルチAZ構成であるかどうか、暗号化を有効化するかどうか、ストレージタイプ、どの程度容量を確保するか、保証すべきIOPS(もしあれば)、バックアップ保持期限、自動マイナーバージョンアップグレードを有効化するかどうか、バックアップとメンテナンスウィンドウの選択、データベース識別子、名称、ポート、マスターユーザー名およびパスワード、どのAZにインスタンスを作るか、VPCグループとサブネットグループの選択、そしてデータベースの設定がある。
明らかに、RDSはより詳細な項目についてもコントロールする選択肢を提供している。これはあなたの視点によっては、良い場合も悪い場合もあるだろう。 データベースの設定は、それぞれのインスタンスタイプ、データベースバージョンに対して、デフォルト値のセットを持っている。 これらのデフォルト値を自分のカスタム設定に修正し、自分のパラメーターグループとして保存し、これを以後のインスタンス作成のときに選択し、インスタンスに割当てることが出来る。 この初期設定は若干複雑であり、これはVPC、サブネットグループ、パブリックにアクセスできるかどうかなどの様々な要素が関連するためである。 しかしながら、ひとたびアカウントにこれが定義されれば、全てのことが簡単なクリック操作だけでよいという状態に大きく近づくのである。
ホストのロケーション、リージョンに関する制約
HerokuはAWS US Eastリージョン(us-east-1)とEuropeリージョン(eu-west-1)で運用をしている。 従ってあなたのデータベースはこれらのリージョンに制限されることを意味する。AZは内部で管理される。
HerokuのPostgreSQLをこれらの2つ以外のAWSリージョンから選んだ場合、データベースのリクエストや、転送レートに対するより大きなレイテンシーが発生することを覚悟する必要がある。 同じように、HerokuアプリケーションでAWS RDSのPostgreSQLを利用したい場合は、適切なリージョンにセットアップされることを確認しさえすればよい。
セキュリティーおよびアクセスに関する考慮事項
HerokuのPostgreSQLでは、SSLで接続する為のランダム生成されたユーザー名およびパスワード、データベース名が与えられるだろう。 ネットワークは(Amazonと同様に)ビルトインの保護機能をもっており、データベースにブルートフォースアクセスを行う可能性のある攻撃者から保護する。これはかなり安全である。 欠点としては、データベースに接続したいと思っている人は誰でも、接続情報を持っていれば世界中のどこからでも接続できることだ。 これはプロジェクトから離れたプログラマに対するヒューマンリソースレベルのリスクと同等であるが、とはいえ留意すべき重要な事項である。 プログラマがチームを離れた時にデータベースのクレデンシャルを交換するのが一般的にこの心配事を緩和する手段だろう。
一方でAWS RDSのPostgreSQLはもっと理解しやすいセキュリティーポリシーを持っている。VPCとプライベートサブネットグループを定義し設定すれば、データベースのアクセスを必要な人やサーバーに限定することができる。複数のユーザーやアプリケーションが異なる権限レベルで、データベースへのアクセスを行い、一方でログ追跡を行うように、より簡単に管理できるよう、多様な権限レベルを持つデータベースユーザーを好きなだけ作成できる。VPCのおかげで、仮に誰かが接続情報を知っていたとしても、VPC内に入らなければデータベースにアクセスできない。
より強固な(一方でより複雑なものとなるが)セキュリティーとしては、RDSは断然良い。 組織、チーム、アプリケーションの開発状態によって、セキュリティーの被害への考えは意味をなさないだろうし、実際に管理したいレベルを超えてより大きな頭痛の種となりうる。 HerokuのPostgreSQLで設定されているものと全く同じアクセスに関するルールを設定することもできる。
バックアップ/リストア/アップグレード
バックアップとリストアに関しては、両方のプラットフォームで良く似たオプションを提供している。 スケジュールされたバックアップ、ポイントインタイムリカバリ、新規インスタンスへのリストア、スナップショットの作成が両者で利用できる。
アップグレードは少し複雑である。両プラットフォームで、メジャーバージョンアップグレードは、ダウンタウンタイムの発生が不可避である。
Herokuでは3つのオプションがあり、全てに手動で行わなければならないステップがいくつかある。 データのコピー、アップグレードしたフォロワー(訳注: RDSにおけるリードレプリカ)の昇格、または、より大きなデータベースの pg:upgrade コマンドによるインプレイスアップグレードである。 pg:upgrade がRDSでのアップグレードのプロセスと一番近い。 RDSでは、インスタンスの変更オプションおよび変更後のバージョンを選択する。 事前および、事後のスナップショットをインプレイスアップグレードの前後で作成し、その一方で全く同じコネクションが維持される。 RDSではアップグレードをスケジュールしておいて、メンテナンスウィンドウ内で自動的にアップグレードさせることができる。 HerokuのPostgreSQLは自動的にマイナーアップグレードとセキュリティーパッチを適用してくれるが、一方でRDSはメンテナンスウィンドウ内で自動的にアップデートさせるかどうかを選択することができる。両者ともかなり単純なプロセスであるが、RDSのプロセスの方がこの場合は手離れの良いものである。
利用できる機能/拡張モジュール
これを執筆中の段階では、AWS RDSのPostgreSQLは9.3.1-9.3.6と9.4.1のバージョンが利用できる。HerokuのPostgreSQLは一方で9.1, 9.2, 9.3, 9.4である。 マイナーバージョンのアップグレードはHerokuでは自動で実施されるため、ポイントリリース(手動でのマイナーバージョンのアップグレード)は不要となる。 HerokuのPostgreSQLの方が歴史が長いため、既存のユーザー向けにより古いバージョンが利用できる。 RDSは9.3からサービスが立ち上がり、これより古いバージョンについてはサポートする意思があるようには全くみえない。 PostgreSQL備え付けの全ての機能に加え、絶えず増え続けている拡張モジュールがある。
両方のプラットフォームで共通で利用できる拡張モジュール
- hstore
- citext
- ltree
- isn
- cube
- dict_int
- unaccent
- PostGIS
- dblink
- earthdistance
- fuzzystrmatch
- intarray
- pg_stat_statements
- pgcrypto
- pg_trgm
- tablefunc
- uuid-ossp
- pgrowlocks
- btree_gist
- PL/pgSQL
- PL/Tcl
- PL/Perl
- PL/V8
HerokuのPostgreSQLでのみ利用できるもの
- pgstattuple
AWS RDSのPostgreSQLでのみ利用できるもの
- postgres_fdw
- chkpass
- intagg
- tsearch2
- sslinfo
ここにHerokuのPostgreSQLおよびAWS RDSのPostgreSQLの完全なリストを記載する。
スケールに対する選択肢
「スケーリング」はデータベースでは用心が必要なキーワードであり、アプリケーションのニーズによって異なる意味を持つ。 読込み/書込みに対するスケールは、少量で大きな負荷(解析)というより、大量で小さな負荷(Webトラフィック)に基づいている。
Webにおける最も一般的なスケーリングは読取りのトラフィックに対するものである。 HerokuもRDSもリードレプリカを作る機能の必要性を示している。 RDSでは (read replicas)リードレプリカ と呼ばれ、Herokuでは (followers)フォロワー と呼ばれるが、本質的に両者は同じものである。 データベースの複製であり、複数のサーバーで読取り負荷を分散できるように書込みによって発生するWALによってアップデートをうけとる。 これは一般的に 水平方向のスケール とよばれる。リードレプリカはいずれのプラットフォームでも簡単なクリック操作で作成できる。
垂直方向のスケール は利用しているデータベースのハードウェアそのものの性能を増やしたり減らしたりするものである。 AWSとHerokuはこのシナリオをそれぞれ異なった方法で実現している。 Herokuでは新しい所望のデータベースクラスのフォロワーを作成し、フォロワーがマスターに追いついたらプライマリデータベースに昇格し、元のインスタンスを後で削除することをユーザーに勧めている。新しいデータベースを使う為にはアプリケーションの接続情報をアップデートする必要があるだろう。
RDSのデータベースがマルチAZ構成であった場合、フェイルオーバーデータベースが最初にアップグレードされる。 利用可能状態となればコネクションが自動的にフェイルオーバーし、プライマリがそれからアップグレードされ、その後プライマリにスイッチバックされる。 マルチAZ構成ではない場合は、アップグレードをインプレイスで実施することができるが、ダウンタイムがデータベースのサイズに依存することとなる。 その他の選択肢として、Herokuが推奨するのと同じように、所望の状態のリードレプリカを新規に作成し、利用可能となったらプライマリに昇格させる、という選択肢もある。
通常の水平、垂直方向へのスケールは、分散した書込みトラフィックをスケーリングさせる為には、どちらの選択肢もとても適するわけではない。 恐らくPostgre-XCの設定をなんとかするか、重い書込みトラフィックを分離し、ユースケースに適した特定のデータソースに分割するようアプリケーションを再構成する必要があるだろう。
モニタリング
AWS RDSのPostgreSQLはCloudwatchから全ての標準のAWSモニタリングオプションを利用できる。
Cloudwatchは外部メトリックを提供していて、これによって細かい粒度で履歴を追い、EメールかSNS通知(基本的にはウェブフック)でアラートを設定できる。 これはPagerDubyのようなツールと一緒に使う為にはとても良い。
HerokuのPostgreSQLのモニタリングはログとCLIツールによっている。pgextras CLIツールは、肥大化、ブロッキングクエリ、キャッシュとインデックスのヒット率、未使用インデックスの同定、特定のクエリをキルする機能を含む、そのデータベースで何が起こっているかの現在の情報を示している。
これらのツールはCloudwatchから取得する統計を時とともに追跡はできないが、非常に価値のある情報をサーバーに入らずとも提供する。 Github上の pg-extras のより多くの例をみることができる。 これらの情報は非常に価値があり、アプリケーションとデータベースをチューニングし、監視する必要のある問題をまず最初に気がつくことで問題を回避するのに役立つ。
その他の履歴データはログ上で利用可能であり、他方でHerokuはLibrato(自動設定で利用可能なHeroku PluginのあるPostgreSQLデータベースで動作する)を使ってみることを推奨している。それに加え、無料のNew Relicプランでは、アプリケーションとデータベースで何が起きているかの膨大な情報を提供する。
Cloudwatchはマシン内で何が起きているかに関する詳細な情報を提供している一方で、Herokuはユーザーサイドで対応が必要になる様々な問題を通知および、モニタリングするのに、 pg-extras で観測できるメトリックのみを利用している。データ破損が起こった場合、Herokuではそれを検知し修正する。セキュリティーの問題は事業者で対処されるだろう。DBAまたはDevOpsの担当者は、 Cloudwatchのメトリックに非常に気をつけることだろう。HerokuのPostgreSQLはそれに気を配らなくてよくすることに重点的に取組もうとしている。
データクリップ
HerokuのPostgreSQLを使う時の1つのボーナス機能はデータクリップである。 データクリップは基本的にチームで各メンバにデータを閲覧する権限を付与せずに伝えるための、読取り専用のクエリを共有し保存する為の方法の1つである。 クエリをタイプするだけで、そのページで結果がすぐみれる。クエリはバージョン管理されている - チームでクエリを発行して、微修正があったとすると、その時間に対する変更をみることができる。
個人的な経験では、データクリップは救世主であり、とりわけプログラマでないチームと共に仕事をする時に役立つ。
ビジネスまたはサポートのスタッフが、売上げ、不正、ユーザー挙動、アカウントの活動、または起きているその他のことに関する情報を必要とした場合、私はいつでもその必要な情報を取得する為のクエリを書き上げることができた。データクリップができる前は、まずクエリを書き、どこかに保存し、通常は結果を一連のCSVかスプレッドシートとして出力し、それから電子メールで必要とする人に送る必要があった。結果として、これは毎回要望を受けるたび行う日頃の活動となるのだ。
データクリップの世界に入ろう。今や、クエリを用意して、情報が欲しい人にランダムハッシュ化されたリンクを送ればよいだけである。 翌日、翌週、翌月にに彼らがより最新の情報を欲しくなったとしてもページを更新するだけで良い。クエリを書けば、2度とそのリクエストを聞く必要がない。 これは開発者の時間節約となる。保存して名前を付けて、必要であればより厳密にアクセス管理を行うことができる。
結論と推奨
一般的に、AWS RDSのPostgreSQLは、より安価で、かつアプリケーションで必要となることに対してより正確に仕立てあげることができる。 より細かい粒度でアクセス、セキュリティー、モニタリング、アラート、地理的配置、そしてメンテナンス計画の制御を行える。
HerokuのPostgreSQLでは、単純化された価格体系に基づき少し多めに払うことになるが、一方で全ての開発データベースは無料である。 RDSが可能であるような詳細な管理はできないが、これは一部はこのような詳細を何もしなくてよいような設計である。 Herokuを使えば、データベースがどのように振る舞っており、内部リソースを使っているかの情報を直接取得することができ、それによって問題が発生する前に設定をチューニングし改良することが可能となる。
もしどうしても決めなければならないとすると、スタートアップではおそらくHerokuとHerokuのPostgreSQLを選択する。アプリケーション開発および顧客に焦点をあるためだ。 収入を確立する為にビジネスのゴールに焦点をあて時間を節約するというのが最重要課題であろう。 それから、サービスが成長し、データベースがもはやそんなに変更できなくなったら、RDSに移行するということに意味がでてくるかもしれない。安定性や、長期的なメンテナンス、セキュリティーに焦点をあてるためだ。
最終的には、何がよりコストとなるかに到達する: 時間か、インフラのコストか、である。時間がより重要なコストとなるのであれば、Heroku PostgreSQLを利用するのが良いだろう。 インフラのコストがより重要となるのであればRDSを利用するのが良いだろう。両者をAWSのデータセンタ内においておくと、両者を切替える必要が出てきた時に、簡単に切り替えられる。
