  |
はてなキーワード: ブラックボックスとは
ここでもよく職場の不満日記を目にするけど、たいてい仕事が増やされたとかそういうのが多い。
基本給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人で提出するぜ。アディオス。
これは、去年のアドベントカレンダーの時期に会社のテックブログに寄稿するつもりだったが、少し過激だったので見送っていた文章です。
見返してみると公益性の高い内容だったので加筆した上で増田で公開することにしました。
セキュリティベンダで勤務後、ユーザー企業間で何度か転職した人間です。もう現役を退いて長いですが、自身も脆弱性診断の経験があります。
最近はベンダコントロールや社内の小さなインシデントを片付けるCSIRT業務しかしていません。
クライアント目線ではベンダ側がブラックボックスなのでちゃんとチェックしているのかわからない。
例えば、脆弱性はありませんでしたという報告書を提出された場合、それを信じるしかない。
ちゃんと報告書の質を見なければいけないが、予算を確保するのに精一杯でそこまでできている企業は少ないだろう。
以前、イ〇〇〇社を重宝していたが、あまりにも報告書の品質のブレがひどいので、現役診断士の知人に相談したところ、イ〇〇〇社はエンジニアの実績を売りにして営業をかけているが、実際には下請けの会社が診断を実施しているケースも多く、社内のエンジニアが担当していない案件も数多くあるとのことであった。また、学生バイトが診断を担当することもあるらしい。下請けに流すのは、この会社だけの問題ではなく、大きな診断会社では結構やっている話らしいが、個人的にはかなり驚いた。
私が過去に在籍していた企業では行っていなかったと思う（知らないだけかもしれないが）....
このように実績が多そうな会社に依頼したところで、実績が多い人がやってくれる確証はない。
報告書の内容が正しいかどうか分からなければ、報告書の品質を見極めることはできない。
社内に脆弱性診断経験者がいれば、その人を担当にするのがいい。いなければ雇ってもいいだろう。脆弱性診断は一件あたり数百万かかるのでそれだけの価値はある。
あまりにも報告された脆弱性が少ない場合は、重要な機能だけ社内でダブルチェックをするくらいのことはやるべきである。
同じアプリケーションを複数の企業の脆弱性診断にかけると、出てくる脆弱性にどれだけ差が出るのか検証することができる。
脆弱性診断はただでさえ高いのに5倍くらいの金額がかかってしまうので大企業にしかこの手は使えないがおすすめである。
その際にコンペであることはベンダに伝えてはならない。伝えてしまうとその時だけ凄腕のエンジニアが担当するだろう。
また、差を見る際には総合件数でジャッジするのではなく、影響度の高い脆弱性の件数でジャッジするべき。
特定のベンダに肩入れしたいわけではないので名前は伏せるが信頼できる企業も存在する。
実績を売りにしている少数精鋭の企業であれば、技術力に誇りをもっているので、がんばってくれるケースが多い。
インターネットで実績を確認できるエンジニア個人に脆弱性診断を依頼するのも一つの手だ。そうすればベンダに依頼した場合とは異なり、間違いなくその人が脆弱性診断を行ってくれる。共通の知人やスカウトメールを通して脆弱性診断やってくれませんか？とお願いすればやってくれる場合もある。
セキュリティベンダをベンダが作り出したWebページを見て、なんとなく信用して依頼するのではなく、依頼する側で見極める力を持たなければならない。
というか外注より内製するべき。コンペする金があれば余裕でセキュリティエンジニアを雇えるだろう。
ネットワークへのペネトレーションテストだとまた話が違ってくるのだが、この増田が伸びれば新たに筆を取ろうと思う。
是非はともかく、やるとしたらこうなるんだろうなという予想。
まずこれが前提事項となる。今回女子で金メダル取ったイギリスのチームは、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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
元上司はしっかりとしてた上司で、二人体制でやる以上はどちらも一定水準の仕事が出来るようにと調整してくれていたが
今の上司は経験が浅いやつに個人情報なんて触れさせない！！！というタイプなので、特定の業務が完全にブラックボックス化してる
一応上司にも数字そのものは上がっているが、どう計算した結果なのか。過程を知らないので脳死で判子押してるのとほぼ同義
じゃあ個人情報はしっかり保護されているのかと思えばそうでもなく
鍵自体はあるが、開けようと思えば誰でも開けられるのでほとんど鍵の意味なし。べつに他人の給与とか見てもしょうがないが
困ったらとりあえず片方に話を振る。そして片方と上司の間でやり取りが始まるので、自分が居る意味なし
人材を大事にしよう！誰か一人の責任ではなく皆の責任！！と理想だけは立派なのだが
言ってることと、やってることの乖離がすごいので言葉だけが虚しく響く
誰にも共有せずに一人で仕事抱え込んだ時点で、そいつが全責任を背負うのが普通なんすよ現実って
まあべつにいいんだけど、転職して今の地位に居る上司が一番そのことを分かってないのはなんか面白いなって思う
緩やかに現状維持・衰退したい人間はそれでいいのかもしれないけど、俺みたいにキャリア意識してるやつは他所へ行くよ
俺が信用されてないのもあるんだろうけどね。でも話し合いにすら参加させてもらえないって、そういうことなのかなって思うよ
場合によっては取引先と最前線でやり取りするのに、営業部の新人ですら持っている名刺を作ってもらえないのが俺
会社行事で幹事役として他よりも正装が必須なのに、会社で採用してる刺しゅう入りジャケットすら貸与してもらえないのが俺
そんな無能が、俺
市場規模は製造業の方が大きかもしれないけれど、設計ソフトがないと物が作れない。
使用する各社の要望を聞いていくと、各社のノウハウが集まって次第に強くなる。
アカデミックの高度な理論を、産業に落とし込むという意味合いもある。
今の日本の大学が陥っている、研究者は研究したいが産業に結びつかないで金が回ってこないという状況も少しはマシになっていたのではないか。
(論文を書き通ったとしても、金を稼げるところを英語圏に握られているので、税金を使って相手を有利にしているだけ、になっている）
プログラムコードに起こすというのは、難しい理論をブラックボックス化して誰でも使えるようにするのと同時に、先端研究結果を広める意味合いもある。
1つの論文に対応するコードだけだと断片的過ぎるのを1つに統合することで金を生み出す仕組みが必要ではなかっただろうか。
国防の観点だと、原子力発電推進と宇宙産業はいつでも武器を作れる技術があるぞ、という牽制の意味合いもあったのと同じ論理で、
設計ソフト、物理シミュレータは必要なはずである。ないと作れないのだから。
抽象的→具体性を欠くさま。物に即して考えたり述べたりしないさま。
イメージ→心に思い浮かべる像や情景。ある物事についていだく全体的な感じ。
ブラックボックス→利用者が内部構造や動作原理を知らなくても支障がない設計の装置やソフトウェア、システムなどのこと。
翻訳すると、「兵力による国家間の闘争と、営利を目的とする社団法人は、具体性を欠いた心に思い浮かべる像や条件、全体的な感じが違うから、会社の内部構造や動作原理を知らなくても支障がない」
？？？？
反ワクチンは正義でワクチン信者も正義、これは掲げる正義が違うから、どっちにも分があると言う理解ができないでもない。しかし前の文との関連性が分からず「つまり」で繋げる意味が分からない。
