「ノード」を含む日記 RSS

はてなキーワード: ノードとは

2022-09-10

最近DavinciResolve界隈が中々楽しくなっている

動画編集ソフトダビンチは基本的に実写動画の加工がメインだ。どちらかというと映画などで使われることが多くて、日本のようなアニメーションを多用する切り貼り動画にはあんまり向いていない。

その上に元々がカラーグラデーションの調整に特化したソフトということから、AdobePremireとかの本格的な動画編集ソフトより使い勝手機能は劣っている。しかも珍しくノード基準にしているので、レイヤーで考える普通動画編集ソフトよりとっつきにくい。海外産ということもあってQ&Aもあまりなくて日本ローカライズ中途半端ってところから日本の利用率ってあんまりない。

無料な高機能ソフトなのでチャレンジした人もいるはずだけど、ちょっとしたVLOG切り貼りならともかく、ゆっくり動画かに全然使えなかった。なにせ矢印や四角形を置くこと一つが手間を要すんだもの

特にゆっくりキャラ口パクさせたり自在に動かすってのはダビンチには向いていない。

というのは1年位前までで、最近になってその考えがちょっとだけ変わってきた。

VoiceVoxやゆっくりボイスを簡易的に連携させたり、口パクキャラの動きをつけたりといったことが楽になるツールが開発されているからだ。最初こそ補助的に使えるかなってものだったが、もはや立ち絵音声合成ソフトがあれば十分に使えるレベルにまでなっている。YMM4の使い勝手にはあと1年程度で追いつくんじゃないかな。

そのころにはYoutube解説動画関係が軒並み下火になっているかもしれないが、なんにせよ日本語でダビンチのツールが開発中ってところにオラワクワクすんぞ。

2022-07-06

anond:20220705205405

ブロックチェーンみたいなもんだよね

唯一違うのはすべてのノードが頭おかしいって点だけ

2022-06-30

おすすめ漫画増田ブコメ返信など

元増田に思い出した既読の好み漫画追記しました

https://anond.hatelabo.jp/20220629082354

記事自分の読んだ好みの漫画一覧を作ったら便利だなというのと、同好の士のためにリストウェブに置いておきたいというつもりで書きました

リストは、上からこの手のだったらまずこれ!という有名作

コミティア系(アフタ系ともいう)

女性向け漫画少女漫画

4コマきらら

作家短編

の順のつもりにしてます

リストカテゴライズしたりおすすめしてもらった物も追加して少しずつ充実させていきたいと思います

以下ブコメ返信

Helfardアフタヌーン出身の作者をググって古い作品を片っ端から読めば良さそう。

雑誌アフタヌーンハルタ青騎士ネムキアックスビーム、イタンあたり鉄板ですよね〜

ウェブ系だとトーチ、電脳マヴォかな

モアイ新人賞ジャンプ読み切りも良さげ

けど私はcomicoで埋もれてるアフタヌーンか?いっそアックスか?みたいなのを知ってたら教えていただきたい訳でしてまして……

ちなcomicoは爪先の宇宙推し

ET777むしろ好みじゃないのも読みなよ

読んでる〜!ていうか地雷(グロホラー)以外はなんでも読む

好きな漫画全部だと本当に書ききれないので特に知りたいコミティア系に絞った

ジャンプ育ち現役WJ読者、漫画描くようになってからコミティア系(ブクマで言うアフタ系)が好きで描きたいのに気づいてひたすら探して読む、後は集英社白泉社少女漫画少々、スクエニ系少々

なので女性向け漫画が弱いかなー漫画ランキングでも女性部門は知らないのが多いし

子供の時から一貫する中心的好みだとコミティア系になるだけで浅く広く色々好き

この辺のジャンルなんていうんだろうね、自分すこしふしぎ系、いい意味雰囲気漫画って呼んでて最近コミティア系という言葉を知ったのでそう呼んでる

ブコメだとアフタヌーン系呼びが多いね

コミティア系以外だとハンター、ワートリの能力バトル知略バトル

キャラクター中心の日常ギャグ

コミティア系とかぶるけど重めのストーリーSFファンタジーあたりが好き

まあおおむね学園ラブコメよりSFファンタジーが好きになるタイプオタク……

ラブコメも読むけど想定読者じゃないなって気持ちにはなる

zeromoon0 自分で調べなさい。それかそういうのはTwitterでやりなさいな。

yas-mal スクロールに疲れて、「これだけ知ってたら、自分で探せるやろー!」という気持ちになった。/池辺葵作品が2つ入ってるけど、連載中の「ブランチライン」も最高だぞ。/幾花にいろあんじゅう」とかどうだろう?

 ネットでも探しまくるけどこっちでもやっておこうかなみたいな

ブコメおすすめでも知ってる物と、当てはまるけど好みじゃないのと、掘り出し物がでるのは一緒だろうし

検索だと出にくい物が個人シナプスネットワーク検索で出る可能性にかけたいなと

ブランチライン」「あんじゅう」知らなかった、ありがとう

inatax知ってるか知らないか優先順位をつけられてもこっちお前が何を知ってるか知らないんだよ / それ町は好きそう。この間連載が始まったばっかりだけどルリドラゴンも好きそう

 全くだ!知ってる物も全部書こうと思ったけど無理だったから知らん漫画リストから予想して知らなそうな漫画に読み替えて欲しい

それ町最初の方読んだ!ルリドラゴンはおおむね好みだが刺さるにはもう少し……

シリアス展開伏線も多いし先が楽しみではあります

NOV1975こっち系はどんなに似てても一筋違うと趣味に合わないってすぐなりそう。頑張って読むしかない感じはする

 それ!comicoの例だと遠い日には青くの方が要素当てはまってるけど個人的に刺さるのは爪先の宇宙みたいなのよくある

からリストはこのタイプって伝えるのを優先して、刺さらなかったのも含めて例としてまとめて上げた

……のだけど数上げてるうちに自分でもこれは範囲に入るのか?となってきてしまった

aliliputジャンケットバンク読んでください!ジャンプラで無料で読めます!何なら5巻まで買ってあげるから!!

 そこは概念ドロボウくるとこでは!?

エンバンメイズ好きだったのでジャンケットバンク読むつもりです

概念ドロボウは一昨日一話読んで買うか検討中

miruna晴れ晴れ日和/古いのだとビブリオテーク・リヴ

 さすがmirunaさん!知らないのだった

ありがとう

chibatp9 多すぎて絞れないか無視してSF妖怪終末方面の俺の好きな漫画を勧めるぜ。『怪異いかさま博覧亭』『篠崎くんのメンテ事情』『終末ツーリング』『アップルパラダイス』『世界の終わりに柴犬と』文字数

 ありがとう!全部知らないし面白そう!

ブログ文字数気にせず書いてもらいたいブクマカだ!

kukky 佐藤史生過去Kindleで読めるから全部読め!竜が出てくる作品でもファンタジーではなくSF寄りだけど。

 知らなかった!ありがとう!今から買ってくる!

otoan52 廃墟好きそう。ハロープラネット絶対好きな人だ。

 はい!大好きです!ハロプラボカロとささくれさんにハマり今年初マジミラ参加の予定です

kerokimu シャドーハウス海獣の子供、The Mark of Watzel などがハマりそうと感じました!ていうかほーほけが入ってる!増田好き!/かげきしょうじょは読んだ?京極堂シリーズコミカライズおすすめなんですけどどうですか??

 ほーほけいいですよね!かげきしょうじょ既読です!

昨日TLで京極堂の学パロ(学パロではない)おすすめって話でて今日Kindle遡ってたら中禅寺先生買ってました!思い出せてよかった、ありがとう

おすすめも読んでみます

 多数おすすめ

夏目友人帳

ヨコハマ買い出し紀行

ハクメイとミコチ

・ニセモノ協会

星屑ニーナ

知ってるけど未読です!かなり好みの要素が多そうな雰囲気がしているので楽しみ!

・葬送のフリーレン

一話試し読みでチョットチガッタ……になったので迷い中

魔法使いの嫁

これも一巻無料読んで迷い中

メイドインアビス

一巻だけ読んでry

好み要素も多そうだけど地雷要素も多そうで躊躇い中

教えて欲しいんですがグロすごいってよく言われているけど血が出る外傷があるグロですかね?

精神リョナは耐性あるけど血が出るリョナはまじで無理、人の怪我した話聞くだけでグロッキーになるぐらい無理

 既読

図書館で読んだりすごい昔に読んだり無料公開で読んだりで忘れていた物と

これは範囲内か?と迷って入れなかった物

書いてくれたのにすまん!

宝石の国

大好きです!でもリストで伝えたかった種類とは違うタイプじゃないか!?

・外天廊

皮肉冷笑の要素が強いと苦手……それ町は好きの範囲

ニッケルデオン

同上の理由道満晴明短編集も苦手……

・尖り帽子アトリエ

言われてみれば要素だいぶ一致してますね……

自分の中では縦軸ストーリーいからそれがなくて魔法日常物だったら入るカウントだった

Landreaall

これも言われてみれば……ゼロサムLandreaallボクラノキセキ鉄板すよね

 知らなかった物

この為に書いた!ありがとう!大感謝

・まいんどりーむ(藤野もやむ作品)

しょうもないのうりょく

ニーナさんの魔法生活

魔法使いの印刷

・コーセルテルの竜術士

・船を建てる

最果てのパラディン

宇宙賃貸サルガッ荘

孤食ロボット

・うちのクラス女子ヤバい

・広がる地図とホウキ

マホロミ

・つるまき町夏時間

リュウマのガゴウ

任侠転生

群青学舎

・とくにある日々

・そのへんのアクタ

マーガレットとご主人の底抜け珍道中

・水の森綺譚

・ヨツコト

バカ兄弟

・私を月まで連れてって!

ラッキーちゃんの新しい仕事

・きみと世界の終りを訪ねて

エルフ狩猟士のアイテム工房

北欧貴族猛禽妻の雪国狩り暮らし

マザー(江戸川治)

・Lv1魔王ワンルーム勇者

・令和のダラさん

・狼には気をつけて

なりひらばし電器商店

・桃と犬と海

グランローヴァ

辺境警備シリーズ

ねこねこファンタジア

・前略 雲の上より

・半助食物帳

ぼっち博士ロボット少女絶望ユートピア

・昴とスーさん

緋色椅子

・IYA Death

オーロラノード

・星旅少年

・TUKIKAGEカフェ

・砂の下の夢

ゆうやトリップ

三千世界を弔って

夢想のまち

アフター0

大丈夫倶楽部

遺跡のある大陸

コーヒーもう一杯

・俺と彼女先生の話

・極彩の家

蒼天のソウラ

幻想グルメ

・エニデビィ

・妹は猫世界八番目の不思議

快楽ヒストリエ

異世界トイレで大をする

マップス

ヤコポコ

・さめない街の喫茶店

ヘテロゲニアリンギティ

アンナコムネナ

・午後3時の魔法

夏の前日

官能先生

ゆめのかよいじ(旧版)

・空の色に似ている

少女ネム

宇宙家族カールビンソン

・終末の惑星

全部触れられなくてすみません

トラバと知ってる未読漫画漫画以外のおすすめも別途返信しようと思ってます今日寝る時間になったのでまた後日編集します!

2022-06-27

anond:20220626151746

ファイナルファンタジーガンビットマリオメーカーノードン、iOSショートカットExcelセル内の関数技術者ではないそこらの社員でも1〜2日でツール作れるようになるノーコード、などなど。プログラミング要素は広まって敷居が低くなり続けた結果、いつの間にか目にしてたり変更してたりお子様の遊びだったりする程度のものに。人目に晒そうとするような特別感はプログラミング部分にはもはや無いと思う。

2022-03-23

経済政策って、もっと制御システムっぽく検証出来ないものなのか?

トリクルダウンが効く/効かない、時代背景が違う、国が違うとか、経済政策に関して前提が合っているのかがわかりにくい。

計算機が発達した現代で、もっと制御システムっぽく組み上げ、色んなノードを見て、政策が合うのかどうかなど、検証出来ないものなのだろうか。

2022-03-04

このままロシアが弱体化すると、どうなるのだろう

欧米ロシアに対する制裁が続いてる。

どこまでロシアを弱体化させた方がいいのか。

今のウクライナ侵攻をロシアが辞めるまで、というのはわかりやすい。

プーチンが降りるまで、というのもシナリオの1つだろう。

それだけで済むだろうか?


「またいつ繰り返すかわからいかロシア解体してしまえばいい、ノードストリーム2がつながっている土地欧州に組み込んでしまえば丸く収まる」

という誘惑はないだろうか。

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

anond:20220119224450

情報ノード

組み合わせ=パーセプトロン

外部データ教師データ

適応モデル適合

全然わからんぞ。「数学的」と言ったのは、どこからどこへの写像かとか、どういう量の最小値として解が与えられるかとか、そういうことだぞ。

例えば「ノード」ってなに?「モデル適合」とやらをする前と後でどういう量がどう変化するの?

anond:20220119181528

情報ノード

組み合わせ=パーセプトロン

外部データ教師データ

適応モデル適合

知ってそうなんで、不足や誤りあったら補ってくれ

2022-01-10

スパコンの中のソフトウェアを開発している人にお時間をいただいて色々お話を伺ったのだけど、非常に面白かった。ある程度組み込みっぽい泥臭い運用環境なんだろうなとは思ってたけど、思った以上に凄く頑張ってた。また、閉じられた世界いつまでもいられないことも知った。思ったよりOSSへの依存度が高いことを知った。ノードスペックはかつての覇者Summitなどと比較すると華々しい報道の裏で実は致命的にポンコツなところがあることも知った。

2021-11-02

わかるー

https://twitter.com/fujiwara/status/1455331866630778883

国産クラウド云々の話、IaaS的に使うならどこでもいいと思うんだけど、AWS最初にS3とSQSから始まってEC2にはしばらくエフェメラストレージしかなかった、つまりデータ永続化マネージドに任せてコンピューティングノード使い捨てろという思想最初から徹底していたのを思うと

国産のはどうしても、EC2で全部やる的な使い方に寄ってる気がして、スケールに対する思想の違いを感じるんだよなあ

飲んでいて酔っ払うとS3はほんとすごくて、S3が盤石だから他のが成り立ってる部分がある、EC2EBS最初じゃないところが凄い、って力説しがち。いや、最近人と飲んでないけど

https://twitter.com/tagomoris/status/1455428553634312193

超わかる、国産クラウド使えっていう人はとりあえずS3とSQS作れるか真面目に考えてから言ってほしい

2021-10-11

エンベデッドスペシャリスト2021/10/10新橋TKP

去年は午後1が数点足りず不合格問題文に相槌うってメモしてたら時間なくなりました。

リトライ。今回はメモや書込みは最小限に、淡々と読み進める!午後1も5分程度余るようにできました。

----

午後1・・・・設問2→1の順で解いた。良かったと思う。

■問1:ペット医療点滴のシリンジポンプ(45min)

設問1

(1)準備中、設定中、設定可

(2)0.5mm

(3)144回転 128pps

設問2

(1)a:キー判定  b:設定終了キーの押下★         (★…ちょうどの単語がなかった)

(2)c:シリンID、点滴流量

(3)薬剤が詰まり圧力センサの出力値が基準値を超えた

設問3

(1)d:設定開始★  e:設定中★  f:準備  g:準備中  (★…設定終了と設定完了かも)

(2)設定項目に不足があった場合✕ 

   (✕設定完了後にリーダをSポンプ接続したとき、一括登録した時、など迷ったが分からない)

■問2:DXレストラン(40min)

設問1

(1)0.38ms

(2)料理人が品切れ情報登録する前に利用者が注文情報送信したとき

設問2

(1)入店清算キッチン

(2)a:注文履歴情報 b:キャンセル対象の注文情報 c:指示タスク d:片付け指示 e:空席管理情報の該当テーブル

(3)全テーブルタスクに品切れ情報送信する

設問3

(1)料理がロボに格納され、かつ着座人数が1人以上であるとき

(2)g:注文履歴情報の該当する注文を配膳済みに更新する

(3)h:該当するテーブルタスクに通知する

----

午後2(120min

■問2:工場生産ライン可視化

設問1

(1)出力ノード    (★ふつう工程かも。迷った。)

(2)a:SDカードフラッシュメモリモデルを読み出し、作成日時を比較し新しいモデルRAMに展開する

 b:次回からフラッシュメモリだけで起動できるため (全然からない。SDカードは他工場でも使うのかなと。)

(3)圧縮行程の工程生産能力:2222個/h

  ライン生産能力:1667個/h

  工程間滞留量の最大値:600個  (概念全然からない。。)

設問2

(1)a:ドライバ識別IDドライバ用の個別データ  b:センサ識別ID

(2)a:読み込むべきモデム及びドライバが、SDカードにある

  b:読み込むべきモデム及びドライバが、フラッシュメモリにある

   (5文字差がSDFMの差だとすると同文言の答えだと推測)

   (「読み込むべき」が無いと「準備完了(条件1,2とも偽)」が説明できない)

(3)(a)d:電流センサ e:産出センサ f:投入センサ

  (b)g:投入量通知 h:中断 i:再開

  (c)工程1。工程2から工程1に投入量通知が送られているから。

  (d)工程異常、ライン異常

設問3

(1)a:152byte増

 (計算: ①サーバ接続情報(64)が増える、

     ②工場ID(4)がS工場の圧造工程と転造工程の2工程分増える、

     ③さらにT工場熱処理工程とU工場表面処理工程工程情報が増える。

      これは他工場工程なので投入センサ情報/産出センサ情報/設備数/設備情報

      不要から工程名(32)+工場ID(4)+【a】識別ID(4)★だけで良い。

  よって、①64、②4*2工程=8、③(32+4+4)*2工程=80 を合計して152byte。)

 (★が明言が無く加算していいのか謎。除くと144。そもそも工場工程も加算で良い?)

  b:工程間滞留量

  c:工程生産量と同値が表示される

(2) j:工程情報通知

  k:"投入量通知"を受信した場合   (★時間なかった。テキトウ。)

 l:モデルの"サーバへの接続情報"の先頭バイトが0

----

2021-10-05

anond:20211005055655

いや何いってんの?

Apple中国ファブが磨いてきた枯れた技術お墨付きを与えるようなモノづくりをしているだけ。先端を追わずに、いいとこ取りしていく狡猾なスタイルだよ。そのくせものすごい精度を求めてくる、生産者としては厄介企業

技術的なイノベーションは常に中国で起きている。

例えば最近で言うと、シリコン酸素ノード電池実用レベルにもっていき製品化したのも中華メーカーだ。これも現在のものを置換えていくだろう。

画面内指紋認証技術もたくさんの機種に搭載されてきた中で着々と世代が進んで高精度化している。

画面内インカメラについても、去年夏、実用化されたZTE Axon 20 5G(≒Rakuten BIG)では酷評が多かったが、最新の第3世代になってくるとXiaomiOppoにも今夏の採用機種がでるほど品質面の問題がなくなってきたという事情がある。

2021-08-22

彼女元カレ

彼女が泣いてクスリは止めて欲しいと懇願した時、

ノードラッグノーライフと言い切ったらしい。

増田くんは真面目だから変な心配しなくていいからうれしいと言ってた。

でもそうかな?

僕は元カレちょっと男らしいなと思うし、

真面目なのはしろ元カレのほうじゃないのかな?と思った。

2021-07-02

anond:20210701235419

ん? 親が消えても子ノード独立存在するからその下に孫ノードがつけられるという話ではなく?

子が親になるというか

2021-07-01

anond:20210701234600

https://anond.hatelabo.jp/20210701213344

気になったら見てみてNE


おお、更新された。

こういう仕様

エントリとそのページのHTMLデータだが紐づいてて

ノードや子ノード更新されるわけじゃないんだな

2021-06-20

anond:20210620162352

ノードを遡ってみたら他の人にも言われてた

怖い

2021-06-18

anond:20210618184327

pop(i)の計算量がO(n)であることを言いたいだけなので、for文を使わないメリットとか考えていません。

また、nodesをスタックのように用い、do somethingの中でnodesの末尾にノードを追加するようなことは、普通にあると思います

その場合、get_node_list()で取得したnodesの先頭または末尾から順番に処理されるとは限りません。

anond:20210618170112

ではi番目の要素へのアクセスは、要素数を持っておいて、近い方から行うのですか?

それとも、インデックスノードポインタ対応付けを木などに格納しておくのでしょうか?

anond:20210618164927

ポインタが末尾を指しているなら、先頭のノードに到達するにはn回リンクをたどらなければいけないよね?

anond:20210617075257

アルゴリズムいらないって言ってる奴いるけど正気か。

そういう奴は、これのどっちが正しいかみたいなことをいちいち個別に覚えるのか……。

nodes: list['Node'] = get_node_list()
while(nodes):
    n: 'Node' = nodes.pop() # 末尾のノードから処理
    # do something
nodes: list['Node'] = get_node_list()
while(nodes):
    n: 'Node' = nodes.pop(0) # 先頭のノードから処理
    # do something
追記

型ヒントをつけろと書いてあったので付けました。

コメント//から#にした。完全にミスった。指摘サンクス

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