  |
はてなキーワード: 収束とは
もともと潔癖気味ではあったのだけれど、人に対してそれを表明することなく、たぶん気付かれもせずに過ごしてきた。
こんな私にとって、新型コロナウイルス禍におけるさまざまな対策は、もちろん面倒なことはあるけれども、
普段の潔癖的な行動をこっそりやらなくても良いという意味においてはプラスだった。
何しろ、マスクしてても、何か触ったら除菌してても、つり革を持たなくても、別に変わった行動とは思われないのだ。
ただ、あれを見てから世界が変わってしまった。「富岳」による飛沫やエアロゾルのシミュレーションである。
「え、普通にしゃべるだけでもこんなに飛沫が飛ぶの？」もちろん今はみんなマスクをしている。飛沫はある程度止まっているのだろう。
だが、新型コロナが収束したら、みんながマスクを外したら、と思うと、あの映像がフラッシュバックするのだ。
この机にも、この書類にも、このドアにも大量の知らない人（知ってる人もいるけど）の飛沫が飛んでいる。
近くで話せば私の体に大量の飛沫を浴びる。今はそれを必死で頭から追い出し仕事をしている。
会社は少なくとも週2、3の出社が必要な業種で、お客様や同僚、上司、協力会社などとも対面で話す機会が多いのだが、
あの映像がだんだん頭から追い出せなくなってきて、ちょっともう無理だと思い始めてきた。
でも、対面がない職種に転職したとしても、生きていれば、いろいろな場面でこれからもたくさんの飛沫を浴びて生きなければならない。
https://news.yahoo.co.jp/byline/kutsunasatoshi/20220223-00283425
多発している高齢者施設クラスターに、今どういった対策が必要なのか
https://news.yahoo.co.jp/byline/kutsunasatoshi/20211023-00264502
新型コロナ 第6波は来るのか？
昨年10月の上記記事では”今のまま感染者が減り続けてコロナが収束するというシナリオはおそらく期待できないだろうと思われますので、第6波が来ることは想定しておかなければなりません。” と 第6波来ないんじゃないか派にやんわりめに釘をさしていたわけだが、今週の記事では”第6波が今後落ち着いてくれば、今後起こると思われる第7波に向けてそうした高齢者施設への支援の体制整備を進め、また高齢者のブースター接種率をできる限り高めておくことが重要になります。”
さらっとではあるが第７波が来ることはほぼ断言レベルになっている。第７波が来ないとは思えない。
忽那先生の記事を読めば、こうなる。”ワクチンをどんなに打とうと第７波は来る”
2020年台湾のカフェを楽しむ市民の姿を挙げて「キツイかもしれないけど日本もちゃんと自粛・規制してゼロコロナにすれば2019年までみたいに外食ができるようになるよ」や、2021年「お前らも2019年までのように自由にライブ、演劇、スポーツ観戦、コミケに行きたいだろ？俺もだよ。だったらワクチン打てよ」といったツイートは残念だけど誤認だったんだな。
”医療崩壊を避け、人命の被害を少なくできるかどうかが勝敗ライン”
忽那先生の記事を読めば、こうなる。2019年までの生活様式は戻ってこない。
クリミアの時より大騒ぎになっているのはなぜ？あの時は「戦争だ」との言説はなかったように思います。違いを教えてください。VIX並びに油も小麦も上昇していますが、今回もアメリカの武器商人が儲かった時点で収束するのではないでしょうか？
ゼレンスキーが「130人死んだ」と言ってますが、元コメディアンの言うことはどれだけ信憑性がありますか？トランプと同じカテゴリーの人間なのかなと思ってるんですが…
チェルノブイリ占領についても荒唐無稽な気がしています。確かなソースや映像は出ていますか？
これだけたくさんの人がなっているから特段びっくりもしなかったけど、
色々と思うこともあるのでつらつらと書き記す。
○みなし陽性
一人だけ検査でほかは皆みなし陽性。
○自宅療養
・２日後の晩に保健所からスマホのショートメッセージで連絡がくる。
・健康状態の入力もスマホとかPCでするんだけど、これホントにしんどい
人ってどうするんだろう。
・そもそも自宅療養とは？ 放置されるのに外出すんなとか意味不明。
○オミクロン
・幸いかなりの軽症で終わったけど、これで本当に社会を止めてよいの？
てか、ワクチンの副作用の方がしんどかった。ワクチン打つ意味なくね？
(1) 自動車、飛行機、火力発電など、あらゆる装置や仕組みは、100％完全なものではなく必ずリスクが存在し、トラブルや事故が発生します。飛行機などは、時には人命を奪うような事故の発生も含め試行錯誤を積み重ねて進化してきました。
(2) 原発も同様でありリスクばかり強調しても意味がないし、ゼロリスクの発想では科学技術の進歩はないとの考えもあるかもしれません。しかし原発の事故とその他事故は、本質的な性質が全く違っていると私は感じています。
(3) 飛行機や火力発電の事故でも死亡者が発生することがありそれは悲惨なものです。しかしこれらの事故は、一定時間が経過すれば、事故被害の程度は固定化し確定します。失われた命の数も、被害地域の範囲も、事故後ある一定の時期からは、基本的には増えることはないのです。
(4) 一方、原発の事故は、福島第一原発の例を見れは分かる通り、事故発生後11年が経過するというのに、未だに被害の程度は固定化せず、広がる可能性があります。
(5) 福島第一原発から漏れ出た放射線や、今も漏れ出ている放射線、さらに今後も漏れ出るかもしれない放射線が、人体や環境にどのような悪影響を与えるのか、確実な予測がついてはおりません。
(6) つまり原発事故は、その事故の影響が相当程度の時期まで収束しないこと、これがその他の事故と大きく違う点だと私は考えています。一般の事故は、その事故を被った人に被害は限られ、被害の及ぶ範囲も一定の場所に限られる場合がほとんどです。
(7) しかしも重篤な原発事故は、世代を超えて悪影響を及ぼす可能性もあります。一般の事故の悪影響は基本的に個人にとどまりますが、原発事故の悪影響は、個人を超えた人類の存在、そのものに及ぶ可能性もあります。環境についても、何世代に渡って利活用できない空間を作り出すことになっています。
(8) 原発とその他の事故には、こうした本質的な違いがあることを認識しなければなりません。原発以外の科学技術と違い、試行錯誤によって進化することが難しいのが原子力技術だと私は感じています。
ここまで引用
この(1)～(8)までのtweetの中で(7)の「世代を超えて悪影響を及ぼす可能性」という言葉を「遺伝的な影響」ととらえて、「放射線による遺伝子の損傷が世代を超えてひきつがれるということはない。なのでこれは福島原発周辺の住人に対するデマ」という風にフレームアップしてしまっているひとたちがいるようなんだけど、さすがにそれは無理筋じゃないですか？
「世代を超えて悪影響を及ぼす」といのは「その事故の影響が相当程度の時期まで収束しないこと」を指していて、その影響というのは「福島第一原発から漏れ出た放射線や、今も漏れ出ている放射線、さらに今後も漏れ出るかもしれない放射線」による影響を意味していることは明確じゃないですか？
もしかして(7)の「しかしも」を「しかし」ではなく「しかも」ととらえているのかな？そうすると「(6)(7)の影響に加えて遺伝的影響が...」という解釈も可能だが、文章にない「遺伝的影響」という言葉をおぎなう想像力が必要だし、そもそも文章のつながりとしておかしくなるでしょ？(6)の「一般の事故は～」をうけて「しかし重篤な原発事故は」と読むんじゃないの？じゃないと「一般の事故は～」の受け先がなくなっちゃう。国語の試験で "(7)の冒頭にふさわしい接続詞は「しかし」か「しかも」か"っていう問題が出たら、ほとんどのひとが「しかし」を選ぶんじゃないのかな？
全てはココに収束する。
同じ場所をグルグル回っているだけなのを螺旋階段を登っていると言い張りたがるのだ。
その円環を進む日本人の群れにとっては嫌韓は２，３０年も前のブームであり、もはや嘲笑されるべき過去の遺物だ。
今どきのディスコでジュリセンをヒラヒラさせる人間がいたら「昔の人のコスプレ」にしかならないがそれを本気でナウいと思えば「痛い」のである。
ダサい。
今のナウは人種差別をしないことだ。
門地による差別をしないことが憲法に刻まれた真面目くんルールから一周回ってイケてる今どきボーイが守るべきルールになっている。
黒人やフィリピン人とも友達のA君は格好良く、たとえ友達が１００人いても日本人率１００％のB君はダサいレイシストなのだ。
そういう時代だ。
これは逆に日本が「戦後の朝鮮戦争バブルで得たリードを失って本来の島国レベルになってきたから」というだけなのだが。
チンパンジーの群れとしてコケにしようものなら日本も巻き添えを食ってチンパンジーであることを認める羽目になるがそんな現実は誰も見たくない。
敵対するには多くを知る必要があるが、単に浅く仲良くするだけならそれなりまでを知ればいい。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
