  |
はてなキーワード: バウンドとは
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
個人的には、温泉むすめの表現の是非の前に、「なぜ株式会社エンバウンドは、温泉むすめの過剰な性的表現を含むキャラ設定を行う必要があったのか」という動機の部分が気になってます。
あのキャラ設定を見れば、炎上の是非はともかく、炎上するリスクが高いことは、素人目にも明らかだと感じます。なぜわざわざリスクを取ったのかということです。
おそらく、エンバウンド社は、イベント企画が主な売上、コンテンツ作成コストが主なコストで、差額を利益としていたはずです。
https://realsound.jp/2019/10/post-428543.html
企画当初にコンテンツ作成のコストをかけた一方で、コロナ以降はイベント企画が難しくなったため、資金繰りが悪化した可能性があります。
コロナ禍で資金を回収するためには、売上をイベント企画から転換し、ウェブコンテンツの広告やグッズのオンライン販売等で売り上げる必要が出てきます。
自分もこの元増田と同じ気分になってたのだがどうもそもそも論点が違うらしい。
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>観光庁に電話しました。
・後援を決めた時点では問題となっているような設定（スカートめくり、夜這い、未成年飲酒）はなく、観光庁のガイドラインと照らし合わせて大丈夫だった
・現在は温泉むすめ（株式会社エンバウンド）および関係各所に事実確認をおこなっている— お肉さん🍖2021y11m (@gdgdhikineet) November 16, 2021
こう言う行動力のある誠実な人の声ほど拡散されないのがツイッターの糞システムである。現に、まるで理解してない馬鹿がこのツイートに糞リプしてる始末。
多分このツイートをした人は丁寧な人だから事を大げさにしたくないのだろうがここは増田だ。もうケチョンケチョンにやっちゃうよ。
つまるところ今回の問題点はこれに尽きる。
「犯罪自慢」
「DQN自慢」
【問一】
タレントや有名人が過去の悪事を面白おかしく暴露してなんならさも武勇伝のように自慢して発生する現象を漢字二文字で述べよ。
【解】
……これが全て。何のことない火元はこれだった。「性的採取」とか「表現の自由」以前の問題だった。
あのな、観光庁みたいな役所が過去に問題起こしてそれをひけらかす奴を使いたいと思うか？思わねぇだろ？夜這いとかそう言う話もあるが過去に女子高の寮に忍び込んで致しちゃった奴を自治体がPR大使として使いたいかって話ですよ。現に小山田圭吾があの様じゃねぇか。むしろネットユーザーは当事者がどんだけ禊済ませようとしても事あるごとに穿り返す案件じゃねぇかよ！てめぇら明礬温泉の源泉で顔洗って出直せってんだ！（どうでもいいけど蒸し卵美味そうだよね）
……怒りに任せてキーボードを走らせたがフェミとヲタの不毛な争いはここで終らせなくてはならない。
いや、俺の認識が間違ってるのかもしれない。「フェミ」と「ヲタ」が争ってるなんて簡単な構図じゃない。この論争は
ではなく
「強きを助け弱きを挫くフェミもどき」vs「自分を表現の自由戦士と思い込んでいる狂人」
と言うのが正解だ。
最初にマジレスするが、温泉街に萌えキャラの看板が立っている事について語っても仕方がない。
キャラクター文化においてルックスの魅力を消費するべきか否かについて議論していけば最後にはサンリオピューロランドやディズニーランドさえ廃墟になるか黒塗りの棒人間をマスコットにするかの二択を迫られることになるが、そんな極端な所までいま議論しても話がこじれるので置いておくべきだ。
温泉むすめについて議論すべきポイントの主語はそこまで大きくない。
「ご当地キャラクターの設定として何を背負わせるべきか」である。
細かい話は以下のURLを見ていただきたいが、わざわざクリックするのがだるい人向けに一番重要そうな部分だけを抜き出した。
https://onsen-musume.jp/news/3711
◆立ち上げの経緯
・全国の観光地に再び活気を取り戻したい
2011年3月に起こった未曽有の大災害「東日本大震災」によって、温泉むすめを運営する株式会社エンバウンド代表の橋本の故郷である福島県は多大な被害を受けました。その爪痕は未だに心の奥深くに残っています。
そんな震災の被害のあった福島と東北に再び活気を取り戻すためには、一人でも多くの観光客が現地を訪れることが必要です。
多額の補助金で一時的に潤った福島県ですが、お金の力だけでは人々の傷を癒すことはできませんでした。その証拠に未だに海外からの観光客は福島県を避ける傾向があります。
よって、実際に観光客や県外の方々が福島や東北に足を運ぶことが、現地の人たちの心を癒し、元気づける唯一の手段になります。
その手段として、若者に人気の二次元キャラクターを活用し、全国を網羅的に盛り上げることを目的に2016年にキャラクターコンテンツによる地方活性事業「温泉むすめ」を立ち上げました。
つまり温泉むすめとは福島の観光をPRするためのキャラクターだったんだよ！
なんだってー！
いやマジでなんなんだろう。
だがわかったことがある。
オタクに人気を出して聖地巡礼で温泉に入ってもらおうでは期待できる効果がニッチすぎる。
それをやりたいなら既存作品の公式と地方がくっつく方向にすればいい。
ぶっちゃけ福島ならフラガール辺りに金を握らせてCMでも作らせればいいのだ。
温泉むすめ単品で新規の客を呼び寄せたいなら温泉むすめがアピールするべきは「キャラ」や「聖地」ではなく「地元」そのものである。
だが温泉むすめはそれが出来ていない。
雑なステレオタイプで雑にキャラクターを当てはめているだけである。
今回真っ先に炎上していたのがコレだ。
たとえば「夜這い文化が合ったんですよ」なんて堂々と語られても反応に困るだけだ。
確かに……確かに「温泉むすめを知ってるオタク同士のカップルが山形旅行に行くことで夜這いOKかどうかを確認」みたいなのはあるのかも知れない……日本の人口が１億人いるんだから１組ぐらいはそういうカップルがいるかも知れない。
だがその可能性があるならば「夜這い文化とか教育にわる……子供連れて東北の温泉街はいけんわ……」となる家族が１０組ぐらいありそうなものでもある。
この時点でもう悪手なのである。
温泉むすめのコンセプトは「地方の個性」をアピールすることではなく、「魅力」をアピールすることであり、その方向性としては「全面的にプラス」なものであるべきではないだろうか？
確かに各地方のキャラクターには負の歴史を抱えているキャラクターも多いが、多くは「でも今はいい時代だよね」で締めくくっている。
それをあろうことか「いやーよか時代もあったもんですなー」みたいにアピールされても反応に困るというものだ。
ポリコレ的な良し悪しもそうだが、単純に企画そのものが企画倒れになっていないか？
観光庁（の後ろ盾を得ている下請けの面々）よ、力を入れたのはCDの録音ぐらいなのか？
そもそも「どの地方出身でも問題なさすぎる」ようなキャラがいる。
マイペースでおっとりした性格のスタイル抜群なむすめ。他のメンバーが失敗や挫折などで気落ちしているのを優しく包み込む。ユニットみんなのお姉さん的存在だが、実はもう一つの顔を持っているという噂がある。
正解はURLを見てもらおう。
https://onsen-musume.jp/character/noboribetsu_ayase
URLを見れば分かる通り、出身地アピールとなるのは名前ぐらいだ。
たとえば貴方が温泉むすめの情報だけを頼りに旅行先を決定するとしよう。
というかこんなものが出てきて誰も「いやこれは駄目だろ」って言わなかったことが問題だ。
これならまだ夜這い文化自慢のほうが「なるほどね。このジジイは脳が大正時代で止まってるんだ」で納得できる可能性が0.1%ぐらいはあるが、こんな無個性キャラを出されて納得するような「ここってマイナスのイメージしかないから無個性アピールの方がマシでは？」と考えるような奴は今すぐ観光業に関わるのを辞めろと言う他無い。
まあこれがもし栃木の温泉むすめで好物エビフライで頭のポンパドールが爆発していて決め台詞が「ないんだな、それが」だったらインターネットに脳を汚染された可愛そうな観光スタッフとしてセーフかも知れない（ちなみに栃木の温泉むすめも割と無個性な部類だ）。
とにかく、こんな奴らを日本中に配置して「観光地アピールしたぜ！」と言われても困るのだ。
温泉むすめ全体に言えることなのだが、何をしたいのかが分かってないまま進んだ匂いが強すぎる。
最初期であるならとりあえず立ち上げて日本全国の最強クラスの温泉街に売れっ子声優を当ててアイドルソングを歌わせておけば終わりでいいかも知れない。
でも２枚目のCDを出す前ぐらいで「でもこれって本当に地方の魅力伝わってるの？」と思い直すべきだった。
そういった話し合いが行われていたとは思えない代物が出てきている。
手段が萌えキャラだからということで雑になったのかも知れないが、それを言い訳にするのなら「地方の観光に力を入れることに対して雑だった」ということにしかならない。
そもそも萌えキャラなんて何をしても「キャラが濃いね」で許されるわけで、大砲だろうが城だろうがなんでも背負わせていい超自由なキャラクター分野だ。
何をやらせてもいいのに特に何もやらせず無個性キャラ乱発というのは「私達はこの地域に全く魅力を感じませんでした」というアピールにさえなることを本当気をつけろよ官僚（から金や権威を貰って仕事している下請けとはいえ多分官僚なんぞに今の時代なる中の下連中よりは優秀であろう連中）ども～～。
今は正社員として事務職をしていますが、コールセンターの頃を思い出して筆をとります。
自分は社会不適合者なんじゃないか？と思ってる無職の人にお伝えしたいことがあります。
法人向けのコールセンターなら、社会不適合者でも十分務まります。
なぜなら…
しかも法人向けなので特殊な業種向けを除けば大体カレンダー通りの休みが取れます。
アウトバウンドの営業電話だと、目標という名のノルマがあることも多いのできついですが、インバウンドならそれもないです。末端は。(SV以上になると受電率や応対時間、保留時間とか気にしないといけない)
そしてコールセンター全般ですが、デスクにパーテーションがあるので、自分の世界に浸りながら仕事ができます。
SVと呼ばれる人とさえしっかり連携できていれば、あとは問題ありません。
私の同僚だった人達のほとんどが、売れない役者もどき(劇団員同士で客席埋めあってるような劇団の役者)、売れない格闘家もどき、漫画家志望者、売れない同人作家、実家の太いこどおじおば、発達障害者、精神障害者、売れない配信者、でした。
でも彼らは毎日イキイキしていました。
人間性はもれなく自分が歳をとった自覚のない頭脳が子供な人間たちでしたが、深く関わらなければ特に影響はありません。
仕事の時間内だけしっかりがんばれば楽勝です。閑散期もあるし。電話線をしめればあとは残業もないですし、別に責任のある業務もほとんどないです。
それは、責任がとても重いですしクライアントのご機嫌も取らないといけないし末端の社不たちをまとめる力がないとできないからです。
それに、向上心があると同僚たちの幼稚さに反吐が出て、同レベルの仕事をしていることが嫌になります。
最低限の礼儀もない情弱、暇人や老人しかかけてこないので、精神削られるだけでサイコパスでもない限り病みます。
私は元引きこもりで、そこから法人向けコールセンターにつきましたが
正規雇用になりたくて、1年ほどで卒業して今はなんとか正規雇用の事務職で頑張っています。
同じ境遇の人たちに届いて欲しい。
世の中をいろいろと騒がせている一世風靡したセピアじゃない方のやり手経営者とかいるじゃない。
メディアでよく見かけて本屋さんでも著書が並んで平積みになってる人。
そう言う人がさ
全部スマホで仕事ができる！勝たんしかスマホ！って言うもんだから
もしかしたら、
結論として私思ったのは
ああいう人は指示出してメールとかだけで仕事が出来ちゃう人だと思うのね。
きっとああ言う人が
物理的なそうねフィジカルな伝票や荷札シールを出したり貼ったりすることがない人たちの世界線は平行線交わらないから
そうそうにもうタブレットで仕事は出来ないかもって結論付いちゃったけど、
寝ながら仰向けになって動画を見ていてうとうとしていたら、
大ダメージを喰らいつつ角が刺さって
もう伝説の勇者しか抜けない剣ならぬタブレットになっちゃったもんだから、
これもしかしたら、
スポーツ新聞で女性タレントが始球式で絶対一面になってそうなノーパン始球式ならぬ
ノーバンで取ればセーフみたいなドッチボールシステムのルールを取り入れつつ、
いろいろと物色していたんだけど、
その副産物として
もしかしたらこれでしか勝たんタブレットで仕事を！って思ったのよ。
もういきなり初っぱなで、
さっき言ったフィジカルに接続された物理的なプリンターも接続することが出来ないし、
それリゾ！ラバ！って言いながら
いきなりしょっぱなで出鼻を挫かれたワケなの。
そう言った感じで全部スマホでお仕事ができちゃうなんて桃源郷の幻想のシャングリラのピーチツリーフィズなのよ。
要はあ・ま・い！ってわけ
私はあまーい！って言うよりも
手に持ったヴィブラスラップって言う楽器でガーって決めるところまでがお仕事だと思ってるから、
そうそうにそして
外に出て外出したらネットに繋がっていなかったという
結局私たちはLANケーブルの束縛から文字通り解放されたと見せかけて、
ダブルミーニングで上手いこと言っちゃったような気がして
抜けさせない問題があるのよね。
本当にああいう人たちって本当どんな仕事してんのかしら？って思うわ。
サザエさんに出てくる黒い家電話が出てきて一向に現実味がない！って批判があるけど、
あれはあれでもう時代劇としてみた方が
腑に落ちる感じがして格さん助さんな海山商事よ。
だから私結構意外とフィジカルなことやってるの多いんだなーって思っちゃって、
よくさテレワークテレワークだワーイ！って在宅で仕事してる人って
私だったら絶対カレー煮込みながらお仕事しちゃう自信あるもんね。
においは仕事先にバレないから絶対にカレー煮込みながら仕事していても分からないもんね。
在宅で完全にテレワークで仕事が出来ちゃう以外の仕事もあるんだなーって
今日はそう思ったし、
うふふ。
すっかり定番もうちょっと本当はタマゴ成分が欲しいところだけど、
ほどほどにした方が良いかもしれないわね。
そうかもね。
いい朝ですね！言いたくはなるわね
ならないけど。
すいすいすいようび～
今日も頑張りましょう！
洋ゲーはおおむね以下の二つに分けられる
もちろんちゃんとした邦訳のゲームもあるが、少ない けっこう少ない
「ミックスウッドの家具が欲しいならトゥー・カーペンターズに行け、とKevinが言っていたよ。」的なクオリティの訳がかなり多い わかるけど、絶対原語でやったほうが楽しいんですよ
バカにしてるとかではない ゲームの訳、絶対難しいし、絶対やりたくないもん 仕方ない
しかし、英語が読めれば、というか、英語を無理矢理でも読んでやれば、このカテゴリわけは途端に意味を失う
レビュー欄をみる
「日本語訳が出るのが待ち遠しいです」
こういう言及を全部なぎ倒して、おのれの力でそのままプレイできる modなんかも基本的に入れ放題 英語に英語の追加コンテンツを足してミスマッチは生じねえ
英語と日本語が読めて快適にプレイできないゲームはそんなに多くはない
「もともとロシア語で、英訳もあるがけっこうガバガバ翻訳」みたいなのはそこそこあるが、あまり問題にならない
なぜか？
英語がガバガバであることには、あまり気付かないからだ 非ネイティヴの強みがここにある
かなり長いメッセージが出て、ウオ、と思っているうちに消えたりするからだ
オススメなのは、アイテムがたくさん出てきて、クラフトとかビルディングとかサバイバルとか、そういう感じのことをするゲーム
木を切って木材を得る そういう動作から、Wood, timber, sapling, sap, acorn, log, branch, くらいの単語が学べる
こういうのが積み重なるので、基礎語彙がかなり増える
俺はstarboundとrimworld とstardew valleyの三本柱を合計1000時間以上やって、初めて受けたTOEICで950点をとれた
正直もともと英語ができなかったわけではないから、完全にゲームのおかげとは言い難い
でも受験から何年も経ち、英語といえばゲームくらいしかしてない状態でそれだったわけだし、概ねゲームのおかげだとは言えそう
実際、試験中たびたび「あっ、これスターバウンド でやった単語だ！」みたいなことを思った
いいんだよ洋ゲー
やりましょう
大企業ではほとんど採用されていると思うが、メールゲートウェイ型のセキュリティアプライアンスで、添付ファイルが
ついていたら暗号化解除して中に含まれるファイルに悪意があるマクロ、プログラムが含まれるものがないか検査して
OKだったら送信許可、NGなら削除されましたの通知だけを送るなどをしている。
従いスキャンできないと、一律でメールは削除、若しくは添付ファイルは削除されましたの通知のみ送られる。
企業のセキュリティポリシーとしてこうしているところはあります。ウイルス感染対策の検知対策確度を上げるため。
さらに、ローカルPCにウイルススキャンが入っていて添付ファイルをローカル保存するとき、開くときにスキャンが
メールゲートウェイ型アプライアンスで、企業のインバウンド/アウトバウンドメールを一律、
チェックしたいんじゃないのかな。それなりに意味はあると思いますが、例えばgmailだと、
これまで暗号化解除(解析&解除)でチェックしていたと思われるが、CPUリソース食いまくりな事
や実効性への疑問(ほかの対策若しくは、複数対策を組み合わせる事での効率化)があって、
添付ファイルはチェックされず送られるか、削除されて何も通知されないみたいです。
> 3、なんで毎回同じPWじゃないの？
同じパスワードだとそれが漏れたり、第三者に知れたら容易に暗号化解除して見れてしまうから。
> これは1の通り、プロキシサーバーでスキャンできる仕組みを作る必要があるってことでいい？
プロキシーサーバではなくてメールゲートウェイ型アプライアンス(古くはオンプレでInterscanなり、、最近は知らんけど)
> この場合既存の仕組みを使えないし、クラウドサービスにロックインされるし
> 腰が重いのもわかる気がする
なにか同等のサービスがあると思う。
とりあえず、G Suite(旧google apps)だとgmailのメールフィルタ機能が標準装備でゴミメールはだいぶ減る。
メールソフトへの実装があまりはやらなかったのもあるし、暗号化強度の問題もあったのでは。(推測)
公開鍵暗号方式の実装したもので使いやすいもの、若しくは この手の送り手/受け手が正しい人かつ、
悪意を持ったプログラムが含まれないことを担保できるメール送受信の仕組みを作ればよいと思う。
インターネット自体は、自律分散系システムなので送ったものが必ず届くという確証もないし、
「子供の遊ぶ声なんて微笑ましいのに迷惑がるなんて心が狭いのね」ってそもそも言ってることが伝わってない気がする。
そういう人の言う遊ぶ声って「キャッキャッ」みたいなのを指してると思うけど、迷惑がってる人の指す子供の声っていうのは「キィィヤァァァーーー！！！」みたいな奇声とか大きな子が年下っぽい子をバカにしたような言動のことを言ってて、しかも公園で遊んでるんじゃなくて建物と建物の間とかの道路やコンクリの上でやるから反響がものすごい。公園でもない反響がものすごい場所で奇声をほぼ毎日聞かせられ続けてても「微笑ましい〜^ ^」なんて言ってられるわけがない。キチガイだろ。
しかも遊んでるんじゃなくて、私のところのは自主練か知らないけどずっとコンクリの上でボールをバウンドさせてる。1人で。しかも向かいのアパートの壁をゴールに見立ててるのかそこに向けてボールを投げるからその音もストレス。ダンっダンっダンっドンみたいな音が頻繁に聞こえる。公園もすぐそこにあるのになんで他人のガキのボールつく音に生活リズムを左右されなきゃいけないんだ。公園行けよ。夕方になるとボールをつくやつがいるなんて知らないで最近引っ越して来たから余計に気になるのかもしれないけど周りの家の人たちもよく耐えられるな。てか印がしてあるわけでもないんだからお前の感覚でゴールを考えてるとしたら意味のない練習だろ。車とかにぶつけたらどうするかとか考えろよ。
公園でボール遊びがダメだって言われるのは多分ボールを追いかけて道路とかに飛び出したりして危ないっていうのもあるからむやみに禁止してるわけじゃないと思う。周りが家に囲まれてる公園なら仕方ないと思うだろ。「公園じゃボール使えないもんね、道路とか建物と建物の間で遊ぶのも仕方ないね」とはならん。普通は。だから「公園が使えないからそうなる」も変な反論だと思う。反論にもなってない。
「自分たちだって子供の頃人に迷惑かけたんだから」ってよく言うやついるけどそんなの「自分も迷惑かけたし仕方ないよね〜」ってなるわけないだろ。迷惑なもんは迷惑なんだから。なんならそこまでうるさかったんだとしたら自分のときのことを思い出して申し訳なくなるくらいだわ。そんな例の出し方なんて、今店やってる人が万引きにあったとしても「自分も子供の頃万引きしてしまったからなんも言えないよな〜」と同じだろ。その人の背景がどうであろうとダメなものはダメだろ。
ていうかそれで「心が狭い人」扱いされるならそれでいいです。
