  |
はてなキーワード: 提供元とは
提供元がもう公開していらっしゃらないので何かあったら対処します
顔でも名前でもうちわや文字ボードでも、何らかの個人を識別できるものを推しに覚えてもらった状態。
ボーダーラインは界隈によると思います…個人でイベントやったり店舗で接客業してるような推しと、ドームやアリーナで何万人も相手にコンサートするような推しだとファンの数も違えば覚えやすさも違うので。
一番最初に推しから覚えられているかも？と疑問を抱いたのは私が始めて推しを見に行った現場(キャパ2000くらいの箱)でビギナーズラックで最前を引き当て、その時に着ていた服の話を後日の配信で話していた時。
HNくらいは覚えてくれているかもしれないと期待を抱いたのはその後の現場で、配信でコメントした内容を覚えてくれていてチェキに「いつも応援ありがとう」と書いてくれたとき。
完全に覚えられたと確信したのは何度目かの現場で、個別に部屋に入っていく方式だったんですがドアを開けて一言目が自分の名前だったとき。
疑問を抱いている辺りまでは覚えてくれてたら嬉しいなとは思いましたが、認知されるために何か行動したとかは特に無かったです
SNSや配信はほぼ毎回リプやコメントをしていたことと、その中でも私は推しの趣味と自分の趣味が一致する部分が多かったので突っ込んだコメントができたこと。
ファンアート人口が少なかったので、ファンレターやプレゼントと一緒に毎回ファンアートを添えていたこと。
一番の理由は推しの関係者だったら一発でファンだと分かる服装を初回からずっとしていたことだと思います。
5.顔・名前・HN・ラジオネーム・SNSアカウントなど、どこまでをあなた本人として認知されていますか？
私はHNやRNも全て本名で統一しているので、顔も名前も各種媒体のアカウントも覚えられているかと…
認知前後で言うと特には…美容に気をつかうようにはなったりしましたが、それは認知される前からなので。
8.認知前と認知後で「認知」についてのイメージは変わりましたか？
前は貰えたら嬉しいものと思っていましたが、いざ認知されると色々な意味で怖いです。
9.あなたが認知された、されていることについて 他者から何か言われたことはありますか？
無いです。認知されていることを同担はもちろん、リア友や血縁者含めて一切他言していないので。
自分の状態にもよります。好きなら別に認知されていなくても配信やイベントに行くし、冷めてしまって忘れられたのなら当然の事として受け止めます。
推しがファンアート肯定派で描ける人はぜひ描いて送って差し上げてください。画力は関係ないというか、推しに見せるんだ！と思いながら描いてる内に勝手にある程度の画力が付きます。私の推しはファンアートをファイリングしてくれるくらい、描いてもらったら画力関係なく嬉しいそうです。
あとは認知された理由の辺りで触れましたが、名前や服装を統一することだと思います。
一瞬の喜びとよくわからない恐怖。
今のままで十二分に幸せなので変わらないで欲しいです。
覚えていただけたのは大変喜ばしく思っておりますが、正直に申し上げるなら私を覚えておく脳の領域を他の有意義な事に使ってください…。
調べてみたらひどいクソ仕様だったので、同じ轍ふまないように知見共有します。
なお、消えてしまったデータは息子の卒業式の動画データ。復元不能。
ストレージは壊れるものという前提は理解しているつもりなので、状況ごとにいくつかのバックアップ体制は取ってある。
安くなったとは言えすべてのストレージをSSD化するには至っていない。
そのため、OSやソフトウェアなんかはSSDにインストール、写真や動画などのサイズがでかいデータはRaid HDDでミラーリングして格納するようにしている。
それ以外にもそれほどサイズの大きくないデータはonedriveとかのクラウドストレージを利用。そのデータもRaid HDDでミラーリングして二重にバックアップ体制を敷いている。
趣味で写真をやっているのだが、今回の事故はその編集のフローの中で起こった。
編集と格納は別で考えているので、アクセス速度が高いほうがいい編集はSSD上で行い、格納はRaid HDDに行っている。
そのタイミングでgoogle photoに分散バックアップ、必要に応じて家族なんかと共有を行う。
つまり、撮影が終わったら最初にすることは、SSD上にあるデスクトップの一時フォルダに写真と動画データをコピーすることから始まる。
Raid HDDに格納するのは、編集ソフトでレタッチが終わってからだ。
まずは写真データから編集を行い、RAWデータから無事にjpegデータへと書き出してHDDへの格納が終わった。
そのタイミングで妻からの頼まれごとのためにメールをpdfプリントして名前をつけて保存しようとした。
めったに使わない機能なのだが、指定されたのはonedriveフォルダだったので、そのまま保存をクリック。
ところが、PCからonedriveフォルダにアクセスしても出力したpdfデータが見つからない。
おかしいなと思ってもう一度出力を試みて保存フォルダのパスを確認してみる。
すると、今現在HDD側に指定してあるonedriveのパスが、SSD上のデフォルトのパスに指定されているようだった。
ここで思い至ったのが、確かPCにonedriveを設定した際にうっかりデフォルト設定のまま起動してしまい、その後、HDD上にパスを切り替えたという状況だった。
「そうかぁ。保存先を変更すると元のファイルを移動させるんじゃなくてコピーを作ってしまうんだな」なんて感じに妙に納得しつつ、もう一度しっかりとパスを確認した上でpdfをコピーしてからSSD上のonedriveをshift deleteで削除した。
エクスプローラーを閉じてデスクトップに戻ってくると妙な違和感。
ない。
はぁ？と思ってPCをダブルクリックすると、すぐに警告ウィンドウが開いて「デスクトップへのパスが間違っています」といったエラー表示。
焦る。かなり焦る。
ウィンドウをすべて閉じても、デスクトップ上にはデフォルトのアイコンだけが並んでいるだけ。
頭真っ白。
多少大事なデータはあったかなと思いながらも致命的と言えるものは思いつかず（まだ見落としてるだけかもしれない）、しかし、すぐに一時フォルダごと動画データがないことに気づく。
写真はすでにjpg出力してあるので、RAWデータが消えてしまったのはなんとかなる。
子供の卒業式の動画はまだ変換をかけてもないし、当然アップロードもしていない。
終わった。
あまりにもショックだ。
読み飛ばしここまで。
結局何が原因だったかというと、最初にonedriveをセットアップする際に、デフォルトの保存先、なおかつデスクトップやマイドキュメントなんかもバックアップに含めるという設定で始めてしまったからだったらしい。
この、onedriveのバックアップにデスクトップを含めるという操作をすると次のようなことが起こる。
「本来はC:\Users\ユーザー名\Desktopにあるはずのデスクトップデータが、C:\Users\ユーザー名\onedrive\Desktopに変更される」
・onedriveのバックアップからデスクトップを含めないように設定変更
この2つの動作を行ったにも関わらず、何故かこのパソコンのデスクトップは、C:\Users\ユーザー名\onedrive\Desktoに残ったままになってしまったというわけだ。
そのため、C:\Users\ユーザー名\Desktopにデスクトップがあると思いこんでいた自分は、C:\Users\ユーザー名\onedriveにあるonedriveのフォルダを、疑うことなく削除することができた。
そしてその結果、デスクトップにおいてあったデータのすべてを失った。
いや、流石にこんなクソ設定想定できないでしょ。
大事なデータを守るっていう名目があれば、大事なデータの格納先をそんな簡単に変えていいと思ってる？
それ、誰に許可取ってやってるんだよっていうさ。
その辺の共通プロトコルを、バックアップソフトが、しかもOSの提供元がやっていいのかよっていう。
これはちょっと言わせてくれ。
マイクロソフトクソだわ。
まぁ、なんというか皆さんも気をつけてください。というか、こんなの気をつけようがないけどな。
どこに気持ちをぶつけたって息子の大事な思い出は帰ってこないのはわかってるけど、やるせなさくらい吐き出させて。
※追記
ブラウザonedriveのゴミ箱にデータが残っている可能性はゼロです。
その理由は以下の通り。
このパソコンは1ヶ月ほど前に新規にセットアップしたものでした。
そのセットアップの過程で、onedriveをインストールする際にデフォルトの保存先、なおかつデスクトップをバックアップという設定にしてしまいました。
ここでノールックで設定してしまった自分が一番悪いことは認めます。
onedriveのセットアップが終わったあと、同期に時間がかかっていておかしいな？と思ってファイルのアップロード履歴を確認したところ、あらかじめ古いパソコンからコピーしてあったデスクトップのデータをアップロードしようとしていたので、慌てて設定を見直して、デスクトップ同期のオフ、保存先をHDDに変更しました。（変更した順番は書いてある通り覚えていません。順番が逆だったら起こり得なかったかも）
この操作によって、onedriveの保存先はHDDに変更になり、デスクトップの同期も停止しました。
しかしそうした操作を行ったにも関わらず、デスクトップの保存先はC:\Users\ユーザー名\Desktopに戻ることはなく、C:\Users\ユーザー名\onedrive\Desktopのままになってしまっていました。
そのことに気づかずに1ヶ月以上作業を続けていたなかで、記載の通りSSD内に同期されていないonedriveフォルダを発見したので削除した結果、デスクトップのデータが消失しまったという話です。
そして卒業式の動画データをデスクトップにコピーしたのは、onedriveの同期を切ったずっとあとのことです。
もともとonedriveにバックアップするつもりもないし、バックアップされていないのでwebに残っているはずもないのです。
デスクトップのデータがそんなところに格納されていることがわかっていれば、もともと削除なんてしません。
同期されていないすでに使われていないonedriveのデータだけしか削除するつもりではなかったのに、何故かその中に現在進行系で使っているデスクトップのデータが格納されていて、一緒に削除されてしまったというお話です。
ちなみに、削除直後は本当に何が起こったのか意味がわかりませんでした。
その後にマイコンピューターを開いた際、別ウィンドウでエラーが出たことで初めて状況が理解できたということです。
そのエラーが「デスクトップC:\Users\ユーザー名\onedrive\Desktopにアクセスできません」といった内容のエラーです。
デスクトップ？お前なんでそんなとこに保存されてたの？からの、そういえば思い出してみればこんなことあったよなーで、原因に思い至ったというわけです。
SDカードの復元を試みましたが、サイズの大きい動画データですので、ヘッダーは読み込めたものの、データそのものはすでに別の写真データに書き換えられてしまっていたせいかちゃんと開けませんでした。
SDカードからデスクトップにデータを移すタイミングというのは、行事ごとに撮影が終わったらSDを空にして新しく撮影できる状況を作るためなので、基本的にはデスクトップにコピーしたあとは次の撮影前に必ずフォーマットすることを習慣づけています。
それは、毎回SDカードを空っぽにすることで、現像のときにデータの重複が起こらないようにするためです。（趣味で写真を取っているので撮影枚数が莫大。尚且つ現像ソフトで不要データを削除するので、SDを空にしないと、削除後にまたコピーしてしまったりと効率が悪いため）
撮影→データをデスクトップに一次保存→次回撮影時にSDカードのフォーマット→時間があるときにPC上のデータを選別、現像→バックアップ含めてデータを格納→SDカードから新しい撮影データをPCにコピー→次回撮影時にフォーマット→時間あるときにPC上のデータを選別、現像→・・・・
SDカード自体も紛失の危険性とか考えてそれほど信用しているメディアではないので、できるだけデータが保管されている時間を短くするようにしています。
個人的には、このワークフローが一番データの保存性も高く、無駄も少ない処理方法だと思っています。
だって、デスクトップを間違って消すなんてこと普通しないでしょ。
壊れたなら仕方ないって、それはそれで納得できるんだって。
流石にこんなことまで想定したワークフロー作れってのは無理な話ですよ。
すでにonedriveからデスクトップの同期も切ってて、しかも別フォルダでonedriveがちゃんと稼働してるのに、まさか自分のデスクトップがC:\Users\ユーザー名\onedrive\Desktopに保存されてるなんて思う？
多様性多様性と言っている中でいわゆる音楽の「ヒットチャート」は意味を成すのかと思っている。
昔のように最近の曲を知っていないと話題についていけないこともないし、知らないことであまり馬鹿にされることもない。
「最近の曲を知らないんだよね」という年齢も昔はおじさんおばさんだけだったのが普通に学生が言う。
髭男の曲も米津の曲もAdoの曲も、人気ではあるものの大衆が熱狂して聴いているほどではなく、あくまで多くの人が聴いている曲の中の最大公約数に過ぎない。
最新の曲を知らなくても過去の曲に簡単にアクセスできるようになったし、人気の曲を聴かなくても自分の好きなジャンルはこれだと胸を張って言う人が増えてきたように思える。
「人気の曲」の指標は確かに必要だし、アーティストのモチベーションにつながると思う。
けれど今はCDの大量買いに再生回数の水増し工作など、そのチャート自体がある程度「いじれる」ようになってしまっている。
提供元が対策を講じてもすぐに再度抜け道を探したり倍の努力をしてその対策を無にしてしまう。こうやってチャートもぐちゃぐちゃになっていく。
いや、意味はあるのだけれど、今後更に音楽に対するアクセスがしやすくなり、音楽の価値が下がると同時に、音楽の好みの多様性が広がり、「これが人気です」の指標に人が興味を示さなくなるんじゃないかと思っている。
法律とか詳しそうな人の意見を聞きたいので疑問だけ置いておきます。
私が危惧している点は、AIの提供元が販売サイトを兼ねる予定であったこと。つまり、販売サイトが他人の著作物のコピーを作成し、販売させたら損害賠償請求等々が可能かと言うこと。
例えばだが、Webサイトで特定の誰かの写真を学習し、AIが贋作を作り、同サイトで販売できた場合、販売前に著作権利者であるかを確認せずに自由に販売しても問題ないのだろうか？
個人使用と騙してローカル保存してから、別なサイトで騙して販売したなら作成サイトにも販売サイトにも責任はないと思える。
だが、販売目的著作物から贋作を作成販売させた場合はどうなのだろうか？
これがイラストや絵画である場合、作成したものが贋作と知りつつ、同社が真作として販売させたとして何らかの問題は発生しないのだろうか？
まずは、日立のサーバーでのWindows Server 2022への対応からお聞きした。
木村： サーバーにはHA8000VとRV3000の2ラインアップがあります。HA8000VがPCサーバーで、汎用的なサーバーとして、エントリー向けや、HCI、VDIのソリューションなど、いろいろな用途で使われています。RV3000はミッションクリティカル向けです。Windows Server 2022のプレインストール対応は、HA8000Vの全機種で2022年5月を予定しています。
Windowsサーバー市場における日立の強みとして、木村氏は、サポート力を挙げる。
木村： 日立は長年に渡ってプラットフォーム製品の開発を行ってきました。作ってきたからこそ、中身がわかっている技術力があります。できることとできないことを技術者がわかっているので、障害が起きたときや問い合わせのときに、お客様に事実を真摯に伝え、重大な不具合があっても技術力で解決に向けていきます。何かあったときに問題をたらい回しにせず、技術力をコアにしてしっかり対応するサポート力が強みです。
こうした日立のDNAを結実させたサポート商品が「日立サポート360」だ。通常はサーバーのハードウェアからOS、ソフトウェアなどは、それぞれと契約し、サポートを受けることになる。日立サポート360ではこれらをワンストップで受け付け、支援することができる。
広瀬： 窓口が1つになるというのは他社でもありますが、そういう表面的な話だけではなく、複合的な力で問題解決支援にあたれるのが真の価値です。内部で、サーバーからOS、日立ミドルウェア、導入ミドルウェアなど、いろいろな製品の部門の連携がすごく濃密にされているからこそ、複合的な力で問題解決にあたれます。これが本当のワンストップの意味です。
この日立サポート360でWindows Server 2022のサポートにも対応する。日立では、長年のサポート実績により蓄積された技術力により高い自社解決率を誇るという。自社解決率が高ければ、それだけパートナーへのエスカレーションが減るわけで、短期間でのトラブル解決が期待できることになる。
日立のハイブリッドクラウドのソリューション「EverFlex from Hitachi」
木村氏は、日立のハイブリッドクラウド戦略としてEverFlex from Hitachi (以下、EverFlex)ソリューションを説明した。EverFlexは2021年10月にクラウドとのデータ連携ソリューションとして始まり、2022年2月にハイブリッドクラウドのソリューションとして強化された。
木村： お客様がオンプレミスとパブリッククラウドを使うときに、最適なシステム設計にして、コストも最適化していきます。ハイブリッドクラウドの導入には事前にアセスメントやコンサルティングを行うことが大切です。なぜなら、パブリッククラウドを導入することで負担が減るかと思われがちなのですが、ハイブリッド化されることで負担が増えることがあるからです。
EverFlexの特徴の中でも特に「クラウドライクなサービス提供」について木村氏は紹介した。
木村： ハイブリッドクラウドになると保守や運用が煩雑になります。パブリッククラウドとオンプレミスの両方を管理しなくてはならないため、システム管理において両方のノウハウが必要になります。このため保守・運用フェーズにおいて簡単化されずコスト最適化が課題となってきます。それを避けるために、共通化するニーズに応えるようにいろいろと工夫しています。
ハイブリッドクラウドソリューションEverFlex from Hitachi
まず、問い合わせをワンストップ化したり、運用管理を1つのツールで一元化したりすることで、顧客の負担を軽減する。
プラットフォームにおいては、オンプレミスからクラウド接続を可能にしてシームレスにお互いやりとりできるOSが各社ある。Windows Server 2022はまさにそれを特徴としており、同じくAzure Stack HCIも選択肢に入る。
さらに、支払い／利用形態についても、オンプレミスでも売り切りだけでなくフィー型も採用する。こうしたEverFlexの中でWindows Server 2022のユースケースを木村氏は2つ挙げた。
1つめは、運用管理の簡単化の部分で、Azure Portalからオンプレミスを管理できる機能の強化だ。
木村： オンプレミスにエージェントを入れておけば、管理者がAzure Portalだけをさわって、オンプレミスのリソースやイベントの管理も全て一元化できます。これに期待しています。
もう1つはセキュリティの強化だ。
木村： ハイブリッド化が進むと、両方の基盤をネットワークで接続することになります。従来には存在していなかった接続となるため、その部分でセキュリティの強化も進めなければなりません。そこでWindows Server 2022では、Secured-core ServerによってOSそのもののセキュリティレベルが上がっています。TPMと連動する機能によってハードからOSのレイヤーを守り、マルチレイヤーでセキュリティを強化しています。
そのほかにもクラウドライクの取り組みとして2つを木村氏は紹介した。
1つめは「サーバ予備リソース提供サービス」。サーバーを余分に設置し、支払いは電源を入れて使った月だけ発生するというサービスだ。
木村： 迅速でタイムリーにリソースを増強したいときに、クラウドなら自由に構成を変えられます。それをオンプレミスでもできるようにします。クラウドではインスタンス単位となり、ハードウェアの構成はメニューの中から選択することになりますが、オンプレミスでは構成を自由に組む事ができます。まずHCIソリューションから開始しましたが、2022年4月からはそれ以外にも拡大する予定です。
もう1つが「ハードウェア安定稼働支援サービス」。オンプレミス環境のサーバー運用管理を省力化するものだ。
木村： 旧来の保守では、ファームウェアのバージョンアップがあると、技術的にどういう影響があるかを確認して、その都度適用するかどうかを判断する必要がありました。それを提供元が判断するのがこのサービスです。お客様の機器を弊社で管理して、ファームウェアの推奨バージョンの選定や、更新作業などを一括でやります。
サブスクリプションに力を入れる
日立のこれからの注力分野について木村氏は、サブスクリプションに力を入れていくと語った。
木村： 全社的な方針で、サブスクリプションに力を入れていきます。クラウド化で初期投資をおさえるニーズと同時に、オンプレミスも求められています。そうしたお客様のニーズにアラインしていきます。
サブスクリプションやクラウドライクなサービスで管理を簡単にして顧客企業がコストを抑えることで、究極的な目的はその先のDXだと木村氏は語る。
木村： 既存のプラットフォームのコストを最適化させ、浮かせた費用を新たな投資先として、AIやEdgeを活用する新たなデジタルソリューションの領域に向けていくことを支援していきたいと考えています。
そのために木村氏は、よりハイブリッドで使いやすいようなライセンス体系をマイクロソフトに期待している。
木村： 今後ハイブリッド化が進むと、繁忙期にリソースを拡張するといったこともあります。そのときにライセンスが、オンプレミスはオンプレミスで買って、AzureはAzureで課金してと、ハイブリッドで使いづらい体系になっています。将来的にライセンス体系を統一するなど、両方の基盤で使えるような体系になることを期待しています。
また、Azure Portalからオンプレミスを管理できる機能についても、さらなる強化を木村氏は期待する。
木村： Azure Portalからは管理できる範囲に限りがあります。OSから上のリソースやイベントは監視できるのですが、ハードウェアの死活監視や電源管理などは対応していないため、JP1やその他のツールなど、複数のツールを使いこなす必要があります。それらの管理ツールが乱立してしまうと、また管理の手間が増えてしまう。こういったことをオンプレのツールか、Portal側で統一することも期待したいところです。
これが一番早いと思います。
ポーズ集や背景集などには「トレースしてもええぞ」「なんならそのままコピって使ってもいいぞ」「俺を使うときは提供元入れろよ」「俺はいらんぞ」と書かれているのものがあるのでそれを使いましょう。
プロの写真家に頼んでトレースしていい写真を買う手段もあります。
被写体が自分だと骨格の違いなどで上手くいかないこともあるので他人の力を積極的にお金で借りましょう。
名画の構図をそのまま使ってキャラクターや小物だけ自分の作品にしましょう。
これでトレスだパクリだと言われたら名画を見せれば「え？誰もが知ってる名作をトレスするという発想がパクリになっちゃうんですか？それは発想力の低さがやばくね？」で殴り返せます。
ただし、上記１、２の方法には欠点があり「うるせー。俺はお前が何も見ないで書いてると思ったから凄いと思ったんだ！」とイチャモンをつけられることがあります。
つまり「猿回しの猿が危険な芸を披露したことに対して金を払っていたのに、実は命綱を使っていたなんて！」といったイチャモンです。
アホかよキチガイじゃんでスルーしてもいいのですが、キチガイほどなにをしでかすか分かりませんしキチガイと痛み分けをするメリットがありません。
難しいようなら線画作成の工程だけでも撮っておくとイチャモンはつけられにくくなります。
音声をONにするとプライバシーがヤバイことがあるのでそこはOFFにした方が安全です。
ここまでやっても文句を言う人はいますが、そのときはこの動画を武器にしてアンチのアンチが勝手に暴れまわってくれます。
ケチをつけられるものがあったらケチをつけて周り、とにかく誰でもいいから叩きたいという欲望はトレパク疑惑をかけた側にも牙を剥くのです。
潰しあわせるために自分が潰れてほしいと思う側が使える武器を用意してやるというのは現代のインターネットを渡っていくための一つのテクニックだと思います。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
gmailを割と早くから使っているので（当時は招待制だった、ほぼ形骸化してたが）、シンプルなメールアドレスを持っている。
そのおかげで身に覚えのないメールが結構な頻度で届いて困っている。
たとえば登録した覚えのないサービスへの登録完了メールやキャンペーン案内メールなど。
スパム通報して迷惑メール登録していたのだが、たまにフィルターをすり抜けてくることもあって鬱陶しいし、自分がそのサービスを利用することになった時に困るのもいやだ。
なのでそういう事態が発生するとメールに心当たりがない旨を送信元に伝えて登録解除しようとするのだが、それが最近難しくなっている。
たとえばメールの本文中に「登録解除はこちら」みたいなリンクがあってもフィッシングやマルウェアのリスクを考えれば迂闊にクリックできない。そういうリンクがない場合もある。
また、送信元を検索サイトで探して申立てするにしても、窓口はチャットボットという場合が多く、会員ではない自分向けの情報になかなか辿り着けない。
有人の対応をしてもらう必要があるのだが、サービス提供元のの電話窓口やメールアドレスなどが記載されてない場合が最近は多い。
だから結局運営会社を検索してインシデント窓口へ通報したりするのだが、この一連のアレコレがなかなか手間なのだ。
脳死患者であっても人間から臓器を取り出すのは野蛮な行為と見なされ、豚が主流の提供元として置き換わっていくだろう。
臓器に限らず、医療の多種多様な場面で豚由来の物質が利用されるようになる。
するとどうなるだろうか。
宗教上の理由でどうしても豚を受け入れることができない一定数の人々が、医療から排除される結果となる。
宗教フォビアがていのいい医療分野の言い訳を身にまとい、豚を受け入れる気がないなら先進国の先端医療を受ける資格もないと言い出すだろう。
豚を不浄のものと見なす信仰を持っただけで、臓器提供を受けられなくなり、さらには医療全般から排除される。
宗教を理由に命を救う救わないという人間の根本の権利が揺るがされる事態になりかねない。
どうすればそのような未来を避けられるか。
それは豚だけでなく、一定数の人間の臓器が常に供給されてくる社会であり続けることである。
例え豚の内臓が利用可能になったとしても、豚を忌避する患者のニーズに応え、やはり脳死になった人の一定数から内臓を摘出する社会。
豚の存在により救われるのが生命維持された脳死の患者であり、救われなくなるのが移植さえ受ければ様々な活動に復帰できる信仰持ちの患者だとするならば、後者を助けて活動に復帰してもらいたいのも人情であるし、人道上も望ましい。
そのようなわけで、豚がいようが、人間の臓器は人道上の理由でニーズを持ち続けるのである。
https://gigazine.net/news/20220111-implant-pig-heart-human-world-first/
今年前半、紙メディアやTV局のウェブメディアの仕事をしていてわかったこと。
ヤフーニュースはPVに応じて、記事提供元がお金もらえる仕組み。
つまりヤフーニュースでバズればPV増えて、その記事提供元がPVに応じてお金を貰える。
かつトラフィックバックもあるので、自社サイトに集客しGoogleの広告収入を得ることもできる。
ヤフコメが酷いという話はよく聞くけど、これって記事提供元が意図的にヤフコメが増えるようなゴキブリ記事作って、PV増えるような酷い炎上コンテンツがそもそもの原因なんだよな。
ちなみにヤフーニュースの提供元はTV局や新聞社、出版社などなど。
DX音痴集団で、本業死亡企業集団だから、ヤフーからの収入が馬鹿にならずモラル崩壊でやっている。
自浄作用もないし、自分たちの襟を正せる脳みそある人達ではないから最近ますますひどくなっている。
昨今の小室圭さんのコンテンツを見ていると、不合格がどうこうとかプライバシー侵害にもほどがあるのでは。
小室圭さんというより親の問題だし。それにもかかわらず叩き続けているし。
もはや、それを判断する脳みそも旧メディア連中にはないのかもしれない。
どこの記事提供元とかはいわずもがなだけど、しつこく小室圭さんをストーキングするネタで稼ぐって人間のモラルとしてどうなんだろうね。
小室圭さん以外にも自殺した芸能人のネタをしつこく書いたりもしていたりするしね。
ヤフーもプラットフォーマーの責任あるし、金が儲かると言っても、ゴキブリ未満の連中を強制的に追い出してもいいんじゃねーの。
https://b.hatena.ne.jp/entry/s/togetter.com/li/1757684
popolonlon3965 「あと数週間で希望者全員のワクチン接種が完了する」なブコメが上位にいて、オリンピック以外にもいろいろパラレルワールドあるんだなと悲しい気持ちになってる。
どこの国にも「反ワクチン勢」「当初反ワクチンだったけどやっぱ接種することにした様子見勢」が4割くらいはいて、接種率60%くらいまではぐんぐん接種が進むけどその後は速度が鈍化している。最初から接種を希望している層はせいぜい6割くらい。
今から9週間後の2021年10月13日にはもうその希望者全員のワクチン接種は終了してるよ。
世界トップレベルのスピードでワクチン接種が進んだイスラエルですら2回目接種率はいまだに5割台。毎日少しずつ接種者が増えている状態。
一人でも接種完了していない人がいたらダメだなんてことでやっていたら、来年になっても国民全員へのワクチン接種が完了していないから自粛継続だ！なんてことになってしまう
追記：思ったよりブクマが伸びてるからもうちょっと具体的な数字を上げる。まず直近のワクチン接種率。
■7/9→8/9のワクチン接種率（提供元: Our World in Data · 最終更新: 2 日前）
2回目：18.6→34.3(+15.7)
15.7%ほど増えてる。つまり9/9と10/9の数字はそれぞれ理論上は
■9/9
1回目：63%
2回目：50%
■10/9
1回目：78.8%
2回目：65.7%
になる。
ただ、海外では2回目接種5割を超えたあたりで接種速度は落ちて予約が空きだらけになっている。
電博ADKといった「自由を履き違えることで金を稼ぐプロ集団」が、ネットという光の速度で情報交換ができるメディアの介在によって存在意義を失いつつあるということは、実に民主主義というものの素晴らしさであって、今回の東京オリンピックの開会と閉幕の愚昧さは、インターネットという「物理学的な伝達速度の限界」にいる我々が、情報格差で成り立ったエリートの時代に打ち勝つ手段を持ち得たことを意味し、人類の歴史においても、真の意味で「プロフェッショナルに直接、金を払う」という時代の到来がきたと、わたくしは確信に至った次第であります。オリンピックでトヨタや NTT が「金を捨てて」を打ち切った背景からするに、広告というものは営利企業が主体的に「自分たちの売りたいもの」を考え、消費者の満足度を上げる目的のものとなり、プロダクトと並行して広告を作り出すという、消費者のためのプロダクトであるという自我に広告は気がついたのです。もはや、広告は「空気の奴隷」ではありません。広告はついに「消費者のためのもの」になるのです。広告は消費者が主体的に消費するものとなる日が、東京オリンピックの閉幕とともにやってきたのです。広告とはプロフェッショナルの代弁者であり、消費者の満足度を上げる価値を提供するプロダクトであるという、己の使命を発見したのです。20世紀の長期に渡って、広告の使命を歪ませてきた広告代理店の罪は、ついに TOKYO 2020 として結実したのを我々は存分に認めてしまった。それに、広告というものは消費者の味方であるべきと、創造主の提供元は認知してしまったのだ。消費者の勝利の日は近い。我々消費者は、広告代理店に歪まされた市場に勝つ手段を手にしたのです。電通は、よろこんで死ぬべきだ。虚業は消えるべきだ。広告の真の使命のために、失せるべきだ。広告は「道具」ではなく、消費者の価値創造の「プロダクト」の一環として、消費者のそばにいることに歓びを覚えてしまった。もはや、広告はコントロールできない。これにて、広告代理店が代理して広告をつくるという間違った既存の悪しきプロセスは、終戦を迎える。広告代理店の敗戦は、生産者と消費者の勝利だ。よろこんで「終わらせて」やろうじゃないか。
今回はステマ疑惑を特集した記事でバズったすまほん!!だが、本来はデジタルガジェットの記事を得意とするメディアである。
昨年5月、ドン・キホーテからNANOTEというPCが発売された。
UMPCと呼ばれる超小型PCというニッチなジャンルの製品だったこともあり、半ばネタにされるような形で大バズりした。
何台入荷したのかははっきりしないが、発売当日の午後には入手困難となるほどの売れ行きだったようだ。
実際、すまほん!!自身も5月1日、3日にこのPCを入手できなかった旨のツイートを行っている。
そんなすまほん!!だが、このPCについて酷評するツイートを複数行っている。
https://twitter.com/sm_hn/status/1256741902570762242
https://twitter.com/sm_hn/status/1287579040707051521
酷評するだけならまだしも、このツイート中の情報には、ほぼデマといっていいほどにまで捻じ曲げられた情報が含まれている。（詳しくは後述）
さらに、商品名を入れて検索に引っかかるようにしたこれらのツイートには、他社の同ジャンルの製品を宣伝するツイートがぶら下げられている。
まず、バッテリー膨張は誤りで、単純に放熱シートが厚いことで裏蓋に変な膨らみができているだけである。
ただし、これについてはすまほん!!自身があとで訂正ツイートをぶら下げているので問題はない。（仮にもガジェット系メディアが裏付けを取らずに拡散するのはどうかと思うが。本当にバッテリー膨張なら安全性の問題があるが、最初から底蓋が歪んでいるだけなら話は別である。）
リマークについては筆者に専門知識がないため、コメントを控えさせていただきたい。
日経bpの取材に対し、ドン・キホーテ自身は否定している。( https://active.nikkeibp.co.jp/atcl/act/19/00128/061000013/?ST=act-infra )
問題は、「技適の番号が合ってるか確認できず」としている部分である。
技適の番号とは、日本国内で電波を使う機器に振られる番号で、これがない機器を使うと違法である。
要は、すまほん!!は「使うと違法な商品を売っているのでは？」と言っているに等しい。
情報源だが、すまほん!!自身が実機を入手できていないことから、他2点と同じくTwitterから引っ張ってきた情報であることは間違いないだろう。
そして、ソースと見られるツイートと見られるものがこちらである。
https://twitter.com/pana_junk_pc/status/1256573540037320704
このツイート自体表現が微妙だとは思うが、一応「反映されていないだけ」という可能性に触れている。
技適が取得済み（＝合法に使用できる）機器でも、公開されているDBに反映されるのが少し遅れることがあるのだ。
これはこの手のマイナー機器だと前例もいくらかあることで、頻繁にガジェットを扱っているすまほん!!が知らないということはまず考えられない。
なお、現在では技適番号が正しく検索でひっかかることは確認できるが、すまほん!!は未だに訂正ツイートを出していない。
Chuwi、GPD、One Netbookの3社の製品が主に宣伝されており、それに加えて小さくMagic-Benの宣伝もツリーの下の方に存在する。
すまほん!!はこの4社のうち、積極的に宣伝していた3社の製品（Chuwi、GPD、One Netbook）の提供を受けているようだ。
提供元がこんなことを依頼するとは思えないので、厳密にはステマには当たらないかもしれない。
とはいえ、すまほん!!の意図がどうであろうと、ほぼデマといっていい情報をバズらせ、そのツリーで提供元の製品を宣伝していたことは事実である。
https://xtech.nikkei.com/atcl/nxt/column/18/00001/05203/
COCOAやHER-SYSの開発において、日本マイクロソフトは厚労省との契約主体ではない。しかし厚労省がHER-SYSの開発ベンダーを急ぎ探していた2020年4月、ベンダーの選考会に参加して営業活動を展開していたのは実は同社だった。パーソルP＆TやFIXER、エムティーアイは、いずれも日本マイクロソフトのクラウドサービス「Azure」の有力な開発パートナーでもある。各社は厚労省の選考に勝ち残った「日本マイクロソフトの呼びかけでプロジェクトに参加した」（パーソルP＆TのDXソリューション統括部の責任者）。
いわゆる「マイクロソフト村」だ。ときどき見かける組み合わせ（異同はある）。
契約段階でパーソルP＆Tが元請けとなった理由は、関係者によれば「製品の提供に徹してシステム開発案件の契約は開発パートナーに任せる」という、日本マイクロソフトの方針によるものだった。
この座組みもよく見る。Microsoftのソフト製品をバンドルしたりAzureを売ったりしている大手日系メーカーやSIerとガチンコ競合にならないための建前的なやつ？
接触確認アプリの基盤を世界的に提供していた米Apple（アップル）と米Google（グーグル）が、接触確認アプリの提供元は各国の公衆衛生当局に限るという「1国1アプリ」と打ち出したからだ。厚労省はそれまで「接触確認アプリ導入に冷ややかだった」（関係者）が、アップルとグーグルの鶴の一声で「公衆衛生当局」として調達を担当することになったのだ。前述の通り、ここで厚労省は接触確認アプリの開発先の調達をパーソルP＆Tに「一任した」。
ここでHER-SYSと抱き合わせでやらせちゃえって判断した厚労省の誰かが、ある意味で最も無能で罪深いと思う。
たしかに接触確認アプリのサーバーはHER-SYS側のデータを定期でもらう必要はあるけど、逆に言えばそこだけっていうか。接触確認アプリの実装において肝になりさらに難航が予想されるポイントは、HER-SYSとは全く性質が異なるじゃん。AppleとGoogleの突貫協議で開発されたOS組み込みのAPIを正しく取り扱うこと、テストしにくいアーキテクチャが不可避な中でなるべく多くの国民が利用できるように多機種に対応し動作確認すること、そういう感じじゃないの。しらんけど。
なんでHER-SYSのおまけで賄えると思ったんだか。やるならやるで別の予算調達してベンダー選定しなよ。
時間がなかったから仕方ない？長くても半年もいらなかったと思うけど。Androidで通知ができてなかった去年の9月から今月までで半年だ。
さらに接触確認アプリの十分な知見がなかったパーソルP＆Tは日本マイクロソフトにCOCOAの調達やプロジェクト管理を任せる形を取った。「丸投げ」が連鎖したわけだ。注意が必要なのは日本マイクロソフトは接触アプリを公正に選べる立場になかった点だ。COVID-19 Radarには同社社員もおり、その接触確認アプリはサーバーの稼働環境にAzureを使い、AndroidとiOSで共通に稼働するコードを開発するツールには同社の「Xamarin」を使っているなど関係が深かった。厚労省は当時、こうしたベンダー側の事情も知る立場にあったとみられる。
知ってたっしょ〜。知らないわけないよ、絶対知ってたよ。（証拠はない）
「なんでもいいからクラウドもってこい」ならぬ「なんでもいいから接触確認アプリもってこい」って態度だったんでしょう。（証拠はない）
日本Microsoftも厚労省もだんまり決め込んでるみたいだけどね。
日本マイクロソフトと厚労省に対して、COCOAの開発先を選んだ当時の経緯について2020年9月から複数回取材を申し込んできた。これに対して日本マイクロソフトは取材に応じず、厚労省は当時の経緯の説明を避けている。
業界を代表する媒体の取材を何度も断るとあらば、今後数年は真相は明らかにならないかもしれない。
やれやれ。
