はてなキーワード: sshdとは
ビルド エンジニアが別の会社に移った。奴は文字通りターミナルの中に住んでいた。
Vim を愛し、 Dotで図を作成し、Markdown で wiki の投稿を書くようなタイプの奴だ。
奴は90 秒以上の時間がかかる場合はなんでも自動化するスクリプトを作成する。
@JaredClaunch
いくつかのダンジョンや直線的な進行に関連付けられたクエストを含むオープン マップは、間違いなく機能する可能性があります。 ダンジョン アイテムを進行状況に組み込むこともできますが、すべてかゼロである必要はありません。
@beans-do6wc
同意しました。 オープンワールドゲームのダンジョンが機能しない理由は、進歩の感覚がないからです
@MachFiveFalcon
はい! 7:41 はあなたの主張をよく反映しています。 「正しい」解決策が得られたとき、私にとって特別な満足感があります。 (ただし、私は新しいオープン デザインのパズルを楽しんでいます。) フックショットのような永続的なゲームプレイを変えるアイテムは、適切にデザインされたパズルで使用すると、プレイヤーに真剣に考えることを強います。
@lucashen9686
なぜあなたたちはそれが理解できないのですか? 誰もがあなたのようなわけではありません。
@juicecake2458
@lucashen9686 私はそれには大いに反対しますが、私は自分自身と上記の人々のことを代弁しているだけなので、確かなことはわかりません。
@amandaslough125
@lucashen9686 そして、ほとんどの人は、パズル主導のダンジョンで知られ賞賛されているゼルダ シリーズを実際には好きではありませんでした。 それはアドベンチャー ゲームの世界におけるユニークなニッチでした。
@t_bone2145
まるで以前にも同じような素晴らしいゲームを作ったことがあるような気がします...咳、風が覚める、咳、咳
@FDMD_
@MachFiveFalcon
@lucashen9686 ブレス オブ ザ ワイルドの祠や神獣は好きでしたか? それともオープンワールドの探索、戦闘、アートデザインだけだったのでしょうか?
@lucashen9686
@amandaslough125 正確に言えば、1 億人を超える Wii 所有者のうち、スカイウォード ソードを購入したのは 400 万人だけです。 ほとんどの人はゼルダが好きではありませんでした。 非常によく知られているにもかかわらず、人々がそれを避けたため、マリオの売上には及ばなかった。 BOTWが来るまでは。
でも、疎外された昔からのゼルダファンにはそんなことは分からないと思うよ。
@lucashen9686
@juicecakes2458 古典的なゼルダの売上が物語っていますし、最も主流のゲーム シリーズにはダンジョンがないという事実もわかります。
@lucashen9686
@MachFiveFalcon 神社も神獣も全体的には大丈夫だと思ってたけど、私としては多くの神社を諦めたけど、筋金入りの古いゼルダファン以外のほとんどの人は金を賭けてもいい、銀河系の頭脳パズルは面白くない 、多すぎます。
BOTW で私のお気に入りの点は、探索とシーカのスレート能力です。
@juicecake2458
@lucashen9686 ビデオ ゲームが非常に広く認識されているのは助かります。 あの頃よりもずっと。 また、『トワイライト プリンセス』などのゲームは約 1,000 万本、『ゼルダ 1』は 700 万本、『時のオカリナ』は 1,400 万本を売り上げました。 それは今のToTKと同じくらいです。
@legendoffarore3711
厳密に言えば、これはボット以前のすべてのゼルダのゲームと同じです。
@lucashen9686
@legendoffarore3711 そう、だからどれも 900 万本以上売れなかったのです。
@m_h_o_o_o_o
@lucashen9686 ゴミ味。 あなたは『スパイダーマン 2』が GOTY を受賞できなかったことにがっかりした人の一人のようですね。
@lucashen9686
@juicecakes2458 これは本当にでたらめです!
マリオカートって聞いたことありますか?? Wiiスポーツ?? ポケットモンスター?? GTA??
80年代以降は2,000万、3,000万ともっとたくさん売ることが可能でした。 ゼルダの売れ行きが良くなかったのは、人々がそれが何であるかを知らなかったからではなく、どこでも雑誌の表紙を飾っていなかったからではなく、ほとんどの人がゼルダを好まなかったからです。
なぜこれが受け入れがたいのか、数字を見れば明らかです。
@lucashen9686
@juicecakes2458 と時のオカリナは 700 万本売れました、何のことを言っているのかわかりません。
また、生涯売上を今年リリースされたゲームと比較しています。 非常に論理的な比較です。
@thatnerdygaywerewolf9559
@lucashen9686 ということは、あなたの意見に関する限り、シリーズのアイデンティティの主要な側面が削除され、既存のファンが遠ざかることは、シリーズの人気をさらに高めたのだから、まったく問題ないということですか? それは、そもそも既存のファンがダークソウルを好む理由であるにもかかわらず、より多くの視聴者を引き付けるためにダークソウルの戦闘と挑戦を廃止すべきだと言っているようなものです。
この議論は結局、シリーズに関して重要なのは IP/ブランド名だけであり、ゲーム自体の本質ではない、ということになります。
@lucashen9686
@thatnerdygaywerewolf9559 もちろんです!
ビジネスはお金を稼ぐために存在します。伝統的なゼルダではないという理由で最大900万人の古典的なゼルダファンがBOTWに満足していないとしても、誰が気にするでしょうか? 3000万部以上売れたんですね! 古典的なゼルダのファンよりもBOTWのファンの方が多いです。 全員を喜ばせることはできません。
あなたのコメントは、ほとんどのファンボーイがいかに非合理的で疎外されているかを示す完璧な例です。
@mmike
@lucashen9686 銀河系の脳パズル? ゼルダの赤ちゃんパズルが銀河の脳だと思うなら、どうやって日常生活を乗り切るのですか?
@lucashen9686
@mmike何?? 😂😂😂 赤ちゃん向けのパズルは何ですか? 天才さん、申し訳ありませんが、私は普通の人間で、ほとんどのパズルは自力で解くことができますが、一部のパズルは私にはちょっと無理で、何時間も解き続ける気はありません。 ガイドを調べるだけでも楽しいものではありません。
@mmike
@lucashen9686 新しいゲームにはダンジョンもありますが、本当にひどいダンジョンです。 それが問題なのです。
@amandaslough125
@lucashen9686 まず、スカイウォード ソードが Wii コンソールの寿命の終わりに発売されたことを忘れています。その頃、ほとんどの人は次世代を待っている間ゲームを無視し、ほとんどのゲーマーがうんざりしていたモーション コントロールに焦点を当てていました。 すでに2年ほど前から流行しています。 移植であるにもかかわらず、SSHD はスイッチですべてが売れるため、実際にスイッチでよく売れました。
第二に、所有するコンソールごとに販売されたゲームに基づくと、BotW は OoT よりも良い成績を収めませんでした。 彼らは本質的に結びついています。 そして、ほとんどのゼルダ ゲームは常にコンソールごとに所有される割合が高く、マリオ カートやスマッシュのようなものにのみ抜かれています。 人々はゼルダのためにゲーム機を購入します。
最後に、一般的な主流市場では、すべての企業が同じものを作っているため、必ずしもブランドロイヤルティがあるとは限りません。 よりニッチな製品からの安定した収入は、現在の市場トレンドで利益を得るよりも長く持続可能です (特に、オープンワールド ゲームはどれだけ売れてもお金が吸い込まれます。このため、現在 AAA 市場は独自のバブルを崩壊させています) 傾向)。 任天堂は自らが生み出した市場シェアに参入してくる競合他社と徹底的に戦ってきたため、彼らはよりニッチな市場を切り捨て、その過程で空白を生み出しているだけだ。 そして、Buldur's Gate 3 は、「時代遅れのゲームプレイ」(ターンベースの RPG など)でも、実際にうまくやれば依然として十分な利益をもたらすことを証明しました。
@mmike
@lucashen9686 小さな子供たちはゼルダのゲームをします。 彼らを銀河の頭脳と呼んだり、倒すには天才でなければならないと言うのは愚かです。 私は天才だと言いたいのではなく、彼らはそれほど難しくないだけです。 私と私の友達全員は7歳くらいのときに時のオカリナを倒し、私の甥はほぼ同じ年齢でブレス オブ ザ ワイルドのすべての祠を倒しました。
@thatnerdygaywerewolf9559
@lucashen9686 かっこいいですね。 したがって、重要なのは人気と大きな数字だけであり、実質的なものは何も気にしていないことがわかりました。
@imatiu
@juicecakes2458 この議論に対する単純な反論は、『リンクの目覚め』のリメイク版が約 700 万本売れたとか、『スカイウォード ソード』のリメイク版が 400 万本売れたというものです。
リメイクであることを考慮したとしても、『リンクスの目覚め』は 30 年前のゲームのリメイクであるため、Switch コンソールを持っているほとんどの人にとってはほぼ完全な新作ゲームですが、それでも売上は『ティアーズ オブ ザ』の半分にも達していません。 王国はそうしました。
したがって、ゲームの認知度が低いということは、売上が低いという正当な議論とは思えません。
@therealpskilla502
@thatnerdygaywerewolf9559 誰もが同じ好みを持っているわけではないという事実をご指摘いただきありがとうございます。多くのゲームが優れているのは、すべての人にアピールしようとしているわけではないことです。 OoT が Wii Sports、GTA、Fortnite などに比べてほとんど売れなかったなど誰も気にしません。それでも、多くの人の意見では、OoT は史上最高のゲームの 1 つです。
@nuclearbeeberman
@therealpskilla502 しかし、任天堂は他の企業と同じようにお金を稼ぎたいと考えており、ゼルダの両方のスタイルを(少なくともAAA品質では)作る能力がありません。 外部スタジオは毎年ゼルダのゲームをリリースしたいと考えているので、今後さらに多くの 2D ゼルダのゲームが登場すると確信しています。 リマスター (いずれにしても際限なくリマスターすることはできません) とウォリアーズのスピンオフの間に、いくつかの新しい 2D ゲームが登場すると確信しています。
@sonymicronin
@lucashen9686 それは真実ではありません 😂😂😂
@sonymicronin
@lucashen9686 あなたが彼らを嫌っているからといって、他のプレイヤーが彼らを好きではないというわけではありません 😂😂😂
常に充電してないと起動すらしないスマホが手元にある
メルカリとかで売っても赤字になりそうなくらいの5年以上前のAndroid6のスマホなんだけど、何か使い道ないか悩んでるところ
条件は以下
・boot loader unlockはできない(怪しいサイトに金払えばunlock codeをもらってできるっぽい)
・32GBの容量があったが、OSなどでいろいろ容量を取られて半分以上は埋まっている
この上で以下をためしていた
・termuxを入れて実質Linux機とする
termuxというアプリを入れるとshellが使えるようになり、sshdも起動するとPCからSSH接続して操作可能になる
色々試したけど、専用のパッケージマネージャが最新バージョンのパッケージは扱えるが、過去のバージョンをアーカイブしてないのか取れないことが判明し
やりたいことが実質できない状態になったので終了。自力で過去バージョンビルドしてみたけどarm64なのがいけないのかうまく動かなかった。
あと性能低すぎてEC2とかの最小インスタンスでもそこまで時間かからず終わる処理が30分以上待たされたりしたので実用するにはハードルが高かった
Alexaアプリのハンズフリー発話の設定を入れればAlexaのほぼすべての機能が使えるのでいい体験になった
しかし、他のAlexaからスマホのAlexaは見えないので他のAlexaから呼びかけ等ができず終了
・Android6の検証機とする
今日日6なんて古いバージョンサポートしなくてもよくなったので終了
以下はまだちゃんと試してない事
スマホ自体を監視カメラにして何かしらのアプリで見られるようにする
懸念点はそこまでカメラの性能が高くない事と、外に設置する場合に電源をどう確保するか、防水をどうするかが悩みどころな点
なんかそういうアプリがあることは知っている
懸念点は持ち運びできないことと、電源の確保
他になにかよさそうな使い方あれば教えて欲しい
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。
【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から見ると単に1つのプロセスが稼働している扱いになる。
【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%増加する、という任意のステップに従ってタスク数を増減させる
リリース直後だと apt-get update && apt-get upgrade でそのまま壊滅的に環境が壊れるという状態で話にならなかったのだが、
現状残っている問題点としては
あたり。
Mac 上で Linux サーバーで動くアプリを作ることが出来るぐらいには Linux サーバーで動くアプリを作れるようになっている気がする。
MBP2011ハイブリッドHDD(SSHD)に換装し、BOOTCAMPに新しくWindowsをインストールしたら、猛烈に動作が遅い。ずーっとプチフリーズ状態で困り果ててた。Windows7でもダメ、Windows8でもダメ。Windows10でもダメ。
タスクマネージャを見ると、ディスクがちょっとした軽微なアクセスでもすぐに100%になってしまうことが原因というところまではわかり、1週間いろいろ試行錯誤して解決した。
原因は
だと予測されます。少なくとも私の環境では、以下の方法でばっちり治りました。
fsutil behavior query DisableDeleteNotify
3、コマンド入力の結果、「DisableDeleteNotify=0」であればTRIMが有効であることを確認。
ふつうSSDであれば、これで良いのですが、私の環境ではこれが原因で非常にWindowsが遅かった。
fsutil behavior set DisableDeleteNotify 1