はてなキーワード: シェルとは
リムタイプは将来絶滅するかな?ディスクブレーキ化されていくのかな?サイクルショップにしてみると、リムブレーキのノウハウなんてさっさと忘れさり、ディスクブレーキのノウハウだけ磨いていきたいって思うだろうから、リムは絶滅だろな。クロスバイクとかコミューターバイクとかそういう中途半端なものってなぜ存在するのだろうか?ママチャリ(シティサイクル)およびロードバイクでいいのに・・あとは山道で遊びたいMTBとかBTX。
フロントギアがマルチ (3s) なのが気に入らない。2か所もレバー操作必要だし、勾配のきつい坂道を延々のぼるわけでもないのに・・
使えずにおいてあるクランクアームがあるので、これに適合するBB (ホローテック、PW-BB73+)およびチェーンホイールを新規に購入 (アリエク!!発注済)。
よく考えずにMTB用クランクアーム買ってしまったもんだ。しかし大丈夫。クランクアームはBBに対しては圧入だな。BB側にスペーサーが付属してるんで68→73化して対応するんだね。
BBの仕組みの変化ってのも自転車パーツの進化の一つなのだろうか?メンテやりやすくなるよね
「BBなど追加購入して、このクロスバイクに取り付けたらいいのでは?」と思いつた。
クランクはMTB用らしくてBBにいっぱいスペーサーがついてくるよう。
STIなどのシフター付ブレーキはめちゃくちゃ高いので、ブレーキだけの奴 (アリエクで)。AcadiaはブレーキがVじゃなくてキャリパーなのがGOOD. リアギア (7s) は サムシフターSL-TZ500でcontrol (アマで)。ペダルは流用。
延期。
現状のハンドルバーの寸法 (25.4/22mm)。ドロハン (Upanbikeがアマで紹介されている)購入? いずれにせよドロハンをねじ込むのが大変だと思う。当て板とか首下の長いネジとかでこじ開けるんだよな。
クランクアームだけスクエアテーパーBB用の奴(アリエク) 買いなおす?コッタレスクランク抜き (B000RW71AS) も千五百円ほどで購入し自分でつけかえたら?ついでにペダルも折りたたみタイプのに?
出先では溝付きの駐輪場使うもしくは前輪外して駐輪場のバーに引っ掛けて、駐輪。
自宅では自転車の前輪を外して玄関に収容。メンテスタンド購入済
前輪外し+フォールディングペダル化+フォールディングハンドル化で車のトランクかもしくは後部座席の床部に
格納できないか?
ハンドルステムの件は無理せずプロ用の浸透潤滑剤が納品されてからにしやう!そういうことで納品を待ち、実際に使ってみたところ見事に緩めることできた。さすが浸透潤滑剤!威力あるわぁ。
世の中で入手できる完組ホイール(特にリア)がディスクブレーキタイプとなったら、いよいよフレーム(+フォーク、約一万五千円)買い替えか?そうするとリアが700で
フロントが26という異径組み合わせになるね?その時はハンドル回りも買い替えだよ。
電アシママチャリ(ホイールはMTB風)における変速は、内装変速機(3速)なのです。これって 5速 に変更できるものなのですか?
シフターはこれに伴って変更ですよね。おそらく3→5速にするとハブ径変わってくるので、スポークも総取り換えですかね?
子どもが乗っていた子供用自転車(フレームサイズが350くらいしかない)が成育しすぎてダメになりそうだから・・
(ちな低身長者用のママチャリのFSは420)流用可能な部分はそこから部品とり。
後輪あとはRD(ディレーラー)。ワイヤー類を内装させる必要あり。根性的に大変?中華電動シフター(中華版Di)って販売してないのか?
海外通販で在庫一掃品のMTBフレーム(V台座付、でもフォーク付属せず)に心惹かれる私
工賃
本当にあれ畳むのか?っていうフレーム (P/N = 1005003617006752)。あいつ→26用だった気がする。それで組むか?
それならポータビリティが高まる(乗用車や電車に積載可能)ってことで、訴求力ありまくり。フロントホイールもQRだし...。
DBマウントだったと思うので、フロントもリアもキャリパー一択。
こいつもオリベロ化できると我が家で二つになる。二人で輪行。母子で輪行とか夫婦水入らずで輪行とか。父子で輪行・・はナイか?
26インチならスピードが出ない問題もある程度緩和されるし・・
折り畳み式フロントフォークみたいなのがあるのか?自宅にあるアジサシ見てるとフレームヘッドに刺さってるフォーク折れ曲ってコンパクト
化してるようだ
BBシェルは68とあるので、標準規格でしょ!?ママチャリのキャリパー化って検索すると死ぬほどたくさん出てくるのはなぜ?世の中には
ママチャリフレームがそんなに好きなのか?なにがそんなにいいのだろ?
その手のサイトでお気に入りは これ→ st162c.blog.jp/
電動(しかも無線で)ギアチェンジさせるガジェット。これでハンドルからディレイラーまでの頑丈な金属線を張り巡らす必要がなくなるらしい。
ゴースト・イン・ザ・シェルとかアリータ:バトルエンジェルとかオール・ユー・ニード・イズ・キルとか名探偵ピカチュウとかドラゴンボールエボリューションとか映画化されとるやん。制作費もドクター・ストレンジあたりとはそう変わらへんで。
PFUの高級キーボード、Happy Hacking Keyboard(HHKB)だが使い方を間違えている人が多い
一応、Fnキーを押しながら使うことはできるが非常に使いにくい
なぜこんなことになっているか、というと、そもそもプログラマー(ハッカー)は基本的に矢印キーを使わないからだ
Vimの人はhjklでのキー移動、EmacsはC-BPNFでのキー移動
シェルを使う場合もEmacs風にキー移動できるしショートカットを使うので基本的には使わない
ちなみに知らない人も多いがTwitterもVim風のキーバインドで移動可能
Macの人は例えばメモアプリなんかがEmacs風のキーバインドで移動可能
Windowsを使う場合もアプリなんかでキーバインドを入れ替えて矢印キーを使わないようにする
こんな感じで矢印キーを使わない人が多いから、矢印キーが無くても問題ないのだ
のではなく
「ハッカーが矢印キーを使わないからHHKBには矢印キーが無い」
ということだ
矢印キーはホームポジションから離れた場所にあるため、使うためには一旦ホームポジションから指を離さなければならない
一度話してまた元に戻るという、このコンマ数秒レベルの遅延が鬱陶しくて仕方が無い
なのでホームポジションに指を置いたままキー移動したい、という考えに至っている
とはいえ、全く矢印キーを使わないかというとそういうわけではなく、そりゃたまには使わざるを得ないし使った方が早い場面もある
なので矢印キーを右下の空いてるスペース(通称、猿が辻)に置いておけばいいし、HHKB Liteだとそこに矢印キーがある
なぜそれでも置かないかというと、そもそもが持ち運び前提のキーボードであって、少しでもキーを減らしたい、という哲学があるからだ
はっきり言ってしまって持ち運ばないならRealforceを使えば良く、HHKBを利用する利点は持ち運び前提であるという一点だけと言っても過言では無い
これの大きな理由は、昔はサーバルームでの作業のようにキーボードを繋いで利用するような使い方が前提であった、というのもあるがそもそもの哲学によるところが大きい
アメリカ西部のカウボーイたちは、馬が死ぬと馬はそこに残していくが、どんなに砂漠を歩こうとも、鞍は自分で担いで往く。馬は消耗品であり、鞍は自分の体に馴染んだインタフェースだからだ。
和田先生のこの談話に代表されるように、キーボードは人間がコンピュータと関わるうえで重要なインタフェースであるという設計哲学がある
なのでキーボードはコンピュータに備え付けられているものではなく、持ち運んで自分の好みのものを使う、ということを推奨している
そのためにもキーボードは使いやすさや打鍵感だけでなく持ち運びやすさを重要視してバランスの取れた設計を目指している
その結果、矢印キーを排除するデメリットよりも、排除することで得られる持ち運びやすさのメリットの方が大きいと判断したのだ
左右の猿が辻があるお陰で持ち運びしやすいというのも使ったことがある人なら分かるポイントだと思う
この辺りは賛否あると思うが、馬の鞍であるという哲学に基づけば、PC毎にHHKBを用意したり、自宅と会社で2つ置いている、などは使い方として間違えている
全く同じキーボードであっても、物理的なモノが違えば慣れ親しんだものではなくなってしまうだろう
キーボードを生涯のインタフェースとするなら1つのHHKBを持ち運び使うということを体現して欲しい
ただ最近はBluetooth接続が増えたことや、HHKB BTの出来が良くないことなどもあるため、複数持っている人も多いとは思う
ちなみに、BTモデルには充電池が内蔵されておらず電池駆動なのも生涯使うことを考えているのだろうと思う
これはHHKBに限らない余談になるが、キーボードの裏面にある足は基本的に出さない
手首に角度を付けるよりも水平の方が使いやすいのは人体の自然な原理だ
なぜあの足が付いているか、というと実は「キートップを見やすくするため」だ
なのでHHKBの無刻印モデルに足が付いている理由は全く理解できないし、HHKBを使うような人がキートップを確認するとは思えないのでそもそもいらない
とはいえ、昔から足を出して手首に角度を付けてタイピングすることに慣れてしまっている人もそれなりにいるだろうから
自分の好みで出したり引っ込めたりすればいいとは思う
——登さんくらい常に気持ちをフラットにできればいいのですが、仕事のストレスで参ってしまうエンジニアも多くいます。
そうですね。ストレスを感じる理由はさまざまあると思いますが、一つ例をあげるなら、仕事の目的が「お金を稼ぐこと」それ自体になっている人は疲弊しやすいかもしれませんね。
稼ぐことを目的としている人のゴールは、おそらくご自身の「安寧な暮らしの実現」にあるのだと思います。それがとても大事なことなのは言うまでもありませんし、否定するつもりも毛頭ありません。
一方で、私や私の周りにいる人たちは、現状の成果に満足せずに得たお金を次の進化のために再投資しようと試みる人ばかり。どちらが良いとか悪いとかではなく、価値観が違うだけのことです。
ただ、前者の「お金を儲けて安寧な暮らしがしたい」という人にとって、仕事から受ける疲労や気分の落ち込みというのは、ある種当たり前のことだとも思うんですよね。
——というと?
どこかで成長を諦め、安寧な生活を望むような性向が、かえって心身の不調やフラストレーションを生み、パフォーマンスを落とす一因になっているのではないかと思っているんです。
「お金を稼ぐためだから、しょうがないか」と思ってやっていること自体が、ストレスになるのではないかと。
登 大遊さん
でも、こればっかりは人の価値観ですからね。変えようと思っても、すぐに変えられるものでもない。
どんな価値観で生きるのかを選ぶのはその人ですし、どんな人生を選んでもリスクはついて回ります。
安寧な生活や休息を優先する生き方には、仕事に対するストレスやそれに付随する心身の不調などの副作用があるということに過ぎません。
ただ、一つ言えることがあります。日本において、「大義を持って働く」生き方を選択をした人は、これから大変有利だということです。
——どういう意味でしょう?
自分の手で未来を変えようと野心に燃える人が世界中から集まるシリコンバレーなどでは、埋もれてしまうかもしれない人であっても、日本の旧態依然とした組織の中では、同じことをするだけで、比較相対的に価値が高くなりますから。
技術者がわざわざベンチャーを立ち上げ、投資家からお金を引き出すために詭弁を弄したり、ニーズをでっち上げたりしなくても、日本の大企業にはストレートに解決すべき課題がいくらでもあります。そしてそれらの問題を、自分自身の頭脳を用いて解決しようとする時は、必ず、従来とは異なる方法で解決する必要があるのです。
なぜなら、まさに従来手法では解決できなかったことからその問題が放置または堆積されているためです。
——その場合は、どうすればいいのでしょうか。
その問題を一旦一般化・抽象化した上で、これを解決することができるより低レイヤーのフレームワークのようなものを作ってしまうことが重要です。一定の労力はかかりますが、それによって生じた汎用的成果物は、他の業務や他の組織においても普遍的価値を持つようになります。
ここで重要なのは、目的を「業務上の特定の問題の解決」から昇格させ、「その特定の問題と本質的に類似しており、かつ既存の最適な解決方法が存在しない、新たな汎用的解決方法の実現」という、より価値の高い目標に設定する必要があるということです。
登 大遊さん
——目先の特定の問題をその場しのぎで解決するのではなくて、普遍的な価値を目指すと。
その結果、問題がうまく解決され、成果物が出たならば、サラリーマン的な自分自身(個人)と自組織にとっての短期的な狭い利益だけでなく、同時に「世界における技術の進歩」という長期的で大きな価値が生じます。
具体例を挙げると、たとえば「UNIX」を構成する重要な機能、たとえばシェルやプロセス間通信、パイプ、grepといった機能。これは電話会社であるAT&T社の特許部門における、膨大なテキストファイルを全文検索するという特定の業務を解決しようとした同社の社員たちが、単にその社内問題解決にとどまらず、さまざまな組織や目的で汎用的に利用できる仕組みを考案し、プログラミングして実装したものです。
結果として、「UNIX」は汎用的に利用される価値を有し、単に一企業の業務に留まらず、全世界的に普及し現在のサイバー世界の基礎となっています。
このように考えれば、ICT技術者は、これまで組織内で放置または堆積されてきた多種多様な課題について、目先の解決ではなく、「正しい普遍的な方法で解決する仕組みを作る」という気概で、真摯に向き合えば、自然に世の中に貢献できる成果ができるわけです。
でしょ
マックイーンで初めてを済ませたらもうライアンに乗り換えてて、メジロ家の姫みたいなことしてメジロ家に内紛をもたらしてそう
と思ったらしっかり会長ともできてんのがなんかよくないわ
マックイーンが一番抜けてる感あるから、寝取られてしまった可哀そうなマックイーンはなんかいいね
それに比べてニシノフラワーは、同じ馬主のセイウンスカイの子供産んでて尊いんだよな、と思って改めて繁殖実績見たらそうでもなかった
年度 | 馬名 | 性別 | 父名 |
2007 | ニシノオフェンス | 牡 | アグネスタキオン |
2004 | ニシノマナムスメ | 牝 | アグネスタキオン |
2003 | ニシノミライ | 牝 | セイウンスカイ |
2002 | ニシノカエデマル | 牡 | パントレセレブル |
2001 | ニシノデュー | 牡 | ブライアンズタイム |
2000 | ニシノハーロック | 牡 | タイキシャトル |
1999 | ニシノライメイ | 牡 | ダンシングブレーヴ |
1998 | ニシノシシオウ | 牡 | ラムタラ |
1996 | ニシノセイリュウ | 牡 | ブライアンズタイム |
あと、男の子がこわいメジロドーベルちゃんも、覚えてしまったらしっかりやれる子
初めてはエル
なんかウマ娘的には相性よさそうだな
絡み合ったっけ?
年度 | 馬名 | 性別 | 父名 |
2016 | ピンシェル | 牡 | ルーラーシップ |
2015 | メジロドーベルの2015 | 牝 | キングカメハメハ |
2014 | ホウオウドリーム | 牡 | ルーラーシップ |
2012 | レーヌドブリエ | 牝 | ゼンノロブロイ |
2008 | メジロダイボサツ | 牡 | ディープインパクト |
2007 | メジロオードリー | 牝 | スペシャルウィーク |
2006 | メジロシャレード | 牝 | マンハッタンカフェ |
2003 | メジロアレグレット | 牝 | アグネスタキオン |
2002 | メジロルルド | 牝 | サンデーサイレンス |
2001 | メジロヒラリー | 牝 | エルコンドルパサー |
少し前にmacOSはLinuxではないとTwitterで話題になりました。その際に
といった内容のTweetを見かけたのですが「元になったのはBSDではなくMachなんだけどな~。昔を懐かしみつつ、調べながら何か書くか」と思いつつ、面倒になったので記憶のまま適当に書くことにしました。
Machは当時一世を風靡していたマイクロカーネル設計を採用したOSで、BSDとは全く違うOSです。
ただしBSD互換機能を利用していたユーザーは、内部に関心が無ければ
といった印象を持っていたのではないでしょうか。互換機能としては成功なのですが。
macOSのもとになったNeXTSTEPはMachを改造して始まりましたが、現在では別物であると考えるべきです。
macOSは直接にはMachから派生したもので、BSDではありません。ただし
など、BSDと誤解させる点があるのは確かです。
上記のUnix → BSD → Mach → NeXTSTEP → macOSではソースコードを利用しながらOSを作って行ったため共通の部分がありますが、これらとは全く関係無く独立して開発されたものです。
しかし現状ではNode.jsやPythonなどでプログラムを作ろうとした場合にシェルで使うコマンドはmacOSとLinuxでは共通するものも多く
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
278あとで/1848users セガがjavascriptでぷよぷよを作るプログラミング講座を出しているが、とても良いプログラミングの教材になっている「写経はとても大事」 | Togetter
238あとで/1666users ジャズのコード進行の原理 - アラクー Arakur
228あとで/1260users ソフトウェアエンジニアなら3秒で理解できる NFT 入門 - Okapies' Archive
220あとで/1885users Adobe製品と同じような事をフリーソフトでやりたい場合の対応表がすごく使える→他にも高機能なフリーソフトが集まる | Togetter
211あとで/1407users 「Visual Studio」の中の人が作ったプログラマー向け十徳ナイフ「DevToys」/今までググって探していたツールがひとまとめに | 窓の杜
210あとで/3113users ゲームの勝敗でかんしゃくを起こす子どもにできることは大人げない大人になること|フィンランドワークショップomena|note
201あとで/1188users 総務省「誰でも使える統計オープンデータ」無料オンライン講座スタート | ITMedia
198あとで/960users プログラムがメモリをどう使うかを理解する(1) | rita | Zenn
196あとで/1262users 仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話|田辺めぐみ|note
189あとで/973users フロントエンドのデザインパターン | Shinya Fujino | Zenn
187あとで/1551users 英語面接で5歳児みたいなことしか言えないからカッとなってWebサービス作った【個人開発】 - Qiita
187あとで/1563users TOEIC満点ホルダーがやっているおすすめ英語学習法(2022年版)|Shin|note
177あとで/1554users 207で1年間磨き続けた1on1のフォーマットを公開します|207株式会社|note
171あとで/1530users エンジニアの"有害な振る舞い"への対処法 - Qiita
170あとで/1316users 顧客との打ち合わせが上手い人がやっていること|いまにし|note
165あとで/1551users 「この会社は詰んでます。潰れました」で気づいた“恥ずかしさ” DeNA南場智子氏がエンジニアから学んだこと | logmi Tech
158あとで/1342users 「勝手に学ぶ人」と「期待されて学ぶ人」の差が埋められない|柴田史郎|note
153あとで/1343users 強いエンジニアになるために英語が必要と聞いたので4ヶ月でTOEICスコア400→900まで上げた話 - Qiita
148あとで/1190users なぜ40歳を越えると「やる気」が出ないのか? 「中年の危機」を乗り越えるためのエンジンの回し方 | 野水克也, 萩原雅裕 | logmi Biz
148あとで/955users ITエンジニアが投票した「ITエンジニア本大賞2022」ベスト10発表。「シェル・ワンライナー160本ノック」「モノリスからマイクロサービスへ」「恐れのない組織」など | Publickey
142あとで/690users JavaScriptを遊び尽くす究極のWebサービス・ツールを厳選して大公開! - paiza開発日誌
138あとで/891users そこまで努力しないで生活をちょっと改善する100の方法 | 英紙が元旦に紹介 | COURRIER
137あとで/1237users 問題職員の正しい辞めさせ方 1/10 | anond.hatelabo.jp
136あとで/635users フロントエンドを集中的に学習できる究極の無料リソースを厳選してみた! - paiza開発日誌
133あとで/768users ミーティング・ファシリテーション入門 / Introduction To Meeting And Facilitation | ストックマーク株式会社 iwashi | SpeakerDeck
126あとで/1056users Future社員が使っているWindows便利ツール(新人さん向け) | フューチャー技術ブログ
126あとで/802users 『データ分析のためのSQL勉強会』資料公開|高橋 光|note
126あとで/859users エンジニアを始めてから便利だったツールまとめ | nakaatsu | Zenn
125あとで/757users 2022年におけるフロントエンド開発のベースライン - LINE ENGINEERING
123あとで/1202users 50歳になってようやく気付いた、人生で重要なことと、後悔したこと。 | fujipon | Books & Apps
123あとで/1055users 【必読】総務省直伝のExcelマニュアルが目から鱗が落ちるものだった | Togetter
ジャズのコード進行を解説したブログが2位になった。はてブでこんなページを目にできようとはとブクマカが驚愕。
COURRIERの「そこまで努力しないで生活をちょっと改善する100の方法」はペイウォールの向こうに行ったが原文は読める。 https://www.theguardian.com/lifeandstyle/2022/jan/01/marginal-gains-100-ways-to-improve-your-life-without-really-trying
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
・めだま焼きと唐揚げ
・親子丼
あたりは、ユダヤ教の「親と子を一緒に食べてはいけない」という教えに反するらしい。
ハラルとか仏教とかそれぞれ違ってめんどくさいから全部食わないのがいちばんだよ。
ID非公開さん
2016/9/1 15:50
6回答
ユダヤ教において「子ヤギの肉を、その母の乳で煮てはならない」という戒律がありますが、“親子”の組み合わせ料理は、ユダヤ教徒は厳禁で 同じ親子の組み合わせ、親子丼やチーズバーガーすら厳
禁らしいです。
でも戒律は「子ヤギの肉を、その母の乳で煮てはならない」であって、あくまでも「子ヤギの肉」を「ヤギ乳で煮てはならない」であるから親子丼やチーズバーガーなら問題ないんじゃないでしょうかねぇ?どうも悪い方へ解釈してしまってるのですね。
宗教・1,114閲覧
cav********さん
2016/9/1 19:05
ユダヤ教では「肉と乳製品をいっしょにとること」を禁じています。チーズバーガーやクリームシチューに肉を入れることはもちろん、一回の食事で肉と乳製品をとることはできません。肉料理の食後のコーヒーにミルクを入れるなどもだめです。私がイスラエルを旅行した時、肉料理の後にデザートとしてアイスクリームが出ましたが、牛乳ではなく豆乳を使っているとのことでした。肉と乳製品を食べる間に、6時間だか8時間だか置かないとだめなのです。(胃の中で双方がいっしょにならないように。)もちろん、どこまで厳格に守るかは個人差があるようです。
親子丼は、卵であって乳製品ではないので大丈夫なのではないでしょうか。
まったくだな、鶏・卵白な親子丼、ヤギでないのに食いたくないのは とんでもない解釈!
お礼日時:2016/9/7 14:18
クリームシチュー 肉チーズバーガー親子丼クリームシチュー肉料理
その他の回答(5件)
dol********さん
2016/9/2 8:10
違うよ。カシュルート(食物規定)では「肉」と「乳製品」を混ぜることが禁じられているんだよ。
で、卵も乳と同じように親鶏から出てきて、子を育てる成分を含むものだ。だから、中世ユダヤ人は卵の性質上、乳と同じだと考えた。ただし、まだ殻を形成していない段階ならば乳とは見なされない。ここは議論があって、絶対そうだというわけでもないよ。
いずれにせよ、卵の殻座の部分には血が混じっているので、その部分を取り除かねばコシェル(適正)にならない。
また、厳格な人は食後にコーヒーを飲むこともしない。うっかりコーヒーにミルクを入れて、胃の中で肉と乳が混ざることを防ぐためだ。
さらに、イスラエルのマクドナルドなんかは、ハンバーガーを売るカウンターと、アイスクリームを売るカウンターとが別々になっている。
あなたは「悪い方へ解釈」と言ってるが、それは「食物規定は悪いもの!」というキリスト教価値観の押し付けにすぎない。
こうした食文化全体として見れば、あなたが挙げた問題なんて取るに足りないことというか、むしろ「より安全な方へ」という解釈になっているんだよ。
なぜなら、神が与えた食物規定の真意は、人には分からない。だから、人がうっかり規定違反することがあるかもしれない。それゆえ、神が具体的に命じたことを範例として、食生活の一つ一つについて詳細に検討した結果なんだ。人の謙遜さの現れなんだよ。
リクルートにおける VDI の導入、運用、コロナ対応、そして今後の ICT 環境を紹介する連載。
今回は、VDI 導入を振り返り、中長期の PC 環境の構想をお伝えする。
23 →目次に戻る
“ ネットワーク状況によっては使えないシーンがある点 ” は、VDI なら避けられない問題です。特に外出中は、ス
マートフォンによるテザリングで VDI に接続する際に、エリアや移動状況によっては通信環境が安定せず、通信が
切断されたり、通信速度が遅くなったりするなど、VDI がスムーズに動作しないシーンがありました。この課題に
対しては、スマートフォンのテザリング容量の観点なども含めて検討し、対処してきましたが、完全には解決でき
ませんでした。そこで、VDI では業務遂行がどうしても困難なユーザーに限定し、さらに高セキュリティ業務以外
での利用において通常の PC(FAT PC)を配布するようにしました。
もう一つの課題 “ ビデオ会議実施時の不具合 ” については、もともと VDI とビデオ会議の親和性は良くない点
が前提にあります。ビデオ会議の場合、クラウドサービスを使うことが多いと思いますが、通常の PC なら、クラ
ウドサービスと PC 上のビデオ会議ソフトウェアが直接つながり、ユーザーは快適にビデオ会議ができます。一方、
VDI の場合、クラウドサービスと VDI 上のビデオ会議ソフトウェアがまず接続され、その後 VDI から VDI 専用端
末(シンクライアント端末)に音声と動画が転送される形になります。音声も動画もいわば二重でデータ転送さ
れる仕組みなので、劣化してしまうのは避けられません。具体的には、音声が途切れ途切れになったり、動画が
また、システム管理の観点でもデメリットがあります。通常の PC では、ビデオ会議ソフトウェアの機能でクラウ
ドサービスとのネットワーク接続状況をチェックしてくれて、最適に通信する仕組みなのに対し、VDI ではそのよう
な機能は使えません。ビデオ会議ソフトウェアにその機能が搭載されていても、VDI から VDI 専用端末に通信す
る段階でそれらの機能が無効化されてしまうのです。その結果、VDI 上でのビデオ会議は通常よりも多くの通信
量が発生してしまい、外出時などテザリングの容量を圧迫することになっていました。
しかし、最近ではビデオ会議のこうした課題の回避策として、クラウドサービス各社が VDI 用のソフトウェアを
リリースしてくれるようになってきました。VDI 用のビデオ会議ソフトウェアを VDI にインストールして、一部のソ
フトウェアコンポーネントを VDI 専用端末にもインストールします。そうすることで、VDI と VDI 専用端末が協調
してビデオ会議端末として動作し、クラウドサービスと VDI 専用端末とが直接つながる構成になり、従来に比べる
と音声や動画の劣化が大幅に避けられるようになってきています。
24 →目次に戻る
中長期の PC 環境を構想する――“ 中長期 ” という新たな観点の導入
以上をまとめると、いまの VDI 環境では当初想定したメリットは得られたものの、ネットワークとビデオ会議に
おいてそれぞれの課題があります。ネットワークの課題は、一部ユーザーに FAT PC を配布することで、ビデオ会
議の課題については VDI 用のビデオ会議ソフトウェアをインストールすることで解決できます。いまの VDI 環境
を評価するマトリクスを作って検討してみると、VDI 用のビデオ会議ソフトウェアがうまく動作すれば、VDI 環境
をそのまま継続するのが妥当なように見えました。とはいえ、そのような “ カイゼン策 ” を施しながら、VDI をい
まの形のまま続けるべきなのでしょうか。そして、そのような思考プロセスに本当に問題はないのでしょうか――。
われわれは検討時に、新たな視点を導入することにしました。それは “ 中長期 ” 視点です。2015 年においては、
3 つの課題という、“ いま、ここ ” における課題に対する解決策として VDI を採用したものの、今後長きにわたっ
て会社を支えていくPC 環境を構想するに当たり、それだけでは不十分ではないかと考えました。リクルートは創
業から 60 年以上がたちました。今後も長きにわたり、カスタマーやクライアントの皆さんのためにより良いサービ
スを提供し続けることになるでしょう。それには短期的な視点だけではなく、中長期でのあるべき PC 環境を描い
て、それに向かっていまどうすべきかを考えなければならないと思ったのです。
そのためには、まず働き方が将来的にどうなるかを想定しなければなりません。次期 PC 環境を検討していたの
はコロナ禍前でしたが、ゆくゆくは「完全に場所を選ばない働き方」になるだろうと予想していました。キーワード
で示すならば、「Anytime/Anywhere/Securely/Work Digitally」という表現になるでしょうか。そのような働き方
を実現する PC 環境については、既にいわれて久しいですが、クラウド中心の方向性は変わらないでしょう。加えて、
今後は多種多様なデバイスが出現すると想定しました。いまは PC や VDI が中心であり、補助的にスマートフォンが
使われているというのがビジネスにおける PC 環境の実情だと考えます。では、今後はどうなるのか――。
スマートフォン中心になるという見方もありますが、学校では情報教育が進みノート型の端末が支給されており、
家庭においてはスマートスピーカーが広まり、AR/VR(拡張現実/仮想現実)もゲームなどを中心に広がってき
ています。また、企業では製造業などで AR/VR が使われる事例も出てきており、IoT デバイスもいろいろなユー
スケースが生まれてきました。
そう考えると、ユーザーが使う端末は、どれかの端末に収束していくのではなく、2in1 あるいはクラムシェル型
などの PC、スマートフォン/タブレット、AR/VR デバイス、スマートスピーカー、IoT などいろいろなデバイスを
使いこなしていく世界になるのではないかと考えます。業務のさまざまな場面で、いろいろなデバイスの中から最
適なものを選び、さまざまなクラウドサービスを使いこなし業務をしているイメージです。それらを使うことで、場
所を選ばず、どこにいても対面同様のコラボレーションができるでしょう。さらには、AI(人工知能)技術などを
活用しながらユーザーの業務を支援するなどして、高い生産性を生み出すことができる環境になっていくのではな
25 →目次に戻る
中長期視点で考え、いま行動する――「クラウド&マルチデバイス環境」へ
われわれは、このような環境を「クラウド&マルチデバイス環境」と呼ぶことにしました。中長期的には「クラ
ウド&マルチデバイス環境」になるとして、VDI の EOSL 契機に対応しなければならないわれわれの次の PC 環
境はどのように整えたらいいのでしょうか。
大事なのは、「中長期視点で考え、いま行動する」ことです。中長期視点だけを考えれば、一気に「クラウド&
マルチデバイス環境」にすべきでしょう。ところが、われわれの環境内にはまだレガシーシステムが残っており、一
気にクラウドだけを利用する業務形態に変えるのは困難でした。また、検討した結果、現時点では VDI に勝るよ
うなセキュリティ確保の仕組みは見当たりませんでした。そのため、情報資産の囲い込みができるという点で、高
セキュリティ環境に対しては継続して VDI を活用することにしました。
セキュアな環境以外の用途においては、“ いま ” のことだけを考えれば、ビデオ会議の部分のみを改善して VDI
環境のまま、次期 PC 環境を作る方向もあり得ました。しかし、それでは今後の PC 環境が VDI に固定化されて
しまうことになります。VDI 環境をいままでと同様にオンプレミスで作るには、初期に大きな設備投資が必要とな
り、また一度構築してしまうと使い捨てるわけにもいかず、それをしばらく運用し続ける必要があります。今後い
ろいろなクラウドサービスやデバイスが出現すると、活用したいと思う方も多いでしょうが、既に VDI を使ってい
る場合、VDI の代わりに別のものをすぐに使うということはなかなかできません。そういう意味で、PC 環境が固
定化されてしまうことになるのです。
中長期の環境に一気に切り替える方針でもなければ、現在のことだけ考える方針でもなく、「中長期視点で考え、
いま行動する」方針で検討した結果、次期 PC 環境は「クラウド&マルチデバイス環境」を目指すための第一歩
と位置付け、「VDI と FAT PC のマルチ環境」を構築することに決定しました。先述した通り、レガシーシステム
が存在し VDI 以上に情報の囲い込みができるソリューションがない中で、VDI から離れ、一気に中長期的な将来
像を目指すのは困難です。とはいえ「将来像に向けた環境をいま作るべき」と考え、VDI と FAT を業務特性に応
じてユーザーに配布するマルチ環境に刷新することにしました。つまり、高セキュリティ業務ユーザー向けにはセ
キュリティを確保した「セキュア VDI」、それ以外の一般ユーザー向けには FAT PC を配布することにしたのです。
将来的にはマルチデバイスといっても、いまだ PC がメインなので、まずは PC を配布し、その上で今後 AR/VR
デバイスといった他のデバイスも検討していきたいと考えています。
なお、VDI 環境としてはもう一つ、機能更新がない固定的な OS を必要とするレガシーアプリ向けの環境も VDI
で用意することにしました。用途が限定されていることから、社内では「特定用途 VDI」と呼んでいます。
26 →目次に戻る
以上をまとめますと、働き方は中長期的に「完全に場所を選ばない働き方」へと変わり、それに応じて PC 環
境は「クラウド&マルチデバイス環境」になっていくでしょう。われわれも VDI の EOSL のタイミングで変わって
いかなければならず、将来に向けた第一歩として、次期 PC 環境は「VDI と FAT PC のマルチ環境」を実現する
ことにした、ということになります。
なお、コロナ禍において、われわれは現在の VDI 環境下でビデオ会議の改善を試みました。先述した VDI 用
のビデオ会議ソフトウェアの導入を検討し、一部導入したのです。その結果、ビデオ会議の音声と動画の品質が
極めて改善されることになったものの、2 つの課題が新たに見つかったのです。
1 つ目は、普通のビデオ会議ソフトウェアと VDI 用のソフトウェアとの間に機能差があった点です。この課題は
今後解消されるかもしれませんが、われわれが導入した段階では VDI 用のソフトウェアが機能面で劣っていました。
2 つ目は、導入/管理コストです。1 つのビデオ会議システムしか使っていない場合は問題ないかもしれません
が、複数使っていたり、今後新しいシステムの導入を考えようとしたりすると、ソフトウェアの導入、管理に都度