「仮想化」を含む日記 RSS

はてなキーワード: 仮想化とは

2022-08-21

anond:20220821221912

今はパブリッククラウド利用と社内のサーバーコンテナ化する流れ

ちなみにコンテナ仮想化技術ひとつとかならわかるけど

そこでOSとか言い出しちゃうのです?なんで?

2022-07-05

技術的に信頼性が低いということがわかってしまったのは打撃ではないだろうか?

KDDIau「(このままじゃ補償金額がヤバそうだ)直ったことにしとこ!昨日で復旧作業終わったで!」

https://hamusoku.com/archives/10536552.html

賠償金 + 名声(信頼)の低下ということで、何か一国の終焉を見ているようだ・・・

賠償金はなんとかなるにしても、技術的に信頼性が低いということがわかってしまったのは打撃ではないだろうか?

特に法人ユーザーシェア低下は避けられないと思う

切り替え時の原因不明エラーって、たいてい技術マニュアルが古いか運用ルールが古いかとかなんだよね

古いというより長年そのままで硬直化していて、「理論上できるはず」で、えいやでやって謎のエラーとかがある

レガシーデバイスレガシー運用はそういう怖さがある

ドコモも同様の問題だったけど12時間で治ったってことは、プチ移行とかプチメンテを定期的にやってたんだろうね

AUがそれをやってなかったとは言えないけど、ドコモほど頻繁じゃなく、柔軟じゃなかったってことかな

やはり電線時代からインフラを保ってたNTTの企業体質に分があったってことだろうね

ソフバンエリクソンルータ証明書更新切れというプチ障害くらいしか起こしてないから、やはりすぐれた運用してるんだと思う

あと今回の事件通話用のIMSモジュールが複雑ってことがわかったけど、楽天新規勢ってこともあって、仮想化してる意味がわかった

仮想化してたらこういう問題は起きてもすぐ復旧できるから当然の設計だと思う

auにとっては不運だったが、やはりコアの部分の体質・運用力という点で2社に劣っていたことを証明してしまったと思う

ソフバンドコモ中の人はほくそ笑んでそう

寡占三強企業による戦国時代三国志とはそういうものであろう

2022-06-18

プログラミング初心者に開発環境について教えて

AnacondaとかDockerとかコンテナとか仮想化とか

そこら辺の知識を体系的に知りたいんだけど、何を読めばいいのかわからない

そりゃ、「Anacondaのマニュアル見ながらインストール、実行」みたいなのはできるよ。

でも、「それをなぜ使うか」とか「他のものではダメなのか」「なにががいいのか」みたいなことを知ろうとしても難しいんだよね

このままあちこちハウツーの言われるがままに入れていったらPC混沌としそうで怖い。

2022-04-30

anond:20220430171536

Officeしか使わない一般企業を想定してもらえるとありがたい

IT企業の開発端末は仮想化してAdmin権限与えたほうが生産性落とさないで済むね

2022-03-21

anond:20220321214147

どうもです!まさか即答頂けるとはありがたい。

アセンブル時間計算した仕事スケジュールになってそれはそれで効率よさそう。

コーヒーブレイクできるし。

今のクラウド仮想化リモートワーク時代はダウンタイムがほぼないからなあ・・・

2022-03-12

anond:20220312080926

次回予告  お前たちの撃ったのはクローンだ。さあオリジナルはどれかな?

次々回予告 我々は国家仮想化暗号化して制約から解放されるッ!

2022-03-03

アンリミテッド夢精

自分でも信じられないような経験をしたので記録に残す。


まず自分スペックだが、30代後半既婚エンジニア

愛する妻に不倫され心がズタボロに壊れて鬱病になり、精神科のお世話になっている。

処方されてる薬はレクサプロ


薬を処方され始めて1年くらいになるが、症状は驚くほど安定し、無事に社会復帰果たしている。


薬の効果は絶大だ。まず怒りや悲しみという感情俯瞰して見れるようになる。

そして、そんな事に心を奪われる事が馬鹿らしく思えてくる。

そもそも元来はエンジニアという職業から極めて単位時間あたりの生産性には気が向く方だったし、不倫された悲しみから思うようにコントロール出来なくなった感情や体調、それによって地に落ちる生産性に悩む日々から解放された事は本当に嬉しかった。

曲がりなりにも、また自分人生を歩めるのだと少し嬉しかった。


一年も経つと薬と過ごす日常も当たり前になる。

自分日常も戻ってきた物だと錯覚していた。

そう、錯覚していたのだ。


薬の副作用なのか、不倫された事による心の傷なのか、気づけば一切の性的興奮への興味を失っていた。

眠くて勃起することはあれど、シコっても射精しないし、射精しようとも思わない。

裸の男女に何も感じないし何も期待しない。むしろ人々の営みを猿か?と引いて感じるほどに、虚無感と賢者感に常に満たされる日々だった。

自慰に使われていた時間コーディングという極めて生産的な時間に生まれ変わった。

人類、いや、精神としての新境地の達した気持ちだった。


ところが、だ。


先日、炎上プロジェクトの火消し対応出張滞在が長期化し、ついには持ってきた薬が底を尽きてしまった。

とはいえ、もう一年も安定した日々を過ごしている。

断薬症状は怖いといえば怖いが、そこまで恐怖は無かった。

俺はもう立ち直ったと、心から信じていた。

から特にアクションを起こす事もせず、そのまま仕事に打ち込んだ。


事件断薬3日目に起きた。


それまでも、頭痛などの断薬症状は現れたいが、現地で購入した頭痛薬などを服用する事でさほど大きな問題にはならなかった。

そもそもレクサプロは効きもマイルド断薬症状もマイルドと呼ばれている薬だ。

日々の生活への大きな悪影響はなかった。


それがだ。

その日見た夢は、それまでの人生で見た夢とは何もかも違っていた。


夢の中の自分は、それまで失ってたいた感情、つまり性欲の洪水の渦の中にいた。

とにかく湧き上がる性欲を抑え切れないのだ。

エッチな事がしたくてしたくてたまらない。

これまでの人生で、こんなに性欲に頭を奪われた経験があるだろうかというくらい、とにかくムラムラしてたまらないのだ。


そして何より、そのとき自分はいま、夢の中にいる事を完全に理解していた。

まり明晰夢だ。


その世界では全てが自分の思うがままだった。

不倫した妻が、過去叶わなかった恋焦がれた人が、仲のいい友人や知人から有名人、大好きなゲームアニメヒロインモブキャラまで、どんな異性もコツを掴めば無尽蔵に召喚できた。


召喚して何をするかって?やる事はひとつだ。


満たされなかった思いを、とにかくぶつけた。

セックスがしたいのではない、俺は、愛し、愛されたかったのだ。


その夢で、俺は何度も射精した。

とにかく射精した。

自分でも驚くが、とにかく何度でも射精できるのだ。

決して鬼頭は摩擦によって痛くならないし、精巣は無限生産力で精子提供す続ける。

とにかく、何度でも何度でも射精でき、その快感無限に味わう事ができるのだ。


頭がおかしくなりそうだった。

本当に、本当に、気持ちいいのだ。


そんな無双な俺にもわかる。

世界では今まさに世が開けようとしている。

後少しだけ、後少しだけ、

どうか神さま、この時間を1msでも私に。

とにかく俺は射精を繰り返した。


その朝はとても気持ちの良い目覚めだった。

こんなにスッキリした頭で目覚めた朝が、過去にあっただろうか。

新しい朝に、新しい世界を迎えれた事にとにかく感謝を捧げた。


案の定、寝起きのパンツの内部は大変な事になっていた。

でもその事後処理は、それによって得られた体験の偉大さの前には、もはや何も無いにも等しい物だった。

自分は人を超越したのだ。

刹那な性欲に負けて愛する妻を寝取った間男を、不倫浮気に悩み悩まされる人類を、俺は仮想化によって超越したのだ。

ついに性欲は、人の営みは、誰も傷つける事のない持続可能(SDGs)なエクスペンスへと昇華されたのだ。

その達成感と幸福感は、なにものにも変え難い物だった。


その体験は三日三晩続いた。

無事に出張を終え帰宅し、投薬を再開した自分は、良くも悪くも日常へと戻ってきた。


あれは夢のような出来事だったのかもしれないし、実際のところ夢だったわけなので、まぁ夢見たいなというか夢なわけだけど、今も自分世界や人を捉える価値観を持つ上で、とても大切な思い出になった。


自分幸せにするのは自分自身だ。

2022-02-18

VMWare苦しい戦いしてるなー

まあVMWorldとかで10年以上人生の春を謳歌してきたからもう十分やろ

お疲れさん

マルチクラウド環境における5つの課題とは

VMware提案する、DRにも対応するマルチクラウドソリューション

昨今のCOVID-19流行への対応やDXを推進する中で、クラウドサービスの利用はビジネススピードの加速や柔軟なシステム運用効果的であり、従来のオンプレミス環境と併用するハイブリッド環境や、複数クラウドを利用するマルチクラウド環境が増えている。一方で、これらの環境を維持していくには課題も多く、セキュリティリスクも増大してしまう。ここでは、こうした課題解決するVMwareソリューションを紹介する。

マルチクラウド環境における5つの課題

COVID-19流行への対応やDX(デジタルトランスフォーメーション)のためのビジネス変革が進む中で、ビジネススピードの向上やニーズに対する迅速で柔軟な対応がこれまでになく求められている。これらを実現するために、アプリケーションの変革やクラウドへの移行が加速している。

多くの企業が、「ビジネススピード対応できるモダンアプリケーション」や、「あらゆるクラウドデータセンター、エッジでビルドおよび実行が可能であること」、「エンタープライズクラスレジリエンスセキュリティ運用の実現とビジネス変革」がDXを実現するために必要であると考え、これらを実現するためにマルチクラウド環境活用が前提になってきている。

具体的には、Amazon Web Services(AWS)、Microsoft Azure(Azure)、Google Cloud Platform(GCP)といった複数パブリッククラウドサービスを併用し、適材適所で使い分けているのが現状であろう。しかし、マルチクラウド環境では解決必要課題存在する。その課題とは、「ワークロードのシームレスな移行・連携」、「クラウドごとのスキル習得」、「運用管理簡素化」、「セキュリティリスクの低減」、「最適なコスト管理」の5つである。この5つがクラウド利用の理想現実ギャップとなっており、これらを意識して進めていく必要がある。

マルチクラウド環境における5つの課題

特にマルチクラウド環境適材適所で使う場合クラウドごとに利用する技術が異なるため、設定項目や内容に違いがあり、その設定ミスによるインシデントも発生している。重大な影響を及ぼす場合もあるため、それぞれのクラウドを扱う際のスキル重要になる。

VMware Cloud on AWSの特長とメリット

こうしたマルチクラウド環境における課題解決するには、一貫性のあるクラウドインフラストラクチャ、および運用管理サービス重要ポイントとなる。例えばVMwareは、複数パブリッククラウドだけでなくオンプレミスを含むハイブリッドクラウド環境においても、仮想的なレイヤーを構築することで管理運用を一元化している。

VMware Cloud on AWSは、VMwareAWSが共同で開発したもので、AWSベアメタルサーバー上にvSphere、NSX、vSAN、vCenterを導入し、ホスト専有型のクラウドサービスとして提供するものだ。

VMware Cloud on AWSの特長

その特長は3つある。1点目は「VMware製品ベースとしたクラウドであること。VMware製品仮想化されているため、AWS世界にいながらオンプレミス環境で利用していたスキルセットや運用管理ツールを利用でき、新たなスキル習得する必要がない。

2点目は「シームレスクラウドに移行できる」こと。ワークロードをオンプレミス環境から無停止で移行することができる。アプリケーションを更改する必要もないため、クラウドに移行する時間コストリスクを大幅に削減することが可能だ。

3点目は「VMware管理を行う」こと。ハードウェアソフトウェアトラブル対応運用管理メンテナンス対応など、すべてサービスの中でVMware実施する。3カ月に一回の頻度で新しいリリース提供しており、ユーザー要件を反映しながら新たな機能を追加している。

最近アップデートの大きなものとして、日本で第2のリージョンとなる大阪リージョンを設置し、サービス提供を開始したことが挙げられる。例えば西日本地区データセンターを持つユーザーは、より低遅延でサービスを利用できるようになった。昨今は感染症流行地震の発生などによってBCPを見直すユーザーが増え、VMware Cloud on AWSリカバリサイトとして利用するケースも増えている。その意味でも、大阪リージョン活用度が高いといえる。

大阪リージョンサービス提供開始

VMware Cloud on AWSが選ばれる理由は、大きく3つ挙げられる。1点目が既存ノウハウ運用管理手法をそのまま踏襲できるという点。VMware製品ベースとしたクラウドサービスであるため、オンプレミス環境における管理者のスキル運用ノウハウなど、既存資産をそのままクラウド上でも活用でき、新たなスキル習得や、運用管理手法の大きな変更の必要もない。クラウドオンプレミス環境をvCenterから一元管理できる。

VMware Cloud on AWSが選ばれる理由

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 Tanzuの概要

高まるDR環境へのニーズ安価に実現

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の活用課題解決するだけでなく将来への有効投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。

2022-01-31

anond:20220131110146

勘違いというより、失敗の歴史を述べたまで。

仮想化身体からの分離→民主化、非中央集権からよい、同好の士の集いだからよい、といったタイプ理想主義はことごとく失敗してきたという話を列挙したまでで、毎回「ぼくがかんがえたさいきょうの」を繰り返してきたということじゃないかと。個人的にはメタバースもいまさかんに言っている理想とは遠く離れたものになると思っている。

オリジナル増田が備忘的に残したらしいメモにに理想主義風の要素を読み取ったので付き合っただけで、それ自体勘違いといわれるならばその通りでしょう。

anond:20220131105904

仮想空間っていうのは、現実世界再現するものなんだから現実世界で起きることはたいてい起きる。

 

起きなかったらそれは仮想化に失敗している。

 

なんか勘違いしているよね。

現実から遊離したユートピアが作りたいなら、現実だって作れるんだそれは。

皆そうしている。毎週末に友達だけで集まったりして。

2022-01-29

anond:20220128174902

おまえアタマ大丈夫か?

サーバレスって本当にサーバ存在しないわけじゃないからw

ただのクラウド上のSaaSの延長でサーバ仮想化してるだけで、実質サーバ知識ないとアカンし。

おまえは物理ハードウェアとしてのサーバが全てだと思ってんのか?

早く大きめの病院行ってこい。

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

2022-01-07

経験から1ヶ月!Pythonで観る将ライフを向上させた話(プログラム編)

まとめ

プログラミング経験から1ヶ月ほどで、将棋評価値の新たな方法でのグラフ化を行うPythonツールを作った。

https://github.com/k-the-p/notherscore

この記事は2本立てです。プログラミングより結果のグラフ将棋に興味がある方はもう一方の将棋から読むことをおすすめします。

未経験から1ヶ月!Pythonで観る将ライフを向上させた話(将棋編)

目標

評価値以外の観る将の楽しみとして、手の広さの可視化提案する

AIはわれわれアマチュア将棋への親しみを大幅に向上させてくれた一方で、棋士が悩みに悩んだ結果として評価値が下がる手を指してしまったときに、「悪手きたwwww」と騒ぐ主にABEMAのコメント欄には忸怩たる思いがあった。

とはいえ、もう評価値を知らなかった時代に後戻りするなんてことは誰にもできないだろう。そして、電王戦から将棋にハマった自分自身としても、AI否定はしたくない。

であるなら、AIを用いた新しくよりよい将棋の楽しみ方を探っていくしかないのではないか

以前から私は、「AIの手を指せるなら人間も苦労しないんだよなあ」と思っていた。あるとき藤森哲也先生Youtubeチャンネルで言っていたことを聞いて得心がいった。「AIの一手は最強の一手なんです。確かにプラス1000点になるけど一手間違えた瞬間にマイナス何百点になるような綱渡りの手。それよりもアマチュアの皆さんにはプラス数百点で得は少ないけど安全な道、最善の一手を学んで欲しい」(大意)と。

ここで言う「最強の一手」に人間にして最も近いのは紛れもなく藤井聡太四冠であろう。藤森先生アマチュアに向けて喋っていたが、その葛藤は間違いなくプロの中でもあるはずである渡辺明三冠が言うように「藤井くんと全く同じスタイルを今から目指しても絶対藤井くんより強くなれない」のは自明であるからして。

私はここにドラマがあると思う。また、最強の一手と最善の一手が等しく「いい手」に見えてしまうわれわれアマチュアとしては、そこを機械に教えてもらえるのであれば、棋力向上にも繋がりそうである

具体的目標

第1候補手と第2候補手の評価値の差を取ってグラフ化すればよさそう?

(差が小さければ手が広い、差が大きければ絶対手に近い、綱渡り

目指すのはあくまで便利な将棋ツール将棋AIを作りたいわけではないので、将棋AI自体局面を入れたら評価値を吐く謎の箱という扱いでよい。

手法

Python一択

グラフ化や数値の扱いだけでなく、将棋AIとのやりとりをやってくれるあれこれもあるようなので。

あと習得が楽だと聞いた。その話を教えてくれた人はもう10年間英語学習法をブクマし続けてるけど。

あと「読みやすコードじゃないと動かない」って設計思想がかっこいい。ついでに言うといわゆる「おまじない」が少なそうなのも魅力。(CのHello world挫折した経験あり。studio.hって何……)

何をしたか

詳しい人に聞く

プログラム講師をやっている?方が音楽制作を初歩からやってみる、という(残念ながら)リアルタイム視聴者が俺だけしかいないような配信があったので、音楽の基礎(についての知識は持っていた)を教えてあげたお返しのような形で、「pythonでこういうことがしたくてこういうライブラリがあるのはわかった。経験HTML+CSS変数導入前、Bootstrapなんてなかった)のみ。どうしたらよいか」という質問をしたら、「progateは簡単すぎると思うのでPaizaが丁度いいのではないか」というアドバイスを頂き、比較もせずに即登録したのだが結果的にはこれがドンピシャだった。

Paizaラーニング

最近流行りの、環境構築不要で講座の内容を書いて覚えるタイプサイト

無料で入門講座の序盤を受けていたらふと目に入ったのが、「対象者:これからプログラミングを学びたい方。HTMLがどのようなものかを知っている方。」でYoutuber先生オススメ完璧か?と思った。そして実際に完璧だった。

基本的に1講座3分+演習1~2問+やりたければ問題集たくさんという形式なのだが、これが簡単すぎることなく難しすぎることもなく、俺の知識レベルベストマッチだった。基本的に毎回何か書くことになるので、変数とは~みたいな解説だけで終わる回がほぼ無いのも飽きなくてよい。

Python入門(と言ってはいるがまだこれだけで発展編はない)の見出しは「プログラミングとは」「条件分岐比較演算子」「ループ処理」「リスト」「辞書」「多次元リスト」「関数」「クラス」「クラス発展」「例外処理」に各5~8講座*3分+演習、という感じ。クラス発展の途中で行けそうだと思ったのでドロップアウトして実製作に移った。実際関数まで理解していれば、この程度の小さなツールには十分だった(もしかしたらクラスを使えば多少楽になった場面はあったかもしれないけど)。

また、これは書いてる今気づいたことだが、上のコースで学んだことで、実際に役立たなかったものほとんどなかった(強いて挙げれば辞書くらい?使えてないだけかも)。このこともコース構成の優秀さを示している。

ここまででだいたい2週間くらい。

Google colab

もともとこのサービスは知っていたのと、谷合先生が実際に使っていたように、便利そうなライブラリのcshogiが主にcolab(jupyter)上で動かすことを意図しているようだったので、まずここから入った。最初はcshogiが列挙してくれる特定局面での合法手をリストに入れて、そのリストの項目数=その局面での合法手の数を出力することから始めた。これは本当に簡単にできて興奮した。

学習と好きなことが直結してると、こんなサンプルコードみたいな簡単なことで喜べるのでコストパフォーマンスがよい。

cshogiとやねうら王をusi連携する

cshogiのチュートリアルで紹介されているレサ改というAIがどうもmultipv(有望な候補手を2手以上挙げる)に対応してないらしく、強さ的な問題でいずれ手を出すつもりだった予定を繰り上げてやねうら王との連携を試みる。

makeって何?あー、もりかしてMakefileが無いと動かない?(これを書いている今もこんな理解である)みたいな人間でもなんとかやねうら王をビルド?することはできた。レサ改をcshogiに読ませる数行のサンプルコードがとても役に立った。今でもあの完成品らしき拡張子が無いファイルがなんなのか分かってない。(なお、評価関数nn.binが無いと怒られたのでどこのご家庭にもある水匠4のそれをぶち込んだら動いた。評価関数とやねうら王の分担は今もって理解あやふや)(また、途中でAyane[やねうらお謹製ライブラリ]も使おうとしたがcolab上では上手く動かす方法が分からなかった)

一応これでcshogiで局面の最善手と次善手およびそれらの評価値を呼び出せるようになったのだが、単にdebugでずらずらと余計なものまで出力するのではなく、重要な指し手周りのinfoだけ出力するようにしようとしたが、上手いやり方がわからず、結局こうなった。

sys.stdout = open('out.txt', 'a')
engine.go(listener=print)

ここは絶対もっとマシなやり方があるはずなので、識者の教えを請いたい。

ようやくWindowsPythonVSCodeを入れる

Colab上でまあまあ目処がついたので、この辺りでPython環境を作った。ここまでそれをやっていなかった理由は、「おま環」トラブル可能性をなるだけ遠ざけておきたかたかである環境が悪いのか俺が悪いのか分からない、というのは初心者にとって限りなきストレスである。あーネットが繋がらなくてルーターの設定や接続とか支払いとか文字通り部屋をひっくり返しながら調べてたら実はフレッツ自体が落ちてた件を思い出してイライラしてきた。cshogiはJupyter上で動かすことを意図しているようなので、それで動かなければ自分の書き方が間違っているのだとほぼ確実にわかる。

まあこの辺りはいろんなサイト見ながら仮想化などしつつ普通に仮想化が何か分かってないんですけど。

Jupyter notebook

これまでColab上で書いてきたものは多少の書き換えで動いたので、ローカルにJupyter notebookをインストールして、数字計算グラフ化を試みる。

ちなみにこの時点で得られているデータはこんな感じ。

go
info depth 1 seldepth 1 score cp -47 multipv 1 nodes 483 nps 241500 time 2 pv 3c3d
info depth 1 seldepth 1 score cp -86 multipv 2 nodes 483 nps 241500 time 2 pv 4a3b
info depth 2 seldepth 2 score cp -53 multipv 1 nodes 847 nps 423500 time 2 pv 3c3d 9g9f
info depth 2 seldepth 2 score cp -68 multipv 2 nodes 847 nps 423500 time 2 pv 8c8d 7g7f
info depth 10 seldepth 17 score cp -78 multipv 1 nodes 100163 nps 1963980 time 51 pv 8c8d 2f2e 4a3b 7g7f 3c3d 2e2d 2c2d 2h2d 8d8e 6i7h 8e8f 8g8f
info depth 10 seldepth 17 score cp -111 multipv 2 nodes 100163 nps 1963980 time 51 pv 3c3d 7g7f
bestmove 8c8d ponder 2f2e
go
info depth 1 seldepth 1 score cp 117 multipv 1 nodes 206 nps 206000 time 1 pv 2f2e
info depth 1 seldepth 1 score cp 78 multipv 2 nodes 206 nps 206000 time 1 pv 7g7f
...

今回の小目標は、goで区切られた中からから2行目と3行目のcpほにゃららを取得していい感じのリストにする、というものだ。この辺りは正規表現でなんとかなるだろうと見通しを立てたが、実際そうなった。

ただ、後手が見たとき評価値が後手目線なので、それだけにマイナスをかけるのはどうするか(そうしなければ、先手+3000点の次が「後手から見て」-2900点だったりして綺麗にグラフにならないのだ)を調べるのに結構時間が掛かった。

また、詰み周りでまたプラスマイナスカンストの絡む計算をしたくないのもあり、数値にNaNを入れてグラフ表記を省略することにしたのだが、そうするとnumpyの関係整数(とNaN)しか扱わないのに浮動小数点で計算しなければいけなくなって若干気持ち悪かったり。まあ動くのでヨシ!

中間報告

この時点で、ローカルにKIFファイルを保存し、pyファイルでcshogiと水匠を動かし、Jupiter notebookを開き評価グラフと手の広さのグラフを重ねて表示する、というそれなりのものは出来上がった。

簡単に言えばpyファイルで1手10局面(森内チャンネルに出てたHEROZの方が使ってた数字をそのまま使っているので特に意味は無い)探索させ、最善手と次善手についての生の評価データを吐き出させ、ipynbでそれを整形し、グラフ化している。

基本的に全部VSCode上でできるので、慣れれば計算時間も含めて10数秒で結果が出るのだが、このワークフローはいかにも美しくない。

なので、Flaskという簡単らしいフレームワークを使ってローカルWebアプリとして使えるようにしようと思った。inputとoutputをどうにかするだけだから余裕やろ。

Google colabを触り始めてからここまで1日。圧倒的成長!

ローカルWebアプリを作る

Flaskを学ぶ

Paizaラーニング再び。後半ではデータベースとか本格的な話もあるようなのだが、txtに書き込む一行掲示板を作るまでの前半部を高速で履修(演習は全部飛ばした)。なるほどー、こうやってやりとりするのね、と最低限は完全に理解した

モジュール

Jupyter向けのコード普通Pythonに直してあっちで数字を出してこっちでそれを受けて元に戻して……とかやってると循環参照か何かで怒られることに。その対策に細かく部分を分けて関数にしたのだが、その場合ってもしかしてdefの内部しかまれない?(共通部分も読まれると思ってた)(いや、共通部分は読まれるけど他のdef内が見えないのか?何も分からん)なるほど。こうなると関数の内部から上に戻るためにクラスとか欲しくなるのかなーという感想

最終的にWebに公開しようとこの時点では思ってたので、txtに一旦出力するのが安全性的にどうかとか考えてたのだが、テキストの読み取り周りでハマる。結局抜け出せず諦めた。

以降は、HTMLダブルクオートが抜けてるのに一時間気づかないとか、FlaskのXSS対策対策をするとか、ファイル書き込み設定をミスって2万手くらい蓄積されて評価グラフが大変なことになったが、原因に気づかずひたすらグラフ生成部を調べ続けるなど、非本質的問題にかかずらっていたので書くことは特にない。

GithubVSCodeとなら連携がらくらく

なので、最初にgitignoreしてなかったせいで1万ファイルくらい上げそうになったけど、それ以外は特に問題も無く。中間報告からここまで2日ほど。結局1ヶ月かけずにプログラミングをそれなりに身につけることが出来た。「プログラムを覚えたければ作りたいものを見つければいい」というのは本当だな、と改めて思った。

で、どうなったの?

については将棋編の方で詳しく書いています

https://anond.hatelabo.jp/20220107060727

どれくらい書けるようになったのか、を見たい方は主にvalue_output.py(将棋AI思考させてデータを取り出す)とgraph.py(データを整形してグラフを書き出す)を見ていただければいいかと思います

謝辞

最初にPaizaを教えてくださったYoutuberの方、cshogiを初心者でも使いやすいように作って展示してくださったTadaoYamaoka様、水匠開発者のたややん様、水匠含めこんにちの将棋AIの基盤を作ってくださったやねうらお様、cshogiを通して利用したpython-shogiのKIFパーサーを書いてくださったTasuku SUENAGA様に、厚く御礼申し上げます

最後

私は現在仕事Twitterフォロワー募集しています

30歳無職よろしくお願いいたします。

https://twitter.com/k_the_p

2021-12-31

貴社のテレワークに最適なVDI 代替の選定ガイド

VDI(仮想デスクトップ代替ソリューションの分類や、それぞれの仕組み、検討ポイントなどを解説する本連

載「テレワーク時代Web 分離入門」。 第1 回、第2 回でテレワークWeb 分離の方式の特徴を解説しました。

最終回となる今回は、方式レベルでの選定方法を紹介します。

今回のゴール

用途観点で各方式を分類すると下図のようになりますが、どんな組織にも共通する「おススメの方式」はあ

りません。

(出典:ネットワンシステムズ

今回は、読者の皆さんが自組織マッチする方式を選定できる状態をゴールとして、「結局、 どれを選べばいい

のか」という疑問に回答します。

フローチャートで分かる、

貴社のテレワークに最適なVDI 代替の選定ガイド

VDI 代替ソリューションの分類や、それぞれの仕組み、検討ポイントなどを解説する連載。最

終回は、VDI 代替ソリューション方式選定における 4 つのポイント解説して、各方式を比

します。

(2021 年03 月04 日)

26 →目次に戻る

4 つのポイント

これまで多くのユーザーと会話してきた経験から、おおよそのケースで次の4 つのポイント論点が集約されます

1. ブラウザだけで業務が完結するかどうか

2. データを処理するマシンローカルマシン大丈夫かどうか

3. データを処理するマシン物理PC大丈夫かどうか

4. 実行環境が分離されている必要があるかどうか

これらを基に、方式選定に使えるフローチャートを作ってみました。

(出典:ネットワンシステムズ

ポイント 1】ブラウザだけで業務が完結するかどうか

ブラウジングだけを安全に実行できればよいのか、それともブラウザ以外のアプリ安全に利用させたいのか」

という業務特性に関わる要件です。

テレワーク用途では、前者でよければセキュアブラウザ方式に、後者でよければそれ以外の方式にふるい分け

できますWeb 分離用途では、前者が仮想ブラウザ方式後者がそれ以外の方式となります

27 →目次に戻る

ポイント 2】データを処理するマシンローカルマシン大丈夫かどうか

次に、「 情報漏えい対策をどこまで強固なものにしたいか」という観点での要件です。

プログラムの実行環境が手元のPC となる場合データも手元のPC に保存されます。つまり、手元のPC

まれ場合、保存されているデータも盗まれしまます

ディスク暗号化している、生体認証有効にしている、だから大丈夫」と言い切れるならいいかもしれません

が、「技術進歩によって将来的に突破されるかもしれない」といった懸念払拭(ふっしょく)できない場合、仮

デスクトップ方式リモートデスクトップ方式のように、遠隔にあるマシン上で作業できる仕組みを導入する必

要があります

その一方、将来の懸念よりも、例えばコストなど別の部分を重視したい場合は、会社PC 持ち帰り方式VPN

方式)やアプリラッピング方式マッチするでしょう。

なお一般的に、リモートデスクトップ方式VPN 方式テレワーク用途のみで導入されますが、仮想 デスクトッ

方式アプリラッピング方式は、テレワークWeb 分離、どちらの用途にも利用できます

ポイント 3】データを処理するマシン物理PC大丈夫かどうか

ポイント 2】で「遠隔にあるマシン上で作業させたい」となった場合は、3 番目の検討事項として、業務継続

性を考えるとよいでしょう。

リモートデスクトップ方式場合、社内の自席にPC物理的に存在することが前提です。そのため、自席 PC

故障したときに「何もできない」状況になります

一方、仮想デスクトップ方式場合マシン仮想化されており、多くの環境において仮想マシン動作してい

サーバ群はn +1 などの方式冗長化されています。そのため、非常に強い障害耐性があります

障害耐性を高めたい場合は、仮想デスクトップ方式ベストです。業務が停止するなどのリスク運用でカバー

できる場合は、リモートデスクトップ方式を選ぶことになるでしょう。

28 →目次に戻る

ポイント 4】実行環境が分離されている必要があるかどうか

ポイント 2】で「手元のマシン上で作業させてもOK」となった場合、3 番目の検討事項として、再度情報

えい対策について考えます。【 ポイント 2】では、PC ごとデータが盗まれしまった場合を想定しましたが、ここ

ではプログラムの実行そのものに対するリスク検討します。

手元のPCプログラムを実行するということは、つまり「端末の脆弱(ぜいじゃく)性を突いたゼロデイ攻撃

を受けるリスク存在する」ことです。脆弱性を突いた攻撃を受けると、多くの場合情報を抜き取られてしま

ます

従って、例えば VPN 方式を導入する場合、「EDR(Endpoint Detection and Response)で脆弱攻撃

策を実装する」「端末のロックダウン化によってデータを保存させない」「実行できるプログラム制限する」「屋

外の公衆Wi-Fi を利用できないように制限する」「多要素認証を導入する」などの対策を併せて導入する必要

あります

このような徹底した対策継続して運用できる組織に限っては VPN 方式有効選択肢ですが、筆者としては

安易VPN 方式の導入を推奨することはできません。

VPN 方式安価かつ容易に導入できるので、昨今のテレワーク需要高まる状況では、多くの組織上記のよ

うな徹底した対策を取らずに導入してしまったと思います。取 り急ぎの暫定処置としてVPN 方式を導入してしま

場合は、これを機に腰を据えて見直してみてはいかがでしょうか。

• 参考リンク日本経済新聞「在宅時代落とし穴 国内38 社がVPN不正接続被害

また、国内に限った話ではありませんが、Verizon Communications のレポートによると、やはりVPN トラ

フィックが増加傾向にあるようです。VPN 方式の普及に伴って、悪意ある攻撃者による被害数も増加すると思い

ます

• 参考リンク:Verizon Communications「Verizon Network Report」

29 →目次に戻る

それぞれの方式比較

ここまで、要件ベースとした考え方を記載しました。選定すべき方式が大まかに見えてきたところで、ここか

らはそれぞれの方式を横に並べて、共通の項目に沿って比較します。

この比較によって、方式選定の次のステップとなる製品選定において「見落としがちな落とし穴を見つけて対策

を考える」といった検討を具体的に進めることができると思います

以降の表の見方説明しておきます。緑塗りのセルポジティブな内容、赤塗りのセルネガティブな内容、黄

塗りのセルはどちらともいえない内容です。また、それぞれの表の下部には、主に赤塗りのセルに関する特記事項

記載しています

なお単純に、緑塗りセルの多い方式が優れているわけではありません。対象業務の内容やコスト運用体制、セ

キュリティ業務継続性など、いろいろな観点からトレードオフ方式を選定することになります

できる作業

(出典:ネットワンシステムズ

仮想ブラウザ方式とセキュアブラウザ方式では、例えばファイルサーバ操作といった、ブラウザ以外のアプリ

は使えません。多くの場合Windows統合認証など Windows依存する機能も利用でません。

また、印刷に関しても確認必要です。製品ごとにサポート内容に差が出るポイントなので、方式選定の次の

ステップとなる製品選定の段階で確認した方がよいでしょう。

30 →目次に戻る

コスト

(出典:ネットワンシステムズ

会社PC 持ち帰り方式VPN 方式)とリモートデスクトップ方式は、端末のアップデート故障時の交換など、

端末台数が増えるに従って、それに対応できる人員数を確保する必要があるので、運用コストが増大する傾向に

あります

その半面、仮想デスクトップ方式は初期コストが高額ですが、メンテナンス対象マスター OS のみであり、仮

マシンを一気に展開できるので、運用員の集約化が可能です。

VDI の運用ナレッジ豊富SIer に依頼することで、作業内容の質を落とさずにコスト圧縮できる効果が期

待されます

運用

(出典:ネットワンシステムズ

仮想ブラウザ方式アプリラッピング方式、セキュアブラウザ方式は、「 Web ページが正常に表示されるかどう

か」などの動作確認を、あらかじめ実環境実施しておく必要があります。この動作確認は、運用フェーズにおい

ても継続する必要があります

また、特に仮想ブラウザ方式は、「 ブラウザタブを開き過ぎるとサーバ基盤の負荷が高騰して Web ページの閲

覧速度が急激に低下する」といったサイジング関連のトラブルが発生しやすくなります

31 →目次に戻る

セキュリティ

(出典:ネットワンシステムズ

マルウェア対策については、会社 PC 持ち帰り方式VPN 方式)やリモートデスクトップ方式仮想デスクトッ

方式は、EDRアンチウイルスソフトの導入などが別途必要です。一方、仮想ブラウザ方式アプリラッピン

方式、セキュアブラウザ方式は、「 利用終了後に環境ごとデータを削除する」「 exe 形式ファイルの実行を禁

止する」などの機能を標準で実装しています

重要情報の盗聴については、リモートデスクトップ方式仮想デスクトップ方式仮想ブラウザ方式(画面転送

型)は、画面転送型なので、暗号化通信が仮に復号されたとしても、実データが盗聴されることはないという強

みがあります

最後に、不正アクセスについては、多要素認証システムと組み合わせるなどの対策がどの方式でも必要です。

ログインに関わる操作が増えることで利便性は低下しますが、昨今の状況を鑑みると、多要素認証の導入は必須

といえます

おわりに

これで 3 回にわたる連載は終了です。いかがだったでしょうか。

セキュリティ利便性トレードオフ関係にありますが、筆者は「仮想デスクトップ方式」と「仮想ブラウザ

方式」がバランスの良い方式だと思います

仮想デスクトップ方式仮想ブラウザ方式は、「 導入によってセキュリティレベルを大きく低下させることはな

い」という点が最大のポイントです。その上で、仮想デスクトップ方式には「従来のクライアント OS と同じよう

に利用できる」という汎用(はんよう)性の高さがあり、これが他の方式より優位な点となっています。一方、仮

ブラウザ方式は、用途限定されるものの、ユーザーにとっては利便性が高く、初期コスト観点では仮想デス

トップよりも導入しやすいので、Web 分離の第一候補になってくると考えます

2021-12-30

ネットブート概要と端末を一元管理するメリット

ビジネス教育現場において、ときには1000台以上のパソコン端末を管理しなくてはならないケースがあります。この際、各端末を一元管理するために用いられるのが「ネットワークブート(=ネットブート)」です。

今回は、大学専門学校などの教育現場にも採用されることが多い一元管理システムネットワークブート」の概要と導入するメリットについて紹介します。

ネットワークブートNetwork Boot)とは

通常、コンピューター使用するためにはWindowsmacOSなどのオペレーティングシステムOS)を各端末に導入する必要があります。これに対して、情報処理ほとんどをサーバーで行い、ユーザー操作する端末自体の処理を必要最小限にする運用方法を「シンクライアント」といいます。「ネットワークブート」はシンクライアント方式の1種であり、構築したネットワークを通じて、サーバーからOSなどの情報を取得して起動するシステムのことです。原則ログイン情報を打ち込むだけでネットワーク内のどの端末からでも、アプリファイルなどの環境再現できるため、パソコン教室に設置するデスクトップパソコンなど不特定多数が使う環境に適しており、教育機関採用されやす理由の1つです。

ネットブートNet Boot)

ネットワークブートと同じ意味で使われることが多い「ネットブートNet Boot)」ですが、厳密にはネットブートmacOS機能の1つで、macOS Serverからの指示によって構築したネットワーク上のMacを起動・操作するシステムのことです。

この機能によって遠隔からソフトウェアインストールなども行えます

デスクトップ仮想化(VDI)型

ネットワークブート型と比較されることが多いシンクライアント方式の1つです。仮想環境作成したデスクトップ環境ネットワーク環境下の各端末に転送して操作する方法で、ネットワークブート型よりもカスタマイズ性が高いことが特長です。また、ネットワークブート型よりも少ないリソース運用可能である一方、サーバー上で処理しなければならないのでサーバーの負荷やライセンス料が増大する傾向があります

教育機関での利用においては、基本的に生徒は全員同じ環境で授業を受けたり、作業したりする可能性が高いため、VDI型の高いカスタマイズ性は必要ないケースが多く、ネットワークブート型が採用されることが多いです。

ネットワークブートメリット

シンクライアントソリューションであるネットワークブート」は、データなどをサーバー側で一元管理できるので、活用することでセキュリティ面や管理効率化などに大きなメリットを得られます

パフォーマンスが高い

端末側のCPUメモリで実行するので、導入したiMacなどの性能を十分に活用できますネットワーク環境PC台数が増えても、高速ブート可能なので高いパフォーマンスが期待できます

アプリケーションや周辺機器制限がない

インストールするアプリケーションや端末側で利用する周辺機器に、原則制限がなく使い勝手が良いのもネットワークブートメリットです。「ローカルディスクがないPC」という感覚で利用できます

管理が容易

詳細は導入先やシステムによって異なりますが、ネットワークブート運用管理システムを組み合わせて一元管理することで、各端末の状態簡単に把握できるほか、ログ採取サーバー設定・更新自動反映などが可能になります。これにより、少数の担当者でも運用管理が容易になるでしょう。

セキュリティの向上

近年、ネットブートが注目されている理由の1つが、セキュリティ性が高いことが挙げられます。各端末のデータサーバー管理するため、ユーザーが利用する端末にはデータは残りません。このため、データ流出などを未然に防ぐことができます

これらのメリットに加えて、教育現場ではクラス替えなどがあって従来とは違う端末を生徒が使うケースでも問題なく、同じ環境で利用することができるほか、必要台数分の有料アプリケーションなどを購入すれば良いので、全生徒分のライセンス料などを払わなくて良いといった特長もあります

ネットブート環境の構築は信頼性の高い業者

ネットブート環境を構築するためには、導入先の独自システムとの連携や構築方法をしっかりと把握して仕様書にまとめる必要があります。規模によっては検討から運用供給まで1~2年かかるケースもあるので、ネットブート環境の構築の豊富な実績と経験がある業者選びが重要になります三谷商事は1000台以上の大規模ネットブートを構築するなど、教育機関への導入実績を長年にわたって積み重ねています大学高等専門学校への導入事例をまとめているので興味のある方は確認してください。

※関連ページ:導入事例

 https://www.mitani-edu.jp/case

仮想化時代NAS 選び - やっぱり iSCSI は早い。


仮想システムを構築するにあたり、CIFS しか使えない NASバックアップ用に選定してきた SI 屋さんが居たので、CIFS と iSCSI のどちらが早いのか、試してみました。



テストに使う NAS は QNAP の Turbo NAS TS110

http://www.tekwind.co.jp/products/entry_6719.php

です。もう6年以上愛用して、カビが生えてもおかしく無い程に古いし, Marvell 800Mhz という低スペックな Qnap NASです。 100Mbps 時代のモノです。

昨年、HDDがお亡くなりになったので、3Tb の HDD に交換しました。ファームウェアはこんなに古い機械でも、QNAP シリーズの最新バージョンが利用できます

iSCSI は、今あまり見なくなりましたが SCSI ケーブル規格や、SASケーブル接続ハードディスクを、一般的IPネットワークで規格で仮想化したものです。

マウントするホストシステム側は iSCSI initiator, ディスクストレージ機能提供する側を iSCSI Target と呼びます

ホストからマウントするしない」はイニシエータ側のソフトウェア的な操作で行います。これは便利な機能で、ディスク故障などで、一時的物理的に取り外さなければいけない場合でも、ホストから操作だけで実際のケーブル結線の脱着を行う必要がないので、今時での SAS の外付けディスクドライブの様に、ホストシャットダウンして電源を切り、結線を外して修理、交換する、という必要がないので、ディスクデバイスの修理をホストの電源を止めないで実施できると言う、実に便利な事ができます

という事で、仮想環境では実に使いやすストレージデバイスなのです。

マウントするホストから見ると単純に SCSI/SASハードディスクに過ぎません。iSCSIストレージマウントしてからは、通常の増設ディスクの様にフォーマットして、ホスト側で使う一般的な XFS, ext4, NTFS などのフォーマットフォーマットする必要があります

LinuxiSCSI ターゲットからは、内部にターゲットとして使う「巨大なファイル」が、どん! とあるだけです。この巨大ファイルを、イニシエータ側に仮想ディスクイメージとして提供しています。当然シンプル仮想イメージなので、ファイルのものバックアップコピーすれば、ストレージイメージのものバックアップができます

※ 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] #

[/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 デバイス複数作れるので、1台の iSCSI 装置複数ターゲット実装して、複数ホストから別々のターゲットイメージマウントする事は問題ありません。

極端な話、ホストハイパーバイザーは USB メモリSANブートさせて、後はマウントした iSCSI仮想イメージ上で、仮想マシンを動かす、HDDレスハイパーバイザー運用もできます

物理的な転送速度は、ネットワークの速度とディスクデバイスの性能に依存します。当然 10Gb baseネットワークカードHUB、高規格なケーブルを使えば、論理的な性能は 10Gbps です。大抵は NAS の性能がそこまで出ないのですけどね。ヨドバシカメラあたりで売っている 4,000 円程度の 1G HUB でも、そこそこの性能が出てしまます

距離は、IPがつながればどこでもなので、ホストコンピュータとメインのストレージを自社のサーバールームに置き、イニシエータを動かし、バックアップ用の iSCSI ターゲットデータセンターに置く、なんてこともできます

【送料無料】QNAP TS-431P2(ホワイトNAS 4ベイモデル クアッドコア CPULAN 2ポート搭載 (TS431P2)

価格:56,145円

(2019/7/27 12:05時点)

感想(0件)

  • LUN -

iSCSI の耳慣れない言葉に LUN (論理ユニット番号 : Logical Unit Number)というのがあります

昔の SCSI は、 SCSI バスアダプタに7番のIDを振り、残りの 0 ~ 6 のディスクCD, Tape などに ID を振り分ける物理的な3ビットディップスイッチやジャンパ端子が付いていました。これが SCSI アドレスです。

まり初期のSCSI 規格では8つ分。

これが実に難物でした。特に複数SCSI バスアダプタカードをデュプレクス設定する場合割り込み番号も別々にするので、手が滑ってジャンパピンを飛ばして床を這いまわって探したり、難解なディップスイッチを前に数日悩んだものです。

まりつのSCSIバスには 0~7の合計8台(うち大抵7番はSCSI バスカード)の物理ユニットデバイスがつながって別々に見えたという仕組みだったわけです。

ところが SCSI バスを使った Raid コントローラが出てくると、ディスクの鈴なりが、一つの物理デバイスに見えてしまうわけです。これを「論理的仮想番号」に分割して、システムからは、単一の鈴なり Raid ディスク複数論理番号に分割したわけですね。

これが LUN というヤツです。

iSCSI 機器ターゲットも、内部のソフトウェア的に複数論理デバイスに分割して、複数ホストコンピュータから複数物理デバイスのように見せかけるわけです。

別々な LUN は一つ、あるいは複数iSCSI 機器によって、複数ホストに別々のディスクデバイスとして見せかけるンです。

まぁ、いい加減な説明なので、他所で調べてください。

https://en.wikipedia.org/wiki/Logical_unit_number

Qnap NAS場合iSCSI ターゲットウィザード形式簡単作成できますEXT4 ファイルシステム上で、オンラインでも簡単サイズの拡大ができるので、 Windows の Storage Server のように NTFSVHD 形式ではないので、そこそこ性能が出ますが、いかんせん古さと遅さは否めません。

Qnap NASiSCSI ターゲットの設定は、偉そうな Linuxサイトに書いてある程、面倒なことはありません。ストレージマネージャから iSCSI タブにあるウィザードに従って iSCSI ターゲット名に任意名前を付けると IQN にその文字列が追加されるだけです。わざわざ vi エディタに「正確に」綴りを間違えずに設定する必要もありません。ここでは Chap 認証は付けませんでした。

仮想時代NAS 選び - やっぱり iSCSI は早い。_a0056607_16405779.jpg

機械は古いのですが、逆に言うと、「古くて遅い」ため、サーバーNASとの接続プロトコルの性能差が、如実に現れる事になります

QNAP TVS-951X 10GBASE-T/NBASE-Tポート内蔵

10GbE接続対応 NAS

Windows10 の MicrosoftiSCSI イニシエータは「コントロールパネル」>「システムセキュリティ」>「管理ツール」の中にあるので、ここで、設定済の iSCSIターゲットを」 「検索」して選んで「接続します。Chap 認証を付けておいた場合ターゲットで設定したパスワード必要でしょう。

仮想時代NAS 選び - やっぱり iSCSI は早い。_a0056607_16412132.jpg

新規作成して、接続した後は、フォーマットされていないため、ディスクマネージャからフォーマットして使います。ちなみに、フォーマットして利用した iSCSI ターゲット仮想ディスクは、他のマシンマウントすることもできます。つまりHDDを取り外して、他のPCに繋げる事と同じことですね。

PR

ちなみに opeSUSE で使うにはこんな感じになりました。

open SUSE Leap 15.1 で iSCSI NASを使ってハマった

https://islandcnt.exblog.jp/239328437/

  • CIFS の性能を見てみる -

一番イラつくのは、巨大なファイル転送でしょう。という事で 3G 程ある SUSE LinuxインストールDVDISO ファイルを CIFS でコピーしてみます

仮想時代NAS 選び - やっぱり iSCSI は早い。_a0056607_16414334.jpg

3分11秒かかりました。1Gビットネットワーク12~3% 程度の帯域を使って通信しています。明らかに古いNAS の性能が足を引っ張っているようです。

スループットは 150Mbps 程度で全体の最大15%程度でしょうか。

仮想時代NAS 選び - やっぱり iSCSI は早い。_a0056607_16415832.jpg

次に iSCSI マウントしたディスクコピーしてみます

仮想時代NAS 選び - やっぱり iSCSI は早い。_a0056607_16422170.jpg

初速は出るのですが、その後は、ボロイ TS-110 の性能がモロに出ます。それでも 20 MB/s から 25 MB/s 程度は出ています

仮想時代NAS 選び - やっぱり iSCSI は早い。_a0056607_16423835.jpg

2分25秒でした。 大体20%程度のスループットです。





--

数字に弱い私の脳みそですが、 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 を搭載して、低価格NASUnix 系のシステムで「低価格」を謳っていますが、そもそも、上位モデルは、CPUメモリの性能が高いものが使われています。性能が違うのは当たり前なのですが、あまり性能が出ないだろうと思います

Windows Storage Server じゃなくて、ちゃんとした Windows Server と CAL 買えよな、という事なのですね。

このあたりは独自OSNAS としてチューニングした Qnap や Synology, asuster などの iSCSI 機能付きの NAS を中規模ネットワークのミドルレンジNAS として利用したほうが良いと思います

仮想環境でのネットワークタッチストレージ(NAS)は、本回線(構内LAN)とは切り離し、ストレージ専用のネットワークとして独立して運用させるのが基本です。サーバーNAS間で凄まじい通信が発生します。サーバーNICが2ポート以上のものが推奨されます

  •  誤解していけないのは --

iSCSIあくまでもネットワーク上のストレージのみの機能提供するものであり、ファイル共有の手段ではない、という事です。

NAS をCIFSで使うと NAS が持つ独自アクセス権限を設定しなければなりません。セキュリティも当然 NAS 独自機能で設定します。

iSCSIあくまでも「外付け SCSI デバイス」のネットワーク版なので、マウントする側のOSのものファイルシステムセキュリティ機能アクセス制限ホスト側の機能をそのまま利用できますセキュリティ的には、マウントする際のパスワード制限しかないので、独自ストレージネットワーク内に配置すべきで、ユーザが使う構内ネットワークに配置すべきではありません。

2021-12-23

anond:20211223200953

中華製でWindowsが入ってる似たようなのがポツポツ発売されてるけど、あくまWindows

SteamDeckはSteamOSっていうLinuxベースのものらしいんだよね。

LinuxWindows仮想化は近年かなり進んでて、GPUパススルーオーバーヘッド無しにできるようになったてことでしょうな。

2021-12-08

anond:20211208183831

3万円の中古ノートなら仮想化環境じゃないんじゃないの?

Ubuntuなら誰でもインスコできるのは同意だけど。

anond:20211208183238

仮想化環境無料で使えるようになってから誰でもできる難易度だし、その時期にデスクトップLinux集落が始まったんだ

実際に使用されるとゴミOSなのがバレてしま

2021-11-03

PCWatchの清水さんホンマ有能やな

もともとNW畑の人らしいが、仮想化セキュリティクラウド物理ビルドなどなんでもござれな印象。

エンジニアとしても普通に四ケタ万円超える人だな。ライターのほうが儲かるのだろうか?

もちろん本人が楽しいということのほうが重要だけど。

https://internet.watch.impress.co.jp/docs/column/shimizu/

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