はてなキーワード: SHIFTとは
ソース:はてなブックマーク[B!]人気記事・評価 - はてなブックマーク
(順位 - メタブクマ数 - ファーストメタブクマ日付 : 対象ブコメ)
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
ブクマ数 | タイトル | ドメイン |
---|---|---|
2287 | 自己肯定感の話 ① | sutekibungei.com |
1344 | 伝わる文章 | 基本要素 | SmartHR Design System | smarthr.design |
1089 | 2022年カタールW杯、日本対ドイツのレビュー - pal-9999のサッカーレポート | pal-9999.hatenablog.com |
1020 | Elon Musk は Twitter で何をしようとしているのか - The Decisive Strike | blog.nagayama.dev |
915 | 今日 Twitter 日本法人を解雇された皆さんへ #OneTeam - The Decisive Strike | blog.nagayama.dev |
775 | LAN配線マンションの回線を直した話 | skmz.one |
636 | 現在の森保ジャパンの攻撃とその問題点について - pal-9999のサッカーレポート | pal-9999.hatenablog.com |
620 | webエンジニアの「業務委託単価表」が公開 - Digital Shift Times(デジタル シフト タイムズ) その変革に勇気と希望を | digital-shift.jp |
595 | なぜ美人を美人と褒めてはいけないのか? オヤジさんのためのジェンダー問題シン常識 | ライフスタイル | LEON レオン オフィシャルWebサイト | www.leon.jp |
546 | ヤマト運輸株式会社 | GitHub | github.co.jp |
509 | 最近のフロントエンドフレームワークに対する認識とお気持ちの整理 - console.lealog(); | lealog.hateblo.jp |
476 | 東北の男性と結婚した外国人女性たちの経験。「不可視化」の理由と託された言葉の数々。#移住女性の声を聴く|ニッポン複雑紀行 | www.refugee.or.jp |
473 | 【勉強法】『一生頭がよくなり続ける すごい脳の使い方』加藤俊徳 : マインドマップ的読書感想文 | smoothfoxxx.livedoor.biz |
471 | 語り手が異常な小説が読みたい - 千年先の我が庭を見よ | kiloannum-garden.hatenablog.com |
451 | 【2022年 最新版】厳選QOLが爆上がりした買ってよかったアイテム紹介(デスク編・iPad編・整理編・エンタメ編・サービス編) | mitsuch.com |
444 | 色々試して行き着いた読書方法 | iwashi.co |
443 | 【お詫びと自主回収のお知らせ】社長に内緒で玉ねぎを入れすぎた 玉ねぎファンに贈るシャリシャリ玉ドレ200ml | 2022年 | ニュース | 綿半公式ページ | watahan.jp |
418 | MF文庫J編集部よりお詫びとお知らせ | ニュース | MF文庫J オフィシャルウェブサイト | mfbunkoj.jp |
411 | Twitterはサービス終了するのか? | www.bluechronicle.jp |
408 | Twitter での 2年 · eed3si9n | eed3si9n.com |
368 | 国立天文台が撮影した2022年11月8日の皆既月食と天王星食|国立天文台(NAOJ) | www.nao.ac.jp |
367 | Stable Diffusionを使って「いらすとや風画像生成モデル」を作った話 - ぬいぐるみライフ? | mickey24.hatenablog.com |
357 | 最近Reactを始めた人向けのReact Hooks入門 | sbfl.net |
355 | たかやん考:ネットラッパーの揺曳する身体と「病み」の美学、そして「エンパワメント」 - ハイパー春菊サラダボウル | namahoge.hatenadiary.com |
352 | 赤色の缶の「サクマ式ドロップス」で知られる佐久間製菓(株)が廃業へ、原材料高騰が影響 | www.tsr-net.co.jp |
342 | 『マネーフォワード ME』無料会員さまの連携上限数の変更、およびサービスの将来像について|マネーフォワード ホームカンパニー公式note | note.home.moneyforward.com |
323 | 【重要な追記あり】世界初のフルダイブVRMMORPG《ソードアート・オンライン》の正式サービスが開始 | dengekionline.com |
322 | GA4の計測設計には設計ドキュメントが重要な件 - ブログ - 株式会社JADE | blog.ja.dev |
315 | 「ザ・ルンペンブルジョワジー」 - tarafuku10 の作業場 | tarafuku10working.hatenablog.com |
306 | iPhoneで「ガスト」検索しようとするも「がす」の『す』でSafariが落ちる!? – kototoka | kototoka.com |
かなりガチめにブラインドタッチを習得して、Tab、Shift、Alt、アプリケーションキーあたりは見ないで使える。右側もフルキーボードであればHome、End、PageUp、PageDownが見ないで使える。
なので割と本当にずっとパソコンの画面しか見てないんだけど、最近になって『キーボードに視線を落とすと焦点が合うのに時間がかかる』ようになってしまった。
これがすごく気持ち悪い。キーボードに視線を落とすたびに焦点の調整で視界が歪むので、脳がぐらぐらする。
多分、変な格好で寝るとその形で筋肉が硬くなってバキバキになるのと同じことが目の中で起こってるんだと思う。焦点を合わすための筋肉がこの形で硬くなってしまう。
という訳でブラインドタッチを習得するにしても程々で、視線はちょくちょくモニターから外した方がいいと思う。キーボードとモニター間で視線移動する頻度が高い方が目(と多分首)にいい。
■写真
https://i.imgur.com/ry7afWi.jpg
■スペック
メモリ:4GB
ストレージ:SSD256GB
■その他
・4GB→8GBにメモリー換装したがシリコンパワー製メモリでは相性問題でNGだった
・Linux環境自体は動いたが、Breveだと問題ないが、AssaultCubeは正直重い
・テントモードは、ファンレスなので冷却的には有効。バッテリーの持ちも良いかも
・画面の回転は設定でできるが、Flex側でショートカットCtrl+Shift+F3でいける
槍→騎兵→弓→槍のジャンケンまでは理解できるが実際に戦うと俺の騎兵が槍兵にボコられて全部終わってしまう。
騎兵を使うことを止めると弓の強化版であるカタパルトに全てが破壊される。
仕方ないので騎兵を遊撃兵として別枠に使うのだがこれがもう無理。
槍1
弓2
斥候3
騎兵一番槍4
騎兵第二陣5
対人攻城兵器6
対物攻城兵器7
全軍突撃を8
ヒーロー9
でやってるんだがもうこの時点で頭と指が追いつかない。
訓練ミッションでなら槍に横陣を引かせて敵の騎兵を止めつつ弓と一緒に引き撃ちを行うところまで出来た。
実戦だと完全に崩壊する。
引き撃ちは分からんので一度ぶつかったらもう撤退は存在しない。
ナポレオンの時代の戦争モノでよく出てくるオッスオッスでビビるかボコられて逃げたやつが蹂躙される押し合いしか存在しない。
そしてこの中で騎兵を暴れさせるのが無理すぎる。
こっちの騎兵は一番槍が全部止められている。
そっちをお取りにして第二陣が敵を蹂躙し返すのだが騎兵を半分無駄遣いしている分こっちがまず負ける。
ヒーローは使い方が分からんので必殺技ぶっぱさせてあとは気づいたら死んでる。
内政も当然のように意味不明なのでとりあえず金鉱に旗を差しておいて住民を量産してから適当に金鉱から他の仕事に向かわせるという杜撰なやり方しか存在せず人数の割合とかは何もわからないので資源が気づいたらダボダボに余る。
もちろんこんな状態で対人が出来るわけがないのでひたすらAIと戦いAIにボコられている。
プロゲーマーの試合の動画を見て「なるほど局地戦ってこうやるんだ~~」と知ったつもりになっていたがそもそも局地戦に戦術を持ち込む余裕がない。
荒らしとか言われても意味がわからないので斥候をSHIFTで予約したポイントを走らせる以外何もさせてない。
相手がCPUだからどうせ自動生成だろうということで敵の農民をみかけても放置しかしない。
本当に分からない。
同じことを子供達も思っているからプロゲーマーの注目度が上がっているんだと思う。
野球やサッカーとかはまずフィジカルと反射神経が大前提で、子供同士の試合だとなおさら技術や戦術が圧倒的パワーの前で霞む。
練習しまくってバケモノ化したんだろうなって思う前に生まれつき身体が凄いだけなんだろって考えちゃうと少しだけど尊敬しにくい気がする。
反射神経は相変わらず大事だけどなによりイカれてるのは当たり前のようにやっていることの当たり前じゃなさ。
それが全て技術によって行われているという部分から来る気持ち悪さ。
変化球や変態シュートのような技術的部分の鍛錬だけをひたすら積み上げて作られる未知の現象を起こしてる。
ヤバイわ。
なんなのこれ?
なんで普通の人がこんなの遊んでるの?
「かきくけこ」、と打つのにローマ字入力だと kakikukeko と10タッチ必要だけど、カナ入力だと5タッチで済む。
そう考えるとカナ入力はローマ字の倍のスピードで入力できそうな気がするでしょう? でも意外とそうではないんです。
たとえば、ローマ字入力で子音入力の要らない「あいうえお」はカナ入力でも同じ1タッチ。
また、ローマ字では子音で表現できる濁点「゛」や半濁点「゜」も1タッチ必要。
それに、拗音(ゃゅょ系)や促音(っ)、句読点「、」「。」はシフトキーの同時押しが必要。
日本語はこれらをふんだんに組み合わせてセンテンスを作るので、差が埋まっていくんです。
極端な例ですが、「情弱」という単語でタッチ数を数えてみましょう。
カナ入力 = し ゛ shift よ う し ゛ shift や く = 10タッチ
どうです? なんと、かな入力のほうが3タッチも多いですね。ローマ字より40%以上多くタイプしています。
実際の文章でカウントしてみましょう。増田の投稿画面にある以下の注意書き。
はてなは、匿名性を活かした自由な表現が可能となる場として、はてな匿名ダイアリーをご利用いただきたいと考えております。普段お使いいただいているアカウントで書くものから離れた文章や、いつもとは違う筆致の文章などの投稿、匿名ならではの問題提起など、匿名性を楽しめるような形でご利用ください。
結果は、
でした(なるべくタッチ数が少なくなるようにカウントしています)。
ローマ字入力100タッチに対してカナは約69タッチしています。3割程度しか節約できていません。
カナのほうがキーの分布が広いことも考え合わせると、カナのアドバンテージはさらに縮まりますね。
列挙してみたらとても実用性のあるソフトじゃないんだけど、何を思ってマイクロソフトはこんなもん自信満々でデフォルトのチャットシステムとしてお出ししてるんだろう?頭おかしいのか?
これのWindowsデスクトップ版アプリが昔はショートカットキーでどこからでもすぐ最前面に呼び出せるって機能があって、
例えばalt+shift+zで最前面に出てきて、もう一度押すと瞬時にタスクトレイに隠れる感じ
これめっちゃ重宝してたんだけど、
結構前に新バージョンが出てきてからこの機能が完全になくなってしまった
で、未だに旧バージョン使い続けてるんだけど、サポートとかは完全に終わってるしPC変える度に古いインストーラーを利用してインストールしなきゃだしなかなか面倒くさい
「特定のショートカットキーで特定のアプリを最前面に出現させ、もう一度押すとタスクトレイに隠す」ってあったら便利だよなーって思うんだけど、どうにかする手段ないかね
23年前に開発終了したにもかかわらずいまだ「定番」と呼ばれるアプリがあるらしい
https://forest.watch.impress.co.jp/docs/serial/yajiuma/1390753.html
駆け出しエンジニアだった20年前、仕事でバイナリ見る機会はあまりなかったけど、TeraTerm、FFFTP、DF(差分比較。インストールが要らないのでサーバー作業で重宝した)あたりはよくお世話になった。当時のフリーソフト作者ってのはマネタイズとか全然考えてなさそうな連中ばかりで、俺もべつだん作者に感謝とかせずに当然みたいな顔して使っていた。今だったらこれくらいの定番ソフト作れたら会社立ち上げて売り抜けて一生遊んで暮らせる目もあると思うが、この現在の風潮を見て昔のフリーソフト開発者たちはどう思ってるんだろうか。裏切られたような気持ちでなければいいんだが。フリーソフトに限らずSHIFT the Oracleとか、Mr. XRAY(Delphi)とか、メーリングリストで親身にアドバイスしてた面々とか、そういう人々って半分は趣味にしても残りの半分は使命感というか、基本的にはアテネの学堂式インターネットコミュニケーションの理想を胸に、金銭的利益を求めずにそれぞれの形でコミュニティに貢献してたんだと思うんだよね。それが俺みたいな木っ端エンジニアとかに散々フリーライドされて、とくに見返りもなく、マネタイズの波にも乗り損ねて、もう年齢的に60手前ってところだと思うんだが、みんなどこでどうしてるんだろう。当時は銭金じゃなかったんだろうけど、いまの銭金一色のネットスケープをどう思ってるんだろう。みんな秀まるお氏くらいには報われてくれてればいいんだが。秀丸は買った。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
そうか、親指Shift派か…