「バランシン」を含む日記 RSS

はてなキーワード: バランシンとは

2024-06-05

anond:20240604182159

嘘をつけないというより、状況に応じた建前と本音の使い分けというか柔軟なバランシングができなくて、

本音とそれ以外のバイナリーで行動してる気がする

本音じゃない場合は常にモヤモヤしてる

2023-12-27

anond:20231227092217

だったらサブカル憧れの若者をじゃんじゃん食いつぶして「映画館バイトってヤバいだって」みたいな噂が常識レベルになるくらいまで循環させるんだよ

そうして映画館ビジネスの悪評がサブカル趣味市場規模毀損するレベルになれば、やっとビジネス考えてる側もプカプカ煙草吸いながら「そろそろ変わらないとダメですなぁ」とか考え出す

逆に、そこまで行かないのならその過重労働ビジネスとして妥当範囲だってことが市場原理によって証明されてしま

グチグチ言ってるけど実は他業種と比べたら全然楽だから流入が絶えないんですよって可能性も市場原理によって取り込まれてるから

食いつぶされないように耐えることが芋虫の悪あがきなんだよ

他の人のこととか考えず、自分にとってきついならやめる、それが一番市場原理バランシン機能をきちんと働かせる、スマートなやり方なの

2022-07-14

anond:20220714122612

陰陽思想のやつらよりゲーフリのやつらの方がバランシング隅々まで考えてるよな

2022-07-04

アルータ18台のうち1台を交換しただけで輻輳するとかそんなことある

絶対キャパティ問題じゃなくて想定通りにロードバランシングが動いてない問題だと思う

2022-01-25

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービス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の登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービス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の登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

2021-08-20

美容垢見まくったメモ

①まず炭酸パックで肌を柔らかくする。

 (ソーダフォームプレミアム10,000 3,500円)

クレイ洗顔は肌に塗り込んでから泡立てる。

 本当は化粧筆で塗り込むのがいいらしいけど俺は道具使うとめんどくて続かないので指でやる。

 (DUO ホワイトクレイレンズは3,000円くらい。家にあるロゼットパスタでやりたい。)

酵素洗顔は鼻だけ。

 (雪肌精 酵素洗顔パウダー コンビニで500円くらい。)

④皮脂の分泌を抑える。

 (キュレル 皮脂トラブルケア保湿ジェル 2,000円くらい)

⑤異常角化を抑える。

 (エリクシール バランシンオヤスミマスク 1,980円)

⑥保湿は油っぽくないもの使用する。

 (今使ってるオードムーゲの乳液がさっぱりしてて好き。)

 (ベアミネラルオイルフリーモイスチャライザーも気になるけど高い。5,000円くらい)

まだイプサの化粧水買ったばかりだから保湿はこのまま、炭酸マスク酵素洗顔だけ買おうかな。

その他

クレンジングは夢見るバームも気になる。

 クレイ洗顔と併用しないほうがいいのかな?

シカデイリースージンマスクも気になる。

 その前にティーリーを使い切る。

ビタミンC誘導体入りの化粧水はやっぱりいいらしい。

 俺は肌荒れするから使えない。サプリビタミンCを摂る。

2021-01-21

anond:20210121172106

からにわか範囲

・本当です。特に太陽光発電事業者(自宅の上に乗ってる奴を除く)なんかはお金目的の方がほとんどです。

バランシングループという名前でそういうことが行われております。誰でもJEPXから電気を買えるわけでは無いのでノウハウのない方々は集まってわかる人に買ってもらってる感じです。

・もうしてます

その流れでインバランス料金(簡単に言うと買い漏れた方向けの最終料金)に200円という上限が設けられるなどの措置がありました。

・最終保証契約という電力会社が潰れた場合セーフティーネットのようなものもあるのでその論調はあまり効果的ではなくされないと思います

・十分あり得ます。結局日本島国なので資源問題に弱いです。大陸であれば気化ガスのままパイプで運べるものタンカー輸送量問題からわざわざ冷やして液化させて運んでいるので、そのような状況にすでになっており、昨年秋に比べるとかなり値上がりしてますが、購入する以外の選択肢がありません。

原発は動かせるなら動かすべきだと思います

どうせあるだけでメンテナンスしなければならないので、宝の持ち腐れになってしまってます

2020-11-24

anond:20201124014015

実際の作業バランシングは各家庭でご相談くださいに尽きるけど

仕事家事育児のための原資を調達するための手段だってのを意識しない人多いよね

2020-09-17

バレエチュチュスカートの中のフリルパンツ

今回もブルマーとは関係ないが

イギリス人ブルマー調査から、ずいぶん遠くまで来た。脱線脱線を重ねてきた結果だ。しかし、昔から気になっていたので、バレエチュチュ(ふわっとしたスカートみたいなあれ)についても調べておこうと思う。子どもの頃に、やっぱりこれがエッチだと思ったからだけではない。どんなことでも、疑問を持ったならば調べることは大切だからだ。それに、こういう素朴な疑問だけれども面と向かって聞きにくいことについて調査し、書き留めておくことは、誤った憶測に対抗する上での価値があると信じている。

これは、単純にお尻フェチだとかパンチラ萌えだとかだけの話ではない。僕たちの欲望がどのような仕組みになっているのか、そして欲望喚起するシステムがどのように働いているのかを理解することは、逆説的に欲望暴走コントロールすることにつながるはずだ。言い換えるならば、社会が求めている女性像/男性から自由になる手段であり、政治広告から発せられる都合のいいメッセージから身を守るすべにもなる。

前置きが長く、堅苦しくなってしまった。どうか肩の力を抜いて読んでいただきたい。

実際、チュチュスカートの中ってどうなってるの?

まずは以下の画像をご覧いただきたい。

https://tutusthatdance.com/blogs/faq/parts-of-a-tutu

これは、クラシック・バレエチュチュ基本的構造である。pantyと書かれている項目に、「ここにフリルが縫い付けられる」と書かれている。要するにお尻の曲線はそこまで丸見えにはならないのである

しかし、このフリルにもいくつか種類がある。英語版wikipediaのtutuの項目には、現代チュチュとして、次の4つが挙げられている。

他にも、日本語版記事には、

短く硬い、釣り鐘状のスカートを持ったチュチュ。通例、パンケーキチュチュより長い。ドガ作品で多く見られる。

https://en.wikipedia.org/wiki/Edgar_Degas#/media/File:Edgar_Degas_-_The_Ballet_Class_-_Google_Art_Project.jpg

これだけを調べるのにも、意外と時間がかかった。当たり前だが、カタログ写真では普通スカートの中まで写さない(というか、写すべきでもないだろう)。「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

2020-08-02

数千倍まではロードバランサーチームがちゃんバランシングしてくれればたえるはず で 数千倍にたえられれば 国内国民が一人数台のパソコンをつかっても たぶん耐えられる設計にはなってるはず

2020-04-21

anond:20200421124322

というか今どきAWScloudfrontとかで申し込みページはバランシングしてるもんで、

申し込み実行処理だってAPI Gateway保護してるだろうから、「ページが見えない」とか今どきの感覚から言えば論外なんだぞ。

2019-05-31

メイプルストーリー キャプテン 考察

最近職業考察があるみたいなので、

JMSにおいて不人気職と呼ばれるキャプテン考察をテキトーにしてみようかと思います

ちなみに著者はハードボスの固定PTに参加する程度の火力です。

 

ベースゆかりサーバー対ボス職業強さ表【ゼロ】 - メイプルエアプレイヤー記事を参考にしてます

 

1.パーティ支援スキル

5次スキル冒険家海賊共通スキルパイレーツフラッグ

 MP500消費、30秒間海賊の旗を召喚

 海賊の旗の周辺にいるグループメンバーAPを直接配分した全ステータス10+d(x/2)%増加、モンスター防御率10+d(x/2)%減少

 クールタイム60-x秒|

 

Lv.30(MAX)でALLステ25%・防御無視25%上がる キャプテン唯一のパーティ支援スキル

30秒しか持たないけれどLv.30だとCTが30秒になるので、使いやすくなります

ちなみにこのスキルが使えるのはバイパーキャプテンキャノンシュータージェットのみ

MAXまで上げといたらグル員に喜ばれるから上げとくべし。これ以外グル員に役立つものもないし。

 

2.バイン

固有バインドはありません。

5次スキル共通スキル・よろず・ルシードイヤリングを使いましょう。

 

3.生存ユーティリティ

状態異常を肩代わりしてくれるスキルがあります

 

3次スキルアセンブルクルー、4次スキルクルーコマンダーシップ

 ノーチラスにいる船員をランダムで2人召喚するスキル

 召喚する船員によって効果が異なる。

 

召喚した船員が状態異常を肩代わりしてくれます

ただし、一度肩代わりしたら再度出し直すまでは肩代わりした状態異常は解除されないので、

早く解除したいとき戦艦ノーチラスでCT減少させましょう。(後述)

 

無敵に関しては特にないので、カメカメを使うのが無難でしょう。

ちなみに3rdVで追加されたノーチラスアサルトに無敵効果があるはずなのですが、

バグなのか仕様なのかわからないですが発動しません。

 

4.移動スキル

移動スキル冒険家の中でも1,2位を争うレベルで揃っていると思います

但し、どのスキルもクセが強いので慣れるまでは大変です。

 

1次スキル:オクトプッシュ

冒険家の中で1回で一番長距離を飛べるFJ

かなり飛ぶので調整がちょっと難しい。

 

1次スキルダッシュ

キャプテンをする上でテクニック面で重要になるスキルの一つ。

ダッシュ使用したテクニックについては後述します。

 

2次スキルバックステップショット

後ろ方向に跳ねて移動するスキルこちらもテクニック面でダッシュの次に重要です。

連打可能なのでFJと組み合わせるとかなり長い距離を移動できます

また、FJで飛びすぎたときキャンセルにも使えます

敵の攻撃ウィルの足とか)を瞬時に避けたりもできるので、扱えるようになってるといいと思います

 

2次スキルウィンズ

上方向に飛ぶスキル

ウィンズ単体で使用すると、キーダウン中は空中浮遊することができますが、

ダッシュと組み合わせて発動することによって空中でもスキルを打つことができます

但し、ダッシュと組み合わせた場合キーダウンでの浮遊できません。

 

ダッシュウィンズ攻撃スキル(キーダウンスキルを除く)を組み合わせて使うと、

空中で硬直なく攻撃可能なので、もはや必須テクニックと言っても過言ではないです。

狩りでもボスでも非常に役立ちますので、出来るようになっておきましょう。

 

5.瞬間火力

5次スキル:ノーチラスアサルト

 MP1500消費、最大15体の敵を攻撃詠唱中は無敵

 船体攻撃一定時間ごとに600+24*x%のダメージで6回攻撃する船体攻撃が7回発動

 一斉射撃一定時間ごとに300+12*x%のダメージ12攻撃する射撃が36回発動

 クールタイム:180秒

  

3rdVにて追加された自他職認める瞬間火力

このスキルが追加されたことによってキャプテンもまだマシな職業になったんじゃないかと思います

 

6.継続火力

まり移動しないタイプボスに対しては多彩な設置型召喚スキル達が攻撃してくれるので、ダメージソースとなります

 

7.攻撃範囲

攻撃範囲はかなり広いです。

 

4次スキル:ラピットファイア

所謂暴風キーダウンスキルハイパースキルで射程距離を伸ばせます

 

4次スキル:ファシリティレイ

横方向ともに範囲が広いです。

このスキルスキルバランシングにてコマンドが新たに追加されています

コマンド効果
スキルキーのみ射程距離が伸びるがスーパースタンス適用されない
スキルキー+↓キー射程距離は縮むがスーパースタンス適用される

 

5次スキルバレットパーティ

とにかく踊りながら攻撃する連打系スキル

横方向に広いのはもちろん、スキル連打中に移動(ウィンズ)が可能であることからかなり広範囲攻撃を当てられます

 

5次スキル:デッドアイ

 パッシブ効果:デッドアイがクールタイム中ではない場合、射程距離内の最大12体をそれぞれ照準し始め、正確に照準された時にデッドアイを使わなければ照準が解除されて一定時間後再び照準開始

 アクティブ効果MP850消費、照準してる敵を800+32*x%のダメージで6回攻撃、追加クリティカル100%

 正確に照準されるほどさらに大きいダメージを与えることができ。最大3倍まで増加

 スキル使用時、攻撃を受ける敵がスキルの最大攻撃可能モンスターの数より少ない場合は1体あたりの最終ダメージ4%増加効果

 クールタイム30秒

 

職業で1番だと思われる広範囲スキル

敵(最大12体)に対して自動的に照準を合わせ、キーを押すと照準が合っている敵に対して攻撃を行うスキルですが、

一度照準されて解除されるまでに攻撃を行えば、画面外でも攻撃可能です。

リブレで例えると、ワープ前に敵に照準を当てておいて、ワープ先で攻撃なんていうことも可能です。

しかも最大照準の状態攻撃するとダメージが3倍まで上がるので、火力面でも期待できます

狩りでも優秀なので、5次以降の狩り効率はなかなか良い方だと思います

 

.....

攻撃範囲が広いので遠くから攻撃しておけばいい良い職業だと思いがちですが、

その考えを覆すスキルこちらになります

4次スキルカウンターアタック

 攻撃を受けると4*x%の確率で、15+3*x秒間ダメージ 5+x%上昇、最大HP一定確率ダメージを負わせる攻撃にも発動。

 [パッシブ効果:受けるダメージ5+x%減少]

 

まり攻撃をくらい続けないと火力を維持できないということです。おかしいでしょこれ。

 

ボスとの戦いやす

耐久性がない・無敵スキルなし・対複数スキルが少ないといった点で劣ると思います

火力面はノーチラスアサルトの登場でかなり貢献できるようになりました。

キャプテン単一相手かつ上下移動しないボスが得意分野だと思います

 

CT管理

キャプテンは火力を出すためにCT管理重要になってきます

4次スキル戦艦ノーチラス

 MP 350消費、320+4*x%のダメージで最大15体の敵を7回攻撃クールタイム30秒

 使用するとサモンクルーラッキーダイスバトルシップボンバーの残りのクールタイム50%減少

 クールタイムの間キャプテンディグニティの最終ダメージ30%増加

 

CT管理キーとなるスキルで、使用すると他スキルCT50%減少します。

この他のスキルCT減少で一番重要なのが、4次スキルバトルシップボンバーです。

 

4次スキルバトルシップボンバー

 MP 150消費、30秒間召喚され一定の間隔で砲弾発射、発射された砲弾が敵に当たると爆発し、最大6体の敵を3回攻撃、最大2台まで召喚可能

 クールタイム:30秒

 ドンツルレス:230+3*x%のダメージ普通攻撃速度、普通の射程距離

 ブラックバーク:400+3*x%、遅い攻撃速度、普通の射程距離

 シュリンツ:105+3*x%のダメージ、速い攻撃速度、普通の射程距離

 ジョナサン:190+3*x%のダメージ普通攻撃速度、長い射程距離

 

戦艦ノーチラスでCTを減少させることによって、バトルシップボンバーを2体出すことが可能となります

召喚スキルボスダメ等のダメージが乗るため、火力ソースとして大きく影響します。

 

更に戦艦ノーチラスのCT中は4次スキルキャプテンディグニティの最終ダメージが増加します。

 

4次スキルキャプテンディグニティ

100%で発動するファイナルアタックみたいなもの

ラピッドファイアの1発分でも発動するため、実質手数2倍という驚異的なスキル

 

.....

最高火力を出し続けるには戦艦ノーチラスのCTが切れたときに即打ち直しする必要があります

バトルシップボンバー戦艦ノーチラス→バトルシップボンバー(2体目)→戦艦ノーチラス→......

 

戦艦ノーチラス自体CTが30秒で本気でCT管理しようとすると忙しすぎるので、正直あまり現実的ではないと思いますが、

できたらかなり火力は出せると思います

 

特有メリットデメリット

 

あとがき

適当な部分もありましたが、これを見てキャプテン始めようと思った方がいればいいなと思います

2019-05-03

GW中ずっと引きこもりだけど、先日届いてたViTAKTのバランシングジェルが凄く良かった。

見た目がシンプルなのも好き。

https://linktr.ee/vitakt

2018-09-14

anond:20180914131058

英語だと、スケートボーディング=ボードに乗って滑ることなので、

乗るだけだど、バランシング と言ってる感じ。

2018-03-24

https://anond.hatelabo.jp/20180324114409

庇護を求める自由も、あるんだろうな、とは思う

あなた権威を与えるので庇護をください」てのは、生きる上での知恵というやつだろうか

はいえ、庇護要求者が寄り集まって「庇護社会提供すべき義務である」なんて主張をしだすと腹立たしい

彼らがそう行動する自由は認めるべきなので、ただ苦々しく思うだけに留めるけどさ

たぶん、そうやって自由主義と社会主義の間をバランシングするのが良いことなんだろうね

2017-11-29

ニコニコ動画(く)リリース失敗に寄せて

そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います

Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita

ドワンゴアカウントシステムScalaコードだけで22万行を越え、ドワンゴ社内で最大のScalaリポジトリとして知られています

ドワンゴユーザーアカウント基盤は明らかに破綻しています10 年以上にわたりガラケー時代から今に至るまで多くの業務コードに落としていくことは極めて難しい作業であったと思います。そうはいってもやってるうちに一回なんとか出来なかったのかとは思うわけです。やっている当人たちがテンションを上げているほどには開発効率が出ていない、むしろ足を引っ張っているという可能性はかなり高いと思います

ニコニコ生放送におけるdockerの活用事例:dwango エンジニア ブロマガ:ドワンゴ研究開発チャンネル(ドワンゴエンジニア) - ニコニコチャンネル:生活

ニコニコ生放送(以下「生放送」)ではバックエンドフロントエンドサーバーを建てる環境として、2016年からDocker Swarm採用し始めています

Docker Swarm Mode については私も検証をしたことがあり、非常に優れた思想をもった将来性のあるプロダクトであると感じていました。個人的検証はずっと続けています。まず swarm mode の何が優れているかと言えば、コマンド体系の分かりやすさです。開発者は何のストレスを感じることもなくクラスタを扱うことができますさらに、サービスディスカバリ層を極めて扱いやすい形(サービス作ると公開することを指定したポートクラスタ内の全マシンで公開されるので、あとはクラスタ全台に向けてロードバランシングするだけでいい事実上ゼロコンフィグレーション)で実装たことは素晴らしいと思いますしかし、残念ながらこの素晴らしい思想を持ったプロダクトは砂上の楼閣でした。その肝心なサービスディスカバリは安定しておらず信頼できません。またマスターコケてそのままクラスタ全部が機能を停止するだとか、ノードが気づいたら行方不明だとかはざらです。こうした問題は 2016 年末から現在に至るまで残念ながらあまり改善されていません。

私は kubernetes が嫌いです。 Google 製品開発者UX考慮しないからです。しかし、 2016 年においても、 2017 年の今においても彼のプロダクトが商用環境における事実上唯一の選択肢でした(ついでに言うならば docker service コマンドで kubernetes いじれるようになるので UX 問題解決する)。正直、 2016 年から swarm mode を仕事で使おうとしたのは、深刻なソフトウェア検証能力の欠如を感じます

http://gihyo.jp/dev/serial/01/dwango-engineersoul/0002 大量トラフィックを支えるインフラ独自プロトコル,ファイルシステム実装もいとわない!~

実は分散ファイルシステム独自に開発しました。もともと既存オープンソースファイルシステムを使っていたのですが,それだと期待する性能が出ないことがわかり,独自調査開発を進めることにしました。

現状は初期バージョンの開発完了にかなり近づいています

こちらの記事を読んでいただければわかりますが、配信基盤の再構築を行うにあたって

  1. OSS分散ファイルシステム使用するという目論見が失敗した
  2. 自前の分散ファイルシステムは 9 カ月まえの時点で全く完成していない

ということが分かります

なぜ彼らはパブリッククラウドCDN を使わないのか?

触れない話: 事実上全然稼働しなかった CTO北の将軍様

パブリッククラウド特に CDN採用することは開発負担の軽減に多いに貢献するように考えられます。実際「 akamai 使えよ」みたいなこと言ってるユーザー結構いるわけです。ではなぜ彼らがそうしないのか、その意思決定理由をここでは探ってみます

ASCII.jp:niconico(く)開発の遅れを謝罪

動画ストリーミングサービスとして遅れているというのは恥ずかしいことではありますが、ハードウェアや使っている回線の影響もありますので、どのサービスも最終的には同じになると思っています。その差をつけられることはこの先はなくなると思っています

ようするに CDN 屋だろうが自前だろうが最終的に同じようなところに落ち着くだろうという予測を彼らは立てているということです。しか現実問題として現在競合他社との差は大きく、新配信基盤のリリースの目途は立っていません(半年以上の遅れというのは通常そういうことでしょう)。ではなぜ彼らは最終的に差は無くなると予測するのか。私はこの点において彼らが空元気をふりまわしているとは思いません。

CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性

大規模配信 | 強烈な価格競争 原価割れ総合サービス提供で収支合わせ)

要するに CDN 各社は現在逆ザヤで出血を続けながら戦闘しており、 DDoS 対処を中心としたセキュリティサービスにより最終的な帳尻を合わせている状態です。自前で動画配信インフラを構築した経験のあるドワンゴCDN流行の早い段階から「成立するビジネスではない」という見通しを立てていたであろうと思います

ただしこの点において今後もビジネス環境技術環境現在のように推移するのかは、私にはよく分かりません(誰にも分かってないでしょう)。結局同じようなところに落ち着くならありもの使っとけよとは思わなくはない。

まとめ

まあもう無理でしょいろいろ

2016-03-09

http://anond.hatelabo.jp/20160309153322

勉強ができるかどうかとかどうでもよくて、単に君は死ぬときに「いやーいいバランシングだった!」って言うのかなーって思うだけ。

その感じだと言うんだろうな。別にそれが良いとか悪いとかじゃないけど。

http://anond.hatelabo.jp/20160309152117

一生バランス取り続けて、いやーいいバランシングだったわ!っつって死ぬのだろうか。

2015-07-11

http://anond.hatelabo.jp/20150711154715

優先させる?ってことはバランシングを意図的にとってるの?

英語運用能力を高める前に、日本語力を高めることを意図的にとっている人見たことないっすわ。

っていう意見ですが。

陳腐なチンカス意見ありがとうございます

2014-09-01

現代日本政治の現状

理想近代政党による 中道左派 vs 中道右派…的なバランシン

現実】 (似非)社会科学・お花畑有象無象 vs 伝統主義(という名の利権主義)+宗教原理主義な連立

実は、イスラーム教圏みたいな国々のが、ある意味では、まだマトモだったりして、と最近思うようになってきた・・・

2013-03-12

今後ネトウヨはこうなる!

595 : アメリカンショートヘア(dion軍)[] : 投稿日:2013/03/12 09:28:40 ID:2kRAKMKnP [10/10回(p2.2ch.net)]

≪僕の予測 今後ネトウヨはこうなる!(・ω・)≫

ネトウヨはTPPに反対する農家在日認定する。

ネトウヨロシアインド同盟や通商関係を強化すべき、と主張する人間在日認定する。

ネトウヨ故障だらけで低スペックのF35でなく心神開発を続けるべき、と主張する人間在日認定する。

ネトウヨ中国中華勢力圏構築をバランシングする橋頭堡の為に、台湾韓国軍事関係を強化する、と主張する人間在日認定する。

ネトウヨはTPPの次に来る日米経済調和対話に反対する人間在日認定する。

ネトウヨ核武装論者を在日認定する。

ネトウヨ従軍慰安婦問題は、アメリカ中国共同の日本封じ込め戦略で、安倍は米中に屈服した、と言う人間在日認定する。

アメリカ日本は改革するべき。従軍慰安婦南京大虐殺日本大罪。 ニヤニヤ」

中国「俺もアメリカに賛成。日本はTPPに入って改革するべき。従軍慰安婦南京大虐殺アメリカも言っているぞ!wニヤニヤ」

馬鹿「TPPに入って改革してチョンを倒せ」

原爆で焼き殺された挙句植民地憲法宗教まで破壊されると、ここまで卑屈な奴隷なっちゃう。

アメリカ中国で共同した行った戦後日本封じ込め戦略は、大成功!( ´ ▽ ` )ノ

http://hayabusa3.2ch.net/test/read.cgi/news/1362834030/595

2012-12-02

あくまでも仮定で、わかりやすいように、ユニクロを例に取るけど、あくまでもイメージであり、ユニクロのことを言いたいわけではない。

1 いままで、紡績産業国内だったと仮定する

2 同じ物を海外ユニクロが作って売ったとする

3 人件費関係で 『同じ利益率』 ならユニクロのほうが安くなる

4 よって、ユニクロは他社と同じだけの利益を得るが、価格は下落する。

5 しかし、労働海外移転しているので、国内失業率は上昇する。

6 失業率の上昇と、価格の下落が起きて、デフレ傾向になる。

7 反面、海外失業率は低下し人件費が向上するのでインフレ傾向になる。

 

しかし、このデフレインフレのセットは、通過問題が問題を起こしているわけでも、金融問題が問題を起こしているわけでもなく

単に、労働単価の差が『是正』されて、2つの国の物価差が0になるようにバランシングの力が働いているだけである

類例では、内外価格差があると並行輸入が発生して、安い海外版が売られるようになり、物価の差が縮まる力が働く。

 

まり、これは世界レベルでは、デフレインフレがセットで起きている現象なので日本が単独で金融政策をいくらやっても

両国間の物価差が0になるまで、価格は下がり続ける。

また、この現象は単なる競争原理であって、デフレとよく似ているがいわゆる、過去言われている金融が原因のデフレではない。

この状況下でインフレを引き起こすと、内外価格差が更に開くので、さらに大きなデフレの力がかかる。

そして、さらさらに大きなインフレを起こすと、さらさらに内外価格差が開き、 更に大きなデフレの力がかかる。

それが、極限までたどり着いたのが、いまの、負の金利である

かけたインフレ圧力と、同じだけのデフレ圧力が働き、国力だけが一方的に減少していく。

 

という仮定はどうだろうか? 

 
ログイン ユーザー登録
ようこそ ゲスト さん