みなさん、こんにちは！フリューでモバイルサイト開発を行っている鷲見といいます。
現在あるソーシャルプラットフォーム上のアプリケーションを構築するプロジェクトでの、クラウド環境の導入の進行状況をそのまま記事にしています。
前回、前々回の記事でクラウド環境の比較、見積りを行い、Amazon Web Servicesを利用することを決定しました。
今回からはAmazon Web Services 1ヶ月導入記とタイトルも改め、Amazon Web Servicesの導入までを記事にしていきたいと思います。なお、今後文中ではAmazon Web ServicesはAWSと省略表記させていただきます。
今回のテーマはデータベースです。
前回の見積編でもAWSでは異なるデータベースサービスの2種類の見積を行いました。また、AWSが準備しているデータベースサービス以外にも、EC2にデータベースをインストールして利用することも当然可能です。
今回構築するシステムでデータベースに求められる要件とAWS上で考えられるデータベースの特徴を突き合わせ、採用するデータベース構成を決定したいと思います。
要件
今回のサービスには以下のような要件があります。
データの特徴
今回のシステムはあるソーシャルプラットフォーム上にアプリケーションを構築するというものです。
今回のシステムは通常のソーシャルアプリケーション同様、ユーザに関するデータはソーシャルプラットフォーム側が持っておりAPIでアクセスします。このような特徴があるため、ユーザに関する情報はアプリケーション側では持ちません。
アプリケーションに関するマスタ情報と課金の履歴などの履歴情報がメインのデータとなります。
データの更新・削除はほとんどなく、履歴への挿入がある程度で、参照がメインのデータです。
複数の表への更新はほとんどなく複雑なトランザクションはありません。
データベースミドルウェアに関して
弊社の今までの経験から、一番得意で経験が多いのはOracleです。
次点はMySQLですが経験は少なく、PostgreSQLの経験はほとんどありません。
No SQLデータベースは技術検証に触ったりはしていますが、実サービスでは利用していません。
運用に関して
サービスの停止は売上の減少に直結するので、出来る限りデータベースが停止する状況を作りたくありません。このような理由から冗長構成を組んで可用性を高めたいと考えています。
また、AWSの経験が初めてなので、出来る限り運用に手間がかからないようにしたいと思います。
開発期間に関して
サービスの開発期間が1ヶ月と短いため、調査などに時間をかけることが出来ません。出来るだけ簡単に設定・運用が出来ることが望ましいです。
データベース構成
AWS上でデータベースを構築する際に考えられる構成としては以下のものが上げられます。
- Amazon Relational Database Service(RDS)を利用する
- Amazon SimpleDBを利用する
- EC2上にRDBをインストール
- EC2上にNo SQLデータベースをインストール
Amazon Relational Database Service(RDS)を利用する
RDSとはAWS上で展開されているリレーショナルデータベースサービスです。
オープンソースのリレーショナルデータベースとしてよく知られているMySQLを複雑な設定をほとんど行うことなく、すぐに利用することができます。
またMultiAZという機能を使って複数のAvailability ZoneにMySQLを配置することで、サービスの可用性を高めることも可能です。
※この記事を書いている6月には既にOracle Database 11gにも対応していますが、データベース選定を行った4月の時点ではMySQLのみの対応でした。
メリット
デメリット
Amazon SimpleDBを利用する
http://aws.amazon.com/jp/simpledb/
SimpleDBとはAWS上で展開されている非リレーショナル型のデータストアサービスです。
イメージとしてはKVS(Key Value Store)型のデータベースをイメージすると分かりやすいかと思います。
特徴としては高い可用性と運用の容易さが上げられます。負荷が高くなったような場合にもAWS側で自動的にスケールアウト・スケールアップを行ってくれます。
また、データは自動的に複数のAvailability Zoneに分散して保存されるので、データがなくなってしまうといったリスクも少なく、可用性も高くなっています。
データの操作はHTTPやSOAPを介して行います。
また、SQL文によく似たSELECTを発行することも可能です。
ただし、トランザクションには対応していません。
メリット
- 可用性が高い
- AWS側で管理するサービスなので運用のコストがほとんど掛からない
- スケールアウト・スケールアップを自動で行ってくれる
- 価格が非常に安い
デメリット
EC2上にRDBをインストール
EC2はAmazonのデータベース上に使いたい時に使いたい分だけサーバを構築できるようなサービスです。
このEC2で構築したサーバ上にRDBを自分でインストール・設定を行って利用します。
Oracle・MySQL・PostgreSQL・SQL Serverなど自分の好きなRDBMSを選択してインストールすることができます。また、自分で好きなように詳細な設定を行うことも可能です。
メリット
デメリット
- インストールや設定などを自分で行う必要がありコストがかかる
- 自動でスケールアウトしにくい
- 運用に関しては通常のRDB同様のコストがかかる
- 自分で可用性を高める構成を組む必要がある
EC2上にNo SQLデータベースをインストール
EC2で構築したサーバ上にNo SQLデータベースを自分でインストール・設定を行って利用します。
Cassandra・CouchDB・MongoDB・Redisなど何でも自分の好きなソフトを選択してインストールすることができます。また、自分で好きなように詳細な設定を行うことも可能です。
メリット
- ソフトウェアの選択の幅が大きい
- 自分で好きなように構築・設定を行うことができる
デメリット
- インストールや設定などを自分で行う必要がありコストがかかる
- 自動でスケールアウトしにくい
- 自分で可用性を高める構成を組む必要がある
- No SQLデータベースの運用の経験がないので、運用にかかるコストが読めない
比較検討
今回のサービスの重要な要件の一つに『設定・運用が簡単』というのがあります。
EC2上にゼロからDBサーバを構築し、可用性の高い構成にするというのは、複雑な設定とテストが必要で結構コストがかかりそうです。
これが経験の無いNo SQLデータベースとなると、なおさらコストがかかってしまいそうです。
この点でEC2上にRDB/No SQLデータベースをインストールするという選択肢は無くなりました。
今回のサービスのデータの特徴として『複雑なトランザクションが必要ない』という点があります。
SimpleDBはこの特徴にマッチするので、RDSとSimpleDBの2択となります。
RDSとSimpleDBでより設定・運用が簡単なのはSimpleDBです。
またコストがSimpleDBの方がかなり安いというのは前回の記事で紹介させていただいた通りです。
SimpleDBのデメリットとして
『AWS側でほぼ全ての管理が行われるので細かな設定・管理は行うことはできない』
が挙げられますが、巨大なサービスを運営しているAWSの設定・管理は信用して任せてよい気がします。
むしろ、こちらで管理を行うよりよっぽど効率的な設定・管理を行ってくれるのではないかと思います。
ということで今回のサービスではデータベースには『Amazon SimpleDB』を採用したいと思います。
まとめ
この記事では、
・高機能かつ可用性も高いAmazon Relational Database Service (RDS)
・シンプルで低コストなAmazon SimpleDB
・自分色に染められるEC2 + RDB or KVS
を比較検討しました。
今回の事例では、シンプルな機能で必要充分だった点と、面倒な設定や運用作業が不要で、価格が安いという利点から、『Amazon SimpleDB』を採用しました。
データベースも決定したので次回はAWSを利用したサービス全体のインフラ構成について検討していきたいと思います。
