  |
はてなキーワード: 整合とは
https://anond.hatelabo.jp/20190318130406
40代後半の女だ。
最近はてなを眺めていて、たわわ関係で思うところがあったので日記を書く。長文だ。
言いたいことは
（１）40代女性があの広告を問題あると感じやすいのは自身の経験&既往研究と整合する。の１点だ。
幼稚園年長
近所のお兄さんにいきなりキスされ、舌でべろべろ唇をなめられた。気持ち悪くて泣いたら、お兄さんは逃げていった。なぜか親には言えなかった。
小学生高学年
土手沿いを自転車で走っているとき、知らないおじさんに声をかけられて、「かわいいね。」、「あっちにかわいい子犬がいたんだよ、見に行こう。」と川沿いのアシが茂った人気のない場所を場所を指さされた。あんなところに子犬がいるわけない、というのと、おじさんの目つきがなんともいえず気持ち悪かったので逃げた。親には知らない人と話すんじゃないと怒られそうで言わなかった。
混んだ電車で祖父母の家に母と出かけた時、いつのまにかスカートの内側に精液をかけられたことがあった。
当時は鼻水だと思っていたが、祖父母の家についてから母が「スカート脱いで」と言って、祖母と小さな声で話しながら裏地を怖い顔で洗い始めて、鼻水つけられたくらいで大げさだなと思っていた。
高校生になって、自転車通学になり、いきなり下半身露出男が日常になった。
学校の行きかえりや、高校のテニスコート周辺に、下半身露出男がしょっちゅうでた。
他には自転車で走っていると、車でのろのろと後ろからピッタリ尾けられることがときどきあった。追い抜く道幅は十分あるのに、なんでついてくるんだろと思っていた。
部活の試合で皆で移動しているとき、空いている電車内で向かいに座っている男が自分たちに向かって下半身を露出することもあった。
電車に乗り込むとき、部活の仲間の尻をスーツ姿のおっさんがさりげなく触っているのに気づいたこともあった。あのおじさんに触られてたよ！と仲間に伝えると、おじさんは気まずそうに次の駅で降りた。
電車通学が始まった。
高校生の時に下半身露出男が日常で、上記の痴漢目撃経験があったため、電車通学時は最大限の警戒態勢で臨んだ。
といっても、痴漢に遭遇したらぶん殴ってやる、と思いながら電車に乗るだけだ。しかし、それが効いた。
同級生と比較すると痴漢に遭遇する頻度は非常に低く、4年間で5回くらい。
胸をもまれたり、股間をまさぐられたり、尻をガシっとつかまれたり、下半身を露出したり、「こいつ、痴漢だ。」とはっきり分かったケースだけだが。
この数を言うと、同じように電車通学していた人には「少ない！」驚かれた。
痴漢にあうのは、風邪をひいたり精神的に落ち込んだりしているなど、弱っているときだった。
どの場合も蹴る、殴るなどして抵抗した。ほとんどの痴漢はこわばった顔で次の駅で降りて行った。
しかし一回だけ、痴漢に殴り返されたことがあった。その場合は、他の男性乗客が「お前が悪いんだろうが！」と殴り返してくれた。そいつは下半身露出タイプだったため、他の乗客にも変質者だとわかりやすかったというのもあると思う。
電車以外では、本屋で2回ほど痴漢にあったことがある。２回とも蹴っ飛ばしたら逃げていった。
アパートで独り暮らしをしていたのだが、歩いているときにBMWから降りてきた知らないスーツのおじさんに家まで尾けられた。
階段の入り口までこられ、私が２階に上がるところまでニヤニヤしながらジロジロみられたので、降りて行って、「おい、なんか用か？」と声をかけると「いや、かわいいなと思って」ともごもご言ってから小走りで車に逃げていった。
おっさんが車に乗り込んで逃げていくまで、お前の車覚えておくからな！と、おっさんの車のナンバーを大声で叫んだ。部屋に戻って鍵をかけたあと、自分の手が震えていることに気づいた。
今思えばセクハラだなと思うことは山ほど経験したが書ききれないので割愛。
結婚してから、仕事関係のおじさんに会食して相談したいことがある、と言われ、断りにくい関係性だったため、夫に相談したら、夫が会食の場の駐車場で待機してくれたことがあった。会食中、全然相談の話にならずセクハラな会話が続き、次の店に行こうと手を握られたので下の駐車場で夫が待っているので、と言って帰った。当時30代半ばだ。
どちらかというと少ない方だと思う。
それでも、40代も後半になって思うのは、いろいろ危なかったな、ということだ。
土手おじさんをはじめ、今思い返すとヒヤリとすることがあった。
若い人は真似をしない方がいい。なんか便利なアプリとかあるみたいだし、周囲に助けを求めて欲しい。
で、本題だ。
某アンケートで、40代以上の女性で広告を問題視する割合が増えるという結果があったが、なぜ割合が増えるのかについては、
①「あの時は危なかったな」と被害経験を客観視できるようになった。
②上記に加え、子供を守り育てる年齢になり、子供たちにああいう目に遭わせたくないなという気持ちが強くなる。
という作用機作があるとおもう。
①について、若かったころは、世の中こんなもんだ、と思い込んでいたが、今思えば、ずいぶんむき出しの危険に晒されていたというか、社会に守られていなかったなという実感がある。
自分はもっと怒るべきだったし、痴漢は蹴っ飛ばすだけじゃなくて周りに助けを求めたり、警察につきだすべきだった。
だから、電車で痴漢を殴り返してくれた男性には今も感謝している。
殴るという方法は良くないかもしれない。でも、周囲の大人は痴漢に怒ってくれる、という信頼感を自分にくれた恩人である。
あのときは小さな声でお礼しか言えなかった。感謝しています。ありがとうございます。
②について、様々な既往研究では化学物質等の危険なものについて、子供の有無に関係なく30代から40代の女性が他の属性よりも危ないと感じやすいという一般的傾向が確認されている。
子供の有無に関係なく、というのがポイントで、その年齢になると、危ないものをより危ないと感じやすくなるのだ。
子供を守り育てるための本能に近いものではないかと考えられている。
割と良く知られていることなので、なんであのアンケートの調査者が既往研究について触れないのかは謎だ。
このことについて、年増女の若い子への嫉妬だ、と揶揄する人もいる。電車内の高校生を性的に見て何が悪いんだ、という人もいる。
おそらくそう言えてしまう人は、男女関係なく、①の被害経験が少なく、「あの時は危なかったな」という客観視プロセスを経ていない人、②子供を性的な被害から守りたいという意識の薄い人、なのではないかと思う。
経験や知識、実感がないと理解できないのは当たり前であり、仕方ないことだと思う。
①と②の意識は男女、年代問わず、誰でも持っている。ただ、それが他の属性よりやや高くなりやすいのが40代女性ということである。
そのためもちろん個人差があり、40代女性でも、高校生の時は自分で自分を守ってきたという自負がある人もいるし、電車内の高校生を性的に見ることを社会として受容可能という人もいる。
40代女性も一人一人違うのである。量的調査をすれば、平均値が他の属性と比較して少し上がる、というだけだ。
以上、40代後半女による、40代女性が例の広告はまずいと思いやすい背景の説明である。
まあn=1なんだが、n=1だろ、と切り捨てるのも科学的態度ではない。そうした質的研究を行うことで、説得力のある量的研究の設計をすることができる。
ちなみに、自分自身は、あの広告の表象が女性差別とは思わない。
巨乳フェチ漫画自体が悪いとも思わないし、新聞社が悪いとも思わない。
なんちゃらアライアンスみたいなのは、事業者間の約束事で、外野がどうのこうの言うもんでもないなと思っている。取り決めを行った主体間で、問題があれば話し合いをしていけばいいだけの話だ。
編集者等、編集部の構成員に上記の①や②の意識はどの程度あるのか。
編集者は「4月4日は今年の新入社員が最初に迎える月曜日です。不安を吹き飛ばし、元気になってもらうため全面広告を出しました。」というコメントをどのような意図で言ったのか？
その目的のため、広告を出すにあたってどのような工夫をしたか。
上記は別に糾弾するつもりはない。出版社ってどこまで考えてくれているのかなという、40代後半女の、単なる好奇心である。
以上。
などと、周りでPixelでNFCが使えなくなっている事例を目にして思った。(4月のアップデートでも治ってないらしい)
https://iphone-mania.jp/news-444457/
個人的にはAndroidもiPhoneもどっちも使ってるんだけど、大事な認証とか支払いとかの機能は全部iPhoneに持たせている。
(Androidって一口にいうのは主語がでかいとは思いつつも)端末バリエーションが多すぎるのが問題で、Androidは信用できないし、開発側からしても魅力的に思えない。
もちろんAndroid端末個々のスペックを取れば大抵iPhoneに勝ってると思う。iPhoneは1世代、2世代前の技術使ってて面白味はあまりないのにも同意する。
ただ、Androidは、アップデートの安定性とかアプリの移植性とか考えると、どうしても不安定になる。
実際、アプリ開発の現場で、特定の会社の特定の端末のみで起こるバグとか、画面が見切れるとかの事象に延々追われて、Androidのリリース・アップデートが遅れるというのは何度も見てきた。ハードの各パーツ、対応しているAPI、OS、画面サイズなどなどが掛け算で無限にバリエーションとして出てくるので全部テストするなんてのは不可能。
おまけにAndroidにインストールされてる他のアプリの影響とかも出てくることがあるので、ユーザレベルでもバリエーションが出てきてしまう。メインストリームだけ、と思っても会社ごと製品ごと全然仕様が違うのでやっぱりつらい。
UI/UXは端末最適、シームレスなものには絶対にならない。周辺機器を考えるともっと辛い。
iPhoneも多少はバリエーションあるけどAndroidに比べると全然大したことない。ハードとソフトが大抵整合していて考えやすい。
そんな状況だから、Androidを使い続ける限り、アプリとかOSのアップデートでいつかバグを引いてしまう。開発側もテストめんどいのでiPhoneに特化してアプリ出したりする(特に日本ではその方がコスパ良い)。もしくは汎用的でそんなに使いやすくないUI/UXでAndroidにはリリースしたりする。そうしてますますAndroidが使いづらくなってしまう・信頼できなくなってしまうというループが長期的に発生しているように思う。少なくとも自分はそう感じていて、Android使う頻度は漸減傾向
オレは麻雀をプレイするんだけど、負けにはおよそ２パターンある。
オレは後者を、運が悪いと称している。自由意志の範囲を最大限認めても、どうしようもない領域がある。たとえば彼女にベストなプレゼントを渡すため最大限の時間をコミュニケーションに割いて、理解の努力をしても、的はずれな選択をしてしまう事もある。
自由意志の範囲をもっと狭く、あるいは全く認めない思想は有り得る。その世界では「責める」概念は意味をなさなくて、すべての刑務所は病院になる。以前、はてな匿名ダイアリーで議論したことがあるんだけど、結局、自由意志不在説を否定することはできなかった。自由意志がまったく無いと考えてもなんら不整合はない。
年相応ってべつに法律ではないんで従わなくても法的な問題はないけど、
もっともねぇと見なす価値観の人が多いので損をするってことなんだろうか。
例えば歳の差恋愛をドン引きする人は多い。たしかに犯罪のケースが多いんで基本的に忌避するものなのはわかる。でも成功例もある。成功例のレアカップルは肩身が狭いのだろうか。
でもナウなヤングってなんか目上の人に対してもチャラそうだし、「年相応でなければみっともない」という概念を持つ人間って減って行ってない？
高齢者の多死期間を経て人口ピラミッド上の老人山脈がどんどん削れていくにつれ、その辺の価値感も急激にシフトしていくのだろうか。
DJ KOOとかどうなん？
藤子不二雄A先生なんかは８０とは思えないくらいめちゃくちゃ元気でしたけど。受け答えがハキハキしてて。
「ジブリ作品って倫理的にアレなところもあるけど人気だから叩けない」みたいな言論を水面下で観測するし、ジブリ亡きあとバッシングが始まるのでは？みたいな予測をしてるのをインターネット言論界で見かけた。潮目が変わる時が来るのだろうか。
トシをとると若い人からはどうしても対等に見られない、気を遣われるので、それ相応の暗黙の察しが必要みたいな人生訓を見かけるけども。一理あるとは思う。
でもそれって因果をよく考えるとニワトリタマゴ状態で難しくない？トシとった側が若い人に壁作ってるから、若い人のほうも壁を意識してるだけじゃね？
壁を作っているのはどちら側か？という問題がそこにはあるのでは。
ていうか「人生１００年時代（笑）」でしょ？それに合わせて年相応のラインも見直していかないと整合とれなくね？
まあ成人年齢は１８になりましたが。
なんか出向先の某大企業の社員が「苦労をぜんぜんしてこなかったので」みたいな口癖で、たしかにいい歳して妻子持ちのわりには幼いなーって人が居たりしたし、逆に若いのに滅茶苦茶過酷な経験をして目がガンギマリしてる人もいるわけで。戦時中の写真に映る軍人さんってスゴイですよね、目力が違う。覚悟の目。なので、年相応に過酷な経験をしてないと年相応感は出せないわけで、ていうか、「年相応」というよりは「経験相応」ですよね。
トシくっても運が良ければ過酷な経験、シビアアクシデントは少なかったりもするわけで。
なんだろう、年相応とかいう言葉でオブラートに包んで過酷な経験マウントとるのやめてもらっていいですか？
戦争に反対することは無条件で良いこととされてきた。
日本が戦争をしている最中に世の中の風潮に逆らって戦争に反対した人は立派な人と言われていた。
与謝野晶子の君死にたまふことなかれとか、国家の存亡よりも個人に寄り添うことがいかに難しい時代だったかとか。
ドラえもんでさえ、タイムマシンで戦時中に行ったとき、この戦争は日本が負けてすぐ終わると言って睨まれる回がある。
だが、ウクライナ情勢ではそういう主張をすることは許されなくなった。
悪のロシアを倒すまで国際協力して徹底抗戦すべきという意見が正しいとされ、
降伏でもなんでも戦争を早く終わらせるべきという意見は徹底的に叩かれる。
ウクライナへの共感をベースに考えるとそれも理解できなくはないけど、
森裕子参院議員に賠償命令 特区ＷＧ座長代理の名誉毀損―東京地裁：時事ドットコム
記事には「毎日新聞社に対しても損害賠償を求める訴訟を起こしたが（中略）真実と信じる相当の理由があったとして請求を棄却」とある。
ということ。妥当。
一方、森裕子に対しては「全国紙の報道であっても、真実と信じる相当の理由があるとは言えない」として真実相当性の法理による免責を認めなかった。
これは2010年の最高裁判決（最決平成22年3月15日刑集64巻2号1頁）を踏襲していると思われる。最高裁判決については以下の資料が参考になる。
最高裁判決を要約すると「一般市民であってもマスコミと同等の調査義務が課される」、換言すると「裏付け取材を行わない限り、真実相当性は認められない」ということ。
今回の判決においても同様の基準が採用されたのであれば、森裕子は「毎日新聞の記事を鵜呑みにし、裏付け取材を怠った」ために真実相当性を認められなかったということになる。妥当。
BIFF 本件の「全国紙の報道であっても、真実と信じる相当の理由があるとは言えない」と毎日新聞の訴訟での「真実と信じる相当の理由があった」は整合性取れてるのかちょっと気になる。。
毎日新聞は裏付け取材を行ったために真実相当性が認定され、森裕子は全国紙の報道を鵜呑みにし、裏付け取材を怠ったために真実相当性が認定されなかった。整合している。
fops 「全国紙の報道であっても、真実と信じる相当の理由があるとは言えない」そうなの？？記事に問題があるならリンクより、記事を書いた人に問題あるんでないの？
それは「配信サービスの抗弁」と呼ばれるものだが、最高裁は配信サービスの抗弁を否定しており、記事を転載した側も当然その責任を負うべきだという判例が確立している。
目出度く「ゴルディアン・ノット」作戦こと21世紀型ABCD包囲網の打破を目指すロシアン真珠湾の概要が公表されたので訳す。なお註釈のうち文中のものはすべて英訳者により、数字のものは註釈ではない和訳者のたわごとである。例により和訳者は頭の悪いのと精神病質者が大嫌いだがまあ共産趣味者とかインテリゲンツィヤとかアリストクラットが労働者を"対象"と捉えるのは今に始まったことではないから特に後ろめたく考えてはいない。
第三次世界大戦は始まったようだ; 同僚たちはシャンパンの封を切っている[1] - イラン・米国間の戦争は核合意を阻害しロシア産原油のイラン産原油による置き換え余地を封じる。ホルムズ海峡の避けられぬ封鎖は原油価格をうなぎ上りにする。筆者は[ロシア・イラン間の]一般的には理解不能な合意がある可能性すら信じているが、裏付けるいっさいの事実は持ち合わせていない。
今日はただわれわれ[組織としてのFSBにとって、#WindofChange個別ではなく]の目から見て差し迫ったロシアの"出口"と、クレムリンの"廷臣"について伝えようと思う。(帝政における皇宮について言っている)
これは(実際の摘要の)"複写"ではないがきわめて正確な再話であり、いかように扱ってもかまわず、内容を伏せずに全文を転載してもよい。
この作業はまだ取り掛かったばかりであるので現在はまだ輪郭があるのみで、最終的な報告書は分量があり、詳細で、より堅固になる。今はイラン-米国紛争にかかりきりであるので、筆者はのちより自身の(この新計画に対する)意見をくわえる予定である。『ゴルディアスの結び目』は深く修正・適合される(イランが在イラク米軍基地へミサイルを発射しているため)。
＞それは「友人」とかじゃ駄目だったの......？「母親」なの...？
の直後に
＞なんと議題が「もし友人にLGBTQがいたらどうするか」というどストレートなもので、議題が出た瞬間なんでこんな公開処刑みたいなことするかなぁ！？
友人がLGBTQだったパターンについて聞いて良いのか悪いのかどっちなんだ。
「デフォ」と「旦那とどっちが文句つけるか」じゃ比較になりませんぜ
読み手の多くが「ほんとにそうかな？」と思うような、意外だったり常識に反したり不意を突いたりするギリギリの内容をタイトルにして、その最後に「ワケ」をつけると、「読めばその論拠が説明されて、おれの疑問が解消されるんだな」という思考に誘導できるから。こういうのを論点先取型タイトルという。
「なぜ○○な人は××するのか？」というのもその類型。あれはタイトル自体で「本当に○○な人って××してるのかな？」という本来あるべき議論をすっ飛ばして既成事実化してしまう。読者としては微妙に「ほんとにそうかな？」と思いつつ、やっぱり「読めばその論拠が説明されて、おれの疑問が解消されるんだな」となる。人間はわからないこととか認識の不整合を解決したい生き物なので、こういう風にすれば読みたいという欲が出る。まあ、釣りのなかでも高度なやつなのではないでしょうか。
おしなべて皆主張されていない事柄を読み取り藁人形に向かってキレている
・この絵はサイゼで喜ぶ女かどうか試している場面だ！
・この絵とこれで喜ぶ者は女は安い店で喜ぶべきだと示している！
・この絵を批判している者は男から貢がれた物の価値で自己の確立を図る下衆女だ！
これらの様な凡そそれからは見出し得ない問題点と論点を自己で創出し当該の絵を叩き台として主張の発散、論敵の決定を行うからありとあらゆる点で話がズレている
ある事柄を起因としそれに対する所懐を述べるのが整合かつ正当だが、この話に於いては、存在しない仮想敵、自分の理想通りの叩きたい敵を勝手に見出し一方的に反感を溜めそれを吐き出さんとする様な愚鈍さ散見される
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
