はてなキーワード: パッケージングとは
半導体の設計に必要なものとしては、人によって分け方に意見があるだろうが、ここでは下のように分ける。
1チップ作るのにソフトライセンス料金で数億かかる時代になっており、それだけ売上が見込める市場がないといけない。
またEDAソフトの使い方はGoogleで検索すれば出てくるものではないため、人材育成に時間がかかる。
先端ロジックを使うゲート規模になると最新のインテルサーバーを買ってきても時間がかかる。
クラウドもEDAベンダー的には今では対応しているが、クラウド代金も馬鹿にならない金額になる。
ただEDAソフトを使いこなせば性能が良いチップが出来るかとそういうわけではなく、製造してどこまでだったら動くのかギリギリを攻めないと競争に勝てず、
プロセス知識が必要になる。ファブレス企業を立ち上げただけで勝てないのは、そのあたりにあろう。
(米国のファブレスは人材の流動性やら、お金と規約で殴っているので解決できているはず)
差別化の為の設計をしようとするとツールが対応してないと出来ない。
国内で設計ソフトを持てなかった時点で駄目だったのかもしれない。
工場と装置を持ったとしても、そこで製造するチップがなければ意味がない。
かつ工場に継続的に投資をし先端を維持するには、製造するチップが扱う分野が成長市場でなければならない。
Googleはサーバー分野だと、速ければ速いほどよく大量に持てばよく、自社で使えない分は社外に開放して稼げるので、
車はあるが、要求スペックが高いわりに数が売れなかったり、単価交渉で車メーカーに負けていたりと、ババを引きたい企業しかやりたくない。
兎にも角にも、わざわざ半導体を作る必要があって、かつ数年で次世代半導体が必要になるような、
そんな針の穴を通すような成長分野を見つけないことには、日本の半導体復活は起こらない。
CPUやGPUやAI向けのような汎用計算用に乗り出すのが手っ取り早いのだが、
CPUやGPUの種類以上に日本で作っていた半導体は種類が多い。
日経などで少量多品種絶賛されていて、客の要望に合わせて機能を組み合わせた物を作った。
ある一部の顧客しか使わないような種類のチップをわざわざ切り替えるほど工場に余裕がない。
そしてそういう顧客が高い価格で買ってくれるかというとそうではない。
機能が多すぎるので、ウチの製品にしか使わない機能だけのチップにして安くしろ、という要望に答えたものだからだ。
Appleですら先端ロジックを使うとなると、M1を複数カテゴリーに投入といったように、
設計に金がかかりすぎて出来ない。
グローバルで馬鹿みたいに個数が売れるApple製品ですら、そんな状況だ。
半導体業界は実務で何をしているのかわからない、というのが殆どではないだろうか。
人手が必要だが、教育するための教科書も、これを読んでおけばひとまず業務が回せるようになるといったネットの記事もない。
このあたりの整備も必要ではないだろうか。
第一話
そんな表現なんだと思うけど、突然姫様がバーンと全裸になってエクスタシーを感じる描写が差し込まれるんだよ
いや、なんでやねん
一話だけかと思ったら、第二話にも似たような表現が出てくる
結局こういう描写で強い違和感を感じ、単行本の購入には至らなかった
なんならAsh横島みたいな、ちょっとエグいぐらいの性描写が大好物ではある
だけど、あれはハナから「エロ漫画です!めっちゃエロいです!」ってパッケージングがされてるから、こっちも心構えが出来ているわけだけど
「姫様”拷問”の時間です」に関しては、萌え要素のあるギャグ漫画の感じで、設定もネタもしっかり面白く
いや、確かに
悪役の女看守のパイオツがやたらデカい時点で、ん?とはなったよ (っていうか、そういうアザとさも本当は嫌なんだが)
でも、今日日こんなキャラデザで一々引っかかってたらもはや漫画なんて読めないわけでさ
だけどさ、ギャグ漫画の主人公の女の子がいきなり全裸になってエクスタシー感じ始めたら
流石にそれはさあ、違うじゃん
そう思ってしまった
ちょうど車の買い換えの時期が来るな、と意識したのが令和3年の8月。何かと維持費がかかる某輸入車が精神衛生上よろしくなく、たまたまティザー広告が目に付いたNXに乗り換えた。今回が初めてのレクサス車である。最近の半導体不足やプーちゃん大暴れにより随分と納車は遅れたが、先日なんとかうちのNXは納車された。しかし、現状としてもっと長くかかる方が多いようである。
自身のSNSアカウントであれこれ書いてもいいんだけど、何かとNXについて発信する車好きのアカウントは変な人が多い、というか、レクサスのファンに変な人が多い。既に納車された層も変な偏りがある印象で、普通の人間によるものとみられるレビューが少ない。絡まれたくないし、言いっぱなしにしたいこともあり、匿名ダイアリーに記すことにした。正直に言えば、せっかく新車を買ってウキウキしているので何か言いたいだけだし、こうやって何か書く私も彼らと実際変わらない。
ただでさえまとまりに欠けるので、いくつかの項目に分けて記載したい。なお、納車3週間目の感想である。長期はわからん。
これから購入を検討される方が知りたいであろうオプションに関することは後半に記載するのでスキップを推奨する。
購入グレードはNX350h AWD Ver.Lである。なお、特定を避けるためボディカラーの記載は避ける。
#デザイン
もともと個人的に見た目は欧州車趣味なのだが、今回のNXは十分に食指が動いた。先行受注のため実車を見ずに広告やカタログのみで評価して購入したのだが、国産車にありがちなガチャガチャ感(例えば、トヨタならどこかのプリウスからのヤンキー顔、ホンダなら少し前のガンダム顔)が和らぎ、詰め込まれる要素の数が小さくなったことにまず驚いた。先代のNXはヘッドライトの下の「隈取り」的なウインカーが頗る嫌いであの(クソダサい)アヴァンギャルド顔から見向きもしなかった。あれを欲しいと思ったことは今も含めてない。今回もフロントグリルは過剰なインパクトがあるが、ヘッドライト内にだいたいの光る物は収まり眺めたときの視線が散らず落ち着いた印象になった。また、線よりは面の構成が主になったことでゴロンとした、金属の塊から削り出されたような存在感のあるデザインに変化した。スピンドルグリルは残ったが、アイコンとしての機能は十分で、全体的に「良い取捨選択がなされたな」と思った。車の印象というものはボディカラーによって大きく変化するので納車されるまでは不安が大きかったが、初見でそれは吹き飛んだ。ちゃんとかっこいいのである。なお、ここまで書いたらおわかりかもしれないが、グリルの加飾が好きではなくそれだけの理由でFスポは避けた。NAVI-AVSやパフォーマンスダンパーは魅力的であったが、本当にただそれだけの理由で見送った。見た目は大事。
#内装
やたらとデカいナビ画面が最初に目に付くが、それ以外は概ねシンプルな構成になっている。以前のモデルはアナログ時計や様々な加飾があったようだが、必要なものに目がいくような、チラチラ余計なものが見えず実用の上で快適だ。契約前にディーラーで現行RXと初代NXを見たが、現行RXは居住空間の余裕からラグジュアリーで加飾が多くとも伸びやかな印象で違和感がなかったが、NXでは少し小さくなるだけでゴチャゴチャして狭さを感じていたので、なんとなく「広くなったな」という印象である。TAZUNAコンセプトとして必要なものにすぐ手が届くように設計されているとのことで、確かに必要なスイッチ類にはすぐに手が届いてそれも快適である。構成もさることながら、リアル・フェイク織り交ぜた全体としてのレザーの品質やその他部品の工作精度など、全体的な製品としてのクオリティも高く「なんかいいもの買ったな」と素直に思える仕上がりになっている。世間で実写をまだ見かけることが少ないのでわかりにくいが、カタログの写真よりも圧倒的に実物の印象が良いことは特筆しておきたい。
そもそも、そんなに車の性能について詳しくないことを事前にお断りしたい。Ver.Lは標準のサスペンションでモードはエコ・ノーマル・スポーツに限られるが、そもそも私はスポーツ走行がわからないので十分である。前者はディーゼルターボで小型のわりに強大なトルクを発生する仕様であったために、単純に街乗りでは頗る速かった。信号が青になったときなんか、油断するとドカーンである。それと比して随分と「ジェントル」になったのだが、静かで振動が少なく、発進時はモーターの比率が高いので、遅いとか、重たいとかと感じることはまずない。ハンドリングを含めて車の挙動としてはスッスと動くので気兼ねなく車を流すのには快適だ。ある程度の余裕を以て機敏に動く印象で、峠を限界まで攻めるとかサーキットを走るとかで無い限りは全く問題にならないだろう、というか、そんなことはしたことがないのでわからない。また、見た目よりも車重が軽い印象で、剛性の高さも動かしたらすぐにわかる。私は車について素人なのだが、素人が動かす街乗りの車で言えば最強なのではないかと思わせてくれる感がある。車の素性がいいとはこういうことなんだろうなと思う。
燃費については先代程度だろうなと思っていたが、8km程度の渋滞を含めた通勤路で14km/L、信号と渋滞の少ない郊外路では20km/Lにも到達するので想像以上に良かった。また、走行データを確認すると、60-70%はEV走行しているそうだ。ラバーバンドフィールはごくわずかにないこともないが、注意を向けなければアクセルの反応は良好だし、ハイブリッドカーも以前とは比べものにならないくらい進化したと思うし、ハイブリッドだからこそ得られる走行の妙味もある。主にエコモードで動かしているが、燃費優先というわけではなく、回生ブレーキの挙動や速度コントロールが非常に楽なので積極的にそうしている。特に説明書などに記載はないが、GPSと地図情報から法定速度情報を得たり、ITSで他車の速度情報を得たりしてコントロールに干渉している気はする。実際は不明だが、そんなに運転中はゴリゴリに感覚を研ぎ澄ませているわけではないので、なにかと気を抜けて(抜くな)ありがたい。なお、なんとなくウェイウェイしたいときはノーマルにするし、めっちゃウェイウェイブーンしたいときにはスポーツにしている。そうするとだいたい気分に合う走りになってくれる。
今回は個人的に初めてAWD設定にしたのだが、普段はわからないが、大雨の中で高速入り口のカーブが続くなかで加速を行うシチュエーションで圧倒的な接地感を感じた時にはうっかり爆笑した。「なんだこれ、全然滑らねぇ。」と。むしろこれまでのFF車が低μ路でいかに浮くように滑っていたか、を思い知らされることになった。とても安心感がだが、これが新型NXだからいいのか、AWDだからいいのかどうかは私にはわからない。だが、AWDにして良かったと既に満足している。
#静粛性
前車と比して随分と静かになった。ディーゼルと比べたら当たり前なのだが、ただ、それ以上に風切り音や外音の遮断がよく効いていてふと窓やルーフを開けたときに「外こんなにうるさかったの?」と驚くことが多い。極端な遮音がなされると自身の体内から発生する音が気になったり、どことなく不安になる感覚を経験したことがあるが、絶妙に不快な音だけをフィルタリングしているかのようで自然かつ快適である。また、若干のエンジン音やモーター音は入るようになっているが、それがないと車の動きが把握出来なくなって個人的には不安になるので丁度いい。もしかしたら、音というよりはハンドルやアクセルペダルから伝わる振動からよく把握できるという方が正確かもしれない。この点はパフォーマンスダンパーが入ったりすると少し違ったりするだろうか。乗り比べる機会がなかなか無いのは残念だ。
今回は外付けドライブ以外の実質フルオプションとしたので走行支援に関する装備も全て装着している。新世代レクサスとして特盛になっているので全てに対して記載をするとキリがないし、良いと思った機能について記載する。まず、街乗りのシチュエーションではプロアクティブドライビングアシスト(PDA)は意外によく働く。先行車の車速などを関知して車速を調整したり、車線からの逸脱を防いだりなど、注意がふと切れるタイミングで作動してくれる印象だ。初期設定では過剰な介入を感じたので設定から「遅め」を選択しているが、慣れれば程よいと感じる程度になった。
今回の目玉装備であるアドバンスドパーキングだが、期待せず面白そうだからという呑気な気持ちで導入したが、意外に使える仕様になっている。正確な画像認識のため駐めたい場所の周辺に近付いたら可能な限り徐行する、車が十分に動けるスペースを確保して周辺に柱などの障害物がないことを確認するといった多少のコツさえ身につければバシッと綺麗に駐車してくれる。そりゃ自分で入れたほうが速いのだが、自分であくせくとハンドルの切り返しやシフトチェンジする必要がないので気持ちは楽である。一部から怒られるかもしれないが、最近は駐車をNXに任せている間に降車の準備としてマスクを装着していることが多い。また、リモートパークも入れたら出られない駐車場で使用したが、さすがに不安だったもののきちんと駐車してくれた。どちらかと言えば駐車している間に隣の車両が変な幅寄せをしてきたときに乗り込むために車をスペースから出す目的で使うシチュエーションが多そうだと思った。
高速道路ではオートクルーズコントロールとレーントレーシングアシストでほぼ走ることにはなるが、基本的な機能として問題なく軽くハンドルの一部を握っているだけで作動してくれるので感覚的には自動運転に近い。また、レーンチェンジアシストもオプションで装備しているが、ウインカーを一定時間保持することで周囲を認識し自動で車線変更してくれる。ただ、3-4秒かけてじわぁ...と車線変更するので横向きのGが発生しにくいので主たる同乗者である妻には好評だが、若干じれったく、この間に道路状況が変わらないか少々不安にもなる。そのために急な障害物や割り込みなどに対して車線変更による回避への対応もできないのでそこからLTAが作動している状況で車線変更しようとすると車が抵抗するし、その後に「もしかしてぼんやりしてますか」とナビに煽られるのは少しイラッとする。自身で車線変更する際にはLTAを切る癖をこれからつけなくてはならないだろう。ただ、ネガティブな点はそれくらいで総じてよくできており、未来が来たなぁ、と感じた。
今回のNXに限らないんだろうけど、車自体がモバイルネットワーク接続できるのって使ってみると相当に便利。離れてても車の施錠などの状況が確認できたりエアコンを事前に動かしたりすることもできる。地味に楽しいのがマイカーログで、運転経路や燃費なんかも確認できる。これまでは車で直接ナビをいじってみることはできたけど、面倒くさくて見ることは正直なかった。これならどこでも手元で確認できるのはお手軽でついつい見ちゃう。あと、これはいいなと思ったのは事前にスマホで経由地や目的地を設定して車に送っておける機能。車に乗ってからナビ設定するのって時間がかかるしすぐに車出さなきゃならない時とかにはうんざりするけど、例えば出先のお店で食事を摂りながら次はどこに行って...みたいな話をしながら入力して、あとは車に乗り込むだけというのは実際に使ってみると実に心地良い。ちなみにまだオーナーズデスクにお世話になったことはないのでそのうち使ってみたい。
#オプション装備について
運転支援については記載した通りなので、パノラマルーフやプレミアムオーディオのマークレビンソンについて。パノラマルーフはツートン調になることに若干の抵抗があり、特に必要性も感じなかったが換気やリセールを意識した際の人気オプションであると説明され導入した。実際には「開けると楽しい気持ちになる」程度であるが、朝の日差しが心地よい時や、ふと信号待ちで天井からの町並みを見上げた時には良い開放感があって装着してよかったなと思える。
ちょっとだけオーディオ趣味なのもあってマークレビンソンの装着はあまり迷わなかった。自分でオーディオ装置を選定するととんでもない手間と金銭がかかることは目に見えていたので、お手軽にメーカー純正のオーディオシステムが最初から入ってること自体が魅力的だった。納車まで試聴する機会はなかったのだが、カーオーディオに詳しくはないものの20万円程度のオーディオシステムとしては十分良いレベルを確保していた。具体的には解像度や定位感が良好でノイズレス、ダイナミクス表現にも優れており小さい音量の楽器までしっかりと表現する「普通に良い音」だった。過剰なサラウンドや低音をブーストするような安っぽい演出ではなく、どこの座席に座っても2chのオーディオらしく自然に聴けるというのは実はそんなに簡単な事ではない。とてもよく練られたDSPが入っていると思う。音量を上げた時にありがちな内装の共振は抑えられてる印象で、キックドラムや超低域のシンセベースのフレーズでもスピード感があって無駄な残響がなくキレがいい。難点があるとすれば、ピュアオーディオ的な良い音の作り方でもあるので音源に左右されがちなこと。当初はiPhoneからのBT接続にしていたんだけど、有線でのApplCarPlayや、妻のXperiaでのLDAC接続では歴然とした差があったし、録音自体が良質なものは心地よいけど、そうでないものは荒が目立って気になってしまう。聴くものを選ぶようにはなってしまうけど、それはオーディオの世界では普通のことだと思うので「スピーカー自体に金をかけたことがある」層のためのオプションなのかもしれない。ただ、この音を自分であれこれ買って再現しようと思ったら3倍出しても得られない可能性はあるし、ある意味コスパには優れているし私個人では大満足で、これ以上はいらないと思ってる。キリがないから。
完璧な車なんてないと思ってるけどネガティブポイントは新型車なのもあってないことはない。例えば、ナビの音声認識。初期設定ではヘイレクサスで起動してあれこれ操作やナビ設定ができたりするんだけど、エアコンやルーフ、窓の操作はだいたい失敗する。AlexaやGoogle Assistantほど賢くもなく、反応も最近の音声認識端末で経験するよりは圧倒的に遅い。なんとか使えるのは目的地設定でこれはわりと精度高くできるんだけど、まぁ時間かかるのでオーナーズデスクに繋いだ方が早く設定できる可能性すらある。いや、どうせならそっち使えばいいんだけど、人間の手を直接煩わせるのに若干の抵抗があるのでナビ側でなんとかならないかなと。
あと、エアコンやナビの地図を動かしたりという場面でナビは見やすい高い位置にあって、更に巨大なので意外に操作していると手が疲れる。リモートパッドが評判悪かったみたいで廃止されたようだけど、あっちの方が楽だとも思う。見やすさや表示範囲は圧倒的に良いのでもっと音声操作がスムーズで高精度だと手を伸ばさなくとも使えて本来開発者が意図した形になるのではないか。あと、再生中の楽曲情報については小さい窓でいいので地図と同時に表示できたらいいのになと思う。
あと、デジタルキー。実は初期登録がうまくいかず、使用できていない。ただ、使う状況もいまのところないのでそのままにしてる。もうこのままでいいと思ってるくらいにどうでもいい機能だったのかもしれない。うちは運転するのが私ひとりなので共有する相手もいないからこれでいいんだけど。まぁ、いらなかったな。
#総じて
イマイチな面もあるが車の素性が大変良いので吹き飛んでしまう、というのは素直な感想。なんだかんだ走らせてナンボなので現状では大変満足している。内装においてはこれまでのレクサスと比してスイッチが多い高級感とかアナログ時計とかの特徴は廃されたけど、要素を絞って現代的でシンプルに徹した品の良さは所有していると好ましく思えてくる。ただ、こう書くと北欧テイストなのかと思われそうだけど、そんなにデザインコンシャスなわけでもなく、日本的な割り切り方や合理性をうまく良い形に落とし込んだ、という感じです。まぁ、前車はボ○ボだったんだけど、正直なところ内外装はボ○ボのほうが好きだった。あれは良すぎるんですわ。でもNXはこれでいいんですよ。マイナー輸入車のあれこれに正直なところ懲りた僕は、天下のトヨタ様がパッケージングした車を買ったんです。
これまで乗ったトヨタ車や、代車で乗ったレクサス車と比べると乗り味が欧州車っぽくなった印象だけど、個人的にはそっちの方が好ましい。メルセデスのGLCと購入検討していたけど、やや世代が古めになるのとシートベンチレーターやらの欲しいけどあまり装着例がないオプションは在庫車もあまりないし、注文者は納期未定で値引きもないし、なんだかんだお高いんですよね。その点でNXはずいぶんとコストパフォーマンスは良いと思います。まぁ、高いんだけど。
輸入車はそれなりにブランド力があって、レクサスがイメージ的に御三家に及んでないところはあるかもしれない。ただ、実車が明らかに劣っているかと言われたら全くそんなことはなく、総合しての商品力はすごく高い。とくにNXは価格でみれば価格以上の出来だと思う。トレンチコートを買うときにバーバリーやアクアスキュータムの名門の定番を買うのか、三陽商会の百年コートを買うのかを迷ったときに、GLCやGLBを買う層は前者だと思うし、 Permalink | 記事への反応(1) | 23:58
ヒステリーというかパニックになってて非科学的な記載が目立つ。
「人参の皮はむくな。」とかいってるけど、根菜の皮はほかの葉物などの作物にくらべて土中の重金属や農薬の吸収率が高いので皮を厚めに剥いて捨てることが推奨されている。ずっと食べているとたとえばイタイイタイ病のような病気になるかもしれない。
もちろん、輸入人参でも農薬などが基準以下のもののみを市販しているが、全数調査ではないので根菜の皮は厚めに剥いて捨てるに越したことはない。
https://www.jstage.jst.go.jp/article/kampomed/60/1/60_1_25/_pdf/-char/en
あと、じゃがいもの場合は皮にソラニンが蓄積していて食中毒になることがあるし、
そうでなくても単純に胃腸にキツい。胃腸がつまる病気になりやすい手術経験者や老人には食わすなマジで。いっとくけど日本の人口の半分はもう老人。
粗食だの農林水産省のフードロスを気にして無理な生活をして病気になると、抗生剤、点滴、ワクチンなど工業の集約のトップにある、高額な石油製品を使うことになる。(直接ではなくても、殺菌や精製やパッケージング、あと人件費や開発費・知的財産権ロイヤリティなど間接的に世界中の石油エネルギーをたっぷりつかっているので高額になる)
三割負担でも薬は高い。10割負担の額にしたらほぼ一般人の手には入らなくなる。アメリカ人がメガネかけないのとおなじようにな。
あとコロナで給食の牛乳もあまって違法だけど川にながして捨てたいってなってただろう。ツイッターで蘇という料理のレシピが流行って牛乳と光熱費を無駄につかう料理をしはじめたりした。
だから病気の影響のほうが環境への負担もおおきいんだっていってるだろ。
つまり、現在市場で入手できるあらゆるものの値段は、(関税や米価調整などの政府調整がはいらなければ)およそ、完成までに使用した石油エネルギーの量に比例している。
素の値段の高いものは環境負荷が高いといえる。(くわしくは環境負荷、環境アセスメントで自分で調べろ)
牛肉が高いのはどこかから運んできた牛にどこかからはこんできたコーンを食わせ冷暖房をいれて何年も育てたあげくどこかへ冷蔵車で出荷されるからだ。鶏肉・鶏卵が安いのは育成期間が短く、一年程度でエサ代冷暖房代が少なめのうちに出荷でき、各地に養鶏場があるからだ。もやしやかいわれ大根も圧縮解凍みたいな作物だから各地で水だけでつくれて安いしうまい。
作物が基本的に安いのは、天から運ばれた水と太陽光でその場で育つし、手間暇かかりすぎるなら価格競争に参加できないためその時点で製造・出荷をとりやめるからだ。
(米や塩の値段だけは政府が調整をいれていたが今はやってないかも)
だから人参の皮をたべてまで安いものを無駄にしない=余計買わないようにしたところで、
そのせいで高い医療サービスを買わざるをえなくなるなら環境負荷も家計負担も政府の医療費負担も増えてしまって本末転倒なのだ。
以前アルファーGOという人工知能があって人間の棋士を負かせるほどの棋譜をつくれた。だが1枚の棋譜に1兆円のサーバー電気代がかかるからグーグルは開発を停止した。
人間棋士(トップクラスでも生涯賃金10億程度の激安価格で200枚やそこらは棋譜を生み出すだろう)のほうが、安くすむし、環境負荷は低かったということだ。
だからこの手の増田も、目の前の高性能コンピューターを無駄につかってないで「ごく普通の、あたりまえの」生活知識を磨き、子供を生み育てろよ、バカめ
人間は石油を直接燃料とせず知的労働の成果を製造できる唯一の家畜だ、それが営々と環境最適化をした今が文明社会の最先端なのだ。
とりあえず紙でガッコーというところで配られる基礎知識セットくらいはあればこんなにヒスらなくてすむんだぜ
ちなみに欧米人もボナペティはいうし、場所によっては神に感謝の祈りを(5文字よりもっと長く)ささげる。
親のつくった温かい飯を前にいただきます言わないで食い出して言い訳に4000字も猿みたいな勢いでキーボード打つやつはマジ家畜だから少なくともプロ棋士以上の知的労働成果を挙げろよな
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
と言うか、いい加減Twitterはこのノイジーマイノリティのお気持ち表明をトレンドに挙げてくんなよ。それでも一応見た。何を言ってるかを見るために。
まぁキモい。不特定多数へのねちっこい恨み言を、綺麗にパッケージングしてるが、「私達の主張を100%飲まない愚民ども!私達に100%同意しない愚民ども!」って言う、日本のノイジーマイノリティのいつもの発狂ぶりをもう少し綺麗に言葉を取り繕っただけ。徹頭徹尾キモさしかない。
反対意見には耳を貸さない為に、リプを制限してるのもやり方が小汚い。言いたいことだけ行って耳に痛い言葉は聞きたくない。私達は被害者ですってか?率直に言って死ねと言う感想しかない。
大体、子無しもホモもレズもただのフリーライダーのくせに、何社会で一端の立場を得ようとしてるの?立場わきまえろよ。お前らが居なければ日本はもっと強く豊かな国になってるんだよ。お前らが国から活力を奪って弱い国にしてるんだよ。
日本が気に食わないならヨーロッパにでもアメリカにでも行ってくれ。お前らは必要ない。