エンジニアとして日々新しい知識をインプットしています。現在の職場には、毎日の終業時に日報を提出する文化があり、その中に「本日発見したこと・気づいたこと」を記載する欄が設けられています。私はこの欄を、業務で得た新しい知見や、業務外の自己学習で学んだことを記録するアウトププットの場として活用しています。この記事は、その日々の学びを知識として定着させ、いつでも振り返れる資産にするために、1ヶ月分をまとめたものです。
2025-12-1
Terraform において、特定のリソースだけを操作するための機能である -target オプションについて知ることができました。
# 特定のリソースだけに操作を限定
terraform plan -target=<リソースアドレス>
terraform apply -target=<リソースアドレス>
# 複数のリソースを指定可能
terraform apply \
-target=’module.docdb_cluster[“staging”]’ \
-target=’module.rds_cluster[“staging”]’
# 注意点：依存関係は自動解決される（インスタンスを指定すると、依存するクラスタも自動で含まれる）
terraform apply -target=’module.docdb_cluster_instance[“writer”]’
# → module.docdb_cluster[“staging”] も自動的に対象に含まれる
. 推奨される使用方法
・一時的な対処として使用
・緊急時の部分適用
・段階的なロールアウト
・常用は避ける（状態の不整合リスク）
2025-12-2
SSM Parameter Store の値管理について、Terraform のベストプラクティスを把握することが出来ました。
機密情報（SecureString）の場合、値は Terraform 管理外とし、箱だけ管理するべき
理由
・Terraform state fileには値が平文で保存される（SecureStringであっても）
・GitリポジトリやCI/CDログに機密情報が露出するリスク
・チーム全員がstate fileにアクセスできてしまう
非機密情報（String/StringList）の場合、Terraform で値まで完全管理するべき
理由
・コードとして管理・バージョン管理できる
・環境の再現性が向上
・コードレビューが可能
・Infrastructure as Codeの原則に沿う
2025-12-4
RDS Aurora / DocumentDB では「クラスター」と「インスタンス」で呼ばれる概念が、ElastiCache では「レプリケーショングループ」と「ノード（メンバークラスター）」という名前で呼ばれることを知りました。
2025-12-5
ElastiCache のパラメータグループは、クラスターレベルでのみ存在し、インスタンスレベルでは存在しないことを知りました。
2025-12-8
ElastiCache におけるノード（メンバークラスター）は、Terraform リソースとして個別管理しないことを知りました。
レプリケーショングループ側で管理する（レプリケーショングループがノードまで自動管理してくれる）ことを知りました。
# レプリケーショングループ（論理的なまとまり）
resource “aws_elasticache_replication_group” “valkey” {
replication_group_id = “my-valkey-cluster”
engine = “valkey”
node_type = “cache.r7g.large”
# ノード数の指定（RDSと違い、個別リソースは作らない）
num_cache_clusters = 3 # 1プライマリ + 2レプリカ
# または、クラスターモード有効時
# num_node_groups = 3 # シャード数
# replicas_per_node_group = 2 # シャードあたりのレプリカ数
# … その他の設定 …
}
ノード（メンバークラスター）は自動作成されるため、個別の aws_elasticache_cluster リソースは定義しない
2025-12-10
ElastiCache におけるクラスターモード（シャーディング）に関して、有効時と無効時の状態を知ることができました。
・有効時：複数のシャード（ノードグループ）に分割され、各シャードが独自のプライマリ+レプリカを持つ
・無効時：１つの単純なプライマリ+レプリカ構成
2025-12-11
ElastiCache におけるクラスターモードの有効時と無効時の挙動の違いについて理解することができました。
（有効時）
レプリケーショングループ内に、シャード（ノードグループ）を複数用意して、各シャードにプライマリノードとレプリカノードを配置する。そして、データをノードグループ毎に分散して保存（水平分割）することで、シャーディングという方法で負荷分散を行う。
（無効時）
レプリケーショングループ内にプライマリノードとレプリカノードを配置するシンプルな構成。 全ノードが全ての完全なデータ（データコピー）を持つ
2025-12-12
RDS Aurora は、下記項目などをインスタンス毎に個別で設定可能だが、ElastiCacheでは個別設定はできないことを知りました。
・インスタンスクラス
・Availability Zone
・Performance Insights
・モニタリング間隔
・プロモーション優先度
・パブリックアクセス
・Auto Minor Version Upgrade
2025-12-15
ALB のデフォルトリスナールールは、aws_lb_listener_rule リソースとして専用で管理せず、リスナー本体側で管理することが一般的であることを知りました。
デフォルトルールは、実際には「ルール」というより、リスナーの default_action 属性として管理される
resource “aws_lb_listener” “https” {
load_balancer_arn = aws_lb.main.arn
port = 443
protocol = “HTTPS”
# これがデフォルトルール
default_action {
type = “fixed-response”
fixed_response {
content_type = “text/plain”
status_code = “403”
}
}
}
2025-12-16
スワップ領域周辺で出てくる si / so の意味（vmstat）について知ることができました。
si (swap in)：swap → メモリ(RAM) に読み戻している量
= swap に追い出されていたページを、必要になって RAM に戻す
so (swap out)：メモリ(RAM) → swap に追い出している量
= RAM が足りない/圧迫しているので swap に退避する
2025-12-17
Terraform において、ALB と NLB はそれぞれ専用でモジュールを作成すべきであり、１つのモジュールに統合すべきではない理由を知ることができました。
ALBとNLBは本質的に異なるリソース
・ALB：Layer7（アプリケーション層）、HTTP/HTTPS特化、複雑なルーティングルール、WAF統合など
・NLB：Layer4（トランスポート層）、TCP/UDP/TLS、静的IP対応、超低レイテンシ
ALBには、以下の特有の機能がある。これらはNLBでは使用できない。
・listener_rules（パスベースルーティング、ホストベースルーティング）
・idle_timeout、enable_http2、drop_invalid_header_fields
・desync_mitigation_mode、enable_xff_client_port
2025-12-18
Disaster Recovery（DR）について知ることができました。
Disaster Recovery（DR）とは、地震・火災・大規模停電・データセンター障害・クラウドリージョン障害・ランサム被害などの「災害級」の事故でサービスが止まったりデータが壊れたりしたときに、事前に用意した手順と構成でサービスを復旧させる考え方・計画のこと。
DRでは主に次を決める
・RTO（Recovery Time Objective）：どれくらいの時間で復旧させるか（例：2時間以内に再開）
・RPO（Recovery Point Objective）：どれくらい前のデータまで失ってよいか（例：最大5分のデータ損失まで許容）
この2つが「DRの要求水準」をほぼ決める。RTO/RPOが厳しいほど、コストも運用も重くなる。
典型的なDRの方式（ざっくり）
・バックアップ＆リストア型（安いが遅い）
・定期バックアップから別環境に復元。RTO長め、RPOも長めになりがち
・パイロットライト / ウォームスタンバイ（中間）
・最低限または縮小構成を別拠点 / 別リージョンに常時用意しておき、災害時に拡張して切替
・アクティブ-アクティブ（マルチリージョン稼働）（高いが強い）
・平時から複数拠点で稼働し、片方が落ちても継続。RTO/RPOを短くしやすいが設計難度・費用が高い
2025-12-19
MTTR について知ることができました。
・MTTRは、信頼性でよく出てくる指標で、一般には Mean Time To Repair（平均修復時間）を指す
・ざっくり言うと、障害が起きてから、元の正常状態に戻るまでに平均でどれくらい時間がかかるか
・一般的には、シンプルに「MTTR = 各インシデントの復旧までの時間の合計 ÷ インシデント件数」で計算する
2025-12-22
CloudWatchアラームにおける「ディメンション」の仕組みを知ることができました。
1. ディメンションの本質的な役割
・CloudWatchアラームにおける Dimensions とは、メトリクスを識別するためのラベル（名前と値のペア）
・同じメトリクス名（例：mem_used_percent ）であっても、CloudWatch Agentは「どのインスタンスのデータか」「どのOSか」といった情報をラベルとして付与して送信している
2. CloudWatch Agentとアラームの紐付け
・アラームを正しく動作させるためには「Agentがデータ送信時に付与したディメンション」と「アラーム作成時に指定するディメンション」を完全に一致させる必要がある
・データ送信側（Agent）：設定ファイル（amazon-cloudwatch-agent.json）の append_dimensions 等で指定された項目（InstanceId, ImageId, InstanceTypeなど）をデータに付帯させて送信する
・データ受信側（アラーム）：CLIの –dimensions オプションなどで、Agentが送ってきたラベルをすべて指定する必要がある。1つでも不足したり値が異なったりすると、アラームは「対象のデータが存在しない」と判断し、データ不足の状態になってしまう。
3. 注意点
・環境による値の差異：disk_used_percent などのメトリクスでは、インスタンスの世代やOSによって device（nvme0n1p1等）や fstype（xfs等）が異なる。そのため、過去の流用ではなく、必ず現在のインスタンスが「どのようなディメンションでデータを送っているか」を確認した上で、アラームを定義する手順が確実
2025-12-23
Linux システムにおいて、現在ログインしているユーザーを確認するためのコマンドである whoami と id コマンドについて知ることができました。
whoami コマンド
・現在の実行ユーザー名だけを表示する非常にシンプルなコマンド
・主な用途は、自分が今どのユーザーとして操作しているか（例：一般ユーザーか root か）を素早く確認したいとき
id コマンド
・現在のユーザーに関するより詳細な情報を表示する
・ユーザー名だけでなく、システムがユーザーを識別するための番号（ID）を表示するのが特徴
・表示される主な情報
・uid：ユーザーID（ユーザー固有の番号）
・gid：プライマリグループID（メインで所属するグループの番号）
・groups：所属しているすべてのグループのIDと名前
2025-12-25
信頼性の観点で出てくる RTO（Recovery Time Objective）について知ることができました。
・RTO とは、障害や災害でサービスが止まったときに「どれくらいの時間以内に復旧させる（再開させる）べきか」という目標値
・日本語だと「目標復旧時間」みたいに言われる
何を復旧とみなすか、という定義も重要で、よくある置き方は次のどれか
・最低限の提供を再開（縮退運転でもOK）
・主要機能が使える状態（SLO相当まで戻す）
・通常運転に完全復帰（恒久対応や性能回復まで含む）
現場では「ユーザー影響が解消した時点」を復旧完了とすることが多い
RTOとMTTRの関係
・RTO：目標（SLA/ビジネス要求）
・MTTR：実績（運用・技術の結果）
イメージは「MTTR が RTO を継続的に下回れているか」を見る
2025-12-26
RTO と RPO の違いについて知ることができました。
・RTO：時間の目標（いつまでに再開するか）
・RPO：データの目標（どこまでデータ損失を許すか）
例：RTO 2時間 / RPO 5分
→ 2時間以内に復旧したい、失うデータは最大5分までにしたい