#インフラ
447 件の記事
CloudWatch メトリクス・アラームの料金 — ログの次に漏れる場所
CloudWatch の請求書で Logs の次の項目を分解します。月 $0.30 ずつ積み上がるカスタムメトリクスとディメンションの組み合わせが個数を爆発させる原理、アラーム・ダッシュボード・API 呼び出し(特に GetMetricData)の単価、サードパーティの可観測性ツールがメトリクス API 料金を作る構造、埋め込みメトリクスフォーマットとディメンション設計で個数を減らす方法、点検の手順まで扱います。
AWS ログ分析の選択 — Logs Insights vs Athena vs OpenSearch
ログをどこで検索・分析するかを分ける基準を整理します。すでに CloudWatch にあるログをそのまま照会する Logs Insights(スキャン GB あたり $0.005)、S3 に貯めて SQL で問う Athena(スキャン TB あたり $5)とパーティショニング・圧縮が料金を分ける構造、常時ダッシュボードと全文検索が必要なときの OpenSearch とその固定費、3 層を組み合わせる実務構成と選択の手順まで扱います。
Kinesis vs MSK vs SQS — ストリーミングとキューの選択基準
イベントデータを受ける 3 つのサービスを分ける基準を整理します。消費すると消えるキューと読み直せるストリームというモデルの違い、SQS の 100 万件あたり $0.40 という単純さ、Kinesis のプロビジョンドシャードとオンデマンドモード、MSK が正当化される Kafka エコシステム要件、Express ブローカーとサーバーレスという MSK の 2 つの枝、規模とチームの力量で分ける選択の手順まで扱います。
Spot インスタンス実践 — 最大 90% 割引の条件と中断対応の設計
Spot がコミットなしで最大 90% の割引を与える代わりに何を要求するかを整理します。2 分の中断通知とリバランス勧告の実際の動き、中断耐性のあるワークロードとないワークロードを分ける基準、price-capacity-optimized 割り当て戦略とインスタンスの多様化が中断頻度を減らす原理、Fargate Spot の位置づけ、RI・Savings Plans・Graviton と組み合わせてコスト 3 軸を完成させる設計まで扱います。
Terraform 依存関係エラーの総整理 — Cycle、depends_on の誤用、known after apply
Terraform の依存グラフから出てくる 3 つの問題をまとめて整理します。Error: Cycle の代表例であるセキュリティグループの相互参照を分離リソースで断ち切る方法と terraform graph による診断、暗黙の依存が基本で depends_on は隠れた依存にだけ使うべき理由と乱用の副作用、count と for_each のキーに計算前の値が入って出る Invalid count argument の解決法まで扱います。
tfstate にシークレットが平文で保存されたとき — キーのローテーションと再発防止
tfstate が sensitive の指定と無関係に値を平文で持つ構造から整理します。露出範囲を判断する順序、state の整理よりキーのローテーションが先である理由、git に state がコミットされていた場合の履歴整理、そして再発防止としての ephemeral リソースと write-only 引数、S3 バックエンドの暗号化とアクセス統制、シークレットをそもそも state に残さない設計まで扱います。
terraform plan が遅いとき — refresh の負荷、並列度、スタック分割の合図
plan の所要時間の本体が差分計算ではなく、リソースごとに API を読む refresh だという事実から整理します。リソース数と API 往復が時間を決める構造、-refresh=false を使ってよい局面といけない局面、parallelism の調整を rate limit を見ながら実測で決めるべき理由、-target が性能の道具ではない理由、そして根本対策であるスタック分割に移るべき合図まで扱います。
AWS provider 6.x アップグレード — breaking change の診断と安全な移行順序
AWS provider のメジャーアップグレードを安全に越える手順を整理します。CLI アップグレードより影響が大きい理由、最新の 5.x を経由して deprecation 警告を消化する標準手順、6.0 の主要変更(リソース単位の region 引数、OpsWorks・SimpleDB の削除、ブーリアンの厳格化、Redshift デフォルトの反転)、スキーマ変更が作る見かけの差分と本物の置き換えを区別する plan の読み方、共有モジュールのバージョン下限が作る落とし穴まで扱います。
Terraform バージョンアップグレードの手順 — 互換性の約束、no-op 検証、ロールバック備え
Terraform CLI のバージョンを上げる安全な手順を整理します。1.x の範囲では構成とワークフローの互換が維持されるという互換性の約束、CLI のアップグレードと provider のアップグレードを分けるべき理由、アップグレード前後で変更なしの plan を確認する検証法、新バージョンが書いた state を旧バージョンが読めないことがあるため必要なロールバックの備え、tfenv と mise によるチーム・CI のバージョン統一まで扱います。
terraform destroy が失敗するとき — DependencyViolation と消えないリソース
destroy 失敗の 3 つの枝を区別して整理します。Terraform の外で作られたリソースが掴んでいて出る DependencyViolation の診断手順、空になっていない S3 バケットと force_destroy を有効にしてから先に apply が必要な理由、prevent_destroy や deletion_protection のようにわざと掛けた安全装置の正しい解除手順、削除が遅いリソースのタイムアウト、部分 destroy 後の残存物の整理まで扱います。
terraform plan は成功したのに apply が失敗するとき — 原因と部分適用の復旧
plan が通ったのに apply が失敗する理由を構造から整理します。plan はスキーマと参照だけを検証し、実際の API 検証は apply で初めて起きるという非対称、権限不足と IAM 伝播遅延、サービスクォータ、グローバルな名前衝突といった典型原因 5 つ、apply がトランザクションではないために生まれる部分適用状態を安全に復旧する手順、already exists エラーが出たときの import 判断まで扱います。
Route 53 ルーティングポリシー比較 — 8 種類のポリシーの選択基準
Route 53 の 8 種類のルーティングポリシーをシナリオで分ける基準を整理します。シンプル・加重・レイテンシー・フェイルオーバー・位置情報・地理的近接性・複数値回答・IP ベースそれぞれの用途、ポリシーによって変わるクエリ単価($0.40〜$0.80/100 万件)とエイリアスクエリ無料の効果、ヘルスチェックの料金と組み合わせの原則、カナリアデプロイ・DR・マルチリージョンという代表シナリオ別の正解まで扱います。