  |
はてなキーワード: 管理とは
北一輝のことを言ってる？皇道派が北の思想を実行しようとしたような局面てあるかねえ。
つか岸信介なんかも北には影響を受け、本人は違和感を感じたと言いつつも、彼の業績は「国家社会主義」と呼ばれるに相応しいと思うが。
まあ戦後のそれに比べれば貧相だが、健康保険とか年金とかは戦前からある。
対してアメリカはだいたい民間の慈善・福祉事業に公的資金を投入する、みたいなかたちだろう。
トラックの左後輪に限ってタイヤが脱落する事故の原因だが、これはこの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方式車両の違いは逆ネジ以外に認識しているか調査した
マスコミは整備士の若手不足を指摘するのだが、その高齢化した整備士が昔の感覚のままでいる可能性にも目を向けないといけない。
更にタイヤの交換なんて運送会社じゃ自分らでやってしまうもので、そこで古い規格品の使いまわしされてないか、整備する無資格の人らの意識の更新がされているかにも目を向けないといかんだろう。
地方でポケモンGoしてるとさ、ほぼ出会う人が複アカや位置偽装なわけよ。コミュの半分も単垢いないんじゃないかな。
別に単垢で楽しめればそれでいいんだよ。わざわざ複数メアド管理するのかったるい。
だけど運営はそんなこと理解していないから、交換だとか対戦だとか、明らかに複アカじゃないと厳しいことを導入してくる。
単垢では攻略が無理、複アカで頑張ろう、ってゲームの仕様にしてる
特に地方で単垢で楽しむなんて不可能に近いのがいまのポケモンGo
なのにさ、ときどきをそれを指摘してくる連中がいるんだよ。
戦前日本で上からの管理で国民生活を向上させようみたいな運動あんまりおこらなかったでしょ。
どちらもテーブルトップ由来のオンラインゲームとしては完成度が高いけど、遊戯王マスターデュエルは「遊戯王というTCG界のガン」を持っているのが一番の難点。単なるデジタルカードゲームとしてみれば昨今では一二を争う良い出来なのに、遊戯王というコンテンツがそれを邪魔している。
遊戯王は特に「何をしているのかわかりにくい」「対戦と言うよりソリティアをみているよう」「ルールや効果が複雑すぎる」という問題があり、それがそのまま反映させている。逆にいえば遊戯王というゲームが過不足無く再現されており、そこにデジタルならではの工夫が随所にあって、非常に理想的な遊戯王の環境と言える。対戦を振り返ったり、いまどうしたかという経緯を可視化できるのはかなり便利だ。
今一番必要なのは、動画配信に関するガイドラインの整備だろうか。
対してMTGアリーナはMTGというコンテンツを充分に生かし切れていない面が多い。MTGもまた複雑なTCGではあるものの、ルールの整備やカードの多様性は他に類を見ないもので、遊戯王に比べれば明確にTCGとして面白い。ただしデジタルのゲームとしてはマスターデュエルには機能面で及ばないことがあり、特にバグの多さやチュートリアルの少なさが目立つ。本来のTCGの良さをデジタルゲームが足を引っ張ってる印象。マスターデュエルとは正反対。
ただ、デジタルならではの工夫もあって現段階で最高にMTGを遊べるデジタルカードゲームなのは間違いない。
どっちもやれ
ほらでた、まったく何も分かっていない。
じゃあ原神はなぜ全世界でヒットしてるんだ？
やってみれば「これがゲームじゃない」と言えなくなる。
まああれほどリッチな作りのゲームじゃなくとも、日本のモバイルゲームだって俺に言わせれば立派なゲームだ。
あれは日本人の恥じらいの性質にあわせて、従来のゲームにおけるハイライト的な場面はほぼ自動で眺めてるだけか簡単な指示をするだけで進んでいくためゲーム性がないように思えるが
ああいったガチャゲーのゲーム性の根幹はその前段階にあるわけ。
つまり如何に場面に応じたデッキを組むか、みたいな戦略要素と、いかに効率的にデッキを充実させていくか、というリソース管理要素がゲーム性の根幹になっているわけよ。
まあガチャゲーの中でもリズムゲーとかはそのへんがちょっと逆転していてコンシューマー的ではあるが。
だから知恵熱が出るくらい悩むような楽しさはだいたいのガチャゲーにあるし、スプレッドシートで最適構成をはじき出していくようなスタイルの楽しさになる。
もちろん、従来のゲームのように試行錯誤を繰り返していけば突破できる遊び的な余裕も十分にある(ないとまずヒットしないし低評価爆撃される)。
戦力の充実に関してはカネにモノを言わせることもできる、というだけで、それをしないで遊ぶこともできるし、昔のソシャゲほど対人戦を煽るようなガチャゲーは少ないから課金は趣味の域に留まっている。
逆に言えば、ソシャゲだった頃はカネかけてれば何も考えずともどんなクエストもポチポチで終わっていたが、今のガチャゲーはどんだけ課金していても頭使わんといけない場面が多かれ少なかれある。
俺はファミリーコンピュータの頃から始まりPCのMMORPG全盛、モバグリ全盛のソシャゲ、スマホゲーム、すべてを(人生ぶんなげて)楽しみ尽くしてきたからアイテム課金モデルゲームの洗練ぶりをずっと見てきたし、どれも素晴らしい部分があると知ってるんだ。
害獣は害を与える獣のことであって、種類ごとに指定するのは管理上の便宜にすぎない。
猫は害獣ではないなどと主張したところで事実として害を受けている人達には何も響かないどころか憎しみを募らせるだけのことだ。
まあ実際問題として農村では野生の猫は棒で叩いて焼却炉に放り込んだりはごく普通にやっている。
(法律が禁じているのは「みだりな」殺傷であって、農作物や家畜を汚染する害獣を駆除する合理的判断を禁じるものではない。)
それでもどうしても猫を守りたいというのであれば、長期的な生物的多様性のために我慢してくれとか、なんらかの補償をするというのならわかるよ。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
元アジャイルコーチとして、アメリカのガチの、ガチのシステム開発現場に、言うたらエスノグラフィ（行動観察調査）をしてるようなもんです。三流プログラマながら。
そういうリファレンスみたいなことをお伝えしたら、皆さん（Regional Scrum Gathering Tokyo 2022の参加者）が喜んでくれるかなとか思って、内容を構成しています。
ただ、僕が知っているのはマイクロソフトだけですし、自分の職場だけなので、主語が大きすぎるとか、そう言うのはやめてください。心が傷つくから（笑）
そういうのを踏まえて聞いてください（笑）。全部一次情報で、人から聞いたものではないです。ちょっとだけマネージャ関連のところはマネージャに聞いたところもありますが、基本的には自分が経験したことのみで構成します。
ウォーターフォールは使われていない
まず滝。ウォーターフォールがどれぐらい使われてるのかって話ですけど、これは簡単です。ゼロパーセント、本当に見たことないです。
だからといって本当に素晴らしいスクラムをみんなやってるかっていうと、そうでもない。どれぐらいプロセスに対してマチュア（成熟）かはチーム次第なんだけど、少なくともイテレーティブじゃないのはないし、アップフロントデザイン（開発前の仕様策定）を大量に時間をかけてやってるというのもない。
デザインドキュメントっていうのを書く人もいれば書かない人もいて、書く人が多いですけど、書いても5ページぐらい。
何年か前にサム・グッケンハイマーというDevOpsで有名な人が日本に来たときに日本のお客さんに「ウォーターフォールとアジャイルのメリットデメリットを教えてください」って聞かれて、彼が「ウォーターフォールは全くメリットがないのでやめておきなさい」って言い放って。
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
分かります。誰も使ってないんだから。やっぱりもうやめといた方がいいですよね、正直話無理があります。
次は、僕のチームがどんな感じで運用されてるかっていうお話をします。
マイクロソフトには統一プロセスとかなくて、基本的にチームをどう回すかはチーム次第なんですよ。でもだいたいみんな似たような感じでやってると思います。
基本的にはスモールチームです。どんな大きなプロジェクトであっても、スモールチームの集まりって感じです。
自分のチームについては、これがよいやり方かは分からないですが、個人商店みたいなもので。「IC」というのはIndividual Contributorですね、開発者。
マネージャからアサインされるバックログが基本的にはふわっとしているので、ICがそれを明確にします。
ICが仕様を自分で明確化して、自分でデザインして、インプリメントする。だからそれぞれがレスポンシビリティを持っていて、それぞれが実装をする。
ただ、同じマイクロサービスをメンテする役割の人みたいなのがいて、それは「Buddy」（バディ）みたいになっていて、僕の場合は例えば「スケールコントローラー」っていうのを開発していますが、スケールコントローラーのチームでバディになってると、質問というかお互いに話が聞きやすい。すぐに答えてくれやすいですね。
他のチームとかになると、ちょっとバリアがあって。やっぱりみんなそれぞれの仕事をやっているので、プライオリティがそれぞれあるんですよ。だから違うチームの人になると意地悪じゃなくて彼らのレスポンスは1日に1回とかになったりするわけですよね。仕方がないことです。
多分このチームの単位はマネージャが管理できる最大以下の人数で構成されてるんじゃないかなと思います。だから本当に自分のチームはそれぞれが個人商店みたいな感じですね。自分でレスポンシビリティを持って自分でやる。それは新人であっても一緒です。
司会）ここでちょっと会場から質問が入りました。このチームというのはどういう単位なんでしょうか。プロダクトの単位なのか、どういう単位なのか。
（右下の点線で囲われたところ）このチームはスケールコントローラをやっていて、（右上の3つのICを指して）このあたりはプラットフォームと言って中の基盤みたいなことをやってたりします。
でも基盤もかなり巨大なので、内部でいくつか分かれているんですけど、同じマネージャが見て、みんなを助けている、という感じですね。
司会）隣のチームと、このチームを分けているのは、マネージャが違うだけ？
ええと、大きな機能で分かれているというのがあります。例えば隣のチームはランタイムっていうチームなんで、Azure Functionsのランタイムを担当してるんですよ。
さて、エンジニアの評価っていうのはどんな感じになってるかっていうと、この図にはマイクロソフトは入っていないのですが、僕の友達に「ゆうさん」っていう人がいて、彼がブログでGAFAの給与体系みたいなをまとめてくれて、マイクロソフトも似たような感じです。
参考：GAFA米国本社のエンジニアの年収をジョブレベル別に比較してみた【Google・Amazon・Facebook・Apple】
こういう情報って外部に公開されてるので別に隠すことはないし、マイクロソフトの給料の額とかも調べられるんですよ。
どういうふうになってるかっていうと、エンジニアとしてランクがあるんですよね、「SDE1」「SDE2」とか。マイクロソフトの場合は「シニアソフトウェアエンジニア」があって「プリンシパルエンジニア」がある、みたいな。
このランクの人はこういうことができる、っていうのが明確に定義されていて、それによって給料が決まるんですね。
だから自分が給料を上げたかったらどうするかっていうと、プロモート（ランク上げ）してもらえるように頑張るって感じです。他の人との戦いじゃないんです。
いまより一つ上のランクの仕事をしばらくしていれば、マネージャが「こいつは今はシニアだけどプリンシパルの仕事してるからプロモートしよう」とノミネートしてくれる。
そうやってノミネートされたら次のレベルに行けるし、行けなかったら転職をする。転職するとそこでネゴシエーションしやすいので、その時に例えばシニアとかプリンシパルになれればその給料がもらえる。
ただ、そういうふうに上に行くとレスポンシビリティも大きくなるので、自分でチョイスする感じですね。自分でチョイスするし、自分との戦いなので。だから他の人と比べて不公平とか全然思わない。
給料を上げたかったら次のレベルになればいい。そういうアクションをとればいいので、あくまで自分との戦いって感じになります。
マネージャの存在っていうのは僕的にはすごい（日本と）違ってるように感じています。
日本にいるときはマネージャって進捗管理や課題管理をしたりとかして、プログラマとか開発者を指揮するとかそんなイメージだったんですかね、僕のイメージとしては。
アメリカの場合は、彼らが重視してくれるのは僕のキャリアなんですよ。僕がハッピーかどうかとか、僕がキャリアで成功するかっていうのをすごい重視してくれるんです。
これまで何人かマネージャが変わりましたけど、みんなそうでした。マイクロソフトには明確にそう定義されているんです。だからマネージャはみんなそういう動きをしてくれます。
マネージャのすごく大事な仕事に「アンブロック」というのがあります。IC、つまり開発者の人がどこかで詰まっている状態になると、マネージャが助けてくれる。ブロックされているものをアンブロックしてくれるんです。
例えば、僕が技術的に詰まるとして、誰かに聞かなあかんけど、誰か聞かなあかん人がなかなか答えてくれへんとか、そういうこともあるかもしれないです。
そういうブロックをされる状況が一番生産性を阻害すると思うんですね。
そういうときにマネージャがアンブロックを手伝ってくれる。ある人に繋いでくれたり、マネージャ経由で他の人が僕に協力してくれたりとか。
マネージャが、このプルリクエストを見たら分かりやすいよと教えてくれるとか。
あと結構面白いのは、少なくとも今の僕の職場では、納期が基本的にない感じです。
あるときもあるんですよ。どんなときかっていうと、マイクロソフト最大のイベントの「Build」というのが5月ぐらいにあって、そのキーノートで発表される予定のプロダクトみたいなもの。それが決まったら納期があるのかもしれないですけど。
マネージャも僕に対して「早くしてください」って言ったことは1回もないですね。どっちかというと、僕が「何か遅くてごめんな」とか言ってたら、「いやそんな気にすんなよ」って、「よくあることだよ」とか言われたりする。
これは多分いろんな意味合いがあるんですよね。多分クラウドのプラットフォームって、難しいことがいろいろあって、例えば自分が1週間でできるって思ったのに2カ月かかったりとか、ほんまにあるんですよ。
例えば、JVMにあるJarをアタッチするだけに見えた仕事に、僕は半年かかりました。
僕の能力のなさもあるかもしれないですけど、そういういろんな予想外のことが起こる。
やっぱり世界中の人が使うプラットフォームなので、よく分かってない実装とかしたらむちゃくちゃになるんです。ちゃんと理解して、より良いアーキテクチャを作らないとひどい目にあう。
だから多分マネージャは絶対に急かさないんだと思います。ちゃんと理解して出来るようになれば、次からは開発が速くなる。だからマネージャとしてはそこで急かさないことによって未来への投資をしてる感じなんじゃないかなと、僕は思ってます。
バックログはあり予定もあるが、達成されないこともしょっちゅう
司会）すいません、マネージャの話しに行く前に。質問が集まっていて。納期がないという話に関して皆さんが大混乱に陥っていてですね（笑）。納期がないとすると逆に何があるのか。バックログみたいなのがあるのか、ロードマップがあるのか。どういうものを始点に駆動されていて、牛尾さんの仕事が始まるのか。
バックログですね。大きなトピックだけはある。今期はこれをやろう、というのはあるんですよ。
だいたい今期はこれとこれをやっていこうというのがあって、それを荒い粒度ですけどブレイクダウンしたストーリーにして、それをICにアサインするんです。
でも、それが今期に達成されないということはしょっちゅう起こります。
思ったよりもすごく難しかったとか、あるシステムで改変が入るのでそれまで作れないとか、そういうのがしょっちゅうある。でもそれでそのICが責められることはないです。
変化は見通せないので仕方ないですよね。オーガナイズはされているけど、できなかったときはできないと認める、ということです。
司会）お客様からバックログの元になるような要求がきて、それがリリースされるまでのタイムスパンはどのくらいなんでしょうか？
僕らの場合はプロダクトオーナーみたいなチームとしてプロダクトマネージャがあって、バックログの発生元はプロダクトマネージャが決めるのですが、そのインプットソースとしては、彼らの戦略（ストラテジ－）とカスタマフィードバックですね。
あとはハッカソンでエンジニアがなにかプロポーズするときもあります。
そういうもののなかからプロダクトマネージャが、今期これをやればインパクトがあるんじゃないかと考えるものがピックアップされます。
で、それが達成されてリリースされるまでの期間は本当にピンキリです。
僕の場合は、早いときは1週間で終わりましたけど、さっきの話みたいに1週間で終わると思ったやつが半年かかったこともあります。
僕の上にはプリンシパルマネージャがいるんですね、それが日本で言ったら課長みたいなもので、その上に部長みたいなのがいて、で、テクニカルフェロー、これは事業部長みたいな感じです。
彼らの技術力はどんな感じか。
僕の1つ上の上司は、Azure FunctionsのJavaランタイムをイチから書いた人です。
その上の人は、Azure Automationの開発をしている人で別チームなので細かいところまでは知らないのですが、技術力がハンパない、ということだけは分かります。
何でかと言うと、どんなテッキーな話題を振っても、ものすごく早く深く理解するんです。彼が経験したことのないことであっても、Kubernetesでも、彼がやったことのないPythonとかでも、完璧に理解してアーキテクチャの深い話をするんです。
で、テクニカルフェロー。これはAzureの主要なサービスをイチから書いていたりします。
つまり何が言いたいかというと、僕の上司で僕よりもプログラミングができない人なんて一人もいないんです。
そしてこういう人が僕の仕事のサポートをしてくれる、応援をしてくれるわけです。
だからこんな上司に何かを説得する必要なんてないんです。彼らがテッキーなミーティングに参加して、しかも僕らにすごい鋭いアドバイスをくれるんですよ。
皆さんがもしマネージャをやるときには、こういう人たちと世界で戦わないといけない、ということをちょっと意識していただきたいんです。
なんか普段使いのPCにもLinuxを入れろみたいなのが話題だけど
これが別途用意した開発環境だとある程度で諦めたりしちゃうけど
例えばアップグレードしたらX.org関係がぶっ壊れてGUI出なくなったらマジで困る
必死でX.orgを修復する過程でドライバ周りやカーネル周りに詳しくなる
一括で変換して保存したりお気に入り部分だけを切り出したりしようとしてffmpegに無茶苦茶詳しくなる
FANZAでセールしてないかスクレイピングしてクロールかけたり
なんならFANZAが閉店したときのために漫画コンテンツをキャプチャしてダウンロードしておいたり
家の中でスマホでエロコンテンツ見たくなったらWebサーバ建てたり配信サーバ建てたり
とにかく動機は真っ黒レベルで不純だけど技術は恐ろしいほど蓄積する
しかしさぁ、ちょくちょく情報聞き出そうって連中なんなのかね。昔の友人だったり同窓が突然連絡してきたけど、どうも競合くさいじゃないの。後役所のアンケートだとか。
新しいことはある。劣化コピーなら簡単にできるだろう。劣化コピーゆえにうまく行かないだろうが。
それでも様々な立場を使って起業どうですか？と聞いてくる。実現も困難だから圧力かけてきたり期間迫られる要件もある。
けどまあ、株として金を入れなかったのは正解だな。のらりくらりでやっていける。
と同時に、サブカルでホント作るの楽しすの領域になってる連中は楽しそう。まあ、なかなか気に入られるものを作れずに苦労しているのも一部見て取れる。
だけど、気に入られなくてだめだってのは、どちらかといえば根詰めたり、気にしすぎて疲れすぎるとだめだっていうのを感じる。気に入られないからだめなんじゃないよ。疲れすぎるとか、気にしすぎることのほうが問題なんだよ。
疲れすぎてネガティブになることさえクリアすれば、徐々にファンが増えていく。食っていけるほどではないけど、少なからずのファンがいて作って楽しすなのは見て取れる。
根を詰め過ぎなければ趣味楽しすでいいじゃない。
サブカルでやってる連中に僕の真の姿を見せればすごいことやってるんですね！とかは、言ってくれはするだろう。まあ、表に出せばそのぐらいの反応は得られるのはわかってるし。
飯食えなければ仕方ないし、弱いって時点で足元見られたり、引っ掻き回したりされる悪趣味な人形遊びでしかないとわかったけどな。
世界の外側を見てみたんだ。そうしたら急に妖怪に管理された人間生活が惨めに思えてな。まあ頑張るけど、やめるかもしれない。
君たちのやってることはほんと素晴らしい。ちょっと金を出すぐらいしか僕はできないけど、ホント趣味楽しすで楽しんでいってね！
タイトルのとおりですが、色々トラブルもあったのでまとめます。
（※追記 2022/1/25 市区町村によってはHER-SYS（自動音声）で体調管理をしているらしく、場所ごとにオペレーションはだいぶ異なるようです。）
【陽性者スペック】
30代独身
熱はないが、朝から倦怠感と喉のいがらっぽい "風邪ひく一歩手前の体調" が続く。
喉が明確に痛くなってきたため、10時ごろ地元のかかりつけ医へ。
熱は36.4℃だったが、これから繁忙期のため念のため抗原検査をすることに。
鼻をゴシゴシし、液をたらして20秒ほどであっという間に陽性に。
先生の「あーでちゃったね」が忘れられない。
保健所の連絡先として携帯番号を伝え、そそくさとクリニックを出る。
薬局も電話でコロナ陽性になった旨を伝え、外でクスリの受け渡しを行う。
（処方されたのはムコダイン、トランサミン、カロナールの風邪薬三銃士）
その日のうちに保健所から連絡がくるということだったが結局こず。
ウエルシアの抗原検査キット(体外診断用)を実家の家族が買ってきたため、
自分も分けてもらったら、やはりあっという間に陽性になって一人で笑う。
末端がすごく冷える。寒すぎて風呂に入り、かえって38℃の熱が出る。
・医師の診断により発症日は1/12、自宅療養はそこから10日間を数えて1/22までを予定
・ホテルと自宅療養どちらを希望するか（でもホテルは空きがないとかなんとか）→自宅療養で
※電話に出れないと防護服のスタッフが自宅にくる場合があると脅される
・家族は同居か→先方が把握している住所が実家だったため、一人暮らししている旨と実際の住所を伝える
※実は濃厚接触について聞かれたらどうしようと思っていたが、一切聞かれなかった。
実家ではちょいちょい食事をしていたため、その話も伝えたが「別居していてお風呂など水回りを共有していなければ大丈夫です！」といわれ、むしろ濃厚接触者を増やしたくない圧を感じた。
熱は37℃台。
17:45 東京都自宅療養者フォローアップセンターからTEL
…がなぜか実家にかかってくる。
看護師から30分以内に改めて電話するというので待つが着信こず。
寝てて気づかなかったが、22:47に着信があった。
鼻詰まりが解消。鼻の下と唇がガサガサ。
喉の痛み、咳は若干あり。
・体調の確認
LINEは毎日10時と16時にその日の体調（症状・体温・SpO2）を報告する仕組み。登録者が4万人ほどいた。
体調がかなり快方に向かう。
ただ、なぜか体温が低くなり、35℃台～36℃ちょっとしかでなくなる。実は死んでるかも。
たんが絡む以外の症状良好。体温は依然低い。
コロナの死骸でも陽性になるので、具合悪いとき以外の療養後のPCR検査はおすすめしない（それで陽性になったらまた病院から保健所に連絡するオペレーションになっている）
・保健所から療養終了の証明書がでるので、そちらを利用しほしいとのこと
・看護師からの電話はLINEで体調管理ができていない人にかけているらしい。
食料品とパルスオキシメーターが未だにこないため、フォローアップセンターに問い合わせる。
調査の結果、伝票の電話番号が誤っていたため配送されずに東京都にもどってきたとのこと。
食料品とパルスオキシメーターが実家に届けられる。
近くなので家族に運んでもらったが、やはり住所も電話番号も訂正前のままだった。
夜、自宅療養終了のSMSが届くが、やはりスパムに分類される。
念のため本日も引きこもる。
連絡先を一度誤るとその後のすべての対応が後手に回るので、最初にしっかり確認したほうがいいです。
とどいた食料品は常温保存できて普段食べないものもあったので大変ありがたくいただいています。
↓このあたりがうまかった
本日、自宅療養2日目で使った抗原検査キットを試したら陰性になってた！
まだたまに空咳がでるので、ワンチャン陽性になると思った…これが後遺症ですかね。
住所の件は、保険証が実家の住所なので、おそらくそのせいだと思います。
日本ではあまりポピュラーでは無いが海外では投げ銭対応バイブレーターが市民権を得ていて、これを利用して投げ銭ができるサイトで日夜配信をする男女が後を絶たない。
※投げ銭対応バイブレーター：アプリによって振動の長さや強弱を管理できるバイブレーター。投げ銭の金額ごとに挙動を設定できるため金稼ぎに利用される場合が多い。遠隔操作もできる。
| サービス名 | 月額 | 年額 |
| Amazon | ¥408 | ¥4,900 |
| Adobe Premiere Pro | ¥2,728 | ¥32,736 |
| Conoha Wing | ¥990 | ¥11,880 |
| IFTTT Pro（LEGACY） | ¥235 | ¥2,820 |
| Netflix | ¥1,490 | ¥17,880 |
| mineo（スマホSIM） | ¥1,247 | ¥14,964 |
| NURO 光（インターネット） | ¥2,740 | ¥32,880 |
| 合計 | ¥9,838 | ¥118,060 |
Amazonは年額プランなので月額は換算。IFTTT Pro（LEGACY）は1.99ドルなので支払日の変換レートで若干上下はあるが200～300円。
・IFTTTは先行者利益で300円で使えるのでありがたい。Switchbotと連携してスマートホームもできてるし、サービスが死ぬまで継続すると思う
・Premiere Proが高すぎる。NURO 光とほとんど変わらない金額だったとは……。動画で収益を上げられているわけでもないのでできるだけ早く他ツールに移行して契約止める
・ConoHa Wingは独自ドメインが無料でついてくるのでVPS＋ドメイン取得よりお得感がある。VPSの運用管理から解放されたのも大きい、今のところトラブルもなし
・Premiere Proの契約を終わらせると2700円ぐらい空くのでそれで何か別のサブスクを始めたい。興味があるのはOura Ring。中古でGen 2買ってGen 3移行で永年無料ユーザーを今からでも狙いたい……
| サービス名 | 月額 | 年額 |
| Amazon | ¥408 | ¥4,900 |
| Adobe Premiere Pro | ¥2,728 | ¥32,736 |
| Conoha Wing | ¥990 | ¥11,880 |
| IFTTT Pro（LEGACY） | ¥235 | ¥2,820 |
| Netflix | ¥1,490 | ¥17,880 |
| mineo（スマホSIM） | ¥1,247 | ¥14,964 |
| NURO 光（インターネット） | ¥2,740 | ¥32,880 |
| 合計 | ¥9,838 | ¥118,060 |
Amazonは年額プランなので月額は換算。IFTTT Pro（LEGACY）は1.99ドルなので支払日の変換レートで若干上下はあるが200～300円。
・IFTTTは先行者利益で300円で使えるのでありがたい。Switchbotと連携してスマートホームもできてるし、サービスが死ぬまで継続すると思う
・Premiere Proが高すぎる。NURO 光とほとんど変わらない金額だったとは……。動画で収益を上げられているわけでもないのでできるだけ早く他ツールに移行して契約止める
・ConoHa Wingは独自ドメインが無料でついてくるのでVPS＋ドメイン取得よりお得感がある。VPSの運用管理から解放されたのも大きい、今のところトラブルもなし
・Premiere Proの契約を終わらせると2700円ぐらい空くのでそれで何か別のサブスクを始めたい。興味があるのはOura Ring。中古でGen 2買ってGen 3移行で永年無料ユーザーを今からでも狙いたい……
アカウントもPWも全部こっちで管理してるわけでもなし、勝手にアプリを入れられて登録されてるし。
こっちには分からん、ドコモ行って聞いてくれ、1年後には辞めとけとは言っておいた。
あいつら、マジ糞だな
経済的に考えても、降ってくるタスクの管理にしても、普通に動き回るのにしても面倒だからもうすこし離して産んでるけどね。
更にいうなら自転車に子供乗せる連中はそうしてるんじゃないの？
区内でとても狭い道を子供いることで正当化して車で走るような人だと考えが及ばないのかもしれんけど。
saebou氏は
を発している。
「saebou氏がいきなり雁琳氏の暴言について勤務先の大学に対処を求めた」とう批判は的外れになる。
内容証明郵便の控えもアップロードされておりほぼ真実であろう。
問題は、雁琳氏の手元には内容証明郵便は届いていないということである。
大学は「文章」を所持しているがこれは大学当局が管理するもので雁琳氏に渡すことができないと主張している
→雁琳氏は12月に甲南大学から呼び出されたときにこの「文章」を見ており、最初「自分宛」だったと勘違いしていたが「大学宛」だったと修正している。
→雁琳氏のその時の大学当局との会話の録音内容からはこの文章が1.か2.かは判断できない。
予想
①甲南大学がハラスメント窓口宛文章と雁琳氏気付の内容証明郵便をひとまとめにしてしまい、気付として本人に渡すべきものを渡していない。
②甲南大学事務のサインで内容証明郵便は受理されたが、雁琳氏に渡すまでの間に紛失があった
③雁琳氏の元に内容証明郵便は届いたが雁琳氏が破棄・紛失してしまいその事実を覚えていない
→雁琳氏は大学のメールボックスをあまりチェックしていないという。
①②の場合「saebou氏がいきなり雁琳氏の暴言として勤務先の大学に対処を求めた」とう批判は無効かされる
また雁琳氏の「2021年12月に大学に呼び出されてからの」saebou氏批判が第三者のミスに起因するもののため不幸な的外れとなってしまう。
雁琳氏気付の内容証明郵便控えは間違いなく存在するので、saebou氏主観では「先に本人に伝えた後で、応答がないのでハラスメント窓口に相談した」形式を満たしている。
雁琳氏の怒りの相応の部分はいきなり大学から呼び出されたことに起因しており、ここで問題がこじれている。
現在のweb議論で①②③の可能性が検討されていないのが不思議である。
雁琳氏におかれましては、先ずsaebou氏との論争の前に大学に再度
「文章は2種類届いておりそのうち1つは自分気付で受け取る権利がある」
確認し、
念入りによく探すことをお勧めしたい。
増田の主張
・これを本人抜きにいきなり大学に告発することについては、かなり黒寄りのグレーではないか？
・雁琳氏を部分擁護する弁護士や教授は、擁護の焦点を「本人気付にできるものを飛ばして、いきなり勤務先大学に対応を求めた」に絞る者が多いが
雁琳氏の過去の暴言について、saebou氏から雁琳氏に直接内容証明郵便を送りつけることをそのものを批判する者は殆どいない、と認識している。
雁琳氏にはここを①②③を解き明かし
「今回の一連の発言は突如勤務先に通知が送られたことに対する怒りの表明であり、私に第一報が届くよう配慮したのならばsaebou氏には過去の暴言を謝罪する」
と表明して頂くのが一番穏当な対応ではないだろうか？
