第一回渋谷アドテク勉強会 メモ書き

いやー面白かったす。

以下は個人的メモ書き

懇親会が一番面白いのはお約束的な。

株式会社adingo 鈴木様 @suzu_v

     『Head First Ad Technology and DMP』

大学院でセマンティックWEBの研究をしていた

• 最近のアドテクノロジー (RTBを中心に)
• DMP入門 - cosmiを例に -

1. アドテク イントロデュース 
1. 広告、効果的に出したいよね
2. Behind The Banner  説明がよくできとるな
2. DMPとは
1. ※このサイトでこんなアクションしたら（購入など）セグメントを振る。セグメントで判定
3. cosmi（addingのプロダクト）で使うテクノロジー
1. Cookie付与
1. iPhoneはどうしてる？
2. Haddopでバッチ処理
3. 当該ブラウザが特定のセグメントに属しているか返す
5. Hadoop集計後のオーディエンスDBはMongoで構築
1. でAPIでDSP,SSPで返す
6. Jenkinsで管理
7. PiggyBackでCookie焼いてる
8. ユーザの訪問履歴や個人情報が渡らないように気をつけている（DMPの良心）

Mixi 大谷和史

     Vantageの開発者

     vntg.jp

• mixiのオーディエンスデータを生かした、広告配信プラットフォーム（DSP)
• OpenRTB 準拠。全内製
• mixi外へもオーディエンスデータを生かした広告を配信したい
• 去年の夏から開発、今テスト配信中
• 個人特定や広告配信に不必要な情報はmixiのDBから取れないようにしている
• 個人情報の取扱に超配慮！
• デバイスをまたいだリターゲティング、オプトアウト（mixiのIDと紐付けて）
• AWSを活用
• OpsWorksも使用
• Python、uWSGI
• データストアはKyotoStoreとRedis
• 夏頃から正式販売

株式会社サイバー･コミュニケーションズ メディア開発部 秦様 （営業）

OpenX Market Japan の概要

メディアレップから見た在庫の価値について

• 『AdExchnageから見たDemand Player&Supply』
• OpenX Marketの概要および実態
• 在庫の価値って？（ユーザー VS メディア）
• OpenX Marketの今後の取り組み

• 
  OpenX Market Japan Co Ltd  
• cciの子会社
• 400site 月間100億imps（海外含む）
• ディスプレイ＆スマートフォン
• 主要DSPとは繋ぎ込み済
• OMJにアカウントを作ることで、OpenX全て購入対象
• OMJに在庫を投入する場合は、cciが全て事前に確認してから
• 在庫の価値はユーザー？人？
• OpenX（ターゲティング） VS Adjust（ノンターゲティング）
• もちろんリターゲティングの方が効果、単価とも上だけど。。。
• メディアの特徴を掴むことで上げることができるのでは無いか
• OpenXのWinRate 25%（数％のところも有る）
• 自分向けのコンテンツで、自分向けの広告に接触した場合、興味の喚起度 8倍
• 買われないメディアを安く有効活用
• OpenXのプライベートエクスチェンジ
• プレイヤーごとに見解が違う
• 広告主：自社広告のみ扱うのが欲しい
• DSP事業者：自社DSPのみ動く在庫が欲しい
• メディア：指定案件のみ在庫提供したい
• ヒアリングしていかないと

アマゾン データ サービス ジャパン株式会社 今井様

• 『アドテク界隈におけるAWSの使いドコロ』
• カオスマップにロガのロゴ混ぜてもらってありがとうございますｗ
• FreakOut USリージョン使ってる
• 構成はうちと同じだけどクリエイティブの配信はCloudFront
• AdRoll
• 広告データ、ユーザデータもDynamoDBに載せてるらしい。
• 日に70億
• 10億のクッキーデータ。。。
• DynamoDB 今年4月に6割値下げ。使ってみるか。
• 海外のDSP、SSPはUS EASTに集まってきてるみたい。（ネットワーク的に近いほうが早いから）
• 海外の勉強用 youtube   http://bit.ly/108aSwX

RapidSSLをELBに適用するメモ

事前準備として、CSR作成時のserver.keyからパスフレーズを除去

1.
$ cp server.key server.key.bk
2.
$ openssl rsa -in server.key.bk -out server.key

1. $ cp server.key server.key.bk
2. $ openssl rsa -in server.key.bk -out server.key
3. Enter pass phrase for server.key.bk:  と出るので、パスフレーズ入力

ここからELBだ。

1. AWSコンソールからELB作る
2. ListenersタブからプロトコルにHTTPSを選択し、SSL CertificateのSelectをクリック

3. Certificate Name:*
   	(e.g., myServerCert)
   Private Key:*
   	(pem encoded)
   Public Key Certificate:*
   	(pem encoded)
   Certificate Chain:

4. Certificate Name  ：判別できるように適当な名前をつける
5. Private Key：上記のserver.keyをコピペ
6. Public Key Certificate：サーバ証明書（crt）をコピペ
7. Certificate Chain： https://knowledge.rapidssl.com/library/VERISIGN/ALL_OTHER/RapidSSL%20Intermediate/RapidSSL_CA_bundle.pem
   のからコピペ
8. 443 <-> 443とプロトコルがなってる事を確認してsave
9. httpsで接続して確認

CloudFront使ってみた

とある開発案件で、Javascript XMLHttpRequest、ではまってしまったのでCloudFrontで助けられたって話
（正確にはこれから助けられるはず。。）
（開発で面倒＆ケチってELBと別のサブドメイン使わないで、1ドメインでやってたから、
　別ドメインだとJavascriptのXMLHttpRequestちゃんとchromeで動作しないの失念してた・・・・）

で、何がやりたいかというと、
　1.静的なjsファイルはキャッシュしつつ
　2.動的に動く部分はもちろんno-cache
　3.上記を同じドメインで動かす
というのをやりたくなった訳だ。


当初、JSのキャッシュ部分のみcloudfrontで、動的部分はEC2で別のサブドメイン切って、、
みたいなので上記のエラーにはまり。
JS改修するのは恐らく大変なので。
じゃ別ドメインじゃなくて同じだったらイケるやん？と。
Cloudfrontが動的スクリプトもサポートしたって言うし。

というのが前段。



じゃ、CloudFrontの設定をやってみよー

まずCloudFrontのDistributionを作成

1. methodはDoenload
2. Origin SettingsやBehavior Settingsは、デフォルトをどうするかで貴方のお気に召すままに。
   俺は当初、S3のバケットに置いたJSをキャッシュさせるつもりだったのでその設定で。
3. 作成

作成したCloudfrontを選択して、Distribution Settingsを選択して

1. Origins:Create Origin を押下
   平たくいうと、ファイルの呼び出し元だねー
1. 追加したいキャッシュ元を入れる。
   （S3 bucket or ELB or Other(別ドメイン、AWS以外でもいけるようだけど試してない))
2. Behaviors:Create Behaviors を押下
   こっちは、Requestされたファイルに対しての適応条件って感じ。
   パターン数の数だけ書いて、どれにもマッチしなければdefaultが適応されますね。
   フィルタみたいな感じだねー
   以下は動的に動かしたかった場合の例
1. Path Patarn : Request URIがこの条件に一致する場合に、この動作をしますよと。
   お試して
   *.php
   /hoge
   /fuge
   とした。
2. Object Caching:Customize
3. Mnimum TTL : 0
4. Foward Cookies:None
5. Whitelist Cookies:ブランク
6. Forward Query Stgings : 動作スクリプトがQuery Stgings 使うのかどっちかでお好みで
   今回の自分の例では、必要/不必要 2パターンだったので切り分けてみた。
7. Restict Viewer Access：アクセスに制限を掛けますかと。今回は割愛

他設定、適切にヘッダ等設定されていないとcacheされるよ！
今回はnginxとphp-fpmでの例
不要なの有ったら教えて欲しいっす・・・

1. php.ini
1. session.cache_limiter = nocache
   session.cache_expire = 0
2. ヘッダ追加
   Nginx の HttpHeadersMoreModule を使うと、mod_expiresみたいな事できるみたいだけど
   今回は時間ないのでスルー…ちゃんと調べたい。
   ので、phpファイルででheader()で。
1. header("Cache-Control: no-cache,max-age=0,s-max-age=0");
3. If-Modeified-Sinceの設定もあるが、nginxはデフォルトでexpiresだったのでスルー

確認

で、暫く待ちましてDeployedになったならば、動的にしたファイルにアクセスしてみる。

とりあえず phpで
　echo date('Ymd H:i:s');

で、都度更新されてるか確認。

問題なければ時間が毎秒更新、アクセスログにも”Amazon CloudFront”からのアクセスログが残るはず。

という事で、これで同一ドメインで
静的ファイルはCloudFrontにキャッシュしつつ、動的に動かす必要がある部分はEC2に処理させつつってのが比較的手間もかからず、負荷にも強そうな感じでできそうです。

良かった良かった。っていうかCloudfront強力だなぁ。好きなサービス上げろって言われたら今はCloudfrontあげちゃうかも。
後はSSLに対応してくれたらなぁ。。

さて、これを元に構成図書きなおさなきゃ。。。

RapidSSLをEC2 nginxに適用した際の手順メモ

何か有っても責任取れないから事故判断でね・・

CSRの作成手順

1. 作業場所作成
   $ mkdir -p ssl/ssl-{対象common名} _2013  とかで適当に作業ディレクトリ作成。
2. 作ったディレクトリに移動
3. 適当にファイル作成
   $ touch {Ymd}
   とかで。
   ※ 後のsha1がディレクトリ内のファイルから擬似乱数ファイルを作成する為。
4. 擬似乱数ファイルを作成

   1. $ openssl sha1 * > sha1.dat

5. 作成した擬似乱数ファイルから秘密鍵ファイルを作成

   1. $ openssl genrsa -des3 -out server.key -rand sha1.dat 2048

   2. Enter pass phrase for server.key:  秘密キーを入力
      Verifying - Enter pass phrase for server.key:秘密キーを再入力

6. CSR の作成
   1. $ openssl req -new -key server.key -out server.csr

   2. Enter pass phrase for server.key: {秘密キー入力}
      You are about to be asked to enter information that will be incorporated
      into your certificate request.
      What you are about to enter is what is called a Distinguished Name or a DN.
      There are quite a few fields but you can leave some blank
      For some fields there will be a default value,
      If you enter '.', the field will be left blank.
      -----
      Country Name (2 letter code) [XX]:{JP}
      State or Province Name (full name) []:{Tokyo}
      Locality Name (eg, city) [Default City]:{Shibuya-ku}
      Organization Name (eg, company) [Default Company Ltd]:{HOGE Co., Ltd.}
      Organizational Unit Name (eg, section) []:{Development}
      Common Name (eg, your name or your server's hostname) []:{対象となるメイン}
      Email Address []:{何もしないでenter}

      Please enter the following 'extra' attributes
      to be sent with your certificate request
      A challenge password []:{何もしないでenter}
      An optional company name []:{何もしないでenter}

   3. CSRが作られる。
7. CSRをRapidに送って第一部完。

CSRをRapidに送って第一部完。

以下の手順はサーバ証明書発行が完了してから

nginxへの適応（NOT ELB！ELBはこの後調査)

1. 【通知】 SSL サーバ証明書発行完了のお知らせ
   とメールが届く
2. SSL関連ファイル置き場所作成

   1. $ mkdir -p /etc/nginx/ssl

3. nginx virtual.conf編集
   
   1. 以下を追記
      

   2. server {

          listen 443 default ssl;

          ssl on;

          # サーバ証明書（サーバ証明書に中間CA証明書を連結したもの）

          ssl_certificate      /etc/nginx/ssl/{ドメイン名}/cert.crt;

          # 秘密鍵

          ssl_certificate_key  /etc/nginx/ssl/{ドメイン名}/server.key;  

      ・・

      ・・

      ・・

      }

4. ファイル作成 cert.crt
   1. nginxでは、サーバ証明書（crt）と中間証明書をくっつけた形式で使う模様
   2. メールで送られてきたサーバ証明書と、
      クロスルート仕様の中間証明書を1ファイルに纏める
      ※メールで送付された中間証明書は、スマホ対応してないようなのでクロスルートを使う事
   3. base.crt にメールで送られてきたサーバ証明書、
      中間ファイルをchain.crtとして、保存

   4. $ cat base.crt chain.crt > cert.crt

5. ファイル作成 server.key
   1. CSR作成時に作ったserver.keyを持ってきて配置
6. nginx restart
7. https アクセスして確認

おまけ：パスフレーズを削除
スケールアウトさせたりするのに不便なのでー

1. $ cp server.key server.key.bk
2. $ openssl rsa -in server.key.bk -out server.key
3. $ Enter PEM pass phrase:[パスフレーズ入力]

でserver.keyを置き換えてnginx restartして確認。

ELBにSSL証明書仕込む時もパスフレーズ削除しなきゃだしねー