  |
はてなキーワード: 自動とは
去年の夏に家を建てた。
12月の電気代が安かったので、あまり電気代を気にせず生活してたら1月使用分の電気代が５万近くになりそうだった。
一番の元凶。２４℃設定、風速強めで家にいる間ずっとつけてた。
とりあえず寝るときには切って、朝５時からタイマーでつけるように変更。
２３℃は子供が半そで、俺がロンT、妻がスエットでいられるぐらい。
サーキュレーターはスマートプラグでエアコンに合わせたタイマー設定済み。
あと、１階に２台エアコンがあるけど、部屋が温まったら、１台だけで動かすようにした。部屋が隣同士なのでほとんど効果は変わらなかった。
リンナイ製は４時間後しか設定できないので、夜９時以降にしかスイッチを押せないのが難点。
朝しか使っていないので、スマートプラグで朝５時５０分に沸かして、家を出る８時くらいには自動で切れるようにした。
深夜電力時間が５時間しかないので、お湯を作り切れていない疑惑がある。
３人目の風呂ぐらいでお湯を作り始める。
外気温によってだいぶ効率が変わるらしいので、冷えそうな夜は昼間のうちにスマホでお湯を作るようにした。
冷える夜は２４時間換気を部分的に切ってみたが、対して電気代が浮かない代わりにCo2濃度が激増したので、それはやめた。
なんとか４万位にはなりそう。
俺はシャイニー薊の沼ダイエットをするために自分用の炊飯器を買った子供部屋おじさんだ。
初めてマイ炊飯器を手に入れていろいろやってみたが”炊飯”を超越した有能っぷりに驚いている。
まず有能なのはごはん以外の料理も作れること。煮物やスープだって作れる。
それから全自動なこと。ボタンさえ押せば火の元を用心せずに自動でやってくれる。これで長時間調理だって楽々。
ここまでなら電気鍋でもよいが、なんと炊飯器は保温までしてくれる。温かい飯がいつでも食べられるという人類の夢を実現している。
野菜を適当に切って、調味料と水を入れて、スイッチを入れて一晩保温すれば美味しいポトフがいつでも食える。最強すぎるだろ。
しかも一升炊きのデカさで1万円ちょい。アイリスオーヤマには頭が上がらん。
欠点として強いていうならば窯を洗うのが面倒くさいことぐらいだ。お粥とかを作るとベタベタになる。
大阪市在住で20代、一人暮らしをしており、慢性的な体調不良（肉体的、精神的）があり、生活保護を利用している
症例がほとんどない病気の疑いがあり、継続して微熱・アレルギー様症状・筋肉痛・倦怠感・気力の低下がある
症状はコロナ副反応、慢性疲労症候群、LOH症候群などに類似している
二回目の副反応で三日ほど、発熱・倦怠感があり、腕を上げたり、寝返りを打つのが辛いモデルナアームも出ていた
医療扶助があるが生活が厳しく、診察費がかかる場所に行くのは難しい
また、自身から二次感染を発生させるリスク、自身がコロナに感染するリスクを考え
できるだけ公共交通機関を利用せず、無料で診断が受けられる病院を探した
電車移動、自宅で少し話をする
マスク、手洗い、換気はしていた
その後は現在に至るまで一度も外出をしていない
腹痛は良くあるので少し様子を見ることにした
消化器症状が継続していたので、かかりつけ医にて診察を受けたいと伝える
コロナの可能性があるのでまず、コロナの診療を受ける様にと言われる
断続的に数回電話をかけるが繋がらない
その後、#7119、病院に連絡後を含め計七回電話をかけ、一度繋がったが自動音声で混み合っているので後ほどおかけ直しくださいと切断される
#7119
二箇所が近かったので連絡
繋がらない
有料の場所を二箇所案内される
風邪などの症状があり、かつ保健所から医療機関に紹介された場合に限られると案内される
厚労省のページにあり、excelとpdfで見ることができますと案内される
昨日同様、合計九回、断続的に電話をかけたが、一度も繋がらなかった
咳、発熱、消化器症状の（程度を問わない）いずれかの症状がある場合は無料で検査を受けられる対象ではないと案内される
つまり、何の症状も出ていない健康体でないと対象ではないということか？と聞くとその通りですと案内される
慢性的な体調不良が継続している人間が、医療崩壊が進行している中で消化器症状を発症させた場合
コロナの可能性があるため、一般の病院にかかるのを控える様に言われる
複数の窓口に電話してもコロナの症状は具体的に何か？という回答は得られず
詳しくは保健所にと言われるが繋がらない
保健所から診察する指示が出ない場合は行政検査にならず、自費診療になる
費用は概ね3000円から30000円程度であり、比較的安価な検査は梅田・なんばなど人出が多い場所で行っている様だ
症状が出ていれば病院判断でも行政検査が可能な様だが、具体的な症状の記載がなく、医者による判断になる
結果、コロナかどうかが不明確な状態で安価な検査しか受けられない場合
公共交通機関を利用し、コロナの感染拡大に寄与してしまうリスク・自身の感染のリスクを犯して
ただただ症状が収まるのを待機するかの判断を迫られる
今はサーバレスの時代ですからね。サーバとか使わないほうが進んでるんですよ。
phpのバージョンは？もちろん最新ですよ。自動アップデートでセキュアな運営を心がけてます。
タイピング自体はまあまあ早いんだけど、なんかそれだけって感じ
特に関数で集計した数字を信用してないのがよく分からない。手入力する部分はヒューマンエラーが起きる部分だから、チェックするのは分かるけど
自動で集計される部分までいちいちチェックするのは目的が全く分からない。一度だけ理由を聞いたけど理解不能すぎて忘れた
会計ソフトのフィルターとか、集計機能を使わないのもよく分からない
例えばコピー用紙を毎月どれぐらい買ってるか、会計ソフトから絞りたい時に「消耗品費」や「現金(預金)」で探すと
関係のないものまで出てきて邪魔だから、摘要や取引先名で絞れば効率よくコピー用紙をどれぐらい買ってるのか分かるのに
一度見かねて「こうやって複数の条件を設定してあげると絞り込めますよ」と教えたが全く理解できていなかった
その割に本人は、やれクラウド化しろだの電子決済がなんだのと言っている。まずは手元にある会計ソフト使いこなしてから文句言えばいいのに・・・
売掛金の管理だってそう。せっかく取引先でソートできて、なおかつ金額の集計も会計ソフト単体で出来るのに、いちいち電卓叩いて計算してる
ほらでた、まったく何も分かっていない。
じゃあ原神はなぜ全世界でヒットしてるんだ？
やってみれば「これがゲームじゃない」と言えなくなる。
まああれほどリッチな作りのゲームじゃなくとも、日本のモバイルゲームだって俺に言わせれば立派なゲームだ。
あれは日本人の恥じらいの性質にあわせて、従来のゲームにおけるハイライト的な場面はほぼ自動で眺めてるだけか簡単な指示をするだけで進んでいくためゲーム性がないように思えるが
ああいったガチャゲーのゲーム性の根幹はその前段階にあるわけ。
つまり如何に場面に応じたデッキを組むか、みたいな戦略要素と、いかに効率的にデッキを充実させていくか、というリソース管理要素がゲーム性の根幹になっているわけよ。
まあガチャゲーの中でもリズムゲーとかはそのへんがちょっと逆転していてコンシューマー的ではあるが。
だから知恵熱が出るくらい悩むような楽しさはだいたいのガチャゲーにあるし、スプレッドシートで最適構成をはじき出していくようなスタイルの楽しさになる。
もちろん、従来のゲームのように試行錯誤を繰り返していけば突破できる遊び的な余裕も十分にある(ないとまずヒットしないし低評価爆撃される)。
戦力の充実に関してはカネにモノを言わせることもできる、というだけで、それをしないで遊ぶこともできるし、昔のソシャゲほど対人戦を煽るようなガチャゲーは少ないから課金は趣味の域に留まっている。
逆に言えば、ソシャゲだった頃はカネかけてれば何も考えずともどんなクエストもポチポチで終わっていたが、今のガチャゲーはどんだけ課金していても頭使わんといけない場面が多かれ少なかれある。
俺はファミリーコンピュータの頃から始まりPCのMMORPG全盛、モバグリ全盛のソシャゲ、スマホゲーム、すべてを(人生ぶんなげて)楽しみ尽くしてきたからアイテム課金モデルゲームの洗練ぶりをずっと見てきたし、どれも素晴らしい部分があると知ってるんだ。
id:lady_jokeとid:lady_jokerは別人です
何かバズってて謎や不快感を抱えている人が多いようなので
1.ladyjoker氏への悪意
なかった。と言うかどういう人なのかもあまり知らない。
ストーカーとか悪意とか言ってる人は性格捻くれすぎじゃないですかね？
悪意が無いと読んでたタピオカとタピオカスターは国語力高いっすね。
これは意外な気づきだった。せいぜい1割もいないと思ってたのに。
意外とみんな違和感に気づかないんだね。
ちなみにこのアカウントのパスワードももう分からないからパソコン買い換えたら
自動赤版になる。
計測です。いくつかの事象がどれくらいの反応があるか計測したかっただけ。
計測目的でlady_jokeのアカウントとって長い間計測がうまくいかなくて
当初の目的を忘れてだらだらとこのアカウントを使いつづけてた。
今回もたまたま試したパクリ手法がタマタマバズってlady_joker氏の怒りを買っただけ。
大御所こえーわ。
私はそんな事してもないのにありもしないことで攻撃されまくって泣いた。
これがよくあるはてブいじめか。低能先生を生んだ、はてブこえー
無職のルサンチンマンの低能先生が耐えられなかったのも分かる。
ペンギンが言っているように朝鮮人差別が横行する2chと大差ない。
みんなは今日は公式にいじめれる素材が見つかってよかったね。今日のいじめは楽しかった？(*'ω' *)
7.このアカウントについて
多くのユーザーが誤認していてlady_joker氏が迷惑してるのなら
アカウント廃止してもいいよ。ただその前に私にネットいじめしたひとたちは謝ってほしい。
pikopikopan タワマンの、私も普通にlady_jokerさんだと思ってスターつけてた。なりすまし怖い・・非表示にしといた。どういう理由だろう・・ともかく気持ち悪い。ほんとアイコン変えたり描いて貰うのも手だと思う。
tableturning よく見るアイツか。悪意に満ちた成りすましだなと前から思ってた。
sekiryo Twitterでも居るけど文句があるなら正面からやれ敗北者。同じアイコンで偽物作って評価下げる発言する見下げ果てたゲス。そういう心根の卑怯者だから唾棄すべき最低の作戦を実行するのだろう。人としての矜持が無い。
monotonus 何度か通報してるけどbanされないねえ。ヤバい奴増えすぎだしもうはてなは2chみたいなとこだと思ってるよ。なんかめちゃくちゃ悪意があるわけがなさそうなのが不気味。
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【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から見ると単に１つのプロセスが稼働している扱いになる。
【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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
大学３年の夏休みに右も左も分からずアフィサイトかメルマガかなんか見て登録した新卒就活エージェントX
会員登録したら２，３営業日中に電話で連絡差し上げますと自動返信メールが届いてソワソワしながら待ってたのに一向に電話鳴らず、こんなものかと放置
しばらくたって翌年4月、「Xですがみなさんに就活の進捗伺ってまして、いかがですか。よかったら企業を紹介する」と突然営業電話をよこしてきた
Xに登録したことなんてすっかり忘れてて、どこなのかその時はピンと来てなかったし、既に別の企業から内定が出ていたが、ノリで面接を受けることに
面接が始まると事前に書かされたプロファイルシートをなんとなーく添削してもらって恩の押し売りをされた後、見てる業界を伝えると企業を紹介されたが、どれも待遇も仕事内容も新卒カードを使うのはもったいなさそうな企業
エージェントにどの今内定がでてる企業と比べても微妙だと伝えたが「説明会だけでも行ってみればいいんじゃないですか＾＾」と。
俺が行きたくないって言ってるのに完全にお前の都合じゃねーかと思ったが、断り切れずに2社説明会を受けることに
これって登録時にはエージェントの癖に生意気にフィルターかけて、フィルターを通過したエリート達のお眼鏡にかなわなかった余りものゴミ企業をゴミ学歴どもなら受けてくれるだろうと今更連絡してきてあてがおうとしてきたってことだよね
そう考えたらムカついてその後は連絡来ても無視した。向こうだって舐めたことやってるんだし
そうはいっても自分より時給が何倍も高い大人が自分の為に動いてるのは事実なので心苦しい。なぜこんなゴミ企業を押し付けられた上にこんなどうでもいいストレスまで感じなきゃいけないのか
という訳で日東駒専以下⑨の低学歴はエージェントなんか使ってもゴミ企業紹介されるだけだしよっぽど困ってなきゃ使わなくていいよ
なめられてます
いや、ネット記事でメタバース上の有害コンテンツを自動判別するAIを facebookが開発中って書いてあったから、メタバース上のjkセックスはどうなるのかなと思って
じゃあjkとセックスし放題だし、それをbanするような企業が出てきたらevilってことでええのか？
ならメタバース楽しみにしとる
それでありながら家庭的というよりはジャンキー寄りな味付けが好みだった。
多いときは週3くらいで行ってたのでまぁ自然と顔も覚えられて常連扱い。
「おっ、いらっしゃい」「大盛サービスしとくよ」的なイベントもあったがそれには特に何も感じず常連を続けていた。
1回来店でスタンプ1つ、15個集めたらとんかつ定食が無料みたいな内容だった。
それを見ながら、その店への愛着が急に冷めていく自分を感じた。
なぜ冷めたのかはハッキリとは言えないが。
その客が常連かどうかの判定は店主のさじ加減で、常連へのサービスもなにか特定のものを提示すれば自動で受けられるようなものでなく、
あくまで店主のきまぐれで行われるような、そんな曖昧な関係性を求めていたのかもしれない。
スタンプ集めというシステマチックな行為の結果で受けられるサービスの無機質なところに嫌気が刺したのかもしれない。
いったんは冷めた店への愛着。
ただ店主はその後もスタンプカードに関係なくサービスしてくれた。
食べっぷりが見てて楽しいとのこと。
スタンプはせっせと集めている。
(追記)
デブのふとした感情の機微に思いのほかトラバ＆ブクマ集まったな。みんなサンキューな。
そういえばその店って、テレビや雑誌でよく特集される人気の料理店……のすぐ隣にあって、
内装は小奇麗な反面外っ側がけっこうボロくてヘンな豚の絵が描いてたりして謎な空気感出してんのよ。
これを綺麗にすればもっとお客さん入るのに……とは思うけど絶対店主に言ったりしない。
推しの某企業所属の女性VTuberの、BTOで買って1年弱の配信兼ゲーム実況用のPCが故障。
自力では故障箇所の切り分けすらままならないため、そこの所属Vの中では恐らく最もPCに強いであろう、ガチゲーマーな同期を呼んで調べてもらったと。
結果、なんと当時ほぼハイエンドだったグラボが壊れていたことが判明。
結局同世代で同じシリーズの高性能版を買い直し、また更に負荷を減ららしつつ高速化を図るためSSDも増設し、ゲーム系は全てそっちに移動。
おかげさまで、3Dアクションゲームでも超ヌルヌルという絶好調なコンディションになって復活。
なお、同期の子に見てもらった際には設定についてもツッコまれ、
「○○ちゃん、せっかく良いグラボに4Kディスプレイ買っても、設定変えてないと意味ないよ～」
とに笑いながら言われたそうな。
ゲーマーにとってディスプレイに求められるのは解像度の他に、リフレッシュレートがある。
しなしながらこのリフレッシュレート、Windowsだと自動認識ではなく、ユーザーが手動で変更しないといけないのだ！
いや、知ってる人からしたら
「加湿器って水入れないといけないの？」
レベルのナレッジだろうけど、そんなん普通は自動認識だと思うじゃん。
実際言われた方のVも、
「でもそれ、殆どの子が知らなくて設定変えてないんじゃないかなー」
と苦笑していたっけ。
WindowsはLinuxと違って、大抵のことは自動認識してくれるので、それが却ってこういう落とし穴の原因になっている気が。
タイトルのとおりですが、色々トラブルもあったのでまとめます。
（※追記 2022/1/25 市区町村によってはHER-SYS（自動音声）で体調管理をしているらしく、場所ごとにオペレーションはだいぶ異なるようです。）
【陽性者スペック】
30代独身
熱はないが、朝から倦怠感と喉のいがらっぽい "風邪ひく一歩手前の体調" が続く。
喉が明確に痛くなってきたため、10時ごろ地元のかかりつけ医へ。
熱は36.4℃だったが、これから繁忙期のため念のため抗原検査をすることに。
鼻をゴシゴシし、液をたらして20秒ほどであっという間に陽性に。
先生の「あーでちゃったね」が忘れられない。
保健所の連絡先として携帯番号を伝え、そそくさとクリニックを出る。
薬局も電話でコロナ陽性になった旨を伝え、外でクスリの受け渡しを行う。
（処方されたのはムコダイン、トランサミン、カロナールの風邪薬三銃士）
その日のうちに保健所から連絡がくるということだったが結局こず。
ウエルシアの抗原検査キット(体外診断用)を実家の家族が買ってきたため、
自分も分けてもらったら、やはりあっという間に陽性になって一人で笑う。
末端がすごく冷える。寒すぎて風呂に入り、かえって38℃の熱が出る。
・医師の診断により発症日は1/12、自宅療養はそこから10日間を数えて1/22までを予定
・ホテルと自宅療養どちらを希望するか（でもホテルは空きがないとかなんとか）→自宅療養で
※電話に出れないと防護服のスタッフが自宅にくる場合があると脅される
・家族は同居か→先方が把握している住所が実家だったため、一人暮らししている旨と実際の住所を伝える
※実は濃厚接触について聞かれたらどうしようと思っていたが、一切聞かれなかった。
実家ではちょいちょい食事をしていたため、その話も伝えたが「別居していてお風呂など水回りを共有していなければ大丈夫です！」といわれ、むしろ濃厚接触者を増やしたくない圧を感じた。
熱は37℃台。
17:45 東京都自宅療養者フォローアップセンターからTEL
…がなぜか実家にかかってくる。
看護師から30分以内に改めて電話するというので待つが着信こず。
寝てて気づかなかったが、22:47に着信があった。
鼻詰まりが解消。鼻の下と唇がガサガサ。
喉の痛み、咳は若干あり。
・体調の確認
LINEは毎日10時と16時にその日の体調（症状・体温・SpO2）を報告する仕組み。登録者が4万人ほどいた。
体調がかなり快方に向かう。
ただ、なぜか体温が低くなり、35℃台～36℃ちょっとしかでなくなる。実は死んでるかも。
たんが絡む以外の症状良好。体温は依然低い。
コロナの死骸でも陽性になるので、具合悪いとき以外の療養後のPCR検査はおすすめしない（それで陽性になったらまた病院から保健所に連絡するオペレーションになっている）
・保健所から療養終了の証明書がでるので、そちらを利用しほしいとのこと
・看護師からの電話はLINEで体調管理ができていない人にかけているらしい。
食料品とパルスオキシメーターが未だにこないため、フォローアップセンターに問い合わせる。
調査の結果、伝票の電話番号が誤っていたため配送されずに東京都にもどってきたとのこと。
食料品とパルスオキシメーターが実家に届けられる。
近くなので家族に運んでもらったが、やはり住所も電話番号も訂正前のままだった。
夜、自宅療養終了のSMSが届くが、やはりスパムに分類される。
念のため本日も引きこもる。
連絡先を一度誤るとその後のすべての対応が後手に回るので、最初にしっかり確認したほうがいいです。
とどいた食料品は常温保存できて普段食べないものもあったので大変ありがたくいただいています。
↓このあたりがうまかった
本日、自宅療養2日目で使った抗原検査キットを試したら陰性になってた！
まだたまに空咳がでるので、ワンチャン陽性になると思った…これが後遺症ですかね。
住所の件は、保険証が実家の住所なので、おそらくそのせいだと思います。
