「Amazon Web Services」を含む日記 RSS

はてなキーワード: Amazon Web Servicesとは

2022-12-30

技術者気取ってるくせに記事も読まずに脳死ブコメって恥ずかしくないのか

https://b.hatena.ne.jp/entry/s/blog.serverworks.co.jp/SPLA_after20250930

上記ブコメ見てて頭痛くなってきた。

AWSは弾いといてAzureOKだったら~」みたいなブコメに大量に星ついてるけど、記事内に書いてるだろ。

Azureだって弾かれてるよ。

3:Listed Provide:Microsoft の定めるパブリッククラウドプロバイダー Alibaba、Amazon Web ServicesGoogleMicrosoft、およびListed Provider をアウトソーシングサービスの一部として利用するアウトソーサーを指す

エンジニア自称する連中はせめて記事内に書かれてあることぐらい読めよ。


そしてここから先は完全に個人的愚痴

この問題って、自社DCMS製品使ったサービス提供する企業のためのライセンスなのに、

AWSAzure使うクセにMS製品ライセンスを利用するクラウドベンダからわずSPLAで済ませることで利益ちょろまかそうとするような

コスベンダーに「ちゃん正規ルートで買え」って言うための変更だろ。

そういうコスい小銭稼ぎするベンダって、ライセンスクラウドベンダから買ってないくせにトラブルシューティングサポート範囲超えた要求平気でしてくる印象しかない。

MSはいろいろクソな変更してきたりするけど、この件に関してはMS文句言うのはお門違いだと思う。

2022-07-26

かなり稼げる情報

先月は40万円の利益になって、3ヶ月目で40万円も稼げたのかと自分で驚いていました。

今月は別案件で忙しいこともあり、受注量を増やしはしませんでしたが、

もし、受注量を増やした場合は、月55万くらいであれば稼げていたと思います

最初は本当にこの方法が稼げるのか疑問でしたし、

学習を続けて大丈夫不安しかありませんでした。

ただ、最初の1ヶ月学習を進めてみると、スキルが意外と身についていて、

試しにクラウドワークスで応募をして見たら、何なく仕事がもらえたんですよね。

「え?私でも仕事もらえるの????」と思ってしまいましたし、

金額としては5万円ほどのお仕事でした。

これはもしかして、稼げるんじゃないのか?

とこの時に思ったんですね。

あ、これ多分いけわ、っていう。

そこからは、猛勉強を始めました。

ひたすら勉強を続けていって、とにかく学びまくり毎日です。

そうしたら、徐々に知識スキルも身についてきて、

2ヶ月目には何と、25万円。

3ヶ月目には、40万円の収入を手にすることができました。

本当に信じられないです。

3ヶ月でこれだけの金額を稼げるとは思わなかったですし、

これだけ稼げる可能性があることにも気づきませんでした。

あの時、ゆうたさんのアドバイス通りに実践して、

本当に良かったと思っています

また報告させていただきます

ありがとうございました。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

以上です。

ここまで報告をもらいました。

さて、ここまで話してきて、

「それってどんな稼ぎ方なの?」

と気になっている方が多いと思います

それについて、これから暴露していきたいと思います

正直、これを知るだけで、今後、プログラミングで稼げる金額がありえないほど変わってくるので、かなり貴重な内容になるはずです。

それではいますね。

詳細について話しま・・・・・

それは・・・・・・

AWSです。

AWSというプログラミングです。

????」

「なんですかそれは???

と疑問に思っている人が多いと思います

一応説明をしておきますと、

AWSとは何かというと、

Amazon Web Servicesの略で、Amazon提供している100以上のクラウドコンピューティングサービス総称です

「よくわからないです・・・・」となっている人もいらっしゃると思うので、

もっと簡単説明をすると、

AWSを学ぶと、Amazon提供するサーバーストレージデータベースなど200以上のフル機能サービスで使うことができるようになるんですね。

これが、最近注目され始めてきているのですが、

「なかなか、AWSに詳しいプログラマーが少ない」

というのも現状なのです。

からこそ、AWS仕事を引き受けられる人があまりいなくて、

技術力のある人はこっそりと稼ぎ出しているという事実があります

僕はこの、AWSに目をつけて、コンサル生に教えた所、あり得ないほどの結果を出させることができたのです。

2022-02-18

VMWare苦しい戦いしてるなー

まあVMWorldとかで10年以上人生の春を謳歌してきたからもう十分やろ

お疲れさん

マルチクラウド環境における5つの課題とは

VMware提案する、DRにも対応するマルチクラウドソリューション

昨今のCOVID-19流行への対応やDXを推進する中で、クラウドサービスの利用はビジネススピードの加速や柔軟なシステム運用効果的であり、従来のオンプレミス環境と併用するハイブリッド環境や、複数クラウドを利用するマルチクラウド環境が増えている。一方で、これらの環境を維持していくには課題も多く、セキュリティリスクも増大してしまう。ここでは、こうした課題解決するVMwareソリューションを紹介する。

マルチクラウド環境における5つの課題

COVID-19流行への対応やDX(デジタルトランスフォーメーション)のためのビジネス変革が進む中で、ビジネススピードの向上やニーズに対する迅速で柔軟な対応がこれまでになく求められている。これらを実現するために、アプリケーションの変革やクラウドへの移行が加速している。

多くの企業が、「ビジネススピード対応できるモダンアプリケーション」や、「あらゆるクラウドデータセンター、エッジでビルドおよび実行が可能であること」、「エンタープライズクラスレジリエンスセキュリティ運用の実現とビジネス変革」がDXを実現するために必要であると考え、これらを実現するためにマルチクラウド環境活用が前提になってきている。

具体的には、Amazon Web Services(AWS)、Microsoft Azure(Azure)、Google Cloud Platform(GCP)といった複数パブリッククラウドサービスを併用し、適材適所で使い分けているのが現状であろう。しかし、マルチクラウド環境では解決必要課題存在する。その課題とは、「ワークロードのシームレスな移行・連携」、「クラウドごとのスキル習得」、「運用管理簡素化」、「セキュリティリスクの低減」、「最適なコスト管理」の5つである。この5つがクラウド利用の理想現実ギャップとなっており、これらを意識して進めていく必要がある。

マルチクラウド環境における5つの課題

特にマルチクラウド環境適材適所で使う場合クラウドごとに利用する技術が異なるため、設定項目や内容に違いがあり、その設定ミスによるインシデントも発生している。重大な影響を及ぼす場合もあるため、それぞれのクラウドを扱う際のスキル重要になる。

VMware Cloud on AWSの特長とメリット

こうしたマルチクラウド環境における課題解決するには、一貫性のあるクラウドインフラストラクチャ、および運用管理サービス重要ポイントとなる。例えばVMwareは、複数パブリッククラウドだけでなくオンプレミスを含むハイブリッドクラウド環境においても、仮想的なレイヤーを構築することで管理運用を一元化している。

VMware Cloud on AWSは、VMwareAWSが共同で開発したもので、AWSベアメタルサーバー上にvSphere、NSX、vSAN、vCenterを導入し、ホスト専有型のクラウドサービスとして提供するものだ。

VMware Cloud on AWSの特長

その特長は3つある。1点目は「VMware製品ベースとしたクラウドであること。VMware製品仮想化されているため、AWS世界にいながらオンプレミス環境で利用していたスキルセットや運用管理ツールを利用でき、新たなスキル習得する必要がない。

2点目は「シームレスクラウドに移行できる」こと。ワークロードをオンプレミス環境から無停止で移行することができる。アプリケーションを更改する必要もないため、クラウドに移行する時間コストリスクを大幅に削減することが可能だ。

3点目は「VMware管理を行う」こと。ハードウェアソフトウェアトラブル対応運用管理メンテナンス対応など、すべてサービスの中でVMware実施する。3カ月に一回の頻度で新しいリリース提供しており、ユーザー要件を反映しながら新たな機能を追加している。

最近アップデートの大きなものとして、日本で第2のリージョンとなる大阪リージョンを設置し、サービス提供を開始したことが挙げられる。例えば西日本地区データセンターを持つユーザーは、より低遅延でサービスを利用できるようになった。昨今は感染症流行地震の発生などによってBCPを見直すユーザーが増え、VMware Cloud on AWSリカバリサイトとして利用するケースも増えている。その意味でも、大阪リージョン活用度が高いといえる。

大阪リージョンサービス提供開始

VMware Cloud on AWSが選ばれる理由は、大きく3つ挙げられる。1点目が既存ノウハウ運用管理手法をそのまま踏襲できるという点。VMware製品ベースとしたクラウドサービスであるため、オンプレミス環境における管理者のスキル運用ノウハウなど、既存資産をそのままクラウド上でも活用でき、新たなスキル習得や、運用管理手法の大きな変更の必要もない。クラウドオンプレミス環境をvCenterから一元管理できる。

VMware Cloud on AWSが選ばれる理由

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 Tanzuの概要

高まるDR環境へのニーズ安価に実現

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の活用課題解決するだけでなく将来への有効投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。

2020-09-22

私は不思議です。なぜAWSを使うのですか?

こんにちわ

私はプログラミングを始めた17歳の男です。

Pythonを使って楽しんでいます

でも1つ疑問があります

なぜAWSを使うのですか?

(ここではAmazon Web ServicesAWSと呼びます)

優秀なプログラマーほどAWSを使っています


でもそれは、私にとって不思議です。

なぜなら、さくらクラウドの方が優れているように見えるからです。

料金、とっつきやすさ、使い勝手、安定感(価格や、システム変更の少なさ)、日本語ドキュメント豊富

AWSが優れているのはその複雑さだけのように感じます

そこで私はAWSを利用しました。

想像と同様に難しいものでした。

料金が引き落とされるときは、その瞬間を見守りました(ドキドキした)

私にはもうダメだと感じました。

私は愚かです。

でもさくらクラウドは、私を見捨てません。

なぜあなたAWSなのですか?

あなたはそれを教える必要があります

私は最上の敬意をこめます

by Masao

2020-05-02

[]2020年4月はてブあとで読むトップ30リスト

はてブホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ

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 NgStanfordの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 一人暮らし新型コロナウイルスにかかった話|ROnote

88あとで/794users 見ずして死ねない日本の伝統建築10

87あとで/1317users リモートワークが 超快適になる製品9選 〜仕事に本気なあなたに〜|村上僚|note

86あとで/425users 「AIをどう習得したのか教えて」と大募集し、技術から集まった記事49本を紹介 - 週末スペシャル日経クロステック Active

86あとで/809users API 設計: gRPC、OpenAPIREST概要と、それらを使用するタイミング理解する | Google Cloud Blog

86あとで/778users Gitでよく使用するコマンドGIFアニメ解説 | コリス

85あとで/395users TypeScript 練習問題集 · GitHub

85あとで/2211users コロナの影響でスーパーで買うカツオ刺身が美味すぎる。|すずきまことnote

[あとで読む]タグの減少が更に進んだ。COVID-19の闘病記がタグを集めた。

2019-10-21

VTuber業界燃えているアップランド企業サイト面白い

株式会社アップランドが、運営するVTuber集団アイドル部」に

所属している夜桜たまの告発きっかけで燃えている。


そのアップランド企業サイト話題になっていたので紹介。

https://www.appland.co.jp/company/


会社概要欄のソースを見てみると、なんと「電話番号」欄がコメントアウト

消されていた。(FAXも同じ)

自社の電話番号欄をコメントアウトする企業とは珍しい。


また、「取引先」には4社のみ記載されているが、これも面白い

以下の通り。

Amazon Web Services, Inc

Facebook, Inc

アップルジャパン株式会社

グーグル株式会社

なんと、取引先はGAFAのみである

なんという意識の高い企業なのだろう・・・


アップランド未来が楽しみである

というかVTuber大手企業でこれって、VTuber未来心配だ。

2018-12-04

日頃より「はてなブックマーク」をご愛顧いただきまして、誠にありがとうございます

このたび、ご利用いただきましたお客さまへお伝えしなければならないことがございます

2018年12月4日(火)8:50より、サーバに致命的な不具合があったため、緊急メンテナンス実施しておりました。

なんとかサービスを再開すべく、「Amazon Web Services」との間で調整をおこなっておりましたが、

データ復旧が難しく大変遺憾ながら、終了の判断をせざるを得ない状況となりました。

このため、大変急なお話しではございますが、本日2018年12月4日(火)をもってサービスを終了させていただきます

長らく「M2 -神甲綺譚-」をご愛顧頂きましたお客さまにはこの様な結果となりましたことを、心よりお詫び申し上げます

2016-12-29

はてブで「Amazon」と検索してみると

昨今話題になってるヤマト佐川関連のブックマークが上位を占めるかと思いきや、まったく違った。

2016年12月29日10:54時点、本文、新着順で検索

Amazon検索結果 (絞り込み: 3 users 以上) 約 3,423 件中 1 - 40 件目 (0.26 秒)

以下略

ECサイト連想させるトピックほとんどなくて、AmazonB2B向けサービスを充実させていることに驚いた。

Amazonって表向きは物流業界革命問題を起こしている要因に挙げられているけど、EC以外のインパクトがどれだけ大きいのか門外漢なので分からない。

↑でブクマ付けた人、何が起きるのか教えて

2016-12-01

アマゾン(amazonaws.com)が提供しているヤフー広告不正クリックサービス

アマゾン(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/)"

このギフハブってアマゾン不正クリックを走らせるプログラムか何かなの?

2008-09-26

Muxtape物語

オンラインで流せるテープ」 を提供していた muxtape が閉鎖して一月。昨日出た、運営者からのメッセージを勢いで翻訳する。

http://muxtape.com/story

http://muxtape.tumblr.com/post/51762430 ←反応

僕は音楽を愛している。

音楽を愛している人にとって、そして音楽そのものにとって、音楽を共有するという欲望は、本質的でかかせないものだと信じている。

愛すべき音楽に出会ったとき、僕たちは友達をターンテーブルの前に集め、CDを貸し、カーステレオで鳴らし、ミックステープを作る。

僕たちは、音楽から感じるものを知っているから。他の誰かにも、それを感じてほしいから。


Muxtape物語が始まったのは、僕がオレゴンでやっていた、週一の大学ラジオ番組だ。

その番組で流した曲の記録のかたわら、そのプレイリストウェブに上げていた。ひとつのブロックが、その週の番組記録したカセットに対応するというものだ。

当時、ミックステープ斜陽の時代に入っていた。でも、あのプレイリストのページは、ミックステープと同じ役割を、そして多くの点でよりよい役割を果たすはずだ。僕は番組を終えてからも、そのことをずっと考え続けた。

ミックステープのように、プレイリストはある意図を持って集められたものであって、その価値は単なる足し算にとどまらない。

ミックステープとは違って、プレイリストには物理的に届けるための制約がない。でも同時に、そこには実際の楽曲がない。

誰かがそのページを見にきてくれても、知っている曲があれば共感してくれるだろうが、 本来リスナーである人たちにミックスを実際に編集する手間を押し付けるのは、もともとの目的ダメにしてしまう。

五年後、インターネット技術が格段に進歩していた。

僕はウェブサイト実験的なUIを試す仕事をしていた。

プレイリストのことをまた考えはじめ、ついにそれに命を吹き込んだのは、その頃のことだ。

僕の音楽を(ミックステープ的な意味で)共有するという欲望はなくなってはいなかった。

だけど、その行き場はなくなりつつあった。

大手のブログサービス音楽ファイルを短期的に置けるようにしていたけれど、

そういう場は僕が求めていたものではない。

カセットテープを手に握ったときにうまれる、突き動かされるような感覚

それを手にしただけで、プレイヤーを探してそいつの使命を遂げさせたくなる。

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の素晴らしさを知っていて、ただ、支払いを欲しがっているだけだった。

その点については同情する。

僕は、共同で提案を行うにはまだいくらか時間が必要だと伝え、決定を先延ばしした。

数週間後、EMIとの会議をした。

彼らは大きく違ったタイプだった。

僕は会議室に入り、8、9人と握手をしてテーブルの前に着くと、目の前に "Muxtape" と題された電話帳並のファイルがあった。

彼らは半円状になって左右の脳のように僕の回りに陣取った。片方は法律、もう片方はビジネス企画

会議の相手は交互に切り替わった。

貴方意図的に権利侵害をしている、サービスを止めるまでに数時間の猶予は与える」という法律サイドハードな尋問と

「仮にサービスを止めさせられなかったら、どのような協力がありえると思うか?」というおずおずとしたビジネスサイドとの議論。

僕は提案を作るのに二週間を求めたが、二日と告げられた。

決断をしなければならなかった。

僕がみるに、選択肢は三つ。

第一は、全てをやめること。これはずっと考えていなかったことだ。

第二は、メジャーレーベルコンテンツを全て禁止すること。これなら、直近の危機を回避することができそうだが、二つ大きな問題があった。

ひとつは明らかなことだけど、ユーザーがミックスに使いたいと思う大半の音楽を禁止することになってしまう、ということ。

もうひとつはメジャーレーベル以外に関して、楽曲所有権と利用をどう扱うべきかという重い問題についてなにもやらないに等しい、ということ。

中規模のレーベル独立アーティストにも、彼らのコンテンツがどのように使われているかについて、それほど圧力は使えないにしろ、大企業と同様の基本的な権利がある。

第三の選択肢は、完全にライセンスを受けるモデルにすること。

これは、ユニバーサルの人に会ってからずっと挑戦していたことだ。

他のサービスライセンスを受けているものは、いろいろな理由でうまくいっていることを知っていた。

同時に、Muxtapeの場合は違うということ、少なくとも模索する価値はあることを知っていた。

レーベルがそこに価値見出しているかどうかという疑問の答えは得られていなかったが、次の疑問は、それにどれだけの費用がかかるか、だった。

六月。

僕は五番街の法律事務所に、メジャーレーベルとのライセンス交渉の代理人をつとめることを求めて、彼らは承諾した。

二週間後、今度は弁護士を同席して、僕は四レーベルに会った。

そして、取引をするための遅々としたプロセスが始まった。

第一回は、堅苦しく複雑だった。だけど、思ったほど悪くはない。

僕は彼らを説得し、Muxtapeがこのままサービスを続けることが皆にとっての最良の利益になる、と納得させた。

これでうまく行きそうだった。

さらに二ヶ月、投資家と会合を持ち、サイトの次のフェイズ設計し、交渉監督した。

困難が予想されたのは、Muxtapeが単純なオンデマンドサービスではない、という点で、オンデマンドよりは支払いが低くて済むはず、という点を考慮に入れてもらえるかどうかだった。

ライセンスの条件からはじめたかったのは、めずらしいwin-winになると思ったからでもある。

僕は、どんな通達があっても(at any given notice)、楽曲検索して再生する機能を持たせたくはなかった。

一方、彼らもそういう昨日にあまりいい顔はしない(少なくとも、今の価格では)。

Muxtapeの特徴的な機能は、複数の意味で強みになった。

最初の危険信号は八月に来た。

それまでは、すべての議論は数字に関するものだったが、

合意に近づくにつれて、掲載位置の販売とかマーケティングの方向性に話が移ってきた。

Muxtapeモバイルバージョンを提案したが、否定された。

僕の柔軟性は身動きできなくなっていた。

Muxtapeに対して公正な取引をすることに心を割いてはいたけど、僕がずっと持ちつづけていた最大の関心は、サイトの統一性と使用感を保つことだった。

(それはライセンスを求めはじめた元々の理由のひとつでもある)

Muxtape経済面での各種の侵略に合意したのも、動かしたい(play ball)からだった。

だけど、編集創作についてコントロールを手放すのはものすごくつらいことだった。

これと格闘している最中MuxtapeサービスホストしているAmazon Web Servicesから通告を受けたのが、8月15日

RIAAからの訴状AWSに届いている、と。

Amazon規約によれば、とんでもなく長い一覧に挙げられた楽曲を一営業日以内にすべて除去しなければ、

サーバーを止められて全データ削除されることになっていた。

これはかなりの驚きだった。

RIAAからの連絡はずっと途絶えていたのだけれど、僕はこれをレーベルの理解が得られたためだと思っていた。

パニックになりながら何度かAmazonメールを交換し、

僕はライセンス交渉最中にあること、これは事務的な間違いじゃないか、夏の金曜日の午後をとりもどせるようにするためにはなんでもしよう、ということを説明しようとした。

営業日どころか、週末を越えて月曜日までやり続けても、結局、Amazonが要求する文書を作ることはできなかった。RIAA電話で連絡したけれど、受けてもらうことさえできなかった。

そしてサーバーは止められ、アカウントは停止された。

僕はドメインネームを新しいサーバーに移して、

これを解決できるはずだという、ほんとうに感じていたままの期待をそこにメッセージとして残した。

僕はまだ、これがなにかのひどいミスだと思っていた。

でもそれは間違いだった。

事態がすこし把握できてきた次の週。

RIAAの動きは、レーベル親会社とは別の、自律したものだということ。

レーベルとの間で得た理解は、RIAAには継承されないということ。

どのレーベルも、僕を助けることに特に興味を持っていないということ。

彼らの見かたでは、交渉には影響しない、という。

僕は納得しなかった。

取引にはまだ数週間か数ヶ月(インターネット上では永遠に等しい)はかかる。

つまり、Muxtapeはすくなくとも年末までは止まったままということだ。

また、どうやって支払うかという問題も残っていた。

この変わりやすい世界では、急成長するウェブサイトがある場合でさえ、投資を受けるのは難しい。

サイトがまったくない状態では、筋違いもいいところだ。

だから僕は、これまでの人生で一番つらい決断をした。

ライセンスの取引すべてからの撤退。

どの取引も、単純さを信条とするこのサイトに対しては複雑過ぎるものになりつつあり、

僕がやりたい方向のイノベーションにとって、制約が強すぎ敵対的すぎるものになりつつあった。

開発にほとんど注意を向けられなくなってしまった結果、僕は自分モチベーションに疑問を感じはじめていた。

僕は、すべてを犠牲にして急スピード大会社を建てるために、これをはじめたんじゃない。

僕がこれをはじめたのは、音楽を愛する人たちのために単純で美しいなにかを作りたかったからだ。

だから、またそこからはじめたいと思う。

約束したとおり、サイトは復帰させる。

でも、いままでどおりのものではない。

ある、開発初期段階にある機能を取り入れるからだ。これからはその機能に中心的な役割を持たせたい。

Muxtapeは、バンドだけのためのサービスとして再出発する。

インターネットで活動するための、これまでにないシンプルで強力なプラットフォームとしての機能を提供する。

2008年ミュージシャンは、ウェブ開発者と手を組まない限り、オンラインで地位を確保する手段はほとんどない。

しかし、彼らのニーズは、実は共通の問題の中にあることが多い。

あたらしいMuxtapeは、バンド自分楽曲アップロードして、それを埋め込みプレイヤーとして提供し、

もともとのMuxtapeの形式に加えてウェブのどこででも動かすことができるようになる。

魅力あるプロフィールを取り付ける機能、さらに、カレンダー写真コメントダウンロード、販売、あるいはニーズのある他の全ての追加機能のモジュールを提供する。

システムは0の段階から無限拡張することができ、CSSデザイナーが使えるようなテンプレートシステムの層を設ける。

詳細は追って公開する。

ベータ版はいまところ非公開だけど、数週間以内に変更する予定。

これは機能の点でかなりの大きな転換だということは、意識している。

でも、Muxtapeの核となる目標は、変わっていない。

僕はいまも、音楽オンライン経験する方法を変革したいと思っている。

僕はいまも、相互接続された音楽のもっとも興味深い側面、新しいものをみつける、という側面を実現したいと思っている。


第一フェイズMuxtapeをこれだけすごい場所にしてくれた皆さんに感謝します。

皆さんのミックスがなければ、ありえなかったことです。

音楽業界はいつかついてくるでしょう。ぜったいに、そうすることになるはずです。

Justin

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