はてなキーワード: モニタリングとは
----
6月21日版(anond:20210621175921) から 3月17日版(anond:20220317182626) に至る記事の続き。
日曜区切りでの先週の感染者数は、予測よりも下回り、予測56691 現実53125 (-6%) となりました。ただし、前回から予測を木曜に変更したので、これは実質3日分の予測結果でしかありません。2週目にあたる本日までの推移を見ると、現実は予測よりずっと減少しています。
東京都の変異株検査 (第84回東京都新型コロナウイルス感染症モニタリング会議より)
東京都 | BA.1 | BA.2 | BA.2比率 | BA.2実数 | BA.2前週比 |
---|---|---|---|---|---|
~2月07日 | 181 | 0 | 0.0% | 0 | - |
~2月14日 | 75 | 1 | 1.3% | l 1404 | - |
~2月21日 | 412 | 33 | 7.4% | lllllll 7572 | 5.39 |
~2月28日 | 268 | 36 | 11.8% | lllllllll 9334 | 1.23 |
~3月07日 | 212 | 46 | 17.8% | llllllllllll 12970 | 1.39 |
~3月14日 | 656 | 411 | 38.5% | lllllllllllllllllllllll 23274 | 1.79 |
※ BA.2比率は判定不能を除いた全体における比率。BA.2実数は全体の感染者数を元にした推計。
2月上旬をピークに感染者数全体が減少を続ける状況にあってもなお、BA.2 は増加を続けていることがわかります。また、最後の週は検査数が1000件を超えていて、統計的な信頼性は改善されています。
全体の感染者数は、前回の予測(anond:20220317182626)より大幅に下回る推移をしています。これは、
なお説明が付かない減少幅です。このほかに考えられる要因を挙げると、
などがあり、濃厚接触者の定義の変更が最も妥当かつ影響が大きいのではないかとみています。(それでもなお減少幅は大きいので、これが要因のすべてとまで言えるかはわかりません)
3月16日以降の感染者数に統計的な連続性がないとすれば、少なくとも当面の間、発表される感染者数を予測するのは困難です。検査の飽和と違って元に戻る見込みもないので、5週予測は前回を最後として、終了します。
先に述べたようにBA.2の感染者数は実態として増加を続けているので、いずれ全体の発表数もリバウンドに至る可能性が高いと思いますが、かといって「濃厚接触者の定義の変更のせいで判断が遅れて、ふたたび医療崩壊を招く」という事態になるかといえば、ワクチンの3回目接種が進みつつあり、BA.1系統の感染による自然免疫も期待できることから、悲観はしていません。医療負荷や感染そのものについて楽観しているわけではないので、達観していると言い換えてもいいかもしれません。(※ 同日追記: 定義の変更のせいで減少して見えることよりも、発見されずに感染を広めてしまう機会が増えることで「急増しやすくなる」という恐れはあるかもしれません。その場合は、定義の変更は悪手だったということになります)
これより以前の予測結果は 1月04日の記事(anond:20220104223956) からご覧いただけます。
予測日 | 1週先 | 2週先 | 3週先 | 4週先 | 5週先 | 期間計 | 備考 |
---|---|---|---|---|---|---|---|
1月04日(anond:20220104223956) | +129% | +179% | +36% | -35% | -60% | -41% | 都のオミクロンが全数検査でなかったと後に判明 |
1月11日(anond:20220111172111) | -18% | -62% | -66% | -62% | -26% | -56% | |
1月18日(anond:20220118182610) | -15% | -18% | -40% | -55% | -43% | -40% | (検査数の飽和が報道され始める) |
1月25日(anond:20220125172023) | -11% | -21% | -43% | -44% | -50% | -36% | |
2月01日(anond:20220201171801) | -31% | -55% | -48% | -41% | +10% | -40% | |
2月08日(anond:20220208171541) | -49% | -44% | -29% | -7% | +39% | -32% | |
2月15日(anond:20220215171824) | -41% | -30% | +3% | +43% | +105% | -12% | |
2月22日(anond:20220222220022) | -23% | +17% | +40% | +83% | |||
3月01日(anond:20220301183041) | +9% | +36% | +54% | ||||
3月08日(anond:20220308172859) | +16% | +34% | この週まで予測に BA.2 の考慮なし | ||||
3月17日(anond:20220317182626) | -6% | この週から予測日を火曜から木曜に変更 |
多くの統計値が日曜区切りになっているため、予測もそれに合わせて日曜までの1週間を単位として予測しています。そのため、「1週先」はあくまで日曜までを区切りとしていることにご注意ください。
プラスは楽観しすぎたこと、マイナスは悲観しすぎたことを意味します。ただし、予測は「検査が飽和していなければ」という前提なので、検査飽和中の予測結果はマイナスになりますし、解消中はプラスにブレることもありえます。また、絶対数が少ない時期は大きくブレやすくもなっています。あくまで大雑把な目安としてご覧ください。
政府予測と比べてみたい方は 新型コロナウイルス感染症対策アドバイザリーボードの資料等 からどうぞ。国立感染研の鈴木基先生提出資料と、京大の西浦先生提出資料に予測があるほか、不定期に他の資料でも予測されていることがあります。
千鳥とか有吉の横に大抵女性タレントが一人いるじゃん(トリンドル玲奈とか佐藤栞里とか)。
それで各芸人のネタとか、ドッキリに対してモニタリングをしてコメントするんだけど、最近女性タレントが「可愛い」って表現をめ〜ちゃめちゃ使うのがすごい気になる。
男芸人がちょっと悩んでる姿や落ち込んでたりする状況になると、すぐ出る。自動販売機でコーラ買おうとボタン押したらコーラ出てくるくらいテンプレの表現になってきてる感じがする。
特定の女性タレントに限らず、有吉やノブみたいな権力の横に置物として配置されてるって状況の人に広く蔓延してる感じがする。
自分はここ2、3ヶ月で急に気になるようになったわな。この投稿で楔を打ち込んだので、これを読んでる人も今日から気になりだすと思う。
これは「ごく稀な」副反応が起きた人たちの話
なので、ワクチン接種の「反対」「推進」「リスク&ベネフィット」に関するコメントは別の場所で
コポォwww
んふふふwww 久しいですな、はてなー諸氏www
リクエストがあったワクチンの副反応、それも長期に及ぶ副反応について語ろうかwww
んん…… でもなあ…… 難しいんでござるよ……
これはもう大ウソつき(※注)でござるなwwwwww オウフッwwwwww
かといってあると「断言」するのも難しいwww
まあ、拙者から言わせてもらえばあ?www
「コロナワクチンを接種してから、深刻な体調不良に悩まされている人が一定数存在している」
(「有害事象」といった所でござるが、有害事象=絶対因果関係なしと決めつけてしまうパーソンもおり、この言葉もまた複雑www)
といったところでござろうか?www ドプフォwww
まあ、にわかには信じられんでござろうwww そうであろう?www
去年の十月までは拙者も信じられなかったからなwww ブフォッwww
いわばコロナ禍初期のコロナ後遺症と似たような立場でござるなwww デュフフフフフwww
日本語でおkwww
しょうがないのうwww TOEIC4000点の拙者が説明して...
あ、400点だった。普通www←ヲイ
タイトルは、
「まれに、コロナワクチン接種後にコロナ後遺症様症状が生じうる」
こんな感じかのうwww
2020年末にアストラゼネカの臨床試験ボランティアを受けた女性の話から始まるwww
ブリアンヌ・ドレッセン(当事者)は接種後から視覚のぼやけ、音のゆがみを感じた。
症状は急速に悪化していき、動悸、心拍数の変動、激しい筋力低下を引き起こし、いよいよ彼女が言うところの「体内で電気ショックが流れて衰弱する状態」となった。
コロナ後遺症では200種類以上の症状が起こりうるとも言われているがwww
そのうちの神経症状に近い病態でおまんなwww ドプフォッwww
読み進めると、アストラゼネカだけでなく、現行のコロナワクチンすべてで同様の症状が起きているとの事www
NIHの研究員は「及び腰になったのではなく、少ないメンバーだけでは対処しきれないから」と弁明しているwww フゴッwww
この問題は明らかに存在はしていたが、誰も触れようとしないwww
プレトリウス(南アフリカの生理学者)は「誰もがこの問題を避けています。多くの臨床医や様々な大学の研究者と話しましたが、彼らはそれに触れたがりません」と言う。
であるが、でござるよ
ウィリアム・マーフィ(アメリカの免疫学者)はこう言っているでござるwww
彼は、2021年11月にThe New England Journal of Medicine(NEJM)誌に、SARS-CoV-2スパイクたんぱく質によって引き起こされる自己免疫メカニズムが、コロナ後遺症の症状といくつかの稀なワクチンの副反応の両方を説明するかもしれないと提案し、可能な限りの関連を探るための基礎研究を増やすよう呼びかけた。
マーフィーは、「ワクチンを理解するために、あらゆる研究が行われているとして、一般大衆を安心させることは、単にすべてが安全であると言うよりも重要だ」と言う。
他の人たちと同様、彼はワクチン接種を推進し続ける。
サイエンス社は、規制当局とワクチンメーカーに、これらの副反応について得た情報を問い合わせた。
ファイザーの広報担当者は「それが我々がモニタリングしているもので確認済みだ」と返事をよこした。
モデルナ、アストラゼネカ、JJの3社は、副反応を深刻に受け止め、受け取った報告を規制当局と共有していると述べた。
FDAの広報担当者は「コロナワクチンの安全性の監視に引き続き強い焦点を当てる」と言い、欧州医薬品庁は「コロナ治療薬とコロナワクチンの安全性と有効性を監視するために、臨床現場から実データを使用するための措置をとっている」と通達した。
走召 糸色 木亥 火暴
その結果、当事者はどうなっているのかwwwブフォwww
ブリアンヌ・ドレッセンは「醜いしみがついてしまって、疎外され、見捨てられたようだ」と言うwww
そして、「ワクチン忌避を引き起こす原因になってしまうのではないか」と恐れてもいたwww
(ブリアンヌとは)他の患者は、ワクチン反対派が「ワクチンを接種するほど愚かなのだから、死んで当然だ」と主張してくることを説明した。
その一方で、ワクチン支持者も、当事者が声を上げることで他の人を傷つけ、ワクチン接種を拒否させ、その人がコロナで死んだらどうすると言ってくる。
ドレッセンは已む無く自ら症状を公表し、反ワクチンの議員が開いた会見に出席www
「政治家と話しをすることは、私たちのプランAではありませんでした...。全く違います」と、ブライアン・ドレッセンは言います。
ある患者は違う道を選んだwww
ヤナ・ルアレンダーもまた、引っかかりを感じている。
モデルナワクチンを一回投与した後、ドイツのカッセルで微生物を学ぶ大学院生だったヤナは、ブライアン・ドレッセン(最初の当事者)が経験した内部電気ショックの感覚、顔の部分麻痺、発作か脳卒中を起こすのではと思わせる筋力低下、激しい口の渇き、心拍と血圧の乱高下などの症状を呈した。
彼女は、自分の症状が、血圧や体液のバランスを調整するレニン-アンジオテンシン-アルドステロン系と呼ばれるホルモン系と重なっていることに気づき、ACE2が重要な役割を担っていることを突き止めたのである。
最近、このシステムを標的とする自己抗体が、彼女の症状を引き起こしているのではないか、と考えている医師と知り合いになった。
このような経験にもかかわらず、「私は今でもワクチンは素晴らしいと思っています」とルアレンダーは言う。
しかし、このような副反応は、彼女にとっては、いくらか改善されたものの、消失したわけではなく、認識され理解されるべきものであるという。
副反応が出て深刻な症状に悩まされるwww
それだけでなく、第三者の身勝手な政治闘争に巻き込まれるwww
マーフィ氏(うじ)のくり返しになるがwww
ワクチンによる「まれな」副反応の研究にはたくさんのメリットがあるwww
そして、
チェン(アメリカの心臓専門医)は、ワクチン接種後の慢性的な問題について語る何十人もの人々から話を聞き、彼らの症状とコロナ後遺症の症状との間に重なる部分があることに説得力を感じている。
そして今、彼女は慎重に、かつ科学的に答えを探したいと考えている。「私たちは厳密さを保たなければなりません」と彼女は言う。
「データが圧倒的に不足しているのです」
大切なのはwww 透明性とwww データなんでござるなwwwwww
(注)国www
aquatofana おい増田ニキよ、最初に出てくる事例の女性の名前「ブライアン」って男性名ですがこれはwwww日本語で言えばサトシくんとかですぞ(原文ではブリアンヌ、「さと子」になっとるで)
これは失敬www id:aquatofana 殿の申すとおり変更させてもらったぞwww こっそりとなwwwブフォッwww
【参考】
https://stopcovid19.metro.tokyo.lg.jp/
モニタリング項目
https://stopcovid19.metro.tokyo.lg.jp/monitoring
ここを見ると、
たとえば2月2日時点での
陽性率の7日間移動平均は37.5%、
検査数の平均に陽性率の平均を掛けると
……9663人。
……あれ?
ここ2日間は2万人超え、
感覚的に陽性率37.5%は変だなあ……と思い、
日別の数字を見てみると……
「発表される陽性者数」と
「検査陽性者数」が全く一致しない。
たとえば2月2日は陽性者数として
21576人が発表されているが、
「抗原検査陽性者数」は2428となっていて、
合計は8875。
「計上されるまで時差があるのでは」と思い、
それ以外の日を調べてみると、
2月2日のように倍以上違う日がある一方で、
(発表される陽性者数のほうが多く)、
また基本的にかなりの大差なので、
陽性率は時差で上がっているわけではなく、
「発表される陽性者数から算出する陽性率」より
「モニタリング項目としての陽性率」のほうが
(確認した限り)ずっと低いままになっている。
この「発表される陽性者数」と
「陽性率算出に使われる検査陽性者数」の
違いがどこにあるのか、
詳しい人、教えてくれたらありがたいです。
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。
【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から見ると単に1つのプロセスが稼働している扱いになる。
【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%増加する、という任意のステップに従ってタスク数を増減させる
家電のシャープがIT業界に進出したってのも驚きだが、いまさら境界セキュリティってのも驚いた。
シャープ株式会社は、攻撃トラフィックを検知・遮断する機能を備えたセキュリティスイッチ「BP-X1PL01」を、1月下旬に発売する。価格はオープン。
BP-X1PL01は、社内のネットワークに侵入したマルウェアなどによる攻撃を遮断し、被害の拡大を抑制するセキュリティスイッチ。社内ネットワークの監視を常時行い、マルウェアなどによるサイバー攻撃を検知すると、発信元の端末をすばやく特定して有害な通信のみをネットワークから遮断する仕組みを備えているため、被害の拡大を抑制できるという。
また、クラウド上の統合管理システムが稼働状況を常時モニタリングしており、異常発生時にはメールによって迅速な通知を行える点も特徴。さらに、複数拠点の状況をクラウドで一元管理できるので、IT管理者の業務を効率化できるのみならず、IT管理者の配置が難しい中小企業やSOHOなどの小規模オフィスにおいても、容易に導入・運用できるとした。加えて、自動セキュリティレポート作成機能を搭載し、脅威の検出状況を数値やグラフで可視化して提示してくれるとのこと。
インターフェイスは、1000BASE-T/100BASE-TX/10BASE-T×8ポート、SFP×2スロットを備えた。スイッチのベースエンジンには、PIOLINK社製のものを採用している。
なおシャープでは、内部対策としてBP-X1PL01を用いる一方で、同社のUTMアプライアンス「BP-X1CPシリーズ」を導入し、出入口対策をあわせて行うことで、より強固なセキュリティ体制を構築可能になるとアピールしている。
石原さとみは阿部華也子や新井恵理那と比べても可愛いあるいは美人なのかと比較されたら、軽々しく前者だと決めつけることはできないと思うんだ
つまりそれだけテレビで活躍しているということで稼ぐ量も多いはずなんだ。
これら単純に石原さとみの方が美人であるからということに過ぎないのだろうか。
俺には三者の顔立ちの質の高さにそれだけの差異を見出すことができない。
丸山桂里奈のように顔が悪くても気配りが上手ということで業界に好かれてるタイプの人間もいるが三者にはそのような差異もないと思う。
なぜ石原さとみが、モニタリングでも男女の憧れの象徴のように使われているように、あそこまで売れているのか不思議に思った。
(比較対象について疑問に思う人がいるかもしれないので断っておくと、引き合いに出してる二者は石原さとみより活躍してないが顔の良さには原因を見出せないと思える人なら誰でもよかった。)
これは楽天モバイルアドベントカレンダーの出遅れ記事です。嘘です。すいません。
インディアンスの楽天モバイルネタ最高だったのでこの記事を書きました。
1プランでわかりやすい料金体系、最低金額は無料、契約して1年間無料というすごい携帯キャリアです。
私は今年の3月から使っており、その品質には概ね満足していました。ところが11月中頃(曖昧)から楽天モバイルの圏外が頻発するようになりました。
ローミング終了に伴い一部エリアでは使えなくなるかもという話は知っていましたが、私がいるのは都内の3線利用できる駅前エリアで今ままでもパートナー回線を使ったことがありません。
おかしいなーと思いつつちゃんとログを取ろうと思い、楽天モバイル端末のWiFiアクセスポイントをONにして手元のノートPCから疎通確認をしてログをとることに。
楽天モバイルのDNSが落ちたことはあった時はDNS設定いじればどうにかなったけど、そもそも圏外はどうしようもありません。
crontabもないし、shじゃないし、tail,awk,uniqもないし面倒でした。
5分に一回 1.1.1.1 にpingを飛ばしてその結果をログに残しました。
以下はbatで書いた処理
@echo off ping -n 1 1.1.1.1 | findstr /i "TTL" > nul if %ERRORLEVEL% equ 0 ( set ret=success ) else ( set ret=failure ) echo %date% %time% %ret% >> %~dp0check_net.log
-- tail -3 相当のps type .92;check_net.log | select -last 3 2021/12/27 22:20:02.44 success 2021/12/27 22:25:06.00 failure 2021/12/27 22:30:05.99 failure -- awk '{print $1, ":", $3}' | uniq -c 相当のps type .92;check_net.log | %{$tmp=($_.toString() -split("92;s+"));echo ($tmp[0] + ":" +$tmp[2])} | group -NoElement Count Name ----- ---- 143 2021/12/19:success 6 2021/12/19:failure 208 2021/12/20:success 81 2021/12/20:failure 279 2021/12/21:success 9 2021/12/21:failure 221 2021/12/22:success 67 2021/12/22:failure 101 2021/12/23:failure 188 2021/12/23:success 277 2021/12/24:success 12 2021/12/24:failure 144 2021/12/25:success 69 2021/12/25:failure 287 2021/12/26:success 2 2021/12/26:failure 43 2021/12/27:failure 225 2021/12/27:success -- 時間ごと type .92;check_net.log | sls failure | %{echo $_.toString().Substring(11,2)} | group -NoElement | sort Name Count Name ----- ---- 21 0 17 1 19 2 20 3 40 4 47 5 42 6 41 7 21 8 9 9 17 10 14 14 18 15 8 16 23 17 14 18 6 19 1 20 6 21 7 22 5 23
ログが不十分なのは途中でログファイル消しちゃったのと、ノートPCを閉じちゃってタスクスケジューラが止まってたタイミングがあるため
途中まで `findstr /i "TTL"` がなかったのでsuccessだけど実際は疎通できてないものがあります(pingの宛先ホストに到達できませんはsuccess扱いだった)
12/23がひどい。1日の35%繋がらない。「日本のスマホ代は高すぎる」けど繋がらないんじゃ意味ないんよ。
11~13時台は落ちてない。逆に何故。
5分に一回の計測なのでたまたまそのタイミングだけ疎通したりしなかったりってのはあるけど、その割合は落ち具合の体感と一致します。
テザリング利用では1日10GBの制限があるらしいですが、制限には引っかかっていません。
今も利用しているのは無料期間中なのと、楽天モバイル回線はYoutubeとかネットサーフィンとか止まっても許せる範囲で使っているからです。
これをメイン回線にしてたら緊急の連絡とか取れないだろうし、だいぶ困りそう。
書き込もうとしたけど、楽天モバイル回線は圏外で書き込めないので別の回線で書き込んでます。
RSRQは-15でした、どいひー
https://blog.tinect.jp/?p=74400
採用をしていると、
「この方は、「仕事やってるフリ」ばかりしてたのでは」
と感じるときがある。
*
彼は、「コーポレートサイトを改善し、お客様に使いやすいサイトを実現しました。」とアピールしていた。
そこで、我々は
「具体的には、「使いやすい」とは何を意味しているのですか」と尋ねた。
彼は、戸惑ったような表情を見せたが
と言った。
なんとも、抽象的な話だ。
そこで、我々はもっと具体的な意見を求めるため、自分たちのコーポレートサイトを見せた。
「では、このサイトを見てアドバイスをいただきたいのですが、これは「見やすい」ですか?そうでないなら、具体的な改善事項を指摘してください。」と要求した。
しばらく後、彼はモゴモゴ何かを言っていたが、結局
「見やすいと思います。」と言うだけで、意見らしい意見はもらえなかった。
結局、彼を採用することはなかった。
彼の言動から、「仕事やってるフリ」の人であると判断されたからだ。
*
彼は「研修などを通じて、活躍できる人材を送り出すことに、価値を感じていた」と、前職での仕事をアピールした。
そこで我々は、「どのような研修を行っていたのですか。」と聞いた。
彼が主に担当していたのは、新任向けの「管理職研修」と、新卒採用後の「新人研修」だった。
知識を与え、同じような立場の方々とディスカッションすることを目的としたという。
そこで、我々は
「研修の成果をどのように定義していましたか。活躍できる人材とは、どのような定義でしたか。」
と、彼に尋ねた。
彼は言った。
「受講者にアンケートをとっており、高い満足度を実現できるようにしていました。」
しかし、考えてみれば「研修の満足度が高いこと」は、「活躍できる人材を送り出すこと」とは全く異なる。
我々は、それを彼に指摘した。
「どうなんでしょう?」と。
彼は
「そうですね。ただ、研修を受けることで、知識やほかの人の経験を共有できるので、効果はあったと思います。」
と言った。
表層的な回答だ。回答になっていない。
「この場で考えてくれてもいいですよ」と勧めたが、彼は考えず、答えられもしなかった。
*
「研修の効果測定を、1年程度、モニタリングしませんか。費用は要りませんので。」
と持ち掛けたことがある。
実際、どの程度役に立っているかどうかを知ることが先決だったので、費用をもらわずともデータが採れれば良い、と思ったのだ。
だが、帰ってきた反応は予想外だった。
「忙しいからねぇ」と言った。
他に声をかけた多くの会社でも、やはり同じような反応だったため、なぜ研修の効果測定を真面目にやろうとしないのか、私は不思議だった。
そんな時、私の大学時代の知人が、ある大手企業で人事をやっていると聞き、現状のヒントになればと
と彼に連絡を取った。
久々に再会した知人は、率直に話してくれた。
「いやー、「忙しいからねぇ」というのは、まさに本音だよね。」と。
私は尋ねた。
「本音といっても、研修にこれだけお金を使っていて、「忙しいから効果測定はしない」じゃ、まずいだろう。」
知人は迷うことなく言った。
「余計なお世話なんだよ。たぶんそういう人たちは「研修の満足度が高くて、参加後のレポートを書いてもらえれば、それで十分」と思ってるよ。」
「なんで。」
「もちろん。だって「効果がない」と分かったら、場合によっては研修を取りやめないといけない。予算も削られる。だいたい、研修やってさえいれば人事は「仕事やってるフリ」ができる。」
私は知人が皮肉を言っているのかと思ったが、彼の目は笑ってなかった。
私はようやく理解した。
「ああ……なるほど。そういうことね。」
*
コンサルタントをやっていて、驚いたことの一つは、上のように、「仕事やってるフリ」をしている人が、かなりいる、という事実だった。
もちろん、「成果」が定義しにくく、「ひとまずやってみよう」という活動があることは理解できる。
しかし、成果を熟考する取り組みさえ行っていない方も多く、「なんのための仕事?」と首をかしげることも多々あった。
ピーター・ドラッカーは、「成果をあげる8つの習慣」を著作の中で紹介している。
(1)なされるべきことを考える
(2)組織のことを考える
(4)意思決定を行う
(5)コミュニケーションを行う
(6)機会に焦点を合わせる
(8)「私は」でなく「われわれは」を考える
もちろんこれは、多くの人にとって「もう知ってるよ」と言われてしまうくらい、単純なことだろう。
だが実践編である、「成果にこだわりぬいて仕事をすること」は、とても大変だ。
疲れる。きつい。ドキドキする。失敗して怒られるかもしれない。
うまくいかない事の方が圧倒的に多いし、そもそも成果とは何なのかを定義するのも、簡単な仕事ではない。
「意識たけーなー」と嘲笑され、「何ムキになってんの?」と蔑まれることもある。
しかし、だからといって「仕事やってるフリ」ばかりしていると、キャリアチェンジはままならず、収入も伸びず、組織から「飼い殺される」人生が待っている。
そうなった果てに言われるのは、「お前は単なる作業者で、頭を使う必要はない」だ。
そうなりたくないならば。
若いころから、成果を意識し、成果を追及する技能を身につけるしかない。
成果とは何かを理解しなければならない。成果とは百発百中のことではない。百発百中は曲芸である。成果とは長期のものである。
すなわち、まちがいや失敗をしない者を信用してはならないということである。
それは、見せかけか、無難なこと、下らないことにしか手をつけない者である。成果とは打率である。
そういうのが本当にあったとしてもうれしくない。
好きになった人じゃない容姿の人が好きな人の動作性格をするってうれしいか。
客観的に美しさに照らして美しいと思えたとしてそれが何になる。
好きになった顔とは違ってるんだから同じ人と対峙してるんだとしてもいつものようなときめきもなくなってしまうだろう。
俺が好きになった顔で俺だけに見せる顔をするからいいんだ。どこぞの芸能人でその顔をされても興味がわかないという人もいるだろ。
しかしこれは思考実験として深めていくと恐ろしいことになってくる。
たとえば催眠術じゃくて本人の意思として整形手術でどこぞの美人女優と呼ばれる者と瓜二つになったら受け入れられるだろうかとか。
もはや元の顔ではないが、それは本人の意思なのだ。連続性があるのだ。
老化しても受け入れるだろう。同一性という観点では整形も同じだ。しかも老化と違って本人のなりたかった意思だ。受け入れるのが筋ということになる。でもこの結論は妙な気がする。
ものまねで元ネタの本物の歌手みたいに歌う人が本物の歌手より収入が少ないのはどうかしてる。
ジェネリック医薬品作ってるとこが元の製薬会社より収益が少ないということはないじゃん。
モニタリングで素人に対して本物とものまね歌手はどっちか当てさせるのやっても外れること多いじゃん。
ああいうことして有意な差が出ないならばもうそれは本物も物まねも現れた時期が違うだけで実質的には同等ということだよね。
長渕剛とか米津玄師のものまねをする人が本人と同じぐらいもらうべきなのだ。
それなのに一般大衆は本人が歌っていることに価値を見出す。目隠しされたら間違える人も半分混じってるくせに。
そういうわけでやっぱり本人の方に大きな金がいく。不条理だと思う。
一般に9時とか10時のドラマで主役取るような20代~30代(場合によっては10代も)の女優はそのルックスから男人気が高いとされている。
というよりも、そうであるという印象を植え付けようと、日々そういう印象操作活動を「テレビ側」が継続しているといったほうが正しいかもしれない。
だって男人気が高いなんて、肌感覚で実態とは合わないと、男として思うから。
告白されたら振ることはまずないだろうが、女優として売れてる人たちの顔って性的にそそられるようなものではないと思う。
端的に言えば穴に突っ込んでも勃たない気がする。恋愛対象ではありうるが結婚しても一生ディンクスなんてことになりそうだ。まあ親族に対して鼻高々にしていられるぐらいの価値はあろうか。
男にとって女とは抜ける穴と抜けない穴に分類される。言い換えれば、ブスか、ブスでないか、だ。
明らかに女優は「ブスでない」方に分類されるが、ああいう顔は演劇において優れた威力を発揮する、言い換えれば、様になるという状況を作り出すのに優位なものなのであって、別に男を興奮させる顔というのとは違うと思う。
でも男たちもまた自分のプロフィールを伝えるのに「好きな女優」を言ったりすることが多い。これは結局、本当に抜ける顔としてはAV女優のあの子が本来の好みということであっても、それを言ってしまっては下手したら社会不適合者の変質者扱いされてしまいかねないから自重しているだけなのだ。AV女優の好みなんて千差万別でゴールデンタイムの女優を引き合いに出すの違って話題の共有が難しかったりそこで話が盛り上がらなくなってしまうという問題もある。
しかし多くの男はそれを自分だけの問題だと思っている。対外的には「新垣結衣が好き」とかみたいに答える男にしか出会わないから。
これは言うなればパノプティコンに囚われているようなものだろう。本当は皆テレビの女優などそこまで好みではない、でも各々社会的正しさという壁に隔たれて実際の好みを明かせないから、「俺は違うけど、ゴールデン女優は男に好かれているんだろうな」というのが各々の頭の中の主観的事実になってしまうのだ。結局それはテレビの作り手にもおよび「男なら、長澤まさみが好きなんだろう!?」と乱心を起してそういう内容のバラエティばかり作ってしまう。(その筆頭がモニタリングだ。)
ゴールデン女優が人気という印象には波風が立たないとこともあるかもしれない。女優ぐらい綺麗な人に男がなびくのは許せるって感覚が女にはある。
しかしこの綺麗というのは舞台映えするということの言い替えでしかないのだが、そこらへんあけすけにして男にとっての本当の好みが伝わってしまうような番組作りをするようになればたちまちフェミニストなどが黙ってないだろう。
まあそんなわけですよ。俺みたいなことを思った人には他にもいてその疑問を表明したブログなり星の数ほどあるのかもしれないが、そういうのはグーグルに「しょうもないこと」と認定されてSEOの影に追いやられているだけなのかもしれない。そこで俺もまた「誰も言わないことを思い切っていってみたと勘違いした者」の一員になってしまっただけかもしれない。おそらくこの増田などを見つけられなかった人がまた同じような内容の文章をネットにあげるわけだ。歴史は繰り返すのだ…。
※フェイク込みかつ突発的に書き殴った文章なので、多少矛盾が生じていても見逃していただきたい。
それはまるで、見えないくらい遠く離れた川の対岸の、それでも同じ世界で生きている人を見つめるような、そんな奇妙な感覚だった。
突然だが、私は8月某日に2回目のワクチン接種を済ませた。3月ぐらいからずっと待ちに待った瞬間で、油断せず感染防止対策は引き続き頑張るぞとは思ったものの、やっぱり心中を占めていたのは無事に終わったことへの安堵だった。
そんな気持ちのまま、自分のTwitterアカウントでフォロワー(ほぼリアル友人しか居ない)へ接種の報告と、その後の副反応の経過を書き連ねていった。医療従事者を除けば仲間内では接種が早い方だったこともあり、何かの参考になればという思いからだった。
フォロワー達からいいねされた通知がちらほらと届く中、それに紛れて見知らぬアカウントから、とあるリストに入れられた通知が届いた。その名も、「ワクチン接種済み」リスト。なんだこれと思いリストの詳細を表示すると、リストに追加されているのは私のような一般人らしきアカウントもあれば、議員さんやジャーナリストの方の公式アカウントなんかもあって、リスト化されたアカウントには一見なんの接点もないように見えた。
ただ、リスト名がリスト名なので早々に見当はついた。少しリストの中身を遡ってみれば、私と同じようにワクチン接種報告のツイートが確認できた。文字通り、ワクチン接種済みのアカウントをリスト化している。アカウント数はおよそ300くらいだった。
この時点で有識者の方々はあ〜……と嘆息しているかもしれないが、その時の私はまったく気が付かず、というかお前は誰やねんwとノータイムでリスト作成者のホームへと飛んだ。
リスト作成者の彼ないしは彼女(なんとなく男性っぽかったので便宜上彼と呼ぶ)は、イベルメクチンを個人輸入し、コロナはただの風邪という主張の書かれたFacebook投稿のスクショをツイートし、ワクチンは人口削減のための陰謀などといったツイートを頻繁にリツイートしていた。つまるところ、陰謀論を信じている人だった。
ここに来てようやく自分をリストに入れた相手の正体を知って、当然のように私は混乱した。マジでこういうの信じる人いるんだって言うか、こんな、フォロワー数2桁の末端アカウント(しかも明らかに実名でもなんでもないオタク垢)を、わざわざ見つけ出して監視する意味はどこに? そりゃ鍵かけてないから誰でも見られるんだけどさあ!
怖いもの見たさで少しだけ彼のツイートを遡ってみたが、どれも混乱をもっと酷くする内容でしかなかったので、そっと自分のTLに戻った。フォロワーが推しの尊さに涙を流していて、なんだかとても安心したのを覚えている。
さて、ここから取るべき手段として一番良いのは、相手をブロックしてしまうことだった。ブロックすれば相手のリストからも自動で削除されるらしいとGoogle先生に教えてもらい、早速実施しようとしてふと、その手が止まった。
なんで彼はこんなリストを作っているのだろう? え、陰謀論で脳が溶けたような相手にそんな明確な理由を求めるな? ……本当にそれでいいのか?
おもわずブロックする手を止めてしまったのは、先述したとおり何故こんなリストを作ったのかが分からなかったからだ。だからと言って直接聞くのも高確率で地雷踏みそうで怖い。なので、少しだけ彼が何をしたいのか考えてみることにした。
私がワクチン2回目を接種した8月某日時点で、少なくとも1回接種した人数はおよそ5700万人、うち2回接種済みはおよそ4000万人だった。ワクチン接種数は後追いでちょこちょこ追加されるので、今見ればもっと多い数字になっているかもしれない。細かい部分はさておいて、私をリストに入れた時点で、彼は5700万人のうちの300人を監視していた。つまり、1回以上接種を済ませた人の約0.000526%を監視しているわけだ。思ったより小数点以下に0が多くて計算方法をミスったかと思ったレベルの割合の人々を監視して、果たして何がしたいのか?(というか本当にこのパーセンテージ合ってるよね?)
ここまで考えて、ある考察が頭を過った。よくあるワクチン陰謀論の中に、ワクチン打ったら2年後もしくは5年後に死ぬという説があった。少し常温で放置しただけで使えなくなる儚いワクチンに期待しすぎwと私は笑い飛ばしたが、彼なら信じていてもおかしくない。もしかして彼は、それを確かめるために目についた接種済みアカウントをリストに入れて監視しているのでは? だとしたらこのリスト、そんな長期計画で運用されてんのか……。
ただ、この説も理由が分かっただけでなんだか釈然としない。仮に数年後に死ぬのが本当だとして、0.000526%をリストで監視する必要など無い。だって、現時点で1回以上接種済み人数は日を追うごとに増えているし、2回目接種済みの割合も既に全体の50%を超えている。更に言えば、先陣を切ってワクチン接種を推し進めたイスラエルや欧米諸国などでも一部伸び悩みこそあるが接種率は高い。それらの人々が数年後にバッタバッタ倒れていったら世界の一大ニュースだ。各国政府はそれを隠蔽するんだ! という主張もあるかもしれないが、この場合は隠蔽する側の政府も多分死んでるし、SNSの浸透した日本で過半数の人がバッタバッタ死んでいったら流石に隠し通せるわけがない。
つまり、私を含めた接種済みリストの人々がTwitterを更新しなくなったのが確認できたところで、その頃にはリストの何百倍もの人々が死亡したニュースで溢れ返っているわけだ。ああリストの人たちも死んだんだな〜、以上の情報は得られないだろう。
ここまで考えても、彼が何をしたいのか分からない。数年後死亡する説云々は置いておいて、単にワクチン接種後の経過観察をしたいだけかもしれないが、そのモニタリングは厚労省がやっているし、なによりサンプルに問題があるように思えた。前述したとおり、私は実名でTwitterをやっておらず、正確な年齢も公表していない。性別はツイートを見ていればなんとなく分かるかもしれない。得られる情報としてはおそらくの性別と、65歳以下であることと(まあ20〜30代くらいというのは読み取れるかも)、打ったワクチンがモデルナ製であることくらいだろうか?
統計学については全く素人かつ数学の苦手な文系人間の考えで恐縮だが、統計的なサンプルを見繕うにあたって、こういった年齢・性別などのパーソナルデータは正確なものであるべきではないだろうか。また、ツイートからは読み取れない基礎疾患の有無や喫煙者か否かなども、ワクチン接種後の副作用という医学的な事柄であれば尚更必要な情報だと思っている。違ったらごめんなさい。
リストに入れられている人の中にはもちろん、議員さんを始めとする実名でアカウントを設けている人も含まれているが、私のような有象無象のアカウントも含まれている時点で、より不正確な統計データになっていると思う。ますます彼の目的も、そのための手段も理解できなくなっていく。
彼は何を思って、リストを作成し、私をその中に入れたのだろう。この広いTwitterランドの中から、私を見つけ出した人のことが純粋に知りたかったのかもしれない。気がつけば私は、混乱の中で撤退した彼のホームにもう一度アクセスしていた。私のツイートも確実に見ているんだから、逆に私が彼のツイートを見たっていいだろう。
彼のアカウントのbioは攻撃的なものでなく、よくある時事ネタも含めて呟く個人アカウントといった趣だった。あまり詳しく記述するのも良くないし、彼のアカウントが特定されるのはなんだか居心地が悪いので詳細は省くが、アイコンもヘッダーもごくごく普通のものだった。ただ、その下に広がるのは陰謀論と陰謀論と陰謀論。頻繁にリツイートをしているせいで、彼本人のツイートが見つけられない。それでも、メディア欄でようやく見つけた彼のツイートからは、彼の日常が垣間見えた。指定日配達が日時通りに届かないかもしれなくてヤキモキし、朝食と共に自分で淹れた紅茶を楽しみ、時に自宅での晩酌の写真を上機嫌でUPし、庭で育てた草花を慈しむ。もちろんその数十倍は読んだだけで頭痛を引き起こすような陰謀論ツイートで埋め尽くされていたが、それ以外は本当に、ごく普通の人だった。
それと、彼がマスクを頻繁に購入している様子も見てとれた。反ワクチンだけど反マスクというわけではないのか……陰謀論信じている勢も多様だな……と感じ入ると同時に、彼もまた不安なのかもしれないと少しだけ思った。
このコロナ禍で、不安を感じなかった人などどれくらい居るのだろう。私ももれなく不安で、とにかくステイホームするしかなく、実家の家族や遠方の高齢の親類がどうか感染しませんようにと祈ることしか出来なかった。インターネット上には様々な情報が溢れていて、コロナウイルスは26度のお湯で死ぬとかいうふざけた情報なんかも蔓延した。26度ってそもそもお湯じゃねーだろ。
冒頭で記述したとおり、私はワクチン接種ができる日をずっと待っていた。それは自分の命のためでもあったが、それ以上に自分の周りの大事な人へ感染させたくない気持ちが強かったからだ。だからこそなるべく早く自分が打って、その様子をレポートすることで接種を迷っている家族や友人の後押しになればと思った。幸いにも職域接種にて早めに接種する機会を得られ、望み通りレポートも出来た。まあ、まさかそれが理由で監視リストに入れられるとは思いもしなかったけど。
ワクチンについての情報は、なるべく正確なものをと思い厚労省のものを主に参考にした。また、Twitter上で医療従事者の方のアカウントで発信される情報も参照していた。なるべく医学的な根拠のある、エビデンス付きの情報が欲しかったからだ。ありがたいことに、私が参照したアカウントの方々は信じるに値するエビデンスを付けて情報を発信していてくれた。でももし、それらより先にYoutubeやFacebookでばら撒かれている陰謀論に触れていたら? もし、それらを信じ込んで家族や友人にその情報を発信していたら? きっと私は、今の私とは正反対の人間になっていたと思う。
私と、私をリストに入れた彼と、それほど大きな差があるとは思えなかった。この不安が渦巻く世界で、私は私の信じたいことを信じ、彼は彼で信じたいことを信じている。彼の信じた情報が多くの人に陰謀論と断じられているだけで、得た情報が違っていたら、意味不明なリストを作っていたのは私の方だったかもしれない。
彼について色々と語ったが、私の意見としては陰謀論は良くない、というか悪い。たしかに何を信じるかは人それぞれだが、自分の発信した陰謀論によってワクチンを打たなかった人がコロナ感染で死んでしまったら、それは発信した自分のせいだ。論拠も無い個人の発言を鵜呑みにする方が悪いという意見もあるだろうが、だからと言って不正確な情報を提供した側が無罪なわけない。致死量の毒の入った飲み物を安全だよと手渡して、相手が飲んで死んだら信じた方が悪いなんて、理屈が通っていない。陰謀論を信じるということ自体は否定しないけど、その中身とそれを流布することの悪性は否定させてもらう。
もっとも陰謀論信じている勢にとってはその毒入りの飲み物こそワクチンなわけで、お互いにどこまでも理解し合えないと思うと少し悲しくなる。これが多様性ってやつなのか……。
最新の彼のツイートを見るに、何周か回ってマスクをし三密を避けようということになったようで、本来の感染症対策を粛々と推し進めていくらしい。何のためかはちょっとよく分からなかったが、ワクチンを打たない人の行動としては正しいんじゃないかと思う。完全に終息するまで続けることが出来るならだけど。
長々とお気持ちを書き殴ったわけだが、私はこれからもたま〜〜〜に彼のツイートを確認しに行くと思う。理解できない存在であることは間違いない。彼にリプを送ることもなければ、逆にリストに入れることも無いだろうけど、なんとなく私を監視している期間中は監視し返したいと思うのだ。もしかしたら、いつか彼が陰謀論から脱却する瞬間を見て溜飲を下げたいだけかもしれない。……あの調子じゃあ一生そんなこと起こらなさそうだけどね。