アカウント名:
パスワード:
管理対象がある限界を越えれば自前で設備を整えて、スタッフを抱えた方が安くなることって一般的な気がする。 例えば、運送会社で小規模なところは整備工場を持ってないけど、昔の日通みたいに大規模なところだと整備工場を持っていて、壊れたトラックから部品を集めてトラックの再生までしていたと聞いたことがある。 で、クラウドといえばガバメントクラウドが、これから本格化するけど、政府や自治体のシステムを集約して載せるならデータセンターを何ヶ所か建設した方が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やネットワーク機器普通にそろえられるからね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
スケールメリットだよね (スコア: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やネットワーク機器普通にそろえられるからね。