「コンピューティング」を含む日記 RSS

はてなキーワード: コンピューティングとは

2022-04-25

MATLABは今後どういう扱いになるのか

MATLABを使っているが、どうも中途半端存在になっている。

端的にいうと、お金を払っただけの価値があるか、だ。


言語的な競合はもちろんPythonになるが、Pythonとの差別化が出来てない。

Python側は純粋Pythonだと遅いが、今はC++ラッパーとして使うのが多くなっており、Pythonの方が速いということが起こる。

最近MATLABJITコンパイラによって昔ほどfor文を気にしなくても良くなっているが、それでも遅さは気になる。

GPU分散コンピューティングMATLAB対応しているが、使いこなすのに苦労する。

GPU使う場合だと、CUDAをそのまま使いたくなるし、GPUメモリーとのやり取りといったオーバーヘッドが加わるので、

単純にGPU使うようにしたら速くなるってことはなく、処理時間を測りながらトライアルを繰り返すことになる。


MATLAB側のエディタ機能が増えているとはいえPython+VSCodeとの対抗となると辛いものがある。


toolboxを追加で課金してCコードを吐き出すことはできるが、劇的に速くなるわけではない。



②toolboxは沢山あるが、使い始めると色々足りておらず、Pythonエコシステムが欲しくなる

toolboxは追加課金で開放されるDLCだ。

toolboxが多くなりすぎていることと、手を広げすぎているのかtoolboxを買って使ってみると色々足りないことがある。

買う前に調べるわけだが、色んな事ができそうだと思って購入し、実際使っていくと、嘘は言ってないが事あるごとに使いにくい所が出てくる。

GUI周りに関しては不満が多い。



GUIが重い、使いにくい

事あるごとにGUIが重たいのが気になって仕方ない。

また使いにくいのが多い。デザインが良いというのはコンシューマ用ではないので気にしないが、重たさと使いにくさで嫌になってくる。


④plotや可視化周りが重い

エクセル普通になっている今、エクセルで出来ないことが出来て欲しいが、そうなっていない。



色々書いたが、MATLAB中途半端なのだ

そりゃ便利な場合もある。あるが、かなり限定的だったりする。

2022-04-04

実務未経験から情報技術者として転職大手自動車メーカーへ勤めてる

経験から3ヶ月で外資IT勤めで年収1600万みたいなのがバズってたので

ただし俺の場合、実務が未経験なだけでプログラミング歴は20ちょっとある、いわゆる趣味グラマから転職
同人ゲーム制作やFLOSS系の活動はずっとやっていて、学生時代バイト出会い系サイト作ってた
前職の都合で自動車メーカーとも繋がりがあり、そのツテで昨今の自動車コンピューティングを強く導入するという流れがあったので誘われて転職することになった
まり草の根(もう死語だねコレ)の情報技術者が昔馴染みを頼って転職しただけと言ってしまえばその通りなのだ

こんな転職の仕方だからプログラミングスクール出身者のレベルがどんなもんだか知らんけど、もともと俺は電気系のオタクシーケンスに関して理解があってH8あたりからプログラミングへ手を出しているって感じがスタートなんだ
たぶんイマドキの純粋培養情報技術者の中には電気回路まったくわからんって人も居るとは思うけど、電気関係素養があったほうがプログラミング習得には今でも有利なんじゃないかな?と思わなくもない
例えば俺へ対してパソコン通信インターネットを通じてプログラミングノウハウを教えてくれたお兄さんたちはゲームメーカーエレメカやってるって人が居たりして、後にゲームハードROM作り始めたなんて話もリアルタイムに聞いていた。今じゃお偉いさんになってるだろうけど

そんなんだから俺はハードソフトネットワークスペシャリストほどではないけれど満遍なく知る変な素養があり直接声がかかった次第だ
イマドキ流行りのGoとかSwiftとかRustみたいなイケイケな言語ではなくC++とかJavaとかBashとかの方が得意だっていうのも評価としてはあったかも知れないけどね
あと日常的なLinuxデスクトップ使いというのも最近Linux興隆の流れから後押しがあったかも知れん

もちろん苦手な部分もある、GUIがそれだ
GUI設計なんて言うものデザイナーがやるべき仕事だね。今流行りのそれっぽいのとかツールチップ使いましたみたいな古典的スタイルを真似たGUIを作ろうと思えば作れるけど、単なるモノマネなので本職のそれとは出来が違う

というわけでプログラミングスクール出身者、どこかで俺みたいな草の根出身者に出会うこともあるだろうから、そのときはヨロシクな

2022-03-21

anond:20220319214152

科学分野だと「いきち」で、コンピューティングだと「しきい値」なんだよな。

読み方。

2022-03-06

anond:20220306144905

ありがとう勉強になりました。

特にステートレスとモノシリックのあたり。

デプロイの際、どうしてもコンピューティングリソースベースで考えてしまうんだけど、この考えもいずれ古くなっていくのかな。

今のところはリソースは有限かつ課金制という前提でほとんどのクラウドは動いているけれども。

リソースをほぼ意識しないクラウドゲーミングの世界なんかに近いのかな。

先進的な考え方だから注視はしていきたいと思います

2022-01-29

anond:20220129073652

コンピューティングリソース意識しないで済むってことなのかな

しろ意識するようになるよ。

時間単位とかトラフィック単位で掛け算で料金が膨れ上がっていく。

設定などミスる天文学的料金を請求される可能性もあるので、リソース無茶苦茶意識するようになる。

ドルアプリ単位での課金、みたいな。

そういう場合もあるし、もっと広い範囲ボト範囲での課金場合もあるし。

サービス形態契約によっても異なる。

まあとにかく一つだけ確実に言えるのは、こいつが頭おかしいということだけ↓

https://anond.hatelabo.jp/20220128174902

anond:20220129071406

横だけど自分も完全に理解してない

コンピューティングリソース意識しないで済むってことなのかな

ドルアプリ単位での課金、みたいな。

まちがってたら教えて

2022-01-25

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービス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の登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービス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の登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

2021-12-15

anond:20211215073257

そういうのはそういうので、SBCシングルボードコンピュータ)というジャンルがそれなりに盛り上がっている。主に8ビットCPUボード。たまに68000とかも。いわゆるレトロコンピューティング趣味ね。あのへんなら個人趣味でもなんとかなるレベルから

2021-11-26

ソフトウェア開発の進歩完全に止まったような気がする

(ゲームの話は一切知らん)

つのまにか「Webフロントエンドの動きが速い」とか誰も言わなくなってることにふと気付いた。なんというかソフトウェアをどう作るか、という問題にたいして大枠の部分では完全に固まってしまって、あとは個別事情をどうやっていくかみたいな話しか残ってないように見える。

端的にいえば、宣言UIkubernetes聖杯だったのではないかな。

k8sにかんしては「Cloud Runみたいのでいいじゃん」みたいな話はあると思うんだけど、Envoyほしいとかなってくると結局事実上k8s必須だし、今新しくアプリ作るとき宣言UIじゃないフレームワーク使うこととかほぼ考えられんよな。で、こういう構成定番ですね、みたいになってなんかもう数年は経つ気がする。結果として日本語ソフトウェア開発の話になるとチームビルディングがどうのみたいな話しかなくなってきていて、なんかつまんねーな、と思う。

wasm+エッジコンピューティング進化でまたもっと全然新しいアーキテクチャが出てくるんだろうか。ぼくは今のところあんまりそんな気もしてなこないんですがどうでしょうか。結局そこでチマチマやって得られるユーザー体験の向上の果実って小さくねえか。とはいいつつ Cloudflare Workers でなんかできないかと遊ぶ日々なのだが。

2021-11-02

わかるー

https://twitter.com/fujiwara/status/1455331866630778883

国産クラウド云々の話、IaaS的に使うならどこでもいいと思うんだけど、AWS最初にS3とSQSから始まってEC2にはしばらくエフェメラストレージしかなかった、つまりデータ永続化マネージドに任せてコンピューティングノード使い捨てろという思想最初から徹底していたのを思うと

国産のはどうしても、EC2で全部やる的な使い方に寄ってる気がして、スケールに対する思想の違いを感じるんだよなあ

飲んでいて酔っ払うとS3はほんとすごくて、S3が盤石だから他のが成り立ってる部分がある、EC2EBS最初じゃないところが凄い、って力説しがち。いや、最近人と飲んでないけど

https://twitter.com/tagomoris/status/1455428553634312193

超わかる、国産クラウド使えっていう人はとりあえずS3とSQS作れるか真面目に考えてから言ってほしい

2021-10-21

日本IT敗戦理由って、SIerだけじゃなくね?

日本IT敗戦理由って、SIerだけじゃなくね?

そもそも 2010年頃に車とか家電組み込みシステム屋が強すぎたからじゃね?

ユビキタスとかエッジコンピューティングとかうるさいんじゃ

車載電子部品老害メーカーには令和になっても血税プロジェクトで金をブチ込むのに

Web クラウド アド セキュリティ会社にはお金くれないんだな

嫌になっちゃうよ

2021-09-23

ニコニコ」用に高速クラウドストレージ「RSTOR」を採用

このニュースいつみても有能だと思う

改善ビフォーアフターを数値で示していてベストプラクティスになっている

もちろんマス向けのサービスから広告目的もあるのだろうけど、一般企業じゃこうはいかない

KADOKAWA Connected日本最大級動画コミュニティサービス

ニコニコ」用に高速クラウドストレージ「RSTOR」を採用

2020.12.10 発表

データ転送料金なしで、頻繁なRead/Write要件に最適

単位オブジェクト集中処理をこなし、約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」をグループ各社の社内ファイルサーバーバックアップストレージとしても利用する他、データ活用を促進するためのストレージとして、今後積極的適用範囲を拡大していく計画です。

従来の課題採用ポイント

数ある動画サイトの中で個性が光る「ニコニコ」は、グループ企業である株式会社ドワンゴ本社東京都中央区代表取締役社長 夏野 剛)が提供し、KADOKAWAWebサービス事業の中核となっており、現在280万人以上の有料会員が利用していますKADOKAWA Connectedは、新しいサービスを開発や、品質改善のためにサービスを支えるインフラ刷新などに意欲的に取り組んでいますが、「RSTOR」の採用もその一環と位置付けられます

Amazon S3 Glacierおよびオンプレミスストレージによる従来システム課題と、「RSTOR」採用に当たり評価されたポイントは以下の通りです。

(1) 性能とスケーラビティ

ニコニコサービス向けのオブジェクトストレージには、アプリケーション開発に必要データビルド済みバイナリログなど)やサイトに表示する静的コンテンツJavaScriptCSSなど)、ユーザーアイコンなどの画像ファイルなどが納められます

現行の製品検討した他社ソリューションは、アーカイブ用途がメインの製品が多く、小さいサイズデータに対するRead/Writeが多い「ニコニコ」の用途マッチしていませんでした。「RSTOR」は、必要とされる性能を十分以上に満たせることが検証確認できました。

(2) システムの安定性

現行システムで、1バケットの同じ階層に1億近いオブジェクトが集中したとき障害発生したのに対し、「RSTOR」は同規模のデータを入れても良い性能が得られました。また、現行システムで、大量のデータの一括削除で操作不能になるのに対して、RSTORでは問題なく処理できました。

(3) コストメリット

「RSTOR」は、容量に対する課金のみでデータアウトとリクエスト課金がなく、また、容量単価もAmazon S3 Glacierにほぼ近い金額アクティブストレージ使用できます。30TBで数億オブジェクトコスト比較すると、1/10近いコスト削減になると見込んでいます

(4) 運用負荷の低減

現行システムでは、性能維持のために約2ヶ月に1回定形作業必要でその作業に5人日かかっていましたが、「RSTOR」ではその運用コスト不要となり、また、障害発生時の対応コストがなくなることで運用負荷が大幅に軽減されます

2021-05-27

anond:20210527100955

んでも2000年代前半にユビキタスコンピューティングとか言って微妙研究領域だったとこはクラウド・4G回線スマホ普通に日常生活ツールになってたりしてところどころ進歩してる感はあるけどなー

2021-05-09

改編

オリンピック開催中にアフリカ系アメリカ人の一人から変異体のウィルス発見された。そのウイルスはまたたく間に東京を覆い、その中から意識を通じる能力を獲得する者達が現れる。その頃米国CIA中国秘密裏に開発していたコロナウィルスの変種が存在することを突き止めた。CIA諜報員□□は日本に発生したPSY体質の者達に接触する。

封鎖が続く日本にて、新たな国中国誕生する。その生誕はまるで集団的意思を持っているかのように思えた。しかし、神性民主主義共和国を掲げたその集団客観的に見ても生産手段を持たなかった。

一方中国では、日本の中に発生させたナノマシン暴走したこと懸念していた。それはコロナウイルス偽装された形で持ち込まれ、爆発的に自己増殖するようにプログラムされていた。しかし、そこから新たな能力を獲得する人類誕生することは想定外であった。

共和国の者達は世界中情報という情報収集し始め、その情報輸出産業として切り売りし始める。この姿勢世論共和国への避難を強めたが、国家コントロールを考える各国元首たちの耳には届かない。やがて共和国の狙いが、ナノマシン主体としたナノグリッドコンピューティング形成することである、と言う事実が□□によって判明した。彼らは『バベルの塔』と呼ばれる巨大建築物を作り出し、すべてはナノマシン支配され、同調すべきであるという指針を打ち出すのだった。

辛くも日本から逃げ延びた□□は、この凶行を前にして軍事的作戦に乗り出すよう米国の指示を仰ぐ。しか上層部の足並みは揃わずナノマシンによる侵食世界の半分を覆い、世界は2つに分断される。

補足:作り方によっては二部構成も作れる。

2021-04-25

いわゆる「お金持ち」の家の子息が普段何をしているか

我が家明治期に興隆した商家で、現在も大枠を考えればモノやコトを売ることで生計をなしている。
いわゆる華族であったが、興隆の経過で江戸期以前の地主武家などと婚姻を経て結びついており、家系図を遡れば皇室とも血筋上の繋がりがあると解釈ができる。

さて、そんな家に生まれた筆者だが正直に言えば高校生くらいまで我が家がそんな家だとは気付いておらず、多少なりとも大きな家に住めている理由として両親や祖父母も「ご先祖様が努力の人だったから」と言っていたので、現在我が家はそこまでお金持ちではなくご先祖様が増やした資産恩恵を受けているのだ程度にしか思っていなかった。ご先祖様すげぇなと。
実際、筆者自身の子供の頃の夢はプロアーチャーであったので全く家業意識していなかった。

我が家はなんか他の家と違うぞ?と気付き始めたのは高校生になった時期で、父や祖父に連れられて社会科見学のような小旅行を頻繁にやるようになってからだった。
自動車工場や造船所、食品工場アパレル工場精密機器工場製紙工場など工業系を中心になぜか見学に連れられ、その工場担当者らしき壮年男性から説明を聞くということを頻繁にさせられた。
今思い出せば、父や祖父はそのくらいの時期から「AはBから生産されていて流通として……」のような話をよくしてくれるようになっていた。
社会科見学のような小旅行面白かったが、なぜ急にそんなことをやるようになったのかという疑問は晴れなかった。まさかそれが後継者教育の一環だったとは。

自分自身の興味と祖父の勧めもあり、大学ではアーチェリーを続けつつもロジスティクスを中心に学ばせてもらい、継続されていた社会科見学が非常に研究へ役立つようになっていた。
そして我が家歴史を完全に知ったのは大学3年生の正月に「就職はどうするのか?」と言われた際に「参考になるかはわからないが我が家家業説明しようか」のように教えられてからだった。
遡れば初代が江戸期に商家として暖簾分けを受け、現在まで続く家業の基盤を明治期に作ることができたとのこと。そこから登場する人名歴史の授業で習うような人々であり、まるで実感のなかった筆者は驚愕するしかなかった。

そんな家の子である筆者が普段何をしているのか?と言えば、某物流企業から商社を経て、現在は父から「そろそろ戻ってこい」と言われ、法人化している我が家の持ち企業へ務めさせていただいている。
筆者の専攻がロジスティクスなので新社会人の頃から数理的に物流計算するのが主な仕事で、笑ってしまうかも知れないが何処へ行くにもCASIO関数電卓ポケットへ入れている。現在関数電卓ソーラーパネル電池駆動するのでスマホなんかよりもよっぽど信頼度が高い。
弊社が集めたデータ取引からロジスティクスに関するデータを貰い、それを数理的に損益分岐点とのその確率をはじき出すというものだが、概算ではなく精密に計算する際はコンピューターに詳しい増田の皆様にも馴染み深いであろうAWSさくらを利用している。
ちなみに筆者のスマホAndroidiPhoneにはまともなターミナルがないので、ふと出先で大きな計算リソース必要になったときAWSSSHしにくい。まぁノートPC使えよって話だが。

もちろん計算するだけでなく、創作物イメージされやすいであろう会食などで人脈交流をしたりもするが、実際のところ筆者の世代ともなるとLINEZoomSlackなどで友人たちと交流している頻度のほうが多い。
正直LINEZoomは昨今の流れもあり使いたくないのだが友人たちは経営学部卒などの文系が多いので、どうもセキュアなコミュニケーションツール活用が上手く行かない。
可能ならば弊社で利用しているオフィススイートMicrosoft office 365やGoogle Workspaceへ移行したいのだが、一部の従業員の皆様の反発から上手く行ってない。後継者といっても実務へ強権を奮えるほど実力はないのだ。筆者の管轄研究グループは即座にSlackを導入できたり出来たのに。う〜む……。
流れのまま愚痴を言えば、例えば総務などはミドルハイエンド性能なChromebookで十分じゃないか?社内ツールもいつまでJavaベースのを使っているのか。HTML5ベースに移行してしまえば互換性の問題Windows使い続ける理由もないんだが。いまだ動いてる骨董品メインフレームをそろそろ引退させてあげようよ。
父は「実務に口を出すべきでない」と言うが、多少筆者の趣味も入ってはいもの環境を整えるのも我々の役目ではないだろうか。
強権を奮って一気にモダンコンピューティング環境にしたい。営業にも今のガラケーから最新のGoogle Pixel 5あたりのスマホを配ってあげるのに。

というようなことを青臭く思っているのだが、実際の後継者なんてこんなもんである。実権を握れるまでおとなしくしているしか無い。
従業員の皆様には申し訳ないが、おそらく筆者にはご先祖様ほどの商才は無いんだろう。苦労させてごめんね。

2021-04-15

VMwareDellより分離独立の件

機械翻訳です。

#####

ヴイエムウェアとデルテクノロジーズ、スピンオフについて合意

デルテクノロジーズ、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による株主向けの情報提供書を作成します。情報提供書は完成後、当社の株主に郵送されます。この取引に関してVMwareSECに提出したすべての文書コピーは、SECウェブサイト(www.sec.gov)またはVMwareウェブサイト(https://ir.vmware.com/)から無料で入手することができます

将来の見通しに関する記述

プレスリリースには、提案されているスピンオフの予想時期、完了効果および利点、特別現金配当の支払い、規模および1株当たりの金額VMwareの将来の投資評価およびプロファイルスピンオフ後のVMwareデルテクノロジーズの戦略的パートナーシップ商業的取り決めおよび協力関係VMware事業戦略およびビジョン、将来の成長機会に対する期待など、将来の見通しに関する記述が含まれています。これらの将来の見通しに関する記述は、1995年米国私募証券訴訟改革法によって創設されたセーフハーバー条項対象となります

VMwareは、

(1)分離・分配契約の終了の原因となる事象、変化またはその他の状況の発生、

(2)特別現金配当のための十分な資金源の確保の失敗、

(3)VMwareのその他の失敗、

(4)その他の要因により、提案されている取引上記の条件またはその他の受け入れ可能な条件で、または全く完了できない可能性があります

(3)その他、VMwareまたはDell Technologiesがスピンオフ完了および特別現金配当の支払いのための契約条件を満たさないこと、

(4)VMware特定格付け機関基準を満たさないこと、

(5)スピンオフおよび特別現金配当の発表がVMwareおよびDell Technologiesの戦略的および商業関係に与える影響、ならびにVMwareが主要な人材を維持・雇用し、顧客との関係を維持する能力に与える影響。6)COVID-19パンデミックVMware事業財務状況、VMware顧客ビジネス環境世界経済および地域経済に与える影響、

(7)一般的経済状況または市場状況の不利な変化、

(8)消費者政府情報技術への支出の遅延または削減、

(9)価格圧力業界統合仮想化技術への新たな競合他社の参入などを含むがこれらに限定されない競争要因。10)買収した企業資産VMwareに正常に統合し、VMwareから売却した資産に関連するサービスを円滑に移行する能力

(11)仮想化ソフトウェアおよびクラウドエンドユーザー、エッジおよびモバイルコンピューティングセキュリティおよびテレコム業界における急速な技術革新、

(12)仮想化ソフトウェアおよびクラウドエンドユーザー、エッジおよびモバイルコンピューティングセキュリティおよびテレコム業界における急速な技術革新。

(12) コンテナ化、最新アプリケーション本質的セキュリティネットワーキングクラウドデジタルワークスペース仮想化通信とエッジ・コンピューティングソフトウェア定義データセンターなどの分野で、VMware顧客が新しい製品プラットフォームサービスソリューションコンピューティング戦略に移行する能力、および顧客が新しいテクノロジーを受け入れる際の不確実性、

(13) VMwareスピンオフ後に戦略的効果的なパートナーシップを締結し、協力関係を維持、拡大する能力

(14)訴訟規制措置継続的なリスク

(15)専有技術保護するVMware能力

(16)製品サービス開発スケジュールの変更、

(17)サイバー攻撃情報セキュリティデータプライバシーに関連するリスク

(18)主要な経営陣の交代による混乱。19)為替レートの変動や貿易障壁の増加など、国際的販売に伴うリスク

(20)VMware社の財務状況の変化、

(21)VMware社とDell Technologies社それぞれの財務状況や戦略的方向性の変化により、VMware社とDell Technologies社の商業関係市場開拓のための技術協力に悪影響を及ぼす可能性があること。22)VMwareDell 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/

ポール・ツィオット(Paul Ziots)

VMware Investor Relations

pziots@vmware.com

650-427-3267

マイケル・タッカー(Michael Thacker)

VMware Global PR

mthacker@vmware.com

650-427-4454

Source: VMware, Inc.

2021-02-09

anond:20210209213345

ケミストリックコンピューティングとフィジックコンピューティングといった方がわかりやすいし

僕たちプログラマーがあつかうのがフィジカルコンピューティング

営業や一部の美大生が扱うのがケミストリックコンピューティング

2つ合わせてコンピューターサイエンス

ただ、ケミストリックコンピューティング、というのはまぁ、僕たちプログラマーに譲ってわざと長い名前を使ってくれるのだが

僕たちはフィジカルコンピューティングサイエンティストかというと

から、それのことをプログラマーというのだ

ログイン ユーザー登録
ようこそ ゲスト さん