  |
はてなキーワード: ブラックボックスとは
最近、赤松健候補をレドマツ呼ばわりするのがニガーと同種の深刻な差別問題だという主張が頻繁にされていて、酷暑の残酷さに心を痛め後遺症を心配するところなのだが、「ニガーを当事者が言うのはOKだが外部が言うのはダメ」という言説はちょっと違うので一言言わせてくれ。
この「罵倒文句を己らの呼称として使うようになる」っていうのはアメリカの伝統なんよ。
Yankeeは元々北部のアメリカ人の事で、主に南部人（デキシー）が使う罵倒語だった。
ところがこれを北部の連中は気に入ってしまい、自分らの事をヤンキーと自称するようになった。NY州の大リーグチームはNYヤンキースだ。今ではアメリカ人＝ヤンキーという使い方も一般的だ。
一方外国がヤンキーという場合は大抵が罵倒語だ。でも当のヤンキー達は気にせず使い続けた。
日本の『アルプス一万尺』はアメリカの愛国歌、ヤンキードゥードゥル Yankee Doodleの歌詞を勝手に改変したものだ。
元は独立戦争に先立つフレンチインディアン戦争時に参戦したアメリカ植民地軍を揶揄した歌だった。
軍服も揃えておらず統率も取れていない、キビキビも出来ないアメリカ人達を正規軍人の英国人達が嗤った歌詞だ。
doodleとはダラダラテレテレしてる、ボケっとしてる、暇なのでイタズラ描きするってな意味だ。特別な日にGoogleロゴが特別なモノに変わるアレもdoodleだがこれは最後の意味のイタズラ描きって意味だな。
そんなアホアメリカ人が手入れもちゃんとしてるか判らん鉄砲持ってテレテレタラタラやってきたよ、あーあ。ってな感じの歌なんだな。
「いなかっぺのキョロ充が街に行った。羽付き帽被っただけでダンディのつもりだ。イカしてるねぇ神聖モテモテ王国だねぇ」
ところがアメリカ人たちはこの侮蔑的な歌を気に入ってしまった。それで自分らの歌としてしまったのである。
独立戦争で歌われ演奏され、独立後の米国軍の行進曲にしてしまった。
ペリーが日本にやってきた時に上陸後は鼓笛隊の演奏で行進したのだが、その時の曲はヤンキードゥードゥルだったのだ。
こんな風に建国の初めからしてこうなので、「罵倒語を気に入って使い始める」というのは後にアチコチで見られるようになった。
思いつく限り列挙してみたい。
The blackとかblack manとか使われていたが、肌の色を直接に示すので差別的だった。特にトイレやバスの座席、施設の入り口の区分けなどで「black」「colored」と書かれていたので猶更である。
だが公民権運動で「ブラック イズ ビューティフル」のスローガンが使われると当事者のプライドと結びつき、やがてblack musicなど一般化された。
南部の白人の事で、農作業で首が赤く灼けた様をからかった語で、保守退嬰的、閉鎖的、進取の気性が無い、低学歴、民度が低い、反国家的など酷い意味が凝縮された罵倒語。
それは「なんでも自分らでやる」というライフスタイルへの愛着と自負で、南部の農家は食料の入手から機械の手入れ、家の修繕、家具の作成、車の修理や改造など、何でも自分でやる。これは日本の農家なども変わらない事で、全体的に器用貧乏だったり詰めが甘かったりするが都会の人間からすると広く何でも出来るスーパーマンみたいに見えるものだ。
以前、トラクター会社が機械部分をブラックボックス化して信頼性を上げる代わりにメーカーじゃなきゃ修理できないようにしたら大炎上した事があった。https://jfaco.jp/column/2435
「レッドネックスタイル」を理解していなかったのが原因だ。これは米国では結構大きな問題になり、欧州の「修理する権利」と結びつける形で法制化が進んでいる。
日本メーカーやアップルが欧州の「修理する権利」で叩かれて電池交換や社外インク可能にさせられているが、この背景にもこの「何でも自分でやりたい」というマインドがあるのを忘れてはいけない。金と財産権の問題にしか見えないのは飼い慣らされている為だ。
だから今では米国外で何でも自分で作ってみる、直してみるのを動画にしているDIY youtuberなどもレッドネックを自称している。
Queerは元々罵倒語で変なやつ、男性同性愛者（婉曲）とかの意味だったのだが、意味が逆転されてポジティブな意味になった。
1985年のバロウズ著『Queer』の日本語は『おかま』だ。この題は訳者の山形浩生が付けたのか？ちょっと意味が違うと思うのだが。つーか、1985年でも男性同性愛を一緒くたにおかま呼ばわりはしてなかったんじゃないか？どうも腑に落ちない邦題だ。
Wikipediaには頭でっかちな事ばかり書いてあるが、実際はドラッグクイーンとかのワザとらしい性的倒錯仕草をクィアとよんでたのが、マジのトランス女性などが世間に認められるようになると（イスラエルのDana Internationalなど）弾き出されて「LBGTに収まらない性的違和」を是認する意味になったとう感じだ。
この辺の変化、日本だと90sドラッグクイーンの代表格井原秀和円奴S（まるやっこスーパー）が女性目指すようになったのが象徴的。90sのクィアポジティブ化は米国のハウスシーンと共にあった。
ロバには馬鹿、間抜け、グズ、ウスノロ、ノロマ、うすらバカ等の含意がある。
勘違いしてはいけないのは、当初の民主党は南部の農民が支持層の保守政党で黒人奴隷解放に大反対していた。民主党、共和党共に今と支持層、支持地域が逆転しているのである。
大統領選で、そんな南部の民主党出身の大統領候補、アンドリュー・ジャクソン（Andrew Jackson）をスマートで都会的な北部の共和党の議員たちがjackassと詰って呼んでいた。jackassは雄ロバの事だが、馬鹿、間抜け、グズ、ウスノロ、ノロマ、うすらバカ等の意味もある。
これをレドマツさんじゃなかった、アンドリュー・ジャクソンは気に入ってしまい、「アンドリュー・ジャッカスです（観客ワハハ）」とか自陣の象徴として使ったのである。
それでその後もそのうすらバカでグズで間抜けの象徴であるロバを大統領選で使うようになって今に至るというわけだ。
ビデオチャットで「いい女やな～」「ぎゃ！ちんこある罠や！」っていうイタズラが元々なんだけど、すぐに生えてないなら興味ないっていう増田みたいなのが増えてtrapは売りに。
これはアメリカの伝統関係あるだろうか？3％ぐらいは関係ある気がする。付いててお得だし。
1987年のブライアン・デ・パルマ『アンタッチャブル 』では主任捜査官エリオット・ネスがガサ入れでヘマした所を記者に写真に撮られ新聞のトップ記事にされ、その記事をオフィスに貼るシーンがある。
これもアメリカの伝統があっての事なんだろう。屈辱に耐えるのではなく、「侮辱を気に入る」のだ。それが先人がしてきた事だから。
という訳で単にいつの間にか意味が逆転してしてしまうのではなくて、アメリカの場合「侮辱を気に入る」「恒久的に自分の表象にする」というコードがあるのだ。単に悪口を逆手にとって「○○ですが何か？」というのと違うのはその語をずっと使うって事だ。逆手に取るのとは違うマインドなんである。
だからニガーを当事者だけが言ってもいいというのはこのアメリカ的伝統の過渡期にある可能性があって、そのうち普通に使われるようになるかも知れないって事である。
だったら差別語は何言ってもいいんだな、とか言って差別発言で炎上して失職したり家が突き止められたりというバカが出るのもネットの常である。
半導体に関するネットのコメントを見ていると、衰退から立て直すための戦略って国家でも難しいと感じる。
あれやこれやと駄目な理由をずっと言い続けるか、銀の弾丸のように単一アイデアに集約される。
半導体のような工程とグローバルで材料や技術が分かれているものだと、分析が出来る規模ではないようだ。
給湯器が半導体が足りないって話の場合、普通に考えれば、その半導体を作っている企業なり、材料を生産している企業の名前が出てくるはずなのに、
インテルやAMDが量産すれば解決するとか、TSMCの工場が日本にできればって話になっている。
半導体にかぎらずだが、BtoBに関して、ブラックボックス化してしまっていて、分析するための情報も得られてないのではないか
ブラックボックステスト (英: black-box testing)は、内部構造や動作を覗き見することなく、アプリケーションの機能を調べるソフトウェアテストの手法のこと。アプリケーションを見えない箱として扱い、入力と結果の整合性を確認する。このテスト方法は、ソフトウェアテストのすべてのレベル（単体テスト、統合テスト、システムテスト、受け入れテスト）に適用できる。仕様ベースのテストと呼ばれることもある[1]。
「ブラックボックス？飛行機に付いてるやつ？」という反応が多かった。
ドッグフーディング (英: dogfooding) または「自社のドッグフードを食べる」「ドッグフードする」(Eating your own dog food、Drinking your own champagneとも言う)は、コンピュータ業界において、自社製品を開発して利用する組織の習慣で[1]、組織が実際の使用法で日々自分たちで製品を利用しながら製品テストを行うことである。日本語では単に「ドッグフード」ということもある。そのため、ドッグフーディングは品質管理として機能し、開発者自身による製品の自信を表す証言広告となる[2][3]。尚、日本企業では自社実践(じしゃじっせん)という言葉が相当する意味の言葉として使われている。
それがどうだかは知らんし実際数量的にどうであろうが関係はないので、とくに問題はないだろう
あとパパ活というのはパトロン活動みたいなものが基礎になっているのではないか
売春目的で最初からパパ活ということで探している両者は勘違いしていると思う
もとより売春行為が目的なら「大人の関係」ないし「大人」または「関係」、旧名「割り切り」だろう
基本的にはデートをしてお金をやり取りするキャバクラ同伴・アフターの個人営業みたいなものがパパ活ではないか
感情やら価値観やらは置いといて「関係」の話でいうとキモイとか問題が多いとかそういう話はぶっちゃけ聞かない
一番多いのは「ひやかし」「ドタキャン」あと交渉に入る以前に「説教」と聞く
20歳の男子が毎月呼んでくれる50歳過ぎのおばちゃんとか、広い戸建てに一人と犬一匹で住んでる医者の家に定期で呼ばれる30歳とか
アパレル店の店長をしているという20歳過ぎの子はどうやらそのアパレル店の店長が野良デリヘルみたいなことをしていて派遣されてきたっぽいとか
合計100例くらいなので母数はあんまりないけれど、そう悲惨な話とかひどい出会いの話は聞かない
一人だけどうやら騙されて野良デリヘルをさせられてるっぽい家出娘みたいな子にはあったが、まあそういう日もあるだろうという事で話を聞いておわることもある
女子大生っぽい子がどうやら処女を捨てたくて形だけしたくて来たっぽい子もいた
こちらも都合のいいタイミングで都合のいいパートナーが調達できればたすかるし、相手もお金以外は求めてないので双方トラブルになったり問題や行き違いがあったことはない
キモいおっさんが汚いリュックを背負って臭いシャツのまま入っていくのを見るのは早朝の風俗店なのだがどうだろうか
すこし早く出勤すると通る繁華街で日の出から営業している風俗店に入っていくのを時折みる
几帳面なサラリーマンっぽいシャツにスラックス、四角いリュックに動きやすい靴のおっさんは一人でホテルに入って行ったりするところを見る
それはおそらくデリヘルだろう
それぞれに求めているサービスがわかれていて、それらがかみ合うことは非常に少ないと思うが性欲旺盛おっさんのあつまりみたいなところで座談会したわけでもないので知らん
関係の待ち合わせはホテルから一定の距離離れたあたりの角で待ち合わせが定番化しているところがあるようで、見ればわかる
何人かの定期とその子らが都合あわないときは野良と会ったりするおっさんから見ればこんな感じだが、なんか一番悪い例だけをとりあげて全体のイメージができてる気がしないでもない
とくに他人の幸せや不幸をどうしようと考えてるわけではないので、自分はとりあえず円満ではあるのでどうでもよいことだけれども
とりあえず問題が発生してない関係の経験者が話をして情報交換することでなにか改善ができるのではないか
採用前に企業が就活生の「裏アカ」調査、たった数十分で特定も 過激投稿の“無法地帯”を見て人格把握
学生側の受け止めは複雑だ。都内の私立大３年の女子学生はインスタグラムを利用している。裏アカには、愚痴や他者の中傷を投稿している友人もいると言う。だから「企業が学生の本音を調べたいという気持ちも分かる」と一定の理解を示しつつも「間違った調査で、自分のものとは違うアカウントを基に判断されないか不安はある」。
一方で、こうした調査には危うさもある。他人に知られたくない本音を投稿したアカウントを調べることで、学生の出自や思想信条を把握する可能性があるためだ。利用の仕方によっては、就職差別につながりかねない。
職業安定法は採用活動で人種、思想信条などの個人情報の収集を原則、認めておらず、収集する場合は同意が条件だ。厚生労働省も配慮すべき事項として身元調査を挙げ「就職差別につながる恐れがある」と指摘している。厚労省担当者はＳＮＳ調査について「一概には言えない」と前置きしつつ、思想信条などの個人情報を収集する恐れが高い点を挙げ「好ましくない」との見解を示している。
一方、企業調査センターは「企業側が採用プロセスで学生に同意を取っているので、法的に問題はない」との立場だ。
こうした点を識者はどう見るのか。岩手大の河合塁准教授（労働法）は、調査自体は違法とは言いがたいとしつつ「本来集めることが禁じられているデリケートな情報まで手に入れてしまうことがあり、本人が知らないところで把握するのは問題になる可能性がある」と指摘する。
さらに「企業側もＳＮＳ情報で不採用にしたとは言わず、調査したこと自体開示する必要はないので、企業側がどういう理由で不採用にしたかが学生には分からず、ブラックボックスになっている」と分析する。調査される可能性があることを把握していない学生もいると言及した上で「どういう目的でどう調査するかを企業側は、あらかじめ示すことが必要だ」と話した。
ここでもよく職場の不満日記を目にするけど、たいてい仕事が増やされたとかそういうのが多い。
基本給10万、他は抱えてるタスク作業ごとに何万円、ってすればいいじゃん。
タスクが終わるなら何時間かけてもいいし、何時間休んでもいい。
これ究極じゃん。
あの人はあれだけもらってるのはタスク多いから当然だ、って納得するし不満もない。
あの人は家庭の事情でタスク少ないから給料も減るしみんな納得。
これでみんな納得で仲良しな職場になる。
今も使われてる「なんちゃら手当」だけにするイメージ。
ベースサラリー＋顧客Ａ見積作成手当＋顧客Ｂアフターフォロー手当、みたいな。
＜追記＞
手当が大項目だけだと、
顧客Ａ対応手当と顧客Ｂ対応手当は、規模が違うのに不公平じゃん！となる。
それさえしっかりできてれば、
まあこれができるのはせいぜい数百人規模の会社までかなあ。
＜追記２＞
https://youtu.be/iGZUJLjtGWo?t=213
＜Q＆Aコーナー＞
世の中のサラリーマンってそんな同僚の給料とか仕事量とか把握して
5000円でも違ったりするとギスギスする。
中途で入ってきて、役職が高かったりすると、まず古参の平社員とトラブルになる。
「なぜあいつのほうが多いんだ！」というのは、判断基準がクリアじゃないからで、
もしそれをクリアにできれば、
究極の民主主義じゃん？ってことで書いた。
基本は同じ発想ですよ。
営業マンと開発・間接部門がギスギスするのはコミッション性と固定給制の違いも一因としてある。
少なくとも不公平感がなくなるかなと。
これは書いた直後に思った。
少人数だと談合とかが起きるのは明白で、だから全社で透明にするしかないですね。
あと、給与も全員オープンにすることが前提となるので、まずそこがイヤな人は入ってこないから、
そういう人材がキックバックとか談合を好むとは思えない、ってのはあるかも。
「自分は今月これだけのタスクをやったので給与アップを希望します」
って言える人が入ってくる。
これを公平に達成するには、一社だけだと厳しくて、絶対にブラックボックス化する。
タスク内容を国レベルでオープンソースにしないとだめかもしれない。
ああいうかんじ。
「Ａ社ではこれこれタスクを〇〇円でやってました～」って実績で活動すれば、
「ウチでは〇〇円ですが大丈夫ですか？」みたいな。
それこそ資本主義じゃない？
「本日は良いお日柄で・・・」「趣味はなんですか？」「ｱﾊﾊﾊﾊ…（ちいかわ）」
そこでオープンソース化ですよ。
JDに書かれているタスクと募集職種でだいたい平均値に収れんしていくはず。
同業種で業務内容がめちゃくちゃ違うなんてことはないんだから。
まとめたら国が基準として発表する。
今までになかった新しいタスクの時にどうするか、は、
それをベースに毎月全社員で固定タスクの単金に落とし込んでいく、みたいな。
そのために、参考にできるオープンデータ（勘定項目）みたいなのがあればベスト。
50項目も抱えてれば、明らかに給料高くても誰も文句言えない、みたいな。
むしろ「この毎月発生してるトラブル解決タスクはなんですか？」と、
突っ込まれてやりづらくなりそう。
すべてガラス張りのタスクになるから、闇でやるのが好きな人はいろいろ不都合感じそう。
まあ実現性はともかく、
「スキルの希少性」は、その人の財産になるのでは？と思ってる。
今の正社員システムは、スキルの希少性がない人ほど、転職できなくなる。
他社で使いまわせないから。
逆に会社としては都合がいい。
とがった人材を作らせない。
これで飼いころしにできる。
成績表の英語数学美術体育でオール3の人材を作る。（忠誠度だけは5）
これがほとんどの会社員の、「月曜日に仕事にいきたくない病」の、
遠因なのではないかな？と思ってる。
今回は、どれかを5にしてほかは2とか1でいいという案ね。
タスク量を定量評価して、人事に反映させるのが上司の仕事なんだけど、日本の場合は給料払えば定額使い放題と思ってるから、優秀な人間の評価ができない。お金を稼ぐには残業。優秀かどうかは能力ではなく（時間）
ある意味、処女を開発して洗脳させるのが新卒採用だからなあ・・・。
経営者には都合がいいのだろうけど。
時間給だと、どうやって一つのタスクにかかる時間を延ばすか、にスキルポイントを振ってしまうのはあると思う。
結果として、その人の能力50%も使ってないってことになるのでは？
JDを明らかにして、その人が意識的にスキルをチョイスしたほうが、長期的にはいいと思うけどなあ。
完全歩合制みたいなの考えたりもしてたけど、結局それやりだしたら無能が弾きだされるし、
効率最優先になって、どんどんいらない仕事が減っていく（失業者だらけになる
そろそろおかしいんじゃね？と気づいていいんじゃないかっていう。
まあ効率最優先になると、国レベルでどんな弊害が出るかもしれないし。
なので10万円っていうのは、ベーシックインカム・セーフティネットのつもりで書きました。
まあAIやRPAが発達すると、多かれ少なかれそっち（効率優先）の方向になっていくのかと。
そういうことができなくさせるための仕組みづくりが、今回のアイデアって感じですね。
民主主義を捨てると何が起きるかってことが。
ほかの社員への協力というのもタスク化されるから、それも成果として可視化される。
あと、このモデルが仮に実践されるなら、教育も必要なくなると思ってる。
最初からタスク内容が100%分かって入ってくるのでミスマッチがない。
風通しについては、
給与とスキルデータが全社員に可視化されるから、全員スケルトン状態。
誰もやりたがらないタスクは少しずつ対価が値上がりしていく仕組みとか試してみたくはある
これは思いつかなかった。
これができれば究極だよね。
明らかなブルシットジョブでも、誰もビッドしなければ値上がりして、最終的に誰かが食いつく。
MSはバルマー時代にこういう評価制度を導入したら皆が自分の短期的成果に繋がる仕事だけする状態になったので、ナデラCEOが「他メンバーの評価に貢献したら評価ポイントがつく」という制度に改革したという逸話がある
「マネージャが自分の仕事やキャリアを助けてくれる」のあたり。
https://www.publickey1.jp/blog/22/1_regional_scrum_gathering_tokyo_2022.html
そんな回りくどいことよりやっちまえよ、セックス
やっちゃえ日産
デレマス（デレステ）で今夏以降開催される総選挙……ではない、後釜イベントStage for Cinderellaのシステムへの感想とか、あとは誰が上位に入りそうかの下馬評。
誰は行けそうだ、誰が本命で誰が大穴、誰は厳しいんじゃないか、そういう話題をアイドル名を伏せずに出すので、そういうドラフト生みたいな話題がダメなヤツはこの時点でブラバ。いいな。俺は言ったからな。
仕組みは割愛する。簡単に言うと190人を4ブロックに分けて予選、予選上位5名＋プレーオフの21名で本戦。予選上位5人x4組にそれぞれ楽曲（＋声）、本戦上位5人に楽曲(＋衣装SSRもろもろ＋声）、本戦一位がシンデレラガール。
CG狙い陣営はウオーミングアップ、ボイス陣営はここが本番、「CGは無理だけど曲はあげたい」って陣営はいるかも（あまり興味がない）。第7～8回ぐらいの温度感 (( 人気投票とボイス争奪戦のバランスとして )) の総選挙が4ブロック開催されんじゃねえかなあという気がする。大前提として人気投票で、そこにボイス争奪戦がどこまで絡んでくるかという話だが、運営はあまり「ボイスが付く」というところをフィーチャーしたがらないし、ボイスがないキャラに無関心でもデレステは楽しく遊べるゲームなので、結局この形式では人気投票に近くなる（＝声付き有利になる）……と思うのだけど、「よくわからないけど、たくさんボイスがつけられそう」とか「5票あるからボイスにも票を回せそう」という反応を自分の狭い観測範囲の中でもたくさん見かけるので、自分が思ったよりボイスへの流れがあり、各ブロック新ボイスが1、2枠、という感じになると思っている。
ボイス、8回以前は前回以前の結果や中間発表もあり「勢い」みたいなのが観測できたが、9回10回は3人固定、結果発表も中間なし上位のみとかなりのブラックボックスで、しかも蓋を開けてみれば「総選挙票のついでのボイス票が大勢を決した」みたいな結果だったので、ボイスへの広報活動の手応えが得られない問題を有していた。今回はボイスへの期待感に加え、「決まった投票先がなく手持ちの票を余す人」（これまでも居たには居たが、これまでのそういう人はただボイスに関心がなかった人なのに対し、関心がある人がそのような立場になりうるというのは9回10回より健全そう）が確実に発生するので、広報活動の手応えがわずかなりとも得られる環境に戻りそうなのは素直に嬉しい所。
あと、「5人投票できる」というのが結構曲者で、自分で入れた票が推しへの妨害になりかねないというシステム的な問題がある。それを解決するために「投票しない」とか「全員に同じだけ投票する」とか「明らかに推しより上位の子に捨てる」とか「明らかに上位に入れなさそうな子に捨てる」とかいう戦術が編み出されるのは当然なのだが、それが広まりすぎるとなんか途中でシステム変更とかになっちゃいそうな。そこは運営さんの腕の見せ所なのかな。
普通のCG決定戦に落ち着くだろう。予選でボイスが付いた枠の子がここで善戦するとはあまり思わない。ただプレーオフからボイスなしが上がってきたなら強烈なブーストを受け5位くらいには入るだろう、予選から上がってきた子はこの時点でボイスがあるので、CG争いに興味がないがボイスに興味がある人の関心を一手に受け、更に「プレーオフから上がってきてボイス付与」という強烈な物語性を持ちうるからだ。俺もプレーオフがボイスなしだったらこの枠に入れる。
順当にCGを狙える子が、ここを戦ってCG争いへというのは正直考えづらいが、何らかの物語……「この子は逆境にめげず何度も這い上がって」みたいな物語を持つ子が――いるのかは知らないが――ここを勝ち上がって本戦に行く可能性はワンチャンありそう（ただそれが本戦で勝つかというと……）。そうでなければただのボイスおかわり枠。まあほぼ後者なんじゃないかなあ。各ブロック上位15まで発表するってすごいなと思ったが、よく考えたら全体60位までだからあまり変わってはおらんのだな。
属性の枠組みがなくなったのがちょっとヤなカンジではある。クール有利パッション不利じゃなかろうか？
わがんね。ただ思うのは、なんとなくの民意として、CG二冠は避けられていたように思うのだが、10回の区切りと枠組みリセットの影響で「二冠」は全然発生しうるな、ということと、CG未経験勢の勢いをあまり感じないこと。よって現時点では◎楓 。 未経験から競ってくるとすれば、○奈緒、○志希、▲美嘉、らへんかなあ。去年のPa順位的には藍子なのだが、CGになる勢いがあるとすれば美嘉な気がする。難しい。
U149での出方次第。もし――そんなことは絶対にないと思うが――「U149では声はつかない」ということが確定したら大炎上とともにすごい勢いになると思う。いや自分で言っててアレだがそんなことは普通無いな。てか、ボイス付くなら、それは始まる前に教えてくれないと困るのだが……。もし不確定のまま本戦に突入した場合、死票を嫌う人たちからはむしろ敬遠されそう。
U149の出方待ち、というカンジではあるのだが、もし、「小春にだけ声が付くことが確定する」みたいな事態があれば、小学生Pさんたちが奮起するシナリオはありうる。ただその可能性は弱め……かなあ……。
ずぅっと候補にいるのにずぅっと報われない子という印象で、今回もやはりプレーオフ圏内程度で終わるのではないかな……。「普通の子」が特徴というのは強い訴求力に欠ける……。
「フリスクに声を」って多分フリスクが登場してからずっと言われていて、でも総選挙とかだと全員同時にっていうのは厳しくて、柚のボイスがサプボの呼び水になることも特になかったので……結局、地道に一人ずつしか無いと思うんだが、じゃあ票を誰に集中させる？ってところのコンセンサスが応援する人たちの間で取れていない、という感じがする。過去の結果的には忍がやや有望だったと思うが、それで忍が行けるかというと、決定力に欠けるような気も……。
ゆかさえイベの抜擢に加え、ノーブルセレブリティのpushも感じるので、要素だけ見ればすごい強そうなんだけど、素地が少なめでまだいまいち伸び切らないか……？という感じはある。お嬢様枠、からの差別化ができればあるいは。
うーん、マシーナリーとも子のインパクトが強すぎて、その異常な活躍をどう評価すればいいかわかんないんだけど、順当に人気は感じるのでなんだかんだとボイスまで行けるんじゃないかなあ。あと眼鏡枠。
この間のライブもそうだがかなり公式からの（沙理奈よりはブルナポの）pushを感じる。ただなかなかチャンスを掴めず、サプボにも値しないと判断されてきたであろうので、思ったより強くねえんじゃねえかなあ……。ブルナポがあと沙理奈さんだけってのは結構長く擦られてきたというか歴史があるので、プレーオフで強い、みたいなことはありそう。
金髪褐色碧眼で、ナターリアの相棒枠でもあり、そういうのが好きな人の票を持ってそうなイメージ。すごく強いイメージはあまりないが、もしかしたら……？
このおねーさんの魅力は単純に顔面の強さなんじゃねえかなという気がするので、普通に善戦はしそう。ただ辛い物好きとかにゃんにゃんにゃんとかギャップの部分が上位に食い込むだけのセールスポイントとして機能してないような印象は受ける。
際立った特徴はないが距離が近くてポジティブでCo詐欺、結構色んな人の「ボイス無しではこの子が好き」枠に入っているイメージ。ボイスまでありそうかなー。
割りとみんな好きだと思うが、未知数……一歩届かない、くらいの位置か。アニメPVへの期待が逆風として機能してしまわないかなあとは思っている。でもPVで蒸機公演があれだけってことはないだろうし、案外アニメで声が付くのか……？
オタクはクールで馴れ馴れしくて機械に強い女の子が好き（ド主観）なのに加え、七海とマキノとのファタモルガーナの流れもありそうで、強いだろう。ド本命読み。
いま一歩という感じはするが、「U149で小春、千佳、舞にボイスが確定」という限定的なシナリオではかなり善戦しそう。そんなことは……あるかな……いや、あるかも……。
いつぞやのエイプリルフール、限定SSR、この度の凪背景と、かなりpushを感じる。あきらとの交流も強めの要素で、Paでボイスまでこぎつける子がいるとしたら紗南だろう、という感じ。
今回のダークホース。とはいえ流石にダークホースで終わるか……？でも限定が三種も出るぐらいだから何かしら一定の実績はあるんちゃうかな。
というわけで俺は、CG高垣楓、新規ボイスは池袋晶葉、藤居朋、大石泉、三好紗南、松本沙理奈、計5人で提出するぜ。アディオス。
是非はともかく、やるとしたらこうなるんだろうなという予想。
まずこれが前提事項となる。今回女子で金メダル取ったイギリスのチームは、1年前とはメンバーが2人入れ替わっているが、半年前の世界最終予選とは同じメンバーだ。
カーリングは春後半～夏がシーズンオフになるので、その間に人を入れ替えることが度々行われる。五輪を契機に大きなガラガラポンが行われることが多いが、年1のシーズンオフでも1～2人くらいの入れ替えは時々ある。
一方、サッカーみたいに試合ごとに代表を選抜して入れ替えると言うことは、そのイギリスでも行っていない。例外は、メンバーがケガして競技不可になった場合の補充だけだ。
選抜制の弊害ともいえるが、イギリスも中国も国内で試合が出来る環境にない。相手がほとんどいないからだ。言い方は悪いが、選抜から漏れた残りの人達をかき集めてチームを組んでもロクなチームはできない。そんなチームにスポンサーはつかず、まともに活動することも困難。そのため、選抜制の場合、必然的に海外にずっと出て強化することになる。
今のクラブチーム制は、代表選定のプロセスとしては非常にガラス張りである。日本選手権で良い成績を収めたチームが代表決定戦に集い、その中で最も良い成績が得られたチームが代表になる。納得するかどうかはともかく、プロセスとしてはとても明確でガラス張り状態だ。
それ以上に問題なのは、代表選出に対して批判の嵐になる事が不可避なこと。
常に20人以上代表が選ばれるサッカー代表でさえ毎回「なんでこの人がいるんだ！（最近の事例では長友選手など）」「スポンサー枠じゃないかコイツ！（事例多数）」「この人は監督の愛人枠だね（森保監督の広島時代の教え子だった佐々木翔選手に対する揶揄）」と騒がれる傾向にあるのに、4人か5人しか枠が無いカーリングでそんなことをやったら「コイツは枕営業したのか！」という下衆な勘繰りが大流行してしまうのがオチだ。枕を実際にはやっていなくても、タブロイドメディアが放火してくることは避けられない。「カーリング娘」とか「クリスタルジャパン」とか「そだねージャパン」ではなく、「枕ジャパン」と呼ばれるようになるだけだ。
それを回避する策はない。
候補を20人くらい選んで、その中から4人選ぶ方式で多少の緩和は考えられるが、20→4の段階で結局同じ事が起こる。20人を5チームに分けて決定戦やるという手もあるが、それだと今のクラブチーム制と実質的に変わらないから選抜制にする意味がない。
別の切り口では、イギリスがやってるように「スキップに選ばせる」という手があるが、そのスキップが集中放火されるだけだ。
サッカーのような選抜制を想定して「カーリングも選抜制にしろ」と言っている人に対して、「あなたの想像している選抜制とは全く違うものになるよ。サッカーの選抜制の悪いところだけは受け継がれるが」とだけ言っておく。
イケてるエンジニアもすなるLaravelといふFWを、底辺チンカスエンジニアの私もしてみむとてするなり。
フレームワークとか逆に難解すぎてやってられねーよ！と今まで拒否し続けてみたものの、なんか人気らしいので気になったんですよ。
で、公式サイトのクイックスタートを見たら、１行目からこれですよ。
Composer？ アホかと。バカかと。お前らな、依存管理如きで余計な要素を増やしてんじゃねーよ、ボケが。
名前は知ってるが使ったことないし、ちょっとググってもよく分からない。分かろうとも思わない。思えない。もともと頭が悪い上に中年なので学習意欲もわかない。
終わりです。終わりました。ハードル高すぎるんですよ。
Composerで手軽にインストール！
って、Composer自体が手軽じゃないんすよ。
ComposerだのAnsibleだのDockerだの超絶魅力的だけど全然意味わかんないっすよ。俺くらいのバカでも分かるように作って欲しいんすよ。
結局フレームワーク使って何かハマった時にブラックボックスすぎてかえって面倒なことになるので（≒言い訳）、俺はこれからも自作FWでやっていきます。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
