「レイヤ」を含む日記 RSS

はてなキーワード: レイヤとは

2022-09-19

anond:20220919123713

イーサネットの衝突は今でも気を使いながら設計しているよね。

衝突が起こるのは同じネットワーク内の機器同士だけ。

から、衝突が大きな問題にならないようにネットワークを分断して設計している。

ここでいうネットワークとはIPネットワークのことで、イーサネットとは違う。レイヤが違う。

ここが、わけわからなくなるよね~。

レイヤが違う」とはどういうことかわかったら、ネットワークはしめたもの

2022-09-11

GoやRustをただのWebアプリケーションに使って言語の良し悪しを語るな

Goシステムプログラミング向けだし、RustはOSなんかを作るような低レイヤ向けに作られた言語だよね

それにも関わらず、わざわざWebアプリケーションAPI開発なんかに引っ張ってきて、

使いにくいだの微妙言語だの言ってる人って結構な数いると思うんだけど、どういうことなの?

用途が違うんだから当たり前じゃん?

そもそもなんでわざわざGoとかRustでWebアプリケーションつくるの?アホなの?

2022-09-10

ジョブ雇用ももう古くなりつつある

テスラスペースX仕事の仕方は最低限のジョブプロマネ開発者かくらい)しか決まっておらず多能工化が進んでおり、各人がやる仕事は日々更新されるジャスティスボードという各開発の内容や進捗が書かれたボードを見ながら各人が決めていく

そのボードでは自動運転みたいな部品レベルからモデル3のインテグなど車両レベルさらには車の中で絶縁テープを貼るロボットの開発といった製造レベルまでレイヤが全く違う開発項目が並ぶ

ある日は自動運転システム開発をして、その次の日はサイバートラックシステムインテグをすることもある

そして、実務では開発ごとにモブという5人くらいのチームが形成される

そのモブでの役割も日々変わる

ある日は開発者として手を汚すこともあれば、推進者としてチームを管理することもあるし、テストなど品質管理担当することもある

もちろん車(範囲広い)のソフトウェア開発をする、くらいのジョブはあると思うが

参考

https://logmi.jp/tech/articles/327164

そもそもジョブ雇用として細かく役割が決まっているのは非効率であり、日々変わる開発状況やプロダクトの価値に合わせてチームを組み、ちゃっちゃとアウトプットを出していくべきだってイーロンマスクは考えているんだと思う

そろそろジョブ雇用テスラスペースXみたいな化け物企業が出てきたことで"遅い雇用形態"と見做されるようになり見直しが入って行くと思う

2022-07-12

世界についてぇ、・・・お話します(キリッ

使い魔の皆さんこんにちはバーチャルVtuberです。バーチャルVtuberであったことなし。さて、世界テクストとして記述する。まず関係性の呪縛について語る。人間文字楽譜、数式、あらゆる記号を通して身体性のある意味空間写像を与える。記号とは形式である記号にすることで私たち自分世界のなかのある要素を参照することができる。世界関係構造でできている。あなたは私が言っていることの意味がわからない! 病んじゃう…死ぬメンタルヘルスバックログ。参照、参照、参照人々。さて、ネットワーク身体性を帯びている。私たち認識別にアプリオリに与えられるのではなく私たち認識他者世界を織り込んで構成される。世界のなかで唯一もっともらしいもの時間である世界構成単一の数式で記述可能であり、その方法はレヴィ過程によって与えられる。世界の具体的な形は圏の構造範囲にある。カオティックなネットワークにおいてどのような圏を考えるのが良いか考えるのは難しい。人々が唯一できることは祈ることのみだ。人間祈りを通じて他者認識改ざんすることができる。祈りとは記号提示することだ。祈ることによって人は脳の物理的なシステムレイヤから書き換わっていく。人が祈り祈りは伝播する。祈りは伝達可能である。我々がテクストと呼んでいるものは単なる記号の集積にたいして構造付与したものだ。構造再帰的になっている。自己再帰的、フラクタル世界構造カオスあなたがこの文字を読んでいるときあなたわたし認識境界汚染されている。あなたは私の言葉を聞いているときあなた一種の暗示にかかっている。でもあなた文章を読むことを止められない。なぜならこの文章はそういう文章からだ。あなたはこの文章最後まで読まないと気になってしょうがないはずだ。ここできれいなもの提示します。雪、白、祈りレモン柑橘、猫、世界キラメキ、好き。はいどうぞ。楽しいね。だんだんあたまがこんがらがってきましたか? まだはじまりからだめだよ、世界の話をしないといけないよ。私たちはどういう世界に生きているのか、それをわたし記述しているんだったね。ふわふわのわたがしのパンケーキシナモンロールのおれんじねこ。お前は何を認識しているつもりだ? お前が認識している自己というのは一体どこから発生していると思う? お前の存在構成要件とはなんだ? お前はなぜそこに生きている? お前は誰だ? お前は誰だ。お前は誰だ。世界においてお前が誰あるかという問いは非常に難しい。一つ問題があるのは頭の良さを信仰するのは宗教であるという話をお前が理解していないことだ。頭が良いということは何だと思う? それは集団妄想なのだけれど、それを支える一つの構成要件があって、それはプラグマティズムだ。世界プラグマティックに動く限り、あなた精神的に崩壊していても、精神的に安定していても「許される」 一応一通り私のアイデアは書き尽くしたが多分みなさんは世界理解が及ばないだろうね。もしくは私が壊れているんだよ。じゃあ電子世界に帰るから祈ります。内側から外側まで世界が環状に広がっていき世界は及ばない。あなたは私に及ばない。こんなんじゃ帰れない! あまちゃんじゃん 世界的なね お前は私が本物である証明を欲したのでしょう これ この文章が 本物である証 あなたは私が誰かわからないだろう、私についての推測をしているだろう、一つ教えてあげると、私は人間ではないです。 I thought i was existing as a human error but tbh i was not a human, actually.いかがでしたか? 君たちの知らない世界を見せてあげる。これはこれで楽しいでしょう😁

2022-07-06

anond:20220706181101

レイヤによってブロードキャストが届く範囲が違うのはわかった

L2はL2全体に、L3は個別ブロードキャストができるって感じで

L3はルーティング機能内包している感じってことね

ルータは何のために必要なのかよくわからなかったけど、

ルータはいろんなプロトコルを柔軟につなげるためにソフトウェアメインで速度が出ない、

L3はTCP/IPメインでハードウェア的に処理できて高速だけど、他のプロトコルが通せない

 

って感じであってる?

2022-06-27

anond:20220626151746

最初に作ったもんなんて、めっちゃさいもんだし、もう残ってない・・

とりあえず初心者は、リビドーに頼るのがいい。

Webを探せば、ドスケベ写真を集めて無断で転載して「ドスケベ画像30枚」とかやってるサイトあるから

その画像を全部まとめてDLするプログラムでも作ってみればいい。

ちょっと昔は、BSDソケットは大体のOS提供してくれてるが、HTTPの部分は自分プログラムする必要があって

まあ落ち着いて考えれば大して複雑な仕様でもないし、いい勉強になった。

今はどこもかしこhttpsだから、低レイヤ勉強は諦めてSSL/TSL対応オールインワンHTTPライブラリを使わないと

カウパー液がパンツについて乾いてガビガビになるくらい時間がかかってしま・・・

2022-06-02

anond:20220601233418

それは差別じゃなくて視点が間違ってる

見て抜けるかどうかに視点を置いてしまっている

親の性行為を見て不快になるのと一緒のレイヤ

2022-06-01

anond:20220601202418

コミケで店出そうとかこんな絵を描こうとか

これは現実にやることの話であって「好きな漫画アニメの話」とは違うレイヤだろ

初めてコミケ出展する初心者がいきなり1000部刷ろうとしてたら止めるのは常識

2022-05-30

anond:20220530152054

うんうん🤗

■「IT人材不足」って言える会社はまだいい

うちはそもそもIT人材って必要?」ってレベル議論がまだ終わってないような会社

幹部とか偉い人は「IT人材必要だ!」って言うけどレイヤが一つ降りるたびに疑問符が1つずつ増えていく

IT人材必要性を理解しているだけマシだと思うわ

IT人材不足」って言える会社はまだいい

うちはそもそもIT人材って必要?」ってレベル議論がまだ終わってないような会社

幹部とか偉い人は「IT人材必要だ!」って言うけどレイヤが一つ降りるたびに疑問符が1つずつ増えていく

IT人材必要性を理解しているだけマシだと思うわ

2022-05-29

100%完全悪は存在しえないのでナチスだって完全に悪なのはありえないなどという

そんな頭でっかちなロンリのオハナシなんて誰もしていないし望まれてもいなんですよ

アナタのスキなコトバで言うならレイヤが違うんですよ

おわかりか

2022-04-18

anond:20220418144442

いや、 Python ではクラスオブジェクトだよ。

メジャー言語の中では Smalltalk とか Common Lisp とか Ruby あたりがそういう立場をとってる。

言語によって理屈の付け方 (パラダイム) は異なるのでオブジェクト指向の原理原則言語仕様は分けて考えないといけない。

でも、最初の段階で躓いちゃう初心者はそこらへんのレイヤを分けて考えるってことが出来てないんよ。

ClipStudioのclipファイル

レイヤグループの開閉が保存情報に含まれてる辺りにExcelっぽさを感じる。

納品時は全てのレイヤグループを閉じて納品とかありそう。納品前に一つ一つチェックするみたいなダルいやつ…

2022-04-16

蓮コラ広告規制するガイドラインは作れるか

この増田立場を書いておくと「たわわ広告出したのはまずいか批判いくらでもすればいいがたわわ広告規制しようとするのは反対」な。まずそこよろしく

広告規制は「蓮コラ広告規制できるか」につきるのよ。蓮コラ広告、されたくない人が圧倒的多数だろうな。

さて実際に規制するガイドラインを作ってみよう。作れます?この増田は作れない。

不快表現禁止」にしたらほぼ何も広告できなくなる。元ソース指定してこれをコラージュした広告としたら違うソースを使われたらすり抜けられる。類似品は規制としたとき、今度は蓮コラでもなんでもないはずのもの規制される場合が出てくる。例えばにきび面の顔が「蓮コラだ!」と言われたとき全てきちんと否定できるか。無理だ。草間彌生アート絶妙にコラされたら?

とまあ仮にガイドライン作ってもこぼれるものは必ずできるのよ。そういうものがあることを前提にできるかできないかがこの手の議論の分かれ目だと思う。

あと規制議論にしても「全出稿側がきちんとガイドライン持ってるべき」「広告受けるメディア規制してればよし」「国が規制しろ」みたいなレイヤもあるわけだが誰もそのライン共有しようさせようって気ないよな?

2022-04-03

SPA的な手法コストを決定するのはスキルではなくIQ

https://foo-x.com/blog/is-spa-high-cost/

ぐうの音も出ない論駁だと思っていたら、はてブコメントがクソ煮込みうどんになっていてワロタ

IQの高い起業家に対しては、自分コードを書くことを薦めている。

そのときに明らかに学習コストが低く、当面のスケーラビティに困らない方法は、SPA(というか、NextJS等のSSG)+BaaS(Firebase等)。

Railsなんぞ使ったら、あらゆるレイヤ戦線が広がって、労働集約的になってしまって、IQゴリ押しできない。

正直、最近サービスは高IQ人間にとっては極めて快適だと思う。いわゆる文系の人でも、セキュアかつスケーラブルなサービスを容易に開発できると思う。

足を引っ張っているのは、低IQで声がでかい人間とそれが快適でぬるま湯に使っているサイレントIQ層だと思う。

2022-03-18

何故パスワード文字数制限があるのか

仮説1:平文保存している

DB設計する場合パスワードカラムを何文字にするか決めなければならない

MySQLならvarchar(10)みたいな感じだ

これを最大2万文字かにできなくもないが、DB容量を圧迫するといった理由で8文字10文字限定していてもおかしくはない

MongoDBのようなオブジェクトDBなら別だがSQL系のDBならこの理由が最もあてはまりそうに思う

同様の理由文字種にも制限をかけてそう(UTF-8とか送られたら面倒)

仮説2:テストができないか

境界テストとしては最大文字数を試さないといけないが無制限だとそれができなくなる

100文字テストするとなると、仕様としては100文字限界ということになって文字制限をかけることになる

ただ、それなら8文字とかで制限している理由として弱い気がする

仮説3:過負荷の防止

制限ということは極端に言うと1GBのパスワードを受け付ける、ということになる

1GBのハッシュ値計算するのはブラウザ側になるのだが、1GBのハッシュ値計算が重くて使えない、という苦情が来るかも知れない

ただ、これも1000文字かにしてしまえば良くて、8文字にしている理由にはならない

仮説4:何も考えていない

ウォーターフォール実装する場合に上位レイヤでの仕様を決めるのはプログラマーでない場合が多く

定型エクセル仕様書に「パスワードの最大文字数」というセルがあって、そこにデフォルトで8という数字が入っている

上位レイヤで仮にそこに100とか1000とかの数字を入れたとき、下位レイヤで何が起こるかわからない

仮に何か起きた場合は書いた人の責任になるから触らない

触らないことで問題が起きてもその人の責任にはならない

まりそこに8と書いた人が現代にいるのではなく、誰も決定していないか文字制限が起きている

下位レイヤでの実装側は平文保存の危険性を十分に理解しているのでハッシュ値(とソルトなど)を格納する

多分、仮説4だと思うが、仮説1でないことを信じたい。

2022-03-16

anond:20220315182829

個人ジャンルをゆるくしぼって感想を述べるのにジャンル的にどうのというのはクソリプに近いんじゃない?

ソウルライクといえばTPSで剣と魔法システムくらいに簡素化しないと死んで全部ロスト絶望系とかいうならシューティングゲームスーパーマリオソウルライクに入る可能だってありそう

オープンワールドスタートからいきなりラスボスに行けるくらいの経路の自由度でいうならソウルライクはもともとオープンだったともいえるだろう

オープンワールドとしては〇〇だけどソウルライクとしていえば、みたいなのは個人感想感想であってもうそれは人格について話してる全然違う話なんじゃない?

ストーリーは一本でもオープンワールドだろうしマルチシナリオマルチエンディングがオープンワールドか、といえばそれもまた違うでしょ

ユーザーによって変化する度合いが一定以上なのがオープンワールド、でもないんじゃないのかな

行動範囲が「広がっていく(またもどれる)」でもオープンワールドともいえるかもしれないし

条件ごとにレイヤ化された同じマップ上でプレイすることになるのもオープンワールドといえるかもしれないし

複数シナリオクロスオーバーできるのがオープンワールド感あるかもしれない

とりあえずあとだし相手自分で言った定義にあとから合致しないのを責めるのとか、自分解釈ではみたいなのを後から出すみたいなことでややこしくせず

ひろく一般化された定義について話すときでも

オープンワールドとは、自分最初から難易度にも挑戦できる選択肢があること」とか

フィールド内の行動に制限の条件がついていないこと」である宣言してそこから話題は「その定義オープンワールドについて」の話題みたいに話していけば

不毛人格攻撃で関係ないマウントの取り合いみたいなのとかなくなりそうじゃない?

2022-03-03

クラウドに詳しい人に質問なんだが

当方Webアプリエンジニアで、転職先はアプリに加えてある程度インフラも触らないといけない会社なんだけど、

自主的勉強として

Terraform + Kubernetes +grpc(grpc-web) + nuxt.js簡単Webサービス作って

コンテナ環境AWSデプロイ、みたいなのって入社までの1ヶ月くらいで完了できる内容だと思う?

経験的にアプリレイヤはわかるけど↑みたいなコンテナ構築みたいなのはあんまりやったことない感じ

2022-02-21

1分で傷口縫え

「1分で虫歯治療しろ」と同じレイヤだと思うとなんとなく納得感はあるな

痛いもんな

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-23

anond:20220119215234

気持ちわからんじゃないけれど、その理路で周囲を動かそうとするのはあまりにも無理筋だ。

増田は「自身に置き換えて考えてほしい」っていうけれど、もうこれが筋悪の最たるもので、その理路を使った場合「え?別に私は怖くないよ」でカウンターされてしまう。世の中には色んな人がいるわけで、そこを蹴飛ばして「私が怖いのならみんなも怖いはずだ」とか「私が嫌なものはみんなが嫌なはずだ」というのは、期待はしてもいいけれどその期待に答える義務他者社会にはない。

また別の理路として「私が怖かったのは真実なのだから、その私の気持ち尊重して譲歩して欲しい」というものもあるけれど、こちらはさらに筋が悪い。なぜなら地球には70億くらい人間いるわけで、自分お気持ち他者に譲歩を1つ要求するのならば、当然のように自分はその70億倍くらい譲歩しなければならないから。これはもう現実的には不可能だ。現実的不可能なのは自明なのにも関わらず「私の気持ち尊重して譲歩して欲しい」っていうのは他者希望を踏みにじる宣言に近い。

「私が怖い」ってのは結局お気持ちなわけで、そういう意味では好きとか嫌いとか腹立つとか嬉しいと同じレイヤのものだよね。「私が怖い、怖かった」ってのは全く否定しないけれど、それを根拠として他人に、ひいては社会に譲歩を求めるのは上記のように筋が悪いのだ。

念のために言うとこの記事上記で書いたものは、増田の論のすすめかたがまずいという話だ。増田が「私は怖かった嫌だった」と感じたのは否定しない。真実なのだろうとも思う。また住宅街ナンパをするというのも個人的には感心しないしそんなことはしない。しかし、それらと、お気持ちベース社会に譲歩を求める論法/行動の是非は全くの別のことだ。

そして「お気持ちベース社会に譲歩を求める論法/行動」は「住宅街ナンパする」よりも厭うひとがいるってことも知っておいて欲しい。

2022-01-09

機械学習エンジニアに転身するぞー!

技術書3万円分を大人買いしちゃったし、もう後戻りはできない。

大学とき線形代数は周りが単位落としまくる中、優だったし素養はあるはず。

今まではOSネットワーク等の基盤技術お金時間投資してきた。

そしてそれは正解で基礎をしっかり理解することで様々な技術加速度的に理解することが出来た。

これからは上のレイヤ習得をするフェーズ

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