  |
はてなキーワード: 連携とは
トッパン・フォームズは、「引越しワンストップサービス」の実現に向けた、引越しにおける各種手続きのオンライン化に関する実証実験を開始した。
「引越しワンストップサービス」は、引越しにともなう電気・ガス・水道などのライフライン系から、金融機関や自治体への転出・転入などに関わる手続きまでをオンラインかつワンストップで完結させるサービス。
本サービスはデジタル庁が推進している取り組みで、本実証実験ではデジタル庁のほか、横須賀市、神戸市、姫路市、三菱UFJ銀行、野村證券、ウェブクルー、NTTデータの協力のもと実施されている。
本実証実験では、トッパン・フォームズの共通手続きプラットフォーム「AIRPOST（エアポスト）」やポータル事業者が提供する各種サービスなどを活用。引越しにともなう一連の手続きのワンストップ化と各種手続きに必要な情報連携の実現可能性を評価する。
また実験では、手続きの負荷低減やUXの向上につながるための意見収集をあわせて実施しているという。
トッパン・フォームズは今後、「引越しワンストップサービス」の実現に向けて協議・検討を進めていくとともに、デジタル庁への提言や「AIRPOST」の機能追加・セキュリティの向上などに取り組んでいくとしている。
https://ameblo.jp/lawyertanaka/entry-12724692878.html
「今はただしばらく眠り，また元の世界に戻るだけ」(第3編引用)と本気で信じている人達なんだから、
ほーんと仮に本気でそんなことを思っていたのなら、
あー死んだね、また今生きているのとまったく同様の姿かたちで復活できたんだろうね、で終わりではないの？
＞「そもそもそういう医師と普段から連携していてそうした医師を紹介できると，あなたたちは普段から公言してるんじゃないんですか？」
等々と批判をしても、教義に従って生きてたら復活するでしょ何怒ってんの、究極にはそれくらいしか思わないと考えるけどね。
勿論ではあるが、死にはしないが治療をしないと著しい苦痛が伴う傷病について、
それらを無輸血治療の専門家をまともに紹介できないのであれば、(たぶん現状まともに出来ないんだろうけど)
https://www.nhk.or.jp/politics/articles/feature/27538.html
↑NHKの記事でな、読むと共産党の嫌われ方がやばい。ある選挙区で野党統一候補を出した場合、共産党系の候補だと非共産系と比べて得票率が10ポイントぐらいさがるらしい。
同じ選挙区で、非自民党系の同じ野党統一候補でも、「共産党員です」って言っただけでそんぐらい票が減るって、、右派はともかく、左派にも嫌われてるじゃん。なんでみんなそんな共産党が嫌いなん？
暴力革命が怖いの？きょうびそんなことできるわけないし、日本が共産主義の社会に！なんて、、、ないない。ソ連はつぶれたし中共は独裁で怖いし、令和のこの時代に多くの人を惹きつけるような魅力も影響力もない。せいぜい最低賃金あげようとか、非正規雇用ガー、で労働環境の改善を謳ってるぐらいの政治団体でしかないよ。一般人からしたらそんぐらいの団体よ、共産党って。大した影響力はない。
なのに、なんでみんな共産党を嫌うの？破防法の対象だし、連合は連携を嫌がるし、自民党は立憲共産党だの民主主義対共産主義だの嬉々として揶揄するし、、、で、実際に選挙なったら票は減るしさ。なんか嫌な思い出でもあるの？
いやまあ人によって考え方はいろいろで、支持できるor支持できないそれぞれあるのは当然なんだけど、それにしても共産党の嫌われ方は異常じゃないか？
クールでイケてるリアリズムで政治を語りたい国士さまがいっちょかみの知識でファッション的に共産党をディスってるだけじゃないの？いわゆるリベラル的な人たちからも嫌われてるじゃん。
リベラルでも保守でも時勢に応じた是々非々の合従連衡で共産党と付き合えばいいのに、蛇蝎のごとく嫌われてるよね。こいつらと付き合ったらもう政治生命は終わり、みたいな。
連合会長が共産党嫌いみたいな最近のニュースを見てそう思った。なんなんだいったい。大企業の労組では連合系と全労連系とかでばちばちやってんのか？私怨？わからんなー
増田が真に欲しているのは連携ではなく、透明性だと思われる。空き情報がネットで横断検索できればよい、というそれだけのことなので。ちなみに俺は情報が連携されていないことに安心感を覚えるので、連携という言葉を聞くと気持ち悪くなる。連携という言葉を今後一切使うな。
(いや、勿論歯医者に限った話じゃなくて他の医者もだし、歯医者とそれ以外の医者との間でもだけど)
例えばさー
急に歯が痛くなった、今すぐにでも見て欲しくなって、まずは一番近いA歯科医院に電話をかける
→A歯科医院「予約が取れるのは二週間後です」
→私(先過ぎるな……でも取れないよりはいいか)「では二週間後でお願いします」
→でもやっぱり二週間も待つのは辛いので、その次に近いB歯科医院にも電話をかけてみる
→B歯科医院「予約が取れるのは一週間後です」
→私(A歯科医院より早い！こっちにしよう)「では一週間後でお願いします」
→C歯科医院「予約が取れるのは一ヶ月後です」
→私(先過ぎるけれどそれだけ人気って事はこっちの方がいいのかも！？)「では一ヶ月後でお願いします」
→でもやっぱり痛いのでもっと早くみてもらえないものかと、その次に近いD歯科医院にも電話をかけてみる
→私(そのくらいなら余裕で待てるかも！)「では明後日でお願いします」
→ちょっと遠いけれど新たにE歯科医院を発見し、電話をかけてみる
現状のシステムはこうなっていて、極めて非効率的。歯医者の数だけ多くても、全部にいちいち連絡して問い合わせなきゃいけないし診察券も別でその都度レントゲンを撮る必要があるなんてあまりにも馬鹿馬鹿しい。
→A歯科医院「うちでは予約が取れるのは二週間後ですが、一番早いところでE歯科医院なら今日の午後に予約が取れますよ」
たったこれだけで済む。歯科医療から自由競争というくだらないものを排除すれば、それだけで簡単に効率的になる。
歯医者が(歯医者に限らないけれど)無駄に多くて乱立し競争し合ってているせいで非効率的になるし、患者も無駄に時間を浪費して医療費も嵩む。
父親は病院に不信を抱いているのかもしれない。なので、まずはこの気持ちに共感しよう。
事実、父親の言っていることも一理あって、医者はピンキリで外れにあたると余計に事態がややこしくなるときがある。
ただ、我々素人が勝手に判断して診断を遅らせるのも同じくらいに危険なことだ。
...とそういう感じで話を進めればいいのではないか。
薬が怖いというのも、薬というものを知らない、ということから来るものかもしれない。
人間は知らないものに対して恐れを感じる。しかし理解してしまえば、それほど怖いものではないと分かる。
...とそういう感じで、誤解を解いていくといいのではないか。
母親が病院に行きたがらないというのも、まずその行きたくないという気持ちを分かっている、ということをよく伝えておき、
状態が安定しているときを見計らって、「怖い検査はないよ」「お医者さんと10分くらい話すだけだよ」などと話してみるといいのではないかと思う。
ただまぁ増田自身もうつのようだから、あまり「こうしなければ」と思い詰めるのもよくない。
まずは母親と笑い合えるような朗らかな会話を増やしてみるといいと思う。
数年前から積立Nisaを始めてるので、時々投資系のYoutubeを見て「へー、投資ガチ勢はこんなこと考えてるのかー。まあこっちはインデックス積立で呑気にやってるんだけど。まあ板にらめっこして『株と債権と商品で今一番儲けるのはどれだ』ってやってるなんて、こっちとは世界が違うね」くらいで見ている。
のだけど、「ひょっとしたら利上げ円安で輸出銘柄が上がるんじゃないか？」って興味が出て、S株で輸出・製造関連を１万円だけ買ってみていた。
そんな時にロシアのウクライナ侵攻の話が出て、商品としての天然ガスが乱高下した。
それで、「ロシアのウクライナ侵攻」→「欧州米国の経済制裁」→「欧州のロシアの天然ガスの輸入停止」→「天然ガスのロシア以外の需要増」っていう展開が見えて、「これは天然ガス関連の企業は上がるんじゃないか」といくつかの銘柄を調べてみた。
そうすると、北米やカナダに権益を持つ企業というのはあるもので、ちょっと購入を考えたが、よくよく考えると、これで自分が儲ける条件て「戦争で（少なくとも軍人は）人が死ぬ」「ロシアの人が不景気で困る」「ヨーロッパの人が天然ガスが高くて困る」という、「マジで人が困るイベント」が前提で、「これでちょびっと上がってもなんか嬉しくない儲け方だな」とおもって、相場は見るだけにして購入は止めた。
そうしてるうちに、「欧米の天然ガス供給の連携」の話がニュースで流れて、「ロシアのウクライナ侵攻」→「欧州米国の経済制裁」→「欧州のロシアの天然ガスの輸入停止」までは本当にその線で進みそうになってきた。
富豪の立志伝で「戦争で財をなして一族の基盤を作った」みたいな人の話が出るんだけど、こういうのを何万倍の規模でやってる人がいるんだなーって思った。
年末までに1000円くらい上がればいいなー。
（支店長が役員でなく、本店と連携・叱咤激励を受けてないタイプ）
飲みにケーション文化が残ってるんでしょうな
野党側でMMT積極財政として信頼できる党はれいわだけだから。
国民民主党は選挙翌日に即新自由主義緊縮財政維新と制作連携という名の犬になったからもはや信頼できない。
もともと国民民主党って、昔希望の党として、前原誠司が希望の党を作ったときに、ほぼまとまりのところで安保法制と消費税増税に賛成できないやつは排除するという問題をやらかしてる。
口先だけきれいなこと言って、ひっくり返せなくなったら裏切る最低の連中だわ。
後、前原誠司は今の局面で金融緩和をやめろとほざいているしな。必要なのは設備研究投資をして外需に合致した供給を作ることなのに。今金融緩和を止めたらしたら完全に国際的な需要の奪い合いに負けてスタグフレーションに落ちるぞ。
https://news.yahoo.co.jp/articles/21e11aad18ee597e879de08f8c4705fe349075a4
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
○ご飯
朝：なし。昼：麻とんてき定食。夜：白菜とピーマンのスープ。ごま。りんご。
お菓子は…… ベビースター、TOUGHグミ、コアラのマーチ、ピノ。食い過ぎでは！？
○調子
麻とんてきという、とんてきに山ほど花椒をかけたやつを食べた。
残業代稼いで何か贅沢しよう。
復刻イベントを周回。指輪、アーカルムポイント、カスカス、半汁を回収。
○ドラガリアロスト
プロテクトリンク編成というのを組んでみた。確かに強いなあ。けどリソースたっぷり使っちゃた。
ただこれでようやく、真ドラゴンの試練が全部周回できるようになった。
| サービス名 | 月額 | 年額 |
| 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移行で永年無料ユーザーを今からでも狙いたい……
