  |
はてなキーワード: マルチとは
まあVMWorldとかで10年以上人生の春を謳歌してきたからもう十分やろ
お疲れさん
～VMwareが提案する、DRにも対応するマルチクラウドソリューション～
昨今のCOVID-19流行への対応やDXを推進する中で、クラウドサービスの利用はビジネススピードの加速や柔軟なシステム運用に効果的であり、従来のオンプレミス環境と併用するハイブリッド環境や、複数のクラウドを利用するマルチクラウド環境が増えている。一方で、これらの環境を維持していくには課題も多く、セキュリティリスクも増大してしまう。ここでは、こうした課題を解決するVMwareのソリューションを紹介する。
COVID-19流行への対応やDX（デジタルトランスフォーメーション）のためのビジネス変革が進む中で、ビジネススピードの向上やニーズに対する迅速で柔軟な対応がこれまでになく求められている。これらを実現するために、アプリケーションの変革やクラウドへの移行が加速している。
多くの企業が、「ビジネスのスピードに対応できるモダンアプリケーション」や、「あらゆるクラウド、データセンター、エッジでビルドおよび実行が可能であること」、「エンタープライズクラスのレジリエンス、セキュリティ、運用の実現とビジネス変革」がDXを実現するために必要であると考え、これらを実現するためにマルチクラウド環境の活用が前提になってきている。
具体的には、Amazon Web Services(AWS)、Microsoft Azure(Azure)、Google Cloud Platform(GCP)といった複数のパブリッククラウドサービスを併用し、適材適所で使い分けているのが現状であろう。しかし、マルチクラウド環境では解決が必要な課題が存在する。その課題とは、「ワークロードのシームレスな移行・連携」、「クラウドごとのスキル習得」、「運用管理の簡素化」、「セキュリティリスクの低減」、「最適なコスト管理」の5つである。この5つがクラウド利用の理想と現実のギャップとなっており、これらを意識して進めていく必要がある。
特にマルチクラウド環境を適材適所で使う場合、クラウドごとに利用する技術が異なるため、設定項目や内容に違いがあり、その設定ミスによるインシデントも発生している。重大な影響を及ぼす場合もあるため、それぞれのクラウドを扱う際のスキルが重要になる。
こうしたマルチクラウド環境における課題を解決するには、一貫性のあるクラウドインフラストラクチャ、および運用管理サービスが重要なポイントとなる。例えばVMwareは、複数のパブリッククラウドだけでなくオンプレミスを含むハイブリッドクラウド環境においても、仮想的なレイヤーを構築することで管理や運用を一元化している。
VMware Cloud on AWSは、VMwareとAWSが共同で開発したもので、AWSのベアメタルサーバー上にvSphere、NSX、vSAN、vCenterを導入し、ホスト専有型のクラウドサービスとして提供するものだ。
その特長は3つある。1点目は「VMware製品をベースとしたクラウド」であること。VMware製品で仮想化されているため、AWSの世界にいながらオンプレミス環境で利用していたスキルセットや運用管理ツールを利用でき、新たなスキルを習得する必要がない。
2点目は「シームレスにクラウドに移行できる」こと。ワークロードをオンプレミス環境から無停止で移行することができる。アプリケーションを更改する必要もないため、クラウドに移行する時間やコスト、リスクを大幅に削減することが可能だ。
3点目は「VMwareが管理を行う」こと。ハードウェアやソフトウェアのトラブル対応や運用管理、メンテナンス対応など、すべてサービスの中でVMwareが実施する。3カ月に一回の頻度で新しいリリースを提供しており、ユーザーの要件を反映しながら新たな機能を追加している。
最近のアップデートの大きなものとして、日本で第2のリージョンとなる大阪リージョンを設置し、サービス提供を開始したことが挙げられる。例えば西日本地区でデータセンターを持つユーザーは、より低遅延でサービスを利用できるようになった。昨今は感染症の流行や地震の発生などによってBCPを見直すユーザーが増え、VMware Cloud on AWSをリカバリサイトとして利用するケースも増えている。その意味でも、大阪リージョンは活用度が高いといえる。
VMware Cloud on AWSが選ばれる理由は、大きく3つ挙げられる。1点目が既存のノウハウや運用管理手法をそのまま踏襲できるという点。VMware製品をベースとしたクラウドサービスであるため、オンプレミス環境における管理者のスキルや運用ノウハウなど、既存の資産をそのままクラウド上でも活用でき、新たなスキルの習得や、運用管理手法の大きな変更の必要もない。クラウドとオンプレミス環境をvCenterから一元管理できる。
2点目が、規模に依存しないシンプルなクラウド移行を実現できる点。ワークロードをそのままクラウドへ簡単に移行することが可能だ。VMware Cloud on AWSには標準でVMware HCXが含まれ、これはオンプレミスのデータセンターとクラウド間のネットワークをL2延伸する。ネットワークがつながった環境で仮想化環境、VMをそのままマイグレーションできる。アプリケーションやIPアドレスを変更することなく、無停止でワークロードを移行することができる。
3点目が、モダナイゼーションを推進して、ユーザーのDXの加速を支援できる点。まず、クラウドならではのインフラストラクチャとして、1顧客あたり最小2ホストから最大640ホストまで拡張できるが、俊敏性を兼ね備えて提供される。例えば、ホストの展開に1時間半程度、ホスト数を追加するのに15分程度と、オンプレミス環境ではありえないスピード感で環境を構築、提供される。
また、リソースを最適化する機能も提供される。ユーザーのリソースの使用状況に応じて、利用するホストの台数を自動的に増減させて最適化する。さらに、名前の通りにAWSが提供する各種サービスとの親和性が非常に高いことも特長。VMware Cloud ENIと呼ばれる専用のインタフェースを経由して接続することで、低遅延で高速な環境を利用して各種のAWSのサービスとシームレスに連携することができる。この面も同サービスの大きな強みとなっている。
最近では、VMwareが提供するKubernetesディストリビューションであるVMware TanzuをVMware Cloud on AWS上で稼働させることが可能になった。これにより、短時間でコンテナ、Kubernetes環境が導入できるようになる一方で、ハードウェア、ソフトウェアの管理はすべてVMwareが行うため、管理者はKubernetes環境に集中できる。
VMware Cloud on AWSのユースケースには、主に「オンプレミス環境のクラウド移行」、「データセンターの拡張」、「災害対策サイト」、「次世代アプリケーションのプラットフォーム」の4つが多い。特に最近は、災害対策としての利用が増えているという。VMware Cloud on AWSをリカバリサイトとして活用する際に強力なサービスとなるのがVMware Cloud Disaster Recoveryだ。
VMware Cloud Disaster Recoveryを利用すると、平常時には本番サイトのデータをクラウド上のストレージ領域にレプリケーションしておき、万一DRイベントが発生した際に初めてVMware Cloud on AWS上にホストを展開し、保護していた仮想化環境をフェイルオーバーする。リカバリサイトとしてあらかじめ物理的なサイトを構築しておく必要がないため、大規模な初期投資が不要となる。
VMware Cloud Disaster Recoveryの特長
このタイプはオンデマンド展開型と呼ばれ、DRイベント時にホストを展開したタイミングでリカバリサイトに対する課金が開始される。復旧後に仮想化環境を本番サイトに戻すことで、ワークロードもフェイルバックでき、不要となったリカバリサイトのリソースも削除され課金も停止される。なお、オンデマンド展開型のほかに、事前にホストを展開しておく事前展開型も用意されており、RTOを重視する場合には事前展開型が推奨される
また同サービスは、最近話題になっているランサムウェアへの対策にも有効だ。クラウドストレージ上に本番環境のデータをバックアップする際には、リカバリポイントを長期的に保持することが可能である。このため、ランサムウェア攻撃に遭ってしまった場合、その直前の時点からリストアすることが可能となる。
マルチクラウド環境を可視化するVMware vRealize Cloud
マルチクラウド環境では、各クラウドが複雑化し、サイロ化してしまう可能性がある。クラウドごとに管理ツールや必要とされるスキル、ノウハウも異なるため、利用するクラウドが増えるほど複雑化、サイロ化の問題が大きくなり、その結果セキュリティリスクやコストが増加してしまう。そこで有効な解決策となるのが、クラウド環境をまたがって一貫性のある運用・管理を実現できるVMware vRealize Cloudである。
まず、VMware vRealize Operations Cloudは、VMware Cloud on AWSのリソースだけでなく、他のパブリッククラウド上のリソースも一元管理できる。複数クラウドの環境にまたがってデータを収集、分析評価を行うことで、例えば常にパワーオフ状態の仮想化環境や、実体がない状態のディスクなどを検知された場合に最適化していくことが可能。これにより、最終的にコストの最適化も図ることができる。
コストや運用を最適化できるVMware vRealize Cloud
また、VMware vRealize Log Insight Cloudによって、複数のクラウドを横断してログを管理できる。例えば、監視対象のイベント通知をあらかじめ定義しておくことで、不正な行動を検知した際には管理者に通知し、適切な調査と対応を行うことができる。セキュリティやコンプライアンスの強化にも有効だ。
さらに、クラウド間のネットワークの可視化は、VMware vRealize Network Insight Cloudで実現できる。End to Endを含むネットワーク全体を可視化できるため、ネットワークに関するトラブルシューティングや、不審な通信を洗い出すこともできる。また、アプリケーションの通信も把握できるため、アプリケーションの移行計画にも活用できる。
今後、DXの推進を加速していく上で、必ずしもひとつの環境、ひとつのクラウドを利用するのではなく、マルチクラウド環境の利用が当たり前になっていくと考えられる。そこで直面する前述の5つの課題に対し、VMware Cloud on AWSそしてVMware vRealize Cloudの活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
暗号通貨界隈のやってることってそのまま土地バブルと同じなんだよね。
これやってる連中はアラサーだろからバブルを知らなくても仕方がない。
旗振ってる連中はわかっててやってんだろうが。
歳を取ると嗅覚が育つ。
近づいたらアカン
Web3なんてものは来やしない、
一部の技術は採用されるだろうが奴らが夢見る完全分散なんてありえない。
例えばYoutubeのサーバー容量が12ZB（2021中盤）。
参加ユーザーそれぞれ500Gを供出するならば２４０億人が参加しなければならない。
（短文でスケール感を示す目的で技術的な重箱ツッコミは無用、計算間違ってる可能性大）
送金が廉価になるというが暗号通貨など使わずに既存の金融システムの改良でどうでにもる。
国境を超えた送金が気楽になるというが、コスト、手軽さ、いずれも何十年も前からある
Western Unionの方が遥かに確実で廉価で手軽だ。
そこで連中はNFT言い出した。
これはできまい、ﾄﾞﾔﾄﾞﾔ
社会に余ってる小銭をかき集める商材、道具立てにすぎない。
日本の税制はおかしい、暗号通貨に適合しろと愚痴ってるアホがいる。
当たり前だろｗ
なんで税制が社会に不要な暗号通貨ごときに合わせてやらねばならないのだ。
てめぇが合わせろ。
キーボードが乗ってきたので書き進める。
例えば百均で皿を買ってくる、それを素材にアーティストが加工し１億円の価値あるものにする。
これを製作したA社からB社に売却しA社は代金として１億円を受け取る。
んなもん税制上許されるわけねぇの。
せっかく作った１億円のお皿を間違って割っちゃった、もはや無価値だ、損失１億円だ。
損金計上させろ。
いやｗ無理でしょｗ
で、ようは暗号通貨連中はこれを認めろと言うている。いや無理ｗ
てめぇらが創造したなんちゃらコイン何百億円の価値なんぞ実態が無く
当たり前だろ？
で、アホｫ通貨連中はガラパゴス税制を改めないと日本に未来がないと曰う。
この批判に反論するためWeb3だのNFTだのでっち上げて価値が創造されるかのように演出。
何十年も変わらない、いくら警告しても引っかかるやつは引っかかる
道具立てをちょっと化粧するだけで騙される。
ダイバーシティとか多様性とかを使い始めたら何かの宗教やマルチにハマったか、その人の居る界隈が非常に劣悪かを表している
例えば何らかのゲームの話題で「老若男女が誰しも色んな遊び方を出来、多様性のあるゲームだと思う」なんていいだしたら完全に赤信号
それに賛同する人が多ければ多いほど、内部は腐っていると思っていい
負けが続き始めてしまいゲーム内キャラの性能の差に苦言していたのですが、人の悪口だと言われました。
確かに過去に対戦相手に対して酷い事を言ったのもあり、気を付けながら性能の事で苦言したはずでした。
今のままだと他の方達に色々迷惑をかけてしまうと思い、今日はこれで終わりますと言いました。
次の日からその人からの誘いは無く、他の方とやっている通知が来ました。
結局自分にはあの対人戦ゲームは合わなかったのだと悟り、今後このままだと現在進行形で他の方達に迷惑かける事による罪悪感とその人からのあからさまな拒絶感によりそのゲーム専用のサーバーか黙って抜けました。
その出来事があり今はゲームで遊ぼうとしても他の方に迷惑かけてしまうかもしれないと思うとマルチ等が出来なくなりあまり楽しく感じれなくなりました。
結局何が伝えたいのかと言うと、ゲームで楽しむ為にまた友人を作りたいですが自分の性格的に作らない方がいいのかと迷ってます。
https://www.mazda.com/ja/innovation/technology/gihou/2021/
これについてちょっと色んな感情を抱いたわけで感想というか考察というかなんかそういうのを書きます。
電池制御屋さん(?)なのでメインはEV関連のところだけピックアップしてみます。本当は全部やろうと思ったけどエンジンとか分からなくて書くことなかったです。
普段こういうことやらないので読みにくかったら見なかったことにしておいてください。
あと、そもそも私は社員でもE&Tさんや販売店さんでもないですので間違ってたりしたらごめんなさい。
去年に比べてボリュームも多く、メインのトピックとしてMX-30のEVが挙げられていますね。マツダ初のEVですからそりゃあ力を入れますよね。(デミオEV?あれは量産されてないからノーカンで)
では順に見ていきます。
こういった経営戦略は専門外ですし特にないです。頑張って下さい、という感じです。でも、スモールプレイヤーであることを自覚しているならなぜスバルさんのようにEV開発にトヨタの力を借りなかったのかが不思議ですが極めて高度な経営戦略的判断なのでしょう。
私はEV反対でもEV賛成でもなく、ユーザが好きなものを買えばいいと思いますが以下の件、エンジニアとしてずっと疑問に思ってますよ。
https://www.mazda.com/ja/csr/environment/lca/
ところで、技報は直近だと技企が担当っぽいんですがどういう基準で毎年内容とか選んでるんですかね。分かりません。
両開きドア、必要だったんでしょうか。使いにくいと思うんですが…
車格的にこれ以上大きくできないけど四人乗りだし特徴出さないといけないという苦肉の策でしょうか。
私は美術の成績が2くらいしかないのでデザインはよくわかりません。
あ、でも、インテリアのコルクの件は誰が思いついたんでしょうか?どういうコルクでどういう工夫がされているかわかりませんが、熱衝撃でボロボロにならないんですかね。ぜひそういうのを技報で取り上げて欲しかったなぁ。
書かれていることは難しくて分かりません。商品企画って大変だと思います。
みなさん、一回乗ってみるといいと思います。思いの外普通の車です。
制御って難しいですよね。まず式が多くて難しい。
この手の制御は実車でのフィーリング評価が多いでしょうからそれだけ走らないといけないだろうし大変だと思います。
Fig.4ってどう見ればいいんですかね。そりゃ制御切ってる赤線が0なのは当然だと思うんですが。GVCのリクエストに対してモータのリクエストトルクが遅れているのはなにか意図があるんでしょうか。私には分かりません。てかこれ実トルクじゃないのね。
Fig.6ではGVCの有無による加減速が記載されてますね。GVCの有無で横Gは変わらないけど前後方向は、「ターンイン時に減速」「ターンアウト時に加速」と。いやこれ、運転してる人には誤差みたいなレベルのGだけど(たぶん、普通に運転してたら0.1~0.4Gくらいでこのデータだと最大0.4m/s^2≒0.04G)いるのこの制御?
この辺で読むのやめたけど、Fig.20はどうかと思う。基準値おかしいでしょそのグラフ。
この辺も専門外だから流し読み。ペダルの味付けの話かな(適当)
Leafとかi3とか回生がキツくて慣れるまでなんか気持ち悪かったけど、MX-30はその辺まだ運転しやすかった気がする。
これもよく分からない。感想としては、エレキシフトである必要ないよねって思う。
電子制御にすれば車側からの介入がかけられるってこと書いてあるけど、ソフトウェアのバグのリスクを抱えることになりそうだし、そもそもどういうヒューマンエラーを想定してんの?って素人的には思うんですよねぇ。
でもそれよりもあの変なシフトの形状の方が気になる。
LCA(ライフサイクルアセスメント)の件はいったん不問にするわ。
ふむふむ、LiBの温度管理をしっかりして容量と入出力を使い切ると。むしろそれ以外にはないわな。
「クーリング・ヒータシステム」うん、こういうのでいいんだよ、こういうので。
なるほど、冷媒冷却なのね。Fig.8を見ると温めるのにはヒートポンプ使わないのか。もっぱら冷却専門って感じね。そりゃあ電池が動かないくらい寒いときに温めるんだから効率の悪いヒートポンプ使わないのは当然か。Hondaさんはモータ系の冷却水を電池に回して加温にも使ってた気がするけど冷媒だと難しいんでしょう。
ところで、車室内が暖房で電池が冷却を求めている場合(真冬の高速連続走行)とかの時はどうなるんでしょうね。ヒートポンプ一個しかないけど。
冬場はヒータを使って電池を温めて充電時間短縮に貢献しているんですね。
あ、そういえば低温の充電についてはこんな記事ありましたよ。
https://insideevs.com/news/486109/mazda-mx-30-battery-pack-heating-issue/
マツダさん、色んなところでMBDのお話してるのでやっぱりありました。
元々シミュレーションで研究やってたんで、モデルベースとかシミュレーションとか僕は好きですよ。
これを見るとHILSがメインなんですかね。HILSって物できてから色々するものだと思ってるんですがこれはMBDなんでしょうか。まぁHILSにはモータとか電池とかのモデルが入っているのでその意味ではMBDか…
ゴリゴリの計算化学的なのはないんでしょうか。EVだから電池系でその辺もあるかと思ってたんですが。
気になるのは4.1の説明で「ユニット間通信もPCMとの Peer to Peer通信を基本とした」と書いてますね。だいたい今の車載系のネットワークはCAN通信なのでP2PっちゃP2Pなんですが、わざわざ書いてるということは何か特別なことがあるんですかね。
Fig.5らへんでは「充電みたいに特定の機能しか使わないときは他の機能を切って余計な電源使わないようにしたよー」って書いてますが、充電してるなら誤差みたいな電流では…?てかまぁ、関係ないユニットをそもそも動かさないのは当然だと思うんですが。
4.3はよくソフト系の品質検証である直交表ですかね。私も何度か作成したことあります。MBDでやるにしてもテスト数絞らないといけないからこういう感じで管理してるんですね。でも、機能毎の組み合わせをみるだけでも効果あるんでしょうか?不具合が見つかったとしても書けないでしょうから記載なくても仕方ないか…
市場での適合性とか考えると特に大変そう。でも気になるのは「1.はじめに」に書かれている「MX-30は約40分でSOC 80%まで充電できる」の文言。
え?40分?いつの車?35.5kWhしかないのに?もしかして急速充電器の出力30kWとかで想定してる?市場の急速充電器は大部分が(少なくとも日本は)50kWだと思うんですが。
外部充電関連やってる人はホント尊敬してます。だって仕様書難しいし仕様書曖昧なときあるし。COMBOとか仕様書自体なんか怪しいし。
本文中でも「HILSだけでは発見できない」って書いてあるけど本当にそうだと思います。
2.1見ると電池は電子部品扱いなの…?なんか共振点が被らないように工夫しました的なこと書いてある。
でも電池って重量あるし、特に考慮とかいらなそうなんだけど、マツダさんでは電池も細かくモデリングしてるのかしら。あとこれ疑問なんだけど、EVで使われるモータとかってエンジンよりも高周波成分持ってそうなんだけど言うほどないのかね、知らんけど。
2.2には不思議な式が載っている。ダメージ量というのはマツダさん独自の概念だと思う。少なくとも俺はいままで振動とか疲労とかの勉強していてであったことはない。疑問なのはFig.4の加速度に通常ひずみに対して使われるレインフロー法を適用していることになってるんだけどあってるこれ??加速度と応力は比例関係にあるけど周波数成分考慮しないと意味なくない??まぁ、そこはマツダさん独自の手法が隠れてるってことなんだろうか。
そして3.1には気になることが書いてある。
いや、とんでもない超過剰品質じゃん。強度半分でいいから車両価格下げてくれ。
3.2はモデルの話。しかし、写真を見るとマツダさんのアッパーケースは樹脂。これどうしているんだろうか。樹脂のシミュレーションなんてあまり精度よくできるとは聞かないし熱とか湿度とかの影響をもろに受けるはず。この辺もシミュレーション出来ているならすごいと思うんだけど特に書かれてない。一番壊れたらやばそうなのに。
ボデー屋さんじゃないからよくわかんない。でも、MX-30って両開きだから剛性保つの大変そう。
2.1には前突時の話が載ってて、電池を守らなきゃいけないから大変だとか。電池ってR100でメカニカルショックの試験あるからそれなりに大丈夫だと思うんだけどそうでもないのかな。あるいはR93/94で代替してるのか。ところで、実車見たことある人は分かると思うんだけど、MX-30ってモータルームスカスカでバカでかい支柱みたいなのがあるんだけどあれどうにかならなかったのか。てかバランス悪すぎるだろあの構造。内燃仕様も作る都合で仕方なかったのかもしれないけど他の車みたいに充電器入れとかにすればよかったのに。てか充電口とかフロントに持ってくればハーネスとか安くなりそう(モータ/インバータ系と同じところからバッテリパックに入れればいい)のになんであんな構造なんだろう。
3.1は側突の話。MX-30は両開きだから大変そう。ところで、これ全部解析の画像しかないけど、実車のやつはやっぱり画像写せないんだろうか。シミュレーションの研究やっていた身としてはシミュレーションが完璧でないことは分かっているので逆に不安なんだけど、こういうでか物はシミュレーションで十分ということなのかな。(認証試験は実車だろうけど)
よくわかんない。たぶん難しい。
日本語でおk。なんだそれは。とりあえず読んでない。
電池もEVも関係ないけど私が元々分子動力学シミュレーションやってたから。
でも、ほとんどMDの話が書いてない。シミュレーション条件も特に書いてないけど、写真を見る限り大した分子数で計算してなさそう。
これで精度が出るんだろうか。その辺を詳しく書いて欲しかった。
この手の計算は結果自体は出る。シミュレーションしてるんだから計算自体はできるものだから。ただ、現実の実験結果と定量的に合わせるのは非常に難しい。定性的傾向は出ても、定量的な比較はMDでは非常に難しい。
これは経験的なもので私が研究していたのは何年も前だけど傾向は変わっていないと思う。4.1でいちおう妥当性検証が書かれているけど、MDの結果については定量的に比較されているわけではない。紙面の都合もあるから仕方ないか。
ということでマツダ技報2021年度版の感想・勝手な考察でした。適当に読んだから読み間違えてたりしたら申し訳ないです。私はマツダ車乗ってるしこれからも頑張ってください。
いろんな場所に住んだが、しばらく行かないうちに潰れてしまった店を見ると、
ああああああもっと俺が通っておけば良かった、と後悔するときがある。
そういう代替の効かないお店というのが地元にあるかないかで、QOLはかなり違ってくるはず。
イオンや中堅スーパーでは替えの効かない業種のお店を挙げてみた。
１.パン屋
地方のスーパーには、とにかく硬いパンとか黒いパン、その他の海外由来のパンが少ないのもその理由。
なにしろパン屋は儲けが少ないし重労働だし、とにかくパンが好きだから開店しました的な商売抜きのパン馬鹿店主が多いので、
2.蕎麦屋
パン屋も馬鹿だが、蕎麦屋も蕎麦命という感じの蕎麦馬鹿店主が多い印象。
メニューに蕎麦がきあるとか日本酒揃えてるとかが特徴だが、こだわりが強すぎて生来の人付き合いの悪さが漏れてしまうこともある。
相性が悪いと感じたら、常連になるというよりは月１くらいのペースで付かず離れず見守ってやりたい。
オモニの作ったキムチやナムルは、スーパーで買えるものとはぜんぜん違う。
ただし、開店してウン十年で先代から引き継いだとかなら良いが、
新規開店だとまれに変な宗教やマルチに傾倒している家族だったりもするので、
これも付かず離れず付き合ってみたい。
4.ケーキ屋
突然辺鄙な田舎の地元にパティスリーができたらホントにラッキーとしか。おめでとうございます。
ナントカ賞を受賞したレベルの腕のある若いパティシエは、経費はたっぷりと材料にかけるべきと考えるので、
田舎にオープンするのは必然ともいえる。まあそれだけの腕前なら、潰れることはないんだけど。
5.ガソリンスタンド
これは市況に左右されるから、どんだけ常連になったところで潰れるときは打つ手がない。
最近だと火事が怖いということで灯油ストーブも敬遠されているのもきつい。
母が変な人を信奉してる気がする。マルチとか宗教とかではなさそうだが、どうも怪しくって嫌い。その人(A氏)は某国立大学の教授で、ウイルスとか感染症とかの専門家なのだが、コロナ禍になってから色々取材されたりテレビに出たり、かなり知名度が上がったみたいだ。個人的な活動だろうが、スマホ配信アプリでよく雑談配信のようなものをしてる。母はその配信アプリから彼のことを知ったらしい。
◼︎嫌いポイント①
A氏の言っていることはやはり専門家なので勉強になるようなこともあるが、なんとなーーく反ワクチンに傾いている。あと、ちょっと口が悪い。コロナ不安がってる人に対して「馬鹿じゃねえの」とか言う。
◼︎嫌いポイント②
取り巻きが嫌い。取り巻きは完全に反ワクチン界隈。配信アプリのファン層が独自にコミュニティを作って、オフ会をやっているらしい。楽しそうだから文句を言うつもりもないが、正直うさんくさい。母がそのオフ会に参加して、コロナワクチンのせいで車椅子生活になってしまった人と友達になって帰ってきた。別に信用してないわけではないが、友達になって、かわいそうだねって言って、だから何？
◼︎嫌いポイント③
母が変わってしまった……。暇さえあればA氏の配信を見て、彼が出るテレビ番組とかチェックして、取り巻き同士でコロナに関する有意義な議論をしてる。私に聞かせたいのか、配信があると音量大きめでリビングに響かせている。彼のどこがそんなにいいのか全くわからん。どうせすぐ飽きるだろうと思ってたのにもう1年くらいこう。
◼︎嫌いポイント④
顔が嫌い。
友人がマッチングアプリで出会った男性が良い人すぎてむしろ怪しくも見えてきてわからない…
・上記発言のあと「嘘つくの苦手ですぐに言葉に出しちゃう」とか言う
・一緒にご飯行けて嬉しかったし「おごらせて！」と言って実際払ってくれる（友人は割り勘のつもりだったけど押し切られた）
・友人のことを「（アプリで会話してたときから）気になってます」とか「いいと思ってます（≒付き合いたいみたいな）」と言う
友人はソシャゲやアニメ、ゲーム、コスプレ好きで男性もアニメやゲームが趣味だったしそこそこイケメンで高身長で情報だけ聞くとすごく合いそうじゃないの、と思った。
最初友人に「こういう人に会ったんだけど、どう思う～？」って聞かれたときは良い人に出会えて良かったじゃん！と関係を発展させるよう声かけてたけど
冷静になってなんかこの手の男怪しくも思えてきて不安になってきた。
背中押しまくったけどこのあと友人がマルチに勧誘されたりなんなりされたらどうしようとか考え始めて不安が…
【追記】
ブコメ見ました。反応ありがとうございます。
友人は27歳で結婚も考えてマッチングアプリを使っている子です。
可愛いから選り好みしなければ男に困らないはずのタイプだけど恋愛より趣味に生きてきてて、割とこれまでも恋愛に興味ありつつもすぐめんどくさがって相手との連絡途絶えさせたりしてたのに
今回はちょっと良いかも、と本人が乗り気だったので背中を押してあげたいと思ったんです。
ただあまり男性慣れしてない子でもあり（本人も自覚してる）、客観的に見たら怪しさマックスな男だけど友人が男慣れしてないから良く見えてるだけなのでは？と不安になって増田に書いたところです。
結婚後とかの話を振ってみるの良いかもしれませんね、既婚者とかなら渋ったりまだ早いとか言いそうですし。
あ、イケメンって書いたけど私は直接見てなくてもともと面食いな友人が見た目も嫌じゃないと言ってたので勝手に私がそこそこイケメンと翻訳（脚色？）してます。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
自分でやるとヒットしないんだよね
絵は天才的に上手いんだけど
アリオンは当たった方なんだろうか
ヴィナスとかスゴいんだけどね…
ゴーグで失敗したと思ってアニメ業界から撤退して漫画家になった気がする
なんかあんまり記憶がないというか、起伏がないというか、大風呂敷広げない
富野は大風呂敷広げて、意味深に思わせといてボカシてそのままにする気がする
というか、それはエヴァもそうだし、ツインピークスというかキューブリックっぽいのかも
本当は裏側は空っぽなのに、なんかスゴいものが詰まってるように見せる
オズの魔法使いじゃないけど
安彦さんは根が真面目なんだろう、その裏側にも詰めてしまうので、
だから、ガンダムORIGINもやっぱり蛇足感が否めないというか、
あまり裏側を詰めすぎると、裏側が見えないけど期待だけデカかった頃に比べると、
なんか、その歴史の裏側がこんなに小さくまとまってていいんだろうか、
そうならないように苦労しただろうというのは見えるのだけど、
所詮フィクションだし、漫画ではなくアニメなので、動きや見た目が重視されるわけで、
ORIGINは富野ガンダムに比べると絵は格段に綺麗だけど、凄く地味に思える
あと、ゴーグのデザイン見てると、やっぱりガンダムのデザインは安彦さんだよね
大河原氏はファーストガンダムの時点ではガンダムのデザインに貢献してない
本人も最近になって言うようになってきたけど、僕が貢献したのはザクです、だよね
玩具会社の意向も含めてああまとめ上げたのは本当にすごいと思う
多分、モビルスーツという名前通り、本当はテッカマンとかHALOみたいなサイズで、
それをスポンサーに巨大ロボットにしろと言われたんだろうけど、
名前そのまんまにした方がかえってその違和感が味になってしまった感がある
偶然も手伝って、汚いテレビの作画を一部修正して編集して劇場版にするとか、
ああいうのは安彦さんにはなんとなくできないというか、
全部やり直しそうなタイプに思える
そういえば、いしかわじゅんだったかに安彦漫画が酷評？されてたけど、
なんとなく言いたいことは分からなくもないところもあって、
要はいわゆるベタな漫画的表現というか、流線があったり、ベタウニフラッシュがあったり、
ジョジョのｺﾞｺﾞｺﾞｺﾞｺﾞみたいな露骨な擬音を使ったり、そういうのがない
アニメーターだからでもあるんだろうけど、アニメの作画を描いてる感がある
当然、中割の動画はない
しかし、アニメーターの漫画は酷い、特にコマ割りが酷い、という法則があって、
例えば結城信輝のヴェルバーサーガ？だったか、絵は上手いけどコマ割りが酷い
というか、もっと酷い人が普通で、アニメーターの人はコマの中の絵をちゃんと描こうとしてしまう
それよりもコマ割りが重要というか、漫画の文法が重要というか、
文法がちゃんとしていれば、コマの中の絵は意外といい加減でもいいというか、
だから、漫画が天才的に上手いのに、一枚絵はう〜んという漫画家は逆にまた多い気がする
そういう感じなので、安彦氏の漫画は漫画の文法には沿ってるし、コマ割りはおかしくない
たしかに独特な乾いた感じがあるが、それは個性というものだろう
宮崎駿のナウシカでさえ、コマ割りというか漫画の文法的にう〜んはときどきある
コマの順番が混乱する箇所があった気がする
漫画家はコマの順番を重視して、読者が読む順番に困らないようにして、
コマの中の絵はどうせ読み飛ばされるのだから、ある程度手を抜いて描くものである
そのへんを両立させてしまったのが大友AKIRAとかなんだろう
あの時代は漫画の作画コストが肥大してしまった一因だと思ってる
そして、それが今のパソコン時代になって楽になっているかというと、
未だに液タブにガリガリ描いて腱鞘炎にまでなってたりするというのが、
意外と現状だったりするのではないだろうか
みたいになる日が来るのかもしれないが、
なんとなくだが、それはそれで納得できない絵が出てくる気がするのである
悪夢のような絵が出てくるのではなく、AIがちゃんとした絵を出力するのだろうけど、
それでもワナビーとして絵を描いてる自分がそれで納得するのか甚だ疑問なのである
というのが楽しいというか、肝なのであって、
例えば、AIが自動作曲してくれて、それが素晴らしい曲だとして、
それが自分の脳内のイメージと直結しているわけではないわけで、
オチはない
【衝撃の事実】日本軽視の転売商材PS5、謎の山積み イケブクログ
ソフト売上など気にしない普通のユーザーは知らないかもしれませんが、昨今日本のコンシューマー業界ではPSの市場が急激に減少しています。
https://s.famitsu.com/ranking/game-sales/
上記のファミ通ランキングはあくまで協力店舗の集計でありAmazonなどは含まれないとはいえ、集計外の大型量販店や通販のみで特定タイトルが売れまくるとも思えないので実際に売れてるタイトルと大差はないでしょう。
見ての通りSwitch一色で、この週が特別なわけではなくPSタイトルのランク入りは0から多くても2〜3本程度が常態化しています。なぜなのか？
ゲーム機には商売的な寿命があり、サイクルが長くなりつつあるとはいえ6〜7年もするとソフトが売れなくなりリリースタイトルも減っていきます。
2013年発売のPS4は長く現役でしたがとうに全盛期は過ぎており、本体の事実上の販売終了やソフト売上の低下は自然な流れといえます。今頃はPS5へと緩やかに移行していたはずなのです。本来なら。
PS5は数字だけでいえば国内100万台以上を出荷していますが、『売ってるの見たことねえ』という人も多いでしょう、事実発売から一年以上経っても店頭に並ぶことは少なく転売が横行しています。
中国で販売されている正規のPS5は定価が日本より高いうえに海外アカウント作成が不可（一応抜け道はある）のためDLCに制限があり、並行輸入品を買うのが半ば常識となっています。
誤解している人も多いですが日本のコンシューマー市場は国別では世界2位、EUをひとまとめで計算しても世界3位の大きさです。日本の購買力が低いというより北米が桁違いなのです。
しかしここ数年日本のSIEJAは権限が縮小され続け開発スタジオも解散しました。日本の数分の1しか市場規模のないイギリスでのPS5出荷が60万台もあり、意図的な日本軽視は明らかです。
性能的にライバルに当たるXbox Seriesとの競争を優先していて、Xbox Seriesが雑魚すぎる日本市場はほっといてもエエじゃろと判断されているという説もあります。
昨年末、PS5の週販が5千台を切ったと話題になりました。Switch発売直前のWiiUで2千〜5千台売れていたといえば少なさがわかるでしょうか？ しかし次の週に記録を更新、販売台数は1133台でした。同じ週にSwitchは20万台を販売しています。
この数字は事実上の出荷停止で、売れた数は店舗の取り置きや流通の余りでしかありません。北米のブラックフライデーを優先したといわれていますが、よりによってハードの売れる年末に出荷停止したことで日本軽視が鮮明になりました。
ソフト販売不振でよくいわれるのが「今どきディスクとか買わない」との声です。PS5はディスクドライブ無しDL専用のPS5デジタルエディションもあり、実数が不明なDL版の売上が議論の的でした。
しかし最近、PSストアのDL版販売数は相当少ないのでは？ と言われています。
PS5DE版本体を見たことのある人はいるでしょうか？ DE版は週販100台前後の超希少種で、そもそも売れ行きを考慮に入れる必要のないレア機体です。
期間内にストアカード購入2万件達成で500円分をプレゼントというキャンペーンが最終総応募数19573件でまさかの不成立。
キャンペーン事務局の想定外だったらしく、期間終了後のサイトには『2万件達成！』の文字が表示されてしまったが後日取り消されました。
DL版の具体的な販売数は伏されているが推測できる材料はあります、PSストアとSwitchのe-shopのDLランキングと制作者の販売報告です。
PS・Switch・Steamなどのマルチ展開ソフトの場合、作者がTwitterで「どの機種が一番売れた」と報告することが多々あり、たいていSwitchがトップです。
PSストアで1位、e-shopで5位くらいのソフトでも「Switch版が大きく売れた」との報告が相次ぎ、PSストア1位って実はそんなに売れてないのでは？ と疑問が持たれていました。
レトロアーケードゲームの移植シリーズであるアーケードアーカイブスで発売されたタイトーの功里金団（くりきんとん）がPSストアランキングで上位に入ってしまいました。
特にエポックメイキングでもないマイナーなレトロゲーですら発売日にはトップに躍り出るPSストアランキングはどんだけ過疎なんだと話題になりました。
CC2の松山洋氏が公演で、DL版の比率は「PSのタイトルだと70％を越えることもあります」と発言。ニュアンスとしては「DL版はこんなに売れるようになったよ！」と前向きな意味合いだが、この発言でパッケージの売上からDL版の最大値を予測できるようになる。
結果、パッケージ実売数が少なすぎるPS5ソフトはDLで数倍売れているというファンタジーが否定され、DL版を含めても微増でしかないという事実が確定しました。
PS5自体はスペックを考えれば大変コスパの良いゲーム機……になるはずでしたが、入手の困難を考えると微妙な立場になってしまいました。
そしてメーカーとしてもユーザーの少ないPS5に全ツッパするわけにもいかずPS4へのマルチが前提なのですが、そのせいで「PS5じゃなきゃ駄目」という空気がいつまでたっても形成されません。
「俺はPS5持ってるしめちゃくちゃDL版買ってんよ！」という貴方。自分では気がつかないでしょうが、貴方は日本のPSユーザーの上位数％に位置するエリートです。しかし、一部の精鋭の存在は大局になんら影響を与えないのも事実なのです。
現在の日本のPSはワンダースワンやドリームキャストレベルのプラットフォームです。なんとかするには本体を欲しい人がいつでも買える状況を作るしかありませんが、世界的な半導体不足の影響で見通しは良くありません。
どう考えても100万人のユーザーはいないPS5ですが、2月発売のエルデンリングの売上で現在の本体普及率が大体明らかになるかもしれませんね。
