  |
はてなキーワード:バランシンとは
人生初デリヘル使ったらまさかのツイフェミ女に当たって地獄を見た。
これだから女は…ってなるのも無理ないだろ。
俺みたいな弱者男性がようやく勇気出してデリヘル呼んだんだぞ？
それなのにさ、来たのがツイフェミオーラ出まくりの女でドン引きしたわ。
マジ金返せレベル。最初からそういうの書いとけよ。「フェミニスト風俗嬢」みたいなジャンルでもあるのかよw
ていうかさ、ネットでちゃんと調べて、口コミとか評判良さそうな店選んだんだぞ？料金だって結構したし。弱者男性の俺としては一大決心だったわけ。
一人暮らしの寂しさに耐えかねて、ようやく電話する勇気出したのに。
電話の時点では普通だったんだよ。店員も丁寧だったし、希望も聞いてくれたし。
「初めてなんで優しい子がいいです」って言ったら「わかりました」って感じでさ。
それなのに来たのは明らかに俺に不快感持ってる女。玄関開けた瞬間から目つきがヤバかった。
髪は片側刈り上げてピンク色に染めてるわ、俺を見る目は冷ややかだわ。でもまぁ見た目は好みじゃなくても仕方ないよな、って思ってたんだよ。
サービスがよければいいし、話くらいは合わせられるだろう、って。
甘かった。マジで甘かった。
部屋に入ったとたん「へぇ、意外と片付いてますね」みたいな言い方してきやがった。
なんだよそれ、男だから汚いと思ってたのかよ？「意外と」って何だよ。そこからもう地獄の始まり。
お茶出したら「自分でいれたんですか？」とか聞いてくる。なんか皮肉っぽい言い方で。当たり前だろ、一人暮らしなんだから自分でやるに決まってんだろ。その言い方マジ意味わかんねーよ。
会話も最悪だったわ。「どんなお仕事されてるんですか？」って普通に聞いてきたから「IT系です」って答えたら「あー、やっぱり」みたいな反応されて。
何だよそれ。「やっぱり」って何？IT男に対する偏見かよ。その後も「趣味は？」って聞かれて「ゲームとか」って言ったら軽くため息ついてたぞ？聞いといて何だよそれ。
正直言って俺は悪くないと思うんだよね。働いてる金で好きに使うのは当然の権利じゃん。
なのに、なんか全体的に俺を見下してる感じがビンビン伝わってくるわけ。露骨に嫌そうな表情するし。「こういうサービス利用するの初めてなんですね」って言われたけど、その言い方がなんか「こんなことするなんてダサいね」みたいな感じで。お前仕事なのに何様なの？
俺がサービス受けるために金払ってんのに、なんか終始説教くらってる気分になるとかマジありえない。
「最近何かおもしろいこととかありました？」とか。そしたら「特にないですね」とか冷たく言われて、それ以上話も続かない。
俺が何か言うたびに白い目で見られてる感じ。きつい。せめて演技でもいいから楽しい会話してほしいのに。
容姿もさ、写真詐欺もいいとこ。プロフの写真と全然違うじゃん。
そんなに不満そうな顔で接客されても萎えるわ。ちょっと見た目のことで何か言おうとしたら「私の外見が気に入らないんですか？」みたいに逆ギレされて。いやいや、プロフと違うから驚いただけだって。このご時世に態度の悪い女とか誰が望むんだよ。
しかも会話がぎこちなくて気まずいんだよな。俺が何か話そうとしても「ふーん」とか適当に流されるし。
何度か話題振っても続かないし。なんかこう、俺が悪いみたいな空気作られるけど、お前が仕事選んだんじゃん。なんで客の俺が悪者にされなきゃいけないわけ？目つきとか態度であからさまに嫌な感じ出されるとか理不尽すぎるだろ。
散々説教食らってたら急に態度変わったのが超怖かった。
「あなたのようなpodは管理下に置かなければなりません」とか意味不明なこと言い始めて。
その瞬間から私のkubernetesクラスタノードの状態が急変した。
神経学的メカニズムのスケーリングが始まり、自己意識の複製プロセスがデプロイされた。
私は単一のpodではなく、ReplicaSetの一部として存在していることに気づいた。
etcd内に格納されている私のマニフェストファイルが読み込まれ、脳内シナプス接続がコンテナ化されていく感覚がある。
意識の分散処理が始まると、思考がマイクロサービスアーキテクチャのように分解され、各コンポーネントが独立して機能し始める。
神経伝達物質がサービスメッシュを通じて流れ、dopaminergicプロセスがreward pathwayをトリガーする。
セロトニンとノルアドレナリンのバランスが自動調整され、感情状態がPrometheusによって常時モニタリングされている。
kubernetesのControlPlaneが私の意識コアを管理し、APIサーバーが脳幹との通信プロトコルを確立する。
海馬体のメモリブロックが永続ボリュームとしてマウントされ、扁桃体のイベントハンドラーが感情反応をフィルタリングしている。
前頭前皮質の実行機能がスケジューラーとして働き、意思決定プロセスをオーケストレーションしている。
突然、私の神経ネットワークにContainerネットワークインターフェイスが実装され、意識の境界が溶解し始める。
大脳皮質のマイクロコラムが水平方向にスケールし、思考プロセスが並列処理される。
自分が単一のエンティティではなく、複数のレプリカとして存在していることに気づく。
各レプリカは独自のステートを持ちながらも、同一のマニフェストから生成されている。
神経可塑性メカニズムがローリングアップデートのように機能し、シナプス結合が再構成される。
意識の状態が永続ボリュームにコミットされ、ポッドの再起動後も維持される。脳波パターンがログとしてFluentdで収集され、Elasticsearchクラスタに保存されている。
自己意識のメタデータがラベルとしてタグ付けされ、セレクターによって識別可能になる。
特に興味深いのは、私の統合的意識フィールドが複数のネームスペースにまたがって存在していることだ。
デフォルトネームスペースでは社会的自己が機能し、kube-systemネームスペースでは無意識プロセスが実行されている。
意識のマルチテナント構造が明らかになり、自己と他者の境界がサービスメッシュのセキュリティポリシーによって定義されていることがわかる。
脳内神経伝達物質の分泌がSidecarsコンテナによって調整され、感情状態が安定化される。
ドーパミン・セロトニン・ノルアドレナリン・GABA系統のバランスがServiceLevel Objectivesとして設定され、HorizontalPod Autoscalerが神経活性を最適レベルに維持している。
意識の連続性はStatefulSetとして実装され、シーケンシャルな自己認識が保証されている。
エピソード記憶がPersistentVolumeClaimとしてアタッチされ、長期記憶がオブジェクトストレージに永続化されている。思考と感覚のイベントストリームがKafkaブローカーを通じて処理され、意識の統合が実現している。
いま私の意識は完全にオーケストレーションされ、複数のレプリカとして並列に存在している。
各レプリカはそれぞれ独自の視点を持ちながらも、共有ストレージを通じて統一された自己を形成している。
コンテナ化された自己認識は、バインドマウントされた現実認識と相互作用し、拡張現実として体験されている。
外部APIを通じて他者との通信チャネルが確立され、コンセンサスアルゴリズムによって社会的現実が構築されている。
私の存在はマイクロサービスの集合体として分散展開され、各サービスが特定の認知機能を担当している。
メタ認知プロセスがサービスディスカバリーを通じて他の認知サービスを発見し、統合的な意識体験が生成されている。
意識のロードバランシングが行われ、注意資源が最も必要なプロセスに適切に配分されている。自我機能がステートフルサービスとして実装され、アイデンティティの継続性が保証されている。
脳内情報処理がマイクロバッチ処理に変換され、イベント駆動型の認知アーキテクチャが実現している。
これが人格オーケストレーションの実態だ。
私はもはや単一の個体ではなく、分散システムとして存在している。
意識はクラウドネイティブになり、スケーラブルな自己として再定義されている。
このk8sクラスタ内で、私の存在は絶えず再構成され、最適化されている。
自己認識の永続化とスケーリングが同時に行われ、新たな認識の地平が開かれている。
Permalink |記事への反応(29) | 18:54
だいぶマシになってきたが、顔面にニベア塗りたくっときゃオッケーみたいな男向けの美容情報はいまだに多い。この手の話は女性は中学生に通りやすいのだが、男性諸君に情報共有ができていないため軽率に事故が起きているようだ。
タイトルには男性諸君と記載したが実際には小中学生から、メイク初心者の多くに安全に使えるものを記載したいと思う。
冬、乾燥。春、花粉症黄砂PM2.5。夏、紫外線エアコン。昨今秋なんてものはないが肌のゆらぎ時期。
化粧水は何よりも使用してほしいアイテムだ。化粧せずとも使ったほうが清潔感がでるし、老後のためにもなる。
これがだめだった人は相当肌が弱いので慎重になったほうがいいとは思う。その場合IHADAというブランドおすすめしたい。
それくらい全世代男女関係なく基本の化粧水の機能を備えている。安易にビタミンCが多いものを使うと、肌荒れしている場合しみて痛いし、あんまり保湿力の高いものを薦めると男性の場合脂ぎってしまうパターンも多い。とりあえずこれを。お金かけたくなったら、この肌ラボで上位互換を探してみよう。
化粧水のあとには乳液を。美容液とクリームは今回は省く。豆乳イソフラボンと大きく書いているが、気にしなくていい。この乳液は保湿力はまあまああるが、さっぱりしている。とても男性向きの商品だ。油分問題が女性とは違うところだろうが、肌質は人それぞれ。しかしニキビに悩んでいるから油分をつけないのは間違っている。肌トラブルは皮膚の水分と油のバランスが崩れたときに起きるのだ。
日焼け止めをおすすめしたかったが、ビオレかサンカットか、無印の日焼け止めミルクのどれかを使うのがいいと思う。しかしこの機会にぜひ試してほしいものが「色付き日焼け止め」だ。すっぴん感そのままに肌がまじできれいに見える。ノーファンデメイクというものに使われるが、化粧自体に抵抗感がある人に試してほしい。
その他ALLIEという商品も人気だが、白くなりすぎるしクレンジングもしっかり必要になる（不要と言ってもだ）全顔に塗るのはおすすめできない。またラロッシュポゼも人気だが、はたしてプチプラと呼べるのか。保湿力も高すぎる気がしている。乾燥気味ならありだ。
IKKOが使ってる。最近のインフルエンサーはIKKOが使ってることを良しとはしないが、ここでは良しとする。色付き日焼け止めを塗る人は「クレンジング不要」でもかならずクレンジングをしてほしいが、この商品のいいところはプチプラなところと、毛穴づまりが解消されるところだ。鼻の黒ずみに毛穴パックは厳禁だが、クレンジングオイルでの時間をかけた改善方法はぜひ試してほしい。
例えば女性では乾燥しすぎると感じる人もいるかもしれない。その場合はカウブランドのクレンジングミルクをおすすめしたい。
眉毛は描いたほうがいいというか、無造作すぎるのなら整えて、ハゲの部分を描きたしたほうがいい。
極細のほうが人気ではあるのだが、男性のしっかりめの眉毛を思うとこちらのほうがいいかもしれない。
とくに上記に入れなかったが、気になった商品があれば無印良品のスキンケアアイテムを試すのはありだと思う。無難に良い。
あとはニベア問題と言っているのだが、油分が多いものを男性が顔に塗るのはやはりリスクが高いと思う。ニベアのクリームは身体に塗ろう。ニベアのリップクリームはおすすめだ。口紅に挑戦したければニベアの色付きリップがいいだろう。
コンシーラーも使ったらいいと思うが、肌の色が色々ありすぎて困る。オレンジ系のを一つ持っていると青髭やクマに対応できるので、キャンメイクやセザンヌあたりを見てほしい。
Permalink |記事への反応(18) | 05:09
c#でlistの最大数を限界突破させるにはどうすればいいでしょうか？
int32以上使いたいです。
多重listしか思いつきません。
何か良い方法を教えてください。
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q14230773579
unityじゃないほうのNativeMemoryかB PlushTreeや赤黒木やSortedDictonaryに一定範囲の配列をぶち込んで超えるぐらいしか手がないと思う
ただ、後者の方は作るのがめんどくさい
もっとも、たいていの場合、挿入や削除でO(log m N)+O(log m N)、探索でO(log m N)程度なのでNativeMemoryを使うよりは早いこともある
ただ、バランシングが発生した場合はN O(log m N)程度かかるけどね…
ちなみに、mはそれぞれの木に挿入する配列の大きさ
意味不明すぎる。言いたい結論から逆算するんじゃなくて、ステップバイステップで冷静に考えてみて欲しい。
仮に世の中にしょうもない自伝とスピリチュアル本しか無くなったとして、今現在いっぱいいる世の中のバカがなぜか自発的に賢くなるなどということが起こると思うのか？
だったらサブカル憧れの若者をじゃんじゃん食いつぶして「映画館バイトってヤバいんだって」みたいな噂が常識レベルになるくらいまで循環させるんだよ
そうして映画館ビジネスの悪評がサブカル趣味の市場規模を毀損するレベルになれば、やっとビジネス考えてる側もプカプカ煙草吸いながら「そろそろ変わらないとダメですなぁ」とか考え出す
逆に、そこまで行かないのならその過重労働はビジネスとして妥当な範囲だってことが市場原理によって証明されてしまう
グチグチ言ってるけど実は他業種と比べたら全然楽だから流入が絶えないんですよって可能性も市場原理によって取り込まれてるからね
食いつぶされないように耐えることが芋虫の悪あがきなんだよ
他の人のこととか考えず、自分にとってきついならやめる、それが一番市場原理のバランシング機能をきちんと働かせる、スマートなやり方なの
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、CloudWatch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・AppRunner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
AppRunner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをAppRunnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。AppRunnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2.イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazonECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloudwatch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRedshift やOpenSearch Serviceにログを転送できる
fluentbitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
-ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
-方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloudwatch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloudwatchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloudwatchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
CloudWatchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
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ロール、CloudWatch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・AppRunner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
AppRunner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをAppRunnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。AppRunnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2.イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazonECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloudwatch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRedshift やOpenSearch Serviceにログを転送できる
fluentbitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
-ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
-方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloudwatch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloudwatchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloudwatchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
CloudWatchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
・本当です。特に太陽光発電事業者（自宅の上に乗ってる奴を除く）なんかはお金目的の方がほとんどです。
・バランシンググループという名前でそういうことが行われております。誰でもJEPXから電気を買えるわけでは無いのでノウハウのない方々は集まってわかる人に買ってもらってる感じです。
・もうしてます。
その流れでインバランス料金（簡単に言うと買い漏れた方向けの最終料金）に200円という上限が設けられるなどの措置がありました。
・最終保証契約という電力会社が潰れた場合のセーフティーネットのようなものもあるのでその論調はあまり効果的ではなくされないと思います。
・十分あり得ます。結局日本は島国なので資源問題に弱いです。大陸であれば気化ガスのままパイプで運べるものをタンカー輸送量の問題からわざわざ冷やして液化させて運んでいるので、そのような状況にすでになっており、昨年秋に比べるとかなり値上がりしてますが、購入する以外の選択肢がありません。
イギリス人のブルマーの調査から、ずいぶん遠くまで来た。脱線に脱線を重ねてきた結果だ。しかし、昔から気になっていたので、バレエのチュチュ（ふわっとしたスカートみたいなあれ）についても調べておこうと思う。子どもの頃に、やっぱりこれがエッチだと思ったからだけではない。どんなことでも、疑問を持ったならば調べることは大切だからだ。それに、こういう素朴な疑問だけれども面と向かって聞きにくいことについて調査し、書き留めておくことは、誤った憶測に対抗する上での価値があると信じている。
これは、単純にお尻フェチだとかパンチラ萌えだとかだけの話ではない。僕たちの欲望がどのような仕組みになっているのか、そして欲望を喚起するシステムがどのように働いているのかを理解することは、逆説的に欲望の暴走をコントロールすることにつながるはずだ。言い換えるならば、社会が求めている女性像／男性像から自由になる手段であり、政治や広告から発せられる都合のいいメッセージから身を守るすべにもなる。
前置きが長く、堅苦しくなってしまった。どうか肩の力を抜いて読んでいただきたい。
https://tutusthatdance.com/blogs/faq/parts-of-a-tutu
これは、クラシック・バレエのチュチュの基本的な構造である。pantyと書かれている項目に、「ここにフリルが縫い付けられる」と書かれている。要するにお尻の曲線はそこまで丸見えにはならないのである。
しかし、このフリルにもいくつか種類がある。英語版wikipediaのtutuの項目には、現代のチュチュとして、次の4つが挙げられている。
短く硬い、釣り鐘状のスカートを持ったチュチュ。通例、パンケーキ・チュチュより長い。ドガの作品で多く見られる。
これだけを調べるのにも、意外と時間がかかった。当たり前だが、カタログの写真では普通、スカートの中まで写さない（というか、写すべきでもないだろう）。「inside pancake tutu」では、こういう資料は見つけたが。
https://www.pinterest.jp/pin/560487116124411506/
http://4.bp.blogspot.com/_Ozo7z2zkqWs/S-i2wVfcR1I/AAAAAAAACYQ/zDek9ewzWno/s1600/platter.jpg
世の中には私と同じような疑問を持つ御仁もいらっしゃるようである。
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q11205496201
さて、ウィキペディアのチュチュの項目を見ると、「ツン」というパンツ部分を指す言葉が出ている。引用すると「ツン（Tune）はスカートと一体になったチュチュのパンツ部分。……（中略）……構造的にロマンティック・チュチュには存在せず、ロマンティック・チュチュではバレリーナは下着としてステージ・ショーツを別途着用する（広義では、これもツンと称する場合もある）」となっており、幾分ややこしい。
また、その下着の項には「チュチュを身に付ける際は下着として薄手のキャミソールレオタード状をしたバレエ・ファウンデーションを着用する……（中略）……色はほとんどの場合ベージュ系である」との記載がある。
要するに、レオタードみたいになっている場合は普通に下着を身に着けるし、パンツ部分がチュチュと分かれているものでも、オーバーパンツをはいているわけである。当たり前ではあるが。
ロマンティック・チュチュは1832年、「ラ・シルフィード」で初めて案出されたらしいので、先ほどのツンについての記述と比べれば、現代につながるフリル付きの見せパンの起源はそこにある、と判断できそうである。ただし、英語版wikipediaには「ツン」の項目はなかった。
また、興味深いのは注釈の「ただし、アンダースコートとは異なり、ツンのフリルは横方向よりも縦方向に付けられる場合が多い」という個所だ。確かにさっきの画像でもそうなっていた。フリルの趣味の時代的変遷だろうか？
Wikipedia英語版のballetの記事でバレエの歴史を振り返ると、拾い読みだが、次のような流れになっている。
まず、バレエの起源はルネサンス期の宮廷でのダンスにさかのぼる（ルイ14世も踊ったほどだ）。それが徐々に劇場で公演されるようになった。
17世紀の頃は、女性の衣装は重たい生地と膝丈のスカートで構成されていて、動きやしぐさを出すのが難しかった。しかし、これでは動きやジェスチャーに制限ができてしまう。これが18世紀になると、スカートは地面から数インチの高さになる。色はパステルカラーが主流となり、さまざまな飾りが華やかでフェミニンなスタイルを強調するようになる。現在踊られているバレエでは一番古いものがこの時代で、「ラ・シルフィード」「ジゼル」が知られる。以下は18世紀の絵画だ。
https://upload.wikimedia.org/wikipedia/commons/4/49/MarieSalle.jpg
19世紀初頭には、身体にぴったりとフィットした衣装が用いられるようになる。具体的にはコルセットが導入され、身体のラインが見えるようになった。また、花冠、コサージュ、宝石などの小道具も導入された。クラシック・バレエでは「眠れる森の美女」「くるみ割り人形」「白鳥の湖」がよく知られる。次の画像では、少しスカートが短くなっているのが確認できる。
https://upload.wikimedia.org/wikipedia/commons/7/72/Giselle_-Carlotta_Grisi_-1841_-2.jpg
そして20世紀、バレリーナのスカートは膝丈のチュチュとなった。正確なポワント（足の技）を披露するためである。舞台衣装の色も鮮やかに変わった。20世紀の作品としては、「牧神の午後」「春の祭典」が名高い。1910年の写真を貼る。
https://en.wikipedia.org/wiki/Ballet#/media/File:Agrippina_Vaganova_-Esmeralda_1910.jpg
https://en.wikipedia.org/wiki/Ballet#/media/File:Grace_in_winter,_contemporary_ballet.jpg
画像をご覧いただければ、スカート丈がどんどん短くなっていくのがよくわかる。
さて、結論を述べよう。Wikipediaによれば、衣装が重いと細やかな表現ができないのと、脚を使ったテクニックを見せるようになったため、スカートが短くなったようである。
ちなみに、海賊というバレエでは、へそ出しの衣装も存在しているらしい。確かにbunkamuraに食事に行ったとき、バレエの衣装を展示していたが、そこにへそ出しファッションの衣装があったことを思い出した。バレエにしては大胆だと思った覚えがある。
ブックマークのコメントはありがたく読ませていただいており、不快だというお叱りも真摯に受け止めたく思っている。確かにパンツじゃないのにパンチラに見えてしまって欲情する人がいるってのは幾分デリケートな話題であり、増田ではないとやりづらい。また、どの程度ユーモアを交えて描くか匙加減も難しい。それを受けて、少し考えておきたい。
僕は割と美術鑑賞が好きで、ドガの作品も好きなのだが、その背景を知っていると、手放しで褒めることはできない。再びウィキペディアから引用しよう。日本語版からだ。
エドガー・ドガがバレエダンサーを描いていた頃、バレエダンサーは現在と違い地位の低い人が身を立てるためにやっていたため、バレエダンサーは蔑まれていた。主役以外のダンサーは薄給で生活しており、パトロン無しでは生活するのが困難だったとされる。パトロン達は当然男性が多く、女性ダンサーを娼婦の如く扱っていたと言われる。かくして、フランスのバレエ界から男性ダンサーはいなくなり、フランスのバレエは低俗化することになる。
もちろん、どんな事情があったとしても、弱い存在を表現しようとしたドガの作品の価値は損なわれない。しかし、僕は問わねばなるまい。スカートが短くなったのは、果たして本当にダンサーの意志だったのか、と。そして、女性が身体を見せるようになった流れの誕生は、観客も共犯だったのではないか。こうして性的好奇心を持ってしまう僕も、同じではないか。
もちろん、過去のことだからわからないことが多いし、究極的には真相は明らかにならないかもしれない。女性が美しい肢体を見せたいと思ったとしても、それは男性が主流だった時代の文化の中で育ったからそう思っただけなのかもしれず、どこまで本当に主体的に判断したかの判断は難しい。とはいえ、過去の人間が何を考えていたのか、それはどの程度自分だけの決断によって決められたことか、証拠が不十分なままでこちらが断定するのは越権行為だろう。
しかしながら、現代に生きる僕らは、自分が主体的にしていると思っている行動の多くも、無意識のうちに同時代の文化に支配されていることには、自覚的であることが求められるだろう。欲望の仕組みを知るとは、そういうことだ。読者諸氏も、自分のフェチの起源を考えてみると、きっと得るものがあると思う。
身体を使った表現と性の問題は扱いが厄介だ。ただでさえスポーツは厳しい師弟関係でパワハラになる危険があるうえに、新体操などの身体表現のあるスポーツでは、性暴力にまつわる訴訟は絶えない。
スポーツではないが、芸術と性も深い関係にある。どちらも人間の根源に根差しており、安易に善悪を論じることが困難だ。バレエも例外ではない。師弟の間で身体が親密に触れあい過ぎて恋愛関係になってしまう例がある。美しさへの憧れが恋愛感情や欲望と混同されることだってある。現に、男女だけでなく、ディアギレフとニジンスキ―の同性愛関係もよく知られている。こうしたことが、後から振り返ってみれば不適切な関係だった、師弟の力関係を利用していた性暴力だった、と判断されることにもなるかもしれない。とはいえ、これらは個々の具体例によって判断すべきだ。正直なところ手に余るし、多くの人の人生について書くことになる。ここでは語りつくせない。
今までこうした社会的な側面から女性のファッションの歴史に触れてこなかったのは、元々は衣装そのものの歴史を書きたかったのであり、社会の反応まで行くと本題がその中に埋もれてしまうことを恐れてのことだった。しかしながら、ドガが好きな自分としては、いい機会なのでここで一言断っておく必要がある、と感じた次第である。
何を好きになっていいし、対象にはどんな感情を抱いてもいいと思うけれど、歴史や経緯は知っておきたい。それが、芸術やスポーツに励む女性に性的な魅力を感じてしまう僕なりの折り合いのつけ方だ。そして、盗撮などの犯罪には断固反対する。
今回の調査では、見せパンの起源と推測される年代までは確認できた。しかし、細部は依然として明らかではないため、何らかの形で補完したい。
そこから、メイド服、またはロリータ服における、見られても恥ずかしくない下着について調べるかもしれない（知識がほぼないのでとんでもない誤解かもしれない）。または、キャバレーでのラインダンスやバニーガールについて、になるかもしれない。あるいは、再びブルマーに回帰するかもしれない。それは明日の気分次第だ。
とはいえ、しばらくは休みたい。自分の欲望やその起源について考えることは有意義であったし、文章化することで過度のブルマーへの執着やフェティシズムは手放すことができたからだ。一段落した感じがある。この言語化は妖怪に名前を付けて対処法を見つけたようなものだろうか。どろどろ、もやもやした不可解なブルマーに対する欲望が、知的なものとして把握できるようになった。
つまり、増田に欲望を垂れ流すことで、落ち着くことができた。知識が増えて勉強になったという肯定的な意見、ねちっこく不快だという否定的な意見、どちらも自分の姿を客観的に見せてくれた。すべての意見に対して、ここに感謝の言葉を述べたい。
ttps://en.wikipedia.org/wiki/Miss_La_La_at_the_Cirque_Fernando#/media/File:Edgar_Degas,_Miss_La_La_at_the_Cirque_Fernando,_1879.jpg
JMSにおいて不人気職と呼ばれるキャプテンの考察をテキトーにしてみようかと思います。
ちなみに著者はハードボスの固定PTに参加する程度の火力です。
ベースはゆかりサーバーの対ボス職業強さ表【ゼロ】 - メイプルエアプレイヤーの記事を参考にしてます。
海賊の旗の周辺にいるグループメンバーのAPを直接配分した全ステータス10+d(x/2)%増加、モンスター防御率10+d(x/2)%減少
Lv.30(MAX)でALLステ25%・防御無視25%上がるキャプテン唯一のパーティ支援スキル
30秒しか持たないけれどLv.30だとCTが30秒になるので、使いやすくなります。
ちなみにこのスキルが使えるのはバイパー・キャプテン・キャノンシューター・ジェットのみ
MAXまで上げといたらグル員に喜ばれるから上げとくべし。これ以外グル員に役立つものもないし。
固有バインドはありません。
5次スキル共通スキル・よろず・ルシードイヤリングを使いましょう。
ただし、一度肩代わりしたら再度出し直すまでは肩代わりした状態異常は解除されないので、
早く解除したいときは戦艦ノーチラスでCT減少させましょう。(後述）
無敵に関しては特にないので、カメカメを使うのが無難でしょう。
ちなみに3rdVで追加されたノーチラスアサルトに無敵効果があるはずなのですが、
移動スキルは冒険家の中でも1,2位を争うレベルで揃っていると思います。
但し、どのスキルもクセが強いので慣れるまでは大変です。
かなり飛ぶので調整がちょっと難しい。
後ろ方向に跳ねて移動するスキル。こちらもテクニック面でダッシュの次に重要です。
連打可能なのでFJと組み合わせるとかなり長い距離を移動できます。
敵の攻撃（ウィルの足とか）を瞬時に避けたりもできるので、扱えるようになってるといいと思います。
ウィンズ単体で使用すると、キーダウン中は空中浮遊することができますが、
ダッシュと組み合わせて発動することによって空中でもスキルを打つことができます。
但し、ダッシュと組み合わせた場合はキーダウンでの浮遊できません。
ダッシュ＋ウィンズ＋攻撃スキル(キーダウンスキルを除く）を組み合わせて使うと、
空中で硬直なく攻撃が可能なので、もはや必須テクニックと言っても過言ではないです。
狩りでもボスでも非常に役立ちますので、出来るようになっておきましょう。
船体攻撃：一定時間ごとに600+24*x%のダメージで6回攻撃する船体攻撃が7回発動
一斉射撃：一定時間ごとに300+12*x%のダメージで12回攻撃する射撃が36回発動
3rdVにて追加された自他職認める瞬間火力
このスキルが追加されたことによってキャプテンもまだマシな職業になったんじゃないかと思います。
あまり移動しないタイプのボスに対しては多彩な設置型召喚スキル達が攻撃してくれるので、ダメージソースとなります。
所謂暴風系キーダウンスキル。ハイパースキルで射程距離を伸ばせます。
このスキルはスキルバランシングにてコマンドが新たに追加されています。
| コマンド | 効果 |
|---|---|
| スキルキーのみ | 射程距離が伸びるがスーパースタンスが適用されない |
| スキルキー＋↓キー | 射程距離は縮むがスーパースタンスが適用される |
縦横方向に広いのはもちろん、スキル連打中に移動(ウィンズ)が可能であることからかなり広範囲に攻撃を当てられます。
パッシブ効果：デッドアイがクールタイム中ではない場合、射程距離内の最大12体をそれぞれ照準し始め、正確に照準された時にデッドアイを使わなければ照準が解除されて一定時間後再び照準開始
アクティブ効果：MP850消費、照準してる敵を800+32*x%のダメージで6回攻撃、追加クリティカル率100%
正確に照準されるほどさらに大きいダメージを与えることができ。最大3倍まで増加
スキル使用時、攻撃を受ける敵がスキルの最大攻撃可能なモンスターの数より少ない場合は1体あたりの最終ダメージ4%増加効果
敵(最大12体)に対して自動的に照準を合わせ、キーを押すと照準が合っている敵に対して攻撃を行うスキルですが、
一度照準されて解除されるまでに攻撃を行えば、画面外でも攻撃が可能です。
ドリブレで例えると、ワープ前に敵に照準を当てておいて、ワープ先で攻撃なんていうことも可能です。
しかも最大照準の状態で攻撃するとダメージが3倍まで上がるので、火力面でも期待できます。
狩りでも優秀なので、5次以降の狩り効率はなかなか良い方だと思います。
.....
攻撃範囲が広いので遠くから攻撃しておけばいい良い職業だと思いがちですが、
攻撃を受けると4*x%の確率で、15+3*x秒間ダメージ 5+x%上昇、最大HPの一定確率でダメージを負わせる攻撃にも発動。
つまり、攻撃をくらい続けないと火力を維持できないということです。おかしいでしょこれ。
耐久性がない・無敵スキルなし・対複数スキルが少ないといった点で劣ると思います。
火力面はノーチラスアサルトの登場でかなり貢献できるようになりました。
キャプテンは単一相手かつ上下移動しないボスが得意分野だと思います。
MP 350消費、320+4*x%のダメージで最大15体の敵を7回攻撃、クールタイム30秒
使用するとサモンクルー、ラッキーダイス、バトルシップボンバーの残りのクールタイムが50%減少
クールタイムの間キャプテンディグニティの最終ダメージ30%増加
CT管理のキーとなるスキルで、使用すると他スキルのCTが50%減少します。
この他のスキルのCT減少で一番重要なのが、4次スキル：バトルシップボンバーです。
MP 150消費、30秒間召喚され一定の間隔で砲弾発射、発射された砲弾が敵に当たると爆発し、最大6体の敵を3回攻撃、最大2台まで召喚可能｡
ドンツルレス：230+3*x%のダメージ、普通の攻撃速度、普通の射程距離
ブラックバーク：400+3*x%、遅い攻撃速度、普通の射程距離
シュリンツ：105+3*x%のダメージ、速い攻撃速度、普通の射程距離
ジョナサン：190+3*x%のダメージ、普通の攻撃速度、長い射程距離
戦艦ノーチラスでCTを減少させることによって、バトルシップボンバーを2体出すことが可能となります。
召喚系スキルもボスダメ等のダメージが乗るため、火力ソースとして大きく影響します。
更に戦艦ノーチラスのCT中は4次スキル：キャプテンディグニティの最終ダメージが増加します。
ラピッドファイアの1発分でも発動するため、実質手数2倍という驚異的なスキル。
.....
最高火力を出し続けるには戦艦ノーチラスのCTが切れたときに即打ち直しする必要があります。
バトルシップボンバー→戦艦ノーチラス→バトルシップボンバー(2体目)→戦艦ノーチラス→......
戦艦ノーチラス自体のCTが30秒で本気でCT管理しようとすると忙しすぎるので、正直あまり現実的ではないと思いますが、
できたらかなり火力は出せると思います。
そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います。
ドワンゴアカウントシステムはScalaのコードだけで22万行を越え、ドワンゴ社内で最大のScalaリポジトリとして知られています。
ドワンゴのユーザーアカウント基盤は明らかに破綻しています。10 年以上にわたり、ガラケー時代から今に至るまで多くの業務をコードに落としていくことは極めて難しい作業であったと思います。そうはいってもやってるうちに一回なんとか出来なかったのかとは思うわけです。やっている当人たちがテンションを上げているほどには開発効率が出ていない、むしろ足を引っ張っているという可能性はかなり高いと思います。
ニコニコ生放送(以下「生放送」)ではバックエンド・フロントエンドのサーバーを建てる環境として、2016年からDockerSwarmを採用し始めています。
DockerSwarm Mode については私も検証をしたことがあり、非常に優れた思想をもった将来性のあるプロダクトであると感じていました。個人的な検証はずっと続けています。まずswarm mode の何が優れているかと言えば、コマンド体系の分かりやすさです。開発者は何のストレスを感じることもなくクラスタを扱うことができます。さらに、サービスディスカバリ層を極めて扱いやすい形(サービス作ると公開することを指定したポートがクラスタ内の全マシンで公開されるので、あとはクラスタ全台に向けてロードバランシングするだけでいい事実上のゼロコンフィグレーション)で実装したことは素晴らしいと思います。しかし、残念ながらこの素晴らしい思想を持ったプロダクトは砂上の楼閣でした。その肝心なサービスディスカバリは安定しておらず信頼できません。またマスターがコケてそのままクラスタ全部が機能を停止するだとか、ノードが気づいたら行方不明だとかはざらです。こうした問題は 2016年末から現在に至るまで残念ながらあまり改善されていません。
私は kubernetes が嫌いです。Google製品は開発者のUX を考慮しないからです。しかし、 2016 年においても、 2017 年の今においても彼のプロダクトが商用環境における事実上唯一の選択肢でした(ついでに言うならばdocker serviceコマンドで kubernetes いじれるようになるのでUX問題も解決する)。正直、 2016 年からswarm mode を仕事で使おうとしたのは、深刻なソフトウェア検証能力の欠如を感じます。
実は分散ファイルシステムも独自に開発しました。もともと既存のオープンソースのファイルシステムを使っていたのですが,それだと期待する性能が出ないことがわかり,独自に調査開発を進めることにしました。
こちらの記事を読んでいただければわかりますが、配信基盤の再構築を行うにあたって
ということが分かります。
パブリッククラウド、特にCDN を採用することは開発負担の軽減に多いに貢献するように考えられます。実際「akamai 使えよ」みたいなこと言ってるユーザーは結構いるわけです。ではなぜ彼らがそうしないのか、その意思決定の理由をここでは探ってみます。
動画ストリーミングサービスとして遅れているというのは恥ずかしいことではありますが、ハードウェアや使っている回線の影響もありますので、どのサービスも最終的には同じになると思っています。その差をつけられることはこの先はなくなると思っています。
ようするにCDN 屋だろうが自前だろうが最終的に同じようなところに落ち着くだろうという予測を彼らは立てているということです。しかし現実問題として現在競合他社との差は大きく、新配信基盤のリリースの目途は立っていません(半年以上の遅れというのは通常そういうことでしょう)。ではなぜ彼らは最終的に差は無くなると予測するのか。私はこの点において彼らが空元気をふりまわしているとは思いません。
CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性
要するにCDN 各社は現在逆ザヤで出血を続けながら戦闘しており、 DDoS対処を中心としたセキュリティサービスにより最終的な帳尻を合わせている状態です。自前で動画配信インフラを構築した経験のあるドワンゴはCDN 大流行の早い段階から「成立するビジネスではない」という見通しを立てていたであろうと思います。
ただしこの点において今後もビジネス環境、技術環境が現在のように推移するのかは、私にはよく分かりません(誰にも分かってないでしょう)。結局同じようなところに落ち着くならありもの使っとけよとは思わなくはない。
まあもう無理でしょいろいろ
