AWSのElastic BeanstalkとOpsWorksとCloudFormationの立ち位置
AWSには、リソース管理サービスとして、以下の3つのサービスがあります。
- AWS Elastic Beanstalk -- ビーンスターク(豆の木, 豆の茎)と発音するようです
- AWS OpsWorks
- AWS CloudFormation
- EC2, Auto Scaling等の個別サービス
それぞれの特徴と選択の仕方は、以下のページに書いてあります。
AWS のアプリケーション管理 | アマゾン ウェブ サービス(AWS 日本語)
以下の様な住み分けなんだと理解しました。
- Beanstalk - インフラ専任がいないので、とりあえずな環境が欲しい
- OpsWorks - インフラ専任もしくはそれなりにリソースがあるが、その運用に効率性・柔軟性を与えたい
- CloudFormation - 自分で好きなように管理モデルを構築したい
ちょっとまえにBeanstalkを使ってみたので、その感想
メリット
Beanstalkは学習コスト対効果がなかなか優れたサービスだと思います。自分の場合は、Beanstalkを調べ始めて1週間程度で、ステージング、本番環境を用意することが出来ました。
この程度の学習で、EC2のオートスケール、ELBによる、アプリケーションの自動配備、ローリングアップデート、DNSの切り替えによるダウンタイム0のデプロイ、システムの監視が得られます。
それぞれ調べて調整するには、もっと時間がかかるように思います。
デメリット
情報がまだ少ないです。設定ファイルの書式は ini ファイル形式なのですが、そこで使えるオプションについてはOpsWorksやCloudFormationのものを参考にしましたが、何が有効で何が効かないか等の情報が少なかったです。
コマンドラインツールでBeanstalkを制御する場合で、チームで開発する場合、どういう開発・デプロイフローが適切かが、不明瞭です。
今後の期待
Beanstalkにチーム開発を想定した追加サービスが現れることを期待します。Jenkins等のCIをサービス化され、GITへのPushをトリガーに、テスト、デプロイが自動化されると、開発環境構築コストがかなり低減されるのではないでしょうか。
AWS Toolkit for Eclipseのインストールエラー
Eclipse 4.4 (Luna M5 Release)に、 AWS Toolkit for Eclipse をインストールしようとした際に、エラーが発生したので、その解決方法をメモ。
- [ヘルプ] > [新しいソフトウェアをインストール] を開きます。
- ダイアログの上の [機能するソフトウェア] というラベルのついた テキストボックスに http://aws.amazon.com/jp/eclipse と入力します。
- 下のリストから「AWS Toolkit for Eclipse」を選択します。
- [次へ残りのインストール手順は Eclipse が案内します。
上記手順通りに行っても、インストールの途中で下記の様なエラーが出てしまいます。
'Installing Software' has encountered a problem.
An error occurred while installing the items session context was:(profile=epp.package.dsl, phase=org.eclipse.equinox.internal.p2.engine.phases.Install, operand=null --> [R]com.amazonaws.eclipse.datatools.enablement.simpledb.driver 1.0.0.v201402141427, action=). Failed to prepare partial IU: [R]com.amazonaws.eclipse.datatools.enablement.simpledb.driver 1.0.0.v201402141427.
どうやらSimpleDBに関するパッケージに失敗しているようです。
インストール対象のソフトウェアを選択する際に、Amazon SimpleDB Managementを除外します。
しかし、次は下記の様なエラーがでてしまいます。
Cannot complete the install because one or more required items could not be found. Software currently installed: Amazon RDS Management 1.0.0.v201402141427 (com.amazonaws.eclipse.rds.feature.feature.group 1.0.0.v201402141427) Missing requirement: RDS 1.0.0.v201402141427 (com.amazonaws.eclipse.rds 1.0.0.v201402141427) requires 'bundle org.eclipse.datatools.connectivity.ui.dse 1.1.0' but it could not be found Cannot satisfy dependency: From: Amazon RDS Management 1.0.0.v201402141427 (com.amazonaws.eclipse.rds.feature.feature.group 1.0.0.v201402141427) To: com.amazonaws.eclipse.rds [1.0.0.v201402141427]
「Amazon RDS Management」が依存しているパッケージが存在していないようです。これは、Data Tools Platformの一部のようです。
先に、Eclipse標準のリポジトリから「Database Development > Data Tools Platform Extender SDK」をインストールします。
その後、再度 「Amazon RDS Management」をインストールすると無事インストール出来ました。
Cloud9からNodeclipseを試してみる
Cloud9を使っていて、ちょっとストレスが溜まってきた(IDEを起動するのが億劫)ので他の環境を探してみた。
Cloud9をしばらく試してみた感想
- ブラウザ上のテキストエディタはちょっと遅い(CPUパワー不足?)
- Cloud9付属のターミナルの反応が悪い
- (ブラウザをいきなり落としたせいか)nodeプロセスが居残り、ポートを離さない事がある(Killで削除した)。
- ファイルを開くときにプログレスバーが進まず開けない時がある(IDE開き直し)
- オブジェクトの宣言へのジャンプが遅い・もしくは飛ばない
- 間違ってF5押すとIDEがリロードされてめげる
- 毎月お金がかかる
Nodeclipseを入れてみた感じ
良い点
悪い点
- Windowsではターミナルは無いので、StartExplorerプラグインでコマンドプロンプトを起動して代用。
- 「Node with moniter」という起動方法(おそらくnode-devで起動する)がうまく動作しない。コマンドプロンプトで直接 node-devを実行。
- 情報が少ない
なんか、これに落ち着きそうな感じ。
ウェブサービスでカード決済を簡単に行うには(特に定期購読)
有料ウェブサービスを提供する為には決済が必要です。 僕の場合、以下の様な要件になりそうです。
- 定期購読ができる
- 簡単に実装できる
- 初期費用が無い・安い。
- クレカで決済できれば良い。
調べた
- stripe
- WebPay
- stripeに非常に良く似たサービス。
- APIの互換性もある程度目指している様子。
- 日本で展開している。
- 定期購読機能がない -- WebPayを使って定期課金(定期購読)処理を行う - Qiita
- PayPal
- 支払者はPayPalアカウントが必要
- ひと通りできそう。
まとめ
Stripeが日本で使えたらベスト。ちょっとがんばってWebPayでやろうかな。 PayPalはもうちょっと調べてみてWebPayと比較したい。
Cloud9を1,2週間使ってみた感想
いい点
悪い点
- コード補完は期待していたほど使えない
- ファイルの保存に時間がかかることがある(長時間ブラウザをほったらかしにしてたりすると起こりやすい)
- IDEとしての完成度はやはりそれなり(エディタのスクロールが重い、関数の宣言へのジャンプが遅い、ジャンプ元に戻れない等)
- ポートをListenするようなプログラムはTerminalで起動できない? -- Cloud9 でAWS DynamoDB Local起動しようとすると Permission Denied
疑問
- mocha のテストをステップ実行するには?
現時点の感想
一人でさくっと何かを試すには良さそうだけど、本格的に開発するにはストレスが溜まりそう 。
Cloud9 でAWS DynamoDB Local起動しようとすると Permission Denied
Cloud9 で、DynamoDB Local を起動しようとしたら、ポートをバインドするときにエラーになってしまいました。
$ java -Djava.library.path=. -jar DynamoDBLocal.jar 2014-02-05 03:33:39.980:INFO:oejs.Server:jetty-8.1.12.v20130726 2014-02-05 03:33:40.383:WARN:oejuc.AbstractLifeCycle:FAILED SelectChannelConnector@0.0.0.0:9000: java.net.SocketException: Permission denied java.net.SocketException: Permission denied at sun.nio.ch.Net.bind0(Native Method) at sun.nio.ch.Net.bind(Net.java:444) at sun.nio.ch.Net.bind(Net.java:436) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) at org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:187) at org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:316) at org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:265) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64) at org.eclipse.jetty.server.Server.doStart(Server.java:293) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64) at com.amazonaws.services.dynamodbv2.local.server.DynamoDBProxyServer.start(DynamoDBProxyServer.java:57) at com.amazonaws.services.dynamodbv2.local.serverRunner.ServerRunner.main(ServerRunner.java:154) 2014-02-05 03:33:40.384:WARN:oejuc.AbstractLifeCycle:FAILED org.eclipse.jetty.server.Server@99b59c: java.net.SocketException: Permission denied java.net.SocketException: Permission denied at sun.nio.ch.Net.bind0(Native Method) at sun.nio.ch.Net.bind(Net.java:444) at sun.nio.ch.Net.bind(Net.java:436) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) at org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:187) at org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:316) at org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:265) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64) at org.eclipse.jetty.server.Server.doStart(Server.java:293) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64) at com.amazonaws.services.dynamodbv2.local.server.DynamoDBProxyServer.start(DynamoDBProxyServer.java:57) at com.amazonaws.services.dynamodbv2.local.serverRunner.ServerRunner.main(ServerRunner.java:154) Exception in thread "main" java.net.SocketException: Permission denied at sun.nio.ch.Net.bind0(Native Method) at sun.nio.ch.Net.bind(Net.java:444) at sun.nio.ch.Net.bind(Net.java:436) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) at org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:187) at org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:316) at org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:265) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64) at org.eclipse.jetty.server.Server.doStart(Server.java:293) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64) at com.amazonaws.services.dynamodbv2.local.server.DynamoDBProxyServer.start(DynamoDBProxyServer.java:57) at com.amazonaws.services.dynamodbv2.local.serverRunner.ServerRunner.main(ServerRunner.java:154)
ソケットをListenするのは、特に制約事項としてなかった気もするのですが、ダメなんでしょうか。。。 しかたないので、実際のDynaomDBにつなげて開発しようかな。
MongoHQとAmazon DynamoDBの比較
概要
しらべた結果
比較対象としてはちょっと違うのですが、MongoDBとDynamoDBをそれぞれ使う場合の理由をアドバイスしているブログが有りました。MongoDBとの比較といいつつも、この人はMongoHQを使っているようですね。
Mason Zhang: 3 Reasons You Should Use DynamoDB over MongoDB -- MongoDBよりDynamoDBを使うべき3つの理由
理由1: DBサーバの管理の為に人員を確保するつもりが無いなら、DynamoDBを使いなさい。
- 私がMongoDBからDynamoDBに乗り換えた1番の理由。
- 実装すべき機能が沢山あり、サーバ管理にまで手が回らない。
- 21日でウェブ開発者になれるなんていう人もいるが、サーバトラブルの対応はそんなに簡単じゃない。
- たった15000ユーザー、1.4万件のレコードで、深刻なトラブルが発生し始めた。
- データを保存すればするほどレイテンシーが悪化していった。
- 将来、シャーディングやシャーディングの為のレプリカセットを設定する為の作業時間が半端なくなるのが想像できた。
- DynamoDBでは完全にDBの管理者は必要ない。
理由2: DBの専用サーバを利用する予算が無いのなら、DynamoDBを使いなさい。
- 私はそれほど多くのトラフィックとデータレコードではなかったのです。
- 理想的には、とてもうまくデータをスケールしてくれるはずでしたが、実際には違いました。
- データベースのアップグレードは、より多くのコストが必要ですが、それでも問題を解決出来ない可能性がありました。
- 私のサービスでは、8GBのディスク領域と、2GBのジャーナルファイルを占めていますが、この場合25GBのプランが必要で、毎月$500必要でした。
- トラフィックとユーザーがより増えたら、費用がかかりすぎてしまう。
- 全データをDynamoDBへ移行する前に、140万のレコードを移行してテストした所、実際のディスク使用量は300MB以下だった。
- DynamoDBの費用は、最初の週で $0.05だった。
理由3: 他のAmazon Web Serviceとの統合を考えているなら、DynamoDBを使いなさい。
- 例えば、全文検索をしたい場合、MongoDBにも全文検索の仕組みはありますが、その為にはインデックスと検索の為の追加のサーバが必要で、その仕組を理解する必要がある。全文検索インデックスがあるのは良いことだが、中国語の形態素解析等の多言語対応は簡単ではないだろう。Amazon CloudSearchはDynamoDBに対応した全文検索インデックスソリューションだ。
- 他にも、DynamoDBとの統合が簡単なAWS Elastic MapReduceや、データベースのバックアップ・リストアの為に他のサービスとの統合されている。
- 私の意見では、Amazon Webサービスの主要なNoSQLのデータベースとして、DynamoDBのは、より多くの機能を持って、あなたは、開発をスピードアップし、Amazon Webサービスを統合することにより、サーバ管理のコストを削減することができます。
Mason Zhang: 7 Reasons You Should Use MongoDB over DynamoDB -- DynamoDBよりMongoDBを使うべき7つの理由
理由1: インデックスフィールドを後で変更するかもしれないなら、MongoDBを使いなさい
- DynamoDBでは後からインデックスを変更出来ない。する場合は、新しいテーブルを定義し、古いテーブルからデータをインポートする必要がある。
- ハッシュキー、 Range key, セカンダリインデックスが使えるが、複雑なクエリは対応していない。
- セカンダリインデックスは、追加のストレージ容量が必要となる。
理由2: NoSQLの利用方法として、ドキュメントデータベース機能が必要であれば、MongoDBを使いなさい
- ドキュメントデータベースでは、データ構造を入れ子式にできるが、キーバリューデータベースの場合は出来ない。
- 複雑なクエリが可能。
理由3: Perl, Erlang, C++を使うのであれば、MongoDBを使いなさい
理由4: DynamoDBの限界を超える場合は、MongoDBを使いなさい
- DynamoDBは、値に格納できる最大サイズが64kbyteまで。 それを超える場合は、複数のキーに分割する必要がある。
理由5: sring, number, base64エンコードされたバイナリ以外のデータ型が使いたければ MongoDBを使いなさい
- MongoDBではさらに、array, date, boolean, Object ID(MongoDB独自の型)をサポートしている。
理由6: 正規表現でクエリをしたければMongoDBを使いなさい
- 正規表現を使用して、前方一致、部分一致、後方一致といった方法でフィルタができるが、フルスキャンが必要。
- DynamoDB ではこのような複雑なクエリを1クエリで行うことは出来ない。
理由7: ドキュメントデータベースが大好きならMongoDBを使いなさい
- 開発元の10genは、コミュニティに対して積極的に関わっているし、コミュニティのみんなも相談にのってくれる。
- Amazonはデカい会社で、中の人となかなか連絡とれないし、もちろん彼らの方針に口出すこともできない。
まとめ
- DynamoDB :コスト:○、パフォーマンス:○、機能:☓、開発しやすさ:☓
- MongoHQ : コスト:☓、パフォーマンス:?、機能:○、開発しやすさ:○
DynamoDBつかおっかな。