  |
はてなキーワード: 使用とは
＞北朝鮮は弾道ミサイルと核兵器の能力を整備していますが、あなたは北朝鮮はそれらを使用しないと思っているんですか？
竜とそばかすの姫 越知町、高知県高岡郡から 田園調布 夜行バス使用 夜行バスは横浜YCAT バスタ新宿 東京鍛冶橋のいずれか着で 800キロメートル強
ドライブ・マイ・カー 上十二滝村は架空の地名なので ①原作小説初出と同じ中頓別町とすると または ②北海道南端 とすると
①仙台回ると2200キロメートル強、（日本海側新潟・秋田回ると2100キロメートル前後） 渋滞なしで29時間（Google調べ）
②函館駅裏として1500キロメートル前後、渋滞なしで22時間（Google調べ）
往復 3000-4500キロメートル、不眠不休、フェリー待ち時間ゼロで45時間かかる。距離だけならルート66の全長（4000キロメートル弱）といい勝負だ。
とは言え、移動は往復でも、中頓別から電話で広島国際演劇祭のプログラマー柚原（演：安部聡子）に電話すればいいと考えれば29時間以内でクリアできる。
これ、「感染症対策のため不織布マスクをしてください」とお願いしても「あ？国が配布してるマスクだぞ！何か文句あるのか？」で性能の低いマスクを使う輩が出てくる悪手なんだよなぁ。
「当時は緊急性を鑑みて布マスクを配布しましたが、その後の研究の結果、不織布マスクの効果が高いことがわかり、また供給も十分にされているため、今後は布マスクは使用しないでください」とか言ったほうがまだマシだよ。
クリミア半島のときもロシアがクリミアを手放すなんてことありえないと、
ある意味ロシア以上に理解しているから形ばかりの抗議で終わったわけだし。
繋がっていった、というのが第二次世界大戦だった。
十数年使用した冷蔵庫が壊れそうなので、新しい冷蔵庫を買いに電気屋に行った。
我が家は氷を使わないので、製氷機にスペースを割いてほしくない、これでまず買える冷蔵庫が大幅に減る。
チルド室狭くして水を入れたり、引き出し一つ丸々氷コーナーだったり。いらん。
今はチルド室が二段になっている形が多いようで、焼肉セットなど分厚い肉の容器を入れられそうにない薄っぺらいチルドルームが多い、これも不便そうで買いたくない。
背が低いので高さは175以下で容量は最低350リットルは欲しい、これがもう絶望的にない、どれもこれも180センチオーバー、前回は高くない冷蔵庫沢山あったのに、何でそこまで大型化したのか。
野菜室は白菜大好き人間なので白菜を丸ごと立てて入れられるスペースがほしいが、これも意外とない。
ペットボトル飲料なんて飲まないのに、野菜室にわざわざペットボトルを立てるコーナーを壁で区切ってる冷蔵庫まである、いらん、自由に野菜を入れさせろ。
前回買った時からAQUAとかいうメーカーが増えていたので店員さんに聞いたら、SANYOの技術者が中国メーカーに事業譲渡されて作ってるメーカーらしい、なんか切ない。
結局何も買えずに帰ってきた。
何か買わないといけないのに本当に困る。
まあ子供だった俺が全て悪いんだけど。
我が家にはトイレが二つある、1階の皆が使うトイレと2階にある今は俺しか使わないトイレだ。
中学生の時はじめて我が家にウォシュレットが導入されたが、俺は尻に水を当てるとか怖くて一度も試さなかったし、使う気にもならなかった。我ながら中坊の癖に好奇心が足りない。
いつのまにやら家族は基本1階のリビングで、俺が2階の自室に引き籠もるようになってトイレの専用化が発生した。この頃から俺の趣味にトイレ掃除が加わったが今回の主題から逸れるので割愛する、一言だけ残せば手間を省けばトイレ掃除は楽しくて気持ちいい。
閑話休題、それから数年後、電気代節約のためにトイレ使用後に蓋を必ず下ろすようにしよう、と父親が言いだした。
当時の俺は普通に面倒だから嫌だと感じたし、手間を惜しむ為なら多少の不便はどうでもいいという思考を持っていた。
ので、便座のコンセントを引っこ抜いた。
どうせ俺しか使わないし、便座冷たくても耐えられるし、節約にもなるから文句あるまい、と思ったし、事実強くは言われなかった。
いや、ウォシュレット初体験そのものは4、5年前だったかな？ 理由はもう忘れたが、外出先、どこかの店舗にあった綺麗なトイレでさ、ふと思いつきでウォシュレットを使ったんだ。
いや最高だなウォシュレット？
尻が楽に綺麗になるじゃん、これは文明の利器だよ、使わないのは損だ。
と思ったものの……さて今さら自宅のウォシュレットに電源入れるか？ 入れたとして20年ほったらかしの管を通って飛び出す水を尻穴に当てたいか？ と自問自答するとどうしても拒否反応が出る。
俺から言いたいのは無闇に手間を惜しむなということと、好奇心を持つことは大事、そして無駄な意地は張らないほうがいい、ということだ。
陰毛をなんとかしたくて仕方なかった。当増田は30代女性、陰毛は非常に濃く、かつ広範囲に生えている。ある夏の生理で不快感に業を煮やし、とりあえず剃ってやろうと思い立った。闘いの始まりであった。
【評】お察しの通り。あちこち切るわ伸びるとチクチクするわで地獄。生理直後で皮膚が荒れていたであろうことも拍車を掛けた。
【評】熱線で焼き切ることで毛先が丸くなり、チクチクしないとか。「遊女は線香で処理してたってのはこれかァ…」と感慨。粗いクシに熱線が渡してあるような形状の製品だったが、毛量に負け2回で壊れる。使用感は良かった。
【評】第2戦でカサが減れば楽になることが分かったので、断面さえスパッとしていなければチクチクしないのでは？と対戦。あっという間に詰まった。
【評】このころ読んだ「パイパンにしたらマジ快適」みたいな増田で除毛クリームを使っていたのに感化され対戦。もちろん大敗。定刻置いても毛が溶けず、数分おきに様子を見ていたがヒリヒリしだしてギブアップ。二度としない。
【評】剃っても切っても溶かしてもダメなら抜くしかないのでは？と対戦。さすがに自分でビリっと剥がす度胸はなかったので、ホットペッパーで安いサロンを予約。いざ施術、痛い。クソ痛い。特にVとIの境目がヤバい。目から火花が出る。毛が多いせいか、サロンのお姉さんも明らかにダルそう。フラッシュ脱毛をお勧めされるが丁重に断る。施術後はさすがに快適だったが、埋没毛が生じたことや、何より痛すぎたので二度とやらない。
【評】サロンの脱毛勧誘は断ったが、結局根本を死なすしか解決策はないんだな…と決意。脱毛器はワキに使っているレーザー式のトリアがあったので、それを転用することに(メーカー非推奨なので自己責任)。
問題は①脱毛前に一度毛を剃る必要があるが、過去にカミソリ負けの経験がある②ワキでもまあまあ痛かったレーザー、果たして陰毛で耐えられるのか？の2点。まず①の解決策としてパナソニックのVIOシェーバーを購入。これが予想外に良かった。むろん宣伝文句のようにツルスベにはならないが、刃が詰まったりパワーダウンすることなくバリバリ剃れる。皮膚も荒れにくい。
そして②だが、メッッッッッッッッッ痛い。出力を最弱にしても痛い。ワキとは比較にならない。第5戦と同じく、VとIの境目は特にヤバヤバのヤバである。ワックス脱毛とはまた違う痛み。インターネッツで対処法を調べ、事前に鎮痛剤服用＋麻酔成分を含む一般薬(ラナケイン、ボラギノールなど)＋保冷剤でだいぶマシになった。インターネッツには感謝しかない。
初回はさほど効果を感じられない上にヤケドっぽくなり凹んだが、繰り返すうち「あれ…？気持ちカサが…減った…？」という状態に。心なしか生える・伸びるのも遅くなってきた。これはいよいよ増田側の勝利が見えてきたのでは…？？
七番勝負って語呂がいいかなと思ったがそこまで行ってなかった。
これまでの敗北を振り返ってみれば、世の陰毛処理の体験談がいかに薄め〜普通の陰毛を持つ人々の筆によるものであるか、そしてそれに早めに気付いてさえいればこれほどの試行錯誤はなかったのに、という思いでいっぱいである。
ただ、試行錯誤を経て勝利への道筋は見えてきた。別にツルツルは求めておらず、全体量が減ってくれれば、特にIOの密度が多少なりとも下がってくれれば言うことはない。しかしIとOというのはなかなか効果が出にくいエリアらしく、まだまだ長い闘いが続きそうである。今後の増田選手の活躍にご期待ください。
欠けた大地の異界３Fクリア。
２つあるワープゾーンが面倒くさかった。一歩歩くたびにウィザードアイを使う必要があり、マップ手書きしないと無理。
元魔術師のロード、侍、ビショップの３人がウィザードアイを使い切るたびに帰還するひつようがあった。
敵は凶悪で逃げそこなうと大抵誰か死ぬ（ファイアドレイクとフェニックスはそうでもないけど）。
特に、タフ・全体攻撃持ち・首はね・集団で出現と３拍子そろったファイアマンティスは３グループ以上出たら負けるから逃げるしかない。
中ボスは初戦で死人ゼロで攻略できた。正直、ファイアマンティス軍団ほど怖くなかった。
最初のターンに敵の攻撃がエレメンタルに集中してくれたおかげで、マジックスクリーンを張れたのが大きい。
ロードとビショップが毎ターンマジックスクリーンを重ねがけしたので、敵のティルトウェイトを含む魔法攻撃がほぼ無力化できたし、ブレイクスクリーンを撃った上でスティールライフがトキシックウルフとボスに刺さったおかげで危なげなく勝利。
そのまま4F探索へ入れる程度の消耗で済んだ。
で、また4Fで敵の凶悪度が上昇。特に手ごわい編成のやつでなければ勝てると言えば勝てるが、毎回総力戦になるから魔法使用回数と気力がもりもり削られてつらい。
あと、強い武器が出ないせいで、２Fから装備がほぼ更新されていない。戦士二人はカシナートと切り裂きの短刀の二刀流。侍は蜻蛉切り。ロードは後列からバルダッシュ。盗賊は女王の鞭。ビショップは聖なるフレイル。
ロードと侍の火力が戦士の半分しか無い上にHPもしょぼいせいで、最終的に予備役入りするはずの戦士2人がバリバリのタンク兼ダメージディーラーとして活躍している。もうこのままの編成で行こうかな・・・
イケてるエンジニアもすなるLaravelといふFWを、底辺チンカスエンジニアの私もしてみむとてするなり。
フレームワークとか逆に難解すぎてやってられねーよ！と今まで拒否し続けてみたものの、なんか人気らしいので気になったんですよ。
で、公式サイトのクイックスタートを見たら、１行目からこれですよ。
Composer？ アホかと。バカかと。お前らな、依存管理如きで余計な要素を増やしてんじゃねーよ、ボケが。
名前は知ってるが使ったことないし、ちょっとググってもよく分からない。分かろうとも思わない。思えない。もともと頭が悪い上に中年なので学習意欲もわかない。
終わりです。終わりました。ハードル高すぎるんですよ。
Composerで手軽にインストール！
って、Composer自体が手軽じゃないんすよ。
ComposerだのAnsibleだのDockerだの超絶魅力的だけど全然意味わかんないっすよ。俺くらいのバカでも分かるように作って欲しいんすよ。
結局フレームワーク使って何かハマった時にブラックボックスすぎてかえって面倒なことになるので（≒言い訳）、俺はこれからも自作FWでやっていきます。
2022/01/13 15.1％
2022/01/16 17.9％
2022/01/17 21.1％
2022/01/18 23.4%
2022/01/19 25.9％
2022/01/21 31.5％
2022/01/23 35.3％
2022/01/24 36.3％
2022/01/25 39.8%
2022/01/26 42.8％
50％予想
1/28〜1/30 金土日のどれか
食堂のカレーを作るときに市販のバーモントカレーの12粒入りのをいちいち箱破いてルー取り出してなんてやってたら日が暮れる
だから、たとえ安くなくても大量に購入できて大量にストックできて大量に使用できるのなら、業務用途では業務用を買うし使う
で、大量大容量パックのついでとして、1食分あたりの単価が安いことが「多い」というだけである
なので、安いの比較対象としてたとえばスーパーの利益マイナス大安売り目玉商品とか持ってこられると、業務スーパーでもぜんぜん安くならない
多くの関西人が同様で、必死のパッチは死語となりそうではあった
が、関西（大阪北部しか知らん）には会話に笑いを取り入れないといけないという残酷な闇ルールが存在する
またスベってもある程度周りがフォローしてくれる優しい環境もまた存在する
年配だったり地位あったり皆に酒を振る舞ったりして常に周りからのフォローを得やすいおっさんは、特にその恩恵を受け、寒いギャグなりなんなりを吐き放題だ。それは周囲に苦痛を与えたり、運よくWIN-WINだったり（ギャグの打率が高めで金銭的に付き合ってると得）する
また、話に笑いを入れるとしても芸人の持ちギャグなどの使用頻度は低い傾向にあり（これはよくすべるしリカバリしにくい、テレビでフジモンがよくやってる一周回って面白くなるタイミングとかであればそこそこ使用価値はあるが、あの辺の匙加減はおっさんにはわからず、おっさんがやるとちょうどよい時期でも寒い）、結局オリジナルだかパクリだかわからないダジャレが採用されやすい
必死のパッチはそんな中でも今まで過去に一度もバズったことがなく、細々と使われ続けている（一時阪神タイガースでこじんまりとした流行を見せたが（あまりにもメジャーなダジャレはそれもまた寒い
なので、周囲に自分に対する敬意と優しさを兼ね備えた人材が多く存在している状況で、必死になったエピソードトークを披露するさいに、「必死のパッチやったで」とかで使えばよいと思います
いいねしたユーザーといいねされた記事などのデータが1つのレコードとして登録される。
2万いいねされたユーザー記事が100万件あれば、2万×100万件分のデータ領域が使用される。
2022/01/13 15.1％
2022/01/16 17.9％
2022/01/17 21.1％
2022/01/18 23.4%
2022/01/19 25.9％
2022/01/21 31.5％
2022/01/23 35.3％
2022/01/24 36.3％
2022/01/25 39.8%
0002 おさかなくわえた名無しさん 2021/05/07 06:26:27
ヒリとは、文字通りガキをヒリだしただけで国や少子化対策に貢献していると思い込み、恥じらいを捨て、ガキをだしに傍若無人で非常識な振る舞いをする頭の悪い自己中心的な子持ち女のこと。
ヘラヘラして聖母に女神気取りのニヤニヤ系ヒリと、無愛想で棒読み注意の仏頂面ヒリの2パターンが多い。
汁とはヒリの男バージョン。
ダニとはヒリ汁に躾をされていない＋少子化を理由に甘やかされ、国の宝としてかしずわれることが多い為に
傍若無人で我儘勝手な振る舞いをする何の理性のない畜生以下の糞ガキの事。
赤ダニとは自我が芽生えていないすぐ喚き散らす人間未満の赤ん坊のこと。上記のダニの前段階。
特にヒリ汁に盾や免罪符に使われる多くどこにでも連れまわされることが多い。ダニーカーで突撃や無理難題を要求する際の口実に利用される。
ヒリには周りに愛想よくすることを強いるための道具として利用されることが多い。
ダニーカーはベビーカーの通称。ダニを運ぶために使われるためそう呼ばれる。
ヒリ汁の最強兵器で、突撃や場所の占拠に使われることが多い。特にヒリが使用しており並列走行が多く人の歩行の阻害になっている。
他人に持ち運びさせるなど親切の強要に使うことが多く、手助けしても十中八九礼言わずである。
ダニンプはパコってボテっただけなのに、国の宝を抱えていると思い込み傲岸不遜な振る舞いをする妊婦のこと。
ダニをダシに傍若無人な振る舞いをするヒリの前段階。 通称ニンプリンセス
道路族は文字通り公共の場である車道を占拠し通行の妨害や、騒音を撒き散らしたりするなど傍若無人な振る舞いをするダニヒリ汁の集団のこと
これらのポイントは
「世の中の全ての子持ちに当てはまるわけではない」
と言うこと
『 酷 く 目 に 付 く 様 に な っ た 』
0003 おさかなくわえた名無しさん 2021/05/07 06:26:51
これだけは確実に言える
・年金や税金の仕組みを知らないでこなしは年金貰うなと喚き散らす
・躾と虐待の線引きが出来ないので手を挙げただけで虐待だと喚く、もしくは引っ込みがつかずに一線を超えてしまう
・堪え性が無いので少しの我慢すらできない
・かつて日本国内を恐怖に陥れたテロリスト団体オウム真理教の教祖(麻原彰晃・死刑執行済み)は妻子持ちであることを知らない
・「母は偉大」と言いつつ、2006年に起きた秋田児童連続殺人犯の畠山容疑者のような母親がいることは認めない
・人には徹底的に厳しく自分にはどこまでも甘い
・他人に迷惑をかけることに対しては無頓着だが、自分にとって都合の悪いことや迷惑になることには過敏に反応する
・社会のルールやマナーに順応しようとせず自己中心的な主張をし反社会的な行動をとる
・子供は泣くのが仕事と都合のいいような弁解をし、親の仕事は果たさない
・子供が親を選べないように、親だって子供を選べない！って意味不明な理屈をこねる
・好きでパコってボテっただけなのに、少子化に貢献してると威張り散らす
0004 おさかなくわえた名無しさん 2021/05/07 06:27:14
・他人任せなくせに要求が高い上に多く、気に入らないことがあれば文句を言う
・自分のダニのことを未来の宝！や未来の納税者！と言って憚らない
・そのくせ今の納税者には感謝のかけらもなく迷惑をかけても平気
・個性や多様性の理解を求めるくせに、「子供嫌い」という個性は認めない
・ダニに対する愛情やママアピールは母性本能ではなく、単なる自己満足、自己陶酔であることに気づいていない
・ダニの奇声は親でもきつい！とか言うくせに他人が迷惑がると不寛容！と喚き散らす
・24時間ダニに付き添うなんて無理！というくせに教員には365日24時間休むことを許さないと抜かす
・他人の落ち度は過剰に責め立てるくせに、自分に落ち度がある場合は言い訳にヒリ屈をこね自己擁護し挙句の果てには責任転嫁する。
授業をどうするかについては、塾長になって以降、各学部の代表者が頻繁に集まって、徹底的に議論しました。その結果、教員が学生全員の顔を見ながら教え、場を共有することが大切だ、このままだと教育の質が落ちかねないという結論になりました。一方で、最先端のツールを使って新しい授業をすることも必要で、両方をミックスすることにしました。最終的に、この4月からの対面授業は9割とし、昨年12月24日に大学ホームページで公表しました。
慶応大「4月から対面授業9割に転換」 その理由を伊藤公平塾長に聞く（朝日新聞EduA） - Yahoo!ニュース
https://news.yahoo.co.jp/articles/3c21c256ab97b33e7e8d7b9a944532d868a92ffc
一方で、
「2022年は、どのように授業を受けたいか」を550人に聞いたところ、「ハイブリッド授業希望」38%と「オンライン授業希望」36%が同程度で、「対面授業希望」26%が最も少ない結果となった。
ハイブリッドという特殊な授業形態が最も期待される背景には、友人と交流する、そして通学時間を短縮させることを共に叶えたいといった、大学生たちの願いが込められているのかもしれない。
また、複数人の大学生に話を聞いた結果、同じ「ハイブリッド授業」という言葉を使用していても、実際の実施形態は異なることも分かった。
オンラインと対面授業から柔軟に選べる形式、各科目でオンラインまたは対面のいずれかを実施方法とし、複数の科目を合わせて数えると体系上ハイブリッドとなる形式、そして1つの科目の中で、授業内容によってオンラインまたは対面授業を使い分ける授業形式もあるという。
大学生が受けたい授業、「ハイブリッド」38%、「オンライン」36%、「対面」26% ＝Dtto調べ＝ | ICT教育ニュース
企業の人事もそうなんだけど、バブル世代の対面幻想って何なんだろうね。大教室で何百人も集まってただ教員の話を聞くような必要はないじゃん。新人研修も、今年は「万全の対策をとって対面で」とかいうだいきぎょー、結構多いみたいよ。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
先月、好きなバンドがメジャーデビュー後初のワンマンやったんだがこれがすげえ良かったので、他人の感想見たくてTwitterでパブサした。
そしたらボーカルのAさんがイケメン！みたいな容姿に触れる感想を公式タグ付けてツイートしてる人が多くて驚いた。
どちらかというと顔売りしてないバンドなんだが……メジャーデビューしてからしばらく顔出し控えてたし、何枚か出たアルバムはどのジャケにも写真使ってないし、PVにもメンバー出てないし……。
このままファンがAさんの容姿に触れるようなツイート連発したら、曲じゃなくてボーカルの顔で売れてんだろって言われそうで怖い。
女性ファンが多いのを理由に「アイドルバンド」って叩かれた某バンドが、それを否定するために男性ファンを過剰に優遇するようになって炎上したけど、好きなバンドにああはなってほしくない。
（アイドルバンドという単語が悪口として機能するのもどうかと思うが）
顔出し控えめなのが仮にバンドの方針だとして、所属レーベルがそれを許したってことは顔売りしなくても売れるだけの力があると判断されてるってことだろうし、顔出し控えめなのは顔売りバンドって言われるのを避けたいからなんじゃないかと思う。
それなのにワンマン参戦するような熱量あるファンがメンバーの容姿に言及するのは、それがポジティブな感想でも関係者の意図や努力を無駄にしてないだろうか。
どうしてもメンバーの容姿についてツイートしたいなら、せめて公式のエゴサや他のファンのパブサに引っかからないようにしてほしい……。
本当にライブパフォーマンスが最高だから、色んな人にこのバンドのライブに参加してほしいと強く思ってる。
だから某バンドみたいに、ファンが、自分ではどうしようもできない属性のせいでエントリーする資格すら剥奪されるような事態になってほしくない。
これ読んで気分悪くした人がいたらごめん。（特に某バンドのファンの方々……）
色んな観点から反論はいっぱいあると思うけど、少しでも「これは自分の好きなバンドの話かもしれない」と感じたなら、心の片隅において、ライブの感想をツイートする前に思い出してもらえると嬉しい。
2022/01/13 15.1％
2022/01/16 17.9％
2022/01/17 21.1％
2022/01/18 23.4%
2022/01/19 25.9％
2022/01/21 31.5％
2022/01/23 35.3％
2022/01/24 36.3％
50％超え27日〜31日予想
OSM は成功したボランタリー地理情報 VGI(Volunteered Geographic Information) の一例と説明されますが、あくまでそれは一つの要素であって、世の中に定着した「最大」の理由はボランティア運営によるクラウドソーシング手法を採用したことではありません
Google Maps のように商用利用時に制限のかかったウェブ地図よりも、より自由で、ある意味何でもできる OSM を採用する企業が増えたことで、OSM の認知度が向上するとともに、企業が OSM を用いたサービスで収益を生むことによる「エコシステム」がまわった。商用利用を許容することで民間企業による OSM のデータ更新と利用価値を更に高める正のフィードバックへとつながったのだと筆者は考えます。
https://medium.com/furuhashilab/show-the-niantic-flag-4ab03ed1c3ea
OpenStreetMapとは、自由に改変ができその利用もGoogleMapより自由度が高いことで有名な地図ソフトです。登山マップやゲームのマップなど、様々な分野で活躍しています。これの特徴は、無償のボランティアや利用する企業によるメンテナンスにあります。その中にはAppleやFacebookといったあまり地図に関係しないような企業も参加しています。
存在しない島を追加したり海岸をまっすぐにいじったりすることは可能ですが、当然そのようなこのはしてはいけません。地図としてきちんと整備することが第一で、OSMやその利用者の利益に繋がります。
ここで名指しで取り上げられているNianticは、ご存じのようにポケモンGoを開発運営する企業。
ポケモンGOの地図はOSMを元に作られています。ポケモンGOは日本だけでなく世界中で広く利用されており、その人口も非常に多いことで有名です。当然Nianticは世界でも指折りのOSMユーザーでありその恩恵を受けていますが、実はNianticはそのOSMに対する貢献が殆ど無いことでも有名です。
自身のアプリ内で直に使用し多くのユーザーの目に触れているものを、自らメンテナンスして貢献していないという実態はコミュニティの中に筒抜けです。
言ってみればNianticはみんなで作る地図にただ乗りしているわけです。
それだけなら大したことではないかもしれません。OSSを幅広く利用していても、その改善に努めないことが間違っては居ません。
ただ、Nianticの作っているポケモンGOはOSM自体への改ざんに繋がっているのが厄介な点です。ポケモンGoはOSM上の公園などの特定の場所にポケモンが出没しやすい仕様です。逆に言えばOSMをいじって自分の周囲に大量をポケモンを出してしまうことも原理的には可能です。そしてそのような改ざんがOSMのコミュニティの中で非常に問題視されました。現在は過去ほど大規模な改ざんは行われていないようですが、小規模な改ざんは今も続いているでしょう。当然、OSMは全世界的にそれが反映されるので、OSMを利用する企業や個人がその改ざんの被害者となり得ます。
それを知っているNianticは問題を放置し、修復を他の企業やボランティアに任せっきりにしています。ただ乗りを明らかに超えていることでしょう。
さらに、現在ではOSMを超えてGoogleStreetMapの改ざんも多く報告されています。実在しないものを審査させるために、その根拠となりうるストビューに意図的な改ざんをして審査を通すやり方です。
ここまでしてまでポケストが欲しい人が多いのが実情
また、ポケモンGoのポケストはそもそもIngressというゲームのポータルに由来します。最初こそこのポータルを設置する機能はポケモンGoにはありませんでしたが、現在はポケモンGoのユーザーでも申請や審査が可能となっています。しかし当然由来と使い方が違う物を別々のユーザーが申請・審査することは非常に軋轢を生むことになります。
現実問題、ポケモンGoで申請・審査ができるようになってからの不正なWayspotの登録は加速度的に広がりました。何も無いはず場所に大量のスポットが出現したり、本来はありえないものが登録されていたり。酷いときには地域毎で談合を行っています。さらにNiaticはあろうことかFourSquarer上から任意のスポットを抽出してスポット化しました。ユーザーに何も伝えずです。
これがポケモンGoの為だけならまだギリギリわかりますが、他のIngressや魔法同盟、ピクミンなどにも影響が及ぶスポットをこのような乱雑なやり方で作成することは問題です。
将来のゲームユーザーも使う物をポケモンGoの恣意的且つ数の暴力で歪めているのが現状です。
唯一のいいところですが、OSMのマッパーが少しだけ増えたことでしょうか。
