aretan.jp

WebをWebたらしているものは何か¶

Webを使う人達、Webで作る人達、Webを作る人達
UserとProviderの関係
論文を共有したい、HTMLとHTTPとURL、HyperMediaSystemの構築
そのとき、Web PlatformはHyperMedia Systemだった
「これはWebを支える技術」で完全に説明されてる
HyperMedia Systemにとって重要なこととは
セマンティクス、URL、分散、ハイパーメディア、ステートレス、とか
Cookie, Form, JS, iframeなどの技術が入ってきた
使いにくい社内システムとかはこういう過去の技術で成立してきた
DHTMLとか出てきても、まだ本質は変わってなかった
Jesse James GarrattがAjaxを発見した
ページ遷移からの脱却、右を押すと右に動く地図が、ぬるぬる動くように
ブラウザは取得されたJSを即座に実行する
誰がどう書いたかもわからないようなものが動く
Jsonpがだめだった理由、別サーバの情報が漏洩する
Originの導入、UMPと揉めたりもした
「できないこと」を整備することで「できること」が増えた
Same Origin Policy、Webのセキュリティモデルを整備
XHRやIframeの挙動原理の整理、Ajaxの正当化
派生議論の解決、JSONP、APIの設計、Originを超えれるヤバさ
マッシュアップとか言ってた時代だから、Originを超えるための議論
Cross Origin、Originを正しく超える手順の定義
CORS Preflight、Websocket Handshake、WebRTC Signaling、ServiceWorker Opaque Responseなど
CROSS Origin Infoleak対策、Site Isolationの実装、バグの高額報奨金
今の議論の対象はCookieやばいのどうする
このあたりから、Webを支える技術では説明しきれない領域に
URLが重要、にURLによって展開されるOriginが重要という意味も含むように
Web PlatformはApplication Platformになった
Applicationを作るには貧弱すぎた
Applicationとしてはないもののほうが多い
線ひけない、動画音声、ベクタ、XHRでのPollingしかない、Font、データ保存、とか
Applicationになったので、概念が大きくなりWebを説明できなくなってきた
それはWebに必要か？論が発生するように
Webはこういうコンテンツを提供するという説明ができなくなってきたので
Contents Use CaseでAPIを議論すると失敗する
Functional Use Caseでの議論に移りつつある
チャットはWebでやるなよIRCでやれよとはならないように
他のApplication Platformと比較されるようになってきた
Mobile App Platform、どうしても比較するように
低レベルAPIの極地に到達する、Webでデバイス関係なくやれたら良いじゃん
WebUSB API、Web MIDI API、Web NFC APIとかデバイスのAPIがどんどんでてきた
こんなのいる？誰が使うんだよ？それWebでやること？
もうBrowserがデバイスマネージメントしはじめたらそれってOSじゃん
要不要の議論は尽きない、ある程度説得力のあるFunctionalUseCaseがあって
セキュリティモデルが確保できるならそれをやろう
OSのセキュリティモデル、インストールというモデルでセキュリティを確保する
安全なデバイスアクセスを実現するセキュリティモデルを構築する
Permissionの導入
Permission API、Quota
ユーザーにやっていい事を聞く、Persist()を呼ぶとPromptが出る
Feature Policy
XSSでデバイス読めないようにとか
Secure Context Restriction、ITM発生時のリスクが大きくなる
User Gesture
リダイレクトしてクッキーを食わせるとかをしていたが、
ユーザーがスクロールやタップしてないとAPIを呼べなくする
Secure Context
デバイスへのローレベルAPIをどうすれば提供できるようになるか、議論している
WebUSB API
WebUSBに対応したUSBしかつかえないようにしすりゃいいじゃん
でもそれっていつ市場に出回るんだよ
Chromeを止められるのはもうMozillaしかいない、RFP: WebUSB API
Writable File API
まだセキュリティどうするか決まってないのに走り出している
Web PlatformはOperating System、パーミッションの問題を解決しなければならない
時代の要求に応じて「Webは何か？」の答えが変わってきている
WebをWebたらしめているものとは、、、
HyperMedia System：ドキュメント共有、ベンダ非依存
Application Platform：様々なユースケースを実現、CORSで壊れないように
Operation System：APIの低レイヤー化のはてデバイスを視野に、Permissionの導入
WebがWebとして壊れないために必要なものを模索（後方互換）

今のWebのメリットとは何か？を考える
互換性を壊さずに延長していっている、Webは停滞するかもしれない

WebがOSになってくるんだったら、OSもういらねーじゃん
その答えがChromeOSとかが答えなんだと思う、Webがどこまで取り込むのか

Flashを潰すことでコンパクトになれた

ネイティブアプリとWebアプリでどういう違いがあるのか
アプリをインストールするという体験を除けば違いはない
が、セキュリティモデルは違ってくるよねたしかに
ChromeとElectronは何が違うのか、Slackとか
できることはできないことにより定義される
パーミッションのとり方が違うだけだよな

高集積コンテナホスティングにおけるボトルネックとその解法¶

ロリポップマネージドクラウド
MrubyのコンテナエンジンHaconiwaを使ったサービス
Namespace
unshare --netでHostOSとネットワークを分離
Chroot、ディレクトリを分離
Cgroup、CPUやメモリやDiskIOのリソースを制限
Capability、Linuxの権限管理の仕組み getpcapsでポートを制限
LXCで学ぶコンテナ入門＠ten_forwardは必見
FastContainerアーキテクチャを利用して使っている
リクエストを契機にコンテナを起動し、一定時間処理して自動停止
ユーザーデータをストレージに置くことでスケールが早い
コアバリュー：コンテナをいかに早く起動するのか？
NetnsのAddが1分かかってて遅かった
ip netns add XXX
ip netns exec XXX yyyy
strace perfで調査すると、Slabをみると12Gあった。
slub.cのDeactivate_slabを読み込む。。。
Slabtopで見るとDentryキャッシュが多かったのでdrop_cachesに3を入れる
毎朝Cronで実行することで解決
Slab12Gとかいくと初期化処理だけでとても遅くなる
1000コンテナの壁
Bridgeがbrctl showでみると1025で頭打ちしている
net/bridge/br_private.hで2の10乗で定義されていた
カーネルにパッチするのはいやなのでBridgeを増やして解決した。
Dockerの場合は、Openvswitchを使うか、カーネルコンパイル
CPU・メモリは余裕なのにロードが高い
cadvisorでコンテナ内の情報を見てスケールしたりしている
gdb ip
b sendmsg
run netns add test_1
bt
とGDBで調べたらiproute2のip/ipnetns.cでget_netnsid_from_nameが当たる
最新のソースではパッチが当たってたー、新しくしたら解決
MacAddressPolicyの変更、Noneに
2500コンテナになるとまたip netns addがまた当たるように
fs/namespace.c copy_treeが遅い
/ver/run/netnsを再帰的にマウントしている
BINDマウントでSHAREDマウントしているMS_RECは再帰的なのでO(n)の時間がかかる
2500個あるから時間がかかっている
我々の用途ではMS_RECが要らないじゃん
3500コンテナ
ip netns execが遅くなったので調べてNetns_switchが支配的だった
ip netns execの中身をみるとこれコンテナじゃん
unshare netns -> unshare mountns -> slave rootsystem -> sys mount
IP追加したいだけなのにコンテナがんばってる
4000コンテナでメモリ枯渇、リソース使い切った！
追加してvalgrindを紹介したい
mrubyのAPIクライアントがメモリ食うらしい・・・
みたら瞬間的に９GBぐらいメモリが消費されているｗ
valgrind mruby test.rbとかして調べる
strace -fc mruby test.rbで統計を取る
perf record --call-graphで調査する
本番のWordpressにABすると関係ないサイト落ちました
apacheに-Xをつけてシングルプロセスで動くのでperfして調べる
Straceで見てみる、たまに遅い時がある、lstatを打っている
Realpathcacheを取っているときに重かった
NFS使っててPHPはファイルを都度開いてコンパイル実行するので遅い
Seccompでシステムコールの制限をするとかRlimitするかとか検討中

Building Self-Fosted Kubernetes¶

K8sは抽象化レイヤーにしっかりなっている
仮想化よりもっと抽象化されているのがいいところである
自律システムであるという所は売りである
KubernetesはMicroservice設計で実装されている
K8S on K8Sは結局K8Sのメンテしてくしかないね
SELF-Hosted k8s
Level of Self-Hostingというレベルわけがあって
0-4 Self-hostingみたいな表現をする
Kube-Apiserverを介さないPodであるStatic podを使う
Static PodでEtcd apiserver cm schedulerを作る
その上にApi-serverにK8sを構築して、Static Podを消す
TestnicやKubeadmならSelf-Hosted K8Sを作れる
MagnumやRancherやKubesprayじゃSelf-Hostedにできない
まとめKubernetesはKubernetesで管理できる
1台のSelf-Hostedだと死んだらやばない？HA構成くんでくれ

RDB The Right Way¶

サービスとかアプリケーションよりデータベースは寿命が長い
データと情報は違う「多くの情報を秘めた貴重なデータ」
データを永続化して蓄えるのがRDB情報を生成するのがSQL
データ設計と情報設計をわけることが大事になる
RoRとか使ってるとここが一緒になっちゃう
データ設計：事実をどう保存するのか
情報優先でデータ設計をするとデータに矛盾が生まれる
ER図でモデリングをする
イベント：過去の事実（いつ、いくら、いくつ、どうする）
リソース：未来も定義（どこで、だれが、なにを、なぜ）
イベントWhenとHow toで定義していって、残りがリソース
アンケートなら回答＝イベント、ほかがリソース
評価と評価理由は親子関係が見えてくる、
まず現実をモデリングして、ERすると必要なデータが見えてくる
リレーショナルモデルで定義してから、正規化する
正規化は、データの矛盾をなくしていくためにある
データに矛盾があるｰ>関数従属でない
そこをベースに考えると正しいモデリングができる
物理設計とはデータをシステムとしてどのように保存するか
インデックス5個もはるのは、テーブルの責務が多すぎる
よってモデリングに問題があるって判断できる
正規化だけで解決しない例
パフォーマンスの問題、アプリケーションの制約、システムアーキテクチャの制約
アクセス増えてきたらテーブル1つじゃ更新とかが多すぎてやばい
RoRとか、IDが必要とか
Cassandra、Redis、MySQLなど
そういう問題のためにRDBMSの機能の利用をする
制約でデータ担保、CHECK()を使う
CHECK()があれば正規化の数を減らせる
ボイスコット正規化とか第五正規化すればMySQLでも保存できる
特殊なINDEXを使う、式INDEXなど
拡張機能を利用する、DBlinkやFDWとか
こういう問題は、最初の設計時ではなく後から出てくる
初めからRDBMSの機能を使った設計をするのは奥の手を最初から使っている
今日ただしかったことが、来年は正しいとは限らない
常に正しさを問う、正しい設計は常に変化する
データベースの問題は忘れた頃にやってくる
サーバーの問題は休日にやってくる
アプリケーションの問題は納期前にやってくる
脆弱性の発見は連休中にやってくる
抽象化、モニタリング、テストコード、覚悟で戦う
スレーブに切り替えろっておもうけど、不思議とスレーブもおちる
技術的負債にはチーズと腐った牛乳がある
チーズは利益がでているプロダクトだったりする
スーパーテーブル作ってませんか？放たれる危険な香り
・行ごとに複数の状態を持っている
・値によって意味が変わる
・特定の列の値で、他の列の意味が変わる
・一つのテーブルが色んな用途で使われる
SQLアンチパターンはとにかく読んでくれ
テーブルのスコープを小さくするために状態ごとにテーブルを作る
データベース考古学：TABLE一覧を眺める会、Batchから紐解く
現在地とゴールまでの距離が測れるようになる、少しづつ改善する
問題を先送りするとより大きな問題を連れてくる
ALTER投げるのにどれぐらい時間がかかるのか
解決した問題の大きさがエンジニアの価値になる
覚悟を決めるには根拠が必要、根拠は技術で解決できる
RDBの知識は数冊の本をよめば十分つく
轍をふんでいくことで道になる、これが正しい道
技術で問題を解決していってほしい