読者です 読者をやめる 読者になる 読者になる

YAMAGUCHI::weblog

土足で窓から失礼いたします。今日からあなたの息子になります。 当年とって92歳、下町の発明王、エジソンです。

次世代Webカンファレンスに参加しました #nextwebconf

はじめに

こんにちは、Go界のエビスビールです。今日、法政大学外壕校舎で開催された次世代Webカンファレンスに聴衆として参加してきました。

以下自分のメモです。

server_perf (10:00-11:00) #405

メモ

  • パフォーマンスの勘所としてクライアント側の変化があると思う
    • @mirakui: スマホのWebとアプリの比率があがってる
    • @xcir: デスクトップからのリクエストは減って、スマホのネイティブアプリでの処理が増えている。APIアクセスが主。
    • @cubicdaiya: Webからのリクエストが1割もなくて、ほぼネイティブクライアントからのリクエスト。15000qps。
    • APIリクエストが主になったことによりJSONのやり取りだけの単純なものになったが、リクエスト数は増えた。
  • 高速化しにくい部分をどうパフォーマンスさせる?
    • @cubicdaiya: 非同期処理できるところはできるだけやっている。APIサーバになるべく負荷をかけさせない。
      • キャッシュの作成、DBのインデックス作成など。IOの処理を上げる場合には札束で殴るしかない。
    • @xcir: 自分でコード書いていないことが多いので改善しづらい。仕様を変えることで改善するしかない。
  • キャッシュ戦略
    • @xcir: キャッシュ生成コスト vs 閲覧数。どのレイヤでキャッシュを作るか。
    • @cubicdaiya: 各レイヤで共通の部分で使うデータをキャッシュする。(
  • 文化
    • @mirakui: ログインしてるとキャッシュしない。(A/Bテストの妨げになる)
  • 言語
    • @mirakui: Rubyは運用しやすい言語である、と思うことにしている。
    • @xcir: PHPにしてる。理由付けができればなんでもいいと思う。
    • @cubicdaiya: GoとかCとか。ずい分前からCPU1コアでの性能は頭打ちでマルチコアで処理しようとしているので、それに対応した言語が良い。
    • @cubicdaiya: APIはルーティングだければできればいいと思っているので、軽量な物を使っている。
    • @xcir: キャッシュできないものをどうやって処理するか
  • ミドルウェア
    • @xcir: VernishでESIやってます。ngx_small_light使ってます。
    • @cubicdaiya: nginxではモジュール書いたりとか、Luaやmrubyで簡単なアプリケーションサーバを書いてる。
    • @cubicdaiya: 私はngx_small_light使ってません。あれはApacheのmod_small_lightの移植で、Apacheはrequest per childで制限できるのでImageMagicが多少リークしてもメモリ死しない安心感がある。nginxはそれがない。
    • @cubicdaiya: nginxはマルチプロセスシングルスレッドなので、できるだけノンブロッキングにしないと死ぬ。
  • 海外展開
    • @cubicdaiya: 国土の広さが関係することが結構ある。TLSハンドシェイクを早くする、証明書の失効確認を早くする
    • @xcir: 「AWSさんよろしくお願いします」
    • @mirakui: 「us-eastに置いておけば大体どこからでも等しく遅い」
    • @mirakui: 海外はネットワークがすぐに切れる。大雨でネットが断線とか。
      • @xcir: ベトナムではカジュアルに海底ケーブルが切れる
      • @cubicdaiya: 東南アジアだとアプリのサイズが大きいと全然ダウンロードされない。
      • @mirakui: Opera Turboはすごい。勝手に画像を縮小。JSを展開。なぜか動いている。開発者はデバッグ地獄。
  • CDN
    • @xcir: 使ってます。
    • @cubicdaiya: 使ってるし昔は自社でCDNを使ってる会社にいた。画像など。
    • @mirakuri: 次世代CDNが来ると思う。CDN内で処理を完結させる。(画像変換や動的キャッシングなど)
  • 録画はあとで公開されます。

話題に出たもの

ui/ux (11:10-12:30) #407

メモ

  • このセッションの「ui/ux」という表記について
    • @kotarok: 僕は「UI/UXと言うな派」だったんだけど皆がどう思うかが気になる。
      • UIというのは表層にあるものであって、直接ユーザが直接触ることができるもの。
      • UXはユーザが感じた体験。直接設計できるものではないと考えている。
    • @manabuueno: 言葉の定義=プロトコル。相手に伝わるのであれば良いかなと。
      • 例:UX/UI, UI/UX, UI+UX, UIUX
      • デザインする対象は個人的には「UI」でいいかなと思っている。
    • @yukio_andoh: 僕は言ってもいい派。
      • ただし一緒に働くなら、それぞれをどういう意味で使っているかをちゃんと見極める必要がある。
      • 唯一気になるのは「求人の時にUI/UXデザイナー募集」という文言。別の仕事だからね。
    • @theodoorjp: 僕は転向派。「いうな派」→「いいよ派」
      • 「ユーザ体験」という言葉が表すものが難しい。
      • エモーショナルデザイン
  • 「ユーザ」とは
    • @yukio_andoh: 「使う前の人」「いつも使ってる人」「使ったけどいまは休眠してる人」全部ユーザ。
      • エモーショナル・デザインの表紙のレモン絞り器はとても美しいけど使ってみるととても使いづらい。使いづらいというのも「経験」
    • @manabuueno: 「ユーザ」っていうのがいま流行っている。(eg. 山手線ユーザ)
      • コンピュータ用語が日常的に使われるようになった。(ユーザ、フラグ、デフォルト)
      • 以前は「ヒューマン」という言葉が使われていた。アメリカでは顧客というぐらいの意味合いで使っているのだろう。
  • 現世代と旧世代の境目は?
    • @theodoorjp: iPhoneの登場によって変わったと思う
    • @yukio_andoh: 直接的なタイミングはiPhoneの登場だと思う
      • 緩やかな行こうとしてはURLが意味を持たなくなってしまった
    • @manabuueno: 若い社員は自分の会社のサイトすらググってる
    • @yukio_andoh: 10代の人間はもうブックマークすら使わない
    • @manabuueno: 自分が感じる変化のタイミングとしては「iPhoneの登場」「APIを公開し始めたころ」
      • 自分の感覚で「ブラウザ」と「ウェブ」が対応してる時点で旧世代
      • 今はウェブと言ってもクライアントはネイティブで持っている
    • @kotarok: 「ハッカーと画家」が書かれたころはネイティブアプリを更新するのが難しい前提でHTML UIを押している。
      • いまはGoogle Play StoreやAppStoreがあるおかげでそれは解消されている。
      • そういう意味で逆行している気がする
  • いまあるネイティブとHTMLの揺り戻しを踏まえて次は何が来るか
    • @theodoorjp: スマホのネイティブアプリのUIはある程度もう定跡化してしまっている。あれが最高系だとは思わない。
      • Google NowやSiriをはじめとする人工知能的なインターフェースは新しいなと感じている。
      • Facebookで個別コメントができるようになっているのはヘビーユーザーだけ。
    • @yukio_andoh: 理想形は楽器のように「だれでも簡単に音を出せるけど、使いこなすのは難しい」
      • 個々人でUIが異なると操作を伝えづらい
    • @kotarok: インターフェースの学習曲線というものを考えないといけないと思う
  • ハイパーリンクハイパーテキストという大発明
    • @kotarok: インターフェースとコンテンツの同化
    • @manabuueno: 「文字が押せる」というのはわかるが課題がある。
      • 対象の文字の長さが短いと押せる領域が減る=重要でないように見える
    • @kotarok: 現世代Webは文章を起点にしているのでリンクは動画や音声といったコンテンツに対してのポインターとして無理がないか
  • 文章に依らないウェブ性
    • @yukio_andoh: リンクを自分で辿らないといけない、というのが次世代ではなくなるのではないか。
      • YouTubeのおすすめのようにどんどん提示されてくるもの
    • @theodoorjp: 「リンク」はいま「人間が読めるもの」と「機械だけが読めるもの」が半々ぐらいになっている気がする。
      • もうちょっとルール付けが合っても良いと思う。
    • @yukio_andoh: rendorman formatやMIDIのような30年持つ規格を定義するというのは大変なこと。
  • URLの軽視
    • @kotarok: あるコンテンツの塊に対して一意なURLを振ることをもっと考えたほうがいいのでは
    • @manabuueno: 1つのURLに対して動的にコンテンツが変化するのは?
    • @manabuueno: 製作者側が良いと思うものを1つのURLに対応させればよいのではないか
  • いまのインターフェース
    • @kotarok: かつてiPhoneが出た頃にすべてHTML5で行くとJobsが宣言した。Facebook
    • @manabuueno: いまこの会場にいる人は何ができて何ができないか知ってるのでほっといていい。そうじゃない人を考えていかないといけない。
      • ネイティブのアプリみたいに「アイコンを押すことですぐにTwitterが使える」という状態をユーザが近く感じるのではないか。
      • そういう意味でブラウザがメインでなくなっているいまの状況は「半分ウェブが死んでるのでは」
    • @theodoorjp: 次世代はブラウザがメインでないのだとしても、いまの通信プロトコルは使われ続けるのだと思う。
    • @manabuueno: 我々が「次世代Web」のようなテーマで語るときは「人類愛」のようなテーマを感じる
  • コンテンツの保存
    • @yukio_andoh: 残そうと思うものはほっといても残る。そうでないものをどう残すか。
      • 本はずーっと残っていく。どうでもいい日々の発言こそ残したい。
    • @theodoorjp: 僕は逆で忘れたい。それをどう設計するか。
    • @manabuueno: たかだか5年前のウェブページが見れなかったりする。
      • 自分とコンテンツの距離が保存される限りにおいてはすべて保存すべきだと思う。
  • さいごに
    • @manabuueno: iPhoneなんだよ。Appleは神。
      • iPhoneが出る前にまったく議論されなかったマルチタッチの話が出た直後に活発になされた。
    • @theodoorjp: いまのスマートフォンのUIから脱却していくんだと思う。
    • @yukio_andoh: スマートフォンの登場によって、「使いやすい」「使いにくい」という感覚が研ぎ澄まされて、評価がなされ、みんながUXの人になっていく。
    • @manabuueno: ウェブの多様性多態性があるので、次世代も大丈夫。

話題に出たもの

webrtc (13:30-14:30) #407

メモ

  • WebRTCってぶっちゃけいまどうなの
    • @tonofo: ひとことで言うと割と辛い。過去の資産を無理やり使ってる。非常に多くの知識を必要とする。
    • @voluntas: 割と辛い。
    • @iwashi86: 本当に辛い。よくあるのは「つながらない」「SDKほしい」。RFCの山。
  • なぜつながらないか
    • @voluntas: ChromeFirefoxとEdgeで全部仕様が違う。さらに6週間でブラウザが自動更新されて死ぬ。
      • クライアント側で頑張ってやる場合はJSで頑張るしかない。
  • 辛い話
    • @tonofo: SDPとCandidateが読めないと絶対運用できない。運用環境で何が起きてるかはCandidateしかない。
      • @voluntas: ブラウザの世界にテレビ会議SIPでやってたことが降りてきただけ。
      • @tonofo: 繋がる最強のやつはLTE回線。社内ネットワークは結構厳しい。
      • @voluntas: 企業内のネットワークはUDPに関してかなり厳しい制限がある。TURNでやる場合は中央サーバが必要になってしまう。
        • NAT超えのためにTURNやSTUNをちゃんと理解していないといけない。
    • @voluntas: 利権に合わせていくしかない。
    • @iwashi86: 現状Firefox以外は独自仕様。
  • ORTC
    • @iwashi86: 期待している。
    • @voluntas: 期待してない。Skypeのために策定しているようにしか見えないので1.0の間は傍観。
    • @tonofo: どこまで仕様通りにできるようになるのかは疑問。
  • WebRTC 1.0の仕様がそろそろ決まろうとしている
    • @voluntas: WebRTCの残念なところとして1つの解像度の映像しか送れない。
      • 同時サイマルキャストが実装されないと厳しい。多人数テレビ会議
      • Chrome実装済みだが、オリジナル実装なので独特なSDPを書かないといけない。
      • SFUで辛いのは暗号化が重い。
    • @tonofo: GPUを使ったMCUなどハードウェア側で頑張らないと辛い。
    • @voluntas: 「WebRTC = RTCP何じゃないかと思ってる」
    • @tonofo:
  • テストどうするんですか、あるいはクライアントの話
    • @tonofo: 社内であればChromeのバージョンもコントロール
      • Electronはとても良い
      • クライアントのバージョンはネイティブで固定できる。ただしOSバージョンは固定できない。
    • @voluntas: Firefoxは仕様にすぐに追従するし素晴らしい。Chromeはつらい。
  • 組み込み
    • @tonofo: RasPi2超速い。H.264のハードウェアエンコーダ積んでる。
    • @voluntas: エンコーディングだけでCPUパワー持ってく。
  • 使っていく話
    • @voluntas: プラットフォーマーは辛い。運用をするのが辛い。
      • ただそれに乗っかればプラットフォーマーが各種スタックを用意してくれているのでそれが良い戦略。
    • @iwashi86: 正直付加価値としてWebRTCを使っていくというのが正攻法。
      • これまで他のことでやっていたものを置き換える、補強するという感じ。
    • @tonofo: SDK側が辛い部分を吸収するので、SDK使ってる分にはある程度楽。
    • @voluntas: 動画や音声みたいな簡単に見えるものの裏側にある困難な部分をいかにプラットフォーマーが吸収するか。
    • @tonofo: WebRTCってこれまでのウェブの形と違う形になっているので面白いと思う。
  • これからの想定ユースケース
    • @voluntas: たとえばSFC/MCU前提でやってみてだめだったらP2Pに落ちるとか
    • @tonofo: Facebookチャットも一度TURNで繋いでから様子をうかがってP2Pに落としたりしている
    • @iwashi86: SVCについても触れたい
    • @voluntas: MCUではSVCのメリットないんで、結局SFU頑張れっていうことになる。
  • あらためてWebRTC 1.0が12月までに決まる
    • @voluntas: サイマルキャストが入って仕様が落ち着けば結構期待できる
    • @iwashi86: 海外ではWebRTC系のビジネスが結構活発。資金調達も結構大型のものもある。
      • 日本でも遅れてブームが来ればいいな。

話題に出たもの

identity (14:40-16:00) #407

メモ

  • これからRP(Relying Party)は何を使ったらいいのか
    • @_nat: OpenID Connectに対応していればOpenID Connectのライブラリだけでいけるようになるはず
    • @nov: TwitterはずっとOAuth1.0で、更新の兆しなし。
  • リスク情報共有
    • @_nat: あるアカウントがある1つのサービスでアカウントテイクオーバーされた場合に他のサービスに即座に知らせて2次被害を防ぐ
      • 他のサービスにあるアカウントが所属している
  • OAuth PKCE
    • @_nat: 後方互換だし、IdPもRPも全部コレ使ってたらいいんじゃないの
    • @nov: 最終的に悪意の第三者にアクセストークンが渡らないように作った仕組みがPKCE
    • @_nat: ランダム文字列をチャレンジ時、それのハッシュをベリファイ時に送ることで、
  • Proof of posession token
    • @_nat: interpolやFBIの溜飲を下げるためには一段セキュリティの高い認証方法が必要
      • Bearar tokenは持ってったらすぐに使えるトークン(例: JRの切符)
      • Proof of posession tokenは使用時に所有者の確認を行うトークン(例: 飛行機のチケット)
  • @_nat: 「パスワードは公害」「パスワード税をかけたほうがいい」「総量規制をかけたほうがいい」
    • なぜパスワードでやるかといえば「安く導入できるから」
    • 税金と両壁をなすのは「保険」がある。情報漏えいした場合にどれくらい補填できるか。
    • パスワードが悪いんじゃなくて、実際にはヘボいパスワードシステムが悪い。
      • Googleはパスワードシステムに見えて他の要素も含めて判断している。300人チームでやっている。それだけのコストを掛けてやりたいのか。
  • ログインやログアウトってなんで必要なんだっけ
    • @nov: authenticatedされた状態が必要なだけだよね
    • @_nat: ローカルデバイス、特に個人デバイスであれば一度認証したらずっと使えていればいいはずだしそうあるべき
    • @mad_p: キオスク端末の場合は個人端末の認証情報を渡せる仕組みがあればいいだけのはず
  • 認証と識別
  • ユースケース毎のリスク評価

話題に出たもの

monitoring (16:10-17:30) #407

メモ

  • 監視とは何か
    • @mikeda: 稼働率を上げるもの。
    • @fujiwara: 落ちないようにするため。それは現在も将来も含めて。(キャパシティプランニングなど)
    • @songmu: 稼働率を最適にするだけでなく、キャパシティを最適にする
      • テストやコンフィグもコードになっていったのと同じように、監視もコードになっていくんだと思う。
    • @rrreeeyyy: サービス提供者側が提供されるべきレベルを保つためのもの
  • チェック監視とメトリック監視
    • @songmu: 最近の傾向としてメトリック監視が増えている
    • @mikeda: 昔に比べると細かい値を取り始めた
    • @fujiwara: チェック監視とメトリック監視は各々役割が違う気がする
    • @mikeda: メトリック監視で割といけることが増えてきたかなという印象
  • 監視の間隔
    • @fujiwara: 数日間は1秒単位のデータを取得したい。
      • 1分間隔だとたまに起きる短い間隔でのスパイクを拾えない。
  • 監視難しい問題
    • @rrreeeyyy: 言語によってどこを監視していいかわからない事が多い。
    • @mikeda: 監視テンプレートをもっと公開してほしい
    • @songmu: Chefが良かったのは個々人が秘伝のシェルスクリプトでやってたことが公開されてシェアされた
      • 管理もそういうふうになればいいな
  • アプリケーションエンジニアとインフラエンジニアの棲み分け
    • @rrreeeyyy: お客様によってはアラートごとに連絡ほしいという人もいれば、対応策まで考えてから連絡してほしいという人もいる
    • @fujiwara: アプリケーションエンジニアにもアラートを感じてもわらないとサービスはよくできないと思う
      • ただ一応段階をわけてアラートを出している
  • どういうチームを作ればよいのか
    • @mikeda: 少人数で24時間の監視体制を回すのは現実的ではないのに、それをやってるのがこの業界。
    • @fujiwara: 特殊なチームメンバーの状況に依存すべきではない。どうしても対応できないならMSPなどに任せましょう。
  • 監視周辺技術
    • @songmu: MackerelではGraphiteを使っている
    • @mikeda: オープンソースを使ってる人が多いのでZabbix使ってます
    • @rrreeeyyy: これからは監視とクラスタマネージメントはセットとなるのでConsulには注目してる。
    • @fujiwara: 時系列データベースどれつかったらいいですか
    • @songmu: Graphiteかと。datadog結構すごいと思う。
  • fluentdが与えた衝撃
    • @mikeda: アレのおかげで各社でログをどんどんあつめてグラフ化するという流れができた気がする
    • @fujiwara: どんどんログの処理がストリーム処理に近づいている
  • SaaS使ってる?
    • @mikeda: 一部datadog使ってるけど大した規模ではないです。(金銭的な理由)
    • @rrreeeyyy: MSPという事業の性質上、当然自前でやっているが、
    • @fujiwara: いまいまはZabbixで全部やってるけどいずれ外出ししたい。監視の監視までしたくない。
    • @mikeda: 他社の監視の事例を見てると、zabbixやnew relicが多いが、いまはdatadogやmackerelなどがだいぶ増えている。
  • 原因特定・未来予測
    • @mikeda: 未来予測系はまだやってない
    • @rrreeeyyy: あんまりやってない。ただやりたいと思う。
    • @fujiwara: アラート上げるときに0 or 1ではなくて「何か違うよ」を入れたい。
    • @mikeda: 未来予測や任意の異常値の検出などは難しいかもしれないけど、検知の自動化はしたい。
  • RDSのようなサービスを使うことによって監視は楽になったか
    • @rrreeeyyy: 管理は楽になったが、監視がどれくらい楽になったかはわからない
    • @fujiwara: クラウドベンダー内でブラックボックスにされたものは何も見れないのが良し悪し
    • @songmu: 自動修復をしてくれるおかげで監視をする部分が減ってるというのはある
  • 繋ぎっぱなしのサービスが増えてきた
    • @songmu: WebSocketやHTTP/2などが出てくればますます接続に関しての監視は難しい
    • @rrreeeyyy: 実際難しくなっていているが、どうするかは考えていかないといけない
    • @fujiwara: そういう場合はアプリケーション側がログを出してあげないといけない
    • @songmu: アプリケーション側だけでなくミドルウェアも考慮してあげないといけない
  • これからの監視
    • @mikeda: 目の前の監視を続けていきます
    • @rrreeeyyy: 次世代には監視業務はなくなればいいなと思うが当分なくならないので良くしていきましょう
    • @fujiwara: 要するに夜寝たいので、監視システムを育てていきましょう
    • @songmu: インフラエンジニアがなくなると言われた時期もあったが、なくなるどころか複雑化している。

話題に出たもの

感想

とにかくまず運営および登壇者の皆様お疲れ様でした。参加率はいかほどだったかわかりませんが、あれだけの人数を登壇者だけでつつがなくさばいたというのは本当にすごいです。事前打ち合わせなど何回ぐらいあったんでしょうか。いずれにせよ、カンファレンスの運営が次世代な感じでした。

内容に関して言うと、自分が想像していた「次世代」よりはずっと手前側の話になっていたような気がしますが、それもあれだけの参加者がいて聴衆に気を遣ってもらうとどうしてもそうなってしまうのかなとも思います。現に自分がIdentityのセッションに参加した時はRFCやISOのドキュメント番号がどんどん出てきて、話を聞きながらそれを追うのに必死という状況で、現状把握ですら大変なのに、それ以降の話となったら追いつけなかったと思います。

今後開催されるかはわかりませんが、久々に自分のフィールドにない話題をその道のプロから聞ける良い機会でした。一参加者としてとても楽しかったです。ありがとうございました。