  |
はてなキーワード: 再利用とは
それじゃあまりにも天才しかできないだろうということでニーモニックというのを持ったアセンブリ言語ができた
多分当時の人の中にあった議論は、こんなの1と0の羅列に名前つけただけだろ、なんかいいことあんの？という人たちと、まさにブレークスルーだ世界が変わるとエキサイトした人たちだろう。
色々あったが、人にも読めるソースをアセンブリ言語に変換してくれるCが出来た。
多分このときも単なるアセンブリのスーパーセットだろ？なんか意味あんのか？っていう人たちと、やばいレベルでプログラミング書きやすくなったとエキサイトする人たちに分かれたことだろう。
このときも、構造化プログラミングに毛が生えた程度のもんだろ？何が嬉しいんだ？という人と、オブジェクト指向なら何でもできる！とエキサイトした人たちで溢れかえったことだろう。
Java以降のIT界隈ではもはやオブジェクト指向抜きには語ることはできなくなった。
何が何でも継承でカプセル化でポリモーフィズムだとオレオレフレームワークが雨後の筍のごとに開発され結局Ｓｔｒｕｔｓに一網打尽にされた。
その後RoRによるCoCによってXMLなんかいらねーわとなったがアノテーションを使う方に進んでいった。
もはやこの時点で継承だのポリモーフィズムだのはそれほど重要なものではなくなったと言ってもよく、このあたりからEoDだとか、再利用性、メンテナンスのしやすさに主軸は移っていったと感じている。
人月の神話の時代から語られた銀の弾丸はないというたった一つの真理は忘れ去られオブジェクト指向ならなんとかなる、オブジェクト指向だという人々もまたこのときに誕生している。DI？ファクトリとリフレクションでなんとでもなることでしょ？何が嬉しいの？と。
その後関数型プログラミングが誕生する。
これを見た人々の中には、関数型プログラミングなんかJavaよりもそけつこうにしたていどのものだろ？小さいクラス作ればJavaでもできることをなんでわざわざ関数型プログラミングに移行しなくてはならんのだときっとそうなったることだろう。
マシン語からアセンブリ、CからOOPとトレンドが移り変わる中で起きているのは、技術革新であり、もうこのままじゃきついからこっちにしようというムーブメントであり、それに乗る人、抗う人というのは必ず現れる。
抗う人の中には、新しい技術に対するモチベーションは失われているがポジションを失うのだけはごめんたといういわゆる老害と呼ばれる人たちや、本気でシフトする意味がわからないくらいに思考が固まった人、はたまたこの技術なら全て解決できるのだから他のものはいらないという信仰を持った人などがいるし、乗る人もこの対極にいるのだろう。
多分２０年後には関数型プログラミングとは違うなにかが天才たちの中から爆誕し、同じような議論が起きることは想像に難くない。
しかし人類はどうすれば簡単に1と0をコンピュータに保存できるのかということをひたすらに追い求めているのだから不思議なものだ。
たしかに極端な話1と０だけ打ち込めれば同じことはできるかもしれないが、その難易度は遥かに高くなっているし、現実的には不可能だろう。
企業がシステムにせいぜい20台程度のホストを導入するようなものだった。
今は百や千のオーダーでは聞かない仮想ホストにDockerコンテナが複数動きこれらが協調しなくてはならない、もしくは各自独立で動いても問題が起きてはいけないので、ここには関数型のデザインが合うと思うし、一方でデータにアクセスするところではトランザクションに強いJavaというように適材適所住み分ける必要がある時代になった。
当然Javaだけでもできるし、関数型たけでもてきるかもしれないが、こういう形の議論をする人はその技術が目的になっている。
継承やポリモーフィズムをする以上はスーパークラスのライブラリもなくてはならないが、それも億劫になっているのかもしれない。
今後関数型プログラミングがあらゆるものを席巻する時代になるかもしれない、OOPがそうであったように。
それとも人々はもうそういう不毛なことはしないのかもしれない。もはやそういう時代は過去のものになったと考えたほうが良いだろう。
関数型プログラミングの理解よりも、オブジェクト指向の習得よりも、目的を達成する最小のコードをエレガントに書くといういわゆる画力が何よりも先に求められる時代に入ったのではないだろうか。
そういう意味では業界としてだいぶ健全になったようにも思える。
それじゃあまりにも天才しかできないだろうということでニーモニックというのを持ったアセンブリ言語ができた
多分当時の人の中にあった議論は、こんなの1と0の羅列に名前つけただけだろ、なんかいいことあんの？という人たちと、まさにブレークスルーだ世界が変わるとエキサイトした人たちだろう。
色々あったが、人にも読めるソースをアセンブリ言語に変換してくれるCが出来た。
多分このときも単なるアセンブリのスーパーセットだろ？なんか意味あんのか？っていう人たちと、やばいレベルでプログラミング書きやすくなったとエキサイトする人たちに分かれたことだろう。
このときも、構造化プログラミングに毛が生えた程度のもんだろ？何が嬉しいんだ？という人と、オブジェクト指向なら何でもできる！とエキサイトした人たちで溢れかえったことだろう。
Java以降のIT界隈ではもはやオブジェクト指向抜きには語ることはできなくなった。
何が何でも継承でカプセル化でポリモーフィズムだとオレオレフレームワークが雨後の筍のごとに開発され結局Ｓｔｒｕｔｓに一網打尽にされた。
その後RoRによるCoCによってXMLなんかいらねーわとなったがアノテーションを使う方に進んでいった。
もはやこの時点で継承だのポリモーフィズムだのはそれほど重要なものではなくなったと言ってもよく、このあたりからEoDだとか、再利用性、メンテナンスのしやすさに主軸は移っていったと感じている。
人月の神話の時代から語られた銀の弾丸はないというたった一つの真理は忘れ去られオブジェクト指向ならなんとかなる、オブジェクト指向だという人々もまたこのときに誕生している。DI？ファクトリとリフレクションでなんとでもなることでしょ？何が嬉しいの？と。
その後関数型プログラミングが誕生する。
これを見た人々の中には、関数型プログラミングなんかJavaよりもそけつこうにしたていどのものだろ？小さいクラス作ればJavaでもできることをなんでわざわざ関数型プログラミングに移行しなくてはならんのだときっとそうなったることだろう。
マシン語からアセンブリ、CからOOPとトレンドが移り変わる中で起きているのは、技術革新であり、もうこのままじゃきついからこっちにしようというムーブメントであり、それに乗る人、抗う人というのは必ず現れる。
抗う人の中には、新しい技術に対するモチベーションは失われているがポジションを失うのだけはごめんたといういわゆる老害と呼ばれる人たちや、本気でシフトする意味がわからないくらいに思考が固まった人、はたまたこの技術なら全て解決できるのだから他のものはいらないという信仰を持った人などがいるし、乗る人もこの対極にいるのだろう。
多分２０年後には関数型プログラミングとは違うなにかが天才たちの中から爆誕し、同じような議論が起きることは想像に難くない。
しかし人類はどうすれば簡単に1と0をコンピュータに保存できるのかということをひたすらに追い求めているのだから不思議なものだ。
たしかに極端な話1と０だけ打ち込めれば同じことはできるかもしれないが、その難易度は遥かに高くなっているし、現実的には不可能だろう。
企業がシステムにせいぜい20台程度のホストを導入するようなものだった。
今は百や千のオーダーでは聞かない仮想ホストにDockerコンテナが複数動きこれらが協調しなくてはならない、もしくは各自独立で動いても問題が起きてはいけないので、ここには関数型のデザインが合うと思うし、一方でデータにアクセスするところではトランザクションに強いJavaというように適材適所住み分ける必要がある時代になった。
当然Javaだけでもできるし、関数型たけでもてきるかもしれないが、こういう形の議論をする人はその技術が目的になっている。
継承やポリモーフィズムをする以上はスーパークラスのライブラリもなくてはならないが、それも億劫になっているのかもしれない。
今後関数型プログラミングがあらゆるものを席巻する時代になるかもしれない、OOPがそうであったように。
それとも人々はもうそういう不毛なことはしないのかもしれない。もはやそういう時代は過去のものになったと考えたほうが良いだろう。
関数型プログラミングの理解よりも、オブジェクト指向の習得よりも、目的を達成する最小のコードをエレガントに書くといういわゆる画力が何よりも先に求められる時代に入ったのではないだろうか。
廃墟といえば、日本的には(アトラクションとしての)ディズニーランドのホーンテッドマンションとか旭川とかにある大正時代に炭鉱で栄えた街の成れの果てといった廃墟施設なんかを思い起こすと思う。
漫画とかメディアミックスされたものだとそこに人に危害を加えるお化けがいるらしいんだけど
一度も遭った事ないんだよね。
霊感がある人にしか見えないとか言うんだけどじゃあ霊感が見えない人にはゴーストタウンって場所はゴーストタウンとは言わないよね。
現実的に見れば暴走族とか反社会的勢力の隠れ蓑として廃墟が再利用されてるという話はよく聞くんだけど
例えば検索してはいけない場所で暗がりの長いトンネルには人を死に誘う幽霊がいるぞとか噂や都市伝説で話題になるけど
ついでに言えばそこでよく亡くなる人っていうのはそういう連中に捕まってリンチされたりレイプされたり強盗目的で殺害されたりといった事に尾ひれがついて
ゴーストタウンだって多分国や自治体がしっかり管理してたらゴーストタウンって絶対言わないと思う
でも世界遺産登録に則って反社を追い出したり環境整備をした結果、ゴーストタウンでなく見れる廃墟施設になったんじゃないかな
きっとゴーストタウンっていう建物や廃墟っていうのは誰にも管理されてない放棄地なんだけどそこに悪い人たちが入り浸ってしまって文字通り常人が入れる場所でなくなった
すなわちゴーストタウンだ！という事かもしれないよね。
ホテルのケトルで「カニ茹でた」宿泊客、損害賠償請求される - 弁護士ドットコムニュース
https://b.hatena.ne.jp/entry/s/www.bengo4.com/c_18/n_14410/
このブコメで「おしっこを沸かすやつがいる」という噂が広まっているが、いっぺんでいいから自分でおしっこを沸かしてみてほしい。
その部屋にいられなくなるくらいの臭気を発するぞ。カニを茹でるどころの騒ぎではない。
俺の自宅では冬場はトイレに小さな電熱ヒーターを置くんだけど、ある日うっかり小便をひっかけてしまった。
ありゃりゃ、と思った数秒後には涙が止まらないくらいの猛烈なガスが発生してパンツも履かずにトイレを飛び出さなければいけなかった。
映画『マルサの女』でも、捜査官に自宅を包囲された容疑者が苦しまぎれに玄関で小便を沸かして捜査官を撃退するシーンがある。
「うわっ、ションベン沸かしやがった！」と逃げ出す捜査官のリアクションは、経験者の目から見て納得のいくものだった。
小便を火にかけるとそのくらいの殺傷力があるのだ。
ホテルの部屋のケトルで小便を沸かそうものなら、ケトルのみならず部屋も当分使い物にならないと思う。
常識的に考えて、ホテルとしては一度小便を沸かされたケトルを洗って再利用する選択肢はないはずだ。
少なくとも俺が従業員なら小便を沸かしたケトルを洗いたくはないし、それをもう一度客に使わせようという気にもならない。
それやこれやを考え合わせると、「ホテルのケトルは小便を沸かしたかもしれないから使わない」というブクマカの判断は杞憂にもほどがあるという気がする。
まあ好きにすればいいけど。
そんなことを心配するくらいなら備え付けテレビのリモコンにもっと関心を払ったほうがよいと思う。
男性客がテレビで有料チャンネルを視聴しながら何してるか想像してみ？
ホテルによっては「消毒済み」と書いたビニールでくるんであることもあるが、友達のホテルマンは「してるわけないじゃんw」って笑ってたぞ。
自分もプログラミングとか挫折したけど、環境構築とかドットインストールとかで教えてくれてるのじゃダメなんか？
今はDockerとかでやるんじゃないの？Dockerを使ったこともないし、それが環境構築を簡単にできるものなんだろうという推測でしかないけど
要は、あれって開発環境をいちいちやることによって整えるのが面倒だから、仮想的な環境をいくつも簡単に作ったり、削除したりできるみたいな発想なんだろ
Dockerの前のなんだったかなー、その仮想環境みたいなのドットインストールで最初にやったな
まもなく3月ですね。
しかし、ノートが全部使い切れなかったのに処分するのはもったいない！と思う人も多いはず。
そこで、大学ノートのまだ使っていないページを、どうにか再利用する方法を考えてみました！
もちろん、使ったページを破り、残りのページをそのまま大学ノートとして使うという方法もありますが、
授業や職場などで、そんな半端なノートを使うのもみすぼらしいですよね。
なので、ノートは加工して、書いてすぐ捨てるような形に変えた方が良いです。
作り方は以下のとおりです。
①大学ノートは、既に書き込んだページを破り捨て、白いページだけを残す。
②ノートの長い辺に一枚一枚糊付けし、表紙から裏表紙まで全てくっつける。
③定規を用意して、ノートの表紙に十字に線を入れる。
④押し切りを用意し、その線の通りに切る。
この業界が息苦しいなと感じているものの、この業界に居続けている
トレンドを追うと、高速化や効率化みたいな内容しか出てこない。
自動デプロイだの、描画速度の向上だの、テスト自動化だの、新しいAWSのサービスだの…
一からサービスは作れるし、外部サービスの連携はAPIを見ればプレーンで書ける。
VPSみたいにサーバー用してもらえれば、プレーンで運用も出来る。
でも、プレーンで描くと「車輪の再発明」だの「再利用出来ない」って言われる（幻聴かもしれんが…）
いかにシェア率が高いメジャーなライブラリや方法を使って開発する事ばかり
フロント周りもそう
この世界に入った時は、色々華々しい事ができるって思っていた
実際は、開発環境やらモダンな開発手法やらごった煮なお作法を勉強しないと「トレンドを追え」と鼻で笑われる
フレームワークやらECMAScriptを使わず、プレーンで描いたら白い目で見られる。
そこまで使いこなせて初めて新しい技術を触る権利がある位面倒くさい
追ったら追ったで、「これ今すぐ使う必要なくね？」ってなって勉強の意義を見出せなくなる
今の自分が、コピペで開発で満足していた過去の自分を見たら、自分を説教してくれた先輩のように説教をするだろう
「ブログを鵜呑みにするな、ドキュメントを見ろ」「コードはコピペすんな、書け」「闇雲に手を加えんな、ログを読め」ってね。
ただ、あの頃みたいに、とりあえず作ってブラッシュアップして行こうっていう気持ちが今もあればまた違ったのかもしれない
プログラムは所詮道具なのに、道具の手入ればかり勉強している気がして何か窮屈だなって思う
だけど、その思考で数年やって来たからこの思考から抜け出せない。
プログラムでモノを作るってもっと自由で良かったはずなんだがな…
UQホルダーの終わり方どう思った？
俺は「まあ。出涸らし再利用の割には頑張ったね」ぐらいの気持ちかな。
ぶっちゃけネギまの最終話の頃にはとっくにゲームバランスぶっ壊れて戦闘に緊張感なかったのによくまあ続けたわと感心する。
ラストのカラーページについては……うーん……出馬表明した５０代のオッサンが金髪ロリとのキスシーンをハッピーエンドの象徴にしちゃうかぁ……って気持ち。
これと比べると進撃の巨人は凄いよく終わったね。
捨てきれない思春期の衝動、世界を巻き込む少女趣味、そんな子供じみた激動をそれぞれが抱えながらも、誰かのために幸せのために目の前の戦いに挑むのが人生なんだって終わり方は非常に健康的だ。
俺は赤松健が政治家になるのはどうかと思うけど、諫山創だったら応援できた気がするんだよな。
描いてる漫画の感じでさ。
赤松って結局は若くてキレイで死ななくて強いロリとショタが正しいんだって世界じゃん。
でもそれってリアルの汚らしい老人や年相応にバカなだけのガキとちゃんと向き合ってくれなそうだなって印象があるんだよ。
じゃあどういう漫画家が向いてるんだろうって考えちゃったんだけど答えがでねーのよ。
なんかコレはって戯言を喋って見せてくれよ。
１００文字ありゃお前らなら十分だろ
『ウルトラマントリガー』からニュージェネレーションシリーズを眺めるからの続き
トリガー終わりました。
ブルーレイパッケージに、新型コロナ感染対策のために脚本を８割書き直したという情報があるらしく（未確認）、スタッフ・キャストの皆様大変お疲れ様でした。
なので、内容云々というより、何故こんな企画になったんだ、という憶測を連ねて、トリガーに関しては閉じることにします。
ティガは年数を経ているにも関わらずトップクラスの高い人気を誇っており、物語構成上は再登場し辛い終わり方をしているものの、何かしら再利用したいという思惑が円谷・バンダイ双方にあった筈で、落とし所として、ティガと繋がりのある別世界とされた様子。実際、トリガーの１エピソードで、ティガの登場を望む人がいればティガを召喚できるというご都合設定が作られたので、トリガーの使命は果たされたような（酷い）。
・これからどうするんですかね
額面で言うと 160 万円。40 代男性、外資系 SE、既婚、二子、23 区内戸建て。ボーナス込みで年収は 2,500 万円。この位になると金銭感覚がどう変わるのか、という話をしてみたい。
平均的なサラリーマン家庭よりは裕福な子供時代だったが、いうて金持ちというわけでもない東京寄りの埼玉の家庭で生まれ育った。今の知識と感覚を持って当時の記憶から推測すると、世帯年収は 700〜800 万円くらいだったろうと思う。倹約家の母は、割り箸もラップも洗って再利用するし、油のついた皿を重ねると食器用洗剤の消費が増えるからと怒る、そんな人だった。
新卒一年目の年収は 400 万円強。諸事情があって実家にお金を入れながら会社近くのぼろアパートに住むという貧乏な一人暮らしを経験したりしつつも、20 年以上ほぼ毎年年収を伸ばし続け今に至る。
年収が 1,000 万円を超えた時はすげぇ嬉しかった。…が、同時にこんなもん？とも思った。その時点ですでに二人養っていたからというのはあるにせよ、二倍稼いだら二倍贅沢な暮らしなんて事は全然なかった。年収 400 万円の頃と変わらず、値引きシールの貼られた商品ばかりを狙って買うし、松屋は心の友だった。
年収が 2,000 万円を超えたあたりでふと気付く。別段贅沢をしている「つもり」はない。お得なクーポンを探すのは相変わらず好きだ。でもさすがに五倍稼ぐと金銭感覚が変わっていた。一般に年収 1,000 万円というと稼いでいると思われがちだが、たぶんその一般的な感覚に当てはまるのは現実では 2,000 万円からだと思う。
例えば、
一万円以下は誤差という感覚がある。それ以上は値段に対する価値を吟味するが、値段相応と思えば 100 万円まではすっと出せる。そんな感じ。
あらためて書き出すとずいぶん贅沢な暮らしをするようになったなと思う。子供のころに描いていた裕福な暮らしそのものではないか。とは言え元が貧乏性なもんで、これ以上の贅沢はもはや思いつかない、というかこれより上は値段相応の価値を感じない。例えば高級車とか全然要らない。
仮に年収が 5,000 万円にまでなったらレクサスに乗り換えるだろうか？そんな気はしないんだけど、10 年前は今ほど金銭感覚が変わるとも思っていなかったから、分からんね。もしもそうなる事があったらまたレポートしよう。
【追記】
謎の誰かが勝手に返信つけてるのウケる。持ち家だから家賃は払ってないよ。住宅ローン返済はしてて、その金額は 16 万だから近いけどｗ
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
さ、さよか…
なんかごめんな…
あれをいいかんじになんとかしといて / 小遣い
↓
↓
作業を手順通りに行って結果これを目指して / 生活費・雑費・小遣い
↓
この作業をするために準備と作業をしたら次のために整理を / 食費・雑費・小遣い
↓
ここに決まった準備があるから、これをつかって作業をして、終わったら次の予定のための整理と、おわった作業の確認から次の手順の準備を / 食費・光熱費・固定費・雑費・小遣い
こんな感じでな、分けることができるってことは片づけることができるってことで片づけることができるってことは準備ができるってことかなと思ったわけなんよ…
ってなんの予定も立たないし何が多いのか少ないのかもわからないじゃん…
なんでも出したら出しっぱなしにしてどこにあるか覚えてるから問題ないと言って生活空間まったく共有する気なく再利用性なんかなくても都度いるものとりだせるからいいっていってるやつかなと思ったんよ・・・
食費が多いぞとか、生活雑貨が多いとか服に金かけすぎじゃねとか、趣味なんじゃないのとか言えるってことはそれだけ分けてるってことなんよな
食費にいれてるからとか雑費とか教育研修費用になってるとか、その科目に問題があるのだったら分けてる事じゃなくて用途の話で逆に用途が明確にできてるから指摘もできる
食費→通ってよし ってそれ おなら→通ってよし で漏らしちゃうのと同じで 中身チェックしてないと問題があるのは同じだしむしろ全部小遣いだったら小遣いの内訳をだせってことになれば家計簿と同じことになるじゃん…
トゥギャッターはTwitterの利用規約に基づいて運営されております。 Twitterの規約では、外部サービスがTwitter上のツイートを規約範囲内で自由に利用することを認めており、ユーザーも再利用を認めていることになっております。 http://twitter.com/tos
そのため、ツイート投稿者に許可をとっているかどうかに関わらず、「ツイートをまとめた」という行為自体がTwitter,Togetterの利用規約に違反することはありません。
「ツイートを勝手にまとめられた」という理由のみでお問い合わせ頂いても、利用規約に則った利用の範囲内の場合は運営にて対応ができませんのでご了承ください。
