次世代Webカンファレンス2019
SRE
メンバー
開発業務の割合
- Googleのプラットフォートチームでやっていることを取り入れていこうとしている
- ユーザーはメルカリのDevelopper
- プラットフォームそのものもやっている
- ユーザーサポートとプラットフォーム開発を5:5になるようにしている
- これがトイルかどうかの分類は結構難しい
- クオーター毎にレビューして次のクオーターの対策をマネージャーと考える
- 例えば割合が多い業務は早めに依頼してもらうようにお願いする
- タスクの割合の可視化方法
オンコール・インシデント対応
- クックパッド：オンコール対応は週次レビューを行い、重要な問題は再発防止する
- はてな：毎日振り返って緊急対応する。当番は休日はあったが、平日はない。SREだけでなく全エンジニアがポストモーテムを書くことになっている。
- メルカリ：モノリス時代はSREチームが担っていた。当番制で回していた。インシデントが起こったら関わった人たちがレポートを書くようにした。ポストモーテムは週一でSlack上で行った。
SLI/SLO
- SLOはプロダクト開発者ではなく、プロダクトマネージャーやCTOが決めるべき
- SLOをバイオレートする可能性があるものはアラート
- モニタリングはデータドッグをメイン。ワーニングはSlack、アラートはPagerduty
- オオカミ少年アラートが多いのをどうにかしたい
- GoogleのSRE本の学びとしては、チーム内全員をアラート全員が見る
- アラートのコード化を進めている
SREの今後
- ばらけていくのが理想？
- 皆がSREをやっていけば良い
- マネージドサービスに任せる
- 開発者全体に溶け込む
- スリーナインのサービスは開発者だけでは厳しい。そこにSREが入るべき。
- ML OpsについてはまだマネージドサービスがないのでそこではSREが必要になる
- SREは科学に近づいている
- 計測しやすくなる
- 研究したり、方法論を決めやすい
- 改善しやすい
- 科学に近づいていくべきだと思う
SREの生存戦略
- システムを理解したソフトウェアエンジニア
- 科学的なアプローチにトライできる人
- ソフトウェアかけるのは当たり前
- マネージドにできないことにどれだけチャレンジできるか
- SREは技術の話だけでなく組織の話だという文化が広まれば良い
用語
- トイル
- ポストモーテム
- SLI
- SLO
Security
メンバー
- コキチーズ
- セキュリティ診断
- mala
- LINEの人
- Livedoorの残党
- 障害対応
- 全社横断の対応
- 個人的にも活動
- 柳橋さん
- https://xss.moe/
- メルカリ
- 今はWebに限らずセキュリティ関連なんでも
- 徳丸先生
- セキュリティ会社やってる
- コンサルの仕事、ブログ
最近のWeb脆弱性
- CDN関連
- https://tech.mercari.com/entry/2017/06/22/204500
- キャッシュ設定していないはずがいつの間に課されていた
- 0秒設定のはずは1秒になった
- Wordpress/EC Cube
- パッケージマネージャー関連
- CVEの重要なもの読む
ブラウザの脆弱性についてどこまで意識すべきか
- 基本はない
- 何か問題あればアップデートされる
- ブラウザ側で治すべき問題をWebサイトで対応するのはしたくない
- 脆弱性のあるブラウザを使っているやつが悪い
- つけないといけないヘッダーが増えてくるのは嫌
- 脆弱性診断ツールだとアラートになる
- 意義をわからずにつけるのは良くない
- ヘッダーを一個つければよくしてほしい
cookie
CSPについて
- Mercariで入れようとしているが面倒臭い
- レベルの話？
- fastlyが設定してくれれば良い
- 問題があった時にレポートが来るようにしているが、量が多すぎる
- とってはいけない情報までとってしまっているものもある
- MicrosoftはXS FilterをやめてCSPに寄せる
プライバシー
- GDPR関連でcookieセットにも同意を求める
- 実装というか手続きの話
- 同意の形骸化になっている
- 本当に重要なものの合意ができない
- 先ずは機械的に解釈できるようにするべき
- 機械が読んでブラウザが判断できるようにする
- 人間を相手にすると厄介
- JSに同意をとる世界が来るかもしれない
- あの裁判次第★
- 既成事実を対象ユーザーが認知しているかは怪しい
- Canvas Fingerprinting
- 使うべきではない
- アドテックのカンファレンスでセキュリティ/プライバシーのセッションがない
- 知られていないのが大きい
- JSONPで広告配信すると漏れる
- ○○市に住んでいる人の特定
- セキュリティ・プライバシーはプライスレス
難読化
最後に
- コピペ問題
- 結城浩 C言語入門を改定
- 脆弱性関連の増強
- こういうところから底上げすべき
- 開発者自身が当事者意識を持ってほしい
- 法務にチェックしてもらったから大丈夫は本当か？
- 最初の一歩だけは気づいてもらいたい
- とっかかりだけは知ってほしい
Microservices
メンバー
- tagomoris
- treasure data
- fujiwara
- カヤックのサーバーサイド/SRE
- microservicesはやるしかない
- tokuhirom
- LINEで広告担当
- 自然にやってればmicroservicesになる
分散トレーシング
- トレーシングのライブラリ入れてる
- AWSのトレーシー？
- なんかあった時のログとしてとるには容量多すぎる
- 送る条件を決めて送るっていう手もある
- エラー
- 時間がかかった
- ログを串刺しに見る方法
- IDで横断的に見るのは基本
- LINEではログの収集基盤があり、串刺しで検索できるようになっている
- zeppelingがあるので見れることはみれるはず？
障害対応
- サービス毎に障害対応ポリシー作るのか
- サービス出す前にあるコンポーネント落としてみて正常に動くかをチェックしている
- カオスエンジニアリング
- アプリケーションの作り状、リトライができてれば良い
- LINEはカオスエンジニアリングに手をつけられていない
- LINEでは新しく入った人の教育で試している
- お客様に迷惑をかけなければ良いという考え方はある
- NetFlixは月額課金だから問題ない？
- 海外のビックプレイヤーがやっているからというで自分の分野考えずに導入するのは良くない
- いつかやっておかないと障害起きた時に爆発する危険性がある
- 特定のサービスが落ちた時にリトライしすぎて死ぬというのはありがち
canary deploy
- やらないで爆発するよりやった方が良い
- 常にはやらないが大きい変更の時はやる
- サービス重要度や規模次第
- 簡単にできるように作りこむのが大事(自動化必須)
サービスメッシュレイヤーのSW
- consulを導入している
- サーバー名等の登録
- DNSキャッシュ
- サーキッットブレーカー
- どの段階で入れるべきか
- 入れるのが当たり前になれば良い
- アプリケーション作成側が楽になる
- ある程度大きい会社であれば基盤部門が導入してくれれば良いはず
サーバーレス
- firebaseの世界
- 結局データ構造考える人がクライアントの人になるだけ
Microserviceの実装面
- gRPC
- クライアント言語によって対応状況の違いある
- https化
- マネージドであまり対応できていない
- スキーマ固定が必須
- 言語がバラバラになるとスキーマなしの通信は無理
- MySQLを直接たたかずにgRPCで包むっていうやり方もある
- failOver時の対応はgRPCの先
- LINEはthriftが多い。一部はgRPC
- JSON利用は減っている
- パフォーマンス的に厳しい
- 複数のプロトコルを1つのミドルウェアをしゃべるケースがある
- Kafkaへの接続
言語
- JSONは大体の言語で良いのある
- データ形式によっては言語毎に差異ある
- Amazon/Googleがサポートしている言語を使うのが良い
- Line:大体はJavaで解決するという立ち位置
- kayak:Goが多い。昔のはPerl。型付の方が変なバグ起きない。数年前にGoに決めた。
- 監視に対応しているかという観点も重要
- Goの監視
- GoのGC等のモニタリングするライブラリある
- マイクロサービスは言語の変更はしやすい
人数が増えるとMicroserviceが当たり前
- １リポジトリで開発するのは大変
- できるだけ分けるべき
- ピザ２枚理論
- S3は２百以上のマイクロサービスに分割されている
- Lineは1コンポーネント毎にサーバーサイドエンジニア3,4人が多い
- 拠点毎にマイクロサービス化するのが良い
Webサーバーサイド
- マネージドサービスによって、担当できる範囲が広くなっている
- 広くするかピンポイントに深くする必要がある
- 1つの場所にフォーカスする仕事が増えている
用語
- consul
- サービスメッシュ
HTTPS
メンバー
- @jxck
- @jovi0608
- @kjur
- @4ma_
PKI/CA
- シマンティックのディストラクト
- CAブラウザフォーラムの体制が変わった
- PKIかわいそう
- そこまでたたかれることか
- GPKI
- リニューアルとしてCAをサブミットした？
- 運用できていなかったことを指摘された
- 魔女狩りに近い？
- EV証明書は無くなると思っている
- 認証と信頼は別
- Let's Encryptで良いじゃんへの回答？
TLS
- TLS1.3の正式化
- TLSデプロイ状況
- SSL PulseによるとTLS1.3が想像より上がってきていない
- TLS1.0,1.1を消すのはどれぐらい大変か
- TLS1.3への移行
- ガイドが出ている
- gistによると1.2,1.3を並行して使うのがガイド
- TLS1.4に向けて
- ゼロRTT
- 量子コンピュータによる暗号化
- https://twitter.com/jovi0608/status/931001682493890560
- 周期性があるものを見つけるのが簡単
- 公開鍵暗号化は脆弱になる
https
- やってこうという話が4年前
- https厳格化するための対応(hstsなど)がどれも上手くいっていない
- httpsは100%であってはいけない
- alternativeがないとマジョリティがダメだった時の逃げ道がなくなる
- httpsは通信の暗号化に寄り過ぎた
signed http exchange(SXG)
- 参考
- いままでは通信の暗号化に偏っている。(土管レイヤ)
- その上のレイヤでの対策が必要
- URLで識別するのが限界になってきている
- それに変わるスキーマが必要->SXG
- SXGへ期待している
- インターネットアーカイブ等への用途の広がりもある
- コード署名と同じ考え方
HTTP3
https://http3-explained.haxx.se/ja/
メンバー
- @flano_yuki: Webとプロトコルの標準化 Watcher
- プロトコル愛好家
- 読んで実装しているおじさん
- @kazuho: CDN 等で使用される HTTP サーバ「H2O」の主開発者。HTTP, TLS, QUIC の標準策定に貢献 [blog]
- fastly
- コーディングがメインで関連する標準化活動へ参加している
- @kaname: IETF で最新プロトコルを追っているネットワークの中の人
- NTTコミュニケーションズ
- ネットワーク視点でHTTP3を見ている
- ベンチマークとってる
- @ysnysnysn: WebSocket や Streams の実装と標準化をやっていました。最近はロボットやってます
- 吉野
- 今はPFNでロボット
- 去年までAPI関連やってた
HTTP3とは
- セマンティックすはHTTP2と同じ
- 大きな特徴はQUICを採用している
- HTTP2でリクエストを投げてQuicに対応していたらQuicで通信する
- 名称
- つけたくなる気分はわかる
- QUICに対するバインディングの名前が変わった
- G-QUICとI-QUICの差がわかりづらいという混乱があった
- I-QUICをHTTP/3となった
HTTP3というプロトコルの見方
- 妥当な進化をさせようとしている
- ネットワーク事業者視点
- 輻輳制御
- NATのバイディング
- 暗号化
- インターネットの5%で既に使われている
- TCPはガタがきている
- レイテンシの壁
- インターネットのレイテンシはあまり変わっていない
- セキュリティの観点
- 平文想定
- レイテンシの壁
- 皆がHTTP3使い出したらどうなるか
UDPがどれだけ使いやすいか
- ファイアーウォール
- UDP443が通らないところが数%あったが、3年後に1/3になった
- NAT
HTTP3で何が嬉しいか
- ネットワーク品質が悪い国では効果あり
- 日本のようにネットワーク品質が良い国の効果は？
- 0-RTTで接続ができる
- ネットワークローミングができる
- wifiから公衆回線への切り替えができる
- partial relaiabilityも入れられる
Quicをどこで使えば良いのか
- WebRTCに向いてる？
- 動画
- DNS
Quicが向かない分野
- レイテンシが小さい場合は別のレイテンシの悪影響が出てくる
- パケロスが少ない
- 例. データセンター内の通信
Webの進化とプロトコル
- WebSocketを作ろうとした時の苦労を思い出す
- Httpの意味論
- 基本的に数十年は変わらないと考えている
- HttpNGで変えようとしたが、上手くいかなかった
- 将来は予測つかない
