Nautilus Office Opening Event & Asakusa-Hadoop on AWS 事例解説+Inside WindGateの解説+「YAESS」 #nt_opening
- understeer
- 3818
- 0
- 4
- 4
本番DBから基になるデータを取り、バッチサーバがバイナリファイルでVPCのHDFSへ転送。戻しはデータ量が少ないよね。 #nautilusop
2011-10-04 19:23:03何故AWSか。運用設計含めてHadoopクラスタ構築までに時間が掛かり過ぎる。スモールスタート可能。API活用可能、OSイメージカスタマイズでの構築が可能。VPCのセキュリティ。 #nautilusop
2011-10-04 19:24:24「バッチ処理シーケンス: 必要な全データを Amazon に転送して処理し、結果を逆転送して取得。 / Hadoop クラスタは Amazon で構築。理由は、国内インフラ提供ベンダも検討したが時間がかかりすぎる、必要な分の課金ですむ、など。 #nt_opening
2011-10-04 19:25:29Amazon VPCなのねー。 Hadoop cluster は Amazon で構築。何よりも時間、スピード構築可能、そしてコストが従量課金でわかりやすいし、最小限でいける、あとAPIが使いやすい。
2011-10-04 19:26:35不手際があり申し訳ありません. 対応ありがとうございます. “@ixixi: #nautilusop でつぶやいてたけど、 #nt_opening になったっぽいので変更。 #nt_opening”
2011-10-04 19:27:59「RDBMS (Oracle) で永続化し、HDFS側はキャッシュ扱い。データ両派 1GiB程度。データ連携の ThunderGateを使用。DCの DBサーバから、ゲートウェイとなるバッチサーバを経由して、AmazonVPC と SCP で通信する方式。 #nt_opening
2011-10-04 19:29:01EC2環境では、VyattaからVPCに接続。社内ネットワークからYAMAHAのRTX1200で接続。80Mbps以上出てる。本番もYAMAHAルータ。 #nt_opening
2011-10-04 19:29:23ネットワーク接続、テスト環境のEC2では、vyatta からAmazon VPCにだったのか。本番は、ヤマハのルータ、これ、AWS対応
2011-10-04 19:30:58EMRを使わなかった理由。現状Asakusaが対応していないため。将来対応予定。現状ではEC2のAPIで制御。あらかじめAMIは用意。バッチ実行時のみEC2を一時停止状態から稼働させる。 #nt_opening
2011-10-04 19:31:19「Amaon EMR は未サポート。AmazonAPIを使った AWS制御ツールを構築し、OSイメージを準備し、Hadoop設定ファイルを配布。バッチ実行時のみ、EC2を一時停止状態から稼働させる。起動コスト(?)などと見合わせて、常時起動しておくことも。 #nt_opening
2011-10-04 19:32:35「バックアップは、AMI として S3 に保存。システム更新時に取得。HDFS上のデータはスナップショットに保存。Amazon EBS をファイルシステムとしてマウントしている。 #nt_opening
2011-10-04 19:34:02HDFSはあくまでもキャッシュとして扱う。OSイメージから即時に構築出来ることが重要。障害発生時の環境とEBSにログが残っているので、調査は後から。 #nt_opening
2011-10-04 19:34:52はい、環境情報はuser dataで与えるイメージです。 RT @marblejenka: O谷さんが環境のインジェクションという喩えをどこかでしてたけど、そんな意識
2011-10-04 19:35:00「障害復旧は迅速・確実。 復旧を優先する。再生は、バッチを最初から再実行すればよい。 原因調査は、障害時のログとOSイメージを元に別途行なう。 #nt_opening
2011-10-04 19:36:18MultiAZを使用。障害時には、別のAZへ切り替わり、運用担当者へアラート。リージョンまたぎはしてないっぽいのかな。 #nt_opening
2011-10-04 19:36:18