「安寧を求める性向」は、エンジニアに不調をもたらす？
——登さんくらい常に気持ちをフラットにできればいいのですが、仕事のストレスで参ってしまうエンジニアも多くいます。
そうですね。ストレスを感じる理由はさまざまあると思いますが、一つ例をあげるなら、仕事の目的が「お金を稼ぐこと」それ自体になっている人は疲弊しやすいかもしれませんね。
稼ぐことを目的としている人のゴールは、おそらくご自身の「安寧な暮らしの実現」にあるのだと思います。それがとても大事なことなのは言うまでもありませんし、否定するつもりも毛頭ありません。
一方で、私や私の周りにいる人たちは、現状の成果に満足せずに得たお金を次の進化のために再投資しようと試みる人ばかり。どちらが良いとか悪いとかではなく、価値観が違うだけのことです。
ただ、前者の「お金を儲けて安寧な暮らしがしたい」という人にとって、仕事から受ける疲労や気分の落ち込みというのは、ある種当たり前のことだとも思うんですよね。
——というと？
どこかで成長を諦め、安寧な生活を望むような性向が、かえって心身の不調やフラストレーションを生み、パフォーマンスを落とす一因になっているのではないかと思っているんです。
「お金を稼ぐためだから、しょうがないか」と思ってやっていること自体が、ストレスになるのではないかと。
登大遊さん
でも、こればっかりは人の価値観ですからね。変えようと思っても、すぐに変えられるものでもない。
どんな価値観で生きるのかを選ぶのはその人ですし、どんな人生を選んでもリスクはついて回ります。
安寧な生活や休息を優先する生き方には、仕事に対するストレスやそれに付随する心身の不調などの副作用があるということに過ぎません。
ただ、一つ言えることがあります。日本において、「大義を持って働く」生き方を選択をした人は、これから大変有利だということです。
——どういう意味でしょう？
自分の手で未来を変えようと野心に燃える人が世界中から集まるシリコンバレーなどでは、埋もれてしまうかもしれない人であっても、日本の旧態依然とした組織の中では、同じことをするだけで、比較相対的に価値が高くなりますから。
技術者がわざわざベンチャーを立ち上げ、投資家からお金を引き出すために詭弁を弄したり、ニーズをでっち上げたりしなくても、日本の大企業にはストレートに解決すべき課題がいくらでもあります。そしてそれらの問題を、自分自身の頭脳を用いて解決しようとする時は、必ず、従来とは異なる方法で解決する必要があるのです。
なぜなら、まさに従来手法では解決できなかったことからその問題が放置または堆積されているためです。
——その場合は、どうすればいいのでしょうか。
その問題を一旦一般化・抽象化した上で、これを解決することができるより低レイヤーのフレームワークのようなものを作ってしまうことが重要です。一定の労力はかかりますが、それによって生じた汎用的成果物は、他の業務や他の組織においても普遍的価値を持つようになります。
ここで重要なのは、目的を「業務上の特定の問題の解決」から昇格させ、「その特定の問題と本質的に類似しており、かつ既存の最適な解決方法が存在しない、新たな汎用的解決方法の実現」という、より価値の高い目標に設定する必要があるということです。
登大遊さん
——目先の特定の問題をその場しのぎで解決するのではなくて、普遍的な価値を目指すと。
その結果、問題がうまく解決され、成果物が出たならば、サラリーマン的な自分自身（個人）と自組織にとっての短期的な狭い利益だけでなく、同時に「世界における技術の進歩」という長期的で大きな価値が生じます。
具体例を挙げると、たとえば「UNIX」を構成する重要な機能、たとえばシェルやプロセス間通信、パイプ、grepといった機能。これは電話会社である AT&T社の特許部門における、膨大なテキストファイルを全文検索するという特定の業務を解決しようとした同社の社員たちが、単にその社内問題解決にとどまらず、さまざまな組織や目的で汎用的に利用できる仕組みを考案し、プログラミングして実装したものです。
結果として、「UNIX」は汎用的に利用される価値を有し、単に一企業の業務に留まらず、全世界的に普及し現在のサイバー世界の基礎となっています。
このように考えれば、ICT 技術者は、これまで組織内で放置または堆積されてきた多種多様な課題について、目先の解決ではなく、「正しい普遍的な方法で解決する仕組みを作る」という気概で、真摯に向き合えば、自然に世の中に貢献できる成果ができるわけです。

Permalink | 記事への反応(0) | 09:05

2022-02-17

■anond:20220217113442

でしょ

マックイーンで初めてを済ませたらもうライアンに乗り換えてて、メジロ家の姫みたいなことしてメジロ家に内紛をもたらしてそう

と思ったらしっかり会長ともできてんのがなんかよくないわ

マックイーンが一番抜けてる感あるから、寝取られてしまった可哀そうなマックイーンはなんかいいね

マベサンいくのもようわからんね

それに比べてニシノフラワーは、同じ馬主のセイウンスカイの子供産んでて尊いんだよな、と思って改めて繁殖実績見たらそうでもなかった

年度	馬名	性別	父名
2007	ニシノオフェンス	牡	アグネスタキオン
2004	ニシノマナムスメ	牝	アグネスタキオン
2003	ニシノミライ	牝	セイウンスカイ
2002	ニシノカエデマル	牡	パントレセレブル
2001	ニシノデュー	牡	ブライアンズタイム
2000	ニシノハーロック	牡	タイキシャトル
1999	ニシノライメイ	牡	ダンシングブレーヴ
1998	ニシノシシオウ	牡	ラムタラ
1996	ニシノセイリュウ	牡	ブライアンズタイム

あと、男の子がこわいメジロドーベルちゃんも、覚えてしまったらしっかりやれる子

初めてはエル

ドーベルってゼンノロブロイの子産んでたんか

なんかウマ娘的には相性よさそうだな

絡み合ったっけ？

年度	馬名	性別	父名
2016	ピンシェル	牡	ルーラーシップ
2015	メジロドーベルの2015	牝	キングカメハメハ
2014	ホウオウドリーム	牡	ルーラーシップ
2012	レーヌドブリエ	牝	ゼンノロブロイ
2008	メジロダイボサツ	牡	ディープインパクト
2007	メジロオードリー	牝	スペシャルウィーク
2006	メジロシャレード	牝	マンハッタンカフェ
2003	メジロアレグレット	牝	アグネスタキオン
2002	メジロルルド	牝	サンデーサイレンス
2001	メジロヒラリー	牝	エルコンドルパサー

Permalink | 記事への反応(1) | 12:17

2022-02-15

■macOSはBSDではない話

少し前にmacOSはLinuxではないとTwitterで話題になりました。その際に

macOSはBSDだ

といった内容のTweetを見かけたのですが「元になったのはBSDではなくMachなんだけどな～。昔を懐かしみつつ、調べながら何か書くか」と思いつつ、面倒になったので記憶のまま適当に書くことにしました。

Unix: ベル研究所で開発されたOS
BSD: カリフォルニア大学バークレー校でUnixを改良したOS
Mach: カーネギーメロン大学で開発されたOSで、BSD 互換機能の開発のためBSDのソースコードを流用しています
NeXTSTEP: NeXT社によりMachに独自のUIを実装して開発されました
macOS: NeXTSTEPをもとにUIを一新しました
FreeBSD: カリフォルニア大学でのBSDの開発が終了した後、それを引き継いで開発しているOS

MachとBSD

Machは当時一世を風靡していたマイクロカーネル設計を採用したOSで、BSDとは全く違うOSです。

ただしBSD 互換機能を利用していたユーザーは、内部に関心が無ければ

BSDと似たOS
中身が違うがBSD

といった印象を持っていたのではないでしょうか。互換機能としては成功なのですが。

macOSはMachなのか

Machは1990年代に研究プロジェクトが終了しています。

macOSのもとになったNeXTSTEPはMachを改造して始まりましたが、現在では別物であると考えるべきです。

macOSとBSD

macOSは直接にはMach から派生したもので、BSDではありません。ただし

MachにはBSD 互換機能があった
macOSの開発の際に改めてFreeBSD から取り込んだ部分がある

など、BSDと誤解させる点があるのは確かです。

Linux

Linus氏が実装したOSです。

上記のUnix → BSD → Mach → NeXTSTEP → macOSではソースコードを利用しながらOSを作って行ったため共通の部分がありますが、これらとは全く関係無く独立して開発されたものです。

しかし現状ではNode.jsやPythonなどでプログラムを作ろうとした場合にシェルで使うコマンドはmacOSとLinuxでは共通するものも多く

macOSでUnix シェルの使い方を覚えた後にAWSのVMにログインするようになった

というユーザーがmacOSとLinuxが似ていると認識してしまうのは仕方がないところではあります。

Permalink | 記事への反応(0) | 17:38

Permalink | 記事への反応(0) | 08:25

2022-02-03

■[あとで読む]2022年 1月 はてブのあとで読む トップ30リスト

はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ

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 強いエンジニアになるために英語が必要と聞いたので４ヶ月で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

Permalink | 記事への反応(0) | 22:11

2022-01-25

■本のまとめ

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

【コンテナとは】

他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術

【コンテナ利用のメリット】

・環境依存からの解放

コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージがリリース単位となる

・環境構築やテストに要する時間の削減

優れた再現性とポータビリティ。

全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。

・リソース効率のアップ

サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲスト OS上でアプリが起動する。つまり、アプリだけでなく、ゲスト OSを動かすためのコンピューティングリソースが必要。

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OS から見ると単に１つのプロセスが稼働している扱いになる。

【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 shift やOpenSearch Serviceにログを転送できる

Fluentdやfluent bitを選択できる

fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる

【セキュリティ設計】

・イメージに対するセキュリティ対策

　- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。

　- 方法

　　脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン

継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CI CD パイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。

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までであること。

・VPCのIPアドレスの割当量に気をつける

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上にソフトウェアを実行する技術

【コンテナ利用のメリット】

・環境依存からの解放

依存関係を含めたパッケージがリリース単位となる

・環境構築やテストに要する時間の削減

優れた再現性とポータビリティ。

全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。

・リソース効率のアップ

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OS から見ると単に１つのプロセスが稼働している扱いになる。

【Dockerとは】

コンテナのライフサイクルを管理するプラットフォーム

アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリのソースコード + Dockerfile

↓ buildでイメージの作成

イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)

↓ ship でイメージの保存

レジストリに保存

↓ run　コンテナの実行

オンプレやクラウドなどで起動

【Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。

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

App Runner

ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点

【コスト】

EC2より料金は割高。ただし、年々料金は下がってきている。

【拡張性】

デプロイの速度　遅め

理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる

理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。

割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き

【信頼性】

しかし、2021年 3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。

【エンジニアリング観点】

Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。

システム要件の確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチ AZ 構成を取る

CI/CD パイプラインを形成し、アプリリリースに対するアジリティを高める

各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい

2章まとめ、感想

3章

この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。

【運用設計】

モニタリングとは

システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる

【ロギング設計】

・cloud watch logs

他のAWS サービスとの連携も容易

サブスクリプションフィルターで特定文字列の抽出も容易

・Firelens

AWS以外のサービスやAWS外のSaaSと連携することも可能

Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる

Fluentdやfluent bitを選択できる

fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる

【セキュリティ設計】

・イメージに対するセキュリティ対策

　- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。

　- 方法

　　脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）

・提供元が不明なベースイメージの使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

　- オペレーションミスによる公開を防ぐことができる

【信頼性設計】

・マルチ AZ 構成

Fargateの場合、サービス内部のスケジューラが自動でマルチ AZ 構成を取るため、こちらで何かする必要はない。

・障害時切り離しと復旧

ALBと結びつけることで、障害が発生したタスクを自動で切り離す

・リタイアという状態

・システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

・サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

【パフォーマンス設計】

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする

既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する

・スケールアウト

スケールアウト時の注意

・Fargate上のECS タスク数の上限はデフォルトでリージョンあたり1000までであること。

・VPCのIPアドレスの割当量に気をつける

ECS タスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watch アラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECS タスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリング Permalink | 記事への反応(0) | 21:45

・チーズハンバーグ（牛肉）

・ラードで揚げたとんかつ

あたりは、ユダヤ教の「親と子を一緒に食べてはいけない」という教えに反するらしい。

最後のはちょっと違うかもだが。

ハラルとか仏教とかそれぞれ違ってめんどくさいから全部食わないのがいちばんだよ。

ID非公開さん
2016/9/1 15:50
6回答
ユダヤ教において「子ヤギの肉を、その母の乳で煮てはならない」という戒律がありますが、“親子”の組み合わせ料理は、ユダヤ教徒は厳禁で同じ親子の組み合わせ、親子丼やチーズバーガーすら厳
禁らしいです。

でも戒律は「子ヤギの肉を、その母の乳で煮てはならない」であって、あくまでも「子ヤギの肉」を「ヤギ乳で煮てはならない」であるから親子丼やチーズバーガーなら問題ないんじゃないでしょうかねぇ？どうも悪い方へ解釈してしまってるのですね。
宗教・1,114閲覧
1人が共感しています
ベストアンサー
cav********さん
2016/9/1 19:05
良い悪いはともかく、拡大解釈であることは確かです。

ユダヤ教では「肉と乳製品をいっしょにとること」を禁じています。チーズバーガーやクリームシチューに肉を入れることはもちろん、一回の食事で肉と乳製品をとることはできません。肉料理の食後のコーヒーにミルクを入れるなどもだめです。私がイスラエルを旅行した時、肉料理の後にデザートとしてアイスクリームが出ましたが、牛乳ではなく豆乳を使っているとのことでした。肉と乳製品を食べる間に、６時間だか８時間だか置かないとだめなのです。(胃の中で双方がいっしょにならないように。)もちろん、どこまで厳格に守るかは個人差があるようです。

親子丼は、卵であって乳製品ではないので大丈夫なのではないでしょうか。
質問者からのお礼コメント
まったくだな、鶏・卵白な親子丼、ヤギでないのに食いたくないのはとんでもない解釈！
お礼日時：2016/9/7 14:18
Yahoo!検索で調べてみよう
クリームシチュー肉チーズバーガー親子丼クリームシチュー肉料理
その他の回答（5件）
dol********さん
2016/9/2 8:10
違うよ。カシュルート（食物規定）では「肉」と「乳製品」を混ぜることが禁じられているんだよ。

で、卵も乳と同じように親鶏から出てきて、子を育てる成分を含むものだ。だから、中世ユダヤ人は卵の性質上、乳と同じだと考えた。ただし、まだ殻を形成していない段階ならば乳とは見なされない。ここは議論があって、絶対そうだというわけでもないよ。

いずれにせよ、卵の殻座の部分には血が混じっているので、その部分を取り除かねばコシェル（適正）にならない。

また、厳格な人は食後にコーヒーを飲むこともしない。うっかりコーヒーにミルクを入れて、胃の中で肉と乳が混ざることを防ぐためだ。

さらに、イスラエルのマクドナルドなんかは、ハンバーガーを売るカウンターと、アイスクリームを売るカウンターとが別々になっている。

あなたは「悪い方へ解釈」と言ってるが、それは「食物規定は悪いもの！」というキリスト教価値観の押し付けにすぎない。

こうした食文化全体として見れば、あなたが挙げた問題なんて取るに足りないことというか、むしろ「より安全な方へ」という解釈になっているんだよ。

なぜなら、神が与えた食物規定の真意は、人には分からない。だから、人がうっかり規定違反することがあるかもしれない。それゆえ、神が具体的に命じたことを範例として、食生活の一つ一つについて詳細に検討した結果なんだ。人の謙遜さの現れなんだよ。

Permalink | 記事への反応(1) | 19:25

2021-12-31

■anond:20211231112736

VDI 導入、コロナ禍におけるビデオ会議の課題と改善、

そして中長期の PC 環境の構想へ

リクルートにおける VDI の導入、運用、コロナ対応、そして今後の ICT 環境を紹介する連載。

今回は、VDI 導入を振り返り、中長期の PC 環境の構想をお伝えする。

石光直樹，リクルート（2021 年 05 月 24 日）

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 →目次に戻る

VDI 用のビデオ会議ソフトウェア導入による 2 つの課題

　以上をまとめますと、働き方は中長期的に「完全に場所を選ばない働き方」へと変わり、それに応じて PC 環

境は「クラウド＆マルチデバイス環境」になっていくでしょう。われわれも VDI の EOSL のタイミングで変わって

いかなければならず、将来に向けた第一歩として、次期 PC 環境は「VDI と FAT PC のマルチ環境」を実現する

ことにした、ということになります。

なお、コロナ禍において、われわれは現在の VDI 環境下でビデオ会議の改善を試みました。先述した VDI 用

のビデオ会議ソフトウェアの導入を検討し、一部導入したのです。その結果、ビデオ会議の音声と動画の品質が

極めて改善されることになったものの、2 つの課題が新たに見つかったのです。

1 つ目は、普通のビデオ会議ソフトウェアと VDI 用のソフトウェアとの間に機能差があった点です。この課題は

今後解消されるかもしれませんが、われわれが導入した段階では VDI 用のソフトウェアが機能面で劣っていました。

2 つ目は、導入／管理コストです。1 つのビデオ会議システムしか使っていない場合は問題ないかもしれません

が、複数使っていたり、今後新しいシステムの導入を考えようとしたりすると、ソフトウェアの導入、管理に都度

工数がかかってしまうという難点が明らかになりました。

　以上 2 点については、いま検討されている方のご参考になれば幸いです。次回は、リクルートがいままさに取り

組んでいる「VDI と FAT PC のマルチ環境」についてお話しします。

Permalink | 記事への反応(0) | 11:28

「シェル」を含む日記

自転車の制動機構の未来

LLBEANはまずフロントシングル化＋ホローテック化

LLBEANホローテック化

フロントシングル化したい

ドロハン化は

ステムはキル (quill) ステム

さびたバッシュガードが悲しい

今後の運用方針

旅行時は？？

ラスペネは強力

アサヒサイクルがお安い完組の車輪を売らなくなったら

サステナビリティだけを追求する自転車 (忘れよう)

前から後ろへ手順書を

番外編

Louis Garneaux (26inchx1.5 HE) 投資分 (for restoration)

もしくは折り畳み式のフレーム

折り畳み式における折り畳み式ハンドルというかフォークというかについて

XShifter

■タワマンのコンシェルジェに「床がきしんでるんで、キミに見に来て欲しいんだ」ってOK?

■ノートＰＣの中古は買うべきではない

■HHKBのよくある勘違い

矢印キーは使わない

何故矢印キーを使わないのか

持ち運び前提

複数持たない

足は出さない

■Macbook Proをクラムシェル で使ってると排熱で筐体が曲がって口がぱっかーん空いてバカみたい

■古塔つみがうらやましい

■社用のiPhoneの遺失届が来て3時間

■macOSはBSDではない話

MachとBSD

macOSはMachなのか

macOSとBSD

■[あとで読む]2022年1月はてブのあとで読むトップ30リスト

■本のまとめ

■本のまとめ

■ヴィーガンのチラ裏

■Macbook Proをクラムシェルで使ってると排熱で筐体が曲がって口がぱっかーん空いてバカみたい

■[あとで読む]2022年 1月はてブのあとで読むトップ30リスト