YAPC::Hakodate
前夜祭
データロスト
業務
困る
個人でも
困る
GitLab
5つのバックアップを取ってたが、役立たずに、結果たまたま取ってたスナップショットに救われる。
バックアップを取ろう。
データサイズはデカくなってきた。
方針によりメリットデメリットがある。
設計が大事
バックアップの目的決め
災害復旧
法規制への対応
目標復旧時点
障害からどれぐらい前のものまでを復旧できるか？
デイリースナップショットなら1日は最大で失われる。
目標復旧時間
どれぐらいで回復完了できるか
リストアテストの方針決め
本当に復旧できる？
リストアテスト
フルリカバリテスト
シミュレーションテスト
セキュリティ
データの暗号化
アクセス制御
バックアップデータの保管ポリシー
実際方法
決まった時間にフルバックアップするだけなら簡単
100TBとかなら大変
他の手段が必要になるなも
フル
差分
前日からの差分
増分バックアップ
ベースの日から増えた分
差分バックアップはベースからのn回のリプレイがいる。
増分バックアップはベースからのdiffを1回積むだけ。
ホットバックアップ
コールドバックアップ
バックアップの実践
rsyncはブロック単位のコピーなので、更新中のファイルを触ると壊れる。 rsyncが舐めるとページキャッシュに乗ってしまってキャッシュが無茶苦茶になる。
データベース
RPOが重要になっていく。
フルバックアップ+トランザクションログで任意のトランザクション時点にリプレイできる
フルバックアップ
コールド、ホットバックアップができる
デ庁が整備する、政府全体が共同利用するクラウドサービス基盤 既存の「パブリッククラウド」を活かす。
柔軟/迅速に調達できる。
セキュア
一括調達によるメリット
コストメリット、可視化、評価
ベストプラクティスの共有で品質よくする。
運用の省力化
標準化できてないことによりコロナ対策、給付金とかで課題が見えた。
標準化/モダン化の両輪で進める
歴史/背景
ガバメントクラウド登録CSP
AWS
Azure
Google Cloud
Oracle Cloud
さくらのクラウド
要件
さくらインターネットの参入の意義
国産クラウド
経済安全保証
サプライチェーンの強化
データ主権
デジタル貿易赤字の解消
ミクロには、サービス水準ブランディグ等……
ガバメントクラウドの開発
〜2023/11
15人程度
あらゆる機能を見ないといけないので、これを15人……
WebアプリケーションをLambda化する
実行時だけ課金なのでリクエストが来ない時は無料
Slack Webhookとか……
急な負荷増加に対応しやすい
勝手にスケールアウトされる。
LambdaをHTTPから呼ぶ
API Gateway
ALB
固定費かかる。
Lambda Function URLs
最新に出たやつ。最高
既存のアプリケーションをLambda化する。
eventをHTTP reqに変えるだけなのでなんとでもなる。
なんらかのmidddlewareがあるでしょう。
goのnet/httpのingerfaceをそのまま使える。
他の環境とコードを変えずに使えるので良い。
lambda web adapter
lambdaのeventを受けて、http requestを投げてくれるproxy
ECS → Lambdaに移行してコスト大削減！
アプリケーションコードの変更は不要だった。
周辺環境の変更だけでなんとかなった。
Fluentd
lambdaはレスポンスを返すと実行が止まるので、ログがバッファリングされるようなものだと使えない。
サイドカーにまかせる
移行手順
internal ALBのtargetにECSだけたったところにLambdaを追加
荷重ルーティングで徐々に移行
複数開発環境 / サービスメッシュ
ブランチdeployほしい
ECSではacidlemon/mirage-ecsが使われていた
lambdaでももちろん欲しい。
aliasのinvokeのふりわけをいい感じにする
なんで？
時間がないので後で資料を見てください状態
まとめ
既存のアプリケーションをlambdaにするのは難しくない。
向かないようなの
IO heavy
リクエストの増減が少ない
低レイテンシが要求されるようなもの
本編
カーネルモジュールと何が違う？
Verifieirでミスを事前に防げる
後方互換性
カーネル内は互換性がどんどん壊されるが、eBPFはAPI interfaceが守られる。
できることが増えるわけではないが、カーネル開発へのアクセスがよくなる。
upstreamとやりとりしなくてもいい。
歴史 cBPF
tcpdumpとかでも利用されてる。
eBPF Verifieir
osyoyu
ソフトウェア産業のもっとも偉大な功績は、ハードウェア産業のなしとげる着実な功績を打ち消し続けること。
フレームグラフは便利だが、細切れに何度も呼ばれてるのとかは適当に見てると見逃すかも。
「推測するな、計測せよ」
当てずっぽうでの改善をするな。
当てずっぽうの改善は無意味だが、当てずっぽうの計測にも意味がない。
自分が医者だとして、咳をしてる人に100m走してもらってもあんまり意味がない。
計測するだけで原因が得られるとは全く限らない。
呪術式パフォーマンスチューニング
計測を使った仮説検証をくりかえすことが理想。
実は別の計測が必要だったか？ とか
計測の使いどころ
問題があった時、初期の状況把握
計測サイクルのなかで、検証するため
計測
「何を」「どのように」「どう評価」
https://gyazo.com/b7052caac29a0a704c9b29e2b9b69471
図
計測すべきは状況の中で変わっていく
存在する知らないことは調べられない。
例: 二次元配列の舐める方向とか、CPUキャッシュのことを知らないと発見はできもどうやって改善すればいいのかはわからない。
広範な知識がないと解決できない。
答えはいつも予想外のところにある。
どうやって測るか？
どうやって測定そのものは実装されてるか？
時間を測るのはむずかしい。
ユーザランドでは測れないものもある。
割り込みできないとタイマーが無理とかもある。
時間ではなく、メモリは？
どういうオブジェクトが大い？
RubyとかならVMで記録できるかも
そうでないならmallocにしこむかも
メモリレイテンシは？
アプリでは取れない。
CPUはパフォーマンスカウンタを備えてる。
一般に、レイヤを降りないと観察はできない。
「いつ」計測するか。
問題があることがここまでは前提だった。
しかし普段から問題があるか？
計測ツール、プロフィラはこれを教えてくれない。
「遅い気がするから測る」はできるけど、「遅いから測ったほうがいいよ」とは教えてくれない。
「いつ計測するか」を主観に依存させない。
システムの重要なパフォーマンスを事前に定義するのが大事？
「ベンチマーカのスコアを上げないといけない」みたいなもの
目標の例
ワークロードの性質から: 決済までの到達率
CPU使用率がn%以下
「レスポンスタイムのp90が100msを越えると異常」みたいなのを決めているとよい。
New RelicやDatadogなどは、「常に」計測してるのが最大の価値
まとめ
パフォーマンス改善は正しい視点を探すこと
ひとつのことを知ってるだけではいけない。
webセキュリティ
cookieが送られるかどうか、portが異なってても送られるの知らなかった……(originが一致してないと送られないと思っていた)。
メモ: 一部の <cookie-name> は特殊な意味を持ちます。
__Secure- の接頭辞: __Secure- (接頭辞にダッシュを含む) で始まるクッキー名は、 secure フラグを設定することが必要で、安全なページ (HTTPS) でなければなりません。
__Host- の接頭辞: __Host- で始まるクッキー名は、 secure フラグを設定し、安全なページ (HTTPS) から読み込む必要があり、ドメインを指定することができず (従って、サブドメインにも送られません)、パスが / である必要があります。
Safariがとにかく揺れてる実装をしてる。
Resource Isolation Policy
same-siteはsame-originではない！
<script>tagはjsonの文字列中でも終了できる ← マジか
code:hoge.html
<!DOCTYPE html>
<html>
<head>
<title>Home</title>
<script>
var str = "hello </script><script>alert(origin)</script>";
console.log(str);
</script>
</head>
</html>
vscodeは気付いてUnterminated string literal. javascriptって怒ってくれる。
文字列埋め込みをscript tag経由でbackendが返す とかだと、self-XSS可能に。
Trusted Types
そもそもsinkには安全な型しか入れられないように
パストラバーサル
Pythonのurljoin、pathに//example.comみたいなのを渡すと、originから変わるらしくて勢いがある。
クラウドストレージのpath
key
.や..を含めると、そのままになる！ ← マジか(そんなことしようと思ったことがなかった)