「ポータビリティ」を含む日記 RSS

はてなキーワード: ポータビリティとは

2024-03-25

anond:20240325114545

基本情報はとったよ

結構やる気あるじゃん

しかし残念ながら基本情報だけでは弱い。できれば自分志向と適性に応じてスペシャリスト資格が取れるといいな。

潜り込むことを考えるとポータビリティの高さが必要だと思うので、ネットワークスペシャリストデータベーススペシャリストいいんじゃないかと思う。わからんけど。

あとSESはとりあえず職歴つけるとかの目的以外ではおすすめしない。できれば土木とかメーカーとか商社とかそういう非IT業のIT屋として潜り込めるといいと思うんだけどね。

基本情報応用情報くらいでサクッとSESに入って職歴つけるのと並行してスペシャリスト資格とって↑の業種に潜り込むとか。

2024-02-04

つぎのラズパイ(もうすでにでてるのか?まだなのか)って5ボルトで5アンペアだっけ?

アンペアだっけ?そんな大電流どうやってだすのってかんじ。

もちろんACアダプターなら大丈夫だろうけど、そうするとポータビリティわるくなるし・・・

それなら12ボルトかにあげたらよかった?そしたら12ボルトがだせるモバイルバッテリー

ひつようか。いまはやりの充電池リチウム系)つかうか。そのばあいでも、すごいことになるぞ。

2023-11-09

話混ぜないようにはしてたんだけど、PSDを業界標準フォーマットにした挙句バカ高年間ライセンス制をやってるくせにああであるアドビ

PSDや.ai(illustrator形式)とかいポータビリティもなくデータ確認手段がほぼアドビ製品一択になるような業界構造形成して行ったうえで、年間ライセンス制をやり出したのもまあ不満が溜まりまくってたわけですよ

(金が高いという点もあるにはあるが、ちょっとした確認でいちいち重たいソフト開くのも大変だし、ファイル形式バイナリがどうなってんのかいまいち不明瞭でデータサイズデカい)

AIの話と混ぜたくないんだけど、ビックテックどもが軒並みああい姿勢を取り出すと流石に「じゃあお前ら今度からリリースソフト全部BSDMITライセンスで配布しろや」って気持ちにはなる

2023-01-05

CircleCI がもう終わりそうだけど

こういうときに備えてポータビリティ高くメンテしていた人(具体的には GitHub Actions を少しずつ並行させていた人)がまったく評価されないのが日本

2022-02-03

光回線を引こうとしたがひどすぎる

NTTも、電力系も、NUROも、おそらく3カ月以上待つらしい。

NTT西なので例のトラブルに巻き込まれるし、NUROは評判だと半年待つ必要があるし、電力系だとNTT電柱許可取るだけで2カ月かかると聞いた。

そして鬼門なのが、固定電話ポータビリティ

ソフトバンクのおうちのでんわだと一回アナログ戻しが必要になるらしい。最悪。

加入権ありの番号ポータビリティはだいたいできるようになってると聞いてたのに、ソフバン系の電話にしてるとアナログ戻しが必要なんだと。なんだそりゃ。

そして光回線は料金が高い。

ネット電話はどこと契約しても5000円強。

NTT接続料半額くらいに下がったとニュースで聞いたんだが、どこがマージン取ってるんだ?

携帯電話の料金は下がった。

光回線はどうにかならんのか。

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-02-26

note投げ銭資金移動にあたるのでは?

noteの売上金の有効期限が180日になるようです。180日を超えると自動的Amazonギフト券に交換されるらしい。

https://help.note.com/hc/ja/articles/360011270774-%E5%A3%B2%E4%B8%8A%E9%87%91%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6

これまでのnoteの不誠実な対応(IPアドレス個人情報漏洩(事故のものよりもそれへの広報がムッとなった)や、cakesの各種炎上)があるし、データポータビリティへの意識の低さ、などの印象があり非常に心証が悪かったが、ユーザーの売上をできる限り消滅させないという姿勢は良しとするものの、もっと前段での問題があると思うので、うううーんという気持ちになっている。具体的には、note投げ銭(サポート機能)の扱いは資金決済法に関連した問題はらんでいると思う。

投げ銭資金移動にあたるんじゃないの?

正面切って「我社の投げ銭機能合法です!」と言い張れる投げ銭機能はほぼない、という立場をとったとしても、note投げ銭機能は法的には黒なんじゃないかと思っている。この辺り結構ややこしいが、以下の3点がポイントになるだろうと思う。

現金化について

まず現金化できることが問題トリガーになる。これが例えばアマゾンギフト券交換だけなら問題ない。なぜなら為替取引ではなくなるので。上で触れた資金決済法抵触しないのであれば問題は一切ないと言える。

コンテンツ販売投げ銭の違い

コンテンツ販売収益ユーザー還元するスキームは、収納代行と考えられる。noteあくまユーザー間の取引安全に行うための場を提供するだけであり、資金の移動は「コンテンツ販売」という役務提供に付随するものなので、このような収納代行スキームは昨今の流れから問題のないものと考えられる(すでに一般的取引と思われている収納代行(メルカリ等)も為替取引なのでは?という議論が行われるくらい慎重に進められているので、こういう大丈夫じゃないっすかね表現になる)。

有効期限を180日に設定したのも、収納代行スキームにおいては受け取った代金を必要以上に残しておいてはいけない(資金決済法趣旨利用者保護である収納代行では前払式支払証票などによる供託金による資産保全義務がない。そのため、必要以上の期間支払金をプールしておくことが法の趣旨に反する)ということにようやく気がついた、ということだろうと思う(個人的には180日でも長すぎると思う、メルカリはこの問題で90日に変更した)。

しかし、投げ銭については疑義がある。noteの想定スキームは、「投げ銭とともに投稿者メッセージを送れる」「サポートアイコンを表示できる」などの役務提供している、ということだろうと推測している。しかしながら、「投げ銭価格自由に設定できる」ので、そもそも役務に対する正当な価格が定められていない、ということになる。対価に対応した役務提供されていないにもかかわらず(経費を控除した上で)全額為替として受け取ることができるのは、脱法的、というよりもはっきりと資金移動に当たるんじゃないか?と思う。

また、上記のような性質の違いがあるにも関わらず、コンテンツ販売収益投げ銭収益を一緒くたに取り扱っていることもポイントであると思う。note的には実装上の楽をし、合法的な収納代行のスキーム投げ銭機能を潜り込ませることで、グレーな感じを演出しているのじゃないかなー。

Amazonギフト券交換に限定したとして

投げ銭現金化について違法性があったので取りやめて、今後Amazonギフト券交換に限定したとしても、まだ問題はある。投げ銭によりプールされたポイントは、未使用の前払式支払証票となり、投げ銭の売上は自家型の前払式支払手段判断されるだろう。note資金決済法的な対応は一切していないのだ。

自家型の場合、未使用残高が1000万円以下が適用除外になり、法的な対応必要なくなる。ただ、note場合、これまでずっと有効期限なしで投げ銭を受け続けており、かつ振込手数料あるので、換金せずに貯めてるユーザー多いのではないかな…本当に未使用残高1000万超えてないのかな…というのは疑問。超えてて資金決済法対応を行わず、かつ利用規約の変更で有効期限を6ヶ月以下に設定し(有効期限が6ヶ月以下の前払式支払手段は法の適用対象外になる)、法の適用対象から逃れようとするの、めちゃくちゃずるくないか?と思ってしまう。いや、まあ未使用残高が1000万円を超えているか外野からはわかんないので、下衆の勘繰りといえばそうだねという感じではあるよ…。まあ、この辺もうちょっと説明したほうが良くないか、とも思う。

まとめ

いい記事にいいフィードバックが還るのは尊いと思うので、機能提供されているのはいい。が、法を無視して進んでいくと利用者は法で定められる保護が受けられなくなるし、善良な企業馬鹿を見るので、良くねえと思っているよ。

2020-11-22

anond:20201122143706

1回と言わず携帯会社を変えるようにMNPできるようにすればいい。マイネームポータビリティだ。

2019-12-22

個人情報保護委員会も、公取委に言ってくれ……これ位。

公取委個人情報保護委員会とは別にオンラインサービス規制提案して、「サービスの対価として自らに関連するデータ提供する消費者」とか言い出してるけど、EUでも似たようなことが起きてたらしい。

欧州委員会オンラインサービス規制のための新しい指令を起草して、そこで「消費者サービスの対価を個人データで支払う……」とか書いてしまった。これに対し、欧州データ保護監督機関が「何すんじゃワレェ!」したのが以下の見解である

EDPS Opinion 4/2017

https://edps.europa.eu/sites/edp/files/publication/17-03-14_opinion_digital_content_en.pdf

EDPSはデータ駆動経済について、EUの成長のために重要であること、デジタル単一市場戦略として唱道されるデジタル環境において抜きんでていることを認めております消費者法とデータ保護法とが共同し相補しあう関係にあることは私たちが一貫して論じてきたところであります。ですから、「デジタル商品」の提供を受ける条件としてデータ差し出すことを要求される消費者保護を強化するために、デジタルコンテンツ供給にかかる契約に関する特有の側面にかかる2015年12月の委員会指令プロポーザル意図しているところを、私たちは支持しております

しかしながら、この指令のある側面は問題はらものです。というのも、これが適用可能なのはデジタルコンテンツのために価額が支払われる場合だけではなく、デジタルコンテンツ金銭以外の個人データその他何らかのデータの形での反対給付と引き換えに供給される場合にも適用可能からです。EDPSは、人々が金銭を支払うのと同じように自分達のデータを支払えるという考え方を導入するような規定を新たに定めることのないよう警告いたします。個人データ保護を受ける権利のような基本権は、単なる消費者利益に縮められるものではありませんし、単なるお値打ち品のように個人データを捉えることはできません。

最近採択されたデータ保護フレームワーク(以下「GDPR」といいます)は、未だ完全には適用可能でなく、新しい e-Privacy 制度は今も審議中でございます。ですからEUとしては、立法者が協議されている入念なバランスをひっくり返すようなプロポーザルは、何であれ避けるべきものです。イニシアティブの重複は、デジタル単一市場統一性意図せずとも損ない、規制断片化と法的不確実性をもたらすことになりかねません。デジタル経済における個人データ使用規制する措置として、EUGDPR適用することをEDPSは推奨いたします。

「反対給付としてのデータ」という概念……このプロポーザルでは未定義のままです……は、所与のトランザクションにおけるデータの正しい機能について混乱を引き起こす恐れがございます。この点で供給から明瞭な情報がないため、さらに難しいことになるでしょう。それゆえ私たちは、この問題解決する一助として、EU競争法におけるサービス定義を一考することをお勧めしますが、その地域範囲定義するうえでGDPRの用いている規定が役立つかもしれません。

見解では、このプロポーザルGDPRとどのように影響し合うことになりうるか検証いたします。

第一に、データ保護制度に基づく「個人データ」の定義が広範であるため、その効果により、この提案指令の対象となるデータが全て GDPRに基づく「個人データ」とみなされることは十分にありえます

第二に、(個人データの)取扱いが発生する厳密な条件はGDPR指定済みであり、この提案指令に基づく修正や追加を必要としておりません。このプロポーザルは反対給付としてデータを用いることを正当とみなしているようですが、GDPRでは、例えば、(本人の)同意有効性を検査し、デジタル取引文脈において(同意が)自由意思に基づくとみなしうるか決定するための、新たな条件を一式用意してございます

最後に、消費者に与えるものとして提案されている契約終了時に供給からデータを取得する権利供給者がデータ使用を控える義務は、GDPRに基づくアクセス及びポータビリティ権やデータコントローラデータ使用を控える義務オーバーラップしている可能性があります。このことで、適用する制度について意図しない混乱をもたらすことになりえます

EDPS Opinion 8/2018

https://edps.europa.eu/sites/edp/files/publication/18-10-05_opinion_consumer_law_en.pdf

見解は、EU消費者保護規則のより良い執行近代化に関する指令のプロポーザルと、消費者集団的利益保護のための代表訴訟に関する指令のプロポーザルからなる「消費者のための新しい取引」と題する立法パッケージに関するEDPSの立ち位置を概説しています

EDPSは、目標において最近近代化されたデータ保護フレームワークと密接した領域で、既存規則近代化しようという同委員会意図を歓迎します。EDPSは、個人データの大規模な収集収益化、およびターゲットコンテンツを介した人々の注意の操作依存するデジタルサービスの主要なビジネスモデルが提す課題対応するために、現在消費者法におけるギャップを埋める必要性を認識しています。 これは、消費者法を改善して、個人デジタル市場の強力な企業との間で拡大している不均衡と不公平是正する、またとない機会です。

特にEDPSは、指令2011/83 / EU範囲を拡大して、金銭的な価格にて提供されないサービスを受ける消費者が、同指令が提供する保護フレームワーク恩恵を受けることができるようにする意図を支持いたしますが、それはこのようなサービス今日経済的な現実ニーズを反映しているからです。

このプロポーザルでは、EDPS Opinion 4/2017の推奨事項を考慮して、「反対給付」という用語使用や、消費者によるデジタルコンテンツサプライヤーへのデータ提供が「積極的」か「受動的」か区別することを控えています。ただしEDPSは、プロポーザルで想定されている新しい定義により、消費者お金で支払うのではなく、個人データで「支払う」ことができるデジタルコンテンツまたはデジタルサービス提供に関する契約概念が導入されることに懸念を示しています。この新しいアプローチは、「反対給付」という用語使用したり、個人データ提供価格の支払いを類推したりすることで生ずる問題解決していません。特に、このアプローチは、個人データを単なる経済資産とみなしているために、データ保護の基本権としての性格を十分に考慮していないものとなっています

GDPRでは既に、デジタル環境にて個人データの処理が行われ得る状況に関するバランスを既に定めています。 このプロポーザルで、GDPRで定める個人データを完全に保護するとのEUコミットメント矛盾するやり方で解釈される可能性のあるアプローチを促すようなことは避けるべきです。データ保護法の原則を損なう危険を冒すことなく幅広い消費者保護提供するために、電子商取引指令における「サービス」の広範な定義や、GDPR地域範囲定義する規定、もしくデジタルコンテンツプロポーザルに関する理事会一般アプローチの第3条(1)などに基づくアプローチ代替することが考えられます

したがいまして、EDPSは、「有形媒体では提供されないデジタルコンテンツ供給に関する契約」や「デジタルサービス契約」の定義にて個人データを参照することを何であれ控えていただくことを推奨し、その代わりとして、次のような契約の考え方に依拠することを提案します。 それは、「消費者への支払いが必要かどうかに関係なく」特定デジタルコンテンツまたはデジタルサービスを売り手が消費者提供または提供することを約束するというものです。

その後

きちんと追えていないが、「EU消費者保護規則のより良い執行近代化に関する指令」は、昨月末に採択されたようで、前文に「digital services provided in exchange for personal data」という表現が残ったものの、個人データについては「GDPRに従う」とのことで落ち着いた様である

https://eur-lex.europa.eu/eli/dir/2019/2161/oj

2019-04-03

anond:20190403231804

10年辛抱して残念かもしれないけど、少なくとも銀行業界はどのみちオワコンもの

財務なら、今でも殆ど企業が欲する、ポータビリティ高い職種だよなあ。10年したら人工知能が与信管理(今流行りの信用スコア?)を完全代替するかもだけど、他の職種も相応の代替を食らっているご時世になっているだろうな。

2018-12-27

anond:20181227085736

Green500がその辺のソフトウェアポータビリティだったりを勘案したランキング「ではない」ってことは一応理解はするからそれはそれで認めるよ。

だが、HPC経済性を評価する際はその辺容赦なく評価されね? ってのは当然受け入れるべきなのでは。「消費電力あたりの処理能力が高い」だけではエコではないのでは? っていうのは真じゃろ。

2018-10-26

anond:20181026113550

スマホ時代ポテチチョコの売り上げが落ちてる所にポータビリティモバイル性が無いことが挙げられるわけで、カキフライに関してもそうだよな。

俗にオリジン弁当パックなんかも片手で開けられて片手で食えるようなもの意識すべき。

2014-05-23

http://anond.hatelabo.jp/20140522162254

いいぞ、もっとやれ

しかしな、「静的型言語」がダメだとは言ってないだろ。

あとJavaだろうがHaskellだろうが結局テスト必要になるぞ。

そんな限定的な1項目(型エラーの検知)だけで優劣語れるわけないだろ。いいか、

優劣を語れる項目なんていくらでもあるんだ。

激論を交わせ、俺はお前に期待している。

2009-08-17

Macに移行したらすっかりviしか使わなくなってしまった。

だってemacsカスタマイズめんどくさいんだいもん。

Windowsじゃxyzzyを結構いじってたのに。

ものぐさになればなるほど人間ポータビリティがでてくる。

コンソールしか使わないとか。

これは進歩なんだろうか…

(追記)

GUNのツールばっかり使ってるから、昔の人から比べたらゆとりなんだろなー。

edですか、そうですか。

2008-11-27

結構大きく変わるんだね。

[mixi] 新機能リリース・障害のご報告

http://mixi.jp/release_info.pl

mixi Platformの開放」においては、まず、2008年12月11日(木)より mixi アプリパートナー向けβ版の提供を開始し、2009年春には正式版を公開する予定です。

2008年12月10日(水)より、15-17歳の方々が『mixi』をご利用出来るように年齢制限を引き下げることになりました。

株式会社ミクシィ | PRESS RELEASE

http://mixi.co.jp/press_08/1127.html

1. mixi Platformの開放(対パートナー向け)

mixi OpenID2008年8月20日より公開中

mixi アプリ2008年12月11日よりパートナー向けβ版を提供。2009年春より正式版を公開予定

mixi Connect:2009年春より公開予定

* mixi Platformの開放にあたりパートナーを資金的に支援するファンドの設立も準備中

概要図

お知らせ「より開かれた SNS を目指して」

http://mixi.jp/guide_openmixi.pl

感想

従来のSNSは閉じたものが多く、FaceBookなど開かれたものであっても、SNS間の連係がとりにくい(データポータビリティ認証の問題)

という意味では閉じている点が多かった。

でも、今後は(今回のmixi革命に合わせて)連係がとりやすいようなSNSが広まっていって、検索・閲覧も透過的に行えるようになっていく、という流れなんだろうね。

なんかAPIが混在すると技術者にとって優しくないことになりそうなのが心配だけど。

規格がないぶんクロスブラウザ問題より深刻になる可能性もある。クロスSNS問題。

2008-11-24

http://anond.hatelabo.jp/20081124191743

自動車会社デザイン開発に女性を大量投入して細かい所の設計をやらせたら

車の売れ行きが大幅にあがったんだと。

女性を投入することによって

・乗り物として、より空間としてどう心地よくすごすのか(室内のミラーの場所やら小物入れの場所の設置やらドアのデザインやら。)

助手席に必要なアメニティ

インテリアエクステリアの色調バリエーションの増やし方

等今まで考慮に入れてなかった点を考慮し始めたのが功をなしたらしい。

車を買うのは男性が多いが、どの車を買うかの決定については男性配偶者家族意見が如実に現れる。つまりカミさん意見

決定権を握るカミさん女性だから、女性意見を数多く引き出して、それを反映した物を作れば当然売れ行きは上がるよね。

これは車だけじゃなくて何でもそうなのだけど、男性はどれだけ高機能かについては興味は示すけどどんなデザインであるかとか使い勝手のよさ、分かりやすさには購買思慮の重点を置かないのにたいして女性は機能に含めて(機能も使い勝手が悪ければ排される場合あり。)配色、デザインポータビリティなど機能を使用していない時でも心地よい気分でいられるもの対して購買思慮の重点を置く傾向が高い。(これは自分意見じゃなくて本の受け売りね。)

更にいうと、既婚男性家族意見を聞いて購入する傾向が高いけれど女性は独断で購入する場合も多い。

だから、マーケティングを考える時その次の年の女性ニーズリサーチしてつかむのは重要、ってのは習ったよ。会社で。実践で。

2008-09-28

http://anond.hatelabo.jp/20080928000313

カキコ愚痴を書いたつもりだったが、ブクマが付いてた。

2008年09月28日 ocs 増田 LLFutureでも語られてたけど、RoR進歩が早すぎるという暗黒面があるらしい。http://www.ey-office.net/public/LLFuture2008.pdf

進歩するのはいいんだけど、互換性が軽視されてるってのはどうなんだろう。リンク先読むと、互換性はない、古いバージョンメンテされない、サーバーリブートは毎日と書いてある。要するに枯れるまで触らない方が安全ってことか。

2008年09月28日 ezookojo 特定の記事が書かれた当時の手順のままで動作しなければならないRailsかわいそうです / とか言ってるとオフィシャルのREADMEやガイドページだったりする

一人ツッコミやってるので、補足するのもなんだけど。ダイアログの手順が少々変わったくらいでうろたえている訳じゃなくて、指定されたサイトから最新のパッケージダウンロードして、そのパッケージにとって正しいと思われる手順を実行したら、動かなかった。

2008年09月28日 dbfireball 増田 Railsすごいよ!って言ってた去年あたりだったら、マジで10分でした。そこから色々アップデートされてその通りにやってもできないっていう状況。

参考にしたのは10分で作るRailsアプリfor Windows。やっぱり互換性がなくなってるんだ。

2008年09月28日 takeshiketa takeshiketa RoRラブな俺だけど、同意。RoRは導入コストで語るんじゃなくて、手になじんだ後の生産性で語るべき

うーん。ラブな方も現状については同じ意見。手になじんだ後の生産性ってのは一見わかる気もするけど。作った後のメンテナンスは誰がやるんだろう。導入コストは低くないと言ってるみたいだけど、互換性軽視の開発が続く中で、デベロッパの手をなじませ続けるラニングコストはどうなんだろう。

2008年09月28日 FTTH # |ω・)…… ハイハイハイ俺も云いたいです!! RoR機構使うよりSQLベタ書きの方がポータビリティメンテナンス性も良いと思います! バックエンド意識しないでいいようなアプリなんてどうせその程度です!!

ポータビリティメンテ性もべた書きより劣るフレームワークって…。

幸いITのプロじゃないので他人ごとなんだけど、RoRで業務サイトを構築している人が居るってのは、少々寒気がする。肝が据わってるのか、想像力がないのか、それとも俺が思っているよりずっと人月って金がかからないのか。

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