次世代Webカンファレンスに足を運びました #nextwebconf

本日は、次世代Webカンファレンスというイベントに足を運んできました。世の中にはいろいろな勉強会がありますが、こちらは識者たるエンジニアの皆さんが時事放談をするちょっと変わったイベントとなっています。

その道の前線にいらっしゃるからこそ日々考えていらっしゃる事柄について、深くじっくりと伺える良い機会となりました。

運営の皆様、そしてパネリストの皆様、どうもありがとうございました！

今回も、例によって感想とメモを残します。

※ビデオもYouTubeの「nextwebconf」チャンネルへアップされるそうなので、セッションの内容に興味がある方はご覧になってみてはいかがでしょうか。

まとめと感想

server_perf

サーバパフォーマンスを引き出す話題に絞り込んだ、話す皆さんは結構大変だろうなと感じながら聴いたセッションでした。Webアプリケーションとしてサーバサイドのソフトウェア開発を行う比率は減り、代わりにAPIサーバの開発の比率が上がってきているというお話でした。その中で、スループットよりもレイテンシ、大きなリクエストより小さなリクエストが増えるシフトも発生しているとのことでした。その中で、並列処理に長けた言語を駆使することが一つのキーポイントになるようでした。

僕も最近は業務ではGo、個人ではScalaに触れる機会があるのですが、これらはどちらも並列処理に長けた言語であります。勘所としていかに活用すると良いのか、自分の理論を形成するための非常に良いヒントをいただけた時間になりました。

server_arch

これからのサーバサイトのアーキテクチャについてのセッションでした。Mincroservices の話はもちろん、CD(Continuous Delivery)、そしてgRPC Gateway開発者の @yugui さんがいることもあり gRPC の話が随所に登場しました。

気になったのは、Googleなどのハイパージャイアントと同じ設計思想を、そのまま中小のWebサービスやスタートアップに採用していいのか、ということでした。ある程度枯れて、実績があり、かつビジネスの速度が向上できるなら積極的に取り入れるのは賛成です。一方で、最高のアーキテクチャを採用しようとしてオーバーエンジニアリングになり、商売として成立しなくなったら元も子もありません。そのバランス感について議論があったらよかったなと思いました。

security

Webのセキュリティ、特にブラウザと、ブラウザを絡めたアプリケーションのセキュリティの議論が繰り広げられたセッションでした。Webアプリケーションそのもののセキュリティは、徳丸本をはじめとした知識を備えているエンジニアが取り組めばほぼ問題ない状態であることはセキュリティ業界の人としては「仕事はどうしよう」ということらしいです。

興味深かったのは、W3Cをはじめとした標準化を進めている団体の仕様はセキュリティ部分について網羅性が足らないという話でした。理想は仕様策定段階で潰せるといいでしょうが、実際は実装から潰していくのが良いという着地点は、非常に現実的だなと感心したのでした。セキュリティを専門とするエンジニアの方たちは、地続きにつながる未来に向かって戦っているのかもしれません。

http2

今ホットなHTTP/2の話題です。HTTP/2が必ずしも高速化を実現しないという現実の把握から、それを改善するためのプライオリティ付けの見通し、そしてTLS 1.3やQUICなどの新しい技術に対しての話題に広がっていきました。

プロトコルはプログラミング技術ほどは変化は激しくないにしても、その基礎となる技術の変化が徐々に早まっていることは、少々恐れていることでもあります。これは、ソフトウェア開発の基礎知識の刷新速度が早まることを意味するからです。これは、少なくとも僕に対する技術者の勉強の仕方に変化を促されているのかなと考えているところです。

monitoring

現場で普段関わっている、サーバの監視について意見が交わされたセッションでした。これまでの監視を棚卸しし、これからの監視がどうあると良いのかに話がつながりました。これからは、より細かいデータの分解能、障害予測、そして自動復旧がキーワードになりそうです。また、新しいWebサービス提供企業ほどDIYで監視システムを構築するのではなく、SaaSを利用した監視システムを利用している傾向があることも興味深いことでした。

僕はMSPの未来をどうするか具体的に手を動かして進めていく立場にあるので、大変興味深く議論を聞いていました。これは僕個人の意見ですが、新しいWebサービス提供企業がSaaSを使って監視するのは大変合理的だと考えています。それは3つ理由があり、開発によりコストをかけられる、ITインフラエンジニアにかける給与よりもSaaSのほうがおそらく安い、そして現時点では競争が激しいのでより良い機能がどんどんつく可能性が高いからです。だからこそ、MSPにおいて監視の部分でどう価値を出していくのか、どんどん回答を出さないと市場に置いて行かれてしまうのではないかという危機感を持っています。

メモ (敬称略)

server_perf

• モデレータ
  • @mirakui
• パネリスト
  • @xcir
  • @cubicdaiya

• サーバサイド技術は随分細分化されている、だからこそパフォーマンスだけに絞る。
• ISUCON
  • 仕事でやっていること以上はできないんだなってのを痛感する @cubicdaiya さんのISUCON後日談
    • アクセス分析
    • 業務分担
• Webの比率の低下
  • パフォーマンスチューニングの勘所の変化
  • APIリクエストの増加
  • サーバ負荷の低下
  • いかに、リクエスト数自体を低下させて負荷を低減させるかがポイントになりつつある。
  • 某ECでは
    • Webは1割、他は全てスマホからのAPI。APIはほぼJSON。
    • やることは減ったが、単体の性能がより求められるようになった。
    • レスポンスデータ量は減ったが、レイテンシがより求められる。
• 改善の取り組み
  • 全てには流れがある
  • 3〜4万接続/台のnginxサーバを安定してどう動かすか
  • Proxyサーバを書いてAPIサーバに負担をかけない
  • キャッシュの非同期化、検索リクエストの非同期化→ジョブワーカーベースで実行。
  • トランザクション処理が必要となるものはチューニングは難しいので、札束でひっぱたく。
    • IODrive, など。
  • そもそも仕様を変える
• キャッシュ
  • 銀の弾丸
  • 運用のしやすさとはトレードオフとなる
  • 基本
    • 生成コスト
    • パフォーマンスがどのくらい上がるか
    • どのレイヤーに置くか
    • 範囲 (共通のものから優先する)
  • 消すとき、消せないとき、どうするのか。
  • ログインしているユーザ情報はキャッシュしない→事故の防止、A/B回線がしづらくなるのを防ぐ。
• 言語の選択
  • 言語はあったものがあればいいのだ。
  • 流行っているからだけでは理由が浅い、特性を見極める。
    • 支えるスタッフが多いから
    • アプリにあっているから
  • CPUの1コアあたりの性能はすでに頭打ち マルチコアで性能を引き出す
    • 並列・並行処理
    • マルチコアで扱いやすい言語を選択する (GoとかScalaとか)
    • LLだとfork()しないといけないので計算機コストがかかりやすい
    • Railsは1リクエストあたりのオーバーヘッドが大きいので高リクエスト時代には見合わないかも
• フレームワーク
  • ルーティングできればよい、軽量なフレームワークを選択する。
• ミドルウェア
  • Varnish
    • 4.1 いじれるところが増えた
      • bodyの加工が可能になった
      • 画像の圧縮なども可能(いわゆるスモールライト)
      • 黒魔術からインタフェースへ
    • Peakでキャッシュヒットレートは95%　現在は85%くらい
    • 多段をしないとキャッシュ不整合が起きやすい
    • 将来: HTTP/2: 4.x系で対応の準備は進んでいる
    • 最近は落としたことはない (3系の古いものはあったが最近はない)
  • nginx
    • APサーバ 30〜40台 その前に置いている
    • 検索サーバの前段にもある
    • Push通知のサーバ
    • Deploy
    • Lua, mrubyなどで拡張していく 簡単な処理を行うAPサーバを書いて高速に裁く
    • nginx script
      • 変数のset, contentフェーズへの書き込み, ヘッダの書き換えがややできる程度
    • 全ての処理をノンブロッキングで処理しないとnginxの良さが失われる
• ネットワーク
  • 米国は国土自体の大きさが違う！
    • TLSの最適化のためのコード(セッションキャッシュ)を入れ込んでハンドシェイクのコストを抑えている
  • 最初から海外のときは
    • 便利にAWSさんお願いします！
      • US-EAST(世界中だいたい同じくらいの速度で…遅い！日本よりはまし)
      • us-east–1は障害が多いという話もあるので考える
    • 近いところにサーバを上げてしまう。
  • CDN重要
  • 日本ってネットワークトラブルが少ないですよね…
    • 大雨で
    • 海底ケーブルが切れる
  • 東南アジアで6MBを超えたアプリはDLされない
    • Opera Term/Opera Miniを使うと画像サイズを小さくしてくれるとかJSをサーバサイドでレンダリングしてくれたりとか
    • 東南アジアはOpera Mini対応で苦しんでいるらしい ガラケー時代のように
• 未来の話・まとめ
  • CDNを使わざるをえない時代に
    • 日本: オフロード
    • 海外: レイテンシ改善(ユーザの近い場所に)
    • 昔に比べて求められることが増えた
  • アプリを載せるレイヤーが上に上がってきている
    • フロント側にボトルネックがシフトしている

server_arch

• モデレータ
  • @ryushi
• パネリスト
  • @yugui
  • @making

• gRPC Gateway
  • Protocol bufferでとりまとめて返す
  • HTTP/2時代に沿ったものに
  • よくない点: JSONベースのAPI(今まで)と互換性がない
  • サーバプッシュが支えてP2Pもできて良い
• SOAPとgRPC
  • 堅いところだと今でもSOAPは主流
• back pressure
  • いらないのでは？
  • あってもTCPの接続断の復帰などを考えると処理が難しいのでは
• Reactive Programming
  • 昔からあったけど、人類が扱えなかった。と思う。
  • スケールさせるためには必要だ。
  • ハードとお金の問題だけでは解決できなくなった。だから、ソフトをちゃんとしないといけない。
  • Reactive Streams
  • Elixr は「隣の芝が青い」くらいにしか見えないw
• ネットワークに困っているのならGCPに移ればいいじゃない。
  • スイッチの話はあるけど、まあこれは内部の話だ。
  • 外との通信も解決するのか、な？
• ScalaとGo
  • ScalaはTwitterの後をついていけばなんとかなるという安心感
  • ビルド速度は遅いが(確かに遅い)
  • Golangの依存ライブラリのvendoringが辛い(でも1.5から解決していく気がするで)
  • ライブラリを一カ所にまとめて、社内標準にするやりかたもどうか。
    • バージョン齟齬の阻止
    • 検証の一本化
• どんな道具が揃ったら乗り換えるのか
• Microservicesのコンテキスト
  • 狭義のMicroservicesとは？
    • サービスレジストリ・サーキットブレーカ
    • Netflixの事例
  • デプロイな簡単なインフラが必要
    • プログラミング言語に縛られない
    • Dockerで標準化
      • メタデータ付与の必要性は検討されるべし
  • モニタリングが簡単なインフラが必要
• 「地雷を踏む」
• Monitoring
  • サーキットブレーカ
  • Prometheus (dockerコンテナのモニタリングツール)よくできてる

security

• モデレータ
  • @hasegawayosuke
• パネリスト
  • @kinugawamasato
  • nishimunea

• 「徳丸先生に怒られないセキュリティ」
• Webのセキュリティはサーバ側の対策に比重が高い
  • やり方に型が出来ていて銀の弾丸はある
  • 改めて研究調査しなくていいよね
• 「新しいXSS」
  • 遊び甲斐がある！！！
  • Deep Link
    • 今までの延長で考えられていなくて準備できないパラメータでアプリが呼ばれたときの対策がまだまだ
    • calurator:とか
    • Firefox 44が出たときに明るみになる脆弱性とか
• ブラウザの特殊な機能を使った脆弱性・ブラウザそのものの脆弱性
  • Webのセキュリティは曖昧なところで決まっている
    • Cookieもhttps, httpで共有
    • Refererとかどうよ https→httpとか丸見えだし
  • 自分の中で整理したい(nishimuneaさん)
  • IETF, W3Cの情報は網羅性はない
    • http://www.w3.org/TR/css-font-loading–3/ とか (originって言葉がない)
  • HSTS Super cookiesの記載は、大元のドキュメントだけ見ていても脆弱性はわからない。
  • 仕様面での脆弱性調査はあまり多くの人が見ないのでブルーオーシャン！
    • 仕様の策定段階で入るのはどうすればいい変わらない
    • 実装を基にした脆弱性報告の方がやりやすい
    • お金になるのは脆弱性報告…
• 今のWebでそれはアリか？
  • 新しいものを入れるbut脆弱性報告の検証はあまりないっぽい→ダメだったら停止
  • 薬とか、重篤な副作用が起こらないように検証とかありますよね？
  • 新しいものをリリースしたときに、少なくとも脆弱性がある状態にさらされるけど本当にいいの？
  • 規格を考えている中の人、それでいいの？
• Cookie
  • Origin Cookie, Secure Cookie
• 新機能
  • httpsのサポートなしには動かないような制限を加えてもいいのではないか？
  • How HTML Injection Is Bad on Firefox OS
• CDN
  • 「信用するしかない」
  • SRI https://www.srihash.org/
• file:// スキームの問題
  • 他のすべてのオリジンのスキームにアクセス可能
  • 権限がめっちゃ強い
  • Electronが積極的に使うので問題が起こるのではないか
• できる技術者は自力で脆弱性は撲滅できている。その上で、セキュリティ診断の人たちは何をしてくれるの？どうやって今後生きていくの？
  • 一方でできない人はまだまだいるので、そこに入り込む余地はある。
  • そこって、セキュリティよりも開発者としての育成を徹底したほうがいいのではないか？
• Click Jacking

http2

• モデレータ
  • @jxck
• パネリスト
  • @tatsuhiro_t
  • @jovi0608
  • @kazuho

• HTTP/2の今
  • RFC7540, 7541で仕様化が完了
  • でかい揺れ戻しやでかい脆弱性も特になく無事仕上がった
  • 主要ブラウザはサポート完了
  • サーバ側もnginx, h2o, nghttp2(ライブラリ)が揃っている
  • 言語側もサポートを進めるべく取り組まれている
  • h20、http/1系よりも速くなっていない部分も…まだあるので頑張りたい
• 速くなることとの関係
  • 「速くなる」: ダウンロードのパイプラインの制限がかからない
  • 「遅くなる」: 依存関係の解決が全て終わるまで画面のレンダリングは終わらない 以前ならHTML, CSS, JSがダウンロードできた段階で終わってた
    • parse paintは昔のほうが速い
  • 1本の接続がブロッキングされると破壊的に遅くなる
• プライオリティ
  • mime type を見て、CSSやJSを優先的に送る(h2o)。
  • ブラウザ側は現在進捗中。ChromeはIssueがある。Safariもがんばるっぽい。Firefoxは進んでいる。
  • ただ、プライオリティをつけたからといって万能的によくなるわけではない。
• RTT
  • 効果が出るサイト・出ないサイト
  • 1RTTで差が出る
• P2P Extension
• サーバとクライアントの負荷が下がる
  • 1コネクションで一括で転送できるので互いに負担が少ない
  • TLSの接続でもさらにアドバンテージがある 暗号化による負担よりもリクエスト数提言による負荷低減のほうがアドバンテージがある
• ではGoogleなどの巨大組織のみしかメリットがないのでは？身の丈にあうの？
  • 1％の売り上げ向上
  • ハイパージャイアントと同じ土俵に上る
  • シャーディング・インライニングが入らなくなる
• いつからHTTP/2対応サイトを作るべきか
  • モバイルだともうすぐ(ブラウザのサポートは終わっている)
• HTTP/3はどうなのか？
  • TLS 1.3に今は目が向いている、その上で次。
    • TLS 1.3はメジャーバージョンアップと呼んで良いほどの改良が入る。
  • QUIC
• WebSocket
  • HTTP/2では動きません！
  • 今後どうなるんだろう、見通しはわからない。
• QUICって？
  • 0RTT
  • TCPのいいところをUDPに実装
  • Socket Buffer の問題も解消する
  • h2oも取り組むのは時間の問題
  • ゲームではUDPが普通だから期待も高い
• テキストでコマンドを打てる時代から、バイナリプロトコルへ。
  • “Hyper Text”ってなんだったのか
  • 「みんなTelnetでデバッグしてるの？curlでいいじゃない。」
• 負債はいつまで残るのか
  • 2020年にHTTP/1.1と5だけ、という世界もあり得る。
  • FTP生き残ってますよね？サーバは20世紀にたてたのが最後かもしれませんが。
• 進化には意味がある
  • ブラウザ・サーバを実装する人が追いつき、使う人が追いつけるのかは悩ましい。
  • エコシステムの中心が移った時に1.1を使う人は取り残されているのでは、という恐怖がある。
  • 勉強するコストが上がっている。
    • HTMLをタグを教えるだけではもうどうしようもない時代
  • セマンティクスが残るのは、今はいいけど、今後負債になるのではないか？
  • 学習コストは…まあ、1年ごとに変わることはないからね！

monitoring

• モデレータ
  • @songmu
• パネリスト
  • @fujiwara
  • @mikeda
  • @rrreeeyyy

• 監視とは？
  • 落ちたら困るものを見つける
  • リソースの傾向を見てあらかじめ手を打つ
  • 継続的なテスト (kazuhoさん)
  • インフラと開発の境界は薄くなってきている
• 死活監視からメトリック監視へ
  • 分けることを重視する人とt、わけなくてもいいと思う人といるよね。
  • 「ベストエフォートはなんだったのか？」
• 分解能
  • 5分→1分の時代へ
  • 1分の中の数秒間だけ劣化した時の問題をどう捉えるか
• 監視難しすぎる問題
  • 言語別のくせ
  • ミドルウェア別のくせ→運用中にわかる
    • 新しいミドルウェアを増やさない
    • アプリエンジニアも関与してもらうとかどうかな
    • ただアプリエンジニアは反応してくれる人とそうでない人がいる
• Chefのよさ
  • 秘伝のShellスクリプトが、プログラマでも触れられるような仕組みになって、プログラマでも関与できるようになった。
• インフラだけで動くと、ノウハウが共有されづらい。
  • HBの「きりわけとエスカレーション」の話は吉川さんから出た。
  • 自社サービスでサービスに影響が出るアラートを感じてもらうには？
    • 対処のレベル感 4段階 3営業日・翌営業日・即時・緊急
• 「人がいないけど24時間 それをなんとかしているのがWeb業界」
  • 当番を組めるほどの体制を組む必要がある。
  • 委託が難しい理由は、同じものを見て同じレベルでやるか。
    • トレードオフ
    • とはいえHBはソースは見てます(マネージドの場合)
  • 事故るのはアプリ要因が多い、半々…？
• 新しい技術
  • TSDB
    • ZabbixのMySQLを馬力のあるマシンでとりあえずこなすってのはできる
    • 大きなサービスとしては必要となるよね(Mackerelとか)
      • InfluxDBはインタフェイスが不安定なのでやめた
      • DatadogはCassandraを採用しているらしい
      • ZabbixもCassandraを採用するとスケールする…らしいがそれすごい手間っぽい
  • 監視
    • 監視とクラスタマネジメントがセット、Consulを推したい。
    • ただしConsulのアラートを投げる方法は別に考えないといけない。
  • fluentd
    • ログ収集の革命
    • だんだんストリーム処理へ
• 監視システムが徐々に複雑になりつつある→監視ソリューションのアウトソース
  • MSPでは業務として採用するのは、現段階では採用は行っていない。
  • 自社サービス: 今後はZabbixなどからシフトさせていきたい
  • 共通: 監視システムの監視をするのは辛い
  • 新しい会社は、外部の監視サービスにアウトソースしている傾向が強い模様。(「WEB系各社で使われている監視ツールまとめ – mikedaの日記」より)
• 通知と障害対応の予測
  • 外れ値の認識をどうするか
  • 画像レベルで認識してズレを見る: ただ、一般化は難しい
  • 基本的な線形回帰を越えたものはまだ出てきていない
  • 死活監視の0/1の問題ではすでにない
  • デプロイなどのイベントの内容
    • イベントプロットができるようになると、そこだけ通知停止とかできそうでいい。
    • 「なんの」障害かを特定するのは難しい
• マネージドサービスの難しさ
  • ミドルウェア自体を使うことは楽になった。
  • 監視が難しくなる 分解能・メトリックの種類はPaaS次第となる。
• オートヒーリング
• Microservices
  • コンポーネントが増えて複雑化すると解決が難しくなるのではないか
• 新しいミドルができたら、監視の口も開けて欲しい。
  • h2oとか
  • JavaScriptの動的なページ(フロントエンド)の監視をどうするか
• 新時代の監視
  • 通信の流れが続いているか…アプリケーションと連携した監視が求められる
• アプリケーション、ミドルウェアを作る人も、だるいかもしれないけど、監視のためのパスを作ってもらえるといいな。より高度さが求められる監視に追従できる。