  |
はてなキーワード: IaaSとは
■周囲のパルワールド熱
Steamのフレにパルワールド買った人が何人かいるけど、かれらのプレイ時間は異常。
先週の連休もすごかった。
3日目はさすがにダウンして夕方くらいまで寝ていたようだけど、
本当に1週間で何時間寝ているのやら。
30代以上の「ゲームに熱中しづらくなった年代」の人もいるはずなのだが、
いつ見ても深夜までプレイしている。
（こちらは〆切間近の案件で深夜まで納品の準備をしているというのに）
やることがなくなってしまったらしい。
見事にプレイ仲間を見つけたのは良いが、
※サーバを借りてそこにゲームサーバを立てる（IaaSのように）というのではなく、
ゲーム用サーバをマーケットのようなところでレンタル契約できるらしい（SaaSのように）
「プレイヤー数が急降下」の話だが、彼のようにゲーム内でやれることがなくなった
というプレイヤーの話はよく聞くので、そりゃそうだろうな、と感じる。
前述のゲームマニアの彼のように一緒にプレイする人を見つけたら、
仲間を巻き込んで、再燃してしまうんだろうなぁ、とも感じる。
■蛇足
私も……と思うが、仕事のことがちらついて中々難しい。
■件の記事
完全に独立した技術スタックになりつつある、しかし出来る人間が非常に少なく胡散臭い優秀なフリをしたエンジニアが数多くいるように見える。
さらにとっつきやすさから新人も参入しやすくカオスな雰囲気を感じる、自分の周囲を見た感じでも技術スキルは低めの傾向が見える。
トンカチを持ってそれを振りかざすことを目的にしちゃってるような人間が多いように見えるし、そうでない人間はそもそも技術へのキャッチアップが低い傾向にある。
昔からそんなに変化がない、AWSやGCPの運用や設計もやることがある。
WEBアプリケーションのフレームワークが無いと仕事できない、とにかくDBが大事でプログラミング能力はフレームワークの使い方に寄っている。
DBが大事なのでプログラミングスクールだろうが独学だろうが、勘所を掴むのは困難で実務ありきで成長する必要がある。
大量のトラフィックを扱う人は分散のための設計なども心得ているものの、大抵は場当たり的な対処しかしていない。
IaaS登場以前は空気が乾燥した寒い部屋で黒い画面相手に定形作業をしていることが多かった。
昨今SREと呼ばれるようになり地位が向上しつつあるが、業務内容も広がってきておりIaaSの設計能力が大きく問われるようになってきた。
WEBフロントエンドほどではないが、仮想OS、IaaS、コンテナなどそこそこのテンポで技術が進歩している。
この他にも過去の名残だったりIaaSを触る都合、社内SE的な仕事もしたりする、相変わらず深夜対応もある、辛い…
年１回、必ず新機能が出てくるので定期的に技術をキャッチアップ出来る必要がある。
国内に限定すると技術スキルは高めの人が多い傾向が見えるが人間としては癖の強い人が多い傾向も見える。
（ちなみに少ない観測範囲だが海外勢は微妙な技術レベルの人間が多かった。）
給与レンジはピンのほうはそんなに高くないがキリのほうはそこまで低くない。
ここ20年ぐらいで台頭してきたITエンジニアとは別種の雰囲気を持つ印象、詳しいことは分からない。
技術力はあまり重視されない、コミュニケーション能力や簿記などの会計知識が重要視される。
給料は低め。
---
WEBフロント、バックエンド、SRE、アプリあたりは幾つか交差する領域がある。
交差するキャリアを取っている人はどれも凄い人かどれも微妙な人に二分される傾向が見える。
なんか病名があるのかもしれんが、おれは集中したまま一瞬で意識が飛ぶ。
3問目、これは難しいな、ドラえもんかのび太か・・・ドラえもん？
って感じで、ハッと気づくと意識飛んでる。
寝不足で夜中とかなら誰でもあるだろうけど、俺の場合は多少疲れている程度の状態でも昼間にそうなる。
これがあるせいで、運転とか怖くてできない。一度クルマ持ってたけど、運転中にガクっとなって怖すぎるから手放した。あのタイミングで事故らなかったのは単に運だ。目を開けたまま意識が目の前を見なくなる。
最初からこうなのではなく、大学院のころ、論文の追い込みで眠気を栄養ドリンクなんかで無理やり圧殺するのを繰り返したせいだと思う。
眠気に勝てるようになった代わりに、眠気に勝ったまま意識が吹っ飛ぶようになった。
無理はするもんじゃねーな。
2014年の出来事だが、自殺の方法に関するロシア語の文章がGithub上にアップロードされたことにより、ロシアの規制当局が、ロシアからGithubへのアクセスをブロックする命令を出した。
https://ascii.jp/elem/000/000/959/959163/
https://jp.techcrunch.com/2014/12/04/20141203github-russia/
これは経済的損失が大きいと考えられる。
その文章のリンクは（内容的に不適切なので）ここには貼らないが、上の記事の中にリンクがあるので、気になる人は自己責任で翻訳してほしい。
私は機械翻訳したが、正直なぜこの文章がロシアにとってNGなのかわからない。恐らくロシア国民には分かる皮肉が入っているのだろうと思う。
この文章を他のサービスに貼り、ロシア当局がブロック命令を出すことで、制裁につながらないだろうか。
AWSにほぼ0円でデプロイするスクリプトを作ろうかと思ったが、そもそもロシアはAWS使えないようだった。
http://yamamototaku.jp/article/20210921/
山本議員の「元妻を守るために」という物言いが（「離別した夫にも擁護されるなんて、やっぱり高市さんは人格的に素晴らしいんですね！」みたいな感じで）高市支持者に大ウケ。さらに自民支持者右派だけじゃなく、河野太郎や小泉進次郞を叩きたいやつら、再エネを批判したいやつらにも大人気になっている。バズりまくりだ。よかったよかった。
IT関連消費電力は2050年には2016年の41TWh/年の約4,000倍の176,200 TWh/年になるとの予測が、国立研究開発法人科学技術振興機構の低炭素社会戦略センターによって発表されています。
現在よりも省エネルギーの進展があったとしても、IT 関連消費電力は莫大に膨れ上がることが予想されます。2050 年にそれらを再生可能エネルギーでまかなうための具体的計画を、環境大臣としてお示しください。
これ読んで、増田諸氏はどう感じるだろうか。少なからぬ増田が「『176,200TWh/年』というのがどれぐらいかわからないけど、ITの進展で電力需要がすごい増えるんだな、それは再エネだけじゃ到底まかなえないんだろうな、小泉進次郎はそういう現実的想定をしないで、夢みたいな再エネ推進を言ってやがるんだな」と思うんじゃなかろうか。でも、そうじゃない。
「176,200TWh/年」というのは、今の日本全体の年間発電電力量の180倍、世界全体の発電電力量の7倍だ。そんなもん再エネどころか原発だろうが火発だろうが絶対充当できるわけがない。もし小泉進次郎や環境省から「なるほど、再生可能エネルギーでまかなうことが不可能だというなら、2050年にそれらを原子力や化石燃料エネルギーでまかなうための具体的計画を、対案としてお示しください」と反論されたら一発で撃沈だ。なんなんだこの数字？ というわけで引用元のPDFを読む。vol.1からvol.3まである。
https://www.jst.go.jp/lcs/pdf/fy2018-pp-15.pdf
情報化社会の進展に伴って、従来の予想を超える膨大なデータが取り扱われるようになり、この傾向は今後も拡大すると考えられる。これに伴い、エネルギー消費がどのような影響を受けるかを 2050 年までを視野に入れ、調査、ヒアリングなどにより検討した。その結果、世界の情報量（IP トラフィック）は 2030 年には現在の 30 倍以上、2050 年には 4,000 倍に達すると予想され、現在の技術のまま、まったく省エネルギー対策がなされないと仮定すると、情報関連だけで 2030年には年間 42PWh、2050 年には 5,000PWh と、現在の世界の消費電力の約 24PWh を大きく上回る予測となった。すなわち、技術進歩がなければ情報関連だけで世界の全てのエネルギーを消費してもまだ不足するという事態になりうる。
現在日本の年間の電力消費量が約 980TWhであるから、現在の技術でまったく省エネルギー対策がなされないと仮定すると、2030年には年間使用電力量の倍近い電力を IT 関連機器だけで消費する予測となる。世界についても、現在の世界の消費電力が約 24,000TWh であるから、やはり現在の2倍程度の電力を IT 関連機器が消費する予測となる。また、2050 年の電力消費量は、現在と比較して日本、世界ともに約200倍という極端な数字となり、情報関連だけで全てのエネルギーを消費してもまだ不足するという状況になりうる。この情報量の爆発に対しての対策が必要なことは明らかである。
つまり「もし現時点から全く技術の進展がなければ、将来はIT関連機器だけで世界中のエネルギーを全部食い潰しちゃうぞ〜」という、極端なシナリオにもとづく極端な数字なのだ。そして、Vol.1（IT関連機器編）、Vol.2（データセンター編）、Vol.3（ネットワーク編）と分野別に分けて、こうした消費電力増大の問題を技術進歩でどう抑えていくか、という議論がされている。IT中心に増大するエネルギー需要に対して、どういうエネルギーミックスで応需していくか、みたいな話は全くしていないし、それどころか低炭素エネルギーへの流れが世界的に進んでいるから「電力供給が大幅に増大することは期待しがたい」とはっきり言っている。電力供給の増大に期待できないということは話の前提で、その中でのやりくりについて書いているのだ。
－データセンター消費エネルギーの現状と将来予測および技術的課題－
https://www.jst.go.jp/lcs/pdf/fy2020-pp-03.pdf
データセンターは IaaS、SaaS、MaaS などの新たなクラウドサービスの進展に伴い今後も膨大な計算負荷が発生すると考えられる。また全世界的な COVID-19 の蔓延にともなう仕事や学習形態のリモート化はそれに拍車をかけるものと思われる。さらに医療画像診断やセキュリティの顔認識なども膨大な計算量の発生が予測される。
これらの状況を考えると従来以上にデータセンターにおける計算負荷が上昇しそうである。一方で、供給電力には限りがある。また、現在世界中で急速に低炭素エネルギーに向けてエネルギーポートフォリオの見直しが進められていて、供給電力の大幅な増大は期待しがたい。
低炭素社会へ歩を進めつつ、社会に必要とされているサービスを提供するためにはデータセンターの省エネルギー化を進める必要がある。本提案書では 2030、2050 年も見据えて現状技術で固定された場合の電力需要を計算した。
（ちなみに具体的提案はCPU、GPUを中心とした要素部品類の集積度向上、液浸、ヒートポンプなどの冷却方法の工夫、必要なとき以外は動作しない（スマート化）…などなどの提案で、それに対する研究支援をせよ、と言っている。割と普通だね）
この提案書の報告主体は「国立研究開発法人科学技術振興機構 低炭素社会戦略センター」なんだけど、ようするにこの提案書は、山本拓議員の引用している文脈とは真逆の論旨のことを言ってるのだ。「これだけ電力が足りなくなるから、再エネを推進してはダメだ」ではなく、「技術に進歩がなければこんな非現実的なシナリオになってしまうから、それを避けるために、IT分野全体で電力消費を減らす努力と研究支援をしよう」という内容なのである。
山本氏議員公開質問ではこういう文脈を無視して、一部の記述を都合よく切り取って、意図的に「再エネではこの電力需要を賄えない、再エネを推進しない現実的な計画を立てるべきだ（立てることが可能だ）」みたいな誤解を招く表現をしてるように見えて、大変よろしくない。山本議員はエネルギー通だそうだから、「176,200TWh/年」という数字が全く非現実的な想定であることは本人も理解しているはずだ。そもそも公開質問では、この数字を引用した部分のすぐ上に
という記述もあるのだ。約 4,814 億 kWh/年 = 481400000000 kWh/年 = 481 TWh/年 である。東日本大震災以後、国内発電量の70%以上を担う火発を全部ひっくるめても480TWhでしかないことを山本議員は承知していながら、その直後には「IT 関連消費電力は 2050 年には （略）176,200 TWh/年になるとの予測が、国立研究開発法人科学技術振興機構の低炭素社会戦略センターによって発表されています」「現在よりも省エネルギーの進展があったとしても、IT 関連消費電力は莫大に膨れ上がることが予想されます。2050 年にそれらを再生可能エネルギーでまかなうための具体的計画を、環境大臣としてお示しください」という書き方をしている。こういうのは誠実な議論ではない。
https://tech.nikkeibp.co.jp/atcl/nxt/news/18/05452/
この記事の真偽はともかくとして、反応を見てると AWS のマーケティング戦略に見事にはまった信者の人たちが冷静な見解が出来なくなって炙り出されてきているのが面白い。
AWS にもO365と同じ様な SaaS サービスあるだろうに、シェアが低すぎて普段見えてない分意識できてないんだろう。
そもそもIaaSとかSaaSを意識せずにクラウドを使える様にする、というのは AWS の根本の思想じゃなかったっけ。
コンピュータのマシン語は命令文もデータも数値で表す。これは今も昔も同じ。
数値だけでは人間が管理しづらいので命令文を mov や add のようなわかり易い単語に置き換えたのがアセンブラ。
複数の処理をひとまとめで扱うサブルーチン・関数・プロシージャ・ファンクションと
いったものができた。
（カプセル化）
アプリケーションからOSの機能を呼ぶシステムコール・APIが生まれた
（ブラックボックス化）
複数のクラスやコード、データをひとまとめにするにモジュールができた。
（カプセル化）
プログラムを外部から操作するRPC、CORBA、SOAP、RMIができた。
IaaS / SaaS / PaaS を使いネット上のサービスにつないでシステムを構築する。サーバ管理不要に。
（ブラックボックス化）
（操作の簡略化）
Docker でWEB/DB/KVSなどをまとめてコマンド１つで扱えるようになった。
強いSEならIaaSの扱い方からオブジェクト指向言語やjavascriptまで一通り知ってなきゃだろうし
エンジニア立ち居振舞い: 技術的な暴力を振るわない - futoase
http://futoase.hatenablog.com/entry/2016/11/19/155427
例示されている暴力はだいたい頭の悪い暴力なので反論できます。
では今あるシステム全部PHPでリプレイスするとして、○人月の工数が必要ですがそのような予算はありません。
Go言語そのものの表現力が低い。そんなものを利用するならJava、Scalaで書くべきだ。ライブラリが豊富にあるだろう。Googleに縛られた環境での開発は恐ろしい。
ところでどうしてWindowsPCを開いてExcelで文書作ってるのか教えてください。
Serverlessそのものはサーバがなくなるわけではない。自身でチューニングなど細かなリソース管理ができないPaaSを使って自身のサービスの命運を預けるなんて馬鹿げている。
理屈の上ではオンプレミスやIaaSの方が細かな管理できるかもしれませんが、サーバ管理にそこまでコストかけるつもりが無いのに適当なこと言わないでください。
iOSアプリそのもの、プラットフォームがいつまであるかもわからないし、今後広がるかわからない。Objective Cを覚えたり、そんなものに技術をかけてどうするのか。
Nintendo Switchが大流行するかわからない。コントローラー使いづらいし。あんなものはチンケなものだ。そもそもUnityをインフラエンジニアが覚えて意味があるのか。
流行前は流行らないと言い、流行った後は将来性が無いと言う、じゃあ一生何も始めないつもりですか？
でも安心してください。すべてはUnityが解決してくれます。そう、Unityならね。
例示された人たちに暴力ふるいたい。
windowsとmacとフロントエンドとインフラと組み込みいう線引きからはみ出してはいけないと思うな。むしろ全部やれ全部だ！誰もお前がカバーしてない部分をサポートなんぞしねえからな！
ECサイト作りたい人 → ヤフオクでやれ(CMSを使うことの大切さ）
iosアプリ作りたいwindows開発者 → くだらないことにこだわってないでmacとiphone買え(ios開発は何もかもmacとxcodeが大前提）
フロントエンドプログラマがgo → goだけ使われても微妙。当然DBとの連携もあるんだよな？ん？(サーバサイドスクリプトはDB連携のためにあるようなもの）
サーバレスに興味あり組み込みエンジニア → どうでもいいからさっさと作れ。そこ悩むとこじゃねーから！(悩むなら一度サーバ立ち上げから自分でやってみてイメージをつかんだ方がいいかも）
NintendoとUnityとインフラエンジニア → やればいいと思うがハードルが高すぎて頓挫する可能性が高い。まずはUnityのエディタ上で動くくらいを目標にすべきだ。
まずIaaS基盤ではない、PaaS実装のためについでで実装されてるだけ
PaaS基盤展開にARMを使うのでそのためにIaaS機能も開放されているにすぎない。
・PaaSメインで使いたい
→ Azure Pack (似たような事はできるけど今後の機能拡張があまり期待できない)
・IaaSメインで使いたい
→ Azure Stack (まちがい)
少なくともWindows Server 2016で実装される各種機能使いたいならAzure Stackは現状無理なので諦めましょう。
Azure のPaaS系機能を使いたいと思うならAzure Stack一択、現状実装されてなくても今後の拡張で実装される可能性は高い。
そもそも的な話すると今後発表されるというCPS的HWじゃないと正式リリース版はサポートされないという事なので、新規HW購入必須です。
あー、どうなんだろう。
なにげに、Virtual CPUって 1GHz前後のCPU能力のことでしょ・・・結構 以外に 貧弱なんだよね。
瞬間最大風速が単一障害点に かかるものこそ、むしろ 実マシンって気はする。仮想化は瞬間最大風速には弱い。
一旦服装はいると 戻ってくるのが遅い。
スタティックなファイルの大量配布にかなり近い程度の負荷なら まぁ、って気もするが。
ぶっちゃけ、そんな大規模だったら、 DCにラック 借りても人件費まで考えても ペイするやろって感じ。
もう、いまどき、ラックマウントサーバーなんて かなり安い。（※ 風圧設計からして DCに 通常PC入れるのは ナンセンスとして ラックマウント入れても もう 大した額じゃない）
※ 急にハイエンドがほしい！ ＞ それこそ 短時間 EC2でしのいで、 ラックマウント増設 でいいと思う。
http://anond.hatelabo.jp/20100518115813
それは一般的にASP（≒SaaS）とかPaaSとかIaaSとか呼ばれるサービス形態で、クラウドの説明としてはちょっと違います。
だけど、クラウドコンピューティングの代表格としてそういう「ネット上の超強力コンピュータを使いたいときだけちょっと貸してもらうサービス」が流行しているので、たしかにそう思えなくもない。
多義的な感じになってしまった「クラウド」を理解するために、ルーツから追ってみましょう。
まず最初に、インターネットは2点間の通信をするための道具であることを思い起こしましょう。国際電話網と同じです。A地点から、B地点を指定して通信するもの。
Webサイトでサービスを受けるときには、ドメイン名をかぶせたURLを使うので実際のIPアドレスは意識しませんが、それでもA-B間の通信であるのは基本でした。
しかしGoogleだAmazonだといった超大規模サービスになると、もうどれだけ強力なサーバにどれだけ太い回線でもリクエストを裁ききれるわけありません。世界中にサーバを置き、同じ「google.com」でもたくさんある中の最寄りのサーバに導かれてそこでリクエスト受け付けてもらうのが当たり前になります。
すると、「google.comサーバと通信する」という意味は薄れます。どれでもいいからgoogle.comの用意しているサーバに要求を処理してもらう……どういう構成かは知らないけどgoogle.comというサービスに要求を処理してもらう、と言う状態になります。
こうなるともはやA-B地点の通信の意味はなくなり、A-（構成はよくわからない分散したサービス）という関係になりました。この「（構成はよくわからない分散したサービス）」が「雲（クラウド）」です。
その後、GoogleもAmazonも、自社で構築した分散サーバ群を外部に提供し始めました。これを利用すれば誰でも、世界中に分散したサーバでクラウドなWebアプリケーションを提供できるようになります。
GAEもAWSも、「クラウドなWebアプリケーションを実現するサーバ群を利用させてくれるサービス」で、これを極端に略して「クラウド」などと呼ぶことがあります（ニフティクラウドとか）。でもこれらサーバの時間貸しは最初に書いたとおり、あくまでIaaSやPaaSであるわけです。
