  |
はてなキーワード: データセンターとは
玉石混交ではあるが、省庁の資料でも言及されるほどで、真面目に分析した物もあると思う。
その前だと、日本版シリコンバレーだろう。こちらも上手く行かなかった。
一方、中国はというと、上手く行っている。
真似が上手いというよりかは、アメリカ企業で働いていた人をかき集めて、同じ仕組みを立ち上げていると言ったほうがいいのかもしれない。
例えば、Moore Threadsという会社が中国国産GPUで、それなりの性能のものを作ってしまった。
アメリカと同じで物量で攻めているというのもある。
まあ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の活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
今やiPhoneを始めとしたスマホカメラの方が性能が良い場合も多いのだが
一眼レフに馬鹿デカいレンズを付けてる方が良い写真が撮れると信じている人が多い
特にバズーカと呼ばれる望遠でF値の低いレンズを買ってはわざわざ興味も無い飛行機を撮りに空港へ行く理系男子は多い
ちなみにその手の望遠レンズはエクステンダーを使うことで更に焦点距離を伸ばすためにF値が低い
エクステンダーを付けることでより望遠になるが、明るさを下げることになるからだ
望遠と超望遠の2本を持ち歩くのが面倒かつ高価なのでエクステンダーを使うような、ネイチャー系の人が使う
わざわざ夕方以降の暗い空港で飛行機を撮るために作られてるわけではない
当然、明るいレンズは写りが良くなるわけでは無いし、そもそも絞って使う
他にもフルサイズ信仰やキヤノン・ニコンの無意味な闘争などキリが無い
という人でもULTRA HDでハイレゾなヘッドホンを使ってる人が多い
人間の可聴域を超えた音を感じ取れると主張する
AACの256kbpsで十分すぎるほどに再現出来ているはずなのだが違いが分かるそうだ
まぁ若い人が聞き比べればもしかしたら分かるのかもしれないが、そもそも聞き比べなければ良い
そして30歳を過ぎたら自分の耳に自信を持たない方が良い
豆の種類、産地、精製処理、焙煎度合い、淹れ方、エスプレッソ、ラテアート、などなど
一番こじらせてるのは自分で焙煎・手挽き・ネルドリップとかやってる人だ
Youtubeで見つけることができたりする ただしこちらの深淵も覗かない方が良い
個人事業主で何かサービスを始めるわけでもないのに自宅ラックをやってる人からは距離を取ろう
自宅ラックを運用することで技能習得できるとかいう謎理論をかざすが、自宅の庭にSASUKEを作る人と大差ないことに気付いてない
サーバならVMやクラウドで良いし、ルータ・スイッチもシミュレータで良い
そもそも最近のルータはCISCOじゃないことも多いし独自コマンドが多いので実際に使い始めてからマニュアルを読めば良いし、それで間に合うような技能を付ければ良い
データセンターの近くに住むことで低遅延だという主張も多いが光は1kmを5マイクロ秒で進むという事実からは目を背けている
何故か？筋肉が付いてない人がエセ科学を主張しても誰も信用しない
万人に共通するとは限らないがその人には少なくとも効果があったということは外から見て分かる大きな事実だ
リクルートにおける VDI の導入、運用、コロナ対応、そして今後の ICT 環境を紹介する連載。
最終回は、現在取り組んでいる VDI と FAT PC のマルチ環境についてお伝えする。
石光直樹，リクルート（2021 年 06 月 04 日）
28 →目次に戻る
ただし、そうしたユーザーに対して環境が変わることについてきちんと説明しないと、混乱につながってしまいま
す。そこで、「なぜこのような環境に切り替えることに至ったのか」や、目的、狙いについてプロジェクト内で改め
て議論しました。ユーザーに対して納得感ある形で社内説明資料などをまとめて、各部署の主要なユーザーに向
けて情報を発信していきました。
今後の移行時には、さらに分かりやすい資料の共有や移行マニュアルの整備などを行い、社内広報の体制も整
えていきたいと考えています。
マルチ環境の実現は簡単なことではありません。特に FAT PC の環境をどう作るのかについては、時間をかけ
て検討しました。まずは、VDI 導入により大幅に解消された “3 つの課題 ”、すなわち「セキュリティの向上」「PC
管理コストの削減」「働き方変革への貢献」の対応策を FAT PC でどのように実現するか。これが次の課題です。
「セキュリティの向上」については、高セキュリティ業務にはセキュア VDI を提供し続け、FAT PC に対しては従
来よりもセキュリティを強固にすることにして、この課題をクリアしました。
続いて「PC 管理コストの削減」では先述の通り、VDI 化によって大きなメリットを得られた部分でした。例え
ば、夜間にパッチを当てたりできるのは、システム管理担当者からすると非常にメリットになります。ところが、FAT
PC に切り替えると、このメリットは享受できなくなってしまうことから、VDI 導入時に刷新した PC 管理システム
を FAT PC にも導入することで一定の解決を図るのに至りました。VDI の導入前に使っていた “ お手製 ” の PC
管理システムでは、パッチ当てや OS 更新などが大変でしたが、最新の PC 管理システムを導入することで、かな
り容易になっていたからです。とはいえ、VDI の管理性には劣ります。この点は、中長期視点でのより良い環境を
目指すために、優先度を下げた部分といえます。
そして「働き方変革への貢献」については、先述の通り、昨今の状況を踏まえると、ビデオ会議をより活用で
きる FAT PC の方がメリットを引き出せるのではないかと考えました。ただし、FAT PC に切り替えることで、い
ままでとはネットワークの流れ方が変わってきます。VDI では、データセンターと端末の間でやりとりされるのは
VDI 画面のデータが中心でしたが、FAT PC ではさまざまな実データがやりとりされることになります。また、社
外などから社内に VPN 接続をする必要があり、その部分がボトルネックになりがちです。その問題に対しては、
ネットワークを再検討することで解決を図ることにしました。われわれの社内ネットワークは VDI に最適化されて
いたので、FAT PC の増加に合わせて拠点のネットワークを増強したり、VPN を増強したりすることを検討しま
した。これにより、働き方変革で求められていたテレワークの要件に対しても十分応えることができると考えてい
たのです。
29 →目次に戻る
しかしながら、この方針は大きく変更を余儀なくされることになります。その理由は 2 つあります。1 つ目はコ
社内ネットワークの再検討はコロナ禍の影響を強く受けることになりました。在宅勤務の方針が示されたこと
で、社内からの接続が減る一方、リモート接続が増え、社内のネットワークトラフィックの在り方が大きく変わって
しまったからです。コロナ禍が続く中で、そしてアフターコロナでそういった状況がどうなるのかについては予測が
難しく悩みました。単純に拠点のネットワーク、特に WAN を増強したとして、使われなくなるなら投資が無駄に
なってしまいます。また、ネットワークにおいては今後のトレンドとして「ゼロトラストネットワーク」が注目されて
きています。おそらく、われわれの目指す「クラウド＆マルチデバイス環境」を支えるネットワークは「ゼロトラス
トネットワーク」になることでしょう。
では、いま「ゼロトラストネットワーク」のようなネットワークを入れるべきなのか。それともいまは暫定構成に
して将来的に「ゼロトラストネットワーク」に移行できるようにするのか――。
コロナ禍で勤務の環境が急速に変わってきていることも踏まえて、この点を検討しなければならなくなりました。
いまもまさに検討しているところで、いまだに完全な結論は出ていませんが、現時点では PC 環境と同じく、将来
的には「ゼロトラストネットワーク」に移行できるように、いまのネットワーク構成を考えるべきと思っています。
変化に対応して、かつ自ら変化を引き起こす
さらに、FAT PC 導入においては大きな変化があります。それは「SAC」（Semi-Annual Channel、半期チャ
ネル）の導入です。
VDI 環境においても「Windows 10」の導入は完了していましたが、「LTSB」（Long Term Servicing Branch※）
を導入していました。頻繁な更新を望まないユーザー向けに作られた、機能更新がない固定的な Windows 10 のモ
デルです。これに永続ライセンス版の「Microsoft Office」を組み合わせて利用していました。
※現在の名称は、「LTSC」（Long Term Servicing Channel、長期サービスチャネル）
これは、「レガシーアプリが存在するので、機能更新がない OS の方がいい」と思っての選択でした。しかし、機
能が更新されないので、OS や Office の最新機能が利用できないなど、将来的には「Microsoft 365」への接続
も制限されるような状況でした。
30 →目次に戻る
他方、SAC なら OS や Office が常に最新の状態になります。そのため、半期あるいは 1 年に 1 回程度のペー
スで機能が大きく更新されます。IT 部門としては、機能更新時に社内アプリケーションの動作確認などをする必
要があり、PC 管理タスクが増えてしまうことになります。PC 運用コストの増大につながり得るので、VDI から
FAT PC に切り替える際の検討ポイントの一つでもありました。しかし、ここでもわれわれは中長期視点を大事に
しました。
今後の「クラウド＆マルチデバイス環境」においては、環境が常に最新になる世界が普通になるでしょう。いま
のスマートフォンを見てもそうですが、OS はどんどん更新されて、次々と新たな機能やサービスが利用可能にな
るのがむしろ普通であり、その波が PC の世界にも到来しているのです。PC 運用コストが上がったとしても、わ
れわれもこの波に乗って、ユーザーに対しても新機能やサービスを次々に提供していき、より良く業務を行っても
らえるようになればすてきだなと思いました。
そこで、VDI から FAT PC への切り替えに際して、OS のモデルも LTSB（LTSC）から SAC に変更すること
にしました。PC が最新に変わっていくSAC のような世の中の変化に対応しながら、われわれの環境においても
変化を引き起こして業務を変えることができればと思い、現在、導入を進めています。
VDI 基盤の抜本的な刷新
ここまでは大多数のユーザーが利用することになる FAT PC のことを中心に述べてきましたが、セキュア VDI と
特定用途 VDI として利用する VDI 基盤のリプレースも大きな仕事です。
VDI 基盤リプレースにおいてもいままでの構成を踏襲せず、一からあるべき姿を検討することにしました。まず
検討したのはクラウドの導入です。将来「クラウド＆マルチデバイス環境」になれば、VDI 自体もクラウドのサー
ビスの一つという位置付けになるだろうと考え、クラウドでの VDI 利用を検討しました。
しかし、残念ながら今回クラウド VDI の採用には至りませんでした。われわれの試算ではオンプレミスに比べて
コストが見合わなかった点と、管理機能がまだまだのように思えた点が見送りの理由でした。クラウドはますます
発展する領域なので、今後は状況が変わるかもしれません。われわれも引き続き状況を観察し、一部の環境には
クラウドをトライアル的に導入してみることも視野に入れて、現在、検討しています。
当面の方針としてオンプレミスの VDI を構築することにしましたが、いままでの構成をそのまま踏襲するような
ことはしませんでした。必要としたのは、運用性やコスト、拡張性に優れたアーキテクチャでした。
31 →目次に戻る
議論、検討を重ね、さらに比較、検討した上で、われわれは HCI（Hyper Converged Infrastructure）構成
を選びました。HCI はサーバ中心のアーキテクチャで、SAN（Storage Area Network）スイッチやストレージ
を省くことができ、構成がシンプルになり、運用性やコストにメリットがある他、リソース拡張はサーバを追加する
だけでよいので、拡張性にも優れています。われわれが望んでいた点を満たすアーキテクチャと評価しました。
いままでは「サーバ＋ネットワーク＋ストレージ」のいわゆる「3Tier」構成で安定運用できていたので、これを
変えるのは大きなチャレンジでした。とはいえ、チャレンジしないことには運用性もコストも拡張性も勝ち取れませ
ん。「新たなことに挑戦するのが、われわれのエンジニアリングの方針だ」と考え、HCI 構成を選びました。
加えて、VDI 基盤のデータセンターのネットワークを SDN（Software Defined Network）に切り替える決断
もしました。従来の構成と比較し、運用性や管理性を鑑みて、より優れているという結論に達したからです。また
仮想システムを構築するにあたり、CIFS しか使えない NAS をバックアップ用に選定してきた SI 屋さんが居たので、CIFS と iSCSI のどちらが早いのか、試してみました。
テストに使う NAS は QNAP の Turbo NAS TS110
http://www.tekwind.co.jp/products/entry_6719.php
です。もう６年以上愛用して、カビが生えてもおかしく無い程に古いし, Marvell 800Mhz という低スペックな Qnap NASです。 100Mbps 時代のモノです。
昨年、HDDがお亡くなりになったので、3Tb の HDD に交換しました。ファームウェアはこんなに古い機械でも、QNAP シリーズの最新バージョンが利用できます。
iSCSI は、今あまり見なくなりましたが SCSI ケーブル規格や、SASケーブル接続のハードディスクを、一般的なIPネットワークで規格で仮想化したものです。
マウントするホストシステム側は iSCSI initiator, ディスクストレージの機能を提供する側を iSCSI Target と呼びます。
ホストから「マウントするしない」はイニシエータ側のソフトウェア的な操作で行います。これは便利な機能で、ディスクの故障などで、一時的に物理的に取り外さなければいけない場合でも、ホストからの操作だけで実際のケーブル結線の脱着を行う必要がないので、今時での SAS の外付けディスクドライブの様に、ホストもシャットダウンして電源を切り、結線を外して修理、交換する、という必要がないので、ディスクデバイスの修理をホストの電源を止めないで実施できると言う、実に便利な事ができます。
という事で、仮想環境では実に使いやすいストレージデバイスなのです。
マウントするホスト側から見ると単純に SCSI/SAS のハードディスクに過ぎません。iSCSI のストレージをマウントしてからは、通常の増設ディスクの様にフォーマットして、ホスト側で使う一般的な XFS, ext4, NTFS などのフォーマットでフォーマットする必要があります。
Linux の iSCSI ターゲット側からは、内部にターゲットとして使う「巨大なファイル」が、どん！ とあるだけです。この巨大ファイルを、イニシエータ側に仮想ディスクイメージとして提供しています。当然シンプルな仮想イメージなので、ファイルそのものをバックアップコピーすれば、ストレージのイメージそのもののバックアップができます。
※ qnap NAS の場合、iSCSI イメージは、 /share/HDx_DATA/.@iscsi.img の下にドンと作られるようです。
[Solved]How to mount iSCSI file?
https://forum.qnap.com/viewtopic.php?f=180&t=25322
[/share/HDA_DATA/.@iscsi.img] # pwd
[/share/HDA_DATA/.@iscsi.img] #
[/share/HDA_DATA/.@iscsi.img] # ls -l
-rw------- 1 admin administ 6442450944 Nov 12 2017 iSCSI-2015ace1-5a078d66.000
-rw------- 1 admin administ 1073741824 Jun 24 09:52 iSCSI-lun4-5d0de534.000
-rw------- 1 admin administ 107374182400 Nov 4 2015 iSCSI-nss01-56399e1a.000
-rw------- 1 admin administ 5368709120 Nov 11 2017 iSCSI-nss2015-5a06cf6d.000
-rw------- 1 admin administ 21474836480 Jun 22 17:11 iSCSI-test-56b3ce90.000
-rw------- 1 admin administ 5368709120 Jun 22 17:11 iSCSI-test-56b3ce90.001
[/share/HDA_DATA/.@iscsi.img] #
※ とても重要
CIFS/NFS のファイル共有NAS と違い、iSCSI でマウントして一つのターゲットを制御できるのは、一つのホスト、一つのイニシエータだけです。複数のホストからイニシエータでマウントする（できちゃいます）と、ファイルの排他制御は行われないので、ファイルシステム自体の不整合が起こります。
つまりファイル共有という目的には向いていない、という事です。あくまでも iSCSI ターゲットはネットワーク上の仮想ディスクです。
もっとも、一つのホストからマウントしてファイルを保存して、いったんオフラインにして、ターゲットを別なホストからマウントする、という事はできます。また、ターゲットは一つの iSCSI デバイスで複数作れるので、１台の iSCSI 装置に複数のターゲットを実装して、複数のホストから別々のターゲットイメージをマウントする事は問題ありません。
極端な話、ホストのハイパーバイザーは USB メモリやSANブートさせて、後はマウントした iSCSI の仮想イメージ上で、仮想マシンを動かす、HDDレスなハイパーバイザー運用もできます。
物理的な転送速度は、ネットワークの速度とディスクデバイスの性能に依存します。当然 10Gb base のネットワークカード、HUB、高規格なケーブルを使えば、論理的な性能は 10Gbps です。大抵は NAS の性能がそこまで出ないのですけどね。ヨドバシカメラあたりで売っている 4,000 円程度の 1G HUB でも、そこそこの性能が出てしまいます。
距離は、IPがつながればどこでもなので、ホストコンピュータとメインのストレージを自社のサーバールームに置き、イニシエータを動かし、バックアップ用の iSCSI ターゲットをデータセンターに置く、なんてこともできます。
【送料無料】QNAP TS－431P2（ホワイト） NAS 4ベイモデル クアッドコア CPU ／ LAN 2ポート搭載 （TS431P2）
価格:56,145円
感想(0件)
iSCSI の耳慣れない言葉に LUN （論理ユニット番号 : Logical Unit Number）というのがあります。
昔の SCSI は、 SCSI バスアダプタに７番のIDを振り、残りの 0 ~ 6 のディスクや CD, Tape などに ID を振り分ける物理的な３ビットのディップスイッチやジャンパ端子が付いていました。これが SCSI アドレスです。
これが実に難物でした。特に、複数の SCSI バスアダプタカードをデュプレクス設定する場合、割り込み番号も別々にするので、手が滑ってジャンパピンを飛ばして床を這いまわって探したり、難解なディップスイッチを前に数日悩んだものです。
つまり一つのSCSIバスには 0~７の合計８台（うち大抵７番はSCSI バスカード）の物理ユニットデバイスがつながって別々に見えたという仕組みだったわけです。
ところが SCSI バスを使った Raid コントローラが出てくると、ディスクの鈴なりが、一つの物理デバイスに見えてしまうわけです。これを「論理的な仮想番号」に分割して、システムからは、単一の鈴なり Raid ディスクを複数の論理番号に分割したわけですね。
これが LUN というヤツです。
iSCSI 機器のターゲットも、内部のソフトウェア的に複数の論理デバイスに分割して、複数のホストコンピュータから複数の物理デバイスのように見せかけるわけです。
別々な LUN は一つ、あるいは複数の iSCSI 機器によって、複数のホストに別々のディスクデバイスとして見せかけるンです。
https://en.wikipedia.org/wiki/Logical_unit_number
Qnap NAS の場合、iSCSI ターゲットはウィザード形式で簡単に作成できます。EXT4 ファイルシステム上で、オンラインでも簡単にサイズの拡大ができるので、 Windows の Storage Server のように NTFS の VHD 形式ではないので、そこそこ性能が出ますが、いかんせん古さと遅さは否めません。
Qnap NAS の iSCSI ターゲットの設定は、偉そうな Linux 系サイトに書いてある程、面倒なことはありません。ストレージマネージャから iSCSI タブにあるウィザードに従って iSCSI ターゲット名に任意の名前を付けると IQN にその文字列が追加されるだけです。わざわざ vi エディタに「正確に」綴りを間違えずに設定する必要もありません。ここでは Chap 認証は付けませんでした。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16405779.jpg
機械は古いのですが、逆に言うと、「古くて遅い」ため、サーバーとNASとの接続プロトコルの性能差が、如実に現れる事になります。
QNAP TVS-951X 10GBASE-T/NBASE-Tポート内蔵
Windows10 の Microsoft 製 iSCSI イニシエータは「コントロールパネル」＞「システムとセキュリティ」＞「管理ツール」の中にあるので、ここで、設定済の iSCSI 「ターゲットを」 「検索」して選んで「接続」します。Chap 認証を付けておいた場合はターゲットで設定したパスワードが必要でしょう。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16412132.jpg
新規に作成して、接続した後は、フォーマットされていないため、ディスクマネージャからフォーマットして使います。ちなみに、フォーマットして利用した iSCSI ターゲットの仮想ディスクは、他のマシンでマウントすることもできます。つまりHDDを取り外して、他のPCに繋げる事と同じことですね。
ＰＲ
ちなみに opeSUSE で使うにはこんな感じになりました。
open SUSE Leap 15.1 で iSCSI NASを使ってハマった
https://islandcnt.exblog.jp/239328437/
一番イラつくのは、巨大なファイルの転送でしょう。という事で 3G 程ある SUSE Linux のインストール用DVDの ISO ファイルを CIFS でコピーしてみます。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16414334.jpg
３分１１秒かかりました。１Gビットネットワークで 12～3% 程度の帯域を使って通信しています。明らかに古いNAS の性能が足を引っ張っているようです。
スループットは 150Mbps 程度で全体の最大１５％程度でしょうか。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16415832.jpg
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16422170.jpg
初速は出るのですが、その後は、ボロイ TS-110 の性能がモロに出ます。それでも 20 MB/s から 25 MB/s 程度は出ています。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16423835.jpg
２分２５秒でした。 大体２０％程度のスループットです。
--
数字に弱い私の脳みそですが、 iSCSI は CIFS より 1.5倍くらい早い、という事が言えます。
Zabbix で QNAP TS-110 の I/O を見てみると、前半の CIFS アクセスより後半の iSCSI アクセスの山が高い事がよくわかります。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16425860.jpg
CIFS を使ったリモートディスクのマウントは、他のPCからもアクセスができる、というメリットがありますが、iSCSI は単一のホストからのアクセスしかできません。<--- これ重要.... -- もっとも、ターゲットストレージを複数作って複数のサーバーから異なるデータ領域にアクセスはできますが -- バックアップ用途や、サーバーの増設ストレージとして考えれば、良い選択であると言えます。
もっとも、iSCSI デバイスそのものは、ターゲット単位で別々なホストから接続できます。しかし同じターゲットで別々のホストからイニシエータから繋ぐと、とても笑いごとにならない事態になるので、普通やりません。
ハイパーバイザー同士で一つのターゲットを共有してライブマイグレーションはしたことはあります。
こうした性能のわずかな違いが、仮想化システムのハイエンドな領域で違いとなって出てきます。なお Qnap でも openiSCSI でも Windows Storage Server でも取った領域そのままのサイズのでかいファイルが作成されるようです。
国産 NAS の「ハイエンド」と称する「LANxxxx」などのモデルでは Windows Storage Server を使って NTFS フォーマットしています。Windows Storage Server は見た目 Windows サーバーそのものなのですが、ところどころちゃんとデチューンされているようで、SOHO向けが限度です。
こういった国産 NAS メーカーの製品カタログでは、「ハイエンド」は Windows Storage Server を搭載して、低価格のNASは Unix 系のシステムで「低価格」を謳っていますが、そもそも、上位モデルは、CPUやメモリの性能が高いものが使われています。性能が違うのは当たり前なのですが、あまり性能が出ないだろうと思います。
Windows Storage Server じゃなくて、ちゃんとした Windows Server と CAL 買えよな、という事なのですね。
このあたりは独自OSを NAS としてチューニングした Qnap や Synology, asuster などの iSCSI 機能付きの NAS を中規模ネットワークのミドルレンジの NAS として利用したほうが良いと思います。
仮想環境でのネットワークアタッチストレージ(NAS)は、本回線（構内LAN）とは切り離し、ストレージ専用のネットワークとして独立して運用させるのが基本です。サーバーとNAS間で凄まじい通信が発生します。サーバーNICが２ポート以上のものが推奨されます。
iSCSI はあくまでもネットワーク上のストレージのみの機能を提供するものであり、ファイル共有の手段ではない、という事です。
NAS をCIFSで使うと NAS が持つ独自のアクセス権限を設定しなければなりません。セキュリティも当然 NAS 独自の機能で設定します。
iSCSI はあくまでも「外付け SCSI デバイス」のネットワーク版なので、マウントする側のOSそのもののファイルシステム、セキュリティ機能、アクセス制限がホスト側の機能をそのまま利用できます。セキュリティ的には、マウントする際のパスワード制限しかないので、独自のストレージネットワーク内に配置すべきで、ユーザが使う構内ネットワークに配置すべきではありません。
政府のクラウド関係のコメントについて、企業向けと同じ感覚のコメントが多く気になった。
別に詳しいわけではないので想像だが、政府と一般人や企業視点とは違うだろう。
米軍事企業から購入している武器の情報については、同等のセキュリティが求められるはずである。
「軍事向けの規格に合格しているクラウド業者に情報を置くこと」と契約に書かれた時点で、国内企業の選択肢はハードルが上がるのではないだろうか。
日本の民間企業は軍事に関わることを避けていること、規格に合格しているかどうかの判断が米国あたりがハードルだろう。
そもそも合格が取れるのか？取りにいったら全部の情報開示しろと米国政府から要求されるのではないだろうか。
一般企業が使っているクラウドの領域と、政府系クラウドではもちろん分けられているはずで、スケールメリットがないため、政府クラウドは価格が高くなると考えるのが普通だろう。
データセンターが日本国内にあったとしても、重要な部分は米国企業内で開発、ディスク不良といった手のかかる部分のみ日本国内から人員配置されるが、
イージス艦などを購入しているのだから、クラウド料金も追加で払うのも構わないという話もあるかもしれない。
防衛費がGDP1%を維持しているが、クラウドにかかっている料金は別会計で毎年値上げされるとか、いざ国内クラウド業者に移動となったときにデータ移行料をボラれるとか、色々あるだろう。
2つ目は、米国政府からの日本政府情報の開示請求があったときに、米国企業は断れるのか？
日本国内のデータセンターと米国内データセンターで常にデータが同期されており、米国政府からは丸見えというのは考えられないだろうか。
どうせ米国にはダダ漏れなのだから気にしてもしょうがないという意見もあるだろうが・・・。
3つ目は、税金使うならノウハウ持ったほうがいいのではないか。
いざというときに言いなりになるだろう。
http://yamamototaku.jp/article/20210921/
山本議員の「元妻を守るために」という物言いが（「離別した夫にも擁護されるなんて、やっぱり高市さんは人格的に素晴らしいんですね！」みたいな感じで）高市支持者に大ウケ。さらに自民支持者右派だけじゃなく、河野太郎や小泉進次郞を叩きたいやつら、再エネを批判したいやつらにも大人気になっている。バズりまくりだ。よかったよかった。
IT関連消費電力は2050年には2016年の41TWh/年の約4,000倍の176,200 TWh/年になるとの予測が、国立研究開発法人科学技術振興機構の低炭素社会戦略センターによって発表されています。
現在よりも省エネルギーの進展があったとしても、IT 関連消費電力は莫大に膨れ上がることが予想されます。2050 年にそれらを再生可能エネルギーでまかなうための具体的計画を、環境大臣としてお示しください。
これ読んで、増田諸氏はどう感じるだろうか。少なからぬ増田が「『176,200TWh/年』というのがどれぐらいかわからないけど、ITの進展で電力需要がすごい増えるんだな、それは再エネだけじゃ到底まかなえないんだろうな、小泉進次郎はそういう現実的想定をしないで、夢みたいな再エネ推進を言ってやがるんだな」と思うんじゃなかろうか。でも、そうじゃない。
「176,200TWh/年」というのは、今の日本全体の年間発電電力量の180倍、世界全体の発電電力量の7倍だ。そんなもん再エネどころか原発だろうが火発だろうが絶対充当できるわけがない。もし小泉進次郎や環境省から「なるほど、再生可能エネルギーでまかなうことが不可能だというなら、2050年にそれらを原子力や化石燃料エネルギーでまかなうための具体的計画を、対案としてお示しください」と反論されたら一発で撃沈だ。なんなんだこの数字？ というわけで引用元のPDFを読む。vol.1からvol.3まである。
https://www.jst.go.jp/lcs/pdf/fy2018-pp-15.pdf
情報化社会の進展に伴って、従来の予想を超える膨大なデータが取り扱われるようになり、この傾向は今後も拡大すると考えられる。これに伴い、エネルギー消費がどのような影響を受けるかを 2050 年までを視野に入れ、調査、ヒアリングなどにより検討した。その結果、世界の情報量（IP トラフィック）は 2030 年には現在の 30 倍以上、2050 年には 4,000 倍に達すると予想され、現在の技術のまま、まったく省エネルギー対策がなされないと仮定すると、情報関連だけで 2030年には年間 42PWh、2050 年には 5,000PWh と、現在の世界の消費電力の約 24PWh を大きく上回る予測となった。すなわち、技術進歩がなければ情報関連だけで世界の全てのエネルギーを消費してもまだ不足するという事態になりうる。
現在日本の年間の電力消費量が約 980TWhであるから、現在の技術でまったく省エネルギー対策がなされないと仮定すると、2030年には年間使用電力量の倍近い電力を IT 関連機器だけで消費する予測となる。世界についても、現在の世界の消費電力が約 24,000TWh であるから、やはり現在の2倍程度の電力を IT 関連機器が消費する予測となる。また、2050 年の電力消費量は、現在と比較して日本、世界ともに約200倍という極端な数字となり、情報関連だけで全てのエネルギーを消費してもまだ不足するという状況になりうる。この情報量の爆発に対しての対策が必要なことは明らかである。
つまり「もし現時点から全く技術の進展がなければ、将来はIT関連機器だけで世界中のエネルギーを全部食い潰しちゃうぞ〜」という、極端なシナリオにもとづく極端な数字なのだ。そして、Vol.1（IT関連機器編）、Vol.2（データセンター編）、Vol.3（ネットワーク編）と分野別に分けて、こうした消費電力増大の問題を技術進歩でどう抑えていくか、という議論がされている。IT中心に増大するエネルギー需要に対して、どういうエネルギーミックスで応需していくか、みたいな話は全くしていないし、それどころか低炭素エネルギーへの流れが世界的に進んでいるから「電力供給が大幅に増大することは期待しがたい」とはっきり言っている。電力供給の増大に期待できないということは話の前提で、その中でのやりくりについて書いているのだ。
－データセンター消費エネルギーの現状と将来予測および技術的課題－
https://www.jst.go.jp/lcs/pdf/fy2020-pp-03.pdf
データセンターは IaaS、SaaS、MaaS などの新たなクラウドサービスの進展に伴い今後も膨大な計算負荷が発生すると考えられる。また全世界的な COVID-19 の蔓延にともなう仕事や学習形態のリモート化はそれに拍車をかけるものと思われる。さらに医療画像診断やセキュリティの顔認識なども膨大な計算量の発生が予測される。
これらの状況を考えると従来以上にデータセンターにおける計算負荷が上昇しそうである。一方で、供給電力には限りがある。また、現在世界中で急速に低炭素エネルギーに向けてエネルギーポートフォリオの見直しが進められていて、供給電力の大幅な増大は期待しがたい。
低炭素社会へ歩を進めつつ、社会に必要とされているサービスを提供するためにはデータセンターの省エネルギー化を進める必要がある。本提案書では 2030、2050 年も見据えて現状技術で固定された場合の電力需要を計算した。
（ちなみに具体的提案はCPU、GPUを中心とした要素部品類の集積度向上、液浸、ヒートポンプなどの冷却方法の工夫、必要なとき以外は動作しない（スマート化）…などなどの提案で、それに対する研究支援をせよ、と言っている。割と普通だね）
この提案書の報告主体は「国立研究開発法人科学技術振興機構 低炭素社会戦略センター」なんだけど、ようするにこの提案書は、山本拓議員の引用している文脈とは真逆の論旨のことを言ってるのだ。「これだけ電力が足りなくなるから、再エネを推進してはダメだ」ではなく、「技術に進歩がなければこんな非現実的なシナリオになってしまうから、それを避けるために、IT分野全体で電力消費を減らす努力と研究支援をしよう」という内容なのである。
山本氏議員公開質問ではこういう文脈を無視して、一部の記述を都合よく切り取って、意図的に「再エネではこの電力需要を賄えない、再エネを推進しない現実的な計画を立てるべきだ（立てることが可能だ）」みたいな誤解を招く表現をしてるように見えて、大変よろしくない。山本議員はエネルギー通だそうだから、「176,200TWh/年」という数字が全く非現実的な想定であることは本人も理解しているはずだ。そもそも公開質問では、この数字を引用した部分のすぐ上に
という記述もあるのだ。約 4,814 億 kWh/年 = 481400000000 kWh/年 = 481 TWh/年 である。東日本大震災以後、国内発電量の70%以上を担う火発を全部ひっくるめても480TWhでしかないことを山本議員は承知していながら、その直後には「IT 関連消費電力は 2050 年には （略）176,200 TWh/年になるとの予測が、国立研究開発法人科学技術振興機構の低炭素社会戦略センターによって発表されています」「現在よりも省エネルギーの進展があったとしても、IT 関連消費電力は莫大に膨れ上がることが予想されます。2050 年にそれらを再生可能エネルギーでまかなうための具体的計画を、環境大臣としてお示しください」という書き方をしている。こういうのは誠実な議論ではない。
統計情報で、論文数が増えているとか、ロケットの発射台数は日本より多いとかは知っているのだが、
中国が広すぎるのと、都市部と農村部で違いがありすぎるのも知っているが、どうも捉えどころがないのだ。
最先端のデータセンター向けの機器を作っている工場もあれば、できの悪い偽物を作っている工場もある。
中国の大学の授業レベルも伝わってこないし、日本のような雑用が多くて研究に専念出来ないような環境なのか、それとも研究に専念できる仕組みがあるのかもわからない。
中国の技術者がどのレベルの書籍で勉強しているのかもわからない。
なにせ日本でアメリカの技術書情報は入ってくるが、中国発の技術書の情報は入ってこない。
各ジャンルの中国で最先端を走っている人の名前も日本には入ってこない。
ここ。
何それつらい、オラクル「自社データセンターを作ったので引っ越ししてください」、客「何ですと？」
社内システムを使えないと仕事が進まないため、シオノギ製薬グループの中には、テレワークの初日に仕方なく出社した人もいた。「想定していたよりも使えない」と従来のVPNに危機感を感じた那須さんらは、拡張性の高いクラウド型VPNを急きょ追加で導入する方針を固めた。
「以前から、社内システムの開発の一環で、当社とAWSのデータセンターを専用線でつないでいたこともあり、AWSのVPNを使うことにしました。VDIの導入も考えたのですが、マスターイメージを短期間で構築するのは無理だと判断しました」
そこで、テレワークを始めた4月8日中に、シオノギデジタルサイエンスのインフラ部門のトップが、CIOを兼任している副社長に「緊急対応策としてAWS Client VPNを使いたい」と直談判。9日に議論し、10日に許可が下りた。「早速10日に、関係者が集まって動作検証を始めました」と那須さんは振り返る。
シオノギ製薬グループが導入した「AWS Client VPN」
許可は下りたものの、設定に時間がかかると出社する社員が増え、感染リスクが高まる。那須さんたちは出社する社員を減らすため、急ピッチで準備に取り組んだ。すると、そこに思わぬ落とし穴があった。
「VPN経由で社用の『Microsoft Office Outlook』に接続する動作検証をしたところ、エラーが出ました。認証に失敗し、『インターネットに接続できません』と表示されるのです。どうすれば直るのか、見当もつきませんでした」
那須さんたちは途方に暮れた。タイミングも悪く、4月10日は金曜日。週明けまでにVPNを増強し、社員のテレワーク環境を整えるには時間がない。間に合わせるには、休日を返上するしかなかった。「在宅で土曜日にトラブルシューティング、日曜日に動作検証を行うことにしました」と那須さんは振り返る。
そして、土曜日にネットワークの専門知識を持つ社員が調べた結果、ルートテーブルの設定が漏れていたことが分かった。
「デフォルトルートを規定する際に、AWSのVPNクライアントを経路に選択できていませんでした。既存のVPNは自動でルートを設定できており、AWSのリファレンス（説明文）にも記載がなかったので、自動で設定が完了すると思い込んでいたのですが、AWSは手動設定だったのです」
こうして那須さんたちは土曜日にトラブルを解決した。日曜日の動作検証には、休日にもかかわらず、研究開発系やバックオフィス系などユーザー部門の有志が参加。AWS Client VPNが問題なく動くかをチェックし、自宅からでも社内システムにアクセスできることを確認した。
・とりあえずVPNにしよう
・とりあえずAWSにしよう
令和の打ちこわしだ！
ALIBABA（オンラインモール、決済サービス、クラウド・コンピューティング：中国）
P&G（家庭用品）
Education First Japan（語学トレーニング）
airweave（寝具）
KNT－CTホールディングス（旅行業務およびナショナルトリップホスピタリティーサービス）
JTB（旅行業務およびナショナルトリップホスピタリティーサービス）
東武トップツアーズ（旅行業務およびナショナルトリップホスピタリティーサービス）
久光製薬（外用鎮痛消炎剤）
三菱電機（エレベーター・エスカレーター・ムービングウォーク）
リクルート（人材サービス&オンライン学習及び教育サービス）
Aggreko（仮設電源サービス）
EY Japan（プロフェッショナルサービス（監査、財務、税務、プロジェクトマネジメント、企画・運営管理コンサルティング））
パソナグループ（人材サービス＝人材派遣、人材紹介・斡旋、人事採用・管理・配置支援サービス、企業向け研修（オンライン及びオフラインのテストサービスなどの語学研修は除く））
ボストンコンサルティンググループ（プロフェッショナルサービス（戦略コンサルティング、プロジェクトマネジメント、企画・運営管理コンサルティング））
まじで試されてんぞ。
変わらないといけないんじゃないかまじで。
結局民主党にいれた国民のせいかもしれないけど、安倍が仮病かなんかで抜けて誰も選んだ覚えのない頼りないひょろひょろのおっさんが来てめちゃくちゃにしてんのよ。
殺しとかやっても、テロに屈したら敗北になるから五輪はやる方向に傾くだけだろうし、
https://jp.reuters.com/article/idJP2021061401001042
バーチャルで4000人
https://www.google.com/amp/s/mainichi.jp/articles/20210515/k00/00m/050/002000c.amp
著名人の参加で日本の主要メディアで報道がぬいと大きなムーブメントもありえない。
反発してもどうせ強行できるんでしょ。
むなしいよね。行動しても。
暴動しかこっちの声届かないんかな。でもみんなシラケてて、怒りのまえに呆れ、諦めが先にきてるならほとんどが傍観するのが関の山だよね。
このままブツブツ良いながらなぶられて気持ちの悪いスポーツを見せられるんだろ。最悪だよ。まじで。納税すらしたくないわ。
スポンサー一覧しといた。
個人の力では本当にどうしようも出来ることはないと思う。誤差程度だろうけど、
みんなできることあったら気が済むまでやってたらいいよ。
俺はここに書かれてある企業を出来るだけ忘れないようにネガキャンしつづけるわ。
五輪のスポンサーだったとこだよね！って言ったら、みんな「あぁ…そうなんだ」っていっきにヘイト高められるでしょ。
もし仕組んでる黒幕がいるとしたら
どこの誰が望んだか知らんけど、
国内で殴り合い始めてくれて潰し合ってくれるんだから、黒幕からしたら仲間割れさせるのが得策だよな。
仮にそうならそいつらの思う壺になってるんだろうな。この流れ。くやしいわあ。
ALIBABA（オンラインモール、決済サービス、クラウド・コンピューティング：中国）
P&G（家庭用品）
Education First Japan（語学トレーニング）
airweave（寝具）
KNT－CTホールディングス（旅行業務およびナショナルトリップホスピタリティーサービス）
JTB（旅行業務およびナショナルトリップホスピタリティーサービス）
東武トップツアーズ（旅行業務およびナショナルトリップホスピタリティーサービス）
久光製薬（外用鎮痛消炎剤）
三菱電機（エレベーター・エスカレーター・ムービングウォーク）
リクルート（人材サービス&オンライン学習及び教育サービス）
Aggreko（仮設電源サービス）
EY Japan（プロフェッショナルサービス（監査、財務、税務、プロジェクトマネジメント、企画・運営管理コンサルティング））
パソナグループ（人材サービス＝人材派遣、人材紹介・斡旋、人事採用・管理・配置支援サービス、企業向け研修（オンライン及びオフラインのテストサービスなどの語学研修は除く））
ボストンコンサルティンググループ（プロフェッショナルサービス（戦略コンサルティング、プロジェクトマネジメント、企画・運営管理コンサルティング））
丸大食品（ハム、ソーセージ、ウインナー、ベーコン、魚肉ソーセージ、かまぼこ、ローストポーク、スペアリブ）
＊参考：https://tokyo2020.org/jp/organising-committee/marketing/sponsors/
【シリコンバレー=白石武志】米紙ニューヨーク・タイムズ（NYT）は17日、米アップルが中国内のユーザーの個人情報を中国政府系企業と共有していると報じた。暗号化したデータを復元するデジタルキー（電子鍵）も米国から中国に移転しており、中国の捜査当局がアップルの同意なくユーザーの電子メールや連絡先などにアクセスしやすい状態にあると警告した。
アップルはこれまではデータセンターで保管するデータはすべて暗号化し、復元するためのデジタルキーは同社が管理してきた。NYTによるとアップルは中国政府の要請に従い、中国内のサーバーで保管するデータについては例外的に同国政府が承認した暗号化技術を使い、デジタルキーについても米国ではなく中国側に置くことに応じたという。
アップルは米国などでは捜査当局の要請に応じてiCloudの個人情報を提供するかどうかは個別に判断しており、場合によっては拒むケースもある。中国ではデータとデジタルキーの双方を中国政府側に明け渡したことで、アップルの意向とは関係なく捜査当局がサーバーから個人情報を引き出せる可能性がある。NYTは中国政府がこれまでにデータにアクセスした証拠はないとしつつ、「異例の取り決め」だと批判している。
アップルは18日までに出した声明の中で、NYTの報道について「主張の多くは不完全で古く、不正確な情報に基づいている」と反論し、猛反発している。中国の法律に従ってiCloudのデータを中国内に置くことは認めたが、「ユーザーのセキュリティーに関しては一切の妥協をしていない」と強調。暗号化したデータを復元するデジタルキーについても「当社が管理している」と述べた。
ただ、日ごろからプライバシーを「基本的人権」の一つと位置づけるアップルにとって、新疆ウイグル自治区やチベットでの人権侵害をめぐって国際社会の批判を受けている中国政府の規制に従うことは矛盾をはらむようになっている。中国では当局が不適切と見なしたウェブサイトへの接続を可能にする「VPNアプリ」を自社のアプリ配信サービスから削除するなど、中国政府によるネット検閲に協力しているとの批判もある。
https://www.nikkei.com/article/DGXZQOGN18E4F0Y1A510C2000000/
国家のシステムにSaaS、つまりAWSとか？外部サービスが推奨されるというのは問題ないの？
AWSやAzure、GCPが停止したら国家のシステムが停止するっておかしくないの？
他国もAWSやAzure、GCPを使ってるよ、とかそういう話ではない気がする
パクリだろうが何だろうが、中国のように国内企業で独立していれば自己責任ではあるが米国企業に左右されないわけで、
そういう国内で、国家手動でしかできない、強固なシステムをゼロから開発することが国家がやるべき役割であって、
ReactやVueを使って公的なシステムを作るなら、言いたくないが自分でもできうる、
弱小零細でも入札で選ばれて公的なシステムを書かされることはやってきたわけで、
今、LINEをまたコロナのためのシステムの中核に入れようと政府はしているけど、
日本の国家の公的なシステムが韓国企業なしで成立しないなんて、そもそも国防上の大問題ではないのか？
これから6年以内に台湾有事が起こることを米国は想定していると公言しているが、
中国はともかくロシアはプーチン政権は、第三次世界大戦を常に想定し、戦略核の使用に前向きであって、
飽和戦のような全力で核を使うということはないとしても、都市単位で消える戦争は十分ありえる
いかにクラウド側のデータセンター等が分散されていようが、そのへんも把握されていることが予想されるし、
いずれにせよ、日本独自の強固なシステムがあるのか？ないなら作るべきではないのか？
そういう役割こそがデジタル庁ではないのか？と自分は思ってしまうのだが考え過ぎなのだろうか
それから、「デジタル庁の副業スタッフとして弊社から数名選ばれました」などという文章をネットで拝見したが、
国家の仕事に従事し、公的なデータを扱う人材がうちの会社にいますよ、と公言していいのだろうか？
例えるなら、うちの会社のスノーデンくんが米国の国家機密を扱うスタッフとして選ばれました、と公言するようなものである
名前は分からなくても、どこの会社か分かれば、そこからソーシャルハックでなんとかなるように思えるし、
接触して賄賂を渡すなどして、デジタル庁のシステムに細工をする等だってありうるのではないか？
自分は心配しすぎなのか、デジタル庁に期待しすぎなのかもしれないが、
逆にいうなら、そんな大したこともないベンチャーという名の弱小零細でもできうるシステムやアプリを開発する庁の設立で、
大々的にどちらかといえば政府が宣伝したり騒いでいるレベルに危機感を感じるし、
本当にそんなもんが必要なのか、
必要だとしても、だったらこんなに騒ぐほどでもない、期待させて肩透かしさせたいのか、甚だ疑問に思うのである
中国はあれはあれで酷いことが多い国だとも思うが、
アリババだのテンセントだのがコロナ関連のシステムもスマホアプリも短期間に開発したと思う
いわゆるアンケートを記入させ、そこからコロナの疑いがあるか、
記入した端末の位置から感染がどれぐらい広がっているかの把握が目的であり、
日本はこれをLINE側が手動する形で実現したが、あれからかなり時間が経っており、
今度はLINEという韓国企業の助けは借りずに日本独自のシステムを構築するのかと思いきや、
またしてもLINEを中核に添えてというのは自分にはまったく納得できない
韓国は長い間政治的都合もあり、日本のアニメを輸入しては国産アニメだと偽って国内で放送したり、
日本のアニメをパクったり切り貼りして放送してきたような時代があったが、
そういった制約からも特にネットワークに関するプログラミング、いわゆるネトゲ開発に秀でることとなり、
国のバックアップがあったり、JavaのNettyなんかも開発者は韓国人だったと思う、うろ覚えだが
アイドルとの1対1のチャット権を争うために大規模なイベントを実現したこともあったように記憶している
素人なのでよく分からないが、簡単には破綻しない大規模チャットを実現できている
そういう経緯からも、韓国の方がリードしているのは理解できるが、この話も大分前の話であり、
要はそういった不可能そうなことを可能にする機会とか、金とか、チャンスがないだけなのではないか？
未踏のようなシステムも、応募する側もできるだけ実現可能で、かつ確実に天才プログラマーの称号が欲しいとか、
日本の国が政府が手動になると、なぜこうも話がみみっちく小さくなるのか？
（そしてシグマのように逆に壮大に見せかけるだけ見せかけて実体は頓珍漢になる
苛立ちをぶつけただけで文章がまとまってない感があるが、消すのも書いた時間が惜しいので登校するが、
高木氏の指摘はともかく、なんとなく単なる現政権の人気取りの一環というか、
コロナ対応への苛立ちをかわしたい、デジタル庁ができればイケてるアプリができるんです、
