  |
はてなキーワード: パブリッククラウドとは
https://b.hatena.ne.jp/entry/s/blog.serverworks.co.jp/SPLA_after20250930
「AWSは弾いといてAzureでOKだったら～」みたいなブコメに大量に星ついてるけど、記事内に書いてるだろ。
3:Listed Provide：Microsoft の定めるパブリッククラウドプロバイダー Alibaba、Amazon Web Services、Google、Microsoft、およびListed Provider をアウトソーシングサービスの一部として利用するアウトソーサーを指す
エンジニア自称する連中はせめて記事内に書かれてあることぐらい読めよ。
この問題って、自社DCでMS製品使ったサービス提供する企業のためのライセンスなのに、
AWSやAzure使うクセにMS製品のライセンスを利用するクラウドベンダから買わずSPLAで済ませることで利益ちょろまかそうとするような
コスいベンダーに「ちゃんと正規ルートで買え」って言うための変更だろ。
そういうコスい小銭稼ぎするベンダって、ライセンスをクラウドベンダから買ってないくせにトラブルシューティングでサポート範囲超えた要求平気でしてくる印象しかない。
https://anond.hatelabo.jp/20220505132024 ←これと同じ世界線の人やね
まずは、日立のサーバーでのWindows Server 2022への対応からお聞きした。
木村： サーバーにはHA8000VとRV3000の2ラインアップがあります。HA8000VがPCサーバーで、汎用的なサーバーとして、エントリー向けや、HCI、VDIのソリューションなど、いろいろな用途で使われています。RV3000はミッションクリティカル向けです。Windows Server 2022のプレインストール対応は、HA8000Vの全機種で2022年5月を予定しています。
Windowsサーバー市場における日立の強みとして、木村氏は、サポート力を挙げる。
木村： 日立は長年に渡ってプラットフォーム製品の開発を行ってきました。作ってきたからこそ、中身がわかっている技術力があります。できることとできないことを技術者がわかっているので、障害が起きたときや問い合わせのときに、お客様に事実を真摯に伝え、重大な不具合があっても技術力で解決に向けていきます。何かあったときに問題をたらい回しにせず、技術力をコアにしてしっかり対応するサポート力が強みです。
こうした日立のDNAを結実させたサポート商品が「日立サポート360」だ。通常はサーバーのハードウェアからOS、ソフトウェアなどは、それぞれと契約し、サポートを受けることになる。日立サポート360ではこれらをワンストップで受け付け、支援することができる。
広瀬： 窓口が1つになるというのは他社でもありますが、そういう表面的な話だけではなく、複合的な力で問題解決支援にあたれるのが真の価値です。内部で、サーバーからOS、日立ミドルウェア、導入ミドルウェアなど、いろいろな製品の部門の連携がすごく濃密にされているからこそ、複合的な力で問題解決にあたれます。これが本当のワンストップの意味です。
この日立サポート360でWindows Server 2022のサポートにも対応する。日立では、長年のサポート実績により蓄積された技術力により高い自社解決率を誇るという。自社解決率が高ければ、それだけパートナーへのエスカレーションが減るわけで、短期間でのトラブル解決が期待できることになる。
日立のハイブリッドクラウドのソリューション「EverFlex from Hitachi」
木村氏は、日立のハイブリッドクラウド戦略としてEverFlex from Hitachi (以下、EverFlex)ソリューションを説明した。EverFlexは2021年10月にクラウドとのデータ連携ソリューションとして始まり、2022年2月にハイブリッドクラウドのソリューションとして強化された。
木村： お客様がオンプレミスとパブリッククラウドを使うときに、最適なシステム設計にして、コストも最適化していきます。ハイブリッドクラウドの導入には事前にアセスメントやコンサルティングを行うことが大切です。なぜなら、パブリッククラウドを導入することで負担が減るかと思われがちなのですが、ハイブリッド化されることで負担が増えることがあるからです。
EverFlexの特徴の中でも特に「クラウドライクなサービス提供」について木村氏は紹介した。
木村： ハイブリッドクラウドになると保守や運用が煩雑になります。パブリッククラウドとオンプレミスの両方を管理しなくてはならないため、システム管理において両方のノウハウが必要になります。このため保守・運用フェーズにおいて簡単化されずコスト最適化が課題となってきます。それを避けるために、共通化するニーズに応えるようにいろいろと工夫しています。
ハイブリッドクラウドソリューションEverFlex from Hitachi
まず、問い合わせをワンストップ化したり、運用管理を1つのツールで一元化したりすることで、顧客の負担を軽減する。
プラットフォームにおいては、オンプレミスからクラウド接続を可能にしてシームレスにお互いやりとりできるOSが各社ある。Windows Server 2022はまさにそれを特徴としており、同じくAzure Stack HCIも選択肢に入る。
さらに、支払い／利用形態についても、オンプレミスでも売り切りだけでなくフィー型も採用する。こうしたEverFlexの中でWindows Server 2022のユースケースを木村氏は2つ挙げた。
1つめは、運用管理の簡単化の部分で、Azure Portalからオンプレミスを管理できる機能の強化だ。
木村： オンプレミスにエージェントを入れておけば、管理者がAzure Portalだけをさわって、オンプレミスのリソースやイベントの管理も全て一元化できます。これに期待しています。
もう1つはセキュリティの強化だ。
木村： ハイブリッド化が進むと、両方の基盤をネットワークで接続することになります。従来には存在していなかった接続となるため、その部分でセキュリティの強化も進めなければなりません。そこでWindows Server 2022では、Secured-core ServerによってOSそのもののセキュリティレベルが上がっています。TPMと連動する機能によってハードからOSのレイヤーを守り、マルチレイヤーでセキュリティを強化しています。
そのほかにもクラウドライクの取り組みとして2つを木村氏は紹介した。
1つめは「サーバ予備リソース提供サービス」。サーバーを余分に設置し、支払いは電源を入れて使った月だけ発生するというサービスだ。
木村： 迅速でタイムリーにリソースを増強したいときに、クラウドなら自由に構成を変えられます。それをオンプレミスでもできるようにします。クラウドではインスタンス単位となり、ハードウェアの構成はメニューの中から選択することになりますが、オンプレミスでは構成を自由に組む事ができます。まずHCIソリューションから開始しましたが、2022年4月からはそれ以外にも拡大する予定です。
もう1つが「ハードウェア安定稼働支援サービス」。オンプレミス環境のサーバー運用管理を省力化するものだ。
木村： 旧来の保守では、ファームウェアのバージョンアップがあると、技術的にどういう影響があるかを確認して、その都度適用するかどうかを判断する必要がありました。それを提供元が判断するのがこのサービスです。お客様の機器を弊社で管理して、ファームウェアの推奨バージョンの選定や、更新作業などを一括でやります。
サブスクリプションに力を入れる
日立のこれからの注力分野について木村氏は、サブスクリプションに力を入れていくと語った。
木村： 全社的な方針で、サブスクリプションに力を入れていきます。クラウド化で初期投資をおさえるニーズと同時に、オンプレミスも求められています。そうしたお客様のニーズにアラインしていきます。
サブスクリプションやクラウドライクなサービスで管理を簡単にして顧客企業がコストを抑えることで、究極的な目的はその先のDXだと木村氏は語る。
木村： 既存のプラットフォームのコストを最適化させ、浮かせた費用を新たな投資先として、AIやEdgeを活用する新たなデジタルソリューションの領域に向けていくことを支援していきたいと考えています。
そのために木村氏は、よりハイブリッドで使いやすいようなライセンス体系をマイクロソフトに期待している。
木村： 今後ハイブリッド化が進むと、繁忙期にリソースを拡張するといったこともあります。そのときにライセンスが、オンプレミスはオンプレミスで買って、AzureはAzureで課金してと、ハイブリッドで使いづらい体系になっています。将来的にライセンス体系を統一するなど、両方の基盤で使えるような体系になることを期待しています。
また、Azure Portalからオンプレミスを管理できる機能についても、さらなる強化を木村氏は期待する。
木村： Azure Portalからは管理できる範囲に限りがあります。OSから上のリソースやイベントは監視できるのですが、ハードウェアの死活監視や電源管理などは対応していないため、JP1やその他のツールなど、複数のツールを使いこなす必要があります。それらの管理ツールが乱立してしまうと、また管理の手間が増えてしまう。こういったことをオンプレのツールか、Portal側で統一することも期待したいところです。
まあVMWorldとかで10年以上人生の春を謳歌してきたからもう十分やろ
お疲れさん
～VMwareが提案する、DRにも対応するマルチクラウドソリューション～
昨今のCOVID-19流行への対応やDXを推進する中で、クラウドサービスの利用はビジネススピードの加速や柔軟なシステム運用に効果的であり、従来のオンプレミス環境と併用するハイブリッド環境や、複数のクラウドを利用するマルチクラウド環境が増えている。一方で、これらの環境を維持していくには課題も多く、セキュリティリスクも増大してしまう。ここでは、こうした課題を解決するVMwareのソリューションを紹介する。
COVID-19流行への対応やDX（デジタルトランスフォーメーション）のためのビジネス変革が進む中で、ビジネススピードの向上やニーズに対する迅速で柔軟な対応がこれまでになく求められている。これらを実現するために、アプリケーションの変革やクラウドへの移行が加速している。
多くの企業が、「ビジネスのスピードに対応できるモダンアプリケーション」や、「あらゆるクラウド、データセンター、エッジでビルドおよび実行が可能であること」、「エンタープライズクラスのレジリエンス、セキュリティ、運用の実現とビジネス変革」がDXを実現するために必要であると考え、これらを実現するためにマルチクラウド環境の活用が前提になってきている。
具体的には、Amazon Web Services(AWS)、Microsoft Azure(Azure)、Google Cloud Platform(GCP)といった複数のパブリッククラウドサービスを併用し、適材適所で使い分けているのが現状であろう。しかし、マルチクラウド環境では解決が必要な課題が存在する。その課題とは、「ワークロードのシームレスな移行・連携」、「クラウドごとのスキル習得」、「運用管理の簡素化」、「セキュリティリスクの低減」、「最適なコスト管理」の5つである。この5つがクラウド利用の理想と現実のギャップとなっており、これらを意識して進めていく必要がある。
特にマルチクラウド環境を適材適所で使う場合、クラウドごとに利用する技術が異なるため、設定項目や内容に違いがあり、その設定ミスによるインシデントも発生している。重大な影響を及ぼす場合もあるため、それぞれのクラウドを扱う際のスキルが重要になる。
こうしたマルチクラウド環境における課題を解決するには、一貫性のあるクラウドインフラストラクチャ、および運用管理サービスが重要なポイントとなる。例えばVMwareは、複数のパブリッククラウドだけでなくオンプレミスを含むハイブリッドクラウド環境においても、仮想的なレイヤーを構築することで管理や運用を一元化している。
VMware Cloud on AWSは、VMwareとAWSが共同で開発したもので、AWSのベアメタルサーバー上にvSphere、NSX、vSAN、vCenterを導入し、ホスト専有型のクラウドサービスとして提供するものだ。
その特長は3つある。1点目は「VMware製品をベースとしたクラウド」であること。VMware製品で仮想化されているため、AWSの世界にいながらオンプレミス環境で利用していたスキルセットや運用管理ツールを利用でき、新たなスキルを習得する必要がない。
2点目は「シームレスにクラウドに移行できる」こと。ワークロードをオンプレミス環境から無停止で移行することができる。アプリケーションを更改する必要もないため、クラウドに移行する時間やコスト、リスクを大幅に削減することが可能だ。
3点目は「VMwareが管理を行う」こと。ハードウェアやソフトウェアのトラブル対応や運用管理、メンテナンス対応など、すべてサービスの中でVMwareが実施する。3カ月に一回の頻度で新しいリリースを提供しており、ユーザーの要件を反映しながら新たな機能を追加している。
最近のアップデートの大きなものとして、日本で第2のリージョンとなる大阪リージョンを設置し、サービス提供を開始したことが挙げられる。例えば西日本地区でデータセンターを持つユーザーは、より低遅延でサービスを利用できるようになった。昨今は感染症の流行や地震の発生などによってBCPを見直すユーザーが増え、VMware Cloud on AWSをリカバリサイトとして利用するケースも増えている。その意味でも、大阪リージョンは活用度が高いといえる。
VMware Cloud on AWSが選ばれる理由は、大きく3つ挙げられる。1点目が既存のノウハウや運用管理手法をそのまま踏襲できるという点。VMware製品をベースとしたクラウドサービスであるため、オンプレミス環境における管理者のスキルや運用ノウハウなど、既存の資産をそのままクラウド上でも活用でき、新たなスキルの習得や、運用管理手法の大きな変更の必要もない。クラウドとオンプレミス環境をvCenterから一元管理できる。
2点目が、規模に依存しないシンプルなクラウド移行を実現できる点。ワークロードをそのままクラウドへ簡単に移行することが可能だ。VMware Cloud on AWSには標準でVMware HCXが含まれ、これはオンプレミスのデータセンターとクラウド間のネットワークをL2延伸する。ネットワークがつながった環境で仮想化環境、VMをそのままマイグレーションできる。アプリケーションやIPアドレスを変更することなく、無停止でワークロードを移行することができる。
3点目が、モダナイゼーションを推進して、ユーザーのDXの加速を支援できる点。まず、クラウドならではのインフラストラクチャとして、1顧客あたり最小2ホストから最大640ホストまで拡張できるが、俊敏性を兼ね備えて提供される。例えば、ホストの展開に1時間半程度、ホスト数を追加するのに15分程度と、オンプレミス環境ではありえないスピード感で環境を構築、提供される。
また、リソースを最適化する機能も提供される。ユーザーのリソースの使用状況に応じて、利用するホストの台数を自動的に増減させて最適化する。さらに、名前の通りにAWSが提供する各種サービスとの親和性が非常に高いことも特長。VMware Cloud ENIと呼ばれる専用のインタフェースを経由して接続することで、低遅延で高速な環境を利用して各種のAWSのサービスとシームレスに連携することができる。この面も同サービスの大きな強みとなっている。
最近では、VMwareが提供するKubernetesディストリビューションであるVMware TanzuをVMware Cloud on AWS上で稼働させることが可能になった。これにより、短時間でコンテナ、Kubernetes環境が導入できるようになる一方で、ハードウェア、ソフトウェアの管理はすべてVMwareが行うため、管理者はKubernetes環境に集中できる。
VMware Cloud on AWSのユースケースには、主に「オンプレミス環境のクラウド移行」、「データセンターの拡張」、「災害対策サイト」、「次世代アプリケーションのプラットフォーム」の4つが多い。特に最近は、災害対策としての利用が増えているという。VMware Cloud on AWSをリカバリサイトとして活用する際に強力なサービスとなるのがVMware Cloud Disaster Recoveryだ。
VMware Cloud Disaster Recoveryを利用すると、平常時には本番サイトのデータをクラウド上のストレージ領域にレプリケーションしておき、万一DRイベントが発生した際に初めてVMware Cloud on AWS上にホストを展開し、保護していた仮想化環境をフェイルオーバーする。リカバリサイトとしてあらかじめ物理的なサイトを構築しておく必要がないため、大規模な初期投資が不要となる。
VMware Cloud Disaster Recoveryの特長
このタイプはオンデマンド展開型と呼ばれ、DRイベント時にホストを展開したタイミングでリカバリサイトに対する課金が開始される。復旧後に仮想化環境を本番サイトに戻すことで、ワークロードもフェイルバックでき、不要となったリカバリサイトのリソースも削除され課金も停止される。なお、オンデマンド展開型のほかに、事前にホストを展開しておく事前展開型も用意されており、RTOを重視する場合には事前展開型が推奨される
また同サービスは、最近話題になっているランサムウェアへの対策にも有効だ。クラウドストレージ上に本番環境のデータをバックアップする際には、リカバリポイントを長期的に保持することが可能である。このため、ランサムウェア攻撃に遭ってしまった場合、その直前の時点からリストアすることが可能となる。
マルチクラウド環境を可視化するVMware vRealize Cloud
マルチクラウド環境では、各クラウドが複雑化し、サイロ化してしまう可能性がある。クラウドごとに管理ツールや必要とされるスキル、ノウハウも異なるため、利用するクラウドが増えるほど複雑化、サイロ化の問題が大きくなり、その結果セキュリティリスクやコストが増加してしまう。そこで有効な解決策となるのが、クラウド環境をまたがって一貫性のある運用・管理を実現できるVMware vRealize Cloudである。
まず、VMware vRealize Operations Cloudは、VMware Cloud on AWSのリソースだけでなく、他のパブリッククラウド上のリソースも一元管理できる。複数クラウドの環境にまたがってデータを収集、分析評価を行うことで、例えば常にパワーオフ状態の仮想化環境や、実体がない状態のディスクなどを検知された場合に最適化していくことが可能。これにより、最終的にコストの最適化も図ることができる。
コストや運用を最適化できるVMware vRealize Cloud
また、VMware vRealize Log Insight Cloudによって、複数のクラウドを横断してログを管理できる。例えば、監視対象のイベント通知をあらかじめ定義しておくことで、不正な行動を検知した際には管理者に通知し、適切な調査と対応を行うことができる。セキュリティやコンプライアンスの強化にも有効だ。
さらに、クラウド間のネットワークの可視化は、VMware vRealize Network Insight Cloudで実現できる。End to Endを含むネットワーク全体を可視化できるため、ネットワークに関するトラブルシューティングや、不審な通信を洗い出すこともできる。また、アプリケーションの通信も把握できるため、アプリケーションの移行計画にも活用できる。
今後、DXの推進を加速していく上で、必ずしもひとつの環境、ひとつのクラウドを利用するのではなく、マルチクラウド環境の利用が当たり前になっていくと考えられる。そこで直面する前述の5つの課題に対し、VMware Cloud on AWSそしてVMware vRealize Cloudの活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
https://news.yahoo.co.jp/articles/6ed4869fdca7cf63f81c8a3dc5870869be0debeb
いまではAWS、Azureのようなパブリッククラウド一辺倒時代だけど本当にいいの？
費用は高いし、サービスは落ちるし、設定は複雑だし、好んで使いたがるなんてただの変態だよね。
AWS使える ＝ 高度な知識？ いや、、、単なる「もはや使い方を知っているオペレーター」でしかないよね。
オンプレでも落ちるだろ？って？
→ 規模の大きさにもよるけど、サーバーラック数本程度の管理ならAWSほどガンガン障害起きないし、自分たちで手が出せない感は無いしなぁ。
→ まぁ、そうだけどさ。銀の弾丸は無いさ。
機械翻訳です。
#####
デルテクノロジーズ、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.
補足→ https://anond.hatelabo.jp/20191205212350
これは退職者アドベントカレンダー2019 (https://adventar.org/calendars/4051) 5日目の記事です。最初は自分のブログに書くつもりでしたが、書いてるうちにどこまで筆が滑っているのかわからなくなったので増田に投げることしました。そしたら余計にタガが外れたのはご愛嬌。
よく見かける「未経験からエンジニアへ！」ストーリーの、あまりなさそうなルートです。よくあるルートのほうはなぜかTwitterで報告して「○○系エンジニア」的な命名をしてから入社その後の動向が闇に葬られているのをかなりの確度で見かけますが、まあ、なんか、いろいろあるんでしょう。逆にそういう成功（？）体験の生存バイアスを強化する情報ばかりあふれていると情報として健全でないように感じます。
といいつつ後日しれっと消えてたらInternetArchivesか魚拓で会いましょう。
この話はここから先はフィクションです。剣も魔法も労基法も出てこないファンタジーです。
地方に潜むフリーターです。好きなvirtual beingsはロボ子さんと東雲めぐさんとれいきらさんです。
これまでは自分のためのプログラムを書き散らすだけで、ITとは無関係のバイトをしてきました。玉掛とフォークリフトなら任せろーﾊﾞﾘﾊﾞﾘ
会社にもぐりこんだいきさつはやや特殊なのでぼやかします。とあるきっかけで知り合った人から誘われました。リファラルです。なお、とあるきっかけはなにかと炎上しがちないわゆるプログラミングスクールなどではないことを防火剤がわりに書いておきます。そんなもんに使う金など無い。
その人のことはあんまりよく知らなかったのですが、CTOとして手伝っている会社のシステム部門で人手を探しているとのことでした。会社のホームページにはリクルートページなど無く、何をやっているかいまいち要領が掴めなかったのですが、ざっくりと自社製のWebアプリ開発をやる感じらしく、内容も聞いた限りでは（自分のスキルと照らし合わせて）そんなにどえらいわけでもない印象でした。ちょうど金もないし無職だし、少し経験でも積んでみるかという気になったので、この際ホームページがDreamWeaverのサンプルを流用したまんまといった細かいところは観なかったことにしました。
面接にいくと社長から「いつからこれるの？」と言われたので「あっこれは」となりましたが、金がなかったので是非もなくそのまま入社の運びとなりました。この頃はプログラム書いて金もらえるなんてサイコーとか思ってました。ちなみにgithubやatcoderのアカウントを書いた職務経歴書は一顧だにされませんでした。
地方の製造業のシステム部門を切り出して別会社にした形態の、創立数年ほどの会社です。自分のほかにもうひとり、社内情シスのようなことをしている方がいましたが、基本的にはサポートが専門な感じでした（ただし肩書は自分と同じでしたが）。紹介してくれたCTOは週に一度のMTGに顔を出すだけということで、実質的に常駐している人間でプログラムが分かるのは業界未経験の自分だけというチャレンジングな環境からスタートしました。なお入社して社内の平均年齢を大幅に下げることになりました。
ちょうど入ったタイミングで情シスの方が抱えている仕事があり、とくにやることもなかったので手伝いました。グループ会社のサイトをスマホ対応させるもので、事情はわかりませんがそれまで他社に制作を委託していたものを自社で運用することにしたとのことです。みてみるとWordPress4でPHP5が動き、Bootstrap3を使ったオリジナルカスタムテーマで運用してきた様でした。もちろん仕様書やローカル環境もあるはずがないのですが、どうせ自分はWebデザインなど知らんのでとりあえず直にheader.phpにviewportを書いてmain.cssにメディアクエリを設定して、ザ・web制作初歩みたいなレスポンシブ対応をしましたが、デザインについて当事者との意見のすり合わせの機会なんかの開発手順はなかったので良しとしました。
入社して2周間ほどのち、社長についてこいと言われた打ち合わせの後日、MTGで「昨日のアレの進捗はどんな感じなの？」と聞かれたことから、いつのまにか新規案件を自分に一任されていることに気づきました。仕様は前日の打ち合わせがすべてだった模様です。要件定義や技術選定・検証のような工程など決まってないので好みで揃えました。趣味と関心からExpress+Mongo+Reactのセットか、触ったことのあるDjango/Railsでざっくりやるか、どうせならDockerも使い時か、こんなときに相談できる同僚やメンターが欲しいなぁなどと考えていたら、CTOがそれまで作っていたやつをみるとPHP+ES5+MySQLだったのでなんだかんだでそうすることになりました。PHPを初めて触り、「これがペラ1のphpにjsもcssもなにもかも書いていくといういにしえのスタイルか…！」と新鮮な感じでやってました。
Windows Server 2012で動いていたサービスをLinuxに移行しました。これは自分が入る前から情シスの方が任されていたのですが、マニュアルに沿ってコマンドを打ちこんではどこかで転け、エラーは読まずにあきらめてCentOSインストールからやり直すということを繰り返していたのを見るに見かねて手伝いました。SSHでPowerShellからマニュアルのコマンドをコピペして実行する方法を教えてあげると目を丸くされました。shellファイルを書いてあげると魔法をみるのような顔で驚かれました。自分が入ってなければどうなっていたんだろうか...
毎日出退時間を規定のEXCELフォーマットに記帳する必要があり、これが非常にめんどくさく無駄に思えたので、自動記述するpython/Goスクリプトを書きました。これは入社して2日目とかだった気がします。しかしここを自動化しても「印刷して人事に提出し、それをもとに人事の方がまたEXCELに書き込む」と知り虚無になったりしました。
これはやったことというか思うところあってプライベートで取り組んだことです。自分の想像していた開発現場との乖離を感じたので、こういうのはFE勉強すればわかるのかもしれないと思って1ヶ月くらいやって取りましたが、得られた知識で会社に活かせそうなものは何一つありませんでした。
チーム開発などという概念は存在せず、「1案件を1人で上流から実装、運用、保守、サポートまですべてやる」という進め方でびっくりしました。手持ちの技術スタックでできる範囲でギリギリなんとかやった感じです。よく転職サイト上で見かける文言で「お任せします」がありますが、これとかも要するに「丸投げ」の換言なんでしょうか。わたし気になります。
自分のように途中からジョインした人に対しての業務移行のシステムがないことから感じていましたが、案の定「誰かが抜けたあとの引き継ぎの機能」も整備されてないことに気づきました。もともとオンボーディングや研修の概念などありません。えらいひとは「そのへんは現場で協力してうまくやって」と丸投げし、すべての作業を自宅でやっているCTOは社内のこうした事情については放任で、いちおう情シスの方がいつのまにかメンター代わりになっていたものの、不明点を尋ねても頓珍漢な返答が多くもどかしかったです。どのサーバでどんなサービスが動いているのかやSSH情報を聞き出すのに苦労しました。こうした不幸と無駄な時間をなくすためにドキュメントを整備しようとしたのですが、頓挫しました。これからも物理フォルダーと社内サーバに散逸した各種の情報は混沌を深めていくのでしょう。gitも無いし。
サーバはオンプレでした。自分はクレカをもっていないためパブリッククラウドを試す機会がなく、ぜひとも触ってみたかったのですが、承認を得るための説明がうまくいかず、結局VBoxでやることになりました。唯一、それまで使われていたVBoxではなくVagrantを導入したのは少しだけ救いでした。どうせ自分しかいじらないのですが。
余談ですがオンプレで面白かったのはHDD増設のために初めてデータセンターなるものに入ったことです。インフラ/ネットワークはまったく分からんしなかなか個人で試せない領域だし縁がないかなと思っていたのですがやはりそこに見える物理層が存在するというのはテンションがあがりますね（断層みたいに言うな）
イキってカイゼン・ジャーニーや情熱プログラマーを買って読んだりもしました。目につくように共同図書のつもりで「ご自由にどうぞ」を添えて自分のロッカーに置いておいたら「私物は持ち帰れ」と言われてしまったので持ち帰りました。
さてお待ちかねメインディッシュですね。
もともと技術やコンテンツの会社ではなく、技術畑の人間がまったくいないことのインプレッションが次第に違和感として強く響いてきました。ITエンジニアとしてやっていくつもりの観点でみると、学習や成長の土壌は無いように思えました。協調関係や信頼がうまく築けず、自分のすべき道筋が不明瞭のままやっていけるほどタフなYATTEIKI精神ではなかったのです。
これは地方の、それもIT気質のあるわけではない、ワンマン経営の中小製造業ならばどこにでもあることかと思われますが、随所に感じるレガシーさに疲れてしまいました。一例を挙げると、毎朝30分に亘り行われる全社清掃（もちろん業務時間外）、社是の復唱、『感謝の言葉をみんなで味わうポエム』の輪読、その感想大会、頻繁に行われる中身のない会議、日報をエクセルで書いてメールで送ったり、出退勤表を毎日エクセルに書いて印刷して事務方に持っていくなどのルーティンがけっこう苦痛でした。
社内のコミュニケーションツールはLINEだったので使い勝手も悪く、会議でchatworkかslackを使いましょうと提案しても誰一人としてそれらの存在を知らず、「勝手にやってくれ」と言われてしまったり。LINE WARKすら知らんやんけ。説明しても「skypeじゃ駄目なの？」と言われたので諦めました。
えらい人の思いつきのたびに方向性が変わり、当人は発言したらそれで全て完了した気になってしまったのか、会議終了後の10分後に「さっき言ったやつまだ出来てないの？」などと言われた時はギャグかと思いました。会議の議事録も誰も見返さないので果たして意味があったのか疑問です。誰かひとりでもmarkdownが書けたり、少なくとも書く気があれば勉強会を開催してHackMDなどを推せたのですが。議事録が機能していないエピソードとしてひとつ思い出しました。開発中に機能追加を下された際に、その挙動は完全にプラットフォームネイティブであり今の技術選定だと作り直しになり、結果納期に間に合わない（し、自分の技術スタックからも遠く外れていたので学習コストも加算）と発言したらその場は収まったのですが、会議終了後に個人メールで「やはり機能はマストだ」と伝えられました。当然それは議事録に反映されることなく、なんかしらんけどそういうことになっているという感じになりました。
初めてのエンジニア職でしたが、社内に開発をる人やマネージャー職は不在で、いわゆる開発現場での流れを学ぶことはできませんでした。少なくとも技術を知らないえらいひとが「俺がスケジュールを立てたからこれに沿ってやれ」と、”開発”と”広告作成”しか書かれていない2週間の計画表をもってくるような現場はシステム開発として正しいのか、 と本能が警告を発していました。
もともと会社は製造業から始まったため、えらい人たちとの見解に齟齬があったのは体感としてあります。同じものづくりといえど設備とマンパワーと時間が線形的に結果に結びつく工場業務と異なり、システムエンジニアリングはかける時間の見積もりも容易でなく、かかった時間が必ずしも結果に結びつかないものである、と言う事実は受け入れられ難く、知識ドメインやマインドセットが異なれば説明も困難です。しかしながらえらいひとは一様に「経営者視点を」の号令で、経営誌を配り、その感想文の提出を義務付けるなど、現場視点を欠いた行動で現場（というか私）を疲弊してました。気づいたらSEO対策や別部署のMTGのためのプロジェクター設定、全PCのwindows updateに伴うドライバの更新の役も同一の職掌として役付けられそうになっていたり（一部は実際に情シスの人がやってた）、It’s not my workなシーンがみられるようになっていました。
そして、よくあることですが、理念と実態が乖離していたことです。世界をよりよくと言いつつ、目先の掛け算を考えてばかりのように思えました。グロースする中で発生しそうなあれこれをすっ飛ばし利益だけを皮算用するのはいいとして、データ量やトラフィックを指摘すると「そこは現場努力でしょう」となるので、世界を良くする前に精神を悪くしてしまい人生で初めて心療内科にいったりもしました。一応グローバル展開を目指しているとしながらサーバからMailerDaemonが飛んできたら「ギャっ英語っ！」と言って読まず捨ててたり、急にサービスが止まった時には激怒して責任の所在の追求を求められたため、草創期にえらい人の個人アドレスで取得してほったらかしにしていたドメインが失効したことが原因と伝えたら「あれはもう読んでいないアドレスだし仕方ない。こういうピンチのときこそチャンスにしようぜ」という謎理論を出されたこともありました。
違和感が確かなものになったのは、外部に提出する資料で社内の数字が異なっているとを指摘すると「こういうのは見栄が大事なんだ」と暗に公文書偽造をほのめかされたことですが、これ以上は闇っぽいので書きません（たぶんどこもやってて罷り通ってる範囲だと思うけど）
総じて、心理的安全性の低さ、そこからくる身動きのとれなさ、ロールモデルの不在、前時代的な風潮、社内文化へのミスマッチと不理解、成長の実感が沸かない不安と不満、それらに伴う摂取アルコール量の異常な増大と過食、といった要因の積み重ねが、ネガティヴな形での退職へと駆り立てることになったのだと思います。まあ、よく知らんうちにリファラルしてるところからして「採用・教育コストを考えてないのでは？」の念はあったのですが。中身がまったく不透明の状態で飛び込んだらそうなるよなぁ、の好例かもしれません。誘われた時はわりと藁にも縋る思いだったのでしかたないね。
現在はスキー場で住み込みバイトしてます。無考えに退職すると年を越せないことに気づきました。
可処分所得・可処分時間いずれも今の方が上なのはちょっとウケます。賃金はふつうに生きていければいいので前職程度でも気にしなかった程度なんですが。いまは映画をみたり積ん読を消費したり、在職時は深いところまで触れなかったPHPをいじったり、生PHPしかやってないことに気づいたのでcakeやったり、あとはweb周辺も久しぶりにキャッチアップしたりしてます。nodeネイティブおじさんなのでFWはangularしか知らないんですよね。vue/nestが面白そうな感じです。あと寮のwifiが談話室限定で窒息しそうだったので、持ち込んでいたラズパイをルータにして部屋まで飛ばしたら隣室の同僚から感謝されたりと活動は多岐に渡ります。
先のことはなにも決まってませんが、ちゃんとエンジニアリングしている組織で開発してみたいなという気持ちがあります。レビューやスクラム、アジャイルなんてのはひとりだと不可能ですし。ですが、やはりそういった会社は日本では都市部にばかり集中しているのでしょう。自分は空気の悪いところには住めないし、案外また辺鄙なところでtechとは無関係のことをしているのかもしれません。ワーホリでも使って海外で大麻栽培でも始めようかなぁ。
巷説に流布する「未経験からエンジニアへ」の言説のたぐいは、どちらかというと技術力よりもコミュ力が偏って高いタイプが生存しがちな雰囲気を感じます。たまにTLに流れてきたのを見かけますが、ああいった立ち回りは自分にはできないしやりたくないなぁと思ってきました。社会の要請ならばそれまでですが。
自分は体系的な情報教育を受けていないどこにでもいる地方高卒で、下手の横好きで趣味プログラムを書いてきたし、続けてるってことはそれなりに好きなんだと思います。得意じゃないけど。んで、こんなのがITエンジニアをしたサンプルというのは見かけないかもなぁと思って投稿しました。光あるところに闇あり。
といいつつ、やっぱり好きなことの結果がおかねになるのはいいよなぁと思った次第です。プログラムを書くのは楽しいけどエンジニアリングは超絶むずい、が雑な総括ですが、今回のことを顛末次第にはする気はないので、どこかに拾ってもらえるよう精進するきもちになりました。
昨今流行りの機械学習でプロジェクトがぽこぽこ立ち上がっている状況なのだが、一部の人を除き、apt-getで躓いているのは会社にとって損失だと考え、オンプレクラウドのようなものを構築することにした。
グループ全体の規模はそこそこ大きいが、将来単なるアッセンブリー屋になることが目に見えている事もあり（今後20年以内には喰われてしまうという憶測もあり）ネットワーク、Linux、コンテナ、プログラミングが出来る自分が社内の機械学習、引いてはITインフラの民主化、なんだったら外販できるくらいのもの作ってやろうと鼻息巻いて無理やり一人プロジェクトを興すことにした。
まずは既存DHCPサーバ、名前解決ができないDNSサーバからゲートウェイPCを用いてネットワーク的に分離、社内の物理的な設置スペースの問題でデスクトップPCとサーバPCが離れた所にあるため、WireGuardでVPN構築、ゲートウェイPCはそれぞれKea DHCPサーバ、PowerDNSサーバを稼働させ、OpenStack導入検討時に悩んだ鶏が先か卵か先か問題を解決することにした。
上述の通り、システム構築にあたってOpenStackやMAAS,RancherOSなどを検討したが、社内のニーズを「100%」汲みとった上で、次世代のオンプレクラウド（個人的にはエッジクラスタがゆるく繋がるアメーバクラウド？のような呼称があっている気がするが）を構築するにはどれも痛し痒しで何かしら制限がついて回るのは許容できなかった。これは今後5年、特に海外事業所の開発者の事を考えた時には外せない要件だった。
とはいえmiekg/dnsを用いてCoreDNS進化版を作るにはリソースが足りず、BINDを用いるにはSA対応がしんどすぎるため、APIを備えており、今後も進化が見込めるであろうOSS、また必要であれば商用製品や保守サービスが受けられる事から上記2つを選択した。
PowerDNSはさておき、ISC KeaはナウでYANGなLinux YANGに対応しようとしているなど（言いたかっただけ）、世の中のオンプレ環境を塗り替えるためには兎にも角にもAPIゲートウェイが重要だと考えたため、双方が提供しているAPIをうまく吸収するミドルウェア（とちょっとしたAPIサーバ）をGo言語で作成した。
次に世の中のパブリッククラウドやOpenStackなどを触ったことのある開発者はCloud-initに慣れているはずという前提の元、対応コスト勘案の結果、NoCloudで対応しつつ、上記のAPIサーバと連携し、ベアメタルマシン管理した事のある人はわかる、ベアメタルマシン特有の諸問題を解決することにした。
まぁなんだかんだ大企業なのでお金で解決する手段もあるが、そもそも高集積ラック搭載GPUサーバ購入の稟議が通るような会社だったら既にKubernetes導入しているだろうし、俺もこんなことしてない。
脱線したが、上記以外にも検証やバックアッププランとしてAnsible記述などの作業はありつつも、3ヶ月かけてようやく基礎となるインフラ基盤が構築できたため、nuxt.js+goで簡単なフロントエンドサーバを構築し、一人情シスの様相を呈している部下のリソース開放、Calico対応+Kubernetes導入、不安がっている上席が安心できるように、分かりやすい餅を用意しようとしている、というのが現状。
ここまで寝る時間も惜しんでトップスピードを維持したまま頑張ってきたものの、少し限界を感じている。
特にオンプレクラウドは部外者が中々見えてこないものがあり、なんならその見えないものを限界まで吸収できるように、かつ現実的に実現可能なギリギリのラインを狙っているのだが、そもそも周りに相談しようとしても何を言っているのか解説する所から始めないといけない。
覚悟はしていたが、ふとした時にとてつもない脱力感に襲われてしまう。
世の中を切り開いてきた諸氏はおそらく一度はぶつかったであろう、この内なる自分の壁をどのように突破してきたのだろうか？
ひたすら孤独との戦いだというのは頭では理解しているものの、突発的にくるこの脱力感はいかんともしがたい。
時間課金だったり、萌えキャラで結構オススメされている事が多いVPS。
ただその実態としては、非常に悪徳な業者なので、軽く触ってみる程度だと問題ないだろうけれど、それ以上の利用は強くオススメ出来ない。
諸条件あると思いますが、CPUを100%使い切りする処理を継続していたら、事前警告なく、サーバを止められました。
こんな利用をしていたのは、CPUは共有ではないとされていたからなのだけれど…
https://megalodon.jp/2018-0114-1653-36/https://www.conoha.jp:443/faq/vps/
そんな事はお構いなしに停止させられました。それも夜中にね。
まぁ専有可能なリソースを100%使い切っても問題はないわけで、サーバの停止に対して不服を申し立てるも一切の応答なし。サーバ停止の事後連絡に対し返信をしようが、サポートへの問い合わせをしようがなしのつぶて。なので、利用者側に過失がある場合はもちろん、事業者側に過失があっても、お構いなしに機械的にサーバを事後連絡でばんばん止めてくる。
CPUの件は、全く以て対策になっていないと思うけれど、以下のFAQをしれっと削除していました。（「basic認証はできますか？」の下にあった）
CPUは共有ですか？
https://megalodon.jp/2018-0204-2144-52/https://www.conoha.jp:443/faq/vps/
いやー、せこすぎるよGMO。
しれっとFAQを共有のCPUですに書き換えるだけでも十分過ぎるくらい悪質だけれど、不都合だからと、いくらなんでも掲載を下ろしてしまうとは…
いやー、早急な改修というのは、隠蔽なんですね。GMOすごい。
一般的な仮想環境の場合、CPUをオーバーコミット（簡単にいうと、8個のCPUに9個以上のvCPUを必要とするゲストOSを起動してしまう）しているケースです。今更、共用云々ということを言ってきたので、この点具体的に聞いてみました。
ご担当者 様
いつもご利用いただき、まことにありがとうございます。
はい、見事に答えてもらえていません。
こちらとしては、契約するときのスペックに関わる重要事項だから聞いているのだけれど、どうやら、ご案内できかねる内容らしい。
厳密なことをいうと、HyperThreadingを利用していると厳密には1vCPUで0.5コアの共有割り当てな一方で、1vCPUで1コア近い処理が出来てしまうので影響がなくはないのですが、こちらの件だとHTに配慮して2コアのサーバを借りていたので、それも関係なかったりね…
ご担当者 様
いつもご利用いただき、まことにありがとうございます。
お問い合わせの件につきまして、すでにVPSの削除を
大変恐縮ではございますが、ご料金の調整につきましては
今後ともConoHaをよろしくお願いいたします。
─────────────────────────────
FAQ/よくあるご質問 https://www.conoha.jp/faq/
お問い合わせ info@conoha.jp
─────────────────────────────
おかげさまで22周年 すべての人にインターネット
■ GMO INTERNET GROUP ■ https://www.gmo.jp/
─────────────────────────────
機密情報に関する注意事項：このE-mailは、発信者が意図した
上記の使い方ですが、別に他のサーバに対するクラッキングをしているわけではないし、停止させられることはありません。念のため…（似た使い方をメジャーなA社、G社のパブリッククラウドや、S社のVPSでやってみましたがいずれも問題なし）
そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います。
ドワンゴアカウントシステムはScalaのコードだけで22万行を越え、ドワンゴ社内で最大のScalaリポジトリとして知られています。
ドワンゴのユーザーアカウント基盤は明らかに破綻しています。 10 年以上にわたり、ガラケー時代から今に至るまで多くの業務をコードに落としていくことは極めて難しい作業であったと思います。そうはいってもやってるうちに一回なんとか出来なかったのかとは思うわけです。やっている当人たちがテンションを上げているほどには開発効率が出ていない、むしろ足を引っ張っているという可能性はかなり高いと思います。
ニコニコ生放送(以下「生放送」)ではバックエンド・フロントエンドのサーバーを建てる環境として、2016年からDocker Swarmを採用し始めています。
Docker Swarm Mode については私も検証をしたことがあり、非常に優れた思想をもった将来性のあるプロダクトであると感じていました。個人的な検証はずっと続けています。まず swarm mode の何が優れているかと言えば、コマンド体系の分かりやすさです。開発者は何のストレスを感じることもなくクラスタを扱うことができます。さらに、サービスディスカバリ層を極めて扱いやすい形(サービス作ると公開することを指定したポートがクラスタ内の全マシンで公開されるので、あとはクラスタ全台に向けてロードバランシングするだけでいい事実上のゼロコンフィグレーション)で実装したことは素晴らしいと思います。しかし、残念ながらこの素晴らしい思想を持ったプロダクトは砂上の楼閣でした。その肝心なサービスディスカバリは安定しておらず信頼できません。またマスターがコケてそのままクラスタ全部が機能を停止するだとか、ノードが気づいたら行方不明だとかはざらです。こうした問題は 2016 年末から現在に至るまで残念ながらあまり改善されていません。
私は kubernetes が嫌いです。 Google 製品は開発者の UX を考慮しないからです。しかし、 2016 年においても、 2017 年の今においても彼のプロダクトが商用環境における事実上唯一の選択肢でした(ついでに言うならば docker service コマンドで kubernetes いじれるようになるので UX 問題も解決する)。正直、 2016 年から swarm mode を仕事で使おうとしたのは、深刻なソフトウェア検証能力の欠如を感じます。
実は分散ファイルシステムも独自に開発しました。もともと既存のオープンソースのファイルシステムを使っていたのですが,それだと期待する性能が出ないことがわかり,独自に調査開発を進めることにしました。
こちらの記事を読んでいただければわかりますが、配信基盤の再構築を行うにあたって
ということが分かります。
触れない話: 事実上全然稼働しなかった CTO 、北の将軍様
パブリッククラウド、特に CDN を採用することは開発負担の軽減に多いに貢献するように考えられます。実際「 akamai 使えよ」みたいなこと言ってるユーザーは結構いるわけです。ではなぜ彼らがそうしないのか、その意思決定の理由をここでは探ってみます。
動画ストリーミングサービスとして遅れているというのは恥ずかしいことではありますが、ハードウェアや使っている回線の影響もありますので、どのサービスも最終的には同じになると思っています。その差をつけられることはこの先はなくなると思っています。
ようするに CDN 屋だろうが自前だろうが最終的に同じようなところに落ち着くだろうという予測を彼らは立てているということです。しかし現実問題として現在競合他社との差は大きく、新配信基盤のリリースの目途は立っていません(半年以上の遅れというのは通常そういうことでしょう)。ではなぜ彼らは最終的に差は無くなると予測するのか。私はこの点において彼らが空元気をふりまわしているとは思いません。
CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性
要するに CDN 各社は現在逆ザヤで出血を続けながら戦闘しており、 DDoS 対処を中心としたセキュリティサービスにより最終的な帳尻を合わせている状態です。自前で動画配信インフラを構築した経験のあるドワンゴは CDN 大流行の早い段階から「成立するビジネスではない」という見通しを立てていたであろうと思います。
ただしこの点において今後もビジネス環境、技術環境が現在のように推移するのかは、私にはよく分かりません(誰にも分かってないでしょう)。結局同じようなところに落ち着くならありもの使っとけよとは思わなくはない。
まあもう無理でしょいろいろ
26歳3年目 転職を考えてる。
持ってる資格
Oracle Bronze,Silver
統計検定2級
大規模構築経験あり
仮想基盤やAWS,Azureのパブリッククラウドの構築経験あり
ミドルは、bind,sendmail,samba,nginx,Apache,Zabbix,LDAPとか
麻雀(天鳳)が趣味で、牌譜の解析とかやりたかったから統計を勉強して、資格にチャレンジしてみた。ついでにpythonと数学も。どちらも業務で使うことはほぼない。
趣味Webメディア作ってたから、Wordpressサイト作るくらいなら一晩で出来る程度の能力。
