はてなキーワード: データセンタとは
NTTが満を持して出してきたIOWNというネットワークサービスが予想通りがっかりだったので解説しておく
そもそもIOWNって何?っていう話については恐らくNTTの社員でも誰一人答えられないので割愛したいが
発端は電気によるネットワークルーティングに限界が来ていることから始まっている
このままではルーター1機に原発1台という時代になりそう、というのはよく言われた話だ
IOWNは光を使ったルーティングを行い、End-To−Endで電気を使わずに光だけで通信すること(All-Photonics Network: APN)が構想の発端である
電気によるルーティングには遅延が発生することもあって「大容量・低消費電力・低遅延」の3つが特徴として挙げられる
1Gbpsしか無かったのに10Gbpsが登場すれば「大容量になった!」となるだろう
IOWNは100Gbpsを提供してくれる
ちなみに今でも企業向けに100Gbpsの専用線サービスは存在している
なのでIOWNは何も大容量サービスではないのだ
ただ、IOWNにおけるNTT側の性能目標はIOWN1.0で従来の1.2倍なので
まぁ実効速度として1.2倍という意味だと思えばこの100Gbpsも妥当かもしれない
また、IOWN2.0では6倍になるとのことなので600Gbpsが実現できるのであろう
ローンチで現行より劣っているのは残念に他ならないが安全側に倒したと思えば分からなくも無い
低消費電力は我々にはほとんど影響がなく、NTT社内の話なので「知らんがな」という感じなのだが
低消費電力でランニング費用を抑えることができているはずなので提供価格も下がるはずである
さて、IOWN1.0の提供価格は月額198万円とのことである
現在提供されている100Gbpsの専用線サービスも198万円である
これも資料を見るとIOWN1.0では1.0倍とのことなので妥当な価格である
IOWN2.0では13倍(倍とは?)とのことなので価格も大幅に下がってくれるだろう
逆に現状では一切電力効率は良くなっていないのに同価格で出してきてくれていることは良心的ですらある
ということで大容量・低消費電力に関しては現行と同等もしくは劣っているIOWN1.0だが
遅延に関してはIOWN1.0で1/200を目指している
これはIOWN4.0まで1/200なのでこれより下がることはなく、逆にIOWNの目指している低遅延をローンチから体験できるということになる
さて、低遅延になって誰が嬉しいのかはさておき、現状では東京ー大阪間で15msぐらいである(往復)
これが1/200になると75μsとなるのだが、東京ー大阪間の光の伝搬遅延だけで5msはあるのでいくらIOWNでも光の速度は超えられない
なので機器遅延の10msのみが1/200となるとすると50μsとなり、往復遅延は5.05ms、ほぼ5msぐらいになる
実際に実証実験では8msを実現できたとのことなので大変速くなっているのだろうが
15msが8msになったのを「1/200」と言われるのはモヤッとする
そのせいなのか、「IOWNが提供できる低遅延の価値」という資料では、「映像処理やコーデックに関わる部分を省略できるので実質1/200」という言い方に変えている
つまりは大容量であることを活用して非圧縮で送信すればコーデック部分の処理遅延を減らせるとの主張である
コーデックの遅延は製品にもよるが200〜800msぐらいある
また、超低遅延のコーデックなら10msを実現できるらしい(使ったことはないが)
伝送遅延なんて無視できるほどコーデックの遅延は大きいので非圧縮であれば確かに遅延が1/200になるような体験ができるだろう
ただしそれは従来の100Gbpsネットワークでも実現できる
特にこの手の非圧縮による低遅延化というのは10Gbpsのネットワークを研究する際によく使われた方便で
4K映像を非圧縮で送ると6Gbps消費するため10Gbpsにしましょう、という論法なのだ
それが今の時代では、8K非圧縮は72Gbps消費するから100Gbpsにしましょう、という話なのである
ちなみに8Kで120Hzなら144Gbps必要なのでまだまだご飯を食べられるのだろう
問題なのはこの非圧縮リアルタイム映像伝送はほとんど使われていないということである
コーデックが進化することでコーデックにかかっている遅延は無視できるようになり
特に高精細映像であるほど圧縮率が高くなるのでネットワーク負荷のコストの方が問題になるのだ
なので実際の利用で非圧縮伝送はほとんど用いられておらず、主にネットワークの試験で用いられているのが現状である
まぁこの辺はさておいたとしても、結局はIOWNの実現した大半の価値である低遅延の部分は従来でもやっている技術であって真新しいことではない
それでも従来の100Gbpsでは15msだった遅延が8msになったとなれば1/200とまではいかなくても価値があるだろうか
遠隔での演奏を実験した際の記事が興味深く、8msの遅延ということは3m程度離れて演奏したことになる
この2mに価値があるのだろうか
また、人間の脳のクロック間隔は30msであるという研究結果がある
15msが8msになることで人間に対して何か価値があるのかは甚だ疑問である
問題なのはIOWNではこれ以上遅延が短くなることはなく、既に限界ということだ
光の速度の限界なので当たり前ではあるのだが
限界まで突き詰めても我々のネットワークを介した体験は一切変化しないということを証明してしまったのだ
普通の演奏では低遅延にほぼ価値がないので、エクストリーム分野のe-Sportsとの相性を模索しているように見える
確かにe-Sportsをやっているような人たちは60fpsの1フレームを競っていると言われている
そのためIOWNもe-Sports会場を繋ぐような使い方を例としてあげているのだが
そもそもe-Sportsのゲームソフトウェアは5msだとか8msとかの中途半端な遅延を考慮してゲームを作っているのだろうか
同じL2の下で対戦を行うことが前提なら普通は2〜3ms程度の遅延を前提に設計するので5msでは遅い
逆に遠隔での対戦を考えれば10ms以上の遅延もあり得るのでそのように設計するが
ジャンケンゲームを作るときに2〜3ms程度までなら同時に開示するが
10ms以上なら1秒待ってから開示するような作りになっていると思えば分かりやすいかもしれない
もちろんゲームによってはこの数msで価値が生まれる場合もあると思うが、あまり数は多くないように思える
結局のところ、IOWNは大容量かつ低消費電力、つまりは低価格のサービスとして進んで行くだろう
End-To-EndでIOWNが必要か、と言われると明確に答えはNOで
10Gbpsですら全然普及が進んでいないのに100Gbpsの大容量ネットワークはそもそも必要ない
一方でデータセンタ間のインフラネットワークとしては非常に価値が高い
データのレプリケーションなどを考えれば遅延など1msでも短い方が良いのだ
特に災害が多い日本では地理位置分散をさせることは非常に重要で
そういったデータセンター間のネットワークとして大容量・低消費電力・低遅延なネットワークは非常にありがたいものとなる
こうしたインフラとしての重要性は明確に求められているのにもかかわらず
「IOWN」と標榜してまるで次世代のネットワークであるかのように喧伝しているのは、一体どのような呪いがかかっているのか興味深いところではある。
https://anond.hatelabo.jp/20221016140905
2040 年前後、高度成長が一段落して成熟化した経済と喧伝される時節であっても
「バイデン老師は中国に於ける半導体産業興隆の父である」と大陸の業界関係者に
所謂、産業政策の観点からは 4 nm 以降の製造プロセス、製造や検査等の装置、
シリコンを代替可能な新素材の基礎研究に至るまで、純国産化を躊躇する理由が
arm や RISC-V の後継規格による SoC が HPC 、データセンタ、消費者向け端末等を
某社が PS3 Cell ブロードバンドエンジンで実現しようとしたことを具現化されますなぁ。
産業界と政治、官僚機構の回転ドア故の属人的な要素が悪い方向へ働き
ネガティブフィードバックを止められないといったところが、内実なのかもしれませんが
根拠のない皮算用 w で単年度 ¥ 8,000 億、20 年、短期的な成果を訴求せずに
Nutanix × ネットワールド対談 ニューノーマルを見据えて企業が目指すべきVDI環境とは?
SpecialIssue
2021/07/01 09:00
コロナ禍で急きょ、業務継続のためにVDI環境を導入してテレワーク対応した企業は多い。だが、今になって急ごしらえの環境による生産性の低下、運用負荷などの問題が顕在化し、新たな課題となっている。今回は、ニュータニックス・ジャパンのエンタープライズ営業統括本部長である江副桂太氏と、ネットワールドのマーケティング本部インフラマーケティング部データセンタソリューション課で業務に従事する金谷宗也氏に加え、多くの企業にテレワーク環境の導入を後押ししてきた総務省テレワークマネージャーの家田佳代子氏をゲストに迎えて、テレワークという働き方が定着するニューノーマル時代を念頭に、今後のあるべきVDI環境の姿をテーマに語ってもらった。
――これまでを振り返って、企業のテレワークに関する動向や変化はありますか。
家田 私は6年以上前から総務省テレワークマネージャーとして、企業のテレワークの相談に乗ってきました。当初の目的は生産性向上が中心でしたが、働き方改革関連法案の成立からはそちらにシフト。さらに昨年のコロナ禍で、その対応のために多くの企業が付け焼き刃的にテレワーク対応を余儀なくされた、というのが現在までの流れです。日本テレワーク学会では、この20年の取り組みで普及が進まなかったものが、この1~2年で一気に進んだという話をしています。
家田 佳代子 氏
家田 企業別の傾向では、まず大手が取り組みをスタートして、中小企業に降りてきました。業界別では、IT系の企業から始まり、大手ゼネコン、設計・デザイン会社、また、AI、ARなどの技術の普及で工場系の企業にも浸透してきました。コロナ以降は、医療・介護系が目立ちます。これはクラスターの発生が施設全体の閉鎖につながるためです。
家田 当初は、何をしてよいのか分からず、仕組み自体から教えてほしいという相談が多かったです。今は、導入したシステムが適切なのか見てほしい、あるいは、急きょ対策することになったが、どんなシステムが推奨されているのかなど、システム寄りの相談が中心です。これは大手も中小も同様で、相談を受ける先も情シスではなく、人事や経営企画からの相談がほとんどです。これも働き方改革を目的としているためだと思います。
――お客様のニーズに対応されてきたニュータニックスさんは、昨年の緊急事態宣言時と、現在とで変化を感じますか。
江副 コロナ禍以前のリモートワーク環境は、ノートPCの置き忘れ、データ漏えいといったセキュリティ対策の観点から、シンクライアントなどデータを端末に残さないVDI環境を検討されるケースがほとんどでした。コロナ禍では、ほぼ自宅で作業するので、従来のFAT-PCでも大丈夫という認識から、VDIから戻すケースもあります。その理由は単純にコストで、他に管理性などの理由もありますが、コスト比較ではPCの単価がかなり下がっているため、十分ではないかと考えられるようです。
江副 桂太 氏
――家田さんは、テレワークマネージャーとして120件以上もの企業のテレワーク導入をサポートされてきたわけですが、FAT-PCとVDIの導入傾向はいかがですか。
家田 かなり以前から大手企業の多くはVDI環境を導入されています。その見直しの時期に差し掛かったところで、FAT-PCとVDIの選択を検討されるわけですが、VDIを選択する第一の理由はセキュリティですね。VDIに対して中小企業はハードルの高さも感じています。まず、専用サーバーが必要であることが大きいと思います。
――急きょテレワーク環境を導入して一段落した今、浮き彫りになってきた問題点は。
家田 システムのほか、マニュアル化、チェックシートなど企業自体の運用体制を含めて環境が整備されていないため、情報システム部門の方に、さまざまな相談やクレームが寄せられて、残業を余儀なくされているというケースが目立ちます。また、人事評価と労務管理にも問題が出ています。
江副 コロナ禍対応で、事業継続を第一に考え、他のことにはある程度は目をつぶっても、いち早くテレワーク環境を実現することを最優先にシステムを導入したケースが多かった。そのため、拡張性や管理性などは考慮されていませんでした。そこで、今になってVDIのサーバー追加などをしようとすると、苦労するケースが見られます。旧来のやり方で作業すると数カ月掛かることもありますが、その間に人の流動があると状況も変わってしまいますから。Nutanixを基盤とするVDIソリューションが選ばれるのも、そうした拡張性などの高さが評価されたためと考えています。
江副 緊急事態宣言下では、保守作業に人が出せないことも課題です。その点でも、Nutanix製品は、もし故障しても自動的に修復する機能を備え、データは保護されています。最悪、すぐに駆け付けられない場合でも時間的な猶予があります。以前であれば、当日4時間以内に駆け付けなければならない、ということもありましたので、お客様にとってもわれわれにとっても、安心感を提供できるものと自負しています。
江副 アプリケーションの観点では以前、VDIは業務使用がメインでしたが、コロナ禍以降はWeb会議などのコミュニケーションが加わりました。これらはシステム負荷が大きくリソース追加が必要になった場合、それが容易なNutanixのメリットが生きます。また、昨年はみんながPC調達に一斉に動いたことで、供給不足が起こりました。その際も、リソースプールから優先順位に応じて割り当てできたことが、お客様に評価されています。
さらに、FAT-PCではWindowsアップデートやパッチの適応など運用の問題もテレワーク環境では難しい作業です。VDIならセンターから一括して実施、統合管理ができるというメリットがあります。Nutanixは1台でも、10台でも、100台でも、同じ画面で同じオペレーションで管理できることが大きな特徴で、1人でも運用することが可能です。
――一度導入した他のテレワーク環境から乗り換えるユーザーはいますか。
江副 テレワーク環境に限らず、今は、全面的なシステムの切り替えを決断するのは、難しい時代だと思います。そこでスモールスタートして、パフォーマンスや業務要件が合うのかをチェックした上で、拡大していくというケースが多い。Nutanixはスモールスタートが容易で拡張性が高く、IT投資を最適化できるというメリットを提供できます。
金谷 Nutanixが優れているのは増設が容易なことで、実際、昨年から今年にかけて既存のNutanix環境に増設したいという問い合わせが増えました。特に、人が出せないという状況下で、簡単に増設できるというNutanixのメリットが活きています。同時に運用担当者に負荷を掛けない容易な管理、サポート品質も高く評価されています。
金谷 宗也 氏
家田 ユーザーにとって、しっかりしたサポートが受けられるという安心感はとても大きく、特に、コロナ禍ではシステム担当者が自分でサポートに出向くよりも、サポート料を払ってもベンダーに頼みたいというニーズが強いようです。
――ポストコロナを考えた時、どのような観点でテレワーク環境を整備すべきですか。
家田 まず、性善説/性悪説(徹底した管理)のどちらを選択するかという観点からはじめ、ゴールを決めて、それに向かって最適なシステムを選択することが、後戻りしないための方法です。セキュリティの確保は第一ですが、がんじがらめであることは使い勝手を損なうのでバランスが大切です。スモールスタートは投資を無駄にしないためにもとても有効な手段で、各部署から選抜した人でスタート、問題がなければ全社展開します。システム以外では、上司と部下でコミュニケーションをしっかりとることをお勧めしています。
――FAT-PCとVDIの選択で悩まれるお客様には、どのようなアドバイスを。
江副 セキュリティ確保を目的にVDIを導入したお客様が、セキュリティに目をつぶってFAT-PCに戻すような選択はするべきではないでしょう。仮に使い勝手に問題があれば、用途に応じてクラウドの選択もある。われわれも、クラウドサービスとしてNutanixを利用できる製品をリリースしているので、オンプレ、クラウドを含むハイブリッド環境で、お客様が適材適所に使い分けるというニーズにもしっかり対応します。
PCかVDIかの比較論は多いのですが、最終的にはシステム全体で見た時のアプリケーションをどうするか、基幹系を含めたDXなど、全体の中の一つの要素にすぎません。そこだけを見て判断すべきでなく、全体最適解という観点で選択されるようお勧めしています。
金谷 当社でも、何が目的なのか、セキュリティの強化なのか、働き方改革なのか、それともBCP/DR対策なのか、お客様の本来の目的を判断した上でディストリビューターの立場ならではの最適なシステム提案ができると考えています。
江副 ニュータニックスは、これまで主にHCI分野でビジネスを展開してきましたが、VDIに絡む部分でも、プロファイルを置くような領域でFiles(ファイルサーバー機能)を提供していますし、追加コストなしで利用できるハイパーバイザー「Nuatnix AHV」も活用いただければと思います。
金谷 最近、VDI導入の相談を受けた時は、Nutanix Filesも一緒にご検討されているお客様が多いです。お客様としても、ベンダーが異なるとサポートが別になって面倒と感じるようで、インフラ部分はニュータニックス製品で統一したいというケースが目立ちます。
[B! セキュリティ] フェイスブックの暗号化、日米英などが見直し要求へ (写真=AP) 日本経済新聞
平文に一定のアルゴリズムに従って暗号鍵から生成したノイズデータを掛け合わせ、意味が読み取れない暗号文を作るのが暗号化である。逆に意味が取れない暗号文から平文を求める操作を復号と呼ぶ。アルゴリズムがよく知られていながら暗号鍵が無ければ復号できないものがよい暗号と言われる。一般には256bitAESでも使っておけばまずパッと見ても聞いても数学的にもほぼ乱数と区別できなくなる。
ノイズデータの生成方法には色々あり、事前に送り付けた乱数表を使い使用後は破棄するもの、事前に送り付けた共通鍵や公開鍵を使うもの、都度生成するものなどがある。掛け合わせる方法も色々あり、乱数表に書いてある数字と暗号文を足し合わせると平文になるもの、共通鍵を暗号文に使うと平文になるもの、公開鍵を使うと平文になるものなどがある。
共通鍵を平文に使うと暗号文になり、共通鍵を暗号文に使うと平文になるものを、対称暗号とか共通鍵暗号と呼ぶ。
公開鍵を平文に使うと暗号文になり、暗号文に秘密鍵を使うと平文になるものを公開鍵暗号と呼ぶ。非対称暗号ともいう。
共通鍵暗号でも公開鍵暗号でも「平文が、暗号文になり、平文に戻る」というところは同じだが、
共通鍵では「平文→ 鍵→暗号文→鍵 →平文」と同じ鍵を使い、
公開鍵では「平文→ 公開鍵→暗号文→秘密鍵 →平文」と二種類の鍵を順に使う。
なお、この二種類の鍵は順に使えば順序はどっちでも良い。先に秘密鍵で処理して公開鍵で処理することも可能だ。とにかく2種類両方を使えば良い。
共通鍵暗号は分かりやすい。zipのパスみたいなもんだ。Wi-Fiのパスワードも同じだ。だが公開鍵暗号については、二種類の鍵を順番に使うと何が良いのかと思う人も多いだろう。どうせ暗号で読めないのだからいいじゃないかと思うだろう。実は名前の通り鍵を公開しても全くノーダメージというところがメリットなのだ。書かなかったが公開鍵から秘密鍵を数学的に求めることは不可能である。逆も不可能である。そして処理する順番もどっちでもいい。つまり適当な暗号文と鍵の片割れを公開しておくことで、もう片割れの所有を証明できるのである。これが公開鍵暗号の醍醐味である。
この技術はHTTPSの証明書に使われている。というかすべての公開鍵基盤で使われている。.pemとか.cerとかid_rsa.pubはこの片割れであり、ウェブブラウザの「証明書の検証」とは、ネットを見てる時にサーバが送ってくる「適当な暗号文」として"*.hatena.ne.jp"のハッシュを知らん鍵で暗号化したもののハッシュを知らん鍵で暗号化したもののハッシュを暗号化したものに対して、事前にWindowsをインストールした時に付いてきたHatena-Masuda Ultra Global Root CAとかいったけったいな鍵の片割れを使ってみてちゃんと復号出来てるかチェックしているのである。
暗号化通信を行うには、暗号鍵でデータを暗号化すればいい。暗号化には共通鍵暗号を使うのが高速で便利だ。公開鍵暗号は原理的に計算量が多く低速である。しかし、どうやって共通鍵を事前に知らせればいい? 公開鍵暗号で共通鍵を暗号化すれば、受け取り手は自分の秘密鍵で復号できるだろう。しかし、秘密鍵は本当に秘密か? 暗号文と秘密鍵が手に入れば、公開鍵暗号でも解読できてしまうのではないか? HTTPS化しているウェブサービスでも、TLSをロードバランサで終端してデータセンタ内は平文だったりするのではないか? そこで鍵交換、セッション鍵生成の議論が登場する。
Diffie-Hellman-Merkle(Diffie-Hellman)鍵交換方式とは、ディッフィー君とヘルマン君が下宿で階段をドタドタやってる時に天啓のように降ってきたと言われる、ネット上に数字そのものを公開することなく、2者間で同じ1つの乱数を得る方法である。
送信者と受信者の間で共通の1つの乱数を得ることができ、その乱数を第三者に知られることがない。
上で何度か「公開鍵暗号の秘密鍵と公開鍵は、平文に対して両方使えば平文に戻り、順序は関係ない」と書いたのを覚えているだろうか。Diffie-Hellmanはこれに似た方式だ。まず、AさんとBさんは送信者がお互い本人であることを証明できるようにする(公開鍵基盤を使う)。そして、それぞれ手元で乱数AとBを生成する。次に、鍵用の乱数Aを適当な乱数で暗号化した鍵Aと、鍵用の乱数Bを適当な乱数で暗号化した鍵Bを計算し、お互いに送り付ける。この暗号Aと暗号Bは盗聴されているものとする。
AさんとBさんはそれぞれ鍵Bと鍵Aに対して暗号化を行う。すると鍵BAと鍵ABが生まれる。このとき数学的な都合により鍵BA == 鍵ABである。
では、暗号A、暗号B、適当A、適当Bのみから鍵ABや乱数Aを求めることはできないのか? 可能だが式変形などで「解く」ことができず、総当たりになるため計算量が膨大になる。従って実質的にはできない。
或は、暗号A、暗号Bを掛け合わせれば、鍵ABになるのではないか? これもできない。暗号AまたはBと掛け合わせるのは生の乱数AまたはBでなければ意味がない。第三者が乱数Cを作って暗号AやBと掛け合わせても、鍵ACや鍵BCになってしまい、鍵ABと一致しない。
これにより、手元で生成した乱数以外のすべての情報が公開で既知で盗聴されているにもかかわらず、2者間で秘密の暗号鍵用乱数を得ることができる。
原始的なDiffie-Hellman鍵交換の実際の計算は非常に簡単であり、この「暗号化」は事前に決めた別の方法で生成する既知の2つの整数X, Yと乱数A, Bに対して、
暗号A = XをA乗してYで割った余り、
暗号B = XをB乗してYで割った余り、
鍵AB = 暗号BをA乗してYで割った余り、
である。
なお、くれぐれも簡単と聞いてPython 2.7とかで実装しようとしないように。算数の上手い人が作ったライブラリを使え。暗号処理の自作は絶対バグらせて割られるのがオチだ。ちなみにDiffie-Hellman-Merkleの三人目のマークル氏というのは両名と何のゆかりもないので普通は名前に入れないのだが、Merkle氏の先行研究が直接の元ネタなので入れるべきだと主張する派閥もある。俺はどっちでもいいと思うが折角なので入れておく。
ここでやっとE2E暗号化が登場する。上のセクションでしれっと書いたが、DH鍵交換が完了した時に送信者と受信者が得る共通の乱数は、各々ローカルで都度生成する乱数を元にしている。身許保証は公開鍵によるが、鍵は公開鍵に縛られないのだ。つまり、SNSやメールサーバその他、身許を保証する機能と文章をやり取りする機能があるツールと、そのツールで間違いなく本人にDH鍵交換の暗号を送れるクライアントアプリがあれば、その経路で本人同士の間だけで共通の乱数を生成し、それを「セッション鍵」として共通鍵暗号方式による通信経路が設定できる。
この「公開鍵認証基盤で本人確認し、DH鍵交換でセッション鍵を設定し、鍵を端末に出し入れすることなく、受信側端末のメモリに入るまで暗号化を解くこともないまま、共通鍵暗号で通信する」のがいわゆる「End-to-End 暗号化」である。
E2E暗号化を行うと、鍵はDH鍵交換で生成され、端末の外に出ないし書き出す必要もなく、通信の中で割り出す事もできず、通信が終われば破棄してもよい。好きなだけ定期再生成してもよい。認証に使う公開鍵と数学的な関係もない。一度設定してしまえば、SNS運営にチャットログを出させても鍵交換した意味不明な履歴と意味不明な暗号文が出てくるのみで、盗聴者をなりすまさせて鍵を再設定させても前の鍵と何も関係のない新しい鍵が出てくるだけで、意味不明な暗号文の解読の助けにはならない。ちょっと量子コンピュータめいているが、端末となりすましの両方で鍵を一致させることもできない。
ざっくり言えば送信側端末と受信側端末に残っている平文か鍵をバレる前にぶっこ抜く以外に解読方法がない。
これは盗聴関係者にとって非常に大きな問題で、米国のFBIなどは盗聴能力を維持するには法規制以外に策がないと考えている。DH鍵交換のアルゴリズムは上に書いた剰余以外にも楕円曲線を用いた数学的に更に複雑なものもあり、ソースはネットにいくらでも転がっているし、電子計算機アルゴリズムの常でやたら強力な癖に計算量的には全然負担にならない。NSAなどは数学者を揃えて最高のアルゴリズムを提供する振りをして、規格書で事前に決めた一定の数学的特徴を備えているべき定数に備えていないものを指定するとか、実装でミスが出やすい関数を選ぶなど小細工を入れているが俺は二次関数も分からんので詳しいことは知らん。しばしば政府の陰謀にキレた若いITキッズが小細工を抜いて差し替えた再実装を公開したりして揉めている。
実際にSNSなどでE2E暗号化を実装する上での問題点は、本人確認、機種変とマルチデバイス、嫌がらせ対応がある。まず本人確認がコケればMITMは可能だ。E2Eでは鍵を外に出さないのがメリットなので複数端末ログインができず(鍵が変わって別端末で書いたメッセージは解読できなくなる)、運営で常時メッセージを監視できない(したら意味がない)ので嫌がらせ対応が多少困難になる。またMITBというか、改造偽アプリで抜かれる可能性は、まあ、ある。
10年前電子回路系の学科の高専を卒業して中小のIT企業に入社した
入社時点ではサーバー?Linux?SSH?なにそれ?といった状態でしたが配属されたのはネットワークインフラとサーバの面倒を見る部署
物理的なサーバのキッティングからOSとかapacheのインストール、データセンタへのラッキングとかスイッチの設定とかを主にやっていました
作業は主に手順書取りに全部手作業で、運用中にアラートが飛んできたら目視確認して対応するといったことをずっとやっていました
そのうち自動化とか監視の外部委託とかそういう感じに手作業で行うことがどんどん減っていき作業量はそれほどなくなってきていました
そうしていたら部署の移動の打診が
主に営業と作戦をねってお客さんに提案しに行ったりとか、運輸中のお客さんの御用聞きを技術側の視点からやってほしいとのこと
正直営業さんと話すのもお客さんと話すのも苦痛でしか無いので10年のITエンジニアのキャリアがあれば転職できるだろう、まだ30代前半だし
と思いたち有給も全部消化して退職して転職活動をすることにしてみた
増田にいる本当のITエンジニアの方々ならおわかりかと思うが自分がやってきたことはただのオペレータでしかなかった
面接で聞かれるのは開発経験の有無とマネジメント経験の有無ばかりでどれも経験がない
周りの大卒の友人よりも少し早く就職して収入があったこともあり就業後野球実は遊びまくっていた
それでも自分はインフラ・サーバエンジニアとして10年のキャリアがあると謎の自信をもっていたため転職なんてすぐ決まると思っていた
結果は上記の通りで全滅、どうしようもない
やっぱり途中で切れたので続きから
違います。
そうです。
はい。Stadia Games and Entertainmentの組織を発表しました。これは我々の1stパーティのスタジオです。
はい。
Googleは開発者に対し全てのツールを支援しています。Stadia向けの開発は彼らにとって別のターゲットにしか過ぎません。Visual Studioを用いる既存のツールや彼らが用いるツールの全てと共に、彼らのワークフローに統合されます。従ってStadia向けの開発はPlayStationやXbox向けの開発と同じくらい簡単です。
我々はUnrealもサポートします。UnityがStadiaをサポートします。予想される多種多用な業界標準のツールとミドルウェアが準備されます。
とても良い質問です。我々はユーザに対し彼等のインフラの中で何が起こっているかをできる限り理解できるよう支援する必要があります。また我々はゲーマーに対し最適な体験を得られるようなチューニングを行うことが可能な情報に対し投資を行うだけでなく、我々自身の技術を用いて最良のパフォーマンスを実現するつもりです。Googleの技術の多くがインターネット網の基盤であることを思い出して下さい。我々はDCからの情報がどのようにユーザに届くかを良く理解しております。できる限りの最適化を行うつもりです。
その通りです。それこそが我々のプラットフォームの根本的な差別化ポイントです。既存のゲームカタログを持つデベロッパにとってStadiaは簡単で親しみ易いものです。我々はできる限り摩擦なくゲームの移植を行えるようにします。なぜならゲーマーは好きなゲームを遊びたいですし、彼らの愛するキャラクター、ストーリー、世界を楽しみたいのです。しかし我々はまた開発者に未来を描く新しいキャンバスをも提供します。ゲームを高速に配布し、プレーヤーと新しい手段で、特にYoutubeにて繋げます。そして開発者が持つアイデアを実現するための前例の無い技術を提供します。
解決されたと同時に緩和されています。まずデータセンターに対しより多くの人々がより良い経験を得られるようにするための投資が行われました。また圧縮アルゴリズムについては我々に抜本的な先進性が存在します。Googleは圧縮アルゴリズム標準仕様の先駆者でありこの点がストリーミングの将来をより確実にします。残念なことですがGoogleでも制御できない点が光の速さです。そのためこの点が常に要因となります。しかし常に理解しなければならないこととして、我々は常にエッジ(終端)にもインフラを構築していることが挙げられます。Googleの中心にある巨大なデータセンタだけではありません。我々はできる限りエンドユーザの側にインフラを構築しています。それによって歴史上の幾つかの問題は回避することが可能です。さらにまだ率直な、あまり洗練されていないProject Streamのストリーマーでも信じられない結果を出しています。さらに我々はサービスリリース時に1080p60を超える品質を実現できるだけの根本的な改善を行いました。我々は8Kに至るでしょう。
圧縮にネットワークです。我々はGoogleがインフラに投入した数々の改善点に依っています。BBR、QUIC、WebRTCを基盤としてその上に構築がなされました。だからIPパケットの低レイテンシでの配信だけでなく、送信元へのフィードバックも行うことが可能です。ですのであなたが仰るZenimaxが使用した技術なら、彼らはここでも利用することが可能です。彼らは彼らのゲームの最適化を行うことができるでしょう。我々はフレーム毎のレイテンシを予測が可能で彼らにそれに合わせて調整を行わせることができます。
我々は改善を続けます。Streamは最初のバージョンです。我々は性能向上のために調査を行っており、レイテンシに適応していきます。リリース時にはより良くなっているでしょう。
確かにそのとおりです。そしてそれこそがGoogleが何年もかけて開発してきたスキルであり、抜本的なスケールする能力です。我々がどうやって実現しているのか、何をしてきたかについては今日は詳細にはお話ししません。しかしGMailやMap、Youtubeが同時に利用可能であるためと同じ基本的な技術のいくつかが我々が依るものです。
我々は競合他社が何をしているかは存じておりません。
我々の第一世代システムに導入されるGPUは10Tflops以上の性能があり、さらにスケールアップします
AMDです。
情報を公開したくない訳ではないのですが、このプラットフォームが進化することのほうがより重要です。そしてこの進化がユーザと開発者の双方に対しシームレスに行われることを確認して頂きたいのです。そして進化は常に継続し、誰もが常に最新で最高の物を手に入れます。
開発者にもこのように考えて欲しいのです。もちろん完全には抽象化されていません。特にゲームの開発者にとっては。しかし我々はそれでもこのプラットフォームが常に進化していると考えて欲しいのです。速さや容量、リソースには制限されていないのだと。
シェーダコンパイラのツールをいくつか開発しました。これらは開発を楽にするでしょう。しかし現在のGPUはとても優れており開発者が既にVulkanに親しんでいれば、例えばid Softwareさんは既に全てVulkanに移行していますが、そのような開発者の方々には既存のゲームをStadiaに移植するのはとても簡単です。Doom Eternalが4K、60フレームで動いでいるのは既にご覧になったと思います。非常に素晴しい状態です。これこそが我々にとって重要な証明ポイントです。FPSはグラフィックとプレイアビリティの双方で要求が高いゲームです。 従ってこれは我々のプラットフォームの強力な証拠であり、idさんにも講演して頂きます。
x86で2.7GHzで動作しています。開発者にとり慣れのあるものです。開発全体を通して、CPUは制約となる要因ではありません。我々は全てのタイトルを動作するに十分なCPUを提供します。
沢山です。
しかしサーバ級のCPUです。Stadiaはこれまでのコンソールと違いパッケージングに制約を受けません。熱対策の問題も異なります。コンソールとはサイズやパッケージングの動機が異なります。データセンタの中でそれはとても汚なく見えるかもしれません。一方でとても帯域幅が高いメモリが使用可能で、とても高速なペタバイト級のローカルストレージも使用可能です。ご家庭のコンシューマデバイスよりも数百倍は速い物です。
パートナーには彼らが話せる時点で彼らの計画を教えてくれるよう伝えています。Stadiaをこの世界で最も偉大なゲームの開発者達に説明することにはとても興奮します。Stadiaは、開発コードではYetiと呼ばれていましたが、Stadiaのビジョンを説明すると、開発者のリアクションは「これは私が期待したものそのものだ。これはまさに我々の次のゲームのためのビジョンそのものだ。elastic computingの考え、次世代レベルのマルチプレーヤー環境、ゲームを観ることと遊ぶことの境をあやふやにし1つの体験にすること」と話されます。
イノベーションの1つの領域として、最初のほうで述べましたが、マルチプレーヤー環境において、単純にパケットを複数のプレーヤーにリダイレクすることから、原子時計レベルでのコンシステンシーを全ての状態遷移において定期的にクライアント間で更新する真のシミュレーションへの移行が挙げられます。これにより開発者はこれまでには不可能だった分散された物理シミュレーションを得ることができます。これだけでもゲーム設計のイノベーションに対し大きく寄与します。このため多くの開発者が、大袈裟でなしに、実際にとても感動的なリアクションを我々のプレゼンに対して返して下さっています。
これこそがゲーム業界の素晴しい点です。技術が常に創造性を刺激し、ゲームに対しより大きな聴衆を作り、そのことがプレーヤーと開発者に対しより大きな機会を作ってきました。エコシステムが進化し、正の方向に回り続けるなら、それはゲームを遊ぶことにとって良いことです。
3台のGPSが一緒に実行されるデモを行っています。私は上限が無いとは申しません。しかし我々は技術上の限界を上げています。そしてStadiaは静的なプラットフォームではありません。このプラットフォームは5年や6年の間、レベルが変わらない訳ではありません。開発者とプレーヤーの要求に従い、成長し、進化するプラットフォームです。なぜならStadiaはデータセンタの中に構築されています。進化させるのは我々にとって簡単なことです。
CPU/GPU/メモリ帯域幅の変更にはいくつかの自然な段階があります。これは家庭の物理な小売の端末よりももっとスムースでより継続的な進化です。しかし、より重要なことは基盤データセンタ網とそれに含まれるネットワーク技術への投資です。この2つが一致して行われることが重要でどちらか1つではダメなのです。
それは我々も既に行っています。Googleが既に20年以上、行っていることです。我々が依って立つまた別の巨人の肩です。
我々はStreamをさらに強化させています。従ってユーザはこの制約が全体のスタックに対する改善と最適化、また特に時間によって緩和されることを期待するでしょう。我々はその期待の上を行きます。
私は具体的な数値についてはコメントしません。しかし当然低くなります。
インターネットの接続環境はStadiaをリリースする市場では全体的に上昇機運が見られます。つまりこのパフォーマンス特性はますます多くのユーザが利用可能になります。
さらに繰り返しになりますが、BBRを初めとする我々の技術があります。さらに覚えておいて頂きたいのは我々のネットワークに対する理解はそのままではありません。それらもまた時と共に改善されていきます。Youtubeはマクロと
Eurogamerにより独占配信されたStadia開発者二人に対するインタビュー記事。
---
タイミングの問題です。20年間の蓄積によりGoogleにはデータセンタ内のパフォーマンスに優位性が存在します。Googleはデータセンタ内ではHWメーカーです。我々はデータセンタ内で何年もの間、高い性能で端末間を接続する基盤を構築してきました。Youtubeでの経験からプレーヤーサイドの観点からだけでなくデータセンタ内部からの技術的観点からの技術統合を行ってきました。他社でもその視点は存在していますがGoogleにはその点に固有のアドバンテージが存在します。
その通りです。我々にはレガシーがありません。全てが21世紀のために設計されています。開発者は制限の無い計算資源が利用でき、何よりもマルチプレーヤーをサポートできます。これまでのマルチプレーヤー環境は一番遅い通信に影響を受け開発者は最も遅い接続に対し最適化が必要でした。我々のプラットフォームではクライアントもサーバも同じアーキテクチャの下にあります。これまではクライアントとサーバの間のpingに支配されていましたが我々の環境なら最速でマイクロ秒で済みます。だからプレーヤーの数は単一のインスタンスにて動的にスケールアップが可能です。バトルロイヤルなら数百から数千、数万のプレーヤーが集まることも可能です。それが実際に楽しいかどうかは置いておくとしても、新聞のヘッドラインを飾ることが可能な技術です。
両方です。
ユーザが我々のプライベートLANからはみ出さないだけでもその効果は大きいものです。Googleは45万kmに及ぶ光ケーブルにより世界中のデータセンタ間を接続しています。米国の西海岸から東海岸まででも20ms、フランクフルトからマドリッドでも20ms。これにより開発者は最も極端な場合においてもレイテンシが予測可能でそれに従い設計を行うことができます。
StadiaはYoutubeの技術と深く結びついていますが、実際には一歩引いています。今日のゲーム業界を考えてみて下さい。2つの世界が共存しています。1つはゲームをプレイする人々で、もう1つはゲームを見る人達です。2億人の人々がYoutubeでゲームを毎日見ています。2018年には述べで500億時間がゲームを視聴するのに費されています。時間と人口の双方で信じられない程の視聴が存在します。我々のビジョンはこの2つの世界を1つにすることでゲームを見ることができ、かつ、プレイもできる、双方向に楽しめることです。
つまり重要なのはゲームシステムでもなくコンソールでもありません。噂とは異なり我々はコンソールビジネスには参入しません。我々のプラットフォームの要点はコンソールでは無いことで、皆が集まる場所を作ることです。我々は箱でなく場所を作る。今までと異なる体験を得られる場所です。ゲームを見るなり、遊ぶなり、参加する場所であり、かつユーザが楽しむ場所であり、ユーザが他人を楽しませる場所です。
だから我々のブランドはStadiaといいます。これはスタジアムの複数形です。スタジアムはスポーツを行う場所ですが同時に誰もがエンターテイメントを楽しむ場所でもあります。だから我々はそれをブランドにしたかったのです。皆が遊んで、観て、参加して、さらにはゲームをする場所。一歩下がって見ることもできる場所。常にどのボタンを押したかを意識しないでも良い場所。他のアーキテクチャでは実現できない場所です。
その通りです。そして単純に技術的に深い点を求めて、我々は第一世代でも4K60fps、HDRとサラウンドをサポートしました。さらに開発者が必要なインフラに従ってスケールします。それだけでなく、同時にYoutubeに常に4K60fpsHDRで画像を送信することが可能です。だからあなたのゲーム体験の思い出は常に最高の状態になります。
プレーヤー次第です。Googleは全てを記録はしません。もしプレーヤーが望むならGoogleは4Kでストリームします
共有が友達だけか、世界中に公開かも自由に選択可能です。Googleはユーザに制御を明け渡します。もしユーザがYoutubeで公開すれば誰でもリンクをクリックすることでそのゲームを遊ぶことができます。
そう。そしてこれはマルチプレーヤーゲームのロビーの新しい形となります。Youtubeのクリエイターなら誰でもがファンやチャンネルのsubscriberを自分のゲームへと誘うことができます。生主として、Youtubeのクリエイターとして私は視聴者を私のゲームに瞬間的に招待できます。それが私と10人の友達でも、(訳注: セレブの)Matpatと彼の数百万の購読者でも、技術は同じです。
Googleアカウントの一部です。従ってGMailアカウントがStadiaへのログインに利用できます。他の基盤についても説明させて下さい。最初のサービス立ち上げから全ての画面への対応を行います。TV、PC、ラップトップ、タブレットに携帯です。我々のプラットフォームの基本は画面に依存しないことです。これまで40年間、ゲーム開発は端末依存でした。開発者として私は制約の範囲内で、私の創造性を開発対象の端末に合わせてスケールダウンする必要がありました。
我々はStadiaでそれを逆にしたいのです。我々は開発者に対し彼らの考えをスケールさせ、どの端末の縛りからも解放したいのです。パフォーマンスに優れ、リンクをクリックすればゲームは5秒以内に開始されます。ダウンロードもなく、パッチもなく、インストールも必要なく、アップデートもありません。多くの場合、専用のHWも必要がありません。従って古いラップトップでChromeブラウザを使用する場合にでも皆さんが既に持っているだろうHID仕様に準ずるUSBコントローラが動作します。そして、もちろん、我々自身のコントローラも開発中です。
コントローラを自作する理由にはいくつかあります。1つはTVへの接続です。我々はChromecastをストリーミング技術に採用します。Stadiaコントローラの最も優れた機能の1つはそれがWiFi接続でDC内のゲームに直接接続することです。ローカルのデバイスとは接続しません。
その通りです。これこそが我々のブランドの実現であり、具現化です。そして独自コントローラにより最高のパフォーマンスが実現します。ゲームに直接接続するためにプレーヤーは画面を移動することが可能です。プレーヤーはどの画面でも自由に遊び、停止し、他の画面でゲームに復帰することが可能です。
そしてコントローラには2つの追加されたボタンがあります。1つはGoogle Assistantの技術とマイクを用います。ユーザの選択により、ユーザはプラットフォームとゲームの双方に対し、自然言語を用いて会話が可能です。例えば「Hey, Google。MadjとPatrickと一緒にGame Xをやりたいな」と言えばStadiaがマルチプレーヤーゲームを指定した友人と共に直ぐに開始します。
我々はゲーマーを可能な限り素早くゲームに辿り着かせるよう考えています。数多くの研究を行いましたが、多くのゲーマーがゲームを起動したら直ぐに友人とゲームを開始したいと考えています。ゲーマーはUIに時間を費したくは無いのです。
誰かが言ったことですが、現在のコンソールは起動した時にまるで仕事のように感じると言うのです。ゲーム機自体の更新や、ゲームの更新があります。我々はそれらを完全に取り除きたいと考えています。もう1つのボタンは、ちょっと趣が異なるのですが、Youtubeにシェアできます。
Youtubeが観られるならどこでもStadiaは動きます。
Chromecastはスマホからストリームを受取はしません。Chromecastはスマホから命令のみ受けます。画像はNetflixやYoutubeから直接受け取ります。Stadiaの場合、StadiaコントローラからChromecastへとこのゲームのインスタンスへと接続せよと命令がなされ、Chromecastはゲームインスタンスから動画のストリームを受け取ります。クライアントはとてもシンプルです。行うのはネットワーク接続、ビデオと音声のデコードのみです。Chromecastは入力を処理しません。全て入力はコントローラが扱います。ビデオと音声とネットワーク接続はChromecastの基本動作で全て既に組込まれています。
そうです。とても良く出来ています。WiFiに繋ぐだけです。コントローラにはWiFiのIDとPWを入れるだけです。それだけです。ホームボタンを押すと勝手にChromecastを探し直ぐにChromecast上でクライアントを起動します。UIが表示され直ぐにゲームを遊ぶことができます。デジタルパッドでUIを操作することも可能です。これが重い処理を全てクラウドへと移行する点の美しさです。Chromecastのような低消費電力の端末で説得力のある体験ができます。Chromecastは5W位下です。Micro-USBで給電可能です。典型的なコンソールは100から150Wもします。またこれまで説明しませんでしたが、例えスマホでも行うことは動画の再生だけです。従ってAssassin's CreedやDoomや他の重いゲームがあなたのスマホの上でモバイルゲームよりも低消費電力で動作します。だからスマホで10時間でも遊べます。
今の所、我々はChromecastのみに集中しています。でも技術的、機能的な観点からはYoutubeがある場所ならどこでも動きます。我々はまだStadiaをどのようにユーザに届けるかは検討中です。
サービス開始時から提供されるサードパーティによる解決手段をサポートしています。他にもアイデアがあります。しかし今は話せません。
良い質問です。私がこのプロジェクトに参加する前からチームは既に何社かと提携しここ何年かの間に技術を提供していました。StadiaはLinuxベースです。グラフィックAPIはVulkanです。開発企業はクラウドにインスタンスを作成しますので、開発キットも今ではクラウドにあります。しかしクラウドだけでなく、開発社のプライベートなDCでも、机上のPCでも可能です。
もしそうしたいなら。でも我々は今後のトレンドが開発でも配布でもますますクラウドへと移行していくと考えています。従って今後数年で開発者にとってクラウド中心、クラウドネイティブがゲーム開発での標準となるでしょう。
デベロッパーやパブリッシャーはとても賢くクラウドネイティブとなる新しいゲーム体験を達成するために必要なツールや技術について考えていると思います。しかしそれは世界中で何千ものアクセスポイントを持つデータセンターを運営することや、それらの運営に必要な莫大な投資資本とは異なるものです。Googleは今年単年でも$13Bの資本を投下しています。
米国では全ての必要な場所に展開が終わっています。Project Streamの試験に必要な環境は2018年末には整いました。我々はGoogle社内で、Google社員を対象に2017年の始めから2年間の間、プライベートなテストを行ってきました。2019年には米、加、西欧、英にて Permalink | 記事への反応(1) | 06:10
角川は別として、漫画家がcloudflareに開示請求をした話。これは国内の漫画家が、弁護士を通して、東京地裁を管轄にした
http://nlab.itmedia.co.jp/nl/articles/1806/29/news105.html
これについて
いくら東京や大阪にデータセンタがあるとはいえ、なんでcloudflareの本社のあるアメリカで開示請求しないの?
日本だと情報開示請求にも馬鹿みたいに時間かかる上、ISP責任制限法だとロクな情報出ないのわかっててやるのは実績作るのが目的で実効があまりないのはわかってるのでは?っていう観測だった
こっちは日本の弁護士とMIAUが権利者と調整した上で、米国の弁護士事務所通して米国で訴訟起こした
https://www.buzzfeed.com/jp/takumiharimaya/manga-mura
cloudflareは淡々と対応して、ウチの利用料金はpaypal通して払われてるから必要ならpaypalに請求出してねとまで言ってる。
後者の方知らないやつまだいそう
来週もやるらしい
1 :2018/06/02(土) 16:50:22.10 ID:0zoDO79x0.net ?PLT(35669)
5ちゃんねるサーバ群が収容されているデータセンタにおいて給電装置の更新のため閲覧書き込みが出来なくなります
予定されている期間は以下の通りです
2018年6月2日(土)21時から2018年6月3日(日)10時
2018年6月9日(土)21時から2018年6月10日(日)10時
上記時間帯のうち最大5時間程度の停電が発生すると予想されています
http://rosie.5ch.net/test/read.cgi/operatex/1521902154/282
Scheduled maintenance on June 2 and June 9 between 5am pst and 6pm pst. Expect down times of up to 5 hours while we upgrade the power feeds in our data center.
自分がBitcoinという響きを初めて聞いたのは2015年くらいだろうか?当時はまだまだ日本語の情報も少なく、そのうち値上がりするんだろうなーと思いながらも気が重くて中々手が出せなかった。Coincheckという取引所に登録したこともあるが、クレカで入金したら10%くらい(正確には覚えていない)の法外な手数料を取られたのに驚愕し、1万円入金しただけで終わってしまった。(せめてBitcoinじゃないくてETHを買っていたら今頃もう少し美味しかったのだが、、、)
さて、下手に参入するタイミングを逃したので、今が天井なんじゃないかと思ってなかなか始める気になれない。
そんな自分も最近のバブルに釣られて、ついに重い腰を上げた。直接BTCもETHも買ってみたけど、今買っても高値掴みになるんじゃないかと思い、中々大金を突っ込む気にはなれない。
ここはエンジニアらしく自分でマイニングでもやってみるかと色々調べて見た。
仮想通貨の価格は上がっているが、価格が二倍になっても掘るためのコストは二倍にはならない(正確には参入者が増えるので、多少分け前は減る)
つまり、最近のバブルにも関わらず、掘る方の原価は変わらないので高値掴みは避けられる!という塩梅である。
ところが、今やビットコインは専用のハード(ASICとかFPGAとか)がないと勝負にならない世界らしい。イーサリアムはGPUで掘るしかないので手元の機材で挑戦できるものの、日本は世界でも電気代が高い部類らしく、自前でやってもあまり儲からないんだとか。(ケーブル抜けて電源落ちた拍子に、数万円で買ったグラボとマザーボードがオシャカになったブログが出てきて戦慄した、、)
一旦諦めかけたが、世の中にはクラウドマイニングという仕組みがあることが判明した。
要すれば、みんなが出したお金でマイニング装置をデータセンタのように一括購入、運用する仕組み。
出資者には金額に応じてマシンリソース(ハッシュパワーと言うらしい)が与えられて、BTCとかETHとか、指定したコインを掘ってくれる。
これってお得なのか?と思い調べてみた。
一応、散々調べた結果詐欺じゃなく運営がマトモなサイトで一番価格競争力があるここで試算した。(もっと安いとこもあるが、詐欺が大半らしい)
https://www.genesis-mining.com/
例えば今爆上がり中のイーサリアム用のマシンの価格は1MH/s で30USD、30MH/s で870USD(2年間利用できる)
とりあえず、30MH/sでナンボくらい掘れるのか計算してみる。
(この会社のプランは電気代コミコミなので、電気代は0にした)
今の採掘難易度で、1年間に6.41 ETH掘れるらしい。(現在のレートで$ 2,341.37)
。。。。これはありかも知れない。2年掘れる訳だけれども、仮に今の価格、採掘難易度が続いたとして、5倍くらいのリターンにはなる。
コインの価格が今バブルな一方で、クラウドマイニングの価格はそんなにまだ上がっていない。
ということで、上記 https://www.genesis-mining.com/ でイーサリアムの30MH/sプラン購入してみた。
クレジットカードで買ったので若干為替で損したけど、ネットに落ちていたプロモーションコードを入力したら3%引きになったので、マイルも貯まると思えばまあいいだろう。
ML9Tsp
ちなみに一日経過してETH 0.01749007掘れてたので、大体上記計算機の数値は信用できそう。
技術的にはAWSのGPUインスタンス借りて、自分でゴリゴリ設定して回した方が楽しいのだけど、とりあえず始めて見るにはいい価格感だと想う。GPUマシン自分で買うより安いし。壊れないし。