  |
はてなキーワード: Sorryとは
シアトルの高校に1年半通ってた。当時その高校にはアジア系は何人かいるけど東アジア系はいなかった。今は中国系の生徒がかなり増えてると思うが。
当初友達がいなくて基本一人で過ごしていた。挨拶すれば返ってくるし、大多数は普通に接してくれる。けれどまあ人を揶揄うのが好きな奴がいるわけだ。アメリカのいじめっ子は基本的にいじめられっ子を無視しない。積極的にいじめる。最初は吊り目のジェスチャーをされたり、教科書を投げられるくらいだから無視してた。いじめ集団がいなくなると比較的大人しい男女が「気にするなよ」みたいな感じで言ってくる。
ある日カフェテリアで一人でご飯を食べてると、いつもの白人四人組が来て俺のトレーをひっくり返した。宙を舞うマッシュポテトとベーコンとスクランブルエッグ。その時たまたまイライラしていたのもあって、ひっくり返した奴を思い切り殴りつけて背負い投げした。柔道は小学生の時に習ってただけだけど、向こうの背が高かったから投げやすかった。そして「Are you fucking kidding me? I’m gonna fucking kill you!」みたいな感じで喚いた。やり返してくるかと思ったけど向こうは「sorry！sorry！」と繰り返して去って行った。
そのあと冷静になり、これは嫌われたかな、とショックを受けていたんだけど、その逆だった。次の日からみんな向こうから挨拶してくれる。人目を気にしながら話しかけてくれてた大人しい男女たちも明るく話しかけてくれるようになった。いじめっ子の奴らも何事もなかったかのように「週末にDanの両親がいないからパーティーをやる。来ないか？」みたいに絡んでくる。その後の生活は比較的平和だったが、よくわからない国だなと思った。
https://b.hatena.ne.jp/entry/kaigainohannoublog.blog55.fc2.com/blog-entry-4291.html
https://www.facebook.com/reel/389380193304358/
関連度の高い順で上から
.
.
.
.
.
.
.
.
インターネットにおけるゲーム攻略ページは個人の攻略サイトから始まり、2000年代中盤では2chの攻略スレ上の有志などが運営する攻略wikiが盛んに作られた。
しかし、このようなサイトで広告収入が得られる事がわかってからは攻略wiki同士の潰し合いが始まり、その結果有志による攻略wikiそのものが衰退していく。
そして2010年代、インターネット上のゲーム攻略情報業界を支配したのはGameWithをはじめとする企業運営による攻略wikiであった。
これは攻略wikiを標榜しつつも他のwikiから情報を盗んでくるなど様々な問題・トラブルが起こったが、現在のゲーム攻略wikiの最大勢力となっている。
近頃では有志のwikiも昔ほどの勢力を持っていないが、それとはまったく別の系統の攻略wikiが存在することがわかったため報告する。
ふたばちゃんねるの二次裏の住民によって作成されたと思われるwikiをこの記事では「ふたば系攻略wiki」と呼ぶことにする。このwikiにはいくつか大きな特徴があるため以下に説明する。
ふたば系の攻略wikiは伝統的にwiki作成が提起されたスレッド上でレスNoのゾロ目を最初に取ったレスの内容をwikiの名前とすることが慣例となっており、基本wiki名を知らなければたどり着くことができない。
例えば「ウマ娘 wiki」のように検索しても検索結果には表示されない。これは外部の閲覧者の流入を防ぐ検索避けの意味合いもある。
ただしマイナーなゲームの場合検索避けの役目を果たせず、後述する問題が発生することとなる。
wikiwiki.jpは比較的管理機能が充実しており、利用者も多いため記事作成のノウハウを知っている利用者が多いためよく利用されるという。
トップページはワードアートやmarquee(すでに非推奨になっている動く文字のためのHTMLタグ)で彩られ、
内容も「Sorry! This site is Japanese Only!」やアクセスカウンターとキリ番報告、「時間ねぇ～」バナーなどの
90年代末期から2000年代初頭の日本のインターネット文化を意識した内容であることが多い。
これは二次裏住民の主要年齢層が30代後半から50代でありその時期のインターネット文化に親しみがあるためであるそうだが、
単に他のふたば系wikiがこの体裁であるためそれを真似しているだけというパターンもあるという。
ＡＢＡＢ
ＣＣＢ
＋)―――――
ＣＢＡＤＢ
これはギンガ算と呼ばれる特殊な覆面算であるが詳細は割愛する。
ギンガ算を表現する方法はwikiによって様々だが、概ね対象ゲームのキャラ画像などを使って表現されている。
例として「攻略対象ゲームとは無関係のゲームの攻略記事」「元ネタ一覧」「実装されていないキャラクターの攻略記事」「対象ゲーム筐体が置いてあるゲームセンター周辺のグルメ情報」がある。
ゲームとあまり関係無いものも多いが読み物として面白いものが多い。
二次裏は画像掲示板であるため、スレッドを立てる際原則画像が必要となる。
二次裏、特にimgでは怪文書と称する二次創作SS作品が投稿されることがある。
それらを保管するページが設置されていることも多い。
上記の通り検索性の低いwiki名であるためこれまではあまり外部に見つかることがなかったが、マイナーなゲームの場合では状況が変わってきている。
企業系攻略サイトはアクセス数(≒広告収入)の少ないマイナーなスマホゲーの攻略を放棄してしまうことが多い。
完全に更新を放棄するパターンと最低限の情報のみを更新し続けるパターンの2通りがあるが、
どちらにおいても情報精度が低いにもかかわらずGoogleの検索結果には残り続けてしまう。(ページごと削除されるケースも少ないがあるらしい)
さらにそのようなゲームであると2ch発の有志wikiにもユーザが集まらず、更新も頻繁には行われない事が多い。
そこでふたば系攻略wikiが注目されてしまう。そのような場合は「ゲーム名 wiki」で検索した結果でもふたば系攻略wikiが上位に表示されるようになる。
上述した異様なwiki名とトップページ、謎の内輪臭、不可解なジャーゴンで埋め尽くされているにもかかわらず攻略情報としては貴重であり
外部のユーザーも参照せざるを得なくなるため必然的にwikiに外部のユーザが流入することになる。
このような場合従来はwikiを放棄(爆破と呼ばれている)して新しいwikiを作るパターンが多かったが、
まともな最新攻略情報が載っているwikiがふたば系攻略wikiにしか存在せず安易に爆破できなくなってしまったwikiもすでに確認されている。
俺はさっきまで知らなかった。これはやばすぎるので増田に書いて広めようと思う。（追記にも書いたが、公式の英語字幕があるので聞き取れなくても心配しないでほしい。）
リンク先を見ればすぐ分かると思うが、驚くべきは、カバーしている分野の広さだ。アメリカのMOOC(Udacityだの、Udemyだの)は、表層的な、「すぐ使える技術」の講座ばかりで、オペレーティングシステムやコンピュータネットワーク、あるいは偏微分方程式や代数学といった、コンピュータサイエンスや数学等の基礎学問のような分野はあまりカバーされていない。（主観だが、恐らく正しいはずだ。Udacityのジョージア工科大のコンピュータサイエンスの授業は別だが、数は少ないし、それにしても数学はカバーしていない。）
しかし、この「NPTEL」では、自分に関わりのあるコンピュータサイエンスや数学等の基礎学問だけでも、合わせて400近い講義が公開されていて、10個ほど目を通してみた限り、どれも良質な授業だ。
後、自分にはよく分からないが、航空力学系の授業で、ミサイルについての授業もあるようだ。（ビデオ講義でないのが残念だが、斬新な授業だ。日本でもこういうのあるのかな？）とにかく幅広い。
自分はジョージア工科大のオンラインのコンピュータサイエンスの修士コースに入れたらと思い、英語の勉強も兼ねて無料公開されているジョージア工科大の授業を見ていたが、公開されていない授業も多く、そのうち教材が尽きてしまうのを心配して色々あさっていたらこのサイトを見つけた。このサイトがあれば教材が尽きる心配とは無縁でいられそうだ。(TOEFL ibt90点が必要とされるそうで、自分の実力的には（受けたことないが恐らく）いいとこ50-60くらいだろうと思っている。(40-50かも)90を取るのには少なくとも5年くらいはかかりそうだし、教材が尽きないかが心配だった。頑張るぞー。）
プログラマだからだろうが、コンピュータサイエンス系の授業はとにかく面白い。いくらでも聞けるので、英語学習には最適だ。残念ながらゴールデンウィークは終わってしまったが、はてなの皆もこういうの好きだと思うし、見てみたらどうだろうか。
旧帝大の数学科出身の準委任で派遣される量産型雑魚プログラマ(27歳)で、社会に出てからは、「すぐに役に立つ」技術ばかりが要求されて、うんざりしていた（それもとても大事だけど。）が、久々に基礎学問の面白さに触れられてとても嬉しい。インドが好きになった。日本もこういうのすればいいのになあ。（インドみたいに全部英語で。）
やっぱりコンピュータサイエンスの基礎はプログラマなら誰にでも必要だと思うんだよね。
ただ、基本的に誰でもアカウント登録さえすれば試験を受けたり成績証明をしてもらったりは出来るようだが、試験会場は基本的にインドみたいだから、日本だと成績証明は難しいのかもしれない。日本のユーザーが増えて日本でもできるようになったらいいな。
ー＞追記。コメントによると、もしかすると東京でも試験は受けられるのかも。もうちょっと調べてみます。(どこで試験を受けるにしても一定の(5000円くらい?)の受験料は必要みたいだけど。)
後、アカウント登録をしたはずなのに、「Sorry, Your email id doesnt matches our record!」と出てきてログインできない。なんでだろう。そのうちサポートに問い合わせしないとな。
インドパワーを感じた一日だった。
・NOC:Introduction to Operating Systems
https://nptel.ac.in/courses/106106144
である。（コメントにリンクを張ってくれた人ありがとう。確かにリンクも張っておいたほうが良いですね。）
更に追記
ちなみに、英語が聞き取れなくても心配しなくてよい。自分も半分くらいしか聞き取れないが、多分全部の動画に公式の英語字幕(NPTEL-Officialと書いている。)が付いているので、それを読めばよい。
リスニングの練習も兼ねているので最初の1,2週くらいは頑張って聞き取ろうとはしているが。
それでも分からない場合は字幕を手打ちしてDeepL翻訳を使おう。（自分もちょくちょくそうしている。）
ー＞あ、コメントにある通り、動画内だけでなく、動画の真下にも英語字幕は表示されてるんだった。手打ちしなくてもいいね。
ー＞NPTEL-Officialと書いてある字幕設定でも、英語にならないことあるな。後、動画の真下に英語字幕が必ず表示されているわけでもないみたい。ただ、何かしらの形で英語字幕を表示させることは多分流石にできるはず。動画ごとに色々いじるしかないな。
ちなみにNPTELというのは、「National Programme on Technology Enhanced Learning」の略みたいです。なんて呼べばいいんだろ。勝手にエヌピーテルと呼んでたけど。
https://24tv.ua/ru/rossija-obstreljala-tc-kieve-iz-za-foto-voennoj-tehniki-sdelannyh_n1914418
ロシア、キエフのショッピングモールを砲撃＝隣家から撮影の軍備写真で-AFU
AFU(参謀本部戦略広報室)は、ロシア軍がショッピングセンターを破壊した原因について説明した。
AFUは、キエフのレトロビル(訳注:ショッピングモールの名前)が破壊されたのはウクライナ軍の装備の動きを窓から撮影した人がいたからだと指摘した。
また、その人物の運命は不明だが、撮影された窓の運命はすべてわかっている-もう存在しないのだ、と付け加えた。
人命を損なわないため、軍隊はウクライナ人に対してウクライナ軍の装備を撮影しないこと、その動きを伝えないことを呼びかけた。
夜遅く、ロシア軍がキエフのポディルスキー地区のショッピングセンターを砲撃したことを思い出してほしい。敵の攻撃により、8人が死亡した。
"Police found a man who uploaded that video"
"'Kyiv Operational' Facebook group uploaded a video which shows a man named Pavel Artemiev, who confessed in uploading a video in internet where a moving of military trucks of Ukraine's army could be seen.
「キーウ作戦」というFacebookグループにウクライナ軍のトラックが移動する様子をアップロードしたのはPavel Artemievという男性だった。
"Those trucks are near Retroville Mall", said the man.
「Retrovilleモールの近くにトラックが数台あった」と男性は言い、「私は過ちをさとり、この事態を引き起こしたことを悔いている」と続けた。
彼はウクライナ人にこのようなこと(ウクライナ軍の動向を映した動画のアップロード)をしないよう強く警告した。
Artemiev added that he understands his mistake and said that he's sorry for what it caused. He strongly advised ukrainians against doing the same stuff (uploading a video with moves of ukrainian army).
He was detained by ukrainian police, and is in custody now."
前半は機械翻訳(露日)、後半はそれでは意味不明だったため人力(露英→英日)
.
おまけ
友達「2014年のときは確かにウクライナから移送された人たちを見たし、移住先の住民が彼らについて話しているのも聞いた。
だが今回そのようなものは全く聞いていない」
増田「まだたどりついてないだけじゃないの？」
友達「それは知らない」
増田「https://www.tokyo-np.co.jp/article/168311
『住民移送の事実はロシア側も認めている。極東メディア「サハリン・インフォ」（電子版）は13日、侵攻前後にシベリアや極東に移送された東部2州の住民は、ロシア政府の公式データだけで約9万5000人に達すると報じた。』と書いてあるけど……」
増田「（使えねえ）他にはなんかある？」
友達「普通のショッピングモールを空爆したと報道されているが、あれは軍用車両の隠し場所だった。写真もある」
増田「合成じゃないの？」
友達「ウクライナ市民が撮ってSNSに上げた写真に偶然写り込んでいたものだ。ロシア軍は当初こういうものを情報源にしていたが、ウクライナが写真をみだりに上げることをやめさせた」
友達「1週間ほど前にtwitterで見たがもうどこにあったか忘れてしまった。有名な写真でもない」
増田「（使えねえ）」
友達「あった。ショッピングモールの隣から撮られているhttps://24tv.ua/ru/rossija-obstreljala-tc-kieve-iz-za-foto-voennoj-tehniki-sdelannyh_n1914418 」
増田「おー」
『ウクライナは救急車を兵士の輸送に使っている』アルジャジーラ」
増田「（スクショじゃなくて元ソース貼ってくれよ）へー。ロシア軍の戦争犯罪のうちどれくらいにそういう疑問点があるんだろう」
友達「４割か５割くらいだろうと思う」
友達「マリウポリにいる友人は、普通の人家のすぐ近くで軍事車両を見たと言っていた。その後彼とは連絡がつかなくなった」
増田「そう」
友達のチャット原文はほぼ英語なので増田が訳しています。（増田はもともと日本語でチャットしていました）
もし友達に言いたい・聞きたいことがあれば書いてください。ロシアとネットがつながっている間は代わりに尋ねて回答を載せるつもりです。
https://24tv.ua/ru/rossija-obstreljala-tc-kieve-iz-za-foto-voennoj-tehniki-sdelannyh_n1914418
"Police found a man who uploaded that video"
"'Kyiv Operational' Facebook group uploaded a video which shows a man named Pavel Artemiev, who confessed in uploading a video in internet where a moving of military trucks of Ukraine's army could be seen.
"Those trucks are near Retroville Mall", said the man.
Artemiev added that he understands his mistake and said that he's sorry for what it caused. He strongly advised ukrainians against doing the same stuff (uploading a video with moves of ukrainian army).
He was detained by ukrainian police, and is in custody now."
DeepLで翻訳してみた
The main issue...the bid price has been reaching ¥80/kWh every day since the beginning of the year.
I can finally get into what I really want to tell you.
The reason why new power companies have stopped accepting bids or have withdrawn from the business is because the days when this JEPX spot market price reaches 80 yen/kWh have been going on and on since the beginning of 2010.
The electricity market is a market. If there is a surplus of electricity, the bid price goes down, and if there is a shortage of electricity, the bid price goes up. The spot market is a blind single-price auction, which means that once a contract price is determined, all market prices are traded at that price. Even if Masuda-san bids 10 yen, if many people bid 20 yen, it will be 20 yen, and if many people bid 5 yen, it will be 5 yen.
And as I said before, if they fail to purchase, the power retailer has to pay the imbalance fee.
Then what happens? Many people think, "I'm going to buy it at the imbalance fee of 80 yen/kWh anyway, so I'll bid 80 yen for it. Here is the URL of Enexchange's website, which shows the spot market price in an easy-to-understand manner.
https://insight.enechange.jp/markets
For March 31, it's in the 20 yen range. That's bright red. It is cheaper than the 80 yen I mentioned earlier.
Imagine this. TEPCO's Standard S plan is 20~30 yen/kWh. You see, what we sell for 20-30 yen, we have to buy for more than 20 yen, or even 80 yen.
How much is the gross profit on something that sells for 25 yen? 8 yen, 5 yen, 3 yen? Let's assume that 90 out of every 100 jobs generate a gross profit of 5 yen, which is a profit of 450 yen. If 10 out of 100 sell at that price, the profit is 550 yen.
450 - 550 = -100.
This is the impact of a spot market price of 80 yen. Imagine if you had a customer base of tens of thousands of dollars, and you have to blow millions of dollars every day for a month. I think you can understand a little bit of the logic behind the suspension of acceptance and shutdown of business.
Of course, calculating the cost of procuring electricity is not this simple. I mean, I can't write about the inside story of procurement in my business because it would violate confidentiality. I wrote what I could find out just from the spot market, where the amounts are visualized by the general public. I didn't tell the whole story, if you think about it. Sorry. It's a title fraud.
Supplement... why is this happening?
To be honest, even as someone in the new power company, I am troubled by this situation. How did this happen? ......
In essence, I think "don't liberalize the infrastructure in the first place" is right. However, to put some position talk into it, I think that the various things that happened in the aftermath of Fukushima and the licking at the Kashiwazaki nuclear power plant were the result of being lenient because it was infrastructure, and I think there is some nuance to that.
However, I don't think that the designers of the system anticipated this level of instability in the power supply when the system was liberalized in April 2004. I was impressed when the supply-demand crunch warning came out. I was like, "This is it! That rumored ！！！！ Supply and demand crunch alert: ！！！！！！！" I was so excited. There's no way there's going to be rolling blackouts! It's about to happen!
However, in the extreme, retailers are wholesalers, and while they are wholesalers, the products they sell are not all that different. How can you make a difference in a commodity like electricity? It is usually impossible. It's hard to add value to a product because it's all about price. Of course it's not impossible. There are plans, decarbonization, optional services, and so on. But there is no difference in the electricity itself. I think it's possible to point out that the reason why various new electric power companies flocked to the market was because hyenas gathered in the industry that was assured of a sweet deal in infrastructure ......, and that's true for a percentage of the population. I think all electric power companies are looking for ways to add value to electricity.
I hope this case will make the market healthier.
Incidentally, there is a new electric power company that is getting a tailwind from this current situation. Where is it? The answer is after the commercial!
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
海外ニキ１「オーマイガー、Hatenaは俺達がマシーンだと思ってるみたいだぜHAHAHA」
海外ニキ２「ジャパニーズは忍び過ぎてヒューマンが存在しないから理解できないのかもしれないぜ」
海外ニキ１「オーマイガー、目が細いからちゃんと見えないのかも知れないなHAHAHA」
海外ニキ２「ニキ、それは何が面白いんだい？僕らはチャイニーズのことは大好きだよ？」
海外ニキ１「Oh.So Sorry.目を凝らして見ているから逆に見えづらいのかも知れないと言いたかったんだ、シノビは調査するのが任務だからね」
海外ニキ２「オーそうだったのか、てっきり僕はキミがクソッタレのレイシズムに手を染めたのかと思ってしまったよ。そうなるとこれは不味かったかな、一応母国の被差別団体に君の発言とHatenaの暴挙について相談したんだ。もしかしたら、君の家の方に調査の手がくるかもしれない。すまない。本当にすまない」
https://www.youtube.com/watch?v=11akhGr3lJQ
こういうコメントがちゃんとあって安心したわ。（下のは若干わざとらしいが）
Kim King
5 日前
I'm a Chinese and most of us were ashamed of this match. Sorry to 木村翔!
李寻欢
5 日前
我是一个中国人，这场比赛在中国引起轩然大波，影响很坏，百分之九十以上的中国人都在骂玄武，我们感到很丢人，中国只有很下层的人还有反日情绪，很多有正确价值观的人都很佩服日本的文明礼貌，科技发达，很多很多地方值得我们去学习，我只是一个中国普普通通的人，但请允许我在这里说一声对不起，请木村翔和他的粉丝原谅。
しかしそんな人たちでも、なんらかのトリガーで臓器ぬいたり反則技つかう人間にコロっと変わってしまう、簡単に反社になってしまう。
金のためだったり、家族のためだったり。
その前はこうだ
[PUMBAA]
I'm a sensitive soul though I seem thick-skinned
And it hurt that my friends never stood downwind
And, oh, the shame!
[TIMON]
[PUMBAA]
Thought of changin' my name!
[TIMON]
Oh, what's in a name?
[PUMBAA]
And I got downhearted
[TIMON]
[PUMBAA]
Everytime that I...
[TIMON]
Hey! Pumbaa! Not in front of the kids!
[PUMBAA]
Oh. Sorry...
くせえって言われて落ち込んだ、それ以来俺はいつも、、、のところで止められる。
いつも屁をこくとき？
いつもクソをするとき？
なんか性的な意味でもあるのかと思ったけどディズニーだしそういうんでもなさそう。
どういうこと？
