記事

• Things I Wished More Developers Knew About Databases | by Jaana Dogan | Medium
  • データストアに関するいろいろなトピック。各論が列挙されている感じだけどいい内容で面白かった
  • トランザクション分離レベルの話とか、分散システムでネットワークやタイムスタンプが信用ならない話とか、そういう データ志向アプリケーションデザイン で出てきそうなちょっと理論寄りの話から、トランザクションがネストしないようトランザクションを開始するレイヤーを決めておくとか、性能検証のコツとか、実運用の話まであり、筆者の高い力量が垣間見える
  • 面白かった
    • トランザクション分離レベルは SQL 標準で定義されている 4 つよりも更に細分化できるよという話
      • データ志向アプリケーションデザイン筆者の プロジェクト も登場していた
    • オートインクリメントな pk がベストではないケース
      • 分散環境にあるデータストアの場合 (分散システムでシーケンスを生成するのは大変)
      • パーティションアルゴリズムに pk を使うデータストアで、シーケンシャルなことで偏りが生まれる場合
      • シーケンシャルな番号以外で pk になりうるカラムがある場合 (計算の分が無駄になる)
    • 性能検証はシビアなワークロードでやったほうが良いという話
      • 例えば、50M 行あるテーブルに関連レコードを伴う INSERT、平均 500 人友達が居るグラフで友達の友達までを取得、500 フォローしているタイムラインの上位 100 レコードの取得、など

データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理

Martin Kleppmann (著), 斉藤 太郎 (監修), 玉川 竜司 (翻訳)

Amazon.co.jpで詳細を見る

• Internal Tech Emails on Twitter: “Mark Zuckerberg: “speed and strategy” February 14, 2008 https://t.co/zx6m54tWr6” / Twitter
  • Mark Zuckerberg が Fb 社内に送った、事業戦略を説明するメール
  • こんなに明快な説明はあんまり見たことなくて、素直にすごいと思った
  • 出どころは、Facebook と Six4Three という会社間の訴訟の際の証拠物件として提出された Fb 社内の内部文章らしい
    • Thousands of Facebook Internal Documents, Emails Made Public in Leak
      • こちらがその生の pdf (627 MB あるので注意)
      • 529 ページ目にある
  • 出処となった事件はアレだけど、このメール単体だとめちゃくちゃいい内容
• Google Testing Blog: How Much Testing is Enough?
  • テストどこまでやる？できてる？を考える上での分類、枠組み
  • とてもよい
• Data denormalization is broken | Hacker Noon
  • パフォーマンスのために非正規化する話から始まるが発展がすごい
  • 非正規化したカラムの更新方法として pure function 的に副作用なしに再計算するか、差分更新的に前の値を使って更新していくか
  • こうしたニーズを完全に満たすデータストアはまだない
    • 限定的なものなら materialized view が該当
• How Lowe’s leverages Google SRE practices | Google Cloud Blog
  • reducing toil の活動例として、1 番にアラートのトリアージを機械学習でやる、というのが出てきてびっくりした
    • いきなり高度な気がしたけど、そうでもないのかな。ちょっとした分類タスクを機械学習でやるクラはもう結構当たり前になってる？
  • Black Monday とかの対応の際に Google の CRE チームにコンサルしてもらうのは面白そう
    • GCP への寄稿なのでそこは割り引く必要はあるけど
• Implementing ChatOps into our Incident Management Procedure — Infrastructure
  • Shopify の slack にある障害対応チャンネルのスクショがのっている。だいたい 400 人強のユーザーが入ったいた。
    • 2018 年の記事だけど、プロダクトに関わる人が大体このくらい居たと言える
  • その規模でこのくらいの作業プロセスの標準化、明文化がされているというイメージができた
  • どういうタイミングで誰にどうコミュニケーションとるかは障害対応時に大事だけど、それは確かに俗人的な知識になりうるし、この規模だとそこを標準化、自動化してもペイするんだな。とか
• The MTTR that matters | FireHydrant
  • MTTR (Mean time to recover) だと、障害の状況に応じて分散が大きすぎて意味のある数値になりづらい
  • 発生から検知までの時間とか、解決から振り返り実施までの時間とかを測った方がよい
• Toward Vagrant 3.0
  • vagrant を ruby から go にポートするらしい
  • しかも後方互換性を保ちながらアーキテクチャもクライアントサーバ型に変える
  • 大変だろうけど楽しみ
• Nat Friedman on Twitter: “GitHub processes 2.8 billion API requests per day, peaking at 55k rps. Lots of busy bots. 🤖” / Twitter
  • GitHub のピーク時 api トラフィックは 55k rps
  • Rails, memcached, & MySQL running on Kubernetes and served via haproxy and GLB という構成
  • これとは別に同規模の git オペレーションもある
  • 参考値としてなんかで使えそう