はてなキーワード: Amazon Web Servicesとは
https://b.hatena.ne.jp/entry/s/blog.serverworks.co.jp/SPLA_after20250930
「AWSは弾いといてAzureでOKだったら~」みたいなブコメに大量に星ついてるけど、記事内に書いてるだろ。
3:Listed Provide:Microsoft の定めるパブリッククラウドプロバイダー Alibaba、Amazon Web Services、Google、Microsoft、およびListed Provider をアウトソーシングサービスの一部として利用するアウトソーサーを指す
エンジニア自称する連中はせめて記事内に書かれてあることぐらい読めよ。
この問題って、自社DCでMS製品使ったサービス提供する企業のためのライセンスなのに、
AWSやAzure使うクセにMS製品のライセンスを利用するクラウドベンダから買わずSPLAで済ませることで利益ちょろまかそうとするような
コスいベンダーに「ちゃんと正規ルートで買え」って言うための変更だろ。
そういうコスい小銭稼ぎするベンダって、ライセンスをクラウドベンダから買ってないくせにトラブルシューティングでサポート範囲超えた要求平気でしてくる印象しかない。
先月は40万円の利益になって、3ヶ月目で40万円も稼げたのかと自分で驚いていました。
今月は別案件で忙しいこともあり、受注量を増やしはしませんでしたが、
もし、受注量を増やした場合は、月55万くらいであれば稼げていたと思います。
ただ、最初の1ヶ月学習を進めてみると、スキルが意外と身についていて、
試しにクラウドワークスで応募をして見たら、何なく仕事がもらえたんですよね。
「え?私でも仕事もらえるの????」と思ってしまいましたし、
これはもしかして、稼げるんじゃないのか?
とこの時に思ったんですね。
あ、これ多分いけわ、っていう。
2ヶ月目には何と、25万円。
3ヶ月目には、40万円の収入を手にすることができました。
本当に信じられないです。
3ヶ月でこれだけの金額を稼げるとは思わなかったですし、
本当に良かったと思っています。
また報告させていただきます。
ありがとうございました。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
以上です。
ここまで報告をもらいました。
さて、ここまで話してきて、
「それってどんな稼ぎ方なの?」
と気になっている方が多いと思います。
正直、これを知るだけで、今後、プログラミングで稼げる金額がありえないほど変わってくるので、かなり貴重な内容になるはずです。
AWSです。
「????」
「なんですかそれは???」
と疑問に思っている人が多いと思います。
AWSとは何かというと、
Amazon Web Servicesの略で、Amazonが提供している100以上のクラウドコンピューティングサービスの総称です
「よくわからないです・・・・」となっている人もいらっしゃると思うので、
AWSを学ぶと、Amazonが提供するサーバー、ストレージ、データベースなど200以上のフル機能サービスで使うことができるようになるんですね。
これが、最近注目され始めてきているのですが、
というのも現状なのです。
だからこそ、AWSの仕事を引き受けられる人があまりいなくて、
まあVMWorldとかで10年以上人生の春を謳歌してきたからもう十分やろ
お疲れさん
~VMwareが提案する、DRにも対応するマルチクラウドソリューション~
昨今のCOVID-19流行への対応やDXを推進する中で、クラウドサービスの利用はビジネススピードの加速や柔軟なシステム運用に効果的であり、従来のオンプレミス環境と併用するハイブリッド環境や、複数のクラウドを利用するマルチクラウド環境が増えている。一方で、これらの環境を維持していくには課題も多く、セキュリティリスクも増大してしまう。ここでは、こうした課題を解決するVMwareのソリューションを紹介する。
COVID-19流行への対応やDX(デジタルトランスフォーメーション)のためのビジネス変革が進む中で、ビジネススピードの向上やニーズに対する迅速で柔軟な対応がこれまでになく求められている。これらを実現するために、アプリケーションの変革やクラウドへの移行が加速している。
多くの企業が、「ビジネスのスピードに対応できるモダンアプリケーション」や、「あらゆるクラウド、データセンター、エッジでビルドおよび実行が可能であること」、「エンタープライズクラスのレジリエンス、セキュリティ、運用の実現とビジネス変革」がDXを実現するために必要であると考え、これらを実現するためにマルチクラウド環境の活用が前提になってきている。
具体的には、Amazon Web Services(AWS)、Microsoft Azure(Azure)、Google Cloud Platform(GCP)といった複数のパブリッククラウドサービスを併用し、適材適所で使い分けているのが現状であろう。しかし、マルチクラウド環境では解決が必要な課題が存在する。その課題とは、「ワークロードのシームレスな移行・連携」、「クラウドごとのスキル習得」、「運用管理の簡素化」、「セキュリティリスクの低減」、「最適なコスト管理」の5つである。この5つがクラウド利用の理想と現実のギャップとなっており、これらを意識して進めていく必要がある。
特にマルチクラウド環境を適材適所で使う場合、クラウドごとに利用する技術が異なるため、設定項目や内容に違いがあり、その設定ミスによるインシデントも発生している。重大な影響を及ぼす場合もあるため、それぞれのクラウドを扱う際のスキルが重要になる。
こうしたマルチクラウド環境における課題を解決するには、一貫性のあるクラウドインフラストラクチャ、および運用管理サービスが重要なポイントとなる。例えばVMwareは、複数のパブリッククラウドだけでなくオンプレミスを含むハイブリッドクラウド環境においても、仮想的なレイヤーを構築することで管理や運用を一元化している。
VMware Cloud on AWSは、VMwareとAWSが共同で開発したもので、AWSのベアメタルサーバー上にvSphere、NSX、vSAN、vCenterを導入し、ホスト専有型のクラウドサービスとして提供するものだ。
その特長は3つある。1点目は「VMware製品をベースとしたクラウド」であること。VMware製品で仮想化されているため、AWSの世界にいながらオンプレミス環境で利用していたスキルセットや運用管理ツールを利用でき、新たなスキルを習得する必要がない。
2点目は「シームレスにクラウドに移行できる」こと。ワークロードをオンプレミス環境から無停止で移行することができる。アプリケーションを更改する必要もないため、クラウドに移行する時間やコスト、リスクを大幅に削減することが可能だ。
3点目は「VMwareが管理を行う」こと。ハードウェアやソフトウェアのトラブル対応や運用管理、メンテナンス対応など、すべてサービスの中でVMwareが実施する。3カ月に一回の頻度で新しいリリースを提供しており、ユーザーの要件を反映しながら新たな機能を追加している。
最近のアップデートの大きなものとして、日本で第2のリージョンとなる大阪リージョンを設置し、サービス提供を開始したことが挙げられる。例えば西日本地区でデータセンターを持つユーザーは、より低遅延でサービスを利用できるようになった。昨今は感染症の流行や地震の発生などによってBCPを見直すユーザーが増え、VMware Cloud on AWSをリカバリサイトとして利用するケースも増えている。その意味でも、大阪リージョンは活用度が高いといえる。
VMware Cloud on AWSが選ばれる理由は、大きく3つ挙げられる。1点目が既存のノウハウや運用管理手法をそのまま踏襲できるという点。VMware製品をベースとしたクラウドサービスであるため、オンプレミス環境における管理者のスキルや運用ノウハウなど、既存の資産をそのままクラウド上でも活用でき、新たなスキルの習得や、運用管理手法の大きな変更の必要もない。クラウドとオンプレミス環境をvCenterから一元管理できる。
2点目が、規模に依存しないシンプルなクラウド移行を実現できる点。ワークロードをそのままクラウドへ簡単に移行することが可能だ。VMware Cloud on AWSには標準でVMware HCXが含まれ、これはオンプレミスのデータセンターとクラウド間のネットワークをL2延伸する。ネットワークがつながった環境で仮想化環境、VMをそのままマイグレーションできる。アプリケーションやIPアドレスを変更することなく、無停止でワークロードを移行することができる。
3点目が、モダナイゼーションを推進して、ユーザーのDXの加速を支援できる点。まず、クラウドならではのインフラストラクチャとして、1顧客あたり最小2ホストから最大640ホストまで拡張できるが、俊敏性を兼ね備えて提供される。例えば、ホストの展開に1時間半程度、ホスト数を追加するのに15分程度と、オンプレミス環境ではありえないスピード感で環境を構築、提供される。
また、リソースを最適化する機能も提供される。ユーザーのリソースの使用状況に応じて、利用するホストの台数を自動的に増減させて最適化する。さらに、名前の通りにAWSが提供する各種サービスとの親和性が非常に高いことも特長。VMware Cloud ENIと呼ばれる専用のインタフェースを経由して接続することで、低遅延で高速な環境を利用して各種のAWSのサービスとシームレスに連携することができる。この面も同サービスの大きな強みとなっている。
最近では、VMwareが提供するKubernetesディストリビューションであるVMware TanzuをVMware Cloud on AWS上で稼働させることが可能になった。これにより、短時間でコンテナ、Kubernetes環境が導入できるようになる一方で、ハードウェア、ソフトウェアの管理はすべてVMwareが行うため、管理者はKubernetes環境に集中できる。
VMware Cloud on AWSのユースケースには、主に「オンプレミス環境のクラウド移行」、「データセンターの拡張」、「災害対策サイト」、「次世代アプリケーションのプラットフォーム」の4つが多い。特に最近は、災害対策としての利用が増えているという。VMware Cloud on AWSをリカバリサイトとして活用する際に強力なサービスとなるのがVMware Cloud Disaster Recoveryだ。
VMware Cloud Disaster Recoveryを利用すると、平常時には本番サイトのデータをクラウド上のストレージ領域にレプリケーションしておき、万一DRイベントが発生した際に初めてVMware Cloud on AWS上にホストを展開し、保護していた仮想化環境をフェイルオーバーする。リカバリサイトとしてあらかじめ物理的なサイトを構築しておく必要がないため、大規模な初期投資が不要となる。
VMware Cloud Disaster Recoveryの特長
このタイプはオンデマンド展開型と呼ばれ、DRイベント時にホストを展開したタイミングでリカバリサイトに対する課金が開始される。復旧後に仮想化環境を本番サイトに戻すことで、ワークロードもフェイルバックでき、不要となったリカバリサイトのリソースも削除され課金も停止される。なお、オンデマンド展開型のほかに、事前にホストを展開しておく事前展開型も用意されており、RTOを重視する場合には事前展開型が推奨される
また同サービスは、最近話題になっているランサムウェアへの対策にも有効だ。クラウドストレージ上に本番環境のデータをバックアップする際には、リカバリポイントを長期的に保持することが可能である。このため、ランサムウェア攻撃に遭ってしまった場合、その直前の時点からリストアすることが可能となる。
マルチクラウド環境を可視化するVMware vRealize Cloud
マルチクラウド環境では、各クラウドが複雑化し、サイロ化してしまう可能性がある。クラウドごとに管理ツールや必要とされるスキル、ノウハウも異なるため、利用するクラウドが増えるほど複雑化、サイロ化の問題が大きくなり、その結果セキュリティリスクやコストが増加してしまう。そこで有効な解決策となるのが、クラウド環境をまたがって一貫性のある運用・管理を実現できるVMware vRealize Cloudである。
まず、VMware vRealize Operations Cloudは、VMware Cloud on AWSのリソースだけでなく、他のパブリッククラウド上のリソースも一元管理できる。複数クラウドの環境にまたがってデータを収集、分析評価を行うことで、例えば常にパワーオフ状態の仮想化環境や、実体がない状態のディスクなどを検知された場合に最適化していくことが可能。これにより、最終的にコストの最適化も図ることができる。
コストや運用を最適化できるVMware vRealize Cloud
また、VMware vRealize Log Insight Cloudによって、複数のクラウドを横断してログを管理できる。例えば、監視対象のイベント通知をあらかじめ定義しておくことで、不正な行動を検知した際には管理者に通知し、適切な調査と対応を行うことができる。セキュリティやコンプライアンスの強化にも有効だ。
さらに、クラウド間のネットワークの可視化は、VMware vRealize Network Insight Cloudで実現できる。End to Endを含むネットワーク全体を可視化できるため、ネットワークに関するトラブルシューティングや、不審な通信を洗い出すこともできる。また、アプリケーションの通信も把握できるため、アプリケーションの移行計画にも活用できる。
今後、DXの推進を加速していく上で、必ずしもひとつの環境、ひとつのクラウドを利用するのではなく、マルチクラウド環境の利用が当たり前になっていくと考えられる。そこで直面する前述の5つの課題に対し、VMware Cloud on AWSそしてVMware vRealize Cloudの活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
202あとで/2672users ブログ: 「平常に戻る」ことはない - イギリスNESTA(科学技術芸術国家基金)より | okuranagaimo.blogspot.com
144あとで/741users 電子情報学特論:Chromiumのアーキテクチャを解き明かす - Google スライド
142あとで/2292users 0403「NY感染体験記(未確定)」|qanta|note
132あとで/1569users イラスト図解! これが新型コロナウイルス(SARS-CoV-2)だ|ぬまがさワタリ|note
124あとで/1229users [PDF]COVID-19への対策の概念 | 東北大学大学院医学系研究科・押谷仁
116あとで/578users API 設計ガイド | Cloud API | Google Cloud
116あとで/1677users 緊急事態宣言から3週間 流行状況はどう変わったか(忽那賢志) - 個人 - Yahoo!ニュース
114あとで/911users 米ジャズプレーヤーが解き明かす“J-POP”の正体、音楽的アイデンティティ(KAI-YOU Premium)
114あとで/609users Google Cloud Platform のトレーニングコース、ハンズオンを 1 か月間無料で提供 | Google Cloud Blog
111あとで/506users ドキュメント作成スキル向上を目指す人向けおすすめ記事まとめ - Qiita
106あとで/970users 月例マグコミマンガ大賞2020 - マッグガーデン / 2月期 入選「賢者の教室」朝野茶柱 | MAGCOMI
104あとで/668users 論文の読み方 / How to survey - Speaker Deck
103あとで/617users SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち?〜 - Qiita
102あとで/452users Git / GitHub を使用したチーム開発時のガイドラインを制定しました | Developers.IO
102あとで/1032users 「日本人は幻想を抱く」新型コロナと闘うウイルス学者の『情熱大陸』のドキュメントがすごい!(追記あり)(水島宏明) - 個人 - Yahoo!ニュース
100あとで/549users Mr. ベイエリア on Twitter: "自分は機械学習を学びたい全ての人類に(CourseraのAndrew Ngのコースをやった後に)Andrew NgのStanfordのCS229の講義を見ることをオススメしてるんですけど、その講義の2018年度バージョンが公開され… https://t.co/OUokFft3ea"
97あとで/600users 自宅で学ぼう!AWS 初学者向けの勉強方法 6ステップ! | Amazon Web Services ブログ
96あとで/435users 文字コード再入門 ─ Unicodeでのサロゲートペア、結合文字、正規化、書記素クラスタを理解しよう! - エンジニアHub|若手Webエンジニアのキャリアを考える!
95あとで/406users “アカウント作成後すぐやるセキュリティ対策” 編を公開しました!- Monthly AWS Hands-on for Beginners 2020年4月号 | Amazon Web Services ブログ
94あとで/538users 大幅にリニューアルされた Next.js のチュートリアルをどこよりも早く全編和訳しました - Qiita
94あとで/1004users 「一生役に立つ」人に質問するときに覚えておきたい…とある大学の授業で配られた『質問の仕方』のスライド - Togetter
93あとで/1447users ヨーロッパでコロナに感染して入院した話 - にゃんぶろ
93あとで/782users これからは「一番最初に思い出してもらえるブランド」しか生き残れない|池田紀行@トライバル|note
92あとで/2071users 一人暮らしで新型コロナウイルスにかかった話|RO|note
88あとで/794users 見ずして死ねない日本の伝統建築10選
87あとで/1317users リモートワークが 超快適になる製品9選 〜仕事に本気なあなたに〜|村上僚|note
86あとで/425users 「AIをどう習得したのか教えて」と大募集し、技術者から集まった記事49本を紹介 - 週末スペシャル:日経クロステック Active
86あとで/809users API 設計: gRPC、OpenAPI、REST の概要と、それらを使用するタイミングを理解する | Google Cloud Blog
86あとで/778users Gitでよく使用するコマンドをGIFアニメで解説 | コリス
85あとで/395users TypeScript 練習問題集 · GitHub
昨今話題になってるヤマトや佐川関連のブックマークが上位を占めるかと思いきや、まったく違った。
(2016年12月29日10:54時点、本文、新着順で検索)
Amazonの検索結果 (絞り込み: 3 users 以上) 約 3,423 件中 1 - 40 件目 (0.26 秒)
(以下略)
ECサイトを連想させるトピックがほとんどなくて、AmazonがB2B向けサービスを充実させていることに驚いた。
Amazonって表向きは物流業界に革命と問題を起こしている要因に挙げられているけど、EC以外のインパクトがどれだけ大きいのか門外漢なので分からない。
↑でブクマ付けた人、何が起きるのか教えて
アマゾン(compute.amazonaws.com)による大量の不正クリックで頭を悩ませているアフィリエイトサイト運営者(まとめでもキュレーションでもない)は多いことだろう。
ASPのV社によると、これは「提携媒体様のサイト表記等のチェック」名目でのアクセスとのことだが、オーガニック検索で辿り着けるページだけでなく、広告出稿ページにまで広告経由で大量にやって来るから頭が痛い。しかも、課金されやすいように分単位、ときには秒単位でユーザーエージェントやホストを変更し、ひたすら同じ広告をクリックし続ける。リファラーなど一切ない。
例えば、このような具合である(サイトに関わる部分は*****にさせてもらった)。
ec2-52-198-49-221.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:05:15 +0900] ***** "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36"
ec2-52-198-49-221.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:05:25 +0900] ***** "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)"
ec2-52-198-222-214.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:05:35 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36"
ec2-52-198-169-39.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:05:44 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36"
ec2-52-197-86-194.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:05:45 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36 OPR/34.0.2036.25"
ec2-52-199-76-193.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:06:26 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36 OPR/34.0.2036.25"
ec2-52-69-168-106.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:06:30 +0900] ***** "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36 OPR/34.0.2036.25"
ec2-52-69-168-106.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:06:32 +0900] ***** "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36"
ec2-52-199-85-63.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:06:38 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2"
ec2-52-198-49-221.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:06:39 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0"
ec2-52-198-49-221.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:06:39 +0900] ***** "-" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Win64; x64; Trident/6.0)"
ec2-52-198-49-221.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:07:06 +0900] ***** "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36"
ec2-52-68-194-244.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:07:17 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36"
ec2-52-198-243-110.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:08:11 +0900] ***** "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)"
ec2-52-198-243-110.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:08:25 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0"
ec2-52-196-112-20.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:08:48 +0900] ***** "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)"
ec2-52-193-171-45.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:08:54 +0900] ***** "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0"
ec2-52-198-169-39.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:08:58 +0900] ***** "-" "Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0"
ec2-52-198-169-39.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:09:02 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2"
ec2-52-192-198-30.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:09:04 +0900] ***** "-" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Win64; x64; Trident/6.0)"
ec2-52-193-171-45.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:09:40 +0900] ***** "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; Trident/7.0; rv:11.0) like Gecko"
ec2-52-197-156-176.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:09:46 +0900] ***** "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; Trident/7.0; rv:11.0) like Gecko"
ec2-52-196-112-20.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:10:16 +0900] ***** "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36 OPR/34.0.2036.25"
ec2-52-199-44-248.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:10:25 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2"
ec2-52-69-168-106.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:10:32 +0900] ***** "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36"
ec2-52-199-85-63.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:10:52 +0900] ***** "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36 OPR/34.0.2036.25"
ec2-52-199-44-248.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:11:08 +0900] ***** "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)"
ec2-52-68-45-242.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:11:08 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36 OPR/34.0.2036.25"
ec2-52-69-169-154.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:11:26 +0900] ***** "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36"
1日でクリックされる広告は多いときで2,000件を超え、ヤフーリスティング広告管理画面の「無効なクリック数」にはたった1日で1,000件を超える無効クリックが計上される始末だ。残念ながらヤフーのシステムでもすべてのamazonaws.comを無効にできず、クリック調査を依頼してわずかながら返金されるも、アマゾンによる不正クリックは数多くが課金計上され、支払っている。
この現状に気づいていないアフィリエイトサイト運営者も多いことだろう。たとえば商標で出稿するなどクライアントのガイドラインに違反している広告であればどんどんクリックしてもらって結構だし、むしろそのようなサイトは不正クリックで是非潰して欲しいところでもある。
だが、普通に出稿している広告にこのような異常なクリックをされるとたまったものではない。
amazonaws.comの地域属性はアメリカなので、では都道府県単位で限定出稿しても、普通に変わらず大量に不正クリックされる。
広告を引っ込めるわけにもいかないから狙われないようにキーワードを絞り込もうとするも、管理画面でクリックされた検索クエリーを確認すると、それはもう満遍なく不正クリックされている。
提携媒体のサイト表記チェック名目にしては数が膨大過ぎて迷惑だという旨をASPのV社に返信したが、それに対する返信はなく、要するに「我慢しろ」ということなのだろう。
それではと、不正クリックサービスの提供元であるAmazon Web Services (AWS) のabuseにサーバーの生ログを添えて通報すると、通報から10日経った頃に返ってきたメールは、
> We were unable to identify the customer responsible for the reported activity.
> Due to the frequency with which AWS public IP addresses can change ownership
とのことで(バカか)、もはや不正クリック代行業者どもが泣いて喜びそうなお粗末な現状である。
アフィリエイトサイト運営者は今すぐサーバーの生ログをチェックし、広告URLに異様な足跡が残っていないか確認すべきだろう。ヤフーリスティング広告の場合、不正クリックによる返金期限は過去60日しか遡れない。
あ、そうそう、最近ASKAで話題のギフハブらしき痕跡もあった。
ec2-52-198-19-198.ap-northeast-1.compute.amazonaws.com - - [23/Aug/2016:18:09:45 +0900] "GET ***** HTTP/1.1" 200 27625 "-" "Mechanize/2.7.0 Ruby/2.0.0p451 (http://github.com/sparklemotion/mechanize/)"
「オンラインで流せるテープ」 を提供していた muxtape が閉鎖して一月。昨日出た、運営者からのメッセージを勢いで翻訳する。
http://muxtape.tumblr.com/post/51762430 ←反応
僕は音楽を愛している。
音楽を愛している人にとって、そして音楽そのものにとって、音楽を共有するという欲望は、本質的でかかせないものだと信じている。
愛すべき音楽に出会ったとき、僕たちは友達をターンテーブルの前に集め、CDを貸し、カーステレオで鳴らし、ミックステープを作る。
僕たちは、音楽から感じるものを知っているから。他の誰かにも、それを感じてほしいから。
Muxtapeの物語が始まったのは、僕がオレゴンでやっていた、週一の大学ラジオ番組だ。
その番組で流した曲の記録のかたわら、そのプレイリストをウェブに上げていた。ひとつのブロックが、その週の番組を記録したカセットに対応するというものだ。
当時、ミックステープは斜陽の時代に入っていた。でも、あのプレイリストのページは、ミックステープと同じ役割を、そして多くの点でよりよい役割を果たすはずだ。僕は番組を終えてからも、そのことをずっと考え続けた。
ミックステープのように、プレイリストはある意図を持って集められたものであって、その価値は単なる足し算にとどまらない。
ミックステープとは違って、プレイリストには物理的に届けるための制約がない。でも同時に、そこには実際の楽曲がない。
誰かがそのページを見にきてくれても、知っている曲があれば共感してくれるだろうが、 本来リスナーである人たちにミックスを実際に編集する手間を押し付けるのは、もともとの目的をダメにしてしまう。
プレイリストのことをまた考えはじめ、ついにそれに命を吹き込んだのは、その頃のことだ。
僕の音楽を(ミックステープ的な意味で)共有するという欲望はなくなってはいなかった。
だけど、その行き場はなくなりつつあった。
大手のブログサービスは音楽ファイルを短期的に置けるようにしていたけれど、
そういう場は僕が求めていたものではない。
カセットテープを手に握ったときにうまれる、突き動かされるような感覚。
それを手にしただけで、プレイヤーを探してそいつの使命を遂げさせたくなる。
Muxtapeの設計の目標は、そういう実感ををデジタル世界に翻訳してやり、音楽が生命の火花を散らして、持つ人を聞かずにはいられなくするということだった。
最初のバージョンは僕のtumblrに載せた一枚のガジェットだったけれど、後の姿と本質的に変わりはない。
フィードバックはすごいものだった。
「俺の分も作ってくれないか」という質問が次々と来た。
でも考えが進むにつれ、それはひどくもったいないことだと気づいた。
ソースで配布すると、到達できる範囲はせいぜい自前のサーバーを持ったニッチなクラスタだけになってしまう。
音楽を発見するための、もっと大きな機会をすべて閉じてしまう。
ミックステープの抜け殻に見えていたそれは、すぐにミックステープの進化形に見えだしてきた。
作ってやらなければならない。
三週間の夜をけずった結果、僕はMuxtapeを公開した。
成功はすぐに目に見えて現れた。
24時間で8685人の登録があり、
1ヶ月で97748人の登録と1200万ユニークアクセスがあり、
さらに順調に伸びつづけた。
行き過ぎた予想。技術オタクは賛美するか、すぐに失敗すると断じるかに分かれた。
誰もがどきどきしていた。
僕はぞくぞくしていた。
Muxtapeは「レーダーの視界の下を飛んでいる」からなんとか生き残っているだけだ、という誤解は多かった。
いわく、メジャーレーベルに見つかれば、閉鎖させられるだろう、と。
実際には、レーベルとRIAAは普通の人と同じようにウェブを見ている。
僕も一週間かそこらで、連絡を受けた。
RIAAからの通告が、メールと書留郵便とFedEx夜間便(紙とCD)の三点セットで届いた。
彼らは、権利侵害に当たるらしい6つのmuxtapeを止めるように求めてきたから、僕はそうした。
同じ頃、あるメジャーの著作権問題(anti-piracy)担当者からの連絡を受けた。
電話をとって最初に聞いた一言は、「教えていただきたいんですが、召喚状と訴状は、どこに送ればいいんですかね?」
対話はそこから始まった。
召喚状は送られてこなくて、それは雰囲気を新規ビジネス立ち上げの会議にふさわしいものにしようとする彼の脅し戦術だった。
本当の狙いはビジネスだった。
同じ頃、別のビッグフォーの企画担当者からもコンタクトを受けた。
次の一月、僕は聴き続けた。
頭のいい法律家、この手の問題について傾聴すべき意見を持つ人々と話し、
Muxtapeの合法性について合意を得ようとした。
得られそうな合意は、合意がないということだけだった。
「Muxtapeは100%合法で何の心配もない」から「Muxtapeは違法コピーの宝庫。十億ドルの訴訟とライカー島(Riker's Island)での服役の覚悟はあるのか?」までのあいだで、二十以上のすこしずつ違う意見をもらった。
結局Muxtapeの合法性は法律的に曖昧(moot)だった。
正当性があろうとなかろうと、訴訟で戦う費用はない僕の上に、メジャーレーベルは斧を振りかざしていた。
僕はいつも、アーティストかレーベルが連絡してきて問題を訴えたなら、削除をすると、自分の中で決めていた。
でも、誰からもそういう疑義はなかった。
ひとつも、なかった。
逆に、僕が聞いた範囲では、どのアーティストもこのサイトのファンで、その可能性にわくわくすると言っていた。
そこの親会社は怒っているに違いない大きなレーベルのマーケティング担当から電話を貰い、最新の情報をホームページに反映させるにはどうすればいいかと訊かれたことも何度かあった。
小さめのレーベルからは、彼らのコンテンツを別のクリエイティブな仕方でアピールできないかと言われた。
明らかに、Muxtapeはリスナーにもアーティストにも、同じように価値あるものだった。
五月、メジャーレーベルのひとつ、ユニバーサル・ミュージックとの最初の会議をした。
僕は、最悪の扱いを覚悟して、一人でそこに行った。
この十年、インディーの界隈に片足を突っ込み、そこで大きなレーベルが彼らの利益になるものも知らず、頑固にラッダイトしているのをみたからだ。
ここで言っておきたいのだけど、レーベルは自分自身のビジネスを、ふつうの人が疑っているレベルよりはずっとよく知っている。
ただし、未来へのアプローチに関しては、個々のレーベルによって驚くべき違いがある。
ユニバーサルで僕が会った紳士たちはすごく柔軟で機転が効いていた。
僕は、彼らにMuxtapeが与える利点を売り込む必要はなかった。
彼らはMuxtapeの素晴らしさを知っていて、ただ、支払いを欲しがっているだけだった。
その点については同情する。
僕は、共同で提案を行うにはまだいくらか時間が必要だと伝え、決定を先延ばしした。
彼らは大きく違ったタイプだった。
僕は会議室に入り、8、9人と握手をしてテーブルの前に着くと、目の前に "Muxtape" と題された電話帳並のファイルがあった。
彼らは半円状になって左右の脳のように僕の回りに陣取った。片方は法律、もう片方はビジネス企画。
会議の相手は交互に切り替わった。
「貴方は意図的に権利侵害をしている、サービスを止めるまでに数時間の猶予は与える」という法律サイドのハードな尋問と
「仮にサービスを止めさせられなかったら、どのような協力がありえると思うか?」というおずおずとしたビジネスサイドとの議論。
僕は提案を作るのに二週間を求めたが、二日と告げられた。
決断をしなければならなかった。
僕がみるに、選択肢は三つ。
第一は、全てをやめること。これはずっと考えていなかったことだ。
第二は、メジャーレーベルのコンテンツを全て禁止すること。これなら、直近の危機を回避することができそうだが、二つ大きな問題があった。
ひとつは明らかなことだけど、ユーザーがミックスに使いたいと思う大半の音楽を禁止することになってしまう、ということ。
もうひとつはメジャーレーベル以外に関して、楽曲の所有権と利用をどう扱うべきかという重い問題についてなにもやらないに等しい、ということ。
中規模のレーベルと独立アーティストにも、彼らのコンテンツがどのように使われているかについて、それほど圧力は使えないにしろ、大企業と同様の基本的な権利がある。
これは、ユニバーサルの人に会ってからずっと挑戦していたことだ。
他のサービスでライセンスを受けているものは、いろいろな理由でうまくいっていることを知っていた。
同時に、Muxtapeの場合は違うということ、少なくとも模索する価値はあることを知っていた。
レーベルがそこに価値を見出しているかどうかという疑問の答えは得られていなかったが、次の疑問は、それにどれだけの費用がかかるか、だった。
六月。
僕は五番街の法律事務所に、メジャーレーベルとのライセンス交渉の代理人をつとめることを求めて、彼らは承諾した。
そして、取引をするための遅々としたプロセスが始まった。
第一回は、堅苦しく複雑だった。だけど、思ったほど悪くはない。
僕は彼らを説得し、Muxtapeがこのままサービスを続けることが皆にとっての最良の利益になる、と納得させた。
これでうまく行きそうだった。
さらに二ヶ月、投資家と会合を持ち、サイトの次のフェイズを設計し、交渉を監督した。
困難が予想されたのは、Muxtapeが単純なオンデマンドサービスではない、という点で、オンデマンドよりは支払いが低くて済むはず、という点を考慮に入れてもらえるかどうかだった。
ライセンスの条件からはじめたかったのは、めずらしいwin-winになると思ったからでもある。
僕は、どんな通達があっても(at any given notice)、楽曲を検索して再生する機能を持たせたくはなかった。
一方、彼らもそういう昨日にあまりいい顔はしない(少なくとも、今の価格では)。
それまでは、すべての議論は数字に関するものだったが、
合意に近づくにつれて、掲載位置の販売とかマーケティングの方向性に話が移ってきた。
Muxtapeのモバイルバージョンを提案したが、否定された。
僕の柔軟性は身動きできなくなっていた。
Muxtapeに対して公正な取引をすることに心を割いてはいたけど、僕がずっと持ちつづけていた最大の関心は、サイトの統一性と使用感を保つことだった。
(それはライセンスを求めはじめた元々の理由のひとつでもある)
Muxtapeの経済面での各種の侵略に合意したのも、動かしたい(play ball)からだった。
だけど、編集と創作についてコントロールを手放すのはものすごくつらいことだった。
これと格闘している最中、Muxtape のサービスをホストしているAmazon Web Servicesから通告を受けたのが、8月15日。
Amazonの規約によれば、とんでもなく長い一覧に挙げられた楽曲を一営業日以内にすべて除去しなければ、
これはかなりの驚きだった。
RIAAからの連絡はずっと途絶えていたのだけれど、僕はこれをレーベルの理解が得られたためだと思っていた。
僕はライセンス交渉の最中にあること、これは事務的な間違いじゃないか、夏の金曜日の午後をとりもどせるようにするためにはなんでもしよう、ということを説明しようとした。
一営業日どころか、週末を越えて月曜日までやり続けても、結局、Amazonが要求する文書を作ることはできなかった。RIAAに電話で連絡したけれど、受けてもらうことさえできなかった。
これを解決できるはずだという、ほんとうに感じていたままの期待をそこにメッセージとして残した。
僕はまだ、これがなにかのひどいミスだと思っていた。
でもそれは間違いだった。
事態がすこし把握できてきた次の週。
RIAAの動きは、レーベルの親会社とは別の、自律したものだということ。
レーベルとの間で得た理解は、RIAAには継承されないということ。
どのレーベルも、僕を助けることに特に興味を持っていないということ。
彼らの見かたでは、交渉には影響しない、という。
僕は納得しなかった。
取引にはまだ数週間か数ヶ月(インターネット上では永遠に等しい)はかかる。
つまり、Muxtapeはすくなくとも年末までは止まったままということだ。
また、どうやって支払うかという問題も残っていた。
この変わりやすい世界では、急成長するウェブサイトがある場合でさえ、投資を受けるのは難しい。
ライセンスの取引すべてからの撤退。
どの取引も、単純さを信条とするこのサイトに対しては複雑過ぎるものになりつつあり、
僕がやりたい方向のイノベーションにとって、制約が強すぎ敵対的すぎるものになりつつあった。
開発にほとんど注意を向けられなくなってしまった結果、僕は自分のモチベーションに疑問を感じはじめていた。
僕は、すべてを犠牲にして急スピードで大会社を建てるために、これをはじめたんじゃない。
僕がこれをはじめたのは、音楽を愛する人たちのために単純で美しいなにかを作りたかったからだ。
だから、またそこからはじめたいと思う。
でも、いままでどおりのものではない。
ある、開発初期段階にある機能を取り入れるからだ。これからはその機能に中心的な役割を持たせたい。
Muxtapeは、バンドだけのためのサービスとして再出発する。
インターネットで活動するための、これまでにないシンプルで強力なプラットフォームとしての機能を提供する。
2008年のミュージシャンは、ウェブ開発者と手を組まない限り、オンラインで地位を確保する手段はほとんどない。
しかし、彼らのニーズは、実は共通の問題の中にあることが多い。
あたらしいMuxtapeは、バンドが自分の楽曲をアップロードして、それを埋め込みプレイヤーとして提供し、
もともとのMuxtapeの形式に加えてウェブのどこででも動かすことができるようになる。
魅力あるプロフィールを取り付ける機能、さらに、カレンダーや写真、コメント、ダウンロード、販売、あるいはニーズのある他の全ての追加機能のモジュールを提供する。
システムは0の段階から無限に拡張することができ、CSSデザイナーが使えるようなテンプレートシステムの層を設ける。
詳細は追って公開する。
ベータ版はいまところ非公開だけど、数週間以内に変更する予定。
これは機能の点でかなりの大きな転換だということは、意識している。
僕はいまも、音楽をオンラインで経験する方法を変革したいと思っている。
僕はいまも、相互接続された音楽のもっとも興味深い側面、新しいものをみつける、という側面を実現したいと思っている。
第一フェイズのMuxtapeをこれだけすごい場所にしてくれた皆さんに感謝します。
皆さんのミックスがなければ、ありえなかったことです。
音楽業界はいつかついてくるでしょう。ぜったいに、そうすることになるはずです。
Justin
kizasi.jp : 今日、ブログで話題になったことって?
ロリポップ!レンタルサーバー - ナウでヤングなレンタルサーバー
Amazon.co.jp: こんな僕でも社長になれた: 本: 家入 一真
ITmedia Biz.ID:“文系出身プログラマー”が独立するまで――コトノハ・大日田貴司さん
Amazon.com: Homepage: Amazon Web Services
Loose Change Japanese nihongo 911 - Google Video
ITmedia Biz.ID:“文系出身プログラマー”が独立するまで――コトノハ・大日田貴司さん
「例えば僕が100時間かけてサービスを作るとしますよね。そのサービスで2万人の人を1時間喜ばせることができたとします。そうすると僕の100時間が2万時間もの幸せな時間になって返ってくることになります。それってすごいな、と思ったのです」
popurls
stratfor