@thorikiriのてょりっき

@thorikiriがWebとかAndroidとかの技術ネタや本を読んだブログです

appengine ja night #ajn21 に行ってきました

めもったことを書いておきます。

GAEで使えるぞ!!SPDYとその実践

  • 資料→spdy
  • 関連→SPDY - The Chromium Projects, こてさきAjax:SPDY - livedoor Blog(ブログ), Wakachi demo
  • 導入
    • Webサービスって変わってきたよね。
    • 画像とか、JSやCSSなどのリソースが増えてきている
    • 一方でHTTPはこの20年間多少バージョンアップしたけれどもあんまり変わってない。もとからシンプルなプロトコルだったから。
      • リクエストを投げて、戻ってきたら次のリクエストを投げる感じ。これをリソースが増えてもやっているから結構大変です。
    • そこで、複数TCPチャネルを使ってやるようになった。
      • 一方で、複数のリクエストが同時にされるので、サーバ側は厳し
      • HTTP1.1では同時には2つまでにしようとした
      • ChromeとかFireFoxなどのモダンブラウザは6個以上にしている
    • サーバ側は、NAT、Proxy、Firewallにも負荷がかかるようになった。
  • SPDY
    • Googleが提案しています。
    • Webを高速化するためのものです。
    • 2009年から話があって、今現在はver2です。
    • GoogleのサービスはSPDYでも提供されています。
    • Chrome, FireFox, Kindle Fireのブラウザが対応されています。
    • 1つのTCPセッションで複数のリクエストを投げつけます
    • 同じサーバに複数のリクエストを送信するときリクエストヘッダが同じになるので同じものは圧縮します
  • TLS
    • SPDYはHTTPで送るとProxyとかFirewallとかLoadBalancerなどでブロックされてしまいます。
    • それを避けるために、TLSで暗号化してトンネリングしています。
    • ブラウザがサポートしているかサポートしていないかを判断してHTTPSかSPDYか使い分けます。
    • 複数のリクエストはKeyValueの形式でリクエストを管理します。
      • なので、リクエストの順番とレスポンスの順番が異なっても問題なく扱えます。
      • ヘッドラインブロッキングもしません。レスポンスを返せるようになったものから順番に返します。
      • パイプラインではありません。
  • SPDYの2つのレイヤー
    • Framing LayerとHTTP Layer
    • つまり、HTTPだけではなく、その他のプロトコルでも使えます
    • バイナリに圧縮されてレスポンスされます。
  • サーバプッシュ
    • chatではありません。そのような用途では使わない方が良いです。
    • ダウンロードのスピードを上げるためにやっています。
    • 通常はHTMLファイルを1度リクエストし、レスポンスを貰ってからHTMLの中のリソースを順次リクエストしていきます。
    • SPDYでは、最初のリクエストのレスポンスのHTMLの中のリソースをサーバ側から送り付けます。送られてきたリソースはブラウザがキャッシュするので、順次リクエストをせずともキャッシュを表示するので高速です。
  • どうやって使うの?
    • Apache+mod_spdy
    • Ngnix+patch
    • アプリ側は特に対応を取る必要はありません。
    • Google AppEngineの場合は、プロトコルHTTPSにするだけで使えます。
      • channel APIもSPDYになります。
    • node.jsの場合は、SPDYに対応している場合にはサーバープッシュをしてあげるなどの実装をすることも出来ます。
  • Tips的な
    • 大きいファイルはやめた方がよい
      • 暗号化されて送られるので、暗号化復号化のコストがかかることになります。
    • CDNはダメっぽい
  • 注意!
    • SPDYだと遅くなるケースもある
    • Kindle Fireでエンハンスモードがなんやかんや
    • なので、単純にやればいいってものではないです
    • GoogleMapはSPDY対応だが、画像はやっていません←嘘でした、やってました
    • Twitterもアイコンとかの画像はやってないらしい(AmazonS3だから?)
    • 使ってみながらベストプラクティスを見つけていってください
  • Tool
  • まとめ
    • 最高のUXを最良のコストで
    • 取り敢えず使ってみてください
  • Q&A
    • スマホのブラウザは?
      • Androidは4.0の標準ブラウザだと対応しています。Chromeは対応しています。
      • iOSはわかりません。
    • Google AppEngineに独自ドメイン設定した場合も使える?
      • SSL的に出来ないと思います。証明書がね。
  • その他
    • MSはTLSではなくて、WebSocketの中でやれば良いのでは?と提案しているらしいです。
    • パケットの中身を見る必要があるようなデバッグは大変かもですね。

数十億件をインデックスなしで数秒で全検索できるGoogle BigQueryってどんな仕組み?

  • 使ってみる
    • サインアップしてコンソールを開きます。
    • サンプルデータがすでに準備されています。
      • wikipediaのデータを検索する。編集回数上位のページを検索する。3億件のインデックスされていないデータを5秒ほどです。
    • SQLっぽいことが結構出来る。ORも複雑すぎないJOINも、副問合せも可能
  • 何がいいの?
    • 後からデータを解析したくなった場合、データベースにインデックスがないことが多いです。
      • 結局はハードウェアを高いお金をかけて良くするしか対応方法がありません。
      • BigQueryは世界最大の分散コンピューティング環境なので、高いお金を自分ではらう必要はありません。
      • Wikipediaのデータであれば月に$4くらいで乗せられますし、1Queryで数セント〜です。
      • オンプレミスでハードを用意すると億の世界
    • Google AppEngineからCloudStorageへの転送料は無料です。
    • ただし、大きい結果は返せません。数値はわかりませんが、1GBでも無理です。
    • アドホックな分析を行いたい場合には向いています
  • どうやって使うの?
  • MapReduceとの使い分け
    • MapReduceではそれなりに時間がかかるので、Try&Errorでやって行きたい場合はBigQueryが良い
    • 大きいテーブルのJOINをするならMapReduceが良い
    • 複雑なロジックを含めたい場合にはMapReduceが良い
    • 処理結果でもってデータを更新したい場合にはMapReduceが良い
    • BigQueryではTransactionはないです
    • バッチ処理のような枯れた処理はMapReduceが良い
    • その場その場でのアドホックなものはBigQueryが良い
  • 速さの秘訣
    • Columnnar Storageだから
    • Mixer検索のテクノロジーだから
    • Columnnar(カラム指向)
      • 列指向だとレコードごとだが、カラム指向ならカラムごとに別々の領域に格納しているから
      • 特定のカラムだけを見たい時には良いです
      • 日付カラムとか同じようなデータが入っているのでデータの圧縮率が高いです
    • Mixer
      • 分散ネットワークを早くします
      • 1つのクエリを複数でやって一番早いものを採用します。
      • 何らかの原因で遅かったり、帰ってこないクエリがあっても複数あるので大丈夫です。
  • ダッシュボード
  • Q&A
    • 表形式(CSV)じゃないとだめですか?
      • ダメです

BigQuery + Google Apps Script

資料→https://docs.google.com/file/d/0BwzWIlBMCiR9d3E3b1NIZHNLY0U/edit

  • Google Apps Scriptって?
    • VBAです。Google SpredsheetとGoogle Siteで使えます
    • 無料で使えます。何故か遅いです。
    • APIとやりとりするのが良いです。あんまりガリガリは使わないでください。
  • 使います
  • BigQueryのAPIは2分類
    • Queryのインスタンスを作る系(JSONを作る)
    • APIを投げる系
      • Project、Dataset、Table、Tabledata、Job
    • AppEngineでAPIを叩くまでもない場合にGoogleAppsScriptを利用すると良いです
  • デモの作りについて
    • GoogleStorageは自前
    • CSVアップロードは自前
    • Documentが見当たらない
  • どんな用途?
    • 今までは解析するつもりはなかったけど取得して貯めておいたデータでやると良いです
    • APIの無料枠があります。100GBくらいなら大丈夫っぽいです

App Engine Search API で嵐を見逃さない方法

  • Search API
    • Solrみたいに使えます。
    • doc_idとフィールド
  • PyCharmかわいいらしい。
    • けどPython使いじゃないからよくわかんなかった

写真共有アプリのバックエンドサーバー

資料→写真共有アプリのバックエンドサーバー
写真共有アプリ→http://cotto.jp/

  • Instagramみたいなアプリのバックエンドを作りました
    • SNSでフォローしている人にだけ写真を公開する機能がある。
      • なので、画像のアクセスに認証が必要である
  • 課金節約のために
    • Frontendでキャッシュします
      • パブリックなものはここでキャッシュすればstaticサーバのようになるので良いです
    • Memcacheでキャッシュします
      • プライベートな認証が必要なものはここでキャッシュします
  • Twitterのタイムラインのようなものの再現は大変でした
    • リアルタイムだとフォローしている人のKeyを取ってきて、そのKeyで検索してソートしてなどしないとダメです
    • TaskQuereでやります。
      • フォローしている人のタイムラインにTaskQuereで突っ込みます
      • TaskQuereで一度に大量にたるのは良くないです。
      • リトライすることもあるので、リトライで沢山の処理が行われる
      • 細かい単位でやって、次のTaskQuereを作るのが良いです

Pythonプロフェッショナルプログラミング

Pythonプロフェッショナルプログラミング