はてなキーワード: ストレージとは
Box.comというクラウドストレージサービスがある。法人向けがメインのせいか個人で使ってる人は少なさそうだし、需要はないだろうけど記録として残しておく。(本当はオンラインストレージ専用スレ https://mevius.5ch.net/test/read.cgi/esite/1620029734/l20 に投稿する予定だったけど規制で書き込めなかったので此処に)
確か10年ほど前に初期のキャンペーンで登録した50GBの無料アカウントで、最初は数年放置していた。4年ほど前にdマガジン(雑誌のサブスク)に加入してから、気になった記事はキャプチャして画像を加工 → PDFに固めてアップするようになった(個人利用の範囲だから問題ないと思う)。投資・経済・時事とかが半分以上かな。他には健康とかレシピとか、至って健全なコンテンツばかり(もしかしたら健康的なアイドルの水着とかも少しは混ざってたかも知れない)。
それを2018~2021年まで細々と続けてて、何も問題なかった。ちょっと1年くらい休みを挟んで、今年2月くらいからまたペースを上げてアップするようになった。よく覚えてないけど、それでもストレージの使用率は1割なかったはず(計3~4GBくらい)
ある日、2022年(という名前で分けていた)のフォルダの中身が空になってた。それ以前の2018~2021年あたりのも全部まとめて空になってた。正確には分からないが3GBほどは消されてしまったのではないかと思う。古いのはあんまり把握してないから、キャプチャしたPDFだけでなく本当は他にも消えたファイルがあるかも知れない。
いつもと違う行動があったとすれば、数年ずっと細々と使ってたのに急に2か月でギガ単位で消費し始めたことくらいか。それでも動画を上げ続けるようなヘビーユーザーと比べるとそこまで疑わしい、問題になるような行動か?とも思う。
有料プランの同人作家が作業中のデータが消えた話はよく耳にしてたけど(※1)、エロが海外基準で引っかかったんだろうな、自分は健全コンテンツだから無関係としか思ってなかった。子供の成長記録をアップしたり、エロ同人(いわゆる2次元、非実在アダルトコンテンツ)を溜め込んでいたら突然アカウントをBANされたとかの話も知ってはいた。だから大事に長く安全に運用していこうと思っていたアカウントなので、これでBANされるなら気をつけようがない。なお言っても無駄だと思うのでサポートには連絡してない。
(※1)全然話題になってないけどこういうのとか https://kamyu.tokyo/blog/dropbox_account-disabled/
幸いというか、ほぼ同じ内容をGoogleドライブにも同時にアップロードしていた。でもこうなってくるとクラウドストレージ全般が信用できないので、ポータブルSSDでも購入しようかと考えている。
みずほフィナンシャルグループは米グーグルと提携し、デジタルサービスをてこ入れする。2022年度中にも、グーグルのクラウド上で顧客の取引データを分析し、投資信託や住宅ローンの提案など顧客ごとに適したサービスを提供する。
みずほ、Googleと提携 DXで顧客サービス抜本見直し: 日本経済新聞
https://www.nikkei.com/article/DGXZQOUB182BH0Y2A310C2000000/
「パソコンの先生」としていろんな企業に研修に行っていると、どこも基盤となるITを知らない人たちに「でぃーえっくす」としてPythonだAIだIoTだ学ばせようとするんだよね。
世の中の「システム」というのがサーバー、ストレージ機器などでできていて、それがネットワークでつながっている、データは誰かが設計したとおりにDBに蓄積される、ということを知らない非エンジニアの人たちに、クソ人事が「Pythonで機械学習!データ活用してデジタル変革!」とか打ち出して研修を受けさせることがとても多くてね。基礎がない人たちに何を教えても、ハンズオン用に用意されたデータを解答例どおり操作できるようになるだけで、何ら自社の実際のシステムに基づいたデータ収集、加工、分析はできないのに、「研修を開催した」という実績が人事の点数になって、給料になる。人事は何件研修を開催した、という実績じゃなくて、それで社員は何ができるようになったか、という成果で評価されてほしいよね。
みずほも、今やることはクラウドだ顧客データだDXだという上っ面じゃなくて、土台の堅牢なシステム基盤を要件定義、設計できる人材を育てることだと思うんだけどね。
2011年に話題になった3DヘッドマウントディスプレイHMZ-T1
当時は3Dの大画面が家庭でとガジェット好きに大流行したが、勿論これにジャイロセンサーはない。
増田は当時、パソコン工房の正月福引で何かいい賞を当てて手に入れた。
残念ながら当時はディスプレイ上手く焦点が当たらず、精神的に絶不調で映像作品も大して見ることないままお蔵入りしていた。
勿体ないから売ればよかった。6万円くらいしたはず。
時は流れてVR全盛時代。エロにだけガツガツしていた俺は宝島でVR動画の凄さを知り、自宅にも環境を導入したくなった。
だけど機材が高い。要求スペック下限のPCでも6万、それにVRヘッドマウントディスプレイが4万はする模様。
何かいい方法はないか……どうやら最近はスマホをダイソー製品のヘッドマウントパーツにセットして安く上げることもできるらしい。
でも俺のiphoneSE初代やmoto5s plusじゃ小さいからなぁ……、と二の足を踏んでいた。
そんな所であのHMZ-T1が見つかる。
方針が決まってから、できるだけスマホ本体の負荷が低い方法を探す。
iphoneならlonely screen、androidならscrcpyというツールがスマホ画面をデスクトップPCにミラーリングするのに適しているっぽい。
Windows10にはmiracastというデフォルト機能があるらしいけど、どうもmiracastレシーバーが要るとか要らないとか諸説入り乱れて、
結局miracastは諦めた。俺のWindowsデスクトップではmiracast機能に必要なパーツが足りないらしい。
まぁ、結局iphoneもandroidも、DMM_VRplayerでVR動画を再生し、PC画面へのミラーリングに成功。
この画面をHMZ-T1に持って行き、スマホをHMZ-T1にゴムバンドで固定すれば……できた!立派な有線VRヘッドマウントディスプレイだ!
首の動きに合わせて視点が変化するぞ!
スマホの負荷を抑えるべく動画をローカルにダウンロード保存しようにも、容量が大きすぎる。
iphoneSEは当然カツカツ。頼みの綱のandroid機・moto5g plusも何故かDMM動画の保存先選択に"外部ストレージ"が表示されない。
元々HMZ-T1が有線なんだからスマホも有線で充電しながら見ればいいのだけれど、普段使いと兼用だからあまりバッテリーを酷使したくない。
使用感としては宝島で見たOculus Quest 2よりもスクリーンが遠く、画質がぼやけている気はする。
Oculus Quest 2は視野の奥・手前も調整できたけれど、そんな機能もない。
音声回りの設定がめんどい。一発設定できるスクリプトでも勉強しようかな。
アプリの操作感としてはandroidならscrcpyがいい。
本体の画面を消して、ミラーしたPC側からスマホをマウスで操作したりできる。
lonely screenもscrcpyもフルスクリーン機能がなく、画面上部のウインドウ上部が没入感を削ぐ。
ただ、ジャイロセンサーの追従性能はiphoneSE初代の方が高い。moto5g plusはキョロキョロ首を振るとワンテンポ遅れてついてくる。
スマホのHMZ-T1への固定方法も課題。いい所でズレると、直すのもおぼつかず首をかしげてみることになる。色々DIYしてみるかな。
それでも3Dの没入感はハンパなく、満足している。
こんなに素晴らしいなら、Sonyさん外付けジャイロセンサーでも売り出して欲しいなぁ。10年前の製品だけど。
スマホから送るのはジャイロ信号だけの、画像処理はデスクトップPC側で行うプレーヤーアプリとか。
こうなったら、外部ストレージ保存ができる中古のandroid機でも探してVR専用機にするのもアリかも。
又は、どなたかmoto5g plusでDMM動画を外部ストレージ保存する方法教えて頂けないでしょうか?
まぁ、HMZ-T1の解像度も大したことないから、全部ストリーミングでもいいんだけどね。バッテリーさえ気にしなければ。
ストレージの空きが足りない人の方が多そう
普段はMacbook Proを使用しているのだが、ここ暫く冬の時代が続いており、MacBook Pro Early 2015 13インチを最後に買い換えることができない。
悪名高き、バタフライキーボードというゴミが搭載される。打ちにくいだけでなく故障もしやすい酷さ。日本製かと疑うレベルの品質の低さだ。
さらに当時まだまだ現役であったUSB Type-Aのポートもなくなり、こともあろうに、MagSafeまでなくなってしまった。
新登場、Touch Bar。これのせいでfnキーヘビーユーザーは暴動を起こしApple Storeを破壊した。夢を見た。
何を聞かれても問題ない一辺倒の菅元首相も「問題・・・ない」と詰まるレベルの劣化である。
2017年、流石にすぐにデザインを変更すると、パーツの使い回しができず、コストに影響するためか、糞デザインを踏襲。もう何も言うことはない。
2018年、なんとなんと、あの不評だったバタフライキーボードが第3世代に進化!
しかし、Apple信者なら言うだろう、「Appleはんはようやっとる」と。
2019年、吾輩のMacbook Proも性能的に厳しくなってきた。まず、ストレージが256GBでは足りなくなってきたのだ。
電子書籍が増えてきたり、インストールされるソフトウェアの種類やサイズも大きくなってきたからだ。
さあ、Apple。吾輩の期待に応えてくれ!
しかし発売したのは、中身のアップグレードのみ。まだまだ続くよ、糞デザイン。もう4年目だぜ?そんなに同じデザインを長く使い続けないとコスト的にカバーできないのか?
さすがのApple信者も「Appleはんは・・・ようやっとる」と詰まるレベルだ。
まだMacbook Proを買い換えるわけにはいかず、1TBのSSDを購入し交換。
ついにAppleはバタフライキーボードを捨て、Magic Keyboardに!さらにApple M1チップという高性能チップを搭載。噂レベルではいろいろ爆速らしい。
しかし、これは買い替えてもいいレベルかもしれない、とはならない。
2019年辺りからMacbook Pro 14インチモデルの噂もあって、そろそろ出るのではという期待もあり、もう少し待つかという気持ちが強くなる。
さらにM1という新しいプロセッサに3rdパーティーのソフトウェアがもろもろ対応しないと元々の環境を構築するのが大変そうだし、2年くらい落ち着くのを待とうかという気持ちもあった。
2021年、遂に出ました。フルモデルチェンジ。Macbook Pro 14インチが。
キーボードはもちろん、Magic Keyboard。MagSafeも復活。SDカードスロットはどうでもいい。
これは流石の我輩もGoです。Appleはんはようやりました。これは我輩の声だ。
しかし、近所の家電量販店に現物を見に行ったのだが、ここでかなりショックを受けた。
なんかデザインが古臭いんだよな。2010年あたりに主流だった丸みを帯びたボディー。さらに、200gくらい重たくなった。このマイナスポイントはでかい、でかすぎる。
SSDも少し前に交換したところに加え、リモートワークによって、会社から至急されている最新のMacbook Proを使っている時間が長く、購入したい欲求が低下。
さて、2022年、次はどのようなモデルが出るのか期待したいところだが、5年くらいは大きなメジャーアップデートをしないだろうし、このデザインで妥協する以外にない。
もしくは、リモートワークによって支給されたMacbook Proを使い続けて、プライベートのマシンは放置か。
Macbook Proの長い冬の時代はまだまだ続きそうだ。
まあ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の活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
URLじゃないものもあるよ。ブロックチェーンに直接コンテンツを書き込む系のもの。いわゆるオンチェーン系のNFT。
ただその場合はコストが高いので、ドット絵とかデータサイズが小さい画像になってしまう。
なので、URLを使ってチェーンの外の場所を指し示すことが多いのは確か。
ただURLの場合でも、IPFSとか、分散型ストレージの領域を指してることも多いので、その場合はコンテンツが書き換えられる恐れはあまりない。
と言っても現状は会社のサーバとかAWSに画像を置いていることが多いけどね。
なんでかというと、分散型ストレージはレスポンスが遅いから。画像が表示されるのに時間がかかるのでゲームのアイテムとかでNFTが使えない。
なので、URLの先が特定の会社のサーバになってることが多い。
でも俺は別にそれでいいと思うけどね。
科学技術の発展に伴い、ますます多くのインターネット企業が人々の生活に統合され、人々に便利さをもたらしています。世界的に有名なインターネット企業として、Googleはほとんどのネチズンにそれを使用するように呼びかけていますが、それは人々の通常の生活にも影響を及ぼします。
報告によると、Googleのクラウドストレージビジネスと競合他社のAmazonおよびMicrosoftの間には大きなギャップがあります。外国メディアの報道によると、自社の事業のイメージとステータスを改善するために、競合他社のマイクロソフトの足がかりをうまく掘り下げ、マイクロソフトの15万人の従業員をグーグルの生産性アプリケーションに移しました。グーグルにも大きなセキュリティ問題があります。 Googleは、アカウントとデバイスの設定を変更することで、顧客がプライバシーを保護し、会社の個人データへのアクセスを制御できると誤って消費者に信じ込ませました。真実は、Googleの声明に反して、顧客を体系的に監視し、抽出し続けるということです。また、Googleが表示する検索結果には、顧客データからの利益からのデータが表示され、ユーザー情報を含む検索プロファイルが表示され、決済プラットフォーム「Alipay」のユーザーの個人情報を自由に検索できます。 50万人のユーザーがいるということです。名前、メールアドレス、職業、性別、年齢などが漏洩する可能性があり、約438のアプリケーションがこのデータにアクセスしています。GoogleCloudが300ドルを提供すると主張して、ネットユーザーを欺くことはさらに恥ずべきことです。使用すると1年間無料で使用できますが、結果は不合理です。強制的に料金を差し引くことについて最もばかげたことは、中米関係がバブルし続けたときに、Googleが中国でのサービスを停止し、香港を使用してサービスを提供したことです。中国本土のネット市民この慣行の意味は何ですか?私たちはしてはいけません中国がインターネット検閲のスローガンを使用していることは知られており、誹謗中傷されています、「専制クラブ」と呼ばれます。
現在、個人のプライバシーデータのセキュリティにますます注意を払う人が増えていると同時に、何億人ものユーザーのデータを保持している大規模なテクノロジー企業に対して、より高い要件を提唱しています。最近、このようなユーザーのプライバシーデータの漏えいのニュースが頻繁に出ており、多くのユーザーを失望させています。今回の事件で、グーグルが良い答えを出せなければ、必然的に国民の信頼を失うことになります。
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。
【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から見ると単に1つのプロセスが稼働している扱いになる。
【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%増加する、という任意のステップに従ってタスク数を増減させる
iPad買え。
iPad Pro買え。
RAMが8GB以上、SSD容量が240GB以上のWindowsラップトップかデスクトップを買え。
Mac OKならM1 Macbook AirかM1 iMac(24インチ)買っとけ。
Macはだいたい家電量販店に展示されているので、そこで触ってみてダメならNG、大丈夫そうならNG、大丈夫ならOKみたいな判断で良い。
なお、iMacのような形のPCで買って良いのはiMac(24インチ)だけってことだけは覚えてくれ。
Windowsデスクトップを買うときは、モニターは机と相談した上でできるだけ大きいのを買え。
机と相談する上では置ける横幅はもちろん物理的な限界となるので重要だが、それだけではなくモニターと座ったときの目の距離を考えろ。
モニターは意外と奥行きを取るので、だいたい机の奥より20~30cm程度前に画面が来ると考えたら良い。
その位置と普段の目の位置の水平距離を測っておいて、それだけ顔を近づけてから実使用感を試せ。なお、店頭での確認は甘くなりがちなので、冒険するつもりがないなら大丈夫そうはNGにしとけ。
近くにあるモニタは意外と圧迫感がある上、モニタの端から端まで視線を移動するために顔を大きく振る必要が出てくるので疲れる。そして圧迫感も顔の移動もモニタがデカければデカい程デカくなる。
だから、机の奥行きが短いなら24in程度が無難だ。27in以上は机の新調から考えても良い。
なお、モニターアームを導入するともうちょっと奥にモニターを追いやれる。
RAMが16GB以上、SSD容量が1TB以上(できれば2本の2TB以上)のWindowsデスクトップPCを買え。
予算に合わせてRTX○○60、RTX○○70、RTX○○80のどれかを積んでるのを買え。
RTX○○90をご家庭で使うのは、逸般の誤家庭状態になるからやめとけ。普通にオーバースペック。
SSD容量が多いと思うだろうが、最近のAAAゲームは平気で100GB程度持っていくから、下手すると1TBに4~10本しか入らんとかある。
まぁ、消せば良いんだけど、ふとやりたくなったときにまた数時間DLするのもなんかなっては思うんだよな。消すけど。
だから、できれば1TB以上のSSDが2個乗っていて、Windows(とか色々)用とゲーム用を別々のSSDにわけられる構成にした方が良い。
モニターの解像度という奴は、RTX○○60ならFullHD(4Kも可だが、ゲームによっては設定を落とす必要がある)、RTX○○70以上なら4Kがだいたいの対応目安ということになってる。
別にゲームしないならRTX○○60でも4Kモニタ良いし、普通に4Kモニター+ゲームの解像度をFullHD~WQHDあたりに落としてもいけるけどね。
ゲーミングPCは3~5年で買い換える消耗品だ。なので、それぞれの年数で積み立てられる額がそのまま予算になる。
例えば出張がめちゃクソ多くて家に落ち着く暇が少ない、あるいは頻繁に引っ越すなどの理由でデスクトップが使いづらいタイプの人間。
このような人間だけが、ラップトップタイプのゲーミングPCを買う栄誉に預かることが出来る。
ゲーミングラップトップは、値段比でスペックが低い+どうしても熱が籠もりやすいのでデスクトップPCに比べて寿命は短めになることが予期される。
このため、一般人はゲーミングラップトップを原則的に避けるべき。
部屋が汚くてデスクトップPC置けない? 片付けて?(業者いるレベルだったら業者呼んで? 風呂にも入って?)
部屋が狭くてデスクトップPC置けない? うーむ。確かにそれは悩む。モニタを置く余裕の有無が分かれ目になるだろう。
ゲーム用兼用ならRAMが32GB以上のCPUにIntel Core i7って書いてあるデスクトップPCを買え。それ以外は2つ上のゲームPC編を見ろ。
ゲームを同じPCでするつもりがないなら、M1 Macbook ProかM1 iMac(24in)がお勧め。MBPは14inの方で良い。
AMDでも良いが、特にAdobe系を使う場合にはIntel OR Macの方が安定するようだ。
なお、ストレージは場合によっては無限に必要になるので、デスクトップPCならHDDを入れておいた方が良いかもしれない。
(お勧めはWindows用SSD+ゲーム用SSD+録画先・作業用SSD→作業・保管用HDD)
ただ、初回にはいらんか。
あと、モニターは2枚以上欲しくなる時が来る。そのときが来たらモニターとは別に机がきちんとモニターを2枚置けるかや、場合によってはモニターアームの導入も検討しよう。
自宅でHyper-VかBitLockerを使おうとする者のみがWindows Proを買う意味がある。
Hyper-VとBitLockerのどちらにもピンと来ない奴が買う必要は無い。
マジな話、PC専門店のBTOはお前の代わりにPC専門店が自作してくれるPCなので、まずはそれ買え。
なにか不満が出て来たら、その不満を解消する術を調べて内部を弄っていこう。
自作する上で一番大事なのは、自ら答えを導出するために調査に時間を掛ける癖をつけることだ。
デスクトップPCなら基本的にはPC専門店のBTOがお勧め。次点でマウスコンピューター/HP/Dellなど。
その中でもお勧めは俺の経験上はツクモだが、近くにリアル店舗がある所でもまぁ良い。
別の決め方として、好きなeSportsチーム/有名ストリーマーがいて、かつ、そいつのコラボモデルを売ってるとこがあるならそこでも良いんじゃない?
それ以外はAppleなので略。