アカウント名:
パスワード:
管理対象がある限界を越えれば自前で設備を整えて、スタッフを抱えた方が安くなることって一般的な気がする。 例えば、運送会社で小規模なところは整備工場を持ってないけど、昔の日通みたいに大規模なところだと整備工場を持っていて、壊れたトラックから部品を集めてトラックの再生までしていたと聞いたことがある。 で、クラウドといえばガバメントクラウドが、これから本格化するけど、政府や自治体のシステムを集約して載せるならデータセンターを何ヶ所か建設した方がAWSとか使うより安くなるような気がするけど、どうでしょうね。(構築・運用のノウハウやスキルをもった人材がいない、とか言われるのかしら)
「サーバーが年間通して常に26台でOK」みたいに、スケールする必用がないならクラウドのメリットも半減するからな。
「学習するときは百万台単位で必用だけど、それが終わったら不要になる。」という負荷の変動が激しい分野なら、学習するときだけ時間貸しした方が安くなるだろう。
変動が少ないし、事業も安定している企業ならメリットも少ない。#そんなことは百も承知で利用してたんじゃないの?
一時的な拡大縮小が効果的に効く分野はゲーム屋とチケット屋しか結局無かったのよ。企業の常用研究用だと、常になんかしらぶん回すから結局占有プランの方の割引率に時間貸しプランが負ける。そして、借りるぐらいなら自前で持った方が格段に安い。1年以内にで元が取れるので比較の俎上にすら上がらん。
おかげで弊社は毎年EPYCの研究開発用サーバーが増えてってる。(EPYCの前はXeonだったけど、Zen2以降のEPYCはコスパとワッパが段違い)
一文目についてだけ、一応もうちょい適用対象はあると言いたい。私のところ、B2Bのシステムで平日日中だけ台数を増やすスケーリングルールをAWS EC2でやっている。そこまで効果的かというと微妙かもしれないけど。
AWSを使うのは自分が入る前から親会社の方針みたいで、そこの理由はよく知らない。
それ定常的やってるのなら、パフォーマンス分析するとわざわざ増減とかせずにリザーブ化して割引分で常時増やしっぱなしにした方が管理コスト含めお得になりそうな気がする。一度分析してみては。
そうそう。全部リザーブドインスタンスで常時稼働させる場合との比較は私も気にならないわけではない。
でも、課金周りを見る権限は本社にしかなくて、RIも適当にやっておくから気にしなくていいと言われている。なので、お守りをしているだけの身だし、考えないことにした。
日本型企業の場合は、本社は漫然と"待ち"の姿勢になっている時があるから上申だけしとくといい。何も意見がないと「現状"大変"満足している=次の時の予算削減対象」のコンボ決められるので、言うだけ言っとくべき。外資系企業の場合は、JD次第の面はあるが給与(と責任範囲)を上げたいなら、自分が調べられる範囲でパフォーマンス調べて「なぜ気にしなくていいのか」を問う形式で尋ねてみると良い。
どちらにせよ、洋の東西問わずコストセンターからのコスト削減に繋がる提案を経営陣が聞き入れないはずがないので、一回上司に上申して上司がさらに上に対して上申しそうになければ、あなたが直接対話できる本社IT系への仕事上のパスを既に持っているはずだから、(外資の場合は特に)そっちのパスに直接ぶん投げるのが効果的。
現状の勤務環境に不満がなく、評価も気にしないのであればそっとしとくのもアリだけど、問題意識を持つこととその共有、そして解決への試行は給与アップ(昇進・転職)への一番の近道なのでせっかくなので行動してみよう。
>一時的な拡大縮小が効果的に効く分野はゲーム屋とチケット屋しか結局無かったのよ。反例をもう一つ挙げておこう。基幹システムでもなんでも、開発環境やテスト環境はIaaSで必要な時に必要なリソースで使うことでメリット出ます。
それは結局TCOで見ると本番環境のクラウド化に伴うコスト増でつぶれると思うよ。いや本番を社内サーバで開発だけクラウドという手もあるが。
クラウド化は停電対策だの回線故障だののリスクマネジメントのアウトソーシングという側面もあるので、一概にそうとは言い切れん。あと事業継続の観点からすると、機材更新も契約乗り換えで済ませられるように維持する動機づけができて楽になるという面もある。手元ハードだからってハードなりOSにごりごりされると乗り換えできなくなるからな。結局は用途次第でしかない。
これやってみるとわかるんだけど、仮想マシンで動くことが多くなった現在において結局リプレース時の負荷は変わらん。OSの入れ替えを伴わない場合は仮想マシンの移行だけで済むし(条件そろえれば無停止も可能)、OSアップグレードとなると結局スクラップ&ビルド移行と変わらんし。停電対策だの回線を含む故障対策だのは必要な場合はオンプレの時もすでにやっているはずで、手元に残るオフィス側でも要件はさほど変わらんはずなのでそこを理由に挙げるのは微妙。
また、常に高負荷で回す用途の場合は高スペックになればなるほど、がクラウドにした場合を軽く上回る金銭コストメリットがオンプレにすると出るので、その分で諸々の対策ができちゃうというのもある。CPU64コアのサーバー7年運用でざっくり台当たり1000万円以上の差が出るから、10台あればそれだけで1億円以上のほかに回すことができる。1億円あればDCやネットワーク機器普通にそろえられるからね。
オフトピだけど、スケールするって言葉をいまだに受け入れられないスケールアップするのかい?スケールダウンするのかい?どっちなんだい?ってなる
今時は自動のスケールアウトとスケールインでしょ。
クラウドの時代になればネットで情報収集してもクラウドの話題しか出てこないので自前でサーバー持つという発想も出来なくなってしまうのでしょうみんながPython使うからPythonの情報しか手に入れられなくて他の選択肢がまったく目に入らない人が多いのはなんだかなぁと思う今日このごろ#長いものに巻かれるのは概して無難で(最良ではなくても)良い選択だが、そうでないこともあることは知らなければならない
> (構築・運用のノウハウやスキルをもった人材がいない、とか言われるのかしら)公共案件で人材育成しない宣言とかしたら、まさに衰退国家って感じだ。国内でも大手ネット企業は自社プライベートクラウドを持ってるんだから政府に出来ないわけがないし。
記事の主題でもあるけど、実際に大企業中心に自前サーバーでのプライベートクラウドに回帰してるよ。SaaS以外は運用コストに対してメリットがないのに気づいた。ちなみにSIerのインフラエンジニアもある程度古い人間なら気付いてるけど、会社の方針と手離れの良さとリモートメンテのしやすさで見ないことにしてる感じ。実際「オンプレ、プライベートクラウド強いっす」じゃ、古い物に固執してると思われておちんぎんが上がらないしね…
今時のアレゲ人だとおうちクラウドも珍しく無いしね。# ストレージが足りない…
> おうちクラウド
クラウドの定義壊れる。プライベートクラウドの時点ですでにだいぶ怪しいが。
そもそもクラウドとは蜘蛛のようなどこかよくわからんところにあるよくわからんものを表現するための用語だ。ユーザからすりゃサーバの時点で雲をつかむようなよくわからないものだ。
ハードウェアにとらわれずサービスを拡縮できるのがクラウドだから、自前でハード抱えたらそれはクラウドではないと思う。
とはいえ、ハードウェアその他インフラとOpekStackを管理する部門がいて、サービス運用部署やグループ会社多数に利用してもらっている。仮想マシンより下は管理部門が責任を持ち、それより上は利用部門が責任を持つ。こういう形態ならプライベートクラウドという考え方が成り立つのではないでしょうか?
そういう風にやっているところがあるのか実態は知らないですが。
メインフレームもプライベートクラウドであると言い張れそうなのはわかったが本人がユーザーのおうちクラウドではその説明でもやっぱり無理がありすぎる
蜘蛛 → 雲
だよね。(わかるだろうけど一応、指摘)
蜘蛛の巣のようなネットワークトポロジーを想像した。
クラウドは既に概念なんでスマホからなんか便利に使えればみんなクラウド
手離れの良さとリモートメンテのしやすさ
も運用コストに含まれるはずなんだがな。そこまで見てどうするか判断だろ。気づくも何も試算すりゃ最初からわかる話なので「気づいた」ってバカすぎじゃないか。企業規模や該当システムの他にも抱えているか否かだけでもSaaSの他もメリットの有無は変わってくる。
それが流行りバズりよあとSIerから見たメリットであって、ユーザー側じゃないのがミソ。本当に適した提案をしてないって話。
世の中には過剰品質という言葉がある。過剰品質だと失敗して早期に設計を見直せたはずのロケット打ち上げがうっかり成功してしまうなどのデメリットがある。JAXAはアリアンの轍を踏まず、しっかり試験機の段階で失敗することができたので、これはもう実質成功と言っていいだろう
企業だと自前の運送会社持ってるとこ多いけど、自前で持つほうが安いのかな。不思議だけど。
扱う物品の数が多くなって倉庫が大きくなると必然的に流通がくっついてくる感じ。自前でコンテナやトラック持った方が安くなる。そしてアウトソースがこれも微妙に高く、建築並みにルールが表向きガチガチなので、B2Bだとスケールが大きくなればなるほど外注じゃ融通が効かなくなる。
「きんでん」は自動車保険をかけないことで有名。
保険は故障リスクを分散するために掛けるのであって、自社内で十分分散できるほど多数の取り扱いがあるなら、保険会社のマージン分損になるだけだと
スケールが大きくなればなるほど外注じゃ融通が効かなくなる。
そして外注に無理難題を押し通せる規模にまで成長出来れば万々歳。
それができなくなるから自社で持つのよ。IT系と違って現業系は無理を押し通すとまずもってまともなところはどこも受けてくれなくなる。下請法とかも遵守しないと手痛いしっぺ返し食らうよ。
あとは~AASの部分をどうとるかじゃないかなーと。その辺はクラウドベンダの方が有利だろうがその辺の差をどの程度コストに織り込めるかあるいは無視できるかでどっちが有利かが決まりそう。
スケールメリットと言うならAmazonやGoogleがいちばん安いはずでは?ってツッコミたくなる
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
スケールメリットだよね (スコア:1)
管理対象がある限界を越えれば自前で設備を整えて、スタッフを抱えた方が安くなることって一般的な気がする。
例えば、運送会社で小規模なところは整備工場を持ってないけど、昔の日通みたいに大規模なところだと整備工場を持っていて、壊れたトラックから部品を集めてトラックの再生までしていたと聞いたことがある。
で、クラウドといえばガバメントクラウドが、これから本格化するけど、政府や自治体のシステムを集約して載せるならデータセンターを何ヶ所か建設した方がAWSとか使うより安くなるような気がするけど、どうでしょうね。
(構築・運用のノウハウやスキルをもった人材がいない、とか言われるのかしら)
スケールの必要がないなら (スコア:3, すばらしい洞察)
「サーバーが年間通して常に26台でOK」みたいに、スケールする必用がないなら
クラウドのメリットも半減するからな。
「学習するときは百万台単位で必用だけど、それが終わったら不要になる。」
という負荷の変動が激しい分野なら、学習するときだけ時間貸しした
方が安くなるだろう。
変動が少ないし、事業も安定している企業ならメリットも少ない。
#そんなことは百も承知で利用してたんじゃないの?
Re:スケールの必要がないなら (スコア:1)
一時的な拡大縮小が効果的に効く分野はゲーム屋とチケット屋しか結局無かったのよ。
企業の常用研究用だと、常になんかしらぶん回すから結局占有プランの方の割引率に時間貸しプランが負ける。
そして、借りるぐらいなら自前で持った方が格段に安い。1年以内にで元が取れるので比較の俎上にすら上がらん。
おかげで弊社は毎年EPYCの研究開発用サーバーが増えてってる。(EPYCの前はXeonだったけど、Zen2以降のEPYCはコスパとワッパが段違い)
Re: (スコア:0)
一文目についてだけ、一応もうちょい適用対象はあると言いたい。私のところ、B2Bのシステムで平日日中だけ台数を増やすスケーリングルールをAWS EC2でやっている。そこまで効果的かというと微妙かもしれないけど。
AWSを使うのは自分が入る前から親会社の方針みたいで、そこの理由はよく知らない。
Re: (スコア:0)
それ定常的やってるのなら、パフォーマンス分析するとわざわざ増減とかせずにリザーブ化して割引分で常時増やしっぱなしにした方が管理コスト含めお得になりそうな気がする。一度分析してみては。
Re: (スコア:0)
そうそう。全部リザーブドインスタンスで常時稼働させる場合との比較は私も気にならないわけではない。
でも、課金周りを見る権限は本社にしかなくて、RIも適当にやっておくから気にしなくていいと言われている。なので、お守りをしているだけの身だし、考えないことにした。
Re: (スコア:0)
日本型企業の場合は、本社は漫然と"待ち"の姿勢になっている時があるから上申だけしとくといい。何も意見がないと「現状"大変"満足している=次の時の予算削減対象」のコンボ決められるので、言うだけ言っとくべき。
外資系企業の場合は、JD次第の面はあるが給与(と責任範囲)を上げたいなら、自分が調べられる範囲でパフォーマンス調べて「なぜ気にしなくていいのか」を問う形式で尋ねてみると良い。
どちらにせよ、洋の東西問わずコストセンターからのコスト削減に繋がる提案を経営陣が聞き入れないはずがないので、一回上司に上申して上司がさらに上に対して上申しそうになければ、あなたが直接対話できる本社IT系への仕事上のパスを既に持っているはずだから、(外資の場合は特に)そっちのパスに直接ぶん投げるのが効果的。
現状の勤務環境に不満がなく、評価も気にしないのであればそっとしとくのもアリだけど、問題意識を持つこととその共有、そして解決への試行は給与アップ(昇進・転職)への一番の近道なのでせっかくなので行動してみよう。
Re: (スコア:0)
>一時的な拡大縮小が効果的に効く分野はゲーム屋とチケット屋しか結局無かったのよ。
反例をもう一つ挙げておこう。
基幹システムでもなんでも、開発環境やテスト環境はIaaSで必要な時に必要なリソースで使うことでメリット出ます。
Re: (スコア:0)
それは結局TCOで見ると本番環境のクラウド化に伴うコスト増でつぶれると思うよ。
いや本番を社内サーバで開発だけクラウドという手もあるが。
Re: (スコア:0)
クラウド化は停電対策だの回線故障だののリスクマネジメントのアウトソーシング
という側面もあるので、一概にそうとは言い切れん。
あと事業継続の観点からすると、機材更新も契約乗り換えで済ませられるように
維持する動機づけができて楽になるという面もある。手元ハードだからってハードなり
OSにごりごりされると乗り換えできなくなるからな。
結局は用途次第でしかない。
Re: (スコア:0)
これやってみるとわかるんだけど、仮想マシンで動くことが多くなった現在において結局リプレース時の負荷は変わらん。
OSの入れ替えを伴わない場合は仮想マシンの移行だけで済むし(条件そろえれば無停止も可能)、OSアップグレードとなると結局スクラップ&ビルド移行と変わらんし。
停電対策だの回線を含む故障対策だのは必要な場合はオンプレの時もすでにやっているはずで、手元に残るオフィス側でも要件はさほど変わらんはずなのでそこを理由に挙げるのは微妙。
また、常に高負荷で回す用途の場合は高スペックになればなるほど、がクラウドにした場合を軽く上回る金銭コストメリットがオンプレにすると出るので、その分で諸々の対策ができちゃうというのもある。CPU64コアのサーバー7年運用でざっくり台当たり1000万円以上の差が出るから、10台あればそれだけで1億円以上のほかに回すことができる。1億円あればDCやネットワーク機器普通にそろえられるからね。
Re: (スコア:0)
オフトピだけど、スケールするって言葉をいまだに受け入れられない
スケールアップするのかい?スケールダウンするのかい?どっちなんだい?ってなる
Re: (スコア:0)
今時は自動のスケールアウトとスケールインでしょ。
Re:スケールメリットだよね (スコア:1)
クラウドの時代になればネットで情報収集してもクラウドの話題しか出てこないので自前でサーバー持つという発想も出来なくなってしまうのでしょう
みんながPython使うからPythonの情報しか手に入れられなくて他の選択肢がまったく目に入らない人が多いのはなんだかなぁと思う今日このごろ
#長いものに巻かれるのは概して無難で(最良ではなくても)良い選択だが、そうでないこともあることは知らなければならない
Re: (スコア:0)
> (構築・運用のノウハウやスキルをもった人材がいない、とか言われるのかしら)
公共案件で人材育成しない宣言とかしたら、まさに衰退国家って感じだ。
国内でも大手ネット企業は自社プライベートクラウドを持ってるんだから政府に出来ないわけがないし。
Re: (スコア:0)
記事の主題でもあるけど、実際に大企業中心に自前サーバーでのプライベートクラウドに回帰してるよ。
SaaS以外は運用コストに対してメリットがないのに気づいた。
ちなみにSIerのインフラエンジニアもある程度古い人間なら気付いてるけど、会社の方針と手離れの良さとリモートメンテのしやすさで見ないことにしてる感じ。
実際「オンプレ、プライベートクラウド強いっす」じゃ、古い物に固執してると思われておちんぎんが上がらないしね…
Re:スケールメリットだよね (スコア:1)
今時のアレゲ人だとおうちクラウドも珍しく無いしね。
# ストレージが足りない…
Re: (スコア:0)
> おうちクラウド
クラウドの定義壊れる。プライベートクラウドの時点ですでにだいぶ怪しいが。
Re: (スコア:0)
そもそもクラウドとは蜘蛛のようなどこかよくわからんところにあるよくわからんものを表現するための用語だ。
ユーザからすりゃサーバの時点で雲をつかむようなよくわからないものだ。
Re:スケールメリットだよね (スコア:1)
ハードウェアにとらわれずサービスを拡縮できるのがクラウドだから、自前でハード抱えたらそれはクラウドではないと思う。
Re: (スコア:0)
とはいえ、ハードウェアその他インフラとOpekStackを管理する部門がいて、サービス運用部署やグループ会社多数に利用してもらっている。仮想マシンより下は管理部門が責任を持ち、それより上は利用部門が責任を持つ。こういう形態ならプライベートクラウドという考え方が成り立つのではないでしょうか?
そういう風にやっているところがあるのか実態は知らないですが。
Re: (スコア:0)
メインフレームもプライベートクラウドであると言い張れそうなのはわかったが本人がユーザーのおうちクラウドではその説明でもやっぱり無理がありすぎる
Re: (スコア:0)
蜘蛛 → 雲
だよね。(わかるだろうけど一応、指摘)
Re: (スコア:0)
蜘蛛の巣のようなネットワークトポロジーを想像した。
Re: (スコア:0)
クラウドは既に概念なんで
スマホからなんか便利に使えればみんなクラウド
Re: (スコア:0)
手離れの良さとリモートメンテのしやすさ
も運用コストに含まれるはずなんだがな。
そこまで見てどうするか判断だろ。
気づくも何も試算すりゃ最初からわかる話なので「気づいた」ってバカすぎじゃないか。
企業規模や該当システムの他にも抱えているか否かだけでもSaaSの他もメリットの有無は変わってくる。
Re: (スコア:0)
それが流行りバズりよ
あとSIerから見たメリットであって、ユーザー側じゃないのがミソ。
本当に適した提案をしてないって話。
Re: (スコア:0)
世の中には過剰品質という言葉がある。過剰品質だと失敗して早期に設計を見直せたはずのロケット打ち上げがうっかり成功してしまうなどのデメリットがある。JAXAはアリアンの轍を踏まず、しっかり試験機の段階で失敗することができたので、これはもう実質成功と言っていいだろう
Re: (スコア:0)
企業だと自前の運送会社持ってるとこ多いけど、自前で持つほうが安いのかな。不思議だけど。
Re:スケールメリットだよね (スコア:1)
扱う物品の数が多くなって倉庫が大きくなると必然的に流通がくっついてくる感じ。
自前でコンテナやトラック持った方が安くなる。
そしてアウトソースがこれも微妙に高く、建築並みにルールが表向きガチガチなので、B2Bだとスケールが大きくなればなるほど外注じゃ融通が効かなくなる。
Re: (スコア:0)
「きんでん」は自動車保険をかけないことで有名。
Re: (スコア:0)
保険は故障リスクを分散するために掛けるのであって、自社内で十分分散できるほど多数の取り扱いがあるなら、保険会社のマージン分損になるだけだと
Re: (スコア:0)
スケールが大きくなればなるほど外注じゃ融通が効かなくなる。
そして外注に無理難題を押し通せる規模にまで成長出来れば万々歳。
Re: (スコア:0)
それができなくなるから自社で持つのよ。IT系と違って現業系は無理を押し通すとまずもってまともなところはどこも受けてくれなくなる。
下請法とかも遵守しないと手痛いしっぺ返し食らうよ。
Re: (スコア:0)
あとは~AASの部分をどうとるかじゃないかなーと。
その辺はクラウドベンダの方が有利だろうがその辺の差をどの程度コストに織り込めるかあるいは無視できるかでどっちが有利かが決まりそう。
Re: (スコア:0)
スケールメリットと言うなら
AmazonやGoogleがいちばん安いはずでは?ってツッコミたくなる