はじめに
こんにちは、Go界のエビスビールです。今日、法政大学外壕校舎で開催された次世代Webカンファレンスに聴衆として参加してきました。
以下自分のメモです。
server_perf (10:00-11:00) #405
メモ
- パフォーマンスの勘所としてクライアント側の変化があると思う
- 高速化しにくい部分をどうパフォーマンスさせる？
- @cubicdaiya: 非同期処理できるところはできるだけやっている。APIサーバになるべく負荷をかけさせない。
- キャッシュの作成、DBのインデックス作成など。IOの処理を上げる場合には札束で殴るしかない。
- @xcir: 自分でコード書いていないことが多いので改善しづらい。仕様を変えることで改善するしかない。
- @cubicdaiya: 非同期処理できるところはできるだけやっている。APIサーバになるべく負荷をかけさせない。
- キャッシュ戦略
- @xcir: キャッシュ生成コスト vs 閲覧数。どのレイヤでキャッシュを作るか。
- @cubicdaiya: 各レイヤで共通の部分で使うデータをキャッシュする。（
- 文化
- @mirakui: ログインしてるとキャッシュしない。（A/Bテストの妨げになる）
- 言語
- ミドルウェア
- @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はマルチプロセスシングルスレッドなので、できるだけノンブロッキングにしないと死ぬ。
- 海外展開
- CDN
- @xcir: 使ってます。
- @cubicdaiya: 使ってるし昔は自社でCDNを使ってる会社にいた。画像など。
- @mirakuri: 次世代CDNが来ると思う。CDN内で処理を完結させる。（画像変換や動的キャッシングなど）
- 録画はあとで公開されます。
話題に出たもの
- Home | Varnish Community
- nginx news
- VarnishではじめるESI
- cubicdaiya/ngx_small_light · GitHub
- smalllight - mod_small_light - Dynamic image transformation module for Apache2. - Google Project Hosting
- Opera ヘルプ
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: 僕は転向派。「いうな派」→「いいよ派」
- 「ユーザ体験」という言葉が表すものが難しい。
- エモーショナルデザイン
- @kotarok: 僕は「UI/UXと言うな派」だったんだけど皆がどう思うかが気になる。
- 「ユーザ」とは
- @yukio_andoh: 「使う前の人」「いつも使ってる人」「使ったけどいまは休眠してる人」全部ユーザ。
- エモーショナル・デザインの表紙のレモン絞り器はとても美しいけど使ってみるととても使いづらい。使いづらいというのも「経験」
- @manabuueno: 「ユーザ」っていうのがいま流行っている。（eg. 山手線ユーザ）
- コンピュータ用語が日常的に使われるようになった。（ユーザ、フラグ、デフォルト）
- 以前は「ヒューマン」という言葉が使われていた。アメリカでは顧客というぐらいの意味合いで使っているのだろう。
- @yukio_andoh: 「使う前の人」「いつも使ってる人」「使ったけどいまは休眠してる人」全部ユーザ。
- 現世代と旧世代の境目は？
- @theodoorjp: iPhoneの登場によって変わったと思う
- @yukio_andoh: 直接的なタイミングはiPhoneの登場だと思う
- 緩やかな行こうとしてはURLが意味を持たなくなってしまった
- @manabuueno: 若い社員は自分の会社のサイトすらググってる
- @yukio_andoh: 10代の人間はもうブックマークすら使わない
- @manabuueno: 自分が感じる変化のタイミングとしては「iPhoneの登場」「APIを公開し始めたころ」
- 自分の感覚で「ブラウザ」と「ウェブ」が対応してる時点で旧世代
- 今はウェブと言ってもクライアントはネイティブで持っている
- @kotarok: 「ハッカーと画家」が書かれたころはネイティブアプリを更新するのが難しい前提でHTML UIを押している。
- いまはGoogle Play StoreやAppStoreがあるおかげでそれは解消されている。
- そういう意味で逆行している気がする
- いまあるネイティブとHTMLの揺り戻しを踏まえて次は何が来るか
- ハイパーリンク、ハイパーテキストという大発明
- @kotarok: インターフェースとコンテンツの同化
- @manabuueno: 「文字が押せる」というのはわかるが課題がある。
- 対象の文字の長さが短いと押せる領域が減る＝重要でないように見える
- @kotarok: 現世代Webは文章を起点にしているのでリンクは動画や音声といったコンテンツに対してのポインターとして無理がないか
- 文章に依らないウェブ性
- URLの軽視
- @kotarok: あるコンテンツの塊に対して一意なURLを振ることをもっと考えたほうがいいのでは
- @manabuueno: 1つのURLに対して動的にコンテンツが変化するのは？
- @manabuueno: 製作者側が良いと思うものを1つのURLに対応させればよいのではないか
- いまのインターフェース
- @kotarok: かつてiPhoneが出た頃にすべてHTML5で行くとJobsが宣言した。Facebookも
- @manabuueno: いまこの会場にいる人は何ができて何ができないか知ってるのでほっといていい。そうじゃない人を考えていかないといけない。
- ネイティブのアプリみたいに「アイコンを押すことですぐにTwitterが使える」という状態をユーザが近く感じるのではないか。
- そういう意味でブラウザがメインでなくなっているいまの状況は「半分ウェブが死んでるのでは」
- @theodoorjp: 次世代はブラウザがメインでないのだとしても、いまの通信プロトコルは使われ続けるのだと思う。
- @manabuueno: 我々が「次世代Web」のようなテーマで語るときは「人類愛」のようなテーマを感じる
- コンテンツの保存
- @yukio_andoh: 残そうと思うものはほっといても残る。そうでないものをどう残すか。
- 本はずーっと残っていく。どうでもいい日々の発言こそ残したい。
- @theodoorjp: 僕は逆で忘れたい。それをどう設計するか。
- @manabuueno: たかだか5年前のウェブページが見れなかったりする。
- 自分とコンテンツの距離が保存される限りにおいてはすべて保存すべきだと思う。
- @yukio_andoh: 残そうと思うものはほっといても残る。そうでないものをどう残すか。
- さいごに
話題に出たもの
- ■公開資料 - hcdvalue
- 「みんなジョブズに騙されている」増井俊之教授が進歩の止まったコンピュータのUIを問い直す【TechLIONレポ】 - エンジニアtype
- HyperCard - Wikipedia
- MIDI - Wikipedia
- Pixar's RenderMan®
- Snapchat - Wikipedia
- Interaction Design Association - Homepage | IxDA
- User Experience Professionals Association
- 作者: ドナルド・A.ノーマン,岡本明,安村通晃,伊賀聡一郎,上野晶子
- 出版社/メーカー: 新曜社
- 発売日: 2004/10/15
- メディア: 単行本
- 購入: 3人 クリック: 132回
- この商品を含むブログ (58件) を見る
- 作者: ポールグレアム,Paul Graham,川合史朗
- 出版社/メーカー: オーム社
- 発売日: 2005/01
- メディア: 単行本
- 購入: 109人 クリック: 4,884回
- この商品を含むブログ (583件) を見る
- 作者: ゴールデン・クリシュナ,武舎るみ,武舎広幸
- 出版社/メーカー: ビー・エヌ・エヌ新社
- 発売日: 2015/09/17
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
webrtc (13:30-14:30) #407
メモ
- WebRTCってぶっちゃけいまどうなの
- なぜつながらないか
- 辛い話
- @tonofo: SDPとCandidateが読めないと絶対運用できない。運用環境で何が起きてるかはCandidateしかない。
- @voluntas: 利権に合わせていくしかない。
- @iwashi86: 現状Firefox以外は独自仕様。
- ORTC
- @iwashi86: 期待している。
- @voluntas: 期待してない。Skypeのために策定しているようにしか見えないので1.0の間は傍観。
- @tonofo: どこまで仕様通りにできるようになるのかは疑問。
- WebRTC 1.0の仕様がそろそろ決まろうとしている
- テストどうするんですか、あるいはクライアントの話
- 組み込み
- 使っていく話
- @voluntas: プラットフォーマーは辛い。運用をするのが辛い。
- ただそれに乗っかればプラットフォーマーが各種スタックを用意してくれているのでそれが良い戦略。
- @iwashi86: 正直付加価値としてWebRTCを使っていくというのが正攻法。
- これまで他のことでやっていたものを置き換える、補強するという感じ。
- @tonofo: SDK側が辛い部分を吸収するので、SDK使ってる分にはある程度楽。
- @voluntas: 動画や音声みたいな簡単に見えるものの裏側にある困難な部分をいかにプラットフォーマーが吸収するか。
- @tonofo: WebRTCってこれまでのウェブの形と違う形になっているので面白いと思う。
- @voluntas: プラットフォーマーは辛い。運用をするのが辛い。
- これからの想定ユースケース
- あらためてWebRTC 1.0が12月までに決まる
- @voluntas: サイマルキャストが入って仕様が落ち着けば結構期待できる
- @iwashi86: 海外ではWebRTC系のビジネスが結構活発。資金調達も結構大型のものもある。
- 日本でも遅れてブームが来ればいいな。
話題に出たもの
- TURN - Wikipedia
- STUN - Wikipedia
- SkyWay ― WebRTCを簡単＆柔軟に使えるプラットフォーム
- VoIP API to Embed Voice into Web & Mobile Apps - Twilio
- TokBox
- ORTC (Object Real-time Communications) Community Group
- WebRTC スタックコトハジメ · GitHub
- Real-time Transport Control Protocol - Wikipedia
- Interactive Connectivity Establishment - Wikipedia
- Best Web Video Conferencing, Enterprise Video Conferencing & Software | Polycom, Inc.
- Scalable Video Coding - Wikipedia, the free encyclopedia
- ORTC SVC SimulCast
identity (14:40-16:00) #407
メモ
- これからRP（Relying Party)は何を使ったらいいのか
- リスク情報共有
- @_nat: あるアカウントがある1つのサービスでアカウントテイクオーバーされた場合に他のサービスに即座に知らせて2次被害を防ぐ
- 他のサービスにあるアカウントが所属している
- @_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: interpolやFBIの溜飲を下げるためには一段セキュリティの高い認証方法が必要
- @_nat: 「パスワードは公害」「パスワード税をかけたほうがいい」「総量規制をかけたほうがいい」
- なぜパスワードでやるかといえば「安く導入できるから」
- 税金と両壁をなすのは「保険」がある。情報漏えいした場合にどれくらい補填できるか。
- パスワードが悪いんじゃなくて、実際にはヘボいパスワードシステムが悪い。
- Googleはパスワードシステムに見えて他の要素も含めて判断している。300人チームでやっている。それだけのコストを掛けてやりたいのか。
- ログインやログアウトってなんで必要なんだっけ
- @nov: authenticatedされた状態が必要なだけだよね
- @_nat: ローカルデバイス、特に個人デバイスであれば一度認証したらずっと使えていればいいはずだしそうあるべき
- @mad_p: キオスク端末の場合は個人端末の認証情報を渡せる仕組みがあればいいだけのはず
- 認証と識別
- ユースケース毎のリスク評価
話題に出たもの
- OpenID Connect | OpenID
- JSON Web Tokens - jwt.io
- Security Assertion Markup Language - Wikipedia
- RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients
- OAuth PKCEがRFC7636として発行されました。 | @_Nat Zone
- draft-ietf-oauth-proof-of-possession-04 - Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
- アイデンティティ管理における「レベル合わせ」（2/3）− ＠IT
monitoring (16:10-17:30) #407
メモ
- 監視とは何か
- チェック監視とメトリック監視
- @songmu: 最近の傾向としてメトリック監視が増えている
- @mikeda: 昔に比べると細かい値を取り始めた
- @fujiwara: チェック監視とメトリック監視は各々役割が違う気がする
- @mikeda: メトリック監視で割といけることが増えてきたかなという印象
- 監視の間隔
- @fujiwara: 数日間は1秒単位のデータを取得したい。
- 1分間隔だとたまに起きる短い間隔でのスパイクを拾えない。
- @fujiwara: 数日間は1秒単位のデータを取得したい。
- 監視難しい問題
- @rrreeeyyy: 言語によってどこを監視していいかわからない事が多い。
- @mikeda: 監視テンプレートをもっと公開してほしい
- @songmu: Chefが良かったのは個々人が秘伝のシェルスクリプトでやってたことが公開されてシェアされた
- 管理もそういうふうになればいいな
- アプリケーションエンジニアとインフラエンジニアの棲み分け
- @rrreeeyyy: お客様によってはアラートごとに連絡ほしいという人もいれば、対応策まで考えてから連絡してほしいという人もいる
- @fujiwara: アプリケーションエンジニアにもアラートを感じてもわらないとサービスはよくできないと思う
- ただ一応段階をわけてアラートを出している
- どういうチームを作ればよいのか
- @mikeda: 少人数で24時間の監視体制を回すのは現実的ではないのに、それをやってるのがこの業界。
- @fujiwara: 特殊なチームメンバーの状況に依存すべきではない。どうしても対応できないならMSPなどに任せましょう。
- 監視周辺技術
- fluentdが与えた衝撃
- @mikeda: アレのおかげで各社でログをどんどんあつめてグラフ化するという流れができた気がする
- @fujiwara: どんどんログの処理がストリーム処理に近づいている
- SaaS使ってる？
- 原因特定・未来予測
- @mikeda: 未来予測系はまだやってない
- @rrreeeyyy: あんまりやってない。ただやりたいと思う。
- @fujiwara: アラート上げるときに0 or 1ではなくて「何か違うよ」を入れたい。
- @mikeda: 未来予測や任意の異常値の検出などは難しいかもしれないけど、検知の自動化はしたい。
- RDSのようなサービスを使うことによって監視は楽になったか
- 繋ぎっぱなしのサービスが増えてきた
- これからの監視
- @mikeda: 目の前の監視を続けていきます
- @rrreeeyyy: 次世代には監視業務はなくなればいいなと思うが当分なくならないので良くしていきましょう
- @fujiwara: 要するに夜寝たいので、監視システムを育てていきましょう
- @songmu: インフラエンジニアがなくなると言われた時期もあったが、なくなるどころか複雑化している。
話題に出たもの
- MSPとは｜Management Services Provider - 意味/解説/説明/定義 ： IT用語辞典
- Kazuho@Cybozu Labs: 監視とは継続的なテストである、という話 (もしくは cronlog とテストスクリプトを組み合わせた監視手法について)
- etcfiles/my.cnf at master · kamipo/etcfiles · GitHub
- Sensu | Monitoring for today's infrastructure.
- Graphite - Scalable Realtime Graphing - Graphite
- Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution
- Consul by HashiCorp
- Apache Kafka
- Cloud Monitoring as a Service | Datadog
- Application Performance Management & Monitoring | New Relic
- Mackerel（マカレル）: 新世代のサーバ管理・監視ツール
感想
とにかくまず運営および登壇者の皆様お疲れ様でした。参加率はいかほどだったかわかりませんが、あれだけの人数を登壇者だけでつつがなくさばいたというのは本当にすごいです。事前打ち合わせなど何回ぐらいあったんでしょうか。いずれにせよ、カンファレンスの運営が次世代な感じでした。
内容に関して言うと、自分が想像していた「次世代」よりはずっと手前側の話になっていたような気がしますが、それもあれだけの参加者がいて聴衆に気を遣ってもらうとどうしてもそうなってしまうのかなとも思います。現に自分がIdentityのセッションに参加した時はRFCやISOのドキュメント番号がどんどん出てきて、話を聞きながらそれを追うのに必死という状況で、現状把握ですら大変なのに、それ以降の話となったら追いつけなかったと思います。
今後開催されるかはわかりませんが、久々に自分のフィールドにない話題をその道のプロから聞ける良い機会でした。一参加者としてとても楽しかったです。ありがとうございました。
