  |
はてなキーワード: プレーンとは
https://www.smashingmagazine.com/2022/05/you-dont-need-ui-framework/
I empathize with developers who want to launch a professional-looking project without any sort of design intuition…
テンプレート (https://mui.com/store/?utm_source=marketing&utm_medium=referral&utm_campaign=templates-cta#populars) から適当なの選んで使うんだよ
これ書いたやつは本当にプロなんだろうか？
折り畳みのはあるんだけど、
ビニール傘どうしたっけ？って思い出したら
何日か前にコンビニに寄ったときに置き忘れていたことをすっかり忘れていたことを今思い出したわ。
時すでにお寿司よね。
「時すでにお寿司」ってお店プロデュースされてそうな気がするわ。
でもさー、
傘その瞬間に思いだしたら、
一旦もう家のドア入ってしまったら
引き返す気力は無いこと無いかしら？
はぁ、
ビニール傘は諦めたわ。
ビニール傘代が惜しいんじゃなくて、
そこが悔しい！って感じで
私としたことがーって。
傘忘れがちな、
ああいったコンビニの傘立てで刺したまま置いて帰るのを防ぐ装置があれば、
傘忘れなくて済むのになぁって。
あのあれあるじゃない、
忘れ物防止タグって物理的に忘れたくない思い出以外のモノに装着するやつ。
あれはあれで付けた途端に
忘れることすらなくす
そう、
意識しすぎていつもそれの持ち物を意識全集中させてしまうから、
きっと
傘も忘れ物防止タグを付けたら逆に意識しすぎて忘れなくなる説あるかもしれないわ。
私もがま口の小銭入れを部屋の中で喪失することがよくあって、
いざ出掛けるときにお財布がないっ！て
だから本当に忘れたくないモノは
意識するために
忘れ物防止タグ風の意識のきっかけを作るダミー忘れ物防止タグってのがあれば
効果ありそうじゃない？
逆に意識せずとも傘に付けてみて、
本当に忘れたときに、
忘れてますよー！って機能が発動するか試してみるチャンス的機会でもあるわね。
だから
気が向いたら
たぶん傘にそれ付けて忘れ物しない！って
思って雨の日楽しみにしてるんだけど、
傘を持ってお出かけする
雨が降らなくなるのかしら？って
逆に思うわ。
傘いらないじゃんってね。
うふふ。
なんだか塩気が強くて
いつものお店のタマゴの旨味がギュッと詰まったサンドイッチが食べ慣れている分慣れているわ。
1本冷蔵庫に冷やしていたのがあるわ。
レモンもいいけど、
すいすいすいようび～
今日も頑張りましょう！
夜食べるものは罪悪感の塊でしかないことをいつも翌朝になって気付く悪ってあるわよね。
はぁ。
分かってても夜お腹空いてるのよね。
暇つぶしになにかお腹空いた感じを散らす感じでゲームしたって、
お酒頂きながら捗るゲームって「スプラトゥーン2」しかないのよ。
これはいいんだけど、
「ダンジョンエンカウンターズ」は緻密な戦闘の敵を倒す順番を足し算計算しなくてはいけないので、
これ酔っ払っていたら全然進まないゲームだと言うことに気付いちゃったわ。
カービィだからって手を抜いているとサーカスの猫のボスが全然倒せなくて、
私試したいことあるんだけど、
話し変わるんだけどさ、
朝銭湯チャレンジエクストリーム出社したらどういう作用を及ぼすか！って
最近さー
ぜんぜん銭湯行けなくて、
あれはあれで全然やっぱりもちろん銭湯のお湯の迫力とは違うので、
すぐお湯が冷めてしまうし、
長時間入って追い炊きするんだったら
そう言ったストレスレスで快適な湯量を正に湯水のように使える銭湯の方が
効果は高いわよね。
だって家の湯船にお湯が溜まるうちに出航できるまで時間かかるし、
それはそれで気付きだわ。
だから
餅は餅屋って言うように
でも最近一番欲しいのは
罪悪感のない食べるものでも大量のお湯でもなく
本当に時間が欲しいわ。
そして優勝よ！
うふふ。
鮭焼いてきてお弁当詰めてきて
いや詰めるだけなんだけどね。
中身分かっていても。
普通に炭酸プレーンなんの風味も付いてない普通のプレーン炭酸ウォーラーを飲んでみました。
ふとした瞬間いいな！って開眼するときがあるわよね。
暑くなってきたから
水分補給はしっかりね。
すいすいすいようび～
今日も頑張りましょう！
隣の会社の部署のお手伝いをたまーにするときに何が嫌かって手書きの伝票を手書きで書くことが苦手なのよね。
お隣のところは、
伝票なりそれがメインなんだけど、
伝票手書きで納品書4枚複写の例のああいうやつの手書きするんだけど、
あれってなんとかプリンタして
画面で管理して印刷してオーケーって言う仕組みにならないのかしら？って
思いながらいつも伝票こしらえてるのよ。
これプリンターあればもっと暮らしが楽になるはずなのになぁって。
だってさー！
聞いて欲しいんだけど
これマジで手書き熨斗書き職人が必要なレヴェルの伝統工芸的なもので人員が国宝級の人材がいない限り
機械化するべく案件のイノベーションのインスパイヤザネクストじゃない。
これで量産体制が整ったところで、
出来るものは全て手書きとかそういうの一旦真心とかブラザーズとかっていうスピリチュアリズムなメッセージは置いておいて
だから鶴の恩返しの話しも
えげつない規模で恩返しが出来たと思うのよ。
あれこそファクトリーオートメーションの賜の話しじゃない？
いつまで経っても罠から解放してくれたジッ様とバッ様に感謝の意を込めれない恩返しの不満の「ふ」の字を言いたいぐらいじゃない！
もっと恩返ししたい！つって
大製糸工場でどーん！みたいな。
大大大恩返しができたってラッドウインプスさんたちが主題歌で歌う劇場版アニメで大感動するストーリーになると思うんだけど、
折るだけに！ってかかってはいないけど。
でさ、
それはそれでそうなったら、
人間は何したらいいの？って
より高効率化できんじゃないのかしら？って思うし
よくさ、
手を掛けて手で作ったものが良いって傾向あっていったりするじゃない。
そう思ったら、
田植えを手植えでやって育てて収穫したお米と
さすがの海原雄山さんも
こ！これは手植えの味がする！！！って言わないと思うぐらい
あたかもそう言ってそうな偏りもあると思わない？
私は手植えでも機械植えでもお米の味は一緒だと思うんだけどなぁって思うんだけど。
それだったらワイン作りのワイン踏みの葡萄を裸足で踏むのは美女が踏んでいる写真を検索して探すのは容易なぐらいに、
あれもイケメンや美女が踏んで作ったワインが美味しい理屈になるんじゃない？
そこはそこでちゃんとファクトリーオートメーションしてると思うのよ。
意外と道の駅って値段安くないよねーって
思いながら本当にこの足踏み手作りワイン足で踏んでいるんだけど手作りって言っていてややこしいワインは美味しいのかな？って首をかしげながら選定してお土産にしようとしたことあると思うんだけど、
テンションが上がるけど、
意外と値段高いのよねーって
家に帰ったら冷静になるときってあるわよね。
サルが四歩足歩行から進化して二足歩行していく人類の進化のイラストってもう100万回生きた猫の絵本よりみんな見たことあると思うんだけど、
もののできる仕組みとしては
こういうことこうやって作ってるんだなぁって実感して大変さは分かった方がいいと思うのよね。
だから
一概には機械化して伝票を出したら良いと思うけど、
一概には手書きして機械便利ね！ありがとう！って思う気持ちを知り得ることも大切だなってね。
私は統一伝票でガッチガチで自動的に印刷出来てワーイって開いた時間に、
伝票を書く時間が空いたから他の伝票を書かなくちゃいけないって
全伝票プリンターに通せるようにフォーマットを戦国時代の時にすでに統一した方が良かったのよ。
まあ
うだうだ言っていても仕方ないので、
手書きで書かないといけない伝票を頑張って書くわ。
まったくよ。
波があるのよ波が。
グレープフルーツのマジ搾りの生果汁を
朝喉渇いてて美味しくいただけたわよ。
すいすいすいようび～
今日も頑張りましょう！
infinite labyrinth裏ボスを平均150レベルくらいで打倒。あれが裏ボスで合ってるはず（表ボスがいないから多分）。
いやー、今まで他のシナリオで見た裏ボスの中で最強だった。こっちはほぼ全員HP1500超えててティルトウェイトを10発20発食らったくらいじゃヒールすら要らないレベルなのに、普通に3人死んだ。
裏ボス倒してアイテムは手に入ったけど、特段イベントや称号はなし、と。
さてどうしようかな。
まだ行ってないステージも手に入れてないアイテムも沢山ありそうだけど、流石にもうどんなモンスターが出てきても敵じゃないから続けてもなあ。最難関ステージの七大魔王もこのレベルなってしまうと1ターンの物理攻撃で倒せるからやりがいがないし。
このシナリオは大量のギミックに加えて、フレーバーテキストのセンスが良くて楽しめた。
金の扉以外は早々に必要なくなってしまうのがちょっともったいない気もする。
ロード二人に侍二人に忍者にビショップで、忍者以外の全員が魔術師と僧侶の全呪文持ちとほぼ理想的な上級職パーティに仕上がった。（忍者はビショップからの転職で、呪文はどっちもレベル3まで。サンダーとトータルテラーとマジックスクリーンが使えるレベル3になってしまえば、基本的にどんなACの相手でもやることなくて困ることはない）
このレベルになってから一番苦労したのは大地のエレメンタルプレーンの最終ステージ。なにが困るって、シュートにガンガン落ちて正しい道を探さなきゃならないのに、オーブ・オブ・オールを持ってたせいで1戦闘毎にレビテイトが復活してしまい、クリアマジックで一々解除しないと先に進めなくなった事。せめてレビテイト無効のシュートであってくれれば、ここまで苦労しなかったのに。結局、このステージに挑むためにオーブ・オブ・オールをアイテムボックスに仕舞ってプラチナチケット使って再挑戦した。沢山のシュートを網羅的に落ちまくってハズレ引くたびに戦闘しながら戻らなければならず、面倒くさいにもほどがあった。何か正解が分かる法則性とかあったのかなあ。
あのさ、
ローラースルーゴーゴーじゃない方のなんかボードにノリに乗って勝手に進むやつを街で見かけたんだけど
しゃーって追い抜いていく際に後ろにナンバー付いていたんだけど
あれってなにかもう軽バイクの扱いになるの？
でも歩道は走ってもいいのね？
それなんてエキサイトバイクワールドレース？って言いたいところだけど、
なんだかそう言う電動の流行ってるのかしら？
何台か見かけたわよ。
一世を風靡していたかのように思っていたけどあんまり日本では一世風靡していないセグウェイも
なんかハンドルがついてない
私もさー
常々思ってるのよ。
ワンマイル内の移動自転車みたいなスルー且つゴーゴーできるような簡易的なしかも人力でいいので動けるアイテムが。
まあ徒歩でも行けないことないけど、
往復として10分の差が出てくるのは
やっぱりそういうの欲しいなぁって思うけど、
どうしてもスルー且つゴーゴーの類いの乗り物が欲しくなるのよ。
銭湯に行くか否かって
かといって、
行ったら行ったで行かなきゃよかった！って絶対後悔することは皆無中の皆無で全くないので、
店内に飛び込み前転で入店できてお風呂楽しむ時間がわずかだとしても、
それはそれで充実しているから
結局は私の行く気がないのよ。
やる気次第というか、
やる気があればなんでもできる訳なのよ。
もの凄く面倒くさいけど、
じゃでも5分だけ片付けましょう！って固唾を呑んでタイマーを5分にセットして片付けの火蓋が切って落とされて、
5分ってすぐ経つじゃない、
そうなるともう片付けの波に乗れたようなものよ。
始まったら途中でやめちゃうのはトータルテンボスさんの忍びないレヴェルなので、
あともうちょっと片付けちゃいましょう～ってなるのよ。
ほんの短時間片付ける5分のつもりが
そんなもんよね。
重い腰は重いの！
こないだ私が観て衝撃を得た
あやまん監督さんの
パンティーで7が出るか出ないかって6のパンティーと7のパンティーとで脱いだり履いたりして7出るんかーいって仕組みを導入しつつ
私の場合は
軽い重いって書いたパンティーを履いて脱いだり履いたりして、
重い軽いルーレットをして
でもたまに重いときに止まっちゃったらそれはそれで、
今日は行くまい！って心も動かなく鳴っちゃう山のごとしテコでも！っていうぐらいだから、
軽い！ってところで
もう半分出来試合だけど。
神無月さんがやり通した伝説の48人プロレスモノマネリレーを地で行くように
なぜか笑ってしまうやつよ。
重い腰が上がるようにしたいところよ。
夜になるとずーんともう出掛けたくないっ！ってぐらい腰が重くなっちゃうから、
シャーっと行けるようになったらいいなーって思ったわ。
話し変わるけど、
シャアのことをシャーって言うと怒る人いるわよね。
うふふ。
べつに体調が悪いわけではないので大丈夫よ。
素白湯ともいうし、
素白湯のレシィピがお料理レシィピ紹介サイトに載っていて笑っちゃったわよ。
お湯沸かすだけじゃない。
すいすいすいようび～
今日も頑張りましょう！
「ダンジョンエンカウンターズ」のことちょっとまたしゃべっていい？
マイナス27000ゴールドからマイナス16000ゴールドまで持って行ったものの、
まだ新しい武器とか装備とかが買えない一方、
マップ上の敵エンカウントはシンボルエンカウントなんだけど、
数字で表されていて、
それに見合った敵が出てくるんだけど、
10の桁が「F」とか！
これはただならぬ殺気を感じる恐ろしさ！
お金盗まれた敵ももしかしたら私が知らずにエンカウントした10の桁が「F」の敵だったのかも知れないわ。
ぜんぜん借金の返済に苦しむ、
そんで！
またただならぬ桁数のなんか強そうな敵に遭遇して
よし！倒してやるぞ！って思ったら
パチパチパチ！
でここからがまた酷いのが
石化した仲間は重いので運べなくて
その置いて置くシンボルも何もなく、
ただただ座標の数字を覚えておかなくちゃいけないのよ！
そんで、
安全なところの石化を解く番号のところに行ってみたら、
慌てたけど一瞬落ち着いて、
仲間の編成表に石化したメンバーの座標があるので、
落ち着いて見たら石化を解除できてホッとしたわ！
でも！でもよ！
石化を解除した仲間をまた拾いに行かなくてはいけなくてそこで合流しないとまた編成メンバーに加入できなくて、
はぁため息が出るわ。
石化解除してまた仲間を拾いに行くとか。
こんなことをチクチクチクチク繰り返していく感じよね。
相変わらず借金まみれだし、
レヴェルの低いメンバーと入れ替えて
地下1階からまた遊んでみようかしら？とも思うし、
新しいアイテムや装備を買うことが出来ずに、
てんてこ舞いの舞を踊ってしまいそうよ！
でね、
どう足掻いても
マップ上マスがないところを指し示しているので、
これはどういうことなのかしら？って
そう簡単には
そうそう安直にはアンチョビを乗せてリッツパーティー！はーいカンパーイ！とは行かない感じみたいなのよ。
仲間はどこ？って感じ
私はリッツの上にスモークサーモンを乗せて食べるのがお気に入りだけどね。
あとやっぱり深部に潜っていくほど敵も強くなるし、
今装備している装備では本当に太刀打ちできなくなってしまったわ。
やっとさー
なんかそれを上回る桁数の敵とか出てきたら、
あと
ここは一撃では倒せないけど手堅く固定値でダメージ削っていく堅実な戦い方の
ターン数でなんとか踏ん張るって地味だわー！って思いながら戦うのよね。
これがまた
ターンの順番とか魔法防御物理防御どちらを崩していくかってところもあるから、
敵と遭遇して、
うかうかしてると
やってない人はこの数字の桁数にビビる様子が何言ってるかよく分からないと思うけど、
昨日に引き続きちょっとこんな具合ね。
寝る間は惜しむけど夢中になっちゃうわ。
うふふ。
そのまま搾って炭酸、
とあわせて、
すいすいすいようび～
今日も頑張りましょう！
どう見ても止まっているが・・・
https://www.atsugi.co.jp/ir/pdf/calender_tyuukan_2021.pdf
繊維事業
レッグウエア分野は前年、新型コロナウイルス感染症の拡大による取引先店舗の臨時休業、在宅勤務や外出自粛の広がりを背景とした個人消費の冷え込み等の大きな影響を受けました。プレーンタイツなど秋冬商品の導入は進みましたが、生活様式の変化等の影響によるストッキング需要の減少は継続し、ソックスの伸び悩みもあり、同分野の売上高は5,336百万円（前年同期比27.3％
増）となりました。
インナーウエア分野も同様に、前年は新型コロナウイルス感染症の拡大による取引先店舗の営業自粛、外出自粛等の影響を受けましたが、株式会社レナウンインクスを子会社化したことなどにより、同分野の売上高は4,433百万円（前年同期比202.9％増）となりました。
これらの結果、繊維事業全体の売上高は9,769百万円（前年同期比72.7％増）、営業損失は1,171百万円（前年同期は1,472百万円の損失）となりました。
全く止まってないしラブタイツ以降大幅にレッグウェア部門の売上落としたで、レナウンインクス子会社化でインナーウェアは51%増したのに、同じくレナウンインクスを子会社にしたレッグウェアは34.2%減少した。
https://www.atsugi.co.jp/ir/stockholder.html
[繊維事業]
（1） レッグウエア分野
新型コロナウイルス感染症の拡大による取引先店舗の臨時休業、在宅勤務や外出自粛の広がりを背景とした個人消費の冷え込み、生活様式の急激な変化等の影響を受け、プレーンストッキングなどのベーシック商品の販売が期初より苦戦し、更には最盛期である秋冬期においてもタイツなどの季節商品が伸び悩むなど全般的に厳しく、同分野の連結売上高は9,899百万円（前期比34.2％減）となりました。
（2） インナーウエア分野
レッグウエア同様、新型コロナウイルス感染症の拡大による取引先店舗の営業自粛、在宅勤務や外出自粛等の影響を受けましたが、株式会社レナウンインクスを子会社化したことなどにより、同分野の連結売上高は5,073百万円（前期比51.0％増）となりました。
これらの結果、繊維事業の連結売上高は14,972百万円（前期比18.7％減）、営業損失は2,922百万円（前年同期は690百万円の損失）となりました。
この業界が息苦しいなと感じているものの、この業界に居続けている
トレンドを追うと、高速化や効率化みたいな内容しか出てこない。
自動デプロイだの、描画速度の向上だの、テスト自動化だの、新しいAWSのサービスだの…
一からサービスは作れるし、外部サービスの連携はAPIを見ればプレーンで書ける。
VPSみたいにサーバー用してもらえれば、プレーンで運用も出来る。
でも、プレーンで描くと「車輪の再発明」だの「再利用出来ない」って言われる（幻聴かもしれんが…）
いかにシェア率が高いメジャーなライブラリや方法を使って開発する事ばかり
フロント周りもそう
この世界に入った時は、色々華々しい事ができるって思っていた
実際は、開発環境やらモダンな開発手法やらごった煮なお作法を勉強しないと「トレンドを追え」と鼻で笑われる
フレームワークやらECMAScriptを使わず、プレーンで描いたら白い目で見られる。
そこまで使いこなせて初めて新しい技術を触る権利がある位面倒くさい
追ったら追ったで、「これ今すぐ使う必要なくね？」ってなって勉強の意義を見出せなくなる
今の自分が、コピペで開発で満足していた過去の自分を見たら、自分を説教してくれた先輩のように説教をするだろう
「ブログを鵜呑みにするな、ドキュメントを見ろ」「コードはコピペすんな、書け」「闇雲に手を加えんな、ログを読め」ってね。
ただ、あの頃みたいに、とりあえず作ってブラッシュアップして行こうっていう気持ちが今もあればまた違ったのかもしれない
プログラムは所詮道具なのに、道具の手入ればかり勉強している気がして何か窮屈だなって思う
だけど、その思考で数年やって来たからこの思考から抜け出せない。
プログラムでモノを作るってもっと自由で良かったはずなんだがな…
これが費用も安くて故障したとき、バックアップの NAS をメインに切り替えたら、わりとすぐ復旧できる。
一旦 USB 経由してるのは NAS は転送速度が遅いからで、うちの場合ネットワークの速度が 10MB/sec ぐらいしか出ん（勘違いでした 50MB/sec 以上は出てました）。
数テラ級の NAS とかになると、一晩じゃ絶対戻りきれないので、
運用しながらバックアップしながら復旧するのに、やっぱり2週間はかかる。
幸い障害時に一番に復旧させる必要な箇所のデータは CSV とかなので、先にそこのデータだけ復旧させたら、
あとはなんとか運用しながら復旧できる。
とりあえず大事なデータは NAS に入れろ！って言うのを周知。
個々のパソコンが壊れたら、
物理的に取り出して、USB 接続させてサルベージできるので、そこはあんまり困ってない。
（だったら RAID も同じ機器2台買って二重にしたいタチ）
取り回しのしやすい USB HDD を複数で多重バックアップさせておけば OK と思ってる。
NAS の HDD は Windows にマウント出来ないので一度 Linux 経由でマウントさせてサルベージさせてみようと思ったけど、差分とかどうやって取り出したらいいのか分からなかったし Linux 自信ないので難しかった。
それを踏まえると NAS が壊れたらややこしいので NAS のバックアップは必須。
困るのが
世代バックアップが出来ないぐらい（あんまりそんな問い合わせもないけど）
だから Mac の TimeMachine は個人であんなバックアップシステムは変態すぎる。
Buffalo の NAS は電源を付けたり消したりしているとすぐ壊れるので、24時間ずっと付けっぱなしの方が壊れない。
（Buffalo の昔のファン付き NAS はファンが壊れたらどうしようもなかったので、苦情も多かっただろう（ファン交換部品もオプションであったしね）、いま Buffalo の NAS はほぼファンレスなので耐久性も抜群に上がってきている）
あと Buffalo の NAS は機種によって勝手に画像のサムネイルを生成してしまう余計な機能がある NAS があるので、そう言った機能がないのがプレーンに使えてよい。
LS510DG や LS210DG など 510 210 の桁の品番が、そう言った余計な機能がない品番になる。
会社で使う分には勝手に色々なファイルを生成されるとバックアップに支障をきたすので、そう言った機能がない方がよい。
零細企業と言えども
NAS 4台もあるし、それにともなう USB 接続の HDD も必然的に多くなる。
この理屈で運用すると NAS の倍の USB HDD が必要になる、実際にそうしてるけど。
今余裕がないので予備の NAS でのバックアップが出来てないけど、まあなんとかなるか。って感じ。
「DiskMirroringTool Unicode版」のみ
この Unicode版じゃないと中国語のフォントなど文字によってバックアップ対象から外れてしまうし、4GB 以上のファイルもバックアップ出来ないので、
Unicode版な。
データは大切！これを分かってくれる人は意外と少ない。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
派手に売上落とした理由は主にコロナだろうけど、ラブタイツ効果でタイツの売上が上がったと言い続けてるオタク達見かけて何かモヤッた。
上がるわけねーだろと。
レッグウエアとインナーウエアはレナウンインクス子会社にしたのに、レッグウエアだけ洒落にならん落ち方してる。
オタクエロを嫌うのはアツギの客じゃなかったと嘘で大喜びするのはアツギに気の毒だしやめて差し上げろと。
https://www.atsugi.co.jp/ir/stockholder.html
https://www.atsugi.co.jp/ir/zaimu.html
繊維事業]
（1） レッグウエア分野
新型コロナウイルス感染症の拡大による取引先店舗の臨時休業、在宅勤務や外出自粛の広がりを背景とした個人消費の冷え込み、生活様式の急激な変化等の影響を受け、プレーンストッキングなどのベーシック商品の販売が期初より苦戦し、更には最盛期である秋冬期においてもタイツなどの季節商品が伸び悩むなど全般的に厳しく、同分野の連結売上高は9,899百万円（前期比34.2％減）となりました。
（2） インナーウエア分野
レッグウエア同様、新型コロナウイルス感染症の拡大による取引先店舗の営業自粛、在宅勤務や外出自粛等の影響を受けましたが、株式会社レナウンインクスを子会社化したことなどにより、同分野の連結売上高は5,073百万円（前期比51.0％増）となりました。
これらの結果、繊維事業の連結売上高は14,972百万円（前期比18.7％減）、営業損失は2,922百万円（前年同期は690百万円の損失）となりました。
