  |
はてなキーワード: 閾値とは
「なんらかの組織に帰属して、自分が人の役に立っている」感覚が無いと、人は一瞬で壊れる。
老害が生まれるのも、定年退職後に有り余る時間の中で「自分は役立たずだ」と強制的に自己認識させられるからだ。
「は？自分は平気だけど(意訳)」と宣ってるブコメが大勢居るが、以下のどれかに該当するだけだと思う。
・体験したのが堅牢な心理的安全性が担保され、なおかつ期限付きの孤独だった。
(親元かつ20代前半以下、手に職が有り次がいつでも決まる状況での数ヶ月程度の息抜き離職、育児期間による離職など。)
・自分を孤独だと認定する閾値がおかしい。(俺・私は人付き合い苦手だし〜→普通に彼氏彼女居る、みたいな。)
・平均より知能が低い。(オタク趣味があれば平気！とか言ってるタイプ。障害者が作業所で延々と単調な軽作業してても狂わないのと同じ理屈。)
・強がり・虚勢。(大半がコレ。狂わない為の自己暗示。そもそも孤独が至高ならば、SNSの類なぞめんどくてやらないし、コメントも書かない。)
一番影が広い写真というけれど、書いた通り再現できる照明機材を持ち合わせてないので、お題に出された写真を引っ張ってきてるだけだよ。
元増田に載せた写真もアニメ風に塗るときの閾値の例示として出しているわけで、
何が言いたいんだろう？論旨がわからない。
このブコメ達を見てほしい
『絵を描かない人からハイライト表現部分を「塗り忘れてるよ！」と言われてしまった』
https://b.hatena.ne.jp/entry/s/togetter.com/li/1869554
ブクマカたちによるとブコメ先に掲載されている絵は照明があまりにも不自然だ、とのこと。
そして、そのような絵になるのは、イラストレーターの能力がなかったり、手癖で描くからだということらしい。
しかし本当にそうだろうか？被写体の上にライトがあれば実現できるのではないか？
ということで検証した。
といっても、おれは照明機材を持ち合わせるほどの金がないので、既存の写真を用いる。
はい。
ということで、アニメ的な階調にする際、どこを閾値にするかが問題なのであって、
実際には起こりえない、ということではないことがわかる。
当然画像全体で加工をしているので、検証画像は実際にこういう光の当たり方をしている。
ということで、イラストレーターはちゃんと知識や経験をもってあのハイライトにしているということがわかる。
タイトルにある「絵を描かない人」にコンプレックスが刺激されたんだろうが、成立しない理屈で叩くなブコメ達。
ブコメ先で、「絵を描かない人の意見も大事だよね」という話がちゃんとされているぞブコメ達。
けれど、顔が白飛びをしているのに髪の毛が白飛びしないのはおかしいのでは、というひともいるだろう。
なるほど、たしかに顔が白飛びをするほどの照明なら髪の毛も白飛びをするのは理屈に合っている気がする。
すると以下のような写真がみつかる。
https://bbs.kakaku.com/bbs/00491011155/SortID=9506170/ImageID=296235/
http://photozou.jp/photo/show/1384474/67526838
不思議なことに、顔がこんなにも白飛びしているにも関わらず、髪には影が残っている。
考えれば当たり前なのだが、髪の毛は毛束なのだから、肌とは違う反射を起こすのだ。
しかし、そもそも論として実写の理論を絵に持ち込むことに無理がある気がしてしょうがない。
実写環境を想定した照明のあたりかたどうだ、という指摘はそもそもおかしい。
それだったら骨格がおかしいだとか、そんな目の大きい人間はいないだとか、そういう話になってしまう。
ようするに野暮なんだよ、それは。
そういう点ではイラストの理屈が先鋭化しすぎているという指摘はまだわかるのだが、
ブコメ先のイラストレーターは4万フォロワーを抱えるイラストレーターなわけで、
やろうと思えば、数人が食ってけるだけのエコシステムを組めるレベルである。
和田誠のイラストに、絵が抽象化過ぎて先鋭化が…ということを言う人はいないわけで、
イラストレーター本人がそれが良いと思って、周りもそれが良いと思っていることを
ましてや、ブコメ先では当然、前衛と大衆のバランスについても言及されているわけで、
そんなの余計なお世話だろうに。
あと、「俺がクライアントなら差し戻す」というブコメがあるが、
いったい何を想定して依頼をするんだ？画がわからないのに。
会社の金を使うんだから普通は調査して、打合せして、想定して、途中経過をチェックするだろ。
「俺が日本の王様なら、国民はすっぽんぽんにするんだけどなぁ」
おれには正直ブコメがなんでそんなに絵が描けないコンプレックスに陥ってるかよくわからない。
というか、エンタメ、芸術分野に対するコンプレックスなのだろうか？
「アニメ風にするなら24コマにしないと」とかえらそーに言ってる奴とかいたけど、あれは何なんだ？
黙って消費に徹しろ、とは言わないし、
悪意のない失礼までするな、とも思わないけれど、
98歳までボケることもなく足腰も丈夫だった(死因は肺炎だった)んだけど、
表題の通りあらゆる食い物に味の素を添加して摂取していて、ある程度家族も巻き添えになってた。
1kg入りの袋を２～３か月毎に買ってたと言えばただ事で無さが伝わるだろうか。
そんな生活を何十年もしていた。
世間では味の素でボケるとか味覚障害になるとかたまに言われるが、味覚障害についてはなるかもと言わざるを得ないけどボケはまったく感じなかった。
数独とかクロスワードとか自分より解くの速かったし、その年代にしては珍しいことに英語もできた。
そのばあちゃんの味の素の使い方が変わっていて、料理をぜんぶ味の素ナシで作ってから、食べる直前にスプーンでがばがばっとかけてたのよな。
見た目のインパクトも絶大だったし、味の面でもグルタミン酸は閾値を超えると味覚では分からないとよく言われるがさすがにその分量だとガクンと脳に来る感じもあった。
なぜそんなことをするのか。曰く、「加熱すると味の素本来のうまさが失われる気がする」という、やべー奴としか思えない理由だった。
まぁ冒頭に「家族もある程度巻き添えに」と書いたように、そのかけ方だと家族は直前でストップを掛けることができるので、
文句を言われつつ常にその分量を摂取することは免れていた（時々フェイントで入れてくるのはあった）。
でもたしかにそういう気がしてくる程、おばあちゃんの作るメシはうまかった。
たぶん味の素とボケにはなんも関係ないってのが有力な説だろうけど、もしボケるとしても加熱しないことでその成分が増えないとか、そういうのもあるんかもしれないな。
そんなおばあちゃんの（たぶんいくらか味の素を含んだ）血を受け継いだ自分も、味の素信者に……はならず、たまにほどほどの分量を使用する程度。
でも実はあの使用法は受け継いでいて、今日も出来立てチャーハンに味の素をパラパラっとかけながらふとおばあちゃんを思い出した次第。
（追記）
自分がおばあちゃんから継承した知識としては、一般人向けの50グラム入り(150円くらいか？)とかを
チマチマ買うより1kgをドカっと買って容器に補充する使い方のほうが圧倒的にコスパがいいということ。
一般人は使い切れるか心配だろうけど実は味の素に賞味期限はないのだ（砂糖や塩と一緒らしい）。
ただ袋の下のほうに小さく「これは業務用です。家庭用とは配合が異なります」とか不穏なことが書いてる。
けど味の違いは正直わかんない。
文章を書いているときも、誰に見られているわけでもないのに、自分の素直な気持ちを書くことができない
だから酒をのんで自意識の閾値を下げないと、ほんとうに思っていることがかけない
だらだらと深酒をしながら、なにか文章を書いて、ふと見返してみると書いてある文章は自分と別人のような文章であることが多々ある
そういうときにかいた文章は、少なくとも自分にとっては意味のある文章であることがおおくて、たまにつらくなったときにみかえしている
なんだかいつも、自我が邪魔をしている感覚はあって、自分に対しての変なコンプレックスなのか、自意識過剰なのか、べき論がつよいのか、そのあたりはよくわからないけれど
もっと気楽になにも考えずに生きていけたら、すくなくとも自分にカッコつけずに文章をかけたらな、いいのにな
岩手県におけるイノシシ Sus scrofa の分布拡大の変遷と出没確率の予測
https://www.jstage.jst.go.jp/article/mammalianscience/62/1/62_21/_pdf/-char/ja
https://doi.org/10.11238/mammalianscience.62.21
目撃メッシュ数 の意味が書かれていないので、読みづらいです。
５ｋｍx5kmを一つの区間として、その区間で目撃がすくなくとも１回以上あった区間の数のことで良いのでしょうか？
図１を見ると目撃メッシュ数に対して、目撃件数が３倍程度あるので、１区間で平均３回の目撃があったという意味でしょうか？
一般に、AUCは未知のデータに対するモデルの予測の精度を比較します。言い換えれば、学習データと未知のデータにデータを区切って、学習データを使って学習をおこない、その後未知データをつかってAUCを計算します。
今回の場合、５種類の環境データの選別を行うために、すべての出没データを学習させたモデルを使ってAUCを比較しています。この場合、どのデータから予測させてAUC計算したのかが不明です。学習に利用したデータから予測をおこないAUCを比較した場合、未知のデータに対する予測ができていません。なので、どの環境データを使うのが未知データへの予測に対して良い効果をもたらすのかを結論付けることはできていません。
2007 年～ 2017 年のデータから、2018 年および 2019 年の予測を行っていますが、そのさいのAUCが不明です。どの程度の精度だったのかが不明です。書くべきです。
この部分もAUCで比較を行うべきです。比較するAUCが無いのに、データが多いほうがよいという結論は出せないと思います。
出没確率からTrueかFalseを判定してAUCを計算しているはずですが、その閾値はどのようにきめているのだろうか？
出没確率からTrueかFalseを判定していますが、その閾値はどのようにきめているのだろうか？
"出没予測は，実用可能なレベル"と書かれてますが、何に使うのかがわかりません。目的達成のために必要な精度も記載がなく不明です。そのため、本当に実用可能なのかがわかりません。
元のデータを使って人間が予測した方が、当たるのではないだろうか。
場所に対する精度が荒いという問題があり、実用可能な問題が限られると思います。
AUCが書かれてないので、精度がいいのか悪いのかが判断できません。
また、付録を見ると、イノシシの出没はほぼ同じ場所である。イノシシのデータだけを使っても同じ精度で予測ができるのではないだろうか？
また、逆に、環境データのみから、出没場所を推定できるのではないだろうか？2011年までの出没データと、2019年までの環境データを入力すれば、高い予測が可能なのではないだろうか？
2007-2015年と2007-2019年の学習モデルが予測した確率分布図がほぼ一致しているのが面白い。
イノシシのデータではなく、環境データのみでも予測が可能であるということを意味しないだろうか。
いずれにしても学習データと検証データをわけることそして、AUCによる比較検証が必要だと思う。
アネレムのつかいかたまとめ
導入 0.1mg/kg
維持 1mg/kg/h→0.8→0.6 min0.4
20分ずつで減らしていく
・bis
数字は当てにならない
・循環
導入時に少しだけ交感神経抑制の時間があるが、落ち着いてからは全くない
驚くほど血圧が下がらない。その人の通常血圧がそのまま麻酔中に出るので、他の麻酔薬に慣れているとベースが高く感じる
交感神経抑制がないので、疼痛刺激の閾値が低い。すぐに反応するので少しレミフェンタニルは多めになる
そのせいで徐脈がでることもある
でも血圧は下がらない
持続昇圧薬の必要性は少ない
おかげでシバリングも出にくい？
覚醒 基本レミ残し抜管
レントゲン板外れたらレミもoff
tidal充分取れて刺激に反応あれば抜管可
抜管後はドロッとしていることが多い
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
例えば以下のようなケースを考えたんだけど、法律よく分からないので詳しいひとに聞きたいな。
ケース（1）
記事の肩書きには「ソニー（任天堂でもMSでも可）○○部所属」とあった
（記事自体は相変わらずガチャゲー批判だが、さすがに普通の批判記事の範疇であった）
このアカウントについてユーザからのクレームがあったこともあり、名指し批判されたゲームの開発元は、所属と思われるソニー（もしくは任天堂もしくはMS）社に対し、発言者が社員であれば発言に注意するよう申し入れを行った
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ここで問題となるとは以下の点だと思う。
良く似た筆名で良くよく似た主張をしているだけであり、Twitterアカウントからの記事への言及があったとしても、なりすましという可能性はゼロではない。
単なる疑いでしかないのに、同一人物という予断で会社に問いあわせをしても良いのか
雑誌に問い合わせてもプライバシーを理由に回答は得られない可能性は高いが、
まずは本人に同一人物であるか問いただすべきではないだろうか。
それで回答がない、もしくは不誠実な回答だった場合はどうか。
ある程度の関係性は認められる以上は、会社宛に断定でない形で問合せをしても良い可能性はないのだろうか？
雑誌記事は社名をのせている以上は会社が無関係とは言えないが、Twitter上は会社名を名乗ってはいないし、匿名で活動している。
つまりプライベートの活動であると考えられるにも関わらず、会社に申し入れるのは不当ではないだろうか
ただ、Twitterアカウントと記事寄稿者が同一人物でれば、それらの言論活動は外観として地続きに見える点も考慮すべきで、完全なプライベートの活動と言い切れるものなのだろうか。
どれくらいの連続性があれば（なければ）、会社宛の申し入れを正当化（不当化）できるのだろうか。
このケースではTwitterの攻撃対象はスマホゲーユーザなど不特定多数、もしくはゲーム会社に限られている。
しかし侮辱罪が成立するような暴言はほぼスマホゲーユーザなど不特定多数に向けられていて、ゲーム会社はひたすらこきおろしているだけである。
「意見論評型の名誉毀損」は法人には適用されないだろうし、「侮辱罪」も不特定多数相手には成立しないだろう。
その状況で所属会社を通じて発言を封じるような行動に出るのは、不当な言論封殺にあたるのではないだろうか。
とはいえ所属会社の社会的信用の低下を防ぐため、社業に関わる方面での社員の発信を制限すること自体は珍しいことではない。
そのような理由で社員の発信を掣肘できる範囲とはどのようなものなのだろう。
何らかの侮辱罪に問えそうな発言があったとして、まずやるべきは発信者開示請求などを経て個人への訴訟であり、所属会社を巻きこむのはそもそも禁じ手ではないか。
所属会社は寄稿記事で社名を名乗らせ、間接的にTwitterアカウントの社会的評価に影響を与えたという点で全く無関係とはいえないかもしれないが、直接的な関係はない。
ただ、個人の紛争を無関係な会社に知らせるような行為は論外としても、(4)で挙げたように会社は全く無関係とも言い難く、会社の名誉を守るためには情報提供は有益とも言える。
Twitterアカウントと記事寄稿者が同一人物でれば、会社を巻きこんだのは本人の意思とも言えるのではないか。
所属会社の当事者性というのはどういう理路で判断されるのだろうか？
ケース②「特定人物（開発者）への侮辱が含まれる場合」も書こうと思ったけど、力尽きたので一旦止める。
全般的に不勉強なので判断基準がよく分からないのもあるし、見落としている視点がきっとあるんだろうな、と思う。
元ネタの方は、事業会社と違い大学には「大学人の言論の自由を保障する」使命が在る点、問題が主に個人への侮辱であるところが大きく違うので同じ結論には当然ならないはず。
ただ、そこまで簡単に白黒つくような話とも思えないんだけどなあ……。
