  |
はてなキーワード: チューニングとは
記事中の会話例に突っ込むのも野暮かなーとは思うんだけどさ、服って、日用品ではあるものの、値段に限らず割と特別な買い物じゃん。
新しいの着てたらまあ目につくしバレるしさ、よっぽど家族に知られたくない服とかでもない限り、普通に会話の中で
「今日服を買ったor買いに行く」
みたいな話にならねえ？ 少なくともウチはなる。
５Ｗ１Ｈ系の質問を、私は対話クラッシャー（潰し）と呼んでいる。この質問を受けると、脳は、心の対話のために使う回路を遮断し、問題解決型の回路が強く発火する。いわば、戦闘モードに入るのである。
これの是非はわかんないけど、そもそも日ごろからそんだけコミュニケーションできてない夫婦や親子だったら、どう話そうがキツイって話なんじゃね？
なんか次の記事で
When（いつ）、Where（どこ）、Who（だれ）、What（なに）、Why（なぜ）、How（どのように）で始まる５Ｗ１Ｈ型の質問は、この「問題解決の対話」を誘発するのである。
男性脳は、狩りをしながら進化してきたので、脳が、強いゴール指向に初期設定されている。すなわち、目標に一直線で、感情や「目の前のあれこれ」に気を取られないようにチューニングされている。そうしないと、危ないし成果もあげられないからだ。
（中略）
実は、母親も、子どもにそれをしてしまうことが多い。夫の問題解決型の対話にはかなりムカついているのに、母親は子どもには、それをしてしまうのである。
て言ってて、なんか尤もらしいような気もするけど、家族の雑談でそんないきなり不躾な質問する親とか、仮想親としても世代古くね？
今時の親世代でそんなやつ多いの？
GT7を遊びはじめて1ヶ月ほどになったので、なんとなく感想とか書いてく。
はじめて書くので勝手が分かってないです。読みにくかったらごめんなさい。
まずプレイする人は必ずやってるであろうカフェのメニューブック。飲み物とかは出てこない。
車全般が好きな自分としては、その辺走ってるコンパクトカーから皆大好きGT-Rやスープラ辺りの
大人気スポーツカー、ポルシェとかフェラーリみたいな高級ブランドまで色んな車に触れつつ、
実際に操作して攻略していく流れは結構面白かった。車良く知らない人でも多分安心。
難易度ハードだと普通に難しくて、ミニクーパー可愛い－！！アメ車曲がらねえ！ポルシェむっず！！とか
叫んでたら全部クリアするのに1週間強掛かった。尚メニューブックを進めていると、自然と車が増える。
結構名車揃いなのも嬉しいところ。基本的に貰える車で攻略出来るようになっているが、車種によっては
厳しかったりする。そんな時は乗りやすくて速い車を調達して攻略もできるし、従来の様に好きな車を
チューニングして突破する事も可能。コレクション系メニューは金で解決もできる。但し何気に旧車を
新車状態で手に入るチャンスでもあるので、個人的には面倒でもレースした方がいいと思う。
コースや各機能はメニューブックの進行に伴ってアンロックされるので、実質クソ長チュートリアルみたいなもの。
最初から好き勝手やらせろボケカスっていう御仁からするとちょっと面倒な仕様かもしれない。
個人的にな要望として、現時点で公開されているメニューブックは最終盤の物を除くと市販車に焦点を
当てたものばかりなので、将来的なアップデートで「フォーミュラカー」「プロトタイプ」「GT3」「スーパーGT」等、
レーシングカーをテーマとしたメニューブックが追加されるようになったらファンとしてはメチャクチャ嬉しい。
2つ目に難易度とかライバルカーについて。ライセンス、ミッション、サーキットエクスペリエンスなど全体的に
難易度高い。個人的にはやり応え十分で良かった。この辺りオールゴールドでクリアできる人は、一定の
実力があるという事でもあるので上達したい初心者さんとかは頑張って攻略したらいいと思う。お金貰えるし。
高難易度の理由としてはゴールド基準タイムが引き上げ、一部コースの天候変化、姿勢が乱れやすくなった挙動、
ライバルカーの高速化etc.この辺りが要因。カフェのメニューブック勝てないよぉ～って人は、ワールドサーキットのレースに
限り難易度を変えられるので素直に下げるのもアリ。
ライバルカーの振る舞いは過去作より結構進化したと思う。GTSでサイドバイサイドに持ち込むと「あっどうぞどうぞ～」と
言わんばかりに日和って、レースというよりも障害物ラリーみたいな様相を呈していた所、今作の場合サイドバイサイドで
粘るだけでなく自車が進入でアンダーを出そう物ならズバっとインを刺して抜き去ったり、特に活きが良いAIになると
AI相手にプレイヤーがやりがちなイン刺しミサイルみたいな振る舞いも見せてくれる。偶にホワイトライン突っ切って
カマ掘ってきたり、重要な局面でタイミング悪く接触してスピンさせられて、殺意が湧く事もそこそこあるものの、
個人的には過去作よりレースしてる感があってずっと良いと思う。
ただ相変わらず最後尾スタートからの追い上げみたいなレースが多く、その辺りもう少し新しさが欲しいとこ。
3つ目はシステム面。なんというか不具合やら何やらが多い。25周年やら決算に間に合わせる為の見切り発車感と、
アプデで直せばいいでしょ感は否めない。新コロで制作に遅れは大目に見てノーカンだととしても、発売延期がお家芸
みたいなシリーズが普通に発売されるとこうなるのかみたいな印象を持ってしまう。
発売直前の公式配信でプロデューサーが「GT7」は「GTSPORT」を内包しているみたいな事を仰っていたので、
ぐへへカフェのメニューブック終わったらおじさんオンラインレースしちゃうゾ～＾＾と息巻いていたところ、なんと
コース変更もロビー設定もロビー設定保存もできない事が判明した時は本当に驚いた。
5Pを経てオンライン対戦機能が実装された初ナンバリングタイトルのGT5ですら当たり前の様にできていた
機能がゴッソリ持って行かれ、代わりに得たのは無駄に細かい時間経過や空模様の設定機能。
二列ローリングスタートなども新たに追加されているので、全てがダメというわけではないけど
アプデでテコ入れされたものの発売当初サンデーカップより賞金の低いGr.3カップなど異常に渋い
賞金設定や、発売1～2週間辺りのアップデートで進行不可能になるバグ、セーブデータ破損、
買ったのに納車されず所持金のみ消失、ダートコースにスポーツタイヤとかウェット路面なのに
レーシングタイヤなど割と致命的なバグ報告が少なくない。もしかしたら今自分達が遊んでいるのは
幸い、ここのところ毎週サーバーメンテナンスに合わせて修正を入れるなど精力的に取り組んでくれたり、
将来的なアップデートについても結構具体的に言及しているのが救い。
ポリフォニーデジタルの皆さん、頑張って下さい。出来ればもてぎとシルバーストン復活してください。
まあまあ遊べるけど不具合とか明らかに足りないとこもあるよねってゲーム。不具合や機能削減が
惜しいけど、アプデで熟成されるはず。そう思いたい。
課金ゲー！クソゲーとか言う人もいるけど言われてる程酷くないと思うし、今までやった事無い人も、
久々にやろうかなって人も、興味あれば買って遊んでみてもいいと思うよ。
インテルやAMDなどのCPUと、NVIDIAなどのGPUとの間の接続はPCIeが速くなってきたとはいえ、
双方向にデータのやり取りが発生するような場合は帯域の狭さがネックになる。
ゲームのようにGPUに投げっぱなしにして、GPUとGPU側のメモリー、そしてディスプレイへの出力だけで閉じても大丈夫な場合は問題にならないが、
世の中そういうアプリケーションだけではない。
GPUカードが高くなっているのにも関わらず、CPU側のメモリーとGPU側のメモリーで似たようなデータをコピーしないといけないという、
なので、「M1 Ultra」のように、CPUとGPU間の帯域が大きく、ユニファイドメモリでCPUとGPUで共通のメモリーにアクセス出来るというのはメリットがある。
インターポーザを介して帯域は確保出来ているが、遠いメモリーへのアクセスへのレイテンシは防ぎ用がないので、
チューニングしようとするとインターポーザを介するメモリーアクセスが発生するかどうかは、プログラミングで気にする必要はあると想像する。
さすがのAppleも最先端プロセスを使う、予約していたTSMCのキャパを使い切る状態にしないといかず、数を出荷しないといかないのだろう。
良品選別したダイをインターポーザで接続して、出荷するチップ数を増やすというのは選択肢としてよかったのだろう。
トランジスタ数も多くなりすぎて、EDAツールで設計する時に必要になるシミュレーション時間も馬鹿にならないはずで、
タイミング検証が済、動くことが保証できている領域があるというのは、段階を踏んで設計するということでも合理的だ。
ただ機能面では、単純に倍になってしまっているため、ProResの本数が増えて、使い切るような状況があるのか？という不安はある。
「M1 Max」でそれなりにバランスを取っているわけで、「M1 Ultra」では多くなりすぎて使われない部分も出てくるだろう。
価格がそれなりに高いので、使われない部分があるというのは、あまり許してもらえないのではないだろうか。
インターポーザで接続する技術は確率出来たので、そこのIF周りは変更せずに「GPUだけ増やしたチップ」と「M1 Max」を接続する
といったのは考えられるが、数がでないといかず、そういうのを作れるかどうか。
他にデスクトップ向けだが低消費電力を売りにしているのは気になっている。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
361あとで/3270users 逮捕にそなえる人生継続計画 - やしお
257あとで/1505users 筑波大教授が著した無料の初心者向けPython教材「とてもわかりやすい」「素晴らしすぎる」 | Ledge.ai
246あとで/1545users 【独学可能】英語を話す方法 第二言語習得研究と行動科学に基づく英語学習ロードマップ - ポリグロットライフ | 言語まなび∞ラボ
228あとで/1502users 「1Byteが8bitに決まったワケ」についての長い話 まずは「バベッジの階差機関」から | ITMedia
228あとで/1340users 1on1 ノウハウの共有 | DevelopersIO
218あとで/2069users 音声合成業界に激震! もはや人間の喋り声、入力文字読み上げソフトVOICEPEAKはビジネス用途でも自由に利用可能｜藤本健の “DTMステーション”
172あとで/1057users 2022年ウクライナ情勢をより深く理解するための歴史文化背景雑学｜tadhara｜note
170あとで/912users BIOSからUEFIへ BIOSはなぜ終わらなければならなかったのか | ITMedia
168あとで/1175users 早く寝るために自分自身をハックする - 本しゃぶり
160あとで/1187users 富士通の撤退する「メインフレーム」ってそもそも何？ | koduki | Zenn
152あとで/854users 「界隈がざわつくほど超進化したPMBOK第7版」に私たちはどう取り組むか | 櫛田 瑞穂 | SpeakerDeck
148あとで/1128users 【登大遊】天才エンジニアの安寧を求めない生き方「日本で“大義”を持って働く選択は有利」 - エンジニアtype | 転職type
146あとで/1624users 元葬儀屋のワイが神奈川県警の悪事を淡々と話すスレ : うしみつ-5chまとめ- #神奈川
143あとで/756users 事業開発者・プロダクトマネージャーが知っておくべきフレームワーク7選｜Shin｜note
142あとで/1250users 「Google検索は死んでいる」がバズったので「まとも検索」を作った。：村上福之の「ネットとケータイと俺様」：オルタナティブ・ブログ
138あとで/728users OSS未経験「なにから始めたらいいかわからない…」←これを一気に解決する神リポジトリ - Qiita
137あとで/1202users 中小企業でApple製品を利用する前にやっておくこと | Hiroshiman | Zenn
128あとで/1357users 1分でわかるウクライナの歴史 | anond.hatelabo.jp
124あとで/1265users 【Mac】Kindle本も永久保存！自動スクショでPDF化する方法｜脱凡リーマンブログ
124あとで/1192users これだけは押さえよう！住所フォームの作り方 - ケンオールブログ
119あとで/928users 今のウクライナ情勢が分かりやすくなる…地政学漫画『紛争でしたら八田まで』が凄いと話題 | Togetter
118あとで/875users 「詩」というもの／谷川俊太郎｜「新潮」編集部｜note
118あとで/955users 子どもの自己肯定感を下げるNG言動 5000人を育成してわかった低い子の特徴（みらのび） - Yahoo!ニュース
115あとで/1012users 人は「楽と感じる方法」しか選ばないことを前提に、仕組みを作らなければならない。 | 桃野泰徳 | Books & Apps
112あとで/1044users 定年退職後に料理をはじめた父の「大葉漬け」がヤミツキ必至の美味しさでご飯がとまらない/ 大葉の大量消費にもオススメ！ | 砂子間正貫 | RocketNews24
112あとで/760users 東京都デジタル人材確保・育成基本方針 ver.1.0 | 東京都 | SpeakerDeck
111あとで/631users ソフトウェアアーキテクチャの基礎 | O'Reilly Japan
108あとで/652users ブラウザで動くサービスを作るときの技術選定 | moga | Zenn
105あとで/755users 2024年に制度変更「つみたてNISA」 始めるなら2022年が有利な理由 | マネーポストWEB
そもそもVtuberって金投げるに値するコンテンツちゃうやろ。
…
１年後か２年後にまた見返しておもろいなって思えるもんか？承認欲求や流行という文脈から切り離しても評価できるもんか？
お前がスパチャとか言って投げた合計金額を５年後か１０年後かに提示されて「経験としてこれだけの金や時間を費やした価値があった」って肯定できるか？他人にその価値を説明できるか？
価値は時代や状況に普遍じゃない。高級ホテルで飲んだコーラは都会で飲むコーラとは価値が違う。体験はその人がどんな状況にいるかに大きく左右される。
価値が変わりにくいエンターテイメントはあるが、そちらの方が優れているという理由はない。手堅い投資先というだけに過ぎない。
お前が絶対的価値を信じるあまり、祭りに乗り損ねている間に、他のみんなはそのノリを楽しんでいる。瞬間にしかない興奮は他では味わえないし、感謝の気持ちもその場所にしかない。丁寧なフィードバックもある。だからコスパは結構高い。
趣味のコスパについて、それを語るのを忌避する人は多いけど、俺はそういう視点はキライじゃないな。
小説や漫画のような従来型のエンターテイメントは、コミットすればするほど体験の価値は上がる。
だけどこちらが投入できる資源はほとんどが時間と集中力だ。情熱のエネルギーや想いをつぎ込む手段がほとんどない。即売会に行って作者に感謝するとか、グッズ買うとか、間接的でロスが多い。時間のない現代人にとって、スパチャにみられる贈与経済はコミット手段の革命であり、情熱解放の未開の領域だ。
Vtuberのほとんどは承認欲求とか性欲とかそういうもんを煽って金集めてる賎業をオタク向けにチューニングしただけで本質は同じ賎業やん。
いや賤業なんてない。職業に貴賎はない。
ここにも重要な認識のズレがある。スパチャに込めてるのは応援したい気持ちだよ。楽しい時間をありがとう、という感謝だし、純粋な賞賛なんだ。だから実感をともなった確信を持って、完全に肯定できる。
毎回上限五万赤スパの人間も、異常者かどうせ親金持ちニートだろう。ふつうの金銭感覚なら、バカじゃなければあんなホイホイ大金を出さない。ただのバカだ。ビジネストークで褒められてるだけなのに。哀れだ。
赤スパって一万とかやろ？お前も同じ穴の狢やぞ。
そもそもVtuberって金投げるに値するコンテンツちゃうやろ。にじさんじの一部とかピーナッツとかはある程度それに値することをしようとしてる奴はおるけど。
Vtuberのほとんどは承認欲求とか性欲とかそういうもんを煽って金集めてる賎業をオタク向けにチューニングしただけで本質は同じ賎業やん。「金を集めるに値するコンテンツ」じゃなくて「金が集まってるだけのコンテンツ」じゃん。
お前らの脂汗とチンカスのこびりついた札束で成り上がった以外の文脈で肯定できるか？１年後か２年後にまた見返しておもろいなって思えるもんか？承認欲求や流行という文脈から切り離しても評価できるもんか？
お前がスパチャとか言って投げた合計金額を５年後か１０年後かに提示されて「経験としてこれだけの金や時間を費やした価値があった」って肯定できるか？他人にその価値を説明できるか？
出来ないやろ。何がおもろいねん。もっと価値のあるもんに時間と金を使えよ。
お前も分かっとるやん。
そこに「リスナーに楽しんでもらう」という観点も「おもろいことやってやろう」って観点もない。
いかに金を巻き上げるかというゼロサムゲームをやってるだけなんや。
Vtuberとかに金を投げる言い訳で「活動を続けて欲しいから」みたいなのみるけど、それの無意味さが分かるやろ。そいつが辞めても別のやつに金投げるだけや。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
オーボエのようなダブルリードはチューニングがしづらい。だからオケはオーボエに合わせる。ダブルリードのファゴットなどなどあるが、伝統的にオーボエ。
ホルンは倍音が多い（管の長さが長い分他の金管楽器に比べ本来楽器の持つ音の上の方を使っている＝倍音が多い）から唇の振動が出す音に即反映される。下手なホルン奏者だと少しりきむだけで違う音が出てしまうのはそれが原因。
まぁ知らんけど。
世界で一番難しい楽器としてギネスに登録されている楽器は2つ存在する。
世界一難しい木管楽器としてオーボエ、世界一難しい金管楽器としてホルンが登録されている。
しかしながら、個人的には難しさというより、オーケストラでの振る舞いを見ていて「なんで？？？」という疑問のほうが大きかったりする。
まずオーボエ。
この楽器のオケでの大事な仕事の一つが、チューニングのA(ラ)の音を出すことなのだが…このチューニングの音色が微妙すぎる(人によっては明確に汚い)ケースが非常に多いのだ。
チューナーにらめっこで吹いているのでピッチは間違いなく正確なはずなんだが、音色が微妙なせいで、とても合っているように聞こえない。
具体的には、ヌラっとした音で吹かれると低く聞こえるし、一方でキンキンした音だと高く聞こえるんだよね。
そもそも、お前その音でソロ吹くのか？てかソロと同じくらい綺麗な音で吹かないのはなんでなんだぜ？とチューニングのたびに思う。
それこそ最高のリードで、最高に綺麗な音色で吹けば、コンマスの表情が曇ったり、ましてや文句言われることはなくなると思うのだが。
次にホルン。
毎度毎度ソロで「外すなよ、外すなよ、あー外した…」と、祈っては溜息出る始末。
それも擬音で表すと「プルッ」という、非常に耳障りな外し方をするんだけど、これわざとやってんの？
てかアマチュアのみならず、プロでも外すことが結構ある(とはいえ、流石プロだけあって注意深く聞かないとわからない程度の事故に収めている)のを踏まえると、ホルンは音が外れて当たり前の楽器なん？
仮想システムを構築するにあたり、CIFS しか使えない NAS をバックアップ用に選定してきた SI 屋さんが居たので、CIFS と iSCSI のどちらが早いのか、試してみました。
テストに使う NAS は QNAP の Turbo NAS TS110
http://www.tekwind.co.jp/products/entry_6719.php
です。もう６年以上愛用して、カビが生えてもおかしく無い程に古いし, Marvell 800Mhz という低スペックな Qnap NASです。 100Mbps 時代のモノです。
昨年、HDDがお亡くなりになったので、3Tb の HDD に交換しました。ファームウェアはこんなに古い機械でも、QNAP シリーズの最新バージョンが利用できます。
iSCSI は、今あまり見なくなりましたが SCSI ケーブル規格や、SASケーブル接続のハードディスクを、一般的なIPネットワークで規格で仮想化したものです。
マウントするホストシステム側は iSCSI initiator, ディスクストレージの機能を提供する側を iSCSI Target と呼びます。
ホストから「マウントするしない」はイニシエータ側のソフトウェア的な操作で行います。これは便利な機能で、ディスクの故障などで、一時的に物理的に取り外さなければいけない場合でも、ホストからの操作だけで実際のケーブル結線の脱着を行う必要がないので、今時での SAS の外付けディスクドライブの様に、ホストもシャットダウンして電源を切り、結線を外して修理、交換する、という必要がないので、ディスクデバイスの修理をホストの電源を止めないで実施できると言う、実に便利な事ができます。
という事で、仮想環境では実に使いやすいストレージデバイスなのです。
マウントするホスト側から見ると単純に SCSI/SAS のハードディスクに過ぎません。iSCSI のストレージをマウントしてからは、通常の増設ディスクの様にフォーマットして、ホスト側で使う一般的な XFS, ext4, NTFS などのフォーマットでフォーマットする必要があります。
Linux の iSCSI ターゲット側からは、内部にターゲットとして使う「巨大なファイル」が、どん！ とあるだけです。この巨大ファイルを、イニシエータ側に仮想ディスクイメージとして提供しています。当然シンプルな仮想イメージなので、ファイルそのものをバックアップコピーすれば、ストレージのイメージそのもののバックアップができます。
※ qnap NAS の場合、iSCSI イメージは、 /share/HDx_DATA/.@iscsi.img の下にドンと作られるようです。
[Solved]How to mount iSCSI file?
https://forum.qnap.com/viewtopic.php?f=180&t=25322
[/share/HDA_DATA/.@iscsi.img] # pwd
[/share/HDA_DATA/.@iscsi.img] #
[/share/HDA_DATA/.@iscsi.img] # ls -l
-rw------- 1 admin administ 6442450944 Nov 12 2017 iSCSI-2015ace1-5a078d66.000
-rw------- 1 admin administ 1073741824 Jun 24 09:52 iSCSI-lun4-5d0de534.000
-rw------- 1 admin administ 107374182400 Nov 4 2015 iSCSI-nss01-56399e1a.000
-rw------- 1 admin administ 5368709120 Nov 11 2017 iSCSI-nss2015-5a06cf6d.000
-rw------- 1 admin administ 21474836480 Jun 22 17:11 iSCSI-test-56b3ce90.000
-rw------- 1 admin administ 5368709120 Jun 22 17:11 iSCSI-test-56b3ce90.001
[/share/HDA_DATA/.@iscsi.img] #
※ とても重要
CIFS/NFS のファイル共有NAS と違い、iSCSI でマウントして一つのターゲットを制御できるのは、一つのホスト、一つのイニシエータだけです。複数のホストからイニシエータでマウントする（できちゃいます）と、ファイルの排他制御は行われないので、ファイルシステム自体の不整合が起こります。
つまりファイル共有という目的には向いていない、という事です。あくまでも iSCSI ターゲットはネットワーク上の仮想ディスクです。
もっとも、一つのホストからマウントしてファイルを保存して、いったんオフラインにして、ターゲットを別なホストからマウントする、という事はできます。また、ターゲットは一つの iSCSI デバイスで複数作れるので、１台の iSCSI 装置に複数のターゲットを実装して、複数のホストから別々のターゲットイメージをマウントする事は問題ありません。
極端な話、ホストのハイパーバイザーは USB メモリやSANブートさせて、後はマウントした iSCSI の仮想イメージ上で、仮想マシンを動かす、HDDレスなハイパーバイザー運用もできます。
物理的な転送速度は、ネットワークの速度とディスクデバイスの性能に依存します。当然 10Gb base のネットワークカード、HUB、高規格なケーブルを使えば、論理的な性能は 10Gbps です。大抵は NAS の性能がそこまで出ないのですけどね。ヨドバシカメラあたりで売っている 4,000 円程度の 1G HUB でも、そこそこの性能が出てしまいます。
距離は、IPがつながればどこでもなので、ホストコンピュータとメインのストレージを自社のサーバールームに置き、イニシエータを動かし、バックアップ用の iSCSI ターゲットをデータセンターに置く、なんてこともできます。
【送料無料】QNAP TS－431P2（ホワイト） NAS 4ベイモデル クアッドコア CPU ／ LAN 2ポート搭載 （TS431P2）
価格:56,145円
感想(0件)
iSCSI の耳慣れない言葉に LUN （論理ユニット番号 : Logical Unit Number）というのがあります。
昔の SCSI は、 SCSI バスアダプタに７番のIDを振り、残りの 0 ~ 6 のディスクや CD, Tape などに ID を振り分ける物理的な３ビットのディップスイッチやジャンパ端子が付いていました。これが SCSI アドレスです。
これが実に難物でした。特に、複数の SCSI バスアダプタカードをデュプレクス設定する場合、割り込み番号も別々にするので、手が滑ってジャンパピンを飛ばして床を這いまわって探したり、難解なディップスイッチを前に数日悩んだものです。
つまり一つのSCSIバスには 0~７の合計８台（うち大抵７番はSCSI バスカード）の物理ユニットデバイスがつながって別々に見えたという仕組みだったわけです。
ところが SCSI バスを使った Raid コントローラが出てくると、ディスクの鈴なりが、一つの物理デバイスに見えてしまうわけです。これを「論理的な仮想番号」に分割して、システムからは、単一の鈴なり Raid ディスクを複数の論理番号に分割したわけですね。
これが LUN というヤツです。
iSCSI 機器のターゲットも、内部のソフトウェア的に複数の論理デバイスに分割して、複数のホストコンピュータから複数の物理デバイスのように見せかけるわけです。
別々な LUN は一つ、あるいは複数の iSCSI 機器によって、複数のホストに別々のディスクデバイスとして見せかけるンです。
https://en.wikipedia.org/wiki/Logical_unit_number
Qnap NAS の場合、iSCSI ターゲットはウィザード形式で簡単に作成できます。EXT4 ファイルシステム上で、オンラインでも簡単にサイズの拡大ができるので、 Windows の Storage Server のように NTFS の VHD 形式ではないので、そこそこ性能が出ますが、いかんせん古さと遅さは否めません。
Qnap NAS の iSCSI ターゲットの設定は、偉そうな Linux 系サイトに書いてある程、面倒なことはありません。ストレージマネージャから iSCSI タブにあるウィザードに従って iSCSI ターゲット名に任意の名前を付けると IQN にその文字列が追加されるだけです。わざわざ vi エディタに「正確に」綴りを間違えずに設定する必要もありません。ここでは Chap 認証は付けませんでした。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16405779.jpg
機械は古いのですが、逆に言うと、「古くて遅い」ため、サーバーとNASとの接続プロトコルの性能差が、如実に現れる事になります。
QNAP TVS-951X 10GBASE-T/NBASE-Tポート内蔵
Windows10 の Microsoft 製 iSCSI イニシエータは「コントロールパネル」＞「システムとセキュリティ」＞「管理ツール」の中にあるので、ここで、設定済の iSCSI 「ターゲットを」 「検索」して選んで「接続」します。Chap 認証を付けておいた場合はターゲットで設定したパスワードが必要でしょう。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16412132.jpg
新規に作成して、接続した後は、フォーマットされていないため、ディスクマネージャからフォーマットして使います。ちなみに、フォーマットして利用した iSCSI ターゲットの仮想ディスクは、他のマシンでマウントすることもできます。つまりHDDを取り外して、他のPCに繋げる事と同じことですね。
ＰＲ
ちなみに opeSUSE で使うにはこんな感じになりました。
open SUSE Leap 15.1 で iSCSI NASを使ってハマった
https://islandcnt.exblog.jp/239328437/
一番イラつくのは、巨大なファイルの転送でしょう。という事で 3G 程ある SUSE Linux のインストール用DVDの ISO ファイルを CIFS でコピーしてみます。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16414334.jpg
３分１１秒かかりました。１Gビットネットワークで 12～3% 程度の帯域を使って通信しています。明らかに古いNAS の性能が足を引っ張っているようです。
スループットは 150Mbps 程度で全体の最大１５％程度でしょうか。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16415832.jpg
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16422170.jpg
初速は出るのですが、その後は、ボロイ TS-110 の性能がモロに出ます。それでも 20 MB/s から 25 MB/s 程度は出ています。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16423835.jpg
２分２５秒でした。 大体２０％程度のスループットです。
--
数字に弱い私の脳みそですが、 iSCSI は CIFS より 1.5倍くらい早い、という事が言えます。
Zabbix で QNAP TS-110 の I/O を見てみると、前半の CIFS アクセスより後半の iSCSI アクセスの山が高い事がよくわかります。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16425860.jpg
CIFS を使ったリモートディスクのマウントは、他のPCからもアクセスができる、というメリットがありますが、iSCSI は単一のホストからのアクセスしかできません。<--- これ重要.... -- もっとも、ターゲットストレージを複数作って複数のサーバーから異なるデータ領域にアクセスはできますが -- バックアップ用途や、サーバーの増設ストレージとして考えれば、良い選択であると言えます。
もっとも、iSCSI デバイスそのものは、ターゲット単位で別々なホストから接続できます。しかし同じターゲットで別々のホストからイニシエータから繋ぐと、とても笑いごとにならない事態になるので、普通やりません。
ハイパーバイザー同士で一つのターゲットを共有してライブマイグレーションはしたことはあります。
こうした性能のわずかな違いが、仮想化システムのハイエンドな領域で違いとなって出てきます。なお Qnap でも openiSCSI でも Windows Storage Server でも取った領域そのままのサイズのでかいファイルが作成されるようです。
国産 NAS の「ハイエンド」と称する「LANxxxx」などのモデルでは Windows Storage Server を使って NTFS フォーマットしています。Windows Storage Server は見た目 Windows サーバーそのものなのですが、ところどころちゃんとデチューンされているようで、SOHO向けが限度です。
こういった国産 NAS メーカーの製品カタログでは、「ハイエンド」は Windows Storage Server を搭載して、低価格のNASは Unix 系のシステムで「低価格」を謳っていますが、そもそも、上位モデルは、CPUやメモリの性能が高いものが使われています。性能が違うのは当たり前なのですが、あまり性能が出ないだろうと思います。
Windows Storage Server じゃなくて、ちゃんとした Windows Server と CAL 買えよな、という事なのですね。
このあたりは独自OSを NAS としてチューニングした Qnap や Synology, asuster などの iSCSI 機能付きの NAS を中規模ネットワークのミドルレンジの NAS として利用したほうが良いと思います。
仮想環境でのネットワークアタッチストレージ(NAS)は、本回線（構内LAN）とは切り離し、ストレージ専用のネットワークとして独立して運用させるのが基本です。サーバーとNAS間で凄まじい通信が発生します。サーバーNICが２ポート以上のものが推奨されます。
iSCSI はあくまでもネットワーク上のストレージのみの機能を提供するものであり、ファイル共有の手段ではない、という事です。
NAS をCIFSで使うと NAS が持つ独自のアクセス権限を設定しなければなりません。セキュリティも当然 NAS 独自の機能で設定します。
iSCSI はあくまでも「外付け SCSI デバイス」のネットワーク版なので、マウントする側のOSそのもののファイルシステム、セキュリティ機能、アクセス制限がホスト側の機能をそのまま利用できます。セキュリティ的には、マウントする際のパスワード制限しかないので、独自のストレージネットワーク内に配置すべきで、ユーザが使う構内ネットワークに配置すべきではありません。
店舗選択の際に裏側で飛ばしてるAPIが頻繁に504で死ぬくせにその旨の通知をせずユーザー操作のせいにするし、そもそもネットオーダー時のログインリクエストが死ぬほど重くてクライアントタイムアウトになったりする。
504の時点で異常に非効率なDBアクセスかロジックを実装してるんだろうけどリクエストの流量どうなってんだ？
まともに外形監視もチューニングもしてないことが明白なこのクソサイトを使うことはできない。
あと、webクライアント側でjsのdebuggerが効いたまま本番運用されてるのワロタ。
まあ今ではKotlinやフレームワーク使うから生でJava触ることはあんまないんだろうけど、
VMがある分のオーバーヘッドは永遠にiPhoneに勝てないんだよね。
もともといろいろなハードウェアに載せたいという趣旨でJavaを採用したんだろうけど、
実際はARM一強になっちゃったし、たまにx86でアプリ動かそうとすると動かなかったりで、
結局アーキテクチャに合わせたチューニングは必要という、中途半端な状況になってる。
まあ後知恵諸葛亮なんですけどね。
ネットで声がでかい人の意見が歴史修正するのはちょっとどうかな、と思う
そもそもiPhone登場の前にiPodの躍進っていうのが史実としてあるし欠かすことはできない
2001年に初代が登場、躍進したiPod nanoが2006年、iPhone登場が2007年。
iPod登場以前からmp3の音楽違法ダウンロードっていうのはインターネット普及と共にあって
しかし日本の各社、特にSONYはmp3の違法性から開発に難色を示し、MDを推進したりATRAC作ったりした
そんな中で空気を読まないAppleっていう会社がiPodを発表、mp3が聞けるってことで大流行。
当初はMacとしか連携できなかった（気がする）けど、WindowsでもiTunesが使えるという当時としてはビックリな対応で世間を賑わせていく。
時を同じくして韓国系メーカーも参入。Rioとか懐かしいよね。当時からFLACとかOgg Vorbisとかが聞けるっていう尖ったデバイスもたくさんあった。
後はCDにmp3を焼いたらフォルダ構成読み込んでアルバムとして再生してくれるやつとかもあったし、wmaとかとの覇権争いもあった。
日本は権利問題が難航して全然そういうデバイスが出てこず、確かAIWAが発売してちょっと世間が沸いたぐらいだった。
そんな中でiPodが更に躍進したのがiTunesのおかげ。これで音楽ダウンロードっていう商売を成立させた。
日本では長らくiTunesで聞けるのは洋楽だけで日本のレコード会社が提供してくれないっていう状況が続いたし
SONYはレーベル持ってたりするのでますます違法コピーの可能性があるmp3配信に難色を示して結果としては完全に出遅れた
そんな中でiPod nanoが発表。信じられないくらい小さくなっておしゃれになったデバイス。
巷を席巻して、もはや携帯音楽プレイヤーはiPod nanoって感じになった。
この頃から携帯電話が音楽再生機能を盛り込み始める。（まぁ前からあったがおまけみたいな機能だった）
しかし例によって音楽業界の圧力なのかSONYの圧力なのかmp3は聞けなかったりして独自仕様に固執。
SDカードは吸い出しできるからMemory Cardとか、いろんなプロテクションをかけてとにかく使いにくかった。
とはいえ邦楽聞くにはそれしか方法が無いので着うたフルとかLISMOとかが出て、SONYからはwalkmanケータイが発表。
まぁそれはそれで結構流行ったけど海外で流行るはずも無く完全にガラパゴスになった。
その頃からみんな噂してたのが
っていう話。
だって携帯とiPodの2台を持つのが面倒だから一台にしたいっていうのが強い思いとしてあった。
Appleが日本の携帯メーカーと協業するっていうイメージが全くなかったから出るならAppleから直接出るだろう、と。
2004年に発売されたNintend DSがタッチスクリーンでUIの新しい方向性を見いだしてた頃だったので
Appleが乗り込んでくるならタッチスクリーンだろうことは間違いなかった
そもそもiPod nanoのディスプレイがタッチスクリーンになるのでは？っていう話もあった。
だって当時のUIのCover Flowなんてタッチすること前提っぽい作りだったから。
まぁ乗り込んでくるなら名前は「iPhone」だろうっていうのもみんな予想してた。
iMacとかiPodとかiで攻めてるからまぁ安直にiPhoneだろうな、と。
ただ、全面タッチスクリーンっていうのは難しいだろうという意見が多かった気もする。
これは自分の周囲だけかもしれないが、キーを無くすと視覚障害者が使えないのでユニバーサルサービスの電話での導入は難しかろう、という話があった。
当時は画面が指紋で汚れるのは御法度でクロスをみんな持参してことあるごとに拭いてた。
その画面を触りまくる携帯なんて考えられない、というのが大勢だった覚えがある。
ところがAppleはやってのけた。そういう弱者は全部切り捨てて全面タッチスクリーンのiPhone発表。
日本の音楽業界と繋がりの強いdocomoは絶対に販売しないと分かってたのでソフトバンクの独占販売。
下手したら日本で販売されない可能性もあったからソフトバンクには感謝しかなかった。
このiPhone、iPodで音楽業界を席巻したAppleだから携帯業界でもやってくれるだろうという期待があった。
ただ初代は流石にしんどい部分が多くて音楽聴いてたら電池なくなるし電話はしづらいし画面が指紋だらけになるし。
とはいえiPod nanoとの二台持ち解消のためにiPhoneを選ぶ人も結構いた。
最初はiPodの代わりっていう立ち位置だったけどApple Storeがその情勢を変えていく。
Nintendo DSがゲームとして提供してたタッチパネルを活かしたいろんなアプリのアイデアがApple Storeでアプリとして提供される。
ギターアプリをインストールしたらギターになって、それを披露するとキャバクラでモテるとかいう噂が流れておっさんがみんなiPhone買い始めた。
後はもう、ご存じの通り、という感じ。
iPhone 3Gとか3GSとか4とかで盤石になっていった。
Androidが対抗馬として出てきたときはかなり期待したけれど
Appleのようにデバイスを固定化できるOSとは違ってAndroidはいわばWindowsを目指したので立ち上がりに失敗した。
デバイスに合わせてゴリゴリにチューニングすることができず、逆にOS内部まで手を入れるとアップデートが出来ないというジレンマ。
そもそも各社がOSのチューニングをするのはAndroidの思想に反するし、とはいえ各社サプライチェーンがあるからデバイスはバラバラ。
Androidでまともに動くケータイの方が少なかったけどXperiaは頑張ってた。そこはSONYの意地だったな。
とはいえAppleみたいにクローズド戦略じゃないから世界的にAndroidの数の方が多いのは当たり前
デバイス差分が大きいからAndroidっていうプラットフォーム上で商売するのはちょっとしんどいんだけど
ただ、Androidデバイスが多いとはいえ公開したアプリが全てのAndroidデバイスで動く保証が無いので
iPhone向けにアプリ作る方が実際に動くデバイスが多いのは確かだろうな
チューニングしないとまともに動くUIも作れないとか、クソだろ。
TeamsやZoomでさえネイティブアプリが主だというのに。
お前らWeb屋の大好きなIllustratorやPhotoshopをWebだけで使えるようなったら呼んでね。
