はてなキーワード: ハンズとは
https://b.hatena.ne.jp/entry/s/togetter.com/li/2012882
静岡駅周辺に住んでいるオレがオススメします。静岡駅周辺はとにかく住みやすいです。
静岡駅北側には静岡駅直結のショッピングセンターとして「パルシェ」「アスティ」が、駅から徒歩5分に松坂屋・パルコが、駅から徒歩10分くらいにショッピングモールの「セノバ」がある。さらに5分ほど歩けば伊勢丹もある。
商業施設に加え、呉服町商店街や両替町といった繁華街が広がっていて、普通の人が日常的に使う店の殆どがある。
強いこだわりが無い限り、これらの店があっても暮らせないということは無いでしょう。
もうちょっと活動範囲を広げれば家電量販店や家具の大型店、業務スーパー、県立美術館、広い公園、山、海とかあります。
スマホアプリで使えるレンタサイクルがあり15分70円で乗れるので、車や自転車が無くてもちょっとした遠出は可能。
北側の繁華街を抜けた先(駅から徒歩15分~20分くらい)と南側の住宅街(駅から徒歩10分以内)には、1LDKで宅配ボックスがついたアパートが7万円台で10候補以上ある。東京だと1つの区や市に2~3候補あるだけ。
3,000万円台で駅から徒歩10分50坪で角地とか普通にある。東京だと3,000万円台では多摩地区の駅から徒歩30分以上離れた30坪の土地とかになる。23区内にはなさそう。
アウトドアの趣味とか子育てとかで車を持つようになっても維持費は都心よりも安い。なぜなら車移動が一般的だから。
駐車場込みのアパートが大多数だし、駐車場代は月極で1万以下~2万円のところが多い。24時間1,000円台で止められるところとかある。
賃貸で暮らしている限り近隣住民との付き合いは東京並み。挨拶とかする程度。
家を買ったら町内会に入ったりするが、それはどこでも同じでしょう。
ライブのアンコールまで見てその日のうちに帰宅することが可能。
CCNAは受けたことないし、インフラ系は実務経験あるだけで体系的な勉強してきてないから自信ない。
というわけで、ちょっと調べたのと観測範囲での印象だけの話になっちゃうんだけど、ネットワークエンジニアじゃなくてインフラ系を名乗るんであればCCNAだけだと足りない気がする。
あと、今からインフラ系を目指すんであれば、Kubernetesみたいなコンテナ使って大きめサイズなことやるときに多少プログラミング(と言っていいか微妙だけど)することからは逃れられないんじゃないかと。
そうでなくてもサーバーいじりは多少シェル書けないと始まらないみたいな雰囲気はある。
そうではなく、ネットワーク専門の、特にセキュリティに強いエンジニアはそれだけで十分需要あるから、そっち方面のスペシャリストになるのもありなのかなと思う。
セキュリティの理解は攻撃したりされたりっていうのを実践してみたり観測するのが近道だと思うから、とっかかりとしてはそういうハンズオンを探すか、YouTube漁ってみるか、あるいはCCNA取った時点でネットワークエンジニアとして実務経験積みながら学ぶのがいいんじゃないかな。
ふわっとしててごめんよ。
「どこで買うか」より「何を買うか」を考えると良いんじゃないかな。
◎まずはジャケット
あまりお金が無いならユニクロでもいいと思うけど、ちょっとだけお金を出して、ららぽーととかに入ってる店を何軒かフラフラして「これかな」と思う一着を買っておくと気分が良くなる筈。
出来れば5万くらい、安くても3万くらいのジャケットを持ってると便利だけど、そこまで金出せないんじゃ、という人はアウトレットモールに行っても良いかも。
あと、やりがちなファッションでパーカーがあるんですけど、10000円以下のパーカーなら羽織らないほうがマシ。
◎シャツ類
ユニクロで良いけどオリカのようなビジネスウエアを売ってる店で「ポロシャツ」を買っておこう。
白以外なら何色でも良い。どうしても黒を選びがちだし黒は無難だけど、深緑や濃紺、エンジ色などのポロシャツを買うのもお薦め。原色は買うな。
チェックのシャツでも良いですけど、モンベルで買うくらいの勢いで行ってほしい。
ワイシャツは白が基本だけどオリカとかでカラーシャツを買うのも良いかも。
ただしジャケットの相性があるから、わかんなかったら無難に白か水色で
◎パンツ類
これもユニクロでおけおけなんだけど体型・体格によってはヨーカドーも選択肢に入れても良いし、ワークマンでも良いかもしれない。
色は黒、ベージュ。グレーは「おっさん」になりかねないので要注意。
ジーンズを買うならリーバイスのような「ちゃんとした」店で買おう。クソ高いけど、シルエットが違う。
裾はまくるな。裾上げサービスを使おう。待ってる時間もったいないとか思いがちだけど。
◎靴
長時間歩いてもしんどくない。
パッと見、革靴のように見えるデザインのが2種類くらい置いてあるからそれを選ぼう(ちょっと高額いけどね)
◎鞄
Amazon Prime Videoのおすすめが定期的に話題になるが、見ようと思ったらプライム対象外になってた…ってことが割とある。ならAmazonオリジナルなら消えないのでは?と思いオリジナル作品からいくつか感想など書いてみた。そんなに見てないので大したリストにならなかった。アマプラ入ってる人は大抵見てるだろう。今から入るって人にはちょっと参考になる…か?
どれ見たか思い出すためにWikipediaの「Amazonが配信するオリジナル番組のリスト」を見てわかったが、Amazonオリジナルと表記されていても「買い取り」作品の場合は配信が終了することかある。現に評判の良かった「Mr.ロボット」はアマゾンでの配信は終了してしまっている。「リーガルバディーズ フランクリン&バッシュ」も一度配信終了リストに載った(現在配信中)。
アメドラ見てる人ならどこかで見たことがある、色んなドラマに(主に)悪役ゲストで出てるタイタス・ウェリバーが主演の刑事もの。顔つきからダーティコップものかな?と思わせて割と真っ当な刑事っぷり。人気が出てS7まで製作され、現在スピンオフの「ボッシュ: 受け継がれるもの」S1配信中。
個人的にはS1はいまいちだがS2からはめちゃくちゃ面白かった。脇のデカ箱+ビア樽コンビが最高。
ちなみにスピンオフは「買い取り」作品なのでいつか見られなくなるかもしれない。
syfyチャンネルでS3まで製作され打ち切られたがベゾスが大ファンだったためにAmazonで拾われたハードSFドラマ。
S1序盤は地味だがどんどん盛り上がっていく。S4からはまた地味になるが。宇宙船や戦闘の描写がいいんですよ。ちゃんと宇宙船に穴が空くし。
サイコサスペンス…サイコスリラーかな?S1はジュリア・ロバーツ主演、S2で完結。一回30分なので見やすい。S1では過去のアメリカの復員兵の復帰支援施設での出来事と、そこで働いていたケースワーカーのハイディの現在が交互に描かれる。とにかくS1の不穏な空気感が良い。演出が素晴らしい。Wikipediaにはズバッとネタバレが書かれているのでネタバレ嫌い組は見てはいけません。
話題になったので知っている人も多いであろう、ブラックな笑いのヒーロー物。かなりグロ。エロもある。話は面白い。ホームランダーが取り繕っていたものがどんどん剥がれていく。
ニューヨークのオーケストラにいたオーボエ奏者による回顧録を原案とし、南米から来た天才指揮者ロドリゴ(デュダメルがモデル)と新人オーボエ奏者ヘイリーをメインにオーケストラをめぐる人間模様や楽団の現実問題等を描く。
自分の中のイマジナリーモーツァルトに話しかけてるロドリゴ、楽団に入りたいヘイリー、ヘイリーのルームメイトのリジー、予算確保に走り回る総裁グロリア、ちょいちょい口を出したがる名誉指揮者トーマスなど脇の人々もみんなチャーミングで良い。S3のシベリウス5番のシーンが美しい。
S4は日本が舞台になるが、変なロボと変なクラオタが出てくる。あんなチンピラみたいなクラオタおらんやろ…面白いからいいが。
画集からインスパイアされたというSFドラマだけど、装置や研究の謎は特に明かされたりしないのでSFっぽい雰囲気のドラマ、って感じ。北欧の田舎の薄暗い空気と佇むなぞのロボ、って絵はたっぷり味わえる。そういうの好きな人におすすめ。
最近公開されたクリス・プラット主演のお父さん復讐もの。クリス・プラット、今回はシリアス演技。アクションは金かかってて見ごたえはある。
これ書いてる今現在3話まで見た。配役の人種がどーたらこーたらと色々物議醸してて、検索してもストーリーの感想までなかなかたどり着かん。個人的には人種は気にならないけど、ヌメノールでのガラドリエルが若者ムーブ過ぎてちょっと気になる。ガラドリエルでも若い頃はあんなもんなんだろうか。
新聞の読者投稿欄の恋愛物語を一話完結でドラマ化。S1はいい感じにオチもある物語が多くてほっこりします。
死後に脳内の記憶をバーチャル空間にアップロードして金がある限り永遠に生きられる世界のコメディ。金が無い人はアップロードしても容量の問題で一日に数分しか活動できなかったりという世知辛さ。主人公がアップロードされた経緯に不審な点があり…とサスペンス展開に。
イーガンで似たような設定あったなと思い出す。
オカルト事件を解决していくコメディ。面白かったけどS1で終わってしまった。
ハルマゲドンを阻止しようとする天使と悪魔、人間のオカルトコメディ。悪魔たちは悪魔の子を人間の子とすり替えるが、うっかり間違ってすっかりいい子に育ってしまうのであった。地獄の番犬もかわいいわんこに。
その他、マーベラス・ミセス・メイゼル、スニーキー・ピート、子供向けだとまほうのレシピ、ゴーティマー・ギボンが評判いいみたいです。そのうち見る。
元英軍兵士で今はホテルのナイト・マネジャーであるパインがかつて殺された恋人の復讐をすべく、武器商人ローパーの組織に潜入。ドキドキスパイもの。
トム・ヒドルストンとエリザベス・デビッキが美しい。ちなみにタイトルはナイトマネジャーだけどマネジャーやってるの序盤だけだった。
スター・トレックの続編ドラマ。親友データを失い、失意のうちに実家のぶどう畑でワインを作っていたピカードのもとに一人の女性が助けを求めて現れる。
スター・トレック全然見てないんだけど、冒頭の掴みが好みすぎて見てしまった。面白かった。
本国アメリカではパラマウントの配信サービスにて配信中なので、最終シーズンはアマゾンでの配信がないかもしれない。悲しい。
二人の破天荒弁護士のドタバタコメディ。よくありがちな深刻な展開がなく気楽に見られる。嫌味な同僚や弁護士の父親との確執もあるにはあるが、全員アホなので全然深刻にはならない。「シリコンバレー」のディネシュ役の人が広場恐怖症の弁護士役で出てくるが、ほぼディネシュ。
あとグッドオーメンズと原作者一緒ということでアメリカン・ゴッズはS1だけ見た。かなり暗かった。
ハンズオブゴッドは1話でやめてしまった。つまらんとか面白いとか言えるほど見てないが、単に1話目の殺人シーンとかが辛くて。
機会があって予備校の数学の授業と司法試験の授業受けたのだが草生えましたわ
『オンライン学習にして予備校から優秀な講師引っ張ってきた方がコスパ良い』
『授業は予備校講師に任せて、公立教師はわからない子や逆にもっと学びたい子のフォローと化学実験や家庭科のフォローや体育のフォローだけやっとけ』
・・・って思ってたが、ここまでわかりやすさ+エンタメ性にはっきりと差がついちゃうのかよとね
確かにわかりやすい予備校の授業でのみ勉強してきたヤツは考える力がつかないことも起こり得そうではあるが、
専門課程に進む前に知識を詰め込む、あるいは何かをする(たとえばプログラムとか)ための知識を得てる段階で考えるも何もねーだろうよ
公立の雑な授業・大学教員の研究の片手間の授業を受けたらからってどうこうなるレベルのものじゃない(そもそも高等教育もリベラルアーツとほぼ遠い)
社会で不自由しないために・詰め込んだ知識を活かすために、最低限は考える力を鍛えなければの場合も、
公立の雑な授業・大学教員の研究の片手間の授業をもって考える力を養うをやりました!とか怠惰なことはやらずに
極端に思考力が弱い人がいると言う前提に立って訓練メニューを用意すべき
あと思考力を養う授業では『理解しました』といっても、極端に思考力が弱い人は覚えた数式を具体的にどう使うのかはわからないとかフツーに言い出すので、
アメリカみたいに世界中から優秀な若者が勝手にやってくる+資源があるなら学位商法やっててもオッケーだが
みずほフィナンシャルグループは米グーグルと提携し、デジタルサービスをてこ入れする。2022年度中にも、グーグルのクラウド上で顧客の取引データを分析し、投資信託や住宅ローンの提案など顧客ごとに適したサービスを提供する。
みずほ、Googleと提携 DXで顧客サービス抜本見直し: 日本経済新聞
https://www.nikkei.com/article/DGXZQOUB182BH0Y2A310C2000000/
「パソコンの先生」としていろんな企業に研修に行っていると、どこも基盤となるITを知らない人たちに「でぃーえっくす」としてPythonだAIだIoTだ学ばせようとするんだよね。
世の中の「システム」というのがサーバー、ストレージ機器などでできていて、それがネットワークでつながっている、データは誰かが設計したとおりにDBに蓄積される、ということを知らない非エンジニアの人たちに、クソ人事が「Pythonで機械学習!データ活用してデジタル変革!」とか打ち出して研修を受けさせることがとても多くてね。基礎がない人たちに何を教えても、ハンズオン用に用意されたデータを解答例どおり操作できるようになるだけで、何ら自社の実際のシステムに基づいたデータ収集、加工、分析はできないのに、「研修を開催した」という実績が人事の点数になって、給料になる。人事は何件研修を開催した、という実績じゃなくて、それで社員は何ができるようになったか、という成果で評価されてほしいよね。
みずほも、今やることはクラウドだ顧客データだDXだという上っ面じゃなくて、土台の堅牢なシステム基盤を要件定義、設計できる人材を育てることだと思うんだけどね。
私はかつて、DeNAで契約社員として3年ちょっとの間、働いていた。当時 (今もそうかもしれん) 、DeNAではゲーム以外の収益の柱になる事業を模索していて、いろいろとエッヂの立った謎なサービスやアプリがリリースされてはひっそりと閉じられていく、ある意味では面白いうねりの中にいた。commだとかGroovyみたく壮絶にリソースを投入してコケたサービスもあれば、Showroomのように分社化して巣立っていった成功例もあった。
そんな、会社としていろいろ試していたフェーズで、Flatというどう考えても収益化できなさそうなSNSアプリがどさくさに紛れてリリースされた。
これは閉じられた匿名掲示板的なSNSで、ローンチ直後はDeNAの従業員だけが利用できたのだと思う。
誰でもスレッドを立てることができ、コメントをみんなが投稿し、いいねで馴れ合うという、機能としてはありふれたものだった。
ただ、後に他のテック企業の人も利用できるようになり、mixiやサイバーエージェント、DMMとかの人たちと交流できたのは楽しかった (各企業のドメインのメアドを持っていないと会員登録時の認証メールを受け取れないようになっていた) 。
スレ主やコメントを投稿した人が誰なのかは分からないが、どの企業の人なのかは表示されていた。アップデートで、同一スレに複数のコメントを投稿するとそれらのコメントが同一人物の投稿だということまでは分かるようになっていたと思う。
「IT用語に『夜の』をつけてエロくする」みたいな大喜利のスレッドがあって、私が投稿した「夜の多分、大丈夫だからリリース」がスレッド内でトップのいいね数を獲得したのはいい思い出だ。
そんなFlatであったが、「全社集会の内容を教えてくれ」みたいな内容で、見るのもコメントするのもDeNAの従業員限定の設定で私が立てたスレッドがあった。全社集会は半期に一度のオールハンズなのだが、なぜか正社員しか参加できないという縛りがあって、どんな雰囲気でどんな内容が話されているのか興味があったのだ。
誰かが「内容は正社員限定の機密だから話せないし、そんなふうにカジュアルに聞くべきではない」とコメントした。私は正社員限定なのは単に会場のキャパ (社内には全員が集まれるスペースはないので、どこかのホールを借りて開催していた) の問題だと思っていたし、内容の一部、たとえば何々への貢献で誰々が表彰された、だとかはわりと普通に共有されていたので、少なくともDeNA社内では秘密でもなんでもないと思っていたので、どんな文言だったかは忘れたが「いいじゃん、そんなケチくさいこと言わずに教えてよ」みたくコメントしてしまった。
それに対して、私の態度がよくない、みたいなコメントが付き始め、それが段々とエスカレートしていった。
「お前なんかぜったいに正社員になれるわけがない」だか「そんなんだから正社員になれないんだよ」みたいなコメント。(別に正社員になりたいだなんて言ってないし、辞めた後で知ったのだが私の給与は並の正社員よりも高かった)
一番ひどかったのは「こいつ (渋谷ヒカリエの) 何階で働いてるんだろう? (自分と同じ) 23階だったら嫌だ。ぜったいに関わりたくない」というコメント。
最終的には何十人かの人から、私の人格を否定するコメントを頂戴することになった。
当時の私の精神状態はなかなかに不安定で、同僚たちの中に私と知らずに私のことをケチョンケチョンに言い放っている奴がいる、というのを意識しながら仕事をするのはなかなかに辛いものがあった。
何年も経った今、振り返ってみて、確信を持って言えるのは、私はインターネットで誹謗中傷を受けたのだということ、そして、それに対してサービスの運営も人事も、なにもしてくれなかったということだ。
当時の私はどうすればよかったんだろう。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
東急ハンズが東急から売られてしまうからもう東急を名前に入れられないのだという。
そうだね日立工機が日立から売られたらもう日立入れられないのと同じだもんね。
でも東急ハンズのブランドのなんともいえない微妙なおしゃれ感高級感は東急だからだと思うんですよ。超高額商品が売ってるわけではないが、ほぼ定価でしっかりしたものを売り買いしている、そういう感じがね。
でもカインズが買うからカインズハンズではあまりにもハンズのイメージが小さくなっちゃいます。
なのでタチを抜いたらハイコーキなのでこれからもコーキって呼んで、みたいになんか近い感じがいいと思うんですよ。
サンキューハンズとかラッキーハンズだとちょっと昭和っぽいし安っぽいですかね。