TPACとは?

TPACとは、Webの標準化団体であるW3C(World Wide Web Consortium)が開催する1週間のイベントのことです。様々な国、様々な企業からメンバーが集まり、現在のWeb標準・将来的なWebの機能(例えば、cryptoやaudio)について議論します。今回は、札幌開催であり主要なWebRTC仕様策定者が一同に日本に集結しました。

tpac 2015

最大の議論の焦点となったサイマルキャスト

WebRTCのW3C側の仕様は、まだCR(勧告候補)になっていませんが、ORTCの議論に後押しされるかたちで、既に次世代の仕様である、WebRTC-NVの議論がはじまっています。今回のTPACではWebRTC 1.0(WebRTC-NVに対して、年内に切り上げる予定のWebRTCのバージョンを1.0としている)に対して、最終的にどの仕様を盛り込むのか、が1つの争点となりました。その中でも特に議論が盛り上がったのがサイマルキャスト(Simulcast)です。TPACで展開されたサイマルキャストの議論を理解するためには、先にサイマルキャストそのものを理解する必要があります。そこで、以下でサイマルキャストとは何か、なぜ必要なのか、を簡単に説明したのち、TPACの議論を紹介します。

サイマルキャストとは？

放送業界の用語として、サイマルキャストという用語をお聞きになった方もいるかもしれませんが、WebRTCの文脈で用いられるサイマルキャストは意味合いが異なります。WebRTCで利用するサイマルキャストを一言で表現すると、「送受信側が1つの動画を、異なる品質でエンコードしたストリームを送受信すること」となります。少しわかりにくいので、以下でさらに具体的な例を利用して説明します。

サイマルキャストがなぜ必要なのか？

WebRTCの弱点として挙げられる点として、「多人数会議の実現」があります。P2P通信のみで多人数会議を実現すると、ネットワークトポロジはフルメッシュ形式となり、端末の能力・帯域に限界が来てしまい、接続数がスケールしません。それを解決するための案として、何らかのサーバを利用するスター型トポロジを利用する案があります。サーバには大きく分けて、サーバ側で音声映像を結合するMCU、音声映像を結合せずに分配するSFUがあります。（MCU/SFUの詳細は、過去記事のWebRTCにおけるサーバーソリューションの決め手とは？を参照ください）

SFUを利用した場合、受信側デバイスの処理能力・帯域が豊富にあれば良いのですが、モバイル端末の場合は常に得られるとは限りません。そこで、登場するのがサイマルキャストという概念です。

simulcast

サイマルキャストでは、上図のように送信側が複数の音声・映像ストリームを受信側に送ります。複数のストリームとは例えば、高解像度の映像と低解像度の映像といったストリームを示します。複数ストリームを受け取ったSFUは、受信側の能力に応じて、適切なストリームを分配します。処理能力・帯域に余裕のある受信側クライアントは、高品質のストリームを受信し、余裕のない受信側クライアントは、低品質のストリームを受けとります。その結果、受信側は自身の能力にあったストリームを受信できることになります。

以上が、サイマルキャストの前提知識となります。以降、TPACの議論内容・要点をまとめます。TPACで議論のベースとして用いられた資料はこちらです。

サイマルキャストを実現するために必要な機能

サイマルキャストを実現するためには、送信側のAPI(JavaScript)でまず、2つ以上のエンコードがあることを明示しなければなりません。具体的なコードサンプルは以下となります：

var sender = pc.addTransceiver({sendEncodings: [
 {rid: “F”},
 {rid: “H”, scaleResolutionDownBy: 2},
 {rid: “Q”, scaleResolutionDownBy: 4}
]).sender;

// 補足：Transceiverという名前も新規に登場しています。
// 本記事では、詳細に説明いたしませんが、簡単に言えばRTPSenderとRTPReceiverを管理する親のオブジェクトとなります。

sendEncodingsの値として、rid(暫定的な名前なため、ridという名前自体は変わる可能性があります。詳細はridが規定されるRFCを参照ください)を利用して、複数ストリームを設定しています。ridの値である”F”/”H”/”Q”は単なる識別子であり、この値はブラウザが選択するのか、それともJavaScriptで設定するのか、について議論がありましたが、最終的にJavaScript側で設定する方向で議論が進みました。

また、scaleResolutionDownbyの値によって、送信ストリームの品質を分けています。scaleResolutionDownByはconstraints(制約)と設定する一例に過ぎず、ここで設定する値についても議論がありました。具体的にはフレームレート、最大ビットレート等で十分なのでは、といった意見が出ていました。

SDPによるネゴシエーション？

従来のWebRTCでは、送受信側でコーデックなどのパラメータを、SDPを利用したシグナリングによってネゴシエーションします。ridを利用したサイマルキャストについても、自然に考えれば、同様にSDPを利用したシグナリングになります。しかし、1点問題があります。SDPで規定される内容は、W3Cで規定する仕様ではなく、IETFのMMUSIC WGで規定であるため、仕様策定に非常に時間がかかるのです。(MMUSICの仕様策定には、これまでの歴史から時間がかかるケースが多いため)

そこで、TPACでは

• MMUSIC WGで、サイマルキャスト向けの仕様策定が上手くいった場合
• MMUSIC WGで、サイマルキャスト向けの仕様策定が上手くいかなかった場合

の2点を同時に考慮する議論が進みました。具体的な方針は以下の通りです。

MMUSIC WGの仕様策定が上手くいった場合

SDPでsimulcast向けのパラメータを記載します。たとえば、以下のようになります。

// クライアント側のSDP
a=rid:F send
a=rid:H send
a=rid:Q send
a=simulcast rid:F,H,Q

// サーバ側のSDP
a=rid:F recv
a=rid:H recv
a=simulcast rid:F,H

上記でネゴシエーションされたRIDをRTP/RTCPの拡張ヘッダの値として規定して、クライアント(例：ブラウザ)とサーバ間(例：SFU)でメディアを送受信する動作になります。

メディアの送受信方法には、いくつか案があり、TPACより前に議論の候補として挙げられていたのは、RTPのヘッダに載っているPT(Payload Type)の値を利用して、ストリームを識別する案でした。しかし、その案にはペイロード番号を使いきってしまうなどの懸念(この懸念はIETFのAVTEXT WGで説明がされています)があったため、RIDをRTP/RTCPヘッダ拡張として設定する案で議論が進んでいます。

MMUSIC WGの仕様策定が上手くいかなかった場合

SDPに対する変更は加えられないため、別の方法が必要になります。具体的な方法は、アプリケーション開発者に委譲されており、開発者が任意の手段でSDP以外の方法でシグナリングすることになります。柔軟なシグナリングを必要としなければ、開発者がパラメータを事前に設定しておいて、不要なシグナリングを減らすような案も考えられます。

どちらの場合でも発生される懸念

サイマルキャスト向けのJavaScriptAPIが利用できるようになると、送信側のブラウザが複数品質のメディアストリームを送れるようになります。その際、受信側はSFUではなく、ブラウザであるケースももちろんあります。その場合、「ブラウザは受信すべきか？どう振る舞うべきか？」といった議論もありました。この振舞いの仕様自体は、WebRTC 1.0のスコープ外であり、ブラウザにおけるSimucastの受信は定義されていません。仮にブラウザが受け取ったとしても、ブラウザは単に別のストリームとして扱えばいいのではないか、といった意見が上がっていました。

その他サイマルキャストの仕様策定における重要な考え方

TPACで重要な点として述べられていたのは、「MMUSICの仕様策定が上手くいかなかっとしても、ネットワーク経路上を飛び交うメディア(RTP/RTCP)については変更を加えない」ようにするという点です。シグナリングは比較的に容易にpolyfillができるので、MMUSICが間に合わなくても、MMUSICの仕様策定が終わり、最終的に整合がとれれば良いという考え方です。

サイマルキャスト以外のトピック

以下で簡単にサイマルキャスト以外のトピックを2つほど紹介します。

IPリーク問題

WebRTCは、P2Pで通信する際にICE(RFC5245 Interactive Connectivity Establishment)という技術を活用します。ICEの内部動作としては、可能な限り接続可能性を高めるために、少しでも通信相手と接続できる可能性がある候補を全て収集します。たとえば、プライベートIP、プライベートIPからインターネットへ出ていく際に変換されるNAT後のグローバルIP、などがその候補に該当します。

接続可能性を向上させる、という意味では正常な動作なのですが、全てのIPアドレスを収集するといったその動作の特性上、ユーザのIPが外部に漏れる懸念があります。実際にNY TimesがIP収集に利用していたといった実例もあります。結果として、同じNAT配下にいるメンバが外部に漏れてしまう、ネットワークトポロジが外部に漏れてしまう、複数のアドレスが同じであることを利用して個人特定に利用される、VPN/Proxyで隠されるべきアドレスが露出してしまうといった懸念があります。これがWebRTC界隈で話題にあがっているIPリーク問題です。

TPACでは、IPリーク問題に対する対応策としてこの資料をベースに議論が実施されました。

結論のみ述べると、以下の4種類のどれかの振舞いをすることで問題を解決します。

1. 全ての候補を収集する(ただし、getUserMediaの同意があるときのみ)
2. 制限付き収集その１(ローカルはデフォルトの候補のみと、RFC1918で規定されるアドレスの候補を集める。これがデフォルトの動作になる)
3. 制限付き収集その２(ローカルの候補は無し。ただしpreferenceやextensionで設定が必要)
4. プロキシのみ(preferenceやextensionで設定が必要)

上記の[2]においては、どの程度のアドレスを集めるのか、選択肢が2つあります。選択肢の1つ目はデフォルトのホスト候補のみ、もう1つの選択肢はRFC1918の全ての候補を集めるといったものです。結論は、実際に計測実験を実施して、接続確率がどの程度低下してしまうのか、たしかめてから最終的な動作を決定する、といった結論になりました。

RtpTransceiver

新たにRtpSenderとRtpReceiverをまとめ、SDPのm=セクションをモデル化したオブジェクトとして、RtpTranceiverが追加されています。アプリケーション開発者はRtpTranceiverを利用することで、メディアストリームトラックの行き先を柔軟にコントロールできるようになります。

TPACではRtpTransceiverに関する議論がいくつかあり、例えばこれまでのWebRTCでa=recvonlyを設定するために利用していたOfferToReceiveオプションは、Tranceiver側でも制御できるようになるため削除する、などが議論に上がりました。

最後に

ここまで、TPAC WebRTC WGでの議論となった課題の背景、議論内容を紹介してきました。2日間の議論であったため、全てを本記事で紹介できたわけではありません。さらに興味のある方は、以下のアジェンダ・議事録をご覧ください。

• アジェンダ
• WebRTC WG 1日目議事録
• WebRTC WG 2日目議事録

連載3回目の今回は、SkyWayの付加機能としてリリースされているSkyWay音声認識機能の利用方法についてお届けいたします。SkyWay音声認識機能とは、クライアント（ブラウザ側）でマイク等を通じて入力した自由発話音声を、サーバ（SkyWay側）と連携して、文字列として受け取る機能のことです。いますぐ試してみたい方は、デモサイトから試用可能です。(注：WebSocketが疎通する環境でないと、正常に動作しません)

同様の機能を実現するAPIとして、Speech Recognition APIがありますが、caniuse.comでも示されるように対応するブラウザが限定されています。SkyWay音声認識機能では、標準では対応していないFirefox等のブラウザも対応可能です。

準備

以降で記載するサンプルコードの中で、SkyWayが提供しているAPIキーが必要となります。実際にお手元で試される場合は、SkyWay公式サイトから開発者登録を行ってください。本記事のサンプルで利用するには、利用可能ドメインに「localhost」と書いた、APIキーを取得する必要があります。

今回作成するサンプル

作成するサンプルは、「音声認識を開始するボタン」と「認識結果を表示するエリア」の2要素のみで構成するシンプルな音声認識アプリケーションです。

スクリーンショットはこちらです。

SkyWay音声認識スクリーンショット

こちらを構成しているサンプルコードは以下の通りです。

<!DOCTYPE html>
<html lang="ja">
<head>
	<title>SkyWay Speech Recognition Sample</title>
</head>
<body>

<!-- 音声認識開始用のボタン、および結果表示用のエリア -->
<button id="start_rec">start</button>
<div id="result"></div>

<!-- 必要なライブラリ群の読み込み  -->
<script src="https://code.jquery.com/jquery-1.11.3.min.js"></script>
<script src="https://skyway.io/dist/msgpack.codec.js"></script>
<script src="https://skyway.io/dist/libspeexdsp.js"></script>
<script src="https://skyway.io/dist/resampler.min.js"></script>
<script src="https://skyway.io/dist/speechrec.min.js"></script>

<!-- 音声認識用のコードサンプル -->
<script>
SpeechRec.config({
   'SkyWayKey':'3969c30a-2789-4e46-9155-79a188256633',
   'OpusWorkerUrl':'libopus.worker.js'
});

$("#start_rec").click(function(){
	SpeechRec.start();
	console.log("音声認識を開始します");
});

SpeechRec.on_proc(function(info){
	console.log(info.volume);
});

SpeechRec.on_result(function(result){
    console.log(result.candidates);
    $("#result").text(result.candidates[0].speech);
});
</script>

</body>
</html>

上記HTMLを任意の名前で保存してください。本記事ではsample.htmlという名前で保存します。また、htmlを格納するディレクトリと同じ階層に

• libopus.js
• libopus.worker.js

の2ファイルを保存して置いてください。音声認識に必要なライブラリとなります。　

動かしてみよう

既にApacheやNginxをインストールされている場合はそちらも活用できますが、今回はpythonからシンプルなWebサーバを起動してみます。コマンドはpython -m SimpleHTTPServerです。

localhostの8000番でWebサーバが起動するので、http://localhost:8000/sample.htmlへ、Chrome/Firefox/Operaのいずれかでアクセスしてみましょう。画面が表示されたら、「start」ボタンをクリックすると、マイク使用許可確認のポップアップが表示されますので、Allow/許可を押下します。その後に自由に発話して、適当なタイミングで発話をやめてください。音声認識結果が上手くいくと、数秒以内に音声認識結果の文字列が表示されます。

コードのポイント解説

SkyWay音声認識機能を利用するためには、大きく分けて2つの処理が必要になります。

1. コンフィグの設定・コールバックの設定

まずSpeechRec.config関数を利用して、SkyWayKeyおよびlibopus.worker.jsへのパスを設定します。サンプルでは、以下のようにconfigを設定しています。

SpeechRec.config({
   'SkyWayKey':'3969c30a-2789-4e46-9155-79a188256633',
   'OpusWorkerUrl':'libopus.worker.js'
});

SpeechRec.configには、その他のパラメータも設定可能であり、ドキュメントから確認できます。

次に各種コールバックの設定をします。サンプルでは2種類のコールバックを設定しています。

SpeechRec.on_proc(function(info){
	console.log(info.volume);
});

SpeechRec.on_result(function(result){
    console.log(result.candidates);
    $("#result").text(result.candidates[0].speech);
});

1つ目のon_procは、発話時の音声ボリュームを取得できた場合に発火するコールバック関数です。サンプルでは、コンソール画面に音量を表示するようにしています。

2つ目のon_resultは、音声認識結果を取得できた場合に発火するコールバック関数です。サンプルでは、結果をコンソール画面に表示する処理、および#resultで指定されるdivエリアに、音声認識結果を書き込む処理をしています。

サンプルでは分かりやすいように、コールバックを2つのみしか設定していませんが、実際にはさらに多くのコールバックを設定可能です。詳細はコールバック関数一覧をご確認ください。

2. 開始・停止の実行

コンフィグおよびコールバックの設定が完了したら、実際に音声認識を開始・停止するための関数を呼び出します。サンプルでは、#start_recボタンがクリックされた際に呼び出すSpeechRec.startが、音声認識を開始するための処理に該当します。

$("#start_rec").click(function(){
	SpeechRec.start();
	console.log("音声認識を開始します");
});

なお、開始だけではなく任意のタイミングで音声認識を終了させるSpeechRec.stop等もあります(サンプルでは省略)。その他の関数はドキュメントから確認いただけます。

おわりに

いかがでしたでしょうか。今回はSkyWayの付加機能である、音声認識機能について解説いたしました。

次回は画面共有を簡単に実現するSkyWayScreenShareライブラリについてお届けします。

This article originally appeared in English at webrtcHacks and has been translated with webrtcHack’s permission for posting to html5experts.jp in Japanese. Please visit webrtchacks for edits, updates, and comments.

イントロダクション

このブログ(webrtchacks)にある昔の記事の1つは、Amazon MaydayをWiresharkで分析して、内部でWebRTCを使ってるか確かめよう、というものだった。当時はWebRTCが出始めの段階だったので、大規模なWebRTC利用例は、WebRTCコミュニティにとって重要なマイルストーンだったんだ。

最近では、Philipp Hancke（Fippoとして知られる）がいくつかの素晴らしい記事を出していて、Google hangoutsや、MozillaのHelloを分析している。これらの分析は、WebRTCが大規模にデプロイして上手くいくかってのを実証してくれている。また、デベロッパやアーキテクト向けには、どうやったらWebRTCのサービスを作れるか、という点についての貴重な洞察になる。

こういう記事は最高だから、もっと欲しいのは当たり前だよね。

ということで、嬉しいことにもう1つが記事できたよ！WebRTCの事実に基づく情報を広めるために、GoogleのWebRTCチームが&yet(Fippoの雇用主)に、詳細なリバースエンジニアリングを加えつつ、分析レポートを書くようお願いしたんだ。Philippは承諾してくれて、分かったことなどをwebrtcHacksで書いてくれることになった！もちろん、この分析はかなり時間がかかる。分析は大変だけど、多くの人に見てもらうことはもっと大変なので、webrtcHacksではいつもの公平で非営利な感じで手伝うことにしたよ。

じゃあ、FippoのWhatsApp音声アプリの分析を見てみよう。

{ “導入の執筆者” : “chad” }

Philipp Hancke deconstructs WhatsApp to search for WebRTC

TechCrunchあたりで噂になった後、WhatsAppはAndroid向けに音声通話をローンチした。これはWebRTC業界で一気に話題になって、Tsahi Levent-Leviも加わって、 この話題についての議論が白熱した。残念なことに、ThahiのブログBlogGeek.Meのコメント欄は小さすぎたので、webRTCHacksで記事として書くことにしたんだ。

ある時、いくつかのモバイルサービス向けの分析をしようと思っていたのと、Google WebRTCチームのサポートもあって、WhatsAppのアプリを複数のシナリオでとったWiresharkのキャプチャを見るのに、数日間の時間を使うことができた。

最初は、単にキャプチャをして中を見ようとしたんだけど（将来的にこれも記事で説明するかも）、面白い情報がもっとたくさんあって、学ぶべきことが多そうだってことがわかってきた。だから、15ページのレポートを書いたし、それはここから入手できる。かなり長いパケットの中の話で、エンジニア以外にはつまらないだろうから、この記事で要約してみるよ。

要約

WhatsAppはPJSIPライブラリを、VoIP実装のために使ってる。キャプチャを見ると、DTLSなんかなくて、SDESを使ってるように見える。（詳しくはVictorのこの記事を見てね)STUNは使われてるんだけど、STUNのバインディングリクエストにはICE関連の属性がない。RTPとRTCPは同じポートで多重化されてる。

Audioコーデックは完全には分からない。サンプリングレートは16kHzで、コーデックの帯域はだいたい20kbit/毎秒ぐらいだ。これはミュート時もかわらない。

stringsツールを使って、バイナリを観察してみたら、PJSIPといくつかの文字列が出てきて、その文字列から、webrtc.orgの音声エンジンにあるいくつかの要素(アコースティックエコーキャンセラ、AECM、ゲイン制御、ノイズ抑制、ハイパスフィルタとか)を利用してることがわかった。

WebRTCとの比較

リレーからP2Pへのスイッチ

いろいろと見つけた中で最も感動的だったのは、最初は中継ノードを使って呼を確立して、後でP2Pにスイッチするっていう最適化だ。 これによって、呼が確立するまでの時間が早くできる。また、将来的にマルチパーティのVoIPへの可能性も広げてくれる。中継サーバは、バイナリを見ると「conf bridge」って呼ばれてるようだ。

最初のセッションを説明してみよう（PDFに詳細なものが書いてあるから、気になったらそっち見てね）：

1. セッションは、TURN ALLOCATEリクエストを8つ異なるサーバに送るところからスタートする(パケット #70)。これは、普通のSTUN属性(見落としがちな)を使ってない。
2. レスポンスを受け取ったら、シグナリングサーバと情報交換をはじめる。これは、集めたリレー候補をシグナリングサーバに送って、他方のピアへ候補を送ってるんだろう。
3. パケット(#132)は、TURNサーバ群の1つに何かを送ってることを示してる。これは実はRTCPパケットで、その後にはRTPが続く。Wiresharkの「decode as」って機能を使って見つけられる。これはWebRTCだと普通じゃなくて、ミスリーディングな感じだ。だって、標準的なTURNの機能（send/data indication)を使ってなくて、代わりに生のRTPを使ってるからだ。
4. パケット#146は他方のピアから受信する最初のRTPを示してる。だいたい3秒ぐらいの間、中継サーバを通して流れてきてる。
5. その一方で、#294のパケットは相手ピアのグローバルIPアドレスにSTUNを送ってる。Wiresharkのフィルタ((ip.addr eq 172.16.42.124 and ip.addr eq 83.209.197.82) and (udp.port eq 45395 and udp.port eq 35574))を使えば分かる。
6. そのレスポンスが#300のパケットだ。
7. で、また面白いことが起こってる。クライアントはRTPストリームの行き先を、#298と#305でスイッチするんだ。RTPとしてデコードすると、RTPのシーケンス番号を確認できる。このスクリーンショットを見てみて：

switch

これで、全てをRTPとしてデコードできてるなら（Wiresharkのデフォルトだと難しいから、多少の工夫は必要）、フィルタをrtp.ssrc == 0x0088a82dに変えれて、もっと詳しく見れるはずだ。

ここでの意図は、確実につながる接続を試して(同じ根拠を別の記事であるminimal viable SDPに書いた)、それからTURNサーバの負荷を下げるために、P2P接続へスイッチするんだ。

マジか！これは賢いね。ユーザーからしたらつながるまでに時間を短くできる。もっかい繰り返すけど、UXを向上させるためのハックだ！

定量化するのは難しい。大規模に実験すれば(標準的なアプローチと、今回のアプローチを両方ね)、答えられるようになるだろうね。

WebRTCへのレッスン

WebRTCでは、だいたい似たようなことをできるけど、今のところは小さい。iceTransports: 'relay'って書いて呼を確立できて、これを使えば、hostとserver-reflexiveを使った候補をスキップできるってわけだ。また、中継サーバを使えば、接続できる確率も上げられる。

このアプローチには、TURNのpermissionの仕組みのため、RTTの観点からいくつか欠点がある。基本的には、TURNのリレー候補を集めるときは、以下のように動く。（実際にはChromeとFirefoxでちょっと違うんだけど）

1. Chromeはまず認証なしでAllocationを作ろうとする
2. TURNサーバは、「認証が必要だよ」って答える
3. Chromeは、認証付きでもう一度トライする
4. TURNサーバはChromeには、ICE候補のアドレスとポート番号を伝える
5. Chromeはonicecandidateコールバックを使って、JavaScriptレイヤにもらった候補を伝える。ここまでで、RTTは2回分だ。
6. リモート候補を処理したら、Turnで実際にトラフィックを中継する前に、ChromeはTURNにpermissionを作るよう依頼する。これはココで書かれてるセキュリティの仕組みだ。
7. STUNバインディングリクエストを中継アドレスに送れるようになる。このとき、TURNのsend/data indicationを使える。
8. ICE候補にお互いで同意できたら、Chromeは、オーバヘッドを減らすためにTURNチャネル（相手ピア向かいの）を作る。

上のWebRTCのアプローチと、Whatsappのそれを比べると、ラウンドトリップの回数がかなり削減できる！

これがUser Experienceを向上させるためのハックだ！

もし、まずリレー候補だけから開始できるなら、通信相手同士で互いのIPアドレスが分からない状態なので、中継サーバ経由で接続確立して、受信側が呼を受けるって決める前にDTLSのハンドシェイクも済ませられる。これは、トランスポートウォームアップとして知られていて、メディアが実際に流通しはじめる前に、ユーザーが感じる時間を減らせる。

リレー候補が確立できれば、SecConfiguration（昔はupdateiceとして知られていたやつ。いまは実装されてない）を利用して、中継サーバが持ってる制約を取り外しにかかる。で、createOfferをもう一回呼んで、このときiceRestartフラグをtrueにしてね、ICEを再開(リスタート)するわけだ。これでICEの処理がはじまるから、P2Pが接続がつながるかどうか試せる。

updateIceが実装されてないにもかかわらず、今日でもリレー接続からP2P接続へスイッチできる。ChromeならICE再開は動く。なので今欠けている唯一の要素は、iceTransprots 'relay'で、この動作としては単にリレー候補を作るだけだ。で、リレーじゃない候補は、Javascriptで全部落としちゃう。

そうすれば、WhatsAppみたいな動作がWebRTCでもできる。私のお気に入りのsdp修正のサンプルをみれば、実装も簡単だと思う。リレーからP2Pへのスイッチは動くし、コードもあるよ。

ICE再開は今は非効率だけど、実際のメディアのスイッチ（これが実際難しいところ）はシームレスに起こるよ。

私見だけど…

WhatsappのSTUNとRTPの使い方は、ちょっと時代遅れな気もする。議論の余地はたくさんあるんだけど、STUNの使い方は分かりやすいし、 中継接続からP2P接続へリレーするのに使われてる。だけど、ICEは同じことができるし、もっと確実なやり方だ。カスタムTURN機能を使って、生のRTPを会議のブリッジ間で使えば、TURNチャネルのオーバヘッドを何バイトか節約できるけど、無視できるオーバヘッドだ。

完璧な前方秘匿性を持ってるDTLS-SRTPを使わないってのも、プライバシの観点から大いに議論の余地がある。SEDSは欠点を持ってることが知られていて、鍵がばれたら後からでも解読できちゃう。（その鍵はちなみに、シグナリングサーバ経由で転送されるやつだよ）シグナリングでの情報交換は、テキストメッセージに使われるのと同じ方法で保護されてる点に注意。

UXの観点からいえば、P2Pにおける通話中呼のブロッキングが、これまでのシナリオで考慮済みってことを示してる。エコーキャンセルはかなり問題になるけど。webrtc.orgのエコーキャンセラはかなり上手くできていて、バイナリにも組み込まれている。awesomeチョコレートっていう見返りがあれば、WhatsAppのチームがもっと助けてくれるかも。。。

{“著者”: “Philipp Hancke“} {“訳者”: “岩瀬 義昌”}

本記事では、WebRTC Conference Japanのセッションの1つである、「WebRTC DataChannelの活用方法とその可能性」について紹介する。講演者は、Mist Technologies株式会社CEO・田中晋太朗氏だ。

Mist Technologies株式会社　 田中晋太朗氏

セッション内容は、大きく以下の2点である。

• WebRTC DataChannelのおさらい
• ひねりのある使い方事例紹介

以下でそれぞれの内容について紹介する。（発表資料全体はこちらから）

WebRTC DataChannelのおさらい

概要

DataChannelは、サーバを介さずにテキストやバイナリデータを送ることができる。特にバイナリデータが重要で、ArrayBuffer、ArrayBufferView、Blob、Stringを送信可能だ。

DataChannel概要

注意点として、CreateOfferでSDPを作成する前に、createDataChannelしておく必要がある。なぜなら、相手との通信に必要なSDPが作成できないためだ。

プロトコルスタック

DataChannelを支えるプロトコルとしてSCTPがある。SCTPは、簡単に言ってしまえば、TCPとUDPの良いとこどりのプロトコルで、createDataChannelの引数にオプションを設定することにより、動作を変更できる。

ひねりのある使い方

事例1:DHT webrtc-chord

P2P技術が好きな方はご存知かもしれないが、DHT(分散ハッシュテーブル)のアルゴリズムの1つであるchordのWebRTC実装が、webrtc-chordだ。chordは、分散型のKVSに似ており、様々なノードが、バランスよくデータを保持できる。

webrtc-chord

DataChannelはこの中で、データの挿入・検索を実現するために利用されている。特に面白いのは、コントロールプレーン（実際のデータではなく、それを制御する通信のこと）をWebRTCのデータチャネルに担わせている点だ。

WebRTC Chordを利用すると、サーバでデータを持つ必要がなくなり、Pure P2Pに近づく。

事例2:ファイル共有 WebDrop

Mist Technologies社で、ウォーミングアップとして作ったサービスだ。ファイル共有をする際に、クラウドストレージにアップロードしたくないが、メール添付の容量を越えてしまう場合に、役立つ。

WebDrop

実装としては、JavaScriptからFileAPIを利用し、データを送る際に必要なメタ情報を、BinaryPackでArrayBufferへシリアライズして送っている。

Sharefestや、ShareDropが類似サービスだ。

データ送受信の注意点

ブラウザによって実装の違いが大きい点に注意する必要がある。例えば、ChromeやOperaでデータを送る場合は、バイナリの長さに制限がある。制限の長さを越えてしまうと、DataChannelがクローズされてしまう。

データ送受信の注意点1

一方でFirefoxは良く出来ていて、どれだけの長さを送信しても、不都合は生じない。ただし、受信時のonmessageでのバイナリの扱いが特徴的で、Firefoxではblobで取り出せるようになっている。そのため、他のブラウザと処理を合わせるためには、Blobで出てきた場合は、ArrayBufferで処理するように実装する。

Chrome等でバイナリの長さ上限を回避するには、2つの方法がある。

• UDPデータグラムの長さの制限 : あるサイズでデータを輪切り(Chunk)にする
• SDPの改変(b=AS:1638400等)により、帯域を変更する

データ送受信の注意点2

データを輪切りにして送信する場合は、送信側はデータをキューにためておいて、よいタイミングでsendを呼び出して送信する。受信側は、分割して送信されてくるので、Chunkを組み立てる必要がある。

事例3: MistCDN

もう1つの応用としてMistCDNを紹介する。

MistCDN1

MistCDN2

MistCDNはP2P型のCDNで、同じサイトを閲覧している近いユーザから、DataChannelでデータを受信する仕組みだ。フロントエンドの実装はTypeScriptを利用している。

どういう利点があるかというと、CDNを使った場合に、ユーザレスポンスの向上が挙げられる。また、CDN自体の利用量（コスト削減）も実現できる。

類似のサービスも色々あるが、動画の配信という点では、MistCDNに優位性がある。

P2P型CDNの要所

既存のCDNは、HTTPの仕様に沿って実現されており、オーバヘッドが少ない。P2P型のCDNを実現しようとすると、シグナリングが必要になり、オーバヘッドが生じる。オーバヘッドが大きい場合は、結局遅くなることもある。

P2Pの要所

そこで、シグナリングのメッセージを減らす、また、小さいコンテンツはまとめて送る、等の工夫が必要になる。

また、データを受信するPeerを選択する場合には、遠いPeerを選ばないように、帯域を利用する等の工夫をしている。（詳細は企業秘密）
ただし、クライアントサイドのコードは、誰でも読めてしまうので、将来的にオープンソース化も視野にいれている。

対応ブラウザの問題もつきまとうので、iOS向けにネイティブライブラリも開発している。

活用方法とその可能性(Discussion)

DHTのWebRTC実装等の事例を紹介してきたが、いくつかを組み合わせると、サーバの仕事を極力減らして、1つのシステムを組めるようになるのでは、と考えている。

今後登場しそうなWebRTC応用

シグナリングはどうしても必要になるが、SkyWay等のPaaSを使えばサーバを持たなくてよい。また、データについてもChordの上に載せてしまえば、これもサーバが不要だ。

Ustreamはメディアをサーバにアップロードして、各ユーザがダウンロードする仕組みになっているが、これをブラウザで実現できないか。まだ現実的にできるかは、わからないが。

最後に、ブラウザをエージェントとして利用すれば、グリッドコンピューティングも実現できるのではないか、と考えている。

2月5日、6日にかけて「WebRTC」をテーマとした、日本初のカンファレンスであるWebRTC Conference Japanで開催された。本記事では、その中の基調講演の1つである、WebRTCに於けるサーバーソリューションの決め手とは？の内容について紹介する。プレゼンターはDialogic社およびwebrtcH4cKSの主宰であるChad氏だ。

The picture of Chad Hart

当日の発表資料はこちらから

WebRTCサーバで考えるべきこと

WebRTCのサーバサイドインフラストラクチャを考えるに辺り、4つのサーバについて本セッションでは述べる。

• シグナリングサーバ
• NAT越えサーバ
• メディアサーバ(音声・映像・データ)
• ゲートウェイサーバ

シグナリングサーバ

WebRTCの通信は、最終的にはP2Pになるが、その過程でシグナリングサーバが必要だ。具体的にはSIPで使われているようなSDPを使って、メディア接続に必要な情報をやりとりする。

もちろん、単にそれだけではなくて以下のような機能も必要となる。

signaling consideration

• ユーザ認証
• アクセスコントロール、セキュリティ
• プッシュ通知 (特にバッテリ消費に注意)
• フェデレーション（他のサービスプロバイダとの相互接続）
• その他、現実社会で必要とされる機能

これらの機能は、WebRTC標準のスコープからは外れているが、アプリケーション開発においては必要となる機能だ。

NAT越えサーバ

次にNAT越えの機能だ。もし、NATが越えられなかった場合、ユーザにNWを変えてみて、とはサービス開発者がお願いすることは難しい。そこで、NAT越えの機能を提供する必要がある。

（編集部補足：NATの解説については当メディアの記事である壁を越えろ！WebRTCでNAT/Firewallを越えて通信しようが参考になります）

NAT越えに対して、レガシーなVoIPシステムでは、SBC(Session Border Controller)を利用している。 WebRTCは、異なったアプローチをとっており、そのプロトコルがICE(Interactive Connectivity Establishment)プロトコルだ。

ICEでは、STUNとTURNを利用している。

STUN

STUNの役割は、自身の外部のIP(NATの外側)を調べるためのプロトコルだ。そのため、非常にシンプルで軽量で、拡張性もある。　

TURN

前述したSTUNだけでは越えられない課題もある。その場合、TURN(Traversal Using Relay NAT)を利用して、 トラフィックの中継をする。TURNはSBCに似た動作をする。実社会では環境にもよるが、10-15%程度がTURNを必要としている。

comparing STUN vs TURN

STUNと違って、TURNは帯域消費が大きく、運用コストも大きい。もし、エンジニアリング（設計等）が不適切だった場合は、レイテンシの増加、音声映像品質を損なうことがある。

メディアサーバ(音声・映像・データ)

次はメディアの話だ。さきほど見たように、TURNを経由する場合等、メディアはP2Pで流れないケースもある。

実際には、TURNでメディアを中継する以外に、メディア中継サーバを理由はたくさんある。

Many reasons for media server

• MCUを使ったマルチパーティ会議
• トランスコーディング(コーデックを変換すること)
• 既存VoIPとの相互接続
• メディアの録音、録画
• ストリーム処理（例えば、画像をビデオに挿入したり、DTMF音を音声に挿入したりする処理）
• 人とシステムとで通信する場合（例えば、音声認識による自動応答等）

クライアントで処理すべき？サーバで処理すべき？

前述した機能はクライアントサイドでも提供できるし、サーバサイドでも提供できる。それらにはトレードオフの関係がある。

例えば、モバイルデバイスの帯域は常に使えるわけじゃないし、無料でもない。また、特にCPUを消費すると、バッテリ消費も著しい。もし、機能をクラウド側（サーバ側）で提供できるのであれば、これらの課題は、解決/軽減できる。

マルチパーティのビデオ会議例

具体的にマルチパーティのビデオ会議を提供する場合を例にとって考えてみよう。

フルメッシュトポロジのアプローチ

マルチパーティの会議を提供するにあたり、最も簡単なトポロジはフルメッシュの構成だ。

Full Mesh

この場合サーバは不要になるのがメリットだが、クライアント側の処理能力の制限もあり、3-4人が限界になることが多い。もし、エンドポイントが増えた場合は、非効率になる。

スター型:MCUをつかったアプローチ

この課題に対する伝統的なアプローチがMCU(Multipoint Control Unit)だ。MCUはメディアを集約し、ミキシングし、各デバイスに流す。かなり、クライアントの処理負荷が軽いのがメリットだ。

ただし、MCUにも欠点がある。MCUはサーバの処理負荷が非常に高いことだ。特にHD品質のビデオを扱う場合は顕著になる。処理負荷が高い理由は、すべてのストリームをそれぞれ、エンコード・デコード処理する点にある。

MCUを改良した効率良いアプローチを、エンコーダシェアリングを呼んでいる。

MCU Resource Share

もし、複数のデバイスが同じストリームを受信するなら、MCU側のエンコード処理は1回で済む。この方式だと、CPUの利用率を30-50%ほど効率化できる。

スター型：SFUを使ったアプローチ

さらに新しいアプローチがSFU(Selective Forwarding Unit)だ。このアーキテクチャでは、まずクライアントは1つのストリームをSFUに送信する。SFUはエンドポイントが希望するストリームのみをリダイレクトする。

SFUの主なタスクは、ストリームの暗号化・復号化であり、サーバサイドでのエンコード・デコードは必要とされてない。そのため、多くのクライアントを捌くこと可能だ。

SFUにSimulcastの手法を組み合わせた方法もある。 この手法では、クライアントが1つのストリームを送るのではなく、 2つ以上のストリームを送信する。（よくあるのは高品質・低品質の両方を送る)

SFU

効果的な使い方としては、話し手のストリームは高品質の映像を流して、聞き手のストリームは低品質のものを使う方法だ。

実際に、Google Hangoutsでは、この技術を利用している。非常に興味深いのは、Googleは独自の実装を使って、これを実現している点だ。詳しくは、webrtcH4cKSを参照されたい。

VP9,SVC：未来のアプローチ

最後にScalable Vicdeo Coding(SVC)というアプローチも紹介する。

SVC

Simulcastと同様に、品質の異なる複数のメディアをクライアントが送り、SFUがリダイレクトする点は似ているが、SVCでは複数のストリームを1つのストリームにまとめて、レイヤー化している点が異なる。

ゲートウェイサーバ

最後のトピックはゲートウェイサーバだ。WebRTCゲートウェイサーバを提供するには、多くのコンポーネントが必要になる。

Gateway Function

• STUN/TURN : 前述した機能
• HTTP-to-SIP(H2S)：SIPとHTTPを変換する
• Mediaゲートウェイ：DTLSによる暗号化をSDESへ変換、ポート多重化技術等の対応
• トランスコード：VP8とOPUSを、既存のVoIPシステムのものへ変換
• SBC：既存のSIPと連携する場合に、SIPヘッダ修正等が必要
• APIゲートウェイ：システム制御のためのAPI
• SDK：WebやNativeに、WebRTCを追加するための開発キット

ここで重要なのは、上記の要素を提供するにあたり、標準化されているものはない、ということだ。そのため、規模やベンダ、また既に存在している機器を考慮して、必要なソリューションを自身で決める必要がある。

まとめ

現実世界でのデプロイ例

ここまで、いくつかのサーバについて紹介してきた。それらを実現している現実のアーキテクチャ例(とあるアメリカのサービスプロバイダの例)を紹介する。

WebRTC Arhcitedture Example

いくつかのキーとなる機能をピックアップする：

• STUN/TURNの利用
• Secure WebSocket(WSS)によるシグナリング
• GateWayでのH2S実装
• Webメディアゲートウェイでのトランスコード
• REST API経由による通信
• OAuth、OpenIDによる認証
• APIマネージャによるNWの防衛

サーバ技術のまとめ

本セッションでは、シグナリングサーバ、STUNサーバ、TURNサーバ、メディアサーバ、WebRTCゲートウェイサーバについて紹介した。

Summary

実際には、その他にWebサーバや、認証サーバが登場するが、これらは既にデプロイされているものだろう。組み合わせるとかなり複雑に見えるかもしれないが、一部のサーバはVoIP機器の進化系にすぎない。

本記事は、webrtcHacksにて英語で掲載されている記事を、webrtcHacks様の許可を得た上で、翻訳＆掲載している記事となります。修正・更新・コメント等がございましたら、webrtchacks/coturn/ までお願いいたします。

This article originally appeared in English at webrtcHacks and has been translated with webrtcHack’s permission for posting to html5experts.jp in Japanese. Please visit http://webrtchacks.com/coturn for edits, updates, and comments.

イントロダクション

昨年、Oleg Moskalenkoへインタビューし、オープンソースのSTUN&TURNサーバで極めて人気のあるrfc-5766-turn-serverプロジェクトについての記事を公開しました。その数カ月後、Amazonが自身のサービスであるMaydayにこのプロジェクトを利用していることがわかりました。それ以後、IETFにてRFC 5766に多くの機能が新たに定義され、オープンソースの新プロジェクトであるcoTURNプロジェクトが生まれました。

今日はOlegに再度、話を伺って、coTURNの何が新しいのか・coTURNとは何なのか、という点についてキャッチアップしたいと思います。

{“導入の執筆者”, “victor”}

Photo courtesy of flikr user Grant Nicholson

インタビュー

webrtcHacks: 前回インタビューしたときは、rfc5766-turn-serverプロジェクトについて話をしていて、既に商用でも使われている例(WebRTCの例、WebRTC以外の例)があるのを教えてもらったよね。 coTURNプロジェクトの何が新しくて、現在人気のあるrfc5766-turn-serverと何が違うの？

Oleg: TURNとSTUNのプロトコルは進化が早くて、新しいネットワークの接続要件を備えていたり、もっとロバストな能力を提供してきている。ある時点で、新しい要件が現在の”レガシー”なユーザ要求と衝突する可能性があることがわかったんだ。そこで、プロジェクトを2つの開発ラインに分けて、2つのモデルをサポートしようと決めたんだよ。古いプロジェクト(rfc5766-turn-server)は安定したコードと多くのユーザを受けて継続する。つまり、バグフィックスや本当に必要な機能だけを加えて、信頼性のあるコードになる。このプロジェクトは古いスタイルのRFC 5766に準拠して欲しいという要望がある限り、存在し続けるよ。

一方で新しいプロジェクトである”coTURN“(複数レルムでco-locationを提供するTURN)は4月にはじまり、2014年の5月に公開した。最初の主な違いは、新しいIETF TRAMワーキンググループで提案されているORIGIN属性をサポートしたmultiple-realms(複数領域)の仕様に対応している点だよ。

webrtcHacks: 読者はIETFでTRAMが何をやっていることについて詳しくないひともいるので、簡単に教えてもらえる？

Oleg: もちろん。TRAM WGのゴールは、複数の取組みを整理・統合して、TURNとSTUNをもっとWebRTCの環境に適したものにすること。その中では、以下の取組みが含まれている：

• 追加トランスポートとしてのDTLSを追加する
• 認証の仕組み
• TURNとSTUNの拡張

実際、知っていると思うけど、TURNbisやSTUNbisのドラフトにも取り組んでいるよ。私の意見だと、今後やって来る標準の中で最も重要な機能は、oAuthベースの認証と認可の仕組みだね。エンタープライズのユーザ・ISPのユーザにとって、マルチテナントサーバになるのが主要な機能になるだろうね。

これに加えて、多くな小さな追加もある：

• ALPN (Application Layer Protocol Negotiation)
• 帯域制御
• IPv4とIPv6の割り当て(dual allocation)

webrtcHacks: あと、さっき言ってたORIGIN属性もあるよね。

Oleg: その通り、これまで決めてきたものの1つに、新しいORIGIN属性がある。これは、セッション単位での領域選択を可能にするんだ。coturnのデータベースは、複数のレルムでグループ分けされたユーザを保持するようになる。それぞれのレルムは異なるパラメータをおそらく持つ。この機能のおかげで、複雑な大規模環境でもcoturnは対応できる。例えば、1つのIPアドレスとポートしないけど、複数のユーザに対応する必要がある場合とかね。エンタープライズ向けの大規模TURNサーバやISPの運用するTURNサーバも適用例になるだろうね。

webrtcHacks: マルチテナントへの変更って、rfc 5766のTURNサーバのプロジェクトから大きなアーキテクチャの変更が必要なの？

Oleg: アーキテクチャに大きな変更は無いんだけど、データマネジメントでかなりの量の変更があるんだ。これまでの多くのことはシステム全体でグローバルだと想定してたんだけど、これからはレルムに限定されるようになる。そのため、かなりの量のコードを書き換えないといけなくて、それがマルチテナントの移行に向けてとても大変なところなんだ。

webrtcHacks: マルチテナント以外の機能は他にある？

Oleg: うん、もう一つの大きな変更はIPv4とIPv6の2つの割り当てだね。この機能のおかげで、サーバは1つのセッションに対して2つのエンドポイントを割り当てできる。つまり、1つがIPv4でもう1つがIPv6。もしTURNのクライアントがv4とv6の両方でピアとの接続を確立したい場合は、クライアントは同じセッションの中で両方の接続を扱えるから、クライアントとサーバのリソースの節約になる。

Coturnは、サーバ上であるレベルの帯域制御も提供する仕様もサポートしているよ。この機能は、TURNクライアントへ提供するサービスレベルを保証したい場合に役立つよ。

webrtcHacks: プロジェクトのコミットを追っかけてて気づいんたんだけど、データベースのサポートについても何かしているよね。これについて教えてくれる？

Oleg: Coturnでは、もっとロバストで抽象化できるようにデータベースのコードを書き直したんだ。これは、新しい機能の開発に役立つし、新しいデータベースも採用できる。例えば、Coturnは古いTURNサーバのプロジェクトでもサポートしてたRedis、MySQL、Postgresに加えて、MongoDBもサポートしているよ。

webrtcHacks: セキュリティについてはどう？何か改善した？　

Oleg: あるよ、今のCoturnの開発はoAuthベースのサードパーティ認証＆認可について取り組んでいる。また、多くのTURNのセキュリティ課題も修正するつもりだよ。CoturnサーバはoAuthの鍵をデータベースから取得するようになり、外部の独立したエージェントがその鍵があるデータベースを扱うようになる。

webrtcHacks: Coturnのパフォーマンスについてはどう？前のrfc5766-turn-serverプロジェクトに比べてどう？

Oleg: Coturnはrfc5766-turn-serverと同じテストスイートを使ってる。Coturnのコードと機能は、より複雑だから理論的にはパフォーマンスは落ちる。だけど、これまでのテストだと気づけるパフォーマンスは落ちてないね。

TURNとして使うのならCPU1つで数千のコールをさばけるし、STUNだけでいいのなら数万のコールをさばけるよ。

webrtcHacks: デザイン面からパフォーマンスに貢献してそうなところはある？

Oleg: 高いパフォーマンスとスケーラビリティのために、TURNサーバはいくつかの機能を実装しているんだ：

• libevent2の利用 – 高パフォーマンスで、耐久性のあるのネットワークIOエンジン
• 設定可能なマルチスレッドモデル(OSがマルチスレッドを使えるなら、CPUのリソースをフルに使えるように)
• 設定可能な複数のリスニング、および複数のリレーアドレス
• より効率的なメモリ管理モデル
• ユーザスペースで動作して、システムに特別な制約を課さないこと

このTURNプロジェクトのコードは、個別に専有されたネットワーク環境で使われることもある。TURNサーバのコードでは、抽象化されたネットワークAPIが使われているんだ。いくつかのファイルを書き直すだけで、TURNサーバに専有環境に適するコードをプラグインできるよ。このプロジェクトのおかげで、プロジェクトでは提供するのは標準のUNIXのネットワーク/IO APIだけでいいんだ。ユーザは他の環境に適したものを実装できる。TURNサーバのコードはもともと企業の専有環境で高パフォーマンスがでるように作られていて、その後にUNIXネットワークAPIを採用したんだ。　

webrtcHacks: スケールやロードバランスはどうするつもり？

Oleg: もちろん、仮想的には無制限にスケールするようにロードバランスのスキーマは使うよ。ロードバランスは次のようなツールを使って実装できる。1つでも複数の組み合わせでもいい：

• DNS SRVを用いたロードバランス
• 組み込みの300 ALTERNATE-SERVERメカニズム(TURNクライアントからの300レスポンスが必要)
• ネットワークロードバランスサーバ

webrtcHacks: メディアリレーするためにTURNサーバってどのぐらい使われるか知ってる？

Oleg: 異なる統計が異なるデータを出しているね。一般的に言えば、8-15%のコールで利用されているよ。もちろん、特別なアプリケーションによっては100％がTURNサーバを通る。ただ、僕の知るかぎりだとWebRTCのアプリケーションじゃないけど。

webrtcHacks: 開発者が全てのトラフィックをTURNサーバ経由にしないとならないシナリオって何か思いつく？伝統的なVoIPだと本質的にSBCを使うような。

Oleg: WebRTCの世界だとそういうシナリオに関する絶対的な情報は知らないな。だけど、一部のエンタープライズユーザはそういうネットワークパターンを議論しているから、ありえると思うよ。

webrtcHacks: Coturnはどのプラットフォームがサポートしているの？

Oleg: リストにすると長いね。サポートしているプラットフォームは

• Linux – Debina, Ubuntu, Mint, CentOS, Fedora, Redhat, Amazon Linux, Arch Linux, Open SUSE
• BSD – FreeBSD, NetBSD, OpenBSD, DragonFlyBSD
• Solaris
• Mac OS X
• Cygwin – R&D用途でプロダクジョン向けじゃない

このプロジェクトは、*NIXプラットフォームで利用できるはず。ただ、公式にはサポートしてないけど。

クライアントプラットフォームはなんでも大丈夫で、Android、iOS、Linux、OS X、Windows、Windows Phoneをサポートしているよ。

webrtcHacks: 昨年、統計付きパフォーマンスモニタリングも追加したいと言ってたけど、Coturnはそういう仕組を備えているの？

Oleg: 今のところは、パフォーマンスモニタリングのデータはTURNサーバに対してtelnetのインターフェースで取得できて、いくつかのパフォーマンス統計は、Redisの統計データベースから取得できるよ。統計以外だと、今のTURNサーバはパフォーマンスベースの輻輳制御の仕組みを備えているよ。この仕組みはTCPとTLSの接続で動作して、TCP/TLSのコネクションを効率良く自動的にチューニングしてくれる。

webrtcHacks: Coturnの将来のロードマップについて教えてくれる？

Oleg: Coturnは最新のTURNとSTUNの機能に追従していくつもりだよ。IETF TRAMグループは新しいTURNとSTUNのRFC(TURNbisとSTUNbisというコードネームがついてる)を採用する方向に進んでいる。RFCが最終的に定まったら、Coturnサーバは新しい仕様のサポートするように準備するだろう。

加えて、データベースやREST API等を扱える分離されたマネジメントサーバを追加したいんだ。リソースが不足しているから、ボランティアで参加してもらえると非常に助かるよ。

webrtcHacks: 読者がCoturnについての情報を知りたかったらどこを見ればいい？

Oleg: 一番良いのはプロジェクトのウェブサイ卜だよ。https://code.google.com/p/coturn/　必要な情報は、全てリンクするようにしてる。

{“インタビューした人, “victor“}

{“インタビューを受けた人”, “Oleg Moskalenko“}

{“編集者”, “chad“}

{“翻訳者”, “岩瀬 義昌”}

Extensible Web Summitとは

2014年9月11日にドイツ・ベルリンにて、Extensible Web Summitが開催されました。本イベントは、Exntensible Web Manifestoに興味を持つ、Web開発者・ブラウザベンダ・W3Cメンバ等が一堂に会し、未来のWebについてディスカッションを行うというイベントです。

イベント自体は、アンカンファレンススタイルで進められるため、会議の前に議題は決まっていません。会議当日の前半のセッションにて、ライトニングトークが5本あり、その内容を参考にしつつ、参加者自らがトピックが設定していきます。設定されたトピックに沿って、本イベントでは3つのブレイクアウトセッションが平行して開催されます。そして、各参加者は自分の興味のあるセッションに参加します。

本記事では、Extensible Web Summit Berlinでの設定されたトピック、およびトピックの中から特にExtensible Web に関係する議論が行われたトピック2つをピックアップし、その議論模様を紹介いたします。世界中のWeb関係者が、どのような点に興味を持っているか参考になるはずです。

当日決定されたトピック

当日決定されたトピックは以下の通りとなりました。

当日の議論の議事録は、こちらで公開されています。各ディスカッショントピック議事録へのリンクもありますので、詳細確認されたい方は、是非チェックしてみてください。

ディスカッショントピックは、Extensible Webに関するものだけではなく、「このトピックについて、W3Cメンバーと開発者との間で議論したい！」というものも多く存在しました（例えば、WebRTCのセッションでは、『iOSってWebRTCサポートされないの？』『こればっかりは分かんないね〜』といった話題も）。

本稿では、各種トピックの中から特に Extensible Web に関わりの深い二つのトピック（上表にて、強調表示）の議論模様を紹介いたします。

セッション紹介：Extensible Web, Huh?

本セッションのみ、全員参加のセッションとなりました。本セッションでは、『Extensible Webって、実際どうなの？』というテーマで、参加者がディスカッションが行われました。

セッションの進行形式としては、質問/疑問を持っている参加者がそれを発言し、他の参加者が回答する流れとなります。ここでは、主な議論事項を紹介いたします。（議事録は、こちら。要旨理解を助けるため一部、議論の順番を組み直して記載しています。）

まず最初の質問として投げかけられたのが、「Exntensible Webでは、低レベルのAPIを公開することになるが、Webのセキュリティモデルに適しているのか？」という点でした。これに対しては、

同様の課題は、Service WorkerやCORSにもある。

や、

もしExtensible Webを実現するためのテンプレート/パターンのようなものがあれば、セキュリティモデルに対する1つの解になるのではないか。

という回答が上がっておりました。

また、Extensible Webでは、世界中のWeb開発者が独自のWeb拡張を進めることが出来ます。このとき、 「多くの開発者が同じ目的を持って、Webの拡張に取り組んだ場合、どうやってまとめていくのか？複数のWebの世界を作ってしまうのではないか？」 という懸念があります。これらに対しては、少しジョークのニュアンスを含みますが、

READMEが最も簡単で理解しやすいものが、生き残るのではないか。

という回答、また世界中の開発者を巻き込むという観点から

技術に取り組むなら、英語が必要だ。優れなコントリビュータの中でも、英語を使えない人をほとんど知らない。 また、仕様に使われる英語をもっと簡単にする必要もある。

という回答がありました。

その他にも、「必要以上に低レベルなAPIを公開することにより、パフォーマンスに影響が出てしまうのではないか？」という懸念も出てきていました。この懸念に対しては、

JavaScriptのパフォーマンスはそこまで悪くない。

といった意見や、

ブラウザネイティブの機能を利用した方が、polyfillを使うよりもパフォーマンスが良いのは理にかなっている。polyfillを毎回ダウンロードする必要もない。

のように、ネイティブの機能のほうがパフォーマンスは良くなる、といった回答も挙がっておりました。

ここまで記載してきたのは、技術的な側面からの質疑でしたが、その他の側面からのコメントとして、

Extensible Webでは、低レベルなAPIを公開する等の技術的な側面はもちろんだが、社会的な側面も必要となる。社会的な側面とはつまり、世界中の開発者をどうやって巻き込んでいくか？ということだ。

というもっともな疑問も挙がっています。本疑問については、参加者の多くが重要と考えており、以下に続く別セッションへ切り出しとなっております。

セッション紹介：New way to do specs; how to connect specs and developers, next generation standardization, etc…

(本セッションレポートは、小松 が執筆しました。要旨理解を助けるため、議論の順番を組み直して記載しています）

本セッションでは、『開発者が標準化プロセスにもっと関われるようになるためには、どのような取り組みが必要か？』についてディスカッションが行われました。W3C HTML5仕様のメインエディター、Robin Berjon 氏がセッションモデレーターを務めました。（議事録は、こちら）

本セッションのポイントは、仕様エディターと開発者との間の連携やコミュニケーションの実効性を上げていくこと。理由は、仕様と実際のニーズとの乖離を防ぐためです。例えば、この手の議論で失敗例としてよく出てくる AppCache ですが、

「AppCacheの失敗は、開発者が望んでいる機能を仕様化しなかったこと」 「AppCacheの考え方（オフラインWeb）自体は、間違っていない。仕様化の進め方が間違っていた」

という分析を行ったとのこと。これを受けて、Indexed Database APIの仕様化にあたっては、エディターとデータベース技術者とで連携したことを紹介し、W3Cの仕様化に普段は関わっていない、実際の利用者から密にフィードバックを得ることが、良い仕様を作るためには重要との考えが示されました。

開発者からのフィードバック手段として現在良く利用されているのが、BlogやSNSへの書き込み。これらのフィードバックは、エディターにとって非常に重要な情報ですが、

「それらを追いかけるのは、大変」

このため、Specifictionというフォーラムを開設しており、仕様へのフィードバックは、是非ここに書き込んでいって欲しいとのことでした。

また、このようなオープンな標準化プロセスを進めるにあたり、その大枠の考え方を WebPlatform Specs として文書化していることが紹介されました。現状、ポイントとしては

• Forkable
• Hackable
• Thoughtful
• Royalty-Free
• Software Practices
• Tested

が挙げられています。最初の二つは、GitHubのイメージですね（参考まで、W3Cではないですが、HTTP/2はGitHub で、オープンに管理されています）。当日のディスカッションでは、

Polyfillの開発やサンプルコードによるユースケースの提示は仕様化を進めるのに有効

との発言もあり、Forkable, Hackableは大変重要な概念と感じました。

あと、3番目の Thoughtful を補足すると、仕様化にあたって「何をゴールにするか？」のルールを複雑に考えていると、それだけで無駄な時間がとられてしまうので、（アジャイルの考え方で）仕様化も継続的に進められると考え、ゴール設定やルールはシンプルでスマートにしようといったことが述べられています。

ほかには、

開発者は普段別の仕事をしており、仕様化貢献にそこまで時間を割くことはできない

というコメントがあり、これを解決するために仕様を機能分割し、開発者の学習コストを下げる取り組みを行っているといった議論もありました。

まとめ

本記事では、Extensible Web Summit Berlinの議論模様を一部紹介いたしました。前述のように、詳細な議事録は、こちらで公開されています。各ディスカッショントピック議事録へのリンクもありますので、詳細確認されたい方は、是非チェックしてみてください。

W3Cの標準化担当者・Web開発者が支持を表名している、「Extensible Web」という概念をご存知でしょうか？ Extensible Webとは、一言で表すと、標準化組織であるW3Cとブラウザベンダだけでなく、 Web開発者も巻き込んでWebの未来を拡張していこう、という考え方のことです。

本記事では、Extensible Webの登場背景、その内容について紹介いたします。

登場の背景

これまでのWebの新機能は、長い年月をかけてブラウザベンダによって開発されてきました。 そのため、多くの場合、Web開発者がブラウザへフィードバックをするには、 まずブラウザ側の機能実装を待つ必要がありました。

しかし近年、Webの開発者が先導して、ブラウザの新機能へ影響を与えるケースが出てきています。 例えば、querySelector や、Object.observe が具体例です。 これらの例は、以下のフィードバックループによって生まれてきています：

1. Web開発者が自身が必要とするユースケースに沿ってAPI(ライブラリ)をデザインする
2. Web開発者は、他の開発者が作成するAPIと切磋琢磨し、自身のAPIを洗練させていく
3. 洗練されたAPIの中から、ブラウザが実装すべき基本的な機能が抽出される（ブラウザがNativeに実装すればパフォーマンスが向上し、かつライブラリのコードも小さくできる)

Webに本当に必要な機能を生み出すためには、 上記のように、ユースケースに沿った実践的なフィードバックループを回すことが重要です。

既にこのプロセスはWeb標準化にも取り込まれています。例をあげると、

といったところが代表的でしょう。例えば、セレクタを用いたDOM操作は jQuery で実践的に有効性が示され、querySelectorとして標準化されました。これにより、jQueryのパフォーマンスは向上し、さらに Zepto.js のような軽量化ライブラリが登場・・・といったWebの好循環を起こしました。

一方、ユースケースの考慮が浅いまま実装されてしまったAPIは、 結果的に実践にそぐわず、憂き目にあってしまうケースが多々見受けられます。(その代表的な例が、Application Cache です)

これまで説明してきたフィードバックループを、 Webを構成するHTML・CSS・JS等の様々な分野で更に展開できるといいのですが、 現在のWebを取り巻く環境では限界があります。なぜならば、
　「Web開発者が、拡張(extend)できるポイントが少ない」
ためです。 例えば、CSSの構文を拡張するのは、既存の拡張ポイント(API)では困難であるため、 そもそもフィードバックループを回しはじめることが出来ません。

Extensible Web Manifest

もし、Web開発者が拡張できるポイントが多くあれば、 言い換えれば、低レベルのAPIがWeb開発者に公開されるとしたら、どうなるでしょうか？ Web開発者が実際に必要とするケースに沿って、 さらに多くのAPIやライブラリを開発できるようになります。

このような考え方は、Extensible Web Manifestoにまとめられています。

Extensible Web Manifesto

Extensible Web Manifestoでは、ExtensibleなWebのプラットフォームの設計原理として、 以下の点を提言しています：

(Extensible Web Manifestoより抜粋、意訳)

Focus on adding new low-level capabilities to the web platform that are secure and efficient.

安全で効率的な、新たな低レベル機能をWebのプラットフォームに追加する

Expose low-level capabilities that explain existing features, such as HTML and CSS, allowing authors to understand and replicate them.

既存の機能(HTMLやCSS)が、これら低レベル機能によりどのように実装されるかを示すことで、開発者の理解を促進し、複製を可能とする

Develop, describe and test new high-level features in JavaScript, and allow web developers to iterate on them before they become standardized. This creates a virtuous cycle between standards and developers.

新機能の開発、表現、テストをJavascriptで実施し、標準化の前にWeb開発者が参画できるようにする。これにより、Web開発者と標準化担当者の間で素晴らしいサイクルが実現される

Prioritize efforts that follow these recommendations and deprioritize and refocus those which do not.

上記のような提言に沿った取組みの優先度を高くし、そうでないものは優先度を低くするか、もう一度フォーカスを練り直す

原典ではそれぞれの項目について、更に詳細な記載がありますので、興味のある方は参照ください。

Extensible Webの今後

Extensible Web Manifestoは、標準化団体であるW3C・各種ブラウザベンダ(Google, Mozilla等)・著名ライブラリの開発者が支持を表明しており、今後より具体化していくことが期待されます。

具体的な活動の一部として、フェイスツーフェイスのミーティングも既に開催されています。 そこで次回の記事では、2014年9月11日にドイツ ベルリンで開催された Extensible Web Summit の議論模様を紹介いたします。

まもなくキーノートがはじまります！HTML5 Experts.jpでは、現地で取材中のエキスパート・編集部と連携し、ライブレポート形式にて本ページにて、最新情報をお届けいたします！

まずは、キーノート会場からご紹介です。

カウントダウンがはじまってます！

ピタゴラスイッチのような演出、そしてFlappy Birdの映像も流れてます。

Michael Gorman氏のスピーチではじまりました。 前回のGoogleIOはグローバルなイベントであり、547箇所で視聴している人がいます。早速、グローバルなスマフォの出荷数を見ます。全四半期では３億台以上が出荷されています。Androidを使っているユーザは毎年数が倍増しており、今年は１０億人以上のユーザが利用しています。

Androidユーザは9300万人が自分撮りをしています。我々の推定では、1000億会場もAndroidをチェックしています。

タブレットの話もすると、数は非常に伸びています。Androidのタブレットは世界市場の62%を占めています。これはkindleを含んでいません。また、利用状況を見ると、一年前はyoutubeを見る人は28%がyoutubeを視聴していましたが今は42%です。今年だけで、アプリケーションのインストールは200%以上増えています。また、10億人以上のAndroidユーザがいますが、50億人以上のユーザにリーチしたいと考えています。

本日はAndroidとChromeについてお話いたします。まずはAndroid “L” Developer Previewについてです。（編集部補足：Kit Katの次ですね。まだ正式名称は内緒のようで、単なるLとして紹介されてます。）

デザインは今日非常に重要です。Lではマテリアルデザイン（材料設計）を取り入れています。マテリアルデザインは、直感的に人々が理解できるようなデザインです。例えば、 影を作ることにより、どのように動くかについて意味をもたらすようなものです。また、Lのガイドラインにより、開発者は1つのデザインで、様々なデバイスのデザインを最適化できます。

（編集部補足：マテリアルデザインについてはこちらの動画をご覧ください。）

さらにLでは、Android開発者はシームレスなアニメーションを作ることができます。

昨年はPolymerを発表しましたが、マテリアルデザインの機能をPolymerを介して提供します。マテリアルデザインではスムースなアニメーションを作れます。具体的に、Lのユーザエクスペリエンスからお話します。Lには洗練されたノーティフィケーションもあります。Lの場合には即時的にロック画面から確認ができます。

Lではノーティフィケーションを優先度をつけて整理できます。さらにノーティフィケーションを、一回のスワイプで外すこともできます。またheads upというノーティフィケーション機能を導入しています。これは緊急度の高いものを通知する機能です。また新しいコンセプトとして、パーソナルアンロックという機能を導入します。

次はパフォーマンスです。

Androidのバーチャルマシンについて様々な意見を頂いてきました。今日、我々はLの新たな実行環境として、ARTを提供します。ARTは新たなガーベジコレクタも提供します。ARTは64bitアーキテクチャに対応しています。

また、Lでは、GPU性能も向上しています。（Lを用いたムービーが再生される）水の反射や煙のエフェクト、秋のリリースでPCレベルのものがポケットに収まるようになります。

最後にバッテリです。プロジェクトVoltaをはじめました。これにより持続時間を向上させています。バッテリ性能を確かめるには、まずは計測をしないといけないので、Battery histrianを作りました。これにより当時の状況を見ることができるようになりました。

そしてジョブスケジューリングAPIも新しくなっており、消費電力も効率化されています。

LではジョブスケジューリングAPIで、バッテリ接続していても自動的にバッテリを節約できます。

明日の午前中には、LのプレビューSDKを提供します。Nexus7で今日にでもはじめられます。5000の新たなAPIが提供され、パフォーマンスも向上しています。

これまでのAndroidのイノベーションを振り返ると、オープンプラットフォームで様々な技術革新を提供してきました

セキュリティアップデートもGooglePlayを介して利用できます。ファクトリーリセットプロテクションを使い、さらに安全に活用できます。 プライバシーもLの側面にあります。ユーザは個人情報の保護を確実にできます。

ユーザはマルチスクリーンの世界を生きています。例えば、車にのってもネットへ接続しています。

シームレスな形式で、どのデバイスを使っていても同様なエクスペリエンスを提供します。その一つとして紹介するのは

androidWearです。 Android Wearでは例えば、センサによってコンテキストを認識、必要な情報を提供します。ユーザはこのデバイスを常に身につけていることによります。世界中の人はAndroid Phoneを毎日125回以上チェックしていますが、このウェアラブルなウォッチを使えば、すぐに確認できます。まずはLGウォッチで紹介しましょう。

これにより、ウェアラブルな形で、流れるようなアニメーションで、フライト情報のような様々な情報を確認できます。

UIのモデルですが、Androidがどのように機能するか？まずは天気や通勤時間を確認できます。また、ウォッチから簡単にスマートフォンと連携できます。簡単にメモもとれます。とったメモはすぐにスマートフォンに同期されるのです。

例えば電話がかかってきた場合は、ウォッチに情報が表示されます。ウォッチを上下にスワイプすることによって、電話を拒否するようなこともできます。また下にスワイプダウンすれば、都合がよくなるまで割り込みを避けられます。

また、ウォッチで音楽もコントロールできますし、再生している最中のアルバム情報もチェックできます。また、その他の機能として、ジョギングの後の心拍数なども計測できます。AndroidWearSDKによって、開発者は様々なものを構築できます。色々なアプリケーションが何十億という通知を、自分の腕で確認できます。3月に開発者プレビューをリリースしています。

ユーザには、さらに良いエクスペリエンスを提供できるようになります。GmailやHangoutと統合できるようになります。eat24というアプリを紹介しましょう。

まずピザのオーダがウォッチからできます。

支払いもウォッチからできます。これだけで、ピザがあなたのもとに届きます。

ソーシャルレシピのような例もあります。レシピをウォッチで見ると、携帯にもすぐに同期されています。これは料理をしている間に身につけていてもOKです。防水処理されておりますので。タイマーもすぐできます。ウォッチさえあれば大丈夫。焼き過ぎなんてありえないです。

音声のアクションを色々とお見せしましたが、他のアクションにも応用可能です。Okay google, call me car　といえば、位置情報を確認して、車がついたらウォッチに通知してくれます。また目的地についたらウォッチに通知してくれるようなアプリも作れます。さて実際のウォッチですが、

今日の午後からLGウォッチをプレイストアで発注できます！またサムスンもAndroidwearファミリー人参加してもらいました！Samsung Gear Liveも午後から発注できます。また丸いUIのMoto3も夏から発売されます。(編集部補足：米国での発売情報です)

Android Wearはシームレスなデバイスすると述べました。次は車を考えてみましょう。

Open Automotive Allianceを発表し、Connected Carを現実にしたいと思います。

そこで、本日はandroid autoを発表します。android autoでは、Androidプラットフォームを自動車のために作りなおしました。運転中にも使えるようにしています。android autoはコンテキスト対応しており、的確な情報を必要なタイミングで必要な情報を出してくれます。また完全に音声対応されているので必要な情報を音声で使えます。

androidフォンを車に近づけると、android autoを車の画面にそれを表示させます。

そして車のコントロールするために、タッチスクリーンを使えます。しかし、アプリケーションはスマートフォンで動作していますよ。さらに、Google Play Musicの主な機能をコントロールできます。これを手を使わずにコントロールできます。

そうそう、皆様はGoogle Mapが好きですよね。android autoはもちろん対応していて音声が使えます。「ヤングミュージアムはいつからやっていますか？」と聞けば、「朝からやっています」ち答えてくれます。次に、「Navigate There」と言えば、ヤングミュージアムへのナビゲーションを開始します。また、その最中に届いたメッセージはheads upで通知でされます。このとき、マップの移動画面も出しながら、音声で返答できます。

android autoについてお話してきましたが、スマートフォンやタブレットと同じように開発できる、android auto SDKを今日発表します。

SDKがあれば音声を簡単に使えます。またメッセージングAPIもあります。これにより、Appをユーザへ提供しています。わずか数行のコードで車の中でも対応できます。

40の新しいpartnerがOpen Automotive Allianceに参加しています。

車をもっていない人もいますよね。そこで、次はTVです。TVは2006年からあまり進化していません。その結果スマートテレビは限定できでした。Androidtvを発表します！Androidtvでは音声入力を活用でき、バーチャルコントローラも使えます。例えば、生のTVが流れている上に、コンテンツをオーバレイできます。TVはコンピュータと違い、エンターテイメントのインターフェースがあります。

例えば、「2012年からオスカーを受賞した番組」と音声入力すると、一覧で表示できます。

リモートコントロールがない場合には、Android wear、ウォッチを使ってTVをコントロールできます。つまり、ウォッチをリモコンとして、TVをコントロールできます。

次はゲームの話です。これまでタブレット等でやっていたゲームを今度はTVで楽しめます。例えば、マルチプレイヤーゲームも楽しめます。

他にも、スマートフォンの映像を直接TVにキャストできます。ChromeCastの拡張のような形です。AndroidTVは複数のデバイスタイプ、つまりTV、セットトップボックス、ゲーム機にも対応しており、協業しています。

実際に、2014-2015年にSony、SharpがandroidTVを出します。最後ですが、ADT1というTV開発キットを提供します。これにより、今日から皆様も開発できます。

次はChromeCastを紹介します。ChromeCastは非常に販売が好調です。実はエレクトロニックデバイスとしては、Amazonで一番売上をあげているものです。このChromeCastははじまりにすぎません。この数ヶ月で6000人のデベロッパが登録しており、10000のアプリがGoogleCastReadyのアプリが生まれています。chromecast.com/appsからアクセスするとGooglecastのアプリケーションが簡単に使えます。

TVは使われていない時間が多いですが、それを活用しようと考えています。

例えば、フォトフレームのように使うこともできます。

次はChromebookの話です。我々な生活の中で重要なデバイスとして、まずはChromebookがありました。ユーザはこれを非常に楽しんでいます。

今、AmazonのレーティングでTop10のラップトップは、すべてChromebookです。

Chromebookに近づいてスマートフォンを持っていれば、chromebookに自動的にサインインできます。GoogleNowの通知も導入済みです。何かあれば、Chromebookでテキストメッセージも追加できます。

このようにChromebookは素晴らしいのですが、ここで我々が考えていたのは、AndroidアプリケーションをChromebookでも利用したいという点です。技術的には非常に難しいのですが、AndroidアプリケーションをChromebookで動かせるようにポーティングできています。

さて、次は法人（企業）の話もしましょう。企業では、個人携帯と会社携帯が別物でした。Lでは、両方のエクスペリエンスを統合して、使えるようになります。一つのデバイスで大丈夫になります。

データは完全に分離されており、セキュアな形になります。もうひとつ、よく要望される機能について紹介します。

Navie Office Editingも提供します。たとえば、皆様はEmailを使ってwordファイルを受信しますが、今まではそれをdocファイルに変換していましたが、これからはNativeな形式でofficeファイルとして使えるようになります。

次はGoogleDriveです。Google Drive for Workの機能を法人にも提供します。エンタープライズに対して、すべての機能を提供します。また、無制限のストレージを月10ドルで提供します。これからはAndroid、Chrome、Google Doc、Google Driveを統合的に使えます。

実際に、多くの企業・学校がすでに利用しています。

Googleの中で様々なインフラを作っています。ここでGoogleプラットフォームの話をしましょう。

Compute Engineを使っています。エクサバイトまで拡張するストレージも提供しておりますし、スケーラビリティも確保しています。

バックエンドを作るという意味においては、パフォーマンスがあり、簡単なツールが必要ですが、それはGoogleにしか無いと感がています。ここで4つの機能を紹介します。

一つのアプリケーションを使って説明します。codewalksは散歩の記録をするアプリです。散歩にいってコメントをシェアするアプリですが、これは情報をクラウドにデータを入れる必要があります。

デバッグのために、ブレークポイントを設定することもできます。

クラウドトレーシングという機能では、すべてのアプリケーションにおいて、どれだけ時間がかかったか、というのを表示してくれます。

最後はクラウドモニタリングです。これによりインフラのモニタリングをできます。例えば、どのようなサービスを利用しているかを確認できます。また数十のOpenSourceのサービスをモニタできます。例えば、こちらではRedisを確認しています。

いままで見てきたのは4つの機能であり、それぞれはCloud Save、Cloud Debugger、Cloud Trace、Cloud Monitoringができるようになりました。

次はデータに注目します。データといえば、もちろん分析が必要です。 その分析において、MapReduceが最適じゃない場合もあります。特にパイプラインを使う場合です。そこで、本日はCloud Dataflowを発表します。これによりデータのパイプラインを使えます。これにより、バッチでもリアルタイムでも分析結果を確認できます。

例えば、CloudDataflowでTwitterを分析してみます。これは、並列化された高速な分析が可能です。

ブラジルvsクロアチア戦の分析結果です。ポシティブネガティブな結果を表示しています。この例では、途中でレフリーについて物議を醸しているようです。

また話を技術的な部分に戻して、なぜMapReduceを使うのをやめたかというと、cloudパイプラインによってこれまで大変だったことが簡単にできるようになり、スピードも早くなるからです。我々自身の問題を解決できるようになったので、MapReduceを使うのをやめたのです。

次はGooglePlayについて話をしましょう。

GooglePlayで開発、配信、マネタイズについて話をします。

まず開発におけるテストです。テストは大変ですよね。appurifyはもっとも洗練されたテストです。appurifyにより、iOSでもAndroidでも活用できるテストが利用できます。また、特定の環境も擬似できます。

次にGoogleFitPlatformを紹介します。GoogleFitがない時代は、専用アプリを使う必要があり、その提供形式はサイロ型になっていました。GoogleFitでは統合した形で、包括的なアプリを活用できます。例えば、ユーザにはより良いレコメンデーションを提供します。具体的には、アディダスやナイキがGoogleFitのエコシステムに参加しています。このSDKはあと数週間で利用可能になります。

次は配信です。クロスプラットフォームのサービスとして、これまで、Google Play Gameを提供してきました。Google Play Gameも強化されます。

例えば、Game Profileにより、自分のアイデンティティをクラウドに保存でき、それをゲームで活用できます。

次はマネタイズです。よくある方法はキャリアにお金を払う方法です。実は今25ヶ国で利用できます。アプリケーションやゲームやムービを、携帯電話の請求書に載せて払えます。これによりユーザに請求を簡単にできます。

実際に前回のI/Oから50億ドルをユーザが支払っています。

次はお待ちかねのガジェットを見てみましょうか。（編集部補足：参加者へのお土産コーナーです）

カードボードや や を会場の皆様にはプレゼントいたします。

これでキーノートは終わりです。参加してくれてどうもありがとう！

Googleが主催する開発者イベントである Google I/O 2014 が、日本時間の6/26(木) 午前1時の基調講演を皮切りに始まります！HTML5 Experts.jpでは、現地で取材中のエキスパート・編集部と連携し、ライブレポート形式にて読者の皆様に最新情報をお届けいたします！

ライブレポートはこちらから！

1時よりキーノートがはじまりますが、まずはその前に会場画像をお届けいたします。

朝食会場です。

そして朝食画像です。