  |
はてなキーワード: コンピューティングとは
MATLABを使っているが、どうも中途半端な存在になっている。
①言語的な競合はもちろんPythonになるが、Pythonとの差別化が出来てない。
Python側は純粋なPythonだと遅いが、今はC++のラッパーとして使うのが多くなっており、Pythonの方が速いということが起こる。
最近のMATLABはJITコンパイラによって昔ほどfor文を気にしなくても良くなっているが、それでも遅さは気になる。
GPU、分散コンピューティングにMATLABは対応しているが、使いこなすのに苦労する。
GPU使う場合だと、CUDAをそのまま使いたくなるし、GPUメモリーとのやり取りといったオーバーヘッドが加わるので、
単純にGPU使うようにしたら速くなるってことはなく、処理時間を測りながらトライアルを繰り返すことになる。
MATLAB側のエディタは機能が増えているとはいえ、Python+VSCodeとの対抗となると辛いものがある。
toolboxを追加で課金してCコードを吐き出すことはできるが、劇的に速くなるわけではない。
②toolboxは沢山あるが、使い始めると色々足りておらず、Pythonのエコシステムが欲しくなる
toolboxが多くなりすぎていることと、手を広げすぎているのかtoolboxを買って使ってみると色々足りないことがある。
買う前に調べるわけだが、色んな事ができそうだと思って購入し、実際使っていくと、嘘は言ってないが事あるごとに使いにくい所が出てくる。
GUI周りに関しては不満が多い。
③GUIが重い、使いにくい
事あるごとにGUIが重たいのが気になって仕方ない。
また使いにくいのが多い。デザインが良いというのはコンシューマ用ではないので気にしないが、重たさと使いにくさで嫌になってくる。
④plotや可視化周りが重い
エクセルが普通になっている今、エクセルで出来ないことが出来て欲しいが、そうなっていない。
未経験から3ヶ月で外資IT勤めで年収1600万みたいなのがバズってたので
ただし俺の場合、実務が未経験なだけでプログラミング歴は20年ちょっとある、いわゆる趣味グラマからの転職
同人ゲーム制作やFLOSS系の活動はずっとやっていて、学生時代はバイトで出会い系サイト作ってた
前職の都合で自動車メーカーとも繋がりがあり、そのツテで昨今の自動車へコンピューティングを強く導入するという流れがあったので誘われて転職することになった
つまり草の根(もう死語だねコレ)の情報技術者が昔馴染みを頼って転職しただけと言ってしまえばその通りなのだ
こんな転職の仕方だからプログラミングスクール出身者のレベルがどんなもんだか知らんけど、もともと俺は電気系のオタクでシーケンスに関して理解があってH8あたりからプログラミングへ手を出しているって感じがスタートなんだ
たぶんイマドキの純粋培養な情報技術者の中には電気回路まったくわからんって人も居るとは思うけど、電気関係の素養があったほうがプログラミングの習得には今でも有利なんじゃないかな？と思わなくもない
例えば俺へ対してパソコン通信やインターネットを通じてプログラミングのノウハウを教えてくれたお兄さんたちはゲームメーカーでエレメカやってるって人が居たりして、後にゲームハードやROM作り始めたなんて話もリアルタイムに聞いていた。今じゃお偉いさんになってるだろうけど
そんなんだから俺はハードもソフトもネットワークもスペシャリストほどではないけれど満遍なく知る変な素養があり直接声がかかった次第だ
イマドキ流行りのGoとかSwiftとかRustみたいなイケイケな言語ではなくC++とかJavaとかBashとかの方が得意だっていうのも評価としてはあったかも知れないけどね
あと日常的なLinuxデスクトップ使いというのも最近のLinux興隆の流れから後押しがあったかも知れん
もちろん苦手な部分もある、GUIがそれだ
GUIの設計なんて言うものはデザイナーがやるべき仕事だね。今流行りのそれっぽいのとかツールチップ使いましたみたいな古典的なスタイルを真似たGUIを作ろうと思えば作れるけど、単なるモノマネなので本職のそれとは出来が違う
というわけでプログラミングスクール出身者、どこかで俺みたいな草の根出身者に出会うこともあるだろうから、そのときはヨロシクな
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
(ゲームの話は一切知らん)
いつのまにか「Webフロントエンドの動きが速い」とか誰も言わなくなってることにふと気付いた。なんというかソフトウェアをどう作るか、という問題にたいして大枠の部分では完全に固まってしまって、あとは個別の事情をどうやっていくかみたいな話しか残ってないように見える。
端的にいえば、宣言的UIとkubernetesは聖杯だったのではないかな。
k8sにかんしては「Cloud Runみたいのでいいじゃん」みたいな話はあると思うんだけど、Envoyほしいとかなってくると結局事実上k8s必須だし、今新しくアプリ作るときに宣言的UIじゃないフレームワーク使うこととかほぼ考えられんよな。で、こういう構成が定番ですね、みたいになってなんかもう数年は経つ気がする。結果として日本語でソフトウェア開発の話になるとチームビルディングがどうのみたいな話しかなくなってきていて、なんかつまんねーな、と思う。
wasm+エッジコンピューティングの進化でまたもっと全然新しいアーキテクチャが出てくるんだろうか。ぼくは今のところあんまりそんな気もしてなこないんですがどうでしょうか。結局そこでチマチマやって得られるユーザー体験の向上の果実って小さくねえか。とはいいつつ Cloudflare Workers でなんかできないかと遊ぶ日々なのだが。
このニュースいつみても有能だと思う
改善のビフォーアフターを数値で示していてベストプラクティスになっている
もちろんマス向けのサービスだから広告目的もあるのだろうけど、一般企業じゃこうはいかない
KADOKAWA Connected、日本最大級の動画コミュニティサービス
億単位のオブジェクト集中処理をこなし、約1/10のコスト削減と運用負荷軽減を実現
株式会社TwoFive（本社：東京都中央区、社長 末政 延浩）は、KADOKAWAグループ向けのICTサービスを提供する株式会社 KADOKAWA Connected（本社：東京都千代田区、代表取締役社長 各務 茂雄）が、日本最大級の動画コミュニティサービス「ニコニコ」のオブジェクトストレージ、および、グループ各社の社内ファイルサーバーのバックアップストレージとして米RSTOR社（アールストア、本社：カリフォルニア州）の高速クラウドストレージサービス「RSTOR」を採用したことを発表します。
「RSTOR」は、TwoFiveが国内代理店として今年9月に提供開始しており、KADOKAWA Connectedが動画配信サービスで使用する国内の第一号ユーザーとなります。
「ニコニコ」サービス向けのストレージには、サイトに表示する静的コンテンツ、ユーザーアイコンなどの画像ファイルなどが納められていますが、小さいサイズのデータに対するRead/Writeが多く、億単位のオブジェクトが集中します。多くのクラウドストレージサービスが、データ格納に課⾦するだけでなく、リクエストやダウンロードの容量 にも課⾦されるのに対して、「RSTOR」は、保存データの容量にのみ課金し、データの移動には課金がないのが特長です。現在は300TBで契約していますが、容量に対する定額課金のみで予測不能な追加費用は発生せず、KADOKAWA Connectedではオンプレミスの現行システムに比べても1/10近いコスト削減になると試算しています。
また、「RSTOR」は、独自プロトコルによる高速データ転送（他のクラウドストレージサービスより最大30倍高速）が特長ですが、大容量ファイルはもちろん、容量が小さなファイルも高速処理できるようにコンピューティングやネットワークを最適化しています。
そのため、現行システムでは、約1億のオブジェクトが集中した際に障害が発生したり、大量データの一括削除で操作不能になっていたのに対して、「RSTOR」では問題なく処理できることが、検証できました。
さらに、現行システムで性能維持のために約2ヶ月に1回、5人日を要していた定形作業が不要となり、障害発生時の対応コストがなくなることで、運用負荷が大幅に軽減される見込みです。
KADOKAWA Connectedは、KADOKAWAグループのDX（デジタルトランスフォーメーション）を推進する戦略子会社であり、「RSTOR」をグループ各社の社内ファイルサーバーのバックアップストレージとしても利用する他、データ活用を促進するためのストレージとして、今後積極的に適用範囲を拡大していく計画です。
数ある動画サイトの中で個性が光る「ニコニコ」は、グループ企業である株式会社ドワンゴ（本社：東京都中央区、代表取締役社長 夏野 剛）が提供し、KADOKAWAのWebサービス事業の中核となっており、現在280万人以上の有料会員が利用しています。KADOKAWA Connectedは、新しいサービスを開発や、品質改善のためにサービスを支えるインフラの刷新などに意欲的に取り組んでいますが、「RSTOR」の採用もその一環と位置付けられます。
Amazon S3 Glacierおよびオンプレミスのストレージによる従来システムの課題と、「RSTOR」採用に当たり評価されたポイントは以下の通りです。
「ニコニコ」サービス向けのオブジェクトストレージには、アプリケーション開発に必要なデータ（ビルド済みバイナリ、ログなど）やサイトに表示する静的コンテンツ（JavaScriptやCSSなど）、ユーザーアイコンなどの画像ファイルなどが納められます。
現行の製品や検討した他社ソリューションは、アーカイブ用途がメインの製品が多く、小さいサイズのデータに対するRead/Writeが多い「ニコニコ」の用途にマッチしていませんでした。「RSTOR」は、必要とされる性能を十分以上に満たせることが検証で確認できました。
(2) システムの安定性
現行システムで、1バケットの同じ階層に1億近いオブジェクトが集中したときに障害発生したのに対し、「RSTOR」は同規模のデータを入れても良い性能が得られました。また、現行システムで、大量のデータの一括削除で操作不能になるのに対して、RSTORでは問題なく処理できました。
「RSTOR」は、容量に対する課金のみでデータアウトとリクエスト数課金がなく、また、容量単価もAmazon S3 Glacierにほぼ近い金額でアクティブストレージが使用できます。30TBで数億オブジェクトのコストを比較すると、1/10近いコスト削減になると見込んでいます。
(4) 運用負荷の低減
現行システムでは、性能維持のために約2ヶ月に1回定形作業が必要でその作業に5人日かかっていましたが、「RSTOR」ではその運用コストが不要となり、また、障害発生時の対応コストがなくなることで運用負荷が大幅に軽減されます。
オリンピック開催中にアフリカ系アメリカ人の一人から変異体のウィルスが発見された。そのウイルスはまたたく間に東京を覆い、その中から意識を通じる能力を獲得する者達が現れる。その頃米国のCIAは中国が秘密裏に開発していたコロナウィルスの変種が存在することを突き止めた。CIA諜報員□□は日本に発生したPSY体質の者達に接触する。
封鎖が続く日本にて、新たな国中国が誕生する。その生誕はまるで集団的な意思を持っているかのように思えた。しかし、神性民主主義共和国を掲げたその集団は客観的に見ても生産手段を持たなかった。
一方中国では、日本の中に発生させたナノマシンが暴走したことを懸念していた。それはコロナウイルスに偽装された形で持ち込まれ、爆発的に自己増殖するようにプログラムされていた。しかし、そこから新たな能力を獲得する人類が誕生することは想定外であった。
共和国の者達は世界中の情報という情報を収集し始め、その情報を輸出産業として切り売りし始める。この姿勢に世論は共和国への避難を強めたが、国家のコントロールを考える各国元首たちの耳には届かない。やがて共和国の狙いが、ナノマシンを主体としたナノ・グリッド・コンピューティングを形成することである、と言う事実が□□によって判明した。彼らは『バベルの塔』と呼ばれる巨大建築物を作り出し、すべてはナノマシンに支配され、同調すべきであるという指針を打ち出すのだった。
辛くも日本から逃げ延びた□□は、この凶行を前にして軍事的作戦に乗り出すよう米国の指示を仰ぐ。しかし上層部の足並みは揃わず、ナノマシンによる侵食は世界の半分を覆い、世界は2つに分断される。
補足：作り方によっては二部構成も作れる。
我が家は明治期に興隆した商家で、現在も大枠を考えればモノやコトを売ることで生計をなしている。
いわゆる華族であったが、興隆の経過で江戸期以前の地主や武家などと婚姻を経て結びついており、家系図を遡れば皇室とも血筋上の繋がりがあると解釈ができる。
さて、そんな家に生まれた筆者だが正直に言えば高校生くらいまで我が家がそんな家だとは気付いておらず、多少なりとも大きな家に住めている理由として両親や祖父母も「ご先祖様が努力の人だったから」と言っていたので、現在の我が家はそこまでお金持ちではなくご先祖様が増やした資産の恩恵を受けているのだ程度にしか思っていなかった。ご先祖様すげぇなと。
実際、筆者自身の子供の頃の夢はプロアーチャーであったので全く家業を意識していなかった。
我が家はなんか他の家と違うぞ？と気付き始めたのは高校生になった時期で、父や祖父に連れられて社会科見学のような小旅行を頻繁にやるようになってからだった。
自動車工場や造船所、食品工場、アパレル工場、精密機器工場、製紙工場など工業系を中心になぜか見学に連れられ、その工場の担当者らしき壮年の男性から説明を聞くということを頻繁にさせられた。
今思い出せば、父や祖父はそのくらいの時期から「AはBから生産されていて流通として……」のような話をよくしてくれるようになっていた。
社会科見学のような小旅行は面白かったが、なぜ急にそんなことをやるようになったのかという疑問は晴れなかった。まさかそれが後継者教育の一環だったとは。
自分自身の興味と祖父の勧めもあり、大学ではアーチェリーを続けつつもロジスティクスを中心に学ばせてもらい、継続されていた社会科見学が非常に研究へ役立つようになっていた。
そして我が家の歴史を完全に知ったのは大学3年生の正月に「就職はどうするのか？」と言われた際に「参考になるかはわからないが我が家の家業を説明しようか」のように教えられてからだった。
遡れば初代が江戸期に商家として暖簾分けを受け、現在まで続く家業の基盤を明治期に作ることができたとのこと。そこから登場する人名は歴史の授業で習うような人々であり、まるで実感のなかった筆者は驚愕するしかなかった。
そんな家の子息である筆者が普段何をしているのか？と言えば、某物流企業から某商社を経て、現在は父から「そろそろ戻ってこい」と言われ、法人化している我が家の持ち企業へ務めさせていただいている。
筆者の専攻がロジスティクスなので新社会人の頃から数理的に物流を計算するのが主な仕事で、笑ってしまうかも知れないが何処へ行くにもCASIOの関数電卓をポケットへ入れている。現在の関数電卓はソーラーパネル電池で駆動するのでスマホなんかよりもよっぽど信頼度が高い。
弊社が集めたデータや取引先からロジスティクスに関するデータを貰い、それを数理的に損益分岐点とのその確率をはじき出すというものだが、概算ではなく精密に計算する際はコンピューターに詳しい増田の皆様にも馴染み深いであろうAWSやさくらを利用している。
ちなみに筆者のスマホはAndroid。iPhoneにはまともなターミナルがないので、ふと出先で大きな計算リソースが必要になったときAWSへSSHしにくい。まぁノートPC使えよって話だが。
もちろん計算するだけでなく、創作物でイメージされやすいであろう会食などで人脈交流をしたりもするが、実際のところ筆者の世代ともなるとLINEやZoom、Slackなどで友人たちと交流している頻度のほうが多い。
正直LINEやZoomは昨今の流れもあり使いたくないのだが友人たちは経営学部卒などの文系が多いので、どうもセキュアなコミュニケーションツール活用が上手く行かない。
可能ならば弊社で利用しているオフィススイートもMicrosoft office 365やGoogle Workspaceへ移行したいのだが、一部の従業員の皆様の反発から上手く行ってない。後継者といっても実務へ強権を奮えるほど実力はないのだ。筆者の管轄の研究グループは即座にSlackを導入できたり出来たのに。う〜む……。
流れのまま愚痴を言えば、例えば総務などはミドル〜ハイエンド性能なChromebookで十分じゃないか？社内ツールもいつまでJavaベースのを使っているのか。HTML5ベースに移行してしまえば互換性の問題でWindows使い続ける理由もないんだが。いまだ動いてる骨董品メインフレームをそろそろ引退させてあげようよ。
父は「実務に口を出すべきでない」と言うが、多少筆者の趣味も入ってはいるものの環境を整えるのも我々の役目ではないだろうか。
強権を奮って一気にモダンなコンピューティング環境にしたい。営業にも今のガラケーから最新のGoogle Pixel 5あたりのスマホを配ってあげるのに。
というようなことを青臭く思っているのだが、実際の後継者なんてこんなもんである。実権を握れるまでおとなしくしているしか無い。
従業員の皆様には申し訳ないが、おそらく筆者にはご先祖様ほどの商才は無いんだろう。苦労させてごめんね。
機械翻訳です。
#####
デルテクノロジーズ、VMwareの81%の株式をスピンオフし、VMwareのさらなる成長につなげる
Dell Technologiesとの戦略的パートナーシップを維持しつつ、VMwareに戦略的および経営的な柔軟性をもたらす
VMwareは全株主に対して115億ドルから120億ドルの特別配当を実施し、投資適格格付けを維持する予定
米カリフォルニア州パロアルト--(BUSINESS WIRE)--(ビジネスワイヤ) -- 独立取締役で構成されるVMware(NYSE: VMW)特別委員会とデル・テクノロジーズは、VMwareをデル・テクノロジーズから分離独立させる条件に合意しました。この条件には、企業の所有構造の大幅な簡素化と、独立した特別委員会が推奨し、VMware取締役会がスピンオフの直前にすべてのVMware株主に対して宣言した115億ドルから120億ドルの特別現金配当が含まれており、すべての閉鎖条件が満たされることを条件としています。Dell Technologiesの株主は、Dell Technologiesが保有するVMwareの株式を比例配分で受け取ることになり、Michael DellとSilver Lake PartnersはVMwareの株式を直接保有することになります。また、両社は、共同で顧客価値を提供するための戦略的パートナーシップを維持・強化する商業契約を締結しました。
ヴイエムウェアのビジョンは、あらゆるクラウドやハードウェアインフラに対応したユビキタスなソフトウェアおよびSaaSプラットフォームを構築し、顧客のデジタルトランスフォーメーションを加速することです。デルテクノロジーズからのスピンオフにより、ヴイエムウェアは、両社の戦略的パートナーシップの強みを維持しつつ、戦略実行の自由度を高め、資本構造とガバナンスモデルを簡素化し、戦略、運用、財務の柔軟性を高めることができます。
"ヴイエムウェアの最高財務責任者(CFO)兼暫定最高経営責任者(CEO)であるゼイン・ロウは、「当社は、すべてのクラウドベンダーおよびオンプレミスのインフラベンダーに当社のエコシステムを拡大する能力を強化し、成長機会を支援する資本構造を持つことになります。"デルテクノロジーズとの戦略的パートナーシップは引き続き当社の差別化要因であり、マルチクラウド戦略の実行に伴い、あらゆるパブリッククラウドとあらゆるインフラストラクチャ上で、お客様に当社のソリューションとサービスを提供していきます」と述べています。
2020年7月15日に提出されたDell TechnologiesのSchedule 13D修正に関連して、VMwareの取締役会は、Dell Technologiesの提出書類に記載されたビジネスチャンスに関するDell Technologiesからの提案の可能性を検討・評価するために、法律顧問および財務顧問を起用した独立取締役からなる特別委員会を設置しました。特別委員会は、VMware社の取締役会による本取引および特別現金配当の承認を評価し、推奨しました。
"VMware特別委員会は、今回のスピンオフ契約が、簡素化された資本構造を確立し、VMwareがその戦略を実行する上で有利に働くことで、すべての株主に利益をもたらすものと確信しています」と、VMwareの独立取締役会の筆頭メンバーであり、特別委員会のメンバー、報酬・コーポレートガバナンス委員会の委員長であるPaul Sagan氏は述べています。
"ヴイエムウェアの取締役会長であるマイケル・デルは、「ヴイエムウェアをスピンオフさせることで、デル・テクノロジーズとヴイエムウェアにさらなる成長機会をもたらし、ステークホルダーに大きな価値をもたらすことができると期待しています。"両社は今後も重要なパートナーであり続け、お客様にソリューションを提供する方法において、差別化された優位性を持っています」と述べています。
ヴイエムウェアとデルテクノロジーズは、この商業契約を通じて、顧客に戦略的価値を提供するソリューションの共同開発を継続し、デルテクノロジーズはヴイエムウェアの製品ポートフォリオに市場規模を提供します。
今回のスピンオフにより、VMwareは、成長戦略を推進するための戦略的、運用的、財務的な柔軟性と俊敏性を高めることができます。これには、資本配分の決定の簡素化や、現在のデュアルクラスの株式構造の廃止などが含まれます。また、VMware社は引き続き投資適格の格付けとプロファイルを維持します。
ヴイエムウェアが全株主に提供する115億ドルから120億ドルの特別現金配当の推定額は、2021年3月16日時点の発行済み株式に基づいて、1株当たり27.43ドルから28.62ドルとなっています。
この取引は、一定の条件のもと、2021年暦年の第4四半期中に完了する予定です。
VMwareは、2021年4月14日午後5時45分(米国東部時間)より、本取引の詳細について説明するインベスターコールを開催します。このイベントのライブWeb放送は、VMwareの投資家向けウェブサイト(http://ir.vmware.com)でご覧いただけます。ウェブ放送にはスライドが添付されます。ウェブ放送とスライドの再生は、同ウェブサイトで2ヶ月間公開されます。
VMwareについて
ヴイエムウェアのソフトウェアは、世界の複雑なデジタルインフラストラクチャを強化します。クラウド、アプリケーションのモダナイゼーション、ネットワーキング、セキュリティ、デジタル・ワークスペースなどのサービスを提供することで、お客様があらゆるクラウド上であらゆるアプリケーションをあらゆるデバイスに提供できるよう支援しています。カリフォルニア州パロアルトに本社を置くヴイエムウェアは、画期的なテクノロジー・イノベーションから世界への影響まで、「良い方向に向かう力」となることを目指しています。詳細については、https://www.vmware.com/company.html。
追加情報とその入手先
VMwareは、株主の承認を必要とする特定の事項の承認に関して、Schedule 14Cによる株主向けの情報提供書を作成します。情報提供書は完成後、当社の株主に郵送されます。この取引に関してVMwareがSECに提出したすべての文書のコピーは、SECのウェブサイト(www.sec.gov)またはVMwareのウェブサイト(https://ir.vmware.com/)から無料で入手することができます。
将来の見通しに関する記述
本プレスリリースには、提案されているスピンオフの予想時期、完了、効果および利点、特別現金配当の支払い、規模および1株当たりの金額、VMwareの将来の投資評価およびプロファイル、スピンオフ後のVMwareとデルテクノロジーズの戦略的パートナーシップ、商業的取り決めおよび協力関係、VMwareの事業戦略およびビジョン、将来の成長機会に対する期待など、将来の見通しに関する記述が含まれています。これらの将来の見通しに関する記述は、1995年米国私募証券訴訟改革法によって創設されたセーフハーバー条項の対象となります。
VMwareは、
(1)分離・分配契約の終了の原因となる事象、変化またはその他の状況の発生、
(3)VMwareのその他の失敗、
(4)その他の要因により、提案されている取引を上記の条件またはその他の受け入れ可能な条件で、または全く完了できない可能性があります。
(3)その他、VMwareまたはDell Technologiesがスピンオフの完了および特別現金配当の支払いのための契約条件を満たさないこと、
(4)VMwareが特定の格付け機関の基準を満たさないこと、
(5)スピンオフおよび特別現金配当の発表がVMwareおよびDell Technologiesの戦略的および商業的関係に与える影響、ならびにVMwareが主要な人材を維持・雇用し、顧客との関係を維持する能力に与える影響。6)COVID-19パンデミックがVMwareの事業、財務状況、VMwareの顧客、ビジネス環境、世界経済および地域経済に与える影響、
(9)価格圧力、業界の統合、仮想化技術への新たな競合他社の参入などを含むがこれらに限定されない競争要因。10)買収した企業や資産をVMwareに正常に統合し、VMwareから売却した資産に関連するサービスを円滑に移行する能力、
(11)仮想化ソフトウェアおよびクラウド、エンドユーザー、エッジおよびモバイル・コンピューティング、セキュリティおよびテレコム業界における急速な技術革新、
(12)仮想化ソフトウェアおよびクラウド、エンドユーザー、エッジおよびモバイル・コンピューティング、セキュリティおよびテレコム業界における急速な技術革新。
(12) コンテナ化、最新アプリケーション、本質的なセキュリティとネットワーキング、クラウド、デジタル・ワークスペース、仮想化、通信とエッジ・コンピューティング、ソフトウェア定義データセンターなどの分野で、VMwareの顧客が新しい製品、プラットフォーム、サービス、ソリューション、コンピューティング戦略に移行する能力、および顧客が新しいテクノロジーを受け入れる際の不確実性、
(13) VMwareがスピンオフ後に戦略的に効果的なパートナーシップを締結し、協力関係を維持、拡大する能力。
(17)サイバー攻撃、情報セキュリティ、データ・プライバシーに関連するリスク、
(18)主要な経営陣の交代による混乱。19)為替レートの変動や貿易障壁の増加など、国際的な販売に伴うリスク、
(21)VMware社とDell Technologies社それぞれの財務状況や戦略的方向性の変化により、VMware社とDell Technologies社の商業関係や市場開拓のための技術協力に悪影響を及ぼす可能性があること。22)VMware と Dell Technologies の商業関係および市場開拓と技術提携におけるスピンオフと変更が、顧客やサプライヤーとの関係を維持する VMware の能力、および VMware の経営成績と事業全般に及ぼす影響、
(23)配当基準日における VMware の発行済株式数、および
(24)SEC に提出した当社の定期報告書および現在の報告書の「リスク要因」のセクションで述べられているリスクなどです。これらの将来の見通しに関する記述は、本プレスリリースの日付の時点でなされたものであり、現在の予想に基づいており、不確実性や状態、重要性、価値、効果の変化、およびVMwareが随時提出するForm 10-KおよびForm 10-Qの最新のレポートやForm 8-Kのカレント・レポートを含む、米国証券取引委員会に提出された文書に詳述されているその他のリスクがあり、実際の結果が期待と異なる可能性があります。VMwareは、本リリースの日付以降、そのような将来の見通しに関する記述を更新する義務を負わず、現時点ではその意図もありません。
businesswire.comでソースバージョンを見る： https://www.businesswire.com/news/home/20210414005849/en/
pziots@vmware.com
650-427-3267
マイケル・タッカー(Michael Thacker)
mthacker@vmware.com
650-427-4454
Source: VMware, Inc.
FORTRAN、MATLAB、Mathematicaなどでプログラミングをするのが広く行われていた時は、物理と結びついていたと思う。
ゲームは今でも物理と結びついているものの、レンダラー用のプログラムを書く人、物理エンジンを書く人は少ないのではないだろうか。
日本のPythonの本で、例えばマランゴニ効果などを計算して3Dで表示するなんてことは見たことない。
Webが強いのは確かだが、物理屋はほぼほぼ全滅しているのではないだろうか。
プログラム関係でアルゴリズムで探すと、物理解析に役に立つコンピューティングよりのアルゴリズムは更新されてない気がする。
そもそも半世紀以上の間デスクトップ／キーボード／タイピングオリエンテッドの2本腕のコンピューティング操作がのさばってる状態のほうがおかしいだろ
音声指示／文章理解／フィジカルジェスチャの時代が次のこの１０年だろ？
”なんか家計簿つけたいから情報取って記録できるようにして。ペイメントとか銀行口座の認証いるなら要るとき声かけて”
ってコンピューターに声かけたらコンテナ構成とかかき集めてくれて3分でサーバー建って記録が始められるとかそういうのでいいじゃんお前なんか介在してくれなくていいわ。
なんで村の長老とか呪術師みたいなオヤジに頭下げて何やってるか分からん祈祷みたいな呪術文を書くのに金銭を貢いだうえに有難がらないといけないのかがサッパリ分からんわ
おまえらの仕事を守りたいために面倒にしてるだけだからいまコロナで批判されてる自称医者や官僚と振る舞いとしては何も変わらんよな
村の脳筋老いぼれマウント爺を太らすくらいなら遠い海の向こうからやってきたと神の生まれ変わりを祖とするらしいなんか凄いっぽい宗教の伝道師とやらに寄進したほうがよっぽどご利益あるし、実際に最新の土木とか治水とかも教えてくれるし。
近くのしきたりに縛られて馬鹿に頭下げるくらいなら、遠くの神に全てを預けて天に召されるまで信心してるほうがよっぽどマシだわ
令和2年12月14日
「新型コロナウイルス、SARS-CoV-2の分子構造を解析する」と謳い、
グリッドコンピューティングへのボランティア参加を呼びかけていた組織が、実は集めた計算能力をビットコインの採掘に利用していた事実がWall Street Timesの取材で明らかにされました。
この組織はリトアニアの大学生15人から構成され、ウェブサイト上ではブルガリアの分子生物学研究所を騙ってプログラムを配布。表面上は実際に分子構造の解析用プログラムを起動させながらも、裏ではビットコイン採掘用プログラムが稼働し、配布開始から先週迄の2箇月間に推定600BTC（約12億円）の採掘に成功したと見られています。
ボランティア参加者は世界中で1000万人を超えており、日本でも有志により結成されたTeamFivechが世界第4位の貢献を果たした事が話題を呼びました。今回の事件は世界規模の感染症を利用した世界規模の詐欺と言えそうです。
リトアニア警察は現在容疑者全員の身柄を確保していますが、押収されたビットコインは70BTC（約1億4000万円）程度で残りの行方は判っていません。
また報道後にはビットコインの価格は30%近い値下がりを見せましたが、報道の1週間前にも一時ビットコイン価格が大きく値を下げていた点から、容疑者等の背後には大口投資家の存在が疑われています。
令和2年12月31日
勤務するテレビ局の番組企画を装い、架空の企画への協力を大学や企業に依頼したクジテレビAD日枝好男容疑者が、名誉毀損並びに業務妨害の疑いで逮捕されました。
日枝容疑者は今年1月から8月にかけて「タピオカそっくりのこんにゃくをタピオカドリンクに入れ何も知らない客に売り反応を見たい」「6大学の学長にお互い異なる大学の入試問題を解いて貰いたい」等と架空の企画を持ちかけ、その予算や人員を大学や企業に無償提供させようとした疑いが持たれています。
日枝容疑者は調べに対し「仕事に不満が有り、図々しい企画を依頼する事で自社の評判を貶めたかった」と容疑を認めているという事です。
令和3年4月3日
DAU10億人超のSNS、Weisbookの利用者の約10%の個人情報が、半年前の6月頃から何者かにハッキングされ書き換えられていた事件の続報です。
WeisBook社の発表ではこれによる個人情報の漏洩は現在確認されていないとの事で、またハッキングされた箇所にはGender Unknown Movementを意味する「GUM」の文字が羅列されており、昨年発生した「性別不明運動」を推進する為の思想的な犯行と見られています。
GUMとは、性別欄への記入に抵抗を抱く人達を支援する目的から、抵抗を持たない人も敢えて自分の性別を不明と表明するか逆の性別を表明する事により性別情報の無意味さを主張し、将来的に個人情報の記入項目から性別欄を無くそうという趣旨で始まった社会運動です。Weisbookは旅券や免許証等の公的書類に準拠した個人情報のみを記入できる仕様なのでこの運動とは無縁の立場でした。Weisbook社では、性別情報の自由な書き換えは仕様上起こり得ないという思い込みからハッキングに気付くのが遅れたと報告しています。
今回の事件には社会学者、経済学者が大いに注目を寄せました。何故なら、Weisbook上に表示される広告は個人情報を基準として個人最適化された種類が選択される仕組みだからです。
性別という消費性向に強く結び付いていると思われる情報が間違っていた場合、男性に化粧品、女性に髭剃りといった見当違いの広告が表示されCTR（Click Through Rate）は下がる筈ですが、ハッキングが起きた6月から情報が修正される1月迄の6箇月間で、ハッキングされていないアカウントのCTRが前年比0.8%減少していた所、ハッキングされたアカウントのCTRは前年比0.3%増加していたという事です。
Weisbook社では、性別以外の個人情報を多く揃えている為個人最適化に対する影響は小さかったと分析していますが、性別という情報が広告の個人最適化を行う上で経済的価値を持つのかを疑問視させる結果が浮き彫りに成りました。
ミスカトニック大学データサイエンス学部のフィリップス教授は「普段どのウェブサイトを見ても個人最適化された広告ばかりが表示される中、そうではない広告の物珍しさが功を奏した結果ではないか」と語っています。
