論文メモ On Designing and Deploying Internet-Scale Services

November 20, 2020

MSNとWindows Liveで培われたシステム管理者による運用負担を減らすためのベストプラクティス集。 07年に発表された。プラクティス集は、10のグループに分かれ、それぞれ複数のアドバイスからなる。特徴的な内容に絞って以下に要約する。

Overrall Application Design

Commodity hardware slice

コモディディ化されたハードウェアを採用する。高価でハイパフォーマンスな少数のハードウェアにシステムをのせるより、安くて大量のハードウェアを使うほうが安くすむ。サーバの処理性能はディスクの性能よりも向上するスピードが速く、また、電力消費量はサーバ台数と比べて線形だがクロック数に対しては3乗の関係にある。また、サーバの台数が少ないと、そのサーバが落ちたときの影響が大きくなる。

One pod or cluster should not affect another pod or cluster

ポッド同士の独立性を高め、ポッド同士が影響して生じる障害をなくす。

Allow (rare) emergency human intervention

まれな障害には管理者による直接の対応を許容する。ただし、ミスのないよう対処方法を文書化するのではなく、スクリプトのような自動化された手段を用意し、それが機能することをあらかじめテストしておく。

Automatic Managenment and Provisioning

Treat operations utilities as part of the service

運用のためのツールをサービスのコードと同等にあつかうこと。コードレビュー、版管理、テストを実施すること。ツールがテストされていないことは多い。

Multi-system failures are common

多数のホストが同時に障害をおこすことを想定しておく。例えば、電力やスイッチの障害は、これらに依存する全てのホストに影響する。

Dependency Management

Expect latency

外部のコンポートネントへのアクセスには、タイムアウトを設定する。また、タイムアウト時の再処理も設定しておく。再処理の実行を記録し、また上限を設定しておく。

Release Cycle and Testing

ステージング環境と本番環境には差異があるため、リリース前最後のテストとして、カナリアリリースを実施する。また、人がすくなく、間違いも起きやすいため、深夜のリリースを避けて日中にリリースする。

Operations and Capacity Planning

リカバリのためのスクリプトは、本番環境でテストしておく。テストできる自信がないものは、障害時には役にたたない。

Soft delete only

物理削除をさけて論理削除にし、データを復元できる手段を確保する。

Auditing, Monitoring and Alerting

開発者が大事な通知を無視しないように、あらゆるイベントを開発者に通知するのではなく、障害のみを通知するように設定する。

Latencies are toughest problem

IOなどのレイテンシの検知は難しいので、注意して検知の仕組みを実装すること。

Track all fault tolerance mechanisms

フォールトトレランスが小さな障害を隠蔽しないようにする。フォールトトレランスで抑制した障害を検知する仕組みを用意する。

論文をこちらからダウンロードできます。