アカウント名:
パスワード:
管理対象がある限界を越えれば自前で設備を整えて、スタッフを抱えた方が安くなることって一般的な気がする。 例えば、運送会社で小規模なところは整備工場を持ってないけど、昔の日通みたいに大規模なところだと整備工場を持っていて、壊れたトラックから部品を集めてトラックの再生までしていたと聞いたことがある。 で、クラウドといえばガバメントクラウドが、これから本格化するけど、政府や自治体のシステムを集約して載せるならデータセンターを何ヶ所か建設した方がAWSとか使うより安くなるような気がするけど、どうでしょうね。（構築・運用のノウハウやスキルをもった人材がいない、とか言われるのかしら）
「サーバーが年間通して常に26台でOK」みたいに、スケールする必用がないならクラウドのメリットも半減するからな。
「学習するときは百万台単位で必用だけど、それが終わったら不要になる。」という負荷の変動が激しい分野なら、学習するときだけ時間貸しした方が安くなるだろう。
変動が少ないし、事業も安定している企業ならメリットも少ない。＃そんなことは百も承知で利用してたんじゃないの？
一時的な拡大縮小が効果的に効く分野はゲーム屋とチケット屋しか結局無かったのよ。企業の常用研究用だと、常になんかしらぶん回すから結局占有プランの方の割引率に時間貸しプランが負ける。そして、借りるぐらいなら自前で持った方が格段に安い。1年以内にで元が取れるので比較の俎上にすら上がらん。
おかげで弊社は毎年EPYCの研究開発用サーバーが増えてってる。(EPYCの前はXeonだったけど、Zen2以降のEPYCはコスパとワッパが段違い)
一文目についてだけ、一応もうちょい適用対象はあると言いたい。私のところ、B2Bのシステムで平日日中だけ台数を増やすスケーリングルールをAWS EC2でやっている。そこまで効果的かというと微妙かもしれないけど。
AWSを使うのは自分が入る前から親会社の方針みたいで、そこの理由はよく知らない。
それ定常的やってるのなら、パフォーマンス分析するとわざわざ増減とかせずにリザーブ化して割引分で常時増やしっぱなしにした方が管理コスト含めお得になりそうな気がする。一度分析してみては。
そうそう。全部リザーブドインスタンスで常時稼働させる場合との比較は私も気にならないわけではない。
でも、課金周りを見る権限は本社にしかなくて、RIも適当にやっておくから気にしなくていいと言われている。なので、お守りをしているだけの身だし、考えないことにした。
日本型企業の場合は、本社は漫然と"待ち"の姿勢になっている時があるから上申だけしとくといい。何も意見がないと「現状"大変"満足している=次の時の予算削減対象」のコンボ決められるので、言うだけ言っとくべき。外資系企業の場合は、JD次第の面はあるが給与(と責任範囲)を上げたいなら、自分が調べられる範囲でパフォーマンス調べて「なぜ気にしなくていいのか」を問う形式で尋ねてみると良い。
どちらにせよ、洋の東西問わずコストセンターからのコスト削減に繋がる提案を経営陣が聞き入れないはずがないので、一回上司に上申して上司がさらに上に対して上申しそうになければ、あなたが直接対話できる本社IT系への仕事上のパスを既に持っているはずだから、(外資の場合は特に)そっちのパスに直接ぶん投げるのが効果的。
現状の勤務環境に不満がなく、評価も気にしないのであればそっとしとくのもアリだけど、問題意識を持つこととその共有、そして解決への試行は給与アップ(昇進・転職)への一番の近道なのでせっかくなので行動してみよう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
スケールメリットだよね (スコア: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系への仕事上のパスを既に持っているはずだから、(外資の場合は特に)そっちのパスに直接ぶん投げるのが効果的。
現状の勤務環境に不満がなく、評価も気にしないのであればそっとしとくのもアリだけど、問題意識を持つこととその共有、そして解決への試行は給与アップ(昇進・転職)への一番の近道なのでせっかくなので行動してみよう。