昨日の記事の続き。2日目について書きます。
帰国してからきちんとまとめようと思ってもだらだら遅れる気がするので、昨日とは違って現時点でのメモをどばっと吐き出したいと思います。
Reliable by Design: Adding Value in the Design Review Process
システムアーキテクチャ・ソフトウェアのデザインにおいては、後々後悔する意思決定があるので、きちんとデザインドキュメントを書き、レビューをしようということで、チェックリスト形式でレビューすべき点を紹介したセッション。
Who, what, why(誰が、何を、なぜ）
- ゴールは何か？ 必要な人がレビューをしているか
- プライバシー・セキュリティ・悪影響を与えるシステムはないか
Alternatives Considered(他の選択肢)
- 他の選択肢を十分検討したか？
Stickiness
- システムの中でどの部分が今後変化する可能性があるか？逆に変化しないところはどこか。
- アーキテクチャがデータモデルに織り込まれているか？
Data
- データの一貫性が求められるのはどこか、アーキテクチャがそれを反映ししているか
- 他のデータによって変更されるもの、そうではないものはどれか
- データのSLO, 保持期間, 暗号化, レプリケーション, シャーディング, バックアップ, アクセス制限, GDPR等プライバシーへの対応
Complexity
- それぞれのシステムコンポーネントは役割が明確か。数を減らすことはできないか。似たものがないか。新しい依存関係を生んでいないか。
Scale and Performance
Operability
- 監視がやりやすいデザインか（やりづらいデザインもある）。
- サードパーティのツールで監視できないか。
- オペレータにとってわかりやすい・使いやすいツールか
- ルーチンワークはToilになる。誰がやるのか。自動化してしまうことでオペレーティングチームのシステム理解度が下がることもある。
- Abusiveなリクエスト・ユーザーへの対応を決めておく
- 外部ベンダーはこちらの機能リクエスト・問題に対応してくれるか
Robustness
- 物理的故障が起きたときにどう対処するか
- ネットワーク分断・レイテンシの上昇にどう対応できるか
- 復旧のために必要な手動のオペレーションは何か
- システムをオペレータ自身が壊してしまうことができるか。一般ユーザーからそのパスが切り離されているか
- 分割可能な単位は何か。依存関係は何か。Gracefulに縮退させられるか
- ゼロから再起動できるか。どれくらいの時間がかかるか。その際システムの依存関係がないか。DNSと監視の考慮も忘れないこと。
- ロードのスパイクに対応できるか
- キャッシュは使っているか。キャッシュを使わなくてもさばけるか
- Control PlaneとData Planeは分離されているか
- Canaryデザインについて。システムに負荷をかけないか。
- システムが自らに負荷をかけてしまうような悪循環に陥るポイントはないか。
Edge Computing: The Next Frontier for Distributed Systems
Fastlyの人が、といっても会社とは直接関係ないトークだ、とことわったうえで、Edge Computingの基本と今後の可能性について述べたセッション。
エッジコンピューティングとはオリジンサーバーでレスポンスを作って返すのではなく、もっとユーザーに近いロケーションにあるシステムによってレスポンスを作って返すことをいう（少なくともこのセッションでの定義）
ユーザーに近いといってもどこか。いくつかポイントがある (↓上から下に行くに従ってユーザーに近くなる)
次のリクエストが異なる○○によって処理されることを想定したシステムが必要。
下記のような考慮が必要
- リクエストの標準化
- 認証でやるのか、Paywallでやるのか（このPaywallという文脈がわからなかった。課金ユーザーのみ許可するアクセス制限とかそういうイメージかと）
- ユーザーエージェントによって異なる処理
- ローカライズ
A/Bテスト
Fastlyが提唱している WASI というフォーマットについて紹介
データのReadだけエッジでやって、Writeは中央(Origin)でやるのか、それともReadもWriteもエッジでやるのか
デプロイはどうするか、設定の変更はどうやるか、ファンクショナルテストや負荷テストはどうするか
TCP—Architecture, Enhancements, and Tuning
TCPの基本からチューニング、さらにはQUICまで、内部実装を紹介しながら今後の進化について述べたセッション。
このへんは部分的には理解しているが、体系立てて説明できるかというとできなかった分野で勉強になった。再度復習したい。
- OSI参照モデルの説明(L1~L7まで)
その中で、L4レイヤー、つまりTransport Layer(TCPの部分)の深掘り
Transport Layerの課題と必要な要件について
- 順序が保証されていること
- ステートフルであること
- 帯域のコントロール
- Multiplexing多重化
TCPのコアコンセプト
- Sequence番号を持つ
- コネクションを張る
- Window Sizeを持つ
- Port番号を使う
- Ackをする
TCP Headerの中身の説明
- Window Size
Retransmission 再送処理の説明
- Syn, Ack, Retransmission Timer
TCPの拡張
- スロースタート
- Congestion Avoidance(混み合うことを防ぐ機構)
- Fast Retransmission（早い再送処理）の仕組み. Recv側から再送リクエスト
TCPのチューニング
- Bandwidth delay product(帯域遅延積と訳せるらしい、ちゃんと理解できていない)
- Bufferのチューニング, Selective Ack, MTU Probing
- Initial Congestion Window
initcwndを増やすことでラウンドトリップを減らす
Congestion Controlのアルゴリズム
QUICの紹介
SCTPについて
BGP—The Backbone of the Internet
BGPの紹介。歴史、実装、プロトコル、実際の例をあげての説明。
自分が特に弱い分野で意味のあるメモを以下に書ける気がしないのでセッションの結論だけ。
- BGPはインターネットのメッセージバスである
- よくスケールするが、全部を網羅することはできない
- 実装が複雑なので、全部を理解するのは困難
Linux Memory Management at Scale: under the Hood
Linuxのメモリ管理についてのセッション。
- Cgroupの説明
- メモリとIOとの関係
SWAPは誤解されている。「SWAPは緊急時のメモリ」ではない
- In defence of swap: common misconceptions これ自分の中で消化できてない。あとで読んで理解する
メモリのReclaimの種類
- kswapd
- direct reclaim
Reclaimできないときに、SWAPはそれを助けてくれる機能。(ちょっとこのへん怪しい)
メモリ周りのツールの紹介
fbtax2の紹介 fbtax2: Putting it All Together · cgroup2
- このへんも自分の中で消化できてない。とりあえずメモのみ
- 優先度に基づいてプロセスをグループ化してメモリの使い方をコントロールする、そこまではcgroupと同じ。それの進化系
下記の画像はfbtax2を使った際にメモリの利用が改善された例の紹介
Ad Hoc SSH Access Using Signed Tokens
SSHアクセスを、従来の公開鍵を接続先のサーバーに置く必要なしに、CAとx.509を用いて必要なときに一定時間だけ必要なサーバーにSSHアクセスを許可する仕組みの説明。OSSではない模様
下記の画像が端的になんたるかを表しているので詳細は割愛
Software Networking and Interfaces on Linux
ネットワークの基本から、インタフェース、ブリッジ、最新のトレンドまでを紹介するセッション。
EthernetやARPの紹介から始まり、vLanやIptable、NATやRouteテーブルの紹介などまでは良かったが、tun/tapが出てきたあたりからついていけなくなり、virtio_net, veth, ipvlan, macvlan, calicoなどまで説明して後半はふむふむと聞いてるだけ。完全に打ちのめされた。このへん理解が浅すぎて勉強しないと...
- インタフェースまとめ
- Loopback
- Dummy
- "real"
- multiple L3 addresses
- TAP/TUN
- vEth
- VLAN
- Macvlan, macvtap
- Ipvlan, ipvtap L2
- Ipvlan, ipvtap L3
↑この辺あとで調べ直す。
セッション動画は下記に上がってます。
Automating OS/Platform Upgrades for Service Owners
Pinterestでの実例から、SpinnakerのCanary機能を用いてOSやプラットフォームごとアップグレードする事例の紹介。
アップグレード前後で比較すべきキーとなるメトリクスを用いて、Canary機能を使って試験的に一定時間デプロイしてメトリクスを収集して、アップグレードをそのまま全デプロイしてよいかを判断する。意思決定フローの都合もあって手動承認する部分を残している。
仕組みとしては分かる。だけどこれを実際にやるのは大変なはずで、これを仕組みとして回しているというのはとても励みになる。
Unified Reporting of Service Reliability
GCPの中の人による、GCPの障害やユーザーサポートの情報を集約するダッシュボードのアーキテクチャの紹介と、それをどう運用しているかの事例の紹介。
前半はデータをどう集約してダッシュボードを作っているかという話で、Entity RelationshipとStar Schemaに基づいたデータモデルを作っているということで、DWHとしては正攻法なやり方をしていると思った。そこからSQLを多段でごにょごにょしてダッシュボードとして提供している。
後半は、そのデータから得たインサイトをどうアクションにつなげえているかという話で、下記の話が一番印象に残った。
SLI/SLOは、Customer Happinessと連動しているのか？相関を調べて、ミスマッチであれば、SLI/SLOを修正する。
Monitoring/Alertのタイミングより先にユーザーからのIncidentレポートが上がっていないか？ そうであれば、Monitoring/Alertのほうを修正する。
全体的に熱量がある話で、こうしたDWHとそこからインサイト、アクションへとつなげるというのはハードルがいろいろあるが、「標準化せよ」「自動化せよ」「ビジョンを持って最初のやり方がうまく行かなくても失望せず続けよ」と締められていて、後味が良かった。
2日目は以上です。
なお、下記のブログ記事にも2日目の様子は詳しく紹介されています。
