  |
はてなキーワード: ゲートウェイとは
占星術に関する本を何冊か買ったりして、
https://twitter.com/yoppymodel/status/1548848031826870272
それ以上にこの話題で噴出する「占い」というものへのコメント群が
「占い全然知らんし興味もない人がイメージで言ってるな〜」と思ってちょいイラッとしたので
分かる人向けに書けば
「ホロスコープの読解は自分や友人のネイタルを中心に何度か試したことがあるがアスペクトを絡めて読むのは難しく勉強中。
トランジットにはあまり興味がなくて心理占星術関係に偏り」です。
わからん人向けに書くと入門書の内容を舐めた程度で占いの実践としては素人。
未来を知りたいとか隠された真実を知りたいとかいう願望はない。
なので以下間違ってる可能性は大いにあり、詳しい人からの異論は歓迎です。
朝の星座占いランキングに代表される12星座占いというのは、その人の持つ「代表的な星座」だけを見ている占星術の簡易版に過ぎない。
本来はその人が生まれ落ちた瞬間の惑星の位置や惑星同士の配置から読み取る。
占いなんて根拠なく適当言っているだけだろう、という人もいるが、
この「生まれた瞬間の星の配置」については誰が計算しても同じものが出る。
（※正確にはハウスの分割方法とか小惑星とか読み取り方に流派はあるけどめんどくさいから割愛）
ゆえに、占星術とはみんなが同じ星の配置を見て、それをそれぞれが言語に翻訳して伝えているものである。
星の配置から何を読み取るか、というのも、ある程度セオリーがある。
たとえば月※や金星や水星、火星といった地球に近い星は、地球から見たときの位置の移り変わりが激しく、感情や気質といったパーソナルなものの象徴として扱われる。
対して冥王星※※、海王星、天王星といった遠い星は、移動する周期が数年〜数十年単位なので、例えば世相の変化や世代の意識のようなより大きなものの象徴として扱われる。
そういったそれぞれの要素が、相互に影響したり、人生のどこかで強調されたりするのを、星の配置――位置や星同士の角度から読み解いていくのが、占星術といわれるものだ。
ネットの無料占いの範囲でも、少し詳しいサイトを見ればバーナム効果で片付けきれない結果を見ることができると思う。
（※占星術は天動説の世界なので太陽や月も「惑星」と呼ばれる。チ。）
（※※冥王星は占星術の世界では今のところまだ惑星扱いである。）
前述のとおり占星術とは「惑星それぞれが象徴するものと、その位置関係」を読み解き言葉に翻訳して伝えるものだ。
そこには、図を見て言葉で伝えるような、翻訳段階のズレが生じる。
また、どの星を読み取るか？も個人の資質に左右されるところだ。
恋愛運を見てください、といったとして、その占い師が「恋愛」が何から構成されていると考えているか、で伝え方は変わってくる。
例えば、
……なんて言われ方をする。
それは、占い師が恋愛というものの構成要素をどう考えているか、に左右されてしまう。
少し昔の本ならば、
なんて断言していた本も多かったが、
そういう一律な読み方を支持する占い師ももう少なくなっている気がする。
占い師は適当を言ってるから結果がぶれるとは一概には言えない。
占い師の考え方自体が、「読み取り」「翻訳」に影響を与えるのだ。
「運がいい」とは星がどういう配置にあることか？という占い師の解釈によって順位が異なるから、結果が異なる。適当に並べているからでは、ないことのほうがおおいだろう。
（余談だが、少し占いをかじるとそのへんのアルゴリズムがなんとなく見えることがある。順位予測など可能である）
ここまでつらつら書いたとおり、私の知る限り、占いとは「象徴の読解」という営みそのものである。
なので占いに関して「当たる」「当たらない」という言い方自体に個人的には違和感があったりする。
人の性格や世の中の動きといった、混沌として一概には言い切れない茫漠として掴みどころのないものを、
占星術の様式に沿って分類し、その関係性を図に表されていると仮定し、それを解釈したもの。
だと私は思う。
とここまで説明されたところで、
「そもそも星の位置が、人の性格だの世の中だの象徴してるわけなくね？？？」
と思う人はいるだろう。
私だってそう思う。
太陽も月も冥王星も惑星で、地球が宇宙の中心にあるという仮定で導き出された図が世の中の何かを「象徴」してるだなんて、
それが「科学的」に「正確」なわけはない。
けれど大昔の人たちはそう思ったのだ。大真面目に。
そして、世の中の物事を観察し、分類し、星星に振り分けて、関係を考え抜いてきた。
「人の性格」とかいう多面的なものを、占星術の世界ではどのように分類してきたのか。
「世の中の動き」とかいう無数の歯車の噛み合った膨大な機械を、占星術はどのように分割してきたのか。
その、この世に向ける眼差しの果てない努力の痕跡が私は好きだし、
それはときどき、現代の日々を生きる私のことを励ましてくれたりもするのだ。
北京の蝶がニューヨークで嵐を起こす、その間には無数の細かな歯車が噛み合っていることだろう。
カムチャツカの若者がきりんの夢を見たりする理由は、若者自身も知らないところにあるんだろう。
そういう、茫漠とした、人間個人では把握しきれない物事を、なんとか星に仮託して把握しようとするのを、馬鹿馬鹿しい振るまいとは私は思わない。
そういう「考えたってわからないこと」「人間の力では及ばないこと」を忘れ、目の前の物事だけに没頭して生きるのはあまりに荒涼としていないかと私は思う。
そういう、「向こう側」をみんなシャットアウトして生きるほうが、私には特殊に思える。
ときどき星を見るとかして、その中の一つとして自分が位置づけられているのだとおもうくらい、正常な人間の営みではないかと、私は思う。
星の話をしてるから仕方ないな。ゆるしてほしい。
さて、ヨッピー氏の主張は
「とはいえ、占いみたいな非科学的なものを電波に乗せて、カルトへの忌避感を下げるのはどうなの？」
というところだと思うのだが、私はこれについては明確におかしくないか？ と思う。
そもそも「科学的な話」「論文などのエビデンスがある話」ならいいのかというと、
「エビデンスとなりうる論文はあっても効果としては現実的ではない話」はいくらでも電波に乗っている。
あれらは健康食品詐欺のゲートウェイになっていないと言えるのか？
彼らはおそらく自分たちのことを「科学的に」思考していると思っているのではないか。
あるいは散々指摘されている「サウナでととのう」なんて明らかに医学的に警鐘が鳴らされてもいるが、「自律神経がととのう」とかいうよくわからんゴリ押しがなされているだろう。
そもそも「科学」とは絶え間なく検証と訂正が繰り返されるものだが、
その大部分は電波に乗ることなく、どこかの商品に都合の良いところ、テレビで視聴率の取れそうなところだけが編集されつまみ食いみたいに放送されるのが現実だ。
でも、それがない放送大学オンリーみたいなテレビを望むかといえば望んでいないだろう。
私が何を言いたいかというと、
「情報がどれほど科学的か」という点では、電波に乗っているものはさほどの差がないのだ。
結局我々はそれを選んで、検証し、学び、考え、実践して自分なりの判断力を養っていくしかない。
すべての情報は自分の判断のための「材料」だと割り切ることだ。
それを放棄して、自分以外の誰かに判断を委ねきってしまったとき、
占いだろうが「科学」だろうが、少なくともテレビに乗っている情報という土俵においては変わらないのではないか。
……と締めようと思ったが、
カルトの怖いところは
「自分で考えろ 自分で考えて私達と同じ結論になれ」なところだし
たとえば反ワクチンやカルト宗教による輸血拒否だって当人たちにとっては自分で考えた結果なわけで
「自分で考える」が絶対の解決策とも思われないのが難しいところではある。
健康診断で医師に不安を煽られないと運動不足の解消に向かうのは難しいし、
ならば医師になら全権委任していいかというとアカン医師をツイッターからいくらでも引っ張ってこれてしまう。
あるいは、飛行機が飛ぶ原理って科学的に立証されてないらしいよ……という情報の正誤を私は確かめられていないが、移動したいときはその判断をすべて棚上げにし、自分の命を航空会社に委任して飛行機に乗る。
委ねるべきときはあるけど、その相手は見極めなければならない。
というなんとも煮えきらない結論で終わる。
え？普通にいらないじゃんと思ったけど、そうか電話回線必要な老害パソコンの大先生だから絶対いると思い込んでるのか。
家庭用に市販されているWifi、もしくはWifi機能がついたルーターは壊れやすかったりパフォーマンスが落ちるのが定説らしいけど、
みんなどうしてるのか気になった。
おそらく以下の5点になるだろうと仮説を立てたので、みんなはどれに該当するか教えて欲しい。ついでに機材も。
ホームゲートウェイというのは、ざっくり言うと光回線契約した時にレンタルでもらえるWifiつきルーターのこと。
たぶん賃貸とかで部屋狭いひとはこれで事足るだろう。
部屋が広くなったらHGWにプラスしてメッシュWifiになってるかな？
自分も今この状態だけど、なんかWifi調子悪いんだよな……もし引っ越したらHGWのWifiはoffにする予定
まぁよくある構成。IPv6にするためにこうしてる人も多いかもしれない。
2重ルーターになるからうんたらとか言われても、基本的にこういう選択肢しかないから仕方ないというのはある。
しかしWifiがついてると壊れやすいらしい。買い換えるにしても高い
上記のWifiつきルータのモード変更でAPモードにしてる人もいるかもしれない。
完全にWIFI AP専用の製品であれば家庭用でも壊れにくいかもしれないし、交換コストがあまりかからないかもしれない。
Wifi APを業務用にするだけで格段に壊れにくいし接続数も余裕があるしパフォーマンスが高いらしい
完全に逸般の誤家庭。普通の家はここまでしなくていい。でも楽しそう。
シード値：-8863289679625882536
①初期スポーン地点からx座標プラス、z座標マイナス方向へ進むと平原の村が1つある。この村のそばに見つけにくいが荒廃したポータルがあり、これを利用してネザーゲートを作ってネザーに行くとかなり近くにネザー要塞がある。
②村に戻りエンダーアイを作って投げるとベルのある井戸のそばに沈むので、そこを掘るとエンド要塞がある。
③エンダードラゴンを倒した後エンドゲートウェイポータルでワープした地点からx座標プラス、z座標マイナスに進むとわりと近くにエンドシップのあるエンドシティが見つかる。
はじめに見つけた村の真下にエンド要塞があったのは初めてだったので記念に記録しました。ネザー要塞も近いしエンドシップも近い。この村には司書と聖職者がいる。
あとこの村にかなり深い洞穴があるので水を流して下まで降りると、流れるマグマの中に9コのダイヤモンド鉱石がある。村の周辺にもまた深い洞穴があるので降りると鍾乳洞の中に廃坑があり、ゾンビスポナーと洞窟グモスポナーがある。ウロウロ歩き回りたくない、サクッとエンドラを倒してエリトラをゲットしたい人にオススメのワールドです。
（もうすぐ大型アップデートがきますが、現時点で村が見つけにくく、ネザー要塞がすごく見つけやすくなった印象がありますが気の所為でしょうか）
自分は公共の場（公共施設・街路・交通機関・大規模商業施設など）に萌え絵を掲出することには絶対反対だ。
不快になる人への配慮と、萌え絵がゲートウェイになりオタク文化への没入を引き起こす点である。
オタク文化も脱社会化された状態で没入していると誤認することで、かえって文化圏の提示するイデオロギー（ラディカル右派と親和性が高い）を学習することが考えられる。
加えて萌え絵は尖った表現であり、人の感情に大きな影響を与える。それは塗炭の苦しみである人もいれば、とてつもない快感である人もいる。
自分の知り合い（男性）に「ゆるキャン△」で精神的苦痛を味わったと主張している人がいる。
だから萌え絵は公共の場に掲出するべきものではないし、萌え起こしも絶対にやめるべきである。
ただ「月曜日のたわわ」の日経広告への批判については引っ掛かりが残る。そもそも日経新聞（紙）は「公共の場」といえるのかということがある。
現在は紙の新聞を読む層自体限られているが、その中でも日経新聞は限定された属性の人しか読まない。
そういう特定属性しか読まない媒体が「公共の場」というのはさすがに拡大解釈し過ぎである。
表現の持つ問題点については確かにその通りなのだが、そういう作品は残念ながら山のように流通・消費されており、「月曜日のたわわ」は運悪くやり玉に挙げられたという印象に過ぎない。
というわけで萌え絵には反対だけど、今回の日経新聞の騒動には違和感しか覚えなかった人間の独り言。
萌え絵のようなオタク文化は問題ある思想を接触者にインストールしようとする点において問題があるけど、じゃあどうすればいいかと言われれば論説を読んで知識を蓄えるしかないよなと。
萌え絵好きな皆さんはラノベだけではなく、岩波・中公のような新書を読むなどして知識を蓄えるよう努めてほしい。高校生向け「現代社会」の資料集も使える（倫理・政経と比べ網羅性が高い）。
シード値：1015118566
初期スポーン地は平原で近くに村もあり。初期スポーン地からx座標−1,500、z座標2000程度の範囲に雪原の村やタイガの村がたくさんある。ゾンビ村やダイヤが3つある村もあり。高低差があり、付近や村の中に深い渓谷のある村が多い。この村々の中に地下にエンド要塞のある村が2か所ある。z座標はあまり動かず、x座標上を動いて探すと良いかも。
ネザーではx座標−700〜500、z座標−300〜100くらいの範囲にピグリン要塞が6か所ある。ネザー要塞を探す途中に見つけることもできる。
ジ・エンドではx座標1700、z座標−2200程度の範囲にエンドシティが6か所あり、エンドシップも4つある。
※エンドシティ探索中、チェストを開ける直前で世界をコピーしておき同じチェストを何度か開けたところ、ダイヤのつるはし、鉄の防具などアイテム自体は同じですが、付与されるエンチャントは毎回違っていました。エンチャントはチェストを開けた瞬間ランダムに決まるのかもしれません。
※途中で見つけたエンドゲートウェイポータルにエンダーパールを投げ入れたところ、黒曜石の上に出ました（ジ・エンドで最初に降り立つ場所）。自分が入ってきたエンドゲートウェイポータルに戻る必要はないようです。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
