ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

データ指向アプリケーションデザイン読書メモ：1章

今日16時から社内勉強会やるよー！

普通に書いてる分は運用で、（chaspy）がお気もち

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

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

信頼性、スケーラビリティ、メンテナンス性に優れたアプリケーション

  • 多くのアプリケーションは演算指向ではなくデータ指向
    • CPUの演算能力より、データをどう扱うか、がボトルネックになりやすいことを示す
      • データ量
      • データが変化する速度
  • 本章ではデータシステムで以下の課題をどのように解決するかを考える
    1. 信頼性
    2. スケーラビリティ
    3. メンテナンス性

信頼性

  • 何か問題が生じたとしても正しく動作し続けること
  • 問題を起こしうるものをfaultと呼ぶ
  • faultによって、システム全体がユーザにサービスを提供できていないことを障害（failure?）と呼ぶ
  • 障害には大きく以下の3つに分けられる
    1. ハードウェア障害
    2. ハードウェア障害は常に起きる
    3. 通常RAIDなど冗長化していて、fault traranceを持つ
    4. 仮想マシンというレイヤーで考えても、AWS EC2インスタンスが使用できなくなることもある（chaspy）
      • メンテナンスのため再起動が走ったりもする（chaspy）
      • クラウドを使う上でも、落ちてもいいように設計すべき（chaspy）
    5. ソフトウェア障害
    6. システム内でのシステマチックなエラー
      • ソフトウェアのバグ、特定の入力があるとクラッシュする、など
      • プロセスの暴走によってリソースを使い切る
      • 依存するサービスの問題
      • カスケード障害
    7. 解決策は？->ちょっとした積み重ね
      • 徹底したテスト
      • プロセスの分離
      • プロセスのクラッシュと再起動の許容
      • 計測
      • モニタリング
      • プロダクション環境におけるシステムの挙動分析
    8. このあたりはReadiness Check / 負荷テストでサービスインのときに把握できるようにしたい（chaspy）
    9. ヒューマンエラー
    10. 人間には信頼性がない
    11. 人間はスケールしない（chaspy）
    12. ではどうするか？複数のアプローチを組み合わせる
      • インターフェースによって正しいことを行いやすく、間違ったことを行いづらくする
      • サンドボックス環境をプロダクションと分離して提供して経験を積む
      • すべてのレベルで徹底的テストを行う
      • 設定のロールバックを即座にできるようにする
        • これは1番大事だとQuipper SREに入って学んだ
      • 詳細で明確なモニタリングの仕組みをセットアップする
      • 優れた管理方法とトレーニングを実践する
  • 信頼性の重要度
    • これ最近考えているテーマだった。何かしらで重要度をつけてRediness Checkを軽くしたりできないかなあと（chaspy）
      • SLOを低く、あるいは設定しない、というふうにするのも一案かなあと思うが悩む（chaspy）
    • アプリケーションが「クリティカルではない」ものであったとしてもユーザに対する責任は発生します
    • 信頼性を犠牲にすることで、開発コストを下げたり、運用コストを下げたりする場合もあるが、その場合信頼性を犠牲にしていることを強く意識しておくべき

スケーラビリティ

  • 負荷の増大に対してシステムが対応できる能力
  • どのようにコンピュートリソースを追加すれば負荷に対応できるか？
  • Twitterの事例
    • ホームタイムラインの取得の際の負荷の問題
      • 読み取り時の処理を少なくし、書き込み時の処理を多くした（書き込み頻度のほうが2桁小さいので）
    • また、極めて大量のフォロワーを持つユーザは最初のアプローチをとり、ハイブリッド型とした
  • パフォーマンスの表現
    • スループット
    • レスポンスタイム
      • 通常外れ値があるので、mean(50 percentile)、95 percentile, 99 percentileを使う
      • 99 percentileはテイルレイテンシ、ユーザ体験に影響していることが多い
        • Amazonの例では99.9 percentileを指標にしている
        • 1/1000しか影響しないが、そのユーザは大量に購入しており重要な顧客である可能性が高い
        • この考えは自分にはなかった、遅いから気にしなくていいと思ってた（chaspy）
        • レスポンスタイムと売上の相関が見れると良いな、うちでいうとどうだろう？学習継続率とか？（chaspy）
  • 負荷への対処のアプローチ
    • 負荷が10倍になったとき、アーキテクチャを再考する必要があるだろう
    • スケールアップとスケールアウトがある
      • 実際、直近はMongoDBをスケールアップした（chaspy）
      • MongoDB自体はスケールアウトの仕組みを持っているが、複雑度が増すため見送っている（chaspy）

メンテナンス性

  • 3つの設計原理
    • 運用性
      • 運用者が扱いやすいものにする
      • 個人の出入りがあっても、システムに関する組織の知識が保たれるようにする
        • 大事だと思う（chaspy）
      • デフォルトの挙動を優れたものにする
      • 総じてドキュメンテーション、自動化、コード化がこれらを支えると思う（chaspy）
    • 単純性
      • 偶発的な複雑さを取り除くこと
      • 優れた抽象化をする
    • 進化性
      • アジリティのこと
      • 運用性、進化性に大きく依存する

まとめ

  • ソフトウェア・システムには機能的な要求、非機能的な要求があり、後者のうち信頼性、スケーラビリティ、メンテナンス性を取り上げた
  • これらを簡単に高める方法はないが、くり返し現れるパターンやテクニックは存在する
  • 今後の章でデータシステムがこれらの目標にどのように向かっていくのか考察する

感想

  • SREとして働く上でもっとも重要な3つの概念を改めて言語化、整理されていて非常に良かった
  • SLOを定める上でパフォーマンスの表現の章が密接に関わる。レイテンシは複数のパーセンタイルで分析したいと思う。
  • スケーラビリティ、メンテナンス性はReadiness Checkでのアーキテクチャレビューで担保できるようにしたい。現状アーキテクチャレビュー、事後の説明になってしまっていてあまり効果的に働いていないので
  • メンテナンス性に関しては経験を持った個人に依存している部分も多くあると思っており、課題を感じている。ドキュメンテーション、コード化のいいバランスを考えたい。（すべてをドキュメント化すべきだとはもちろん思っていない）

勉強会終わったあと追記します。