西鉄ストアの本部基幹システム、AWS のクラウドサービス上に全面移行 55
ストーリー by reo
によによ 部門より
によによ 部門より
insiderman 曰く、
福岡県・佐賀県にスーパーマーケット 56 店舗などを運営する西鉄ストアが、その本部基幹システムを刷新、Amazon Web Services (AWS) を使ったクラウド上で動作するシステムに移行したという (クラウド Watch の記事、ノーチラス・テクノロジーズのプレスリリースより) 。
稼働しているシステムは「売上・売掛金管理システム」「仕入・買掛管理システム」「テナント管理システム」「管理会計システム」という、どれも停止すると大きな影響のあるシステム。関係者がこれについて紹介しているが、バッチ処理はすべて Hadoop で処理しており、Hadoop クラスターの運用面でのトラブルやパフォーマンス問題を解決するために AWS を採用したという。いっぽう、AWS を利用することでコストパフォーマンスが少なくとも
半分以下で2倍以上になり、またクラウドを利用することによる運用負荷の軽減、可用性の向上などもメリットとしてあげられている。開発者側もクラウドを使うことは絶対にないだろうと思っていたレベルの案件だったそうで、当然ながら AWS 側で障害が発生することもあらかじめ織り込んでのシステムだそうだ。この規模のシステムをクラウド上で動かす例は (少なくとも国内では) 少ないと思われる。とりあえず全面稼働は開始したが、ここからがある意味本番なのかもしれない。
あれ？傍系にDC事業やっている会社があるけど？ (スコア:3, 興味深い)
#これはACじゃなきゃ投稿できない
Re:あれ？傍系にDC事業やっている会社があるけど？ (スコア:2, すばらしい洞察)
西鉄情報シ○テム？
Re:あれ？傍系にDC事業やっている会社があるけど？ (スコア:2)
今どき、グループ企業が該当事業を行っているからといって、受注できて当然とは限らない。それどころかグループ企業で内実を把握しているからこそ、発注したくないということもある。
もちろん、AWSより割高でも手厚いサービスを求める顧客はいくらでもいるだろうから、国内ベンダーにも勝ち目はある。
Re: (スコア:0)
いまどき、親会社があっても、そこにおんぶ抱っこのほうが珍しいよね。
親も子会社より良い条件があれば他と契約するし、
子会社も親よりいい仕事があればそっちを優先する。
これも時代だねえ。
発注したのに届かない (スコア:2)
仕入れ担当者が「konozama」という呪文を覚える日は近い・・・・か？
＃最近唱えてないなーgesaku
Re: (スコア:0)
どうしても貶めたいんだろうけど、国内のクラウドよりはよっぽど稼働実績ありますからねぇ...
国内は、サービス開始と同時にトラブル起こして閉鎖してた某大手通信系のクラウドサービスもあったし
Re: (スコア:0)
EC2もやらかしたじゃないかｗ
Re: (スコア:0)
AWSはトラブルはあったけど、NTTPCのCloud9のように閉鎖はしていないので月とスッポン。
Re: (スコア:0)
この業界も、継ぎ接ぎ続けたシステムに、
正規化の例外みたいな(ただし商慣習上は必要な)データを少しずつ重ねてキメラみたいなシステムを使ってるので
注文が原因不明のエラーで止まるとかよくあること
# 可変税率が来たら家出します探さないで下さい
コストパフォーマンス (スコア:1)
とありますが、良いの?悪いの?
Re:コストパフォーマンス (スコア:3)
>AWS を利用することでコストパフォーマンスが少なくとも半分以下で、
とありますが、良いの?悪いの?
わかりにくい表現ではありますな…リンク先には
従来のコストで2倍のパフォーマンスを得たほか
とあるので、コストパフォーマンスはかなり良くなった。ということなのでしょう。
Re: (スコア:0)
元記事の内容は「オンプレミスでのC/PはAWSの半分以下だった」ということなので、
トップ記事としてまとめるなら「AWSとした事によりオンプレミスの倍以上のコストパフォーマンス」と
する処ですね。
要するに記者が悪い。
Re: (スコア:0)
システムの種類にもよるが、今後の拡張性とかそういうことを抜きに、現有システムのコストだけでみたら、オンプレもAWSもそう大差ないはずなんだが…
単にNISとか経由してぼられてただけなんじゃね？
Re:コストパフォーマンス (スコア:3, 興味深い)
サーバ代だけだったら大差ないかもしれませんが、
オンプレシステムって、センター代が馬鹿になりません。
うちが見積もった限りでは、普通にラック借りて安いサーバ
買って置くだけでも、余裕でAWS超えてしまいます。
その上、調達リードタイムとか、構築コストとか考えると……
円安ドル高 (スコア:0)
円高だった時期にAWSで構築してコストが下がったー！って言って喜んでたところは、アベノミクスとやらの影響で急激に円安になり、担当者＆財務担当者の顔色が青くなっているという…
一般に、クラウドは調達コストや構築コストは安いですが、運用コストは高くなります。
まして円安で自動的に料金が高くなってしまうんですから、さらに運用コストが跳ね上がります。
長く使えば使うほど、オンプレよりもコストが高くついてしまうんですね。
Amazonが企業努力により、大幅に料金を値下げすれば別ですけどね。
Re: (スコア:0)
これはこのタレこみが悪いだろ
「コストパフォーマンス」が「半分以下」になったらそれは悪いことだけど今回の件では「コストパフォーマンスは倍以上」になってる。
タレこみ時点で文章が間違えられてる。
Re:コストパフォーマンス (スコア:1)
修正しておきました。ご指摘ありがとうございます。
規模感の問題なのかい？ (スコア:1)
ごめんちょっとストーリの意図がよく分からない。珍しいの？
>この規模のシステムをクラウド上で動かす例は (少なくとも国内では) 少ないと思われる。
これは 「この程度しかない規模のシステム」 なのか 「これほど巨大な規模のシステム」 なのか、ちょっと意図が読めなかった。
「かかわった人数が非常に多いシステム」って考えているのかなぁと思うが、それって規模とは違わなくないかなーとかちょっと思った
// オフトピっぽいのでアレなら沈めてくだし
// ウチのアレとかアレとかアレとかもAWSなんで、少ない例の一つってことなのかにゃー (:>^
Re:規模感の問題なのかい？ (スコア:2)
記事にある「関係者の紹介」には
> 外部接続のインターフェイス数は600本強、主要画面数で600画面程度、
> 一晩で走るジョブグループ数で200でバッチ本数で3000本弱、
> この間に処理されるデータ件数は最大で20億件弱に渡ります。
> 開発期間は2年強。投入人月で600~700人月クラス。
> のべ人数で200人以上は関わったと思いますが、出入りも激しいプロジェクトでした。
> バッチ処理は全てHadoopで処理しています。
> ピーク時点では一晩で20億件のデータを業務処理する化け物のようなバッチのカタマリのシステムです。
とあり、その上で
> これだけの複雑かつミッション・クリティカルな仕組みが
> AWSにあがっているのは、日本では間違いなく初めてでしょう。
とまとめていますね。
Re:規模感の問題なのかい？ (スコア:1)
やー・・・読んだけど・・・
もっとでかいシステムいっぱいあるやん、って突込みが・・・
Re: (スコア:0)
日本語力がやばいじゃ…
大きいシステムが、のほうでしょ。どう読んでも。
>// ウチのアレとかアレとかアレとかもAWSなんで、少ない例の一つってことなのかにゃー (:>^
おたくの規模がわからんから何とも言えんわ
搭載システムによって異なる (スコア:1)
AWSにしてコストが半分になる場合もあれば、逆に数倍に跳ね上がることもあります。
なんでもかんでもクラウドコンピューティングにすると良くなると会社上層部が勘違いしないよう、要注意です。
リソースのピークと平常値の差、そしてそれぞれの時間（期間）の割合によってオンプレかクラウドか、適切なのはどっちか決まります。
誠実なSIerなら、その辺をきちんと調査して計算し、オンプレがいいのかクラウドがいいのかまで教えてくれますが、その辺すっ飛ばしてクラウドにしようとするSIerが来たら要注意です。
クラウドな機能はどこに (スコア:0)
出先からスマホで会計業務とかやっちゃうんでしょうか
インフラのアウトソーシング以上の内容が伝わってきませんね
Re:クラウドな機能はどこに (スコア:1)
サーバーがクラウド上にあるのです。googleのサーバーがどこにあるか、壊れないのかもしくは壊れた時どうしているのか気にしたことないでしょ?
Re:クラウドな機能はどこに (スコア:1)
AWSは生きていても、九州のIXが死んだらもろとも
なのか。
#サイゼリアの店員注文端末がiPod touchになった
#らしいけど、クラウドだったりするのかな？
#アプリだけかな。
Re: (スコア:0)
IXが死んだら、そもそもクラウドだろうが何だろうが、ネットワークを通じてする作業全般がダメになるんでは。
そこまで想定してサービスを作ると、全部紙で印刷する世界ですよ。
Re: (スコア:0)
専用線とか公衆網って何なんでしょうね。
Re: (スコア:0)
言い訳がましいが、全国どこでも同一のISP使っていればIXを通らなくてもサービス提供できるのではないだろうか、と
Re: (スコア:0)
IXが死んでも自社内にサーバがあれば繋がる。
AWSの可用性はともかく、AWSに接続するための可用性は
大丈夫なんだろうか。
Re: (スコア:0)
IXと繋がらなくなったりAWSが動かなくなった時の復旧までのコストと自社サーバーでの運用保守のコストとを天秤にかけてAWSに決めたのでしょ。
Re: (スコア:0)
むやみにクラウドに移行して失敗する原因の一つが、クラウドサービスまでの通信費です。
特に社内基盤システムをクラウド上に置く場合、いくらクラウドがスケールイン・アウトに優れ、障害時の復旧も迅速にできるとしても、そこまでの通信回線は増速し、かつ予備回線や別の経路でも確保して置く必要があります。
「今日はインターネット回線に障害が発生してるので、全ての業務は停止します」なんて事態は回避しなくてはなりません。
品質保証のある専用回線を２系統引く時点で、コストはかなり上がると思います。
Re: (スコア:0)
IXが落ちても大丈夫でしょ。
AWSが落ちても大丈夫なように作ってるらしいから、
待機系が社内にあるんじゃないかな。
Re: (スコア:0)
クラウドのインフラを(多分)全部自社調達している超特殊例を引き合いに出されても。
Re:クラウドな機能はどこに (スコア:1)
単に、「仮想型のレンタルサーバ」って意味で使ってるみたいですね。
単にデータセンタを区画借りして、仮想サーバを運用しているに過ぎない気がする。
人によって「クラウド」の意味が違ったりするので、性質が悪い。
Hadoop (スコア:1)
Hadoopで処理ってことで、クラウド型サーバ、特にAWSとの親和性が高いというものでは？
＃Hadoop選んだ時点でAWS使うのが前提ともいえる？
Re:クラウドな機能はどこに (スコア:1)
http://hugjp.org/index.php?view=article&id=2:cloud-definition [hugjp.org]
Re: (スコア:0)
以上とか以下という話じゃない。
元記事ってただの自慢話じゃ (スコア:0)
＞やはり、Hadoopの運用はなかなか骨が折れます。
＞稼働が一年近くになってくると、さすがにいろいろイカレてくるのですが、どうにも国内の某ベンダーさんは対応できませんでした。
対応できないが既に謎かな。
ベンダーさんにどこまで期待しているのかわからんが、
それはAWSにしたら解決するのか？
自分たちで対処することになるだけじゃないのか？
＞一部の例外を除き、全然お勧めしません。どうしてもやるなら、最低でも、いろいろと人的なコストが青天井になることは覚悟すべきです。
Hadoopについてはその通りだと思うが、タダの自慢かなと。
そこでオンプレはダメだ。に繋がるところは謎。
＞・・・あとこのインフラ移行をやったのが、うちのエンジニアが約一名です、ってのもちょっと特記すべき事項だと思っています。
＞（略）
＞最後に実際に弊社某エースの作業中の独り言だけ書いておきます。
結局この人１人がスゴイだけじゃね？この人辞めたらとか
技術の共有とか継承とか全く何も書いてない。
ちなみに、うちもHadoop使ってるから大変なのはわかるけど
AWSの安定度とHadoopの安定度を考えたら、
AWSでHadoop！なんていう選択肢は無いな。
で、元記事見ても、「安くてパフォーマンスが良かった」しか書いて無くて
・AWSのインスタンスが落ちたときに、Hadoopをどうやって稼働させ続けるつもりなのか
という一番大切な部分が無い。
たぶんそのうち大障害でインスタンス落ちてデータ整合性無くなるに１票。
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)
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)
人的なコストが青天井になったらコスパは非常に悪くなるような気がするのだけれど、人的コストは人件費に跳ね返りません、ということなのだろうか。