  |
はてなキーワード: Iaasとは
計算機科学は、情報の理論的基盤から実用的な応用まで、広範な領域をカバーする学問です。以下に、計算機科学の主要な分野と、特にネットワークに関連するトピックを体系的にまとめます。
プログラミングパラダイム: 手続き型、オブジェクト指向、関数型、論理型など。
プロセス管理: CPUのスケジューリングとマルチタスキング。
機械学習アルゴリズム: 教師あり学習、教師なし学習、強化学習。
深層学習: ニューラルネットワークによる高度なパターン認識。
ネットワークは、情報の共有と通信を可能にする計算機科学の核心的な分野です。
OSI参照モデル: ネットワーク通信を7つのレイヤーに分割し、それぞれの機能を定義。
プレゼンテーション層: データ形式の変換。
アプリケーション層: ユーザーアプリケーションが使用するプロトコル。
TCP/IPモデル: 現実のインターネットで使用される4層モデル。
リング型: 各ノードが一方向または双方向に隣接ノードと接続。
IP（Internet Protocol）: データのパケット化とアドレッシング。
TCP（Transmission Control Protocol）: 信頼性のある通信を提供。
UDP（User Datagram Protocol）: 信頼性よりも速度を重視した通信。
ルーター: 異なるネットワーク間のパケット転送とルーティング。
IDS/IPS（侵入検知/防止システム）: ネットワーク攻撃の検出と防御。
VPN（仮想プライベートネットワーク）: 安全なリモートアクセスを提供。
SDN（Software-Defined Networking）: ネットワークの柔軟な管理と制御。
IoTプロトコル: MQTT、CoAPなどの軽量プロトコル。
SNMP（Simple Network Management Protocol）: ネットワークデバイスの管理。
ネットワークトラフィック分析: パフォーマンスとセキュリティの最適化。
ネットワークオーケストレーション: 自動化された設定と管理。
AIによるトラフィック最適化: パフォーマンスの向上と障害予測。
マイクロセグメンテーション: ネットワーク内部の細かなアクセス制御。
『コンピュータネットワーク』 アンドリュー・S・タネンバウム著
『ネットワークはなぜつながるのか』 戸根勤著
Coursera: 「コンピュータネットワーク」、「ネットワークセキュリティ」コース
edX: 「Computer Networking」、「Cybersecurity Fundamentals」
IETF（Internet Engineering Task Force）: ietf.org
IEEE Communications Society: comsoc.org
W3C（World Wide Web Consortium）: w3.org
私はプロではないのでわからないので、間違っているのは当たり前だと思って読んでください。
個々人のエンジニアの能力がとかクレジットカードがとかは基本関係ないという話です。
（関係なくてもパスワードを使い回している場合は、同じパスワードを使っているサービスのパスワードはすぐ変えるの推奨）
私は長年社内システムの奴隷をやって参りました。現在のクラウドになる前のサーバも触って参りましたので、その辺りからお話しをさせてください。
サーバーというのは、簡単に言うとシステムを提供しているコンピュータです。
貴方が触っているコンピュータシステムのネットワークの向こう側にいます。この増田も増田のサーバーというのがいて、私たちにサービスを提供してくれています。
しかし、このサーバ、どんなイメージを持っていますか？ でっかい黒い冷蔵庫？ちかちか光るロッカー？ それともバーチャルのネットワークで画面上に写されるものでしょうか。
サーバーといっても、実４形態ぐらいあるのです。私もチョットワカルぐらいなので間違っていると思いますが、まずは理解する為に簡単に説明させてください。
と言う段階があります。
ニコニコ動画のサービスはどうかというと、色々な情報を得ると、④を使いながら③にする途中で、まだ②が残っている、ということのようですね。
これらの使い分けについてですが、最近は自社でサーバを持っていると自分たちで管理しなければならなかったりして大変なので、できるだけ②から③、できたら④に持っていきたいと言うのが世の中の流れです。それでも②はのこりますが、最小限にしていく方向。
現在は、②のシステムがだけがやられたように、セキュリティ的にも預けた方が望ましいと言われています。
今回も、自社で管理している部分が攻撃されました。特にクレジットカード情報が漏れていないと何度も言われているのは、そこを自社で管理せずに専門業者に任せていたことが大きいわけです。
この流れをまずは頭に入れましょう。
さて、メールを扱ってるサーバーと、売れた商品をバーコードでピッとして管理するシステムは全く別でどちらかがハッキングされたからといってもう一つもされるこことはありません。これは何故かと言うと、それぞれを細かくたくさんのシステムや仮想サーバに別けた独立なシステムになっているからです。
さらにKADOKAWAのようにサービスを外部に展開してる会社の場合、外部向けのシステムと内部向けのもの（バックオフィス）で必要な機能が異なるので、部署が異なるのと同じように違う仕組みになっているはずです。ただし、物理的にどこにサーバがあるかなどはあまり関係がありません。
しかし、こうなると小さなサーバがたくさんたくさんあると言う状態になって管理が大変です。
利用者の視点にしても、システムごとにログインするための情報が別々だと非常に使いづらいですよね。会社で部屋ごとに別々の鍵がついていて、じゃらじゃら鍵束を持って歩くような状態は面倒です。
すると、どうするかというと、これらをまとめて管理するシステムというものが作られます。
これを「システム管理ソフト」と「認証システム」といいます。これらが全体に対してユーザ認証や、サーバが正常に動いているかどうかの管理を提供する事で、たくさんのシステムの管理を効率化するのです。
企業の警備室に機能を集約するようなものです。ですが、ここが要になっていて、破られると全ての鍵が流出してしまうということになるわけです。
出てきた情報から見ると、この管理するシステムと認証するシステムがやられたと思われます。
また、その前の前段はVPNと言う仕組み（ネットワークを暗号化して安全に隔離するもの）が攻撃されて破られたのではないかと推測しています。
これは近頃猛威を振るっている攻撃で、業務用で多く使われているVPN装置の脆弱性（弱点）が狙われて、多数の問題が起きています。当然脆弱性を修正したプログラムは適用されていると思いますが、次から次へと新たなセキュリティホールが見つかる状況であり、匿名のアングラネットでは脆弱性情報が取引されているため、訂正版のプログラムが出る前の攻撃情報が用いられた可能性があります。（これをゼロデイ攻撃といいます） あくまでも推測ではありますが。
個々のシステムは独立しています。ですが、こうなってくると、今回はシステム全体が影響を受け、さらにどこまで影響が及んでいるかの分析が困難なレベルだと言われています。
ここまで広範囲に影響するとすると、管理と認証とVPNが攻撃を受けてやられたとみるべきでしょう。
また、ここが破られていると、クラウドシステムにも影響が及ぶケースがあります。
一時期「クラウド」というとストレージの事を言うぐらい、クラウドストレージが当たり前になって、自社運用ファイルサーバは減りました。これは今では危険と認識されているほかに、こちらの方が安く利便性も高いからです。
それ故に、クラウドストレージ、たとえばSharePoint OnlineやGoogleDrive、Boxなど外部のシステムに置くようになっています。
オンプレミスの認証サーバが破られているので、その認証情報を利用してクラウドにアクセスできてしまったものだと思われます。言わば、鍵を集めて保管してあった金庫がやぶられるようなもの。
通常、クラウドシステムはそんなに甘い認証にはなっていません。例えば多要素認証といってスマホなどから追加で認証すると言うような仕組みがあります。貸金庫に入るとき、自称するだけでは入れず、身分証明書とパスワードの両方が必要なうなものです。
また、日本企業なのに突然ロシアからアクセスされたりすると警報をだして遮断する仕組みがあります。
とはいえ、いちいちクラウドにアクセスする度に追加認証をしていると大変で、面倒クサいと言う声が上がりがちです。
そんなときに行われてしまうのは、自社のネットワークからアクセスするときは、認証を甘くすると言う仕組みです。
つまり、ネットワークは安全だという仮定の下においてしまうわけですね。自社の作業着を着ている人なら合い言葉だけで、本人確認なしで出入り自由としてしまうようなものです。
ところが今回は、ここが破られてしまって被害を受けている可能性があります。自社の作業着が盗まれているので、それを着られてしまったので簡単に入れてしまったようなもの。
また、社内システムからデータを窃盗するには、どのシステムが重要かを判断しなければなりませんが、クラウドサービスだと世界共通であるため、一度入られてしまうと慣れ親しんだ様子で好きなようにデータを窃盗されてしまうわけです。
上記のことを踏まえて、KADOKAWAの展開してるサービス自体や、そこに登録しているクレジットカードは「おそらく」大丈夫です。パスワードも「ハッシュ化」という処置を経て通常は記録されていません。
ただ、パスワードを使い回している方は、その事実とは別にそもそも危険です。パスワード変更をおすすめします。さらに、ハッシュ化をされていても、時間をかければ色々な方法でパスワードを抜き出す事も不可能では無いことも忘れずに覚えておきましょう。
しかし、単なるユーザー、お客さんではなく、KADOKAWAと会社として関わってる人や従業員、取引先で色々な書類等出した人は、既に情報が窃盗されていて、そこから今後も追加で情報が出回る可能性があります。
一方で、分かりやすい場所に保存されていたわけではない情報（システムのデータベース上にだけ入っていたものなど）は、センセーショナルな形で流出したりはしないのではないかと予想しています。
犯人が本当に金が理由だとするならば、データを分析するような無駄な事に労力を割かないためです。
腹いせで全てのデータを流して、暇人が解析する可能性はあります。
ありますが、犯人はコストを回収しようとするので、これらの情報を販売しようとします。売り物になる可能性のものをただ単に流したりもしづらいのではないかと思っています。
もちろん、油断はするべきではありませんし、購入者が現れるとすると購入者は具体的な利用目的で購入するため、より深刻な被害に繋がる可能性も残されています。
犯人が悪いからやられたのです。レベルが低いからとか関係ありません。
また、周到にソーシャルハッキング（オレオレ詐欺のようになりすまして情報を搾取するなどの方法）や、このために温存したゼロデイ攻撃（まだ誰も報告していない不具合を利用した攻撃）を駆使され、標的型攻撃（不特定多数ではなく、名指して攻撃すること）をされると、全くの無傷でいられる企業や団体は、恐らく世界中どこにも存在しません。
それは大前提とした上で、敢えて言うならば、どちらかというと、経営判断が大きいと思われます。
ニコニコ系のサービスと、KADOKAWAの業務システムと2つに別けて話しをしましょう。
ニコニコ系のサービスは、現在、クラウドにシステムをリフトアップしている最中だったと思われます。先日のAWS（クラウドサービスの大手企業）の講演会で発表があったようにです。
ですが、この動きは、ニコニコのようにITサービスを専門にする企業としては少し遅めであると言わざるを得ません。
これは何故かと言うと、ニコニコ動画というサービスが、日本国内でも有数の巨大なサービスだったからだと思われます。特殊すぎてそれを受け入れられるクラウドサービスが育つまで待つ必要があったと思われます。
それが可能になったのはようやく最近で、動画配信系はクラウドに揚げて、残りを開発している最中だったわですが、そこを狙われたという状態ですね。
ただ、厳しい見方をするのであれば、その前に、クラウドに移行する前に自社オンプレのセキュリティ対策を行っておくべきだったと思います。結果論ですが。
それをせずに一足飛びでクラウドに移行しようとしたというのだとは思います。確かに一気に行けてしまえば、自社オンプレに施した対策は無駄になります。コストを考えると、私が経営者でもそう言う判断をしたかも知れません。
KADOKAWAの業務システムですが、これはITを専門としない企業であれば、オンプレミス運用（②番）が多く残るのは普通です。
何故かと言うとシステムとは投資と費用なので、一度購入したら4年間は使わないといけないからです。そして自社向けであればそれぐらいのサイクルで動かしても問題はありません。
しかし、それ故に内部的なセキュリテ対策の投資はしておくべきだったと思います。
以上の様にエンジニアのレベルととかは関係ありません。基本的には経営者の経営判断の問題です。エンジニアに責任があるとすれば、経営者に対して問題点を説明し、セキュリティを確保させる事ができなかったと言う所にあるでしょう。
ですが、パソコンのことﾁｮｯﾄﾜｶﾙ私として、想像するのです。彼らの立場だったら…自社グループに経験豊富なエンジニアがいて、一足飛びにクラウドへリフトアップができそうなら、既存の自社サービスのセキュリティ変更に投資はしないと思います。
逆に、パソコンに詳しくなく、自社部門だけでは対応が難しく、SIerの支援を受けつつやらなければならないと言うのならば、SIerは固いセキュリティの仕組みを付けるでしょうし、システムごとにSIerが異なることから自然とシステムは分離されていたでしょう。
そして減価償却が終わった者から徐々にになるので時間がかかることから、昨今の事情により、セキュリティ変更に投資をしてからスタートしたかも知れません。
ただし、繰り返しになりますが、犯人が悪いからやられたのです。レベルが低いからとか関係ありません。
（おそらくは）社内のシステム管理を、自社でできるからと言って一本化して弱点を作ってしまったのは不味かったと思います。
先ほど述べたように、高度化していく手口でシステムへの侵入は防ぐことが出来ません。
なので、システムは必ず破られると考えて、それ以上被害を広げないこと、一つのシステムが破られたからと言って他のシステムに波及しないようにすることなどを意識する必要がありました。
これは物理的な話しではなくて、論理的な話です。例えば物理的に集約されていてもちゃんと別けていれば問題ないし、物理的に分散していても理論的に繋がっていたら同じです。
すごく簡単に言えば、管理するグループを何個かに分けておけば、どれか一つが破られても残りは無事だった可能性があります。
とりあえず今まで出てきた内容からするとニコニコとかその他のKADOKAWAの外部的なサービスは人員的にも予算的にも全然関係ない感じ
■周囲のパルワールド熱
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のエディタ上で動くくらいを目標にすべきだ。
