  |
はてなキーワード: 転送とは
初音ミクなどバーチャルシンガーを好む層の中では話題となっているのだけれど、2022年3月1日にCASIOからカシオトーンブランドの新製品「CASIO CT-S1000V」が発売開始となったけれど、このCT-S1000Vが最高なので語ってしまいたいと思う。
「カシオトーン？電子キーボードの？よく家電量販店に売ってるアレ？」と反応してくれる人は流石だ。
その通りで「家電量販店に並んでる電子キーボードでネコ踏んじゃったを弾いた。それはたまたまカシオトーンだった」なんていう経験を持ってる人は少なくはないと思うけれど、CT-S1000Vはそのカシオトーンブランドの新製品だ。
「電子キーボードなんて興味ないし」というそこのアナタ、実を言うと筆者は電子キーボードのみが好きというわけでなく様々なガジェットを愛するガジェットマニアなんだ。
筆者は単に電子キーボードをパソコンやスマホ、カメラなどに並ぶものとして見ていて、言ってみればそれは古き良きFM音源のPC-9801-86やPC-9801-26K、SoundFont全盛期のSound Blasterの延長線上にあると思っているわけだよ。
例えば多くのガジェットマニアが同意してくれると思うんだけど2000年代はパソコンや携帯電話(スマホ)が面白い時代で、2010年台はカメラが面白い時代だったわけじゃん？
では2020年代って何が面白くなる兆しを見せてるのかを筆者に言わせてみれば電子キーボードシンセサイザーなんだよね！ソフトももちろんなんだけどハードもメチャクチャ面白くなってるんですよ！
そんな電子キーボードシンセサイザーが面白くなっている2022年3月1日に発売開始したのがCASIO CT-S1000Vというわけだ。
前述した通りCASIO CT-S1000Vには「ボーカルシンセシス」というボカロのようなバーチャルシンガー音源が搭載されており、このボーカルシンセシスの技術ははてな界隈でも話題となった自然な歌声を実現したCeVIO Pro(仮)のテクノスピーチが関わっている！
実際に演奏してみると何より驚くのは和音が鳴ることで、これまでのハードウェアボーカルシンセサイザーは基本的に単音だった。発音機構を複数搭載することで和音を実現する方法はあったが、単一の発音機構で和音を、しかも処理能力を上げると販売価格へ跳ね返ってくるハードウェアで価格を抑えつつ和音を実現したことは素直に驚くと言って過言がない。
しかも、歌詞はiOS/iPadOSやAndroid OSなどから入力し転送することが可能で、AIベースで構築されたアルゴリズムによりボカロで言うところの調教がほとんど必要がなく、ただ弾くだけでボカロ文化黎明期で話題となっていた神調教を実現してくれるので驚きを超えた驚愕だ(初期のボカロはベタ打ちしただけでは聴くに堪えなかったよね。それも味ではあったけれど)。
ただ、こんなことは楽器系Webメディアやガジェット系Webメディア、情報技術系Webメディアなどが既に伝えているし、今はYoutubeもあるのでボーカルシンセシスへフューチャーしたレビューなんてのは(何故か海外を中心に。日本勢なぜ興味が薄い？)Youtubeで観て聴くことが出来る。
CASIO自身もそこが推しの1つであるようだし全面に出しているけれども、ガジェットマニア、シンセマニアからすると注目点はそこだけではない。何なら実際にCT-S1000Vの開発者だって「ボーカルシンセシスだけじゃないんだぞ！」と言いたいだろう。
ボーカルシンセシスは素晴らしい、ハードウェアで鳴るバーチャルシンガーはイケると踏んだCASIOの英断には敬意を表したいレベル。
確かに現状の電子キーボードシンセサイザー界隈で唯一足りないと言って良いのがボーカルシンセサイザーだ。
2020年以降アナログシンセサイザーもFMシンセサイザーもウェーブテーブルシンセサイザーも革新的で優秀なものが沢山リリースされたが、ボーカルシンセサイザーだけはそこに空白があった。
2020年以降、革新的なシンセサイザーを牽引しているのは間違いなくKORG。
KORGは2020年1月26日にウェーブテーブルシンセサイザーの「wavestate」を発売開始するのだけれど、これがかなり出来の良いシンセサイザーだった。
実は2010年代にソフトウェアのウェーブテーブルシンセサイザーとして「Xfer Serum」が登場してウェーブテーブルという方式そのものが徐々にその評価を上げて行っていた。そのなかでもSerumはソフトウェアウェーブテーブルシンセサイザーの代表格として捉えられていたんだ。
2022年現在では電子音が特徴的な楽曲でのSerum採用率は異常なほどで世界中のヒット曲を影で支える存在だ。
そんな注目集まるウェーブテーブルシンセサイザーだけど、前述した通りKORGはその機運へ即座に反応しwavestateを発売。
ウェーブテーブルシンセサイザーは複数の特徴的な音声波形を並べシームレスに繋げ、繋がった音声波形の任意ポイントを選択し発音させることが出来るという、言ってみればノンリニア音声波形編集ソフト(有名所のフリーソフトだとAudacityとかSoundEngine Freeとか)をそのままシンセサイザーにしたかのような発音構造を持つ。
シームレスに繋がった音声波形の任意のポイントを選択して発音するというウェーブテーブルシンセサイザーの方式からKORGはシーケンサーと相性が良いという発想を持ち、シーケンサー上で発音する波形や発音ポイント、音の高さ、波形に掛けるエフェクトを指定するウェーブ・シーケンシング2.0という高度なシーケンサー機能をwavestateへ搭載した。
これが凄かった凄すぎた。ウェーブテーブルシンセサイザーが流行ってることもあり、ソフトウェアウェーブテーブルシンセサイザーの中には明らかにwavestateを意識した機能を搭載したものも多数登場したんだ。
KORGの革新はこれだけでは済まなかった。2020年11月28日にはFMシンセサイザー「KORG opsix」を発売開始。ウェーブテーブルの次はFMである。
ハードウェアFMシンセサイザーと言えば原初にして最高峰「YAMAHA DX7」が有名だけれど、シンセサイザー界隈では「リングモジュレーターとFMはシンセサイザーの2大難解機構」と古くから言われており、少しパラメーターをイジるだけで大きく音色変化がして面白いが、予測がしにくく音作りが難しいとされてきた。
そのように難解とされるFMシンセサイザーへKORGは6つのノブと6つのフェーダーを搭載し、まるでアナログシンセサイザーのように感覚的な音作りを可能とさせてしまった。
そして実際に販売開始されるやいなやopsixへの反響はwavestateを遥かに超えるものとなった。wavwstateが凄すぎたのならばopsixは一体なんなんだと。こんな簡単に音作りできるFMシンセサイザーがあって良いのかと。でも我々の前へ確かにopsixは存在する。
しかしKORGの革新はwavestateとopsixだけでは終わらない。2021年8月8日「KORG modwave」が発売開始する。
modwaveもwavestateと同様にウェーブテーブルシンセサイザーで、次の試みは何と物理エンジンを搭載してきた。シンセサイザーに物理エンジンだぞ物理エンジン！
物理エンジン上でボールを転がし、その位置によって割り当てられたパラメーターを変化させるという機構だけれど、ボールには反発係数や摩擦係数を設定することができ、更にボールが転がるフィールドへ凹凸を作ることで直線的なボールの軌道すらも歪ませることが出来るようにした。
もちろんwavestateで得たモダンなウェーブテーブルシンセサイザーのノウハウを反映しつつmodwaveへ最適化した高度なシーケンサー機能である「モーション・シーケンス2.0」も搭載しており、なおかつ、ウェーブテーブルとして読み込む音声波形になんと前述したソフトウェアウェーブテーブルシンセサイザーSerumの音声波形もインポート可能としてしまった。大胆不敵すぎる！
こんなKORGの様子を見ていればライバル各社も大人しくしているはずがなく、Rolandは過去に製造販売した名作シンセの再現であるBoutiqueシリーズへあの小室哲哉が好んで利用した銘機JD-800の再現「Roland Boutique JD-08」を追加！Boutiqueシリーズへいつか追加されると言われていたが切り札を使うなら今しか無いと出してきた！
YAMAHAは2020年5月にライブパフォーマンスを意識した61鍵ステージキーボード「YC 61」を、更に鍵盤数を増やした「YC 73」「YC 88」を2021年1月23日に追加販売する。
その中でも特にYC 88はYAMAHAがアコースティックピアノの鍵盤を再現することに注力したステージキーボードで、そのタッチフィールは幼少期からピアノを習っていたものほど評価すると言われており、プロのピアニストからピアノ演奏系Youtuberまでが愛用することを現に見ることが出来るほどの完成度！
KORGは革新、Rolandは銘機、YAMAHAは演奏という激アツな2020年代の中でCASIOはCT-S1000Vで勝負しようというわけだ。
筆者は言ったCT-S1000Vはボーカルシンセシスだけではないと。
CT-S1000Vのボーカルシンセシス以外の特徴は何と言っても新しいAiX音源と、そのAiX音源を活かすために設けられたK1〜K3として割り振られている3つの物理ノブ！
カシオトーンと言われて何をイメージする？楽器音色選んで、リズム鳴らして、鍵盤叩いて、ハイ終わり。これだろう？
他に出来たとしてもデモを再生したり、サラウンド機能をONにしたり、ベロシティ感度(タッチ感度)を変えたり、残響感を調整したりとそんなもんだ。
あぁCASIOは鍵盤が光るやつもあるな。オモチャも含めて家電量販店で最も売れる鍵盤楽器はCASIOっていう地位を確立した大ヒット商品で大事な存在だが本題とは違う。
カシオトーンは楽器音色選んで、リズム鳴らして、鍵盤叩いて、ハイ終わりだが、カシオトーンであるにも関わらずCT-S1000Vは違う。
シンセサイザーを少しでも触ったことある、もしくはシンセサイザーで音作りをしている動画などを観たことがある、またはシンセサイザーを中心としたいわゆるマシンライブを観たことがある人ならシンセサイザーがミョンミョン鳴ったりミョーンミョーン鳴ったり音の長さや高さが変わるのを観たことがあるだろう。
他にはEDMなどの電子音楽が好きな連中には籠もった音が段々と明瞭にフェードインして行く定番の変化をよく聴かないか？
実はそれCT-S1000Vに搭載されている機能で実現可能なのだ！
そしてそれら変化をさせるパラメーター調整に利用可能なK1〜K3として割り振られている3つの物理ノブの存在が非常に大きい。
いや確かにアナログシンセサイザーの一般を考えればノブが3つというのは非常に少ない。もしシンセサイザーに詳しい人がこれを読んでいるならば「メニューに潜るんだろ？」と言うだろう。返せる言葉は「その通り」だ！
ただ、ノブがゼロなのと3つあるのとでは全く違う。音作りでも実際のパフォーマンスでも物理ノブはあったほうが良いに決まってる。
しかもよく考えてみろコイツはカシオトーンだぞ？楽器音色選ぶだけの「あ の カ シ オ ト ー ン」だ。
CT-S1000Vはカシオトーンなのにリード作ったりベース作ったりパッド作ったりドラム作ったり出来るようになったんだよ！
しかも61鍵で最大発音数64和音で最大パート数3だ。カシオトーンには唯一の良い部分として豊富なプリセット楽器音色があるけれども、そのプリセット楽器音色は802種類もある。アルペジエーターだって150種類もある。バーチャルシンガーもある。ステレオスピーカーもある。ノブも3つある。
これ値段いくらだと思う？55,000円だぞ？5万円台で10和音鳴れば御の字、普通に5万円台の単音モノフォニックシンセサイザーが存在するシンセサイザー界隈で64和音だぞ！？
アコピ鳴る、エレピ鳴る、ギター鳴る、ドラム鳴る、SFX鳴る、ボカロっぽいもの鳴る。802種類のプリセット楽器音色をレイヤー・スプリットで最大3パート重ねられて同時に鳴らせる。
おいおいおい・・・おいおいおいおい！55,000円！？カシオトーンなのにミョンミョンできるブンブンできるパワワワワできるシュオォォォできる、それが55,000円ってアンタ、中高生が親におねだりしたらワンチャン買ってもらえるレベルの価格帯じゃねぇか！
ボーカルシンセシス確かにスゴイよ！？でもCASIO CT-S1000Vは55,000円で買える64和音ポリフォニック・3パートマルチティンバー・バーチャルアナログ/ボーカルシンセサイザー(スピーカー付き)であるという事実の方にこそビックリするわ！
CT-S 1000Vを家電量販店は店頭に並べるべき、そして店頭に並んだCT-S 1000Vをアナタたち皆さん触ってみるべき。ピアノ経験者・シンセサイザーマニア・バーチャルシンガー好き・DTMユーザーはなおさら触ってみるべき。何度も言うけどコレ55,000円だぜ？嘘でしょと。
(トラバへ続く)
RDPは普通にファイルの転送もできますが...。そしてRDPの通信自体も、平文か弱い暗号化しかされていないことが多いです。
これが費用も安くて故障したとき、バックアップの NAS をメインに切り替えたら、わりとすぐ復旧できる。
一旦 USB 経由してるのは NAS は転送速度が遅いからで、うちの場合ネットワークの速度が 10MB/sec ぐらいしか出ん（勘違いでした 50MB/sec 以上は出てました）。
数テラ級の NAS とかになると、一晩じゃ絶対戻りきれないので、
運用しながらバックアップしながら復旧するのに、やっぱり2週間はかかる。
幸い障害時に一番に復旧させる必要な箇所のデータは CSV とかなので、先にそこのデータだけ復旧させたら、
あとはなんとか運用しながら復旧できる。
とりあえず大事なデータは NAS に入れろ！って言うのを周知。
個々のパソコンが壊れたら、
物理的に取り出して、USB 接続させてサルベージできるので、そこはあんまり困ってない。
（だったら RAID も同じ機器2台買って二重にしたいタチ）
取り回しのしやすい USB HDD を複数で多重バックアップさせておけば OK と思ってる。
NAS の HDD は Windows にマウント出来ないので一度 Linux 経由でマウントさせてサルベージさせてみようと思ったけど、差分とかどうやって取り出したらいいのか分からなかったし Linux 自信ないので難しかった。
それを踏まえると NAS が壊れたらややこしいので NAS のバックアップは必須。
困るのが
世代バックアップが出来ないぐらい（あんまりそんな問い合わせもないけど）
だから Mac の TimeMachine は個人であんなバックアップシステムは変態すぎる。
Buffalo の NAS は電源を付けたり消したりしているとすぐ壊れるので、24時間ずっと付けっぱなしの方が壊れない。
（Buffalo の昔のファン付き NAS はファンが壊れたらどうしようもなかったので、苦情も多かっただろう（ファン交換部品もオプションであったしね）、いま Buffalo の NAS はほぼファンレスなので耐久性も抜群に上がってきている）
あと Buffalo の NAS は機種によって勝手に画像のサムネイルを生成してしまう余計な機能がある NAS があるので、そう言った機能がないのがプレーンに使えてよい。
LS510DG や LS210DG など 510 210 の桁の品番が、そう言った余計な機能がない品番になる。
会社で使う分には勝手に色々なファイルを生成されるとバックアップに支障をきたすので、そう言った機能がない方がよい。
零細企業と言えども
NAS 4台もあるし、それにともなう USB 接続の HDD も必然的に多くなる。
この理屈で運用すると NAS の倍の USB HDD が必要になる、実際にそうしてるけど。
今余裕がないので予備の NAS でのバックアップが出来てないけど、まあなんとかなるか。って感じ。
「DiskMirroringTool Unicode版」のみ
この Unicode版じゃないと中国語のフォントなど文字によってバックアップ対象から外れてしまうし、4GB 以上のファイルもバックアップ出来ないので、
Unicode版な。
データは大切！これを分かってくれる人は意外と少ない。
さすがにこれはボったくりすぎ
秋葉原では500GBで5000円切ってる、2TBで1.8万切ってる
エレコム、PlayStation 5向けのヒートシンク搭載PCIe Gen4対応M.2 NVMe SSD
エレコムは1月26日、PlayStation 5への対応をうたったPCIe Gen4対応M.2 NVMe SSD「ESD-IPS」シリーズを発表、1月下旬に販売を開始する。価格は500GBモデルが3万2241円、1TBモデルが4万6376円、2TBモデルが8万4568円だ（いずれも税込み）。
ESD-IPSシリーズ
PCIe Gen 4に対応したM.2 NVMe SSDで、PlayStation 5への装着に適したアルミ製ヒートシンクを標準で搭載しているのが特徴だ。転送速度はPlayStation 5接続時でリード最大6100MB/s。PC接続時でリード最大7200MB/s、ライト最大2500MB/sとなっている。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
ただし、すぐには渡せないし、今年度来てない先生とかは勘弁してね。
もちろん中身を覗いたりしないよ。
あと授業期間中に送ってくれると嬉しい。
内容証明郵便の件やオープンレターについてはちゃんと読んでないので何の意見もないんだが、大学に非常勤講師のレターケースはない、
手紙を渡すまともな方法はないとかいう言説を見かけて頭に来たので書いている。
私は田舎の私立大学の事務職員で、郵便の受付・整理もやっている。
ていうか非常勤講師宛の手紙とか実際来るが？ 普通に渡しているが？
うちはレターケースがあるのでそこから取ってもらっているし、レターケースがないとして事務文書を渡す手段を作ってない学校とかあるの？
学事暦の連絡とか授業の成績評価依頼とか、事務文書なんかたくさんあって、それらを渡す手段作ってないとかやってられないだろう。
今はコロナ禍ってこともあってメールや郵送での連絡も増えてるけど、メール連絡がメインになったのはここ10年くらいで（早くても15年くら
いだろう）、それより古い大学はそれまでの渡し方があったはず。
本人が大学に来ないと受け取ってもらえないのは確かで、下手すると1か月2か月かかってしまうので、「すぐに何かをやめてくれ」というよう
な連絡をするには向かない。とはいえ、3か月くらい来ないのが確実なら転送するか、他の文書とまとめて本人宛に郵送するけどね。
ていうか、非常勤講師っていうと若い不安定な身分の研究者を思い浮かべるのかもしれないけど、大物や名誉教授も一時的に講義を
担当するという身分としてはまとめて非常勤講師の扱いなんだから、非常勤講師という立場に敬意を払わないとかありえないからね。
そりゃ気に入らない教員もいるけれど、全員を等しく教員として尊重して扱っているよ。
なので、そういう人たちの手紙を勝手に開けるとか、そんなこと絶対しない。書留が来たら（もちろん未開封のまま）事務所の金庫に
しまって本人に連絡して手渡しする。
内容証明郵便は来たことないけど、本人住所に転送をかけるかもしれないし、近々来る予定なら預かるかな。
この程度、田舎の小規模大学でもやってるんだから、都会の大規模校がやってないわけないぞと。
そちらの大学はやってないの？ 本当に？
GPUでもやっているのは知ってるんだが、グラフィックがリアルになるのに動きや物理シミュレーションが気になって仕方ない。
人の表情筋とか、布のシワとか。
レイトレも出来るようになったと言うわりに、違い分からんくらいだし、かといって精度上げると何時間かかるだって状態だし。
デスクトップPCってPCIスロット多いのにGPUが3スロット埋めて終わりで拡張性がない。
物理シミュレーション用の半導体でも出てきて拡張性追加してほしい。
GPUはGPUで、CPUから離れているからメモリを別途積まないといけないわ、メモリ積むから価格は上がるわ、
使ってる電話ってーのが別に事務所のはビジネスホンじゃないいわゆる家電話いわゆらなくてもなんだけど、
これ子機と親機で
なぜかなと思ったら
で、
そこでよ。
問題が発生するんだけど、
これそれぞれのデータを送りあったら上書きされちゃうのかな？問題。
無いデータだけ都合良く追加してくれるのかしら？
まあ試したらいいんだけど
いままで試す時間がなく
このまますごしていた感じよ。
はて？登録したのに名乗らないのはなぜ？って思っていたら、
親機には登録されていない子機だけのデータだと名前を言ってくれないみたいなのね。
たぶん恐らくそう言うことだと思うわ。
今の世の中自動的に何でも調整してくれると思ったんだけど
勝手に調整してくれないのは、
こう言ったなんか昔ながらのテクノロジーの電話なのかしら？って思ったわ。
まあよく分からないけど、
週明けは忙しいんだけど、
電話私苦手なのよね。
はぁ。
まあ弱音を吐いていても仕方ないので
そう言う時はもう出ないに限るわ。
って出なかったら出なかった出また掛かってくるので、
とりあえず
要件があったら、
メール出来てくれた方が助かるんだけど、
どうも困るのよね。
しかも今読んでメールそれ受信していたところだとなおのさらよね。
今見てたつーの！って言っちゃいそうだわ。
なんかもうちょっと電話まわりのテクノロジーがなにかこうもっと電話嫌いな人にも便利になってくれたらいいのになぁーって思うわ。
事務所ついてほっと一息まず入れたいじゃない。
ヒーコーは欠かせないわ。
グレープフルーツ1玉買ってきて
果汁搾って炭酸割りよ！
冷たいけど朝のシュワシュワいいわね。
炭酸も欠かせないわ。
すいすいすいようび～
今日も頑張りましょう！
| 規格名 | 仕様書上の名称 | マーケティング名 | 転送速度 | 形状 | 策定年 |
| USB 3.0 | USB 3.2 Gen1 | SuperSpeed USB | 5Gbps | Type-A Type-B Type-C Micro USB | 2008年 |
| USB 3.1 | USB 3.2 Gen2 | SuperSpeed USB 10Gbps | 10Gbps | Type-A Type-B Type-C Micro USB | 2013年 |
| USB 3.2 | USB 3.2 Gen2×2 | SuperSpeed USB 20Gbps | 20Gbps | Type-C | 2017年 |
見やすいように区切ってみたで。
小林秀雄はそう言われてるの知ってたんだけど。
https://www.youtube.com/watch?v=Fzrr1MIZiFY
なんか知らない人多いな。
そして知の巨人多いな。
AWSとかAzureとかGCPは内部ネットワークはunmeted（無課金）だからつまりクラウド自体の料金も安くなるメリットがあるんだよな。
10MBのファイルを100回ダウンロードするだけで1GBに達してしまうが、VDIなら画面情報の差分を圧縮して送ってるだけなので8時間の勤務で300MBとかですむ。700MBの差で100人社員がいたら1か月の転送量は1.4TBになってクラウドの追加料金がかかる。（たいていクソ高い）
ただし、VDI先のマシンでユーチューブとかにアクセスされると画面情報の差分もふえて転送量が増えてしまうから、URLブロックとかが必要かも。それについても端末に設定するんじゃなくてVDIのマシンに一括設定すればいいだけだから、遠隔設定が不要でラクになる。
このあたりの説明、わかってくれる人はわかってくれると思う。
