インフラ設計

アプリは両AZで動かし、DBはプライマリとスタンバイを別AZに置く。AZ障害時はALBが残った側へ振り分け、DBはスタンバイにフェイルオーバーする。

ロードバランサー（LB）は、利用者からは1つの窓口に見せながら、後ろの複数のサーバーにリクエストを振り分けます。定期的なヘルスチェックで応答しないサーバーを自動で外し、戻れば再び入れます。AWSでは、HTTPの中身を見て振り分けるALB（L7）、TCP・UDPを高速に転送するNLB（L4）、FWなどの機器に通信を通すGWLBがあります。

サービスの入口に立つので、設定の誤りがそのまま利用者に見える障害になります。デプロイのたびに数秒だけ 502 が出る、1台だけ負荷が高い、ヘルスチェックの失敗で全台が外れる、といった症状の多くは、下の表の設定で説明できます。

デプロイ時の502は、登録解除の遅延とKeep-Aliveの設定を最初に疑う。

下の「ブラウザで試す」の図では、ラウンドロビンでサーバー1・2に順番に振り分ける様子から始まり、ヘルスチェック（/health）がタイムアウトしてしきい値の回数だけ続けて失敗したサーバーが自動で外され、復旧すると戻るまでを順に見られます。1台が外れたあと、残りのサーバーで全量を受け止められるか（N+1 の余力）に注目してください。

直列につながる依存先が増えるほど全体の可用性は下がる。外部SaaSへの依存も同じ計算に入る。

実際の障害の多くは「変更」が原因になる。デプロイや設定変更を安全にする仕組みは、ハードウェアの冗長化と同じくらい重要。

オートスケールの注意点：起動に時間がかかる、DBなど下流がボトルネックになる、スケールインで処理中の接続を切らない。

第12章「パフォーマンスチューニング」：負荷試験とキャパシティ計画を図で詳しく

DR（Disaster Recovery、災害対策）は、データセンターやクラウドのリージョンがまるごと使えなくなるような大きな障害から、サービスを立て直すための備えです。ふだんの冗長化（複数台・複数AZ）では防げない規模の障害を想定します。

方式は、待機側にどこまで準備しておくかで分かれます。待機側をふだんから動かしておくほど早く復旧できますが、そのぶん費用がかかります。どれを選ぶかは、RTO と RPO という2つの目標（意味は表の下）から決めます。

RTO は復旧までにかかってよい時間、RPO は失ってよいデータの期間（どの時点まで戻ってよいか）です。面接では、DR訓練を実際にやっているかを聞かれやすいです。

必要以上に速い復旧を求めるとコストが跳ね上がる。ビジネス要件から決める。

下の「ブラウザで試す」の図では、東京のリージョンが止まったときに、Route 53 のヘルスチェックが失敗を検知し、DNS の答えを大阪に切り替えるまでを順に見られます。TTL が切れるまでは古い東京の IP に接続しようとする人がいること（RTO に効く）と、DNS が切り替えるのは入口だけで、大阪のレプリカの DB は別に昇格させる必要があり、非同期だと東京で最後に書いた分が届いていないかもしれないこと（RPO に効く）に注目してください。

DBマイグレーションは後方互換を保つ（Expand / Contract：列追加 → アプリ切り替え → 旧列削除）のが定番の答え。

どの方式でも、メトリクスを見て自動で戻せる仕組みとセットにする。

5段目以外はいつでも戻せる。戻れない操作は最後に回す。

Git は、ソースコードやインフラの定義（Terraform・Kubernetes のマニフェスト）の変更の履歴を残す道具です。SRE にとって大事なのは、「いつ・誰が・何を・なぜ変えたか」が追えること、そして壊れたら戻せることです。障害の多くは変更がきっかけなので、変更の入口を Git にそろえておくと、原因の特定と切り戻しが速くなります。

SRE として決めておくこと：main への直接 push を禁止（ブランチ保護）、PR に CI の合格とレビューを必須に、コミットに課題番号を入れる、秘密情報を入れない（入れてしまったら履歴から消すより先に鍵を無効化して作り直す。履歴は複製されている前提で）、タグでリリースの版を残す。

CI/CDとGitHub Actions・ビルド・CIの高速化

GitOps は、インフラやアプリの「あるべき姿」を Git に宣言として書き、Argo CD や Flux のような仕組みが、クラスタの実際の状態をそれに合わせ続けるやり方です。本番を変える入口が PR だけになるので、変更のレビュー・履歴・切り戻し（revert）がすべて Git でできます。

IaCのデプロイフロー戦略

CI（継続的インテグレーション）は、変更のたびに自動でビルド・テスト・検査をすることで、CD（継続的デリバリー・デプロイ）は、検証済みの成果物を自動でステージングや本番に届けることです。GitHub Actionsでは、リポジトリの .github/workflows にYAMLでワークフローを書き、PRやpushなどのイベントで実行します。

name: deploy
on:
  push:
    branches: [main]
permissions:
  id-token: write   # OIDCでAWSに認証するため
  contents: read
concurrency: deploy-production   # 同時に2つ走らせない
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production       # 承認者ルールを適用
    steps:
      - uses: actions/checkout@<コミットSHA>
      - uses: aws-actions/configure-aws-credentials@<コミットSHA>
        with:
          role-to-assume: arn:aws:iam::123456789012:role/deploy
          aws-region: ap-northeast-1
      - run: ./scripts/deploy.sh

「ビルドは1回、同じ成果物を環境ごとに昇格」が基本。

迷ったら標準ランナーから始め、重いジョブとVPC内に届く必要があるジョブだけ別のランナーにする。

CIの時間は、障害時に修正をデプロイするまでの時間（MTTR）にも含まれます。「緊急時は承認を省略できる」よりも、「普段から速い」ことの方が大事です。

まず計測し、一番長いジョブから手をつける。考え方はパフォーマンスチューニングと同じ。

Terraformなどで書いたインフラは、変更の影響が大きく、間違えるとリソースを削除してしまいます。そのため、PRを作るとCIがplanを実行して差分をコメントし、レビューと承認を経て、CIだけがapplyする流れを仕組みで強制します。人の端末から本番にapplyできる権限は持たせません。

planのレビューでは、特に削除（destroy）と置き換え（replace）を確認します。DBやボリュームの置き換えはデータの消失につながるので、prevent_destroyで守ります。手動で変更された差分（drift）は定期的なplanで検知し、コードに取り込むか元に戻します。

「planを見ずにapply」と「手元からapply」をなくすのが最初の一歩。

コンテナの中のプロセスも、ホストのLinuxカーネルの上で動く普通のプロセスです。違いは、namespaceで見える範囲を分け（自分のプロセスしか見えない、独自のネットワークやファイルシステムを持つ）、cgroupsで使えるCPUやメモリの量を制限していることです。OSを起動しないので軽く速く起動しますが、カーネルを共有しているので、カーネルの脆弱性は全コンテナに影響します。

コンテナのメモリ上限はcgroupsで決まるので、ホストに空きがあってもOOMKilledになる。

コンテナは、アプリと必要なライブラリを1つにまとめ、どのサーバーでも同じように動かせる形にしたものです。Kubernetes（k8s）は、たくさんのコンテナを複数のサーバー（ノード）に配置し、落ちたら作り直し、負荷に応じて数を増減させる仕組みです。コンテナは Pod という単位で動かし、Pod への入口として、変わらない名前と IP を持つ Service を置きます。

SRE は「アプリが動く土台」として、Pod の状態の見方や、リソースの設定・ヘルスチェック（Probe）の設計を問われます。設定を誤ると、正常な Pod が再起動を繰り返したり、リクエストを取りこぼしたりします。

第11章「セキュリティ」：コンテナセキュリティを図で詳しく

下の「ブラウザで試す」の図では、クラウドの LB から Ingress を通って Pod に届き、その Pod が別のサービスを Service の名前（CoreDNS で引く）と仮想の IP（kube-proxy の規則で本物の Pod の IP に書き換える）で呼ぶまでを順に見られます。表の Probe に関係するのは後半で、readiness probe に失敗した Pod が再起動されずに振り分け先から外されるところに注目してください（再起動するのは liveness probe です）。

Kubernetes で Pod がうまく動かないとき、kubectl get pods の STATUS 欄に Pending・CrashLoopBackOff のような状態の名前が出ます。名前を見れば、ノードへの配置（スケジューリング）・イメージの取得・起動後のアプリ・通信のどこで止まっているかの見当がつきます。

障害対応では、まず状態の名前で段階を絞り、次に kubectl describe の Events や kubectl logs で原因を確かめる、という順番が基本です。面接でも「CrashLoopBackOff になったらどう調べるか」はよく聞かれます。

下の「ブラウザで試す」の図は Pod の通信の流れなので、表のうち関係するのは最後の「Service に繋がらない」です。Pod が Service の名前を CoreDNS で引き、kube-proxy の規則で Ready な Pod の IP に書き換えられて届くまでと、readiness probe に失敗した Pod が振り分け先から外れるところを見られます。kubectl get endpoints が空になるのは、selector が Pod に一致していないか、Ready な Pod が1つもないときだ、と結び付けて見てください。