2025/07 技術インプットまとめ

エンジニアとして日々新しい知識をインプットしています。現在の職場には、毎日の終業時に日報を提出する文化があり、その中に「本日発見したこと・気づいたこと」を記載する欄が設けられています。私はこの欄を、業務で得た新しい知見や、業務外の自己学習で学んだことを記録するアウトププットの場として活用しています。この記事は、その日々の学びを知識として定着させ、いつでも振り返れる資産にするために、1ヶ月分をまとめたものです。

2025-7-1

特定のテーブルのカラム情報を手軽に確認したいときは、SHOW CREATE TABLE コマンドが最も簡単であることを知りました。

・テーブルの作成に使われたSQL文が表示される
・その中にカラムごとの文字コードと照合順序が含まれている

2025-7-2

RDS Auroraクラスターのリーダーインスタンスが複数ある場合に、リーダーエンドポイントにアクセスした際には、複数あるインスタンス間で自動的にリクエストが負荷分散されることを知りました。

2025-7-3

S3 の Inventory 機能について知ることができました。

一言でいうと、バケット内に存在する全オブジェクトのリストと、その詳細なメタデータ（属性情報）を一覧にしたレポートファイルを、定期的（毎日または毎週）に生成する機能。lsコマンドやコンソールでオブジェクト一覧を見るのと似ているが、S3 Inventory は数百万〜数億といった非常に大規模な数のオブジェクトを扱うことを想定して設計されている。ListObjects APIを何度も呼び出すよりもはるかに効率的に、バケット全体の「棚卸し」ができる。生成されるレポートには、オブジェクトキー（ファイル名）に加えて、サイズ、最終更新日、ストレージクラス、暗号化ステータス、オブジェクトのバージョンID、レプリケーションステータスなどの様々な情報を含めることができる。レポートは、指定した別のS3バケットにCSV、Apache ORC、Apache Parquetといった形式で出力される。

2025-7-4

AWS::Route53::RecordSet における TTL（Time To Live）プロパティについて理解することができました。

TTLは、DNSリゾルバがこのDNSレコードの情報をどれくらいの期間キャッシュに保持するかを秒単位で指定する値。例えば、TTLが300秒の場合、DNSリゾルバは一度取得したIPアドレスの情報を300秒間保持し、その間は再度DNSサーバーに問い合わせを行わない。TTLが短いほどDNSの変更が早く伝播するが、DNSサーバーへの問い合わせが増える可能性がある。

2025-7-7

db-auroracluster-1111cluster-1111.ap-northeast-1.rds.amazonaws.com のような RDS エンドポイントの名前解決を誰が担当しているのか気になったので調べました。

VPC内での名前解決は、VPCのDNSリゾルバー（AmazonProvidedDNS または Route53 Resolver）が担当している。VPC 内のすべての EC2 インスタンスや Fargate タスクは、デフォルトで VPC の CIDR ブロックのベース IP アドレスに .2 を加えたアドレス（例：VPC CIDR が 10.0.0.0/16 なら 10.0.0.2）にある DNS サーバーを使用するように設定されている。この VPC DNS リゾルバーは、パブリックなドメイン名だけでなく、rds.amazonaws.com のような AWS のサービスエンドポイントや、プライベートホストゾーンで定義されたプライベートなドメイン名も解決できる。RDS Aurora クラスターエンドポイントの場合、VPC DNS リゾルバーはクラスターの現在のプライベート IP アドレス（具体的には、書き込みインスタンスのプライベート IP アドレス）を返す。

2025-7-8

SOAレコード（Start of Authority Record）について理解することができました。

SOAレコードとは「このDNSゾーン（ドメインの管理範囲）に関する権威と管理情報はこれです」と宣言するためのレコード。各DNSゾーンには必ず1つのSOAレコードが存在し、そのゾーンのプライマリネームサーバーやゾーン管理者、ゾーン情報の更新に関するパラメータなどを定義する。DNSゾーン全体の「戸籍謄本」のようなもので、そのゾーンがどのように管理され、他のDNSサーバーとどのように連携するかの基本的なルールを定めている。

2025-7-9

LambdaとSQSの連携には、大きく分けて2つのパターンがあることを知りました。

LambdaがSQSにメッセージを送る（能動的）
Lambda関数が処理の途中で、他のシステムに何かを依頼したり、処理結果を渡したりするために、SQSキューにメッセージを書き込むパターン。これはシステム間で処理を非同期に連携させる一般的な使い方。

SQSがLambdaを起動する（受動的・トリガー）
SQSキューに新しいメッセージが追加されたことをトリガーとして、Lambda関数を自動的に起動するパターン。大量のリクエストを一度SQSキューで受け止めて、Lambdaで順次処理していくような構成でよく利用される。

2025-7-10

SCP（Secure Copy Protocol）について知ることができました。

SCPとは、暗号化された安全な方法で、コンピュータ間でファイルを送受信するための通信プロトコルのこと

何に使われるか
・ローカルコンピュータとリモートコンピュータ（サーバーなど）との間でファイルをやり取りするために使われる

なぜセキュアなのか
・SCPは、SSHを土台にしている

どのように使うか
・主にターミナルで、scpコマンドを使って操作する

注意点：現在の動向
・SCPは長年広く使われてきたが、いくつかの技術的な問題点やセキュリティ上の懸念から、現在ではより高機能で安全なSFTPやrsyncといったツールの利用が推奨されることが多い
・とはいえ、SCPはその手軽さから、今でも多くの場面で利用されている

2025-7-11

ECSタスク定義では、シークレットを環境変数として注入するための専用のプロパティがあるおかげで、シークレットマネージャーのARNを注入すれば自動で値自体を注入するという挙動をとってくれるのですが、Fargateにはそういった機能はないため、ARNを注入して実行時にアプリケーションコード側でboto3などを使ってARNをもとに手動で値をフェッチしてくるか、あるいは CloudFormation の動的参照 ({{resolve:secretsmanager:…}}) を使って解決したり、AWS Parameters and Secrets Lambda Extension を使う必要があることを知りました。

2025-7-14

Mixed Contentについて知ることができました。

Mixed Contentとは、HTTPS や TLS（SSL）で暗号化されたページ上で、HTTP（非暗号化）プロトコルのリソース（画像・CSS・JavaScript・API 呼び出しなど）を読み込もうとする状態を指す。安全なはずのページを攻撃に晒す入口になる。

Mixed Content が問題になる理由
1. セキュリティリスク
・HTTPS ページは通信の暗号化・改ざん防止を保証するが、ページ内に HTTP リソースがあると、そこだけは平文で送受信される
・攻撃者がそのリソースを盗聴したり改ざんしたりできるため、ページ全体の安全性が損なわれる。

2. ブラウザの振る舞い（現代のブラウザは混合コンテンツを検出すると次のように対応する）
・アクティブ混合コンテンツ（JavaScript や iframe、API リクエストなど） → 多くのブラウザが完全にブロック
・パッシブ／ディスプレイ混合コンテンツ（画像・動画・音声など、ユーザー操作以外ではページを書き換えないもの） → 警告を出すか、条件付きで許可（例：ユーザーの操作が必要）

Mixed Contentが出る場面
・HTML内で HTTP URL を指定（例：）
・JavaScript コードが HTTP 経由で動的にリソースを読み込む（ fetch(‘http://api.example.com/data’) ）
・外部ライブラリや広告・分析スクリプトが HTTP を使っている
・リバースプロキシやロードバランサで SSL 終端後、アプリケーションが HTTP と誤認して asset() などで HTTP を生成

対策のポイント
・すべてのリソースを HTTPS 経由で提供
・asset() や url() の出力を HTTPS 化
・リバースプロキシ（ALB）→ アプリケーション間のプロトコルを正しく認識（Laravel なら URL::forceScheme(‘https’) や TrustProxies ミドルウェアで X-Forwarded-Proto を信頼）
・外部 CDN／API も HTTPS 対応を確認

2025-7-15

EC2インスタンス内で発生したログを指定のロググループに転送する設定を、インスタンスの中に入らず、SSMのパラメータストアやドキュメント、Run Commandという仕組みを使って設定する方法を知ることができました。

1、SSM Run Command > Run Command
2、コマンドドキュメントで AmazonCloudWatch-ManageAgent を選択。CloudWatchエージェントを管理するスクリプトを準備
3、Optional Configuration Locationにて、SSMパラメータストアにある「ログ転送設定を示すjsonが格納されたパラメータ名」を指定
4、命令を実行する対象のEC2インスタンスを指定
5、実行し、結果が Success になるのを確認

2025-7-16

collectdについて知ることができました。

・collectdとは、主にLinuxシステムで古くから利用されているパフォーマンス監視ツール
・バックグラウンドで常に動作し、様々なシステムの数値を定期的に収集して記録する
・最大の特徴はプラグイン形式である点で、必要な監視項目に応じてプラグインを追加することで、多種多様なデータを収集できる

プラグインを有効にすることで収集可能なメトリクスが下記

基本的なシステムメトリクス
・CPU：コアごとの使用率、待機時間、負荷など
・メモリ：詳細な内訳（バッファ、キャッシュなど）
・ディスク：I/O操作回数、スループット、待機時間
・ネットワーク：パケット数、エラー数、スループット
・システム負荷：ロードアベレージ
・その他：稼働中のプロセス数、ログインユーザー数など

アプリケーション固有のメトリクス（collectdの真価は、特定のアプリケーションを監視するプラグインが豊富な点にある）
・ウェブサーバー（Apache, Nginx）：アクティブな接続数、秒間リクエスト数
・DB（MySQL, ポスグレ）：クエリ数、キャッシュヒット率、スロークエリ数
・キャッシュ（Redis, Memcached）：メモリ使用量、キャッシュヒット率、接続クライアント数

2025-7-17

Terraform が AWS 上でリソースを作成するときの流れやイメージを簡単に掴むことができました。

実行エンジン
Terraform CLI / Cloud が provider プラグインをロードし、AWS SDK または AWS Cloud Control API を直接呼び出す

状態管理
.tfstate ファイル（S3 などに保存）

デプロイ時の権限
AWS 認証情報（Access Key / STS など）で API を直接実行

（詳細）
Providerプラグイン方式
Terraform は「プロバイダー」というプラグインを介して各クラウド／サービスと通信する。AWSの場合 hashicorp/aws（従来）や hashicorp/awscc（Cloud Control APIベース）プロバイダーがあり、どちらも AWS SDK / Cloud Control API でリソース CRUD を直接呼び出す。

AWS上に別の形式が残るわけではない
Terraform で作成したリソースは、AWS 側から見れば普通の API 呼び出しで作られたリソース。特別な「Terraform 用メタデータ」や「隠しスタック」が AWS アカウントに出来るわけではない。

状態の保管場所が違う
CDK/CloudFormationは、AWS 側にスタック状態を保持するが、Terraform は .tfstate を自分で管理（S3 バケット＋DynamoDB Lock など）する。そのため、ドリフト検出の仕組みやロールバック挙動もそれぞれのツールで異なる。

（まとめ）
・HCL → 直接 AWS API で実行。CloudFormation には変換されない
・.tfstate を持ち、プロバイダーが API 呼び出しを担当

2025-7-18

OSファイルシステムがデフォルトで大文字・小文字を区別しない挙動により、gitがその影響を受けて、例えばApi.phpとAPI.phpを同じファイルとみなし、renameしても差分として認識してくれないケースがあることを知りました。

・Gitは、OSのファイルシステムが大文字,小文字を区別するかどうかを自動的に検知し、core.ignorecaseという設定を決める
・WindowsやmacOS上では、既定でcore.ignorecaseがtrueになっており、大文字,小文字だけの変更を無視する挙動になる

2025-7-22

CDKの構造とCloudFormationとの違いについて理解することができました。

CloudFormationの場合
・リソースをフラットなリストとして定義する
・リソース間の関係性は、!Ref や !GetAtt を通じて暗黙的な依存関係として構築される
・デプロイの順序は、この依存関係グラフに基づいてCloudFormationが決定する

CDKの場合
・コード上で new MyConstruct(this, ‘id’) のように、コンストラクタの第一引数（scope）に親となるConstruct（通常はthis）を渡すことで、論理的な親子関係を明確に構築する
・このツリー構造が、CloudFormationのフラットな定義よりも、実際のインフラの論理的な構成を直感的に表現してくれる
・この親子関係は、CDKがリソースの論理IDを自動生成したり、スタック情報を子Constructに伝搬させたりする上でも利用される

CloudFormationはリソース間で並列的な依存関係を構築するのに対し、CDKは親子関係を持つ階層構造でインフラを表現する。これがCDKの分かりやすさの一つの特徴である。

2025-7-23

AWS CDKのConstructについて概要を知ることができました。

・CDKにおけるConstructとは、AWSリソースを表現するための基本的な構成要素
・一つまたは複数のAWSリソースをコードで定義するための部品と考えると分かりやすい
・Constructは階層構造になっており、これらを組み合わせてアプリケーションのインフラ全体を定義する

Constructの3つのレベル
Constructには、抽象度の異なる3つのレベルがある。レベルが上がるほど、より少ないコードで高度な設定が可能になる

L1
・名称（プレフィックス）：Cfn（例：CfnBucket）
・概要：AWS CloudFormationに直接対応する最も低レベルなConstruct
・特徴：CloudFormationの全プロパティを1対1で設定可能。自動生成されるため、最新のAWSサービスに即座に対応できる。詳細な設定が必要な場合に利用。

L2
・名称（プレフィックス）：（プレフィックスなし例：Bucket）
・概要：AWSによって設計された高レベルなConstruct
・特徴：ベストプラクティスに基づいたデフォルト値が設定済み。定型的な処理（IAMポリシーの自動生成など）を隠蔽。より少ないコードで直感的にリソースを定義できる。

L3
・名称（プレフィックス）：パターン（例：ApplicationLoadBalancedFargateService）
・概要：複数のリソースを組み合わせた再利用可能なコンポーネント
・特徴：特定のユースケース（例：ALB + Fargateサービス）を想定して作られている。最も記述量が少なく、迅速に一般的なアーキテクチャを構築できる。

Constructの利点
・再利用性：作成したConstructは、他のスタックやアプリケーションで簡単に再利用できる
・コードの簡潔化：L2やL3のConstructを使うことで、インフラを定義するコードの量を劇的に減らせる
・ベストプラクティス：高レベルなConstructには、セキュリティや信頼性に関するAWSのベストプラクティスが組み込まれている
・構成の容易さ：複雑なリソース間の連携（例：権限設定）などを自動で行ってくれるため、設定漏れやミスを防ぐ

2025-7-24

yieldジェネレータについて知ることができました。

・PHP5.5から新しく追加された機能
・一言でいうと、メモリをあまり使わずに巨大なデータのかたまりを効率的に扱うための新しい仕組み
・yieldというキーワードを関数内で使うと、その関数はジェネレータと呼ばれる特殊なオブジェクトを返すようになる
・通常の関数：return で一度だけ値を返す。配列を返す場合、その配列の全要素をメモリ上に展開する必要がある
・ジェネレータ関数：yieldを使って、値を一つずつ順番に生成（産出）する。一度にすべてのデータをメモリに保持しない

2025-7-25

CDK Constructの３つの抽象度レベルのうち、L2とL3の「提供する責務範囲の違い」について知ることができました。

L2 Construct
・「単一の論理的なサービス」を提供する
・S3バケット、Fargateサービス、Lambda関数などがこれにあたる
・そのサービスを実現するために内部で複数のAWSリソースが作られることはよくある（例：s3.BucketというL2 Constructは、単にS3バケットを作るだけでなく、必要に応じてバケットポリシーリソースを自動で作成, アタッチしてくれる）

L3 Construct
・「複数の異なるサービスを連携させたアーキテクチャパターン」を提供する
・「ALBでリクエストを受け付けてFargateで処理する」といった、より大きな単位の部品

このように「単一リソースか複数リソースか」という数ではなく「提供する部品の責務範囲」がレベルによって異なる、と理解するのが適切であり、実態に近い。

2025-7-28

TerraformにおけるProviderプラグインとModuleについて、概要を知ることができました。

Providerプラグイン
・「どのクラウドAPIと通信するか」を担当するバイナリ
・provider “aws” { … } など
・AWS版、GCP版、Azure版など複数共存可
・例：hashicorp/aws Provider

Module
・再利用可能なHCL部品
・複数リソースやロジックを 1 つにまとめ、変数でカスタマイズして呼び出す
・CDK で言う Construct に近い概念
・terraform-aws-modules/vpc/aws を呼び出すだけで VPC＋サブネット＋NAT などを一括構築

2025-7-29

Terraformの状態ファイル（tfstate）とリモートバックエンドの仕組みについて、大枠を理解することができました。

tfstate
・Terraformが「最新の実環境の構成」と「HCL 定義で管理すべき構成」の対応表を JSON で保持するファイル
・plan時に tfstate とクラウド API を突き合わせて差分を算出し、apply で差分どおりに環境を更新し、tfstate も書き換える
・CloudFormationとの違いとして、CloudFormationは AWS 側に実環境＝スタックの状態が保持されているため、ローカルファイルを意識する必要がほぼ無い
・tfstateをS3に保存 → planでS3上のtfstateと実環境を比較 → 差分だけ更新 → 新しい tfstate を S3 に上書き、という流れになる

バックエンド
・tfstate をどこに置くかを定義する仕組み
・backend “s3” などと指定する
・リモート（S3/GCS/Consul/Terraform Cloud …）に置けばチーム全員が同じ tfstate を参照でき、競合防止ロックも働く
・S3 の場合は DynamoDB でロックを取るのが定番
・CloudFormationとの違いとして、CloudFormation は API が状態を持つため、別途ストレージを考える必要がない
・マルチクラウドに対応するため、状態保存をユーザーが選択できる設計

2025-7-30

CDKコンストラクトと Terraformモジュールそれぞれの違いについて簡単に調べてみました。

AWS CDK Constructs
・主な提供元：AWS
・特徴：AWSのサービスに特化しており、L2/L3コンストラクトはAWSのベストプラクティスが組み込まれた高品質な抽象化を提供する
・部品の量：AWSサービスに関する部品は網羅的に提供されており、非常に豊富
・強み：AWSに特化した、深いレベルでの抽象化と開発体験の良さ

Terraform Modules
・主な提供元：HashiCorp、AWS、コミュニティ
・特徴：マルチクラウドに対応しており、非常に幅広いユースケースのモジュールが存在する。公式モジュールから個人作成のものまで多様性に富んでいる
・部品の量：AWSに関するモジュールも公式・非公式含め膨大な数が存在する。単純な数ではTerraformの方が多い可能性があるが、玉石混交な側面もある
・強み：マルチクラウド対応と、ベンダーロックインを避けたい場合に有利。巨大なコミュニティによる多様なモジュール

2025-7-31

TerraformにおけるPolicy as Code（PaC）について知ることができました。

TerraformにおけるPolicy as Code（PaC）とは、インフラストラクチャの構成ルールをコードとして定義し、自動的に評価することで、セキュリティ、コンプライアンス、コスト管理を徹底するための重要なプラクティス。これにより、手動レビューのばらつきをなくし、一貫性のあるガバナンスをCI/CDパイプラインに組み込むことができる。TerraformでPolicy as Codeを実現するための主要なツールとして、Terraform Cloud/Enterprise (Sentinel), tflint, Open Policy Agent (OPA) などが存在する。それぞれに特徴があり、用途に応じて使い分けられる。