  |
はてなキーワード: CPU使用率とは
Dockerは、開発から運用まで一貫した環境を提供することで、開発者の作業負担を減らすという大きな利点があります。また、仮想マシンと比較してリソースの使用効率が高いため、エコとも言えます。
ただし、確かにDockerには一定のオーバーヘッドが存在します。これは、DockerがゲストOSを持たずに、ホストOSのカーネルを共有して動作するためです。それにより、アプリケーションの実行に必要なリソースが追加で必要になり、パフォーマンスに影響を及ぼす場合があります。
また、Dockerを利用する際の設定や構成によってもパフォーマンスは大きく変わります。例えば、Dockerのネットワーキングやストレージの設定、またホストOSとの互換性など、考慮すべき要素は多数存在します。
あなたの現在の状況について具体的に述べると、FESSのクローリングが重いという問題は、Dockerのオーバーヘッドだけが原因ではない可能性があります。Dockerコンテナ内のFESSやJVMの設定、ホストマシンのリソース割り当て、ネットワークやストレージの設定など、様々な要因が絡んでいるかもしれません。
また、Dockerのログ出力が多いと感じる場合も、実際のところはFESSやDockerの設定によるものかもしれません。ログの出力レベルを調整することで、必要な情報だけを出力するように設定することも可能です。
しかし、これらの設定を調整するためには一定の知識と経験が必要で、それがなければ素直にネイティブ環境での構築が良い選択かもしれません。結局のところ、どの方法が最善かは具体的な要件や状況によります。
このような状況に直面した際には、パフォーマンスの問題を具体的に分析し、適切な解決策を見つけるためにパフォーマンスモニタリングやロギングツールを使用することをお勧めします。それにより、問題の原因を特定し、適切な対策を講じることが可能になります。
たとえば、Dockerが高いCPU使用率を示している場合、それはコンテナ内のアプリケーション（この場合はFESS）が高いリソースを消費している可能性があります。その場合、アプリケーションの設定や実行パラメータを調整することで改善できるかもしれません。
また、Dockerコンテナのリソース制限を調整することも検討できます。Dockerは、コンテナに割り当てるCPUやメモリの量を制限する機能を提供しています。これにより、他のプロセスに影響を与えることなく、特定のコンテナのリソース使用量を管理することが可能です。
さらに、Dockerのボリュームやネットワーク設定が適切であるかを確認することも重要です。不適切な設定はパフォーマンスに悪影響を及ぼす可能性があります。たとえば、ファイルI/Oのパフォーマンスは、ホストOSとコンテナ間でデータを共有する方法に大きく依存します。そのため、適切なボリュームの設定や、パフォーマンスを向上させるための最適化オプションが適用されていることを確認することが重要です。
最後に、Docker自体のアップデートもパフォーマンス改善に寄与する場合があります。最新のDockerエンジンには、パフォーマンスを改善するための修正や改善が含まれていることがあります。
これらの要素を考慮に入れ、Dockerのパフォーマンスを最適化する方法を探すことができます。ただし、これらすべてを試してもパフォーマンスが改善しない場合や、必要な知識や時間が不足している場合は、Dockerを使用しないネイティブな環境での構築が最善の選択であるかもしれません。
そりゃそうなんだろうけども。そんなに？
追記：FESSをOSに直接インストールするのに参考にしたというよりコピペさせてもらったのは以下の記事
https://qiita.com/hyoshiaki/items/598127fe30b94bd82b6e
半年前に辞めてしまった前任者から存在すら知らされていない客先のメールアカウントが必要になった。
無いならないであきらめてもらえるんだが、僕は優しいのでファイルサーバに無いかくらいは確認しようと思ったが
なので昔うっすら使ったことのあるFESSで全文検索しよう、多分txtかxlsだろう。
とウェブサイトで構築方法を見ると今はDockerで動かすのが良いらしい。何がいいか知らんが。
ドキュメントに従いインストールし、なんとかクローリングまで実行できたが、重い。重すぎる。
サブフォルダ無しで100ファイルくらいのフォルダでも2，3日回しても終わってない。
CPU使用率が50%超えてるんだよ！ってログが出まくっている。そのログ出力無駄じゃない？
使えないかー、とググってみるとDockerではなく素で構築する方法を有志の方が書かれているのを発見。
それに従い構築。するとサブフォルダ5階層くらいのフォルダが3分くらいで終了。
ログにCPUがーっていうのも出てないわけではないが、明らかに少ない。なんだこれ。
Dockerは構築楽らしいしVMよりエコだっていうのは聞いたことあるんですが、
素のOSに入れるよりはどうしてもオーバーヘッドあるんですかね、というのが今回の教訓でありました。
自宅ネットワークで、セキュリティのためにタグVLAN切ったりしたいけどEdgeRouterとか中古RTXのようなCLIで設定するのはめんどくさいな…。Wi-Fiとかも1つの機器で一緒にやってほしいな…。という人にピッタリ。
半年ほど前にUnifi Dream Machine(UDM)を買って、GUIやアプリで細かいところまで設定できるし（CLIアクセスは可能だけど使ったことない）便利だなあと思っていながら愛用していたら、先月にUDRの日本版が発売された。UDM買ったばかりなので迷ったけど、PoEとWi-Fi6がほしいので買ってみた。UDMより安いしね。
結果としては大正解で、UDMとくらべてWi-Fiが強くなって風呂に届くようになり、PoE対応で電源タップを1つ開けることができ、Wi-Fi 6対応で自己満足を得ることもできた。CPUのスペックが下がってるのが懸念点だったけど、スピードテストやCPU使用率の値を見る限りでは個人ユースでは問題なさそう（DPIをつけて外向き600Mbps程度は出る模様。それ以上出るのかは不明）。
一つ気になったのはファンの音で、UDMでは無音に等しかったのがUDRでは若干音が聞こえるようになった。上部のカバーが揺れてるのが音の原因の一つらしく、カバーと本体を養生テープで固定したら気にならなくなった。寝室に置くならUDMにしておいたほうがいいかも。
Unifi製品は安くて（英語が読めるなら）ナレッジも多く、ライセンス料不要でアップデートしてくれるのでおすすめです。APあたりも買ってみたい。
そう思ったらラズパイ4が輝き出した
・ラズパイ4 4GB + SATA SSD(USB外付け化) + PX-Q3U4 + epgrecUNA + lighttpd の構成で
・8本同時録画いける、load average 2.09
・トラコンはムリ、リアルタイム視聴なし、とにかく ffmpeg ダメゼッタイ（CPU使用率が一気に悪くなる）
エンコを捨てればなんとかなるがエンコを捨てるとHDD容量リミットがマッハになるので
録画済のファイルを不定期にエンコしに行く別ノードが必要かも知らん
もう一台ラズパイを用意して共有フォルダ見に行ってエンコ + 録画サーバのDBにレコードぶっこむ、みたいなの
追記： gst-launch-1.0 でも頑張ってみたが ffmpeg 使ったのと大差ねえわ。エンコするなら同時に2か3（夏なら2かも）、エンコなしなら8本、というアンバランスな話になりそう。
まったくその通りで、数年前ならPCを使った会議をメインでやることも少なかったから2コア4スレッドメモリ8GBのPCで全然十分だったんだよ。
でも今はOfficeだけを使うケースはあんまりなくて、Teamsで画面を共有しながらOfficeを使う。リモートワークになってるから情シスが導入を強制した監視ソフトがパワーアップしてて常に1コアを占拠していたりする。Teamsが1コア、監視ソフトが1コアを占拠しているから2コアが全部使われているので他のことをやる余裕がCPUにはなくなっている。
会議しつつ、「いま資料を出します少しお待ちください」とか言って皆を待たせることになる。そこに30秒ほどかかってしまう。自分の生産性が下がるだけじゃなくその会議に出てる全員の生産性を下げている。
監視ソフトが1コアを占拠しているがハイパースレッディングのおかげでこれが占有しているCPU使用率は25%と表示される。監視ソフトのベンダや情シスは「1/4しか使っていないので他のことは十分できるはずである」などと言っているがそんなことはなく実態としては40%くらい使っている。とにかく今の時代にはメモリ8GBで2コアのCPUでは、企業で使うという制約の下では、環境によっては仕事にならない。半分は情シスのせいだとは思う。
のやり方知りませんか？
もはや意味のない「高校生活2008」とか「挫折経験2012」「打ちのめされ感2015」みたいな1個1個はそんな大したことなくてもこのファイル？アプリ？の残骸みたいなのが体に残ってる感じありますよね？
そのせいで体っていうか精神というか動作重くなる感じありますよね？？
もうどうやったら削除とかアンインストールできるんですか！？！？
なのになぜ若いときの苦労は買ってでも知ろなんていうんですか！？！？！？！？
有料でもいいので負荷が高すぎる記憶のアンインストールの方法教えてください！！！！！！
私の体はもう訳のわからない古いアプリケーションでCPU使用率がやばそうなんです！！
！！！！
「ニュースと称して広告送ってくる」のは反意図性があるからあとは、
「CPUパワーを結構くう」が具体的にどれくらいかによるけど、50%超える？
コインハイブの最高裁の判決では、プログラムの反意図性は認められたけど、
CPU使用率が0.5に設定されてたことで実害がないとして無罪になった。
もしそれより大きいようなら実害アリとして、通報もしくは告発してみては？
・・・と思ったけど、たぶんWindowsの使用許諾書のどこかに
「ユーザーのエクスペリエンス云々～のために、Microsoft社が広告を配信する権利が云々～、その実行環境をユーザーは提供する云々」みたいな文言があって、
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
あの裁判官はバカ過ぎる。技術革新を守るどころか足を引っ張る判決だ。以下、今後起きる影響を列挙する
CPU使用率50％までなら合法という判例が出たからだ。お金の臭いに敏感なこの手の業者がこのチャンスを見逃すわけがない。
当然ながらこうなり、若者がWebアクセスやスマホアプリをあまり使わなくなる。
そして最高裁判決で出た「技術革新」という単語に国民的批判が集まっていき、
という結果が待っている。
最高裁裁判官は、性善説で物事を見すぎである。有罪にしろとは言わないが、「早い法整備を望む」など、野放しにならない付帯文を入れるべきだった。5年後を見据えて裁判してほしかった。
僕がコインハイブを知ったのは冤罪で検挙されたモロさんと同じくGIGAZENEの海外記事紹介でだった。2017年後半のことだ。
その後、海外の超大手の海賊版サイトが導入したとか日本でもニュースにもなり知名度が海賊版サイトの悪名とともに広まった。
そして漫画村もコインハイブを導入して、さらに悪名がつくことになった。
2018年。それまで一部のまとめサイトなどでの範囲に収まっていた漫画村批判が、2018年は年初からマスコミや大手ネットメディアも名指しで取り上げるようになった。
その時期にコインハイブ設置したものだから、そうした記事ではコインハイブは漫画村批判にこれでもかと利用された。
その時にマスもネットも全てのメディアはコインハイブの解説をトレンドマイクロに求め、トレンドマイクロはコインハイブへの警告を出し続けた。やれCPU100%、やれ端末がぶっ壊れる等。
批判記事が量産されるとともに漫画村叩きの熱も高まる。それとともに各記事におけるコインハイブの解説も漫画村批判を煽るために怖さを増幅させるものになっていく。
初期のねとらぼの記事ではトレンドマイクロの解説として「ウィルスではありませんがトラブルになることがあるのでトレンドマイクロでは警告を出している」と穏当なコメントも掲載してるhttps://nlab.itmedia.co.jp/nl/articles/1802/20/news114.html
が、3月のNHKの記事になるとトレンドマイクロがCPU使用率が100%になる画面を見せる調査を元にコインハイブについて「アクセスするだけで利用者の端末で不正なプログラムが勝手に動きだすことがわかりました」と「不正」と断定して記述するようになりhttp://www.nhk.or.jp/seikatsu-blog/800/291202.html
4月にはテレ朝系のAbemaニュースではネットに詳しい弁護士がコインハイブについて「不正指令電磁的記録供用罪に問われる可能性がある」と違法行為と解説させるようになったhttps://times.abema.tv/articles/-/3978705
産経は漫画村記事でコインハイブは「北朝鮮の資金源」と書いた。
こうしたメディアの動きと合わせて、この時期Twitterでは何とか漫画村を利用させないために「漫画村にウィルスが仕掛けられてる」という投稿が拡散されるようになり、「コインハイブ＝ウィルス＝不正」という理解が高まる。
このようにメディアとSNSで「コインハイブ＝悪」という認識が根付いていく裏で、全国の警察がコインハイブ設置者の大量検挙に動いていた。NHKがこの時期に「不正なプログラム」と断定していたのも警察の動きを把握してのものだろう。
その後、漫画村は政府によるブロッキングを経て潰れ、それとともにコインハイブの話題も一旦終了する。
そして漫画村の記憶も薄れた6月に警察が「今年に入ってコインハイブで数十人を検挙したよ～」と発表し、高木浩光先生が「コインハイブで逮捕はおかしい」と批判の声を上げて流れが変わる。http://takagi-hiromitsu.jp/diary/20180610.html
高木先生はコインハイブが事件となった理由を「トレンドマイクロの暗躍」だとした。
漫画村はすでに潰れていたこともあり、以前に漫画村つぶしのためならとおかしいことをおかしいと言わずにスルーしていた人たちも一斉に高木先生に同調し「コインハイブは不正じゃない」と声をあげ冤罪救済のちからとなった。
寝て起きてもまだCPU使用率50%固定でぐるぐるやってたので、今ある250GBぶんのファイルを0.3MB/sで読んでどのくらいかかるか計算した
250GB/0.3MB/60/60=231.48h
ん－、10日間くらい？おうふざけんあ
・ バックグラウンドでストレージ内のファイルをチェックしている ←わかる
・ 短時間で終わらすため一気にストレージを読んでたらCPUとメモリの消費が激重と批判されたのでちょっとずつ読んでる ←わかる
・ 0.3MB/secでちょっとずつ読みながら全ストレージをチェックするとなると動作完了までに時間がかかる ←わかる
・ CPUのコアをひとつ丸々占有してCPU usageが50%になる ←わけがわからない
いや俺やったことないからわかんないんだけど、たぶんそんなCPU資源使わないと思うんすよね
不具合でいいと思うなあ
ちなみに10時間くらい経ってもずっとCPU使用率50%で（面白いことにタスクマネージャのパフォーマンスタブで完全に50%で推移してる）割と困ってる
4台のPCに一つずつ稼働させることにした。
【よかったこと】
・IISというWindowsのサーバー建てるフレームワークみたいのを使って初めてWindowsでサーバーを建てる経験を得られた。
Windowsでサーバーを立てるのは規約違反だった気がしたが最近はWindowsに元々サーバーを建てる機能が付属してるし別にいいのだろう。
・Windows10のドライバ認識能力のすごさを知ることができた。
Linuxだとファンが回らない、何も映らないけどWindowsだと普通に動くなどした。
・Windowsでサーバーを建てるのはムズイという知見を得た。
・信じられないくらい遅い
CPU使用率が低いままで全く変わらず、にもかかわらず簡単なウェブページの表示に10秒とか待たされて使い物にならなかった。Xubuntuに変えたら1秒以内に表示された。
httpsにリダイレクトされるのをやめさせようとしたり、SSL証明書を設定しようとしたがどうやってもできなくてWindowsを使うこと自体を辞めた。
・家に余ってたHDDを全部繋げて1.5TBのクラウドサーバーを作ることができた。
複数のHDDを一つのHDDとして扱う技術（LVM）の設定をする体験ができた。1.5TBの使い道はない。不用品の処分をするのが目的。
・XubuntuならMacbookPro(2007年製)にUSBメモリからインストールできることを知った。ただしインストール画面がたまにしか表示されない。
【デメリット】
・今までは仮想マシンで動かしていたので扱いやすかったのだがそれができなくなった。
失敗しても5分前の状態に戻すとかできないし、仮想イメージのエクスポートとかできない。
・電気代を4倍食うようになった。
個人的に激安だからって買ってみたWindows10のeMMC32GBのノートパソコンなんですけど、普通に使える？ラッキーって思ってたらだんだん厳しくなってきました。
要はバージョンが1803でサポートが切れてるものの叩き売りだったみたいですね。なるほどーこれが安さの理由なんでしょうか？とても初心者に胸を張ってオススメできるしろものではなさそう。
で、Windows10アップデートがサポートの1803まででいいんですが、延々と1903や1909にバージョンアップしようとし続けて失敗して、またインストールしようとして、それの繰り返しで止まりませんし、いつも何もしてないのにCPU使用率が常に100％ちかいとか、なんなんですかこれ。
最後の手段で1909が手動でダウンロードして更新できるのか、できなかったらWindowsUpdateのサービス自体止めてしまおうかと思います。最悪の場合。
激安Windows10は要注意かもしれません。
今日の夜食のお供は苺とホイップクリームのどら焼き的なコンビニスイーツです。
これと牛乳飲んでもうちょっと頑張ります21時までには帰れるでしょう。
