  |
はてなキーワード: BITとは
なんで０OR１００で語りたがるんだろうな？
マジの頭１BITじゃん。
ミッキーのイラストをAIが出力してディズニーがキレたらアウトだけど、そういうのでもないなら別に問題はないだろ。
市民プールで特定の相手を追いかけながらプールの水を飲み続けるやつは変態だけど、大勢が入ったあとのプールの水を飲むやつはただのバカで終わる。
結局は濃度の違いなんじゃねえかと思うわけよ。
そこで濃度１００を想定した結論ばかり出すのも、濃度０．０００００１を想定した結論ばかりを出すのも、等しく頭悪いとしか思えねえんだよなあ。
A:はい、私はアセンブリ言語のコードを記述することができます。アセンブリ言語は、コンピュータのプロセッサが理解できる低水準の機械語命令に直接対応するプログラム言語であり、CPUの命令セットアーキテクチャに依存するため、異なるCPUアーキテクチャに対して異なるコードが必要です。
以下は、x86アーキテクチャ向けの単純なアセンブリ言語の例です。これは、メモリの特定の場所にある2つの数値を加算して、結果をレジスタに格納するプログラムです。
Copy code
section .data
num1 dd 10 ; Define num1 as a double word (32-bit integer) and set its initial value to 10
num2 dd 20 ; Define num2 as a double word and set its initial value to 20
section .text
global _start ; Declare the entry point for the program
_start:
mov eax, [num1] ; Move the value of num1 into the eax register
add eax, [num2] ; Add the value of num2 to the eax register
mov [result], eax ; Move the value in eax to the memory location "result"
section .data
result dd 0 ; Define result as a double word and set its initial value to 0
このプログラムは、num1の値をeaxレジスタに移動し、num2の値をeaxレジスタに加算し、最後にeaxレジスタの値をresultメモリアドレスに保存します。
文系学問は文系でもできる範囲で発達しているに過ぎないと思う。
物事には理系にしかできない論理構造というのがあって、それが必要なものについてはいまだ解明されていないと思う。
文系の論理はなんというか線条的なんだ。ああなったら、こうなるという論理。雨降って地固まるというような思考様式さえ理解できるなら片がつく。双方向的な論理もあるかもしれないが所詮は一次元のなかでのUターンに過ぎない。
俺はディ二の定理もガウス積分も「理解できない」ことで完全に理系の素養がないと悟った何者かである。
https://mathlandscape.com/dini-theorem/
たとえば上リンクのディ二の定理の説明に使ってるグラフによる関数列の定義が理解できない。
fn（x）についてfn（2/n）=1とは一体どういうことだと言うのか。
xについて解けばn=2のときx=1らしそうだがそれってどういうことなのか。つまり関数列のxを固定して数列としてみたfn(1)についてn=2のときの項は少なくとも1だということになるがそれ以外のnについても項が全く不明ではないのか？
ガウス積分も同様だ。どうしても変数変換のところで理解が追いつかない。rとθが同時に動くような状況を理解しなくてはいけない。高校の置換積分とは理解に必要な脳のスペックCPUでいうならbit数が根本的に違う。
ようするにこれらは変数の数の問題だ。文系の論理は変数でいえば一個の変化を辿っていくようなものでしかない。
しかし理系のそれは二個以上が容赦なく変化するような論理の流れを追えなければ理解が追いつかないということになる。
しかし私のような人間は一つの変数についてたどろうとするとそれ以外の変数に対する考慮がおろそかになってしまうような理解しかできないのだ。
この状況は絡まった糸で例えられるかもしれない。糸の端が外側に出ているという前提であれば、複数の糸がそのように絡まった糸玉に対してある端から辿ってその糸の別の端を探すということはできるはずだ。
理系がやばいのはこの辿るという作業を二つ以上の糸に対して同時に行えてしまうようなところにあるのだと思う。とてもじゃないがワーキングメモリーが足りねえよ。
つまり二つ以上の変数を一挙に思考の範囲内に収めてみんなまとめて辿れてしまうんだ理系ってのは。
応用数学を解いたり、初等的な計算が早かったり、フラッシュ暗算が得意だったりというところだ。なかには理系以上の計算力を持ってる人もいる。
しかし理系もみんなそれなりの計算力はあるのである。大事なのは、計算力があるなら理系であるとは限らないこと。百ます計算や公文式で得意げになってる子供に理系としての将来を期待するのは早計なのだ。
だって俺でもガウス積分を使わなければならない問題でも一定の演習を積めば答えの法則をそれとなく察してパズルのように解けるようにはなってしまうと思うから。高校数学の延長上の応用数学はみんなパズルである。ナンプレと大差ない。パズルとして解こうとする限り計算問題はみな線条的な論理理解力があれば事足りるのである。
しかし原理的な理解がなければ既存の定理を発展させることはできない。
実は文系という人間にありがちと思われるのは、正しく新しい定理を証明までできた気になって得意げになってるか、既存の定理について延々と具体的な数値を代入してみたりして納得を試みようとするが一般的にそうだと言えることについてはついに何度人に教えてもらってもいまいち理解には辿り着けないかのどっちかだろう。
前者は無知の知すら弁えてない傲慢な人間、後者は合理的な知性主義によって既存の知性となんとかすり合わせを行おうとしているがそれができない、という違いだ。
ちなみにツイッターに棲息していがちな、法律の話で独自解釈をしているのにそれに気づかない人間は前者である。
やや急進的な言い方かもしれないが、位相集合を基盤とした数論幾何をはじめとする現代数学と一部の物理以外はだから文系なのである。理論や主張を腹落ちするのに複数の糸を同時に辿れるような能力はいらない。
というかそういう人間しか研究に携わってきてないから、そこから出力される理論もその程度なのだろう。理系の頭をもってしか理解できない領域が人文社会科学にもあるならば、それについてはいまだベールに包まれたままなのかもしれない。しかしなぜか真の理系人間の誰一人として文系学問には進まないか、文系学問において理系脳をフル回転させようとしないのだと思われる。
dorawiiより
hi, i live very close to MSU. I had plans to be at the Union Building that evening to work on some stuff at one of the tables or glass study room things in the basement. it's only be coincidence that I was not there, because I had to go home to fix a computer that had stopped working correctly. I got lucky.
i went there this morning, to the Sparty statue. I was there for a bit.
I hear there's some stuff at the Hannah building, resources, people to talk to, etc. You might consider going there.
StableDiffusion系はbf18,fp16,8-bit adamなどで8GB程度でも動くようになったが、追加学習をしようとすると足りない。
日々HuggingFaceに投稿される言語系AIや音声、言語と画像・動画を組み合わせといったのになると、24GBでは足りない。
80GBで足りないのも出てきている。、
GPUは8枚まで並列に出来るので、80GBx8枚=320GBといったのになっている。
結局チューニングしないとそれほど役に立たず、お高めのパソコンで個々人でチューニング出来るとありがたいのだ。
CXL（Compute Express Link）というメモリ拡張用のバス規格が数年前にでき、製品も出始めている。
今までだとCPUからGPU側のメモリにコピーだったのが、アクセラレータから参照も出来るようになるらしいのだが、今の所サーバー向けらしい。
まぁ手段はなんでもいいんだが、VRAMの容量が増えればいい。
アカデミー賞でウィル・スミスが妻(ジェイダ・ピンケット)の病気の件を馬鹿にされ、プレゼンターのクリス・ロックをビンタした件。
暴力が駄目なのは解る。暴力でやり返さなかったクリスが立派なのもわかる。
でも結果ウィルが処分を受け、クリスがお咎めなしで終わったの納得いかない。
ウィル・スミスがビンタした件、日米で温度差があるのは何故なのか？ アメリカ人記者に聞いてみた | ロケットニュース24
rocketnews24.com/2022/03/30/1616848/
日本に伝わりづらい「ウィル・スミスがビンタした件」について / アメリカ在住日本人の話が目からウロコだった | ロケットニュース24
rocketnews24.com/2022/03/31/1617141/
でも、過去には世界的な晴れ舞台、グラミー賞の授賞式でスティービー・ワンダーの身体の件を馬鹿にしたアンディ・ウィリアムス、数年に亘って司会を務めてきたが次の年に降ろされた。
グラミー賞秘話～こんなことあったの知ってます？ | 侍ヤンキースのブログ
ameblo.jp/samurai-yankees/entry-10205069373.html
1977年の第19回のグラミー賞のホスト～アンディ・ウィリアムス
その年のグラミー賞の目玉の一つは受賞式の当日、ナイジェリアにいて当時としては珍しい衛星中継で演奏を披露する予定のスティービー・ワンダー
しかし、本番中にアクシデントが起った。当時の衛星中継の技術がイマイチだったので「Sir Duke(愛するデューク)」を歌い始めたスティービーの映像や音声が乱れ、途切れ途切れに
で、その時、司会をしていたアンディ・ウィリアムス。～彼がふざけた感じでこんなことを言ってしまったのだ。盲目のスティービーに対し
「Stevie, can you see us now?(スティービー。今、僕らが見えるかい？)」
勿論、その言葉は顰蹙を買い、翌年からグラミー賞のホストはジョン・デンバーに代わった。アンディ・ウィリアムスはその後、謝罪のコメントを発表している。
Grammy TV Show Is Smooth but a Bit Silly - The New York Times
www.nytimes.com/1977/02/21/archives/grammy-tv-show-is-smooth-but-a-bit-silly.html
“The 19th Annual Grammy Awards” have been concocted for the recording industry. The production was flawed with technical difficulties, most notably in an elaborate and expensive live‐via‐satellite transmission of Stevie Wonder from Nigeria.
The picture came through well enough, but the sound was thoroughly garbled. Instead of quickly abandoning the project, the producers kept going back to Mr. Wonder in an apparent bid to recoup part of their satellite investment. A flustered Andy,,Williams. the slick host for the affair, found himself asking the blind singercomposer, “If you can't hear me can you see me?” Mr. Williams recovered with a rapid apology.
note.com/nipponcontext/n/nda946921b305
スタンドアップコメディアンは、アメリカ社会唯一の例外として「何を言ってもいい」という特権が認められている。たとえそれが差別的な言辞であっても
コメディアンならTPO問わずどんな場面でも他人の身体を馬鹿にしてOKなの？
コメディアン自身の舞台でなら許される、ってならまだまあ理解できなくもないが。
世界的にも注目される晴れ舞台、米国スーパーボウルのハーフタイムショーに於いて出演するラッパーはダーティな言葉を差し替えてる、TPOを考慮して。
Dr. Dre, Snoop Dogg, Eminem, Mary J. Blige, Kendrick Lamar ＆ 50 Cent FULL Pepsi SB LVI Halftime Show
youtu.be/gdsUKphmB3Y?t=424
https://b.hatena.ne.jp/entry/s/www3.nhk.or.jp/news/html/20220708/k10013707601000.html
id:hkanemat 安倍は 1 bit も支持しないが、かと言って暴力で排除するのはだめだ。
id:kanjin30203 思想政策はまったく相容れないが、これは明確にテロで認められないだろ…。ていうか銃って何！？この国そんなに治安悪かったっけ？
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!
https://www.nhk.jp/p/bs1sp/ts/YMKV7LM62W/episode/te/XLJ547N44X/
こちらを見て、正直いって、25%ぐらいはいいこといっていたが75%が酷すぎたと思う。
【前提となる自分の背景】
＝＝＝（Nスペ目次）＝＝＝＝＝
＝＝＝（Nスペ目次）＝＝＝＝＝
もう、10年何をしてきたのかという諦めの気分。いま目次を書いてみると、たしかに１時間で
まとめるとこうなるのもやむ無しという気がしてきたが。結局 so whatが無いんよ。
自分が思うso whatは個人単位の戦争をすればいいので「日本で勝負するのは辞めよう」
未だに海外に行かない日本人研究者層が歯石のように積もり積もって自分の首を締めていると思う。
特にドン引きしたのが、ネパールの人材の青田買い。何をしているかというと、「早めに内定を出して日本語教育をしている」
ということ。インド人エンジニアには見向きもされないから、更に安い国としてネパールを選択し、その安物エンジニアを供給
しようとしているようだが、はっきりってその見向きをされていないインド人にどれだけお金を払うかの方が大事。
安いエンジニアは誰も要らない。
わざわざ日本語を勉強してこようみたいなモチベーションのネパール人が使えるわけがない。SIerの下請けにしかこない。
私はカンボジア人のエンジニアと仕事をしていたが、当然英語だし、たしかにコストは安いし、その割に国のトップみたいな
人材だが、その人がわざわざ日本語しかできない人と働くとは思えない。
そういう楽をした内向きの戦い方が全ての元凶だろう。
自分さえどうとでもなればよいという考え方の方が実は日本を救うと思う。いま一時帰国して、この番組を見て
理系人材の扱いが自分の卒業した12年前時点と１bitも変化していないことにショック。
日本の若者がむしろ自分の内向き志向をコロナ等で深めている気がしていることを憂慮する。
松尾豊さんが言っていた「兵站がない」っていう言葉、日本人はとても好きなんだけど、兵站って無限にないんすよ。
僕は国力を上げるにはもう中国化するしか無いと思う。権力への批判機構みたいなのが多少弱まろうが、兵站がない以上
ただし、理系においてはITのような【今トレンドである】ようなものやAIのようなチャラチャラした学問ではなく
、生命科学、物性、宇宙、ITのすべての学問に戦力的集中を行う。
その代わり文系人材、F欄大学などは廃止する。申し訳ないが、これをやらない限り、日本全体が沈下する。
しかし、そしておそらくみんなそれでいいと思っている。なので、そりゃ無理よ。
阪大生命科学の人がオートファジーみたいな研究は芽が出ないから選択と集中を行われては困るというような
言い方をしていた、それは本当にそのとおり。しかし、選択と集中を行わないために選択と集中を行う必要がある。
シャープが選択と集中を進めた結果潰れたのではなくて、選択と集中をしても潰れる流れをせき止めれなかった。
文系の教授のウクライナ情勢での解析の体たらくを見ていてもドン引きする。置きにいったコメント。自分は専門外だからと
小泉特任講師のように画像解析など普通にするべき理系的アプローチも解析もできず、歴史というわかりにくい概念でけむにまくだけで、
この千載一遇の研究結果を元にissueを提言するべきところで何もできていない。
はっきりいって文系という学問がそういう性質があるのはやむをえないがそういう置きに行くことをしていると、当然
なりふり構わない、中国などに勝てるわけがない。日本人全体が苦手なので、玉虫色にしたがって、その結果兵站が
尽きる。当たり前のことである。
1byte=8bitってのはASCII ( *American* Standard Code for Information Interchange)、つまりアングロサクソンの世界制覇の野望であって、我々 ISCII (International Standard Code for Information Interchange) は1byte=10bitのコンピュータを作る! となったとしよう。ISCII仕様のコンピュータはヨーロッパ諸言語の文字、キリル文字などを表現できて (なにせ1byteあたり1000種類の文字が表現できる!) ヨーロッパ、ロシアを中心にバカ売れ、そしてIBMを倒し、ISCIIが世界制覇をする。
実際問題ハードを作る一番基礎の段階では、1byteが何bitであってもよいのだ。統一されてさえいれば。統一されていないと、DRAMやら外部バスやらとの処理の時に毎回変換が入って大変 (なお余談だが、通信の世界では普通に通信路上でエラー検出・修正のために冗長なbitを使う。64b/66b とかでおぐぐりください)。
さて、DRAMは... アドレス線も10本単位で作ればよい(もちろん読み出し・書き込みも10bit単位(あるいは50bitとか？)が最小の幅だ)。アドレス線の数が2べきである必要は... あるのかな。
レジスタとかCPUのワード長もshort=20bit, long=40bitとかになりそう。さすがに30bitは使わないかなぁ。
うーん何か困るかな、何も困らないような気もする。ちゃんとソフトが動くコンピュータ作ったことないただの素人なのだけど、何か見落しがあるだろうか？
--
この本は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を眺めていたら、ハリー・ポッターのゲームが始まるという情報が流れてきた。ゲームなんて10年ぐらいやってなかったけど、リリース日の7/2にインストールした。魔法の世界で私が杖をふって魔法を唱えるのだ。それって夢のようじゃない？
ゲームを始めて気が付いたのはオリジナルストーリーが展開していることだ。
あんなに切望した物語の続きがここにあるということは私を興奮させた。
私はずっとハリー・ポッターシリーズが好きだった。本が出たのは大人になってからで、映像化は社会人になったばかりだった。映像化は想像以上に良い出来栄えで私は幸せになれた。逆に映画から原作に入った人はより深い魔法の世界に浸ることができたと思う。これもきっと幸せなことだった。夢中になった。だけど大人が大声で「大好き！」と言うことはなんだか憚られた。
そして本編完結から12年、（ファンタビはあるけど）本編最後の映画が公開されて9年。世界で一番有名な魔法使いになったかもしれないハリー・ポッター。
2019年の夏、周りでこのハリー・ポッターのゲーム「魔法同盟」をしている人はいなかった。
ソロ活動でコツコツとレベルを上げた。Twitterで見つけた「魔法同盟」をしている魔法使いや魔女の皆さんを密かにフォローした。攻略サイトを見て職業を決め、闇祓いになった。私の中ではハリーの職業というより、闇祓いはシャックルボルトである。（実はつい最近まで「シャックボルト」だと思っていたのだが、Discordのお仲間につっこまれつつ教えてもらった。）
気が付くと砦があり、フレンド機能があった。ソロ活動の私にはハードルが高かった。
一日一回通勤の途中に砦で戦い（もちろん一人で）、デイリー任務をこなした。なにかのイベントでフレンドを作る任務があった。とりあえずTwitterでフレンドを募集した。英語も添えて。サービス終了を前にシンガポールとブラジルとスペインのフレンドたちとは未だにギフトのやりとりをしている。海外のギフトを見るのは楽しかった。それ以外特に交流はないけど幸せになれた。
そんななか、全国の皆さんがリアルで対面共闘をしていることを知った。正直うらやましかった。こちらはソロ活動である。九州の中では栄えている街の砦を見ても緑に光ってなかった。たまに光っていても共闘なんてできるはずもなかった。
有志の人なのか中の人なのかわからない方が書いた攻略のnoteを見るようになっていたので不便は感じなかった。だけど、このゲームはお金にならないのかな、と思う。
マスクが街から無くなり、アクリル板越しの対面は声も聞こえにくく、ソーシャルディスタンスという単語は不必要なコミュニケーションを減らすのに都合がよかったけれど、憧れていた対面共闘からも距離ができた。
福岡のオープンチャットに新しく加わった方々によりDiscordを使いナイトバスで行ける砦で共闘をしていると聞いた。ゲームの仲間に飢えていた私は飛びついた。Discordに登録して何もわかってないのに福岡支部のボイスチャンネルのリクエストをした。何度か使ったけど、定着しなかった。でも使い方を覚えたのは収穫だった。
職場はその頃忙しかった。いつも通り働き、いつも通りイベントを終了させた。読書量が一気に落ちた。読書の時間だった通勤時間にイベントを頑張りすぎたからだ。でも幸せだった。痕跡を集め、それぞれのストーリーを楽しんだからだ。
Discordの隠れ穴にコメントを書き込んだ。ハリー・ポッターの話を、ハリー・ポッターを好きな人としたかったからだ。
『ハリー・ポッターと賢者の石』の4DX上映があったのもこの頃。クイディッチの試合を4DXで観ることができた感動は忘れられない。砦のBGMが、ハリーが初めてのクイディッチの試合に向かう時の音楽だと気が付いたのはこの時のことだ。小さな発見でも幸せになれた。
Discordの全国共闘に誘ってもらった。参加者の皆さんの声が聞き分けられず大変で、戦略もわからずとにかく混乱した覚えがある。後になっても時々話題になるけれど、新しい戦略を試すチームに参加していたのだ。混乱は仕方ない、初心者だもの。でもエリート実績がこの共闘で達成できたらしい。楽しかった。
少しずつ色んな人とおしゃべりができるようになる。隠れ穴での同時上映に参加したのもこの頃だった。テキストでやりとりしながら映画を観るのは本当に楽しかった。ここにはハリー・ポッターが好きな人がたくさんいる。ここほど素敵なところはない。
Discordの全国共闘に時々参加するようになっていく。4月以降は夜の共闘に参加してのおしゃべりが楽しくてついつい夜更かしするように。
少しずつ砦の戦術にも慣れていった。戦いながら会話することもできるようになった。慣れたら博多弁が出た。恥ずかしかったけど、みんなもっとおしゃべりしてくれるようになった。夏は夜な夜なアイスクリームのオススメを話した。アイスクリームと違って、袋入りカキ氷は水なので太らないと信じていた。ものすごく楽しくて、ありえないほどはしゃいでいた。ほぼ毎日セブンイレブンにお世話になった。主にアイスクリームとカキ氷を買うためだ。
「ハリー・ポッターと魔法の歴史」展の日本開催のニュースが流れ、神戸会場に行ってついでにUSJにも行ってみたいと思ったけれど、やっぱり私は一人だった。
行きたいなってTwitterに書き込んだ。そしたらなんと共闘でご一緒していた方々からお誘いがあった。ゲームで知り合った人と会っていいのか、迷いはあった。けれど、好奇心には道徳がないのである。なによりとても嬉しかった。そして実際お会いしたらめちゃくちゃ楽しかった。この時、神戸のポートタワーの砦で共闘した写真を撮ってTwitterに投稿した。お気に入りの一枚だ。コロナ禍で決行に迷いもあったけどその旅は、楽しかった！で言い表せないぐらい濃密で幸せな時間だった。歩きすぎて筋肉痛も腰痛も今までに経験したことがないレベルだった。ついでに熱中症にもなりかけた。
毎晩のようにおしゃべりしているのに、一度お会いしたらもっともっとおしゃべりしたくなった。他にも会ってみたい人が増えた。
突然のサービス終了のお知らせ。まだまだ楽しい計画が待っているのに。
私はさよならをどう言えばいいか分からない。言葉が出てこない。
だけど私はたくさんの幸せを「魔法同盟」からもらった。本や映画やゲームの中の魔法は現実の世界でも「幸せ」という形で存在する。
次はみんなで丸の内を素敵なクリスマスの魔法で包むのだ。それは私のたくらむ“よからぬこと”の一つ。
まだサービス終了までひと月と少しある。
レゴを使ったストップモーションの映像と、ファミコンのようなサウンドのBGM。こんな映像作品を、Youtubeで見かけたことがないだろうか。
「Rymdreglage - 8-bit trip」ーhttps://www.youtube.com/watch?v=4qsWFFuYZYI
この映像を作ったのはスウェーデンの二人組バンド、Rymdreglage。音楽と映像とゲームをこよなく愛する彼らが送り出す素晴らしい作品群は、彼らのYoutubeチャンネルにて鑑賞することができる。
彼らの作品は度々メディアに取り上げられるものの、日本語ではもちろん英語でも彼らにまつわる情報が出てこないため、かなりマイナーな存在だ。しかし、恐ろしいほどに手間がかけられた映像と音楽は、メジャーにはなりえないかもしれないけれど、誰かの心に深く刺さるかもしれない。このまま人の目に触れないのはあまりにも惜しく感じるので、勝手ながら、場末のネットコミュニティで彼らの作品を紹介することにした。
Terminator 2 - 20 years ( July 3 1991 - July 3 2011)ーhttps://www.youtube.com/watch?v=a4mWyeVitNQ
ターミネーター2の20週年を記念し作成された作品。Eテレの番組「テクネ 映像の教室」にて取り上げられた作品でもある。色付きの画用紙にターミネーター２の名場面が描かれ、溶け落ちるロウソクと積み上がる紙くずが途方もない時間を演出している。
Rymdreglage - Insert Coinーhttps://www.youtube.com/watch?v=0sNxRji1STg
アーケードゲームを題材にした作品。コインがヌルヌル動く映像を演出する様は圧巻。Rymdreglageの、ゲームへの愛に溢れる作品となっている。
Rymdreglage_Kallbrand ー https://www.youtube.com/watch?v=QcvnDNPbsOo
Rymdreglage_Kallbrand_inst ー https://www.youtube.com/watch?v=plGRtq6jVF8
80年代の様々なゲーム映像をレゴブロックで表現した作品。もしかしたら、あなたが昔遊んだことのあるゲームもあるかもしれない。本家とインストで2種類の動画が公開されているが、どちらも別の映像となっており非常に手が込んでいる。
その他にも、ユニークで面白い作品はたくさんある。よかった見てみてほしい。
Rymdreglage - Respawn ー https://www.youtube.com/watch?v=nhJj13iChCk
Rymdreglage - Old days ー https://www.youtube.com/watch?v=ohlQczU45SA
また、彼らの音楽作品はAmazonミュージックやSpotifyなどで絶賛配信中だ。
Rymdreglage公式サイトーhttps://www.rymdreglage.se/
恥ずかしげも無く、同じネタで煽り文だけ変えて複数投稿できる感覚、スゴイと思う（憧れないけどw）
●携帯番号「090」はおっさん!? 新たな“おじさん認定”にショックの声…番号の割り当て方を総務省に聞いた（午前11:40 · 2021年5月30日）
https://twitter.com/FNN_News/status/1398831762961145857
●若者からおじさん認定されるのは、最近はその人の言動だけではなく、#携帯 のある番号でも言われるという投稿が話題になっている。
「『携帯番号が090～はおっさん』という若者の発言を聞いてa little bitショックを隠せない」と投稿したのは、げどすら（@gedoslime）さん。（午後4:16 · 2021年5月31日）
https://twitter.com/FNN_News/status/1399263447712296961
●この投稿に「090」番号と思われるTwitterユーザーから「大ショック…」「私おっさんだった」と同じくショックを受けたというコメントが多く寄せられた。なぜ「090」や「080」で始まる携帯番号があるのか？携帯事業者に番号の配布などをしている #総務省 に話を聞いた。（午後4:16 · 2021年5月31日）
https://twitter.com/FNN_News/status/1399263557766639620
●番号として違いはないが、あるとするとそれぞれ携帯電話への指定時期が異なる。番号は数に限りがあるので、少なくなると新しく番号を追加している。070は最初PHS用だったが、現在ではPHSと携帯両方で使用され、080は、02年指定当初から携帯用として利用されています。（午後4:17 · 2021年5月31日）
https://twitter.com/FNN_News/status/1399263632135835652
●「090」で始まる #携帯 番号は約20年前から使われており、解約後の再利用もあるが、基本的に空きがないため「昔から番号を変えていない人が多い＝おじさん」となったようだ。一方で、「090番号がうらやましい」などと希少性を感じる若者がいることも興味深い。（午後4:17 · 2021年5月31日）
