アカウント名:
パスワード:
>やはり、Hadoopの運用はなかなか骨が折れます。>稼働が一年近くになってくると、さすがにいろいろイカレてくるのですが、どうにも国内の某ベンダーさんは対応できませんでした。
対応できないが既に謎かな。ベンダーさんにどこまで期待しているのかわからんが、それはAWSにしたら解決するのか?自分たちで対処することになるだけじゃないのか?
>一部の例外を除き、全然お勧めしません。どうしてもやるなら、最低でも、いろいろと人的なコストが青天井になることは覚悟すべきです。
Hadoopについてはその通りだと思うが、タダの自慢かなと。そこでオンプレはダメだ。に繋がるところは謎。
>・・・あとこのインフラ移行をやったのが、うちのエンジニアが約一名です、ってのもちょっと特記すべき事項だと思っています。>(略)>最後に実際に弊社某エースの作業中の独り言だけ書いておきます。
結局この人1人がスゴイだけじゃね?この人辞めたらとか技術の共有とか継承とか全く何も書いてない。
ちなみに、うちもHadoop使ってるから大変なのはわかるけどAWSの安定度とHadoopの安定度を考えたら、AWSでHadoop!なんていう選択肢は無いな。で、元記事見ても、「安くてパフォーマンスが良かった」しか書いて無くて・AWSのインスタンスが落ちたときに、Hadoopをどうやって稼働させ続けるつもりなのかという一番大切な部分が無い。
たぶんそのうち大障害でインスタンス落ちてデータ整合性無くなるに1票。
「ウチは問題ない」自慢ですか?良かったですね(皮肉じゃないです)
AWSの管理者は下記の記事に書かれてるように博士号レベルの方だそうですホントにクリティカルな問題が出た際の問題解決能力とか考えると、AWSという選択はアリな気がします
(2010/6/11)米Amazon Web Services幹部が語る「アマゾンクラウドの真実」http://internet.watch.impress.co.jp/docs/event/irop_tk10/20100611_3736... [impress.co.jp]
博士号レベルならすごいって言い張るのは完全に子供だましだろ…。まともな企業なら博士の1人や2人そこらにごろごろしてる。下手すりゃ隣で寝てるレベル
おいおい。日本のモラトリアム博士と、北米のPh.D.は混ぜるな危険だぞ。
そう言う言い方は「NASAで開発された」って宣伝文句に飛びついちゃうおばちゃんぐらいしかもはや釣れないと思われ
>日次・月次バッチでも事足りるんじゃないの?的な裏方処理それこそが通常ではクラウドやHadoopに乗せない部分で、それをクラウド+Hadoopに乗せたからリリースしてるわけでしょ。
お前がそう思うんならそうなんだろう、お前ん中ではな
Hadoopは並列処理の基盤であって、バッチ処理に必ずしも向いているわけではない。また、バッチ処理といっても単純なものから複雑なジョブネットの場合もあって、ジョブネットそのものにHadoopは全く不向きだよ。おそらく単純なバッチ処理しか知らないからHadoopはバッチに向いているといっているんだろうが、今回の案件はAsakusa frameworkがあってのHadoopだよ。JP1やSystemwalkerで稼働する規模のバッチ処理を簡単にHadoopで実現できるなら、その手法を教えてほしいぐらいだ。
素のHadoopは複雑なバッチ処理に向かないから、AsakusaというHadoopの上位に位置するフレームワークを構築しているわけで。この2つを同一視するほうがおかしいし、会話の中で区別がつかないのはまずいぜ。
人的なコストが青天井になったらコスパは非常に悪くなるような気がするのだけれど、人的コストは人件費に跳ね返りません、ということなのだろうか。
自社内あるいは下請けの人的コストはサービス残業でまかなうから増えないんじゃないですかね?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
元記事ってただの自慢話じゃ (スコア:0)
>やはり、Hadoopの運用はなかなか骨が折れます。
>稼働が一年近くになってくると、さすがにいろいろイカレてくるのですが、どうにも国内の某ベンダーさんは対応できませんでした。
対応できないが既に謎かな。
ベンダーさんにどこまで期待しているのかわからんが、
それはAWSにしたら解決するのか?
自分たちで対処することになるだけじゃないのか?
>一部の例外を除き、全然お勧めしません。どうしてもやるなら、最低でも、いろいろと人的なコストが青天井になることは覚悟すべきです。
Hadoopについてはその通りだと思うが、タダの自慢かなと。
そこでオンプレはダメだ。に繋がるところは謎。
>・・・あとこのインフラ移行をやったのが、うちのエンジニアが約一名です、ってのもちょっと特記すべき事項だと思っています。
>(略)
>最後に実際に弊社某エースの作業中の独り言だけ書いておきます。
結局この人1人がスゴイだけじゃね?この人辞めたらとか
技術の共有とか継承とか全く何も書いてない。
ちなみに、うちもHadoop使ってるから大変なのはわかるけど
AWSの安定度とHadoopの安定度を考えたら、
AWSでHadoop!なんていう選択肢は無いな。
で、元記事見ても、「安くてパフォーマンスが良かった」しか書いて無くて
・AWSのインスタンスが落ちたときに、Hadoopをどうやって稼働させ続けるつもりなのか
という一番大切な部分が無い。
たぶんそのうち大障害でインスタンス落ちてデータ整合性無くなるに1票。
Re:元記事ってただの自慢話じゃ (スコア:1)
「ウチは問題ない」自慢ですか?良かったですね(皮肉じゃないです)
AWSの管理者は下記の記事に書かれてるように博士号レベルの方だそうです
ホントにクリティカルな問題が出た際の問題解決能力とか考えると、AWSという選択はアリな気がします
(2010/6/11)米Amazon Web Services幹部が語る「アマゾンクラウドの真実」
http://internet.watch.impress.co.jp/docs/event/irop_tk10/20100611_3736... [impress.co.jp]
Re: (スコア:0)
博士号レベルならすごいって言い張るのは完全に子供だましだろ…。
まともな企業なら博士の1人や2人そこらにごろごろしてる。下手すりゃ隣で寝てるレベル
Re: (スコア:0)
おいおい。日本のモラトリアム博士と、北米のPh.D.は混ぜるな危険だぞ。
Re: (スコア:0)
そう言う言い方は「NASAで開発された」って宣伝文句に飛びついちゃうおばちゃんぐらいしかもはや釣れないと思われ
Re: (スコア:0)
Re: (スコア:0)
印象操作がうまい記事だなぁ、と。
スーパーマーケットの名前を上げて基幹システムとかミッションクリティカルとか表現すると、あたかも店舗POSまで含めた高い即時性が求められるシステムかのような印象だけど、記事を見ると『本部基幹システムは、「売上・売掛金管理システム」「仕入・買掛管理システム」「テナント管理システム」「管理会計システム」の4つのサブシステムから構成される。』って書かれてて、日次・月次バッチでも事足りるんじゃないの?的な裏方処理がメインなのよね。
#だからって、大したことないとか言う気はありませんが。
Re:元記事ってただの自慢話じゃ (スコア:1)
>日次・月次バッチでも事足りるんじゃないの?的な裏方処理
それこそが通常ではクラウドやHadoopに乗せない部分で、それをクラウド+Hadoopに乗せたからリリースしてるわけでしょ。
Re: (スコア:0)
お前がそう思うんならそうなんだろう、お前ん中ではな
Re: (スコア:0)
Re: (スコア:0)
Hadoopの特性や実装の話をしているのではありませんよ。
Re:元記事ってただの自慢話じゃ (スコア:1)
Hadoopは並列処理の基盤であって、バッチ処理に必ずしも向いているわけではない。
また、バッチ処理といっても単純なものから複雑なジョブネットの場合もあって、ジョブネットそのものにHadoopは全く不向きだよ。
おそらく単純なバッチ処理しか知らないからHadoopはバッチに向いているといっているんだろうが、今回の案件はAsakusa frameworkがあってのHadoopだよ。
JP1やSystemwalkerで稼働する規模のバッチ処理を簡単にHadoopで実現できるなら、その手法を教えてほしいぐらいだ。
Re: (スコア:0)
それは違うよ、って言いたいの?
Re: (スコア:0)
素のHadoopは複雑なバッチ処理に向かないから、AsakusaというHadoopの上位に位置するフレームワークを構築しているわけで。
この2つを同一視するほうがおかしいし、会話の中で区別がつかないのはまずいぜ。
Re: (スコア:0)
人的なコストが青天井になったらコスパは非常に悪くなるような気がするのだけれど、人的コストは人件費に跳ね返りません、ということなのだろうか。
Re: (スコア:0)
自社内あるいは下請けの人的コストはサービス残業でまかなうから増えないんじゃないですかね?