  |
はてなキーワード: パッチとは
先週末の土日もいろいろ捗った。
アルター高原の「夜の騎兵」や「死の鳥」などフィールドボスを撃破しつつ、「ウィンダムの地下墓」をクリア。
「ウィンダムの地下墓」を探している途中に「ゲルミアの英雄墓」も見つけたけど、「英雄墓」と名のつく場所は面倒そうなんで、ここはいったん放置。
面倒そうな「日陰城」は、「堕落調香師」や地中から出てくる蜘蛛人間みたいな「王族の幽鬼」がネックだったけど、近接やめて遠距離攻撃できる戦技「氷槍」ランスの装備でだいぶ楽になった。
ボス部屋の「鉄茨のエレメール」はグレートソードの「獅子斬り」連発で撃破。
部屋の前では瀕死の「パッチ」に遭遇して「踊り子の打楽器」をもらったので「タニス」に渡すも、その後、とくにイベント進展無し。
「ライカード」の遺体を食べる「タニス」ヤバい。気になって首だけのライカードをペシペシ叩くも、とくに変更無し。そりゃそうか。
これ、いつかは食べ終わってイベント進行するんだろうか。
次は、これまた面倒そうな「ソールの城砦」の「宿将ニアール」に挑戦。
前回、近接戦を挑んで惨敗だったので、近接用のグレートソードに加えて「氷槍」ランスも装備、防具は「大楯」持ちの「中量」に変更。
まず雑魚騎士２体を「獅子斬り」で潰してから、後はローリングで「宿将ニアール」の攻撃を回避しつつ「氷槍」で遠距離攻撃に徹したところ、なんとか撃破。
先に進んで「聖樹の秘割符(左)」をゲット。
調子に乗って「ソールの城砦」近くにいる「死儀礼の鳥」「ティビアの呼び舟」、祝福「氷結湖」近くにいる「凍てつく霧ボレアリス」を騎乗戦で撃破。
「聖樹の秘割符」も揃って、あとは「安息教会」から先に行けばメイン・シナリオも進みそうなので、その前に取り返しのできない要素をなるべく潰すため、放置エリアやイベントを回ってみた。
「忌み捨ての底」は２体もいる巨大エビや頻発する落下死に苦労したものの、なんとか「ローデイルの地下墓」に到達して「もう二度と来たくない」の一心で「血の司祭エスガー」までクリア。
「ローデイルの地下墓」は「帰りたい」のメッセージに共感しかなかった。
「忌み捨ての底」自体にはまだ続きがあるらしいけど、シナリオ進行後も再訪できるみたいだし、面倒エリアが続くと心折れそうなので、またしばらく放置することにした。
その他、「王都ローデイル」で時限アイテムらしい「グランサクスの雷」を拾ったり、すっかり放置していたNPCのイベントを進行。
「セレン」イベントで放置していた「サリアの隠し洞窟」をクリア、同じく魔女の「ラニ」イベントでは、まったく眼中になかった地下都市の「ノクローン」や「ノクステラ」へ行ってみた。
ここに来るまで地道に取りこぼしないよう進めてたつもりだけど、一度訪れたエリアでも、行けてない場所やゲットしてないアイテムがどんどん出てきて驚く。
プレイする人によって、ここまでエンディングまでの過程が異なりそうなゲームはそうはない。
面倒そうなエリアは連休中にやるとして、平日はなるべく取りこぼし要素を潰しておきたいと思う。
というわけで、以下、今週の目標。
https://anond.hatelabo.jp/20210723080535
この話の続きのお話
今回更にざっくりなのでふんわりと読んで欲しい。
トーゼンながら一過性の爆増激減が続くわけもなく、今はそれなりに客が戻ってきてる。
NAだとLost Arkがかなり人気でそっちもあって減りはしてる。
WoW開発部門はBlizzardセクハラ報道後定期的にやらかしてて、
まずやった事が「ゲーム内のちょっとエッチな絵画を果物の絵画に変える」事。
その次にやったことが「女性キャラクターの露出を抑える」という、
なんともピントのズレた修正をかましてきた為定期的に大炎上してる。
次の拡張では女性キャラの装備がブルカになるぜみたいなmemeが大量に作られたぐらい。
パッチで緩和されてある程度改善されたとはいえガッツリRaidやるには
トークン回収の為のタスクは山のように積み上がってると言っていい。
WoWは次の拡張で新種族が追加されるのだけど、喜び半分不安半分(またサブキャラ増やさないといけないのかみたいな)
って感じでスタンディングオペレーションって感じではとてもない。
まともな人が戻ってこないからとも言われているが多分これは正しい。
多分今この状況だと治安の悪さはLoLに肉薄するかもしれない。
民度の話と連動するけども、WoWはFF14に例えるとゲーム利用権やその他のものがギルで買えるシステムを搭載してて
プレイヤーの中にもこの存在そのものを疑問視、というよりもすべての元凶扱いする声がNFTMMOも絡めて
ゲーム内通貨が現実通貨に近いものに変換できるのであればPayToWinに他ならないし
そんなものプレイヤーの心は荒れるに決まってるじゃんという話。
吉田がNFTの話出した時に日本と違って海外プレイヤーが恐慌に近いほどの反応を見せたのは
こういう背景もあっての事。
大げさだろと思うかもだが本当。
NewWorldは今では結局一過性のよくわからんゲームだったと言わざるを得ないし
古株のゲームがどんどん規模縮小や開発がNFT導入をチラつかせてる。
WoWも開発への不信感＋大本がMSに買収されてどうなるか分からない。
今北米だとLostArkとFF14の２つが誰が見ても好調と言えるMMOなんだけど、
LostArkは職業で外見と性別がある程度固定されてるので（改善予定あり）
所謂キャラ大好き勢のライトプレイヤーが楽しめるゲームではない。
そういうわけでそこそこのグラでおしゃれな装備が沢山あってPS4でもできて好調なFF14が
リムサのエーテライト前がよくyoutubeの動画で描写されるのは
FF14といえばリムサエーテライト前ぐらいまで他ゲープレイヤーにも浸透してる為。
何故かというと暴言があんまり飛び交っておらず（リムサだけ常時監視してるのかRMT宣伝とかもマッハでBANされる為）
ロスガル2人がエモートで抱きしめあってる横でミコッテが10人ぐらい並んでケツ出してたりしてたり
ララフェルがスプリントしながらセクハラしてたりしててもそういうもんよなで許容される空気がある。
FF14は同性婚が実装されてるのもあって所謂LGBTを名乗っているプレイヤーがめちゃくちゃ元気なのもあるけどね。
重要なのが普通の性癖の人も同じ場所で負けじと大暴れしてる所でこれが真の多様性だぞとか大げさに言ってる人もいるぐらい
当然ケンカはめっちゃ起こってるけど対立を招くとかもなくケンカの範疇で収まってる。
そんな感じで多少なりとも全員で妥協しつつ許容しあってるリムサの光景を心の支えにして遊んでる人が相当数いる。
いやいや、お前がそんなこと言えるのは、緩和前を知らないからだよ。
結構な対価を払ってアカウントが、３年とかで消えるのがデフォだったからね。強制リセマラ。
「火山館」で「牢街教会」の中にある見落としてた昇降機から先に行ってみた。
いったん場所が分かってしまえば何で見逃してたのか自分の認知能力を疑いたくなるほど分かりやすい場所にあった。
一見するとただの柱に見えるのが昇降機だったのだけど、横にあるレバーにまったく気づかなかった。
さらに先で行方不明だった「ラーヤ」にも会って、少し迷ってから「忘却の秘薬」を渡すことにした。
渡さない場合は「手紙」が貰えるそうだけど、深刻な絶望の淵にあって「もう殺してください」とか言ってる相手に「それでも現実に向き合うんだ」とか、なかなか言えるもんじゃない。
週初めの月曜ということもあって「人生、知らないで済むなら、そのままの方がいいこともあるよな…」とか、なんだか鬱になるイベントだった。
「火山館」の「石剣の鍵」使う場所とか残りエリアを踏破するのにわりと時間かかってしまい、あとはルーン稼ぎと武器強化をすることに。
やる気がないのも影響してか、ルーン稼ぎなのはずが度々雑魚敵にボコられて無一文になり、だんだん心が虚無になってくる（夜11時頃）。
いくつか武器を強化するも、どの武器を伸ばして、どうゆうビルドにするかとか画面を前に悩みつつ、圧倒的に低レベルの雑魚相手に試し切りとかしてたら、虚無が深まって、いつの間にか深夜3時になってしまった。
今現在、寝不足で頭はっきりしないし、なんだかテンションも低いし、もちろん仕事なんてやる気でない。
エルデンリング、ボスを撃破するくらいのまとまった（何度でもYOU DIEDする）時間が取れない日には手を出しちゃいかんのかもしれん。
とか言いつつ、やっちゃんだろうけどな。
これ書きながら「火山館」についてさらに調べてると、まだ解放してない祝福「地の底の責問所」があることが判明（まだあるのかよ！）。
そういや、パッチが「鉄製の乙女人形」がどうとか言ってたけど、「学び舎の一室」に近い水車で降った先の話だったのか…。
もし「魔術学院」途中で「火山館」とか転送されたら絶望しかないし、無視で正解だったような気もするが、どうなんだ。
「乙女人形」すごい苦手なんで気が進まないけど、後で行ってみるか…。
以下、今週の残目標
現状で地方にあるのは、農業、漁業、食品加工、飲食業、小売店、食品加工、車販売・整備、建築。
農業については、既に国がバフをかけている状況。
農業に対しての補助金は出ているし、新規開発のための投資資金も出ている。ふるさと納税で地方特産を国内での認知度向上もやっている。
ただ、国内全体での需要は今後人口減で増えない。消費地である東京に売り込むしかなく、東京以外の全ての地域が競争相手という過当競争になっている。
日本全体で農作物の輸出は1兆円になっているが、輸出全体が70兆円～80兆円なので大きくない。
国によって好みの味があるし、輸送コストなどが加わり、日本産は少数で高い部類に入ってしまっている。
各国とも自国の農業を守りたいので、大規模に輸出を増やすということは今後もないはずだ。
高級品種が海外に出ていったら、パクられて海外で栽培されるという事例も今後も増える。
日本食が世界に広まっているというが、実体としてはそれぞれの国でアレンジされ、その地域で取れる食材で作れるようになっている。
歴史的には、労働力が必要だった農業は機械化され、跡取りでない次男などが都市部に出ていって都市部が栄えた。
ただ機械化によって収益の増大と少労働力化は、ほぼ終えている。
今持っているコンバインを最新のコンバインに買い換えるような設備投資をしたとして、借金に見合う収益増大が見込めないから困っている。(経済合理性があるなら既に実施している）
外国人労働力に頼るほど人手が足りてないのは確かだが、下手なパッチをあてているので持続性が疑わしい。
アグリテックは注目されるが、工場による大規模な生産性向上というところまでいけてない。
（工場は加工などによって付加価値つけるの向いているのであって、食物の育成のスピードだと収益が怪しくなる。商品に価格転嫁すると海外産との価格競争に晒される）
海外への輸出に関しても、農作物よりは輸送のしやすさなどはあるが、味の嗜好は各国違うので難しい。
単価が劇的に高くなるわけでもない。似たような味を再現した商品をすぐに作られるのは、今まで経験してきたことだろう。
加工工場自体を海外に作って利益を上げる方法はあり、今の日本の貿易で稼ぐのではなく海外投資で稼ぐ投資立国と一致はしているが、
国内での設備投資が増えなければ給料が増えない、というのはここ数十年経験してきたことだ。
インバウンドが復活する可能性はあるが、外国人観光客が一番行くのは東京だ。
東京に集中している。
東京の人は東京と地方で2拠点生活、週2で新幹線や飛行機で東京と地方を行き来すればいいといった案もメディアで話題になるが、
本社機能が東京にある時点で、地方は衰退していく一方だし、そもそもそんな生活をする人は少数派だ。
国内市場を相手にするのではなく、外貨獲得ができればいいが、東京にある企業ですら出来ていない。
単純なソフトウェアでは市場の大きいアメリカにも、中国にも出て行けていない。
文化的側面が大きいゲームは任天堂のように海外に出て行けているが、日本っぽさを強調しすぎると日本でしか売れず、海外に完全にマッチさせるのは海外企業の方が上で競争出来ない。
そもそもゲームは年々投資規模が大きくなっているにも関わらず、当たり外れがあり、博打に近い。
パッチの出る期間が驚くほど短い殆どのAndroid端末の方が継続的に端末変える需要大きいと思うんだが。
ハイエンドまで含めた幅広い端末から切替先を選べる高額プラン、ミドルレンジまでに制限したプラン、
ローエンドのみに絞った低額プラン、ぐらいに分けて、それぞれ半年に1回ぐらい選択対象端末の見直しするとかすれば
発売からそんなに時間たってない端末をゴミみたいな値段で投げ売りする必要がなくなりはしなくとも減りはするんじゃない？
PlayStationの看板ゲームだったグランツーリスモだけど最新作のGT7がヤバい
GT7のソフトを入れて一番最初に画質の調整をするんだけどそこがバグってる
画質調整の明るさとか色彩とかのバーを動かしても背景が全く変化しない
アハ体験レベルで変わってないのかと思ったけど公式アナウンスで「バグです」とのこと
発売から２日ぐらいでパッチが当てられて修正されたけど、こんな初っ端の正常系部分でバグがあるとかどういうこと？
2P対戦してたら全然1P側に勝てなくて「いやどう考えてもおかしい」って話になって
試しに同じ車でグリッドスタートで直線でアクセル全開にしてみたら1P側の方が速いっていうね
2P側はアシスト設定が反映されないで変な状態で固定だし、マルチプレイもバグってること多いし、もはや対戦は不可能状態
おまけに衝撃的なバグが公表されて、ライセンス取得の試験の中に「ダートドライビング」っていうのがあっていわゆるラリーなんだけど
このダートドライビングの試験に使用する車両にダートタイヤが装着されてないとのこと
滅茶苦茶頑張ればブロンズは取れるだろうけれどゴールドはほぼ不可能
その他、ライセンス試験中にペナルティ表示が出たり車高を1mm下げるだけでPP（車両が出場できるレースでの制限値みたいなもん）が滅茶苦茶下がったり
そもそもGT6の1200車種ぐらいから一気に450車種まで削減
しかも大半は同じ車両のノーマル仕様・レース仕様・〇〇エディションみたいなので稼いでるから実質ほとんどの車種が無い感じ
例えばレクサスはRCFとLC500だけだと思ってもそんなに違わない
LFA無いとかどうなってんの
三菱もGTOは残ったけどFTOはクビだし、トヨタもMRS無いし、日産もシルビアS13はあるけどS14はない
スバルにいたってはレガシィも無いしインプも22Bとクーペぐらい
内装作るの大変だろうけどGT6みたいに無くてもいいから乗させてくれよ
沿道に立ってる人も完全にマネキンだし雨の表現も全然臨場感無いし
そのくせフォトモードとかいうコラ丸出しの写真が撮れる機能搭載
誰が使うの、この機能
もうグランツーリスモは技術力をアピールは出来ないんだな、と再認識
非常に残念
エホバの証人組織は1990年に「血はあなたの命をどのように救うことができますか」という31ページの薄い出版物を発行しています。この出版物は，ウェブ上でもみれます。
その中では，
①輸血をしなくても無血性の血漿増量剤（食塩水・ヘタスターチなど）を使用できること，
②ヘモグロビンが100ｃｃ中１．８グラムまで落ちても救命できた事例があること，
③エリスロポエチンなどのホルモン剤を使って赤血球の形成を促進すること，
④低血圧麻酔法やレーザーメスを使用して患者が必要とする酸素量を減らすこと，
２ また，エホバの証人組織は，「保存版」と銘打った上で，「私たちの王国宣教2006年11月号」という別の出版物の中で，
「受け入れ可能な血液分画」についての一覧表を信者に提供しています。
その中では，
①分画製剤：アルブミン・免疫グロブリン・血漿由来の凝固因子・ヘモグロビン・ヘミン・インターフェロン
②自己血関連の治療：術中回収式自己血輸血・血液希釈・人工心肺・透析・ブラッドパッチ・血漿アフェレーシス・自己血由来の血小板ゲル・標識
トラックの左後輪に限ってタイヤが脱落する事故の原因だが、これはこの10～15年くらいでタイヤに関する規格が色々変わったせいだ。
そもそも重量車のホイールが脱落する時、直接の原因はホイールボルトの折れに因る。だがこれはボルトに問題があるのではない。
ホイールナットはホイールをもの凄い力でハブ（車軸の端でホイールボルトが生えている部品）やブレーキドラムに押し付けている。これによってホイールの裏側とハブ/ドラムの間には巨大な摩擦力が発生する。この摩擦力が車の重量を支えているのである。
これが緩むとどうなるか？
ナットが緩むと先の摩擦力が低減する。そして摩擦力が車両重量を支えられなくなるとこの重さはボルトを切断する力になるのである。1.5cm程度の鉄の棒でトラックを持ち上げられる訳もない。
だからナットが緩みきってナットが取れちゃうのではなく、緩んだせいでボルトが折れてしまう。これが脱落のメカニズム。
日本のトラックの左側タイヤのホイールボルトというのはずっと逆ネジが使われてきた。これはJIS規格による。
逆ネジとは普通とは違い左に回すと締まり、右に回すと緩むネジの事だ。
なんでそんなのを使うかと言えば緩み止めの為だ。左ホイールは走行中左回転する。ここに普通のネジを使うとナット自体の慣性力によって緩んでしまうのだ。
例えば身近なところで言えば、扇風機の羽の中央のネジは逆ネジになっている。これはモーターが右回転し、その起動トルクによって中央ネジの慣性力（止まっていようとする力）が左向きにかかるので正ネジでは緩んでしまうからだ。
これは逆ネジがめんどくせえというのもあるのだが、それよりもトラックのナットはそれ自体が重くて慣性力が強くて緩みやすいって事もあると思われる。
実は増田も最近、トラック＝左逆ネジじゃなくなったと知って驚いたのだが、長年日本ではトラック＝左逆ネジは常識だった。
因みにトヨタとかの1tトラックは左逆ネジじゃないし、いすゞだとワンボックスバンとかも左逆ネジだった。流石トラックメーカーだ。
しかしマツダがいすゞからOEM供給受けるとマツダのワンボックスにも左逆ネジが出てきて実にややこしかった。
2010年にホイール規格がJISからISOに移行したのだが、このISOでは全部正ネジがされている。
だからこれ以後の新車はJIS規格の時の様な緩み止め効果が期待できない。なのでテキトーな整備や放置（乗りっぱなし）をした場合の安全マージンが減っているのだな。
以上のJIS逆ネジからISO正ネジへの変更については指摘している人も結構多いようだ。
だがまだ原因となり得る変更点はあるのだな。そして「左後輪ばかりが落ちる」の「後輪」に関係する変更点は以降の点なのだ。
以前は大型トラックのホイールは「分割式の鉄ホイール」一択だった。これは普通鉄チンと呼ばれる。
分割式と言ってもリムの真ん中で分かれるんじゃなくて手前側のツバだけが外れて、通常は鉄のリングを叩き込んで固定するという方法だ。
これはタイヤチャンジャーを使わずに手でタイヤが組めるという利点があって増田も手でパンク修理して組んでいた。
一方で大きな欠点もあって、まずチューブレスタイヤが使えない。合わせ面から空気が漏れちゃうからね。なので2000年頃まで大型トラックやバスは自転車みたいにチューブが入っていた。これに自転車と同じようなパッチを貼り付けてパンク修理していた。
でもチューブなのでパンクするとあっという間に空気が全量抜けてしまい特に高速道路などで危ない。
もう一つの欠点はこのリングが空気充填中に外れる事故が多いことだ。膨らんだタイヤによって押し付けられて固定される仕組みなので完全に充填されると安全だが、遷移状態の充填中が危ない。
トラックのタイヤは乗用車の4倍近い空気圧を入れるのでこれがはじけてリングが飛んで人間に当たると大抵は死亡事故になる。
その事故態様も凄惨で、頭にリングが当たる事が多いので、顔をショットガンで撃ったような、或いはキルビルのルーシーリューの最期みたいに頭部が切断されて脳がまき散らされるという状況になる。
だから充填時にはホイールの穴にタイヤレバーを突っ込んで（絡ませて速度を減衰させる）人は遠くに離れるというのが鉄則だった。
アルミホイールはタイヤチャンジャー必須になる代わりにこういう欠点が無くなるが、問題もある。
乗用車のホイールもそうだが、ホイールとハブ/ドラムの当たり面というのは平らになっていない。リブがあって凹んでる所を作ってある。
一見、摩擦力が減りそうだが、これは皿の裏側と同じで、真っ平らだと座りが安定しない。ちょっとでも歪みがあると、一番高いところ以外が接触出来なくなるからで、逆に摩擦力が大きく減ってしまう。
その為に、ハブ/ドラムの方に円状に溝が彫ってある。皿の裏側の円状の足が二重になったような出っ張りがホイールに接触する様になっている。
だからホイールナットで締め付けた時にはそのナットの向こうのホイールの裏側というのは宙に浮いてる。力はその周囲の円状出っ張りに分散して掛かってるわけだ。
ところでアルミというのは鉄よりも柔らかい金属だ。だから長年鉄のドラムに押し付けられて巨大な車重がかかった状態でグリグリされ続けているとアルミの方が凹んでしまう。
つまり定期的に増し締めをしてやらないとこの凹みの分だけ締め付けが甘くなるのだ。
更にこのホイールが入れ替えされるとどうなるか。
もとのドラムの当たり面ピッタリで凹んでいるから、他のドラムには「癖が合わない」可能性がある。
その場合は接触面が小さすぎて摩擦力が十分稼げないって事になる。
摩擦力が足りない＝ボルトを切断する力になるって事だ。または接触面が小さすぎ＝直ぐに凹んであっという間に緩むって事である。
乗用車のタイヤを外した事ある人は気が付いているだろうが、乗用車のホイールナットというのはホイールに当たる所がクサビ形になっている。当然ホイール側の穴も逆クサビ型に角度がついている。
クサビ形にすると以下の利点がある。
1.締め込むとセンターが出る
クサビが真ん中に滑りこむ為にホイールのズレが自然に解消される
2.緩みにくい
クサビを打ち込んだ形になるので緩むときには打ち込まれて巨大な摩擦力が掛かっているクサビ座面を横に滑らすという無体な力が必要になる。ホイールナットを緩める時には「ギュッ！」「ギッ！」というような軋み音が出るのはこの為だ。
因みに乗用車のホイール＆ナットのクサビ形状には1.ホンダの球面形状と2.それ以外の単純クサビ型という二つがあるので注意だ。
ホンダにそれ以外のナット、その逆の組み合わせをやると緩んで事故になってしまうのだな。
だがISOでは普通のナットと同じ平面で押し付ける形式なのだ。つまりクサビ効果による緩み止めが期待できないのだ。
トラックの後ろタイヤはダブルになっているが、JIS時代には2本の特殊なボルトを組み合わせていた。
まず、ハブから短いボルトが生えている。これにインナーナットという特殊ナットをねじ込む。この特殊ナットの根元には先の球面座金ナットの先端部だけが付いている部分がある。「インナーナット」で画像検索してもらった方が判り易い。
この座金が内側のホイールを固定する。そして外ホイールの座ぐりに隠れるのだ。だから内ホイールは2つの部分で固定される。
1つがこのインナーボルトの座金。もう一つが外ホイールの当たり面全体だ。
このインナーボルトに外ホイールをひっかけてからホイールナットで締め上げる。
この構造だともし外ホイールナットが緩んでも内ホイールはインナーボルトの座金が押してるから安全だ。
更にナット緩み→摩擦力減衰→ボルトにせん断力→折れという機序を示したが、隣に同じ高さのタイヤがあったら最後のせん断力もかなり緩くなる。つまりナットが緩んでも折れるには至り難い訳。
一方欠点もあって、ハブから生えている親ボルトはインナーボルトが被さる厚みの分だけ細くせざる得ないからそこが弱くなるっていうのはる。
ISO方式ではこれをハブから生えている長いボルト一本にしてしまった。だからナットの緩みは致命的で、内ホイールも外ホイールも一緒に緩んでしまう。
その後は摩擦力減衰→ボルトにせん断力→折れという機序だ。最後のせん断力を最小化させていた「隣の同じ高さのタイヤ」というフェイルセーフが無い構造なのだ。
ここまで読んで来たら「役者多すぎじゃね？」と気付いた方も多いかと思う。即ち、
こんだけある。JIS時代、特に2000年まではJIS規格鉄チンのハブ、ホイール、ボルト、ナットだけだったのだ。
この中には組み合わせNGのものが多数ある。例えば鉄チン用ボルトにアルミホイールを合わせた場合、アルミは厚いのでボルトの長さが足りなくなる。ネジが掛かる部分が足りなくなる。
またISOホイールにJIS用ナットを組み合わせると球面座金＋平面となって接触面積が減って緩んでしまう。
そして運送会社は同じ車両をまとめて購入するのでホイールやナットを使いまわすのだ。
要するちゃんと規格ごとに分けて管理してないとヤバいという事だ。
東北以北+冬に事故が集中というのはここに問題を感じるのである。寒い地域では冬にはスタドレスに換えて、減りやすいので春には戻すのだ。一台ずつやるとめんどくせえのでストックしたホイールに冬用タイヤを付けておき、ホイール毎タイヤ交換していくって方式なのだ。
混ぜて使ってないか？と。そのホイールって昔のトラックで使ってたやつじゃないの？と。
因みにJISのホイールとISOのホイールではボルト穴の並ぶ直径（PCDという）がちょっとだけ違って「付くが付かない（付けちゃダメ）」という状態であり、どこまでややこしいんだと言う外無い。
ホイールナットはトルクレンチという測定器具を使って適正トルクで締めることになっているがJIS時代には誰も守っていなかった。スピナーハンドルに鉄パイプ延長しておもいきり、とかインパクトレンチ（F1のピットインとかで使ってる空気式打撃レンチ）で締めてお仕舞だ。増田もトルクレンチで締めた事無かった。何しろ3/4のトルクレンチって10万以上するんでな。
でも以上のように安全マージンになってた部分が無くなっちゃったので昔の考えでやってると事故になるって事だろう。
国交省はこの事故群に対して「左側は路面が傾きのせいで力が掛かり」とか間抜けな事を言っていてマスコミはそれを鵜呑みにして報道しているのだが、上で書いたような事を全然考慮していない。
現業とスーツ組の間の障壁が大きいんじゃね？JIS時代の規格が決まっていった経緯とか忘れてる気配だ。
・JIS時代とISO方式車両の違いは逆ネジ以外に認識しているか調査した
マスコミは整備士の若手不足を指摘するのだが、その高齢化した整備士が昔の感覚のままでいる可能性にも目を向けないといけない。
更にタイヤの交換なんて運送会社じゃ自分らでやってしまうもので、そこで古い規格品の使いまわしされてないか、整備する無資格の人らの意識の更新がされているかにも目を向けないといかんだろう。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
