サーバー
要求を受けて応答を返し続けるプログラム、およびそれが動く機械。
形態#
| 形態 | 管理する範囲 |
|---|---|
| 物理サーバ | ハードウェアから全部 |
| VPS / IaaS | OS から上 |
| PaaS | アプリケーションだけ |
| FaaS | 関数だけ |
| 静的ホスティング | ファイルを置くだけ |
このノートサイトは静的ホスティング。 ビルド済みの HTML を配るだけなので、 サーバ側で実行するものが無く、 攻撃面も運用コストも最小になる。
落ちる原因#
| 原因 | 対処 |
|---|---|
| メモリ不足 (OOM) | 上限設定、リーク調査 |
| ディスク満杯 | ログのローテーション、監視 |
| ファイル記述子の枯渇 | 上限引き上げ、リークの修正 |
| 依存先の障害 | タイムアウト、サーキットブレーカ |
| 想定外の負荷 | レート制限、自動拡張 |
ディスク満杯とログの肥大は、地味だが頻出。
冗長化#
| 手段 | 内容 |
|---|---|
| 複数台 + ロードバランサ | 1 台落ちても継続 |
| ヘルスチェック | 異常なら振り分けを外す |
| 複数の可用性ゾーン | データセンタ障害に備える |
| グレースフルシャットダウン | 処理中の要求を終えてから止める |
監視#
メトリクス … CPU、メモリ、レイテンシ、エラー率
ログ … 何が起きたか
アラート … 人を呼ぶ条件SLI / SLO — 何を測り、どの水準を目標とするか。 「可用性 99.9%」なら月に 43 分まで落ちてよい、 というエラーバジェットの考え方が 過剰な安定志向を防ぐ。
参考文献#
- Betsy Beyer et al. (eds.). Site Reliability Engineering. O’Reilly, 2016.(全文公開) https://sre.google/sre-book/table-of-contents/
- Martin Kleppmann. Designing Data-Intensive Applications. O’Reilly, 2017.