記事
- Two reasons Kubernetes is so complex • Buttondown
- k8s が難しい・学習コストが高い理由の考察
- 二点あげられている。まずは分散システムの OS 的な役割を担うようデザインされているから
- リソースを管理しハードウェアを抽象化して提供するといった特性が OS と似ている
- 様々なバリエーションを抽象化しているので必然的に複雑になる
- = 解こうとしている課題自体が複雑
- 宣言的な記法とコントロールループというデザインのため
- 分散システムは部分的な障害が日常茶飯事なので、常に目的の状態に変更する作業が発生する
- 宣言的でない・コントロールループが無いオーケストレーションツールの場合、結局誰かがコントロールループの役割をする (例えば人間が)
- k8s は最初からこれがフレームワークのデザインに組み込まれている
- そうすると、正常時はとてもシンプルだけど、そうでないときに難しさがでてくる
- なぜ目的の状態にならなかったのかのデバッグが難しい
- リソースを追加・変更したタイミングでなく、実際にそれに対するオペレーションを行うときまでエラーが出ないのでデバッグが難しい
- 内容そのものもそうだけど、こうやってソフトウェアの設計思想・意図を整理するのは、適切に使用するために大事
- Designing Uber - High Scalability -
- designing シリーズの uber 編
- driver 情報のインデックス、最短経路問題、gps 情報と実際の位置のズレの補正など、計算機科学的なトピックが多くて面白かった
- Roblox Return to Service 10⁄28-10⁄31 2021 - Roblox Blog
- 同僚に教えてもらった記事
- 昨年の9月に Roblox が 72 時間の障害に見舞われた際の障害報告
- 初期対応の部分が身につまされた。Consul クラスタを全台二倍にスケールアップしたり、リクエスト数を削減しても問題が解消しなかった。その状況を想像すると胃が痛くなる
- 込み入った root cause なのにちゃんと特定できてこれだけ詳細なレポートを上げられるのはすごい
- あとオンプレで構築しているのは意外だった
- WHOIS: Fragile, unparseable, obsolete... and universally relied upon
- whois は標準化されておらず実装も多岐にわたりだいぶ厳しい
- 確かに whois コマンドのレスポンスの読み方は今までずっとよくわかっていなかった
- 別のプロトコルに移行して改善する試み自体はあるらしい
