インフラの横文字、いい加減ちゃんと理解する

こんにちは、タリーです☕️

インフラを勉強し始めて最初にぶつかる壁が「横文字が多すぎる」問題。サービス名（GCP/AWSの◯◯）は調べれば出てくるけれど、その手前にある「概念」の言葉が曖昧なままなのでまとめました。

この記事では、インフラの現場で飛び交う概念用語を、

ざっくり一言（覚えるならこれだけ）
意味（もう少し正確に）
いつ使う（どんな場面で登場するか）

の3点セットでまとめることにします！（備忘録も兼ねています）

1. 監視・オブザーバビリティ

用語	ざっくり一言	意味	いつ使う
モニタリング（監視）	「決めた項目を見張る」	事前に決めた指標を継続的に計測し、閾値を超えたら知らせる仕組み。「何を見るか」を先に決めている。	CPU使用率80%超えでアラート、など既知の障害パターンに備えるとき
オブザーバビリティ（可観測性）	「外から中を推測できる状態」	システムの外部出力（ログ・メトリクス・トレース）だけで、内部で何が起きているかを説明できる性質。「まだ知らない問題」を後から調査できるかどうか。	「なぜか特定ユーザーだけ遅い」のような未知の障害を掘るとき
テレメトリ	「システムからの発信データ」	システムが自ら吐き出す計測データの総称。ログ・メトリクス・トレースをまとめてこう呼ぶ。	「テレメトリを収集する基盤」＝ログ/メトリクス収集基盤の話をするとき
メトリクス	「数値の時系列」	一定間隔で記録される数値データ。CPU使用率、リクエスト数、エラー率など。軽くて長期保存に向く。	ダッシュボードで傾向を見る、アラートの発火条件にする
ログ	「イベントの記録」	「いつ・何が起きたか」を1行ずつ記録したテキスト。情報量は多いが重い。	障害発生時に「その瞬間何が起きたか」を追うとき
（分散）トレース	「1リクエストの旅の記録」	1つのリクエストが複数サービスをどう通過し、どこで何ミリ秒かかったかを繋げて可視化したもの。	マイクロサービスで「どのサービスがボトルネックか」を特定するとき
スパン	「トレースの1区間」	トレースを構成する最小単位。「サービスAでのDB問い合わせ 120ms」のような1処理。	トレースを読むとき、どこが太いスパンかを見る
カーディナリティ	「ラベルの種類の多さ」	メトリクスに付けるラベル（タグ）の値の種類数。ユーザーIDのような無限に増えるラベルを付けると爆発してコストが跳ねる。	メトリクス設計時に「このラベル、高カーディナリティでは？」と止めるとき
アラート疲れ（アラートファティーグ）	「オオカミ少年状態」	意味のないアラートが鳴りすぎて、誰も反応しなくなる現象。	監視設計のレビューで「このアラート、本当に人を起こす価値ある？」と問うとき

3本柱（Three Pillars）: メトリクス・ログ・トレース。この3つが揃って初めてオブザーバビリティが成立する、という整理をよく見る。最近は OpenTelemetry（OTel） という標準規格で3つをまとめて扱うのが主流。

2. 信頼性・SRE

用語	ざっくり一言	意味	いつ使う
SRE	「信頼性をエンジニアリングする職能」	Site Reliability Engineering。運用を人力ではなくソフトウェアで解決するアプローチ。Google発。	組織・役割の話をするとき
SLI	「測る指標」	Service Level Indicator。可用性やレイテンシなど、実際に計測する値。	「何を計測するか」を決める段階
SLO	「自分たちで決める目標」	Service Level Objective。SLIに対する目標値（例：成功率99.9%）。内部向けの約束。	非機能要件の可用性目標を決めるとき
SLA	「顧客との契約」	Service Level Agreement。破ったら返金などのペナルティが発生する対外的な合意。SLOより緩めに設定するのが定石。	契約書・利用規約レベルの話
エラーバジェット	「壊していい残量」	SLOが99.9%なら、残り0.1%は「失敗してよい枠」。この枠が残っていれば攻めたリリースをしてよい、という判断材料。	リリース速度と安定性のバランスを議論するとき
トイル（Toil）	「手作業の消耗戦」	手動で・繰り返し・自動化可能なのにしている運用作業。SREでは削減対象。	「この作業、トイルなので自動化しよう」と提案するとき
ポストモーテム	「障害の振り返り」	障害後に原因と再発防止をまとめる文書。人を責めない（Blameless）のが原則。	障害収束後の振り返り会
MTTR / MTBF	「直す速さ / 壊れない長さ」	MTTR＝平均復旧時間、MTBF＝平均故障間隔。近年は「壊れない」より「早く直る」を重視する流れ。	運用品質のKPIを設計するとき
オンコール	「呼び出し当番」	障害時に呼び出される待機当番の体制。	運用体制・シフトの設計

3. 性能・スケーラビリティ

用語	ざっくり一言	意味	いつ使う
レイテンシ	「1回の遅さ」	リクエストを投げてから返ってくるまでの時間。	「p95レイテンシ 300ms以内」のような性能要件
スループット	「単位時間の量」	単位時間あたりに処理できるリクエスト数（RPS/QPS）。	負荷試験の目標値を決めるとき
パーセンタイル（p50 / p95 / p99）	「平均は嘘をつく」	遅い順に並べたときの上位◯%の値。平均だと一部の激遅リクエストが隠れるため、p95/p99で評価する。	性能要件を定義するとき（「平均◯ms」は要注意ワード）
スケールアップ（垂直）	「マシンを強くする」	CPU/メモリを増やして1台の性能を上げる。限界がある。	DBなど分散しづらいものを強化するとき
スケールアウト（水平）	「マシンを増やす」	台数を増やして処理を分散する。クラウドの基本戦略。	Webサーバー層の増強、オートスケール設計
ステートレス / ステートフル	「状態を持たない / 持つ」	サーバー側にセッション等の状態を持たない設計は、どの台に振っても同じ結果になるためスケールアウトしやすい。	「なぜスケールできないのか」を議論するとき
ロードバランシング（負荷分散）	「交通整理」	複数のサーバーにリクエストを振り分ける。	冗長構成の入り口として必ず出てくる
オートスケーリング	「自動で増減」	負荷に応じてインスタンス数を自動調整する。	コスト最適化 × 可用性の両立を語るとき
キャパシティプランニング	「どれだけ要る？の見積もり」	想定トラフィックに対して必要なリソース量を事前に見積もること。	非機能要件（性能）の前提を置くとき
ボトルネック	「一番細いところ」	全体の性能を律速している箇所。ここを直さないと他をいくら強化しても意味がない。	性能改善の優先順位づけ

4. 障害耐性・レジリエンス

用語	ざっくり一言	意味	いつ使う
可用性（Availability）	「使える時間の割合」	稼働率。99.9%（スリーナイン）なら年間ダウンタイム約8.7時間。	非機能要件の中心。ナインの数で会話する
冗長化（Redundancy）	「予備を持つ」	同じ役割のものを複数用意し、1つ壊れても止まらないようにする。	マルチAZ構成などの設計根拠
単一障害点（SPOF）	「ここが死んだら全滅」	Single Point of Failure。冗長化されていない箇所。	設計レビューで「SPOFはどこ？」と潰していく
フェイルオーバー	「予備に切り替える」	障害時に待機系へ自動で切り替えること。	DBのプライマリ/スタンバイ構成など
グレースフルデグラデーション	「全滅ではなく縮退」	一部機能が落ちても、コア機能だけは生かして提供し続ける設計。	「レコメンドAPIが落ちても商品は買える」ようにする設計判断
サーキットブレーカー	「ブレーカーを落として延焼を防ぐ」	依存先が壊れているとき、呼び出しを一時停止して自分まで巻き込まれないようにする。	マイクロサービス間の連鎖障害（カスケード障害）対策
リトライ + エクスポネンシャルバックオフ	「間隔を空けて再挑戦」	失敗時に指数関数的に待ち時間を伸ばして再試行する。単純な即時リトライは相手にトドメを刺すので厳禁。	外部API連携の実装方針
冪等性（Idempotency）	「何回やっても結果が同じ」	同じ操作を複数回実行しても副作用が1回分にしかならない性質。リトライを安全にする前提条件。	決済APIの二重課金防止、リトライ設計
レートリミット / スロットリング	「流量制限」	一定以上のリクエストを弾いたり遅らせたりする。自分を守るための防波堤。	API公開時、DDoS/暴走クライアント対策
ヘルスチェック	「生きてる？の確認」	定期的に「正常に動いているか」を問い合わせ、死んでいるインスタンスを切り離す。	LB・Kubernetesの構成設計
RTO / RPO	「いつまでに復旧 / どこまで戻る」	RTO＝復旧目標時間、RPO＝許容できるデータ損失時間（＝バックアップ間隔の上限）。	災害対策（DR）の要件定義
カオスエンジニアリング	「わざと壊して確かめる」	本番に近い環境で意図的に障害を注入し、耐性を検証する手法。	可用性を「祈り」ではなく「検証済み」にしたいとき

5. デプロイ・リリース戦略

用語	ざっくり一言	意味	いつ使う
ローリングアップデート	「順番に入れ替える」	稼働中のインスタンスを少しずつ新バージョンに置き換える。	無停止デプロイの基本形
ブルーグリーンデプロイ	「まるごと2面用意して切り替える」	本番（Blue）と同構成の新環境（Green）を作り、ルーティングを一気に切り替える。切り戻しが速い。	ロールバックの速さを最優先するとき
カナリアリリース	「まず5%だけ試す」	一部のトラフィックにだけ新バージョンを流し、問題なければ拡大する。※炭鉱のカナリアが由来。	影響範囲を絞って本番検証したいとき
フィーチャーフラグ	「コードは出すが機能はOFF」	デプロイと機能公開を切り離すスイッチ。	リリースとリスクを分離したいとき
ロールバック	「戻す」	前のバージョンに切り戻すこと。「戻せる設計か」が設計品質そのもの。	リリース計画に必ず含める

6. インフラ構成管理

用語	ざっくり一言	意味	いつ使う
IaC	「インフラをコードで書く」	Infrastructure as Code。手作業のGUI操作ではなく、コードで環境を定義・再現する。Terraformなど。	環境差分をなくしたい、レビュー可能にしたいとき
宣言的（Declarative）	「あるべき姿を書く」	「どうやるか（手順）」ではなく「どうあるべきか（状態）」を書く。差分は仕組みが埋める。	Terraform / Kubernetes の思想を説明するとき
べき等（Idempotent）※構成管理文脈	「何回流しても同じ状態」	同じコードを何度適用しても、最終的な状態が同一になる性質。	IaCの安全性を語るとき
イミュータブルインフラ	「直さない、作り直す」	稼働中のサーバーを手で修正せず、新しいイメージで置き換える。	「秘伝のタレサーバー（構成不明な職人サーバー）」を撲滅したいとき
プロビジョニング	「用意する」	リソースを作成し、使える状態にすること。	環境構築フローの説明
CI / CD	「自動でテスト / 自動で届ける」	CI＝継続的インテグレーション（統合とテストの自動化）、CD＝継続的デリバリー/デプロイ。	開発フロー設計
GitOps	「Gitが唯一の正解」	Gitリポジトリの状態を「あるべき姿」とし、それに実環境を自動で一致させる運用。	Kubernetes運用、監査可能なデプロイを作るとき

7. セキュリティ・運用ガバナンス

用語	ざっくり一言	意味	いつ使う
最小権限の原則（PoLP）	「必要な分だけ渡す」	権限は業務に必要な最小限だけ付与する。	IAM設計の大原則
ゼロトラスト	「社内だからと信用しない」	ネットワークの内外を問わず、すべてのアクセスを検証する考え方。	境界防御（お城と堀）モデルの限界を説明するとき
監査ログ（Audit Log）	「誰が何をしたかの記録」	操作の実行者・対象・時刻を残す。アプリのログとは目的が別物。	コンプライアンス要件、内部統制
シークレット管理	「鍵を平文で置かない」	APIキーやパスワードを専用の金庫（Secret Manager等）で管理する。	リポジトリへの認証情報コミット事故を防ぐ