イントロダクション from DDIA
Chapter 1. Reliable, Scalable, and Maintainable Applications
本書内で使われる語の定義、問題意識の説明
本書では3つの要素で問題を見ていく
Reliability
「逆境」に直面しても「正しい」パフォーマンスが実現されること
正しさとは設定された指標であり、すると設定の問題が出てくる
逆境とはハードとソフトの問題だけではなく、ヒューマンエラーに対する耐性も考慮する
Scalability
システムがデータやトラフィック、問題の複雑度に対して人間の理解できる方法でスケールすること
Maintainability
多くの開発者と運用者が同時に関わり、新機能追加と既存機能のメンテナンスを平行に行い続けられること
加えてそれらがより効率的であること
Reliability
停止には単位があることに留意せよ
faultsは小さな失敗やエラーのこと
failureはあるシステム全体が停止してしまう現象
avashe.icon日本語では障害かな
fault-tolerantなシステムではfaultsは増加する
faultsのハンドリングは更なるfaultsを呼び込むため
faultsの耐性度合いを見るには実際にfaultsを再現することである
ヒューマンエラーを防ぐのもReliabilityの重要なポイントである
ソフトウェアエラーに比べ、人間の設定ミスは頻度そのものは少ないが、それがサービスのfailureに繋がる割合が最も大きい
運用者のオペレーションを検証する仕組みは後回しにされるか、全く検証されないのどちらかのため、致命的になりがち
一つの対策として抽象化の層を挟むこと(それこそk8sのような)が挙げられる
一方で痒いところに手が届かなくなった瞬間膨大なブラックボックスの理解を求められるリスクがある
この解決策だとバランス感覚という話になってしまう
検証環境を用意し、そこでレビューを行う
自動化されきってはいないが、これが正攻法なイメージ
反映された設定のモニタリングと、ロールバックの仕組みを用意する
Scalability
この技術はスケールするみたいな議論は無意味
あるシステムアーキテクチャにおいて特定の要素が増大するとき、対応する我々にどんな選択肢が残されているか?
負荷の解消方法として、そのシステムにどのように計算資源を加えることができるか?
システムのアーキテクチャを分析すれば、負荷を幾つかのパラメータでモデル化できる
これをロードパラメータと呼ぶ
webサーバなら秒間リクエスト数、DBならR/Wの比率、チャットツールならアクティブユーザの数etc
twitterの実例では、ユーザごとのフォロワー数(に個々のツイート頻度を加味したもの)の分散が主なロードパラメータだった フォロワー数が膨大な世界的有名人もいれば、ほぼ身内オンリーな人もいて、一方に対応するともう一方がおざなりになる
twitterでは2つの手法を混ぜることになる(省略)
パフォーマンスを測る作法
パフォーマンスを語る際はちゃんとパーセンタイルを使おう
分布に強い指標を使うべきである
例えば中央値は50th percentileだが、p50と略すこともあるらしい
avashe.icon英語圏だとページの単数形、複数形がそれぞれp. 50, pp. 50と略されるから被らない
%ileという表記もあり、私はこっちのが好き
amazonではtail latencyを重視している
問題が遅延(latency)なのか応答時間(responce time)なのかを認識しよう
遅延は処理が実行され、完了するまでの実時間
応答時間はクライアントから見た見かけの時間
avashe.icon e2eな遅延は応答時間だろと言われると言い返せないが、遅延は運用側にとって観測できるという意味が込められてると思う
それぞれ解決方法が異なる
tail latencyが大きい場合システム全体のパフォーマンスを落とすことがある
avashe.icon例えばMapReduceのようなマルチノードによる並列処理系では、ボトルネックはノードが結果を返すまでのtail latencyに依存していることがわかる これが複雑な分散システムになると、ほとんどのコンポーネントが高速であってもあるコンポーネントが謎の遅延を起こすことで全体が許容できない応答時間になりうるということ
そういった現象をtail latency amplificationと呼ぶ
負荷へのアプローチ
現実的で良いシステムはスケールアップとスケールアウトを上手く組み合わせている
すぐ大量の小さなvm群に思いを馳せず、数台の高級マシンで殴る方が手っ取り早いということも頭に入れておこう
負荷のピークが予測しづらいシステムでは必須になってくる
avashe.icon data-intensiveだとストレージが高く付くからメインはオンプレだけど、予期されるピーク時の緊急回避機能として瞬間的にIasSを購入して水平分散する手法も知られている
Maintainability
Operability(運用性)
よいOperabilityとは、オペレーションの自動化がしやすいことを指す
多くのオペレーションはシステムの成熟に伴い自動化されていくべきだが、始めの自動化作業とその動作の保証は依然人間の努力を要する領域である
「良いオペレーションは悪いソフトウェアの制約を回避するものだが、良いソフトウェアはそもそも悪いオペレーションを実行させないものだ」
Simplicity(単純性)
Accidental(非本質的な)複雑性を排除せよ
解決すべき問題に内在する複雑性以外の、実装に由来する複雑性のこと
本書ではこれを維持するための良い抽象化について見ていく
システムは自身の変化を許容し続けなければならない
あなたがより良い方法を思いついたから、予期せぬユースケースが現れたから、ビジネス要件が変わったから、ユーザからの要望が高まったから、プラットフォームを置き換える必要があるから、法や条例が変わったから、システムの成長にアーキテクチャが耐えられなくなったからなどなどなど...
本書ではシステムという長期的なレベルにて、変化の速度を上げる方法を模索する
変化に強い開発手法としてアジャイル(Agile)が知られているが、これは非常に短期的なレベルの話である 例えば、本書で取り上げられているtwitterのアーキテクチャ変更事例をどう乗り切るか?という話
本書ではシステムレベルのアジリティを区別して、Evolvabilityと呼ぶ
avashe.iconこの主張があるからこの本を読もうと思った
現代のソフトウェアエンジニアリングにおける最重要課題なんじゃないかとさえ思っている